Pirated Apps in the App Store - <AUTHOR> http://lipsky.me/blog/2013/7/2/pirated-apps-in-the-app-store

<comment><USER3> This happened to me recently, and it seems to be a very large scale problem on the app store. In my case there were three different copies of my app (UX Write) on the app store, under the names "Document Master", "Word Touch", and "Word to Go".

The only reason I found out about them was that in all three cases, there had been some extra resource files included for some unknown reason (likely from another app), which for a very obscure reason were causing the app to crash. I was receiving hundreds of emails containing crash logs and noticed that the process name was different, which is what tipped me off. The fact that all three had the same set of extra files (and all said "Document master" in the modified documentation file) suggested it was either three developers working together, or one developer with three separate accounts.

I found it _extremely_ difficult to get this problem addressed. I contacted Apple and was asked to fill out a form on their website about the apps, and then their legal team just sent an email to the other "developers" asking if they owned copyright. None of the developers responded, and the legal team did nothing. Several more phone calls to the developer relations team left the problem unresolved.

I only managed to get the copies taken down eventually when I was at WWDC and took the opportunity to meet in person with two representatives from the app store team and show them the original & copies. They immediately recognised it was a clear-cut case, and removed the infringing apps within a couple of days.

I think there are some very straightforward technical solutions to this - <USER2> submission process could take hashes of all files in a new upload and check them for matches in a database of hashes of all files from all apps, with any matching apps flagged for further inspection. It amazes me this isn't done, especially given the reputation the app store has for being strict about political/sexual content etc. I've seen a ton of copied apps on the store; it's just ridiculous.

<comment><USER4> If it was such a clear-cut then why did you need to meet them in person to show them?

<comment><USER3> I think it was a matter of them not having actually checked the apps themselves, and that their process was just to shovel everything off to the legal dept.

