Github major service outage - <AUTHOR> https://status.github.com/messages https://status.github.com/ <comment><USER2> I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub.

Whenever GitHub runs into problems like this, it reminds me of when a team's CVS or Subversion servers used to go down. It could be a pretty disruptive occurrence, if it wasn't resolved quickly. While git can theoretically handle this better, in practice the use of GitHub, for instance, renders git just as susceptible.

<comment><USER3> Even worse is other tools that rely on Github, like Homebrew (Mac OS X package manager) which breaks in various silly ways when Github is down.

Anyone happen to know a way around this specifically? Trying to install some stuff and brew just bails after getting 5xx from github.com.

<comment><USER4> Clone the homebrew repo. Use a cronjob or Jenkins or some such to periodically fetch updates to a server under your control. Modify homebrew and its setup script to use your repo (it's been a while since I did this but the Github URL for the homebrew repo used to be hard coded in one of homebrew's ruby scripts). Whenever setting up a new machine, use the modified setup script.

Periodically you can merge upstream into your clone to get updated recipes. (e.g., the aforementioned cronjob can mirror master from github to remotes/upstream/master in your repo, then separately you merge that into your master).

Your servers are now immune to github outages[1] and you can review recipe updates before your servers update to those recipes.

[1] unless of course the recipes you're using are hosted on github. But you could recursively mirror those sources too and modify the recipes as needed.

edit: I'm on a mobile device but I can provide further details the next time I'm in front of a keyboard in case this wasn't clear.

<comment><USER3> > unless of course the recipes you're using are hosted on github

Yeah, the problem I was having at the time was that Homebrew was trying to fetch a tarball hosted on Github. I was just whinging though, that was the only time I've ever hit that particular snag.

The system you propose would be great, but more work than switching to running headless Linux VMs on OSX for most dev work ;) This is something I have been drifting toward for a while now, using Vagrant.

</comment></comment></comment></comment><comment><USER5> <http://www.isitdownrightnow.com/github.com.html>

<https://status.github.com/messages>

<comment><USER6> Or for the HN friends without Javascript, <http://isup.me/github.com>.

</comment></comment><comment><USER7> Least reliable service that I pay for by a long shot.

<comment><USER8> Must not pay for very many services? <https://status.github.com/graphs/past_month>

<comment><USER9> To be fair 99.77% uptime isn't very good.

<comment><USER10> That isn't fair at all.

It's 99.770% for a single month, immediately following a major event. If you sampled yesterday (or tomorrow, assuming no further issues) it would be higher. If you just look at today, it's at the much lower at 95.871%. If you assume no availability issues for the last 12 months (not true, but the point remains) then it's 99.981%. During an actual outage, availability was at the unacceptable 0%.

Unfortunately they don't provide 12mo stats, which is what you typically want if you're going to start calculating nines of availability.

<comment><USER11> Hey, are you seriously defending 3 9's of uptime? That's abysmal.

Github, if they're honest about their 12 month uptime levels would be lucky to be a single 9 service. Their uptime is Terrible with a capital T. But you know what? Until there's something better everyone is going to keep using them, right?

Great services with values that are hard to find become damn near irreplaceable even with terrible uptime. This is an obvious place to compete; if you made a github clone that simply stayed online you could win market share during every downtime. However cloning github would not be trivial.

And therein lies the problem and the answer to why we accept their terrible uptime levels. They give us something we can't get elsewhere: social coding and easy centralization.

<comment><USER10> Are you seriously incapable of distinguishing "hang on, you are getting numbers that look bad using statistical chicanery" from "Github = teh awesome"?

Pointing out that someone whose point I agree with is using bad math as evidence is not disagreeing with the point, it's asking that people who agree with me behave like honest, civilized, human beings---I don't care that you've already gone through the hassle of getting your pitchforks out of storage.

Speaking of which... your accusation that they are lying means that Github has had nearly 37 days of total outage this year---that they're down for two and a half hours a day, every day, for a year straight. And by honest, I assume you mean "they are lying", as opposed to "they are using a different definition of uptime than I would like." Naturally, you have some evidence for these claims, right?

<comment><USER11> Lying is a bit of a strong word. I think calling anything a single 9 service should be taken in jest. It's pretty hard to be down almost 40 days and still be in business.

Also, technically something with 98.9999% uptime would still be a single 9 service...

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I didn't even know it was down haha. I've been pushing to a private GitHub repo all morning with no problems.

</comment><comment><USER13> Database outage causing everything to go down?

<comment><USER14> That and their wording suggests a single db server :/

<comment><USER15> They have a typical master/slave setup with memcached on the front. <http://www.slideshare.net/err/inside-github>

<comment><USER16> Since they're using MySQL, is there a technical reason (as opposed to historical/lack of time reason) they're not using Galera Cluster?

I'm in the process of migrating an existing datastore to MariaDB+Galera, and so far it seems like everything I could hope for in a clustered RDBMS.

<comment><USER17> Last I investigated Galera it lacked support for query caching. Over 50% of our queries are cache hits, so it made it hard to justify using Galera over a normal master+slave setup. However I could see it being useful for setups where a single server can't handle the load (we average 300 queries/sec on a single server with lots of room to spare.)

<comment><USER16> They still disable the query cache, but MySQL's query cache generally isn't considered all that great a thing anyway, so few people care. You're better off making judicious use of Redis or memcached.

The biggest win for Galera is high-availability that actually works with minimal effort. (I've never experienced a high-availability solution not based on multi-master/all-nodes-hot principles that didn't cause more problems than it solved.)

They also claim some scalability wins at the front end, but I haven't really tested that, and am content with the performance not being terrible.

<comment><USER18> _but MySQL's query cache generally isn't considered all that great a thing anyway_

You've never had to prime a query cache on a MySQL server, have you? :)

<comment><USER16> Of course not. I use a caching layer with lower overhead that doesn't invalidate the entire cache when a single record changes. The query cache just isn't competitive.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> The status page says that "Code Downloads" is "Normal". How do you get to the downloads page for a given repo? Is there some canonical form for a URL for repos? Maybe while they're fixing it we can still download code...

<comment><USER20> try:

      git://github.com/{user}/{repo}.git

or

      https://github.com/{user}/{repo}.git

anyway, not working right now for me (Italy)

EDIT: working, give it 30 seconds to start.

<comment><USER19> Nope, no joy - 30 seconds or otherwise.

</comment></comment></comment><comment><USER21> We mainly used github and one of their last updates, our entire repository turned to blank. Nada, no file, no wiki, nothing... We emailed support and tweeted their account. After one week, someone replied asking "is there problem still there?" I thought that was funny in term of how immature this company is. They eventually fixed it after like 2 weeks by restoring the backup database.

Anyways, Github is nice. Use it with caution. It cannot be full blown Enterprise ready grade service yet.

</comment><comment><USER22> Looking through the past few months of messages on <http://status.github.com/messages>, I'm really quite surprised at how many service outages, major or minor, are reported. It seems something goes wrong more days than not.

</comment><comment><USER23> A number of ticketing systems, like Unfuddle and Assembla, include free git repos. Personally I prefer Github, but if you're already using such a system, might as well utilize its git hosting (for a backup if nothing else)

</comment><comment><USER24> Same for me from San Diego, CA. I am unable to push and unable to access the main page. Getting "This page is taking way too long to load."

</comment><comment><USER25> im getting a 500 (from NYC) on the main page + i cant push to remote repos

<comment><USER15> From here (NE UK) _everything_ is down.

Typically I was in the middle of setting up a development environment on a new machine which has a lot of composer dependencies....

Oh well will have to go drink coffee in the sporadic sunshine :).

</comment></comment><comment><USER26> It's back up for me.

</comment><comment><USER27> Why Unicorn Why!

<comment><USER28> So, what's better than Unicorn ?

<comment><USER29> Two unicorns.</comment></comment></comment>


New ammonia production process: generates electricity instead of consuming - <AUTHOR> https://phys.org/news/2017-02-flipping-ammonia-production-electricity-consuming.html <comment><USER2> Replying to a number of previous comments on energy balances.

The reaction N2 + 3 H2 -> 2 NH3 is exothermic, giving off energy [1]. N2 is abundant and free (80% of the atmosphere), but H2 is not. The most common way [2] of producing H2 is from hydrocarbons (oil/gas products). In principle H2 can be produced from something else (e.g. water, through electrolysis), but that is _very_ energy intensive [1], making the overall reaction N2 + 3 H2O -> 2 NH3 + 3/2 O2 a net energy consumer.

Point being, yes, it might be possible to save energy compared to the Haber- Bosch process, but the net production of ammonia from free/abundant materials will not ever be "for free" energy-wise.

