Google says Nest's built-in mic not listed in specs was not meant to be secret - <AUTHOR> https://www.businessinsider.com/nest-microphone-was-never-supposed-to-be-a-secret-2019-2 <comment><USER2> Having worked at large companies before, I'm almost certain that more than one person working on the product raised the point "this has a microphone, why isn't it documented?" or "this has privacy implications", but was silenced.

(Or it could be that everyone working at Google has been carefully chosen to not have such concerns; I do get that feeling sometimes too.)

<comment><USER3> Contrast this to Amazon: during design of the original Echo at Lab126, an engineering discussion took place where they determined that implementing the mute function in software would be less expensive in terms of component requirements than implementing a physical disconnect of the mic circuit.

The engineering team refused to take the less expensive route, and insisted that the mute button physically disconnect the circuit, so that no future engineering team could decide to stealth "unmute" the microphone through software.

To this day, you can disassemble an Amazon Echo device and you will find a physical disconnect of the mic circuitry when you push the mute button. Don't want an "always listening" smart speaker? Just keep it muted, and a red LED circle informs you that the mic is physically disconnected.

I'm proud of the approach that Amazon takes to privacy. Privacy of customer data is considered the most important thing to Amazon, and this customer obsession (the #1 leadership principle) permeates the organization.

Disclaimer: I'm a principal engineer at Amazon.

<comment><USER4> In this story, it was only _lower-level_ engineers that took a stand for user privacy. It was them against everyone above them at Amazon. Doesn't sound like Amazon-the-company deserves credit.

Update to clarify reasons for this characterization: Parent used the words "refused" and "insisted," which strongly suggest conflict between the pro- privacy engineers and others at Amazon involved in the project. And "so that no future engineering team could decide to stealth 'unmute'" suggests a lack of trust in long-term company management. Nothing in this story supports the later statement that "Privacy of customer data is considered the most important thing to Amazon."

<comment><USER3> The company fully backed their decision. They did not have to fight anyone.

This type of product design decision happens all the time. Whenever you're considering component costs, you have to evaluate all of the options. You're mischaracterizing it as a fight between engineers and management.

</comment></comment></comment></comment><comment><USER5> Oh wow, this is amazing. There's been a lawsuit in court about someone in Germany who sued their landlord because the landlord has put a Google Nest fire alarm into their flat against their will, ignoring offers by the renter to put in a non-google-non-iot fire alarm at the renter's expense. The landlord won because apparently the court was not convinced that the fire alarm could spy on conversations [1]... What would have happened if Google had secretly put a microphone into their fire alarms as well, not just their home security system?

