Linux is Obsolete (1992) - <AUTHOR> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D <comment><USER2> Though history seems to prove him wrong, Tanenbaum wasn't incorrect.

Linux to me is an example of the wrong thing at the right time. Linux embracing Posix and fully supporting Intel gave programmers exactly what they wanted right at the nascency of the dotcom boom. Apache, MySQL and PHP needed a home that wasn't Windows ... and Linux provided that home on the best dollar-for-dollar processors on the planet.

If Motorola or IBM had challenged Intel with cheap, better processors then history might have looked different because Linux wouldn't have been a solution on those platforms.

Linux works well enough I suppose, but the fact that we have this gigantic mess, where we run an OS, and then run a hypervisor on it, and then run more copies of an OS, and then finally get to run our application code, tells me something is quite wrong.

The fact that unikernels are even a thing tells me that people DO feel the pain of monokernels and yearn for something simpler. Securing a monokernel like Linux, even one so open and scrutinized, is really, really hard. There is just so much surface area in the kernel to attack. Everything is so heavyweight.

I think Tannenbaum was right, but he just wasn't enough of a hacker to get things done in time to catch the wave that the dotcom boom created.

To me the dream would be something like Google's new Fuschia OS where everything is capability-based so security is built into the OS concept from the very beginning.

<comment> Const-me > and Linux provided that home on the best dollar-for-dollar processors on the > planet.

FreeBSD was very competitive. They both were launched around the same time, first version of Linux released in 1991, 386BSD in 1992. They share a lot of features, i386 target, posix compatibility. BSD pioneered some very important technologies, kqueue (epoll was couple years later in Linux), jail (docker was a decade later), etc.

I still don't understand why everyone uses Linux now, but BSD only stayed in very niche markets.

<comment><USER3> What timeframe are we talking about here? Maybe I'm late to the party, but even for "special interest" Linux in the late 90s was already kind of well- known compared to the BSDs. (I was in school back then, no internet, and only learned about Linux from some folks already studying computer science). And I'm just using that point of data because when I came in contact with Linux there wasn't really much about FreeBSD, so either that was my bubble or it was technically competitive but had already lost the popularity contest.

<comment> Const-me > it was technically competitive but had already lost the popularity contest.

I think that's the case. It never gained traction outside of niche markets. Most ISPs in late 90s were running a lot of BSD-based servers, companies like Apple, Juniper, Sony, Nintendo are still using BSD kernel and/or other components in their products, but it was and still is relatively little-known OS.

I can't say I'm happy about that. I'm currently working on an embedded Linux- based firmware, I'd gladly switched to BSD. Maybe it's just my irrational fears but I feel BSD is more reliable. However, that would require too much work to accomplish. I need stable and reliable GPU and WiFi drivers; hardware vendors (ARM and Realtek, respectively) only ship drivers for Linux, and I don't think I'm competent in that area to attempt to port them, I never did substantial work on Linux nor BSD device drivers.

