skysight-inc/HackerNews huggingface dataset:
Perhaps, chrooted environment is required for effeciently serving static files, I don't know.

And of all apps - nginx, which has been designed to be self-contained (process-isolation is good enough) and has almost zero external dependencies (openssl and pcre, which are parts of any modern OS). I could understand the idea to "containerize" that pile of Java crap with its 100500 maven dependencies just in order not to touch it again, but nginx...

BTW, does Docker's "port mapping", which is, of course, has zero overhead, is what one needs in front of nginx in production?
I'm not sure on most chips. I do know if you look up MOSIS, etc prices you'll find that most of the cost of the prototyping run is the masks. The masks start at tens of thousands then just go up from there. High-end nodes are in millions to tens of millions. Every prototype run of your chip takes a new mask. Hence, all the money spent on proprietary tooling to reduce odds of digital or physical defects. Many ASIC's still need respins. Then, there's 3rd party stuff like I/O packages.

Now, compared to that, the silicon wafer might cost a few grand with packaging (not volume) costing $10-20 a unit. For any OSS project, dare I say most of the cost will be in the first paragraph and recouping it will take significant unit prices. How significant depends on what's being sold and at what volume. A PIC or AVR clone at modest volume will be cheaper than an Oracle T2 clone at low volume. Hope that helps.
I remember the researchers at Oracle mention in their presentation that not all languages can be ported to GraalVM. Do you know what language runtimes can and cannot be implemented on GraalVM?
Since it's v8, does this mean someday certain Node.js modules could be written in wasm, but still be callable from JS?
Thanks. I would have said the same but was way too polite.
This is where you tear the $100 bill in half and give him one half.

Always ask the driver if they can change a $100 before you get in.
fighting hipsterism with hipsterism.
Many companies already make similar products for parking, e.g. [1]. The autonomous, unoccupied drive to the parking structure and being connected to power without human intervention are the more pressing problems.

1. http://www.parkmatic.com
> I think algorithms are something to embrace rather than fear

He has the same sentiment in his article.
Unless this is an underground lot and there is a worry that the heat of 300 burning teslas might do something to the building above. It would at least give off some nasty fumes. Someone will want that one car put out before it propagates.

