Nothing to do with other items in orbit, I can believe. The ability to launch a little outside the window and still make it, though, should be valid unless they are running on a lot less margin than I expect. I know the first stage, at least, has *some* margin, or it wouldn't be able to do the deceleration and landing burns.

Nobody does message passing for basic operations. I actually tried to asynchronize DragonFly's system calls once but it was a disaster. Too much overhead.

On a modern Intel cpu a system call runs around 60nS. If you add a message-passing layer with an optimized path to avoid thread switching that will increase to around 200-300ns. If you actually have to switch threads it increases to around 1.2uS. If you actually have to switch threads AND save/restore the FPU state now you are talking about ~2-3uS. If you have to message pass across cpus then the IPI overhead can be significant... several microseconds just for that, plus cache mastership changes.

And all of those times assume shared memory for the message contents. They're strictly the switch and management overhead.

So, basically, no operating system that is intended to run efficiently can use message-passing for basic operations. Message-passing can only be used in two situations:

(1) When you have to switch threads anyway. That is, if two processes or two threads are messaging each other. Another good example is when you schedule an interrupt thread but cannot immediately switch to it (preempt current thread). If the current thread cannot be preempted then the interrupt thread can be scheduled normally without imposing too much overhead vs the alternative.

(2) When the operation can be batched. In DragonFly we successfully use message-passing for network packets and attain very significant cpu localization benefits from it. It works because packets are batched on fast interfaces anyway. By retaining the batching all the way through the protocol stack we can effectively use message passing and spread the overhead across many packets. The improvement we get from cpu localization, particularly not having to acquire or release locks in the protocol paths, then trumps the messaging overhead.

#2 also works well for data processing pipelines.

-Matt

Well... basic procedures using only MOV/CMP/JMP is not something that even linux really needs to code in assembly. What is being talked about here is primarily the trap, exception, syscall, signal trampoline, and interrupt entry and exit mechanisms. Also thread switch code can get pretty complex because there is a lot more hardware state involved than just the basic register set. When you start having to deal with SWAPGS and MSR registers, you've really gone down the rabbit hole.

-Matt

It's not a major refresh, only a modest one, and it doesn't really fix the readability issues (which would require a complete rewrite). Linux assembly is a mostly unreadable, badly formatted, macro-happy mess. The assembly in the BSDs is much more elegant and minimalistic.

-Matt

You're remembering wrong. Most ISS launches have windows a few seconds wide, at most. There's a lot of stuff in LEO, all moving very fast, If you want a course that will hit the ISS at exactly the right speed, and not come too close to anything else, you've got a narrow window to do it in. You *can* launch outside that window (space is a big place), but it eats into your fuel and safety margins and usually there's no reason to do that.

If you plan on having the medium survive your house burning down, it'll either have to be something really exotic(CNCed cuneiform tablets?) or something boring inside a sufficiently fireproof safe (which can get costly; but are a well recognized product category).

If it gets to the point where the fire and/or water are in contact with your storage medium, luck might save you; but the odds are lousy enough that it doesn't really qualify as a plan.

You really should consider off-site storage. This doesn't have to mean 'in the cloud', anything that gets updated very infrequently can be dumped to some backup medium and shoved in a safe deposit box.

Hillary is 67. That's three years older than Romney was four years ago and only three years younger than McCain was in the election cycle before that.

The only candidates the Republicans have ever run (going back to 1856) who were older than Hillary were McCain, Bob Dole, and Reagan (for his re-election, not his first term).

The people who complained about Republican candidates being old white people are proclaiming Hillary is just the perfect age now. It was all just hypocritical grousing.

Looks pretty good. LG should have just licensed/bought that from you. They'd probably have made it a service that starts (with elevation) automatically, but eh, much better than what they actually did!

You're aware that Windows 1-3.x, Windows 9x, and Windows NT/2000/XP/Vista/7/8.x/10 are each very different systems, right? No, of course you're not, you're a loudmouth who has no idea what he's talking about. Windows NT (which is to say, every version of Windows for PCs or servers since XP) was very much designed with isolation between *all* users, including between Administrators and non-Administrators, as a central feature. Windows NT is not, and never has been, a single-user operating system.

The last version of Windows that was designed as "A SINGLE USER operating system" was Windows ME. Why the fuck would you want to run as though you're running Windows ME? That's bloody idiotic!

Windows NT 3.1 (the initial release, came out in 1993) was very much multi-user, although it wasn't terribly good at timesharing (it wasn't until Windows 2000 that Microsoft added the ability for multiple interactive logins at the same time).

