windlep

Would've been nice if the article had pointed out that ad-networks have become a popular way to distribute trojans and malware using Flash exploits (though I'm sure when Flash is gone, ppl will keep finding other browser exploits ad's can exploit).

Sleep deprivation. It explains all the symptoms mentioned in the article.

Kids in kindergarten start early, and stay later than they have in the past with no nap period. Busy parents (both of whom are now working full-time) are lucky to get home by 7pm, so the kid(s) are generally kept up till 9/10pm so the parents can have some time with them.

If parents are going to keep a 5/6-yr old up to 9:30pm or later, then wake them up at 7:15am to get ready for school at 8:15am.... which goes till 2pm with no nap time. Well yea, sleep deprivation hurts.

Ask your parents, grandparents, etc when they went to sleep, when kindergarten began, how long it ran, whether it included a nap/rest-time. Most of us got a lot more sleep than the kids now.

Edit: I agree kids need more free-play time, but that's separate from their sleep deprivation.

"To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."

So, the best GC for the next decade was proposed in 1978. Whatever computer scientists have proposed since then apparently hasn't been as good.... so they can all just pack it up and go home?

I'd be really really curious to hear from some academic computer scientists if the best that can be done was first proposed back then, and they've all just failed to find anything better since. Cause this is just downright depressing otherwise (If you actually want to believe that we're making progress).

The article is terribly mislabeled. Uber's bookings are scheduled to reach 26bill, not its revenue. Supposedly this year they will reach 10 bill in bookings, which would provide revenue of about 2 billion [1].

[1] http://www.reuters.com/article/2015/08/21/us-uber-tech-fundr...

Soylent open-sourced their recipe afaik, that was part of the whole appeal for many, they could replicate the entire formula and tweak as desired. There's other food-replacements as well, like ensure, which I cited.

Edit: Soylent has an entire forum of various varients of their recipe: https://diy.soylent.com/recipes

I'd love to see this study replicated, only instead of "proprietary (expensive?) product", it was just 40% of your daily caloric intake.... in soylent.

There's been multiple studies I've seen now indicating that fasting does this, the questions I want to know are:

1. How much of a caloric intake drop is required?

2. How much does it matter what specific types of calories are used for the lower-calorie period? (ie, 500 cals of fast-food vs. soylent vs. prolon vs. ensure)

3. Is there any tell-tale sign we can test for indicating when a sufficient 'period' has occurred for the benefits, thus knowing we can resume normal diet?

I can only imagine if these scientists are associated with a specific product, they probably don't have a huge reason to find out if a cheap existing product (soylent/ensure) works just as well as their most-likely-more-expensive-proprietary one. But it's the first thing I want to know.

Ground Kontrol (http://groundkontrol.com/) has generally done an awesome job imparting the vibe I remember. And The 1-Up (http://www.the-1up.com/) has given me similar goose-bumps.

Of course, now that I can enjoy a beer, the fact that both these arcades serve fantastic beer and some food sure doesn't hurt. I'm only sad that I don't live in Portland or Denver near these arcades...

Was quite excited to try out a little websocket server with Kore till I saw it fork's per connection. I don't really want 20k processes for handling 20k connections, I was really hoping for an event loop.

"I can't trust air I can't see", was my favorite line of my grandfathers, who lived in LA for the past 60 years. He always mentioned how incredibly clear and clean the air is now compared to a few decades ago (where I live in Northern California now, even the Bay Area seems polluted and smoggy most days).

First thoughts in my head....

1) Ah, cool, creator of Raft algo, so some of the 'obvious' mistakes in an implementation should've been resolved by now (though if ppl weren't trying to use it in production.... who knows).