</comment></comment></comment></comment><comment><USER4> > Apologies to ast, and thanks to John Nall for a friendy "that's not how it's > done"-letter. I over-reacted, and am now composing a (much less acerbic) > personal letter to ast. Hope nobody was turned away from linux due to it > being (a) possibly obsolete (I still think that's not the case, although > some of the criticisms are valid) and (b) written by a hothead :-)

> Linus "my first, and hopefully last flamefest" Torvalds

Comparing this to his more recent emails, it doesn't seem him he has mellowed with age!

<comment><USER5> Yeah, I came here to post that "last flamefest" part. Oh Linus, it certainly won't be your last...

</comment></comment><comment><USER6> > _" Be thankful you are not my student. You would not get a high grade for > such a design :-)"_

It's really amazing to read and see all sorts of good points from both sides, and know that if it weren't for the benefit of hindsight, I'm not really sure which side I would agree with.

But I really strongly get the feeling that Andy had a great opportunity thrown into his lap, but by looking at MINIX as a "non-serious" hobby (as Linus implied) that he only did for fun and to unwind, and by not really listening to his user base (make it free, fix filesystem race conditions, add POSIX compatibility, etc), he really threw the opportunity away for it to grow. Which is fine if growth was never the goal.

And sure, a project owner doesn't _have to_ say yes to every feature, and they actually probably shouldn't. But you have to let what you're creating evolve into something that meets needs, and turn into something different. Look at the first page of commits on Semantic-UI's repo. It was called Origami (then Shape) and was meant for doing 3D stuff in JS, before he renamed it to Semantic and turned it into a JS-based version of Bootstrap. Terrible example and doesn't really apply here but I remembered coming across that fascinating bunch of commits the other day and wanted to share it with someone.

<comment><USER7> I've always thought, however, that Torvalds was in fact Tanenbaum's student in Univ. of Helsinki... Well, if ast stated that linus was not, then, obviously, he was not at all.

<comment><USER8> Tanenbaum has never taught at the University of Helsinki, so it would have been difficult for Torvalds to have been his student there...

<comment><USER7> Good point! Andrew Stuart Tanenbaum (born March 16, 1944), sometimes referred to by the handle ast,[6] is an American-Dutch computer scientist and professor emeritus of computer science at the Vrije Universiteit Amsterdam in the Netherlands

</comment></comment></comment></comment><comment><USER9> Discussed in 2009: [https://news.ycombinator.com/item?id=545213](https://news.ycombinator.com/item?id=545213)

2012: [https://news.ycombinator.com/item?id=3785363](https://news.ycombinator.com/item?id=3785363)

2014: [https://news.ycombinator.com/item?id=7223306](https://news.ycombinator.com/item?id=7223306)

2015: [https://news.ycombinator.com/item?id=8942175](https://news.ycombinator.com/item?id=8942175) and [https://news.ycombinator.com/item?id=9739016](https://news.ycombinator.com/item?id=9739016).

</comment><comment><USER10> In a way Tanenbaum won.

Micro-kernels are everywhere on high integrity computing, run on the radios of mobile OS.

User space drivers, containers, hipervisors, Project Treble are all examples of trying to bend Linux into the same design.

<comment><USER11> They were both right, it's just dependent on the timeframe.

Monolithic kernels "won" because they made pragmatic design decisions based on the hardware and software available. Linux in particular worked well partly because it built on a 20-year-old OS design.

Microkernels have had another ~30 years to develop and they are now performance competitive with monolithic kernels [1]. There is still a large legacy investment in monolithic kernels, but as security becomes increasingly important ... it's hard to see monolithic kernels staying the dominant form of OS design in the future.

Tanenbaum is a computer scientist, Linus is a computer engineer.

[1]: [https://os.inf.tu-dresden.de/pubs/sosp97/](https://os.inf.tu- dresden.de/pubs/sosp97/)

<comment><USER12> The article you linked to is 21 years old. Microkernels is the fusion power of software, always 50 years in the future. They're great in theory, it's just that nobody got them to work outside the lab.

As for security, yes, there are still vulnerabilities in the Linux kernel, and a microkernel might be helpful here, but it seems to me that the high-impact vulnerabilities we've seen in the past few years have been outside the kernel (spectre/meltdown and rowhammer in hardware and heartbleed in userspace). It's not obvious that microkernels will give a big enough security benefit for the investment to catch the technology up to the state of the art.

<comment><USER10> Funny because apparently they run on my phone broadband radio chip, in many industrial automation control systems, medical devices, avionics and cars.

It sounds pretty much outside the lab to me.

</comment></comment></comment></comment><comment><USER13> For those that don't know.. Tannenbaum wrote the book on Operating Systems... Well a book. I think his OS Minix[2] is in there. Its on every intel CPU, but I think that was news to Tannenbaum.

This argument was at its root a "theory" vs. "getting it done" now argument. I think thats why it resonates.

[1][https://www.amazon.com/Modern-Operating-Systems-Andrew- Tanen...](https://www.amazon.com/Modern-Operating-Systems-Andrew- Tanenbaum/dp/013359162X) [2][https://en.wikipedia.org/wiki/MINIX](https://en.wikipedia.org/wiki/MINIX)

This is a debate about how OS's should be structured. There is some merit to Tanenbaums MicroKernel approach, but ultimately its slower and for an OS that matters, thus Linux being ascendant . Also everywhere gcc was ported could compile and run linux.

Microkernels "lost" but there was a microkernel called "Mach" worked on by Avie Tevanian who went to Next then to Apple. I think OS-X is kinda microkernel based (if they're still using XNU which is loosely based on the mach microkernel.).

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

I still miss HPUX RTE for PARISC(Real Time Extensions) for sending jobs to specific processors or processor sets, disabling interupts....

If you like OSs. I like the case studies in the dinosaur book: (stupid text- book prices though....)

[4] [https://www.amazon.com/Operating-System-Concepts-Abraham- Sil...](https://www.amazon.com/Operating-System-Concepts-Abraham- Silberschatz/dp/0470128720)

<comment><USER14> > This basically was at its root a "theory" vs. "getting it done" argument.

Because worse is better. [https://www.jwz.org/doc/worse-is- better.html](https://www.jwz.org/doc/worse-is-better.html)

<comment><USER15> Copy&paste the link. Do _not_ click.

</comment></comment></comment><comment><USER16> So funny. Linus would be probably kicked out of Tanenbaum's OS class, and most of Andy's predictions were incorrect (still waiting for my GNU/HURD on MIPS). The lesson is not to get discouraged by prevailing winds of academia I guess, they have different objectives, and their processing of reality is on a more abstract level, meaning ideas might look better in theory, but not so great in practice.

<comment><USER10> It is running on the radio chip of your mobile phone.

[https://gdmissionsystems.com/products/secure- mobile/hypervis...](https://gdmissionsystems.com/products/secure- mobile/hypervisor)

<comment><USER17> Which is mildly interesting, but a long way from "microkernels are where OSes are going in the next decade or two (from 1992)".

Microkernels were not a completely worthless idea, and they have appeared here and there. But in terms of OSes, they lost for three decades after Tannenbaum's statement.

</comment></comment></comment><comment><USER18> Netiquette[1] mentioned. I just re-read it after so many years. :) This makes me realize how old I've become (for they made us read some pre-RFC versions before getting accounts to Sun workstations in college). Oh how civilized the online discussions used to be. And how the community self policed, until it didn't[2].

Maybe FB, Reddit and others should put their AI researchers into good use and make people and bots alike take a hard to cheat test on Netiquette before being allowed to post stuff that will be seen by others. And implement a one month 'observation-only' period as suggested by Netiquette[1]... ;-)

[1] [https://tools.ietf.org/html/rfc1855](https://tools.ietf.org/html/rfc1855) [2] [https://en.wikipedia.org/wiki/Eternal_September](https://en.wikipedia.org/wiki/Eternal_September)

</comment><comment><USER19> Tanenbaum reminds me of those "smart people" Art Williams was talking about in his 1987 "Just Do It" speech. Good to learn of another example of "more smart" not being "more successful".

<comment><USER20> He did by creating MINIX. His loss to Linux was not from an unwillingness to get his hands dirty and build something.

<comment><USER21> MINIX was an educational demo. He slapped on a restrictive license even though he didn't make money from it, because his ego didn't want other people to touch his baby. Then he never made time to build anything useful with it. Being right about something you aren't going to build is worse than being a little wrong about something you build.

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

> Its use in the Intel ME makes it the most widely used OS on Intel processors > starting as of 2015, with more installations than Microsoft Windows, > GNU/Linux, or macOS.

That's... not too shabby, if you ask me.

</comment></comment></comment></comment><comment><USER7> Did everybody else reading this just disregard other people's comments on that thread and skip it just to read ast and torvalds debatting?

<comment><USER6> I really thought I was going to, but the other replies provide so much context, plus it's kind of like time traveling and being a fly on the wall in a conversation that took place over 25 years ago. I'm just imagining them all looking like the cast of Friends while sitting at their 15-inch 90s PC screens typing these electronic-mails in software I wouldn't recognize. And you have people chiming in and calling out argument flaws and offering suggestions on new words for "make POSIX" like posixiate. Fun stuff! It's like the comment section of an HN post. Which is funny because HN evolved out of mailing lists like that, and the culture did too.

<comment><USER23> Same feeling here, I usually skim these threads for the big names, but in this case there is so much historical context that makes this a great read. It would be wonderful to have been a subscriber to this mailing list back in the 90's.

<comment><USER24> it was a newsgroup - usenet was still a thing, and not just about binaries, back then

</comment></comment></comment></comment><comment><USER25> Back then, nobody realized how bloated the Linux kernel was going to become, with way too much in kernel space. The kernel is somewhere above 15 million lines of code now.

<comment><USER26> I think AST did. IMHO, drivers belong in user space. There's an exponential number of devices out there, jamming them into the kernel has been a messy chore at best.

<comment><USER27> As someone completely alien to that side of computing except rudimentary stuff most people know, I never understood the reason why the drivers have to be maintained in the kernel tree. Maybe include the most common stuff, but why not have a second, distinct linux-drivers project that maintains those stuff in their own time?

Also, why we don't have a common interface to drivers at least between Linux and BSD by now? I don't like that there's animosity between the two ecosystems. That way we could have, if technicalities permit, a way for many diverse OS models to enter into the competition: if the drivers are written agains a certain standardised interface, one can code-up an OS to support that interface, and just like with POSIX, the OS would have a whole suite of drivers available from day one. Better for the driver authors too.

<comment><USER28> Linux kernel maintainers are actively hostile to the concept of a stable driver ABI. They believe that drivers are best maintained with the kernel so that they can be kept up and fixed.

Given that Linux has the broadest hardware support of any open source OS, and arguably any OS period, it's difficult to say they aren't right.

<comment><USER10> Which is exactly what Project Treble introduces, it converts Linux into a micro-kernel design, where each driver runs in its own process with a tiny kernel presence, communicating over Android RPC mechanisms.

[https://source.android.com/devices/architecture/hidl/](https://source.android.com/devices/architecture/hidl/)

<comment><USER29> Are Treble drivers compatible with Fuchsia? That'd be cool.

<comment><USER10> No idea, but I don't think so as they are completely different architectures.

<comment><USER29> Genode has an ABI for userspace (which includes OS components and drivers) that works across multiple kernels, which are mostly microkernels, but also Linux.

Considering Google designed both Treble and Fuchsia, it's not such a crazy idea.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> > _Of course 5 years from now that will be different, but 5 years from now > everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5._

This will always be my favourite quote from this exchange. Just imagine what desktop computing would look like today had that come to pass.

</comment><comment><USER31> For those readers that are curious who Tannenbaum is, he wrote (the best IMHO) operating systems book [0]. This book contained the complete source of an operating system 'Minix'. At the same time Torvalds wanted to build a OS system. Did Torvalds use/steal or extend the Minix source? It is extremely controversial [1] amount CS types.

[https://www.amazon.com/Modern-Operating-Systems-Andrew- Tanen...](https://www.amazon.com/Modern-Operating-Systems-Andrew- Tanenbaum/dp/013359162X) [0]

[http://wiki.c2.com/?MinixOperatingSystem](http://wiki.c2.com/?MinixOperatingSystem) [1]

<comment><USER32> Because you misspelled it twice, Tanenbaum's OS is called Minix.

</comment></comment><comment><USER33> Network effects don't only depend on quality. Is basically the summation of this whole debate.

If you had 2 teams and both could start from 0 and spend 5 years to develop an operating system most people would probably pick some version of microkernel design.

<comment><USER17> Most people would pick the OS that was of a microkernel design? No way. Most people would pick whichever one was most solid and/or had the most features.

<comment><USER33> I mean for development.

<comment><USER17> Oh, I see. I will not argue against your position, now that I understand it.

</comment></comment></comment></comment><comment><USER34> The most insightful thing about this repost is that Google groups is still around. Tried to find it recently and couldn't. Woohoo!

</comment><comment><USER35> One thing that jumps at me is how childish and rude Linus is in his response. I think at that time he was 23 years old, so an adult.

As a piece of advice to young people, try not to be rude and accept criticism with grace, as the Internet has a long memory and you'll probably not be respected enough for your achievements to be tolerated, like Linus is.

<comment><USER36> Linus is still rude or rather, blunt. To be honest, though, i prefer blunt over fluff or politically correct way.

Way more informative.

<comment><USER37> Bluntness doesn't increase the information content of a message, it's just a way to force one's message through. Everything that can be said bluntly can be said politely, and usually to greater effect.

I'm always confused by people who defend Linus style because it isn't just blunt but often plain insulting for no apparent reason at all.

There are many problems with this. Apart from antagonizing people as already mentioned, if someone is constantly screaming they lose the ability to modulate how serious they actually are. You can rarely tell whether Linus is legitimately upset because he seems almost always upset. It's better to default to politeness if only because if you're actually upset at least I know that I need to pay attention.

<comment><USER38> Some people really appreciate the blunt communications style. Some people don't. I personally believe one should be able to appreciate all communications styles, because it provides you access to more information. Ignoring something smart because one got bad feelings from how it was said strikes me as rather puerile.

<comment><USER27> > I personally believe one should be able to appreciate all communications > styles

Wut? Some communication styles are just "harassment", including Linus'. One can put up with it, but appreciation? BS. Linus is worse than Kalanick.

</comment></comment></comment></comment></comment><comment><USER17> > As a result of my occupation, I think I know a bit about where operating are > going in the next decade or so.

> While I could go into a long story here about the relative merits of the two > designs, suffice it to say that among the people who actually design > operating systems, the debate is essentially over. Microkernels have won.

That's a theoretician confusing theory and practice.

And note that Tannenbaum isn't one of the "people who actually design operating systems". Tannenbaum designed toys to demonstrate concepts, not OSes for real-world use.

And, was Tannenbaum right that NT was a microkernel design? I have this vague memory that the drivers were supposed to be in user space, but they moved at least the video drivers into the kernel for performance reasons.

</comment><comment><USER39> Ah yes, this oldie newsgroup post from ast, the guy whom wrote a bunch of mandatory CS textbooks and MINIX 2 (before the course moved to FreeBSD) which we had to hack on in ECS150. I'm sure he's crazy rich by now from passive income.

A hypothetical kernel&userland like OpenBSD built on seL4 (a-la DragonFly or MINIX 3), implemented in Rust, OCaml or Haskell, with thorough unit, integration tests and perhaps formal proofs, seems like the safest, not necessarily the fastest, kernel approach possible using modern technologies. seL4 communicating by sending messages is really efficient and builds in IPC as a fundamental, low-latency operation.

<comment><USER17> > A hypothetical kernel&userland like OpenBSD built on seL4 (a-la DragonFly or > MINIX 3), implemented in Rust, OCaml or Haskell, with thorough unit, > integration tests and perhaps formal proofs, seems like the safest, not > necessarily the fastest, kernel approach possible using modern technologies.

Seems to me like an approach that would take even longer to implement than Hurd did.

</comment></comment><comment><USER40> If anybody can provide an alternative source for the text thanks in advance. It requires a google login for reading.

<comment><USER41> You can open it in a private browsing window. It only requires login if you were previously logged in to a Google account, and that login has expired. Incredibly annoying.

</comment></comment><comment><USER42> several past discussions: [https://hn.algolia.com/?query=%20LINUX%20is%20obsolete%20(19...](https://hn.algolia.com/?query=%20LINUX%20is%20obsolete%20\(1992\)%20&sort=byPopularity&prefix&page=0&dateRange=all&type=story)</comment>


Should our client (a startup) buy SoftwareEngineeringAcademy.com for $350? - <AUTHOR> http://www.softwareengineeringacademy.com

<comment><USER2> It's long, but if you guys have seacademy, or sea.com then it makes sense. Otherwise, no :\

<comment><AUTHOR> What is your opinion of the value if not $350?

<comment><USER3> from a SEO stand point it is a decent name, From a branding standpoint it is not good. It's probably worth a ballpark of what they are asking.</comment></comment></comment>


Google+ Was Never a Facebook Competitor - <AUTHOR> http://www.readwriteweb.com/archives/google_was_never_a_facebook_competitor.php <comment><USER2> >Contrary to popular belief, Google+ was never created to directly compete for people's time on the internet. A simple, ad free system, Google+ was launched to compete for users' personal data. Becoming the primary platform for social networking would simply be a bonus

So it is a Facebook competitor then?

<comment><USER3> I think the author is trying to make a poorly articulated argument that the _intent_ of G+ is not to "kill" Facebook, but instead improve Google's targeted advertising capabilities. To some extent, this is true, but I'm not sure if it is a relevant distinction. If Google had the option to replace Facebook wholesale, I'm sure they'd jump at the chance. Perhaps "not competing" is merely a way of lowering expectations?

</comment></comment><comment><USER4> Probably one of the worst articles I've read on HN in a while.

The first five paragraphs contain generic filler, which are then followed by the bombshell that more information about users provides greater opportunity for targeted advertising.

Someone's being paid by the word, IMO.

</comment><comment><USER5> I think I understand the author's point. They aren't trying to compete with Facebook, they are just attempting to exist in Facebook's market, make money by all of the same means, and attract the same customers who will then do most of the same things.

Make sense?

</comment><comment><USER6> tldr; g+ is about helping google make tonnes more money; it will do that even after its crappy engagement; don't ask me how.

</comment><comment><USER7> Insert Oceania joke...</comment>


Series A Crunch Worsens - <AUTHOR> http://www.pehub.com/193036/series-a-crunch-worsens/ <comment><USER2> So if these guys are reliable (?) and if I understand this right, from 2011 to 2012 we saw:

* An increase in preferred stock deals, decrease in convertible note deals. (bad)

* if you started in 2011, 50% of you got a series A. Started 2012 - only 33% (bad)

* this is somewhat offset by doubling of seeded companies getting follow-on seed finance (12% - 23%, almost half of the drop above) (good)

Trends:

\- Seed financing is becoming institutionalized (if you see Angellist as an institution)

\- Seed deals grew ~400% and Series A grew by 50% (This is the Series A Crunch right there)

\- Getting Series A needs traction, apparently traction is not being shown by most companies started in 2012. (v bad)

Also:

There appears to be a difference between software companies and "Internet/Digital media" companies. I am guessing content but frankly how can content be 3/4 of the funded market?

It ignores companies funded with less than 1/4 million - so that may well explain the preponderance of "content" companies.

Summary

Overall I like broad sweep reviews, its my years of Risk playing. But it does not look too good for companies taking finance and hoping to drive into millions more on Series A - and only a review of the sub-250K market is going to tell if the world is drying up, or startups are becoming in the old words "too cheap to meter"

<comment><USER3> > decrease in convertible note deals

Why is that necessarily bad?

<comment><USER2> Late reply: bad for start up owners (convertible notes seem to be preferrBle)

<comment><USER3> They're easier and cheaper for startups.

That is distinctly better than good for them.

I've seen a lot of evidence that they aren't.

</comment></comment></comment></comment><comment><USER4> This really doesn't say much about a Series-A crunch.

It doesn't take into account the percentage of those companies who raised a seed round that were _seeking_ a Series-A round. This looks to me as if the article is making the assumption that 100% of companies who raised a seed round were seeking another around, and thus this year a smaller percentage of seed companies actually raised a round.

It also fails to mention whether or not the size of the average seed round grew. If you use HN and TechCrunch as anecdotal evidence, the trend seems to be much larger seed rounds the last two years. This alone could explain the fact that more companies are not actively seeking a Series-A within the first year.

</comment><comment><USER5> Lots more details in the report (PDF): [http://www.fenwick.com/FenwickDocuments/2012_Seed_Survey_Rep...](http://www.fenwick.com/FenwickDocuments/2012_Seed_Survey_Report.pdf)

</comment><comment><USER6> The quoting article spins the article quite differently than the source, which had a "things aren't so bad" message.

</comment><comment><USER7> If by "crunch" you mean "return to sanity"...</comment>


Git: Grafting repositories - <AUTHOR> http://ben.straubnet.net/post/939181602/git-grafting-repositories

<comment><USER2> There's no need for grafts for what they are doing. "git filter-branch --parent-filter" will do what they want without any need to much around by hand with anything in the .git directory. There's even an example in the man page for that command showing how to use it for exactly what they are doing.

</comment><comment><USER3> Grafts allow you to do a bunch of other neat stuff. I use Git as a backup system for SQL dumps, but since the repository will grow a lot I want to throw old dumps away.

So I just create a graft and rewrite my history so that it only contains 7 commits (7 days):

        git rev-list HEAD | sed '7q;d' > .git/info/grafts &&
        git filter-branch -f HEAD

</comment><comment><USER4> I had to deal with this a while ago. Scripts resulting from my troubles are at <http://github.com/mattsta/git-shrink></comment>


TruffleRuby on the Substrate VM - <AUTHOR> http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html <comment><USER2> SVM is super cool, but there's a huge caveat: Not only is it closed source, but you can't even use things it outputs in production. The TruffleRuby wiki notes that the output of SVM is covered by [http://www.oracle.com/technetwork/licenses/standard- license-...](http://www.oracle.com/technetwork/licenses/standard- license-152015.html) which says that you can only use it for testing and not production.

Essentially, you can only get good startup times with TruffleRuby for testing. If you want to use TruffleRuby in production, you can't use the SVM version.

<comment><USER3> I am sure there must be use cases where users need high performance and low RAM with Ruby, but can not move to Go/Rust/Java for critical parts and hence need something like SVM. I just can't think of those scenarios.

<comment><AUTHOR> We're aiming to be 100% compatible with MRI. It's far easier to swap out your runtime than it is to rewrite production code. Of course, situations vary for everyone and each team needs to evaluate on their own.

Prior to joining Oracle Labs, I ran a company that went through TechStars (Boston, 2010). We started with Ruby to get the MVP out. I would even say overall it was architected fairly well. But as we started growing, we hit performance issues that we just didn't have with a smaller customer base. As a bootstrapped company trying to grow, putting everything on hold to rewrite subsystems wasn't a terribly appealing option. We finally decided that it was a necessary evil and were going to move from MRI to JRuby, at which point we'd start replacing pieces with Java. As it turns out, JRuby ended up meeting our performance needs and we didn't have to rewrite anything (modulo code changes needed to run on JRuby). I ended up winding that company down for a variety of other reasons, but I'm happy I didn't become another case study in code rewrites.

<comment><USER3> Good to hear. At workplace we upgrade Java version without changing our code to use newer APIs. So far it is working reasonably well by getting benefit of newer GC and JRE without any code change.

</comment></comment></comment></comment><comment><USER4> The only benchmark that matters is how fast it runs a real world Rails application. It doesn't matter much if it requires huge amounts of RAM and has a long cold start. Developers can use MRI and run CI and production with SVM, much like they do with JRuby now.

<comment><AUTHOR> I think you might be missing the aim here. We already have a release of TruffleRuby that starts cold but has great peak performance. This is done by way of the GraalVM. What's new is we're now able to target a new virtual machine that can provide fast start-up as well.

By far, one of the most common complaints we hear is the start-up time is too slow. The split development model you've describted works for some, but becomes problematic when you want to use extensions specific to one runtime or another. Additionally, a lot of people don't want to run completely different language implementations in development and production.

So, the idea here is to give you a choice. You get to keep the same language runtime but get to choose the VM you want to run it on based on what your current context demands.

<comment><USER4> Ok, understood. Then the other benchmark that matters in the typical Rails workflow is how fast rails c starts, and how fast tests run. If MRI runs tests twice as fasts it's hard not to use it. Think 30 seconds vs 1 minute. It really makes a difference. Or running a single rspec example.

Tests seem a really cold start scenario, even if only a bit of code changes among test runs. Is it possible to save (I don't know what, the internal state of the VM?) for the unchanged parts among runs? Would that even work?

<comment><AUTHOR> Agreed. That's why I presented numbers for running the language specs. It was something I could easily and fairly compare MRI vs TruffleRuby with. And it's representative of what a typical RSpec suite will look like.

With the SVM, we're now at 1s (MRI) vs 9s (TruffleRuby/SVM). Previously, we were at 1s (MRI) vs 68s (TruffleRuby/JVM). There's a lot of ways to look at that data. You could say TruffleRuby/SVM took 9 times as long as MRI and that rules it out. Or you could say it took 8s longer and that's acceptable for my entire test suite, especially if I don't have to juggle multiple versions of Ruby. I really can't say -- that's for each team to decide on their own. But, we're looking to make the decision easier by further reducing that run time.

It could be possible to save the state of the parsed AST and embed that in the binary. It's actually what we do for the core library to help with start-up time. I'm not sure you'd really want to do that for individual codebases though. You would need to rebuild the static binary every time your code changes, eliminating a lot of the benefit of using a dynamic language is the first place. It would be far better if we just make TruffleRuby and the SVM faster, which we're working on.

<comment><USER4> I sincerely hope that you succeed!

</comment></comment></comment></comment></comment><comment><USER5> Interesting to see IBM has also open sourced its JVM infrastructure as Eclipse OMR [0]. Which provides a JIT infrastructure to any existing runtime.

[0] [http://www.eclipse.org/omr/](http://www.eclipse.org/omr/)

<comment><USER3> It is interesting piece of software but to me it seems to say critical business case of in-house JIT infra is gone. IBM lately seems to be betting on Swift for apps and Go for blockchain related infra initiatives.

</comment></comment><comment><USER6> The Substrate VM is still not open source, correct? Are there plans to do so in the near future?

<comment><AUTHOR> That's correct. The script used to generate the compiled binary is open and you can play around with that per the terms of the OTN license, but the SVM itself is closed source. There aren't currently any plans to change that.

<comment><USER7> Well, apparently I'm eating my words in my sibling comment. That's incredibly disappointing, really. (I suppose I'm already having enough fun with Graal though, so I'll temper my sadness!)

Just to be clear: when you refer to the 'compiled binary', what binary are you referring to _exactly_? Is this the 'aot-image' tool inside the Graal OTN builds I was looking at? It was not clear to me if that was _actually_ the Substrate tool or not, because the documentation is very vague[1] -- can any Graal-based language use that tool to test better startup times, etc?

Clearly if SVM is going to remain closed source, I'll have to continue to mostly ignore it (as I've done since I followed Graal), but it would be at least nice to see it "In Action" and what it does to the warm-up time, with my own eyes...

[1] [http://www.oracle.com/technetwork/oracle-labs/program- langua...](http://www.oracle.com/technetwork/oracle-labs/program- languages/overview/index-2301583.html)

<comment><AUTHOR> The "compiled binary" I was referring to your compiled interpreter. The aot- image tools in the GraalVM distribution is just a bash script that sets up a bunch of options to control the AOT compiler (also called the boot image generator). If you look at the end of the aot-image script, you can see how the boot image generator is ultimately invoked. The output product of this script is a static binary of a Truffle language interpreter (we don't AOT guest programs -- those will be run in the AOT compiled interpreter)

Out of the box, the aot-image script has support for building Graal.js and TruffleRuby images/binaries, but you could modify the script to build whatever Truffle language you'd like. This is just our first release of the SVM and those are the two languages we've tested. As the SVM is fairly young and under active development, it's possible you'll encounter missing functionality. But we do have at least one community member on the graal-dev [1] mailing list trying it out.

I can't say whether the SVM will remain closed or not. I really don't know. There just currently aren't any plans to open it.

[1] -- [http://mail.openjdk.java.net/pipermail/graal- dev/](http://mail.openjdk.java.net/pipermail/graal-dev/)

<comment><USER8> > I can't say whether the SVM will remain closed or not. I really don't know. > There just currently aren't any plans to open it.

Then there are no reasons to expect it to be open, as long as it's commercially viable to sell it. This is Oracle we're talking about. Not a company known for its love for F/OSS.

<comment><USER9> >"Then there are no reasons to expect it to be open, as long as it's commercially viable to sell it. This is Oracle we're talking about. Not a company known for its love for F/OSS."

It'd be a real shame if Oracle couldn't see the benefits of open-sourcing SVM. New companies are far less likely to base their tech stack on closed source components when more mature open-source competitors exist, there's too much risk involved.

</comment></comment></comment></comment></comment></comment><comment><USER10> [https://github.com/kostya/benchmarks](https://github.com/kostya/benchmarks)

it looks more speedy than ruby, but also is eating a lot of memory, and for some benchmarks is not that fast :)

Will be interesting with substrate vm if the results or memory are the same.

<comment><USER11> What's the methodology? JIT warmup taken into account or no?

The memory use does seem excessive though. Perhaps a little too much code bloating due to the polymorphic inline caches?

<comment><USER10> I guess not for sure, so most the time will be in interpret mode

</comment></comment></comment><comment><USER12> We can finally combine the speed of Ruby with the light weight of the JVM!

<comment><USER13> But the entire point of this project is that it's a faster version of Ruby, combined with a much more lightweight version of the JVM.</comment></comment>


What should I say if I got promoted for dropping code quality to meet deadlines? - <AUTHOR> https://workplace.stackexchange.com/questions/156659/what-should-i-say-on-my-resume-if-i-got-promoted-for-dropping-code-quality-to-me <comment><USER2> wear the shame proudly.

in 10 years you will have moved up several steps on the ladder using this technique. and probably earned a good salary.

the dept you lead is in constant turmoil, no long term planning is done, the code is brittle and un-understandable and un-changeable, but somehow enough fires are put out for things to almost work.

all caused by you doing something 'quick and dirty', being rewarded for it. and this becoming an example that others follow.

welcome to 95% of the world.</comment>


Comparing HTML5 Mobile Web Frameworks - <AUTHOR> http://www.dzyngiri.com/?p=752

<comment><USER2> This article seems to be very dated.

"jQuery Mobile is the new kid on the block. Announced in August 2010, it's quickly progressed to a very functional Alpha 2."

jQuery Mobile has been out of Alpha for a very long time. 1.0 was announced in November of last year and they are currently in a stable 1.1.0 release. Alpha 2 was announced in November of _2010_.

<comment><USER3> original ...

"JANUARY 23, 2011 - DAVE FELDMAN"

[http://operationproject.com/2011/adventures-in-html5-part- on...](http://operationproject.com/2011/adventures-in-html5-part-one/)

</comment></comment><comment><USER4> I think you hit the nail on the head with this post. Over the past few weeks I have been doing similar research. I have come to the conclusion that there isn't a really great option.

Out of all the frameworks, I am most impressed with Sencha Touch's performance. It was the only one that felt "native" to me.

What I didn't like about Sencha is it doesn't let me use backbone.js, it also looks really difficult to customize the UI if you don't use their "widgets".

Wish there was a better option :(

<comment><USER5> Did you tried jqmobi? It works great with backbone.js

<comment><USER4> I haven't. Have you had any experience with it?

<comment><USER5> Only for some mockups. Worked fine. The biggest complains I would have is that the default themes do not look native.

</comment></comment></comment></comment><comment><USER6> It's hard to imagine we won't get there eventually though. For the time being, there really aren't great options, but that will certainly change in the coming years. Mobile remains in its infancy.

</comment><comment><USER7> I get a 503, is there a mirror available?

</comment><comment><USER4> Has anyone tried jqMobi?</comment>


Show HN: Subcast.fm – Listen to your favorite newsletters - <AUTHOR> https://subcast.fm <comment><AUTHOR> Hello HN!

If you're like us, you have a lot of unread newsletters in your inbox — staring at you waiting to be read.

As avid podcast-listeners, we decided to turn some of our favorites into audio.

subcast.fm allows you to subscribe to some of the best content out there, and creates a custom feed that you can then listen to on your favorite podcast player.

We'd love to hear your feedback and product suggestions!

Best, Ian & Jameson</comment>


Congress just blocked Jeff Sessions from messing with medical marijuana - <AUTHOR> https://arstechnica.com/science/2017/05/congress-just-blocked-jeff-sessions-from-messing-with-medical-marijuana/ <comment><USER2> kinda funny how the parties are flip flopped on this one. Republicans don't want states rights and Democrats do.

<comment><AUTHOR> The Republican Congress is blocking a Republican administration from cracking down on states' rights. This is something only Jeff Sessions wants.</comment></comment>


Milton Friedman's Free To Choose - <AUTHOR> http://www.freetochoose.tv/

<comment><USER3> I hate sites that don't tell me what they are at first glance. I don't know what this is and I'm not going to watch a video to find out. I am an average user with a short attention span, and I'd give you advice on targeting people like me, only I'm not sure what it is you do and whether average users are your target audience.

Please. All it takes is a paragraph. Hell, you don't even have an "About" page.

Edit: I'm sorry that this sounds unnecessarily harsh, but it bugs me to hell that I have no idea about what I'm looking at. =]

<comment><AUTHOR> Uh, I'd think it speaks for itself. Milton Friedman is pretty well known - <USER2> was a leader of Chicago school economics. This is a TV series that he produced that explains the mechanics of the free market.

What is it you want as way of explanation? I figured Hacker News is a place where people might be interested in capitalism.

<comment><USER3> That would have been enough. I neither own a TV nor live in the USA (where I imagine he's more well-known?), and while I do spend the greater part of my life on the internet, I had never come across his name before.

Thanks for clearing that up. =]

</comment></comment></comment><comment><USER4> I like how Friedman explains his logic in the first half of each video, then in the second half, invites 5 people with opposite opinions to his own and debates them. The older series is better.

This video (and also Commanding Heights shown on PBS) had a great impact on my economic views.

Nothing causes more harm than good intentions.

</comment><comment><USER5> i like the simple site layout. i wish more sites were like this. easier on my eyes and brain and easier on my computer. one design suggestion I have is to add some kind of About blurb or page.

</comment><comment><USER6> Awesome.</comment>


Sam Ruby converts to Vue.js - <AUTHOR> http://intertwingly.net/blog/2017/09/11/Converting-to-Vue-js <comment><USER2> Why this uproar about the licence? It didn't change. That this licence is a bit strange and not really free was obvious from the beginning. People starting converting their projects now only because Apache told them the obvious are as weird as this licence.

</comment><comment><USER3> ruby2js looks very interesting - hadn't spotted that before. Lighter than Opal but still provides the pleasure of writing in Ruby rather than JS.

[https://github.com/rubys/ruby2js](https://github.com/rubys/ruby2js)

</comment><comment><USER4> What is it that makes fb value _the license clause_ above react?</comment>


Javascript bookmarklet to dynamically change all images to placeholder kittens - <AUTHOR> http://www.tupalo.com/en/blog/kittens-bookmarklet/

<comment><USER2> Makes every website except lolcats.com better.

</comment><comment><USER3> Oh god, what have I started :(</comment>


Show HN: Get paid in GitHub stars for your open source work - <AUTHOR> http://paywithastar.herokuapp.com <comment><USER2> Why does it need write access to all of my repositories, when I click on the demo link?

<comment><USER3> Dang, the curse of GitHub OAuth granularity strikes again!

> public_repo:

> Grants read/write access to code, commit statuses, collaborators, and > deployment statuses for public repositories and organizations. Also required > for starring public repositories.

Source: [https://developer.github.com/v3/oauth/](https://developer.github.com/v3/oauth/)

<comment><AUTHOR> Yes :(

I tried to find a better way to do that, but public_repo is the least granular permission that github provides.

<comment><USER4> get rid of write with (no scope)

</comment></comment></comment></comment><comment><USER5> Nice idea, but the permission page makes it look like a facebook scam app.

<comment><AUTHOR> I get what you mean.

Will a page explaining exactly what's going to happen before asking permissions help?

</comment></comment><comment><USER6> Nice idea, but isn't it too much hassle?</comment>


Here Are the Signs the Bitcoin Bubble Is About to Burst - <AUTHOR> http://fortune.com/2018/02/02/bitcoin-bubble-burst-trouble/ <comment><USER2> Article is fairly lacking in terms of "signs". More like "here are a bunch of opinions from Monday morning QB economists."</comment>


Peterborough, New Hampshire - <AUTHOR> https://en.wikipedia.org/wiki/Peterborough,_New_Hampshire <comment><AUTHOR> >"Peterborough is home to the first tax-supported free public library in the United States. The Peterborough Town Library was founded at a town meeting on April 9, 1833.[11]

This idea was revolutionary in a time when subscription libraries were popular."</comment>


AMD's "heterogeneous Uniform Memory Access" coming this year in Kaveri - <AUTHOR> http://arstechnica.com/information-technology/2013/04/amds-heterogeneous-uniform-memory-access-coming-this-year-in-kaveri/

<comment><USER2> Currently there's a big problem in GPGPU computing - high latency until the computation results are available. That can be tens of milliseconds. This significantly limits type of tasks you can efficiently offload to GPU. I understand AMD's hUMA/HSA is supposed to address this problem.

But there's another problem: currently CPU memory buses are connected to two or more DDR3 memory channels. And DDR3 doesn't simply have sufficient bandwidth for high performance graphics and GPGPU computing, especially when shared with CPU.

Intel Haswell will have CPU and GPU on-package together with shared 128MB of eDRAM 64 GBps "L4 cache". I believe that should enable low latency high performance memory sharing.

I don't understand AMD's bandwidth story. Does the GPU share one memory controller with CPU and have another private one, for example connected to GDDR5? I don't see how hUMA could work efficiently over PCIe bus either, so I guess hUMA is about APU + CPU only.

How does AMD provide the bandwidth?

<comment><USER3> I think this hUMA/HSA is a value proposition and not meant for high-end graphics or GPGPU, which can easily stream through GBs of data very quickly (high end cards have > 4 GB on card). Even Haswell strikes me as a value product; everything great until your problem doesn't fit into your cache.

The transparent memory hierarchy is still quite expensive, and there are lots of performance benefits, at least at the high end, to managing it yourself.

<comment><USER4> There are a lot of performance benefits to managing the memory hierarchy yourself. But I think that the demise of the Cell demonstrated that not enough people are willing to do it to justify it as architectural decision.

<comment><USER3> In the video game market sure, but in the HPC market, CUDA rules.

<comment><USER4> I was talking about for a single chip. There was a lot of interest in Cell in the HPC market, but it also died.

For applications that can tolerate the latency, offloading computation to the GPUs is such a multiplier in performance that they have to put up with manually managing the hierarchy - but even there, it's a rather coarse memory management.

</comment></comment></comment></comment></comment><comment><AUTHOR> I'm surprised it's taken this long to get unified memory access across CPU and GPU. Carmack has been asking for it for a while now and that's just for the traditional application of a GPU (graphics). For GPGPU this would be massive. It's also probably one of the few places AMD can really compete with Intel too as they have both CPU and GPU tech.

<comment><USER5> I think Nvidia will do it, too, starting with Tegra 6 (Denver/Maxwell) and beyond, but in mobile devices. I think ARM can already share the memory between Cortex A15 CPU's and their Mali T600 line of GPU's right now (ARM is also part of the HSA Foundation).

<http://regmedia.co.uk/2011/08/19/hc_cohere_small.jpg>

<comment><AUTHOR> That's a good point. I was thinking about this in terms of the traditional x86 fight between Intel and AMD. I could see Nvidia going beyond mobile with it though. Consider this playbook for Nvidia:

1)Build an ARM 64bit chip with the latest GPU tech (not the generations behind stuff they've been using on mobile), and unified addressing with the memory controller on die.

2)Stick a bunch of fast ram, some fast flash for storage and a gigabit chip to build a blade server.

3)Start selling these to people that today have GPGPU type loads. This should easily be cheaper and more power efficient than the equivalent Intel solution.

4)As 64bit ARM becomes more performance competitive with x86 (is that happening?) and people get used to developing for ARM, move to take over more traditional CPU workloads.

It would make sense for them as they've already tried to enter the x86 market with their motherboard/chipset business before and been mildly successful. Back then they were just trying to build a better x86 and got squeezed by Intel, here they'd be using the classic Innovator Dilemma strategy of coming from a lesser product (ARM) to dominate the market.

One of the most interesting points in Ars previous articles about AMD was that before they decided to buy ATI they were actually considering Nvidia but the sticking point was that Nvidia's CEO wanted to be CEO of the joint company. It makes you wonder what could have come out of AMD+Nvidia with Jen-Hsun Huang at the helm.

<comment><USER6> >As 64bit ARM becomes more performance competitive with x86 (is that happening?)

Correct me if I'm wrong, but I don't think there are actually any 64bit cores available for consumers yet. A quick google suggests they are just getting these cores into ICs now:

[http://hexus.net/tech/news/cpu/53661-arms-64-bit- cortex-a57-...](http://hexus.net/tech/news/cpu/53661-arms-64-bit- cortex-a57-taped-out/)

<comment><USER2> Not for consumers, right. But ARMv8 64-bit X-gene should be available: <http://www.apm.com/products/x-gene>

<comment><USER6> Interesting, I'd not seen that before thanks. Not clear to me if I can actually buy one yet, there contact page doesn't list the 64bit servers which is weird. Anyway I've pinged them for more information would be interested in playing with one.

</comment></comment></comment></comment></comment></comment><comment><USER7> The low barrier intermixing of GPU/CPU code is a pretty ambitious project on the software side, they need to implement it well and get developers onboard. I hope AMD can pull it off.

Their fate depends on leveraging their GPU lead over Intel, and it's much easier to port code over to GPU if you don't have to completely rewrite it around the old school GPU data shuffling requirements.

This might have a better chance on the PS4/Xbox 720 side, with one size fits all hardware and hopefully less driver problems.

</comment><comment><USER8> _hUMA addresses this, too. Not only can the GPU in a hUMA system use the CPU's addresses, it can also use the CPU's demand-paged virtual memory. If the GPU tries to access an address that's written out to disk, the CPU springs into life, calling on the operating system to find and load the relevant bit of data, and load it into memory._

Is demand-paging actually relevant, or just a poorly chosen example of what would theoretically be possible? I'd think that in an application where the worry is memory transfer speed, one wouldn't ever want to be swapping to disk. Better a swift death by the OOM killer than drowning in molasses.

More generally, do swap files still have a useful role to play in high performance computing? I'd think the window between "fits in RAM so no need for a swap file" and "ever so slightly larger than RAM so we can quickly page in what we need" is thin and growing thinner.

Sharing a virtual address space, transferring directly to and from RAM, and hardware cache synchronization sound like real advantages, though.

<comment><USER4> It allows people to treat memory on the GPU just as they do on CPUs. You are correct, you will probably not achieve high performance if you are paging in from disk all the time. But, what if you want it done once every ten minutes? Consider the amount of programmer effort required to do that manually. This is part of sharing the virtual address space.

</comment></comment><comment><USER9> Doesn't sharing a virtual memory context with the GPU increase the cost of context switching? Also, which CPU core shares context with the GPU? Or are we talking about a fixed mapping (like the kernel)?

<comment><USER10> I'd assume they'd handle sharing memory between a CPU and a part of the GPU the exact same way they'd handle sharing between two CPU cores.

</comment></comment><comment><USER11> This sounds _really, really, really freaking cool_. I am overjoyed to see AMD not throwing in the towel and conceding the entire high-end CPU market to Intel. A monopoly there would threaten Moore's law.

I can think of a lot of cool things to do with hUMA. I might have to get one and dust off my once very strong interest in evolutionary computation (strongly biomorphic genetic algorithms, artificial life, etc.). EC can do very interesting things -- its the only "AI" technique I am aware of that can be genuinely creative -- but it eats CPU cycles for breakfast.

It would also be great for creating a practical fully homomorphic cryptosystem based virtual machine for "blind cloud computing"-- where the VM host has no idea what the VM is doing. All kinds of neato stuff is waiting on this kind of computing platform to be practical.

</comment><comment><USER12> Pardon me, but this is fucking awesome!

</comment><comment><USER13> Off Topic - AMD codenames it Kaveri; let me guess the better part of development is done by South Indians..

<comment><USER14> Kaveri also means "buddy" in Finnish.

</comment></comment><comment><USER15> AMD (Intel too, sometimes) often goes on talking about its new technology, yet customers have shown they don't care. There are literally only two things that matter to buyers: price and "speed." Anything else is just PR hype for the investors.

<comment><USER16> "Speed" is most certainly PR hype. There is no single objective measure of the "speed" of any particular hardware.

Unified CPU and GPU memory is very interesting.</comment></comment>


OpenSSH sshd – memory leak - <AUTHOR> http://pastebin.com/raw.php?i=gjkivAf3 <comment><USER2> This is garbage. Probably the same guys behind this other one recently ([http://pastebin.com/qPxR9BRv](http://pastebin.com/qPxR9BRv)).

One of the members of the full disclosure mailing list outed these guys here: [http://seclists.org/fulldisclosure/2014/Apr/292](http://seclists.org/fulldisclosure/2014/Apr/292)

Only this time - they got _smart_ :

> Please note that we are busy and we will NOT answer to questions, social > engineering tentatives or dumb comments.

AKA

> Please note that we will not in any way prove this is legit (not falling for > that again!)

</comment><comment><USER3> So:

1) this is probably bullshit. cf. [http://seclists.org/oss- sec/2014/q2/247](http://seclists.org/oss-sec/2014/q2/247)

2) from the memory dump, it looks like it is post-authentication so the impact would be quite limited (stealing the password hash of an account one already has access to)

3) we're (OpenSSH) going to check it out anyway

<comment><USER4> Kudos for playing it safe, this does open you up to the possibility of being DOS'd with fake vulnerabilities whilst exploiting a real one.

</comment></comment><comment><USER5> Folks on oss-security are skeptical about this (and rightly so, since posts like this have been showing up regularly since heartbleed). [http://seclists.org/oss-sec/2014/q2/246](http://seclists.org/oss- sec/2014/q2/246)

<comment><USER6>
      | 236kb of exploit source, must be written for enterprise.

</comment></comment><comment><USER7> Could you image being the person who spends 20 BTC for an exploit without any evidence that it's real? "But look, there's console output _right there_!"

</comment><comment><USER8> [https://blockchain.info/address/14PEL35LQf81oCvSPurhoyTSvosv...](https://blockchain.info/address/14PEL35LQf81oCvSPurhoyTSvosvtQT7u3)

> Total Received 0 BTC

<comment><USER9> Well duh, ... of course if someone sent 20 BTC there you can bet they'd be flooded with emails of the form "my txid is {txid}, send it over to me".

This is one of multiple reasons why the Bitcoin system wasn't designed for people to reuse addresses.

<comment><USER8> uh? you can sign the message to prove your identity

<comment><USER9> Maybe you can, not always.

Did you issue the payment from your account a service? Did you issue it from a hardware wallet? Did you, by chance, happen to decide that you want to use an anonymization tool when buying your exploit? Perhaps, you have a strict retention policy and destroy keys which are no longer used and can't sign for it anymore…

<comment><USER8> If you are paying 20btc for a zero day exploit I suppose you know what you are doing. Either way everything you had mentioned are not deficiencies of Bitcoin per se.

</comment></comment></comment></comment></comment><comment><USER10> 20 BTC seem quite cheap for these kind of bug no?

<comment><USER11> But a good price to scam people; not too expensive, so it'll get a few bites.

</comment></comment><comment><USER4> Anybody that pays for this deserves exactly what they get. I also still have a bunch of lightly used one-time pads for sale...

</comment><comment><USER12> > This vulnerability exploits a bad check on the network layer of the sshd > server that we trigger to retrieve all children processes memory sections…

That's not making sense to me. I really thought that, and correct me if I'm wrong here, parents _never_ had access to child process memory and that you had to go out of your way to do even limited memory sharing between processes.

<comment><USER4> Well, technically after a fork you have access to all the childs memory pages, they're identical to your own (that is, until any writes happen, usually that's when copies are made and each process ends up with a different version of that page). But then the 'exec' bit happens and it's a completely new process. Any access to memory of the child process thereafter would be through some deliberate mechanism unless there is a significant issue with the underlying operating systems ability to keep processes where they belong (separated).

The whole idea is that processes have separate memory spaces, debuggers, shared memory applications and IPC implementation work hard to do this on purpose.

If sshd really had unfettered access to its child processes then so would every other process that spawns some new process, init comes to mind as a nice candidate, cron as another (though neither exposes network sockets).

Of course, a process running as 'root' has technically access to all the other processes memory through (on Linux) /dev/mem (phys) and /dev/kmem (virt) but you have to open it first and as far as I'm aware sshd does not do this.

<comment><USER13> _...(though neither exposes network sockets)._

I'm not sure, but that may no longer be true with systemd.

</comment></comment></comment><comment><USER14> a 236 kbyte C exploit code example - you defiantly get 'something' for your 20 BTC..

<comment><USER15> > defiantly

I realize that was (probably?) a typo, but it's oddly amusing and strangely fitting.

<comment><USER14> definitely fitting :P

</comment></comment></comment><comment><USER16> Maybe a crowdfund could be set up to gather together the 20 BTC and then open source it or distribute it to the backers

<comment><USER17> It is probably a scam. They haven't provided any real evidence, only an imaginary PoC.

<comment><USER18> Someone could put 20btc on a machine that only exposes ssh and see if they can get in. Then they'd earn it. :P

</comment></comment></comment><comment><USER19> 236k for some exploit code. Okay.

<comment><USER3> IMO this isn't implausible - if I were making a single-file exploit then I'd probably just include most of OpenSSH in that single file.

</comment></comment><comment><USER20> Seems legit.

</comment><comment><USER21> It seems that once again, running services on non-standard ports where possible might have payed off.

Off to patching. Or rather, wait for eventual patches.

But you know what interests me the most about the whole thing? Theo de Raadts reaction. You know, after bashing OpenSSL heavily. _And hinting at a SSH hole in FreeBSD, known to him but deliberately undisclosed_.

Judging from the announcement's tested systems, it might be the exact hole he referred to. _"...many more"_ sounds like they'd like to claim more successfully exploited platforms, but can't since they do something different, and the de facto reference implementation of OpenSSH on OpenBSD is suspiciously absent.

<comment><USER22> I'm curious how running services on non-standard ports has an impact on anything like this.

This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.

<comment><USER23> It helps against a masscan on the standard port. If the attacker is specifically targeting you or has the resources to masscan every port, then I agree that it's useless.

<comment><USER22> [https://zmap.io/](https://zmap.io/) / [https://github.com/zmap/zmap](https://github.com/zmap/zmap)

It's pretty crazy to think about, but a portscan of the IPv4 space isn't that hard to do in practice:

"On a typical desktop computer with a gigabit Ethernet connection, ZMap is capable scanning the entire public IPv4 address space in under 45 minutes."

<comment><USER23> It isn't clear whether that is on a specific port or every port. The documentation[1] makes it look like it's on a specific port since it requires a target port to run. If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. Thanks for sharing, I had not heard about ZMap before.

[1] [https://zmap.io/documentation.html](https://zmap.io/documentation.html)

EDIT: The research paper says that it's on a particular port, from page 3: "The architecture allows sending and receiving components to run asynchronously and enables a single source machine to comprehensively scan every host in the public IPv4 address space for a particular open TCP port in under 45 mins using a 1 Gbps Ethernet link."

<comment><USER24> > If it's on a specific port, you might want to multiply 45 minutes with > 65535, if not I'm impressed.

You're not? I am. Or would be if this wasn't known info yet.

Think about it for a bit - you can narrow down your search area quite a bit by excluding huge swaths of the Internet such as consumer ISPs. Focus on the target-rich environments like EC2 space, hosting providers, enterprises, etc. You also can not scan any unassigned v4 space (admittedly getting smaller), multicast addresses, RFC1918, etc. The usable pool of v4 is actually quite a bit smaller than 32 bits, and the interesting parts are even less. I would be surprised if you couldn't come up with a list of interesting space to scan that you couldn't do within 15 minutes per port. You aren't using this tool to pwn Joe nerd who runs a Linux NAT box off his cable modem.

From there, you just need a few hundred compromised servers (not difficult this day in age) and you can probably scan the entirety of "rich" space on all ports rather quickly via a distributed manner.

The only downside is such scans tend to generate complaints, so you'll need to balance your loss of compromised hosts with the expected payoff.</comment></comment></comment></comment></comment></comment>