Networking on Microsoft was an afterthought until the mid-90's. Sure there were token ring and banyan vines drivers in the late 80's early 90's, but that was to share a drive letter. The entire idea of multiple users didn't appear until Win3.1 for workgroups, decades after multiuser OSes. WinNT started to take protected mode seriously, but they re-invented networking from an MS perspective (e.g., POP/SNMP? nope: MSExchange).

It's not a surprise that Windows is such a mess under the hood compared to Linux/BSD/Unix/SystemV when you look at the history of Windows. I dunno, maybe that's not fair, but switching between *nux and Windows from a networking / distributed computing perspective is jarring. And that's just for simple things (interface config, tracing, configuration of multiple adapters and bridges...)

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.

But for servers, I much prefer Linux. It uses less resources, and it's so much easier to get it into a known and consistent state that Windows.

Also, something about having a GUI for servers has always felt... wrong somehow!

It wouldn't surprise me at all to find some windows based companies that have classic windows VMs in the cloud, running Visual Studio, and production deployments are: RDP in, stopping with the little red button, updating the codebase (with a copy over a network share), and then re-running the code on the production server with the little green play button. Database changes are done by hand in SQL Server Manager.

I know this isn't at all related to the post here - but it's just an interesting phenomenon - the fact that Azure is about 50 percent windows means it's mostly running things like Office backend products, crazy running copies of Visual Studio. It is probably a total mess if half of Azure goes down for 5 minutes. Linux servers would come back up and continue running whatever. All the Windows companies get a call, have to RDP in and do shit.

This and the rest of your post is about one specific kind of developer, and I honestly wonder how you can think that's it.. Lack of experience or just bad luck and only ever met this kind perhaps? Anyway while I know for a fact these exist, your feeling is sort of wrong in that there are also developers who just use VS as the IDE it is (to write code and debug; it's good at that) and for the rest automate build environment setup, deployment and whatnot just like you'd do on another OS. I just don't know the numbers, i.e. which share of developers using VS act like you describe. It's not like using VS somehow makes people blind for concepts like CI. Data point: we have a bunch of scripts (combination of PowerShell/Python/MSbuild) which will install and setup the complete build environment from scratch (VS/Miniconda3/Vcpkg/...) checkout all code (yes from git, not from a network share), build a myriad of different flavors of the product, package it; all in one commandline command.

Python used to do this, it still may.

I think what you're noticing is that Visual Studio makes it easier for point-and-click developers to participate while a bash shell takes a little more effort to learn. You can have poor developers in both worlds or great developers in both worlds.

I have also build in Go, nodejs, Php, RoR.

But VS is truelly the best IDE experience I have witnessed.

Database changes are automatically migrated and deployed using entity framework fyi.

The big deployment button changes the connection string per deployment, deploys with feature flags directly and automatically migrates the db to the latest version

Something VS based development, build and deployment based workflows have been doing for over a decade through the largely Web..config files and .csproj files.

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy...

That might have been true once, but I think Microsoft-stack devs are a lot more command line savvy these days.

The move towards DevOps and scripting makes the command line much more necessary, and makes the benefits of the command line clear. The move towards cloud has introduced Linux to a lot more organisations, yes, even Microsoft shops.

I don't think it's ever been that true. It's just a handy stick for some people to bash their perceived out-group.

I'm detecting a bit of disdain for the VS world

As someone who learnt to program using linux/Mac OS, when I got a job somewhere that used windows and VS exclusively, trying to get my head around the (to me) needlessly confusing and convoluted way in which windows-dotnet devs seemed to do things was a painful experience.

Watching some of them try and debug docker files was amusing because that was a total role reversal.

My experience as well. In fact it was extremely much faster.

- Hello world took something like 5 seconds to run on Windows

- on Linux (a VM on the exact same laptop, with the same Windows running underneath in fact) it was so fast I had to use the time command to figure out how many milliseconds it took :-)

FTR: while it was hardly scientific I actually put some effort into trying to make sure it was equal.

Well, technically it might have used 700ms the first time and 400ms later, I didn't measure the first run, but it was still way faster than on Windows which was why I started measuring using time after all.

Also on Windows it kept being slow on subsequent runs, and in my world that matters too.

I don't have recordings, but I recommend you try for yourself. I compiled both from the same source, and as far as I can remember I used standalone compilation for both (I don't have perfect memory but I have a history of being careful.)

RegEdit, is there a text version for that? Imo there's no comparison to the Linux ecosystem.

Windows is GUI first.

Uhm, in Powershell:

    PS C:\Users\zb3> cd hklm:
    PS HKLM:\>

Also I get much more fine grained control over permissions in the registry, right down to individual keys. Try doing that when your config is in a text file.

Yes, MicroSoft made a big thing about this about five or six years ago if I recall correctly. All the server products like Exchange or SQL Server treat PowerShell as a first class client.

You can walk around the registry just as if you are traversing a directory tree.

If anything the GUI is becoming rather dumbed down in recent releases.

AFAIK, yes, it's at %WINDIR%\System32\reg.exe

And what third party tools does that involve?

Apparently Windows is human first which isn't what servers are meant to be.

The GUI is big, and I run that when needed, RDS, userland stuff etc.

The advantage of Linux is when you want to accomplish tasks without a great internet connection, but the windows tools are not evolved enough as far as command line functionality.