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.

I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS, that you don't really need to care about what the platform gives you. That gives you a great portability story, once the layer is in place. The bad thing is that you do not benefit from the specifics of the platform. If you let your portability/base layer rot, you are also behind everyone's game. What's happened during the last 5-10 years is a lot of work to make the C standard library (or slight variations of it), as well as base system calls, much more hardened, to some extent providing security in depth. The LibreSSL critique has been based on the fact that OpenSSL went with their home-rolled, slightly inferior, slightly unpredictable (not handling NULL values in places, at least not in the same way any sane platform did, etc) layer for far too many things, even on modern platforms. As a provider of a platform with security in mind, I can understand the frustration of having a crucial library saying "hey, we don't care about that stuff, we can implement everything we need".

The power output of a Boeing 747 is 140 MW according to a slightly unreliable Wikipedia list. Now, this is probably the total engine output, but you would certainly need a significant fraction of that in electrical power for propellers. Note the other number in that list? A full Nimitz-class destroyer is 190 MW (that seems to be electrical power). A nuclear submarine does not even come close. The cooling environment of that 20 ton reactor is probably quite different, too. You can cool off the rector coolant against the ocean. Not so at 30,000 feet.

Furthermore, what is atomic in terms of context switching preemption is not necessarily atomic in terms of memory bus arbitration. The two can usually coincide, but they don't have to.

I would imagine that the gradient will be much more dependent on the location of pumping and isolation, rather than gravity, though.

I think it does. The time scale is just staggeringly different. Watching a water surface dry, and one with low area versus the volume, at that, is a boring activity. Put some table salt in a glass and fill an identical glass with water. Put some lid over it all. The equilibrium state will be more water in the initially empty, salt-containing, glass, than in the one originally containing water. Why? Because of the change in boiling enthalpy. But that change, and the formation of a water film or drops on all other surfaces in the enclosed volume, is immensely slow anywhere near room temperature.

I think you need to be introduced to a modern optimizing compiler. It will handle the first two for you, just fine, as long as you are in the same compilation unit (or doing fancier global optimziation). Since you just refactored this from a single function, you are supposedly still in the same compilation unit. If you pack the data in something like a stack-allocated struct even the last one will be reduced or completely avoided.

The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess. And then we haven't even got started about embedded systems...

Go to the company website instead. They say lunar resources and are able to tell the difference between kms and miles. However, it's all a bit pie in the sky even there. Even with the advantage of lunar resources, I would be more optimistic about geostationary orbital solar power. Microgravity would mean that you could get away with really thin structures, even concentrated thermal solar might make sense if you can work out a reasonable cooling part of the cycle (just make an extremely thin mirror as the bulk of the concentrator).