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

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.

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

Well gconf is hardly any better.

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.

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.

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.

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

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.

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>

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.