Someone else made a comment here about Apple not wanting to get in the middle of copyright disputes (particularly for cases that _aren 't_ so obvious). So that's probably why they don't have a process in place to have someone actually look at the apps. Developers have to chase it up themselves, which is annoying.

</comment></comment></comment><comment> mh- Serve DMCA infringement notices on Apple for the offending apps. The apps will certainly be removed. You shouldn't expect their legal department to respond to non-legal correspondence.

edit: not to downplay the egregiousness here. just my advice if you want this "fixed"

<comment><USER5> I have _actually_ sent a DMCA notice to Apple.

While I would also suggest the DMCA route, I can tell you that you will experience the exact same effect (no obvious response) observed by the OP.

<comment><USER6> Shouldn't this be actually the better case (Apple not replying to a DMCA notification?). IANAL, but it seems the safe harbor policy of the DMCA don't apply if the service provider just ignores DMCA notification. Which means you don't need to go after the person who actually put a copy of your software into the app store, but you can directly go after Apple. The facts in that case seem to be relatively clear, so the risk of losing in court against Apple should be low.

</comment></comment></comment><comment><USER7> This really bothers me. I've been fine with Apple's "Walled Garden" App Store approach, because I do believe it offers consumers an amount of safety when buying apps.

Anecdotally, I tell friends and family who are new to their iPhone (or Mac, iPad), that they don't need anti-virus, certainly not on their iPhone. They don't need to worry about downloading bad apps from the App Store, Apple doesn't let anything bad in (Android has a history of malware in its app store). It's what they _expect_ from owning an Apple device.

I really don't want to have to start telling them, "Careful, you could be downloading a fake app" anytime soon. I believe Apple should work harder to stop apps like these from getting into the store - it's much better for developers and consumers.

<comment><USER8> According to 148apps.biz[1] Apple gets just under 1000 apps submitted per day.

At that scale they can not "guarantee" safety. The same goes for any other application store, that works at the scale.

Some of the checking the submitter did could easily be automated and flag a user if there is a possibility.

But they "must" be using some tech like that, I hope?

[1]: [http://148apps.biz/app-store- metrics/?mpage=submission](http://148apps.biz/app-store- metrics/?mpage=submission)

<comment><USER9> With the magnitude of profits Apple makes from the App Store, they can't hire 100 smart people to intelligently and thoughtfully screen 10 submissions per day? Also, it sounds like their automated tests don't (for instance) check the submitted binary against hashes of all the other binaries that have ever been submitted, which I think would be a good step toward mitigating this particular plagiarism issue.

</comment></comment></comment><comment><USER10> I did some contracting at a place last year, while there the competition released a complete clone (as in identical) of the companies app. While we where having a laugh at how similar it was we noticed expanded the app store description and it was copied verbatim from the place I was at, which comically included links through to the support area, contact information via telephone, brand names etc...

I'm not sure what the follow up was as I was only there a few weeks, but its shocking how lazy people can be when cloning something.

<comment><USER11> Hm, if I were to pirate your software, I'd much rather direct any support requests to you than deal with them myself. As long as I get the app store revenue, that's all that matters. Don't you think that's all they care about?

<comment><USER10> The app was free, so the motivation was literally an arms race I'd guess.

</comment></comment></comment><comment><USER12> Exactly same disgusting thing happens to my app. I have filed a complaint to Apple weeks ago and yet to receive any response.

</comment><comment><USER13> I thought a walled garden was suppose to fix these sorts of problems, isn't that what Apple fans say about Android?

</comment><comment><USER14> You'd think the review process would catch this. But then I guess I should remember who apple does the reviews for. Not for customers, not for developers, but for apple.

<comment><USER15> I think Apple tries to avoid being involved too much in policing other people's IP. It can be a very messy situation with licensing and such. They tend to approve it then take it down if they get complaints.

<comment><USER16> > I think Apple tries to avoid being involved too much in policing other > people's IP.

Given that they provide the sole means of performing this infringement (given that there are no other means to make money off iOS applications), this argument is a bit too generous towards what is basically Apple not giving a shit about developer's rights.

They do not "avoid being involved too much in policing other people's IP"; they are providing the only infrastructure and act as payment processor (even taking their share!) of the infringements taking part. This is morally significantly worse than Pirate Bay and the like (who provide a service to the public), but unfortunately[1], there's no RIAA/MPAA equivalent for software developers.

[1] It's debatable whether this is actually unfortunate for the general public

<comment><USER15> To clarify, I mean that Apple does not consider it their job to require proof that a given developer owns the IP during the initial review process. They don't want to be policing contracts and stuff that they aren't a party to.

</comment></comment></comment></comment><comment><USER17> I'm curious how one would reverse engineer and acquire the source code? Not looking to do anything illegal, just wondering what goes into making such duplicate apps.

<comment><USER18> I'm quite sure that they are merely replacing some of the application's image resources and resigning it... But I could be wrong.

<comment><AUTHOR> Correct, they are simply updating the image resources and resigning the app. The code hasn't been touched (though the code is from a two year old version of the app).

<comment><USER12> I think we could add some detection to in the code that if the bundle id doesn't match, then app should display a warning.

<comment><USER17> Correct me if I'm wrong but doesn't the .ipa include the bundle ID as well as the App ID inside the binary? I didn't think it was possible to edit that and still get it codesigned for approval.

<comment><AUTHOR> Unfortunately, the bundle id is just stored in a plist file, and it's actually quite easy to re-sign an app bundle with a different profile after modifying it.

<comment><USER19> Would checking the value of [[NSBundle mainBundle] bundleIdentifier] with a hardcoded value help?

It would be a bit more code, but just a few lines of verification code when the application launches and the app can refuse to start up if the value doesn't match.

Someone dedicated would still be able to crack it, but it would at least require some effort on the part of the fraudster

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> As of this morning, the first app mentioned in my blog post is no longer available for purchase, and the second application is now only for sale in Egypt.

</comment><comment><USER17> For you android devs out there, is this something you've also had to deal with? I'm wondering how prevalent this is on the Android app store?

</comment><comment><USER20> This is possibly the worst nightmare for app developers. This problem applies to both Android and iOS.

<comment><USER21> It also applies to desktop software. This problem has been known since the good old shareware days.

Sending an DMCA complaint to Apple/Google has at least the potential to be successful. Trying to take down a web site in Russia or China that is selling your software is another story.

</comment></comment><comment><USER22> This is a problem that isn't unique to a few outlier developers. This happens frequently. A word processor that I love to death, Bean, has several _identical_ ripoff apps based on its code on the Mac App Store by a "developer" by the name of Weiwei Zhang.

The "developer" also has the audacity to charge _nineteen_ dollars for that particular application. Disgusting.

</comment><comment><USER23> Sometimes I wonder why people dread so much Apple approval process... I never got rejected.

Also, beside that, people also clone stuff NOT in the iTunes, and I mean clone by literally get someone app for other platform, reverse engineer it, and compile again for iOS and launch it as it was their own (even if controls end being shit).

<comment><USER24> Some people work on apps where Apple's policies are unclear or inconsistent.</comment></comment>


Spectrum – Image transcoding library for Android or iOS - <AUTHOR> https://libspectrum.io <comment><USER2> Figured this is worth a note here: Squoosh is an image compression web app that allows you to dive into the advanced options provided by various image compressors. [https://github.com/GoogleChromeLabs/squoosh](https://github.com/GoogleChromeLabs/squoosh)

</comment><comment><USER3> Looks interesting, though on recent iOS devices, images will be in HEIF format, which is about 50% the size of JPEG at similar quality, and MozJPEG isn't compatible with it afaik.

If you're interested in compressing JPEGs without quality loss, there's a free Mac app called ImageOptim that can handle JPEG, GIF and PNG. It has Google's Guetlzi, so on some JPEG you can reach 20-40% compression without any loss of quality that I could detect (and sometimes lower levels around 10% on images that are already well compressed or smaller resolution).

[https://imageoptim.com/mac](https://imageoptim.com/mac)

<comment><USER4> 50% is extremely optimistic between HEIF and a good JPEG encoder (mozjpeg/guetzli).

Guetzli usually produces _very slightly_ better results than mozjpeg but is several hundred times slower. The 20-40% comparision is vs libjpeg.

<comment><USER3> Guetlzi comparison is mostly against JPEGs you can find in the wild (ie. from a digital camera).

In my experience, Guetzli is a lot slowly than mozjpeg, but tops up at much higher space savings when the conditions are right.

</comment></comment></comment><comment><USER5> Is there a site which tracks the use of such libraries across popular apps, similar to builtwith?

<comment><USER6> Cocoapods' website integrates with [https://www.appsight.io/](https://www.appsight.io/)

It appears that it tries to do that.

</comment></comment><comment><USER7> More detail about the open source here: [https://code.fb.com/developer- tools/spectrum/](https://code.fb.com/developer-tools/spectrum/)

</comment><comment><USER8> It's interesting to see no iOS example code in Swift.

I know that the Swift adoption rate at Facebook is low for certain reasons, but I was hoping it would go up, or at least be of concern for open sourced projects.

<comment><USER9> As someone maintaining Obj-C libraries, I can see why. Usually the Swift examples are 90% the same thing so maintaining both is just a boilerplatey hassle. And really, I expect all competent iOS developers to be able to use an Objective-C API from Swift without even thinking about it, much less require specific examples.

With that said, I do find it useful to write unit tests in Swift, just to see that the Swift API looks as expected. So that's one way to add examples.

<comment><USER10> We write our internal demo apps for our iOS framework in Swift for this reason as well.

</comment></comment></comment><comment><USER11> Nice. Anyone have experience using this?

</comment><comment><USER12> Is there integration with React Native?

</comment><comment><USER13> Good thing

</comment><comment><USER14> Facebook has the worst image compression on any website, their photos are compressed to a point where they look horrible. Why would anyone want to use this?

I do not see what this benefits any developer over just using mozjpeg with better settings.

<comment><USER15> Do you really not see the benefit in avoiding the need to recreate a bunch of scaffolding around 3 separate image encoders, or is this just an excuse to dump on facebook?

<comment><USER16> libimage-magick should be sufficient, however I don't know how well that runs on androids and iphones.

It smells like a NIH project to me, but then again there might have been some very special requirements that facebook needed that was not already available in other libraries.

<comment><USER17> Does libimage-magick work at all in iOS/Android?

At Facebook's scale, the choice of whether to resize/crop/compress images on devices or at the backend must be a complete no-brainer. Why would you stand up additional datacenters instead of just burning a little more of your user's (your "product's"?) battery?

</comment></comment></comment></comment><comment><USER18> I like how there are 2 products called Spectrum on the front page and they are completely unrelated. Anyway, this lib looks pretty ok for it's purpose.

<comment><USER19> GAFAS tends to never do their homework before choosing a name: they know they can roll over most previous projects and just don't care about the community as long as they can't get PR from it.

</comment></comment><comment><USER20> The title should say "Android and iOS" rather than "Android or iOS", it makes more sense that way.

</comment><comment><USER21> I'm going to make a similar library called Verizon.</comment>


Half-Life 2 released for Steam on Linux - <AUTHOR> http://steamdb.info/app/220/#section_history <comment><USER2> I loved Half-Life 2. I loved Counter-Strike 1.5 (and 1.6 too). I loved Portal. Valve has done a good job of making games. But I reeeeally wish some other developers would step up to the plate and port as well. I'm thinking Borderlands, Deus Ex: Human Revolution, and others. Those two already have Mac ports so I doubt it's unfeasible to move things over. Wine typically works well enough --assuming you're willing to either fiddle with it for hours or else pay for an out-of-the-box solution like Crossover-- but nothing beats native :)

Edit: Been playing the Portal Beta. The horizontal tearing without vertical sync is annoying. Mainly because, with vertical sync, there is substantial input lag. But hey, it's called "beta" for a reason.

<comment><USER3> Sorry little off topic : Is anybody working on HALF-Life 3 ?

I was really looking forward for this, I am old now but not old enough for HL3.

<comment><USER4> Between the Steam Box, porting everything in their catalog to Linux, Dota 2, and scrambling like madmen to make the ten thousanth TF2 hat, I assume Valve has a lot on their plate right now.

<comment><USER5> Roll out a new revamped set of TF2 Unusuals and, boom!, cash enough to hire another entire product team.

</comment></comment></comment></comment><comment><USER4> Wow, I'm going to go try this! Portal runs "surprisinly well" (eg. great performance but it has occasional graphical glitches) on my machine (Arch x64, Intel HD 4000), so I'm curious to see how HL2 runs.

I understand Valve hasn't gotten the bugs out quite yet, but this is an excellent start.

Edit: Oh man, "Half-Life 2 (Beta)", "Half-Life 2: Episode One (Beta)", "Half- Life 2: Episode Two (Beta)", and "Half-Life 2: Lost Coast (Beta)" are all in my steam library. It's like Christmas all over again.

<comment><USER6> While I agree that it's nice to have native (assuming it's actually native) ports, HL2 and most of the other Source engine games have reportedly run great via Wine for a while now: [http://appdb.winehq.org/objectManager.php?sClass=application...](http://appdb.winehq.org/objectManager.php?sClass=application&iId=2095)

<comment><USER7> There's a big gap between "can be made to run under wine by following a recipe someone posted to appdb.winehq.org" and "click on Download, then Plan".

I fiddle with messy integration issues on embedded Linux and Android professionally, and am about as qualified as anyone could be to make that work. I never once bothered trying to get wine running. I installed Portal last week without a moment's thought.

<comment><USER8> Just use PlayOnLinux. It makes handling of wine configuration very easy and automatic.

</comment></comment></comment></comment><comment><USER9> You know why I'm going to download this? Because I never played the game and when I finally downloaded it to play, there were major graphics engine or driver issues that made it dirt slow and unplayable on my m11x R2. And I couldn't figure out how to fix it so eventually gave up. Coincidentally, I have Linux on my m11x R2. Maybe it'll work on Linux.

What a silly reason. But true. Wouldn't it be ironic if the Linux beta was more bug free in my experience than the Windows version...

</comment><comment><USER10> Will not buy, HL1 is still full of bugs: [https://github.com/ValveSoftware/steam-for- linux/issues?labe...](https://github.com/ValveSoftware/steam-for- linux/issues?labels=Half-Life+1)

They should at least fix the bugs which affect gameplay, so I won't end up with a library of broken games.

<comment><USER4> Half life 2 works OK on my Intel HD4000. The only bugs are graphical glitches, and they're not very noticable. (Keep in mind that Half Life and Half-Life 2 use completely different game engines; one's bugs don't necessarily translate to the other.)

<comment><USER10> _Half Life and Half-Life 2 use completely different game engines; one's bugs don't necessarily translate to the other_

Yes, but that doesn't mean there won't be bugs in HL2. And Valve not fixing HL1 before releasing HL2 doesn't bode well.

</comment></comment></comment><comment><USER11> Do they also have Portal?

Because I never played it, and if they release it for Linux, I could be this guy:

<http://xkcd.com/606/>

Even the date is about right :)

(I do play modern games as well, but due to the rebooting to another OS required for that it's a commitment which I don't make for every game)

<comment><USER12> Yes, portal is already on Linux: <http://steamdb.info/app/400/>

</comment></comment><comment><USER13> They also added VR mode if you opt into the SteamPipe beta.

See more info here: [https://developer.oculusvr.com/forums/viewtopic.php?f=42&...](https://developer.oculusvr.com/forums/viewtopic.php?f=42&t=957)

</comment><comment><USER14> I wish I had the time to support this better by actually playing some of the Linux games I've bought.

<comment><USER15> to support them, you only need to buy their games. Playing them is not needed!

</comment></comment><comment><USER16> Tried HL2 on linux yesterday. Very impressed to see that HL2 still does not look too bad even many years later. At full details on full HD, it's still very decent graphically speaking.

</comment><comment><USER17> I know this is only HL2 beta - but unfortunately it doesn't run nearly as fast as HL2 on wine. I'm on ubuntu 12.10, 2010 mac mini (nvidia graphics)

<comment><USER18> Steam on Arch Linux here, old Core 2 Duo 3 GHz, but I added a nVidia GTX550Ti (2GB) card a few months ago and HL2 is running amazingly.

Playing it on a 46" TV at 1080p. Smooth as hell and looks fantastic.

</comment></comment><comment><USER19> I am waiting for DOTA 2 to be ported on Linux; this would really help the Linux Steam platform taking off.

</comment><comment><USER20> valve said last yr they would start porting to linux to avoid microsoft 8 store plans where they want to restrict software sales to the "microsoft app store" and shave 20% fees from all sales. this would destroy the steam delivery model so makes sense they are diversifying

</comment><comment><USER21> Erm. Wasn't Half-Life 2 already out? Pretty sure I've had it in my library for months.

<comment><USER4> For linux? It wasn't in my library last week. Perhaps you got lucky and were chosen for a fancy linux beta test period?

<comment><USER21> Ah that explains it. I was indeed selected... I assumed that everybody had it when it came out of beta...

</comment></comment></comment><comment><USER22> almost thought they released half life 3 exclusively for linux or something. Wouldn't that be fun?

<comment><USER23> It's almost like it's a BETA or something.

</comment></comment><comment><USER24> Looks like my weekend is set, then.

</comment><comment><USER25> Isn't this game like 10 years old?

<comment><USER26> It may be almost 10 years old but it is still one of the best FPS games ever created. Hell I still play Deus Ex as it is my favourite game ever made. Just because a game is not brand new does not mean porting it to a new platform is not worth it.

<comment><USER4> It also helps Valve keep excitement for half-life 2 going strong when they choose to release episode 3. Then their story won't be "Hey, remember when we released the last chapter to this one back in 2007? Well go play the new one!" Instead, they can say "Hey, remember Half-Life 2? Now you can play it all over again and reacquaint yourself! Then you'll remember why you want episode 3 so bad!"</comment></comment></comment>


Ask HN: What does this ruby snippet print and why? - <AUTHOR>

  class Base
    def something
      puts "called something base"
      return {a: 1, b: 2}
    end
  end

  class Extended < Base
    def some_method
      puts "something is {a: 1, b: 2}:"
      puts something.inspect
      if false
        puts "doesn't get executed"
        something = {}
      else
        puts "something is now nil:"
        puts something.inspect
      end
    end
  end

  e = Extended.new
  e.some_method
 Edit: formatting <comment><AUTHOR>
      something is {a: 1, b: 2}:
      called something base
      {:a=>1, :b=>2}
      something is now nil:
      nil

In the end something is nil (instead of {a:1, b:2}) for me on ruby 1.9.3p194 and 2.0.0-p247. Does anyone know why this happens?</comment>


Binary File Descriptor library (a.k.a. BFD/libbfd) - <AUTHOR> https://en.wikipedia.org/wiki/Binary_File_Descriptor_library <comment><AUTHOR> Excerpt:

"BFD works by presenting a _common abstract view of object files_.

An object file has a "header" with descriptive info; a variable number of "sections" that each has a name, some attributes, and a block of data; a symbol table; relocation entries; and so forth.

Internally, BFD translates the data from the abstract view into the details of the bit/byte layout required by the target processor and file format. Its key services include handling byte order differences, such as between a little- endian host and big-endian target, correct conversion between 32-bit and 64-bit data, and details of address arithmetic specified by relocation entries.

Although BFD was originally designed to be a generic library usable by a wide variety of tools, the frequent need to tinker with the API to accommodate new systems' capabilities has tended to limit its use;[2][3][4] BFD's main clients are the GNU Assembler (GAS), GNU Linker (GLD), and other GNU Binary Utilities ("binutils") tools, and the GNU Debugger (GDB). As a result, BFD is not distributed separately, but is always included with releases of binutils and GDB. Nevertheless, BFD is a critical component in the use of GNU tools for embedded systems development.

The BFD library can be used to read the structured data out of a core dump."

Related: [https://ftp.gnu.org/old- gnu/Manuals/bfd-2.9.1/html_chapter/b...](https://ftp.gnu.org/old- gnu/Manuals/bfd-2.9.1/html_chapter/bfd_1.html)

Excerpt:

"Information can be lost during output. The output formats supported by BFD do not provide identical facilities, and information which can be described in one form has nowhere to go in another format. One example of this is alignment information in b.out. There is nowhere in an a.out format file to store alignment information on the contained data, so when a file is linked from b.out and an a.out image is produced, alignment information will not propagate to the output file. (The linker will still use the alignment information internally, so the link is performed correctly).

Another example is COFF section names. COFF files may contain an unlimited number of sections, each one with a textual section name. If the target of the link is a format which does not have many sections (e.g., a.out) or has sections without names (e.g., the Oasys format), the link cannot be done simply. You can circumvent this problem by describing the desired input-to- output section mapping with the linker command language.

Information can be lost during canonicalization. The BFD internal canonical form of the external formats is not exhaustive; there are structures in input formats for which there is no direct representation internally. This means that the BFD back ends cannot maintain all possible data richness through the transformation between external to internal and back to external formats."

Opinion:

The information loss aspect should be properly understood.

libbfd is trying to act as a "bridge" between all different object file formats(!), all of which evolved differently.

Object files are no different than databases; to understand this in database terms, think of a tool that's trying to unify all 'customer' or 'product' databases...

There will be similarities, database to database (every 'customer' database will have a customer name, every 'product' database will have a 'product' name), but there will be additional pieces of data that show up in one, that don't show up in the other... that's the information loss that we're talking about.

libbfd, again, is trying to act as a "bridge" between these different "databases"!

That makes libbfd quite the Software Engineering undertaking, despite this "limitation"!

In my opinion, anyone who has to work with object file formats (e.g., compiler writers and would-be compiler writers) should study this tool...</comment>


Why Is It So Hard to Build Profitable Robot Companies? - <AUTHOR> https://spectrum.ieee.org/automaton/robotics/industrial-robots/robotic-dreams-robotic-realities <comment><USER2> The main competition for robots are people and people are cheap, plentiful, and incredibly capable. It makes sense that robots would only be profitable in highly niche areas that were too dangerous for people or so repetitive that the bot is cheaper than the person.

It seems like we'd need something like off-world colonies, a fertility crisis or environmental collapse to really create a need. I think I'm happy with the status quo on this one.

<comment><USER3> That's true, and yet we already have a $20-30 billion (depending on who you ask) industrial robotics market.

There are a large number of highly profitible robotics companies in this area.

Fanuc with over $1 billion in net income from about $5 billion in revenue stands out[0], but also ABB ($2 billion in net income from $34 billion in revenue)[1], Omron, Kuka, etc.

They not be as interesting to report on as humanoid models, or the consumer market, but it's an enormous, rapidly growing market.

[0] [https://en.m.wikipedia.org/wiki/FANUC](https://en.m.wikipedia.org/wiki/FANUC)

[1] [https://en.m.wikipedia.org/wiki/ABB_Group](https://en.m.wikipedia.org/wiki/ABB_Group)

<comment><USER4> Yeah - those robotics company do exactly that stuff which is too dangerous or too repetitive for humans. There's also the issue of strength. Robots are a good candidate for handling materials when people literally can't. But, yeah, those robots don't look like people.

Here's an interesting fact. Most people think of forklifts as being stronger than people, and that we use them to lift stuff that people can't. That's true. But, what most people don't think about is _why_ it can lift stuff like that. Hydraulic multiplication provides the power to actually do the lifting, but, a human shaped robot with the same hydraulics couldn't. Most forklifts weight about 3x the weight of a car and are mostly filled with lead. The same will go for robots. the form factor of improving human strength doesn't really benefit from changing the strength to weight ratio, it benefits from scaling both.

edit: as context, the average forklift is so heavy that when put on a trailer they exceed the tow rating of 1500-class pickup.

<comment><USER5> This is a mischaracterization of the size and operational use of the average forklift. Small (like under 5k curb weight) forklifts outnumber the big guys by an order of magnitude. If you count the small ones that the big box stores use I'd say it's two orders of magnitude. Most fork lifts are used to move small (<1000lb) things on pallets in indoor settings.

I personally think human form factor robots are a dead end but if the Incredible Hulkbot was as readily available as a forklift then then you wouldn't see so many things being palletized in the first place because you'd just have Hulkbot move them. The reason we have so many fork lifts is because we've settled on the pallet as a form factor and forklifts are good at moving pallets.

<comment><USER4> Maybe so - I looked around on practical machinist and on some of the website before making that statement and found that few items that really looked like forklifts were available that had load capacities under 3-5K, so those probably weight about 2x their load capacity. the kind of ride-behind pallet movers aren't really forklifts, but obviously do come with lighter duty availability. For reference, a pallet of bottled water weighs about 2000lbs. and most big box stores would rather operate forklifts with some capacity overhead.

</comment></comment></comment></comment></comment><comment><USER6> I recently took a job with a robotics startup...it's a tough business to operate in with huge operating costs (compared to software), but I think there are a lot of opportunities yet untapped. The old Feynman saying "There's plenty of room at the bottom" is extremely true in robotics.

There are markets where robots have been (profitably) in service for a decade or more, but they are big robots with extremely limited roles: An arm that lifts a door onto a car, a glorified cart that follows a yellow line around a warehouse or hospital or whatever, etc.

The new generation of robots is human scale and has more flexibility built in. They deliver door-to-door/peer-to-peer, instead of along a fixed route. They carry small packages instead of a stack of boxes. They do inspections in places that aren't safe for humans. etc. Plenty of room for smaller, smarter, cheaper, robots.

But, it is definitely a tough/expensive business to build in, and the market probably doesn't have room for at least half of the companies currently running on investor money.

<comment><USER7> Why is building robots so much more expensive than software ?

Software is complex. The main tools to create software cheaper are abstraction and reuse.

Can't those be available to new robotics startups ?

Is building a robot from standard components possible ? or using some sort of software based mechanical/robotic design tool, similar to the procedural modelling 3d graphic designers are starting to use ?

<comment><USER8> I don't work in robotics, but from my electrical engineering degree, I could hazard a guess:

\- Software becomes much harder if you have to interface with hardware. You mess up software, you edit and then recompile/rerun. You mess up hardware, you need to buy a new copy of the hardware. Imagine if every time you wrote a bug or compiled a dependency with a bug, you need to pay $5 to somebody. If somebody else's software caused an error on a piece of critical hardware, your hardware may break too (e.g. car crash). And good hardware costs a ton of money. A Dynamixel servo costs something like $500, for a motor that's maybe 8 inches cubed or less, but if you use a cheap motor from China your precision over time will suck and software-based closed-feedback loops aren't as good as good hardware. So maybe you decide to do simulations, and you write a hardware emulator to load your software on. That costs a lot of money too, and doesn't and never will mimic hardware in all cases.

\- Software for robotics is pretty low-level. You may need to write drivers for special hardware you develop, or you may need to rewrite drivers if proprietary drivers don't do the job for some reason. Drivers are if not hard to write, then a long slog to write (I don't write drivers). You need to make sure your software is highly performant, lightweight, and fault-tolerant. Maybe you need a real-time operating system, or you need to fork the Linux kernel and rip out bits and pieces (I heard somewhere SpaceX does this for their avionics, because they didn't want to deal with an RTOS). There is no let-it-crash philosophy. There may be no concurrency abstractions that are performant enough besides threading/locking primitives. There's the added complexity of failover that you plan into your design. You can't live without any of these most likely, because otherwise your customers may not live at all.

\- By the time you master all the tools you need to build a successful robotics company, you haven't changed the system, the system has changed you. You accept the truth that good hardware is hard to make, good low-level software is hard to make, and great insurance plans are expensive. You're a Windows guy now because you use SolidWorks to design parts, and you can't be bothered to make a startup to rewrite SolidWorks for Linux because it's hard to get the physics/math background to reproduce even a part of SolidWork's functionality and user experience (which is a lot, CFD/FEA/etc). You deal with manufacturers who are perfectly happy with older tech because it works and because newer stuff always comes with risk. Your customers are enterprise Karens who shatter your roadmaps and don't care about your dreams.

This is a (possibly inaccurate) tasting of why building a hardware company is hard. I have the highest respect for those who do.

<comment><USER9> What is an enterprise Karen?

<comment><USER8> So this is a Karen:

"44\. mother of three. blonde. owns a volvo. annoying as hell. wears acrylics 24/7\. currently at your workplace speaking to your manager."

[https://www.urbandictionary.com/define.php?term=karen](https://www.urbandictionary.com/define.php?term=karen)

I used "enterprise Karen" as a corporate personification of "Karen".

</comment></comment></comment></comment></comment><comment><USER10> _" Overselling is a dangerous strategy that can be counterproductive, even for the whole robotics community. Both companies and researchers publish videos of robots doing tasks, but sometimes they fail to point out the limitations of the technology or that those results were achieved in lab conditions. This makes it much more difficult to explain to non-roboticist industry executives the difference between creating a one-off demo and creating a real product that works reliably."_

This makes me think of automobiles - cars were first seen as "a rich man's toy", but Henry Ford worked hard to change that perception. He said cars are for anyone. They can be used to go to work, to visit family, to go sightseeing.

I still don't see basic needs like that being addressed with robotics. For instance, is it going to take out the trash? Clean the toilets? Fix the plumbing?

<comment><USER11> Yeah, once we have a more general-purpose robot that can fold your clothes, set your table, cook breakfast, and load/unload your dishwasher, washing machine, and dryer (or at least handle a reasonable subset of those tasks) we might finally start to see some progress in this area.

Those are enormously complicated tasks to solve in the general case though, so I don't anticipate anything like that being available for quite some time.

<comment><USER12> > fold your clothes, set your table, cook breakfast, and load/unload your > dishwasher, washing machine, and dryer

But are these pain points for a sufficient number of people? I can understand robots that could do these tasks would be a godsend for disabled people and the very elderly, but those are small markets. The vast majority of able bodied people just fold their own clothes and do their own laundry. It's easy and takes minutes. I don't think I'd even pay $100 for a robot that could fold clothes.

<comment><USER13> Laundry is absolutely the biggest "housekeeping" item I have trouble with. I would pay a lot of money (thousands of dollars) for a robot that would take dirty laundry and wash, dry, and fold.

<comment><USER14> Can't you pay a human to do that, if you're willing to pay thousands to have it done for you?

<comment><USER13> Yes, I suppose I could. I guess that I don't want another human coming into my house in my absence to do that, nor do I want to have to schedule it to happen when I'm home. Nor do I want to take my laundry someplace else and have to return later to pick it up.

I could probably live with leaving the laundry on the porch and having it returned there. I'll have to look into whether such a service is available in my area.

<comment><USER15> Traditionally, you would physically separate your living quarters from the areas where servants would work. In this scenario you could have a laundry room in the basement and a dumbwaiter connecting your basement to your closet, and have a separate door that only goes into the basement.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Robots are still too stupid to be used outside of niche applications such as military or heavy industry. In these applications, stupidity is a _feature_ , not a bug, as a robot is expected to only do the tasks its owner wants it to do in the way its owner wants them to be done. But they still cannot be expected to work alongside people in their day-to-day because either they're not smart enough to interact safely with people, or people have expectations set by C-3PO and R2D2 that the robots just can't live up to (something the article touches on). Heck, people routinely get bored with Siri and Alexa because these technologies pretend to be smarter than they are, and ultimately outside of setting an alarm or playing a song, the value proposition they present does not even meet that of the stupider technologies people are used to. Real, exploitable stupidity is at the end of the day more valuable than fake smarts.

So if you want to be a roboticist and make money at it, don't expect to be Dr. Noonien Soong or Dr. Light. You will spend your career building dumb machines to perform mind-numbing tasks for the world's militaries, factories, or fast- food joints. Adding smarts to robots is a moonshot project, as Alphabet learned with Waymo -- you need to be rich or have a rich patron just to get anywhere. That's where things stand now -- maybe in a decade or two, things'll be different.

That said, I worked in robotics on such "dumb machines" for four years, and it was one of the coolest jobs I ever had. So if you can land a job in one of the niche industries where robotics is really useful, don't let my desexifying the industry dissuade you.

</comment><comment><USER17> I am not sure I agree with the article's definition of robots.

The way I see it an automatic blinder that reacts on either a timer or sunlight is in the spectrum of a robots. It's a very simple one, but it does things for me that I would otherwise have to do.

Right now it seems like people are more trying to invest and push Robots in the image of "The Jetsons" which I don't think consumers are even close to being ready for yet, plus the technology and algorithms will always lead to disappointment until we get much much further.

We need to think simpler. The irobot is successful because it doesn't try to be a Jefferson robot despite it's name but rather it solves a specific need.

<comment><USER18> My kids get confused when I refer to my 3d printer as a robot. Heck, even the 2d paper printer is a robot. In that respect, I do have some very useful robots. I would very much like a robot that could do household chores though, like laundry.

</comment></comment><comment><USER19> It's frustrating. Even basic industrial robots have not been hugely successful outside of a few areas, such as automobile assembly. Amazon seems to have given up on the Amazon Picking Challenge; the last competition was in 2017. Here's the winner.[1] That's just bin-picking. Manipulation in unstructured environments is still very poor. DARPA's manipulation and humanoid robot programs got as far as public competitions and were then discontinued. Here's how far that got.[2]

On top of that, good robot arms are expensive. Startups announce low-cost ones, but many don't hold up in continuous use. Universal Robot from Denmark seems to be doing well, but their arms start around $35,000. Rethink Robotics went bust. Even with more "AI", the smartness is mostly limited to targeting objects that aren't perfectly aligned.

[1] [https://www.youtube.com/watch?v=AljePt7Mh6U](https://www.youtube.com/watch?v=AljePt7Mh6U)

[2] [https://www.youtube.com/watch?v=jeABMoYJGEU](https://www.youtube.com/watch?v=jeABMoYJGEU)

<comment><USER7> >> Robots ... low-cost ones, but many don't hold up in continuous use. Universal Robot from Denmark seems to be doing well, but their arms start around $35,000.

$35,000 is the price of new, reliable car. and cars are much more complex, and suffer more forces trying to wear them out.

So why are robots so expensive ? is it mostly a matter of volume ? or is it something expensive about the tech ?

<comment><USER20> I think it is largely a matter of volume, Not just the volume of robots sold but also of the sensors and actuators that go into them. It's also a matter of market, no one is really selling robots in this price range to consumers, it's all going to large manufacturing companies or to large research institutes.

There are of course even lower cost robot arms, ~$100 toys, $1000 educational platforms etc. They just don't have the precision or power needed for industrial or research applications.

</comment></comment></comment><comment><USER21> > Overselling is a dangerous strategy that can be counterproductive. Both > companies and researchers publish videos of robots doing tasks, but > sometimes they fail to point out the limitations of the technology or that > those results were achieved in lab conditions.

This. Autonomous vehicles are the most obvious example of the overselling of robotics with the inevitable extending of the timelines that were promised a few years ago. The more we learn the less likely it seems we'll get AVs anytime soon, although anyone actually working in the area knew this already.

People were selling the idea of AV production systems that can solve hard robotics problems that havn't been solved in research in the most benign conditions. This was all driven by hype and money and it doesn't seem like there was much of a downside to those overpromising. Unless this changes and people are held accountable for their overselling then we'll keep seeing this behavior.

It has a genuine negative impact on anyone trying to do something that is actually possible and useful as their pitch will seem underwhelming compared to all the noise being generated by the people overpromising.

</comment><comment><USER22> The short answer is that Robots are still heavily in the research phase, and not useful enough outside of some industrial zones currently to generate any profit.

That doesn't mean we shouldn't continue investing in them - they will most certainly become more useful and generate more profit. It just means at the moment, the best we can do commercially are more or less upgraded furbies and security guards who drown themselves.

<comment><USER23> Precisely. I think we're heading into an era where we need to have a "hunker down for the long haul" mentality, and yet we're heading into this at a time when our culture is particularly impatient.

The industry is up against several Hard Problems, and it may be a long while before any real gains are realized.

</comment></comment><comment><USER24> The near impossibility of building a robot to do something as simple as taking out the trash leads me to believe that the impending automation apocalypse is much further out than many people think.

There are limitless tasks that humans can perform with ease. There are very few tasks we've discovered that machines do with ease. Those few discoveries have changed the world.

In 2019, we can design and implement solutions for robots to do almost anything. But with very few exceptions these designs fall apart when they perform outside of a controlled environment or even inside of controlled environments when tasks need to be done reliably.

<comment><USER25> > The near impossibility of building a robot to do something as simple as > taking out the trash

Part of this issue is that we think we need the robot to do it like a human would; in this example of "taking out the trash", we imagine the robot grabbing the bag of garbage from wherever, going outside, and throwing the garbage away, then returning.

Instead, what if the robot was the garbage bins themselves?

You have an inside robot garbage bin, and an outside one. The inside one would - once full - wheel itself outside and interface with the larger one to dump, then return. The outside one would periodically wheel itself to the curb to be dumped by the (probably someday fully automated - it's already most of the way there) garbage truck.

Essentially, make each robot a slightly smaller "garbage truck" that can be dumped by the larger units.

Of course, that still means the robot needs to be able to navigate a home, open and close doors, etc. If the home had automatic doors, that would make things easier. Then it would become a navigation problem mostly.

It's kind of like something I told a guy at my work who said he wanted to build a robot to bring him a beer. He was wondering about all the complexity, etc.

I told him - why don't you make the robot be the refrigerator, then you'd just summon the fridge to wherever you were, and it would dispense a beer, then return back to the kitchen.

Dish cleaning? What if the cabinets were dishwashers instead? Plumbing would be a nightmare - but in theory it would be possible.

Basically - think of ways to make the problems more tractable for the machine, instead of trying to make the machine act like a human (note the automation in many factories that does jobs humans use to do - they didn't make the machines/robots look like humans to do them, right? In many cases, the tasks and such were even changed for the sake of the machine handling/assembly - such home tasks could be looked at in the same manner, to an extent).

<comment><USER26> Thats the whole challenge we're dealing with now, right? Robots are trying to participate in a world where all of the interfaces are designed for humans, and thats why we get hung up on humanoid designs. I think its probably equal parts whatever the futurism equivalent of nostalgia is and and the raw practicality of making robots that understand human-world interfaces seeming easier than rebuilding the entire human world with robots in mind.

</comment></comment></comment><comment><USER27> Most hardware based consumer technology is derived from industrial technology. Let this be electrical components (motor and such), computers, dishwashers, or cars/automobile. Even though consumer purchasing power has been getting stronger these past two decades thanks to the large boom in software development, it's still not strong enough to push key technology. If the industry does not adapt "general" robotic technology, there is very little chance that consumers will see this in their households any time soon.

<comment><USER28> Counter example: LiPo phone batteries

<comment><USER27> But the cellphone industry started in with the industry. Either from the early shoebox cellphone to the later model of Nokia and Sony Ericsson in the 90s. The main purchasing driver was for business use. It eventually got to the point of BlackBerry and iPhone which the consumer can buy.

</comment></comment></comment><comment><USER29> When I saw Chobits as a kid I was excited about home robots, but I feel like Instead we got smartphones.

I still think home robots could be amazing, they could interface with you easily by voice and control everything connected to your network, act as GPS when they follow you to your car, go buy groceries for you.

But I'm well aware that, if a robot like that is made, the implications on privacy would be terrible (if privacy still exists by then)

<comment><USER30> > But I'm well aware that, if a robot like that is made, the implications on > privacy would be terrible

I give it 5 years maximum before Amazon releases an "Alexa" robot that is initially just the same Alexa we all know, just mobile (flying or rolling, or both) with a small arm and able to do a few rudimentary tasks. There is no real loss of privacy to be expected over current Alexa anymore.

<comment><USER31> _an "Alexa" robot that is initially just the same Alexa we all know, just mobile (flying or rolling, or both) with a small arm and able to do a few rudimentary tasks._

"Alexa, get me a beer!" Actually, a device or a couple of combined devices which could enable that gracefully might sell pretty well. (Some kind of fridge which can dispense canned beverages as the 2nd device? This could be adapted from vending machines.)

<comment><USER30> Even if they just tamper with immobile, non-fragile objects like physical light switches and door openers and if they follow you around as a mobile BT speaker/alexa, such robots would be useful.

<comment><USER31> _Even if they just tamper with immobile, non-fragile objects..._

Like stubborn, sedentary spouses?

</comment></comment></comment></comment></comment><comment><USER32> Note that they aren't talking about Kubota, Cincinatti Milacron, etc. People that make robots for manufacturing are doing ok. But that also points to a big hole in this story, robots and what they are.

Back when I was running the Homebrew Robotics Club the question of "what is a robot" came up several times. Typically the definition is a machine that can perform some task while responding to changes in its environment that might otherwise prevent the task from being completed. The essence being sensing, executing an action to achieve a result, and identifying/signalling completion of the action. By this definition your dishwasher is a robot, it senses water temperature, dish placement, and sometimes even the amount of soiling on the dishes. It may adjust its cycle to insure the dishes are clean.

But most people mean mobile, anthropomorphic devices that interact with people when they think "robot." And making a business in that space is very hard indeed.

In part because we don't really have a way to "value" what the robot is doing. When you replace a union auto worker with a robot, you can directly compare the what you would have paid the worker in salary/benefits/training with what it costs to operate the robot. The math is "easy". But when you have a robot that is more "companionable" than not having a robot? How do you value that? And if you have tasks like "fetch me a beer from the fridge" that the robot can do, how do you evaluate the value of that versus doing it yourself?

Most people say "I'd love a robot that would pick up laundry off the floor and put it into the basket next to the washing machine." But if you say, "Here you go, for only $20,000 (ask about our payment plan), our picker-upper 1000 will collect dirty laundry and put it in the basket." people always blanch and say, "Heck for that much money I'll do it myself."

<comment><USER33> Which is a little weird, because a $10/hour job for 40 hours/week for 50 weeks/year is $20K. The robot can presumably work 168 hours/week for 52 weeks/year, which means that it's roughly 1/4 the cost of a human (and that doesn't count hiring time, HR training, sick days, worker's comp, taxes...)

The real issue is that we expect minimum wage workers to operate independently on minimal instructions, and as every programmer knows, explaining what you want done to a computer is much harder than telling a competent adult.

</comment></comment><comment><USER34> They are working with a terrible definition of "robot". Most robot companies are profitable, if we are talking about all of the companies that participated in the huge surge of automation that swept of the Western world during the postwar boom of 1945 to 1973. Some of the biggest of the companies are still profitable. This is also a line of work that has, somewhat, consolidated into the hands of German firms. Siemens is probably the best known of the older companies, and SAP is the best known of the modern software companies, but there is a lot out there.

See: [https://ias.german-pavilion.com/en/home/](https://ias.german- pavilion.com/en/home/)

</comment><comment><USER35> The more structured the task the sooner robots will be doing it. They've already eaten factory assembly where you do the same repetitive action every time. Now they're making their way into cleaning the floor, mowing the grass, cleaning up spills at stores, and (cough) putting items into boxes for online deliveries. Soon they'll probably be stocking shelves too. But a robot that can pick up your house the way a cleaning service can is probably the last thing we'll see before AGI.

</comment><comment><USER31> Perhaps highly contextually constrained applications are where we should look first?

Machine Learning used for power tool kickback detection: [https://www.youtube.com/watch?v=OdW7vhYYSdM](https://www.youtube.com/watch?v=OdW7vhYYSdM)

EDIT: This is a bit risque, but I'm seriously asking: Has anyone applied Deep Learning to sex toys? The timing and processing of feedback involved seem like a good target for current tech.

<comment><USER36> Possibly NSFW [https://www.indiegogo.com/projects/autoblow-a-i- replicates-h...](https://www.indiegogo.com/projects/autoblow-a-i-replicates- human-oral-sex-techniques#/)

<comment><USER31> _Possibly NSFW_

Possibly.

o_O

</comment></comment></comment><comment><USER37> I worked on a consumer robotics project which had great promise (in my biased take at least) but ultimately was canceled and scrapped due to poor management leadership in my opinion. It is expensive to bring a hardware group up and running, and I believe that there were expectations to create a class-leading product from nothing in under 5 years when it should have been at least 10 (see iRobot's Terra project timeline). It was a very exciting project and I am slowly getting over it's untimely and premature demise :(

The constant changing of requirements was a challenge but that is normal for any engineering project. I think the ultimate problem was the lack of understanding of the "Iron Triangle[1]" in project management. The company wanted it Fast Fast Fast Cheap and Good (in that order) but my team was trying to make it Good Cheap Fast (in that order). So, I think if we did it all over again we would have reprioritized from the beginning and dropped all the complicated design decisions we made, and work on those in version 2 just like any good MVP[2]!!

I think the key for a successful hardware project is strong technical leadership who understands the pitfalls and timelines of designing the mechanical, electrical, and software as well as can evaluate when and where to build vs buy across the project lifetime. With robotics in particular it is also important to understand how we can limit the environment to make things easier for the robot to operate, with things like magnetic or painted stripes on a floor, ultrawideband beacons, things like that. Making an autonomous system robust is difficult enough in a controlled environment!

[1] [https://en.wikipedia.org/wiki/Project_management_triangle](https://en.wikipedia.org/wiki/Project_management_triangle)

[2] Some examples of things we could have completely dropped to save development time: Bluetooth and phone app, designing low cost custom motor drives, use standard materials instead of injection molded parts

<comment><USER38> I really wish product development failures were described in as much detail as successes. So much time is wasted by repeating mistakes someone, somewhere has already made.

</comment></comment><comment><USER39> 1\. Robots get classified as toys which sets an unreasonable price point.

2\. Robots arn't good enough yet despite any hype you've heard.

3\. In cases where a the product works better than the alternative and people are willing to pay a sustainable price the company does well ... just like every product ever.

</comment><comment><USER40> Brain Corp in San Diego is solving this problem as we speak. In about two years, they've enabled floor care machines, a vacuum, and now an inventory tug for grocery stores.

<comment><USER41> Just checked out their tech - pretty interesting stuff. Leveraging other peoples machinery cuts out a huge amount of manpower needed to build a robot from the ground up.

</comment></comment><comment><USER42> Isn't it very hard to build _any_ profitable company? Or are robot companies appreciably/an order of magnitude harder to make profitable?

<comment><USER6> Just from a logistics perspective hardware is harder than software to make profitable, and robots as a business involves a lot of hardware. More things have to go right, fewer things have to go wrong, etc. You rely on an entire supply chain to get things mostly right mostly on time, and that supply chain is mostly out of your control; you can have strong contracts, you can line up multiple suppliers for each part, you can vet them carefully, but at the end of the day you're tossing the dice that they'll deliver.

I've been working with a robotics startup for the past few months, and I'm often struck by how much extra stuff has to come together to deliver the product (in our case, we have to integrate with phone and elevator systems, have to deal with various regulatory compliance in every country we ship to, etc.). The sales pipeline is also long and expensive, involving shipping out multi-thousand dollar devices for evaluations, sending people out to demo the devices, etc. It's a _production_ involving a half dozen people and thousands of dollars worth of resources to make every single sale.

So, yes, I think they are harder than some kinds of businesses. At _least_ an order of magnitude harder than software. Though, because of it, the competitive landscape is somewhat smaller...robots are cool, so a lot of people want to work on them, so there's more than the market will support, but it's less pronounced than, say, the mobile app market in terms of competition for customers.

<comment><USER42> This makes sense to me. I think the word "robot" has some historical/cultural connotations that lead us down this rabbit hole of defining what a robot is. Rosie from the Jetson's? R2D2? FANUC industrial robots? It's tempting then to cherry pick one's own definition of a robot, and point out challenges and theorize why it's hard to build profitable robot companies. The question is fallacious.

In general, I think the hardware business is hard for all the reasons you mention. Or better stated, the hardware business has characteristics that make it difficult to get right the first time (more important in hardware than software, I'd argue) and scale. It's not inconceivable for a single (or a small team) to build a useful software product that makes money (several successful mobile apps, companies like 37signals, etc.). It's difficult for me to think of similar hardware analogs (I'd love examples!). This isn't to say that scaling software—building companies like Google–isn't incredibly hard. It is. But for a hardware company to even have a chance, it needs a minimum scale threshold from the very get-go (besides all the other things that any business needs – a useful product, luck, etc.).

I used to work for a large aerospace company in the early/mid 2000s, and the products we built were useful, and amazing (hunks of metal weighing tens or even hundreds of thousands of pounds flying in the air transporting people). I was absolutely awestruck by the fact that upcoming companies like Google and Facebook (which were "just websites" in my then-naive worldview) had fewer people, and made way more money than us.

</comment></comment></comment><comment><USER43> It's simply too early. The product cycle is probably going to be very similar to smartphones. Two decades with lots of prototypes but negligible market impact (Apple Newton, PalmPilot, HTC P Series). Followed by a decade of rapid expansion when all the desired features can finally be implemented (like in the iPhone). We are probably still in the Newton decade.

</comment><comment><USER44> There are a lot of profitable robot companies. They make washing machines for clothing and dishes. I have one to open my garage door. Like industrial robots they have people on either end feeding them.

I'm sure more robots will appear and some will be successful and called something else. (I'm a lot adopter of the vacuum, but there are others in developement)

<comment> gingerbread-man "'I would say that a robot is a physically embodied artificially intelligent agent that can take actions that have effects on the physical world,' says roboticist Anca Dragan of UC Berkeley." [[https://www.wired.com/story/what-is- a-robot/](https://www.wired.com/story/what-is-a-robot/)]

Industrial robots and Roombas may fit this definition, because they are controlled by fairly sophisticated software that synthesizes inputs from arrays of sensors to perform complex physical tasks. But less advanced machines like dishwashers and garage-door openers don't really reach that level.

Garage door openers do take input from an optical "obstruction" sensor, but the response is binary: don't close the door. In contrast, robotic vacuums translate distance sensor readings into a motion plan to cover every square foot of your room while avoiding obstacles.

<comment><USER45> That is a pretty narrow definition of robot. The term is often used to describe programmable, but not artically intelligent, machines. Like robots used in car manufacturing. I agree that washing machines shouldn't qualify though.

I think robot implies complicated actions that are reprogramable to perform a wider array of functions.

</comment></comment></comment><comment><USER46> Gall's Law : A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

<comment><USER47> Added to [http://github.com/globalcitizen/taoup](http://github.com/globalcitizen/taoup)

</comment></comment><comment><USER48> It is very difficult to have a company culture that optimized both for software and hardware.

"Move fast and break things" doesn't work when you have to retool your production line or throw away inventory, or call a supplier to request changes.

Conversely, hardware development processes tend to be too rigid and slow when applied to software.

It is very, very hard to get these working together even (and particularly) when they are two distinct groups in a company.

I have had to deal with 'firmware' updates on a VM. You know, the full "build and download a binary" thing from some website, upload to FTP, then login to a website and point to that FTP server, so the binary would be applied and the instance restarted.

No big deal, right? We do that sort of thing for OS upgrades, right? Except it wasn't an OS upgrade or actual firmware, it was updating the application running on that machine. The sort of thing that could be accomplished by an automated CD job, and a docker pull (or heck, apt-get update). All because the thing was an appliance. So it was lifted and shifted as-is and now "it's a cloud app, because it's on AWS!".

I have had to argue against authentication for a HTTP health check. "But if there is no authentication, people can spam the endpoint, and it's slow and returns a lot of data". Ok, first thing: it's not a public accessible endpoint. Second, I'm not interested in testing auth or taking the machine down when credentials expired. And third, if it is slow, then just return a HTTP 200 for me if it is ok, I don't care about anything else. "But if I just return 200, it doesn't mean the app is actually working". Ok, so go do the checks at whatever interval you want, and return the last run. "But this needs authentication, otherwise there could be a DOS, as the checks are slow." No you don't understand, they are supposed to be async... This went on and on for months. I finally got the health check.

... but then, now they want to log all packets to our centralized logging, so that they can count them. Dude, expose a metrics endpoint, Prometheus will call it periodically. "But there are too many messages, we can't hold all of these!" No, you give me a counter. Return the counter. "But counting messages is even slower". No... you increment the counter _as you receive them, not when I request_.

 _sigh_

So anyway. Even when hardware is amazing, software development can lag behind. Or vice-versa.

</comment><comment><USER49> I see google as more of robotics company in making. They have software to identify things, surrounding and object like we humans do(which I think is a big feat).

They have a lot more pieces of complete robot problem.

</comment><comment><USER50> Why wouldn't this work like personal computers? You use them at work or encounter them in school. When they're prevalent in those places, people begin bringing them home.

</comment><comment><USER32> Apropos of nothing, Intuitive Surgical is a profitable robot company.

</comment><comment><USER51> What we now think of as "robot" companies aren't really robot companies, they are software companies. The hardware is easy and will be commoditized.

</comment><comment><USER52> supply chain, rapid tech shift that affects _and_ effects capex, known unknowns and unknown unknowns.

</comment><comment><USER53> [https://youtu.be/1o_1d26JU5s](https://youtu.be/1o_1d26JU5s)

</comment><comment><USER54> [https://outline.com/C438br](https://outline.com/C438br)

</comment><comment><USER55> Hey, I could probably answer this one without needing to read the article, as I have literal TONS of robots in my solar facility.

You know those nice multi-tens-of-thousands-of-dollars Japanese robotic arms? We ditched them because it was just as simple to build our own robotic arms with basic framing and motors.

At a literal tenth of the price ($70K for our Kawasaki armature, $7K for our hand-built array of framing and motors with vacuum lines for picking up and placing solar cells.)

Our in-house robot runs faster as well.

</comment><comment><USER56> I guess a big problem is being realistic about the market needs. Maybe give up on dreams about humanoid helpers and focus on industries that actually are desperate for smart automation (e.g. logistics).

If you're interested in AI+robotics jobs check out [https://nomagic.ai/](https://nomagic.ai/) \- we're hiring! Super exciting work with xooglers, academics and oxbridge/ETH grads.</comment>


Turn mailing list sign-ups immediately into paying customers - <AUTHOR> http://42insights.com/turn-mailing-list-sign-ups-immediately-into-paying-customers/

<comment><USER2> Great advice. If you're just starting this, don't get hung up on the automation steps at the end; just change your welcome email, and go from there. If you have such a big list that you need to automate the scheduling etc., then deal with it when it's a problem. Don't let fiddling with that get in the way of acting now.

<comment><AUTHOR> Good point. The first step should always be to implement the process. Automating it from the get go can result in more effort than it's worth, when you decide to change and iterate on the process as you move forward.</comment></comment>


Qualcomm's New Smartwatch Chips Promise 'No-Compromise' WearOS Exp Later This Yr - <AUTHOR> https://beebom.com/qualcomm-new-wear-os-chips/ <comment><USER2> I'm not much into smart watches but this is big news. The current Qualcomm chip is 2 years old and totally outdated. Essentially Qualcomm killed the Android based smartwatch market by not innovating.</comment>


Why am I doing this? - <AUTHOR> http://bits.usablebytes.com/?p=38

<comment><USER2> I live by the idea that no person will do things exactly the same way I do them.

Best of luck to you.</comment>


New Stealth Spy Drone Already Flying Over Area 51 - <AUTHOR> http://www.wired.com/dangerroom/2013/12/new-stealth-drone/ <comment><USER2> As a side note: Aviation Week is an incredible magazine. Next time you are at the magazine rack, be sure to check it out. Our office has a subscription and it just blows me away what is happening in the aviation sector. They cover everything, from jets, military, spy technology, to satellites.

</comment><comment><USER3> Aveation Leaks article is much more informative: [http://www.aviationweek.com/Article/PrintArticle.aspx?id=/ar...](http://www.aviationweek.com/Article/PrintArticle.aspx?id=/article- xml/awx_12_06_2013_p0-643783.xml&p=1&printView=true)

<comment><USER4> Yes, it is more informative. Does Wired just steal the content by adding the words, _" according to Aviation Week and Space Technology"_, to their own article. Or do they pay a fee to Aviation Week to license the content? If it's the latter, why don't they just reprint the original and better article? Can anyone familiar with the magazine business explain this?

</comment></comment><comment><USER5> Sounds to me like this is the UAV follow-up to the U2 programme rather than the SR-71. It almost certainly flies s-l-o-w-l-y as per a B2 rather than at SR-71 insane-mega-speed. It has 24 hours or so of loiter time with no in- flight refuelling.

Good luck with that, flying over the Crimea, with Russian S-400 missiles just a few kilometres away. Imagine the consequences, anything up to full-on war just because they shot down one of our drones.

<comment><USER6> That's my impression too. The most basic air force can defend against drones, let alone Russia's. Even this supposedly stealth drone is very obvious, from behind. Any IRST system would detect it immediately.

<comment><USER7> IR attenuates rapidly in the atmosphere and is only useful for very short range detection (short range missiles, TV remotes, "laser" tag guns). The artist's concept seems to show the standard flat exhaust intakes (first employed on the F-117) which increase efflux "surface area" (versus a circle) to promote mixing with ambient air. There might be pre-exhaust mixing too.

<comment><USER8> IRST systems are actually quite long ranged for detection, it's identification that is more problematic. F-14D IRST systems were quite good at long range detection, and those were much older legacy systems with nothing like today's technology.

<comment><USER7> Yeah, but still very limited by aspect angle to engine exhaust. Detection is ok, tracking is poor unless very close or with LoS to the tailpipes. Anything ground-based will almost never be able to stare directly at the aft end of an aircraft except during egress (i.e. after it's done its job). What I'm getting at is there are huge limitations to passive tracking of IR emissions, otherwise we'd be using it instead of (active) radar.

<comment><USER8> An aircraft moving at near Mach speeds has a significant amount of friction caused by air. It's not necessary for an IR system to be able to see the exhaust of an aircraft. In fact, all aspect IR missiles have been around since at least the AIM9L which was used in the Falklands War in 1982.

</comment></comment></comment></comment></comment></comment><comment><USER9> What I'm curious about is, what sort of advanced technology are our rivals and 'allies' flying over us? Is our air/surveillance superiority absolute, or do they spy on us like we spy on them?</comment>


Startups Shouldn't Follow Trends - <AUTHOR> http://adii.me/startups-shouldnt-follow-trends

<comment><USER2> I couldn't agree more. We're in Toronto and I'm often left scratching my head asking "Why" after reading Techcrunch, HN and other startup-centric sources. If you aren't solving a problem for a customer, then you are wasting effort. Problems come in many shapes and forms - seek them out and solve them better than anyone else, that's the secret to a successful business in a nutshell.

<comment><USER3> In some cases the customer is the investor; the product is the startup. Or so it seems.

</comment></comment><comment><USER4> I agree with this. I see most of the people here doing what everyone else is doing. Using RoR and AWS because it's 'cool', using all kind of bullshit names to indicate non-existing bullshit jobs, applying practices because everyone else is using them... There's nothing wrong with using a normal programming language that has debug tools (such as C#) and there is nothing wrong with building something that has nothing to do with social media, but something that's actually useful. Yet some people think that they can become rich by doing what everyone else is doing... Doesn't work like that.

Too bad the author kind of participates in this as well with hipster terms like 'ex-rockstar', 'bootstrapping' and 'lean startup'.

<comment><USER5> There's nothing wrong with using a normal programming language like Ruby either. Many people use RoR because it's a good tool, not because it's 'cool' (aside: is RoR even 'cool' these days?). All tools have their strengths and weaknesses and while I tend to agree with you that C# has nicer debugging tools, that is only one of many important considerations when choosing a tool.

Agree with your other points, particularly about doing something that isn't social media.

</comment></comment><comment><USER6> Wait, blogging using Svbtle about not following trends as the ceo of a web startup centered around delivering wordpress themes? I don't mean to hate, but I can't not ask for an explanation.

<comment><USER7> To be fair to Adii, he was one of the first to sell WordPress themes. His startup, WooThemes, helped lead that trend.

Though I completely agree about the blogging on Svbtle.

</comment></comment><comment><USER8> Agreed. I go to startup meetups and it's crazy how similar all the ideas are. My startup is B2B and ad-supported, two things that are definitely not trendy, and I kinda dig that.

<comment><USER9> I've observed this too at a number of startup pitch events. There are countless people ready to build a business based on some little missing feature of Pinterest, Twitter, Facebook, etc., but there is almost no one that wants to solve any problems in any established industry. Seems crazy to me. Sure maybe building B2B software isn't always sexy, but there are tons of interesting problems to solve, and lots of real money to be made.

</comment></comment><comment><USER10> _[x] shouldn't do [y]_. meh

Social was taking off (myspace, friendster etc) and Facebook hopped aboard that train, and road it longer and harder, than the others. The rest is history.

However I do agree that going against the grain can work too, just skeptical of one-size-fits-all advice.

Also, one _should always_ tell readers not be trendy, while blogging about it, on the ultra-trendy and exclusive SVBTLE network. :p

</comment><comment><USER11> I agree with this article, but I have one suggestion. Don't do what's trendy, but also don't start to hate everything that is trendy either.

I've seen people on both sides. Those who wont touch anything that is conservative or a little bit enterprisey and (quite intelligent) programmers who have allergic reactions to anything that is not .NET or Java (and even within .NET, they don't consider things like F#).

</comment><comment><USER12> I agree. The product decides itself, how it's gonna be implemented. Things evolve with time, just you've to look the best option at that time. I do agree too with the bootstrapping point, it's always good to be in a lean mode, if you are doing a startup and do not have a solid back support.

</comment><comment><USER13> _Stop doing things just because they're trendy and mainstream media seems to reward it with publicity. It's not clever business._

Am I the only one left wondering why isn't it clever business?

</comment><comment><USER14> solve hard problems. Things have become easy now a days so it should be more affordable and doable to really solve hard problems.</comment>