[1]: [https://www.bundesverfassungsgericht.de/SharedDocs/Entscheid...](https://www.bundesverfassungsgericht.de/SharedDocs/Entscheidungen/DE/2015/12/rk20151208_1bvr292115.html)

<comment><USER6> > What would have happened if Google had secretly put a microphone into their > fire alarms as well, not just their home security system?

You could have found it by dismantling the device and the renter would have won their case against the landlord.

<comment><USER7> I hope you all know that Nest fire alarm aka Nest Protect v2 features microphone for automatic sound (health) checks.

<comment><USER8> Yeah so the nest protect is, when you look at it objectively, a ceiling mounted general purpose remote sensing package. It's basically only lacking a wide angle camera and I suspect that's because they figured it would cross too far into "creepy" for it to be saleable.

It seems to me like a team sat for a while, looked at all the possible ways they could get people to mount a package like this in every room and settled on calling it a smoke alarm.

At the most optimistic they started with a smoke alarm and gradually realised they could build a general purpose platform based on the hardware being deployed in lots of rooms and many types of sensors being dirt cheap now.

Decided they could enable new capabilities (and data goldmines!) in software later.

It's a pity there's not an actually customer controlled version of it.

<comment><USER7> Are there any alternatives to nest protect that would: Sense Carbon Monoxyde AND smoke AND fire off some event to mobile phone via wifi/sms/whatever?

<comment><USER9> There's the first alert onelink. May have the same issues though, it has a microphone and an alexa integration. Also support homekit, unlike the Nest Protect.

Are there any best practices for using a device like this but not having it communicate with the wider world? I.e. It can communicate with you via a homekit hub, but can't connect outside your LAN

[https://onelink.firstalert.com/withalexa/](https://onelink.firstalert.com/withalexa/)

</comment></comment></comment></comment></comment></comment><comment><USER10> Infosec dramas are getting more and more tiresome. Between this and the Singapore Airlines story, it just seems like people need to ratchet everything up to 11.

You have two options, choose one:

\- 1. Google wants to spy on you with a hidden mic

\- 2. They had future plans for the mic, but it was disabled, so it wasn't mentioned by the marketing department

For the Singapore Airlines story, you have two options, choose one:

\- 1. Singapore Airlines wants to record you

\- 2. The infotainment devices in the seats are just off the shelf Android devices

One option gets you lots of clicks and let's the infosec drama crowd tweet obnoxious things and sound insightful. The other is the pretty obvious explanation.

<comment><USER11> For Google, I'm not sure how option 2 is supposed to be acceptable either. It is perfectly reasonable to be concerned about introducing an internet- connected microphone into your house. It doesn't even require assuming a malicious Google to see potential problems with this. You're one decent security flaw (in an IoT device no less) from anybody having a microphone in your house.

<comment><USER5> > You're one decent security flaw (in an IoT device no less) from anybody > having a microphone in your house.

Many people already have Android smartphones, so there is already a Google microphone in your house. The big difference is that you _know_ that it has a microphone.

<comment><USER12> The smartphone requires a battery, which drains away noticeably if it is sending all your conversations. The Nest is connected to the house power, so it can stream audio non-stop.

<comment><USER13> Are you sure about that battery drain?

A malicious actor could easily conceal their activity by making 24-hour-long recordings and sending them in the night (or whenever connected to WiFi and plugged into power).

<comment><USER14> The main trick smartphones use to have their battery last long enough, is to power off every piece of hardware that's not in use, for as long as possible. Doing a 24-hour-long recording would require the main CPU to be awake far more often than usual (and in fact, I would suspect it would have to be pretty much constantly awake, unless the phone had a large dedicated hardware buffer for the recorded audio samples).

</comment></comment></comment></comment></comment></comment><comment><USER15> One would have thought that in post-Snowden world, such reassurances would be completely unacceptable. Yet many people even here are dismissing the case with the "conspiracy" catch-all label.

<comment><USER16> If there's one thing we've learned from post-Snowden world, it's that most people don't care enough to dodge the surveillance because most people didn't respond by voluntarily throwing out all their computing devices, smartphones, ISP service plans, etc.

<comment><USER17> Another thing we've learned from the post-Snowden world is that people invoke the post-Snowden world as an excuse to abandon critical thinking and skepticism and assume all conspiracies are valid, and often don't actually understand what, specifically, Snowden did and didn't demonstrate. People still believe the PRISM program was about companies giving the NSA direct and unlimited backdoor access to their databases, and that every logo on a single slide is more or less an NSA front.

It's a similar phenomenon to the "post-Hilary" world of the Wikileaks email docs. People assume there was hard evidence proving a criminal conspiracy by the DNC to rig the election _somewhere_ in there... mostly because that's what other people told them. Not because they've bothered to look.

People's cynicism has led them to put more trust in the metafictional reality of leaks than actual reality. Which, ironically, makes them easier to manipulate even as they believe themselves to be somehow above indoctrination and control having reached enlightenment through the "Snowden revelations."

<comment><USER18> My take away from the Snowden leaks was basically non-technical and simply an appreciation for how public-private partnerships have assembled a new sort of surveillance industrial complex. One which resembles the military industrial complex and may in the future even replace it? It felt like a warning along the lines of Eisenhower and even Snowden's role as a whistle blowing contractor felt symbolic of our government's diminished role in it all.

Would you consider that as misguided? It certainly encourages a general distrust of all those company logos in the slides.

<comment><USER17> I would consider it misguided to assume that one can determine whom to trust and whom not to trust based on whether or not their logo appeared on a slide leaked onto the internet, yes. I would also consider it misguided to implicitly believe stories that conform to any particular ideological bias, because misinformation, manipulation and deception can take place everywhere.

It leads to things like people implicitly trusting DDG because they weren't on the PRISM slide, or implicitly trusting Facebook and Reddit because they aren't the "mainstream media."

</comment></comment></comment></comment></comment><comment><USER19> > It also said the microphone was originally included in the Nest Guard for > the possibility of adding new security features down the line, like the > ability to detect broken glass.

Detecting broken glass with a microphone? Does the device even have enough CPU power (and RAM) to add advanced advanced audio processing features? Or was this going to upload the audio to Google's servers to do the work? If it's the latter, that would necessarily[1] require uploading audio _without_ a wake- word trigger.

Either they just admitted to wanting always on microphones in the home, or they are blatantly ling about why the microphone hardware was included. Designing hardware for a large market usually involves a _lot_ of value engineering to reduce the number of parts or replace a feature that requires expensive parts with a functionally similar design that is cheaper. Saving $0.01 (or less) by removing an optional resistor doesn't sound like a lot, but it adds up if you're selling >100k units. A microphone is _much_ more expensive[2]. A part that costs $0.366 (or more[3]?) needs a good reason to be included, and "for the possibility of new features" isn't good enough. So what was the _real_ intended use that justified including a moderatly expensive part?

[1] The robber about to break your window isn't going to call out "Ok, Google" first so the Nest Guard knows it can upload an audio clip.

[2] [https://www.mouser.com/Electromechanical/Audio- Devices/Micro...](https://www.mouser.com/Electromechanical/Audio- Devices/Microphones/_/N-awp4b/?Ns=Pricing|0)

[3] $0.366 when buying >10,000. Up to $0.75 in lower quantities. (prices from a random example: [https://www.mouser.com/ProductDetail/DB- Unlimited/MO064402-4...](https://www.mouser.com/ProductDetail/DB- Unlimited/MO064402-4?qs=sGAEpiMZZMtcsMZaWNSquyIpiU55CdOlgUxGjuk%2fltGvCULOk0lGsA%3d%3d) )

<comment><USER20> You don't need "advanced audio processing" to detect a glass window breaking because it is loud, and has a distinctive spectrogram. It's a lot easier to detect glass breaking than a wake word, and you can buy standalone acoustic glass break sensors for under $30.

[1] [https://www.amazon.com/Honeywell-Intellisense- FG-1625-Acoust...](https://www.amazon.com/Honeywell-Intellisense- FG-1625-Acoustic-Glassbreak/dp/B003V1BGT4)

<comment><USER19> Ok, so it could at least plausibly have been local processing. I haven't been able to find out what kind of CPU/etc is in the device, and most of the features would have been easy to implement on the almost any hardware. It would have been even stranger to _also_ include a powerful (expensive) CPU to do a bunch of audio processing, but if there are techniques that work on $30 devices, that opens up a much broader range of cheaper hardware.

(I still think it's insane that the bean counters and value engineers let them include a microphone that wasn't needed.)

<comment><USER21> > I still think it's insane that the bean counters and value engineers let > them include a microphone that wasn't needed.

Having worked on hardware products, the features planned sometimes (even often!) change _after_ the hardware has been prototyped and an initial production order has been placed. It is cheaper to simply not ship the feature than it is to change the board.

Many in this comment section do not really seem to have much experience with hardware. It is fairly common for products to ship with unused hardware and it much more believable than malicious intent, especially given how disorganized Google is internally.

</comment></comment></comment></comment><comment><USER22> What never ceases to amaze me, is the absolute inability of companies like google to understand what their actions look like for somebody who is concerned about privacy.

Maybe they understand and do not care, because there are many vocal critics. But having a microphone in a product and not disclosing it? If not even google can keep track of what they _should_ tell us, how on earth do they think they deserve trust?

<comment><USER23> who's "concerned about their privacy" and why?

<comment><USER22> Privacy is a important factor in the stability of free democratic societies.

Today we have a asymmetry of transparency: institutions and companies are intransparent while the individual isn't. This assymetry in information translates into an asymmetry of power.

The traditional way citizen of free societies dealt with asymmetries of power was to divide them.

A government could easily sentence and jail anybody if it weren't for some strangely roundabout rules that made this hard.

The privacy movement is part of a powerplay between individuals and entities that go beyond single persons.

Of course you also have those who think it is about their dick pics..

</comment></comment></comment><comment><USER24> It's really sad to see companies like google buy companies like nest, or more recently amazon and eero. These little companies build fantastic devices, then the companies get acquired and the elegant products get mutated to serve their new owners. Finally a new player enters the market and the cycle continues.

<comment><USER25> What's sad is that those companies accept. I have been offeredd job interviews at google and facebook and politely refused.

Yes, millions are a much bigger temptation, but you still have a choice. In the hand, either they decided those companies where matching their ethics, or they gave up on ethics for money.

Given our entreprenarial culture, is that surprising ?

<comment><USER26> Often, the offer is much harder to pass. "We will buy you or we will build a better you and destroy your business" \- it's not just a money offer to refuse when you think about it. Part of the decision process is also the feeling that a huge company wants to enter the market with the same product. Can you compete?

<comment><USER27> An example that went the other way? Snapchat. Facebook just made their own.

</comment></comment></comment></comment><comment><USER28> It wasn't listed in tech specs, but it was never hidden or kept secret. It probably could have been more explicitly detailed, but in the FAQs for the Nest Secure it even tells the user:

> Can Nest Secure detect breaking glass? No. We're working on bringing glass > break detection to Nest Guard, the main hub of Nest Secure. Nest Detect, the > open/close motion sensor, doesn't have a microphone, so it can't detect > breaking glass. But its motion sensors can detect movement by intruders as > well as when a door or window opens and closes depending on how it's > installed.

[https://nest.com/support/article/Frequently-asked- questions-...](https://nest.com/support/article/Frequently-asked-questions- about-Nest-Secure#secure-glass)

This was listed before this big announcement.

</comment><comment><USER29> Fun fact: any device with a speaker can be turned into a microphone because a speaker is fundamentally the same thing as a microphone (a membrane connected to a coil/magnet).

<comment><USER30> Yes, any speaker can become a mic, but only if you plug it into an amp's input channel. Unfortunately for the CIA, they're all plugged into _output_ channels.

<comment><USER31> input and output channels are not always physically different pins, sometimes it's just a software configuration. see [https://news.ycombinator.com/item?id=13014435](https://news.ycombinator.com/item?id=13014435)

</comment></comment></comment><comment><USER32> I wonder if Singapore Airlines has something new to say about the cameras in their IFE system?

[https://twitter.com/vkamluk/status/1097008518685573120](https://twitter.com/vkamluk/status/1097008518685573120)

<comment><USER33> Of all places to 'spy' on folks, on a cramped airplane seems like the worst. Most people will be 1) asleep, 2) pissed off, 3) eating shitty food, 4) watching bad movies. It's likely that they decided to shove in some cheap android tablets that someone else sold them. It's unlikely that they are actively watching everyone, though the possibility of them switching on the camera to watch/record you shifting in your seat to get away from your neighbor trying to use your shoulder as a pillow is always there.

<comment><USER34> I used to go to a gym where the exercise machines all had Windows tablets built in. They all had a camera and Skype installed. I'm still curious who ever wants to Skype all sweaty during an exercise, but probably the same person who wants to Skype on an airplane.

<comment><USER2> _I 'm still curious who ever wants to Skype all sweaty during an exercise_

Maybe a variation of this old meme might help explain: "The great thing about going to the gym isn't exercising, it's showing everyone online that you did."

</comment></comment></comment></comment><comment><USER35> I love Google for the service values they provide, but if this were to come from another company then I might have believed it was in fact an error.

Privacy has always been an important factor when people consider any Google products, and they are fully aware of that so this topic must have always been on their list of priorities. For a company like Google with rigorous testing/approving processes in place before a product is even launched, to come back and say that it was an accident is pretty hilarious, though realistically what else could they have said?

I still like them. It's a love-hate relationship, we have passed the denial phase and entered the acceptance stage long time ago.

<comment><USER36> Why does Google get a pass? They're an advertising company, and listening to conversations is _very_ relevant to that business model.

In fact, I think it's _more_ plausible that this entire foray into IOT is to collect even more data for use in advertising (e.g. get more microphones in more places). Why else would an advertising company get into such a wide array of businesses?

Yes, their products are convenient and typically get good QA testing, but there's still no way I'll be convinced that they're not trying to get as much data as possible to contribute to their core advertising business.

</comment></comment><comment><USER37> And if they later activated the microphones through a software update and didn't tell anyone, I guess that would be an "error," too.

</comment><comment><USER38> Mods,

Can you change the title to say "Nest Gaurd's", because this has nothing to do with the Nest Thermostat, which is called, "Nest".

<comment><USER39> Yeah, I was worried it was the thermostat too. Hopefully that day will NOT come when they tell us all their products have microphones in them.

</comment></comment><comment><USER40> Will they recall the product or offer a replacement without the mic? If not, they are not sorry, the breaking glass claim is false and this invasion of privacy was always the intent.

</comment><comment><USER41> This thread has been comprehensively derailed and is an embarrassment to informed discussion. Imagine if a major Chinese firm had 'forgot' to document a microphone, how many people here would be making excuses? This is an astonishing reflection of the quality of technical discussion.

Anyone who is even remotely familiar with hardware design will know this cannot be an accident in any way and form. It's there because its designed to be there. The fact that its not documented takes it firmly in the territory of extreme malice and dystopic surveillance unconstrained by any ethical concerns.

The only folks for whom this is not a concern are those unburdened by any sense of societal or ethical concern. They represent those sections of the tech community who have zero compass or qualms and do not see any problem building a toxic dystopic society.

</comment><comment><USER42> Literally, "Oh, we're sorry. We thought it was obvious we were spying on you by now". Guess their conditioning program isn't yet complete...

<comment><USER16> When a person hires a personal assistant, the person doesn't generally turn around and accuse the assistant of spying on them because the assistant listens too attentively.

<comment><USER42> The Nest is not a personal assistant like the Google Home. It's a thermostat.

<comment><USER28> The microphone is not part of the Nest thermostat, it's only part of the Nest Secure, the keypad which is included as part of the Nest Guard.

</comment></comment></comment></comment><comment><USER43> And most of the rich people in my neighborhood have complete voice devices in their homes, Amazon's device and Google's I refuse to have these devices in my home regardless of how cool they seem.

<comment><USER44> What event down the road do you think will vindicate your decision? How do you think your neighbors will be harmed?

<comment><USER45> Some people have no problem putting a little webcam in their toilet bowl so that the world can watch them eliminate every morning. Personally I prefer to keep my business private. I don't need any "vindication" to be happy with my decision to protect my privacy. If you don't understand the value of privacy nobody can explain it to you - but they may watch your morning broadcasts.

<comment><USER44> You don't see any difference between people getting a Google-connected device (like a Google Home or Pixel phone) and those that install a public webcam in their bathroom?

<comment><USER45> The Google-connected monitoring device is arguable much more intrusive.

<comment><USER44> It's almost as bad as a smartphone with Google's software installed.

</comment></comment></comment></comment></comment></comment><comment><USER46> Now I'm going to have to take my Google Wifi points apart to check for "forgotten" microphones

<comment><USER47> If you've got Google wifi points in my opinion you're simply inviting them to spy on you anyway.

</comment></comment><comment><USER48> At the bare minimum Google should offer a full refund for those who bought a Nest Guard. This could be covered under the breach of implied warranty of "fitness for particular purpose", where the purpose is "to purchase a device and having a reasonable expectation of being free from surveillance".

</comment><comment><USER49> Placing an inactive mic does raise questions naturally but shipping updates to hardware is not easy/possible. So you'd want to future proof your hardware throughout its lifetime. Had Google announced in their marketing that there's an inactive mic there, it would've become the only focus by the louder segments of the media. Whether or not it would ever be activated.

Perhaps had Google assistant been more useful, fewer people would've felt so upset. The mic can also be used to detect broken glass, etc.

</comment><comment><USER50> ahh, hate it when the company whose business model is to spy on me accidentally forgets to mention they put a microphone in my home security device!

</comment><comment><USER51> > "the revelation is especially problematic for the company that blah blah > blah"

How is it problematic? What exactly will change? Customer's will abandon Google's products? Google will stop this practice?

There will be exactly zero repercussions, and more "ooops it's an error we never meant it to he a secret" down the line.

</comment><comment><USER52> it wasn't meant to be secret. it just happened to turn out that way. so weird huh? sorry guys!

</comment><comment><USER53> I wonder how would people react if it had an undisclosed 360-degree IR camera with LED.

</comment><comment><USER54> Sounds familiar: [https://ca.news.yahoo.com/singapore-airlines-passengers- unse...](https://ca.news.yahoo.com/singapore-airlines-passengers-unsettled- cameras-073029950.html)

</comment><comment><USER55> We need an IOT protection bill that starts with labeling.

        * sensors
        * endpoints it talks to
        * update timeline
        * security protocols and device specific passwords

</comment><comment><USER56> Couldn't read the article due to adblocker, but I assume the mic was for home/away detection. Is there any evidence that it uploaded audio?

</comment><comment><USER57> This remind of the wifi sniffing "mistake" of Google. What other "mistakes" is Google making?

</comment><comment><USER58> So no one opened up one of these and looked at the components?

<comment><USER59> Just like many physical and non-physical (software) products, very often, _literally nobody_ reviews/verifies/checks them.

Google will learn from this mistake, and next time they'll use a fancy MEMS microphone or a similar technology and place it inside a semiconductor package.

When do you think such a feat will be discovered by independent researchers? Probably never.

<comment><USER60> There's also the reality that they can simply change the components/layout without ever telling anybody about it.

People just keep buying the same boxes without even being aware that the hardware inside these boxes might be completely different revisions.

Who's to say that future batches of Nest won't have cameras added for "future use"? Who's gonna go through the effort of checking every fresh batch of Nests for revisions like that? And what are the chances of actually catching it when it's only rolled out in small batches?

<comment><USER59> Good point. I'd like to also mention that it is possible for companies like Amazon to "personalise" orders before they are shipped.

</comment></comment></comment></comment><comment><USER61> That's bad, but remember that every smartphone has a microphone built in ...

<comment><USER36> Only two more months until Librem 5 launch. Yes it has a microphone (it _has_ to), but it's _far_ more trustworthy than any other smartphone from a privacy perspective.

</comment></comment><comment><USER62> *Nest Guard</comment>


Bank Hackers Steal Millions via Malware - <AUTHOR> http://nautil.us/issue/21/information/how-i-taught-my-computer-to-write-its-own-musichttp://www.nytimes.com/2015/02/15/world/bank-hackers-steal-millions-via-malware.html

<comment><USER2> Page not found.</comment>


Tech Choices - Why we use Centos instead of Debian / Ubuntu - <AUTHOR> http://www.chinanetcloud.com/blog/tech-choices-why-we-use-centos-instead-debian-ubuntu <comment><USER2> I've been supporting production RedHat and CentOS servers since RH 7 (15 years), and while RHEL 6 is a huge improvement over the bad old days of up2date and RPM dependency hell, RedHat still has a long way to go to catch up to where Debian was 10 years ago. The quality of packages on RH is still piss- poor compared to Debian (regularly missing man pages, broken default configurations, etc), and if it's not in RH core or EPEL, you're pretty much building it from source because finding up to date third party rpms that target the right version of RHEL is nearly impossible. yum is enormously slower than apt (I've clocked it at 10x slower on average on identical hardware), and rickety as crap. You get into dependency deadlocks regularly that require you to remove whole swaths of rpms just to clear out a conflicting dependency. Yum's use of an ancient version of Python mean that supporting modern python applications on RHEL means you're building all your own Python RPMs and installing in non-standard locations, or you end up breaking yum.

At my current job, we pxe install thousands of CentOS compute nodes and never touch yum again. When it's time to update, we build a new kickstart and re- install. That's the only reasonable way to run RHEL/CentOS and not lose your mind.

I have debian systems that are still running dist-upgraded versions of 10 year old installs, and the dpkg database is sane and clean. You can't do that with RHEL.

The unfortunate fact is that, in the enterprise world, people other than system admins make the decision to run RHEL at the expense of sysadmin time and sanity.

<comment><USER3> I take the contrasting view (vastly prefer Enterprise Linux) but write software that has to support many distributions.

Generally speaking, there are _better_ package review standards applied to Fedora (Red Hat and CentOS upstream) and you don't have things like debconf that make figuring out how to do a non-interactive install a little confusing. This means that in general there is less "randomness" that will occur than in your typical apt package.

Kickstart is also easier for users to bootstrap installations than preseed files, which in many cases require scripts to all be written on a single line. Writing preseed files causes me immense pain.

.rpmnew is also a nice system for replacing configuration files. By contrast, I've had apt purge _fail_ when files were deleted prior to running the purge.

Ultimately I'm not sure what kind of repositories you are working with, but that may be the problem.

I would choose CentOS or RHEL every time.

Many slowness issues can be solved by maintaining a local mirror and also by disabling the fastestmirror plugin -- while perhaps good for slow connections, the mirror speed checks cause added delays.

</comment></comment><comment><USER4> I see no discussion of package management in here, which is kind of a bummer. My experience with yum has been pretty crummy and I don't think it's improved over the last several years. That alone should drive someone developing software away from working on that platform.

Centos & Red Hat are great if you have a single package you need to deploy to a machine and all the dependencies are already there or easy to pull down from yum. You get the advantage of not having a capricious OOMKiller process that can randomly take down your system. But if you're actually in the process of building something, working on Centos is just a pain in the ass.

<comment><USER5> Just a counter point: I love yum. It is, by far, my favorite package management option. Managing yum repos is a breeze vs every other option (the toolchain is one command, vs a half dozen commands and hours of manual labor to setup a new repo for Debian/Ubuntu). I also prefer it from the end user perspective.

apt-get is fine, and I wouldn't be at all unhappy with servers running Debian, but yum is my preference.

<comment><USER6> As a Debian user, I agree that you can't beat the ease of setting up a repo on RHEL/CentOS. On the other hand, I'm not fond of the .spec format and working with yum is not particularly pleasant. Not to mention that Debian ships with a lot more packages.

<comment><USER7> I've provisioned and maintained dozens of servers all running Arch, and currently have four home PCs running it. I've found Pacman to be one of the easier and more pleasant package managers to live with.

You can sort through tens of thousands of existing PKGBUILDs on the AUR [1], which typically makes it quick and easy to start packaging software for Arch. You can even sync a flat text file database of all official Arch packages with abs [2]. The ability to reverse engineer every PKGBUILD for a wide variety of software is a major plus in my book.

Writing a PKGBUILD takes roughly the same effort as compiling software from source with a bash script. PKGBUILDs are simple to write, and there's just enough "magic" in Pacman to keep things sane.

Nine times out of ten, the PKGBUILD writing process boils down to copy/pasting directions from README or INSTALL files. It's like a bash script, except more 'done-for-you'. Finding exact dependencies is typically a cinch with the AUR and tools like packer.

Maintaining a rolling distro can be a labor of love, but if you love the system, you'll find it may significantly increase your overall sanity. It's another way of doing things, but I consider choice of distro to be one of the more important decisions to make, and IME, Arch has been such a significant departure from other distros that not trying it in a serious capacity is roughly equivalent to not trying Vim / Emacs ever in your career. Which is to say, I think it's a mistake not to at least see what it may offer you, especially if you're in any doubt.

I hope my positivity is only seen as that: positivity, and not overzealous dedication to one specific toolset. Arch probably isn't a panacea, nor will I claim that it's a perfect fit for your way of doing things. But I have never found something as pleasant as Pacman to work with. In addition, I never would've even tried Arch if I hadn't been slightly flustered by the seemingly irrational exuberance random sysadmins displayed for the system.

1: [https://aur.archlinux.org](https://aur.archlinux.org)

2: [https://wiki.archlinux.org/index.php/Abs](https://wiki.archlinux.org/index.php/Abs)

</comment></comment></comment></comment><comment><USER8> > _[W]e need reliability and predictability over a large variety of systems > over many years. We need strong support by most of the world 's software > vendors and open source project. We need documentation, tools, and global > resources for the most commonly used systems._

In which of these does Debain fall short?

<comment><USER9> Compared to RHEL/CentOS the Debian release cycle is actually very short, with support for an older version ending just one year after the release of a new stable version. So in average you will only have support for about 3 years for each release, compared to at least 10 years for RHEL. That's why there has been some discussion about a possible Debian LTS release: [http://lwn.net/Articles/565007/](http://lwn.net/Articles/565007/)

<comment><USER5> Lifecycle cannot be underestimated. The average life expectancy of a server is over 3 years. I'm pretty much running on a five year cycle, right now, for most of mine. It's a huge time cost to have to deploy a new OS more frequently than you deploy new servers.

</comment></comment></comment><comment><USER10> FreeBSD has a very stable core distribution with an up-tp-date rolling release "ports" system for additional software. It's great for these purposes. It also has excellent documentation, stable native ZFS, and compatibility with Linux binaries.

<comment><USER5> I've found FreeBSD to be extremely fragile, with regard to updates. It can easily become unusable if you initially install from binary packages and then move some things to ports builds (library dependencies aren't handled appropriately, as far as I can tell). System upgrades (from 8 to 9, for instance) are also scarier and more prone to failure than any Linux distro I've used.

While I have a lot of respect for FreeBSD's developers, I'd be unwilling to deploy it for production on servers; this is at least partially my own inexperience with the system...but I'm simply afraid to trust a system that makes it so easy for me to shoot myself in the foot.

Even with my own very limited use, I've never had a FreeBSD system that didn't end up utterly trashed eventually (in such a state that I chose to reinstall rather than try to fix it, because I had no idea where to start on fixing it; I'm sure a more experienced FreeBSD user would have been more capable of getting the system working again). I can't imagine what would happen if I were using it heavily, without first spending months or years learning how to avoid the pitfalls I run into so readily.

I had a similar level of experience with Debian (which is to say, not much), but never had a problem keeping it running. My experience is much higher on Red Hat based distros (I've managed CentOS and RHEL servers, and before that Red Hat Linux servers, for almost two decades), so I can't really compare it to FreeBSD, but I know our customers rarely run into OS issues on RHEL or CentOS, and we have a lot of them. CentOS represents more than half of our user base.

<comment><USER11> I used fbsd for 15+ years, 10+ years in production... and found it to be very stable.

I never experienced the problem you mentioned with packages... but packages are frozen at release.. so they're never updated... so you end up having to use ports for everything anyway. I always disliked having to compile every single package from source. If you have a large number of systems, it's worth setting up a build server and creating your own packages.

Major upgrades ARE scarier than on Linux. They have a fairly new binary upgrade tool that I never used.. upgrades using build world generally work ok.. just update your source tree, wait a few days for anyone to report bugs on the mailing list, and then run build world. You can't do this over ssh though.. you need concole access. Again, if you have a large number of machines, setting up a build server is worth it.

With that said though... FBSD has been slowly losing out in my company. 10 years ago, I used it everywhere... then fbsd neglected the desktop (not enough resources in the project), and Linux got so far ahead, that I was pretty much forced to switch to Linux on every workstation. Then a few years ago, found fbsd wasn't stable when virtualized.. ran a custom build on Xen for a while.. but eventually moved to Debian.. so it's now about 90% Linux.

</comment></comment></comment><comment> redhat-reallyp This is a content-free article. It boils down to "we've committed to CentOS, so that's what we prefer to use."

The claim that "in our experience, [Debian/Ubuntu] are not nearly as stable or trouble-free as RHEL/CentOS" says more about their lesser experience with those systems than it does about Debian or Ubuntu.

<comment><USER12> "Many people ask us why not use Debian-based systems such as Debian or Ubuntu server. We do support these if there is no other choice, but in our experience, they are not nearly as stable or trouble-free as RHEL/CentOS."

So while they do have "less experience" they do have _ongoing experience_ with Debian or Ubuntu. They say. We don't know what that means it could mean 1 machine per year or it could mean 10 per month.

Now if they hadn't needed to support essentially any Debian/Ubuntu that might mean they are stale in that area. So without qualification of their exact experience "how often" it is really hard to tell the bias in that statement wouldn't you agree?

<comment> redhat-reallyp "without qualification of their exact experience "how often" it is really hard to tell the bias in that statement wouldn't you agree?"

No, because many people have experience which contradicts theirs, and they don't provide any support for their claim: no information on what the stability issues or troubles they encountered were, no information on the causes and how they were specific to the OS in question as opposed to e.g. user error, no information about how CentOS would do better on that issue, etc.

All the indications are that they're making a very typical sort of claim that people make when trying to defend a decision that they're not qualified to defend. They provide no reasons to take it seriously. As I said, it's content- free.

</comment></comment></comment><comment><USER13> Really the only major things that annoy me[1] about using ubuntu LTS as a server are:

\- The fact that packages which install server software autostart the server on install, and the mechanism to disable this can vary package to package. I'd rather install-configure-then-start than install-disable-configure-then-start.

\- The mechanisms for setting options for packages to be installed are geared towards interactive use. You have to disable it popping up a curses dialog, and I don't think there's an easy way to pre-configure them so you just wind up with defaults if you do.

\- The version of upstart in 12.04 is really limited, and the mix of packages using old and new style init can be frustrating at times.

[1] Perspective check: I'm mostly a software developer, but I also admin my own servers for personal projects as well as having it as a peripheral aspect to my job at times.

<comment><USER14> Wow. I am the author of a popular app-that-runs-as-a-daemon and I just went through a HUGE debate with some folks about whether or not my package should auto-start on boot by default.

I eventually settled on this: If you're using Upstart you get auto-start by default. For everything else you'll have to turn on auto-start at boot via whatever mechanism is normal for your distribution.

That means for Ubuntu you get auto-start on boot the moment you install the package. For Debian you'll use update-rc.d and for RHEL-based distros you'll use chkconfig.

I have no idea if I made the right decision though since there's no standard. Sometimes it annoys the hell out of me that a package configures itself to start at boot and other times I wish it _did_ auto-configure itself to start at boot. It all depends on the package and what I want the server to do (primarily).

<comment><USER13> One of the nice things about upstart is that it helps this situation out a lot. Disabling a service before you install the package is as simple as creating a /etc/init/servicename.override file with "manual" in it. Unlike some other solutions (like placing a full configuration file before install) this doesn't trigger a conflict with the package installation.

The thing is that for a desktop user, starting the service is fine. A lot of the time it's what you want. And that's Ubuntu's main raison d'etre.

Also note that autostarting when _installing_ is different from autostarting when _booting_. It's the former that I find frustrating, not so much the latter. Generally speaking, I have plenty of opportunity to tweak the boot behaviour between installing and rebooting (assuming the server ever reboots at all).

</comment></comment></comment><comment><USER15> Redhat puts a lot of effort into building its enterprise distro. Yeah, it's mostly out of FOSS parts, I get that, but distros are nontrivial and costly undertakings.

I've always had a bit of a problem with Centos, which as I understand takes Redhat's work, removes the proprietary parts, and redistributes for free-as- in-beer - perhaps depriving Redhat of a sale or two. It's not exactly theft, but not sporting either.

Would somebody straighten me out? Am I wrong to avoid Centos based on social principle? What does Redhat think of Centos?

<comment><USER16> RedHat loves CentOS. To quote their CEO

> CentOS is one of the reasons that the RHEL ecosystem is the default. It > helps to give us an ubiquity that RHEL might otherwise not have if we forced > everyone to pay to use Linux. So, in a micro sense we lose some revenue, but > in a broader sense, CentOS plays a very valuable role in helping to make Red > Hat the de facto Linux.[0]

[0][http://readwrite.com/2013/08/13/red-hat-ceo-centos-open- sour...](http://readwrite.com/2013/08/13/red-hat-ceo-centos-open-source)

<comment><USER17> Somewhat why Adobe didn't care if you pirated Photoshop. If you weren't making money with it, they'd rather you know it than something else (maybe gimp?). Having mindshare (uggh, I hate that word) definitely helps when it comes time to get the credit card out for tools you'll need for a paying project.

</comment></comment></comment><comment><USER18> At work I run close to 30 VM's on Ubuntu. I chose Ubuntu for two reasons. I've been running it on my desktop for years and thus know how it works. And CentOS did not have the newer versions of various packages I needed in its default repos.

For the couple years I've been doing this, I can't think of any downtime that wasn't caused by something other than the OS.

Heck, even my desktop hasn't had OS caused downtime.

I would bet my experience would be the same if I was using CentOS.

Also, there are so many different ways you can automate your server and app deployments, that your choice of OS should really depend on what app you are running. A cutting edge app might need the latest Ubuntu release to get the latest packages. Another app might need the stability of an LTS release. And another might only work with an RPM based OS and specific versions of dependencies that are only found on CentOS.

Anyway, that's my opinion and experience. I am curious if there's statistical/scientific evidence supporting the idea that CentOS/RHEL is more stable than Debian/Ubuntu.

</comment><comment><USER19> Is it generally considered better to go with a better supported OS (eg CentOS or an Ubuntu LTS) and use extra package sources for non-OS programs or to use a more up to date OS that's already tested with the latest programs?

We made this choice recently, choosing Ubuntu 12.04 and a few (popular but unofficial) PPAs, rather than use Ubuntu 13.04.

<comment><USER20> Wise choice, because non-LTS version of Ubuntu is basically piece of shit.

<comment><USER5> It's not that non-LTS releases are "shit"...Just that you'd be a fool to sign up for replacing your OS every 18 months on a server that will be in service for more than 3 years (which is the average lifespan of a server, and that number seems to be growing).

<comment><USER17> Depends on the environment.

I manage a large AWS environment at my current gig, and all of our code is in git. With configs in puppet, code in git, I can deploy to new OS version instances in the background, do testing/QA, and then swap out the old OS environment for the new one all transparently to the user.

Now if you're talking bare metal, yes, it makes sense to go with LTS releases.

It all depends on what your equipment lifecycle is.

</comment></comment></comment></comment><comment><USER21> I've usually hated using RPM/Red Hat based distros because they tend to create giant headaches whenever you need to use a relatively recent release of a library or application and because I just don't like their package manager.

I think most people's problems with Ubuntu having too short of a release cycle come from people installing the current version of Server instead of the LTS version. I've known shops that stupidly used non-LTS Ubuntu server releases, and then kept them running after their support cycle ended...

I think maybe that's what happens when people who don't really know how the Ubuntu ecosystem just start using stuff.

</comment><comment> sorin-panca Why not have a tested Gentoo image and all servers with two root partitions to alternate between them on upgrades? The image can then be updated, tested and deployed (using pxe) when you feel the need. Also, using puppet or chef or even emerge of binary packages (by an in-house built deployment solution), one can install supplemental packages on a running system if needed. From my experience, having a fully source based Linux system is good for performance, security and - last but not least - stability.

</comment><comment><USER22> It seems that you are not familiar with debian's testing program.

</comment><comment><AUTHOR> I respect RHEL/CentOS but for ease of use (packaging system,vast amount of packages, easy upgrades) I prefer Ubuntu/Debian for my server and desktop.

</comment><comment><USER23> "Stable" sometimes means people are more familiar with the bugs than bug- fixes... Conservative tech choices: I'm only familiar with X so I don't choose Y like you guys who are familiar with both. -- This is OK because the benefit of better tech doesn't matter so much for their business.

<comment><USER24> For a second there I thought that you were gonna start another Wayland flamewar...

</comment></comment><comment><USER25> Isnt Redhat more expensive than Windows? I hope Debian gets better than Redhat, if its not already :).

</comment><comment><USER26> Has anyone had any reliability or other problems with Ubuntu 12 04 LTS?

<comment><USER18> I chose the wrong option when installing a grub update yesterday. Repairing from a live cd didn't seem to work. So I'm currently backing up my data and will install from scratch. Something I've been planning on doing eventually since this was a system upgraded from 11.10.

I also run 30ish VMs with it at work. Only real issue I've ever run into is how the /boot partition fills up with old kernels...

So, I have yet to see any proof that Debian is less stable than RedHat. Or the other way around. Heck, how would you even measure that?

</comment></comment><comment><USER27> Thank you very much :)</comment>


Trump is tame compared to Indian  prime minister Narendra Modi - <AUTHOR> http://www.independent.co.uk/voices/indian-election-narendra-modi-bjp-donald-trump-far-right-a7635086.html <comment> andrew-lucker Yeah, but not if Trump gets rid of our cash too and replaces it with higher denominations with his face all over it.

<comment><AUTHOR> Well, demonetisation isn't as big issue as action against Human rights organizations like Amnesty International or Environmental groups like Greenpeace. Trump isn't going to ban them or choke their funding directly. Also Steve Bannon is tame in comparison to Yogi Adityanath, the newly appointed CM of UP (a state with 204.2 million population). This Adityanath guy:

1\. Said that he will put hindu idols in every mosque.

2\. Said that Shah Rukh Khan(one of the greatest Bollywood) actor is a terrorist(Hafiz Sayed).

3\. Distributed arms for rioting.

4\. Has a person on his organization stage who said they should rape dead Muslim women in graves.

5\. Said those who don't want to do yoga should leave India and should drown.

6\. Will kill 10(100 in another) muslim for 1 hindu(killing anyone is wrong).

7\. His organization (Hindu Yuva Vahini) engages in nonviolence during valentine. This guy has been chargesheeted but no action.

What I have noticed is that during Bush time, Cheney was boundary of fringe for right in US. Now in Trump's time, Bannon is the boundary of fringe.

Similarly in India during vajpayee time, Advani was the boundary and Modi was fringe. Now during Modi's time, Yogi is becoming boundary. And mark my word, next boundary will be more direct oppression and removal of minority identity.</comment></comment>


Ask HN: Best bank(s) for startups - <AUTHOR>

Do you have a recommendation for a bank?
We're a bit sick of Wells Fargo and their "past century" feel. What is a good bank for startups/small companies?
Some criteria (that we're looking for -- others not matching these, please point it out): fewer attempts at sticking you with fees, somewhat efficient (e.g. for payments to freelancers national or international), no need for local branches, I think (we do not use ATMs often), can issue well-accepted credit cards, promotions for startups (like intros to angels or angel groups?).
(We're a bootstrapped company based in Silicon Valley aiming to scale, in case that matters. Feel free to recommend banks for others too.) <comment><USER2> Silicon Valley Bank has been good to us.

<comment><AUTHOR> We heard good things from them about intros, events, etc. Is that why you say they were good to you?

Put another way, why do you say they were good to you?

<comment><USER2> Just a lack of normal BS you have to deal with if you have Wells Fargo. Basically a well-run operation. Haven't used many of the benefits/features they offer other than banking.</comment></comment></comment>


Shipping Rust code in Firefox - <AUTHOR> https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/ <comment><USER2> Not in the same league as the mp4 parser shipping to all Firefox users, but GeckoDriver [1], a Mozilla-authored standalone binary for interacting with Firefox via the WebDriver protocol (e.g. using Selenium) is also written in Rust and shipping, possibly to as many as hundreds of users ;)

Overall the experience of using Rust for that project has been pretty great; the original requirements for a language were "able to produce static executables with no external runtime requirement, not prone to C-style memory safety issues, and accessible to a team with mostly Python backgrounds". That leaves quite a few options — Go for example — but being a Mozilla project taking the opportunity to use Rust seemed like it would align better with initiatives like those discussed in the article.

Apart from the general niceness of Rust-the-langauge, the experience of the Rust ecosystem has been really nice. Not only were there easy-to-install, well documented, packages to do much of the heavy lifting (http server, command line argument handling, etc.), it was also quite straightforward to set up travis builds using cargo to compile releases for linux64+musl osx and cross- compile releases for linux-arm7hf (added because someone asked about running on raspberry pi and it turned out to be trivial) and win64. The only wrinkle so far has been the difficulty of cross compiling to win32, meaning we might actually need to set up Appveyor or similar.

Obviously this is a much smaller project than the original post in terms of the number of users, and rather different as it is much higher level and could comfortably be written in Python or similar, except for the distribution requirements. However I think the use of Rust has been an unmitigated success, and I would be tempted to use it for a lot more projects that I would never consider writing in C/C++.

[1] [https://github.com/mozilla/geckodriver](https://github.com/mozilla/geckodriver)

<comment><USER3> How did you handle the Python to rust knowledge transition? Do you know any helpful guides?

<comment><USER2> I don't think I have any specific resources to recommend, sorry.

I wrote most of the initial implementation of geckodriver and mostly learnt Rust from reading the official book, writing some small patches for Servo, and working on this project (of course); pretty much the same advice you would get coming from any other language.

I just chatted with one of the other major contributors to the project who said that he was able to learn on the job by reading the existing code, looking up concepts in the book or via web searches, and asking questions when necessary; although some parts of Rust undoubtedly have a significant learning curve it is empirically possible to contribute to an existing project without a significant amount of upfront study. This arguably isn't too different from learning most languages, although you are going to need to read up on the rules around e.g. references and borrowing sooner than you would need to look something up if you took the same approach to writing your first Python.

The type system and borrow checker mean that the compiler will tell you if you're doing something wrong which is both a blessing and a curse; it can be dispiriting to get dozens of compile errors when you are getting started, but once you have satisfied the compiler it's possible to be more confident that your code won't break in ways that are relatively common in Python (e.g. missing or broken code for error handling).

So I'm not sure that I answered your question, but in practice it didn't seem to be a major problem. Of course in a different environment — one where people were less enthusiastic about learning a technology their colleagues were raving about, for example — you might have a different experience.

</comment></comment></comment><comment><USER4> Rust (like Let's Encrypt) is a great thing coming from Mozilla and I'd like to thank them.

Edit: "Coming from" in the sense of bootstrapping great independent communities around these.

</comment><comment><USER5> Even if Servo doesn't pan out as anything more than an experiment (though I'm optimistic that it will), I think Rust will bring real benefits to Firefox by enhancing security of isolated components like this mp4 parser.

<comment><USER6> If you look on the Mozilla bug tracker you can look at a number of tickets open for integrating servo components into Firefox.

For example Gecko is gaining support for Servo's style engine so maybe CSS will be the first large component merged.

I wonder if Firefox will slowly become written in mostly Rust.

<comment><USER5> > I wonder if Firefox will slowly become written in mostly Rust.

I doubt that will ever happen. Small parts of Firefox, yes, but the browser is enormous. I think I once read that even Servo, which is a showcase for Rust, has more C/C++ code in it than Rust code, largely because it uses Firefox's JS engine.

<comment><USER7> > I think I once read that even Servo, which is a showcase for Rust, has more > C/C++ code in it than Rust code

Not in the core project: [https://github.com/servo/servo](https://github.com/servo/servo)

<comment><USER8> Where is the feature in GitHub that would show the languages used in a repository? That would be useful here regarding this comment.

(Note I have no doubt you are right. It would just be a useful metric.)

<comment><USER9> Did they just..get rid of it? I can't find it either.

<comment><USER10> No, it works for other repostiories.

Probably Github uses cloc. I downloaded the code (over 500MB, insane!) and cloc throws an error.

<comment><USER11>
      > and cloc throws an error

tokei is a similar program that's parallel, and written in Rust. It takes 11 seconds to run on my machine, and shows

[https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d74...](https://gist.github.com/steveklabnik/b4ede6f13c9d609edc61d7421e0af1b1)

(using a gist since the output is huge, and see Manish's comment as well)

<comment><USER12> This is including the cargo cache dir?

<comment><USER11> I built Servo last week, I ran "git fetch upstream && git reset --hard upstream/master && git submodule update" and then "tokei .". So, unless Servo puts its cache in the dir, I would guess not, no.

<comment><USER12> I think by default servo does put the cache in the dir. So yeah, this would be an accurate estimate.

Though not all that rust code is written specifically for servo, and a lot of that C/++ code is winapi and skia. winapi is autogenerated, and skia isn't used by default anymore iirc.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> AHHH Telemetry! I feel like there is a group of people who freak out to any form of telemetry, I just wanted to highlight them using it to track bugs. It's super beneficial to any form of changes, especially something like switching an entire language for a component.

<comment><USER12> IIRC the telemetry involved here was only run on the nightly/developer edition versions. Or something like that.

The restrictions on telemetry on release versions are pretty stringent. It's possible this was measured on release, I'm not aware of the details, but I suspect it wasn't.

<comment><USER6> From my understanding release is opt-in only.

(My understanding is based upon whenever I install Firefox it promts me to enable telemetry, which is disabled by default)

<comment><USER14> You are both correct. :)

Firefox telemetry is opt-out on the Nightly, DevEdition, and Beta channels, but (mostly) opt-in on the Release channel. The opt-in telemetry from the Release channel has limited use because it is not representative of all users.

Here is a list of Firefox's telemetry measurements. Those that are opt-out on the Release channel are tagged _" releaseChannelCollection": "opt-out"_. Adding a new opt-out measurement requires an additional privacy review.

[https://hg.mozilla.org/mozilla- central/file/tip/toolkit/comp...](https://hg.mozilla.org/mozilla- central/file/tip/toolkit/components/telemetry/Histograms.json)

</comment></comment></comment></comment><comment><USER15> Does this imply anything regarding rust compiler package for distros? To support the Firefox build, all distros will have to have good rust compiler packages now, right? (I'm sure the status is already not bad, I haven't checked recently..)

If it becomes something dependable, infrastructure-wise, like Java, this might mark the beginning of a more serious uptake.

<comment><USER11> We've been doing a lot of work in this area, and some distros already have packages. Debian testing, for example.

Currently, I believe that this functionality is optional, so distros aren't required to actually ship it just yet.

<comment><USER16> Now that Rust can properly bootstrap from previous versions I can see most distros getting it packaged soon(TM), unfortunately the Fedora 25 change window ends today and since rust/cargo will require new packaging guidelines unless someone really steps up to the plate (I don't have time today) it won't make it in until F26.

<comment><USER17> SBT (scala) bootstraps itself in the same way. I think we're going to be seeing more of that going forward.

For the produced binary packages (rpms, debs) it won't matter that much; although it will reduce build dependencies for source packages and give more consistent builds, even if your distribution comes with an _ancient_ version.

<comment><USER18> That's not a complete comparison though -- sbt only downloads the platform- independent jars and minuscule launcher scripts. It's still on the user to install a JRE globally.

An analogue for rust would be something that detects the platform at runtime and then downloads a statically linked (?) binary that works on that platform. It can also exploit the ivy cache as the Scala compiler is just a library as far as SBT is concerned.

Isn't that a deal breaker? I would assume that downloading and checking in the binary for a whole compiler for 3+ platforms is untenable.

<comment><USER12> Distros are okay with a single starting binary for compilers. Gcc does this, for example. Rust would publish a single bootstrap binary, and distros would build the next compiler with that (and publish), and build the next one with the one that they just built, and so on. Multiple platforms would just involve cross compiling the first time.

<comment><USER16> The problem, historically, with Rust is that each release was built with the latest nightly, so you had to bootstrap each new version. Now they've changed to using the previous compiler release to bootstrap, so you can bring a binary in for the first build of a package then immediately rebuild with your bootstrapped binary and continue on from there for eternity.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'm curious why rust-url still hasn't been shipped with firefox yet.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1151899](https://bugzilla.mozilla.org/show_bug.cgi?id=1151899)

<comment><USER20> There are a couple of big pieces of work here:

1) Making the "cargo vendor" story work better. rust-url has a bunch of dependencies, and you have to get them all in-tree.

2) More security review & planning. URL parsing is scary! And we'd want to ship & run it alongside the C++ one to check for places where rust-url is not fully web compatible, but there are major privacy issues in reporting back anything more than "1 failure," even for users who have explicitly opt'd in to reporting back data.

But the team is definitely working on both of these pieces and I'd hope to see it in the near future. No timeline / release number promises, though, right now :-)

<comment><USER21> It would be cool for #2 that if a difference was detected, firefox would try to test and generate a general case (or a minimal case) - substituting out sensitive information. I guess sort of like fuzzy testing...

<comment><USER22> Another question is that determining what is sensitive information is a bit complicated… But there is an option of asking the user to edit URL to find anonymous enough form of the bug trigger. Maybe after doing some basic fuzzing (like replacing runs of alphanumerics with random runs of alphanumerics of the same length, if possible).

</comment></comment></comment></comment><comment><USER23> Super exciting!

I followed Rust at the beginning and I was pleased with the design goals of the language. However, I wasn't thrilled with the pre-1.0 documentation, and even after 1.0 there were breaking changes to the language.

Hopefully this is a sign of Rust's maturity. I'll have to look at it again:>)

EDIT: s/from/at/

<comment><USER11> Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.

<comment><USER23> The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems that this should be rarer than it has been so far with Rust.

So I haven't worried about anything per se, but breaking changes are mildly irritating to me. Without a doubt the utility value of some of these changes has been worth it (specifically RFC 1214, which was ironically one of the most major and definitely necessary). I'm not involved enough to be able to speak about other changes.

EDIT: I should also add that the software I work on professionally doesn't use any language that Rust competes with directly. Rust doesn't offer me professional utility so it's easy for me to complain about one thing and ignore all the benefits of Rust. If I were in a situation where I was contemplating using C++, Rust, or maybe Go, I think I would still choose Rust. It's far ahead of its competitors and gets a lot of things right.

<comment><USER24> I'm curious, do you have a language in mind that has been better than Rust as far as breaking changes go after the 1.0 stable release? An example? Rust has been far above most languages/libraries that I've found in dealing with breaking changes. The complaint here seems pretty empty to me. (Complaining for the sake of complaining)

<comment><USER25> Go has better backward compatibility.(i.e. no breaking change after 1.0)

<comment><USER26> Rust has the same policy.

It might appear differently because we're _very_ up front about any change that _might possibly_ break any code, even theoretically. We don't make any changes that we think _actually_ break code, except for blatant bug fixes.

Go has made changes post-1.0 that were more aggressive than anything Rust has done, such as changing the size of int.

<comment><USER25> I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in terms of stability. Why do you need rustup if Rust is so backward compatible? I'm not saying that Go is a better language than Rust but the its ecosystem and dev experience is definitely superior.

<comment><USER26> > Can you list the these `aggressive` breaking changes?

Changing the size of int. Changing methods to introspect the type of their arguments and do things differently. And so on.

> There were only 7 releases since go1 and I fail to find any breaking change > in the language specification. On the other side each Rust release has a fat > list with "BREAKING CHANGES".

Because we have a very specific definition of "breaking change" that is primarily concerned with the _practical_ effect of changes we make. Go does not consider these changes "breaking". Using Go's definition (changes to the language definition), we have no "breaking changes".

If we were to change the size of int (something we will not do, by the way, due to the practical effects of making such a change), then we would list it under "breaking changes", even if we were technically allowed to do it. That's because we care about the practical effects of our changes, not just the letter of the language definition.

> Many Rust packages only work with specific Rust versions(i.e. nightly).

Because they are explicitly opting into unstable features that are carefully marked as such. We can't stop packages from doing that. Nor can any other language.

> The rust ecosystem(std lib, tools etc) is also way behind Go in terms of > stability.

The parts of the Rust standard library that are marked stable have remained completely backwards compatible, in both interface and implementation.

> Why do you need rustup if Rust is so backward compatible?

Because it's nice to keep your compiler up to date and to target different platforms?

<comment><USER25> You are right about the compiler changes but even so you can't compare 1-2 compiler BK with Rust which has language changes as well. Compiler changes are the norm in Rust.

>> The parts of the Rust standard library that are marked stable have remained completely backwards compatible, in both interface and implementation.

This looks like a breaking change on a stable API. Am I wrong? [https://github.com/rust-lang/rust/pull/28811](https://github.com/rust- lang/rust/pull/28811)

<comment><USER12> > Compiler changes are the norm in Rust.

Compiler changes are the norm everywhere? I'm not sure what you're trying to say here.

> This looks like a breaking change on a stable API. Am I wrong?

Yes and no.

Rust's policy on breaking changes is that changes that can be fixed by properly qualifying an implicit path are not breaking. Otherwise, adding any method to anything would be a breaking change. In this case, you can use the UFCS syntax to disambiguate.

So it's an "allowed" kind of breakage because not allowing this means freezing the stdlib.

(Go doesn't have this issue due to lack of generics, overloading, and interface-based overloading. Edit: actually, go does too, due to inheritance, but that is easier to avoid and isolate. In rust you can always write client code that breaks if the stdlib adds a method, anywhere. This is true for most typed languages).

Anything that has the chance of practically breaking things is still run through crater (which tests impact on the ecosystem) and as you can see that PR had minimal impact.

<comment><USER27> > Go doesn't have this issue

Steve has pointed out that go _did_ have this issue as it has a limited level of auto-deref, which it has changed in the past: implementations performed two levels of auto-deref when executing methods when the spec only requires one, the implementations were changed to only allow a single auto-deref: [https://golang.org/doc/go1.4#methodonpointertopointer](https://golang.org/doc/go1.4#methodonpointertopointer)

<comment><USER12> Right. However, as I mentioned in the edit, you can still be careful about avoiding breaking changes through inheritance and autoderef in the evolution of Go's stdlib. It forbids very specific types of methods from being added, and if you avoid that, you can continue to add methods as if nothing is wrong.

Rust (and C++, because SFINAE, and many other languages), on the other hand, technically has a breaking change each time _any_ method is added to any public type in the stdlib. It's always possible that the client lib was using a trait method of the same name, and now has to fully qualify the method call.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> That telemetry graph looks odd, dates filtered from 2016/03/03 to 2016/04/07 but "Number of dates" is "3".

So does that mean despite a billion samples between those dates, all samples fell on just three dates?

<comment><USER29> If you click on the image to see the interactive graph, under "Advanced settings" there's a switch "Date range variable: filter submissions by build date range or submission date range", which is set to "build date range". So those "3 dates" correspond to three different build dates.

<comment><USER14> The telemetry link in the article points to Firefox 45 data. Curiously, the error rates appear to be going up: Firefox 46's error rate is 0.10% and Firefox 47's error rate is 4.35%.

* Firefox 45: [https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...](https://telemetry.mozilla.org/new-pipeline/dist.html#!measure=MEDIA_RUST_MP4PARSE_SUCCESS&max_channel_version=release%252F45)

* Firefox 46: [https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...](https://telemetry.mozilla.org/new-pipeline/dist.html#!measure=MEDIA_RUST_MP4PARSE_SUCCESS&max_channel_version=release%252F46)

* Firefox 47: [https://telemetry.mozilla.org/new-pipeline/dist.html#!measur...](https://telemetry.mozilla.org/new-pipeline/dist.html#!measure=MEDIA_RUST_MP4PARSE_SUCCESS&max_channel_version=release%252F457)

<comment><USER30> Wouldn't that make sense because FF 46 was not an ESR, 47 is the latest, and most users have been pushed to 47? More users are triggering more bugs in the parser.

Also, 45 ESR doesn't include the Rust code on Windows (I heard that's landing in 48, if a Mozillian could please confirm that), so that's a large userbase to not have included in testing.

</comment></comment></comment></comment><comment><USER31> Are there other improvements besides the security advantages from this? E.g. performance or memory usage?

<comment><USER32> Performance can be considered a consequence of security/language safety. Rust code is free from data races and developers can utilize concurrency and all available CPU cores without fear.

<comment><USER30> As evidenced by Servo.

</comment></comment></comment><comment><USER33> I'm sort of surprised that this is the first time they've used rust for anything in the browser. I thought they developed Rust for this exact purpose?

<comment><USER34> Rust was supported from the start by Mozilla in order to enable the construction of an experimental browser engine (ie. Servo) that was completely separate from Gecko and Firefox. Afaik, there was never any explicit goal at the beginning to rebuild things in Firefox - this is just the result of how successful the language project has been.

</comment></comment><comment><USER35> This is awesome. Now we just need a rust based flash player :-)

<comment><USER36> Or we should get rid of flash already.

<comment><USER35> I see it more like the Chesterson's Fence argument. Flash exists, and continues to plague us, because it met a need for developers that wasn't met in other ways. If that need still exists, rather than remove Flash (can the capability with it) and replace it with the same capability but with a much reduced attack surface.

I think that would be an excellent project for someone, if you should both show all of Flash's capabilities implemented in Rust and that the result was safer it would be an excellent endorsement of Rust. It could also illuminate end user features which can never be made safe. Also good for the overall body of web knowledge.

<comment><USER37> > Flash exists, and continues to plague us, because it met a need for > developers that wasn't met in other ways.

Emphasis on "met". I've yet to come across a function that can be built in Flash, but not in HTML 5. In fact, I'm not using flashplayer at all anymore and I don't suffer. (There are a few video sites that are still Flash-only, but `mpv --ytdl` works around that very nicely.)

Come to think of it, this is actually not true. At work, I have to use Flash Player for exactly one thing: Adobe Connect. I wonder why they didn't move to Flash yet. ;)

<comment><USER38> Not sure if this is the case for adobe connect, but other, similar products (such as blackboard's collaborate) are trying to move across to webRTC. This is complicated because Apple doesn't support webRTC yet, which I'd imagine is why Adobe hasn't moved across just yet.

</comment></comment></comment></comment></comment><comment><USER7> Will this include iOS devices too?

This is great news for the language as it's going to help make sure a wider array of architectures are supported.

Awesome work!

<comment><USER39> Firefox for iOS is just a wrapper around webkit since Apple refuses to allow any alternate engines.

<comment><USER27> IIRC, technically alternate (rendering) engines are allowed but you can only execute downloaded code using the system's webkit/JSC (and if you didn't you'd be restricted to a straight interpreter).

</comment></comment></comment><comment><USER40> [https://www.youtube.com/watch?v=B2KXVfnw4rg](https://www.youtube.com/watch?v=B2KXVfnw4rg) pokemon go death???

</comment><comment><USER41> Seems Rust is moving up in the world!

</comment><comment><USER42> Am I'm reading either the headline or the announcement wrong?

As I read it, they are not shipping Rust but a component written in Rust.

        > For this reason, Ralph Giles and Matthew Gregan built Mozilla's first Rust
        > media parser. And I'm happy to report that their code will be the first
        > Rust component shipping in Firefox.

<comment><USER43> You did not think, they would replace VanillaJS with Rust, did you? ;)

<comment><USER42> What does "replace" have to do with it? Why do you invent the most illogical option possible - that I never uttered - to find a counter argument?

Assuming that they ship another language _in addition_ to Javascript would not be completely out of the question. While it seems that with WebAssembly that is no longer necessary, who knows what Mozilla, in search of future funding, may come up with to open new markets. They also tried creating their own OS for mobile - shipping Rust to further its adoption for whatever to me at the moment inconceivable reason is no less improbable.

So yes, I wasn't sure what to expect from the headline - it said they are "shipping Rust" after all, so something crazy was certainly within realm of possibility.

<comment><USER44> > While it seems that with WebAssembly that is no longer necessary

I believe they have mentioned that a WebAssembly target for Rust compilation is something they are working towards, and IMO that would be the ideal way to deploy Rust for a website (if it's a compiled language, there's no need to deliver it uncompiled).

</comment></comment></comment></comment><comment><USER45> The headline is really wrong. Mozilla is shipping compiled and executable code to us. Now, if its Perl, I can confidently say I'm shipping Perl code to you.

Small nitpick, I know :)

<comment><USER17> Their source contains the actual Rust code and it's part of the build process. Distribution build maintainers will compile that rust code when making their packages. I run Gentoo, so that process happens when I upgrade Firefox.</comment></comment>


Koonji Launches User-Generated How-To Web Guides - <AUTHOR> http://www.sfgate.com/cgi-bin/blogburst/display/tech_web20?bbPostId=CzEkZm8d0SI4KCz7YgP3oqkQo9Cz5iKaa2rjFEJCzDMorG58GswR <comment><USER2> This is the email I recieved from those guys yesterday. Two tips: make it shorter(three lines?); dont use random font color/formatting style.

\</comment><comment>---

Hi Zaid, Koonji is an innovative experiment to redefine the way people access and use information. The main objective is to make web research more meaningful by providing a complete solution to search, enhance, organize and share relevant online information. Koonji is a community-powered step-by-step how-to guide to do effective searches on the web. People often turn to the internet to find information and to seek advice typically starting with a search engine. But there is no way they can get organized information and a guide to trace the path for them. Koonji solves this problem by organizing information by breaking down topics into multiple steps and providing the best resources available along with helpful tips. The step-by-step guides can be on any topic from baking a cake to applying for a home loan.

Koonji's content is all community driven, the guides or "Koonji's" are authored by users usually drawing from their experiences. Koonji believes that the community's collective experiences are the best place to generate information. Users find organizes information and are also aided by a companion Koonji toolbar travels with the users, allows users to tag and save information as a Koonji.

Whether one is looking to learn how to buy a HDTV, how to organize a birthday party, how to find a job or how to plan a vacation—the process for completing these activities can be time consuming and frustrating. Koonji users benefit from the discoveries know-how of others, avoid time consuming web searches and any the trial and error method of finding information. Koonji.com is information by users and for users seeking information.

Please do contact me should you have any queries at firstname.lastname@example.com .

Warm Regards,

Team Koonji

\</comment><comment>-----</comment>


Reasons to use Haskell as a Mathematician (2006) - <AUTHOR> http://blog.sigfpe.com/2006/01/eleven-reasons-to-use-haskell-as.html <comment><USER2> I've slowly come to the opinion that laziness is not the best idea, even from a pure mathematical point of view. There are large mathematical benefits to using a strict language like SML. One important benefit to me is that strictness allows you to have an equality operation with a very strong mathematical guarantee, namely that the types for which equality can be automatically defined are _precisely_ the types for which equality is decidable (always terminates). A lazy language throws that out the window. In a strict language you can define both a type of guaranteed-finite lists with decidable equality and a type of potentially-infinite streams, while in a lazy language you only have the latter.

I wrote about it in more detail here: [http://slepnev.blogspot.ch/2014/06/is- laziness-wrong-for-equ...](http://slepnev.blogspot.ch/2014/06/is-laziness- wrong-for-equality.html)

<comment><USER3> But mathematics is non-strict. One can define functions that terminate when evaluated lazily but don't terminate when evaluated strictly. These kinds of functions are prevalent in mathematics.

<comment><USER2> Does your belief that "mathematics is non-strict" go as far as saying that the type of natural numbers:

        data Natural = Zero | Successor Natural

must include this member as well:

        omega :: Natural
        omega = Successor omega

        bool1 = (omega == Zero)            -- returns False
        bool2 = (omega == Successor Zero)  -- returns False
        bool3 = (omega == omega)           -- whoops, infinite loop

The moral is that some parts of mathematics may be lazy, but mathematical induction has gotta be strict. Since many functional programs rely on induction for proofs of termination, correctness and resource usage, that means they should be strict as well.

<comment><USER3> >Since many functional programs rely on induction for proofs of termination, correctness and resource usage, that means they should be strict as well.

Am I incorrect in thinking that any strict program proven to be correct and terminating is also correct as a lazy program?

<comment><USER2> Yeah, that's true for programs, i.e. things that accept no arguments. Lazy evaluation provably makes more programs terminate than any other evaluation strategy. But it's kind of misleading for functions that accept arguments, like numbers or lists. Most functions in a lazy language can fail to terminate, because the arguments could fail to terminate or could be non- standard entities like omega. So, for example, the statement "computing the length of a list always terminates" is true in a strict language but not in a lazy one.

In general, strict languages allow you to say more about termination and time/space complexity of functions than lazy languages. For example, the statement "computing the length of a list takes O(1) space" is true in a strict language, but in a lazy language it's difficult to say what the statement even means, and in most practical cases it's false. Computing length with either foldr and foldl uses at least O(n) space, and the usual advice is to use foldl', which has a strictness annotation. I think this should be alarming to anyone who recommends lazy evaluation as the right default.

In slightly more complicated cases, like sorting a list, there's no sensible way to assign a time or space complexity at all, because it depends on how the function is called and how much of the result is used by the caller. People sometimes claim that's an advantage of lazy languages, e.g. implementing quickselect in terms of quicksort and claiming that quickselect will only evaluate as much of quicksort as needed. I think that's a hack. We need to be able to reason about the time and space complexity of a program in terms of its parts, without relying on implementation details of the parts.

</comment></comment></comment></comment></comment><comment><USER4> As someone who has used Haskell for math, I would comment that the standard prelude (Haskell's standard library) can be quite obnoxious to work with depending on what you are doing. When I use Haskell for math, I normally switch to the numeric-prelude [0].

[0] [https://hackage.haskell.org/package/numeric- prelude](https://hackage.haskell.org/package/numeric-prelude)

<comment><USER5> At least #2 on their list of issues is currently fixed in GHC 7.8

</comment></comment><comment><USER6> I'm currently porting a Numpy project into haskell as a self-improvement project, and it's been 69% great. But then I find some library that I have to implement from scratch when I just had it in python. That's a pretty big problem, and I'm willing to put up with it, but most people aren't.

<comment><USER7> A nice way to look at it: if you share what code you have had to reimplement, you're making it more than 69% great for the potential Haskellers that follow!

<comment><USER6> Would love to! But my employer probably wouldn't be so thrilled about it.

</comment></comment></comment><comment><USER8> I've always wondered why computational mathematicians/physicists end up using MATLAB/FORTRAN instead of haskell or similar.

<comment><USER9> The author of the article gives a hint: "Haskell isn't very good at dealing with arrays." High performance numerical code typically involves mutating large arrays distributed over a grid of machines or processors. I talk about the question you ask a little more here:

[http://arstechnica.com/science/2014/05/scientific- computings...](http://arstechnica.com/science/2014/05/scientific-computings- future-can-any-coding-language-top-a-1950s-behemoth/)

<comment><USER10> That just isn't true though. It might be true for the standard prelude, but there are very high performance options available. Not only that, there are great wrappers to the standard C/Fortran scientific libraries used by everyone.

I have written real time 3D reconstruction and SLAM algorithms in Haskell, so I have had to face this head on.

</comment></comment></comment><comment><USER11> there are a bunch of languages mathematicians should know, haskell is one of them, so is prolog, lisp, APL, FORTRAN, and C. They all have their advantages, and you just have to know which one will give you an edge in your problem domain.

</comment><comment><USER12> I want to hear from people who do math all day every day, and not just programming language theory. I want to hear about algebraic geometers, topolgists, ring theorists using Haskell and saying "Yeah this is really helping me in my work."

<comment><USER13> As a mathematician I'll certainly endorse a number of the points in the linked post. Because what they mean is that it can be very quick to translate mathematics into code. Maybe it won't run fast or be understandable by anyone else, but I can express complicated ideas (relatively) compactly and quickly and get something working without huge amounts of tedium.

<comment><USER12> Can you give me some examples? What do you use Haskell to do? I am also a mathematician so I can handle the jargon.

<comment><USER13> Mostly not large things. (Or at least, mostly not things that are large in Haskell.) An example recently -- I wanted to consider, let's say you have two finite rooted trees, S and T, with T having more vertices; and you you have a bijection f from the set of subtrees of S (subtrees have to have the same root as the original) to the set of subtrees of T, with certain restrictions on it; and then to f you associate a system of linear equations; and if the solution set to this system isn't contained a hyperplane aligned with the axes, then (if there exists an f for which this is true) I'll say "S interferes with T". And then I want to check for various T whether there is any smaller S that interferes with them.

Basically without something like Haskell, or at least something like Haskell- or-ML (I didn't need typeclasses and I don't know how much I needed laziness), it seems like that would have been a complete mess.

Of course, the above example is perhaps not the best as it meant I had to [either look up a library, or, what I actually did] implement row-reduction in Haskell, obviously not a great language for it! But ultimately it wasn't too terrible. And the rest as I've said would have been terrible in another language.

</comment></comment></comment></comment><comment><USER14> Shamelessly off-topic, but I can tell the author is a legit pure mathematician:

 _(1) Haskell is Functional

(2) Haskell Insulates You

(3) Haskell Performs Well

[...]

(3) Haskell is Declarative_

Not being ironic, by the way. From experience, often I can tell pure vs applied mathematicians by how hilariously bad/absent-minded they can be at basic arithmetic/algebraic manipulations.

Same for theoretical- vs systems-oriented CS people, I've found --almost as if being a horrible programmer somehow gives you academic hipster cred.

( _EDIT - To clarify: I mean CS academics in grad school, not CS professionals in industry. Also it 's just a silly anecdote only marginally correlated with reality: no offense intended to anyone._)

<comment><USER15> It is technically impossible to be a good 'CS People' and simultaneously be a 'horrible programmer'. It seems that what you are referring to are people who know basic CS concepts and even know the basic features of a language or two but do not have a 'Hacker' mindset. This does not make them a 'horrible programmer' \-- just as a hacker who comes up with 'tricks', without actually understanding that the things he 'created' were already discovered in some 70s CS paper, is not a 'horrible Computer Scientist'. It's not a sufficient method to describe a person's strengths and weaknesses.

<comment><USER14> Sorry I wasn't clear: by 'CS people' I meant to refer to CS academics in graduate school (professors, post-docs, grad students), not CS professionals in industry --admittedly a sign of insularity, I recognize.

And what I meant is that, anecdotally, academics working on CS theory ( _eg_ theory of computation, computational learning theory) are more likely than not to unmistakeably be what I think everyone on HN would agree to call point- blank "horrible programmers": no use of version control, no tests, little concern for organization/modularity/maintainability, _etc_. And in part it makes sense since they don't have to hack nearly as much as systems-type CS academics --in many ways their work is closer to pure mathematics than engineering/applied math. That's all.

In all just a silly anecdote, although with a kernel of truth. See for instance Scott Aaronson's joke comments about his programming abilities [1]:

 _On the spectrum of computer science, I 'm about as theoretical as you can get. One way to put it is that I got through CS grad school at Berkeley without really learning any programming language other than QBASIC_ (!).

[1] [http://www.scottaaronson.com/blog/?p=266](http://www.scottaaronson.com/blog/?p=266)

<comment><AUTHOR> This wouldn't be at all surprising if people realized that the job of academic computer scientists is not to program (just like the job of an academic mathematician is not to perform basic arithmetic.)</comment></comment></comment></comment>


The Fallacy of Motion - <AUTHOR> http://blog.dmbcllc.com/the-fallacy-of-motion/

<comment><USER2> This is the exact reason why I keep telling myself to slow down all the time, using pen and paper, drafting the problems and solutions before getting my hands dirty, writing them down and writing them bold. One tip I learn from my current CEO is that whenever you feel you're in a heating situation, get yourself a glass of water or coffee, drink it slowly, enjoy and the moment and do nothing. That quiet moment would help you slow things down, recharge your mental energy to do better.</comment>


Ask HN: Doctors in Silicon Valley - <AUTHOR>

I am planning on moving to Silicon Valley in 2012 to work at a start up. But only if my wife can find a job. She finished her residency in Emergency Medicine next year. Does anyone know about the job opportunities for Emergency Medicine Physicians in that area? <comment><USER2> Don't know any specifics but have some doctor friends in Silicon Valley. It seems like it's a healthy job market for physicians.</comment>