Nvidia's Integration Dreams - <AUTHOR> https://stratechery.com/2020/nvidias-integration-dreams/ <comment><USER3> Huang's first reason why they would take up ARM is really, really interesting (and serves as a big counterpoint for my pessimistic take on the announcement yesterday).

> Number one is this: as you know, we would love to take Nvidia's IP through > ARM's network. Unless we were one company, I think the ability for us to do > that and to do that with all of our might, is very challenging. I don't take > other people's products through my channel! I don't expose my ecosystem to > to other company's products. The ecosystem is hard-earned — it took 30 years > for Arm to get here — and so we have an opportunity to offer that whole > network, that vast ecosystem of partners and customers Nvidia's IP. You can > do some simple math and the economics there should be very exciting.

If Nvidia _truely_ sees ARM as an opportunity kill off Mali and expand Geforce's install base, they might create an incentive for themselves to keep the ARM ecosystem alive. Note this is a pretty credible take I think - Samsung's next Exynos processor will have Radeon graphics and Nvidia can quickly nip that stuff in the bud by this (assuming Geforce is better and cheaper). If this plays out this way would simply be great for the ARM ecosystem. _If_ Nvidia can sell Geforce like ARM sells Mali and leave the ARM ecosystem truly intact, I don't think many will lament the demise of Mali (although I expect some counterviews for this on HN :) ).

Having Geforce be a commanding presence in the ARM ecosystem might be a big problem for the future diversity of GPU vendors though, but that's something I'm interested in seeing play out at least. I do hope AMD can take the battle to Nvidia on ARM too, and that Qualcomm and PowerVR find ways to stay relevant.

<comment><USER4> > If Nvidia truely sees ARM as an opportunity kill off Mali and expand > Geforce's install base,

Perfect replacement, from one unsupported hard to use non-open-source Linux- drivered gpu to another hard to use non open source Linux drivered gpu.

> I do hope AMD can take the battle to Nvidia on ARM too, and that Qualcomm > and PowerVR find ways to stay relevant.

Qualcomm's Adreno amusingly enough came from AMD, as Imageon, in 2009. I definitely hope AMD can get back in the mobile game though. Good luck to powervr & anyone else too. You are probably up for some hard competition soon!!

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

<comment><USER5> > non-open-source Linux-drivered gpu

I have seen this concern countless times, but not why that matters to them. I can understand it matters from Linus' perspective as kernel maintainer, but from users perspective I can't really get the issue. Anyways, not all code that runs on your system is open source. Why not demand your bootloader manufacturer for open source with the same intensity. If say NVIDIA wants the driver to contain malicious backdoor, open source is not going to stop them.

<comment><USER6> > from users perspective I can't really get the issue ... If say NVIDIA wants > the driver to contain malicious backdoor, open source is not going to stop > them.

No, but if such a backdoor were discovered, it _would_ be possible to do something about it. The quote from the article in top comment here says it well: [https://news.ycombinator.com/item?id=23944954](https://news.ycombinator.com/item?id=23944954)

> Anyways, not all code that runs on your system is open source.

Not yet, but it is my goal. If/when that's achieved, I'd also like to run it exclusively on free/libre/open (FLO) hardware.

> Why not demand your bootloader manufacturer for open source with the same > intensity.

My bootloader plays a much smaller role in my computing endeavors than my gpu. And less importantly, as a practical matter, there's many more major motherboard vendors, and few FLO alternatives; whereas both nvidia alternatives (amd, integrated intel) _do_ have FLO drivers.

</comment></comment></comment></comment><comment><USER7> I think that if Nvidia open sourced it's Graphic Drivers , 80℅ of backslash against Nvidia would disappear suddenly.

I think that Backslash against Nvidia is due to it's somewhat hostile nature towards OpenSource (to be accurate, they didn't open source Nvidia's Graphic Drivers).

But, Nvidia's drivers work well(Nvidia's Linux drivers are somewhat on parity with Windows ones) . I heard that until AMD open sourced their drivers, lot of them were preaching that Nvidia is only way to Play high end games on Linux(also CUDA).

Personally, I prefer AMD GPU. I find their drivers to work great with Linux.

<comment><USER8> Yes, nvidia (the proprietary GPU driver) was way better than fglrx (the proprietary amd driver) and even nouveau (the open source reverse engineered driver for Nvidia) worked better than radeon for me in those days. It was intel for smooth sailing or nvidia for acceptable performance.

I think their unpopularity these days come from three factors:

1\. For the gamer crowd, RTX 2000 was a price hike and even the higher end cards were not that impressive for performance. It looks like they were resting on their lead against AMD.

2\. People love to root for the underdog and AMD was behind for the longest time.

3\. For the developer crowd, the closed source Nvidia drivers were not great for Linux compatibility, and the Mac crowd couldn't care because they couldn't have Nvidia after their fight with Apple.

I think for a sample of the general public who have opinions on Nvidia, it's 1,2 and 3 in that order while for HN users, it's 3, 2 and 1 in that order.

<comment><USER9> > 2\. People love to root for the underdog and AMD was behind for the longest > time.

AMD has had pretty much always a solid mid-tier offering in the last five years, but people would still rather buy an nVidia card (like, say, a 1050) instead of the better AMD (at the price point) because of the "1080 Ti" halo effect.

nVidias software stack is pretty bad. Sure, the driver core works pretty well. The nVidia control panel looks like it was last updated in 2004, _which is actually true_ (go find some screenshots of it from 15 years ago running on XP, it looks the same). Now, that doesn't mean it has to be bad (don't fix what isn't broken), but the NCP is actually clunky to use. Not to imply AMD's variant is necessarily better, but at least they're working on it.

The nVidia "value-adds" like shadow play and so on are all extremely buggy. And while their core driver may be good, you still get somewhat frequent driver resets and hangs with certain interactive GPU compute applications.

<comment><USER10> >AMD has had pretty much always a solid mid-tier offering in the last five years, but people would still rather buy an nVidia card (like, say, a 1050) instead of the better AMD (at the price point) because of the "1080 Ti" halo effect.

Do people actually think this way? "I'll buy the nvidia 2060 super rather than the amd 5700 xt (for the same price, and benchmarks higher), because nvidia has the 2080 ti"

<comment><USER11> The people who look at benchmarks aren't the ones deciding that way. It's more like "I heard Nvidia makes the fastest GPUs, I'll buy the Nvidia one I can afford."

</comment></comment></comment></comment></comment><comment><USER12> "I don't know if it will work; data centers are about the density of processing power, which is related to but still different than performance- per-watt, ARM's traditional advantage relative to Intel, and there are a huge amount of 3rd-parties involved in such a transition." But isn't performance- per-watt starting to become more important than the density of processing power which is limited by your power consumption?

They have been buying some other data center/HPC companies as well this year like Mellanox and Cumulus, to me it almost seems like they want to own the entire data center stack and eventually provide a similar offering as AWS, Azure and Google Cloud.

<comment><USER13> They'd rather sell the picks & shovels to AWS, Azure and GCP.

<comment><USER8> Isn't this more selling the ore to the pick and shovel makers? The hapless gold miners in this case being all the Uber for street sweeper startups

<comment><USER14> Totally OT I know, but _Uber for street sweeper_ \-- I want this. Give me an app to request a quick cleanup and maybe try to get my neighbors to chip in. Or to report roadway debris to the city. Or for driveway snow removal during the winter.

