The first person to hack the iPhone is building a self-driving car - <AUTHOR> http://www.bloomberg.com/features/2015-george-hotz-self-driving-car/ <comment><USER2> Prototypical case of the 80/20 rule. He has implemented the happy case. But that system is nothing people realistically would want to drive their cars.

What he did is impressive. But the results are not that outlandish for a talented person.

1) Hook up a computer to the CAN-Bus network of the car [1] and attach a bunch of sensor peripherals.

2) Drive around for some time and record everything to disk.

3) Implement some of the recent ideas from deep reinforcement learing [2,3]. For training, feed the system with the oberservations from test drives and reward actions that mimick the reactions of actual drivers.

In 2k lines of code he probably does not have a car model that can be used for path planning [4] (with tire slippage, etc.). So his system will make errors in emergency situations. Especially since the neural net has never experienced most emergencies and could not learn the appropriate reactions.

And guess what, emergency situations are the hard part. Driving on a freeway with visible lane markings is easy. German research projects autonomously drove on the Autobahn since the 80s [5]. Neural networks were used for the task since about the same time [6].

[1] [http://www.instructables.com/id/Hack-your-vehicle-CAN-BUS- wi...](http://www.instructables.com/id/Hack-your-vehicle-CAN-BUS-with-Arduino- and-Seeed-C/)

[2] [http://arxiv.org/abs/1509.02971](http://arxiv.org/abs/1509.02971)

[3] [http://arxiv.org/abs/1504.00702](http://arxiv.org/abs/1504.00702)

[4] [http://www.rem2030.de/rem2030-wAssets/docs/downloads/07_Konf...](http://www.rem2030.de/rem2030-wAssets/docs/downloads/07_Konferenzbeitraege/Ruf- Ziehn-et-al-2014-Evaluation-of-an-Analytic-Model__ICMC2014.pdf)

[5] [https://en.wikipedia.org/wiki/Eureka_Prometheus_Project](https://en.wikipedia.org/wiki/Eureka_Prometheus_Project)

[6] [http://repository.cmu.edu/cgi/viewcontent.cgi?article=2874&c...](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2874&context=compsci)

<comment><USER3> Why is the first comment on HN minimizing this truly impressive project? Of course it's not perfect, he's ONE person.

<comment><USER4> Because this article reinforces our bizarre cultural notion that one person deserves all the credit for some innovation.

Nevermind the ridiculous amount of engineering that was required to build all the tools he's using and the order of magnitude more engineering required to make this a safe, mass producible product.

But nah, let's just praise the founder, allow him to get rich while we all do the dirty work.

<comment><USER5> This comment is depressingly cynical. This is probably the single best definition of "hacking", as the community often refers to it, that I've seen in a very long time. One guy starts working on something only the biggest companies in the world dare attempt, throws together a minimal prototype built on top of existing technology. Just look at the picture of it.

Claims of commercial viability or beating Tesla are a bit ridiculous, but this is pretty damn amazing.

<comment><USER6> I think it's a fair comment given his quote "I know everything there is to know" and the headline of the article claiming he's "building a self-driving car by himself". I've always thought the "hacker" community attributed value to sharing and building off other's work, but maybe times have changed.

<comment><USER7> Seems obvious to me that the journalist was manipulating what he said which was that he is deeply familiar with the state of the art of AI tech.

<comment><USER6> To expand on that: '"I understand the state-of-the-art papers," he says. "The math is simple"', which seems like an attitude of someone without a solid understanding of ML. But who knows, maybe he's figured out something the rest of the field hasn't...

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> "His self-funded experiment could end with Hotz humbly going back to knock on Google's door for a job."

The biggest thing here IMO is this is self-funded. Any startup trying to do what he is doing in this environment would have raised $50 Million, hired 100's of engineers from top notch schools, become accepted in YC, and have Marc Andreessen, Paul Graham, Sam Altman and all singing their praises.

Kudos to him for being self-funded.

<comment><USER9> Creating 1 job is better than hundreds?

<comment><USER10> Well, Hotz did state that, "The truth is that work as we know it in its modern form has not been around that long, and I kind of want to use AI to abolish it. I want to take everyone's jobs. Most people would be happy with that, especially the ones who don't like their jobs. Let's free them of mental tedium and push that to machines. In the next 10 years, you'll see a big segment of the human labor force fall away. In 25 years, AI will be able to do almost everything a human can do. The last people with jobs will be AI programmers."

<comment><USER11> Yeah and the world will split in rich and poor people with poor starving.

<comment><USER12> What interests me about your argument is the assumption that the "poor starving" will just sit by and passively accept that.

The reason we don't have an insurrection on our hands _now_ about wealth disparity is that while the wealth of the super wealthy has accelerated hugely so has the general living standard of the poor, if (when) the jobs go away that will no longer be the case and then you are talking about a brutal escalation into a full insurrection and while the technology and wealth will be on one side, the last 15 years in the middle east has shown what committed people with pickups and AK's can do against an on-paper massively superior opponent.

I just hope the super wealthy are smart enough to see this coming and avoid it, it would be spectacularly brutal.

</comment></comment></comment></comment></comment><comment><USER13> > "I understand the state-of-the-art papers," he says. "The math is simple. > For the first time in my life, I'm like, 'I know everything there is to > know.' "

Yep, he's still in his twenties.

<comment><USER14> I wish I could upvote this more. A person in their 20's knows nothing, but thinks they've outsmarted the world. It's not until your 30's that you realize how big of an idiot you were/are and how much of the world you actually understand (read: little).

<comment><USER15> This whole: "Twenty year olds don't know shit but 30 year olds are so enlightened" sentiment needs to stop. I agree that many younger people _think_ they understand more than they do but that's just part of growing up and we all go through it.

<comment><USER16> You are misunderstanding the sentiment. No one is saying 30 year olds know everything, they are saying 30 year olds _realize_ they don't know everything.

<comment><USER17> Or as Socrates put it, "the only true wisdom is in knowing you know nothing"

(probably one of the more Buddhist-ish gems from Western philosophy)

</comment></comment></comment></comment></comment><comment><USER18> Like most hard problems, it's easy to pick off the low-hanging fruit and claim that you have solution.

Self-driving cars (in some form or the other, under some loose definition of "self" and "driving") have been around since the 20s. But it still remains a vexing problem.

It is quite easy to program a car to stay between 2 cars and follow the car in front. It is quite another to have the same car drive on (a) a road without lane markings; (b) in adverse weather conditions (snow, anybody? Hotz should take the car to Tahoe); (c) in traffic anomalies (ambulance/cop approaching from behind; accident/debris in front; etc. etc.); and so on.

No offense to GeoHot, but I'd love to see his system work in rush-hour 101 traffic; or cross the Bay Bridge, where (coming to SF) the lanes merge arbitrarily.

The key challenges are not only to drive when there's traffic; but to also drive when there's NO traffic, because lane markings, etc. are practically nonexistent in many places.

Having said all that, I still admire his enthusiasm and drive(no pun intended). Tinker on!

<comment><USER19> TBH, since it's a training based system it's "just" a matter of making sure the training set is large enough, including the situations you mentioned (assuming the training method is robust, generalizes well, etc). I would love someone knowledgeable to give an estimate, but I would guess you need at least a handful (10+?1000+?) of examples of each edge case (involving bicycles, pedestrians, weird road designs, street signs, and so on) -- and there are many of them I suspect (at least 100s?). Estimating you'd take about 1 hour between experiencing a tricky scenario while driving around, this should put the number of hours at something like 100,000+ -- not easy to come up with by himself (that's about 50+ years of driving 6 hours a day).

Mobileye is doing something interesting by curating the reliable parts of the dataset (e.g. they have curated databases of traffic signs for each region) -- again not something you could do own your own, and seemingly archaic (hence GeoHot's criticism), but if you can afford it can speed up the training significantly.

Tesla is a massive resource here because they already have a huge fleet of internet connected cars proving enough data to fill the aforementioned training set in a matter of days or months: let's estimate their fleet at 40,000 cars -- then they could fill that minimum dataset in less than a day, and in a month they might have a 100x safety margin. Of course, there's a big technical problem of relaying all that video (maybe they just relay prediction failures), but the data is there.

Another fundamental problem with exclusively hands-off training (and little optimal control theory, etc) is picking up bad habits from drivers -- even the best algorithms will have a hard time and be only about as good as a good driver in each scenario, in the best case -- since the training data is acting as a ground truth.

<comment><USER18> > I would love someone knowledgeable to give an estimate, but I would guess > you need at least a handful (10+?1000+?) of examples of each edge case > (involving bicycles, pedestrians, weird road designs, street signs, and so > on)

The problem is: there are new edgecases born every day.

Consider, for example, an accident where the cops have set up flares. How often do you come across one of those? Very rarely, I imagine. And even if you did come across it in your training set: how does the ML know that you are following the cops' signals, and not just randomly switching lanes? That the flares are a critical signal?

<comment><USER19> Good point, but if you consider the Tesla dataset... it's formidable. Every day they could collect data enough for ~55 years of driving a lot every day. Even if you never encountered this case, if it happens at all it's likely to be seen many times (probably 100+ in a few months) in that dataset. After driving cars have gone mainstream, this may start to be seen as a design problem by traffic agencies: they might standardize ways to deal with traffic a little more.

Ultimately as long as the cars driving autonomously is small enough and procedures change slowly enough you should be able to continously update the driving system.

But let me reinforce that a pure learning approach even with very large datasets may not be efficient as one would like -- the curation of signs is a good idea, and manually reviewing accidents and near misses (a highly human- intensive task) and perhaps flagging bad driving behavior (probably after some outlier screening, which can be good or bad) will be important to get it really good with the training-intensive approach (and not the top down optimal path planning and control approach).

EDIT: Mobileye CEO discusses some interesting design issues and manual validation (and shows they have lots of data, good sign) [https://www.youtube.com/watch?v=kp3ik5f3-2c&feature=youtu.be...](https://www.youtube.com/watch?v=kp3ik5f3-2c&feature=youtu.be&t=7m51s)

</comment></comment></comment></comment><comment><USER20> It's somewhat frustrating that he continues to get the credit for "hacking the iphone" when he was neither the first nor the only person on the project. The "iPhone Dev Team" was a group of five to ten people who built tools to jailbreak the phone and unlock the radio. If anything, the first person was a guy called Nightwatch who was also associated with various .tif exploits to unlock the PSP. As near as I could tell at the time he worked in some capacity for a South American university. Geohot worked only on the baseband unlock and was forced out of the closed discussions when he released exploits before everyone had time to prepare. This is important because some peoples participation in the project could have potentially affected their employment. Luckily I don't know that anything bad happened, but suffice it to say the kid is not a team player.

<comment><USER21> Take some time to watch his YouTube video explaining the iPhone hack.

He starts the video by giving credit to other people involved in the project.

<comment><USER20> Nice. Can you link me? I was involved in the project :)

<comment><USER22> what was your osx86 handle? I was also involved in the early times but don't recognize your name.

<comment><USER20> It was ixtli. I wrote iPHUC and still own the repo, i think: [https://code.google.com/p/iphuc/source/browse/trunk/AUTHORS](https://code.google.com/p/iphuc/source/browse/trunk/AUTHORS)

<comment><USER22> ah the very early days then, nice. yeah I understand your take, George did get credited for things that were a team effort (including a lot of work by gray). but really a lot of that was the press who just based it off him being the one to publish the unlock demo video, he just probably got tired of correcting people.

as a counterpoint in which he was definitely a team player and not many knew about, he helped us get iOS 3 for S5L8900 devices pwned when we couldn't get the firmware files decrypted due to tricks that Apple put in iBoot (for only that version too - taken out after), which involved using a built in coprocessor and a payload in an assembly language that wasn't ARM and none of us could recognize. so to try to work it out he actually reverse engineered the structure of the assembly language to help figure out what it was doing, which was really cool. I don't think the whole payload got fully "reversed" as I believe one of us (it was either ius or myself) found a data sheet that pointed to it being some type of 16-bit RISC based thing, but was still pretty cool to see how he went about solving the problem. there was nothing directly incentivizing him to help other than a fun challenge.

</comment></comment></comment></comment></comment></comment><comment><USER23> The 21" monitor portrait-style in the car is fantastic.

The testing of a hacked-together system on the public road is not. He _probably_ won't kill anyone, but if he were to I suspect he'd get the book thrown at him in the way that everyday death-by-DUI drivers don't.

Actually I'll go futher with this criticism: we've just seen drones being FAA regulated because users were unable to refrain from doing dangerous or nuisance things with them, such as flying near airports. DIY self-driving car research is similarly likely to damage the concept if it goes wrong.

<comment><USER24> That screen looks like the mother of all distractions.

<comment><USER25> Which theoretically doesn't matter if the car drives itself.

</comment></comment></comment><comment><USER26> For comparison, a similar hacker spirit underpins Tesla Motors propulsion tech: Back in the early 2000's, there was a young engineer driving around Palo Alto in a brilliantly hacked electric Porsche 944, which would do about 130mph on the highway.

His name was JB Straubel, and nowadays he's Tesla's CTO.

Best of luck to Hotz!

</comment><comment><USER27> > The last people with jobs will be AI programmers

Geohotz makes a decent point. The way the industrial revolution reduced manual labour, and made thinkers and tinkerers much more valuable, the advent of AI (true AI, mind you, not the tiny stuff that we currently assume) might actually make us obsolete. It is a peaceful and yet terrifying thought.

<comment><USER28> Can you point to one such job where someone lost his/her job to "AI"?

<comment><USER29> Look at any automated warehouse these days. Pickers, stockers, warehouse managers..... Those are going by the way side.

<comment><USER28> Would you consider those machines AI?

<comment><USER30> Narrow AI, yes. If it simulates a human action and adapts to the environment to a small degree (e.g can recognize a screw bolt and pick it up even if it is in a different location every time), it's a narrow AI.

<comment><USER29> It can do even more than that. Warehouse organization, putting high usage/fast moving objects towards the front of the warehouse, reorganizing based on usage and expiration, restocking, kit packaging etc... Goes way beyond just picking things up with a fork lift and moving them to a different location. All things a person or team of people used to get paid in the 6 digits for are now just run by robots and AI.

</comment></comment></comment></comment></comment></comment><comment><USER31> > Amazed, I ask Hotz what it felt like the first time he got the car to work.

>"Dude," he says, "the first time it worked was this morning."

I can't tell if this is a joke or unbridled hubris. Either way, self driving cars seem like a new hacker space.

<comment><USER32> Also: "Hotz hadn't programmed any of these behaviors into the vehicle. He can't really explain all the reasons it does what it does."

Good luck to him understanding how to fix corner cases: he's built a black box.

<comment><USER33> This will be safe on the road for sure.

<comment><USER34> Are YOU safe on the road? Have you tested all corner cases on yourself?

</comment></comment></comment></comment><comment><USER35> > "Frankly, I think you should just work at Tesla," Musk wrote to Hotz in an > e-mail. "I'm happy to work out a multimillion-dollar bonus with a longer > time horizon that pays out as soon as we discontinue Mobileye."

> "I appreciate the offer," Hotz replied, "but like I've said, I'm not looking > for a job. I'll ping you when I crush Mobileye."

> Musk simply answered, "OK."

I have to agree with Elon here, Hotz is such a good fit there. But Hotz knows best, if he thinks he can take down Mobileye then he did the right decision, sucks that Tesla wouldn't back it. I'm sure other car companies would buy Hotz's software

<comment><USER36> I'd be far more interested in a piece of software for my car put out by Hotz than either Google or Tesla. Because the latter two are almost certainly going to keep it proprietary as heck. (Tesla has notoriously actually called people to ask them to stop tinkering with their car when they detect the interface has been connected to.)

<comment><USER37> > "He says he's come up with discoveries—most of which he refuses to disclose > in detail"

<comment><USER36> We'll see where things get in the future. If I wasn't sure where I was going yet, I might hold a few things close to the vest initially too. There's a short-term value too, where he has to ensure Google or Tesla or Uber doesn't become too dominant first. I really hope self-driving systems are an ecosystem, not a monoculture.

</comment></comment></comment></comment><comment><USER38> He seems like a pretty cool and level headed person. If you watch the video, they're working on phase 3 of car automation which is basically when you're on the highway (or on the smaller roads) and the car takes over for you. It seems like google is working on phase 4, which I feel is basically too far off (no reason for us to need cars that can drive themselves without anyone in it). Also, Tesla, Mercedes, those are all phase 3 (Autosteer).

Also pretty cool he's working in his garage :P.

<comment><USER39> he says phase 3 takes 99% of your driving task. So I guess it would be way more than that.

<comment><USER40> I think this number of "99%" is only valid for the large US suburbs which are way easier to navigate than a typical small town in Germany/Europe. Over here we have so many narrow streets, millions of pedestrians and bicycles, construction zones and so on. More often than not it is difficult for a human to figure out what is going on so it will be much harder for a car to do the same.

<comment><USER39> Yup, I thought about Marseille the other day and I don't see how a self- driving car could drive there.

</comment></comment></comment></comment><comment><USER41> >The smartest people I knew were in high school, and I was so let down by the people in college.

He seems like a good person to get into business with. He's so non-judgmental. Reminds me of myself and all the stupid things I said to VCs in my 20s.

<comment><USER42> Aren't judgmental people the best kind of people to get into business with? At least as long as they can judge people/situations accurately. Because that implies that they will make better decisions for your company w.r.t hiring initial people and choosing strategies

<comment><USER43> Being able to assess people is completely different from being judgmental.

The former is a result of experience and social intelligence; the latter is mix of bad attitude and superiority complex.

</comment></comment></comment><comment><USER44> @imgeohot - Before launch, you should look into a communications protocol between the vehicles. It appears to me that the new LiFi standard might be perfect. You might be able to use the laser range finders themselves to communicate between vehicles.

What to communicate? I'm not sure, to be honest. Road conditions or notifications of the position of obstacles is one obvious thing. Advertising the current version of the software and pushing signed OS upgrade binaries is another. Voice/Video chat with other vehicles in range would be cool, as is media syncing and discovery.

Building in some kind of Bitcoin based payment protocol would be fun too. You could load your cars Bitcoin wallet with some funds and tip cars around you all over the LiFi.

I'm not saying you need to build all that stuff, just put in a good hackable messaging protocol into the system before wide release :-)

Great work man. Good to see people with a good hacker ethos accomplish really cool things.

<comment><USER45> The cars could signal a turn ahead of time, or indicate how hard they're about to brake. With a large enough network, they could even predict traffic patterns and choose a different route.

</comment></comment><comment><USER46> >At Google, he found very smart developers who were often assigned mundane tasks like fixing bugs in a Web browser; at Facebook, brainy coders toiled away trying to figure out how to make users click on ads.

I'm not sure those two are equally horrible though - fixing complex bugs requires using lot of skills and the high you get when you finally nail it is nothing to miss.

Getting people to click on ads though - that's genuinely depressing.

<comment><USER47> Ok cool, you find one of them enjoyable. He (subject of the article) finds them both terrible.

<comment><USER46> Yes, anyone can find anything enjoyable or terrible - but the point I was trying to make was that most hackers enjoy bug fixing by nature and Geohot seems to be exceptional that he despises bug fixing as mundane.

<comment><USER48> Hackers enjoy bug finding or simply building new stuff. Why would they like fixing bugs? Why would any developer enjoy it for that matter? Yes, it's something necessary that all developers should know how to do, but that doesn't make it enjoyable.

<comment><USER46> A nagging bug is ultimately one more thing you don't understand. I don't know about anyone else but as someone who loves to take apart things I don't sleep well when I find there's something out there that I don't understand. Besides bugs are a given if you're building something new and if you don't find them interesting you're not going to fix the most challenging ones. If you ever followed Linux kernel development you'll find many hackers enjoy fixing challenging bugs.

</comment></comment></comment></comment></comment><comment><USER49> Sorry, but how can this be legal? With his homemade solution, he is not only endangering himself but all the other people in the cars around him.

Usually before you are allowed to use something like this on a public road your stuff has to be tested and approved by the state. At least this is how it is in Europe, does this not matter in the states?

<comment><USER50> He's sitting behind the wheel ready to take over, it's not quite the same as making a cup of tea while the car drives itself.

<comment><USER49> Yes, but what if his system suddenly decides to turn hard right for no reason while driving fast and he runs into another car, human, tree, whatever and he has no chance to react quickly enough? This is different to a PS3 crashing because he made some error.

<comment><USER51> The steering is massively torque limited by the car's EPS module(5x lower limit than Tesla). It can't turn hard right, it can lazily list to the right, giving you tons of time to react.

I actually have put a lot of thought into safety :)

<comment><USER52> How do you train it for emergency situations (i.e. a car suddenly turning left in front of you)? I'd imagine it would be hard to get many of those in the training data set.

<comment><USER53> Easy, you drive in a simulator! (ie: backfeed/simulate LIDAR and camera data using a video game (GTA5 for example)). Then try to simulate lots of near- crashes, reactions to traffic lights, signs, etc. Hotz's code just reacts to inputs. Simulate the inputs and you can run any training case you want.

<comment><USER51> Exactly the plan for outlier cases. Though perhaps not GTA...

<comment><USER54> Maybe partner with the creator of the XXX simulator series, you could make some kind of "MMO" where each participants have to run errands the safest way possible while interacting with each other, and upload the training data. Some player could be randomly elected as "maverick" whose goal is to crash and cause accident, the other player would have to handle them.

And if driving in highway is a problem, why not use a test terrain complete with fog generator? With RC car representing pedestrian, other car, animal, ... feed the video first into an AR system and then give it to the neural net.

anyway good hack, I wish you well :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER55> I don't know what's going to happen with this project of his, but this certainly is an interesting article:

>Sitting cross-legged on a dirty, formerly cream-colored couch in his garage, Hotz philosophizes about AI and the advancement of humanity. "Slavery did not end because everyone became moral," he says. "The reason slavery ended is because we had an industrial revolution that made man's muscles obsolete. For the last 150 years, the economy has been based on man's mind. Capitalism, it turns out, works better when people are chasing a carrot rather than being hit with a stick. We're on the brink of another industrial revolution now. The entire Internet at the moment has about 10 brains' worth of computing power, but that won't always be the case.

<comment><USER56> Regarding slavery that's a fatalistic attitude that's not very good for the advancement of human societies.

The other side of the coin of his "technology outgrew slavery, and thus we got rid of it", is that if tomorrow's technology demands some moral monstrosity, to "work better", we can't but bend over and accept it.

Neither human struggles (from the civil war to MLK and Rosa Parks), nor desires and leadership come into any of this, neither is "working better" (towards what? for what purpose? etc) defined.

<comment><USER55> I agree. But still quite an interesting article, one of the more entertaining reads I've had in a while.

</comment></comment></comment><comment><USER57> Surprised that no one else commented on this: It is completely mad and irresponsible to test a self-driving car on a public highway especially since the one who has built it admits that he has no idea what it is doing. Hotz is putting other people's lives in grave danger and everyone is applauding him for that.

<comment><USER58> >the one who has built it admits that he has no idea what it is doing

When did he do that?

<comment><USER57> No time to read the article again to find the quote but the problem is really inherent to the technology. It is very difficult to know what a neural network extracted from the training data, and therefore it is extremely hard to know how it will behave in the future and especially in emergency situations that were not part of the training data.

</comment></comment></comment><comment><USER59> I met Hotz at SpaceX, and can assure you he's not as cocky as this article makes him out to be.

</comment><comment><USER60> During my internship at Google I watched Hotz give a talk on QIRA and his Pwnium exploit.

George Hotz working his magic on the computer is the most fucking legit thing I have seen in my life.

<comment><USER61> Was that talk made available online? Would be curious to see it!

<comment><USER60> Regrettably, not on the Internet. If you get a job at Google you might be able to search for it on the intranet :)

</comment></comment></comment><comment><USER62> Absolutely exciting stuff. Imagine if you have 100, 1000 or 10000 cars each with deep learning software on board. Have them all upload data after each drive to central repository and download updates from other cars. You might start without stuff like 'react to that deer that just jumped on the road' but when you have 10 000 or 100 000 cars that learn and share their knowledge between them you'll quickly learn a lot of corner cases.

</comment><comment><USER63> ""Hold this," he says, dumping a wireless keyboard in my lap before backing out of the garage. "But don't touch any buttons, or we'll die.""

Quality.

</comment><comment><USER64> Self-Driving cars are very exciting but we know it can be done - super cool that Hotz got this working. Now he could really impress the community if he could solve 6 additional concepts [http://gizmodo.com/6-simple-things-googles- self-driving-car-...](http://gizmodo.com/6-simple-things-googles-self-driving- car-still-cant- han-1628040470?trending_test_four_a&utm_expid=66866090-68.Fycr7CNTRMO9chDASrU7Hg.1&utm_referrer=https%3A%2F%2Fwww.google.com%2F)

</comment><comment><USER65>
      He thinks machines will take care of much of the work tied to producing food and other necessities. Humans will then be free to plug into their computers and get lost in virtual reality.

Well, that's an astronomically depressing future.

<comment><USER66> The more technology can seamlessly take care of the foundation of humanity's needs, the better. Leisure is a very new concept and only came about when humans were able to destress from not having to worry about their next meal or getting attacked by predators. Despite all the progress, much of humanity still faces some basic problems due to inequality and access to resources. Technology combined with some other cultural and structural changes can do away with those issues for good.

<comment><USER65> Of course, but once our needs are seamlessly taken care of we're going to just "plug into our computers and get lost in virtual reality"? _That_ is the depressing bit.

<comment><USER66> I think he's made the assumption that virtual reality would be the ultimate form of leisure since as the article states, it would allow us to experience things our world can't create on its own. We'll leave it up to each individual to decide whether that's depressing or the ultimate goal.

</comment></comment></comment></comment><comment><USER67> Looks like the car he is using already comes with adaptive cruise control and lane keeping assist[1]. Can someone with more knowledge on the subject chime in on how/what he is doing that improves upon those?

[1] [http://www.acura.com/Features.aspx?model=MDX&modelYear=2016&...](http://www.acura.com/Features.aspx?model=MDX&modelYear=2016&context=Interior#lane_keeping_assist_system)

</comment><comment><USER68> I always thought default Ubuntu WM is only used by the people who don't know how to change it.

<comment><USER69> Or those of us who don't care about it enough to change it. There are a lot of things that in the right context are not worth bothering about.

</comment></comment><comment><USER70> Congrats geohot. Come up with a good development framework for people to build on and it would be awesome. This is good innovation and engineering.

Like the article said it sure beats writing code to make people click ads or fixing some obscure deadbeat bug in some useless software which nobody uses.

</comment><comment><USER71> _"I don't care about money," he says. "I want power. Not power over people, but power over nature and the destiny of technology. "_

This has echoes of J.R.R. Tolkien:

 _Anyway all this stuff is mainly concerned with Fall, Mortality, and the Machine. By the last I intend all use of external plans or devices (apparatus) instead of development of the inherent inner powers or talents -- or even the use of these talents with the corrupted motive of dominating: bulldozing the real world, or coercing other wills. The Machine is our more obvious modern form though more closely related to Magic than is usually recognised. . . . The Enemy in successive forms is always 'naturally' concerned with sheer Domination, and so the Lord of magic and machines._

</comment><comment><USER72> "George Hotz will be a panelist at Bloomberg Businessweek Design 2016 on April 11, 2016."

</comment><comment><USER73> He is hiring: [http://comma.ai/hiring.html](http://comma.ai/hiring.html)

</comment><comment><USER74> Can anyone recommend a AI/economics book regarding the implications of a population where jobs are no longer necessary?

<comment><USER75> [https://www.youtube.com/watch?v=7Pq-S557XQU](https://www.youtube.com/watch?v=7Pq-S557XQU)

Also, a book with the same name

</comment></comment><comment><USER76> This the same guy that Sony wanted to put in prison for figuring out how to run code on the PS3...

That stunt is also what lead to a coordinated attack against PSN that took the service down for more than a month.

<comment><USER77> Link?

<comment><USER78> [https://www.youtube.com/watch?v=9iUvuaChDEg](https://www.youtube.com/watch?v=9iUvuaChDEg)

[https://en.wikipedia.org/wiki/Sony_Computer_Entertainment_Am...](https://en.wikipedia.org/wiki/Sony_Computer_Entertainment_America,_Inc._v._Hotz)

</comment></comment></comment><comment><USER79> If it passes the written and driving tests at the local DMV, should the car be given a driver's license?

<comment><USER80> no, because that's silly.

</comment></comment><comment><USER81> Is it really the best approach to only train from real world scenarios without any programmed constraints? Most humans are terrible drivers and there's a reason so many people die every year in car accidents. It seems like his approach might be more organic but it'd also be really hard to provide training data around emergency situations as others have mentioned here.

</comment><comment><USER82> If a self-driving car is designed around neural networks, then does that remove the liability dilemma introduced when such a car is involved in an accident? The car panicked and crashed.

If we could move the liability to the car itself, then maybe we could just add the car to its own insurance policy, you know, as if it were a dependent, like a teenage driver.

<comment><USER83> Wow, here's a ton of possibilities! The neural net powered bank computer stole your money and used it to pay the CEO a bonus - move the liability to the computer! The possibilities are endless.

<comment><USER82> I meant to say that the liability moves to the guardian which is how common insurance schemes work when dependents are involved.

Clearly, you can't meaningfully punish computers. Hah, or banks, for that matter.

</comment></comment></comment><comment><USER84> Interesting to see an nvidia shield box on his shelves [0] - I've been playing with one, and the Tegra X1 SoC in there is an absolute beast. Nvidia are pushing this chip for automotive, supported by freely available learning and vision toolkits.

I'd not be surprised to see some interest and support from nvidia on this (if not, then they should REALLY look into it).

[0] [http://www.bloomberg.com/features/2015-george-hotz-self- driv...](http://www.bloomberg.com/features/2015-george-hotz-self-driving- car/img/feat_hotz52__03.jpg)

<comment><USER85> The NVidia Jetson TX1 platform is indeed very interesting, it has the VisionWorks API with lot of CUDA accelerated primitive useful for autonomous driving : SLAM, Optical Flow, ... [https://developer.nvidia.com/embedded/visionworks](https://developer.nvidia.com/embedded/visionworks)

</comment></comment><comment><USER86> I really like his 4 stage definition of self driving car. I don't really care about the fully autonomous like the google car. I've driven the adaptive cruise control VW in europe and that was an amazing experience. The only thing missing was lane control which this guy has done. Personally, where self driving really shines is long trips on the highway. All I really want is smarter cruise control that can stay on one lane and not bump into anything, and ideally send an alarm if it thinks it needs help.

</comment><comment><USER87> This one takes the cake for me: "It scares me what Facebook is doing with AI," Hotz says. "They're using machine-learning techniques to coax people into spending more time on Facebook."

</comment><comment><USER88> His AI strategy that doesn't use IF statements sounds influenced from the Sussman & Radul paper the Art of the Propagator. In this related course you also learn how to program AI decisions based on pattern matching like him giving space to a cyclist and the AI later doing the same [https://groups.csail.mit.edu/mac/users/gjs/6.945/](https://groups.csail.mit.edu/mac/users/gjs/6.945/)

</comment><comment><USER89> Can we get some third party verification here? I live in Potrero and would like to take a ride in his car, or at least help out with his project... hit me up man!!

</comment><comment><USER78> He does a bit of interesting projects, hacking the iPhone, Android and even the PS3 to the point of being sued by Sony [1]. Geohot has potential, so it will be interesting what we see him accomplish, hopefully some company doesn't swoop in and ruin his progress.

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

</comment><comment><USER90> The article mentioned Elon's delaying tactic. I wonder what would happen if Hotz's idea/project was bought out by Tesla.

</comment><comment><USER91> Geo Hotz amazes me!! With that said, can he be prosecuted for using his driverless car on public roads without a license to do so?

<comment><USER36> Possibly, since California I think has specific laws governing self-driving cars, and it sounds like he wants to test it there. If he's in a state that doesn't have laws on self-driving cars, it'd probably be up to existing laws. Is he driving recklessly?

</comment></comment><comment><USER92> > 'I know everything there is to know.'

Except the law when it comes to exceptions for being in control of your vehicle at all times. Somebody take this guys license before he kills someone due to a divide-by-zero. Testing this in an abandoned parking lot would be ok with me (probably still against the law but fine). In traffic is a definite no.

</comment><comment><USER93> Probably best that he's working on his own, doesn't seem like the kind of guy you'd want to work alongside.

<comment><USER94> Or people tinkering with far more interesting things...

</comment></comment><comment><USER95> [http://comma.ai/hiring.html](http://comma.ai/hiring.html)

</comment><comment><USER96> Good to see smart people working on something actually useful, and not another group chat or instagram clone app.

<comment><USER70> Yes it is. Such smart people should be working on these things and should be encouraged. Of course his system is still a lot rough and a lot of work has to go into it but he is just one person doing a lot of thinking. In the interview he has a lot of enthusiasm which is really nice.

</comment></comment><comment><USER97> > In the coming weeks, Hotz intends to start driving for Uber so he can rack > up a lot of training miles for the car.

Really? I did not expected this from him. Why don't he put his sensors\cameras\kit on few other hundred\thousand cars and pay them some money or get some early adopters.

</comment><comment> J0-onas So how does his technology/software react on dangers? The video only shows how he keeps his lane...

<comment><USER98> Probably really bad now, or doesn't react at all and also probably will collide in critical and dangerous positions. But that is also not the future. The future is how does it interact in non-dangerous positions long-term while other cars are self-driving in compliance.

<comment><USER99> Is it that hard to detect a clear danger like a car that suddenly stopped in front of you on the highway?

<comment><USER100> Not hard to detect for the sensors, the questions is how (if) the software reacts.

He uses an artificial neural network to make the driving decisions.

You train them by showing millions of situations (images of the surroundings, information about the cars current state and information about the imminent past in this case) and the wanted reactions/solution/answer (how to drive in this case). Hotz probably has enough "normal" data, because you hold the line all the time when driving and apparently there were enough situations where the car in front slowed down and he slowed down.

From the latter case you could guess that the car would break more rapidly if the car in front stops more rapidly than in the training sessions with a human driver (you would have to test that, as you usually cannot just look at the trained neural network and see that, because they become insanely complex after a certain depth).

But probably the car never "saw" bricks falling of the truck before you or even a kid running from the left side. Those are edge cases, that are unlikely to happen, especially on a motor way. But I'd still like to know whether his software would just apply the nearest trained case and see it as noise, or notice that something is off here and alarm the driver.

Definitely a cool project, don't get me wrong. But I get kind of sad when the work of thousands of scientists who worked on the theory and the work of Tesla, Google and big car manufacturers gets dismissed by "but look at this guy" (in general, not directed at you).

</comment></comment></comment></comment><comment><USER101> _(This is completely Off-Topic but it 's been bothering me for such a long time now and I never got sufficient answers)_

Why am I seeing Ubuntu on Screens of developers, experts, et cetera in Cover Stories such as these, most of the time with the 100% plain Ubuntu Desktop with all the craziness that comes with it? It feels like this is the case 90% of the time. Two more (recent) examples I can remember:

1) Fyodor (Guy behind nmap) running plain Ubuntu on a Notebook while giving a speech at a conference

2) Developers at Honda (Video was an Asimo promotional video) running plain Ubuntu

Since in my personal opinion Ubuntu is not the technically superior choice in these cases (though that can be debated), it can not simply be explained with it being backed by a company, there being support you can buy for the system if you need it.

What motivates technically extremely skilled people to use "Plain Ubuntu" instead of one of the many alternatives?

I really don't understand, please enlighten me!

(I actually think it's worth "spending" some Karma on this if I for once get a satisfying answer)

<comment><USER102> Most of these people have passed the stage of caring about the desktop itself. I would say they are simply interested in a bash shell that sits on a reliable, well maintained, stable distro with good community knowledge.

When you spend all your time at a prompt you don't really care about unity vs cinnamon vs anything else.

Debian is stable and has fantastic package management, and Ubuntu builds on that with a vibrant community and wide support. For these users, Ubuntu 'just works' and lets them get on with what they want to do. It's about as simple as that.

<comment><USER103> curious what myztic would recommend as well? ubuntu may not be 'ideal' but it works and installs a lot easier than arguably any other linux distro. i have no problem using debian/arch/etc but if you are just trying to get up and going ubuntu seems to always be the easiest.

<comment><USER70> I personally use xubuntu. What myztic meant was using "plain ubuntu" instead of alternatives like xubuntu, lubuntu or kubuntu.

Xubuntu is medium light for me and is fast. Previously I had only fluxbox on Kubuntu for the KDE apps which was extremely fast but with bugs in fluxbox I switched.

<comment><USER101> Nope, I really meant Ubuntu compared to other Operating systems / Distributions.

</comment></comment></comment></comment></comment><comment><USER104> It looks like he has various sensors for gathering driving data. But how do you really know when you have gathered enough dimensions of data in this situation? How do you train for edge cases?

I imagine there will still have to be some hard rules in case the AI encounters edge cases.

</comment><comment><USER105> Response from Elonmusk [https://twitter.com/elonmusk/status/677403793651175424](https://twitter.com/elonmusk/status/677403793651175424)

</comment><comment><USER106> But my intuition say. Google has fairly large amount of data. Their cars drove much distance than his leading them more space to test. More data to test more intelligent systems will be.

</comment><comment><USER33> So its more a fancy autopilot than a self driving car.

<comment><USER45> You're aware that "auto pilot" literally means "self driver", right?

<comment><USER107> Yet few people would call an airplane with auto-pilot a "self-flying plane", even with advanced autopilot that can take off and land itself.

Autopilot is understood to mean a limited computer assist that can help with routine tasks, but not expected to allow a plane to fly without a pilot.

<comment><USER45> What more would a plane need to be "self-flying" beyond taking off, navigating, and landing?

<comment><USER107> The ability to handle unusual emergency or unexpected conditions - the same thing that's needed to call a car "self-driving".

</comment></comment></comment></comment></comment><comment><USER28> Would be interesting to see demo that is not just car self-driving in a straight(ish) line.

</comment><comment><USER108> What a cool article!

</comment><comment><USER109> The fuck. Hotz is awesome... The only coder with a skillset so diverse yet immersive I know is Fabrice Bellard. I'd love to see them on a team together... probably will invent true AI O.o

</comment><comment><USER110> I really liked Hotz until he went to work for the dark side (google's android security) and decided to make smartphones harder to root instead of easier.

<comment><USER111> I dunno, it's still pretty easy. I think if google really wanted to they could make it quite a bit harder. And fixing exploits that give apps root access would prevent malicious apps from abusing it, no?

</comment></comment><comment><USER112> I love this guy's personality.

</comment><comment><USER113> Great!

</comment><comment><USER114> > 99%

</comment><comment><USER115> He must have rich patents or a sponsor. The Lidar isn't cheap (50k).

<comment><USER116> $8k - [http://velodynelidar.com/vlp-16.html](http://velodynelidar.com/vlp-16.html)

<comment><USER115> It looked like the VLP-32. The VLP-16 is pretty new, I am surprised it's already available, last time I checked it wasn't. Google cars use the VLP-64 which costs 70+k.

</comment></comment></comment><comment><USER117> The guys hacked the PS3. That guy can build a self driving car.</comment>


Ask HN: Do you program naked? - <AUTHOR> Ok, this might be an unusual title :)
But the question is exactly that. It seems the summers get hotter and hotter. Where I am, it gets about 34°C (93°F) inside. And I don't have air condition.
Is it best to expose as much skin as possible while coding, so it is easier for the body to dissipate the heat? <comment><USER2> I don't have air conditioning either, but I have a huge fan on the ground that blows air under the desk. Plus I have a smaller fan on my desk, aimed at my upper body.

It keeps me cool enough to work in relative comfort, and I don't need to take all clothes off (but I do wear a polo shirt, khaki shorts and flip-flops which I kick off under my desk).

[https://www.coolblue.nl/product/855263/fuave- vv3010-chrome.h...](https://www.coolblue.nl/product/855263/fuave- vv3010-chrome.html)

<comment><AUTHOR> I often hear that you get a cold from using a fan.

I wonder if that also applies for fans placed on the floor?

<comment><USER2> I think that may happen if you aim it full in your face. I don't do that, it's uncomfortable to my eyes.

</comment></comment></comment><comment><USER3> Not usually, but I sleep naked. And sometimes, in the middle of the night, to stop an idea continually revolving in my mind and keeping me awake, I will get up and put that bit of programming down on screen.

And yes, where I live, it's a chilly night if it drops to 16C (61F). Most days it's over 30C (86F).</comment>


10% of Covid patients in intensive care unit - <AUTHOR> https://mailchi.mp/esicm/the-future-of-haemodynamic-monitoring-first-webinar-of-the-year-1009715 <comment><USER3> 10% of all positive cases or 10% of the people who already are seeking advanced medical care?

Their wording is "10% of all positive patients."

</comment><comment><USER4> The problem I am having is that there is wildly contradictory information coming out. Some numbers that make it sound only a little bit more dangerous than flu, and then something like this that says 10% of positive cases need respirators.

I think until we can be very sure that is not true, we should take this much more seriously. Seems like they are not interested in testing people in the US if they can find any excuse. I hope the people making that decision will review this information.

<comment><USER5> I don't trust the numbers from Italy and China - Italy because they seem to have lost the control completely and there seems to be no proper testing of significant population or tracking of the infected patients, and China because...China.

So far, it seems Korea has the best data over the situation, and is likely the most applicable for countries with proper public health and medical systems.

Per Korea's Ministry of Health and Welfare - [http://ncov.mohw.go.kr/upload/viewer/skin/doc.html?fn=158337...](http://ncov.mohw.go.kr/upload/viewer/skin/doc.html?fn=1583372501478_20200305104145.pdf&rs=/upload/viewer/result/202003/)

As of today, 150K people tested, 5766 infected, 35 death, 0.6% fatality rate. Their age distribution looks interesting:

0-30: ~2k infected, and no death.

30-50: ~1.5K infected, 2 death (0.1%)

50-59: 1127 infected, 5 death (0.4%)

60-69: 699 infected, 8 death (1.1%)

70-79: 288 infected, 13 death (4.5%)

80+: 127 infected, 7 death (5.6%)

Their number of infected graph is showing some sign of deceleration - <USER2> growth rate seems to be leveling off or slowing down slightly.

<comment> eric-hu I think Italy is particularly worth paying attention to as a bad case approximation of what can happen in the US. About a week ago, Korea had tested 90k people while the US had 400 tests available and fewer tested.

<comment><USER6> Besides lack of testing, the US could turn out even worse than Italy given that many lack insurance and/or cannot afford to call in sick.

<comment><USER7> I'm growing tired of this meme.

Everybody in the US has insurance, that was literally a major point of contention to Obamacare - the left didn't like that the solution still used private insurers and the right didn't like that they were forced to buy something. If you have a low income, you get subsidized premiums.

For sick pay, it's just a lack of budgeting and planning. If you have a job that pays you $12/hr with no paid leave time or a job that pays you $10/hr with an accumulation of leave hours, it's still the same in the end if you work X days and are sick Y days and get a monthly income of $ZZZ, just in one case your employer is holding back your leave pay and in the other case you're paid full value up front and save for your leave period yourself.

<comment><USER8> > Everybody in the US has insurance

Isn't that factually wrong ?[https://www.nbcnews.com/politics/politics- news/number-americ...](https://www.nbcnews.com/politics/politics-news/number- americans-without-health-insurance-rises-1st-time-decade-n1052016)

> it's just a lack of budgeting and planning.

Which people living paycheck to paycheck can't do. [https://www.washingtonexaminer.com/news/nearly-half- american...](https://www.washingtonexaminer.com/news/nearly-half-americans- live-paycheck-to-paycheck-bank-survey)

<comment><USER9> It is factually wrong. The correct way to phrase it would be that anyone can commit moral hazard and sign up for a public plan in response to a sudden need for medical treatment. So insurance can be available in a way that defeats the purpose of insurance systems.

However:

1) This is not free

2) This is not likely to save you from enormous medical costs

3) This is about on par with filing taxes. Probably easy to do if you understand the basics of whats going on, but few people do.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Worth pointing out that that the average age in Italy is 46 vs 37 in China. Given that old age is well known to increase mortality and morbidity, we should expect worse outcomes in Italy.

<comment><USER11> Life expectancy between Italy and China differs by about 7 years in Italy's favor, so I guess it's not that big of a difference.

<comment><USER12> True, but the age distribution skews older in Italy.

Italy: [https://en.wikipedia.org/wiki/File:Italypop.svg](https://en.wikipedia.org/wiki/File:Italypop.svg) China: [https://en.wikipedia.org/wiki/File:Population_pyramid_of_Chi...](https://en.wikipedia.org/wiki/File:Population_pyramid_of_China_2016.png)

</comment></comment></comment><comment><USER13> I really wish that China had not filtered/hidden the data related to Covid-19 for its population. That would have really helped the rest of the World prepare better.

Right now the rest of the world is just grappling with if the mortality is 3.4% or is it higher or lower. How many, across gender and age groups and so on, end up in ICU vs have milder symptoms, and so on..

<comment><USER14> You can possibly try to blame China for hiding things up until mid January. But absolutely after that you can't. At that point the entire world had more than good enough data to see how serious this was and that it was going to become a pandemic. Yet even still now the response in the western world is totally underwhelming for the seriousness of the situation. I'm in Seattle which is heading right towards becoming America's Wuhan and they still aren't even cancelling all events or closing all schools and colleges.

<comment><USER15> There is a big "It won't happen to me" mentality I can see going around. In many people's minds, coronavirus is something people in Asia get, not something westerners get.

Students at the university in my town are bragging about going skiing in northern Italy, saying "It's overblown" and "It won't happen to me".

Even acquaintances are saying "It's just the flu, what's the big deal?".

</comment></comment></comment><comment><USER16> It's funny how the same heuristics I have developed around the growth of artificial intelligence are useful here. Spotting long term indicators trending in a bad direction. Having the gumption to examine a repellent conclusion, even though my mind wants to shy away from it. Ignoring ridicule and trusting numbers over social cues.

Not that it's done me any good.

</comment><comment><USER16> Really really hope people are paying attention to this. Suspect we're just sleepwalking into a disaster.

<comment><USER17> Literally tens of thousands of people (if not hundreds of thousands) are working on this outbreak. My friend works for the CDC in Atlanta, and the taskforce in that city alone is 1,500 people. They work 75 hrs/wk exclusively on this outbreak.

The idea that the many thousands of people with jobs and doctorates in public health, epidemiology, and medicine would be sleepwalking while you (and I assume some other people) are more aware of the impending disaster is ludicrous.

<comment><USER18> Then why are we 8 weeks into this and the US has tested approximately no one, while other countries are testing thousands per day? Wtf are these 1500 people doing for 75 hours per week?

<comment><USER17> Each test kit has a limited number of uses[. The first batch of thousands of test kits had a flaw and couldn't be used[1]. With a limited number of kits, they had to limit testing to high-risk people.

As I've written on HN before, a great deal of the problem is that the current administration appoints political donors and anti-government activists to important roles in agencies handling science and medicine. These are mid-level people whose names almost never end up in news.

So you have incompetent decision makers appointed throughout the organization, funding cuts, discouragement of civil service at all (through things like killing debt forgiveness and stagnating wages), and an administration that publicly denies the problem is even serious because it's afraid of the stock market tanking.

Add to that that the State Dept has been gutted and has many hundreds of open positions that the administration refuses to fill, and you have more disasters like allowing likely-infected Americans to return to the US without testing or quarantine.

1\. [https://www.nytimes.com/2020/03/02/health/coronavirus- testin...](https://www.nytimes.com/2020/03/02/health/coronavirus-testing- cdc.html)

<comment><USER18> Oh, i'm 100% on board with the fact that it's not the experts' fault. But it's also not at all fair to say "Thousands of people are working on this, so we can't be sleepwalking!" and that's what I was responding to. Thousands of people _might_ be working on this, but if their work is being ignored or undermined, they might as well not be.</comment></comment></comment></comment></comment>


Dealing with Data Deluge at LHC - <AUTHOR> https://newscenter.lbl.gov/2016/02/22/updated-workflows-for-new-lhc/ <comment><USER2> "generate up to 10 gigabytes of data"

That's got to be misprint .

<comment><USER3> [https://en.wikipedia.org/wiki/Worldwide_LHC_Computing_Grid](https://en.wikipedia.org/wiki/Worldwide_LHC_Computing_Grid)

<comment><USER2> thanks. "The data stream from the detectors provides approximately 300 GByte/s of data, which after filtering for "interesting events", results in a data stream of about 300 MByte/s. The CERN computer center, considered "Tier 0" of the LHC Computing Grid, has a dedicated 10 Gbit/s connection to the counting room."

</comment></comment></comment><comment><USER3> I imagine that the warehouse-scale computing people at Google (for example) wince as they read this article.

And more when they see this:

[https://wlcg-rebus.cern.ch/apps/capacities/federations/](https://wlcg- rebus.cern.ch/apps/capacities/federations/)

(Note that tier-0 is the only real CERN datacenter. Apparently it is split into two pieces linked by 100gbps fiber. Maybe that's explosion protection? Anyway, the external partners are some kinda SETI@home arrangement.)

Google, can you just _give_ CERN an old datacenter and 2 FTEs worth of volunteers?

<comment><USER4> I've worked both at Google and at CERN Openlab, and if your impression is CERN's grid effort < an old datacenter and 2 FTEs, you're greatly underestimating it.

<comment><USER3> I've only got experience with the former, not the latter, so yes I was estimating. I accept your appraisal of my estimate.

I guess I just wasn't impressed with the tier-0 core count--no, it's that I expected LHC to be the earth's darling project and get whatever resources it may need. This article describes a struggle that sounds resource-related... And, gah, academic software < industry software. :(

<comment><USER4> > I expected LHC to be the earth's darling project and get whatever resources > it may need

Yeah, the DC at CERN is constrained by the power it can draw from Meyrin (or at least it was, 9 years ago). And the rest of the grid is donated by universities (with some trade mechanism to donate the CPU/disk time back to them in the future). So I expect any of the big Cloud providers can beat it. It'd be lovely if one of them donated resources, in exchange for bragging rights.

<comment><USER3> Meyrin? Oh, hey, I know that lake. I've been to Lausanne... It didn't even occur to me to try to visit the LHC on the way... d'oh!</comment></comment></comment></comment></comment>


Today I wrote some code - <AUTHOR> http://www.jacquesmattheij.com/today+I+wrote+some+code

<comment><USER2> It's funny. Just as the author reached this realisation I've reached the realisation that tests are killing my productivity and are exactly the wrong strategy for my nascent product.

I've been testing obsessively for the past 18 months but just realised that I've got a stack of perfectly tested code that's perfectly wrong for what I need it for. I'm going to have to tear it apart and rebuild.

I've been thinking about what the right balance is between the two. As code matures the value of tests becomes higher and higher but early on when you need to shape and reshape they really kill momentum.

<comment><AUTHOR> Funny you should say that :)

This is one of the reasons why I don't make testing into a religion but pick a time and a place to add the tests. The 'write your tests first' school is right in that it can create another boost but it comes with the problem that it puts a damper on any exploratory programming. I typically take three tries to get it 'right', and only after the third try with a reasonably stable interface is where I will add tests.

Maybe I'm a lousy designer in that I can't nail down an interface on the first try but on non-trivial code this is unfortunately my experience so far.

First try: very quick, rough and dirty. Second try: a bit slower, mostly right but still needs major rework. Third try: minor tweaks in the longer term but mostly finalized.

The elapsed time is usually something under a day for the first try, a few days to a week for the second and after the third try it goes into 'maintenance' pretty quickly.

<comment><USER3> > why I don't make testing into a religion but pick a time and a place to add > the tests

Quite. Testing is great. "Test Driven Development" where expensive Agile Consultants who haven't written code in ten years tell teams they always have to write tests first for everything is bullshit: <http://xrl.us/bmebj3>

<comment><USER4> Many successful devs also preach TDD. TDD is great when your client has a high quality spec, or you are being paid for meeting team spec. TDD is less great when your project goal is "build something neat" with a very loose spec and wide tolerances.

<comment><USER5> Well it really depends. You can make a religious Process out of TDD where you start with something like Cucumber and work your way down through the design. You can TDD your glue code. You can TDD trivial stuff, like when you put a link in your web app to your new feature, you could write a view test that verifies that the link appears. You can, if you _really_ want to, go through an obnoxious iterative process of writing the same function in a progressively less and less broken state. There might even be value to this approach. I wouldn't know.

Or you could do something like this: whenever you have a function that seems to do an actual algorithm, or process some data, or provide a predictable result given an input, you write up a few asserts and _programmatically_ see whether it seems to work immediately after writing it instead of writing it and wasting your time futzing about with it by hand, or tracking down a bug in it after noticing strange results coming out of the whole program.

Or you could do something like _this_ : whenever you get a bug report, create a test case that reproduces the bug first.

Agile Consultants are like anyone else who tries to sell you enlightenment: they wouldn't eat unless there was actually a kernel to truth behind what they were saying. Writing your tests first is a _fantastic_ idea sometimes.

</comment></comment></comment></comment></comment><comment><USER6> I forgot where I first read it, but I loved the

A boy turns up to school half an hour late, out of breath as he was running into the schoolyard pushing his bike, "Sorry miss, it took me 45 minutes to run here" he explained to the schoolteacher, "Why are you pushing your bike, why didnt you cycle?" the schoolteacher asks, "I was already late when I left the house, I didnt have time to get on my bike"

As mentioned elsewhere, turning testing and code coverage into a dogmatic religion is obviously a bad idea, but when I talk to people about testing it seems that we error hugely on the side of not testing, when you dont think something is testable, it is usually because you didnt design it to be testable from the outset. There is definitely no easier programming guide I have found than a little light that goes green when I have done the right thing, If I have tested code properly it is an order of magnitude less likely to take on technical debt, huge sweeping refactorings are no longer big scary tasks

<comment><USER7> Completely agree. People tend to dismiss testing rather than balance the depth of testing that they do. 100% code coverage doesn't mean you've tested every conceivable combination of parameters to a method.

One of the biggest benefits of testing in my mind is improving the design of code. If you have code that is very difficult to test, there is likely something wrong in your design.

Any way you cut it, you need to become knowledgeable about testing to be able to apply it effectively.

<comment><USER8> At work, for one small subsection of the project I'm on, I wrote the regression test. I'm testing a "program" that consists of 56 processes (what I'm testing) across three machines (and requires around four other processes across two machines to stub out some services we require but aren't technically part of what I'm testing). It can take up to half an hour to set up (one of the reasons it's not fully automated is that the third party network stack we rely upon will shut down if there are too many errors) and it takes around four hours to run (except for two test cases that require manual intervention to run properly).

And that's just for the back-end processing (nearly 300k lines of C/C++ code). Unit testing? Okay, for large values of "unit", and most of the "units" being tested require almost as much set up as the entire "program".

Is something wrong with the design? Given the constraints and how the project evolved, I can't see it being any simpler. And I'm somewhat overwhelmed with the thought of testing the frontend (which requires Android phones).

<comment><USER9> My metric here is always finding the most valuable way to use my time long term. In the short term, test automation always seems wasteful. But in the long term, it's great. Solid product, little debugging, and minimal manual QA.

You're in a situation with a lot of legacy code. Testing shapes design, but it sounds like you're trying to retrofit testability onto an existing mess. People cut corners for years, and now it's your problem. That sucks.

In your shoes I'd either start improving it or find a new job. I think life's too short to spend my time doing something a computer could and should be doing.

<comment><USER8> Heh ... it's actually a new project. Yes, the majority of the code is third party software. And while we do have a bit of "legacy code" in the project (in the form of the third party proprietary network stack that literally _is_ in pure maintenance mode) we're mostly working in a legacy system (telephony network) that requires very high degrees of redundancy (hence the number of processes on the number of machines).

And for the most part, I was able to get the regression test for the backend process(es) to run unattended once started (thankfully---I (along with two others) did it _once_ manually and it was horrible). I have no idea of how to do that for the frontend Android cell phone client. Sure, we can run tests on an emulator, but there are issues with the Android emulator (it exhibits different buggy behavior than the the physical hardware) so that only gets you so far. It's an interesting (if somewhat overwhelming) problem.

<comment><USER7> Would you consider this testing 'unit testing', though? Sounds more like higher-level integration tests with a lot of dependencies. Honest question.

<comment><USER8> I'm not sure. Yes, we _can_ (to some degree) independently test parts, but like I said, each part requires a significant portion of the environment to be up (or simulated). And "unit" testing (that is, testing an individual routine or module) doesn't really make sense given how the code is written (receive a message via SS7---the network stack I mentioned) and convert it to an IP based message). To test the portion that talks to the telephony network requires a telephony network (very hard to mock out---lord knows I would love to) and another major unit we wrote (which is another part I test) to even be testable.

And to test that other part? Well, it requires I mock out the previous unit (or run it), plus three three other parts (one including a cell phone---which is really a simple script at this point). And again, it doesn't really make sense to test individual routines because this takes the translated IP packets from the SS7 module, and makes several queries to other IP based services. So a lot of what's going on is just simple translations (in a multithreaded/multiprocessor environment---more fun!).

<comment><USER10> I went to an Agile class where the lecturer compared unit tests to double- entry bookkeeping. An accountant doesn't say "oh, I don't need to add up both columns here, I know it's just trivial addition".

Once I got in the habit of writing tests of even the most simple transformations, the code complexity and my test complexity grew at the same rate, so it's much harder to end up with a giant untestable mass.

<comment><USER8> I once spent over a month tracking down a bug (in a different project than the one I mentioned above) that I have a hard time seeing how unit testing would have caught. The program: a simple process (no threads, no multiprocessing) that would, depending on which system it ran, would crash with a seg fault. The resulting core files were useless as each crash was in a different location.

It turned out I was calling a non-re-entrant function (indirectly) in a signal handler (so _technically_ it was multithreaded) and the crash really depended on one function being interrupted at just the right location by the right signal. That's why it took a month of staring at the code before I found the issue. Individually, every function worked exactly as designed. Together, they all worked _except_ in one odd-ball edge case that varied from system to system (on my development system, the program could run for days before a crash; on the production system it would crash after a few hours). The fix was straightforward once the bug was found, but finding it was a pain.

So please, I would love to know how unit tests would have helped find _that_ bug. Yes, it is possible to write code to hopefully trigger that situation (run the process---run another process that continuously sends signals the program handles) but how long do I run the test for? How do I know it passed?

<comment><USER10> no, unit testing doesn't tell you if your constructs aren't safely composable. So: it will pretty much never find a threading bug, a concurrency bug, a reentrancy bug, etc.

I only know three ways to detect this sort of bug, and they all suck: 1) get smart people to stare at all of your code 2) brute force as many combinations as possible 3) move the problem into the type system of your language so you can do static analysis of the code

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Let me just state a fact: every programmer tests code. Whether you're checking a command line output, experimenting in the REPL or reloading a browser, you're testing your code.

What rubs me the wrong way is that, instead of a simple "you know all that ad hoc testing that you do? There's a way to automate that that'll probably save you some time and let you test the same things, in an automated fashion, with the press of a key...", _non-testers_ usually get a condescending "oooh my sweet summer child, what to you know of code?"

<comment><USER12> I'm afraid the statement that "every programmer tests code" is _not a fact_. Not by a long shot.

In fact the vast majority of bugs are the result of not testing changes _at all_ , in any way shape or form. Committing code changes without even running it (or only running it to the most simple and predictable of scenarios) is not an exception.

Many programmers, especially those that don't like writing test, simply assume it works "because it was simple". It's this utterly unrealistic and unprofessional hubris that gets condescending reactions.

Given the damage it does to both the product at hand and our profession in general, I would say condescension is a rather mild response to this behaviour.

<comment><USER13> At one of my past jobs, the threshold for "should I commit this?" was "does it compile?". The rationale was that if there were problems with it, they'd be caught during "acceptance testing" (which was probably 6 months down the road). I didn't stick around for very long...

<comment><USER14> I've seen PHP committed and deployed to production with syntax errors, which means nobody ever tried the offending pages _even once_. I also left that shop pretty quickly, because I don't think options keep vesting if I garrote somebody with a network cable.

</comment></comment></comment></comment><comment><USER15> Hey, I have a question for all you TDD fans. In my (still short) programming career, I have only stumbled across stuations where automatic testing looks impossible to do in a sensible way - deploying a patchwork of code against huge platforms like SharePoint or working with APIs like COM that don't lend themselves very well to testing, and where the code is "interface" heavy rather than "logic" heavy. Recently I've been looking into iOS development.

I also get the impression that most IT work today mainly involves working with huge libraries and APIs, and that automatic testing therefore is hard to implement in a sensible manner. I very much get the idea of automatic tests (and I've wished for them quite a few times, where they've been very hard to implement because the API seems to get in the way). But are there really so many applications for them unless you are building a huge, monolithic application where everything is defined in advance? Seems to me, like a lot of people have pointed out, that it will slow you down when prototyping.

This is not a criticism of TDD/automatic testing, but I just don't see how to create good tests when most of your code is just glue between different libraries and most of your time is spent reading documentation and chasing bugs in your library. Would be really cool if someone could point me to an overview of these things. Am I just in the wrong organization?

<comment><USER16> You're asking for integration tests, and yes those are hard to do, esp when the integration is against a large deployment of third-party or existing API code like you describe.

What you want to do in that case is isolate the "glue code" if you can and test its assumptions in isolation. Wrap the API dependencies in an interface and inject mock objects to play the role of that API. This is really what mocks do well.

If your code is also bootstrapped by some special plug-in hook that is hard to emulate in a test environment, like a MS SharePoint or Dynamics thing, then you should isolate the code in question from the Class that implements that hook, so that a test can boot up that code just like the plugin would. Interfaces are probably a good option on this end as well.

So, you often can't test your production code in an integration environment exhaustively, but that's OK in most cases because A) a truly exhaustive integration test is probably a combinatorial problem and not realistic anyway and 2) you'll just be proving that your third-party API works as guaranteed, which is probably not your highest risk and not worth the trouble.

Your real concern is to test the assumptions of new code and also create the TDD discipline around that code which tends to make for better code.

</comment></comment><comment><USER17> I think going back into some production code you wrote years ago and doesnt have tests and putting them in is a really nice way to self-reflect. It would provide at least two benefits, 1) improving the code 2) showing you just how far you've come since writing the code, which in turn shows you how far you can keep going.

</comment><comment><USER18> > For a lark I'm going to take an old project that has been running for years > without a hitch and I'm going to retro-actively add tests to the code.

Be prepared to possibly rewrite most, if not all, of your code. I have found, at least in my old code -- which admittedly was written well before I became familiar with the concept and discipline of testing -- that my code is just not testable. At all.

It is very tightly coupled, and against which is almost impossible to write any sort of meaningful tests.

But maybe you were a better designer than I was, and if so, you may be able to fairly easily add tests to your code.

But if not, you're in for a challenge. :)

<comment><USER19> If your code has been "running without a hitch" and "an old project" (which I assume means you are no longer actively updating it) why are you adding tests?

Out of curiosity, what's the ROI that you see in adding tests to that project?

<comment><USER20> For some reason clients tend to get upset when things that were working suddenly break (they don't even care if it as legacy code base!).

Joking aside, in order to effectively prevent that, a test suite must be in place to prevent regressions when you change/add code. If there isn't one, you need to decide between cranky clients or the nastyness of adding test to legacy code.

<comment><USER21> > For some reason clients tend to get upset when things that were working > suddenly break (they don't even care if it as legacy code base!).

Another sad truth to consider is that just the process of refactoring your code to add tests can just as easily break functionality. I've learned this the hard way.

</comment></comment></comment></comment><comment><USER22> The cool kids write invariants that they prove correct via equational reasoning.

<comment><USER23> There's also the Woz method of thinking about the problem so intently that you can simulate the whole system in your head without even looking at any code. Being unable to write your program bug-free would be like not being able to recognize your mother.

</comment></comment><comment><USER24> _For a lark I'm going to take an old project that has been running for years without a hitch and I'm going to retro-actively add tests to the code. I'm really curious how many bugs and unexpected behaviors will turn up._

Last week I got an enhancement request from a customer that basically said, "Add B capability and make it work exactly like A capability."

"Cool," I thought, "This should be easy."

So I examined all the "A" stuff, which had been in production since 2008. Then I cut, pasted, modified, and added a whole bunch of stuff. (I know, I know, every once in a while, a programmer's just gotta take the lazy way out.)

When I started unit testing my B stuff, I broke everything on almost every try. This was before I even assembled a test plan, it was just a hacker beating up his own work.

How could this be? So I went back and beat up the A stuff and broke it in all the same places. Stuff thousands of people have used thousands of times. Sigh.

<comment><USER25> How is the A stuff wrong when thousands of people have used it successfully(presumably for its intended purpose) thousands of times? I understand where you're coming from. But the longer I do this, the less dogmatic about testing I get. If the code works for its intended purpose then it's probably all right. Now, adding features and having confidence in refactoring is another story with untested code.

<comment><USER26> Because the people using it for the intended purpose are not fuzzing it for potential security flaws.

<comment><USER25> Do you write lots of security fuzz unit tests? Cause I don't. I write tests that hit the edge cases I can think of, but invariably, I can't think of everything. I really don't think the security argument has much to do with unit testing.

</comment></comment></comment></comment><comment><USER27> In one project, I refactor my code late, late at night. I do it in almost a dream state; it's a process of nearly pure symbolic manipulation, involving none of the complex mental model that we're used to needing to maintain while programming. I've been doing this a few times a month for a year, and have introduced _one_ known bug. I have a very modest test suite.

I'm no programming god, I'm just writing in haskell. Referential transparency, purity, and strong type checking for the win.

(That one bug? Made during this hlint run <[http://source.git- annex.branchable.com/?p=source.git;a=commi...](http://source.git- annex.branchable.com/?p=source.git;a=commitdiff;h=7e17151e69fcd86fd5cb90dd61ff55d2d017fee7>); and fixed here <[http://source.git- annex.branchable.com/?p=source.git;a=commi...](http://source.git- annex.branchable.com/?p=source.git;a=commitdiff;h=7e17151e69fcd86fd5cb90dd61ff55d2d017fee7>))

</comment><comment><USER28> I've taken a long, meandering road to appreciating TDD/BDD. When I started programming, I looked up to _why and his hacking approach to coding. Sadly, I could not express his brilliance and my code was not just untested and sloppy, but fragile and inundated with smells. As the scale of the projects I develop increases, I've learned to use testing to decrease the potential breakage and to better understand the libraries and features I'm working on. Of course there is an exploratory spike here and there, with tests coming in later to glue it all together, but those are now exceptions to my normal practice. When debugging legacy applications, simply creating test coverage for problem areas goes a long in solidifying the patches. Testing is not fail proof elixir, but it certainly improves my workflow and my product, and those results are hard to argue with.

</comment><comment><USER29> Related: I am a big fan of testing in my personal projects, but have never written a test for a client because they don't want to pay the additional hours. I have quoted about 25% - 30% of the time on writing tests , if they want them. Am I wrong? Ditto on documentation, no biters.

<comment><USER18> If you read _Pragmatic Unit Testing_ [1], it talks about how writing tests actually takes less time than building a project without tests, in the long run.

First of all, it's possible to actually ship a product that was built with tests quicker than one that was not built with tests. This may not always be the case, but adding tests doesn't necessarily mean that it will add time, overall. It may feel like it's quicker to build an app without tests, but often the testing and bug fixing that happens at the end often exceeds the time it would have taken to build tests and eliminate most of the testing/bug fixing at the end.

Second, bypassing testing rarely saves time in the long run, especially for apps that continually require maintenance to existing code. Regression almost always occurs, and sometimes this isn't caught until production.

Unfortunately, it's a hard sell to clients, and depending on how well you are at covering this up, it often goes unrealized.

[1] [http://pragprog.com/book/utj/pragmatic-unit-testing-in- java-...](http://pragprog.com/book/utj/pragmatic-unit-testing-in-java-with- junit)

<comment><USER29> While I agree with you, it's a very tough sale if you're consulting for a company without a strong programming department. I find that companies plan for best-case scenario and deal with the consequences thereafter. Bugs are usually considered a programming mistake, even while acknowledging that poor planning plays a part.

</comment></comment></comment><comment><USER30> Someone needs to spell out the difference between "tests" vs. "test _ing_ ", might as well be me. Tests are something you, a developer, or a test engineer writes. Really important. Test _ing_ is something that the dev, a test engineer, or someone off the street can do. That is the _most_ important part towards making working software. Unit tests are important, but are in a vacuum. The only way you can look at your code in context is to have someone use it.

Lots of games (including ones I worked on) ship with hundreds of thousands or millions of lines of code and practically no unit tests (if any). According to this article, they shouldn't be working at all, let alone make billions of dollars. Do I think it's a best practice? No. But on those projects we had an army of QA to test builds and producers obsessed with their features to always be in there making sure that things worked. The most effective testing was "everyone play the game day" (or weekend). Only then can you find edge cases that unit tests can't. Dogfooding is another important take on this concept.

tl;dr: unit tests are important in their own right, but even 100% code coverage can't tell you if the thing as a whole works as the user expects. That's "testing" as opposed to "tests".

<comment><USER31> Someone in the test industry here. I had a stint in the games industry, as well.

An army of QA is... problematic. Inevitably it turns into a death march, which is a huge waste. Worse, developers feel much less inclined to own the quality of their code (consciously or unconsciously) because "QA will catch it." I suspect that even if you _wanted_ to be more rigorous, the incentives are against you.

Fixing bugs filed by QA is also expensive, relative to fixing the code before it's checked in. By the time a bug makes it to QA, it's a ton of patches later, the developer is working on another feature, and it's not at all obvious which patch introduced the bug. The most expedient strategy of "revert the culprit" is difficult if not impossible, and checking in new code for a fix introduces further risk.

There's certainly something to be said for expert/exploratory testing. Hell, it puts food on my table. :) But as a tester, I'm far less inclined to work on a product where developers aren't concerned about code correctness or quality even at a micro level. It says to me that they don't value my time.

Then again, I suppose in the games industry it matters less what QA thinks, given that the people actually doing the testing are often temporary/contract employees.

</comment></comment><comment><USER32> Completely agree. Even though I am quite new to coding, I was shocked to see how much more time I spend on debugging a piece of code than actually writing it. The ratio is closer to 3:1 and sometimes even higher. Writing tests has brought that down to roughly 1:1 (varies from project to project).

I still don't do as extensive testing as I want to (primarily because I am lazy) but I have seen the shift in the way I think about solving a problem. Writing tests forces you to assign structure to your code (in my case I put it down on paper). It helps you think in terms of "pipes" as in what is going in and what comes out.

But, I think a lot also depends on the nature of the project. Parsers and frameworks may need thorough tests while simple apps may do without many. And for some people, it may be too much of an overhead at times.

</comment><comment><USER33> As a long time skeptic, but a new convert to TDD, it also occurred to me that I was also reaping the benefits of immediate feedback after each build analogous to Bret Victor's theme in his talk and demo at CUSEC. It definitely increased my iteration speed.

</comment><comment><USER34> Anecdote: I rewrote an operating system (back when people did things like that) to repackage it as a library of modules (kernel, drivers, services) that self-configured on each boot.

It took 19(!) tries to get past the 1st line of code in the entry point module.

There is no such thing as a trivial change (tho that was sure not trivial). My mantra is: "If you haven't tried it, it doesn't work" We all know that, deep down. We tell stories over dinner of the time something worked on the first try. Why? Because that hardly ever happens.

</comment><comment><USER35> As a mostly self taught programmer who has been ignoring tests for too long, can anyone provide links to any books/primers/resources that can introduce me to writing tests and doing so effectively?

<comment><USER36> I'd suggest making a pot of coffee and diving in to the wiki:

<http://c2.com/cgi/wiki?CategoryTesting>

</comment></comment><comment><USER37> Congrats on discovering testing! Getting "test-infected" yielded easily the biggest productivity gain in my career.

However, you've got another big win waiting for you if you'll try something subtly different: write the tests first. Moving to TDD was another large improvement in my overall productivity because it drastically improved the quality of the code I write.

It seemed silly when I first heard of it, but now I won't write code any other way (except for short, exploratory programs). Give it a try!

</comment><comment><USER38> Wow, this guy guarantees that if it isn't tested, it doesn't work. Important projects that people depend on like the linux kernel must have really good test coverage.

</comment><comment><USER39> Jacques is stating the obvious here. I see testing code and running code in an organic relationship, like the flesh and the shell of a lobster, wrote more about it in here <http://www.douban.com/note/205412385/>

</comment><comment><USER40> My local university now requires tests to be submitted with homework. Sometimes though tests are provided.

</comment><comment><USER41> What do people use for testing web front ends? Selenium?

</comment><comment><USER42> I find that my tests often need tests, and sometimes even these second-order tests need to be checked and verified by third-order tests. In experimental programming though, just running the code is a test...

</comment><comment><USER43> I don't think it was a good read because I already thoroughly agree with you.

In fact, as with a lot of things about programming, even when programmers are widely accustomed to that line of thought, the real problem will be to convince management.

In my mind, testing (or lack of it) is part of the technical debt concept (<http://en.wikipedia.org/wiki/Technical_debt>).</comment>


Show HN: Authentic Virtual Letters For The Web - <AUTHOR> http://blog.bubbleideas.com/2012/06/authentic-virtual-letters-for-web.html

<comment><AUTHOR> @bubbles is an easy way to write letters from your browser. You can type, draw, sketch, make a collage, scribble and highlight on letters that were sent to you or sign in your own handwriting to make your letters look authentic. It is 100% free for consumers (ad-free also)and is as easy as writing on physical paper.

by @monsterix and @kumar_navneet

<comment><USER2> Interesting. If it works well on tablets and smartphones, this could really appeal to non-techies.

Is it possible to send letters to users who are not registered on this site? Forcing everyone to sign up is a huge barrier to adoption in my opinion.

<comment><AUTHOR> Yes it does work non-natively on an iPad i.e. on safari browser of iPad. We are yet to achieve mobile support, the current version is primarily a web app.

And yes, it is possible to send letters to users who are not on @bubbles yet. You can mention email id of the recipient(s) on the letter itself and it will be delivered as PDF over email. With your signature and drawings everything. :)

</comment></comment></comment><comment><USER3> very interesting UI.

<comment><AUTHOR> Thank you, @eviral</comment></comment>


Using red wine to turn iron telluride into a superconductor - <AUTHOR> http://www.technologyreview.com/blog/arxiv/27664/

<comment><AUTHOR> I find the 'randomly soak with liquid' methodology frightening but the quest for a better superconductor seems to be gaining some interesting footholds.</comment>


Robert Scoble departs his AR company following sexual harassment claims - <AUTHOR> https://www.theverge.com/2017/10/23/16527862/robert-scoble-resigns-transformation-group-sexual-harassment <comment><USER2> i know this is off topic but i never understood this this guy's influence.

<comment><USER3> Indeed, I wrote this three days ago:

"Since he appeared on the scene I have always wondered, how in an environment where engineers take pride for what they have actually done (US tech world), a guy that only talks and has no engineering accomplishment to show is given that much cognitive space. Back when he was a Microsoft evangelist (!) I have watched a few videos of him to get the sense of a talking human being. And I could't believe how shallow he was. His whole demeanor was one of an airhead."

To add to that, and get back on the topic, how can someone who has not writen a lot of code or designed significant hardware consult someone? And companies are obviously willing to pay him. What a world!</comment></comment>


Hollywood on Wall Street - <AUTHOR> http://www.nytimes.com/2011/10/23/opinion/sunday/bruni-occupy-wall-street-and-hollywood.html?_r=2

<comment><USER2> So if someone is a millionaire, they're not allowed to think that Glass- Steagall should be re-enacted, etc? Why must one be poor to align with the protesters?

<comment><USER3> Of course they can have an opinion, but celebrity involvement threatens to turn the protests into the fashionable left wing cause of the second. There's something artificial and glib about rich entertainer's politics - even when I agree with them I shudder when they weigh in on a subject.</comment></comment>


Parasitic computing -- what can you get other machines to compute for you unknowingly? - <AUTHOR> http://www.ddj.com/architect/184404947

<comment><USER2> Answer: Not much.</comment>