[1] [https://en.wikipedia.org/wiki/Standard_enthalpy_of_formation](https://en.wikipedia.org/wiki/Standard_enthalpy_of_formation) [2] [https://en.wikipedia.org/wiki/Hydrogen_production](https://en.wikipedia.org/wiki/Hydrogen_production)

</comment><comment><USER3> ATP is required to make the reaction happen. My suspicion is that it's energy net-negative. Sure you make some electricity but how much does it cost to make ATP? Probably more than you get out in electricity. Not that there's a fast and easy way to turn electricity into ATP. [https://www.reddit.com/r/askscience/comments/46ax8r/can_elec...](https://www.reddit.com/r/askscience/comments/46ax8r/can_electricity_be_used_to_convert_adp_to_atp_in/)

<comment><USER4> Theoretically, ATP could be harvested from plants or bacteria. They could also be modified to produce the ammonia directly via this reaction. That wouldn't actually reduce the energy cost, but it could reduce the economic cost by making it logistically easier to produce. Maybe instead of making ammonia in complicated chemical plants, we could "grow" it on farms.

<comment><USER3> I mean, sure, you can do that. But it's kind of silly. "Grow" ammonia feedstock on farms to then turn into fertilizer to use at the farm to grow food?

Maybe you should just plant legumes instead and let them fix the nitrogen straight into the soil where you want to grow food. It's not sexy since it's 19th century technology (or older) but it works. And it requires very little in the way of logistics or infrastructure meaning that it's resilient.

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

<comment><USER5> Oh you city slickers... This has been a thing for centuries and it works pretty well. Getting big industry in the middle of the process would be new but the process is old.

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


SeenBefore: A search engine for what you have seen before - <AUTHOR> https://www.seenbefore.com/ <comment><USER2> Obvious point to raise: the reason people regularly delete their browser history is because they watch porn without turning on private browsing. How do you propose to deal with this?

You'd need to provide at least the ability to selectively delete portions of the history. But you can selectively delete portions of your browser history too, and people don't - because it would be too easy to miss something. Instead, they just nuke the whole thing. How is your tool different?

<comment><USER3> Vinny Glennon, One of the founders here. Thanks very much for the up votes. The Chrome extension does not work in private browsing. I have a set of porn sites(1.7 million stored in redis) that I check if incoming links are a member of. You can selectively block sites ( <https://www.seenbefore.com/blacklist_items>).

<comment><USER4> Where did you get your list from, and can you share it?

<comment><USER5> For research purposes.

<comment><USER6> For science.

</comment></comment></comment></comment></comment><comment><USER7> Beat me to it! This was something I had been planning to build on my own for a while, but didn't get around to . Congrats!

Whenever I have tech discussions with friends I would recall something mentioned in a article I read via HN. But it would take me a whole lot of effort to get that link. Oftentimes I simply couldn't get hold of the link even after an hour of searching.

Please do get the Firefox extension out. Would love to use it. Also, please do make sure the extensions/addons are stable. Have been facing problems with Annotary's extensions [1], for instance.

By the way, do you have a crawler fetch the link content or do you send it from the user's browser?

[1] [https://getsatisfaction.com/annotary/topics/unstable_browser...](https://getsatisfaction.com/annotary/topics/unstable_browser_extensions)

<comment><USER3> cofounder here. Our first version spidered out for the content but a far more efficient way was to upload compressed version of the data from the user as we can then do hash checks for reference counting. Chrome extension has been used in the wild for last 3 months on 6 continents. Firefox extension too unstable at the moment(also Mozilla ten day review process), but hope to get it out with 1-2 weeks. Would love any feedback, good or bad!

<comment><USER7> Few annoyances I noted in the FAQ "What Google search sites does it support?" section. google.co.in is by default in English, you would have to explicitly set it to another language [1]. "Indian" is not a language (Hindi, Malayalam, Bengali etc. is [2]). Farsi is not spelt Farsai [3]

[1] <https://www.google.co.in/?hl=ml>

[2] <http://en.wikipedia.org/wiki/Languages_of_India>

[3] <http://en.wikipedia.org/wiki/Persian_language>

<comment><USER3> Fixed. Switched example to Turkish and Iranian, as that is were most of your traffic came from this post. Just read an 800 page book on India, can't believe I made that mistake.

<comment><USER7> It's, unfortunately, a common mistake.

</comment></comment></comment></comment></comment><comment><USER8> Interesting idea. Some quick questions:

\- How much data do you store per user?

\- How do I delete certain results? (preferably after the search comes back)

\- Another thing to consider is - After how much time does this just become as painful as finding that page through a search engine?

\- What version of the page gets stored? The _latest_ or the one that I saw?

I guess its one step better than Evernoting a page and adding tags myself.

Good luck!

<comment><USER3> Main issue with Evernoting and Bookmarking is that it requires an effort to say that today, this page is useful and I want to store it. Most pages I want to find are very things I did not think was useful at the time. Each unique page(unique as per the content) is stored per user. Our goal is to build the tools needed to find the information quickly, similiar to what hipmunk.com did for airline search. We have the added dimension of time to use.

<comment><USER9> The main thing I use bookmarks for is categorisation. If you add the ability to tag and/or add notes that becomes part of the search terms, that'd be the killer feature for me - I could throw out my 3500 bookmarks and remove Xmarks (at least if we could get a way of automatically getting our existing bookmarks installed).

I'm a paying Xmarks user, but if you were to add a way of tagging sites or adding a note, I'd happily pay for this instead. Just a freeform text field that I could add some keywords into that gets treated as part of the search would actually be sufficient for me.

</comment></comment></comment><comment><USER10> Some of the things I "see", I would prefer they never show up in a Google search.

I'm sure there is a configuration setting somewhere to deal with that, but it would be yet another thing to take care of.

</comment><comment><USER11> One feature that could help this: verifying that the account holder is the one using the computer, before showing results.

Without this, assuming this plugin is always-on on all the computers one uses, breaking user's privacy just becomes too easy.

And there's a lot of data one might want to leave private except porn(and usually don't post them in facebook): medical issues, sexual issues, marriage and some other relationship issues, drugs issues and probably others.

</comment><comment><USER12> You could hook it into Chrome's history API[1].

[1] <http://developer.chrome.com/extensions/history.html>

<comment><USER13> If it would let people search there history and bookmarks, they could start benefiting from it right away.

</comment></comment><comment><USER14> Hmm, this is similar to <http://historio.us>, which I built. However, this doesn't require any user interaction, which might work well.

Do you store just the URL and depend on Google returning the results? How does it work exactly?

<comment><USER15> I remember thinking that <http://historio.us> was a neat idea.

But Seen Before requires less effort on my part as a user -> I am more likely to use it. I just continue to google as per normal and now I have an extra option on the right to filter results.

<comment><USER14> This is true. The use cases are a bit different, but I still don't know exactly how this works so I can't say.

</comment></comment></comment><comment><USER16> "SeenBefore stores your information securely in the cloud from your work or home computers.

So no matter where you read it you can still search for it even when your browsing history has been deleted."

Erm...

I think it's a good idea but I think many people would need convincing on the security front.

</comment><comment><USER17> Who am I handing my data over to? I can't find this anywhere on the site.

<comment><USER18> And would it be possible to configure it to use my own "cloud"?

<comment><USER3> Definitely something we are looking into. Major barrier is the cost for someone keeping a server running 24*7 in cloud(Micro instance on AWS is 175 dollars a year).

<comment><USER19> Some of us already have servers running 24-7 in the cloud. I have two, for example.

</comment></comment></comment></comment><comment><USER20> Yes, I have seen it before! I have build a personal search engine MindRetrieve back in 2005.

<http://mindretrieve.net>

Specifically I'm not comfortable for big web company to keep the history of my web activity. So I make it work completely locally. My project did not get much uptake, probably my lackluster marketing and other assorted issues are to blame. So good luck on this one!

<comment><USER21> Too bad. Looks like a really cool project. Even more impressive when seeing how old it is.

</comment></comment><comment><USER3> Co-founder here. This took us by surprise, we were planning to have Firefox and Safari support done by launch. At this stage, it is priceless to know if we are solving a real problem people have. Also, is this something people would pay for (loops back to if this is enough of a pain point). From the moment we start charging, is the moment we start learning.

<comment><USER9> See comment elsewhere: With tagging or (simple plain text) notes attached, absolutely. Even moreso with a simple API and/or support to push the cached content to my own server. If it could be selectively enabled for private content too, then even better (e.g. there's several extensive private Wiki's I use regularly that are not sensitive enough that I'd worry about getting them indexed, and I'd love to be able to tell you to index them but perhaps disable the caching).

</comment></comment><comment><USER22> "40% of searches online are people simply looking for what they have already seen before." - How did they calculate this statistic?

<comment><USER23> "According to Yahoo, 40% of searches are simply searching for what you saw before."

<https://www.seenbefore.com/pages/faq#currently_do>

They should link to the study.

<comment><USER3> Linked: <https://www.seenbefore.com/pages/faq#currently_do> . Thank you so much! :)

</comment></comment></comment><comment><USER24> I get that deployment is easier when it is vendor hosted, but this really should be a local app using local storage, withe maybe transient server-side storage for syncing between machiens.

</comment><comment><USER25> Dup of Archify?

<https://www.archify.com/>

> 40% of searches online are people simply looking for what they have already > seen before.

Citation link needed.

<comment><USER3> Citation link: <http://cond.org/sigir07.pdf> [PDF]

Information Re-Retrieval: Repeat Queries in Yahoo's Logs

Abstract: "This paper explores repeat search behavior through the analysis of a one-year Web query log of 114 anonymous users and a separate controlled survey of an additional 119 volunteers. Our study demonstrates that as many as 40% of all queries are re-finding queries. Re-finding appears to be an important behavior for search engines to explicitly support, and we explore how this can be done."

<comment><USER26> Wow, does 240 people even count as a sample. At Yahoo and Google log sizes its probably the error from cosmic rays in the data center.

<comment><USER27> If they selected them in a properly random way and had an effect close to 40% then yes, that probably does count as a sample.

<comment><USER26> As someone who signed up to coursera stats 101, err... Why 40%?

<comment><USER27> I am making some assumptions here absolutely, but because 40% is a large effect you don't need as many samples to be confident.

The other way of looking at it is that maybe it's actually 35% or 45% but either way, that's still interesting, even with a rougher approximation of the actual "answer". If, for some reason, you needed to know if it was 40% or 40.01% because that mattered to you then you _would_ absolutely be annoyed at the small sample size.

If the finding was 2% then we _would_ care about the uncertainty of +/- 5% since the finding is dwarfed by the error rate. That's a smaller effect size so you would need more samples to separate reality from the noise.

I am, by the way, pulling all of these numbers out my ass. Your stats 101 class will teach you the formulas to calculate the actual error bars at work here as well as the assumptions you need to make about the distribution of the data to use those formulas.

</comment></comment></comment></comment></comment></comment><comment><USER28> I think this is a great idea. I've been using Opera, which has a full-text search capability for history, but it's limited to the machine you're using it on.

I often find interesting articles on Hacker News while I'm at home that I want to find again when I'm at work. Being able to search by browser history across machines is fantastic for me.

</comment><comment><USER29> YES! I've been looking for something like this for ages for stuff I have read on Hacker News.

<comment><USER30> I use a system adapted from <http://www.gwern.net/Archiving%20URLs> to archive every page I've bookmarked (using FF) in the previous month. Then I just query with local tools.

Not ideal, several flaws, but works well enough for me so far.

</comment></comment><comment><USER31> I'll take it for a spin... this is something I've wanted for a long time.

I was going to hack it by making chrome bookmark every site I visit with a tag:history then when I wanted to search for a site that I've already visited I was going to just search with that tag.

</comment><comment><USER32> Doesn't Google already have this? Go to...

Show Search Tools -> All Results -> Visited Pages

<comment><USER33> I'm pretty sure that's only for filtering pages visited _via a prior google search_

In theory Chrome lets you search through your history for pages, but it doesn't seem to actually work very well for me.

</comment></comment><comment><USER34> Similar to my project Peerbelt.com. A notable difference is Peerbelt runs entirely on the client to void privacy concerns. Vinny, let's chat and see if we can collaborate. Cheers, -Krassimir the Peerbelt founder

</comment><comment><USER35> There's also weekly reports that tell you what sites you've been visiting the most, what time of day/what days you visit sites most, and how many pages SeenBefore added to your file.

</comment><comment><USER36> In a similar vein, Pinboard offers to snapshot and full text index all your bookmarks, for a small annual fee:

<https://pinboard.in/upgrade/>

</comment><comment><USER37> I'm going to give it a spin and let know what I think (it'll take a few weeks of usage), but I can tell you right now that it's definitely solving a real problem I have.

</comment><comment><USER38> I am going to try this out because it seems like what I spend a large portion of my time doing. The security and privacy of this scares me a lot though.

</comment><comment><USER39> I love this idea but I think you will find more traction by turning it into a kind of bookmarking app with less focus on the search engine part.

</comment><comment><USER40> I love the date visualization. This is something I think that pretty much all search results could benefit tremendously from.

</comment><comment><USER41> How is this different from Google Search History?

<https://history.google.com>

<comment><USER7> GSH searches only within your Google search history. This guy searches through your entire browser(s) history.

<comment><USER41> Thanks, I was confused by the fact that this integrates with Google Search.

</comment></comment></comment><comment><USER42> Great idea, I assume with Chrome's new incognito browsing, this won't be picked up on seenbefore or am I wrong?

</comment><comment><USER43> Looks useful. I've been well aware that google tracks everything I search for but I still don't like it.

</comment><comment><USER44> I don't know why I should give you my browser history. I'd like to keep it to myself.

<comment><USER45> I agree, sounds like a crazy thing to do when this could easily be achieved locally on my machine. Or am I missing something ?

<comment><USER27> But if a small piece of software was installed on your machine it wouldn't be "in the cloud". We know that makes everything better. Ok well not application performance ... or cost ... or usability ... but still, "the cloud".

</comment></comment></comment><comment><USER46> For those using Firefox, there is a similar add-on called RecallMonkey.

[https://addons.mozilla.org/en-us/firefox/addon/prospector- re...](https://addons.mozilla.org/en-us/firefox/addon/prospector-recall- monkey/)

</comment><comment><USER47> Great idea. Love it.

</comment><comment><USER48> great idea and works brilliant!</comment>


Apollo 13 transcripts "Houston, we've had a problem" - <AUTHOR> http://apollo13.spacelog.org/02:07:55:20/ <comment><USER2> I'm blown away by the user interface and visual design on this site. What a great way to make transcripts seem more lively, and attached to real people.

<comment><USER3> It really is exceptional. Way better than just reading the logs.

</comment></comment><comment><USER4> That is cool - both the transcript, but more importantly the web site. Is that built on some kind of open source software, or did they roll their own?

<comment><USER5> <https://github.com/spacelog/spacelog>. -- looks like it's built with Django, Redis, Xapian, and a few other things.

</comment></comment><comment><USER6> I find it amazing how collected and professional folks stayed during this. They reported the issue, communicated information, nobody seems to have freaked out like I probably would have.

<comment><USER7> Years of military training will do that for you. :)

</comment></comment><comment><USER8> Effectively a dup: <http://news.ycombinator.com/item?id=1958292>

There are other submissions as well:

<http://searchyc.com/submissions/spacelog?sort=by_date>

<comment><AUTHOR> Yeah, sorry about that - I was especially interested in this part of the transcript and didn't notice the other submissions beforehand

</comment></comment><comment><USER9> Here's the actual audio:

<http://www.youtube.com/watch?v=0vZa7g14F-Y>

It's right in the beginning, and they definitely say "we've had a problem."

</comment><comment><USER10> It took me a second to realize this is probably an OCR error:

<http://apollo13.spacelog.org/02:09:38:58/#show-selection></comment>


HN Feature Idea: Add the ability to ignore particular users. - <AUTHOR>

Over the last 18 months or so, I've started making liberal use of the "ignore" functionality possible in IRC software, forums, social networks, etc.
I've noticed a marked increase in my own happiness as a result.
Given the widespread belief that the quality of HN comments has gone downhill over the last year or more, perhaps adding the ability for individual users to ignore particular users who post less-than-helpful comments would be a good idea?
I'm imagining an "ignore" link accessible when you click on their username to view their profile page. This would prevent the link from being accidentally clicked.
I suppose someone could also create a Chrome extension to do it via JavaScript (hint hint). <comment><USER3> I disagree, I believe that not being able to see part of a conversation because you have blocked some people would be irksome.

I suppose it could be true for brutal trolls and the most rude of people, but it would eventually be used to ignore people with opposing views - <USER2> everyone is a yes man.</comment>


When Will We See Collisions for SHA-1? (2012) - <AUTHOR> https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html <comment><USER2> Question answered. [https://security.googleblog.com/2017/02/announcing-first- sha...](https://security.googleblog.com/2017/02/announcing-first- sha1-collision.html) dated February 23, 2017.</comment>


Skynet Today – a platform for experts in AI to debunk hype and misunderstanding - <AUTHOR> https://www.skynettoday.com/ <comment><AUTHOR> Just felt like submitting this now since we got a fancy new look. Check it out!</comment>


Ask HN: How dangerous is it to use 1Password's cloud storage? - <AUTHOR> I ended up making the migration a couple weeks ago, though I can't help but feeling like my data is now part of a big honeypot. <comment><USER2> [https://support.1password.com/1password- security/](https://support.1password.com/1password-security/)

You're encrypting your vault client-side, so unless an attacker gets ahold of your master key, I think you're good.

<comment><AUTHOR> Thanks. Is there anyone auditing that process, or that there's not a secret key?

I'm more worried about hackers that governments... but all the same.

</comment></comment><comment><USER3> They allow you to store the (encrypted) data in your own Dropbox if you're concerned about the 1Password cloud.</comment>


I am Getting A Chance to Interview Sabir Bhatia  - <AUTHOR>

I am Getting A Chance to Interview Sabir Bhatia the Creator of Hotmail . what Should I Ask ? <comment><USER2> * You can perhaps ask him what are his views about the current state of email (HTML).

* Does he think he has better ideas than current reigning email services?

* If given a chance, when will he improve in email services like Gmail. Or will he improve them at all?

* Where does he think email stands in the future of communication?

</comment><comment><USER2> You had already posted this <https://news.ycombinator.com/item?id=5642344>

<comment><AUTHOR> it was a browser bug (opera mini ) sorry

</comment></comment><comment><USER3> Ask him, why mail hasn't changed a bit since hotmail days?

</comment><comment><USER4> Ask him how he came up with the name hotmail.

<comment><USER2> >>>The name "Hotmail" was chosen out of many possibilities ending in "-mail" as it included the letters HTML

<https://en.wikipedia.org/wiki/Hotmail#Launch_of_Hotmail></comment></comment>


Intel Skylake/Kaby Lake processors: broken hyper-threading - <AUTHOR> https://lists.debian.org/debian-devel/2017/06/msg00308.html <comment><USER2> The problem description is short and scary:

 _Problem: Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active._

I wonder how many users have experienced intermittent crashes etc. and just nonchalantly attributed it to something else like "buggy software" or even "cosmic ray", when it was actually a defect in the hardware. Or more importantly, how many engineers at Intel, working on these processors, saw this happen a few times and did the same.

More interestingly, I would love to read an actual detailed analysis of the problem. Was it a software-like bug in microcode e.g. neglecting some edge- case, or a hardware-level race condition related to marginal timing (that could be worked around by e.g. delaying one operation by a cycle or two)? It reminds me of bugs like [https://news.ycombinator.com/item?id=11845770](https://news.ycombinator.com/item?id=11845770)

This and the other rather scary post at [http://danluu.com/cpu- bugs/](http://danluu.com/cpu-bugs/) suggests to me that CPU manufacturers should do more regression testing, and _far more_ of it. I would recommend demoscene productions, cracktros, and even certain malware, since they tend to exercise the hardware in ways that more "mainstream" software wouldn't come close to. ;-)

(To those wondering about ARM and other "simpler" SoCs in embedded systems etc.: They have just as much if not more hardware bugs than PCs. We don't hear about them often, since they are usually worked around in the software which is usually customised exactly for the application and doesn't change much.)

<comment><USER3> CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.

<comment><USER4> In my limited experience, their root cause analyses are really impressive as well with lots of internal attention and resources. I'm not allowed to talk about any Intel issues, but we reported a very strange issue to Nvidia, sent a couple of dozen cards back and six months later got a truly fascinating report back we with hundreds of pages of compute test result tables and electron microscope images and chemistry lab reports. Anything that hints of a manufacturing problem is taken incredibly seriously.

<comment><USER5> I worked for a large company that used thousands of Intel CPUs every year and when we suspected a CPU bug we were mostly brushed off. We had a very persistent person on the team who kept tracking the issue to find correlations and some very good kernel developers that went on to nearly pin-point the issue and only then did Intel pay attention and it then took them still several months to acknowledge the issue give a brief report on the issue and acknowledge that our proposed workaround will indeed work.

I've never seen Intel do a very good job at failure analysis or following on with failures unless prodded very hard.

<comment><USER6> Intel likely has very thorough data on the issue, but you'll never see it unless you are one of their tier 1 customers* and have an NDA with them. In my experience working for a large hardware manufacturer they are very skittish about releasing detailed failure analysis data to outside companies.

* For Intel that would be companies like Dell, Apple, HP, and maybe a couple of others.

</comment></comment></comment></comment></comment><comment><USER7>
      The issue was being investigated by the OCaml community since
      2017-01-06, with reports of malfunctions going at least as far back as
      Q2 2016.  It was narrowed down to Skylake with hyper-threading, which is
      a strong indicative of a processor defect.  Intel was contacted about
      it, but did not provide further feedback as far as we know.

      Fast-forward a few months, and Mark Shinwell noticed the mention of a
      possible fix for a microcode defect with unknown hit-ratio in the
      intel-microcode package changelog.  He matched it to the issues the
      OCaml community were observing, verified that the microcode fix indeed
      solved the OCaml issue, and contacted the Debian maintainer about it.

      Apparently, Intel had indeed found the issue, *documented it* (see
      below) and *fixed it*.  There was no direct feedback to the OCaml
      people, so they only found about it later.

Inexcusable.

<comment><USER8> What exactly do you find inexcusable here?

<comment><USER7> The contempt for users. I know what I do when a user files a real bug: respond to them, acknowledge it's a problem, tell them when it's fixed.

The fact that Intel does not do that with a bug of this magnitude shows how much respect they have for their users.

<comment><USER9> It's totally plausible that Intel detected this bug independently with their own verification effort or through another customer. Matching different defect reports when "unexplained" or nondeterministic behavior is the expected result can be challenging.

</comment></comment></comment></comment><comment><USER10> The latest intel-microcode package from Ubuntu 16.04 does not fix the problem. I installed the same package from Ubuntu 17.10 [0] which fixes the problem. You can check your system with the script linked in the mailing list thread [1].

[0] [https://packages.ubuntu.com/en/artful/amd64/intel- microcode/...](https://packages.ubuntu.com/en/artful/amd64/intel- microcode/download)

[1] [https://lists.debian.org/debian- devel/2017/06/msg00309.html](https://lists.debian.org/debian- devel/2017/06/msg00309.html)

<comment><USER11> Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106 [1]. Later Ubuntu releases do have more recent microcode packages [2]. I cannot understand why they left out 16.04 there. So much for LTS, it seems.

This recently came to my attention while debugging some increasingly frequent lockups, which took me a solid week of eliminating all seemingly more likely causes (VirtualBox, nVidia driver, faulty RAM, etc). In the end I found the culprit while digging into the Intel Specification updates: my Core i7-5820K (and most other Haswell-E and Broadwell processors) has a bug when leaving package C-states, and the only workaround is to disable C-states above level 1. Timely updated microcode, which applies this workaround, would have saved me my week.

[1] [https://launchpad.net/ubuntu/xenial/+source/intel- microcode](https://launchpad.net/ubuntu/xenial/+source/intel-microcode) [2] [https://launchpad.net/ubuntu/+source/intel- microcode/+change...](https://launchpad.net/ubuntu/+source/intel- microcode/+changelog)

<comment><USER12> > Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient > 20151106.

By ancient, perhaps you mean the version that was current at the time 16.04 shipped?

> I cannot understand why they left out 16.04 there. So much for LTS, it > seems.

See [https://wiki.ubuntu.com/StableReleaseUpdates](https://wiki.ubuntu.com/StableReleaseUpdates). The point of an LTS (or any stable release, for that matter) is that it doesn't change by default. For those who want to keep everything up-to-date, Ubuntu ships a new release on a six month cadence. If you choose not to use that, then you shouldn't be surprised when things aren't updated, since that's exactly what you opted in to.

The microcode package may warrant an exception, however, and we have a bug to track that. It's tricky because without the source we cannot pick apart what changed, or determine whether any changes meet our update policy. We have to be careful. Sooner or later some user will inevitably come along to tell us that a microcode update broke things, and ask why we didn't fulfill our LTS promise by not changing it.

<comment><USER11> By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it.

You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it? Precisely because Ubuntu cannot pick it apart, what is it that they're trying to decide in the bug? Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The Intel specification updates list tons of processor bugs including some very critical ones, so we know the microcode updates do help with some of those. When was the last time that an Intel microcode update brought a new bug or made something worse? I'm not aware of any such instance, and although that may indeed happen sometime it doesn't seem as likely as facing existing known bugs, right?

I think it could be argued that it is up to the user to decide (say, a warning during installation), or that Ubuntu could choose to apply all microcode updates by default and let the user opt out. Ubuntu might impose a certain delay, say a month or two at most, in order to see if a microcode update gets withdrawn or ends up too buggy. But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case, or to choose which ones to apply and which ones to skip, like it seems to be trying to. Microcode should be treated like other propietary software, but with special dilligence due to its criticality. If nVidia says a particular driver release is very buggy and should be updated, Ubuntu promptly updates it. Why would Ubuntu sit on known critical microcode updates then? If, and it's really a big if, eventually some microcode update brings a new bug and Ubuntu deployed it, it would be Intel's fault and not Ubuntu's.

<comment><USER12> Why is this Ubuntu's sole responsibility? Can you not get a UEFI firmware update from your vendor?

> I think it's a fair and tame adjective considering this is processor > microcode we're talking about...

Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise.

> You say Ubuntu has a bug to track the microcode package as an exception, but > that doesn't seem to be having a positive effect, does it?

By being careful before pushing out an update to millions of users? I'd say that's a positive effect.

> ...what is it that they're trying to decide in the bug?

Whether to continue to let users have a choice, or by taking that choice away by doing things automatically for them. There are also packaging-based regressions to consider; not just the microcode ones. For example: if the wrong microcode is applied to the wrong processor because of a packaging error, who would you be blaming? Intel or Ubuntu?

> But I don't think Ubuntu could reasonably choose to skip all microcode > updates for 1.7 years like it did in my case...

Ubuntu didn't "choose to skip" all microcode updates. Ubuntu didn't choose at all; pushing an update requires a specific effort.

In light of this issue, Ubuntu is now considering what to do about it, responsibly, for all users. Both for this particular issue, and for microcode updates going forward.

<comment><USER11> I don't think yours is a serious answer, what I said already refutes your points. Ubuntu has already made me waste a week and I don't want to waste any more, particularly when you can't or won't listen to what I say and look for irrelevant excuses like the availability of UEFI vendor updates. Just FYI Intel provides these updates for very good reasons and RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog). Bye now.

<comment><USER12> > RHEL/CentOS/Fedora have been providing processor microcode updates for ages > now and with relatively frequent updates (see the microcode_ctl RPM > changelog)

I wasn't aware of this, thanks. Though I searched, and I found that they've been causing their users problems by doing so: [https://rhn.redhat.com/errata/RHBA-2017-0028.html](https://rhn.redhat.com/errata/RHBA-2017-0028.html)

I think this backs up my point: care must be taken.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Here's how to fix it on a Thinkpad on Linux. I've got a T460s and checked with the script[1] that it was indeed affected. The Debian instructions said to update your BIOS before updating the microcode package so I went to the model support page[2] to the BIOS/UEFI section and downloaded the "BIOS Update (Bootable CD)" one. The changelog included microcode updates so it looked promising[3]. To get the ISO onto a usb drive I did the following:

      $ geteltorito n1cur14w.iso > eltorito-bios.iso # provided by the genisoimage package on Ubuntu
      $ sudo dd if=eltorito-bios.iso of=/dev/sdXXX # replace with your usb drive with care to not write over your disk

I then had a bootable USB drive that I ran by rebooting the computer, pressing Enter and then F12 to get to the boot drive selection and selecting the USB. From then it's just following the options it gives you. It's basically pressing 2 to go into the update and then pressing Y and Enter a few times to tell it you really want to do it. After that just let it reboot a few times and the update is done. After booting again the same test script[1] now said I had an affected CPU but new enough microcode.

[1] [https://lists.debian.org/debian- user/2017/06/msg01011.html](https://lists.debian.org/debian- user/2017/06/msg01011.html)

[2] [http://pcsupport.lenovo.com/pt/en/products/laptops-and- netbo...](http://pcsupport.lenovo.com/pt/en/products/laptops-and- netbooks/thinkpad-t-series-laptops/thinkpad-t460s/downloads)

[3] [https://download.lenovo.com/pccbbs/mobiles/n1cur14w.txt](https://download.lenovo.com/pccbbs/mobiles/n1cur14w.txt)

</comment><comment><USER14> There's a perl script on the debian mailing list that digs a bit deeper and tells you if you're affected in the first place, if you're affected but patched already, affected but have HT disabled, etc.

[https://lists.debian.org/debian- user/2017/06/msg01011.html](https://lists.debian.org/debian- user/2017/06/msg01011.html)

<comment><USER15> I ported this to bash since I have a chromebook w/o perl and (as for right now) the fs is read-only, so I just piped the script to it and sure enough my brand-new Samsung Chromebook Pro appears to be vulnerable, though apparently patchable.

Details and if you want the script I link to it from here: [https://forum.xda- developers.com/hardware-hacking/chromebook...](https://forum.xda- developers.com/hardware-hacking/chromebooks/samsung-chromebook-pro- asus-c302ca-t3627253) \- don't judge my shitty bash skills.

ft

</comment></comment><comment><USER16> In my experience with parallel code written in Haskell, hyper-threading offers only a very mild speedup, perhaps 10%. It is essentially an illusion, a logical convenience. (How long does it take to complete a parallel task on a dedicated machine? Four cores with hyper-threading off has nearly the performance of eight virtual cores with hyper-threading on.)

Many people have neither the interest nor the hardware access to overclock, and these processors have less overclocking headroom than earlier designs. Nevertheless, the hyper-threading hardware itself generates heat, restricting the overclocking range for given cpu cooling hardware. In this case, turning off hyper-threading pays for itself, because one can then overclock further, overtaking any advantage to hyper-threading.

<comment><USER17> It depends on what resources your code uses on-chip. If all threads are contending on the same resources, then you won't see a speedup; if they're using different resources, hyperthreading can increase throughput significantly. I've seen hyperthreading give me the equivalent of 50% of another CPU, particularly when I'm running multiple CPU-bound processes concurrently (so they're not executing the same code at the same time in some kind of parallel operation, and certainly aren't bound on synchronization primitive overheads).

<comment><USER16> That makes sense. I'm a mathematician, and my experience is with pure computations, homogeneous across each (virtual) core.

</comment></comment></comment><comment><USER18> It's painful to have to read text like « select Intel Pentium processor models ».

If Intel used marketing names that were more closely related to technical reality, then when something like this happens they wouldn't have so many customers finding themselves in the "maybe I'm affected by this horrid bug" box.

</comment><comment><USER19> So will this be affecting most Macbook Pros of the past few years?

If so, there's a way to disable hyper-threading, but you need Xcode (Instruments).

Open Instruments. Go to Preferences. Choose 'CPU'. Uncheck "Hardware Multi- Threading". Rebooting will reset it.

<comment><USER20> This is kind of like cutting off your leg because of a hangnail. I've been running a Skylake MBP for more than 6 months for compilation workloads and haven't seen a single processor hang.

I'm much more annoyed by the completely unpredictable desktop assignment on monitors when hotplugging DisplayPort connections on multiple displays. This one bothers me every day.

<comment><USER21> > haven't seen a single processor hang

If there was data corruption you might not notice.

</comment></comment></comment><comment><USER22> Rule of thumb: On a desktop, if you have an i5 you do not have Hyperthreading. All i3s and i7s do have Hyperthreading, as do new Kaby Lake Pentiums (G4560, 4600, 4620).

On laptops, some i5s are not real quad cores but dual cores with Hyperthreading.

<comment><USER23> >Rule of thumb: On a desktop, if you have an i5 you do not have Hyperthreading. All i3s and i7s do have Hyperthreading, as do new Kaby Lake Pentiums (G4560, 4600, 4620).

Hmm...either this statement is wrong or this desktop /proc/cpinfo is wrong:

        $ grep -E 'model|stepping|cpu cores' /proc/cpuinfo | sort -u
        cpu cores	    : 4
        model           : 94
        model name	    : Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz
        stepping	    : 3
        $ grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && echo "Hyper-threading is supported"
        Hyper-threading is supported

Intel's product spec page[1] lists this CPU as not supporting Hyper-Threading so I'm a bit puzzled as to why the ht flag is present.

[1][https://ark.intel.com/products/88188/Intel- Core-i5-6600-Proc...](https://ark.intel.com/products/88188/Intel- Core-i5-6600-Processor-6M-Cache-up-to-3_90-GHz)

<comment><USER24> Hmmm, checking for "ht" seems to be giving weird info. On a i5-750 here (few years old), running Fedora 25:

        $ grep '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo
        flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush
        dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts
        rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2
        ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida

"ht" is being returned even though the CPU only has 4 cores and no hyperthreading:

[https://ark.intel.com/products/42915/Intel- Core-i5-750-Proce...](https://ark.intel.com/products/42915/Intel- Core-i5-750-Processor-8M-Cache-2_66-GHz)

dmidecode seems to give more accurate info for this:

        $ sudo dmidecode -t processor | grep 'Count:'
        	Core Count: 4
        	Thread Count: 4

<comment><USER23> It looks like dmidecode also contradicts itself with the hyper threading flag:

        $ sudo dmidecode -t processor | grep -E 'Flags:|HTT|Status|Count'
        	Flags:
    		HTT (Multi-threading)
    	Status: Populated, Enabled
    	Core Count: 4
    	Thread Count: 4

<comment><USER24> Hmmm... yeah that's showing the same on mine too. According to dmidecode, this CPU has hyperthreading.

</comment></comment></comment></comment></comment><comment><USER25> I would've expected at least an example assembly code reproducing the bug? How was it not discovered before, but only with the OCaml compiler? They say "unexpected behavior", does this mean that code compiled with this can give incorrect results? Can this have any security implication? How much code was compiled with similar patterns? Can the problem reproduced with any JIT compiler? We need to know what can cause this, maybe compiled and working code already contains such patterns waiting to be abused...

</comment><comment><USER26> Charming. I picked up a 5th Gen X1 Carbon configured with a Kaby Lake processor, and apparently there's no way to disable hyperthreading in the BIOS, and according to Intel's errata, no fix available yet.

Oh well... so far the machine (running Windows 10) has been stable minus one or two random lockups in 2 months of heavy usage which could be attributed to this. Guess I wait...

</comment><comment><USER27> That's a really nicely done announcement. Simple, to the point, no drama, all the info you could want, scripts to figure out your processor, etc.

Well done Debian folks!

</comment><comment><USER28> So if I understand correctly, some affected processors can be fixed by a microcode update, but there are some which _cannot_ be fixed at all?

Also the advisory seems to imply that the OCaml compiler uses gcc for code generation, which it does not -- it generates assembly directly, only using gcc as a front end to the linker.

<comment><USER29> It sounds like they can all be fixed by disabling hyperthreading.

<comment><USER30> > fixed

mitigated

</comment></comment></comment><comment><USER31> So, serious question: If the microcode "fix" for this ends up disabling HT, how does one get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue?

This isn't a hypothetical; what did Intel do when the only fix for broken functionality was to disable TSX entirely?

<comment><USER32> I remember the pentium bug in the mid 90s, they actually shipped out replacement processors. Doubt that could be pulled off on laptops. Perhaps a microcode update can work around it.

<comment><USER33> Given my Surface Book got a 1/10 repair-ability score on ifixit... I dont think they'll just replace the chip :-P

</comment></comment></comment><comment><USER34> If anyone on Windows wishes to update their CPU microcode without waiting for Microsoft to push it out via Windows Update, you can use this tool from VMware [https://labs.vmware.com/flings/vmware-cpu-microcode- update-d...](https://labs.vmware.com/flings/vmware-cpu-microcode-update- driver) which can update microcode as well.

Windows stores its microcode in C:\Windows\System32\mcupdate_GenuineIntel.dll which is a proprietary binary file and you can't simply replace it with Intel's microcode.dat file (which is ASCII text), so you have to use a third- party tool such as VMware's one.

Simply: 1\. Download and extract the zip file in the first paragraph 2\. Modify the install.bat file so that the line which reads `for %%i IN (microcode.dat microcode_amd.bin microcode_amd_fam15h.bin) DO (` only contains the microcode.dat parameter (since you obviously don't have an AMD CPU, and the tool is made for both) 3\. Download and extract microcode.dat from Intel's website ([https://downloadcenter.intel.com/download/26798/Linux- Proces...](https://downloadcenter.intel.com/download/26798/Linux-Processor- Microcode-Data-File)) and place it into the same directory as the VMware tool 4\. Run install.bat with admin privileges 5\. Hit cancel when it tells you that the AMD microcode files are missing, and you're done

The CPU microcode will be updated immediately (yes, while Windows is running.) The service will also run on each boot and update your CPU microcode, since microcode updates are only temporary and are lost each time you restart. You can check Event Viewer for entries from `cpumcupdate` to see what it has done. It's advised to run a tool to view the microcode version before installing (such as HWiINFO64) so you can re-run the tool after installing and confirming that the version has changed.

I have done this and it works as described. I went from 0x74 to 0xba as shown by the μCU field in HWiNFO64, and I have an i7-6700k.

</comment><comment><USER35> Has anyone benchmarked one of these machines before and after applying this microcode update? The options in microcode are rather limited and all are likely to have performance impacts. This is likely disabling functionally to avoid this case. I would hope the patch is smart enough to not apply if threading is not enabled, but who knows.

<comment><USER36> Would a performance hit go unnoticed?

Usually (always?) it's not a ROM update, the encrypted microcode blob is loaded into the CPU by the OS on every boot via CONFIG_MICROCODE.

some linkrot: [http://imgur.com/a/z1uLv](http://imgur.com/a/z1uLv)

</comment></comment><comment><USER37> Just got the 2017 no touchbar 13 macbook pro with the kaby lake i7. Should I be worried, can I even disable HT with mac. And presumably the update will be provided so the whole laptop is still ok?

I've been using the thunderbolt 3 dock with two external monitors and occasionally get a little glitch prolly loose cable I think.

I've downloaded the bitcoin blockchain, done quite a bit of work in pycharm + chrome, multiple projects, flow and webpack in the background and haven't had any sort of crashes tho.

</comment><comment><USER38> Holy cow. Definitely feel like I dodged a bullet by building an AMD/Ryzen system this time around - which had it's own set of issues (but seem to be more or less ironed out now).

<comment><USER39> This is not a fair comment: Ryzen had a crash that can be triggered by compiling with GCC and a memory compatibility issue where it cannot run them at their nominal speed. Ryzen is a really young architecture, it already had like 6 stable patches of microcode and you can expect way more.

<comment><USER38> Still seems to be doing better than "turn off half of your processor, sorry no fix just buy a new one".

<comment><USER40> Hyperthreads are just that - threads. It won't be 50 % slower with HT disabled.

<comment><USER41> Intel still charge extra $100 for it.

<comment><USER42> That's less than 50% of the price for CPUs with HT.

</comment></comment></comment></comment></comment></comment><comment><USER43> How does one get new microcode on Windows? Is that what the Intel Chipset drivers are?

And is the microcode fix available for non-Linux systems yet?

<comment><USER44> Windows update

<comment><USER45> Has this already been patched via Windows Update? I didn't even know WU could do CPU microcode patches.

</comment></comment></comment><comment><USER46> Does Windows have a patch for this too? Or just disabling HT is the safest option?

<comment><USER47> Windows does have a microcode update driver, as you would expect, so it can fix this.

However, looking at the microcode update driver on an updated Windows 10 as of right now, I don't see a recent enough microcode version to fix it. The latest updates appear to be from 2015.

<comment><USER48> That's pretty cool, I didn't know of this functionality. Is there a good resource on how to look it up?

<comment><USER47> I haven't seen a description of it anywhere that I can think of. The driver lives in C:\Windows\system32\mcupdate_{genuineintel,authenticamd}.dll. All it does is detect which CPU it's running on, and load the appropriate microcode.

Loading the microcode is straightforward---all you need to do is put a few values in the appropriate MSRs. This is described in the Intel manuals, Volume 3. The microcode itself is embedded in the above DLLs, as a big binary table. The latest entry I see is 20150812 for the Intel 0x40651, aka Haswell.

</comment></comment></comment></comment><comment><USER49> When intel had the floating point division hardware bug they recalled chips. [https://en.wikipedia.org/wiki/Pentium_FDIV_bug](https://en.wikipedia.org/wiki/Pentium_FDIV_bug)

I wonder if intel will do something like that again or if the industry as a whole is more tolerant of unreliable / buggy behavior and will just live with it. Examples of Apple just telling people that the poor reception strength was their own fault / changing software to hide problems / etc.

<comment><USER44> If you read the link you'll see they've fixed it with a microcode update.

</comment></comment><comment><USER50> I have a Skylake mobile CPU (i7-6700hq) and it pretty much rocks with Ubuntu 17. Also the system is stable and fast. Under heavy load, e.g. games the system is stable. Compiling a big(>10000 modules) C++ project via ninja/cmake under Qt Creator hangs the system resporducibly after ~15 minutes. I wonder now if this broken hyperthreading could be such sideffect.

</comment><comment><USER51> I wonder how this issue affects cloud providers?

</comment><comment><USER52> When HT first started appearing on P4 chips I was looking after NetWare, 2K and XP boxes, they would freak out with HT enabled all kinds of oddities, I suspect most because of the OS's not fully supporting it.

To this day I disable it by reflex on everything!

</comment><comment><USER53> I do wonder though, why didn't Debian maintainers pick up the microcode updates when they were made available by Intel? Why did it need a wink from the Ocaml people for them to note? Or am I missing something?

</comment><comment><USER54> The late 2016 Razer Blade uses the i7-6700HQ which is specifically a Family 6, Model 94, Stepping 3 processor.

I wonder if a microcode update would solve some of the various issues I have in Windows.

</comment><comment><USER55> My CPU (6th generation i5) died last week. RIP.

I installed debian 9, installed virtualbox, vagrant, setup a clean development machine for myself, everything took 4 hours to finish.

I reboot the virtual machine, and boom, there was a kernel panic which I sadly don't remember exactly / didn't take a picture of. After I rebooted the machine, and opened terminal, the system froze. The cursor wouldn't move. Reboot again, motherboard has a CPU fail/undetected light on. Couldn't get it to boot after that.

I am both sad and relieved that bad stuff exists, but it's being patched to prevent proliferating.

I sincerely hope I'll get a replacement from Intel.

<comment><USER56> CPUs rarely die, unless you're OCing or PSU went bad and took things out, I am willing to bet your MoBo is the part that is bad.

</comment></comment><comment><USER57> Are those microcode updates deployed via windows (10) update?

</comment><comment><USER58> What is the probability for this to happen? Or how could I estimate the time it takes for random code to hit this bug at least once with a probability of over 90%?

</comment><comment><USER59> A little off-topic, but does anybody know of any hacky ways to disable hyper- threading (on Haswell if it matters) if the firmware doesn't provide the option?

</comment><comment><USER60> If I run $grep name /proc/cpuinfo | sort -u

model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz

then $cat /proc/cpuinfo | grep ht

Definitely there under flags Should I be concerned?

<comment><USER61> Your processor isn't affected. It would be i[357]-[67]xxx processors only.

But a new computer may serve you well...

</comment></comment><comment><USER62> One of many typical erratum... nothing to see here, been patched months ago. Most people are unlikely to ever encounter it even if unpatched.

</comment><comment><USER63> Is it fixed or not? Beginning of post says to disable hyperthreading but then goes on to say Intel fixed this with a microcode update.

</comment><comment><USER64> This is just great! Just yesterday I got a new laptop with a skylake processor. Now I wonder whether I experienced that bug today as I got kicked out of dosbox (on debian) for no apparent reason. In the config file I had to change the value of 'core' in the cpu-section from 'automatic' to 'normal'. Could be something entirely different but it is a funny timing.

</comment><comment><USER65> Well, at least Intel acknowledges, documents and finally fixes these CPU bugs (via microcode updates).

AMD on the other hand doesn't even acknowledge an issue when multiple customers report problems. See this Ryzen bug: [https://community.amd.com/thread/215773](https://community.amd.com/thread/215773)

<comment><USER24> Huh? There are plenty of AMD employees in that thread who have acknowledged the problem. They're "looking into it", but just seem to have no progress to report yet, and suck at keeping people in the loop.

<comment><USER66> And at least one person near the end of the thread reports the problem occurs when ASLR is turned on, for what it's worth: [https://community.amd.com/thread/215773?start=105&tstart=0](https://community.amd.com/thread/215773?start=105&tstart=0)

</comment></comment></comment><comment><USER67> Does this affect execution of Ocaml runtime, or only the Ocaml compiler?

<comment><USER28> It affects code generated by the OCaml native compiler, which includes the OCaml compiler itself since it is written in OCaml. See also: [https://caml.inria.fr/mantis/view.php?id=7452](https://caml.inria.fr/mantis/view.php?id=7452)

It also affects code generated by GCC, but apparently GCC is less likely to generate code sequences which trigger the CPU bug.

<comment><USER68> > It affects code generated by the OCaml native compiler

Possibly, but that was not the issue here. It's clear from your own link that the crashes were due to _C_ code in the OCaml runtime (used by the compiler itself), which is written in _C_ and was compiled with _GCC_ at -O2. See [https://caml.inria.fr/mantis/view.php?id=7452#c17129](https://caml.inria.fr/mantis/view.php?id=7452#c17129)

<comment><USER28> Indeed, you're right.

</comment></comment></comment></comment><comment><USER69> has anyone affected by this bug tried using a kernel configured with hyperthreading support disabled? would that work?

</comment><comment><USER70> So what does this mean for the thousands of new MacBook Pro 2016/2017 owners out there?

<comment><USER71> Nothing, since they've been running their laptops without issues (it would have been all over the news if it was some widespread issue) for 2+ years.

At some point in the near future Apple will package the microcode fix in an update, and that will be it.

<comment><USER72> I've run into an issue where switching users causes a crash on my 2016 MBP. Many more people are having this issue, according to the Google.

Also, up until the end of 2016, Apple didn't use Skylake processors, so it wouldn't be 2+ years.

</comment></comment></comment><comment><USER73> The poor guys from OCaml who found the bug. Imagine how much debugging it takes to find such an issue and narrow it down to the precise register sequence. I guess since it's a hyper threading bug it even depends on multiple threads doing certain things at the same time. Usually you trust your CPU to execute code properly.

</comment><comment><USER74> Intel's communication is incredibly poor. Errata exist for all CPUs but this one is quite important and resulted in no proper public communication it seems.

</comment><comment><USER75> Am I hellbanned?

<comment><USER76> nope

<comment><USER75> I was for a while there. Heisenban?

<comment><USER76> What makes you think you were?

<comment><USER75> Couldn't see multiple comments I made in unrelated threads when reading from an incognito tab. Unless comment delay for non logged in viewers is an undocumented feature?

Or this is inception level hellban, where some bots and devil curators lurk. What is even real.

Btw good to see your Lego contraption article in IEEE Spectrum.

<comment> vertex-four Pages are cached for significant lengths of time for non-logged-in users.

</comment></comment></comment></comment></comment></comment><comment><USER77> So if I understand correctly, this was known all along?

</comment><comment><USER78> Great, pay a premium for the top of the line CPU to get anything more than 4 threads, that disable it...

<comment><USER79> Only until a fix is available, if it isn't already yet.

<comment><USER80> It is, the issue being fixed was the only feedback the OCaml community received.</comment></comment></comment>


I've been hacked :( - <AUTHOR>

I'm ashamed to admit it but one of my machines was hacked. It was a media server running an older linux distro, I more or less forgot that box was still up and running in a house that is up for sale. Last week when I went there to turn up the heat so the pipes wouldn't freeze I noticed I couldn't use the machine to check up on some websites. I figured it had crashed and brought it back down south with me to have a look at what the cause was.
So, the cause was pretty simple, someone managed to get in through my not-so-carefully concealed backdoor, how they managed to crack a 20 digit root pw is something I'll never know.
Lesson learned, even old and rarely used systems need to be kept secure and up-to-date, the box was sitting on a 10 Mbit adsl line, most likely it was used for some not so nice purposes. <comment><USER2> if it was an older linux distro, they probably DIDN'T crack your 20-digit root pw, rather exploiting a bug somewhere else?

</comment><comment><USER3> I hope you had good backups. :-)

<comment><USER4> hey there. This is totally irrelevant but i wanted το know how you manage το be so active on HN. Did you take any breaks i missed?

<comment><USER3> My activity level varies. Some weeks I don't make a single comment.

Right now I'm relatively active due to (a) having released a new version of Tarsnap yesterday, and (b) not wanting to start anything major until after Christmas.</comment></comment></comment>


Tesla says its Model 3 car will go on sale on Friday - <AUTHOR> https://apnews.com/9e7afbbfbc234b688032f7c4b37d5bbd/Tesla-says-its-Model-3-car-will-go-on-sale-on-Friday <comment><USER2> Hmm, so back on track on the release timeline. I wonder did they manage to make it with their custom cells?</comment>


Hacker News in Chrome OS Tablet Concept Vid - <AUTHOR> http://www.youtube.com/watch?v=debO2FroXA0&feature=player_embedded

<comment><USER2> <http://news.ycombinator.com/item?id=1094091></comment>


Ground-Penetrating Radar Reveals Entire Ancient Roman City - <AUTHOR> https://www.gizmodo.co.uk/2020/06/ground-penetrating-radar-reveals-entire-ancient-roman-city/ <comment><USER2> That's very impressive. Someone should take that rig out into the desert and see what turns up.

<comment><USER3> Yes. But also the continental shelfs. (If it could be made to work under water at all.)</comment></comment>


Releasing early and often... how it failed for us [extended version] - <AUTHOR> http://behindtheclock.timmyontime.com/post/85858089/releasing-early-and-often-how-it-failed-for-us

<comment><USER2> There's a subtle difference here that isn't being highlighted: Releasing often does not mean giving in to feature creep. Feature creep and lack of coherent direction was the failure, not release timing nor release frequency.

Releasing often is about gauging user feedback to evolve features, seeing how user's really use things and discovering what nobody foresaw. That, however, does not mean that you're supposed to give in to each and every feedback request from users. Most of all, releasing early does not absolve you of the responsibility to consider the effect the feature will have, in either its requested form or your translation thereof, on the direction of your product.

To expand on that, your users will have ideas for features that would take your product in a direction that you do not want to go. Releasing often does not mean that you have to go that way. It's perfectly fine to say, "You know what, we're not going to build that," and still keep releasing changes every couple days. Users provide feedback, but ultimately, you control the direction of the product.

So the question becomes: (1) Do you embark on this journey as a ship, taken by the winds and currents of user feedback wherever they may roam? Or, (2) Do you get out some oars and influence your path.

Remember, it was your vision that caused you to start this. You shouldn't discount that just because users want things you're not providing. That's not to say that you shouldn't listen to user feedback, just that you have to decide upon your philosophy and either stand firm with your product direction, be comfortable with having the direction swept out from under you when the site begins to grow, or drift somewhere in between.

<comment><AUTHOR> I don't think we were the prey of feature creeps. The human factor of wanting to release often caused us to lose our vision. In a perfect world, it wouldn't happen but we're not part of this world.

</comment></comment><comment><USER3> The article is nowhere near as controversial as the title makes it sound. You released what you called "half-baked" ideas, so it's no wonder it didn't quite work.

Clearly there is a "too early": taking release early and often to its logical extreme you would first release a "Hello World" app then extend in thousands of iterations of 1 line of code, which is clearly nonsense.

Look at the positives - you learned a hell of a lot about your market and development from this experiment, so I'm sure the next version will be a success.

<comment><AUTHOR> It was half-baked because we felt the urge to release often. I consider this experience very positive, we learned a lot but meanwhile, our product had to fail and now, we have to resurrect it.

<comment><USER4> But that's not what release often means. If you've got a half-baked idea, then it's half-baked regardless of when and how often you release.

<comment><USER5> Releasing often has lead us to stop seeing the bigger picture. I think the danger when you release often is to rush the releases... and in the end transform what was a great idea into a half-baked product. I don't want to say that this statement is always wrong, because it certainly isn't, but I think people should approach it with care and stop applying it like it was a God commandement.

<comment><USER6> > ... but I think people should approach it with care and > stop applying it > like it was a God commandement. Isn't that the case with _any_ guideline ?

Guidelines like 'Release early, release often' are just that, guidelines. Take any guideline to its extremes and it will just collapse. They are just there to 'guide' your _thinking_, and that's something no-one else can do for you.

</comment></comment></comment></comment></comment><comment><USER7> Now, this I can comment on.

As others have pointed out, you should be more hesitant to call this a failure. You've learned a lot about your market, and you've also learned a lot about your vision, by exploring it "hands-on". Would you have gotten that if you'd instead spent 12 months developing your product before releasing it? Probably not. In short, it's best to err on the side of releasing too often than not often enough.

But the more important point is a clear demonstration that you can't replace a project manager with a motto. "Release early and often" is a good practice, but all practices need to be adapted and tailored to your specific project. You can't just follow them dumbly. A project manager's job is to understand the specific circumstances of your project, pick the right practices at the right stage so that your project goes as well as possible, then adapt and evolve those practices as the project goes along. No single practice is ever going to be always right.

</comment><comment><USER8> To me, you just did everything right. The idea of releasing early & often is to learn about your market, understand what your users really need and what your product should be. Could you have done your 'grand scheme' release without the experience gained during those 2 years?

<comment><AUTHOR> Writing the post, that's what I realized. The problem is that when we had enough experience, we didn't stop to "release often" and it hurt us more than it helped us.

<comment><USER8> good point... I fear we're at that stage :-)

</comment></comment></comment><comment><USER9> Has it "failed"?

You have a user base, and you've experimented with lots of features very quickly. You now you have a very clear idea of what you want, what the market wants, and a sense of how different features and implementations contribute to that.

Did you have such a clear idea at the beginning? Could have have gotten this clarity in any other way?

Prototyping won't tell you the right way, but it gives you concrete terms to think within: by holding some aspects constant, it's easier to reason about the remaining aspects. Prototyping is an aid to thinking.

But I feel your pain; this is an ordeal. It would be so much less frustrating to know how to do everything perfectly in the first place. :-)

<comment><USER10> Agreed. Releasing early and often didn't fail them. It sounds like they found out a _lot_ about their users, they found out a lot about what their application should _really_ be and how it should really work.

They also found out that releasing early and often doesn't mean you _have_ to develop and release every half baked new feature idea as soon as it pops into your head! :-)

</comment></comment><comment><USER11> As others have already said, to me the definition of "release early and often" doesn't mean "release something as soon as possible". But rather...

Release Early: Find the minimum amount of features needed to let your customer achieve their goal, implement just those and release it.

Release Often: Stage the release of new features rather then letting a load stack up and releasing them all at once. Release feature, receive feedback, refine and repeat (Wow 4 Rs!).

If something is not right or not finished. It should be kept back.

A philosophy shouldn't be the determining factor as to what and when things are released, only _you_ can decide that.

</comment><comment><USER12> Nice example of how releasing early and often can go bad... on many levels (dual submission)

</comment><comment><AUTHOR> After bad comments on how short was the first post, here is the new version. We'll see if I get more comments on a short post or a long post.

<comment><USER13> Of course it won't. You submitted the same story twice, instead of just fixing the first one.</comment></comment>


ESR: Ego is for little people - <AUTHOR> http://esr.ibiblio.org/?p=1404 <comment><USER2> On the one hand, I kind of know what he means. What he's calling "A-listers", I call "graceful overachievers". People who get an _incredible_ amount done, but never seem to break a sweat; who are occasionally irked, but have taken the measure of their own capacities, and are well satisfied by them, and by using them.

On the other hand, this writing doesn't feel like the work of a graceful overachiever. It feels like a rationalization of the man's own loneliness. The graceful overachievers I know are _warm_ people, who see the good in the people they're dealing with, warts and all, and who respect that good.

<comment><USER3> I agree that his basic point is correct. If you spend time in any subculture that has some sort of skill stratification, you will notice that most of the people at the top lack an ego. It's typically the people that are trying to reach the top step that do.

<comment><USER4> Yeah sure when you are on top but then there is the fall from grace. As you become less relevant or get superseded. That's when the ego comes out, tantrums, destructive behavior, etc.

<comment><USER5> I'm not sure that esr reached "the top". Perhaps on the speaking gig tour, and yes he's written a couple books.

But he's never achieved what he so likes to claim.

He claims to be a "core linux developer", yet he has no code in the kernel, and CML2 was flatly rejected.

He used to claim that he contributed to GNU starting in 1982, but when I showed that was impossible, he corrected to "mid-80s" (its 1987.)

I think he feels he was on the way up, met his limitations, and has since been scrambling in an attempt to maintain the position he held in 1999.

</comment></comment></comment></comment><comment><USER6> Eric S. Raymond has become such a ludicrous parody that it just seems cruel to make fun of him.

</comment><comment><USER7> > I'm going to use myself as an example now, mainly because I don't know > anyone else's story well enough to make the point I want to with it. I'm the > crippled kid who became a black-belt martial artist and teacher of martial > artists. I've made the New York Times bestseller list as a writer. You can > hardly use a browser, a cellphone, or a game console without relying on my > code. I've been a session musician on two records. I've blown up the > software industry once, reinvented the hacker culture twice, and am without > doubt one of the dozen most famous geeks alive. Investment bankers pay me > $300 an hour to yak at them because I have a track record as a shrewd > business analyst. I don't even have a BS, yet there's been an entire > academic cottage industry devoted to writing exegeses of my work. I could do > nothing but speaking tours for the rest of my life and still be overbooked. > Earnest people have struggled their whole lives to change the world less > than I routinely do when I'm not even really trying.

[no audible dialogue]

<comment><USER8> Really makes you wonder who he's trying to impress with all that.

And at $300 / hour he's having a whole population of lawyers laugh at him to boot...

</comment></comment><comment><USER8> What's with the vendetta John ?

Your Alan Turing efforts put you in a class of your own, this ESR bashing is detrimental.

Let him stew, outcode him or ignore him, it's not worth it.

<comment><AUTHOR> I didn't post this because of a vendetta. I thought he had some good points about A-listers and it was interesting for HNers.

Clearly, I don't agree with his self-assessment as an A-lister, but the article has some interesting points. But that's partly because my evaluation of him is that he's not, and partly because I don't think self-assessment really counts.

<comment><USER9> It's my experience that most decent programmers, and even some crummy ones, think they are in the top 1%. It's a lot like poker - everyone thinks they're way above average at it.

<comment><USER10> I saw a study a few months ago on that, I think it was linked on Overcoming Bias,but I'm not sure. Apparently, most people rate themselves in the 3rd quartile; everyone under average thinks they are somewhat above, and people in the upper quartile generally over-estimate the average, thinking most are more like themselves, so only those who are actually in the third percentile are (accidentally) accurate in their self-assessments.

</comment></comment></comment></comment><comment><USER11> Raymond's point about people at the top not needing to to self-promote is something I've heard described many times before. I would call it trite, actually, but my googling is failing me so I can't find examples to back that up.

One very eloquent description I've seen is "The luxury of humility." Basically, a guy like Einstein had the luxury to declare himself horrible at math (for example) because his reputation as a physicist and mathematician was so solid that nothing he said could possibly dent it. Instead, any self- deprecation he did would simply bolster his reputation for humility.

An unproven physicist, on the other hand, would not be advised to mimic Einstein in declaring himself bad at math because people would be more likely to take it seriously and dismiss his work as probably containing errors.

That said, Eric Raymond used to annoy me, then he became this sort of perversely amusing thing (about the time ELER was running). Now I have to say that I can't read this kind of stuff without feeling sorry for him. He's a textbook example, or at least his writing is, of false bravado vainly trying to mask almost limitless amounts of insecurity.

<comment><USER12> Einstein was certainly a great physicist, but not a mathematician. He was really bad at math, it wasn't false modesty.

</comment></comment><comment><USER13> This is one of the most egotistical and self centered writings I have (partially) read in a long time.

I quit reading when he started using himself "as an example". Talking about himself seemed to be the point of this post.

<comment><USER14> Everything ESR has written about hacker culture boils down to "hey, people like me are really awesome!" and often not much to how things really are...

</comment></comment><comment><USER15> _You can hardly use a browser, a cellphone, or a game console without relying on my code._

Any guesses? I'm pretty sure this phone doesn't use fetchmail.

<comment><AUTHOR> I believe he's referring to the fact that he was at one time the maintainer of giflib (or libgif) and that he contributed some code to libpng. Since these are, he claims, vital to all those items you mention then we are all using his code.

<comment><USER2> That's right. People asked about this in the comments on the post. His answers are here:

<http://esr.ibiblio.org/?p=1404#comment-242133>

<http://esr.ibiblio.org/?p=1404#comment-242156>

Bottom line: libgif and libpng.

<comment><USER15> _CompuServe described GIF, and then Gershon Elber and I made an open-source implementation that became ubiquitous_

Worth noting that multiple years span the time between when Elber actually wrote giflib and when ESR added 2 functions and 3 utilities to it.

</comment></comment></comment></comment><comment><USER16> There is no such thing as an A-list. If you think that you are in the A-list because you are a worldwide renown developer, you can always be better, and be one of the best developers of all times. Or one of the biggest people of all time. You can always be better.

So you think you are the best mathematician all around? You can still compete with Gauss.

</comment><comment><USER17> IMO, Ken Burnside's comment on ESR's post (#5) was better than the article.

<comment><USER18> "It's tempting to pigeon-hole Eric's history as 'loud self display' and 'overinflation of accomplishments'" <http://esr.ibiblio.org/?p=1404#comment-242109>

</comment></comment><comment><USER19> Although I've never met Mr. Raymond, since his own measures (self-display, insecurity, constant approval-seeking, overinflating one's accomplishments, etc) would lead most to the obvious conclusion that the he is either a small person or a hypocrite, I think he may actually be attempting some kind of transcendent Andy Kaufman performance humor - the real joke being the predictability of everyone's reactions.

</comment><comment><USER10> I think that the real reason the best of the best don't display much ego, is that they are primarily focused on whatever it is they do, rather than on themselves; that is how they got to be the best in the first place.

</comment><comment><USER20> I am redoubling my efforts to actually learn programming, for the sole purpose of outcoding this yahoo. Shouldn't be hard.

</comment><comment><USER21> I would like to hear what Alan Kay has to say about that (or Terry Pratchett or ... ).

</comment><comment><USER5> Why does Eric Raymond remind me of Glenn Beck?

</comment><comment><USER18> ESR: What an Ego!

</comment><comment><USER22> it does seem faintly absurd that he's pushing satori whilst citing examples of the pursuit of boats and hoes.

</comment><comment><USER23> If you have to declare yourself a member of the A-list, you aren't.</comment>


Why Political Liberty Depends on Software Freedom More than Ever - <AUTHOR> http://www.softwarefreedom.org/events/2011/fosdem/moglen-fosdem-keynote-highlights.html

<comment><AUTHOR> Full transcript here: [http://www.softwarefreedom.org/events/2011/fosdem/moglen- fos...](http://www.softwarefreedom.org/events/2011/fosdem/moglen-fosdem- keynote.html)</comment>


10-year Treasury yield plunges below 0.5% - <AUTHOR> https://www.cnbc.com/2020/03/09/10-year-treasury-yield-plunges.html <comment><USER2> It's getting increasingly difficult to say we're not entering a recession. Pretty much every leading indicator is flashing red now. I'm expecting Q1 earnings reports and forecasts in a month to be the nail in the coffin.

<comment><USER3> Doesn't seem like something that should catch anyone by surprise.

That said, it seems like this recession could have a significantly different flavor to it than the others in recent memory.

As they say: All happy families are alike; each unhappy family is unhappy in its own way.

(Credited to Tolstoy where I looked it up just now.)

<comment><USER4> This has got to be the best telegraphed recession of all times. I cannot believe that anyone having skin in the economic game didn't know that it is likely coming. Come on, don't be ridiculous.

<comment><USER3> I really don't understand what it is you're replying about since the first line of my comment was:

> Doesn't seem like something that should catch anyone by surprise.

</comment></comment></comment></comment><comment><USER5> Things are definitely looking bad, but given how optimistic the market has seemed over the past months even with lots of bad news coming out, I wouldn't be surprised if there's a pretty sharp recovery once Covid-19 is contained.

<comment><USER6> When and how do you see it being contained?

<comment><USER7> Doesn't matter if it is contained. If people accept it as normal (i.e.: full global spread) that's enough. There are bigger pandemics people have adopted to (AIDS,flu,etc...) a vaccine would help too.

The market fears are not a result of being afraid people will die. It's mostly around consumer spending,containment/quarantine efforts and supply chain stability.

This by itself is a very recoverable crisis, you don't need bailouts and mergers like in 2008. Nothing has collapsed (yet), which means everyone is trying to "buy low" as soon as any sign of long term recovery is seen. The only big fear is how politicians might throw gas into the fire for certain political ends.

<comment> blaser-waffle Not sure why this is being downvoted. This is generally correct:

> The market fears are not a result of being afraid people will die. It's > mostly around consumer spending,containment/quarantine efforts and supply > chain stability.

It's a nasty virus, but this isn't the Spanish Flu devastating the post-WW1 landscape. It is absolutely going to screw up productions schedules and messing with the supply chain. Turns out if millions of people have to miss work the economy suffers, go figure.

<comment><USER7> Probably because of the last bit about politics, that was just me expressing a paranoia but to many their politics is like a religion to them and they assume I meant their side in my comment (I just meant politicians in general,plenty act in bad faith)

</comment></comment></comment></comment></comment><comment><USER8> This isn't only because of COVID-19. The OPEC+ union between Russia and Saudi Arabia broke down yesterday. The Saudi's are now flooding the market with crude and are likely going to increase production to record levels. Crude is down 30% as of 3/9 1AM EST. This uncertainty (plus people moving out of energy bonds into treasuries) is also driving the flight to safety.

</comment><comment><USER9> There are three solutions:

1) Government makes more treasuries, sells them to the fed, and spends the money on infrastructure. That increases government debt, but improves our deflation situation and shrinks the loan bubble a bit. Preventing a deleveraging.

2) Government literally prints money, and gives it to people. That will rapidly increase inflation, which will increase corporate profits, shrinking the loan bubble a bit, preventing a deleveraging.

3) Don't do 1 or 2 because it basically redistributes wealth. Wait for rich people to spend their massive wealth on CPI-style goods and services, causing poor people to eventually have and spend more money. This takes aeons.

As far as I can tell, the powers that be have decided that #3 is the solution, and absolutely refuse to have a stable monetary system that involves giving anything to poor people.

<comment><USER10> In the economically prosperous portions of our nation, inflation is doing just fine. Housing prices have performed phenomenally in the past decade. The overall CPI understates inflation because there's a great number of areas that aren't economically relevant in the U.S. and consequently haven't experienced the accompanying inflation.

</comment></comment><comment><USER11> Jeez, this really isn't the best time to start the process of getting my first job post grad school.

<comment><USER4> This too shall pass.

Also a recession is a cleansing thing (Austrian school). A lot of unproductive people will be fired and a lot of stupid projects will be shut down, creating space for new ventures. You should take risks exactly during the time of a recession, not during the time of market & general confidence all time highs. Same with young age - take risks when you're young and your downside is small.

But it ain't going to be easy.

(contingent on the recession actually materializing).

<comment><USER12> For a novel that romanticizes this idea that recessions are the time to take risks, see _The Driver_ by Garet Garrett

<comment><USER4> Ahh, the times of bimetallism. Bimetallism was the Bitcoin of the times, railroads were the "tech" of the times. Robert Shiller has a very entertaining comparative research between Bitcoin and bimetallism in his book Narrative Economics: [https://youtu.be/QV0JrMV5nnc](https://youtu.be/QV0JrMV5nnc)

</comment></comment></comment></comment><comment><USER13> Every year the flu kills 640,000 people world wide. Right now we are at 3648 from coronavirus. Also there is a lot of evidence to suggest that the actual number of infections is much larger than the reported numbers. This means that the actual death rate is much lower than what is reported.

All of this smells like a massive over-reaction to the coronavirus.

There has been a correction to world markets going on for a while with the US being a possible exception. What actually shakes out it tough to say. Sadly, the markets are controlled just as much by sentiment as by actual hard data so...

<comment><USER14> > Every year the flu kills 640,000 people world wide. Right now we are at 3648 > from coronavirus.

Great. How many people will die if coronavirus infections spread as widely as flu infections?

<comment><USER10> The lack of a reputable statistic is concerning. I found the number 480,000 deaths (only U.S., not a global figure) circulating on sites including Daily Mail, Business Insider, /r/China_Flu, and abc14news.com, a domain registered in late 2018 and may or may not have any relation to ABC News the company.

<comment><USER15> Answer: it does not. Pretty skeevy, since they're clearly hoping people will confuse it with a local ABC broadcaster.

[https://abc14news.com/about-us/](https://abc14news.com/about-us/)</comment></comment></comment></comment>


Ask HN: Need More MOOC on Discrete Math - <AUTHOR> Mit's videos are good but no solution to pset or exams. Makes it tough to self learn.<p>Other than one in coursera, are there any MOOCs with lecutre videos and pset/exam with solutions? <comment><USER2> Coursera is really good. Introduction to Discrete Mathematics for Computer Science | Coursera [https://www.coursera.org/specializations/discrete- mathematic...](https://www.coursera.org/specializations/discrete-mathematics)

Alexander Shen is one of the professors back in school his book helped me in stuff related to competitive programming.</comment>