And is water the correct thing to throw on a few hundred pounds of burning lithum batteries? I really don't know, but I suspect not.
I recommend reading this: http://www.sparringmind.com/changing-habits/ and other articles by the same guy. He links directly to a lot of productivity studies, and you're in a good place so you have plenty of time to try things out. Good luck!
Despite the seemingly representative anecdote in your last link, I'm very hesitant to believe that most Uber drivers in San Francisco expect a cash tip. This hesitance is based primarily on the fact that I have never heard of tipping with cash, and I know very few (if any) people here that routinely carry cash, especially small bills. But perhaps the practice really is more common and expected in other demographics, like tourists.
This should be interesting. If I were in a Walmart parking lot facing an empty car and it was trying to take a space, I would probably accelerate at it assuming it would back off, since there's no one who cares. If everyone did this, would it end with some parade of never-parking-Teslas that just drive around the parking lot until their owner gets done shopping? That's not necessarily a bad thing...but it would be a weird new aspect to parking.
I know that every time I have to use it (which isn't very often) I have to look up WTF each switch does in the manual because there's no way I'll ever remember what "hard", "soft", and "mixed" are supposed to mean.
You're the second person to bring up microcode. I'm curious why two are focused on this rather than the HW itself. What about you?

Note: For readers not in the know, microcode is the sequence of wiring activations of the physical, closed hardware. Instructions, merely series of bits, get translated to that by the microcode engine running from a memory rather than hardwired engine. Unlike the ISA, it's highly tied to the hardware since it drives it directly.
Wait, some drivers give passengers bad ratings if they don't tip?
There is going to be a billion dollar jackpout
This might be a lottery ticket with positive EV. Maybe some VC will figure out a way to buy all the rickets.
I don't know the answer to that, but currently they have: Java, JavaScript, C, Ruby, Python, R, and a simplified SmallTalk.
Very good analogy!

> but were chosen to be equal right from the beginning

While this was almost certainly the case, it's sufficient for them to have been chosen so as to be decidably comparable.
It's about time. Volkswagen had that in 2008.[1] Audi in 2012. Chevrolet in 2014.[2]

[1] http://www.gizmag.com/volkswagen-demonstrates-fully-automati...
[2] https://www.youtube.com/watch?v=3zh_5QGA1zw
Tiny Computer Equals Great Geek Fun
It's weird to me to see this upvoted on HN.

1. I doubt most people here are using (or have used) asm.js, let alone memory growth.

2. Maybe people think some major feature is being removed from asm.js (not really, will expand below).

3. Maybe people are confusing asm.js with WebAssembly?

4. This will be in Web Assembly, see post's point #2.

Emscripten-emitted-code has a fixed size memory space (static memory, stack, heap). Heap size can grow, via sbrk, but if you moved the program break past the end of the Typed Array the code used as memory space, Emscripten could create a new Typed Array, copy over all data from the old to the new, free the old, and continue executing with data in the new. That process was memory growth, and was very slow. In practice, you never really needed it, since you could run your program a few times, see what the high water mark of your heap was, then set the precise size at compile time.

Memory growth was helpful if you wanted to start up faster, but could potentially have non-deterministic memory growth (though you'd still be limited to 32b address space).
Lots of cats are attracted to computers and laps for warmth, so perhaps a heating pad? Also, feed your cat at consistent times during the day if you don't want him/her to bother you whenever he/she feels hungry.
really? cool!
Welcome to the CHIP Operating System
Not a positive one.
I now see I'm being rude but I don't mean to be mean-spirited: I've behaved similarly. It's not the end of the world.
Nobody seems to have considered the possibility of actually driverless cars. Would not be remotely legal, but interesting to consider them just aimlessly driving city streets or looking for parking that it will never find.
Yea, I need to collect some more data on price vs. no price in ad. It seems like a price point of $25 might work a lot better than $49 based on percentage of ads served and CTR - https://cloudup.com/c-Jy2nwWjQC
This should be easy to fix at the driver level. Window close and and GPU resource release are not operations that occur often enough that memory clearing would affect performance.
Also, is there a new kind of 'road rage' where one's automated car is defeated in some way by someone else's automated car? Or, if one is blocked out by superior automation? I'm a bit new to thinking about this, but I'm starting to imagine the confrontations. The bitterness will be amplified and at the same time limited by the fact that cameras are recording everything.
Have they said that? I don't see anything from tesla saying that these cars are allowed to move without the driver watching. In fact Musk has made more than a few statement denouncing the behavior of tesla owners who have let their cars loose as unsafe.
Somehow, I suspect that WebAssembly will eventually have most of the problems of Java in the browser.
Rickets used to be a hell of a thing https://en.m.wikipedia.org/wiki/Rickets
General Motors just invested $500 million in Lyft, and will partner to provide vehicles today and autonomous vehicle technology as it develops in the future.

GM has already committed to autonomous cars in the past, but it got more real when they threw half a billions dollars in the ring and partnered with Lyft.
Congratulations on taking the dive! I've met lots of digital nomads and starry eyed entrepreneurs in Japan but the slog and paperwork of getting things set up often puts them off.

Let me know if you make it to Fukuoka and I'll buy you a coffee.
What are you qualifications in computer architecture? You're arguing against pretty much everyone in the field.

> I'm surprised to see a lot of RISC proponents still around, because I think it's quite clear that things didn't quite work out the way they thought it would --- the vision of cheap, simple, high-performance CPUs just didn't happen. Thus I'm not of the opinion that another "MIPS, but free" architecture is such a good idea.

You seem to be implying that there's RISC failed. If you ask anyone who mattered in computer architecture ranging from academics like Patterson who literally wrote the most used books in the field to Intel fellows, they'll all tell you that the essential point the RISC folks were making was proven right. This point being that RISC is requires less logic (=area,power) to implement, it's easier to write compilers for, processors have faster cycle times, and so on.

In the end though, it turned out the market valued software compatibility over performance. That, good marketing and a phenomenally efficient supply chain and fab resulted in Intel winning. But don't confuse this with CISC winning or RISC losing. If Intel had to do a clean slate design today, they'd do RISC themselves. In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.

> In my experience, statements like this really mean "it's actually really bad, but we don't want to say that"... after all, who would call benchmarks "controversial" if they were winning? There do tend to be few comparative benchmarks, but here's one that shows how ARM and x86 are competitive, but MIPS is behind in energy efficiency:

The benchmark performance depends only on how much effort is put into optimizing the implementation. Intel have on average maybe 200 architects and 200 more designers tweaking their processors for performance for the last 30 years. It is completely absurd to expect a team of 10 or so grad students to compete with them.
We'll have to see who can bribe, whoops I mean donate, the most money. Self driving cars is being backed by Google, Apple, Tesla, GM, Uber, Lyft...that's a lot of weight to be thrown around.
> unbiased algorithms often discover that things we previously attributed to bias were actually unbiased predictors

Absolutely. Or the exact opposite: that the algorithms simply reflect results caused by bias, a far more likely relationship given what we know of history.

The reason we're against this is not because we think our biases are not supported by real data; we know that some of them most certainly are. But we also know that a snapshot of current society is often little more than a reflection of social forces that has made the society what it is at this particular point in time, and treating them as immutable (or simply placing faith in their persistence) is nothing more than a political policy that helps perpetuate them. Treating past correlations as future predictors in a dynamic system such as society is programming conservatism into your algorithm. Acting on them is a political policy which strives to maintain the status quo -- there's nothing wrong about it per se, if that's what you want, but we need to be aware of this fact. Alternatively, we could program the algorithms to predict or even assist with social change.

The worst thing we can do is accidentally program politics into algorithms, and then fall for our own ruse and start believing that the algorithms are apolitical. That takes away our agency in making political choices.
There is very little in this article that has anything to do with doing architecture at all. This is all polemical griping about implementation—and that's developer territory.

Also, the initial dismissal about studying philosophy, English, film studies, or engineering—what the fuck does that have to do with anything at all related to software architecture? Sets an instant tone that what follows will likely be flimsy ad hominem arguments based on subjective shit the author personally dislikes. Useless.
And on top of that, it only has some weird sort of pseudo-ASLR.
APPlite-Today Latest Gadget
OK, say you're in Manhattan. Assuming a private car, instead of paying for a garage, should it be acceptable to just leave an automated car driving around, or instead, driving outward until it finds a public space? Would it result in cheaper garages, or some other crazy problem?
Definitely - one makes more money than the other. If a bank is biased against some group they are turning away profitable customers. This is also purely a statistical problem; once some quant discovers they can make more money by fixing the bias, they'll do it.

Understanding what to expect out of the algorithms is absolutely the wrong way to determine this. The fact is that we simply don't know apriori the optimal way to allocate credit. That's why we need an algorithm in the first place.
The Pithos Guide
I believe this is an example where all parties in the chain from malware>Ad network>Forbes can be held liable. You could decide to sue any and all parties that delivered the malware /biz law 101 guess
> Schneier is discussing an unpleasant fact; unbiased algorithms often discover that things we previously attributed to bias were actually unbiased predictors. But we don't like to admit this, so we instead make silly statements like the above.

There is a legitimate question as to whether an algorithm is actually unbiased. It could be quite accurate or there could be a bias, e.g. because the algorithm penalizes drug convictions and drug convictions have an unjustified bias due to racist or sexist enforcement.

The problem is it isn't a simple question to answer. And people are going to want to choose their answer based on their politics.

But that can't work. We can't let a black box take discriminatory inputs and expect it to produce a just result. We also can't just assume that every unequal outcome had an unjust cause, or we'll end up e.g. causing loans to be given to uncreditworthy people and wrecking the economy (see also housing crash).

Which means that Schneier is wrong about quotas but exactly right that what we need is transparency. Because if there is unjustified bias then we need to understand why so we can prevent it, and if there isn't then we need to understand why so we can accept it.
Thank you for the list. I really hope the VM can enable porting language runtimes that are not available in JVM, C#, Swift, Go...
Yes. Unless you pay a monthly premium. Then your tesla will always win the fight. The cars of the poor will politely give up their spots.

Except my spot. Which will have a tesla-proof orange cone forever protecting it from skynet.
This analysis is a badly regurgitated copy of the free O'Reilly e-book about software architectures by Mark Richards located at http://www.oreilly.com/programming/free/software-architectur...

It's a lot worse than the original.
You can't actually get causal proof though right? I mean we can prove that probability should cause a phenomena identical to Benford's law, but maybe it actually happening is just a fluke! A few trillion pieces of evidence isn't proof after all.
I get the sentiment and empathize but there are actually handicapped and other mobility-impaired people out there... Lots of them in fact.
Woah.

I think that many "servers" today aren't going to benefit though from the level of optimization that you're talking about. Network bandwidth is at least an order of magnitude slower than memory and PCI throughput. For all but the most heavyweight computational tasks (ie. gaming, finance, scientific computing, etc.) this kind of multiplexing optimization is very helpful. If you're needing to get that kind of performance, you would userspace map off the NIC.

With how fast modern processors (CPUs and GPUs) are, whats much more important nowadays is not stalling on the flow from the NIC. The solution of the original author seems to me like a very simple fix for the old naive paradigm of state machine switching off from a single thread.

I think you might be (impressively) too close to the metal, and guilty of premature optimization. For example, a simple database application would benefit much more from keeping the slow I/O bottlenecks flowing than from the compute multiplexing.
Google and Apple: The bridge is closed, but drive over it anyway (2012)
Much more importantly, an Intel design team has something like 1200 engineers working for 2-2.5 years on the next generation of an existing processor. I don't know about ARM, but I'd guess they probably something like a team of 200-300 people on working on each revision.There's no way a team of 10 or so grad students can hope to out-optimize them.

Also SPEC isn't a synthetic benchmark, it contains real applications like bzip2 and gcc.
We don't need fair and unbiased inputs. In the real world these don't exist, and the field of statistics has devoted extensive effort to the problem of getting good answers out of bad inputs.

E.g., for an unbiased measurement (m = x+g, g ~ N(0,\sigma^2)), you use the likelihood function G(x-m,\sigma^2). For a biased measurement g ~ N(b, \sigma^2), you use the likelihood function G(x-m+b, \sigma^2). Here G(x,\sigma^2) is the pdf of the distribution the noise g is drawn from.

But this is mainly just something that can be determined by studying the process. Mandating specific outcomes is just a way of ensuring that the predictor can't discover certain facts.
By providing memory safety to the GPU in either software or hardware, or most likely some combination of both just like with standard memory now.
Well, the last time I used it was when I was hacking on Palm Pre phones =O
what if the cost of having my empty car wander the city is cheaper than paying for parking?

will parking costs go down? will there be some laws forbidding this behavior?
Looks great, but I can't comment more as I haven't used it.

It looks to be solving the same problems as DNAnexus, Seven Bridges, BaseSpace etc as a way to wrap open source tools in more user-friendly ways.

But it's orchestrating the production of smaller set of data that still needs the next step of human interpretation, report writing, family-aware algorithms and most complex annotations (the problem space Golden Helix is in).

In other words, the automatable bits that is not the hard part that I mentioned in my blog post.
Patterson says they've tried their best to make sure it doesn't infringe on patents they know about but they obviously can't provide any guarantees.
Chrome will not be developing the Sidebar API (chrome.sidebar)
Yeah, as wealth generation becomes more urban you have to pretty much expect cities to subsidize suburbs and rural areas.

The main issue here though is that due to some sordid political history the MTA is a state agency, despite running the NYC subway. This has resulted in the city's transit budgets being routinely raided to supplement state budget needs, and also a focus on state-centric mass transit efforts to the detriment of in-city mass transit (see: redeveloping Penn Station which serves long-distance train commuters, designing the AirTrain to LaGuardia to primarily serve suburban Long Island travelers, etc).

There's a pretty dramatic misalignment of incentives when a state agency under the command of the governor runs the city's subways, rather than the mayor or even a regional government.
Or, having realized that algorithms making predictions based on past data are politically conservative (pretty much by definition), if we really want to improve the economy, we should take political action to change the situation. This is how it's always been done, and it can work; sometimes rather well.
Very happy we got to see him perform a brief experimental work in 1998. Movement that would be brushed off as a special effect if kids saw it today. Seeing it live was astonishing.
I'm very interested! Will V8 be the first browser engine to ship WASM to developers?
Would you please clarify what problems are you referring at? Some Java-in-the-browser problems that seem orthogonal to the minutia of the language running in the browser:

* Language-based security model. Hopefully not an issue, browsers have been pretty good at sticking with same origin policy and not trying to mix code from different providers in the same address space.

* sun.misc.unsafe. As long as the APIs available to WebAssembly are the same as the Javascript APIs, not an issue.

* Slow startup times. For a decent loader / JIT infrastructure this is not an issue regardless of the language. In other words, an implementation detail and not a systemic issue.

* AWT / Java2D. There is a chance non-DOM widget toolkits will make a comeback, but that's less of a WebAssembly issue and more of a Canvas issue. Canvas has been around for a while, but most people still use the DOM.
I still have yet to see what driverless cars will do in light of the trolley problem. [1]

[1] https://en.wikipedia.org/wiki/Trolley_problem
Wow. Impressive that the author is able to compress so much negativity and lazy thinking into that space. The attributes of an "architecture hipster" are an assortment of unrelated things that presumably annoyed the author at some point in the industry.

Read his code on GitHub for an extra giggle.
Loves UML making diagrams

Four years of university desperately tried to convince me that UML is 90% of real world coding. I'll remain happy to not see this be the case.
What I Believe, by E.M. Forster (1938)
I somehow doubt it will be working by 2021...
> I think it's telling that they didn't have any traditional investors in their most recent round.

No, it's not telling at all. If you're trying to raise $500M, you don't have many choices. You're looking at 1) IPO, 2) private equity, 3) strategic investors. IPO has obvious problems. The fact that Lyft chose strategic investors doesn't say much. I'm sure there were tons of Asian private equity funds clamoring to invest.
Regulations are largely local matters (at least on this matter,) and AARP is a federal powerhouse, not a local one.
I suspect the DSP makers just use VLIW because of interia.
They probably don't have the money or incentive to revisit their old decisions.

Also wouldn't you say that most of the stuff that used to be implemented on DSPs is now moving into ASICs? I wouldn't be so sure that VLIWs are going to be around forever.
Saturn and Venus conjunction on January 9 was awesome [Photos]
If any such algorithms are going to be built, it better be open source or be able to explain to me how it arrived on that judgment. I am not going to trust some blackbox on this.