Start-Up Chile is OK. Nothing more. - <AUTHOR> http://liispeetermann.tumblr.com/post/26064265686/start-up-chile-is-ok-nothing-more#.T-xIPystjNs <comment><USER3> Very well said. I particularly agree with the list describing the kinds of companies that can get the most out of Start-Up Chile.

It's critical that participants have the right expectations but Start-Up Chile create a huge amount of marketing fluff which seems to get in the way of that. Now they have had well over 300 participants I hope they start focusing on communicating success stories (there are a few) and the learnings (there are loads) rather than "the dream" and "the vision". Enough interesting things happened over the last 18 months that they shouldn't really need to use old school marketing techniques any more.

I previously commented about my recommended set of Start-Up Chile expectations here:

<http://news.ycombinator.com/item?id=3811445>

</comment><comment><USER4> I like the idea of Startup Chile. After reading this article, I still like most of it, except for trust issues.

I'm not in favor of video surveillance, but if I ran Startup Chile, I'd be adding some cameras all over the place. Maybe go to a badge system for building access and egress.

Not being safe enough to leave your gear on the desk while you go to lunch or something is a big red flag that something's wrong. You can't have an open and free environment when folks are having to padlock everything they own and don't trust the guy next to them not to walk off with their iPad.

<comment><USER5> > Not being safe enough to leave your gear on the desk while you go to lunch > or something is a big red flag that something's wrong. You can't have an > open and free environment when folks are having to padlock everything they > own and don't trust the guy next to them not to walk off with their iPad.

That just seems really weird... Is it other people in the program, or do outside people have access, or...?

Changing subjects, I hope someone will do an analysis of the whole program 5 years from now to see what the results of it are. How many companies came/stayed/grew/died/etc...

<comment><USER6> _I hope someone will do an analysis of the whole program 5 years from now to see what the results of it are. How many companies came/stayed/grew/died/etc..._

Good point. It would be also interesting to know how the perception of Chile has changed in entrepreneurial circles through this program. I think this is really a unique idea and so far it seems as they did at least an acceptable job of running it.

<comment><USER7> Hey stfu! .. haha.. im part of the program and i think it has changed the point of view of some chileans. By now i have done mentorship for two university students and im sure their life-path has changed.

One of them has already raised $16k (little but enough for a 2-months project).

The other one is still developing the project but at least is working on it :).

None of those guys was taking this seriously until they saw young people being part of Startup Chile program. This is just the people i have been in close contact with and im pretty sure there are lots of cases like this ones.

<comment><USER6> Very cool, that's really a great way of giving back! I really hope that this is going to have a sustainable impact for Chile. They definitely deserve it for taking such a unique way of stimulating an innovative environment. How do you see generally speaking the "sticking" rate? What percentage of people in the program are most likely to stay there for longer than just the time they got the Startup Chile financing?

</comment></comment></comment></comment></comment><comment><USER8> I spent today (Thursday) talking with the Executive Director (Horacio) and a few of the senior staff members. I presented this morning on Lean Startup processes for the newly-arrived.

I'm in Round 2, I've been giving feedback for months to the staff. The feedback I got today about changes they're making during Round 4 (for those just arriving now) is pretty impressive. If they carry it all off then the programme will be improved by a fair margin for subsequent Rounds.

The improvements are still under discussion but ought to address many of the mentorship/fund raising/expectation issues that have been raised (at least - <USER2> have cautious optimism that that's the case).

Disclaimer - I don't work for SUP, I'm almost finished here in Round 2, I've had my complaints during the programme but generally they're reacting/improving to the significant issues. Things are improving for every new Round.

<comment><USER8> Horacio (exec director) today announced the changes that I'd hinted at yesterday (I didn't know this was happening when I posted yesterday).

