Hacker News Reader

I think both are a mess under the hood. I cannot make sense of where things will be configured in Linux. maybe /etc/, maybe somewhere else, with loads of setting file configurations. There's not a huge amount of consistency.

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).

I'd still take a heavily configurable and customizable "mess", as you put it, than the one that doesn't allow me to control how it works.

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

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

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.

Well, not to mention that you're allowed to add features to it without waiting for Microsoft to do it. Linux might not be the best codebase in the world, but it's probably easier to add a feature to Linux than it is to get MS to add a new feature.

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?

> "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.

Linux didn't have real threads early on tho, didn't it? LinuxThreads were only introduced in 1996, and they were broken in many ways.

You're right. According to the old Linux Threads FAQ (https://web.fe.up.pt/~jmcruz/etc/threads/linuxthreads-faq2.h...), that seems to be about the right timeframe.

Oh well, shows what my memory's worth.

Yeah, that completely ignores how shitty all the UNIX userland was.

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?

When I worked for a large semiconductor company from late 1980's till early 2000's, I saw IT move from a ghastly mix of AIX, HPUX and SunOS terminals & distributed computing to 100% Linux ... in under 2 years!!

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.

Maybe you can check out openbsd.

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)

In another post I point out that BSD has done a great job keeping things consistent, whereas linux is a bit of a freeforall trying new stuff.

Not if you stick with Suse (OpenSUSE) or RedHat (centOS).

Gee, I need to change a setting on $APP. Wait, is that a config file in /etc/$app/? Or did they put that in /var/lib/$app/? Huh, can't find the setting I'm looking for there, guess I better check /etc/sysconfig/$app...

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 will tell you where installed files are:

rpm -ql <package>

Nor is there any consistency with the windows registry. Except that, by being such a pain in the posterior, noone edits it manually anymore and all changes are done through GUI apps. Editing config files is easier and faster (not to mention, automatable), so people don't bother creating "control panels" on Linux for the most part.

> 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?

> Nor is there any consistency with the windows registry.

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...

> Imagine if the registry had a schema with embedded documentation, foreign key relationships

So a database then?

Well, if you think about it, the Windows registry already is a hierarchical database – just a quite limited one. You could have a hierarchical database with richer features (LDAP is a good example of that, although in some ways LDAP is rather clunky).

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.)

I've wrestled with this for DECADES!

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.

Well gconf is hardly any better.

It moves around as well. There's a huge distinction between Linux _as a kernel_ and "Linux" _as an operating system_. The kernel has the same layout across all the distributions / operating systems, but everything else is up to the particular stack that distro chose. Gentoo is different from Redhat which is different from Debian, etc.

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.

Yes, that is an important distinction I glossed over. Thanks for adding that.

This is where Kubernetes points, FWIW :)

My favorite way to picture Kubernetes is to think of it as a distributed operating system. It generally happens to be run across Linux hosts and is used to run Linux containers, but the Linux parts are incidental, like the specific model of CPU in a desktop system. The Linux parts aren't core to Kubernetes' abstractions, and it's possible that Kubernetes could add support for hosts and container runtimes that aren't Linux but instead platforms more streamlined for Kubernetes usage without historical baggage.

Yeah, that's a good point.

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.

One of Linux's many great failings: it constantly seeks to reinvent the wheel. Unfortunately modern Microsoft is also suffering from this terrible affliction.

On the one hand I like seeing behavioral trends feed back into the software. On the other hand, there needs to be tighter acceptance standards, and more effort to minimize the disruption to established rules. That's probably much harder to do on Linux than BSD (windows & macos have no excuse, they control everything!). Linus T. really exemplifies that with the KERNEL, it is the OS that is suffering.

Having grown up under Solaris, which was BSD-flavored at one time, and then added SysV commands, and when Linux was on the ascent, added the GNU suite ... all I have to say is, bring it! All the inconsistent compile options for sed, find, things that look the same but don't act the same. Bah! :) It mystified me that epel packages install by default in /opt so you have to stick /opt/rh/blah/bin in PATH, and the attendant libraries. Considering the OS war in the 90s between Microsoft and Sun, it's a little funny, like cry-a-bit funny. Mr. McNealy would be surprise how his spats (probably for show) with Mssrs. Gates and Ballmer turn out.

> "Windows came from the single-user domain. Unix came from server space."

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.

I have to wonder what percentage of the Windows 10 codebase is for backwards compatibility.

While that is true, the win32 API and other stuff that floats on top of NT for the GUI based stuff (which is most stuff) is still very much restricted by that legacy.

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.

Not expecting that to happen as MS is investing less in Windows.

Given that we just got the new SDK, DirectX 12 Ultimate is around the corner and release notes are a pleasure to read, it doesn't look to me like that.

Can you give any examples of Win32 API that manifest design flaws or restrictions due to "single-user domain" legacy?

Yep, many years ago I casually stated here that Windows was clumsy on the network, and it really offended some guy. Limited drive letters and backslashes didn’t help, but the history you mentioned is the foundational problem. The misdesign around console/remote admin is another. For more background read the Art of Unix programming and the Windows Terminal blog about all the layers they had to work around to shoehorn it in.

I still run into Windows Admins who don't understand UNC paths vs mapped drives.

I agree that networking stuff feels pretty frustrating on Windows compared to POSIXey stuff; for the most part using a good networking library like (as mentioned above) ZeroMQ or even some of the built-in JVM socketing stuff will help abstract it, but Unix sockets are simply better out of the box.

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).

socketing stuff will help abstract it, but Unix sockets are simply better out of the box

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.

Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP.

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

Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection.

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).

You could always pipe commands, there just weren’t any worthwhile to pipe to. I often consulted this site often twenty years ago:

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.

Windows IO model - including network - is arguably much more well designed than anything POSIX, thanks not least to Dave Cutler and his team.

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.

You appear to understand this stuff better than me, so you've gotten me a bit curious; how did something like Java NIO work before kernel 5.1?

This is a very enlightening post, thank you. I don't often develop cross platform to this depth, and I think it is a wise reminder that Microsoft actually knows a thing or two about operating systems, contrary to popular opinion. It's almost like the application teams sabotage the OS teams...

It hasn't changed! Except for PowerShell, but that's... oy.

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!!!

"Bash for Windows" is just WSL2 (forget WSL1 existed, as a proof of concept market validator it was good, but it has real issues because bridging NT -> Linux syscalls is hard.).

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.

I came from the Windows world to Linux. Especially when it comes to Enterprise, my experience is that Windows Admins are more likely to know network basics then Linux admins.

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

Windows has many ways to compose programs together, but usually the applications need to be designed to be composed together. The idea wasn't just to shuffle text around, but entire binary objects and shared state.

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.

Lots of FUD and misunderstanding going on there.

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.

GP is unfair in as you say, NT was a from-the-ground-up new OS based on VMS design without the single-user baggage of old DOS/Windows.

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.

Except for UNIXes like NeXTSTEP and Sun NeWS, as no other UNIX ever had any clue about GUI development, as Jobs used to say.

Unix was originally a single tasking OS, that's what the U is for