pslam

Netflix is not a user. The end customer is. Flipping this on its head, so that it sounds like the "super heavy users" are the businesses, is an anti-net-neutrality talking point. Don't fall for it.

Businesses such as Netflix enter peering arrangements to build out network infrastructure and server farms close to where the customer demand is. It's customers who are driving this, because the ISPs would lose them otherwise.

If this is deployed in release builds — in production — then it is effective in mitigating anything which isn't covered in fuzzing. Your application/process gets terminated, which is perfectly acceptable behavior.

This is not true. There are ways in which "at-will" termination can be illegal. Most obviously, protected-status discrimination.

Termination related to labor organization is illegal. However, recourse (for the employee) generally fails because of the time scales involved, with the inevitable failure to form a union, but the employer will have to deal with the fallout eventually.

That does not make it naive, and you should not further participate in making this self-fulfilling.

I’ve found my fair share of SoC bugs over the last couple of decades, and cache coherency is by far the most common problem. It’s complex to implement, and implementers are always messing with it to gain a cycle here and there. They get it wrong, frequently.

I would go so far as to bet every mainstream SoC has at least one cache coherency bug either already documented (errata) or undiscovered.

I know it's a joke, but this still branches, via an obscure mechanism of faulting, and mov instructions past the faulting instruction will speculatively execute.

At least in the case of Cortex A-7, there's about 2-3 cycles (maybe 3-4 instructions with dual-issuing) before a branch mis-predict causes a pipeline flush. You can maybe fit a couple of loads into that time, and maybe one of them will result in a Dcache fill. Other in-order cores in the Cortex-A line have similar Dcache side-effect under mis-predict. It's not clear whether this actually leads to speculated Dcache fills, though.

So it's possible that some of the Raspberry Pi versions are in fact vulnerable to (much weaker versions of) Meltdown and Spectre.

The cores in (all versions of?) Raspberry Pi do speculatively execute. It's just that the window of opportunity is tiny - just a few cycles (and maybe up to twice that many instructions) - and there's (probably) no way to get an indirected side-effect.

I wouldn't write off the ability to get a useful side-effect signal. The variants widely documented are not the only possible methods of inducing speculative side-effects.

As far as anyone can tell, the data from the breach hasn't been used yet. When that happens, it'll probably be the largest identify theft fraud ever, and if it's traced to Equifax, we may see an "adjustment".

I'm still betting (small) on that happening.

The UK was an example of consolidation resulting in terrible quality and limited choice. The "CAMRA" (CAMpaign for Real Ale) group is a result of push-back against this, and has been very successful: http://www.camra.org.uk/key-events-in-camra-s-history

Distribution all the way down the chain was consolidated — i.e Pubs — and was only remedied through legislation: https://en.wikipedia.org/wiki/Guest_beer

The US is nowhere near the same setup, though, so it's doubtful it would end up quite as bad. For beer at least, every time there's a consolidation, there's an opportunity for a new player to enter the market they just left behind.

As a veteran from the chip industry, I can tell you my experience is completely the opposite.

Nobody in their right mind would produce an ASIC without going through simulation as a form of validation. For anything non-trivial, that means FPGA.

> If you want to know about how chips are made then I'd highly recommend the book "CMOS Circuit Design and Simulation" by Baker.

This is a ~$120 book. Do you (or anyone else) have a recommendation for something a little easier to tell hobbyists they should get?

"This device is not part of A Bomb. Rather, it implements a common wiring and chemical mixture function that may be used to ignite, and rapidly interact with the surrounding environment. Implementation of A Bomb is not required for use of this device: only the Joke Bang Sign is required to be implemented as a common baseline."

"The accidental nuclear launch was blamed on a single piece of software in a web service" -> Is obviously a stupid assessment.

"Equifax was the victim of a hole in Apache Struts" -> Likewise.

Nothing so valuable should be safeguarded such that a single failure results in total loss. It is utterly their fault.

Absolutely agree. Almost all tasks will perform very well when using multiprocessing. It also has a nice side-effect of steering you towards explicitly coding data flows without fine-grained sharing.

If you need to close that gap between the performance of multiprocessing, and multithreading, then you probably shouldn't be using Python, or any language of the same shape, in the first place.

There is one other option I'd like to see: multiprocessing style, but with multiple Python interpreter instances in the same process — one per thread. There would still be the hard delineation of data boundaries between instances, but less overhead for pushing data between them.

