Ruby 2.1 Garbage Collection: ready for production - <AUTHOR> http://samsaffron.com/archive/2014/04/08/ruby-2-1-garbage-collection-ready-for-production

<comment><USER2> I think the takeaway is that there _actually is_ a straight-up bug in the 2.1.1 GC that causes unbounded memory growth, and that the new GC does typically result in higher memory use.

The memory issue isn't really that serious, as it seems to be a tradeoff for performance. Although it's not like Ruby is light on memory use as it is…

Far more interesting are some of the other issues, like this one: [https://bugs.ruby-lang.org/issues/9262](https://bugs.ruby- lang.org/issues/9262)

 _For an app like Discourse 3-10% of request time is occupied looking up methods, due to cache inefficiency._

That's _amazing_ , and demonstrates that there's probably still quite a lot of low-hanging performance fruit that Ruby can look to exploit.

All of that aside, performance is generally so much better in the 2.1.1 series that it's really worth using.

<comment><USER3> I think it's part bug and part having a GC with only two generations (old and young). When you have to choose between putting these tweener objects somewhere, you have to be more conservative and move them to the old generation. Once a third generation is added (Ruby 2.2?) this will be much smoother.

> _For an app like Discourse 3-10% of request time is occupied looking up > methods, due to cache inefficiency._

Hmmm, I thought Ruby 2.1 already had a per-class method cache, or maybe it was just a per-class method cache invalidation, but I don't know how you coud have one without the other. I'll have to reinvestigate this.

> _That 's amazing, and demonstrates that there's probably still quite a lot > of low-hanging performance fruit that Ruby can look to exploit._

I'm not sure I share as much of a positive outlook. Short of adding JIT compilation, I think the gains from here on out will start to get smaller and smaller. The performance gains of RGenGC were very impressive, though.

<comment><USER4> I'm working on a "as static as possible" Ruby compiler as a hobby project, and it's incredibly frustrating at times to see the generated code grow to ridiculous size as I'm getting closer to actually complying with real Ruby semantics... But I do still think there are substantial gains possible.

For starters, for most method calls there's no reason to do the expensive method lookups that MRI still uses - cache or no cache - you can use C++ style vtables, as long as you propagate updates to them downwards when a method is re-defined. You do need to be able to fall back to handle dynamically created methods with names not present when you generate the vtables, and optionally reduce waste (as the vtables needs to be the same size for all classes, with unimplemented methods replaced with pointers to method_missing thunks), but in terms of performance you can do fairly well and compared to this GC blowup, the memory waste would be small.

But there's also not much alternative but going for proper JIT'ing of at least some things.

<comment><USER5> Dynamic languages tend to gain more from JIT as AOT due to such issues.

On the other hand, have a look at Dylan, as it might inspire you:

[http://opendylan.org/](http://opendylan.org/)

<comment><USER4> For the method lookup, other than for methods that are dynamically generated with names not known at compile time, the only additional gain you'll get from JIT is by going to full on inline caches, but vtables gets you most of the speedup without the hassle of inline caches and tracing, and doesn't _prevent_ using tracing and inline caching down the line.

<comment><USER5> With JITs you get devirtualization as well, so no need for vtables.

Something possible in AOT as well to certain extent, but it requires a mix of profile guided optimizations coupled with whole programm analysis.

Which have issues with dll/so anyway, as those calls cannot be optimized away as in JITs.

<comment><USER4> > With JITs you get devirtualization as well, so no need for vtables.

That's what I referred to with "inline caches". The problem is that for Ruby you need fully polymorphic inline caches, with guards all over the place, because unless you do tons of analysis upfront, you will have problems knowing whether or not the world has totally changed on you after any method call, and almost anything is a method call. (call into code you have not verified can't possibly call "eval", and you might find that adding two integers afterwards does in fact not add them, but returns a string and changes global variables, and what-not)

The upshot, is that compared to vtables, you're not actually saving all that much. E.g., take "1 + 2 - 3". You could inline Fixnum#+ (and could reasonably do so with an AOT compiler too). But you need to add a type guard before the inlined fragment to verify that Fixnum#+ still is the Fixnum#+ you inlined, which at the minimum costs you a comparison and a branch _or_ you need to record _every_ call-site with inlined code and be prepared to overwrite it with fixups if the implementation changes.

And if Fixnum#+ has been overridden, or the Fixnum#+ implementation has method calls, chances are you will need another guard before "-" too, because you might not even know for sure whether or not the object returned from "1 + 2" will be a Fixnum, so you might find that the inlined method suddenly is for the wrong class.

I'm planning on benchmarking inline caching for my compiler against vtables, but absent evidence to the contrary I'm expecting that there will be a very substantial number of cases where the complexity isn't worth it, or where they might even turn out to be slower.

> Something possible in AOT as well to certain extent, but it requires a mix > of profile guided optimizations coupled with whole programm analysis.

It does if you want to do _everything_ upfront, but you can pull things into inline caches with a mostly-AOT compiler relatively easily with just a little bit of extra information, and a few guards thrown in to do some basic tracing.

<comment><USER6> I've implemented a handful of simple dynamic languages years ago, and something I was interested in trying, but never did, was taking advantage of the MMU to replace guard clauses.

For example, mapping a few pages for vtables/method dictionaries read only. When something like `def` or `define_method` comes along, catch the segfault (which in this case would actually mean "segmentation fault" instead of "I fucked up") and rewrite all JIT blocks or method caches that depend on that method table. Once everything has settled, generally after startup and the vtables tend to stay more stable, the overhead seems like it'd be negligible.

<comment><USER4> Catching the vtable updates and propagating them downwards is pretty simple, you "just" need every class to know which classes inherits from them. There's an implementation for dynamic runtime updates of dispatch tables for Oberon, of all languages (though that version sidesteps the "sparse vtables" issue by splitting the vtables into interfaces, and adding one extra level of indirection).

The tricky bit is if you have gone as far as inlining the method.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Kind of depressing how far behind Ruby is from V8, Hotspot, CLR etc in terms of the sophistication of the GC, non-existent JIT etc. Still hoping someday someone will make the investment needed to catch up.

<comment><USER8> Like Rubinius? Or why not JRuby?

<comment><USER9> Because there's always something different that needs to be done for them once your project starts becoming non-trivial. You might need a different version of a gem (e.g. pure-java Nokogiri), or they're behind recent MRI features. And if you care about concurrency, it's different everywhere.

In my personal experience I've found MRI to be the best experience simply because that's what most other people are using, and there's a lot to be gained from being in the mainstream.

Don't get me wrong- I would actually love for JRuby to become the de-facto Ruby implementation. So many headaches are caused by native code in gems. And we'd have a solid foundation for GC, concurrency, etc. But that's not the current reality.

<comment><USER10> Rubinius does not need Gem replacements like you need in JRuby, it still has a compatible CAPI.

> [...] or they're behind recent MRI features.

Part of this is due to MRI having literally no specification process at all. Python has the PEP system, no such thing exists in Ruby land. People tried to change this in the past ([http://rubyspec.org/design/](http://rubyspec.org/design/)) but with little to no success so far. As a direct result of this there are only two ways to keep up to date with what changes in Ruby:

1\. Follow every issue reported on bugs.ruby-lang.org, forever. 2\. Wait until users report issues about something not being present, behaving differently, etc.

> And if you care about concurrency, it's different everywhere.

This is FUD. An implementation may offer different primitives for concurrency (e.g. Rubinius has Rubinius::Channel) but they also offer shared APIs. For example, the Thread class works across all implementations as you'd expect. Whether you use this on JRuby or Rubinius the end result is the same: proper concurrency.

</comment></comment></comment></comment><comment><USER11> And still, there is no RubyInstaller 2.1 for Windows =(.</comment>


Is Ruby Dying? - <AUTHOR> http://jmoses.co/2013/12/21/is-ruby-dying.html <comment><USER2> You just may not be used to Ruby not having the exciting fire of initial hype. That _is_ dead. But that's good. Languages can't live like that forever. Sooner or later they need to stop the wild experimenting, find some best practices and things that work, and settle down and ram home the things that work.

Ruby has entered final maturity. It will be in that phase until such time as it really _does_ die, which could well be 10-15 years. Or more, though, honestly, I doubt that in 2028 we'll be considering Ruby anything more than legacy code... that's not because of Ruby itself, but rather the language category it is in. I expect we'll be looking at Python and Perl the same way.

Oh, and kudos for running numbers before simply writing the "Ruby is dying!" blog post!

<comment><USER3> I think Perl has already reached the state where it's mostly used in legacy code, at least for web development.

<comment><USER4> What about Catalyst? Or Mojolicious? Or Dancer? If it's just used in legacy code, why are there still healthy frameworks being produced (granted, these aren't as popular as Rails, but, Perl on the web is hardly in legacy mode)?

<comment><USER5> I personally haven't seen any new code being written in Perl during either my time in England or in the Bay Area. I don't really see a reason to use Perl when there are languages like Python and Ruby out there with easier learning curves and which are just as, if not more powerful (would be happy to learn some good reasons, though).

<comment><USER6> I am in Manchester. I write new Perl code. Python is Perl with a little nicer syntax and a shitload of baggage from overly opinionated people. Ruby is Perl with a little nicer syntax and no other advantages.

I have found no compelling reason to switch, and lots of annoyances that don't seem to exist in Perl.

<comment><USER7> Following this logic, every language is Perl with a bit of this or that. Perl was one of the first of the kind, but people saw obvious problems with it and so they innovated with 'little nicer syntax' or 'little better object system'. You might not want any of this, but you can't deny most people are happier with Python or Ruby.

<comment><USER8> I'd say it's more like Perl is every language with a bit of this or that. A sufficiently "skilled" Perl hacker can write everything from bad C, to bad Lisp, to bad Fortran, in Perl -- and most certainly can write plenty of bad Perl in Perl, too. It's writing _good_ Perl that's hard.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> First off, popularity of a language shouldn't be as important as you seem to make it in starting a project. Finding the right tool for the job should be much much more important, new kid in town be damned. Second off, number of package releases doesn't tell much about maturity of packages, developer involvement, or anything. Ruby's a mature language. It's quite feasible, and arguably desirable, for package releases to slow down in time. Styles have been developed, the urgency for new features to be rolled in Right Now is lessened, and the need for components that doesn't break on upgrades becomes more and more important. Yes, the novelty is gone. That isn't a bad thing. You know Ruby's strengths and weaknesses, you know how to use it, you know how not to use it. Jumping to a new language just because of all the jibber-jabber is not a practical thing at all.

<comment><USER10> > Finding the right tool for the job should be much much more important

That's the most overstated claim in programming. LESS is the "right tool for the job" when the job is styling web pages. Ruby is a general purpose programming language, the jobs it is good for is everything not covered by DSLs like LESS, the same as all other general purpose languages.

<comment><USER11> > Ruby is a general purpose programming language

I question that. Ruby is very slow, dynamically typed and suffers from scaling challenges because of its multithreading support.

I think Ruby is increasingly falling into a niche: prototyping. Get a prototype up and running in a few weeks and once the proof of concept is established, switch to a statically typed language on the JVM.

<comment><USER12> I disagree.

Ruby was slow (still is), but that trend is changing. More and more effort is put into speeding up and modernising Ruby in general.

It might have only begun to mature, but it's definitely getting a there.

Rubinius is a lot faster than MRI and has proper multithreading support. There is also JRuby, which runs on JVM.

</comment></comment></comment></comment><comment><USER13> Developer discovers nodejs, drinks kool-aid, assumes other languages are dead or dying. News at 10.

<comment><USER14> So true, I was expecting to see Node code in this article even without reading it and can tell already that your comment is the whole tl;dr story of this post.

After Node will stop being popular and "hip" author will probably make a new post saying "Is Node Dying?".

</comment></comment><comment><USER15> I didn't start using Ruby (or Rails) until this year. The language is nice and makes my top 3 language list.

That said, I find both Python/Django and Node.js both more productive than Rails for quickly building API-driven web-apps. More so this has to do with Rails, which has a number of warts and a tendency to require excessive configuration for all its pretty much patently false 'convention over configuration' spiels, than it does with Ruby.

If there's a problem with Ruby, it's the inseparability of it and Rails. As things like node make using non-JS languages server side less appealing, use of Rails will decline, making Ruby decline.

The main reason this hasn't happened is that there's not a standard groupthink-do-it-all toolkit for building things with node yet.

And even when it does happen it will take years and years to go away. Just look at PHP.

I'm going to go ahead and say it: Ruby will be the new PHP...

And yes, I think it's fair to assume that Ruby usage is vast majority tied to Rails.

<comment><USER16> > patently false 'convention over configuration' spiels

such as ?

Rails has plenty of warts but models still live in /app/models, classes are named after tables and all CRUD routes are defined with a single two-token line.

You are probably forgetting to consider what the world was like before this.

</comment></comment><comment><USER17> Ugh...must not take Lord's name in vain. 14 points in almost as many minutes? Is it so easy to get to the top of HackerNews on a holiday with such a loaded question? I can't imagine how many points the OP would've gotten if the title was "Is Ruby Dying Faster than MongoDB?"

That said, as a pro-Rubyist...well, I don't find much comfort in the OP's spurious assumptions about what the data can show. However, for those who think Ruby's time is limited or otherwise hate the language (or more specifically, Rails)...what do you think will take its place? Ruby seems popular because of its readable syntax...which is also a factor in its relatively slow performance...do you see an even more human friendly (and inefficient) language taking its place? Or do you think such a niche need not be filled?

That Ruby is so great for DSLs...I would hope that it can stay in that function as one of the better glue languages we have.

<comment><USER18> Ruby IS dying faster than MongoDB! Evidence to prove it! [http://bit.ly/1c9vo1S](http://bit.ly/1c9vo1S)

</comment></comment><comment><USER19> Is it that day of the week again?

I would like to also point out the title of the post is misleading, as the findings are exactly the opposite.

<comment><USER20> [http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines)

<comment><USER21> Citing this is such a knackered HN cliché it should mean an instant hell- banning.

<comment><USER22> Shouldn't submitting things that fit Betteridge's Law should get you banned instead? Why ban the symptoms?

<comment><USER21> My comment was tongue in cheek, but there is no way one would realise that just by reading it. I don't really think people should be hell-banned for it, being down-voted into oblivion would suffice :)

</comment></comment></comment></comment></comment><comment><USER23> TIOBE index for December 2013 says otherwise: [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Ruby dropped 3 spots from this time last year (currently #13); if it is dying, it's dying slowly.

For my work on the JVM, Scala in comparison is way down at spot #31; Groovy #47, and Clojure doesn't even break the top 50.

Meanwhile F# is kicking some serious azz, soaring 27 spots in a single year to #20, impressive.

Ruby should be just fine for the next several years, assume will drop down into the 20s as the static typing + FP movement takes root in the enterprise.

2014 should be a fun year for the JVM: Java 8, Scala 2.11, a possible Kotlin release, and whatever Groovy and Clojure have planned.

<comment><USER24> I used to look at the TIOBE index all the time, until I saw Visual Basic .NET jump a bunch of spots this year. I then started to question either TIOBE index or the people that are using Visual Basic.NET

<comment><USER25> Not sure what to say about TIOBE. It bases its results on search engine trends.

They can't really tell the difference between Ruby(The stone) and Ruby(The language). Or Python(The snake) and Python(The language).

</comment></comment></comment><comment><USER24> NodeJS, been there done that. Even with generators it makes doing task synchronously a royal pain(have you ever tried to write sql update code with transactions?). Until something comes a long to replace Ruby([https://github.com/mirah/mirah](https://github.com/mirah/mirah) looks promising), I'll still use it. Ruby is a great scripting language, and it has one of the best(if not the best), web frameworks out there.

I definitely think MRI will die, and Ruby will live on in the JVM. I've been really impressed with JRuby and the advances they have made on that project.

Plus you also have projects like RubyMotion and the promising Opal(Ruby to JS).

<comment><USER26> Mirah has almost zero usage, and it seems very little development is going on there. I'm on the Mirah google group and there have been 5 posts since October.

I love the idea, but it seems few are interested....

<comment><USER24> Exactly. That proves my point. There are no Ruby like languages ready to replace Ruby right now.

</comment></comment></comment><comment><USER27> Ruby is like Disco. It was fun for a while, but now it is old news.

I was forced to learn Ruby while at Aardvark, as well as the Rails and the Agile process.

It was true today as it was then; Ruby, Rails, and Agile are absolutely useless for real data science and machine learning, and this is what companies need to move forward. Indeed, to bring machine learning tech to the Aardvark team, I had to fight tooth and nail against the Rails consultants and the Agile process guys.

Ruby is a useful gateway language for learning other modern scripting languages such as python, lua, and scala

I agree that Ruby is now legacy technology. Let me be clear; I use it all the time. It is useful to build stable projects based on solid ideas, and I use it for dev ops, for crawling the web, and for making simple DSLs. Chef is very good (compared to, say, Ansible) , and the Bundler deployment system is quite nice. It is easy to build web endpoints in Sinatra, and the Nokogiri gem is a pleasure to work with compared to, say, java JSoup.

But Ruby is not moving the needle forward. It does not even have a decent NumPy-like module, which makes it completely useless for modern back end work in data science, machine learning, and the real things companies need to generate revenue

Rails is a good example of being overspecialized. They are so good at web programing circa 2007 that the future passed them by.

Python. Lua. Scala. Closure. These are the future.

</comment><comment><USER28> A better title would have be, "Is Ruby Dying? Getting The Data." As others have pointed out, the data suggests no, it is not.

<comment><USER29> But then it wouldnt be linkbait!

</comment></comment><comment><USER30> Google trends:

[http://www.google.com/trends/explore#q=python%20programming%...](http://www.google.com/trends/explore#q=python%20programming%2C%20ruby%20programming&cmpt=q)

<comment><USER15> With javascript: [http://www.google.com/trends/explore#q=python%20programming%...](http://www.google.com/trends/explore#q=python%20programming%2C%20ruby%20programming%2C%20javascript%20programming&cmpt=q)

<comment><USER31> With node: [http://www.google.com/trends/explore#q=python%20programming%...](http://www.google.com/trends/explore#q=python%20programming%2C%20ruby%20programming%2C%20javascript%20programming%2C%20nodejs&cmpt=q)

<comment><USER32> I don't think it's comparable to compare the 1-word "nodejs" with the 2-word "xxx programming" phrases.

<comment><USER33> sans "programming" [http://www.google.com/trends/explore#q=python%2C%20ruby%2C%2...](http://www.google.com/trends/explore#q=python%2C%20ruby%2C%20javascript%2C%20nodejs&cmpt=q)

</comment></comment></comment></comment></comment><comment><USER34> I have been working with Ruby and RoR for a few years now after using C# and Java. I now can put together web apps or APIs in hours vs days and integrate it with about anything out there from other APIs, using gems wrapping them or other gems for integration like redis, rabbitmq etc you name it. I have never ran into issues of incompatible gems I could not fix myself in a short period of time. It's incredible productive and reasonable fast. I am dealing with data reads/writes in the ten thousands of records per second and when something smells like bottleneck you still can throw in a native extension or use jruby and call java libs. If you are building all you do with boilerplate activerecord or other ORMS you just don't use it right. Flexibly is key. I think every challenge has it's best tools. I tried grails, play, spring mvc and other frameworks but promise that I can beat every of these frameworks in terms of development speed. Ruby is far from being dead and has a huge community. Having that said its always good to also stay up to date with other tools. For many deploying rails apps is a pain so why not throwing in warbler and deploy a war file to an app server...seconds later, boom, online and scalable. I could go on for hours:) I am a fan and so are our shareholders.

</comment><comment><USER35> > _What do you guys think? Is Ruby dying? Did you once use Ruby and have now > started to use something else?_

I was using Ruby as my main language for 3 years before I switched to first Coffeescript and then Scala now. Personally I prefer the simplicity (a function is a function) of Coffeescript and the richness (so many things to fool around) of Scala over Ruby.

The popularity of languages don't die over the course of a couple of years. Projects with legacy code rely on them and maintenance of their libraries. And legacy code is very very hard to kill.

If the interest is in finding out the trend of the "favorability" of a language, it might be more accurate to survey how many green field software products(not libraries, which could be driven by the need of improving some legacy code) are choosing it. Unfortunately, such survey is more expensive to perform, and might be close to impossible to perform retrospectively to understand the trend. Given the fact that the "popularity" of a language isn't that important, the favorability is probably even less, such survey is probably hard to justify.

</comment><comment><USER36> after looking at the node code in the article, no.

</comment><comment><USER37> Ruby is maturing, not dying. It has lost much of its fadish hype.

</comment><comment><USER38> Ruby isn't dead. It's stabilizing now that all of the language hipsters have moved onto Go/Node.js/Scala/Clojure to recreate a bunch of mini Web libraries to try and make names for themselves in the new languages.

Ruby's best days are still far away.

</comment><comment><USER39> Ruby is only dying in the sense that C is dead. It's not that exciting, but instead is widely used, including by companies.

Additionally, I doubt gem releases correlate with language 'vitality'. Fewer releases may simply indicate library stability.

<comment><USER40> Too true, I'm writing more C lately than ruby. Then again I'm not a rails fan and I need to interface with ioctls more than oauth or whatever. So C fits much better in my domain space.

That and command line apps in ruby, well there like perl with cpan modules, sheer pain to manage across systems. Versus static link in archive files and make a package.

</comment></comment><comment><USER41> That's a fifteen year graph, and does appear to depict a decline at the end. I'd like to see this data rescaled to just the last six months (unfortunately his data files are 404ing now).

If you want to find out if TV sales are declining, you don't compare against the 1950s.

</comment><comment><USER42> It is surely dying among those folks who only build one page apps and post them to blogs...

</comment><comment><USER43> The author must be pretty wet behind the ears if they think a blog audience will want to read huge blocks of mundane javascript code with console logging and error handling.

</comment><comment><USER44> If there is one person working on the next version of ruby it is not dead.

jruby and rubinius close the performance gaps. (This is an arguement for only knowing one language.)

</comment><comment><USER45> no.

<comment><USER46> lol. Agreed. I'm not a fan and sometimes wish it would but enough people are using it successfully to make it pretty evident that it is not going anywhere anytime soon.

</comment></comment><comment><USER47> my question : is ruby trying to get on pair with python regarding machine learning ?

<comment><USER27> not even close. even lua is way ahead of ruby in machine learning !!!

</comment></comment><comment><USER48> As always, the answer to posts with a question as the title, is no.

</comment><comment><USER49> Pure Hacker News bait.

</comment><comment><USER50> graph only shows that all smart coders switched to ruby and it is steady updating

also most gems in all areas are good enough already

</comment><comment><USER51> Netcraft needs to confirm this, first.

</comment><comment><USER52> Probably not.

</comment><comment><USER53> I know Ruby on Rails isn't!

</comment><comment><USER54> No, but BSD is.

</comment><comment><USER55> Wait? What????</comment>


Dockers forms Governance Advisory Board with frontrunners Google, IBM and Red Hat - <AUTHOR> http://www.sdtimes.com/DOCKER_FORMS_GOVERNANCE_ADVISORY_BOARD/By_Alex_Handy/About_DOCKER_and_LINUX/70147

<comment><USER2> Go to docker.io/governance to see the full proposal (and provide comments/nominations). Our blog explaining the move is at blog.docker.io</comment>


Government by Algorithm: Artificial Intelligence in Federal Agencies [pdf] - <AUTHOR> https://www-cdn.law.stanford.edu/wp-content/uploads/2020/02/ACUS-AI-Report.pdf <comment><AUTHOR> Full title is "Government by Algorithm: Artificial Intelligence in Federal Administrative Agencies". Had to omit a word due to HN character limits.</comment>


Awk info - <AUTHOR> http://awk.info/

<comment><USER2> I use awk almost every day for one-liners that massage data and log files. In fact, my progression in scripting started with O'Reilly's sed and awk book, followed by the vi book, then with the llama and camel books (back in the perl 4 days). A classic tool that hasn't lost its usefulness after all these years.

</comment><comment><USER3> Upvoted because awk is pretty great. Combined with rc and sed, it's easy to make very powerful scripts.</comment>


Optionsbleed – HTTP OPTIONS method can leak Apache's server memory - <AUTHOR> https://blog.fuzzing-project.org/60-Optionsbleed-HTTP-OPTIONS-method-can-leak-Apaches-server-memory.html <comment><USER2> For those who come straight to the comments, it should be noted that most Apache installs won't be affected and this is a relatively low-impact vulnerability, although for those who are affected it could be pretty bad.

The flaw only occurs if you have a "Limit" configuration that specifies an invalid HTTP method. For some unknown reason, this causes the leak. A "Limit" with a valid method, or no "Limit" at all, will not provoke the bug. I have to imagine that most Apache setups either don't configure this or configure it only with valid methods.

The article points out that shared hosting setups which allow individual users to customize settings through .htaccess would be vulnerable, since anyone on the machine could set an invalid configuration and then use the vulnerability to potentially get data from other users.

Obviously you should patch it when you can, but it is probably not time for most of us to panic.

</comment><comment><USER3> I was able to reproduce this issue on Apache 2.2.22 with a legitimate method:

      <LIMIT GET>
      Allow from x.y.z.v
      Deny from all
      </LIMIT>

      for I in `seq 1 100`; do curl -sI -X OPTIONS http://myhost/ | grep ^Allow; done | uniq
      Allow: ,GET,HEAD,POST,OPTIONS
      Allow: GET,HEAD,POST,OPTIONS
      Allow: ,GET,HEAD,POST,OPTIONS
      Allow: GET,HEAD,POST,OPTIONS

<comment><USER4> This doesn't quite look like the same bug described in the article. Maybe the inconsistency with the comma separator is a separate bug?

<comment><USER3> Most certainly something is leaking:

      l-lbiegaj ~ -> curl -sI -X OPTIONS http://mysite/ | grep ^Allow
      Allow: allow,HEAD,GET,HEAD,POST,OPTIONS

Value returned in 'Allow' changes with every apache2 restart, but I haven't yet seen any parts of the config or something other than extraneous commans or 'allow' string.

<comment><USER5> Interesting. Maybe see if it still leaks with the patch jimjag points out below?

[http://svn.apache.org/viewvc?view=revision&revision=1807754](http://svn.apache.org/viewvc?view=revision&revision=1807754)

</comment></comment></comment></comment><comment><USER6> > Does it have a CVE?

> CVE-2017-9798. -> > [https://nvd.nist.gov/vuln/detail/CVE-2017-9798](https://nvd.nist.gov/vuln/detail/CVE-2017-9798)

The CVE is still in RESERVED state. I'm frequently concerned about "responsible disclosure" in such cases.

<comment><AUTHOR> It's normal that CVEs aren't filled directly after a disclosure. Takes some time till the database gets updated.

Not sure how that makes you concerned about responsible disclosure. As you can read in the bug report the apache security team was informed (actually it was one of their devs figuring out the details of the bug, I just saw it "in the wild", but at first was unable to reproduce it locally). I had also informed the distros mailing list a week in advance.

I'm aware responsible disclosure is a weakly defined term, but if you have any concerns that I did something irresponsible I'd like to know.

<comment><USER6> In my mind (biased) responsible disclosure includes ensuring that a respected database for tracking security issues has the issue described and publicly available either before or at the same time that a blog publicly discusses it. Otherwise the _impression_ is that the blog is discussing a security issue before it's been addressed by interested parties.

That's just my opinion. Whether or not that's the "definition" of responsibility is of course up for discussion.

<comment><USER7> I've got two and three year old vulnerabilities I've disclosed which have CVE's which are still not populated. This is very common. No one waits for the CVE to be populated before going public.

<comment><USER6> I understand and that's quite unfortunate. Nonetheless, my opinion is my own and I see nothing to change it so far.

<comment><USER5> The delay seems like it's caused by the people who update the database just not having the time to get it done. Or alternatively, just not prioritising it for the time they have.

Either way of looking at it, delaying release of vuln info to wait for the above to happen seems like it would let vulns keep in-the-wild-and-unknown for much longer.

That being said, if you're able to assist with or fix the not-enough-time-to- get-things-done problem, it wouldn't hurt. :)

</comment></comment></comment></comment></comment></comment><comment><USER8> Those interested in patching their local machines, while 2.4.28 is being buttoned-up, review the following link: [http://svn.apache.org/viewvc?view=revision&revision=1807754](http://svn.apache.org/viewvc?view=revision&revision=1807754)

</comment><comment><USER9> I'm astonished how many shared hosting provider still using apache 2.4.

Yes, there are a few things apache is remarkable about - the npm-itk engine could run as user processes, which was nice for shared hosting - but all the problems with it - slowloris, anyone? - simply outweights the benefits.

Shared hosting should be containerised or vm-ised instead and run on nginx/lighttpd/cherookee/etc + php-fpm 7.0 which will save you a lot of headaches and CPU cycles.

.htaccess can be just as much a benefit as a curse.

(Note: WordPress is completely nginx + php-fpm friendly.)

<comment><USER8> "all the problems" are really old, old news, long ago addressed and resolved. In fact, such statements are more FUD than anything else. Certainly you MUST know that Apache httpd supports PHP-FPM, for example.

<comment><USER10> The old problems are not solved and not resolved at all. I am working on a critical apache setup at the moment and the software is rigged with weird corner cases and bugs. This shit doesn't happen with haproxy and nginx.

<comment><USER11> You know you can use HAProxy with apache too right?

I never understand these arguments that basically pit Apache2 on its own/with modules against a completely modular arrangement of tls/cache/web/app as different layers.

If you use apache as the "web" in that setup, it needs relatively few modules loaded and when configured correctly can be blazing fast.

</comment></comment></comment></comment><comment><USER12> I will leave here the link of our 2014 paper, "Support for Various HTTP Methods on the Web" ([https://arxiv.org/pdf/1405.2330.pdf](https://arxiv.org/pdf/1405.2330.pdf)) for the reference. The issue is described in section 5.3 of the paper.

</comment><comment><USER13> Is anybody still using Apache?

I'm really iterested on the whys (in addition to the obvious legacy reasons).

<comment><USER14> Speed is one of the reasons to stay on apache. Using nginx to serve static and using php_mod vs fpm-php will be faster as long as you disable directory level .htaccess

<comment><USER9> If you're using php-fpm over unix socket, I doubt this is true, please show some stats.

<comment><USER14> [https://www.reddit.com/r/PHP/comments/4bi9a4/why_is_mod_php_...](https://www.reddit.com/r/PHP/comments/4bi9a4/why_is_mod_php_faster_than_phpfpm/)</comment></comment></comment></comment>


Ask HN: Tooling for Cross-Platform Handbook? - <AUTHOR> I am starting a medical residency, and many departments at the hospital I am at have paper/PDF handbooks with in-house protocols and resources. They are often a little out of date and hard to find/use on your phone.
I'd like to convert these to a very simple app to improve searching, navigating, and updating the content.
Background: I am an ex-software developer, but mostly backend/scientific-computing and have never built an app so I'm unfamiliar with the territory.
What framework do you suggest for creating an iOS/Android app of what is essentially a reference book with search (i.e. table of contents, chapters, sections with text and images)? My development environment is linux, currently.  I'm looking into frameworks such as flutter and react native.
I think my ideally the handbook content would be stored in a public repository, perhaps as markdown, so that it can easily accept contributions / issues. Separate code bases would turn the content into an app, PDF document, or website possibly.
Thanks! <comment><USER2> Flutter acts like a Windows app: you install and use it, bringing sanity to app development. React is like Linux: you be the mechanic. You chose.

hackmd.io provides a nice web interface you might use to flesh out the concept and see if markdown works out (I'm not affiliated). Good plan, good luck.</comment>


Apple Considered Purchasing Intel's Smartphone Modem Chip Business - <AUTHOR> https://www.macrumors.com/2019/04/26/apple-considered-purchasing-intel-modem-chip-business/ <comment><USER2> By the sounds of things the patent portfolio could be worth a fair bit but the rest of the division? Not so much.</comment>


Ziggeo Invents API Customer Acquisition Tool – And Freaks Out Customers - <AUTHOR> http://blog.ziggeo.com/2015/04/01/ziggeo-invents-api-customer-acquisition/ <comment><USER2> Interesting read!</comment>


Show HN: Backordr – An honest ccTLD drop catching service - <AUTHOR> https://backordr.com/ <comment><AUTHOR> Hi everyone! I built this project to fix a hole in the domain name industry that I've been victim of many times. Most drop catching services force you into public auctions and do shady things like auction off user domain names before they actually expire. I was tired of all the bs.

Backordr is focused 100% on registering a domain name for a user, and then we urge the user to transfer the domain name to their registrar as soon as they can. In addition, rather than public auctions, we use a silent auction system that's both more fair, and keeps prices lower.

This market can be really shady, and I hope to eliminate the shadiness and simply provide a service that works well.

Please let me know what you think, and thanks for checking it out!</comment>


Scratch.rb, A Ruby Microframework - <AUTHOR> http://gist.github.com/188861

<comment><USER2> I'm not sure this solves any particular problem that _I_ have, but there are enough interesting ideas here (like the lightweight form generation) that I think are worth looking at. Definitely not just a clone of Sinatra or web.py.

<comment><USER3> I agree, I'm a huge Sinatra fan and was coming in here to rail against somebody reinventing the wheel, but I see some value in the magic form generation and the baked in, but lightweight marshalling. Seems like it would be handy for a "hey, fill in this form for me" type page....

</comment></comment><comment><USER4> Some interesting ideas, and I love the conciseness, but..:

      [:title_x60, :text_60x10]

.. made me throw up in my mouth a bit. I like some of the ideas but this is the sort of janky Ruby that unfairly makes other people go _"See, this is why Ruby sucks."_ Nothing that couldn't be cleaned up, of course :)</comment>


Substance: a JavaScript library for web-based content editing - <AUTHOR> http://substance.io/ <comment><USER2> Thank you for sharing this on HN. Just wanted to add our introduction blog post, which may clarify some of the questions asked here.

[https://medium.com/@_mql/build-your-own-editor-with- substanc...](https://medium.com/@_mql/build-your-own-editor-with- substance-7790eb600109)

And some usage examples:

Scientific Writing \- [http://substance.io/lens](http://substance.io/lens) \- [https://github.com/Coko-Foundation/pubsweet-core](https://github.com/Coko- Foundation/pubsweet-core) Spreadsheet Software \- [https://stenci.la/demo/sheets/iris](https://stenci.la/demo/sheets/iris) Digital Archives: \- [https://medium.com/@_daniel/publish-interactive- historical-d...](https://medium.com/@_daniel/publish-interactive-historical- documents-with-archivist-7019f6408ee6#.337wsufou)

<comment><USER3> Mmh, lens example doesn't work well with the ipad pro (safari). I get a zoom on a few words and can't zoom out.

<comment><USER2> For the scientific editor mobile is not a priority atm. However we work on better mobile support for Substance in general. Beta 5 is dedicated to that among other things.

</comment></comment></comment><comment><USER4> Can somebody give any use case that make this project or draft.js interesting compared to all the other WYSIWYG editors available (tinyMCE, CKEditor and so on...)?

Especially since the generated HTML of the editor is very verbose and doesn't respect semantic (header1 isn't translate as h1 but a div with a super long id. Why?)

And what is so terrible about contentEditable? I spent a few minutes with it a few month ago and it felt great (and works on old version of IE), just lacking some library on top of it to give the end user a way to fully control everything.

<comment><USER5> ContentEditable is an absolute nightmare across browsers if you want to normalize your content in any way -- since there's no standard for what the generated HTML is supposed to be, every browser implements it differently (and sometimes very _unusually_ ). Couple that to the fact that you can't control what the user is doing (at least not without intercepting events where possible) and you have a feature that lands somewhere between worthless and actively malicious.

<comment><USER4> In the same way as highjacking the scrollbar, WYSIWYG editors have always feel like a hack to support end user needs without technical background. The idea of being able to seamlessly edit a website, create pages that respect semantic that even my grand ma could maintain is quite compelling to me.

Many of those editors tends to produce bad looking HTML code that might be fine for today but will become an headache to migrate to any other platform or will become an headache when somebody decide they want to change the color of all their link as their crappy editors produce inline styling ....

Anyway we might not have a one size fit all solution but WYSIWYG isn't a perfect solution either.

</comment></comment></comment><comment> david-given Huh. I have actually been looking for _precisely this_ \--- I was going to go with the Guardian's Scribe, but I might investigate this instead.

Unfortunately it looks like it's JQuery and AMD modules, and I'm a Polymer and browserify shop, so it may just not be feasible. [sad face]

<comment><USER6> Old (veeeeeeery old) substance dev here.

They are not AMD based (have a look here indeed [https://github.com/substance/substance/blob/master/browser.j...](https://github.com/substance/substance/blob/master/browser.js#L1)) and about jQuery I'm pretty sure you can wrap it up as a Web Component pretty easily.

<comment> david-given I've never actually used browser-side require, so have no idea how it works --- I just saw a boot.amd.js file.

Also, did I say browserify? I meant vulcanize.

</comment></comment></comment><comment><USER7> They're going down the route of not using contentEditable, which I think is a great move. I was a little bit disappointed when I saw Facebook's Draft.js didn't do the same. It's more work up-front to get something functional, but it's a better pattern for building text editors on the web.

</comment><comment><USER8> Nice! Glad to see mobile support is on the roadmap [1]. So many browser rich editors seem to be virtually unusable on touch devices, it's the first thing I check now.

[1] [https://github.com/substance/substance#beta-5](https://github.com/substance/substance#beta-5)

</comment><comment><USER9> Very exciting project, specially the support for custom document schemas.

If the authors are around, I'd love to hear what was their thinking regarding implementing focus and selection, with regards to the inconvenients outlined by the author of ProseMirror here: [http://marijnhaverbeke.nl/blog/prosemirror.html#general- appr...](http://marijnhaverbeke.nl/blog/prosemirror.html#general-approach)

In a nutshell, ProseMirror chose to keep contentEditable in order to have browser-level support for spell-checking, screen-readers, RTL, etc.

What are the tradeoffs exactly?

Thanks.

<comment><USER2> I think the approaches of Substance and ProseMirror are quite similar. We map DOM coordinates to model coordinates and the other way around. That way we can use the native DOM for cursor navigation (not trivial to implement), but all input is applied on the model first and then updated in the view component.

I had a brief talk with the author of ProseMirror the other day. From my point of view the difference lies in scope. ProseMirror's focus is providing an editor widget that can be extended but works out of the box with HTML + markdown. With Substance you basically start from zero, and you probably have to invest more time to get going. But then you could build apps that are not limited to one isolated editor area for instance. You could build a custom title editor, body editor and metadata editor and have a shared toolbar for them and shared undo/redo history. Substance also provides a bunch of top- level UI components that you can but don't have to use. A ScrollPane with a visual scrollbar for instance. A Table Of Contents component, TwoPanel editor layout etc.

</comment></comment><comment><USER2> Just published an example that shows realtime collab capabilities:

[http://substance.io/examples/collabwriter/](http://substance.io/examples/collabwriter/)

</comment><comment><USER10> This looks really interesting - it's very encouraging to see it being used in real projects of quite disparate types. It bodes well for the maturity and flexibility of the model.

</comment><comment><USER11> For something like this I usually like to see a demo before I invest time in trying it out but the demo link is broken... Seems like something I might want to explore though!!

<comment> david-given There's a demo on the front page --- try typing into the big white box at the top with the bullet points in it.

<comment><USER12> I missed it too. Not obvious at all.

</comment></comment></comment><comment><USER13> With the next release we will package the ability to have editors based on document slices (aka prjections): [https://cloud.githubusercontent.com/assets/284099/13857486/6...](https://cloud.githubusercontent.com/assets/284099/13857486/6be94134-ec7a-11e5-96de-b216b0a3ad06.gif)

</comment><comment><USER14> Does anyone know what GitHub uses for their editor?</comment>


Multi Programming language version manager for Node, Ruby and more - <AUTHOR> https://github.com/asdf-vm/asdf <comment><AUTHOR> Instead of using NVM|N for Node and RVM|RBENV for Ruby just asdf</comment>


Ask HN: How has your experience with Amazon Prime been? - <AUTHOR> Have you run into any issues? Would you stay with Amazon Prime for the long haul? Why or why not?<p>Thanks <comment><USER2> With Prime, local food and beer delivery I haven't needed to leave Mom's ^s^s^s^s my underground lab for months at a time.

I buy a lot of electronics parts from China, etc because of the super low cost and free shipping. While they quote 15-20 days, most stuff shows up in a week or so.

</comment><comment><USER3> I've been a prime.memner for about 18months. I live in a major city, I primarily have it for the video service but prime deliveries and music etc are a good bonus. Great service and will continue to use it.</comment>


The iOS 6 disaster: Apple bit off way more than it could chew - <AUTHOR> http://www.extremetech.com/mobile/136571-the-ios-6-disaster-apple-bit-off-way-more-than-it-could-chew <comment><USER2> Let us ignore Maps, as we've all had a pleasant and merry chat about it and focus on the rest.

Siri/iMessage/iTunes Store Connection Issues are pretty easy to understand (although annoying), they use Apple's backend server infrastructure which is getting _swamped_ by iOS6 downloads, iPhone 5 registrations, iCloud backup creation/restores etc. This doesn't give Apple a free pass, core services shouldn't be getting impacted in this manner, but saying iOS6 is a mess because they've had high load is a terrible thing. That's like saying "My mobile phone provider is a disaster because on New Years Eve it takes ages to send a text", which is annoying and they should prepare for but it's a thing and it's not a disaster.

I've been pleasantly surprised with how stable iOS6 has been, it's had no flaws and no rough edges aside from Maps. The march of cloud based services pushes on, and we'll often find services like iMessage will have issues.

</comment><comment><USER3> Sounds like the only real problem stated is... maps. Every other service is working fine. I have personally tested the system; iMessage, and even Maps (in NYC). It all works great (even maps [in NYC]). So other than Maps this seems like hyperbole of BS.

<comment><USER4> This article is definitely overblown but I will say this is the first time in recent memory where I can remember there being this much frustration with a mainstream Apple product. Many friends have either avoided upgrading to iOS6 or have been relatively unhappy with the upgrade. This is a problem of expectations more than anything but expectations are high because every Apple product launch in the last few years (that I can remember) has been smooth as silk.

<comment><USER3> REALLY?! Did you forget about the Antenna-Gate? The problem that disappeared as fast as it appeared. That was HUGE! No this happens a lot. It's much ado about Nothing.

</comment></comment></comment><comment><USER5> This is a really terrible article. "iOS 6 is a disaster, but it's not just maps.. it's also maps and maps and maps". Seriously? The contents of this article constitutes a "disaster"?

</comment><comment><USER6> Is iOS 6 really a disaster (honest question)? Isn't it selling like hot pie? The general layman is really annoyed by theses problems? Does anyone have numbers?

</comment><comment><USER7> It's not just maps there seems to be bits of iOS6 that just haven't be designed e.g. the sharing options in Safari - <https://pbs.twimg.com/media/A3QbcieCYAEvN7D.jpg:large>

In iPhoto the print icon is actually in color.

</comment><comment><USER8> I love this post as the line for the new iPhone at the SF Apple Store is wrapped up Stockton, down Ellis, all the way to Powell</comment>


CraftStudio: Collaborative game-making platform - <AUTHOR> http://indiegogo.com/CraftStudio <comment><USER2> Hum... Nice idea and good luck. But I would put it in kickstarter because of all the money flowing there, in my humble opnion it would be easier to raise there, more people are familiar with it I think.

<comment><USER3> Hey, thanks! Kickstarter projects can only be started by US residents so that's not an option for me.

Quoting from [http://www.kickstarter.com/help/faq/creating%20a%20project#S...](http://www.kickstarter.com/help/faq/creating%20a%20project#StarAProj):

"To be eligible to start a Kickstarter project, you need to satisfy the requirements of Amazon Payments:

Be a permanent US resident and at least 18 years of age with a Social Security Number (or EIN), a US bank account, US address, US state-issued ID (driver's license), and major US credit or debit card."</comment></comment>


The Frame Problem (2016) - <AUTHOR> https://plato.stanford.edu/entries/frame-problem/ <comment><USER2> Every time I see someone make an illogical prediction about AI, it's because they don't understand the frame problem.

Immense processing power is of no value, if you have no capability of grounding and regrounding it adaptively in reality. That's the job our bodies and our societies provide, and AIs have no way to do it, except taking on a human body and joining human society, at which point an argument can be made they're not AIs any more, but human cyborgs.

<comment><USER3> While I agree that AIs need lots of experience with all kinds of situations to take all of them into account correctly, I don't think that a human body is necessary for that. It could be a network of surveillance cameras, or a fleet of sensor-stuffed cars or any other source of large numbers of observations. To predict the effect of an action, you don't need to be able to execute it yourself; or even if you can do it, there is no need to have done it; simply observing it is enough. There is no reason to suggest that AIs couldn't learn similarly through observation.

<comment><USER2> I don't mean to be rude, but did you read the article? The reason AIs can't learn just from observation is the frame problem.

You use your body to interpret what you see. Animals who are paralyzed from birth are blind, not because they have no eyes, but because they have no embodied experiences to allow them to interpret what they are seeing.

<comment><USER3> _In spite of these subtleties, a number of solutions to the technical frame problem now exist that are adequate for logic-based AI research. Although improvements and extensions continue to be found, it is fair to say that the dust has settled, and that the frame problem, in its technical guise, is more- or-less solved (Shanahan 1997; Lifschitz 2015)._

Yes, I read the article.

> Animals who are paralyzed from birth are blind, not because they have no > eyes, but because they have no embodied experiences to allow them to > interpret what they are seeing.

That's interesting. Where can I learn more about that?

<comment><USER2> [https://io9.gizmodo.com/the-seriously-creepy-two-kitten- expe...](https://io9.gizmodo.com/the-seriously-creepy-two-kitten- experiment-1442107174)

</comment></comment></comment></comment></comment><comment><USER4> I was playing recently with logical planning [1], and heuristics to determine what possible actions to explore. A heuristic that I happened upon, that worked quite well, was to work backward from the desired solution and choose actions that reduced the requirements on the state of the world.

The result was not plans that were optimal, but it found plans quite quickly. When I changed it to find optimal plans (essentially performing a reverse breadth-first search) then it did so, but instead of "finding" a solution it simply exhausted the space of actions and states. The algorithm stopped seeming intelligent, and merely felt thorough.

I wonder if this is state-requirement-reducing heuristic is closer to the problem-solving approach we use. Not an approach where we understand the world thoroughly, but one where we make plans that require the least specificity of the state of the world.

In part this is because our planning is iterative; given a goal: plan towards the goal, perform an action, observe the state, plan towards the goal, perform the next action. Unexpected effects are accounted for... eventually. And the result is often not optimal.

Also logical planning does not introduce conditionals, even though our plans always contain conditionals. To use the Yale Shooting Problem [2], we might construct a higher-order action, like "shoot the turkey" – and implicit in this action is "if the gun is not loaded, load the gun, then shoot the turkey". Also "if the turkey has escaped, find the turkey, then shoot the turkey". If the turkey escapes while you are loading the gun, then perhaps a better plan would have included securing the turkey before loading the gun, but this is exactly the sort of mistake that humans make in their planning.

With conditionals it's even easier to have actions that reduce the specificity of the requirements to achieve a goal. But the plans will probably not be optimal, but still they are resilient to a world with unintended consequences.

[1] [https://github.com/ianb/bitplanning](https://github.com/ianb/bitplanning) [2] [https://en.wikipedia.org/wiki/Yale_shooting_problem](https://en.wikipedia.org/wiki/Yale_shooting_problem)

</comment><comment><USER5> This seems really stupid to me. An action has defined effects, there is no reason to think of all possible nonexistent side effects. Then they allow for that as a default and point out an apparent exception: what if an object is moved into a can of paint... This is so incredibly stupid I can't imagine people take this seriously.

<comment><USER6> > there is no reason to think of all possible nonexistent side effects

But there is. Actually there are two reasons.

The first is that the "non-existent side-effects" are only non-existent in certain circumstances, i.e. an action's effects depends heavily on the context in which it is executed. Moving X from A to B can have lots of other effects beyond changing the location of X depending on the circumstances. These effects can be _arbitrary_ \-- consider for example the case where X is a switch and A is the OFF position and B is the ON position.

The second is that there really is no such thing as a truly non-existent side- effect because even a null action -- waiting, doing nothing -- results in change, and sometimes that change turns out to be the best way to achieve your goal. For example, if you're a farmer whose goal is to water their crops, one way to do it is to do nothing and wait for rain. But to figure out whether or not that's what you should do you have to know an awful lot about how the world works.

In fact, waiting and doing nothing is often an integral part of many goal- achieving procedures. Think about, for example, traveling as a passenger on an airplane. The usual procedure goes something like:

        Buy a ticket
        Wait
        Go to the airport
        Wait
        Board the plane
        Wait
        Disembark the plane

If you leave out the null actions, that procedure fails badly.

</comment></comment><comment><USER7> I'm just happy that somebody thought it worthwhile to post this article here. With all of the heard running towards ML, its great to see that not everyone has forgotten GOFAI inspired issues!</comment>


Ask HN: What are the options for getting notifications? - <AUTHOR>

I'm considering making HN my new crack addiction but this seems like such an obvious missing feature.  I don't want to look on my iPhone for updates (from notifo) - any other options? <comment><USER2> Add a webhook:

<https://api.notifo.com/docs/webhooks>

And you can redirect your notifo alerts to email/rss with a tiny bit of code.</comment>


Why is there a 'null' value in JavaScript? - <AUTHOR> https://stackoverflow.com/questions/461966/why-is-there-a-null-value-in-javascript/12962408#12962408 <comment><USER2> > I think that your conclusion that JavaScript defines undefined as "there is > no such property" and null as "the property has no value" is perfectly > correct.

This answers a puzzling irk I had with TypeScript where name?: <type> could have a valid value of <type> or undefined rather than what I'd expect to be null or a non-null valid value of <type>. If I consider that 'name' is a property of the containing object then undefined makes sense in context. It is annoying to say <type> | null | undefined though.</comment>


Ethel Lang, the last Victorian, has died - <AUTHOR> http://www.theguardian.com/commentisfree/2015/jan/18/ethel-lang-last-victorian-dies-victorian-values-live-on

<comment><USER2> I know some Australian Victorians that would feel different... [http://en.wikipedia.org/wiki/Victoria_%28Australia%29](http://en.wikipedia.org/wiki/Victoria_%28Australia%29)

</comment><comment><USER3> My favorite anecdote in this vein is that John Tyler, President from 1841-1845, has two living grandsons (although I think one may have passed on in the last year).

[http://www.snopes.com/history/american/tylergrandsons.asp](http://www.snopes.com/history/american/tylergrandsons.asp)

</comment><comment><USER4> It sounds like a long time ago but there are some surprisingly good pictures of Queen Victoria out there as photography came into its own in the late 1880s. Here's one of her smiling in a carriage:

[http://en.wikipedia.org/wiki/Queen_Victoria#mediaviewer/File...](http://en.wikipedia.org/wiki/Queen_Victoria#mediaviewer/File:Her_Majesty%27s_Gracious_Smile_by_Charles_Knight.JPG)

<comment><USER5> A working link:

[http://upload.wikimedia.org/wikipedia/commons/0/06/Her_Majes...](http://upload.wikimedia.org/wikipedia/commons/0/06/Her_Majesty%27s_Gracious_Smile_by_Charles_Knight.JPG)

</comment></comment><comment><USER6> This is a bit like the last widow of a soldier in the American civil war dying in 2008 [1]. History is not as far away as it appears.

[1] [http://en.m.wikipedia.org/wiki/Maudie_Hopkins](http://en.m.wikipedia.org/wiki/Maudie_Hopkins)

<comment><USER7> True, although she didn't personally live through the civil war. Missed it by 50 years.

</comment></comment><comment><USER8> As a Canadian who doesn't have much patience to spare for what passes for British royalty these days, it's fascinating to think of a time, just one human lifetime ago, when Canada was a part of an empire ruled by a monarch who actually _mattered_. There is much fault to be found in Victorian values, but those values and Queen Victoria herself did much to free the British empire from rule by British despots. Victoria's rule, and the values she promulgated, paved the way for the Commonwealth of today. Even though Britain typically acted with rapacious greed in exploiting its colonies, somehow most of them achieved independence peacefully and, in most cases, are today better off than neighboring countries that were not a part of the empire. Victorian values are largely to thank for this implausible bit of history.

<comment><USER9> I think the best frame of reference is to look at colonisation by British in comparison to other countries. The difference is that the British tended to leave behind a system of governance wbased on English common law, which stretches back a millennia. That also leads to functioning institutions.

So while some see colonisation as exploitation - certainly by the standards of today it is unthinkable - in other cases you can see the bequeathed laws and institutions have made up for that over time, leaving those countries able to stand on their own feet. The peaceful transitions are by design with the promotion of the rule of law and creation of Houses of Parliament and courts and separated church, government and armed forces.

Interestingly the school of thought I have read says that the commonwealth independent model has everything to do with American independence - better to have a stake in something than lose everything.

<comment><USER10> You're rewriting history (both of you are). Colonialism in Africa was certainly detrimental and exploitative, and not just by standards of today. The "peaceful transitions" you speak of, included borders and methods of government that were set up for the benefit of the colonial powers, the ramifications of which continue to this day. And while independence was achieved peacefully in some cases, colonization itself was a violent process.

[http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1182&...](http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1182&context=utk_chanhonoproj)

[http://exhibitions.nypl.org/africanaage/essay- colonization-o...](http://exhibitions.nypl.org/africanaage/essay-colonization- of-africa.html)

<comment><USER11> Not every case was bad. It was extremely successful in New Zealand with hardly anyone killed (relatively speaking), a peace treaty quickly signed and the quality of life brought up to modern standards, ending 1000 years of murderous tribal warfare. The natives didn't have their own country before it was colonized because they were fractured into tribes. So it was absolutely a good thing to save them from themselves.

<comment><USER12> "Save them from themselves" is quite possibly the most dangerous mentality to have ever existed on the face of the Earth. The Belgians thought they were saving the Congolese from themselves. Totalitarian states thought they were saving the people from themselves. As soon as you take it upon yourself to decide what is good for someone else, you have decided to become a god with the knowledge of a man. I am quite disappointed to see such ideas supported here.

<comment><USER13> The Belgians knew they were in it for the money - the main reason it went so wrong there is that they really needed the money now, and so were willing to inflict long-term damage for short-term profit.

Yes, it's very easy to get helping other people wrong, but the answer isn't to give up on doing so entirely.</comment></comment></comment></comment></comment></comment>


OpenSSL Security Advisory - <AUTHOR> https://www.openssl.org/news/secadv_20150108.txt

<comment><USER2> The optics of this advisory are bad, of course, but these are probably not operationally important bugs for most people:

* DTLS segmentation fault in dtls1_get_record ( _only impacts people who use DTLS, and is a null pointer deref, which usually isn 't exploitable_)

* DTLS memory leak in dtls1_buffer_record ( _same, and only exhausts memory_ )

* no-ssl3 configuration sets method to NULL ( _a non-standard build produces a null pointer crash in SSL3 negotiation_ )

* ECDHE silently downgrades to ECDH ( _this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl_ )

* RSA silently downgrades to EXPORT_RSA ( _a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl_ )

* DH client certificates accepted without verification ( _breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are "extremely rare and hardly ever encountered"_)

* Certificate fingerprints can be modified ( _this one I actually wonder about the sev:lo on; it 's low because it doesn't impact browsers, but certificate blacklists are common in enterprise software_)

* Bignum squaring may produce incorrect results ( _this is just weird_ )

<comment><USER3> That bignum one is weird. The patch suggests the character of it: something in the carry logic between 32-bit words, replicated for each assembly architecture as well as C. Here's the C version:

       #define mul_add_c2(a,b,c0,c1,c2) {	\
       	BN_ULONG ta=(a),tb=(b),t0;	\
       	BN_UMULT_LOHI(t0,t1,ta,tb);	\
      -	t2 = t1+t1; c2 += (t2<t1)?1:0;	\
      -	t1 = t0+t0; t2 += (t1<t0)?1:0;	\
      -	c0 += t1; t2 += (c0<t1)?1:0;	\
      +	c0 += t0; t2 = t1+((c0<t0)?1:0);\
       	c1 += t2; c2 += (c1<t2)?1:0;	\
      +	c0 += t0; t1 += (c0<t0)?1:0;	\
      +	c1 += t1; c2 += (c1<t1)?1:0;	\
       	}

The test case adds this number: 0x80000000000000008000000000000001FFFFFFFFFFFFFFFE0000000000000000

If you were wondering whether OpenSSL code has really gotten too complicated, wonder no more.

Full patch: [https://github.com/openssl/openssl/commit/e078642ddea29bbb6b...](https://github.com/openssl/openssl/commit/e078642ddea29bbb6ba29788a6a513796387fbbb#diff-6dd63052b7680975a9eeb33dca68da52L478)

<comment><USER4> It's clear LibreSSL is only a half measure.

TLS is far too complicated with design-by-committee, special vendor extension sauce nonsense. Heck, the FIPS code was rushed and basically done at the behest of US/Canadian govts. OpenSSL should consider burning their deadwood and stop adding features until it gets its house in order.

There's no telling how large of an attack surface remains at the protocol level, in the codebase and with CAs being compelled to issue rogue certs for MITMs.

Moreover: Can TLS features be narrowed to focus on popular and high-value use- cases instead of SCTP, UDP, oh look a bird feature? It's fine for hacking on, but not production code. (If "TLS" is evolutionarily to "Perl," who's working on a "Python"?)

BTW: What ever happened to the cert WoT overlay 'moxie0 was working on?

<comment><USER5> It is true that TLS is part of the problem. But, it is also a widely deployed standard that cannot be changed overnight. That's why LibreSSL is necessary.

We need to build simpler protocols that make better use of cryptographic primitives, but first, we have to push back the tide. Eventually, TLS will be superseded by a better standard. But, this is something that even if started today with the most aggressive schedule would take 5 to 10 years to go industry-wide.

</comment></comment></comment></comment><comment><USER6> Seems like INRIA is starting to do some formal checking of OpenSSL. Here's their page: [http://prosecco.gforge.inria.fr/](http://prosecco.gforge.inria.fr/)

Here's another OpenSSL flaw that was found with Coq, a formal prover: [http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS- Inject...](http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection- en/index.html)

</comment><comment><USER5> While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don't mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base.

LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it's only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it's this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years.

</rant>

<comment><USER7> Rust would also eliminate these bugs, as a class. And Rust has inline asm, for those cases where you need platform specific. Finally, Rust van export a C ABI library, so you could make a drop-in replacement.

<comment><USER8> "these bugs, as a class"

It absolutely would not eliminate CVE-2014-3570 or many other of the cryptographic bugs that show up in OpenSSL and other TLS implementations.

This kind of axiomatic thinking that memory safety equals all safety almost resulted in Rust being less safe (IMO) than C in these other respects: the normal types in rust are all defined to overflow even though overflow is almost always a bug, and so you couldn't use static analysis on arbitrary rust codebases to warn you about these issues (where you can in C because signed overflow is undefined, so an analysis tool can always flag that as an error without it being a false positive). Fortunately, it sounds like Rust is moving to fix this ( [http://discuss.rust-lang.org/t/a-tale-of-twos- complement/106...](http://discuss.rust-lang.org/t/a-tale-of-twos- complement/1062) ), which is a big improvement.

But it's important to not be fuzzy about the risks. There is a well established link between safety equipment and risky behavior in driving and bicycling; ([http://en.wikipedia.org/wiki/Risk_compensation](http://en.wikipedia.org/wiki/Risk_compensation)). I don't mean to suggest that better isn't better and we shouldn't use safer tools, but if our response to safer tools is to lower our vigilance, even the slightest, we may get worse results.

<comment><USER5> I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core foundational libraries like OpenSSL are written in C: portability, age of the code base, knowledge of the contributors, etc.

While I would personally like to see a pragmatic move towards C++ in many of these low level libraries for some of the additional type safety and mechanics the language provides, this is a normative idea only, and I am under no delusion that it would necessarily result in better code. Good software transcends language.

I would, however, like to see enhancements to the style of code being written in this library so that tools like static analyzers and contract verifiers can provide meaningful results. A craftsman is only as good as how well he/she can make use of the available tools. Much of OpenSSL defies analysis, which is why the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard to find.

It's impossible to eliminate all bugs. But, it is possible to build code in such a way that when there is the suspicion of a bug, one has a fairly good idea of how and why it is occurring. It is also possible to structure code -- even C and assembler -- so that it's easier to read and analyze, be this by eye or using tools. Finally, it's possible to structure code so that automated unit testing provides meaningful results regarding boundary conditions and contracts between functions. This latter point isn't meant to find bugs on its own, but rather to codify the more subtle bits of contracts between functions and data structures in a defensive way to ensure that future patches -- like the one that caused Heartbleed -- don't stomp on assumptions made in software.

<comment><USER7> > There is nothing inherently wrong with C

The fact that almost no teams on Earth seem to be able to ship large codebases without severe vulnerabilities rather disputes that idea.

<comment><USER5> Let me assure you that this is true regardless of language or platform.

I've done vulnerability analysis on codebases written in C++, Java, C#, Objective C, Ruby, and Python. I've found bugs in each of these platforms. The biggest differentiator I found was experience. More experienced software developers, on average, made fewer bugs resulting in vulnerabilities than less experienced software developers.

There is no magic language or platform that makes writing secure software easy. There are tools, techniques, and training that can help. But, these can only help. Writing quality software -- of which security is an important part -- is a difficult process that requires a lot of experience and discipline.

<comment><USER7> Please point to the CVEs for the plethora of remote code execution bugs in apps written in Java and C#, for instance.

I went through every single security bulletin MS published over the past couple years. The vast majority of the serious ones were 100% due to memory safety issues. The biggest exception was due to trying to sandbox arbitrary code (their .NET equivalent to Java applets).

If you have some counter-evidence, showing C to be even remotely as safe as, say, Java, please step forward. If you are actually saying "Well I found a lot of SQL injection bugs in code written in Java", that's a different issue. And I'm sure you're aware of it.

There's probably a name for the use of rhetoric of the form "Nothing's perfect. Therefore X and Y are just as good, since they are both imperfect."

<comment><USER5> Luckily, I don't have to respond by your goalposts.

You are hammering on a single class of security vulnerability out of hundreds of potential vulnerabilities. How does Rust prevent a confused deputy vulnerability? How about SQL Injection? Okay... well, what about all of the potential side channel attacks?

People in higher level languages tend to believe that the relative safety of their position means that they have to be less vigilant about vulnerabilities. That is often what I have found. The number of vulnerabilities overall were similar, but the type of vulnerabilities were different. Because there was a completely mistaken belief that these platforms were "more secure", security practices were often sloppy. Most of these vulnerabilities were at the application level. So, looking for Microsoft CVEs isn't going to help you.

The C++ code bases tended to have more senior level people working on them, who were more careful about both defects and vulnerabilities. Code bases in higher level languages, in general, had more junior level people working on them. Largely, the number of vulnerabilities were similar.

Again, I'm speaking of my own experience. But, I think that many researchers in the field would give you a similar story. I'm always wary of people promising silver bullets over hard work.

<comment><USER7> So by your own logic, if experienced C++ developers wrote in, say, Rust, they would not make mistakes like SQL injection, _and_ they wouldn't be making all the memory-safety mistakes, either.

Edit: If your overall point is that systems are laughably insecure, and most app devs just leave gigantic holes open, sure, great. But let's not compound that by making their OSes and low-level network stuff run arbitrary code for anyone on the Internet.

<comment><USER5> It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat.

But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience.

I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C.

All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all.

A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.

<comment><USER7> If you can teach people how to write safe C code, you should setup a site and rake it in. Meanwhile, Mozilla, Microsoft, Google, and others have tried to build safe applications and simply fail due to memory safety issues. When such high profile teams cannot deliver, then at some point you gotta say "hmm, maybe the language is at fault".

I understand you like C/C++ and want to point out that if people delivery on a superhuman effort, then we can have nice things. Meanwhile, in reality, so far, this just doesn't happen. Lemme know when we can go a year without a memory safety issue getting tons of systems owned.

<comment><USER5> When Rust has been around long enough, and people have started adopting it, then we'll see vulnerability reports in systems developed in Rust too. As I said, there are no silver bullets in security.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2.

1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP/2, adds support for cross-root certificate validation).

</comment><comment><USER10> I'm unable to compile this on Win32 (I don't have any problems compiling older versions). I don't understand how the code could compile for anyone, maybe it's a platform specific issue. Take a look here on line 80:

[https://github.com/openssl/openssl/blob/master/crypto/cversi...](https://github.com/openssl/openssl/blob/master/crypto/cversion.c)

The variable cflags isn't defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file.

I thought C defines were case sensitive on all platforms. Anyone knows better than me?

<comment><USER11> You have to keep in mind that OpenSSL runs several Perl scripts as part of its build process. And it's one of these scripts that generates a header which defines the cflags variable:

[https://github.com/openssl/openssl/blob/103b171d8fc282ef435f...](https://github.com/openssl/openssl/blob/103b171d8fc282ef435f8de9afbf7782e312961f/util/mkbuildinf.pl)

Apparently this is done to work around potential length limitations in C string literals.

<comment><USER10> I can compile the previous versions. I've used the same script for several years, and its not until this version today I have an issue. When seeing the issue, I actually tried compiling the old versions again and those still worked.

It would seem odd if they actually change the build process in a security patch, right? The instructions on how to build OpenSSL on Windows has not been changed in 2 years.

<comment><USER12> > It would seem odd if they actually change the build process in a security > patch, right?

No release of OpenSSL has ever been "the previous release plus the minimal patches for a security fix". This isn't a security patch. It's a new release that happens to include some security patches.

<comment><USER10> It's a security patch in the sense that the only way to get the security patches is to install the new version.

But thanks for the info. That seems like a pretty bad practice when it comes to a lib such as OpenSSL. Having to do changes to the build process to integrate an urgent security fix seems less than optimal.

</comment></comment></comment></comment></comment><comment><USER13> [https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j......](https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k)

And for future releases, it may be worthwhile to watch this URL to find unpatched vulnerabilities:

[https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k......](https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...OpenSSL_1_0_1-stable)

;)

<comment><USER12> > VMS fixups for 1.0.1

Oh, whew!

<comment><USER14> Oh good; I was worried there for a second; now I know that my VAX will be nice and secure!

</comment></comment></comment><comment><USER15> Nothing on centos/epel yet.

</comment><comment><USER16> [https://www.openssl.org/news/secadv_20150108.txt](https://www.openssl.org/news/secadv_20150108.txt)

<comment><USER2> This should be the link this story points to.

<comment><USER17> Changed from [http://marc.info/?l=openssl- announce&m=142046772204265](http://marc.info/?l=openssl- announce&m=142046772204265). Thanks.

</comment></comment></comment><comment><USER18> Security advisory: [https://mta.openssl.org/pipermail/openssl- announce/2015-Janu...](https://mta.openssl.org/pipermail/openssl- announce/2015-January/000007.html)

<comment><USER19> Here's a link which doesn't double as a survey to see how many HN readers will override the HTTPS validation warning:

[https://mta.opensslfoundation.net/pipermail/openssl- announce...](https://mta.opensslfoundation.net/pipermail/openssl- announce/2015-January/000007.html)</comment></comment>


Ev3dev - <AUTHOR> http://www.ev3dev.org

<comment><USER2> No love for C#, well one could argue that once .net 5 is done, it would be possible to use C#</comment>


US gov't: Snowden also took secret docs while working at Dell in April 2012 - at-fates-hands http://arstechnica.com/tech-policy/2013/08/us-govt-snowden-also-took-secret-docs-while-working-at-dell-in-april-2012/

<comment><AUTHOR> So the government should have had a year to catch him before he went AWOL to HK? Holy Cr*p! Please, please, please... when do they learn to shut up?

</comment><comment><USER2> Why does Dell, a hardware manufacturer, have a relationship with the NSA?

</comment><comment><USER3> And this claim, assuming it's true, is important enough or interesting enough to spread because .... ?

<comment><USER4> Last night in the thread on Groklaw shuttering due to pj not liking her personal life being burrowed through I made a comment asking people to distance themselves from companies involved NSA related activities if they are not willing to make firm demands of their employers. Enabling the works that the US government/NSA pay for services on while bringing home a paycheck is indeed being complicit once made aware of the activity of your employer.

Due to my inclusion of the name "Dell" I was accused of thinking that "the entire info-tech infrastructure, companies and "wage-slaves" alike are complicit in all this.[1]" Even though I never mentioned "wage slaves."

Well, the user wasn't aware of Snowden obtaining NSA documents while there, he just needed to be alerted of the information. But before that time the response I received was "Dell? A computer hardware device assembler? What on earth are you on about.[1]"

I imagine now the question that user is asking is "Dell? A computer hardware device assembler? What on earth is the NSA's involvement with them and why does Dell's employees have access to volumes of sensitive data?"

It is important enough simply because it is.

[1] [https://news.ycombinator.com/item?id=6242740](https://news.ycombinator.com/item?id=6242740)

<comment><USER3> Ah, yes. I thought the intent was to spread rumors about what Snoden might have done while working for Dell, and was oblivious to the elephant question of why Dell might have had that information in the first place.

Thanks for clearing things up.</comment></comment></comment>


29-Year-Old Rejected by 35 Potential Employers. Now, Co-Founder of $1B Startup - <AUTHOR> https://www.entrepreneur.com/article/274693 <comment><USER2> Would've made for a more interesting story if the guy hadn't come from money and actually worked his way up from nothing.

<comment><USER3> To be fair, it sounds like his family members were decidedly middle class entrepreneurs. It doesn't sound at all like he "came from money."

And as for "interestingness":

 _"I wouldn't be here without my brother or the other guys at Twitch. That's probably the most important thing," he says. "Not just having an idea or executing on an idea -- it's all about the connections that you have and the people you know and the people who support you."_

I actually appreciate the fact that the article tells it like it is. We might want to prefer to believe that if we just have the right idea, we can beat out the people who went to the right schools, and/or had amazingly successful family members -- without working 10x as hard. But in reality, it just isn't so.

<comment><USER2> My point was that this is just another story about a guy from a wealthy family who goes on to become very wealthy himself. Reminds me of the cliche where someone who is definitely not poor goes to a prestigious university, has an idea, creates a startup, drops out, becomes rich.

<comment><USER4> This path will always exist due to confirmation bias resulting from rational decision making. Someone grows up wealthy, gets opportunities to go to a prestigious university, and accepts it. Should they have said no to the university? Of course not... so their _rational decision making_ advances them one step further on the self-perpetuating path. Next, they're at university and they meet some people who introduce them to venture capitalists. Should they refuse the introduction, since not everyone gets to talk to venture capitalists? Of course not... so they make a rational decision and take the venture capital.

I agree with your sentiment that this is a common trope. I'm merely suggesting that it is inevitable and self-perpetuating. As long as people make rational decisions to accept the best opportunities offered to them, they will funnel themselves into the "path of privilege," maybe without even realizing it.

Of course, it's questionable whether the best opportunities are the ones that only come to you because of your status.... usually that means there is excess supply of those opportunities and you are on the verge of entering a culling machine. (See: recent increase in CS majors)</comment></comment></comment></comment>


Show HN: Unit Circle Visualization in Elm - <AUTHOR> https://aesakamar.github.io/unit-circle/ <comment><USER2> Neat!

Since the "Star" button isn't clickable, here's a link for anyone else interested in the source: [https://github.com/aesakamar/unit- circle/](https://github.com/aesakamar/unit-circle/)

</comment><comment> prospero-live Very elegant! I was once a math tutor and this would have come in handy. Particularly for students who are primarily visual learners to get an intuitive feel for sec, csc, tan, and cot.

<comment><AUTHOR> I was good at secondary school maths, and got SOHCAHTOA and all that, but this visualisation would have help me understand it a lot better, and not be so scared of the other things like COT. I didn't even learn COT at school, but knew of it's existence through BBC BASIC.

Also I like this visualisation because it shows what we can easily do with SVG and JS (in this case Elm compiled to JS). It is a lot more powerful than Flash, but I don't see this kind of thing used much on the web, it would be good to see more of it, (for good uses of course)</comment></comment>


When did blog comments die? - <AUTHOR> http://www.phpied.com/when-did-blog-comments-die/ <comment><USER2> I think they died when Facebook Comments and Disqus grew like weeds. they promised less spam, faster loading times, easier to use on multiple sites, etc. It became way easier to handle things that way rather than deal with all of the spam and trolls.

</comment><comment><USER3> they pretty much died with the rise of community sites like reddit and such. people post links and comment there.

<comment><USER4> This was my thought as well. Then I started thinking about the huge amount of moderation effort to make sure that comment sections stay civil. From where I stand it seems like for most writers offering a comment section is a lot of work for a very small payoff.

<comment><USER3> If you think of it from the perspective of "building and maintaining a jail" yes, it is hard. You as the blog admin represent the warden, and as such are the enemy

But if you have the inmates police themselves (like the reddit community), problem solved.

<comment><USER5> "Solved" only in the sense that "the community" polices itself to become something that most in "the community" consider desirable (or at least acceptable). But that might not be the kind of community the blog author/owner wants.

To put it in concrete terms: HN is moderated. Reddit is policed by the inmates. Which is a better community? I'll take HN by a fair distance.

<comment><USER3> > I'll take HN by a fair distance.

I understand where you're coming from.

That being said, I knew reddit will begine to wobble when it went corporate</comment></comment></comment></comment></comment>


General Catalyst Lands Facebook Co-Founder to Help Create Next-Gen Web Media Startups - <AUTHOR> http://www.xconomy.com/boston/2009/03/18/general-catalyst-lands-facebook-co-founder-to-help-create-next-generation-of-web-media-startups/

<comment><USER2> So i'm curious how one becomes a resident entrepreneur... aside from doing something astounding like Chris has. if anyone can speak to this from experience i'd appreciate it.

<comment><USER3> VCs generally bring in entrepreneurs in residence (EIRs) for one of the following reasons:

1\. To help source (i.e. find) great startups they can consider for investment.

2\. To help provide advice/guidance to existing portfolio companies (EIRs are often successful entrepreneurs themselves).

3\. To assist with due diligence and analysis of potential investments.

4\. To possibly place the EIR at some future portfolio company (often, EIRs are looking for their next opportunity).</comment></comment>


Women overtake men in IQ tests for the first time in 100 years  - <AUTHOR> http://www.dailymail.co.uk/news/article-2173808/Women-overtake-men-IQ-tests-time-100-years-multitasking.html

<comment><USER2> Great that women are improving on the IQ tests, but are IQ tests not a bit flawed?

I do not think multitasking is the reason. I think it is because they were so adapted to the old men's world where they were not allowed to show their smarts that now that they can they are doing a sprint.

Like how someone that has always gotten something expects to get it in the future and does not hoard it, but if you didn't always get it, and then you can grab all you want. You will grab as much as you can.

</comment><comment><USER3> >Two years ago, a five-month online contest between the sexes concluded women were cleverer than men. The competition in nine languages was based on the popular board game Trivial Pursuit. More than 15 million questions were asked and although the balance of power shifted consistently women narrowly clinched victory. They answered 4,088,139 questions correctly, compared to the 4,077,596 right answers given by men.

Trivial Pursuit is an IQ Test?</comment>


Jet.com Is Making Its Employees' Salaries Transparent and Non-Negotiable - <AUTHOR> http://www.forbes.com/sites/erikamorphy/2015/07/21/jet-com-is-making-its-employees-salaries-transparent-and-non-negotiable/

<comment><USER2> Salary transparency essentially has taken all power away from the employee

Companies normally will get in trouble if they talk to each other about salary, but now that there is transparency, it's public information.</comment>


Godaddy .com domain just 1.99/yr - <AUTHOR> http://www.godaddy.com/deals2/?isc=cjc199x&utm_source=buffer&buffer_share=26af4

<comment><USER2> Finally the opportunity to buy GodaddyYouSuckForSupportingSOPA.com

</comment><comment><USER3> I'd rather pay 10x that to avoid using GoDaddy at all.</comment>


Invisible CAPTCHA - <AUTHOR> http://jaudu.net

<comment><USER2> This is much easier to overcome than image/text CAPTCHA systems.</comment>


Show HN: Jasymchat, Computer algebra system (CAS) with chat - <AUTHOR> http://jasymchat.com

<comment><AUTHOR> dev here...happy to answer any questions.

<comment><USER2> 1\. No history.

2\. No online help.

3\. After making an entry, the system's response scrolls out of view.

4\. The IPython notebook environment already exists, is suitable for server environments, and is much more polished.

[http://ipython.org/ipython- doc/rel-1.0.0/interactive/public_...](http://ipython.org/ipython- doc/rel-1.0.0/interactive/public_server.html)

I hope this helps.

<comment><AUTHOR> there is extensive help...actually the entire doc is included right at the top.

It is not IPython and isn't meant to be.

Not sure what you mean by history but if you sign in you can save sessions.

<comment><USER2> > there is extensive help ...

Yes, but, unlike most CAS systems, there's no inline help. "help (command)" doesn't work. "command?" doesn't work.

> It is not IPython and isn't meant to be.

Okay, but you do realize that this application lives in the same world with its alternatives, yes? And that IPython does what this application does, but better?

> Not sure what you mean by history ...

Try pressing your keyboard's up-arrow to see if your prior entries come into view.

The fact that the server's response scrolls out of view is by itself a show- stopper. The user is reduced to providing scroll-down inputs constantly during a work session. This kind of problem is trivially solved.

Just trying to help.

<comment><AUTHOR> Feedback is appreciated.

Yes inline help isn't currently supported...I believe you typed "help solve"? That won't work right now:)

There is a "Recall" button, it is meant to emulate the up-arrow recall feature you find in CLI environments...I might add it.

This is really meant for high-school/undergrad/and maybe grad students...IPython is a much more comprehensive environment.

In any case thanks for the feedback.</comment></comment></comment></comment></comment>