2) Great, C++, it should be efficient and fast with consistent RAM usage (Go's GC is a bit.... eh... still).

3) Oh, you need a C++ client library. :(

I would love to say that API's don't matter, but they do. So, so, so much. If they didn't, etcd would never have had a chance against Zookeeper. The Zookeeper folks are looking at adding RESTful API's to allow functionality ala-etcd, because its obvious a convenient API is a huge win. Any distributed system solution attempting to gain steam should consider this from the beginning now, as the bar has been set.

With regards to the name-server bit, I honestly can't re-iterate this enough. It's amazing how many "My internet is slow" remarks really come down to DNS resolving slowly. My router has WAN failover, and I've had to manually tweak the DNS it chooses many times because even when a WAN is 'up', the DNS it uses might have latency exceeding 2+seconds for hours at a time (Comcast) even though the link itself is perfectly fast (125Mbit).

Merely setting a different DNS source immediately shows off the full potential of the link. I still need to setup my own local DNS server so that I can be rid of this problem entirely. :(

So... $337 for a decent soekris board and 'ok' case... or $340 for this: http://www.amazon.com/Ubiquiti-Networks-Edgerouter-Router-ER...

The latter has a complete open-source OS, you can ssh in and re-flash it yourself easily, a great community, the same TCP hardware offload, etc. I have been spec'ing out a BSD+soekris board setup for years, but when the Edgerouter came on the market it was a no-brainer. The fact that it works-out-of-box with little effort (for someone experienced with networking) is a big win, and that its quite easy to re-flash it and tweak as desired sure doesn't hurt.

While I really dig the DIY-router stuff, and was about to do it myself, Ubiquiti has sure made it hard to go that route when they can supply dang good products for the same price or less.

Edit: Added bit that this isn't a "zero effort for newbs" type product. If you've never setup a router, there'll be some research in your future to setup an Edgerouter, or BSD router.

I meant more that languages with an iterator/generator usually have similar constant space usage. That is a drastic oversimplification of stream fusion and fails to mention other practical outcomes as you mention, along with a variety of optimizations.

I found this posting a little more approachable to seeing the various optimizations possible with stream fusion: https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-...

Yep, that was added after my bug report about it. Also fairly recently, he added the ability to do a request with no CookieJar at all.

Yup, agreed. The #haskell channel on FreeNode has been great about providing feedback on what libraries one should use for performance.

I actually thought that too, but I guess that's not the case. I helped write some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it wasn't fast enough as the lib author later rewrote all the attoparsec code to use pointers to the underlying byte buffers.

https://github.com/kazu-yamamoto/http2/commit/0a3b03a22df1ca...

The stream fusion stuff is sweet, but not exactly unique to Haskell since any language with good iterator/generator abstractions have similar constant-time memory characteristics.

I tried to write a Haskell websocket server, the library is quite nice, but it leaked memory (space leak? fragmentation? some of both?): https://github.com/jaspervdj/websockets/issues/72

The author helped me narrow it down to some issues with how ghc by default allocates a stack space that is rarely enough, and once it starts growing the stack space the RAM per connection gets pretty ridiculous. Using higher default stack space helped remedy this some, but the per-connection RAM cost was still way higher than Golang/Python which I was comparing to.

So... separate project, I write a load-tester in haskell for a websocket server. I need to issue some HTTP requests, and I see Brian O'Sullivan made a nice library, wreq. I use it as described and quickly discover it uses ridiculous amounts of memory because it doesn't mention that you should always re-use the Session (the underlying http-client emphasized the importance of re-using the Manager): https://github.com/bos/wreq/issues/17

(I am sorry that this issue prolly came off as a bit whiny there, I was very frustrated that such a gap was omitted from the docs)

So, my program is working pretty nicely, until I discover that its not actually sending multiple HTTP requests at once (even though the underlying http-client lib has a thread-safe TCP connection pool). After browsing some code, I see the problem: https://github.com/bos/wreq/issues/57

The solution that was so far implemented seems equally weird to me.... letting different requests stomp over the Session's cookie jar... I forked it so that I could have multiple wreq Sessions use the same Manager, and now it finally works as it should.

I won't even go into how some of these libs have occasionally wanted conflicting dependencies which leads into its own 'cabal hell' (googling for that is entertaining unless its happening to you).

I've only been writing Haskell for a bit over a year now, but everytime I write code with it, despite my love of the language, the libraries and run-time end up frustrating me.

I really like Haskell, but one of the main problems I've had (that I don't see many people cite) is that the libraries just aren't made for use under serious load/concurrency. Many of the people that have written these libraries, and use them are not using them in high-performance, memory-sensitive areas (production use at companies).

There are Haskell libs of course that are used in these environments, and the companies usually end up fixing them such that they're quite good. Most libs used by pandoc are likely to be great, and there's a few dozen others of the same caliber (its useful to search around and see what libs are used by the other few companies using Haskell since they have likely been vetted as well).

The other largest issue to actually using Haskell is that all the knowledge your ops team has of running a production system are essentially null and void. All your existing knowledge of how to fix performance issues, null and void. Learning Haskell and becoming productive in it almost starts to look like the easy part compared to effectively running a Haskell (dealing with space leaks, memory fragmentation issues, and ghc tuning for stack sizes, allocations, etc).

I continue to be incredibly sad that any OS considers it ok to lock-up the entire UX for a program running amok. Most people would consider such an OS defective, and consider what else is out there, rather than ssh into it. I can't really fault them, I do wonder what is wrong with people making such systems that think this is an acceptable situation.

A crash is not a hang. Firefox never crashed, eventually linux asked if I wanted to kill it, but there was no segfault, no crash.

Yes, it's not named "lock-up the entire system". I was expecting a segfault, quite disappointed.

Seriously, no disclaimer that this will hang Firefox, and will likely lock up a system for 20+ seconds before it will let you kill Firefox (linux)? (Thankfully I run linux in a vmware image, so I can go play a game while waiting for linux to figure out the process went rogue)

I didn't realize HN was the new 4chan/8chan. Sigh.

PyPy really closes the speed gap. The latest PyPy 2.5 release uses pinning to pass pointers between the C layer and PyPy greatly improving IO performance [1]. I've noticed this in a project I've been working on holding open large amounts of concurrent connections (> 100k at a time), PyPy has been completely competitive with Go, and actually using less memory. Yes, it's not as fast as a Java/C+ version, but with PyPy its more like 2-5x slower, not 10-100x slower which really changes things.

[1] http://morepypy.blogspot.com/2015/02/pypy-250-released.html

I'd assume that Google/Youtube's TOS include a clause such that any issue you might ever have, can only be resolved by arbitration. Lots of companies are busy making sure that merely using their service means you can't press a class action lawsuit.

Many of the industries/groups you cited don't have nearly as much wealth wrapped up in them. That's what makes the tech one worse, more wealth concentrated with less gender equality than others.

Once you reduce that list to ones with as much wealth as tech, its a pretty dang short list and it'd be interesting at that point to compare gender % in each.

Firefox Hello does have an open socket connection to Mozilla servers. This is why once you give out the link, Hello can ring the browser to indicate someone has joined the conversation.

Since Hello currently doesn't have a Friends list or a way to utilize existing social networks, passing a link to a friend is how you give them permission to ring your browser.

Cool, I didn't know that. It definitely counts for something.

Agreed, I believe Hello will be added text chat along with the video calls using WebRTC data channels in an upcoming release.

Since no one realizes that Mozilla actually develops stuff in the open (vs. code/project-dumps like Google after its 'done'), here's the Mozilla project page for Hello (previously called Loop): https://wiki.mozilla.org/Loop

A bunch of the hypothetical questions here on HN could be answered easily by skimming over this page and some of the pages linked in.

Edit: I'm not suggesting its bad or good to get a project to a more polished state before open-sourcing it, mainly just pointing out that for good/bad, Mozilla does happen to keep the entirety of the process very open.

WebRTC was "generically" added to Firefox in 2013, ie: https://hacks.mozilla.org/2013/06/webrtc-comes-to-firefox/

Of course, with it being added generically, tons of websites immediately started using it..... nope. Ok, well, lets go back before that blog post... https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-c...

Ah ha, isn't that neat. WebRTC in Firefox and Chrome and a demo of it! Wait, still pretty much zero use in the wild of WebRTC...

This is why Google/Mozilla are adding features utilizing these new specs to the browser, because they're cool and no one else is. In the case of WebRTC, it's for a good reason, its a PITA to run TURN/STUN servers to ensure that people behind firewalls can establish a connection.