Re: None of this changes anything
Q: What's the problem with the current (W7 and better) registry?
Fragile, difficult to manage, overly complicated, difficult to update without a running instance of Windows.
When it works, it works reasonably well, except some developers use it as a dumping ground for all kinds of crap that doesn't belong there.
But if your Windows installation goes belly up and you need to change a registry setting, you're in for hell. Contrast this with the nearest Linux equivalent I can think of: gconf, or the MacOS X equivalent, plist files, both of which are basically XML files stored with a strict naming scheme.
So anyone with sufficient knowledge can edit the appropriate file with a text editor to correct problems, a text editor that might be running from a LiveCD — this is more difficult to achieve in Windows with the registry.
Q: What's the problem with the current (W7 and better) DLLs?
Nothing with DLLs themselves, the biggest problem is Windows package management. MSI is a step forward, but there's still a lot of cowboy installers out there that just ram stuff in where ever it seems to fit.
End result: the OS has no idea what package owns what file, and so when you go to install a package that conflicts, the installer will likely just overwrite the existing DLL with theirs, or the uninstaller will delete it breaking something else. Worst of all, the DLL version information is embedded in the file, rarely does it feature in the file name.
Contrast this with Linux: where the package manager is responsible for installing and uninstalling packages, will scream at you if you attempt to install two packages which both include the same file, and dynamic libraries are named by their version number (so multiple versions can be installed in parallel).
Q: How many client systems are real time? How many server ones?
Not hard real-time, but you try listening to music or doing anything multimedia-related without some kind of real-time support. Multimedia is a real-time application, if the decoder doesn't keep the buffer on the DAC filled up, the buffer drains, under-runs, then the user complains that the audio is crackly.
VoIP is where this is particularly felt, and is applicable to both server and client — the whole system has to operate to real-time constraints. Too bigger buffers, and the latency becomes untenable for regular conversation, too little, and you become vulnerable to buffer under-runs.
Q: And of those how many are HARD real time like the old ORG/M or (IIRC) OS/9?
There is a hard real-time fork of the Linux kernel. Solaris also supports hard real-time.
Q: What do I need RT for outside of specialist systems
See above. Hard real-time tends to be more for control systems, and thus tend to be more specialist in nature, however examples of soft real-time systems abound everywhere.
Q: What is the benefit of Posix?
Write-once-compile-everywhere. Where there are differences, the changes are small enough that simple #ifdefs in C code can handle it.
I recently did a project wherein I was porting a coal train weighbridge system from SCO OpenServer to Linux. The system itself was based on MacroView SCADA and used UUCP as a means for transmitting weighbridge reports via phone lines back to the central office for billing.
The field computers needed to talk to a particularly old weighbridge controller. I was able to take the source code of their old driver, tweak a few serial port settings in the code and compile it for Linux. The biggest changes were in the stty settings for the serial port, everything else more-or-less JustWorked™.
I hear one of their techs (with no Linux experience) was able to take a field computer out to site and get it going without assistance. A true plug-and-play system.
I shudder to think what hell I'd be in for if I had to port the thing to Windows.
Q: Does Linux support Access Control lists OOB?
It has done for some time. Do we use them? Most of us find that the old-style Unix permissions work well enough for our needs. ACLs are useful in edge cases, but are overcomplicated for the bulk of permissions requirements.
Q: Where is the equivalent of WSUS or ZenWorks? (And no, the Repositories run by "somebody else" are not)
Perhaps you'd like to elaborate on what WSUS and ZenWorks do that aren't present in the open-source offerings? Rather than expecting us to be Microsoft-experts as well as Unix ones.
My rough recollections of ZenWorks was that it allowed deployment of software to a network of machines: something addressed by the combination of repository managers (e.g. apt, yum, etc) and orchestration software (e.g. Ansible, puppet, chef, etc).