This is the wrong way to go about it. x86 mnemonics bear little resemblance to the encoded binary machine code. For example, what x86 lumps into a single "mov" mnemonic, is actually half a dozen different underlying instructions, e.g load, store, reg-reg, and a few special cases.

It's the wrong question too. Perhaps what you're looking for is: "What is the number of combinations in which an instruction can be decoded?" This would need to lump together all the multi-bit fields (such as immediates) as one (or a few if there's special values). This would be a measure of the expressivity of instruction set, and somewhat a measure of the encoding efficiency — how much it can cover the execution unit inputs?

It's a much easier thing to answer for most of the "RISC" oriented architectures, e.g ARM 32 and 64 bit. It's basically the set of valid binary encodings of instructions, compressing together all the immediate values.

Or just never install an identity in the default location (.ssh/id_*)

You're right. I'm remembering a different codec — I think this is how H.264 orders DC coefficients for macroblocks. JPEG uses an actual 2D DCT, not a 1D DCT of a flattened block.

JPEG transforms 2D images into 1D arrays using a "zigzag" ordering of 8x8 blocks. See this diagram on wikipedia:

https://en.wikipedia.org/wiki/JPEG#/media/File:JPEG_ZigZag.s...

It's a shame the author didn't do the same transformation, because it would de-correlate a lot of the error noise. You can see in the highest compression settings that the "MP3" image compression is smearing everything horizontally. If it used a zigzag transformation, it would be a more smeared both horizontally and vertically, but probably less visually bad.

> Note that we’re 40 years of Moore’s law scaling later and the available memory bandwidth per instruction has gone down substantially.

This is unfair, and (this is me being unfair now) this article is missing the woods for the trees.

There were engineering pressures which resulted in the current ratios. I think it is fairer to say that the current situation — where there's about (hand-waving) 1 byte per instruction of bandwidth per core — reflects the kinds of tasks we expect our machines to be doing. It is very rare to find a task which is memory speed bound. There's almost always substantial processing to be done with data.

It's not even that hard to increase memory bandwidth. You "just" double up memory channels. This is of course expensive, which in turn is a back-pressure which results in architectures designed around the current sweet-spot.

I'm also puzzled the author thinks the situation is "worse". Pretty much every desktop class machine I've used from about 1990-2005 was extremely starved of memory bandwidth, and cores did a far worse job of hiding latency (OOO renames etc). What we have today feels fairly comfortable, to me at least, with some outlier tasks where you might want more (and then obtain specialist hardware).

This is a long-winded way of saying: the current core vs memory speed ratio is a sweet-spot of cost vs efficiency, and works well given the tasks and algorithms we execute on these machines. What we had in the olden days was just a case of unoptimized architecture, which hadn't converged yet.

What did you expect — a turn-key solution for sale? They claim no such thing.

This is great research. They've demonstrated that it is in fact possible to obtain a passcode at a distance, at least in contrived conditions. The fact it's possible whatsoever is a significant result. Even without being able to obtain the exact passcode, this would yield the ability to guess a passcode in much better time than just random selection.

H1B is not mentioned by the actual DOJ complaint. This is not an immigration story.

You would think, from your comment, that this case involved immigration and/or the H1-B Visa system. But it doesn't. Immigration isn't mentioned whatsoever in the document.

> Can the DOL back up this claim with salary data to see if Oracle is abusing the H1-B visa system by purposefully keeping wages low?

Readers should note that this is purely your own conjecture. The H1-B visa system is not relevant to this story.

You're missing the part where the employer is required to:

- Post representative salary data, including the last few (5?) hires to this position.

- Publish the job position locally, so it can be filled by local workers preferentially, and then only by H1B if unfilled.

- Ensure the worker is initially paid a salary similar to other existing hires in that position.

I don't understand how people make the leap that H1B is used to lower wages. It's an awfully complex, risky and inefficient way to suppress wages. You would need to lie about "prevailing wages" in order for this scheme to work, which is illegal and would put you and your company into deep trouble.

> When I read OP's question I was thinking about already-shipped products that became too hard to run and maintain.

I've been mostly in consumer electronics related companies, where a product which ships and then becomes too hard to maintain usually doesn't "fail". It just gets phased out. In a way, this is another way technical debt has an indirect, but large impact on products: obsolescence becomes a necessity. Not so much planned — which implies malice — as simply realizing it's not possible to maintain indefinitely.

> I am curious how long your products/projects were in development for before falling to tech debt? Were these net-new projects?

Usually very quickly, or after far too long.

The better projects know ahead of time that there are Dragons lurking in the code base. But that's effectively saying there are projects which never even got past brainstorming because we knew the technical debt was too high.

On the other hand, there are projects where it only becomes apparent how much debt there is after a lot has already been invested. It's like you'd expect, e.g "There's a performance problem because of a basic primitive this library uses everywhere. And that was originally a workaround for a compiler performance bug. We could fix the compiler bug, but it turns out other libraries relied on it..." and so on. Extra time-to-market makes a product make less and less sense — fashions change, hardware improves, new tech arrives — and so it gets killed. Or worse, shipped.

How about: All Of Them

Every failed product/project I've worked on in my professional career, which had full intent to ship from the start, was killed by technical debt. It's usually indirect, but it's always the root cause.

It takes many forms:

* Too buggy to ship, due to a creaky old code base being over-stretched to a product with too high reliability/experience expectations.

* Product form factor, efficiency, user experience not good enough to sell well, due to spaghetti code base which couldn't be whittled down to removable pieces. Result: large runtime, more expensive, less efficient hardware.

* Existing old codebase deemed too bad to ship a product, requiring a rewrite-from-scratch, but timescale too long to make any sense -> product killed.

It's difficult to elaborate more while maintaining some discretion about exact companies and projects. The general point is: technical debt isn't just some fuzzy intangible issue — it indirectly creates enormous costs in people and time, can affect the physical form products take on, and impact the user experience. Products always get started without taking this debt into account, but when it's finally realized, it can change basic features, and then it kills them.

Products are designed with faulty assumptions about what existing resources can be applied to them.

"The directors of Lyft and Uber are legally required to maximize profit for the respective shareholders."

This is utterly not true, and even companies like Google have (had?) it specifically written into their shareholder prospectus that this wouldn't be the case. Companies which maximize profit at any cost are doing it because they want to not because they have to.

http://www.nytimes.com/roomfordebate/2015/04/16/what-are-cor...

Video output and its perception, is not at all like audio output and its perception.

We can make blunt statements about the limits of audio, because output devices behave (largely) linearly and band-limited, and because human perception can be modeled accurately and is also band-limited.

You can't say the same about video. The output is an array of points, not even perfectly square or smooth, it is picked up by another array of receptors, and is non-linear. The limit being 1/60th degree is too blunt a rule of thumb. That's picking an arbitrary point on a curve showing how much better than guesswork a viewer is.

The screen isn't a perfect output source, and the viewer isn't a perfect receiver, and the combined effect is you can easily observe the difference of 2K vs 4K images at distances those graphs say you wouldn't. I can easily observe the difference where it says I shouldn't be able to, and I'm nowhere near perfect vision.

I would say pretty much everything in those graphs is off by a factor of 2.

I've never been a fan of SELinux, in the context of what a "normal" GNU/Linux install looks like.

I've only just managed to put into words what my misgivings are after reading this article: it feels like anti-virus software. The trouble is, it's bolted-on security. It's trying to contain software which wasn't written to a strict boundary, to a strict boundary. So you start with a crappy boundary of existing insecure software. That doesn't really achieve much - it prevents expansion of each process' role, but it's already a huge boundary most have.

It makes more sense in the context of "fresh" Linux OS software, e.g Android, but that's exactly where a strict policy from the start, like seccomp, would have done the job.

I think the article misses that there's a third way: subdivided software written with strict roles and boundaries in the first place. Hence why I classify this as "anti-virus" - its enforcement only kicks in after compromise. Prevention is better.

There is a monumental amount of "faster horse" in modern OS deployment. Hypervisors, and their ugly cousin - secure monitors, are an example of Conway's Law. They exist because there are different groups involved in writing the kernel, user land, and server deployment.

The author seems to feel that everything will concentrate at the hypervisor level - kernel and user land just a "detail" as they are single-purpose. However, you should spot that really the kernel and userland can be compressed into one layer. So why are there 3 layers at all? Then we have kernel and user land again and hey we just came full circle.

Again, it's just a reflection of how the organizations are arranged. Given a single organization with authority over the entire stack, it would be a terrible waste to have that 3 layer stack.

This is not wikipedia, and we don't need [Citation Needed] for everything we say. As you point out yourself, you can easily find at least 5 results. You can also easily find references for everything else I say.

The standard here is not to LMGTFY every few words.