<comment><USER12> Your city might have an app for reporting issues to the city. [https://www.sandiego.gov/get-it-done](https://www.sandiego.gov/get-it-done) has it for example.

</comment></comment></comment></comment></comment><comment><USER15> The comments about edge, and combining Nvidia / graphics tech with Arm makes a lot of sense to me. I suspect that's where most of the value of this merger will come from. When it comes to Arm in the datacenter, my question is: How do they actually plan to extract money from ARM displacing x86?

AWS has been deploying at least one ARM chip (Annapurna/Nitro) on _every single_ EC2 server for 5+ years. Surely they would have made sure their license ensures future rights to keep using ARM at a reasonable price. Their Graviton instances are effectively just one more ARM chip, so an Intel instance has 2 Arm chips (1 for EBS, 1 for networking) while a Graviton/Arm instance has 3 (EBS, networking, CPU).

Unless the Arm license reads something like "If you make a really big multi- core chip we get to charge you more"... how does the x86 -> Arm transition actually move the needle for Arm Holdings / Nvidia?

<comment><USER16> Arm licensing of their processor includes a royalty. More processor sales make more money for Arm.

<comment><USER15> This estimate has 6 billion Arm chips shipped in Q4 2019: [https://www.statista.com/statistics/1131983/arm-based- chip-u...](https://www.statista.com/statistics/1131983/arm-based-chip-unit- shipments-as-reported-by-licensees-worldwide)

The hyperscale/cloud datacenter market is single-digit millions of CPUs shipped per year. So if the whole cloud went to Arm tomorrow it would be less than 1% of total Arm chip shipments.

My point is that unless there's a way to extract higher $ per chip in the datacenter then actually it doesn't make a difference for Arm.

Edit: By datacenter market I'm really referring to AWS/GCP/Azure... the rest of the market ain't going en-masse to Arm anytime soon.

<comment><USER17> What makes you think ARM charges the same for a Neoverse N1 CPU as a Cortex M0 CPU?

That wouldn't make business sense.

<comment><USER15> I don't know what's in those licenses. Feel free to enlighten me :)

But it also wouldn't make business sense for Amazon to hang their hat on ARM without assurances or contractual guarantees that they can keep selling ARM chips for a reasonable price into the future. Where I define "reasonable" as Arm taking a much, much smaller cut of the final price than what Intel can do.

</comment></comment></comment></comment></comment><comment><USER18> On the Arm in the datacenter point, Nvidia doesn't actually have to cut off IP from competitors to achieve dominance, just the ability to do so is enough. Would anyone continue to fund Ampere (the company not the graphics architecture) if they know that they are dependent on one of their biggest competitors for IP?

I'm prepared to make a prediction: In 5 years Nvidia will be the only significant Arm supplier in the datacenter and all the other entrants will have given up - and that this explains why Intel's stock has risen over the last couple of days.

<comment><USER19> I agree with this except to point out that Nuvia and Marvell are not dependent on Arm.

</comment></comment><comment><USER20> Back in May 2017, a talk in RISC-V con ([https://riscv.org/wp- content/uploads/2017/05/Tue1345pm-NVIDI...](https://riscv.org/wp- content/uploads/2017/05/Tue1345pm-NVIDIA-Sijstermans.pdf) ) was given. Here are the conclusions of the talk:

\- NVIDIA will use RISC-V processors in many of its products

\- We are contributing because RISC-V and our interests align

\- Contribute to the areas that you feel passionate about!

Since then, I didn't observe much NVIDIA activities in RISC-V software community. But some NVIDIA people do participate Virtual Memory Task Group.

Apparently, the stance have changed.

</comment><comment><USER21> I wonder how the world would've looked like if companies with valuation greater than 100 billion (adjusted to inflation) just wouldn't be allowed to purchase and\or merge with other companies.

</comment><comment><USER22> Hard to wrap my mind around what a "data center software platform" means in practice. Isn't that covered by things like AWS and Azure?

<comment><USER23> Own NVidia GPU's. Own ARM chips. Connect ARM chips to NVidia GPU's in big racks of racks connected to power.

ARM is effectively embarrassingly parallel, low-power compute, and GPU's are parallel high-power compute.

If NVidia got into datacenter design (with ARM+GPU), dropped K8S+S3+Postgres onto it, charged $1999.95/mo for access, what could they deliver to customers?

What would a vertically integrated datacenter look like where you are the designer + manufacturer for everything from the concrete up?

<comment><USER24> > What would a vertically integrated datacenter look like where you are the > designer + manufacturer for everything from the concrete up?

A lot like AWS, Oracle Cloud, and soon to be Google Cloud and Azure?

people are losing their shit but this isn't even that novel lol, quite a few other players already own their full stack.

<comment><USER25> None of those companies make their CPUs or GPUs.

<comment><USER26> AWS Graviton, although an arm.. Google TPU and affinity for experiments like with POWER.. microsoft hiring people with custom cpu/soc experience (and they have experience with sq1/snapdragon)

</comment></comment></comment></comment></comment><comment><USER27> This sounds like a blessing in disguise for Intel. Nvdia trying to compete in the server space effectively means that most of the other companies designing Arm servers will go out of business. Since Nvdia will not be interested in any of the other market Arm is in, it will be neglected.

</comment><comment><USER28> Old cynic:

This all sounds like buzzword bingo and vaporware. It is one possible future. It also highly depends on the definition of "our time" \--

We are joining arms with Arm to create the leading computing company for the age of AI.

AI is the most powerful technology force of our time. Learning from data, AI supercomputers can write software no human can.

Amazingly, AI software can perceive its environment, infer the best plan, and act intelligently.

This new form of software will expand computing to every corner of the globe

</comment><comment><USER29> NVidia will make CUDA cores available across the whole ARM ecosystem, from Cortex-M? on up.

NVidia will integrate Arm cores into their GPUs where the GPU itself will start to become server hosted on a PCIe bus, potentially with its own Infiniband connection.

</comment><comment><USER30> "Owning it all ... from cloud to edge" is an exciting ambition not only for Nvidia but also as a developer and a consumer. It's going to be hard to pull it off, of course, but it's worth a shot.

EDIT - explaining the benefits for developers, and therefore consumers.

A "cloud to edge" stack from hardware to the application layer could create new application patterns that can tremendously accelerate autonomous driving, everyday robots, gaming. It could democratize this for small (maybe indie) developer teams. Wouldn't this have a great impact on consumers?

<comment><USER31> The idea of a company "owning it all" does not sound like something that I am going to benefit from as a consumer long term.

<comment><USER24> AMD and Intel also already "own it all" in this sense. NVIDIA is merely a third competitor in this space, with a much more undesirable CPU IP.

You should welcome a third competitor to the duopoly that has strangled CPU development. We surely could have made much more progress if x86 was not limited to only two (really three) competitors, you can already see how much change that AMD getting back in the game has made.

And I'm not sure Huang is going to burn it all down anyway. That seems like it would be a shortsighted move that would negatively affect the long-term value of ARM.

But I mean - I don't think anyone can deny that Huang would do great things with ARM. Terrible, perhaps, but also great.

(and it says a lot that a lot of people are probably nodding along with a comparison of one of the greatest tech CEOs of all time to literal Voldemort, the public opinions on NVIDIA and Huang are just ridiculously hyperbolic)

<comment><USER32> AMD and Intel don't actually own it all, certainly not from a software perspective. That's the difference here. The upshot of this article is that Nvidia basically wants to "CUDAify" the entire datacenter software stack. Intel and AMD absolutely do not have that kind of lock-in. You don't need to use their proprietary language to write programs that run on their systems.

<comment><USER18> This is such an important point.

Plus CUDA shows what can happen even when alternatives are available (OpenCL for example) you just have to use the hardware / software integration to be sufficiently ahead and establish a virtuous circle.

</comment></comment></comment></comment></comment><comment><USER33> Will they buy micron or another major memory company?

</comment><comment><USER34> I hope this fails miserably.

NVidia doubly fucks over desktop Linux with it's proprietary drivers and CUDA beating Khronos Group stuff, and I don't want their abilities to grow.

<comment><USER34> The post author is very bullish on commoditization and modularization winning in the end, and points out this would damper or sink NVidia's plans, and I very much hope he is right.

</comment></comment><comment><USER35> > The most advanced versions of Nvidia's just-announced GeForce RTX 30 Series, > for example, has an incredible 10,496 cores.

I'm _so_ tired of Nvidia getting away with this blatant falsehood.

They weren't even actual-cores when Nvidia started counting SIMT lanes as "cores" (how many hands do you have, 2 or 10? And somebody who writes twice as fast as you must obviously have 20 hands, yes?), and now that the cores can, under some conditions, do dual-issue, they are counting each one double.

What's next, calling each bit in a SIMT lane a "core"?

<comment><USER36> As a GPU buyer, I don't understand Nvidia's marketing at all. They list all their specs as like "X ray tracing cores, Y tensor cores, Z CUDA cores" and I have no idea how that translates to real-world performance. Which of those does my game use? Which of those does Blender use when raytracing? (Those are the two applications that I use a GPU for, so the ones I personally care about.) And the cores are listed as separate things, but I have the feeling they're not; if you're using all Y tensor cores, then there aren't Z unused CUDA cores sitting around, right?

I think it all ends up being useless at best and completely misleading at worse. The reality is that I don't even know if I want to buy their product or not. I guess that's what reviews are for? But why do reviewers have to do the job of Nvidia's marketing department? Seems strange to me.

<comment><USER37> > But why do reviewers have to do the job of Nvidia's marketing department?

Are you suggesting you would rather read reviews of Nvidia products that are written by Nvidia, and you would trust them more than 3rd party reviews?

> I don't understand Nvidia's marketing at all.

Do read @TomVDBs comments; this isn't Nvidia, this is the industry-wide marketing terminology.

Cores are important to developers, so what you're talking about is that some of the marketing is (unsurprisingly) not targeted for you. If you care most about Blender and games, you should definitely seek out the benchmarks for Blender and the games you play. Even if you understood exactly what cores are, that wouldn't change anything here, you would still want to focus on the apps you use and not on the specs, right?

> I have the feeling they're not; if you're using all Y tensor cores, then > there aren't Z unused CUDA cores sitting around, right?

FWIW, that's a complicated question. There's more going on than just whether these cores are separate things. The short answer is that they are, but there are multiple subsystems that both types of cores have to share, memory being one of the more critical examples. The better answer here is to compare the perf of the applications you care about, using Nvidia cards to using AMD cards, picking the same price point for each. That's how to decide which to buy, not worrying about the internal engineering.

<comment><USER36> I wouldn't trust them more, but it would be a good rule of thumb for whether or not I need to be awake during this product cycle. For example, if they're like "3% more performance on the 3090 vs. the RTX Titan" then I can just ignore it and not even bother reading the reviews. Instead, they're just like "well it has GDDR6X THE X IS FOR XTREME" which is totally meaningless.

<comment><USER37> > Instead, they're just like "well it has GDDR6X THE X IS FOR XTREME" which is > totally meaningless.

That's referring to memory and not cores; is that a realistic example? I'm not very aware of Nvidia marketing that does what you said specifically - <USER2> example feels maybe a little exaggerated? I will totally grant that there is marketing speak, and understanding the marketing speak for _all_ tech hardware can be pretty frustrating at times.

> if they're like "3% more performance on the 3090 vs. the RTX Titan" then I > can just ignore it and not even bother reading the reviews.

Nvidia does publish some perf ratios, benchmarks, and peak perf numbers with each GPU, including for specific applications like Blender. Your comment makes it sound like you haven't seen any of those?

Anyway, I think that would be a bad idea to ignore the reviews and benchmarks of Blender and your favorite games, even if you saw the headline you want. There is no single perf improvement number. There never has been, but it's even more true now with the distinction between ray tracing cores and CUDA cores. It's very likely that your Blender perf ratio will be different than your Battlefield perf ratio.

<comment><USER36> I haven't seen any of those. All I've seen is a green-on-black graph where the Y axis has no 0, they don't say what application they're testing, and they say that the 3070 is 2x faster than the 2080 Ti. Can you link me to their performance numbers? As you can tell, I'm somewhat interested. (And know that real reviews arrive tomorrow, so... I guess I can wait :)

<comment><USER38> The official press release of the 3000 series[1] has a graph that seems to be what you're looking for. Look for the section named "GeForce RTX 30 Series Performance".

It has a list of applications, each GPU and their relative performance. Y=0 is even on the graph!

[1]: [https://www.nvidia.com/en-us/geforce/news/introducing- rtx-30...](https://www.nvidia.com/en-us/geforce/news/introducing- rtx-30-series-graphics-cards/)

<comment><USER36> Ah, OK, I saw that. I am just very suspicious of the fact that they didn't use "fps" as the units, and instead chose "relative performance".</comment></comment></comment></comment></comment></comment></comment></comment>


'Craft' coffee is becoming the province of chin-stroking joy thieves - <AUTHOR> http://www.theguardian.com/lifeandstyle/2015/jul/07/craft-coffee-is-becoming-the-province-of-chin-stroking-joy-thieves

<comment><USER2> Yeah, I get it. I can taste the difference between a Pilsner, a Hefeweizen and a Guinness. But any more more distinctness than that starts to blur.

In coffee, I know that I like the Arabian Mocha Java (smooth) better than Costa Rica (acidic), French Roast is an occasional choice if I really need a pop, and I actually can't stand the strange flavor of New Guinea.

So I've really admired the connoisseur notes on Philz blackboard menu, but fuck if I can tell 'earthy' from 'charcoal' from 'clove':

[https://fitnessissweet.files.wordpress.com/2013/06/img_2784....](https://fitnessissweet.files.wordpress.com/2013/06/img_2784.jpg)

<comment><AUTHOR> Reminds me of the time I was in a fairly fancy restaurant with my mate, who is the wine connoisseur of the group.

After a lengthy - and I'm talking ten minutes - to-and-fro with the sommelier, he uttered the phrase "something with that whole autumn leaf carry-on", the sommelier finally got it "aha!", and we got the wine. Suffice to say the rest of the table hasn't let him forget that one. (Hi, Alex!)

</comment></comment><comment><AUTHOR> I love this bit:

"Not for the first time, the "craft" movement is slowly and earnestly sucking the joy out of something that isn't half as complicated or important as some people think it is."

<comment><USER3> Indeed.

The way that breeders have utterly messed up the genetics of "show" animals has a lot of similarities, I think.</comment></comment>


Poll vs Epoll, once again. - <AUTHOR> http://www.jacquesmattheij.com/Poll+vs+Epoll+once+again <comment><USER2> interesting.

The discovery of the edited source is a nice, solid addition to the discussion.

Ultimately though, AFAICT you and Zed are looking at - and generally agreeing with - the same facts, ie. that epoll and poll perform better depending on the situation.

If I am understanding you correctly, where you both are disagreeing is that you are determined that no webserver will actually reflect the usage pattern that would make it worthwhile for Zed to implement this 'superpoll' feature, while Zed is thinking that it will be worthwhile.

Which makes you seem like two reasonable people agreeing on the facts and both coming to a different conclusion, unfortunate but it does happen (and always fascinates me).

I wonder if part of the reason for the differing conclusions is differing expectations for Mongrel2? you seem very focused on 'expected real-life scenarios for existing websites', but I do have the feeling that Zed is anticipating/hoping/expecting that Mongrel2 will have a broader set of uses and be used in other ways in addition to the standard webserver.

<comment><USER3> _I wonder if part of the reason for the differing conclusions is differing expectations for Mongrel2? you seem very focused on 'expected real-life scenarios for existing websites', but I do have the feeling that Zed is anticipating/hoping/expecting that Mongrel2 will have a broader set of uses and be used in other ways in addition to the standard webserver._

I can't speak for him of course, and I may have misunderstood some of the details of these posts[1], but it seems like jacquesm is saying that the cases in which poll beats epoll turn out to not actually be _high-scale_ use cases in any interesting sense (and his arguments seem compelling to me). In which case it does seem safe to not bother optimizing them.

I certainly wouldn't discourage Zed from _trying_ though. Who knows what might come of it?

[1] I write a lot of Twisted code that _uses_ epoll - I wrote the justin.tv chat server for example, which has scaled to half a million concurrents, and I believe I get the basic concepts of epoll/poll/kqueue, but I've never actually tinkered with the details.

<comment><USER2> He says "Also, you should take under consideration the workload of your system, if you are sure that you will have a very large portion of your fds active most of the time and that your worker pool is sufficiently large compared to the number of connections that you have that there is no reason not to use poll (think media/file servers), whereas if you are fairly sure that the majority of your fds are inactive and/or that the size of your workerpool is substantially smaller than the number of fds that you have open (think web servers) that there is no reason why you shouldn't use epoll.

That's the precise reason those two calls exist in the first place, and which one is 'best' (for whatever bit of extra throughput you can squeeze out of a machine because of this optimization) depends on your traffic."

To me it sounds as if overall he is saying roughly two things: (1) "There are server conditions where epoll works better, and server conditions where poll works better,"

and (2) "I dont believe that web servers specifically under real-life conditions are likely to be improved much by poll"

Clearly he and Zed agree on (1), that being the point of the related Zed post, and (2) might well be true, but I dont think it necessarily speaks directly to the use cases that Zed is hoping will eventuate for mongrel2.

Zed used a web server to test the differences between epoll and poll, and that has clearly focused the discussion somewhat, but from what I gleaned by reading his ongoing 'The Coming Of Mongrel2' series, he has a wider range of possible uses in mind for Mongrel2, and I am wondering whether that is where his and jacques conclusions are differing.

[1] I mean, clearly they are _both_ entirely insane in a very real sense, but I do love to pretend that those around me are rational actors and enjoy projecting rational explanations for their behavior upon them.

<comment><USER2> sorry? why am I being downvoted? surely if you think Ive missed something in the above summary it would be more constructive to post a reply?

<comment><AUTHOR> It may have to do with calling Zed and me insane. I don't know what you base your knowledge of me on but in defence of Zed he does not at all come across as insane to me, though he definitely does seem to have a pretty rough edge.

</comment></comment></comment></comment></comment><comment><USER4> Do you have any hard evidence that _I think (and have observed in real life) that servers spend more time doing other stuff than they spend time polling,_ is true?

<comment><USER2> The call for great quantities of hard evidence that is occuring on both sides is both entirely reasonable and utterly unrealistic.

These are two good developers who are drawing on their real life experiences to develop their opinions, backed up with some simple tests performed on local machines.

While it would be pleasant if they could provide hard data for a wide range of webservers to 'prove' their opinions it is hardly a realistic option for either of them without investing a degree of time and effort that is far greater in scope than the work being discussed.

I would prefer to see less of a cry for hard evidence of real life usage patterns from either side, and a greater acceptance of the fact that this is simply an interesting discussion of technical possibilities by some good developers.

<comment><AUTHOR> I've given what data that I have easy access to (from a single threaded asynchronous home brewn server that sees an awful lot of traffic) in that other thread. Now that's a special enough case that I think that the conditions under which normal servers operate will be skewed considerably in the _downward_ direction compared to that one and even there I never observed an active-to-total ratio of more than 40% over a span of 5 minutes during a 2 hour run.

Instrumenting varnish or apache would be a lot harder to do because I don't know those code bases well enough to know for sure that I'm doing it just right so all I can rely on there is the data reported by the 'status' modules of those programs, and for now neither of those suggest otherwise.

Zed attacks that data with a bunch of handwaving but to date has yet to show a single instance of a server which actually has an active-to-total ratio that is higher than 60%. I suspect such servers do exist, media servers, file servers and other other servers with relatively few connections, a large worker pool compared to the number of active connections and lots of long files being shipped across those connections.

But your typical web server is more likely to be stuck in an endless cycle of accept-read-write-close where both the 'read' and the 'write' can block for significant amounts of time compared to the number of bits shipped, and the backend can do the same thing once more. So idle is the norm.

</comment></comment></comment><comment><USER5> Uh, Zed stopped being inflammatory quite a while ago now.

<comment><USER6> Are you being facetious?

If so, read the comments here: <http://news.ycombinator.com/item?id=1570694>

</comment></comment><comment><USER2> wow. the downvoters are strong in HN tonight.

an actual discussion would be an interesting thing.

sure, its _easier_ to just downvote someone as you go past without actually engaging sufficiently to understand or discuss the issues, but ask yourself...is that really who you want to be?

<comment><USER3> <http://ycombinator.com/newsguidelines.html>

"Resist complaining about being downmodded. It never does any good, and it makes boring reading."

<comment><USER2> Its not the downmodding I am pissed at, its the lack of decent conversational skills.</comment></comment></comment>


A roster of TLS cipher suites weaknesses - <AUTHOR> http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

<comment><USER2> The elephant in the room for me is the legion of paying customers running old Microsoft browsers.

Microsoft's regrettable browser-tying/integration strategy has exacerbated web crypto problems. And it doesn't look like Microsoft is going to stop doing it, either--ten years from now we'll be dealing with whatever crypto suites the maximum IE version supports on Windows 7.

I'm picking on Microsoft here, but the same is true for any platform browser. Crypto suites need to be completely modular, enabling backporting to old environments.

</comment><comment><USER3> A fantastic overview of the past few years of exploits against SSL. All I can add is a companion resource you probably already know about: [https://www.ssllabs.com/projects/index.html](https://www.ssllabs.com/projects/index.html)

But even that doesn't give enough practical advice as to which ciphers to pick. This blog post helps, but basically points out that there's no "perfect replacement" for what SSL ciphers people tend to be using today. That said, any attempt to avoid bad ciphers -- usually defaults -- is better than nothing. Be careful: there are even valid SSL choices that don't encrypt your data at all. Do your research when planning SSL and verify your SSL configuration once you've selected server-side preferred options. It really does matter.

[http://security.stackexchange.com/](http://security.stackexchange.com/) is useful too, though not as fresh as many security blogs might be.

<comment><USER4> For specific advice, here's my blog post with a proposed configuration that will work with any program that relies on OpenSSL:

        http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html

But I've found in practice that many operate under different circumstances. For example, many hardware devices offer only a limited set of cipher suites. To know how to configure them, you have to understand the advantages and limitations of each.

That's why I keep the SSL/TLS Deployment Best Practices higher level, without specific cipher suite configuration examples:

        https://www.ssllabs.com/projects/best-practices/

<comment><USER5> In the blog post above you say that IE 8 on XP doesn't support PFS, but this technet document seems to indicate that a few cipher suites with DHE are available on XP: [http://msdn.microsoft.com/en- us/library/windows/desktop/aa38...](http://msdn.microsoft.com/en- us/library/windows/desktop/aa380512\(v=vs.85\).aspx)

Are all of them problematic for other reasons?

Thanks for all your work in this area!

<comment><USER4> Yes, they are problematic. Cipher suites are typically tied to a particular key algorithm. Microsoft does support the DHE key exchange, but only in combination with DSA keys (DSS in the cipher suite string). There are a couple of problems with that. First, if you do use DSA keys, you don't get to use any RSA suites[1], which are much better supported. Just as an illustration Chrome supports only one DSA suite. Second, virtually no one uses DSA keys today for SSL. So, all the advice you will find is about RSA keys. Third, and worst, Microsoft does not actually support DSA keys stronger than 1024 bits, and you can't use 1024-bit keys because they're considered too weak.

I am sure there is a reason, but Microsoft never supported the DHE and RSA combination, which was the only way to achieve Forward Secrecy before ECDHE became widely supported.

[1] Actually, some web servers support multiple keys/certificates. With Apache, for example, you could have an SSL site with RSA, DSA, and ECDSA keys if you wanted. I think nginx is adding this capability too. But IIS does not support it.

</comment></comment></comment></comment><comment><USER6> It's probably not complete fantasy to believe somewhere in the billion dollar funded NSA machine, they have cracked RC4

Despite beast, I've disabled it completely and gone to AES with EC ciphers.</comment>


An open letter to Elon Musk, from eelo founder - <AUTHOR> https://medium.com/@gael_duval/an-open-letter-to-elon-musk-from-eelo-founder-6d6feafb53a2 <comment><USER2> Can anyone tell me what eelo is?

Edit: nevermind. www.kickstarter.com/projects/290746744/eelo-a-mobile-os-and- web-services-in-the-public-in</comment>


Google Maps will let you share your location with friends and family - <AUTHOR> https://techcrunch.com/2017/03/22/google-maps-now-lets-you-share-your-location-with-friends-and-family-for-a-specific-period-of-time/ <comment><USER2> Can't help but roll my eyes.

Moved from Google Maps (Latitude) to Google Plus (Android only) to Google Maps.

It wasn't broken, it did a great job and you could access it from the browser. It also gave interesting stats including how far you had traveled and how far to go to get to the moon ( I only got half way there :( ).

<comment><USER3> It used to work fine for Google Plus iPhone users, until the app was updated to remove the feature. I have now changed to Glympse for iPhone/Android comparability.

</comment></comment><comment><USER4> Great. Because it's not like we've been using Google Plus for ages to track our whereabouts. ;) And before that, Latitude.

But wait, there's competition - we also have their Trusted Contacts, which features similar functionality.

<comment><USER5> For real, I was using Latitude years ago to allow family to track me on long trips.

I never used the 'Find My Friends' crap on Apple but it was the same deal from what I gather.

<comment><USER4> This is frustrating... Latitude was great and easy to find. Then of course they had to go and retire it, true Google style.

In Plus, the functionality is hidden away behind their myriad tab panes (they have the bottom one, and an additional vertical behind a hamburger - it's on the latter) - but it works just fine. I've got a bunch of friends there and we all enjoying seeing each other's whereabouts. My wife could however never remember where to find it, and got me onto Life360.. (which has some interesting extra bits including arrival and departure notifications).

The functionality probably always belonged in Maps. What will be interesting is whether they restrict the access like in Trusted Contacts or allow an unfettered list like in Plus / Latitude.

<comment><USER4> Just got the update here too. I have had Locations removed from G+, but added in Maps.

I have to define my sharing again.

I'm sharing my locations with family in a country that hasn't received the new Maps. Brilliant.

</comment></comment></comment></comment><comment><USER6> What I really want is a low-impact, low-risk way of knowing where someone _who is happy that I can do this_ actually is. My typical use case is working out if my wife is driving home, or at the gym etc -- where SMS/IM won't get a response, and a phone call would be intrusive. I don't want constant sends from the remote device, rather than ability to trigger a pull of current geo.

That is - low values of intrusion, negligible battery usage, relatively low exploit surface.

Glympse[1]is handy for ad hoc notifications - I use it sometimes to give family an idea of my time of arrival. But it also requires me to activate it, and runs for (IIRC) at most two hours. And by golly it sucks up battery.

Cerberus[2] could do this, but it's not the primary use case, and the diddling around that's required is messy - plus, massively intrusive given the feature set (remote wipe, camera & audio recording, etc).

[1] [https://play.google.com/store/apps/details?id=com.glympse.an...](https://play.google.com/store/apps/details?id=com.glympse.android.glympse)

[2] [https://play.google.com/store/apps/details?id=com.lsdroid.ce...](https://play.google.com/store/apps/details?id=com.lsdroid.cerberus)

<comment><USER7> It's a damn shame Google hasn't solved this yet, because with my iPhone, it's as easy as "share location with contact", and I'm presented with "24 hours" or "indefinitely". And it just works. There are even geobounding alerts available.

<comment><USER8> Google released Trusted Contacts [0] a while ago that essentially works like how the OP wants. You can one-time request a contact's location and (unless they block it) it will share it after a timeout. It also allows temporary sharing and has last-known location for if your battery dies.

[0]: [https://play.google.com/store/apps/details?id=com.google.and...](https://play.google.com/store/apps/details?id=com.google.android.apps.emergencyassist&hl=en)

<comment><USER6> Thanks for the recommendation.

First time I'd read the description it looked like the recipient of the request had the option to grant / deny - which kind of defeated the purpose. Re-reading it looks like there must be some kind of time-out feature, where it will default to a response? Anyway - will give it a go.

<comment><USER9> Yes, that's exactly how it works. It asks first, but if there's no response in a while (and you're on their list of trusted contacts), then it defaults to allow.

<comment><USER6> Okay -- we played with this tonight -- and it's not fit for purpose.

There's a 5-minute delay, with a screen-on alert for the duration at the b-end, before you can get a geo-location response back.

If the 5-minute delay was configurable (I want it immediately), and the pop-up was a notification (sys-tray rather than full screen / break -screen saver) then it'd be a contender.

As it is, it's less useful than sending an SMS.

<comment><USER10> Whats your use case for needing to know someones location and you must know within 5 minutes? or is the objection more about the full screen popup(i.e. if they are at the gym, does the request interrupt their music listening?)

<comment><USER6> Use case is essentially that there are times when I'll make a quick decision based upon where my wife is. I _could_ be more organised and use Trusted Contacts 5 minutes before I want to know the answer, but I'm typically not.

Thinking commute -- train then long walk home -- if convenient I'd rather share a lift than walk. Not the best example as I really should walk, but nonetheless.

With the gym scenario -- I know the days of week, and rough time, she'll be there, so not the best. In that case it's not the full screen pop-up that's the problem, just the hard-coded 5 minute delay.

Better example: early evenings, I'd like to know if she's working late or driving home. Without requiring that I interrupt her. If I SMS and she's driving, she has to break the law to respond. If I call (or SMS) and she's still working, that's disruptive. If I use Trusted Contacts and she's still working, also disruptive.

I'd never really thought about this stuff before the Google Maps article, and some of the discussion here -- it feels like my use case isn't _that_ uncommon a thing. I may look at some of those family / kid-tracker applications, though last time I reviewed the field there they felt a bit clunky and overly intrusive.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> My immediate family all share locations via Apple's contacts, painless and very useful. I like the ability to share for an hour or a day with other contacts too, makes meeting friends much easier whenever there's a crowd. The downfall is that it only works with iPhones but for a lot of people, that's good enough.

</comment><comment><USER12> I've been doing this for years with Glympse. I can't believe it took Google this long to bring around this functionality.

<comment><USER13> In what situations do you typically use Glympse?

<comment><USER14> I'm another person but I do use Glympse Express, a version made only for sharing the position. I use it to show friends where I am on the way of meeting them. No more messages about being late or on time. I usually share position with whatsapp. I didn't know it had a share position feature but it's OK to compartmentalize information between different vendors. I'll keep using Glympse.

</comment></comment></comment><comment><USER15> Your friends and family and google

<comment><USER16> Doesn't google know already if you are using the maps?

<comment><USER17> It already knows if you are using Android. Assuming you didn't turn off location history. I left it turned on because: a) Google finds out where I am in many ways and b) it actually is more than just for diagnosis, so it provides me better results etc.

</comment></comment></comment><comment><USER18> > There's even a new maps app designed specifically for people following each > others' cars on long road trips.

What app would this be?

Classic Google taking an existing feature, rip it out, and put it back into another app with Minimum Viable Product functionality, and slowly restore it to parity

<comment><USER19> I can see a very valid (and very useful) use case for parents to track their kids when they are out with friends, or in a field trip. Hopefully less missing children.

<comment><USER20> Ah, to be old...

When non-smart phones and GPS for the general public arrived in my country, there was a discussion among the lines of "now that it's possible to track your kids' position, would you do it?". The general consensus seemed to be "no, that would be a violation of their privacy, and it would imply that I don't trust them".

20 years later, and it's a feature in all phones. I guess _that_ point is finally settled.

<comment><USER9> Was that the consensus among techies, or the general public?

</comment></comment></comment></comment><comment><USER21> We use life360 for this. I can see where my wife is, I can know when she arrives home safely. She gets a notification when I leave work so she knows I'm on my way home to help with the kids.

<comment><USER22> So glad I grew up before any of this was possible.

<comment><USER23> I have mixed feelings about a lot of this.

For younger children, it's hard to object. But the general idea that you might give general access to your location info to a family member and that not doing so could become an issue feels... bothersome.

In a different vein, as someone who grew up pre-cell phones, I'm a bit bothered by the idea that you should always be reachable. That said, as satellite trackers/SMS/emergency beacon devices become more affordable I do start to ask myself if something like this isn't prudent on a relatively remote solo trip.

</comment></comment></comment><comment><USER24> Google Maps is not new in this game, but, imho, "GeoSlavery"[0] problem gets more serious as tech develops in general. [0][PDF] [http://www.colorado.edu/geography/class_homepages/geog_4103_...](http://www.colorado.edu/geography/class_homepages/geog_4103_f07/docs/DobsonFisher03.pdf)

</comment><comment><USER13> I'm curious, for those that do use a location-sharing type feature (or app like Glympse), what is the appeal of doing so? In which situations do you typically share?

<comment><USER25> I share location with a few very close friends - for those who live in other cities, just cause it's fun. For those who live in the same city as me, because it enables serendipity ("oh hey i'm near your house and i see you're home, let's grab tea if you have time!").

I've also shared location with significant others in the past just cause it makes everyday coordination and organization better ("oh she hasn't left work yet, i'll hold off on cooking dinner")

This of course implies that a) you have nothing to "hide" from one another, and that b) you be mature about it (eg don't be upset if your friend is home but doesn't reply to your text/says they're busy), but these are things i value in my personal relations anyway.

<comment><USER13> Is that through an always on location-sharing service? Or something you'd do at a specific moment or situation (e.g. I'm headed somewhere to hangout, I'll turn on location sharing with some friends I know to increase chances of serendipity)

<comment><USER25> Always on through Find My Friends.

</comment></comment></comment></comment><comment><USER26> She wanted to stalk me so I decided to show her some latitude.</comment>


Comcast's Google Fiber Rival Will Be Laughably Expensive - <AUTHOR> http://www.wired.com/2015/07/comcasts-gigabitpro-pricing/

<comment><AUTHOR> "Comcast's forthcoming Gigabit Pro service, which promises speeds of up to two gigabits per second, will cost $299.95 a month with a two year agreement, plus as much as $1,000 in installation and activation fees, according to a page on the Comcast XFinity website spotted by DSL Reports. That's more than four times the $70 monthly cost of Google Fiber in Kansas City."

</comment><comment><USER2> Does anyone know how it is 2Gbits?</comment>


Google Challenges Apple At The iOS Application Layer - <AUTHOR> http://techcrunch.com/2012/12/16/iterations-google-challenges-apple-at-the-ios-application-layer/

<comment><USER2> The Apple/Google feud lens is getting so exhausting.

Far from challenging anything, Google is adding value to Apple's platform. Everyone wins. The end.</comment>


Show HN: zen.jquery - <AUTHOR> https://github.com/thunderpenny/zen.jquery

<comment><AUTHOR> This is a jQuery plugin that makes it super simple to add random moments of zen from [https://api.github.com/zen](https://api.github.com/zen) . We just added it to the navbar of our internal dashboard, and it's nice.</comment>


Carlo Urbani (2003) - <AUTHOR> https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(03)13107-8/fulltext <comment><USER2> This is very inspiring and touching. Makes me think of the many people out there risking their lives to do something good.

I think I feel particularly close to this story because I've relatives in Ancona.

I'm very grateful to whoever shared this article, it changed my day.

<comment> rbrtdrmpc- Born and raised going south from Ancona, never heard about Urbani before. Thanks for sharing!</comment></comment>


The art of stealing - <AUTHOR> https://www.nrc.nl/kunsthal-en/ <comment><USER2> Tricky business doing security in an art museum. Often the art pieces are worth millions, yet easily accessible to the general public. Yes, there are alarms and a security guard at the door but even a few petty thieves can with a little planning get the opportunity to steal. Should art be better protected? It would, however, mean less access for the general public. Difficult to strike the right balance. Maybe there is more security that I'm not aware of...

<comment><USER3> Sadly one thing most art thieves don't understand is that even if a painting is worth millions to a gallery or collector on the legitimate market, it's black-market resale value is basically zero. (Turns out, not many people want to buy famous paintings for enormous sums of money that they'll never be able to show off.)

And even if there were some Bond villain waiting to get his hands on a Picasso for his mountain lair, the smash-and-grab art thieves suddenly realize they don't have the connections to find such people.

It would probably help if there were less insane hype about art prices in the culture generally, but at this point the ever-increasing valuations of these works is what keeps certain segments of the secondary market alive (and on significantly thinner margins than most people imagine).

<comment><USER4> _It would probably help if there were less insane hype about art prices in the culture generally, but at this point the ever-increasing valuations of these works is what keeps certain segments of the secondary market alive (and on significantly thinner margins than most people imagine)._

Seems sorta like blaming the victims. "If only art wern't so valuable, ppl wouldn't be so tempted to steal it"

<comment><USER3> Hmmm, that's kind of a stretch. You can hypothesise about motivating factors in people's behaviour without endorsing bad behaviour.

I sort of took it as read that people who break into museums and steal the collective cultural heritage of society are doing bad stuff and I disapprove of them.

I also wanted to make the point the crazy-high valuations aren't really a good, or useful, or socially valuable aspect of the (especially secondary) art market, and they create a false sense of the transferability of that value. That was mainly as a response to the idea of the tradeoffs between security and accessibility that the parent comment was highlighting.

It would be sad if a bunch of "security" was added to art museums, and as a culture we could let go of the idea that for something to be important it has to also have a millions-of-currency pricetag attached to it.

None of that alters the fact that if you tell people something is worth a life-changing amount of money, and put it within their reach, you have to accept that somebody is gonna try to make off with it every once in a while, especially in a society that closes off lots of more reasonable paths out of poverty or hardship.

<comment><USER5> The bigger stretch is thinking you can keep the value of art a closely-guarded secret.

</comment></comment></comment></comment></comment><comment><USER6> I visited an art museum recently. There were rooms with nice oil paintings, and a couple of rooms with modern art in it.

I was convinced the guards in the modern art section were there to keep the janitors from tossing the modern art into the trash bins.

<comment><USER7> So sad these people are down voting you.

IMNSHO if most 5 year old can do it, it's not art.

If you insist it is art, fine, it is very shitty art. Very good confidence trick though!

<comment><USER8> I sympathize with your view (although with s/5 year old/me/). However, over the years I have come to realize that many of the things I used to think I could have done, I actually could not have...to say nothing of your 5 year old. It might look like a few apparently random splotches of paint could have been put there by you, but in many cases looks are deceiving.

You might watch a grandmaster chess game and think that you could make those moves. Or perhaps you see a solution to a traveling salesman decision problem and think "it's easy to see there exists a path that short". But in both cases you're mistaken. The moves you would have played wouldn't be as good as the grandmaster's. The path you would find wouldn't be as short. And the paint splotches you would throw on the canvas wouldn't look as compelling.

Yes, there does exist shitty "art"\--things that you or your 5 year old could have done. But I suspect it's less common than you think.

<comment> yjftsjthsd-h I thought they'd actually done blinded studies that showed an inability to distinguish between "real" art and amateur attempts?

</comment></comment></comment></comment><comment><USER9> Reminds me of this Roald Dahl short story: [https://en.wikipedia.org/wiki/Parson%27s_Pleasure_(short_sto...](https://en.wikipedia.org/wiki/Parson%27s_Pleasure_\(short_story\))

</comment><comment><USER10> This art theft reminds me of this story of a Georgian women scavenging for copper knocking Armenia off the Internet: [https://www.theguardian.com/world/2011/apr/06/georgian- woman...](https://www.theguardian.com/world/2011/apr/06/georgian-woman-cuts- web-access)

The common thread is poor people turning euros into cents, which is to say destroying something of great value to (attempt to) produce some small gain for themselves. This is a completely rational thing to do when it seems you have no better options, which is why social mobility is so important.

<comment><USER11> Social mobility? No, it's about preventing people becoming that desperate.

By definition, social mobility just lets you mix up the set of which people who are desperate, no?

<comment><USER12> Only if you assume mobility is a zero-sum game. It doesn't have to be, if we allow people to obtain wealth from their labor instead of sucking all the alpha into a black hole of wealth consolidation by the already-wealthy.

Positive-sum social mobility was supposed to be the point of economic growth, but instead that growth was captured by rent-seekers, institutional investors, and others.

<comment><USER13> Quality of life has been rising and poverty has been falling at very consistent rates worldwide over the past few decades. By just about any metric you could find, it's currently the best time to be a human being in the history of humanity.

<comment><USER14> I cannot square that with a generation jobless, unable to buy their own place or even a car in many cases. If you cherry pick what 'poverty' is, I guess so, and surely even the least of us live better than 13th century peasants. But better than in 1980? No.

<comment><USER13> 13th century peasants didn't live a much better life than many people did 100 years ago.

But even if you're only talking about the US between the 80s and now, you're still wrong. Unemployment is half of what is was in 1980, and at the lowest rate since the 60s. Household wealth has grown an enormous amount since the 80s, the poor are less poor and the poverty rate has dropped since the 80s too. The only somewhat legitimate issue you can point too is that housing in some areas is unaffordable for most people. But if your biggest complaint is that you can't afford to buy your own house in the most expensive cities in the world, even though there's lots of places where you could, and even though poverty and unemployment is down, and household income is up, then maybe you're just proving my point?

<comment><USER14> Employment as a flat stat is useless. Folks with college educations are flipping burgers. A better measure might be 'employment expected value' where you take the sum of the product of job X earnings or some such.

Its been popular lately to claim that, because folks who used to have good- paying factory jobs have slid down the economic ladder to labor or service, its still good because its 'full employment'.

<comment><USER13> All of the statistics prove you wrong, so you demand that I produce a statistic that literally doesn't exist?</comment></comment></comment></comment></comment></comment></comment></comment>


Setting up Unicorn with Nginx - <AUTHOR> http://sirupsen.com/setting-up-unicorn-with-nginx/

<comment><USER3> The article talks about several concepts as if they're new things and/or can't be done just as efficiently outside the kernel. For example...

> Normally load balancers reverse proxy to the worker that is most likely to > be ready

This really is a problem especially for apps that have long-running requests. However, both HAProxy and Apache can be configured to load balance to the worker that is guaranteed to be ready. Why they don't do so by default is beyond me. I believe HAProxy's config option is called 'max_conn 1' or something.

Phusion Passenger also load balances like this with its Global Queuing feature. Since version 3.0 that's on by default.

In short: load balancing like this doesn't require the kernel to do the job.

<comment><USER4> In my opinion, an advantage of Unicorn over HAProxy is that it doesn't require another moving part in your deployment.

<comment><USER3> Depends. If you scale out to multiple servers then you will need an extra reverse proxy in your architecture.

</comment></comment></comment><comment><USER5> _Instead of stacking people up in long queues behind some guy who's connection fails miserably; Unicorn lets that one guy fail._

I believe that from what I have read and experienced that Reddit uses a similar system. Sometimes if the wireless connection I use is weak and takes too long to send the request after establishing a connection, Reddit will give me a "timeout" message rather than serving the page.

<comment><USER3> Timing out connections is pretty standard practice. However that's not what the article is referring to. Imagine requests being handled serially by the web server. If two clients are queued up, [A, B] with B being the first in line, and B also happens to be on a flaky wireless connection that takes 2 minutes to complete the request, then A doesn't get its turn until 2 minutes later.

To fight this undesirable effect, you will want to handle all connections simultaneously so that no user has to wait for the other. However many web apps tend to be serial with limited concurrency, because of the way they're written.

One way to solve this problem is by buffering the request and the response at the reverse proxy level, where the reverse proxy can - in principle - <USER2> an unlimited number of connections concurrently, or at least a large number of them concurrently. The reverse proxy doesn't pass the request to the web app until the request has been completely received. Likewise, the reverse proxy receives the complete response from the web app, thereby immediately freeing the web app's limited concurrency resources, and then sends the buffered response to the client no matter how long that can take. Both the reverse proxy receive and send steps can be combined with a timeout; this is what you're referring to in your reply but it's only a part of the total picture.

However all of this is pretty standard practice for many web servers, and has been for a while. Phusion Passenger has done this since version 2.0 (2 years ago). Before Unicorn, traditional setups with Nginx + mongrel_cluster, Nginx + Thin, Apache + mongrel_cluster, Apache + Thin, do exactly the same thing.

To be clear: Unicorn is not responsible for handling slow clients. It's fairly unique in its policy to explicitly _not_ handle slow clients, and to require the user to put it behind a buffering reverse proxy. This makes sense if to people who are intimately familiar with network server architectures, but can be confusing to newbies who just want to setup a server expect it to work; this newbie will be in for a nasty surprise.

For example Thin does not require a buffering reverse proxy, it buffers internally. Mongrel can handle slow clients up to a certain number because it's multithreaded in so far it hasn't hit the app's lock yet.

<comment><USER6> _Before Unicorn, traditional setups with Nginx + mongrel_cluster, Nginx + Thin, Apache + mongrel_cluster, Apache + Thin, do exactly the same thing._

Actually, this isn't entirely correct. Traditional setups with nginx have needed HAProxy in the middle to perform the same balancing that Unicorn provides.

I've deployed Nginx + Mongrel, Nginx + HAProxy + Mongrel, Nginx + HAProxy + Thin and finally Nginx + Unicorn.

For any non-trivial app, you will need some form of balancing of requests to avoid the 'single request hurts everyone' problem. Unicorn does this in the cleanest way, as the number of places to define the process count is in a single location with Unicorn, and in at least 2 places with HAProxy + <Thin or Mongrel>.

We tried testing Phusion Passenger 2.x for our workload, and found that it often ran more processes than we configured it for, and could take out the entire server by over committing memory. This then needed yet more config in out monitoring solution and became more trouble than it was worth.

For ease of configuration and actually working as advertised, I would recommend Unicorn to anyone running a Ruby web server.

</comment></comment></comment><comment><USER7> I'm in the process of building out a web services architecture built in Rails and served up by Unicorn. Its working great so far. All of the clients hitting my service are high end servers on a local network, so I don't have to worry about network latency, client buffering, etc.

Web services is what Unicorn was built for! :)</comment>


Rust 0.7 Released - <AUTHOR> https://github.com/mozilla/rust/blob/master/RELEASES.txt#

<comment><USER2> The "detailed release notes" page: [https://github.com/mozilla/rust/wiki/Doc- detailed-release-no...](https://github.com/mozilla/rust/wiki/Doc-detailed- release-notes) (it's actually shorter this time than the brief release notes, amusingly).

The most exciting user-visible change this time around is almost certainly the new iterator libraries. See the several links in the detailed release notes for more context, but this is such a good resource that I can't resist linking it again here: [http://journal.stuffwithstuff.com/2013/01/13/iteration- insid...](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and- out/)

EDIT: a link to the actual release announcement itself: [http://thread.gmane.org/gmane.comp.lang.rust.devel/4596](http://thread.gmane.org/gmane.comp.lang.rust.devel/4596)

<comment><USER3> The post about internal and external iteration is fantastic and definitely makes a good argument for a language supporting both (which newer versions of Ruby do, actually), but this part left me scratching my head:

> As far as I can tell, you simply can't solve [the interleave example > problem] using internal iterators unless you're willing to reach for some > heavy weaponry like threads or continuations.

I must be missing something, because it doesn't seem particularly hard:

      class Array
        def interleave_each(other)
          self.zip(other).each do | a, b |
            yield a if a
            yield b if b
          end
        end
      end

Am I cheating somehow, or have I misunderstood the problem?

Edit: Ah, I see, the problem is that I'm relying on the specific semantics of lists, which works for the example as written, but not for the general case (ie. if I have one file and one list).

<comment><USER4> You "cheated" by using zip. You can't easily implement zip using only internal iterators but you easily can using external iterators. If you look at a slightly different problem that doesn't precisely fit the special case of zip you'll see the difficulty involved with using internal iterators.

<comment><USER5> Where does haskell fit on this paradigm?

You can derive "internal" iterators using Traversable but it's not like zip is difficult to implement.

<comment><USER6> Haskell typically uses internal iterators, but because it's lazy many composition strategies are more straightforward. Rust is strict, however, so the same techniques don't apply.

</comment></comment></comment></comment></comment><comment><USER7> Has it been decided yet if garbage collection should be moved out of the core and only be provided as a library? If memory serves me right there was some discussion on this shortly after the 0.6 release [1][2].

[1] [http://pcwalton.github.io/blog/2013/06/02/removing- garbage-c...](http://pcwalton.github.io/blog/2013/06/02/removing-garbage- collection-from-the-rust-language/)

[2] [https://news.ycombinator.com/item?id=5811854](https://news.ycombinator.com/item?id=5811854)

<comment><USER2> Consensus is leaning towards moving it out into a library. The only undecided thing at this point appears to be the fate of the @ symbol, e.g. whether it should remain as sugar for user-provided pointer types (which includes types in the stdlib).

<comment><USER8> So @ would mean "something that implements the pointer trait"?

</comment></comment></comment><comment><USER9> The Rust documentation is a list of modules, but I think a cross-reference with a list of all traits declared in all modules would be very useful. Developers, particularly people writing libraries, would have a big "to-do" list of all the traits their new types could implement.

<comment><USER10> Hi! I'm working on the new rustdoc (the current one is horribly outdated and all-around crappy). Any other feature requests? I'm tracking them at [https://github.com/mozilla/rust/wiki/Bikeshed- rustdoc](https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc)

</comment></comment><comment><USER11> Is Rust always going to require MinGW on Windows? I'm very interested in Rust but this is a stopper for me if Windows executables are going to need this.

<comment><USER12> It is the intention to support MSVC: [https://github.com/mozilla/rust/issues/1768](https://github.com/mozilla/rust/issues/1768)

<comment><USER2> Note that that bug is filed under the "backwards compatible" milestone, which is the _absolute minimum_ for a 1.0 release. Barring drastic circumstances, you should assume that MSVC support will land before then.

However, Rust really needs Windows-savvy developers! If you can help, please do.

<comment><USER13> Found the list of windows bugs after a bit of searching: [https://github.com/mozilla/rust/issues?direction=desc&labels...](https://github.com/mozilla/rust/issues?direction=desc&labels=A-windows&page=1&sort=created&state=open)

Seems like there are a few straightforward "fixables" in there.

</comment></comment></comment></comment><comment><USER14> It says

        `Option<~T>` is now represented as a nullable pointer.

Does that mean they _introduced_ more prevalent nulls into the language? that seems like a shockingly bad choice

<comment><USER2> No, it means that _at runtime_ the representation of `Option<~T>` is simply a nullable pointer (this is also how borrowed pointers are represented at runtime, i.e. with no overhead whatsoever compared to C-style pointers). It's simply a perfectly-safe memory optimization (the language leaves the runtime representation of enums (of which Option is one) deliberately unspecified so that these types of optimizations can be made). It doesn't make Rust any less safe, as the language itself still has no notion of null pointers.

</comment></comment><comment><USER8> I like that the iterator trait has a thread-safe design. C#'s is a pain in the neck: having MoveMext and Current as separate methods was a bad idea.

<comment><USER2> That was never a concern; it would take signficantly _more_ work to make iterators non-thread-safe. Welcome to Rust. :)

EDIT: And if you're referring to the way that our iterators automatically guarantee that iterator invalidation just can't happen, well, that's simply how borrowed pointers work! No extra effort required (not that borrowed pointers are the easiest thing to grok in the first place, mind you...).

<comment><USER8> To clarify, having advance return the result means the design can be used to read from an external queue on multiple threads. C#'s IEnumerable can't do this, because the interface assumes only one consumer.

(Edit: I should point out C# is not the only platform that gets this wrong. C++/STL has the same design.)

</comment></comment></comment><comment><USER15> Is it soup yet?

<comment><USER16> soup?

<comment><USER17> It's a figure of speech... asking "is it soup yet?" basically means "is it done yet?" I haven't met many people who use that particular expression, but I had an old boss who was from the Pittsburgh, PA, area who used that all the time. Apparently it was inspired by a 1970's era commercial for Lipton soup.[1]

[1]: [http://www.urbandictionary.com/define.php?term=Is+it+soup+ye...](http://www.urbandictionary.com/define.php?term=Is+it+soup+yet%3F&defid=2965736)

<comment><USER15> You kids today, you don't know how good you have it. Back in my day we didn't have Internet memes, we had _television_. Three whole channels of it!

<comment><USER17> We only had two channels... "off" and a channel full of snowy looking stuff that made a noise like kkkzzzzzzsshshshszzssshshshzzssshhshszzzsshshshzzsshshshszzzsshhhh...

<comment><USER18> Luxury! we had to make the noise ourselves...

</comment></comment></comment></comment></comment></comment><comment><USER19> Who uses this?

<comment><USER6> It's not production-ready yet. However, we're using it for Servo, and there are various projects using Rust.

Here's a page with some of the projects I know off the top of my head: [https://github.com/mozilla/rust/wiki/Projects-using- Rust](https://github.com/mozilla/rust/wiki/Projects-using-Rust)

<comment><USER20> is rust-azure the rendering backend for servo?

<comment><USER6> Yes, Rust uses Azure as the rendering backend for all content. Azure, in turn, wraps Skia, Core Graphics, Direct3D, and Cairo/Pixman. It allows us to work with the native drawing backend on each platform with one set of rendering code.</comment></comment></comment></comment>


Ebooks Made of YouTube Comments Invade Amazon Kindle Store - <AUTHOR> http://www.technologyreview.com/view/428175/ebooks-made-of-youtube-comments-invade-amazon/ <comment><USER2> I am really not sure what to make of this. I see Markcov-Chain spam web pages all the time, but they are only occasionally entertaining.</comment>


Ways Startups Fail - <AUTHOR> http://blog.eladgil.com/2011/05/4-ways-startups-fail.html <comment><USER2> I can think of a few more: \- inability or unwillingness to adapt to market changes \- creating the wrong product \- setting the wrong prices

In fact, I would venture to bet that this list could go on near indefinitely.</comment>