What would be interesting is a complete re-imagining of a server OS. Consistent file locations for everything, which are automatically versioned a la git allowing you to roll back any specific change, built into the OS level. All processes totally sandboxed from each other with specific permission elevations as required (like iOS).

> What would be interesting is a complete re-imagining of a server OS

Not sure how 'complete', but aren't you after something like NixOS?

The Windows registry is a bad implementation of a good concept.

Imagine if the registry had a schema with embedded documentation, foreign key relationships, a packages database with each key owned by a package, etc...

I've built software with a configuration database (Windows registry) and with flat configuration file-folders (*nix). I feel like I'm running in a circle because the trade-offs are so equally balanced that there's no best-case. From considering backups and database consistency, to tripwire malware detection of changed settings, to automation of access, to consistency in naming, retrieval, and type conventions, to self-documentation, to backwards compatibility... At this point I'm not even sure I would understand the correct or "best" methodology if it was handed to me on a silver platter.

So a database then?

If by database you mean "relational database" – I'm not sure the relational model is the best fit for a config store. I think a more hierarchical database model is more natural for that purpose. (Of course, you could use a relational database as an underlying implementation detail – LDAP is fundamentally a hierarchical database, but there exist LDAP servers which store the data in an RDBMS, for example Oracle Internet Directory.)

There is a big difference between Linux and BSD here.

Linux has really exploded with configuration. Are we using 'ip' or 'ifconfig'? Are we using /etc/<app> or /etc/<app>.d/? What about /lib/system? Do I restart that systemctrl or service?

BSD has kept it a little more "pure" in that it is more of a "only one way to do it" philosophy.

There's a good reason why Linux absolutely dominates the server space.

It was like someone flipped a switch and suddenly there was only one type of environment for all computing (we used something else besides VNC to manage remote X sessions, I forget what it was, it was some weird launcher for Windows).

IT claimed hundreds of millions in savings due to not having to pay for AIX, HPUX and SunOS licensing. I think the cost is what tipped the scales.

Yeah, it was cheaper (in both senses of the word) than all the other contenders and more or less Unixy enough that software could easily be ported over.

Correct me if I'm wrong, but wasn't Linux quicker to support multithreading than Windows, largely because big megacorps needed that for their servers?

Surely you jest. The other Unixes, including Microsoft Xenix, supported multithreading before either Windows NT or Linux even existed. Big megacorps in that era used Sun Microsystems ("The com in dotcom™") server and other proprietary Unix servers because both Windows NT and Linux on the x86 hardware of the time weren't considered good enough to handle megacorp server loads and that didn't change until around '00.

If you go strictly by release date, Linux 0.01 came out in '91 and Windows NT 3.1 came out in '93 so it's technically correct that Linux had multithreading first but neither Linux 0.95 (what would have been available in '93) nor NT 3.1 was exactly something anyone would consider using in production, let alone at a megacorp.

Oh well, shows what my memory's worth.

Some of the kernels were even good, but what gain does it bring if tar would always do the most insane action instead of backing-up your disk?

You can do what you describe without changing the kernel, but you would need to modify the userspace environment. One of my toy projects has been trying to run all "user" applications in filesystem sandboxes because I'm sick of how many random "dot-files/directories" get created in my home folder.

It's as opinionated as you are.

(FWIW there has always been a level of consistency in Linux w.r.t. file paths, if you stick to your distribution maintainers packages)

Usually, developers are sane and put things in /etc. However, there are a number of very common applications which have configurations strewn all over the place. Bonus points for apps which have even additional configurations in their systemd service files!

rpm -ql <package>

Windows 9x came from the single-user domain but is long dead except for compatibility stuff left over in modern Windows. Windows NT and its successors came from server space from its VMS lineage.

NT was supposed to be very tunable and modular and have multiple personalities and abstractions but it turns out it mostly is just win32-on-NT and everything else ended up being on top of win32.

It has gotten better, especially post-OneCore, but it still is very much restricted compared to Linux, BSD and Unix.

Windows NT (and VMS) were not as much multi-user server as they were more closer to mainframes (which died/are dying for their own reasons). VMS, like plan9, had concepts to allow many (theoretically) fancy server things, but were to much a created world instead of a grown world (like post-system-v). Also, while the VMS dude who was on the NT team did influence it heavily, the legacy they had to support made it almost impossible to use any of that fancy 'new' stuff back then. While it was orders of magnitude better than DOS, it feels like Windows needs to make yet another evolution like it did going from DOS to NT to get back to current times instead of patching on top of patches every time.

Even a simpler example though; the fact that there wasn't really a built-in analog for the "pipe" until PowerShell sort of boggles the mind. Yes, I'm aware that Windows isn't command-line focused, but it baffles me that software engineers didn't really see a need in Windows to compose programs together. (Someone, please correct me if I'm wrong on this point, I haven't touched Windows in any serious capacity in almost a decade).

From the get-go Windows NT (Win32) had a common model for overlapped IO (async IO in today's parlance). This async capability permeated everything from disk IO to network IO, and works well today with USB, Thunderbolt etc. Mind you, this model has not changed while Unix/Linux/POSIX still have not found a common model that works for all. See for instance https://stackoverflow.com/questions/13407542/is-there-really...

Under the hood Windows was also designed with a completion-oriented model (IO completion ports) which scales better in most instances than the Linux readiness-oriented approach (I believe that MacOS uses a completion approach as well, so the readiness approach is not universal *nix). Basically, windows saves at least one context switch for every basic IO operation. Windows supports the Berkeley sockets API with some optional extensions to make socket operations overlapped/async as well, essentially supporting both the straight socket model as well as the completion oriented extensions.

https://ss64.com/nt/syntax-redirection.html

And half the time you’d have to use the “for” cli monstrosity. I looked up the instructions every single time I used it for decades, that’s how bad it was/is.

https://en.wikipedia.org/wiki/Component_Object_Model

This is definitely getting deep into the Windows world, and if you didn't do a lot of highly Windows focused software development its probably easy to miss it. COM is a big giant complicated beast and definitely not a complete darling to work with but it had (has?) a lot of really cool concepts. Very different from the everything is a stream of text basis in Linux. And even now with things like Powershell, you're not sending text to the things you're piping to, you're passing .NET objects around.

Can you elaborate? Do you mean performance? Because the on the C level both use (apart from some minor differences, which aren't enough to call one 'simply better' than the other) the same berkeley socket API.

I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.

The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).

I have PowerShell, Git Shell and Cygwin running on my windows Dev box and all three make me cry on a weekly basis because I have to switch between them to do different things. I suppose one day I will sit down to fix my Windows dev environment, but it makes me feel so bloody frustrated that my muscle-memory shell is so ... perverted by windows implementations.

MS is bringing Bash to windows natively. I don't know how that is going to work since piping just isn't there, but I've got my fingers crossed that I'll only have to deal with ONE shell for windows!!!

It's not a native Bash experience but it's pretty close. I say "not native" because it's actually running a VM under the hood and bridging the file systems via 9P network protocol.

I know people who are using it and love it. I have not switched yet, but I am definitely going to investigate it at some point.

However, Linux admins who know networking usually have a deeper understanding.

Windows NT, which is what everyone uses, is a descendant of VMS design and culture, built for shared file systems, multi-user accounts, and distributed computing just like UNIX.

But still for a long time Windows NT made a lot of concessions to the single-GUI-user model that UNIXes didn't, like putting font rendering in the kernel.