Changes being rolled in: * Mentorship - try to provide mentors for all * Traction Groups - get companies to start and join private self-mentorship groups (based around the prototype I organised in this round: [http://ianozsvald.com/2012/05/16/mentorship-groups-in- startu...](http://ianozsvald.com/2012/05/16/mentorship-groups-in- startupchile/) ) * Roadshow in Silicon Valley - after Demo Days take companies up to the Bay Area and run an investment/demo road show * Academy - online & face to face courses for StartupChile members to learn about business basics (e.g. lean processes, pitching, sales etc) * Top 20 Accelerator - cherry pick a top set of companies and super-accelerate them (private mentorship, focus on growth etc)

I don't know the details of the above changes, the ideas will evolve and a lot of questions are raised. What interests me is how a lot of the current programme criticisms (e.g. lack of mentorship, DemoDay not being too cool, lack of peer mentorship) should be addressed (and then some).

As stated yesterday I'm not employed by StartupChile, I'm nearly finished with Round 2. As much as I've criticised the programme in the past I continue to be impressed at how quickly they're iterating and improving.

</comment></comment><comment><USER9> I don't agree with her list of companies that should apply to Startup Chile. For example, Startup Chile is great for bootstrapping companies. You get 6 months and $40.000 USD to test out your idea. You visit an amazing country and another culture. You can learn another language. Startup Chile is a great choice for people that are ready to make the jump from a boring job to starting their own thing.

And even if you are experienced doing startups it's still awesome to visit another culture and see how things work in another place. Maybe you won't like it that much, but at least you experienced it.

What Startup Chile isn't good at is creating companies that need VC funding or Silicon Valley connections. If your startup needs these things then don't look for it in Chile or anywhere else... because you won't find it here or anywhere else.

<comment><USER10> Don't you have to promise to hire people to get the $40K?

<comment><USER11> No, in the pilot round you got RVA points for hiring locals but they dropped that in later rounds so it is not even explicitly encouraged right now.

</comment></comment></comment><comment><USER12> I have to say that I don't really agree with the overall assessment made over here. It appears that a lot of people come to Startup Chile expecting the wrong things.

Why would you come to Chile and expect:

\- There will be no bureaucracy (this is a government run program..)

\- You won't have to give anything (RVAs) at all back - (equity free capital in return for what ? in that case..)

\- Connections to US accelerators and investors (WTF ?)

To be honest, it's unrealistic to expect all of the above. I do agree that Startup Chile can do MANY good things (connections to latin american investors, more guidance/mentorship, etc.) but why not take into account the fact that this is a young program being run by a government in a country with very less startup experience.

Here are some positive points I've heard from people:

\- Use government connections. Folks who have their startups in fields where government help can work eg. education, social service, etc. are able to uniquely utilize startup chile's clout in the government sector.

\- Learn some Spanish.

\- Do something relevant. You're hardly going to get support if you're designing a product that solves a problem in the US or elsewhere (with no possible extension into Latin America). Besides, why would a local investor be interested in that case ?

As for the part where filing statements, getting reimbursed, etc. - there's no need to whine about that. The processes have been streamlined a lot over the past few months and these guys seem to be working on it more, there is definitely good faith involved and it's not all "Oh yeah we're going to make them WORK for their money". They just need to be sure that your expenses are justified. I know of people who are trying to squeeze out an iPhone or two in their reimbursements. They naturally have to be very careful due to the fact that this is taxpayers money.

Furthermore, all the pains of startup chile are pretty well known. It is definitely not an accelerator, you will probably not have a lot of events and guidance. But, if $40k equity free capital and a reasonable amount of freedom (in how you use it..) are important to you - then sure, I think it's a program worthy of mention.

/ Just sick of all the whining that goes on about how Startup Chile doesn't connect you to the US blah blah blah.. -- why should it ? Also the sense of entitlement a lot of people carry is sickening. A lot of folks seem to treat startup chile as a 'gap year' and then whine about how they didn't manage to make the next $1B company (not saying that the author is doing this...). That's just messed up.

</comment><comment><USER13> The main Startup Chile drawbacks are:

\- they don't invest on you, instead they give you access to a grant

\- there are no real investors backing the program

\- there are no real entrepreneurs backing the program

\- they don't know anything about technology

\- nobody is thinking about getting rich except the entrepreneurs joining the program.

EDIT: Well actually there are local entrepreneurs too.

<comment><USER14> > nobody is thinking about getting rich expcept the foreign entrepreneurs.

What makes you think the foreign entrepreneurs are better than the local ones? I have not seen any such pattern in Startup Chile. In fact some of the best products (and teams) are Chilean.

<comment><USER15> I was under the impression that Startup Chile gives some preference/reservations to local teams.

In any selection process, any group that gets a boost due to irrelevant factors needs to meet a lower standard. Typically, a group of people meeting a lower standard will be inferior to a group of people meeting a higher standard.

Of course, if I'm wrong about Startup Chile boosting local teams, this reasoning wouldn't apply. Anyone know what their policies are?

<comment><USER11> In the first round no Chilean teams were allowed, second round they opened it up and now the rumor is they are moving towards more and more Chileans because, frankly, some foreign teams scam the system and go on a 6 month $40K holiday.

</comment></comment></comment></comment><comment><USER16> Thanks for the write-up - really good to see more experiences of the programme.

We were offered a space to be in the same batch as you, but we kind of realised this would be the case _before_ going. Whilst the money was attractive, the admin, the inflexibility on the length of the programme, and the fact it would be a distraction to actually launching our product meant we just stayed bootstrapped working from home.

Notably, the fact they don't give you the money up-front shows that they're not investing in your company (and that they have no interest in equity). You are going to be made to work for that cash - and that work is time not spent on your startup.

I'm confident we launched quicker this way - whether we would have made a killer connection to make or break our company through the programme, I guess we will never know! But it does seem unlikely from your review and the others that have gone before it.

</comment><comment><USER17> I think the author's complaint that all of the beneficial events, connections, etc. came from the participants and not the organization is a bit misplaced. After all, the whole point of Startup Chile (as I understand it) is to provide exactly this kind of networking, resources, etc. from foreigners because it's not really available in Chile today.

That being said, there's really no excuse for having poorly-secured and lit office space.

</comment><comment><USER18> One red flag- 100 working hours for getting all the paperwork done to get paid

Otherwise, I think the program is pretty clear about it's objectives from the get go. It's about bringing techies/entrepreneurs from all over the world to start businesses in Chile.

Expecting exposure to US investors is not fair I think. But the program should provide exposure to Latin American investors.

<comment><USER19> The 100 hours really surprised me. The rules are different for each round, but least for my team in the second round we have not had to spent that much time on it. We probably spent no more than 30 hours and that is generous. However I guess it depends on the type of company and the kind of expenses.

Overall I have found people's perspective on the program depend entirely on assumptions and expectations before they arrive. If you expect a suitcase of cash when you land, if you expect all the processes to be pre-arranged, if you expect to never have to deal with any bureaucracy, you will be in for a surprise. If you expect lots of opportunities to network and get connections, if you expect that the government will throw the odd curve-ball now and then, then SUP will be what you expect.

<comment><USER8> Me again (Round 2) - I spent 2 days doing the first reimbursement (following instructions, taking advice from Round 1 people) and then 1 day or less for each subsequent monthly meeting (including having the meeting). Write-up from a few months back: [http://ianozsvald.com/2012/03/24/this-week-in-startups- stron...](http://ianozsvald.com/2012/03/24/this-week-in-startups-strongsteam- pitch-reimbursements-mentorship/)

All in I'd expect 1-2 days per reimbursement meeting (including meeting time), less as you get better at it, less if you reimburse just a few big things (rather than lots of small stuff). Cash payments require less proof (less paperwork) than debit or credit cards (CCs require most). That's about all there is to it.

</comment></comment></comment><comment><USER16>
        "I believe companies with the following would get the most out of Start-Up Chile"

This list is what Startup Chile should be using to vet its applicants to ensure that no startup comes away feeling the programme wasn't really right for them - it's a shame that people will go with one expectation, only for reality to be vastly different. It only harms their image in the longer term - even if the number of participants looks impressive at first.

</comment><comment><USER20> I think the post author is right in the sense that Startup Chile is not for everybody, but I also think she was expecting everything to be provided to her as part of the program. I believe there are some good criticisms, like the one about office security (although, you should really get your own office, that's what the money is for), but most of it seems like unmatched expectations (she was expecting the same experience she and other members of her team had at american startup accelerators, and like she says, Startup Chile is not an accelerator/incubation program).

She also talks about not having access to mentors, and I know that is not completely accurate. Startup Chile has a mentorship system (godfather/godsons) in which experienced entrepreneurs help the teams participating in the program.

I was there for Demo Day too, there were two rooms with presentations. And even though they had some pretty bad technical issues at the room I was in, the whole thing there was in English (I can't say anything about the other room).

I hope that in spite of her disappointments, she had a good experience and that Startup Chile keeps improving in the future.

<comment><USER3> The "mentorship system" you've heard of isn't a mentorship system. When it works it connects you with a friendly Chilean that can help you by picking you up from the airport, helping you find accommodation, introducing you to other friendly locals and showing you around the city. They are generally no more experienced or connected than participants in the program. Sadly it works less than 50% of the time - most participants rarely see the "mentors" they've been assigned to.

They could be more useful to the startups if they were provided with some mentorship training and if there was some light-weight facilitation like YC's Office Hours to help it along.

<comment><USER20> I didn't know that there were mentors who were not experienced entrepreneurs. I have several (very successful and experienced entrepreneurs) friends, who are mentors for Startup Chile participants. They've advised these companies, hooked them up with important contacts for their businesses and even provided office space. I guess I generalized that to the whole mentorship system.

<comment><USER3> I guess it's luck of the draw. I don't envy Start-Up Chile's task of trying to find experienced mentors in Chile with time for 300 startups a year.

<comment><USER21> I think nico is talking about a CORFO program that I've only barely heard mention as a Startup Chile participant (someone else mentioned getting mentorship thru it, but I've never seen anything from Startup Chile on how we could participate).... while jot is talking about the padrino program.

So, two different groups of people.

<comment><USER20> I was actually talking about the padrino program and the people I know who are padrinos for Startup Chile participants.

</comment></comment></comment></comment></comment></comment><comment><USER22> This program is more than perfect for me. Point. I am from Egypt and can't find an investor to back me, so I am going to try this out.

Thanks for letting me know about it.

</comment><comment><USER23> It's slightly concerning that the author talks about people being "green", but then complaining about having to manage bureaucracy, not having access to a ready-made network of experts & having to spend your last peso.

Isn't this just part of the life of starting a business?

<comment><USER24> No, in many countries bureaucracy is not part of doing business. Especially in Estonia where setting up a company or doing anything with the government public services, taxes, reporting etc takes a few minutes online and is never done on paper.

<comment><USER12> Yes, but when you start something in Chile you can't expect it to be like Estonia or elsewhere. ;)

<comment><USER24> Why not?

<comment><USER25> Because it's not in estonian.

<comment><AUTHOR> And if this in Chile, it have to be big hassle? Fine, then entrepenuers will simply ignore this country. Simplez.

<comment><USER12> I think the point was that there would be some obvious differences in systems. That doesn't mean that they aren't improving their system - it just isn't at the same place as Estonia yet. Not so hard to understand - right ?

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I just graduated from Startup Chile and the main change they should make is market themselves and Chile as the bootstrap capital of the world. Look at SUP as a bootstrap opportunity and things make a lot more sense.

</comment><comment><USER22> Chile Government is very smart... they know that you will spend at least 60% of the money inside the country.. and there still a small potential to bring more investment into this, if you settle and get acquired!

</comment><comment><USER8> The Round 4 application process was discussed here a week back: <http://news.ycombinator.com/item?id=4158967>

It has discussion from Round 2+3 people on the pros and cons of the programme. Sidenote - I knew Liis (she's lovely), her concerns are echoed by others (including me). My take on the programme is nonetheless positive, you just have to come with eyes-wide-open.

</comment><comment><USER26> The bureaucracy, Spanish, and lack of connections to US investors and entrepreneurs make it a lot less attractive.

I wonder if a US state or AU/NZ would do something similar someday. English would be a big advantage, and if they outsourced the management of the program, they could deal with the bureaucracy, selection, etc. a lot better.

</comment><comment><USER27> I went to Japan 20 yrs ago on a scholarship and the moment I set foot on the campus I was handed an ATM card with ¥100k ready to use (~$1k), auto refillable every month.

I love Japan.

<comment><USER28> I went as a Monbusho scholar in the period 2004 - 2009 and this is not the case anymore. Nowadays you spend a lot of time filling forms and getting access to basic services like cellphones or Internet. They do give you around ¥160K these days...

<comment><USER29> A few years back, I was to go to Brazil on scholarship. Last minute, the US university mentioned they paid the money one month in...yet one has to pay at the start and Brazilian uni starts one month earlier than in US. Catch-22. Four months of prep, crossing T's and dotting I's and it all went down the drain.

</comment></comment></comment><comment><USER30> My interaction with this 'team' came earlier, where I wouldn't email replies nor pertinent information even when forwarded by 'big names' (to get attention).

This only backs up my impressions and feedback from others.

As a founder you need a handful of crucial things (amongst so many including drive to succeed): \- Capital \- Mentors \- Environment

Obviously there are more, but these are important.

</comment><comment><USER25> Thanks for a nice post. However, I'm still wondering about the networking part of this program. Where were most of the participants from? Was it Latin America? Also, were there any interesting people to connect with from Europe/US?

<comment><USER31> Most of the people were actually from the U.S. (if I remember the stats correctly), many people from Europe, also from Latin America, but not many locals inside the program compared to the others. There's a lot of interesting people for sure! From all around the world!

</comment></comment><comment><USER32> What kind of startup is willing to move to Chile for $40K? Two answers: startups that will benefit from being located in South America, and bad startups that have a really hard time raising a few thousand dollars and/or haven't thought through how moving several thousand miles increases their execution risk.

</comment><comment><USER33> Just as a side-note I would like to mention that the Colombian government will soon start a similar initiative called "Apps.co"[0]; probably is going to be less attractive than Start-Up Chile but it haves to start somewhere. I would also like to mention that I am a Colombian developer willing to create a Start-up in this country; if that is also your case please get in touch (my email is in my profile).

[0]<http://www.vivedigital.gov.co/appsco/> (Spanish)</comment>


Myths about /dev/urandom - <AUTHOR> http://www.2uo.de/myths-about-urandom/ <comment><USER3> Could someone explain DJB's point to me:

      Cryptographers are certainly not responsible for this superstitious nonsense.
      Think about this for a moment: whoever wrote the /dev/random manual page seems to
      simultaneously believe that

      (1) we can't figure out how to deterministically expand one 256-bit /dev/random
      output into an endless stream of unpredictable keys (this is what we need from
      urandom), but

      (2) we _can_ figure out how to use a single key to safely encrypt many messages
      (this is what we need from SSL, PGP, etc.).

      For a cryptographer this doesn't even pass the laugh test.

Is the argument here simply that a properly encrypted message should look like randomness? And as a result we should be able to turn something non-random into randomness?

<comment><USER4> The same types of cryptographic algorithms used in SSL, PGP, etc. are also used to securely expand a small bit of entropy into an endless stream of good randomness. It's intellectually inconsistent to not trust these algorithms when used in an RNG, but to trust them when used in SSL, PGP, etc. See the contradiction with stressing the importance of using random, not urandom, when generating SSL/PGP keys?

</comment></comment><comment><USER5> These aren't myths, they're platform guarantees. It just so happens that a few of the most common unixes (Linux, BSD) implement a very good /dev/urandom and the author is suggesting that we write non-portable software that depends on implementation details of these platforms.

There can be benefits from depending on non-portable implementation details but also significant drawbacks.

<comment><USER6> No. Applications _on Linux_ should use urandom to the exclusion of any other CSPRNG.

<comment><USER7> > _Applications on Linux should use urandom to the exclusion of any other > CSPRNG_

Applications, yes. Appliances built on it - now that's more open to interpretation.

Back in 2003/2004 I was building a centrally managed security appliance system. At the time I made the hard choice that first-boot operations (such as generating long-term device keys) MUST use /dev/random. It made the initial installs take longer, but I refused to take the chance that an attacker could install and instrument a few hundred nodes and find out possible problems with entropy sources.

Once the first-boot sequence was over, applications used /dev/urandom for everything. This included the ipsec daemons. Forcing everything to /dev/random during first boot made sure that on subsequent boots there would be (for all practical purposes) enough entropy available for urandom to work securely.

The first-boot problems were amplified by the fact that we were running our nodes inside virtualization. (At the time: UML, and we built our own on top of it. Xen wasn't nearly ready enough back then.)

It's fascinating to see that the problems we had to deal with 10 years ago are now becoming an issue again. To this day I choose to use /dev/random if I need to generate key material shortly after boot (which could be install), or for my own long-term use. Good thing personal GPG keys have a shelf-life of several years...

<comment><USER6> If you're building an appliance, why wouldn't you simply ensure urandom is seeded at first boot?

I'm sympathetic to people's concerns about generating long-term keys. But my problem is, /dev/random isn't addressing the major risks there either. You should generate long-term keys on _entirely separate hardware_.

</comment></comment></comment></comment><comment><USER8> > Both /dev/urandom and /dev/random are using the exact same CSPRNG

The author keeps coming back to this fact, but I don't understand how it negates any of the arguments in favour of using /dev/random. What does it matter if the numbers are ultimately coming out of the same PRNG? I don't see how this negates the "self-healing" property of /dev/random or any of the other advantages. It seems like the author is really just saying, "/dev/urandom is probably good enough".

<comment><AUTHOR> This is basically a response to the widespread conception that /dev/random has some mechanism whereby it generates "true" random numbers, while /dev/urandom only uses some lowly PRNG.

The idea that a lot of people get from that is that urandom is not much better than Mersenne twister, while /dev/random is the real thing.

And yes, you're right, the argument is precisely "computational security is good enough".

By the way, /dev/urandom is also self-healing.

Which other advantages of /dev/random might be there, apart from the cold boot case?

<comment><USER9> > The idea that a lot of people get from that is that urandom is not much > better than Mersenne twister

> And yes, you're right, the argument is precisely "computational security is > good enough".

Point of order. MT is not, and is not meant to be, a cryptographically secure random number generator.

Generally speaking, good RNGs may be divided into two categories. First, there are RNGs designed for simulation. Goals: high periods, strong statistical randomness, and speed. Then there are RNGs designed for crypto. These have one primary goal: that even if you knew how the RNG worked, and had a long stream of previous output, you could not [easily] predict the next output.

MT is in the first category. It is trivially predictable given about 650 past integers, since they collectively defined its internal seed.

<comment><USER10> A point of order is limited to issues regarding procedure. It is not meant for factual disputes and or differences of opinion.

<comment><USER9> Shoudn't your comment have been a point of order? :-)

</comment></comment></comment></comment></comment><comment><USER11> I could be mistaken, but weren't there a security issue a while back with keys generated at boot time by using /dev/urandom? Since there weren't enough entropy, using urandom created an silent failure in the security design.

I think this is a key point that the article is missing. Silent security failures are very, very bad. Blocking will at least provide assertion that either things are as expected, or the issue will be detected early.

<comment><USER12> It's not missing:

 _Linux 's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer._

I invite you to read the article, because there's more.

<comment><USER11> Yes, I did read it.

But my key point is that urandom can fail silently. /dev/random create an assertion that there is enough entropy, which is a useful assertion to do until there are guaranties from urandom of the same.

<comment><USER13> But the entropy estimates are spurious, which means /dev/random can easily fail silently. This is the whole motivation behind Bruce Schneier and Niels Ferguson developing the Fortuna algorithm. Yarrow relied upon entropy estimates to recover from state compromise. With Fortuna, you don't know how long it will take to recover from state compromise (since it's difficult to reliably estimate entropy), but you know it eventually will happen.

Also note that most POSIX systems will cat a random seed file into /dev/random at startup and save entropy from /dev/urandom to the seed file at shutdown (and also hopefully right after adding to the entropy pool at startup). As long as an attacker doesn't have access to the disk or root permissions on the host, insufficient entropy should only be a problem the first time a host boots after install, presuming it gathers enough entropy after first boot.

FreeBSD and OSX use Yarrow for /dev/random and /dev/urandom, with absolutely no difference in behavior between /dev/random and /dev/urandom. I'd like to see Linux adopt Fortuna and make /dev/random non-blocking, though I can see the case being made for making /dev/random block after each boot until the estimated pooled entropy first goes above some threshold.

<comment><USER11> What happens with live-cd's on a read-only media? What about disk-less/thin clients? What about image restoration from backup? In each of those cases, the seed will either not be there or identical for each boot.

I would like to see a smarter /dev/urandom which asserts that there is enough fresh entropy. It would increase the trust of using it, and would put /dev/random usage in the special category of one-time pads. Until then, each case which the saved seed can cause issues with will have to be addressed if one choose to use /dev/urandom.

<comment><USER14> /dev/random should not be used for one-time pads. It's still generated from a stream cipher-based CSPRNG and is not "true" randomness.

</comment></comment></comment></comment></comment></comment><comment><USER15> Another good source explanation of the difference between urand and rand is the Linux source code, which is well commented:

[https://github.com/torvalds/linux/blob/master/drivers/char/r...](https://github.com/torvalds/linux/blob/master/drivers/char/random.c)

The operation is explained starting on line 52. The 2 paragraphs starting on line 78 explain the relationship behind the entropy estimator and the CSPRNG (It relies on SHA-1).

> As more and more random bytes are requested [from /dev/urandom] without > giving time for the entropy pool to recharge, this will result in random > numbers that are merely cryptographically strong

<comment><USER16> Thank you! That was actually much clearer. Line 307 is also relevant - <USER2> seems that the urandom pool is reseeded at most every 60 seconds?

[https://github.com/torvalds/linux/blob/master/drivers/char/r...](https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L307)

</comment></comment><comment><USER17> I'm not a crypto expert but I find the arguments of this article (and tptacek et al) convincing.

The one thing I still don't like about /dev/urandom is this: urandom's proponents say that it only fails on first boot, because modern linux distros capture entropy to seed urandom on following boots.

This means that in order for /dev/urandom to be ok, I have to depend on specific functionality of both the kernel and the linux distribution. In contrast, /dev/random is (arguably) harder for the distro to mess up, as it's primarily a function of the kernel.

Given the number of times distros have screwed up crypto, what are the odds that this will someday matter in the real world?

</comment><comment><USER18> > Virtual machines are the other problem. Because people like to clone them, > or rewind them to a previously saved check point, this seed file doesn't > help you.

There is work on fixing this problem (or, at least, improving the situation) on Ubuntu: [http://blog.dustinkirkland.com/2014/02/random-seeds-in- ubunt...](http://blog.dustinkirkland.com/2014/02/random-seeds-in- ubuntu-1404-lts-cloud.html)

<comment><USER19> Cloning: okay. Regenerate the seed, and also regenerate your sshd's private key.

But rewinding and restoring to a previous save point? What's the harm in keeping the seed?

<comment><USER18> I'm not sure what the author's intention was when he said that, but I think there would be a problem if you cloned, and then returned to a previous save point shared with other clones.

<comment><AUTHOR> That's one thing.

The other one is that after rewinding you've got the identical internal state of the CSPRNG.

So you're possibly reusing the same random numbers (or closely related ones) as before.

Of course, after a short while the rewinded VM diverges. It's another flavor of the cold boot case, really.

<comment><USER20> If I rewind a VM, and it chooses the exact same random numbers this time, I consider that everything acting correctly.

</comment></comment></comment></comment></comment><comment><USER21> Why not make /dev/urandom block, but only at boot time until sufficient entropy has been achieved? Then you could "trust" it, even in boot conditions and in normal operations it would still never block…

Or if the change in semantics is too onerous, a new /dev/drandom (delayed- random) could do this.

</comment><comment><USER22> This article's premise seems to come down to the key argument under the section "What's wrong with blocking?", which seems to summarize as "security should not get in the way of the developer: if it does, they will turn off the security". This frankly just seems silly: if the developer cannot be trusted to not do something insane (seriously? "patching out the call to random()"?!), then they should not be developing :/.

This is like saying that using consistent databases for things that require consistency is also "wrong", because the developer is going to add some ludicrous poorly-implemented caching layer in front on production as the performance dips, leading you to have a poorly-controlled inconsistent system anyway. It's an argument I appreciate, but one that indicates a deeper problem of developers thinking they can fix things they can't.

...and that's the only argument in the entire document for why /dev/random is _bad_ : everything else is a justification for why /dev/urandom should be considered a reasonable alternative to /dev/random, most of which is difficult to confirm or deny unless you are a cryptographer. I mean, from a naive standpoint, it would sound like "putting all your eggs in one basket" could lead you to a problem, but how would I know, right?

Helpfully, the article claims to quote cryptographers on the matter. However, and this pretty much damns this article for me: he takes these quotes out of context. If you read the original sources, Daniel Bernstein makes it clear that /dev/urandom is broken on Linux (more on this later), and Thomas Pornin was responding to a user that was simply trying to get unique random values (where /dev/urandom is obvious).

As for Thomas Ptacek's emphatic "use /dev/urandom" repetition, his article was about people attempting to use user-land replacements for the kernel implementations, not people who were using /dev/random. In essence, he's trying to make the argument that people shouldn't be _so afraid of /dev/urandom_ so as to _use something clearly worse_. He _does_ state that /dev/random is overrated, but correctly points out its flaws.

Back to this article: after a ton of argumentation that the people suggesting that there is a key difference between /dev/random and /dev/urandom are inherently being misleading, the author gets around to quoting a section of the man page that sounds perfectly reasonable, and even is willing to cede that there is no issue using /dev/random for those use cases. I think the author is just mad because some service is slow. :/

Now, here's what I'll leave you with: an argument why this author's article is not just wrong but promoting beliefs that are actively harmful, an argument that can I hope can be believed even if you aren't a cryptographer and does not rely on me being a cryptographer: its an argument based on practical concerns only, with a demonstration of the problem not just in theory, but that happened to real people/developers.

[edit: Apparently, I misremembered this Android issue, so when I pulled sources for it I ended up with something that is not actually an issue with /dev/urandom. I have added details on a different situation where /dev/urandom actually was the culprit, but the argument isn't _quite_ as strong. I was hoping for an argument that anyone would believe without invoking even a single hypothetical, but sadly I screwed up: I'm sorry for the confusion :/. I think the new example still makes a strong, though not impervious, point.]

So, if the author got his way, then all source code everywhere would be referencing /dev/urandom instead of /dev/random for all use cases (including "long-lived keys"). However, the author also admits that /dev/urandom "isn't perfect", and that on Linux it _never_ blocks, even when it really should. It is then claimed that the correct solution to this problem is that you should seed virtual machines with entropy before using them.

Look: that just isn't always possible. I say this not from theory, but from the trenches of information security. On Android, some poor developer made java.security.SecureRandom use /dev/urandom. This meant that all Java libraries that rely on random numbers were getting ones from urandom, even when they claimed that they wanted "cryptographically strong" ones. Put short: the author's dream come true, codified into the library.

Sadly, users expect to be able to use Android devices soon after they boot, the user is not in control of the entropy sources, and the people who build the kernel drivers for these devices often didn't include enough entropy sources to fill the pool faster. This meant that all of this code was now broken: instead of blocking until "seriously-random numbers" could be generated, it would get "reasonably random-looking ones".

This is not a theoretical issue: people built bitcoin wallet applications sitting on top of these APIs, and some of the people using those wallets ended up with bitcoin addresses secured by keys that were painfully predictable across usages on different devices (the specific concern people bring up using /dev/urandom!). This was looked into, traced back to this design flaw, and Google even commented on the situation.

[edit: For clarity, this is the part that is wrong; as pointed out in the author's rebuttle to my comment, SecureRandom was actually doing something ludicrous here--the kind of thing that Thomas Ptacek was angry about ;P--and thereby Google's own article, which I had pulled up as a source for something I had apparently misremembered, claims that developers could consider using /dev/random _or_ /dev/urandom to replace it.]

[http://android-developers.blogspot.com/2013/08/some- securera...](http://android-developers.blogspot.com/2013/08/some-securerandom- thoughts.html)

[edit: Thankfully, there is another situation I can cite: the attack on routers from a year or two ago that involved low-entropy keys that were generated at boot. It is the same issue, but what makes this a weaker argument is that the user is now the developer, and the developer is actually in control of the device and could have fixed the entropy pool as stated by both this author and by Daniel Berstein's full comment.]

[edit:]

So, in this new example, the key issue is that a bunch of embedded systems-- routers and firewalls from companies such as Cisco--were generating keys to secure their configuration portals and administrator consoles using /dev/urandom. This was done, on first boot (when there would be no entropy available), and the result was that many RSA keys were generating the exact same input prime numbers. If you are trying to factor a large semi-prime, and you have another large semi-prime that shares a factor, you can break it apart very easily with simple math.

Some researchers went through to determine why this happened, and their conclusion was that reliance by library developers on /dev/urandom, being used on devices and at moments where /dev/urandom didn't end up working very well, was the "root cause" of the issue, and made a recommendation to library developers that usage of less secure mechanisms should be a non-default option and that any tradeoffs in its selection should be clearly documented, lest security be contingent on factors that do not immediately seem related to security.

[https://factorable.net/weakkeys12.extended.pdf](https://factorable.net/weakkeys12.extended.pdf)

> In the final component of our study, we experimentally explore the root > causes of these vulnerabilities by investigating several of the most common > open-source software components from the population of vulnerable devices > (Section 5). Based on the devices we identified, it is clear that no one > implementation is solely responsible, but we are able to reproduce the > vulnerabilities in plausible software configurations. Every software package > we examined relies on /dev/urandom to generate cryptographic keys; however, > we find that Linux's random number generator (RNG) can exhibit a boot-time > entropy hole that causes urandom to produce deterministic output under > conditions likely to occur in headless and embedded devices. In experiments > with OpenSSL and Dropbear SSH, we show how repeated output from the system > RNG can lead not only to repeated long-term keys but also to factorable RSA > keys and repeated DSA ephemeral keys due to the behavior of application- > specific entropy pools.

> When we disabled entropy sources that might be unavailable on a headless or > embedded device, the Linux RNG produced the same predictable stream on every > boot. The only variation we observed over 1,000 boots was the position in > the stream where sshd read from urandom.

> On stock Ubuntu systems, these risks are somewhat mitigated: TLS keys must > be generated manually, and OpenSSH host keys are generated during package > installation, which is likely to be late in the install process, giving the > system time to collect sufficient entropy. However, on the Fedora, Red Hat > Enterprise Linux (RHEL), and CentOS Linux distributions, OpenSSH is > installed by default, and host keys are generated on first boot. We > experimented further with RHEL 5 and 6 to determine whether host keys on > these systems might be compromised, and observed that sufficient entropy had > been collected at the time of key generation (due to greater disk activity > than with Ubuntu Server) by a slim margin. We believe that most server > systems running these distributions are safe, particularly since they likely > have multiple cores and gather additional entropy from physical concurrency. > However, it is possible that other distributions and customized > installations do not collect sufficient entropy on startup and generate weak > keys on first boot.

> For library developers: Default to the most secure configuration. Both > OpenSSL and Dropbear default to using /dev/urandom instead of /dev/random, > and Dropbear defaults to using a less secure DSA signature randomness > technique even though a more secure technique is available as an option. In > general, cryptographic libraries should default to using the most secure > mechanisms available. If the library provides fallback options, the > documentation should make the trade-offs clear.

[/edit]

Of course, this is covered by the idea that these devices were not properly configured; but that's kind of the point, right? What everyone is saying about /dev/urandom is that it isn't guaranteed to produce anything "seriously" random; it happens to, most of the time, on most operating systems, produce something _incredibly_ random, but some times, on some operating systems, it might produce something that is barely random at all.

This means that if everyone switches to using /dev/urandom in their code, a ton of libraries are going to work on some systems, and not on others; they might work on a properly configured server, but not on an Android device, or might work on one cloud provider, but not another... this is insane... if I download "secure off-the-record messaging implementation library for Linux", am I going to expect it to fail like this?

Certainly, the developers this article seems to believe are both common and acting reasonably enough to be worked around by people writing code--the ones who are supposedly going around patching random() out their libraries ;P--are not going to realize their code isn't secure, or that they they need to configure their kernel or operating system distribution to make it secure; but this is even going to burn the people reasonable enough to download code and not try to hack it :/.

[edit: And, to close the earlier edit: clearly the people who were building these embedded routers didn't realize these tradeoffs. The author of this article is thereby asking developers to be cognizant of how these different pseudo-random number generators operate and design their entire systems in ways that will make specific sub-components, components they probably don't understand well and "just want to be secure", continue to work correctly under potentially-modified assumptions. While they technically can do this--unlike the sadly-flawed Android argument I wanted to make, where users and developers had no control--this seems like a much higher bar than keeping people from taking random() and patching it out entirely due to a performance benefit, and comes down to a simple heuristic.]

<comment><AUTHOR> Thanks for laying out your thoughts, but obviously I disagree.

Let me rebut two points that kind of irk me:

You claim that the Android problem that bit several Bitcoin wallets was due to java.security.SecureRandom using /dev/urandom.

That is mistaken, as the blog posting you gave clearly shows:

"Developers who use JCA for key generation, signing or random number generation should update their applications to explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random."

So, in their opinion, /dev/urandom is fine.

Furthermore you claim that I've taken quotes out of context.

I was aware that there is the danger of misunderstanding these people's point of view, so I emailed all three of them, right when I put this web page up some days ago, specifically asking them if they felt that I might be misrepresenting them or if they are otherwise unhappy about me using their names.

Of those three two replied (both very quickly).

Daniel Bernstein replied very shortly with "Seems reasonable.", but noted that he disagrees with the "more entropy cannot hurt" point. That's why I added the little sidebar with a link to his blog posting.

Thomas Pornin seems to have taken the time to really read the article, he wrote "That's a fine page. I like it.", noted a mistake in the boot scripts section (that I have fixed) and suggested some additional points to discuss (which I did not put on the page).

Off-topic remark: All in all I was really fascinated how easy it is to get in touch with those highly-respected people, and how respectful they treat "us normals". :-)

<comment><USER22> Wow, you totally win on the Android thing; I apparently misremembered that issue. I'm really sorry: I pulled a source for that based on memory of it having happened, but failed to notice that I had misremembered the cause of the problem. I've added a couple inline edits to my comment response admitting the ways in which it is wrong. Thankfully, this isn't the only example of this problem, it was just the one that was easiest for me to cite, so I'm going to go add a couple paragraphs shoring up the argument [edit: done; I also left the original example, but admit clearly how it is flawed].

> Furthermore you claim that I've taken quotes out of context.

As for this, I don't just claim it: I demonstrate it; the fact that these people also separately said your article sounded reasonable doesn't change the original reasons they made their comments. It hurts my position that they approved of your article, but it still irks me that you are using these quotes as evidence, when they aren't actually good arguments for your position. "I e-mailed these people and they agreed with my article" would have been a much stronger statement to me than "they said these things, out of context and in ways that sort of undermine my position, that you should believe".

</comment></comment></comment><comment><USER23> What if certificates and SSL weren't guaranteed to work properly "on cold boot" and the industry expected OS implementers to know this and take appropriate steps to "do it right?" This wouldn't make any sense at all. Yet CSPRNG are pretty foundational to cryptographic tools across the board, and the programming field seems to have this kind of hair-shirted attitude about it.

We as a technical community and we as a society need to start using the same stances and strategies that governments and agencies like the NTSB use to prevent accidents. When planes crashed in the wooly pioneering days of aviation, people probably stood around sadly tsk-tsking someone's failure to recognize a stall. Today, the NTSB conducts root cause analyses and the industry takes concrete steps to prevent future mishaps. (Like equipment that detects stall and warns the pilot.)

In this case, why don't we simply have classes of devices that are expected to implement crypto for end-users, and require them to be built with generous entropy pools? (To head-off the expected smart-asses: Each one gets their own unique one, of course.)

(EDIT: An analogy: What if you knew that pilots all had conflicting opinions on how to fly and maintain a plane, with constant acrimonious debates, and where some large swathe of all pilots simply were operating on misinformation? Would you fly? Would you expect lots more crashes? Now ask yourself what the situation is like with computer security, where knowledgeable people expect security to always be broken.)

<comment><USER24> > In this case, why don't we simply have classes of devices that are expected > to implement crypto for end-users, and require them to be built with > generous entropy pools?

Intel added a generous entropy source to their processors. The result is that nobody trusts it as a single entropy source, and /dev/random blocks anyway. Also, we are learning that using it only as an added source may also be harmful, and maybe we should ignore it completely.

I don't think this'll have any simple solution, although the idea of a CSPRNG that may block only at boot is interesting.

<comment><USER14> There's no problem with combining non-entropic (or even malicious!) sources of entropy into an entropy pool. As long as _some_ (and enough) of the input is unpredictable to an attacker, they can't predict any outputs of the system.

</comment></comment></comment><comment><USER25> The author seems to be assuming that all operating systems use the same implementation or have the same man page even for these random number generator devices -- they do not.

For example, on Solaris from random(7D):

      The   /dev/random   and /dev/urandom  files  are suitable
      for applications requiring high quality random numbers
      for cryptographic purposes.
      ...
      While bytes produced by  the /dev/urandom  interface are
      of lower quality than bytes produced by /dev/random, they
      are nonetheless suitable for less demanding  and shorter
      term cryptographic uses such as short term session keys,
      paddings, and challenge strings.

In short, on Solaris, you can use either one although you are encouraged to only use /dev/urandom for specific cases.

<comment><USER26> How much do you want to bet that that man page isn't grossly misleading, just like the linux one?

<comment><USER25> I'm very much willing to bet the Solaris man page is NOT grossly misleading, since I know the past and present authors / maintainers of the cryptography framework on Solaris personally :-)

Also, one of the Solaris Security Engineers wrote about random number generation on Solaris extensively just last year:

[https://blogs.oracle.com/darren/entry/solaris_random_number_...](https://blogs.oracle.com/darren/entry/solaris_random_number_generation)

Some blogs from other Solaris Security engineers:

Valerie Fenwick: [http://bubbva.blogspot.com/](http://bubbva.blogspot.com/)

Dan Anderson: [https://blogs.oracle.com/DanX/](https://blogs.oracle.com/DanX/)

Darren Moffat: [https://blogs.oracle.com/darren](https://blogs.oracle.com/darren)

...and last, but not least, Enrico Perla (doesn't have a blog at the moment as far as I know) did author this book and is a Solaris Engineer and someone that works on Solaris Security-related things:

[http://www.amazon.com/Guide-Kernel-Exploitation-Attacking- Co...](http://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Core)

<comment><USER26> Okay, you've convinced me, they definitely put in a somewhat weaker urandom. Also that function for getting random numbers with no zero bytes 'for key generation' terrifies me a bit.

<comment><USER25> Yeah, Solaris has pretty strong crypto verifications thanks to a great security team :-)

I'm glad I could provide useful info.

</comment></comment></comment></comment></comment><comment><USER27> _> Imagine an attacker knows everything about your random number generator's internal state ... But over time, with more and more fresh entropy being mixed into it, the internal state gets more and more random again._

Of course that probably only only counts if an external or local unprivileged entity manages to become informed of the random source's internal state. If the attacker has direct access to the kernel's state then they probably have access to influence (or at least monitor) the incoming entropy such that they can _stay_ informed of the full internal state.

There is a point in some attacks beyond which your only half way guaranteed solution is the metaphorical orbital nuke platform.

<comment><USER28> If you always use the same seed, and the attackers knows the PRNG implementation details, then he can devise the seed, and after that he can predict the next value. So, reseeding makes sure this doesn't happen. I think. I'm not a cryptography expert, more of an aspiring noob. :D

You don't need access to the machine.

<comment><USER27> Aye, but if the attacker is local and can see the pool directly, then they may be able to circumvent your attempts to reseed so you can't escape the situation that way. Once someone has that level of access all is lost: turn it off and build a new one!

Of course if the attacker is not that far in and has derived the PRNG state by other means (and you can stop them just relearning the state by the same means) then reseeding would work.

</comment></comment></comment><comment><USER29> The only sensible long-term solution for Linux seems to be to adopt FreeBSD's way of /dev/random operation - block once until enough entropy is gathered and then never block.

This would make sure that distro vendors don't even get a chance to mess initial seeding at boot time. It will also force vendors of embedded or "cloud" distributions (eg. Ubuntu's AWS images) to find a way to pre-seed the images to reduce the initial boot times.

Unfortunately there is such a huge amount of software that depends on this particular difference between /dev/random and /dev/urandom that I don't see the change happening soon.

</comment><comment><USER30> Always good to see people trying to fight superstition. :) Just one tiny nitpick if you don't mind: it seems to me it's somewhat unclear what does FreeBSD actually do. In FreeBSD there is in fact no /dev/urandom, it's just a symlink to /dev/random. If one already doesn't know this, relevant parts of the last section can be a bit confusing, IMO, so maybe you should point out that they are the same device (or that urandom doesn't really exist, or something like that).

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER31> I found this article very confusing, second paragraph:

      /dev/urandom is a pseudo random number generator, a PRNG,
       while /dev/random is a "true" random number generator.

      Fact: Both /dev/urandom and /dev/random are using the exact same CSPRNG (a cryptographically secure pseudorandom number generator). They only differ in very few ways that have nothing to do with "true" randomness.

What? So it is a myth, then why is the line started with: "fact"?

<comment><USER32> He's saying:

      This a commonly believed myth

      Fact: This is the real fact

</comment></comment><comment><USER33> most libraries use some form of specialized crypto random number generator (openssl uses the ssleay random number generator, JDK has the same schema for java.security.SecureRandom): /dev/rand is used to seed it with some random numbers, each iteration computes the SHA1 checksum of the previous state, the algorithm returns part of the state as random number output.

The assumption here is that the initial state can't be guessed, i guess you would rather use /dev/random for that, even if it blocks. Now be careful with the initialization step of your favorite crypto library, most inconsistencies /fishy tricks do happen right here !

Also another issue is that that such a random number generator introduces locks; I have a small program that encrypts everything with RSA, and uses multiprocessing to speed up the process; RSA encryption is supposed to use padding schema that needs to generate random numbers, so it locks, however you don't have this problem with decryption - that's where it counts because RSA decryption is much slower than encryption.

here is my project: [http://mosermichael.github.io/cstuff/all/projects/2014/02/24...](http://mosermichael.github.io/cstuff/all/projects/2014/02/24/openssl.html)

</comment><comment><USER34> As people have pointed out in this thread and other articles, clearly there can be issues with using /dev/urandom on boot where there is a lack of entropy. What I would love to know more than anything on this topic though, is whether it might ever make sense to use /dev/random after boot--after the CSPRNG has been properly seeded with good entropy. Specifically, I would love to hear of any real attacks. Anyone?

<comment><USER30> It makes no sense. The only difference between /dev/random and /dev/urandom is that random uses the estimator of the seed entropy (which doesn't make that much sense to begin with) to block when it "estimates" that there wasn't enough entropy in the seed, but apart from that gives numbers _identical_ to the ones urandom gives.

<comment><USER34> Maybe I'm not following your response. What I'm saying is that there _are_ reasons to use /dev/random at least after boot (to block for seed entropy). Saurik gives a real world example of the "cold boot" problem as other articles have done in the past. Are you saying we should be able to simply stop there and then just use /dev/urandom? If so, then why is the CSRNG re-seeded every 60 seconds? It would seem that there are reasons for doing so.

<comment><USER30> > Are you saying we should be able to simply stop there and then just use > /dev/urandom?

Yes.

> If so, then why is the CSRNG re-seeded every 60 seconds? It would seem that > there are reasons for doing so.

From what I understand about it (IANACryptographer), mostly to safeguard against situations where an attacker can learn the internal state of the CSPRNG at one moment. But I don't think this is too relevant for the problem at hand.

The only difference in Linux between /dev/random and /dev/urandom is that /dev/random always plays a guessing game about the seed entropy. The main argument here is, I guess, that this is a silly game. How can you really estimate entropy? It doesn't only depend on what physical sources in the machine give you, but also on what the attacker knows or can know about these sources and the state of the machine. How do you estimate that?

This was the main motivation behind the Fortuna CSPRNG by Schneier, Ferguson and Kelsey. There is no guessing going on, rather the algo is designed to not need to guess. Interestingly, the way Fortuna works seems to me would also somewhat mitigate the kind of attack DJB talks about in the article referenced by OP[1].

[1] [http://blog.cr.yp.to/20140205-entropy.html](http://blog.cr.yp.to/20140205-entropy.html)

</comment></comment></comment></comment><comment><USER35> What is the point behind an 18-point font? Even if you Ctrl-minus to reduce the font you get this tiny squeezed column of text and _still_ have to scroll forever. My scrolling finger and eyes are exhausted.

<comment><AUTHOR> It's hard to please everyone.

[http://www.reddit.com/r/linux/comments/1zt76a/myths_about_de...](http://www.reddit.com/r/linux/comments/1zt76a/myths_about_devurandom/cfww9gs)

</comment></comment><comment><USER36> For the vast majority of cases, urandom is fine. I am glad random exists though.

</comment><comment><USER19> Nice try, NSA!

</comment><comment><USER37> tldr..

haveged, /dev/random</comment>


Human-AI generated pizza - <AUTHOR> https://howtogeneratealmostanything.com/food/2018/08/30/episode2.html <comment><USER2> A char-RNN is a bad way to go about it. The results are effectively random - there's a ton of structure in recipe-space, but forcing it all through the bottleneck of text (and then sampling!) is going to hide a lot of it. You want something like "Sukiyaki in French style: A novel system for transformation of dietary patterns" [https://arxiv.org/abs/1705.03487](https://arxiv.org/abs/1705.03487), Kazama et al 2017's `word2vec` (using structured recipes like [https://open.blogs.nytimes.com/2015/04/09/extracting- structu...](https://open.blogs.nytimes.com/2015/04/09/extracting-structured- data-from-recipes-using-conditional-random-fields/) ); or IBM Watson's recipe generation ( [https://www.eater.com/2014/2/26/6272773/food-truck-is- actual...](https://www.eater.com/2014/2/26/6272773/food-truck-is-actually- serving-ibms-insane-computer-generated-dishes) [https://www.newyorker.com/magazine/2016/11/28/cooking- with-c...](https://www.newyorker.com/magazine/2016/11/28/cooking-with-chef- watson-ibms-artificial-intelligence-app) ).

<comment><USER3> I think the intent (and this blog in general) is more for _fun_ rather than an academic exercise.

<comment><USER2> If you used better approaches, the recipes sampled would be a lot more fun to evaluate and discuss. With generative stuff, there's a sort of inverse uncanny valley: it's only when it gets _very_ close to perfect that it's really interesting to look at, because that's where you get the most creativity and reactions like 'I can't believe that worked' or 'maybe...'. For example, I find that sukiyaki paper a lot more fun to read than OP, because the recipes are meaningful rather than random gibberish. ('cranked red onion' is not actually amusing, it's just gibberish).

</comment></comment></comment><comment><USER4> You have roughly 3 main toppings per pizza before it becomes a cluster-fuck, maybe 50 ingredients if you're stocked. There are 125k combinations, half of which _obviously_ won't sell, 49% of which might sell as a novelty, with the remaining 1% being the combinations people mostly know about.

If the menu has 20 new combinations per day, I'm having a hard time seeing why an AI would be better able to derive a new list per day than a motivated high- school cooking class is.

If a mechanical robot had some precision, I'd be more interested if an AI was trained to place the ingredients in optimal locations (r, theta) on the pizza, so as to maximize enjoyment and minimize cost.

</comment><comment><USER5> Most of those sound like a recipe for going out of business.

</comment><comment><AUTHOR> Some of those recipes looked great. I wish I wasn't gluten intollerant.

<comment><USER6> It's definitely possible to get GF-pizza, the dough is a little strange (dryer and chewier, usually). My girlfriend is gluten intolerant too and we live somewhere without too many exotic food ordering options but there's a number of pizza places that offer a gluten-free base. Ask around, you might be surprised!

</comment></comment><comment><USER7> This kills the Italian

</comment><comment><USER8> TL;DR - it's canadian bacon and pineapple, thin crust.</comment>


Congress Rep. Brad Sherman calls for the ban of all cryptocurrency [video] - <AUTHOR> https://www.youtube.com/watch?v=Cnz2oo8MRas <comment><USER2> I really hope this does not turn into anti blockchain legislation.

What blockchain can become is as yet unseen. Additionally, many monied interests represent the third parties that blockchain is poised to disrupt.</comment>


Trump and Putin: The worst case scenario (2016) - <AUTHOR> https://qz.com/871436/donald-trump-nuclear-weapons-putin-and-trump-release-statements-that-hint-at-increased-nuclear-armament/ <comment><USER2> This will get flagged, but it's a decent article.

I've thought for a while that Trump is not Putin's puppet but rather a Putin wannabe. He's too egotistical to be anyone's puppet. His goal is to become America's effective dictator, eventually either rigging (like Putin) or abolishing the electoral process. A partnership with another totalitarian oligarch would be fitting and very helpful toward this goal.

If the thesis in this article is correct the target of such a partnership would likely be China and to a lesser extent Japan and the EU, since those are the only world powers who could challenge Russia or America.

There's an intellectual basis to it as well. Putin is purportedly a believer in many of the same ideas that one finds in America's alt-right: esoteric post-war fascism (search for Julius Evola) and neo-reaction / neo-feudalism. The end goal is probably more feudal than fascist, though the distinction is somewhat academic.

If such a scenario unfolded we'd end up with something like a planetary nobility.</comment>


The Max Headroom TV Hack - <AUTHOR> http://www.atlasobscura.com/articles/the-freakiest-tv-hack-of-the-1980s-max-headroom/ <comment><USER2> Hi there.

I'm the guy who did the AMA.

I don't think the guy who interviewed me from Atlas Obscura disclosed that he was from Atlas Obscura.. I thought he was some kid doing a high school paper or something. :) Meh. Oh well.

Anyway, he didn't get some of his terminology correct. I've directed him to how he can clean it up, however.

..."Churnalism" is spot-on.

<comment><USER3> Surely the statute of limitations on this has passed now and we can know who these legends really were? Perhaps encourage them to seek legal advice about revealing themselves.

<comment><USER4> I was going to reply indicating that criminal law has no Statute of Limitations but that seems to be a Canadian thing. In the US it has to be considered a "Heinous crime". I'm certain under modern light of what hacking has become they'd likely consider this relatively innocent event heinous by modern standards.

</comment></comment></comment><comment><USER5> That's great - and interesting that someone would react with "I got so upset that I wanted to bust the TV set" about it!

As this is an article about hacks, then I'll also point out that Max Headroom played the role of a "computer-generated television journalist", but there was nothing computer-generated about him at all... it was all prosthetics and makeup: even the "computer graphics" in the background were hand-drawn!

<comment><USER6> It was the same for the original TV series of The Hitchhiker's Guide to the Galaxy. They got enquiries about what computer system they used to make the graphics for the guide. They were all hand drawn.

Special effects were done manually until quite recently. Independence Day was probably the last big budget film to use models. Now it's all computer generated.

<comment><USER7>
        Independence Day was probably the last
        big budget film to use models. Now it's
        all computer generated.

[http://sploid.gizmodo.com/mad-max-fury-road-without-the- spec...](http://sploid.gizmodo.com/mad-max-fury-road-without-the-special- effects-is-still-1709358729)

</comment></comment></comment><comment> at-fates-hands There were quit a few articles on the 25th Anniversary back in 2012, but this article by Motherboard went into a lot more technical detail about how this was probably pulled off:

[http://motherboard.vice.com/read/headroom- hacker](http://motherboard.vice.com/read/headroom-hacker)

It also details other TV intrusions as well.

<comment><USER8> The Vice article appears to be the better source than the current link.

<comment><USER9> Indeed, the current link seems to just be Atlas Obscura engaging in some churnalism and regurgitating existing articles on the subject. Apropos of not much, the account that posted the current link a) is new, and b) has posted nothing but Atlas Obscura links thus far.

I also find it a bit strange that Atlas Obscura is even posting this, being that its modus operandi is stated as being "the definitive guide to the world's wondrous and curious places." Signal intrusion or the 80s aren't much of a "place" no matter how curious they are.

<comment><USER8> I guess the pool of the "curious places" seems not big enough for their appetite.

</comment></comment></comment></comment><comment><USER10> _" But 28 short years ago, the term [hacker] hardly existed–that is, until the Max Headroom Incident."_

That's blatantly incorrect. For example, the movie War Games (pretty mainstream, with Matthew Broderick) is from 1983.

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

<comment><USER2> This.

You are correct. Like I said -- There's some issues with accuracy in this guy's article, unfortunately.

By 1987, people were well aware of what hackers were. Not so much the details, but, the basic concept at least, was well known.

I'd say the term entered the public vocabulary by about 1982, with War Games.

Truth be told, hacking even garnered some of its own vocabulary from War Games. That's precisely where the "war"\- prefix of different discplines comes from, first wardialing, then wardriving. I'm sure there will be more. I'd love to see warfaxing catch on..that's an untapped goldmine of fun. :) I'm trying to think of what such programs were called (programs that searched a given block of lines within a given prefix for any modems set to auto-answer) before War Games. "Hunters", I think.

Cheeseball plot aside, as a movie, War Games is, in retrospect a surprisingly accurate portrayl of hacking at the time. The discovery process was slow, laborious, time-consuming, and produced craploads of paper. It was also done by the marginally social, quietly, in relative isolation from others, not as a group, or as the public team sport it is now.

The gear Broderick's character was using, even -- By 1982, a box like a toggle driven IMSAI 8080 with an 8" floppy drive and a monochrome monitor would have essentially been throw-away, garbage-quality gear.

High-quality systems are superfluous these days, but, for the longest time, most hacking, including back then, was done predominantly on discarded, semi- obsolete, well-worn gear, just as depicted in the film.

<comment><USER11> "Are you a _hacker_ , Kaz? Tsk tsk!" \-- Grade 9 Computer teacher, 1985.

That was because I had used the word in the _positive_ sense: hobbyist, tinkerer.

The hacker-versus-cracker quibble was already festering.

</comment></comment></comment><comment><USER12> You know if this thing were an everyday occurrence (not that I even watch TV) it would probably be annoying, but the nature of the Max Headroom broadcast intrusion was more comical than anything, and it's almost a shame that no one has done anything like it since. So long as the broadcast intrusion isn't violent, overly crude, or exceedingly long/disruptive I think it would really be interesting to witness something like this again (it's kind of amusing to think you might even make a sport of it, in very limited doses). Most of the time I understand why the FCC cracks down so hard on misuse of RF, but it's hard not to have a soft spot for this sort of gag.

<comment><USER13> >and it's almost a shame that no one has done anything like it since.

Well, technically this happens all the time with website hacks and what not. The problem is that the "culture" of hacking is a lot like taggers. Its an attempt to promote your group or brand. Its childish bragging.

While the Headroom hack was childish as well, it was also completely absurdist and didn't promote anything. I think its rare to see something like this where the hackers aren't pushing some agenda or self-promoting. From an aesthetic perspective it was pretty impressive. It really sells the idea of being creepy and mysterious.

As a nerdy Chicago tween at that time, this stuff was legendary. These guys became heroes on all the local BBS's and in the local geekdom. Man, I miss those days.

<comment><USER14> I think another big part of the "appeal" or notability comes from the fact that there were so few gatekeepers for information on par with TV and radio stations.

Nowadays you could probably get some attention, both positive and negative, from defacing the website of a huge company. Maybe if you got "Facebook" to show up as "Fuckbook" for thousands of users for 10-15 minutes or something. Otherwise, there are so many websites and we are so accustomed to having access to a sort of mass communication that the rarity and impact is diminished.

I remember being a kid in the 80's and a teen in the 90's and even then, I was blown away when I learned what public access TV was. The idea that you could actually get _on TV!!_ as a normal person and run a show seemed insane. TV was that thing that talked _at_ you. There were 13 channels for us frugal or less well-off families and there were maybe 50 or 60 for our luckier friends. Other than that, it was something out of reach.

We played with camcorders and tape decks, playing at being radio DJs or TV personalities but the idea of something like a Shoutcast station in the late 90's or a Youtube channel in the 2000's would have fried my tiny brain as a hyperactive, creative little kid.

So not only was someone subverting the technical systems of a big company but they were doing it to _TV_. At least to me, that was one of those larger than life things that took place elsewhere and the rest of us just watched. Co- opting a TV broadcast was like getting the policeman's mythical "master key" or sneaking into the White House.

</comment></comment></comment><comment><USER15> I think my favourite (rather savage) line from the series was in the Xmas special which went along the lines of "Whether you're busy hanging decorations in London, or busy being decorated for a hanging in the Philippines - it's Christmas!".

</comment><comment><USER16> I love how enamored the HN audience is with Max Headroom. This is the 9th submission in the past 5 years: [https://hn.algolia.com/?query=max%20headroom&sort=byDate&pre...](https://hn.algolia.com/?query=max%20headroom&sort=byDate&prefix&page=0&dateRange=all&type=story)

The submission rate is almost exponential. Also goes to show how easy it is to churn out interesting articles by digging into the HN archives and picking up forgotten stories.

<comment><USER17> I think "enamored" is a strange word to use here. I would classify nine submissions in five years to HN as barely a passing interest.

<comment><USER18> Agreed. This is what "enamored" looks like: [https://hn.algolia.com/?query=elon%20musk&sort=byDate&prefix...](https://hn.algolia.com/?query=elon%20musk&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

<comment><USER19> Or: [https://hn.algolia.com/?query=framework&sort=byDate&prefix=f...](https://hn.algolia.com/?query=framework&sort=byDate&prefix=false&page=0&dateRange=all&type=story)

</comment></comment></comment></comment><comment><USER20> > The audiences subjected to the Max Headroom intrusion were deeply perturbed > by what they saw.

Once was amusing and intriguing. If it happened all the time, I'd get annoyed. Especially if they continued to interrupt Dr. Who.

<comment><USER21> Exactly. Most TV you can interrupt to your hearts content for all I care... but DO. NOT. FUCK. WITH. DOCTOR. WHO!!!

</comment></comment><comment><USER22> I remember watching him, but my favorite memory was when my project lead #defined a table size as 'MAX_HEADROOM'.

</comment><comment><USER23> Around the same time this happened:

[http://www.macdougallelect.com/bio.html](http://www.macdougallelect.com/bio.html)

I remember because I think he want to WPI.

Edit: more here: [http://www.skepticfiles.org/cowtext/100/captmidn.htm](http://www.skepticfiles.org/cowtext/100/captmidn.htm)

</comment><comment><USER24> Someone on reddit who claims to have known who was behind it - [https://www.reddit.com/comments/eeb6e/i_believe_i_know_who_w...](https://www.reddit.com/comments/eeb6e/i_believe_i_know_who_was_behind_the_max_headroom/)

<comment><USER25> He's on this here thread now.

<comment><USER2> Hi. :)

</comment></comment></comment><comment><USER26> Previous discussions: [https://hn.algolia.com/?query=max%20headroom&sort=byPopulari...](https://hn.algolia.com/?query=max%20headroom&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

</comment><comment><USER27> Whereas my favourite memory of this icon is the Art of Noise's Paranomia track, featuring Max Headroom:

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

</comment><comment><USER28> Here's a bit I had forgotten about: an "appearance" on Letterman in advance of the TV show in the U.S.: [https://www.youtube.com/watch?v=eoqMSr1H1ek](https://www.youtube.com/watch?v=eoqMSr1H1ek)

</comment><comment><USER29> I've read about this and watched all the clips multiple times. It's really interesting and I'd love to see more stories like this.

<comment><USER30> In 2007 a Czech art group hacked a webcam and incorporated a nuclear explosion at the location it monitored. It later got showed on a weather news segment.

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

[https://en.wikipedia.org/wiki/Ztohoven#The_Media_Reality](https://en.wikipedia.org/wiki/Ztohoven#The_Media_Reality)

</comment></comment><comment><USER31> I have found myself wondering lately if the amount of trolling and such have been on the rise ever since anonymous got attention.

Kinda like people have picked up the activities, ignore the goals, and are "cargo cult"-ing it into the ground.

<comment><USER14> I think that as the tools for intrusion and defacing have gotten more common and easier to use, you get a lot more low grade trolling.

Like you have a million schoolkids writing dirty limericks on the bathroom walls for every real-life "Turk 182".

</comment></comment><comment><USER32> I love a good public freakout. This is classic.

<comment><USER2> Agreed. It's almost...accidentally perfect.

I mean, considering:

1) The video cuts out -precisely- at the point in Dr. Who where the guy says "A massive electric shock -- he must have died instantly!" ...probably accidental, but just perfect..lol

2) The block of shows on WTTW (Channel 11) on Sunday night were often very, very avant-garde in content. To be able to take it to an entirely higher level like that, against the backdrop of already weird stuff...thats just priceless..

3) The fact that the public was split between those who found it hilarious, and those who found it frightening... what more could you ask for?

As a hack, with all its warts and confusion, it's a triple axle quadruple salcow kind of performance. :)

BTW, speaking of weird -- I've been asked on occasion, how weird. Check this out:

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

This is "The Shivering Man". There was a show that aired late nights on Channel 11 at the time, called Image Union.. Image Union was sort of a showcase for short subject amateur/experimental/avant-garde films and videos. It was on the air about maybe half an hour or an hour after Doctor Who every sunday night, and usually ended the scheduled broadcast day.

One of the films that aired on Image Union around that time (1987-1989 or so) was "The Shivering Man". Here, you've got a ballet dancer in a red dress jumping around guy covered in talcum powder having a conniption fit/seizure, followed up by a fat bald guy in a chair who, uh, suggestively..sprinkles.. when the chair is shaken..lol..

Tame by internet standards, but totally WTF-worthy by late 80's Chicago public television standards. By running this sort of stuff, they were all but inviting a visit from Max, if you ask me. Weird attracts weird.

</comment></comment><comment><USER33> I'm sure that's a fine article, but so much crap kept popping over it as I tried to read it on my phone I gave up.

Later, maybe - on my rooted tablet, with adblock etc..

</comment><comment><USER34> This incident is the origin of my username.

</comment><comment><USER35> I didn't actually witness this broadcast, but I remember other kids talking about it at school on Monday morning.

</comment><comment><USER36> Which eventually became a Coke commercial with Matt Frewer who went on to play a doctor in "Dr. Doctor, Dr. Doctor" an uproariously funny TV series on CBS.

<comment><USER37> You've got it backwards. This hack was referencing the previously-existing Max Headroom TV show, commercial, etc.

<comment><USER36> Yes but that doesn't change anything about what I said.

</comment></comment></comment><comment><USER38> Max Headroom was indeed once a revolutionary, subversive figure. But then he sold out to the man and starting pimping Coke. [https://www.youtube.com/watch?v=Wgm5GUo8o7I](https://www.youtube.com/watch?v=Wgm5GUo8o7I)

<comment><USER39> Perhaps Coke is secretly revolutionary and subversive, and Max Headroom was giving us all a subtle hint?

</comment></comment><comment><USER40> In case you've never seen it, and to save some the YouTube search, here's the crazy Max Headroom hack video with subtitles:

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

<comment><USER41> This is the same video from the article itself.</comment></comment>


Working Remote Is Awesome - <AUTHOR> https://danschnau.com/blog/working_remote_is_awesome <comment><USER2> In terms of remote work, only one thing matters — work! This is amazing because the ordinary question "What have you done today?" replaces many others such as: "What time did you come?", "Why are you late?", "What did you do today?", and so on. Teamwork becomes result oriented, not process oriented.</comment>


TAE says net power from fusion in two years, commercialization in five - <AUTHOR> https://www.forbes.com/sites/jeffmcmahon/2019/01/14/private-firm-will-bring-fusion-reactor-to-market-within-five-years-ceo-says/#5a0824fa1d4a <comment><AUTHOR> A couple years ago I was in a meeting that had someone from Tri Alpha. At that point they'd proven plasma stability, and said they had one more hurdle, which was to see if the plasma stayed stable as they ramped up the temperature. Their model said it would but they hadn't tested it, and were only at 10M degrees so far. They were building a new reactor that would would work at 100M degrees.

He said if that worked out, they had no more unknowns, all they had to do after that is increase the temperature more and that was easy, just add more heating. There'd be no more barriers to commercialization.

I guess it worked out.

Their first net-power reactor will be D-T fusion. With the boron fusion they're ultimately shooting for, there's an insignificant amount of neutron radiation, and they won't need a turbine to extract energy, which will be mostly in the form of fast-moving charged particles. That would make it a very cheap and practical reactor.

</comment><comment><USER2> I really hope it turns out to be true and not hyperbole inspired by more prosaic motives. It would be something if the world's energy problems were solved not by the billions invested by the establishment but instead by the investment of a soap opera star!

Mind you based on their claimed timetable shouldn't Lockheed be producing a working prototype about now?

<comment><AUTHOR> Yes, but when Lockheed made that claim they were just getting started with fusion, and their experiment used about as much energy as a light bulb. They revealed very little about their design.

TAE has the largest fusion reactor in the U.S. They've been at this for 20 years, present at fusion conferences, and get papers published in serious journals. They achieved stable plasma several years ago.

The actor was one of their earliest investors, but others have included Paul Allen, Goldman Sachs, and the Rockefellers, totaling $700 million so far.

</comment></comment><comment><USER3> Isn't it traditional for fusion energy to be 10 years out?

Why did Forbes break with tradition?

<comment><USER2> Well in only a week they have already corrected the artical to add a year or two so we are catching up fast...</comment></comment>


Decades after Chernobyl disaster, engineers slide high-tech shelter over reactor - <AUTHOR> http://arstechnica.com/science/2016/11/decades-after-chernobyl-disaster-engineers-slide-high-tech-shelter-over-reactor/ <comment><USER2> 30 years later, what a project: "More than 40 governments have contributed to funding its construction (€1.5 billion), which involved 10,000 workers."

</comment><comment><AUTHOR> I was really impressed that it was slid on rails into place instead of being assembled in place in sections.</comment>


Quaternion rotation explained for artists - <AUTHOR> https://www.youtube.com/watch?v=4mXL751ko0w <comment><AUTHOR> From the the /r/gamedev thread "The first video that has intuitively explained quaternions to me."

[https://www.reddit.com/r/gamedev/comments/4wnd54/the_first_v...](https://www.reddit.com/r/gamedev/comments/4wnd54/the_first_video_that_has_intuitively_explained/)</comment>


12 Best Practices for UX in an Agile Environment - Part 1 - <AUTHOR> http://www.uie.com/articles/best_practices/

<comment><USER2> so...you're splitting the 12 practices into multiple posts?

<comment><USER3> That's "UX in an Agile Environment" in action!</comment></comment>


Are people happy when they fail? - <AUTHOR> http://www.stepanp.com/?p=387

<comment><USER2> I think this makes it simplistic- as an entrepreneur running a growing startup I HATED my failures. I previously ran a startup that didn't make it and I was miserable for a long time...it's hard to accept defeat.

In the digital ecosystem we celebrate failure because if you've never failed, you've never tried. You have to be willing to take the risk and put yourself out there.

The best entrepreneurs I know have also failed- it is very, very rare to hit a homerun the first time out. The article says maybe we should celebrate completing something but a failure is that- a failure to complete the plans for the startup. You didn't complete it, you failed.

And once you fail you can either give up and go back to corporate America with its fake veil of security or you can brush yourself off and start over

</comment><comment><USER3> I mean, it's great to fail and learn from it, but I don't really agree with

" I think failure has began to be applauded by everyone. Entrepeneurs are starting to be happy when they fail"

Nobody is HAPPY when they fail. It's just something they have to learn from. It's something they CAN learn from, but that doesn't mean they necessarily will. Some people hit a road block and rather than overcome, they just blog about how hard it is. They don't learn, they pretend and cheat their way through. I'm not implying that submitter is doing this, though. I think the industry is learning that it's good to learn from failure, but people need to learn how to do that first.

To be perfectly honest, when I fail, or my projects have to get pushed back because I couldn't finish on time, I don't feel like I'm learning. I feel like shit and just drink. The next day, I go to work same as every day and put my all into it.

In my opinion, it's not about working hard, or necessarily finishing things, or any of that. It's about setting aside all the bullshit and excuses and doing something you decided you were going to do. That ties back to finishing things I suppose, but not in the sense that a complete project is all that matters.

Ya got me ramblin'!</comment>


Liquid glass: the spray-on scientific revelation - <AUTHOR> http://www.telegraph.co.uk/science/science-news/7125556/Liquid-glass-the-spray-on-scientific-revelation.html

<comment><USER2> _The spray, which is harmless to the environment,_

The first thing I think when I read something like that is "how many years until they regret saying that?"

<comment><USER3> It's just silicon dioxide, same as sand; the innovation here is is to liquefy and suspend it so it can form a layer rather than crystallize (looking at the product datasheets, it has a shelf life and is best within 6 months of manufacture - after which, I presume, it begins to crystallize or the SiO2 molecules begin to fall out of solution.

<comment><USER4> "Just" silicon dioxide? Ever heard of the irreversible lung disease, silicosis? <http://en.wikipedia.org/wiki/Silicosis>

<comment><USER3> It's in solution in water or alcohol and applied by spray and evaporation, not airborne as dry particles. I'd guess this risk is quite manageable. Germany isn't exactly a hotbed of environmental abuse.

<comment><USER5> The press releases mention it's available on the consumer level in Germany. Does anyone know the brand name and/or distributor?

<comment><USER3> Nanopool, it's in the article. I don't think they have a US distributor. I wrote and inquired about it, if I lern anything interesting I'll post it.

<comment><USER5> I'm going to be in Germany in the summer, I was curious if anyone knew where to purchase it there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Sounds like a fairy tale? Any experts here want to chime in on whether airborne silicone dioxide is really as harmless and versatile as they claim?

<comment><USER7> There are so many stories in non-technical media that make you question whether or not they're pure fantasy. The only technical area I have advanced knowledge of is software programming, and often when I read media stories where that knowledge is relevant it's really cringe-worthy. I can imagine an engineer at this company reading this and thinking, "well, not quite..."

<comment><USER8> nice, you sidestepped the Gell-Mann Amnesia Effect

</comment></comment></comment><comment><USER9> I don't get it. You're spraying a surface with tiny particles of glass, right? So how would they form a cohesive layer, instead of sitting on top like loose sand, to be brushed off (or ground into the surface) by the first thing that touches them? Coating something in actual glass requires melting it and letting it harden into interlocking structures, right?

Sounds like snake oil to me.

<comment><USER10> Nah. There are all sorts of ways to suspend glass microparticles and a binder in some kind of solvent that evaporates after spraying, leaving a glass- particle-and-binder layer behind. The physics/chemistry of it are pretty easy (for those so inclined). What's probably hard is making the deposited layer durable and non-toxic. For example, if the glass microparticles turn into aerosolized dust then you probably don't want to do a lot of breathing anywhere nearby; think asbestos and cigarettes.

</comment></comment><comment><USER11> This sounds like sodium silicate (or a similar silicate salt), a water soluble material that has long been used as a surface sealant. It is widely used to protect concrete surfaces. Chemical toxicity is minimal. Silicosis should not be a problem as long as the material remains reasonably soluble after application -- it will self-dissolve in the body.

<http://en.wikipedia.org/wiki/Sodium_silicate></comment>


Facebook VCs: We're Investing in Facebook Apps Too - <AUTHOR> http://www.insidefacebook.com/2007/07/11/facebook-vc-were-investing-in-facebook-apps-too/ They're promoting and "investing" into Facebook apps because they're major investors in Facebook and will benefit from Facebook IPO. More apps, bigger the IPO?!<p>In any case, it has nothing to do with them wanting YOU to succeed. <comment><AUTHOR> They're promoting and "investing" into Facebook apps because they're major investors in Facebook and will benefit from Facebook IPO. More apps, bigger the IPO!

In any case, it has nothing to do with them wanting YOU to succeed.

<comment><USER2> I'm also slightly amazed at the willingness of developers to create apps for the Facebook platform, since it's closed and controlled by a single corporate entity.

Have people forgotten (or are too young to remember) the days when MS completely dominated the development platform, and the economic consequences for 3rd party software companies?

The web app revolution is _supposed_ to be all about breaking out of that pattern (which is why MS fought Netscape so hard).</comment></comment>


Deep linking in React Native - <AUTHOR> https://arsfutura.co/magazine/deep-linking-in-react-native <comment><USER2> I always thought "deep linking" was the dumbest phrase, definitely for websites, maybe less so for SPAs.

It's just "linking"!! And it should be trivial to implement.

<comment><USER3> "Linking" is already used to describe both object file linking (which is unrelated to deep linking) and html anchor linking (which is related to but different from mobile app deep linking). If you want a generic term, one can of course use the word linking to refer to deep linking, but it's often valuable to have a more specialized term that distinguishes links to functionality in mobile apps from links to anchors in web pages.

<comment><USER4> In HTML, "linking" is a contraction of "hyperlinking". I guess deep linking and hyperlinking have a significant cross-over, maybe to the point where it's not a useful distinction?

<comment><USER3> Flat head screws and pan head screws have similar cross-over in that both are screws. To someone who thinks assembling IKEA cabinets counts as woodworking, the term screw is enough. To someone involved in actual manufacturing, the more specialized terminology remains important. Specialists will always have reason to use more precise language than generalists.

</comment></comment></comment></comment><comment><USER5> Very cryptic rejection of Universal Links in the final paragraph here... anyone know what they're talking about?

> However, I would not really recommend implementing support for this in your > React Native app. It can bring potential complications and not-so-many > benefits for a React Native app.

<comment><AUTHOR> There are a few reasons I would recommend deep linking over implementing support for universal link into your app. Firstly, universal links are somewhat more complicated to set up than classic deep links and might make the development process more difficult. Their functionality is also somewhat similar to deep links. Secondly, they only work for iOS which cuts the number of viable users by a significant amount. Generally speaking, I would recommend implementing universal links after your system of deep links is constructed, in case you want to invest extra effort into your iOS application. Overall, it is definitely not an unuseful feature, I would just prefer deep linking for React Native.</comment></comment>


Why a CS Degree Is Better Than Teaching Yourself How to Code - <AUTHOR> https://zeroequalsfalse.press/posts/cs-degree-over-self-study/ <comment><USER2> At least in Germany, even if you are pursuing a CS degree at an university, you are supposed to teach yourself how to code anyway. Hence it makes more sense to get an degree in mathematics or physics, which have much higher prestige than computer science.</comment>