Even if mass would be quantized, the Newtonian equation is m1m2/r^2. Even with discrete mass quanta (which is also false, see other replies), you would get a continuous spectrum of resulting forces. Inserting relativity here changes the expressions, but it would really just muddle things. So, no, there is no specific reason to believe gravity to be quantized - outside of an actual theory of quantum gravity.

My point is that a "too good to be true" bug could easily have quite devastating consequences if it's just fixed. If they remove 'false' in the putative "if (isInTest() || (isNOxReductionNeeded() && false) enableEGR();" line and this increases fuel consumption or reduces maximum torque a lot, they cannot simply release that fix.

Embedded automotive control systems and scientific research are quite different domains, but in science I've repeatedly been close to thinking I had solved a problem, just to realize that my benchmark was off and the code was not really working at all. I have not published any of those results (AFAIK) yet, but I've reviewed and seen publications with blatant errors. When you have reached the kind of result you hoped for and believed likely, you are not on guard anymore. Fixing the blatant error might very well mean that the whole work is pointless. The error is trivial, the consequences are not.

Yes, but that was not a conspiracy. It was very clear in the specs and even highlighted as an advantage. The question is "who knew and approved, at what point, that this design would not work out in practice". Even the idea that smart design of the control regime would make it possible to achieve low emissions without SNCR is not, in itself, equivalent to fraud. It's only when this design becomes all about "detecting test conditions" things get really, really bad.

The linked article makes the point that the sensors and hardware would not be necessary. I think the writer seriously underestimates to what extent a modern car with protection systems will try to juggle different constraints. Things like non-driving wheel rotation (defeated by being on a lab stand) are needed for breaking systems and possibly to some extent to moderate throttle control for stability. Wheel movement patterns are also needed and useful, even if you don't actually have electric power steering.

Regulating the exhaust gas recirculation somehow also makes sense. You might go totally on and off, but you would certainly want to keep it at a sensible level. You want good acceleration and full combustion of fuel while still not emitting to much nitrous oxides. It makes total sense to me that you might want to design your control system to try to judge not only the current emission levels, but also the overall driving pattern (steady straight ahead, repeated stop and go, etc) with some kind of state machine to try to find the best EGR regulation regime. This requires sensors and ways to regulate the feature.

My most innocent guess about how something such as this might have happened was an intent to find a good regime that would give nice bursty performance, while keeping nitrous oxides low overall. Progressively, the control regime was pushed until it ended up in the corner where the case of EGR being properly activated under real-world conditions basically does not happen. Some parts of it might even in the end be a bug between the intended state transitions and the actual ones. Like all bugs that give performance that seem too good to be true on the metrics you really care about (fuel consumption and enjoyable driving), no-one investigated.

Do I think it happened this way? It's hard to say. Probably not. But, in one way, it's even more frightening than an evil conspiracy. It's easy to say "I wouldn't take part in a conspiracy by my employer". It's harder to say "I would never be pressed to write code with goals that could not be fulfilled, eventually find a hack that seemed to work, and maybe ignore investigating why it worked so well"...

My attacker is very regular. He kicks my canary machine down every 49.7 days.

Unless it, say, causes a higher energy usage or makes you slightly more prone to parish from an infection. The selection pressure for most of our evoluationary history might just be a tad different than it is today. It works the other way, too, of course. Other threads note the increased risk of getting depressed from all the "bad news you can't fix". A high intelligence might make it harder to just shrud that off, while you could more easily filter it out with lower intelligence. (Just like kids can hear some conversations and really don't take note of the full depth of what's being said.) This phenomenon might be worse today than it used to be.

What is this fusion "ore" you are talking about? Even if we restrict ourselves to deuterium or even tritium, the ocean reserves are plentiful even in the "multiple orders of magntiude" energy consumption case. Longterm, exponential growth will require space exploration and I am all for it in short-term, but let's keep to the facts.

So, did the inhabitants evolve into somewhat benevolent beings of pure energy, or just underground-dwelling mega-brains that like to keep pets?

While impersonation and other techniques is used a lot more and including larger portions of the API, impersonation itself has been along since NT 3.1. Are you a file server process serving a request from a client? Just create an impersonation context for the user who sent the request and pass that along to the file system. You only need to make sure that you create the right context and tell other services on whose behalf you are doing this. This is not identical to setuid and similar, most importantly because a single thread can keep many impersonation contexts.

That this is part of the application compatibility cache service is almost coincidental, the real problem is in the fact that impersonation services are used, but used incorrectly. Impersonation was part of the original NT design, and for relatively good reason.

Any wear levelling worth its salt will not do what the grandparent wrote. You simply do not change one page in a block. If you write a single page, that is handled by mapping that page to another (free) block and maintaining a mapping table for which LBAs are currently stored in what blocks. However, if you are doing single-sector writes, or in turn repeated I/O flushes of the same sector, you still see a lot of write amplification. To keep data integrity, the mapping tables also need to be kept updated in a correct way (or at least uniquely recoverable by scanning through all blocks after a hard power off).

But, well, the difference is that Oracle has actively asked everyone else to quote references to their book. Google has produced a product that only respects those references that Oracle has encouraged anyone to use. If Oracle starts pursuing anyone *writing* Java code for copyright infringement ("hey, you called all methods of ArrayList, in the order they are declared"), that's a different thing.

Has Google copied Javadocs? Those texts are not necessary for technical interoperability. Thus, it would be a very different thing. Public symbols should be just that, public.

There are many things involved. Like whether you call it Java. Microsoft wanted to call their VM Java and execute Java bytecode. Google differs on both points. And, well, despite its size, Google is currently not (considered to be) a monopolist.

Proper help to the health workes would include vaccine. In an early phase, there won't be enough vaccine doses for the general population anyway, but currently health workers are at high risk and the number of doctors is dwindling. Not because they leave their posts, but because they die. If you have protective gear and practices that reduce the risk of infection by 99 %, that's still a high risk scenario if you are at a treatment center with multiple patient encounters a day. For any similar infection where there is some kind of vaccine or prophylaxis, health workers get it. The side effects could be quite dire and still be worth it, assuming they are going to do their job at all.

Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have. Some of the lessons learned regarding being frugal make sense, but you will also learn a lot of tricks that are either directly counter-productive, or at the very least steal your attention from what you should be concerned with, even in those very cases where you are really focusing on performance and power efficiency (in addition to the myriad of valid cases where developer productivity is simply more important than optimality).

It used to be that you couldn't pre-calculate everything since you didn't have enough storage. These days, you shouldn't pre-calculate everything since it will actually be cheaper to do it again rather than risk hitting main memory with a tremendous amount of random accesses, or even worse, swap. Up to some quite serious size data sets a flat data structure with fully sequential accesses can turn out to be preferable to something like a binary tree with multi-level indirections. (Now, the insane amount of references even for what should be a flat array in anything from Java to Python is one reason for why even very good JITs fall short of well-written C, Fortran, or C++.)

A slightly more pragmatic approach is to keep those implementations, at least the most crucial ones, but please make sure that you use memcpy etc directly on any sane modern platform.