As for why you shouldn't use your OS as a single-user system, there's a number of reasons. One of them is because you, personally, obviously aren't competent to use a computer securely, and probably shouldn't be trusted with anything you have more control over than an iPad (which is, by the way, very multi-user although the earliest versions of iPhone OS, before it could run third-party apps at all, ran everything as root). Another is because sometimes other people run stuff on your computer (via exploits or Trojans or just by walking up to it while you're taking a piss) and you probably don't want them to be able to change everything they feel like changing (you had an impressively stupid rant above about how even an installer shouldn't be able to change UAC settings, which was funny).

As a point of random curiosity, are you aware that there's malware that installs into your hard drive controller and/or your motherboard firmware? Reformatting won't help you there. Also, have you heard of cryptolocker (and friends)? If you reformat, you lose just as much data as if the malware has its way with your machine.

Wow, I've rarely seen so much idiocy written in one post! I honestly can't tell if you're trolling just a little too subtly, or are sincerely that clueless. People are modding you up though, which is really unfortunate. Here, let me see if I can correct even a little of that...

If you run as a full Admin, nobody cares what you consider yourself; people who know anything about security (on *any* OS) are going to consider you an idiot. The fact that you think you know anything is just extra pathetic. People who actually understand security turn UAC up (to make it require your password, like the equivalent mechanism does on non-Windows OSes), or don't run as a member of Administrators at all (in which case UAC requires an Admin's password).

Windows simply wasn't built from the ground up to insulate the user space from the root space.

Welcome to... 1993? Windows NT was very much built from the ground up to do (among other things) exactly that. It was a core design goal and generally successful; while local EoP exploits have been found (and fixed) much like they are on every multi-user OS, I challenge you to get from my normal account to Admin on either my work or personal boxes. Fortunately, on a properly-used machine - even one being used by a security engineer, which I am - UAC prompts are very rare.

The fact some program that can change the UAC settings is pretty huge example of why Windows has issues separating userspace from root space.

You're aware that the installer for this thing runs as Administrator (like most installers), right? How exactly do you propose separating Admin (the installer) from Admin (the privileges needed to change the way UAC works), and what the fuck does that have to do with separating user from Admin? Oh, by the way, "userspace" or "user mode" is the opposite of "kernel mode" or "supervisor mode". Everything in kernel runs as root, but not everything in root is in the kernel. Most processes running under root (or Administrator, or even SYSTEM) are user mode.

Who's [SIC] brilliant idea at Microsoft was it to provide any sort of API that can let any program (besides the control panel widget that lets you adjust UAC settings) adjust UAC settings?

Do you have any fucking clue how an operating system works? I mean, even at the basic, general level? Here's a hint: when that Control Panel widget adjusts UAC settings, it is flipping some bits in some configuration store somewhere (*nix mostly uses text files for these stores, Windows mostly uses the registry; in this case the relevant bits are, indeed, in the registry). *ANYTHING* with arbitrary privileges on the system (like an installer running as root) can flip those bits; that's just a basic function of the way OS security works.

I think

No, you actually don't. It's really kind of pathetic.

No program should be permitted, regardless of it's permissions, to touch things like UAC settings.

And how, exactly, do you propose to stop a program that has (worst case) the required permissions to load a driver that can touch physical memory directly from doing anything at all, including changing an OS setting? I sincerely ask you, please, tell me your brilliant idea for revolutionizing the entire field of computer security more than anything since Multics development started 50 years ago.

What do you mean, Admin isn't "allowed" to terminate SYSTEM processes? Administrator (the user), or members of the Administrators group (after UAC) have exactly the same level of access as SYSTEM; SYSTEM is just a machine/service account, rather than a user account.

There are certain processes on Windows that the OS will prevent you from trying to terminate, but that's because they're critical OS processes, not because they run under SYSTEM. You can run Calc.exe under SYSTEM with a little effort, but killing it through (elevated) Task Manager is trivial.

Uh, no offense, but you don't know much about Linux, I take it?

There's a bunch of options, ranging from "mark everything setuid and owned by root" (the least efficient, but you could do it in a few lines of shell script) to simply making each user be UID 0 (which is a trivial edit to /etc/users).

Frankly, you kin of sound like you're mouthing off without knowing anything of what you're talking about (Windows or Linux. Windows NT (which everything since XP has been, in kernel and core components) was very much designed from the beginning with security options in mind. The fact that everybody then ran as Admin instead of running as a normal user unless a program needed admin is unfortunate, and is partially Microsoft's fault, but only somebody utterly ignorant would think that Windows security is an afterthought.

To be the kind of person who would be utterly ignorant and then open your damn fool mouth is... well, I'm sorry. Nobody wants to be that person. You do deserve to be modded down, but what you say is not true at all. I have mod points, as it happens, but chose to reply instead. Maybe somebody else will take care of you and your unfortunate attitude...

For what it's worth, here's some more info: It's true that mandatory integrity control (MIC), which has security impacts, is relatively new (Vista) to Windows, but at least Windows uses it at least slightly; a typical Linux distro doesn't use it at all (though it is available). Speaking of afterthoughts, though, Windows (NT family) has supported ACLs since its initial release, while Linux only supported basic Unix permissions (which are a small subset of the control that ACLs give you unless your group count balloons absurdly) until 2002.

The core of the issue has nothing to do with going off-grid and everything to do with matching production from renewal sources to the actual load on the grid. Without that we get into the situation that Germany finds itself in, which is two fold: (1) That electricity prices fall to zero during the day due to all the solar, and as subsidies go away the owners can't make money from providing power to the grid. And (2) The base load differential between day and night is so great that the traditional generation (i.e. coal) cannot run continuously at critical mass and so becomes extremely inefficient and uneconomical. So coal power generation companies in Germany are also going bankrupt.

Ultimately consumers with PV systems will be forced to pay spot rates and feel the pain. This is already beginning to happen in many parts of the country... where day-time electricity rates are lower but the buy-back is also lower, and night-time rates are higher and have a higher buy-back.

The idea with using the electric car battery (or some other form of temporary storage) is to use it store energy when prices are cheap and inject it into the grid when prices are expensive. This also has the side effect of reducing the base load differential between day and night, so other generation sources such as nuclear and coal can operate efficiently (and thus profitably) to make up the difference.

There is nothing nefarious going on. Really, going entirely off-grid is not something anyone should be trying to do unless they actually live somewhere with a flaky grid (or no grid). And the reality is that electricity prices are going to fluctuate even more between day and night, or rainy vs not, or windy vs not, as more renewable energy sources are brought online.

-Matt

ark is helpful, if not always detailed enough; but it make Intel model numbers non-cryptic in much the same way that DNS makes IP addresses human readable.