OSDev.org

Hello,

almost a month ago there was a global outage on windows, but especially on servers. It still fascinates me why Windows is used as a server at all, but that aside.

I've always been a fan of working only in the console, it makes things easier and clearer.

But the outage got me thinking, why isn't there still a small, respectable operating system that is only suitable for running on servers?

When I started out in software development over ten years ago, I always thought that servers mostly worked with such systems. More code leads to more errors and errors are an absolute nogo, especially on servers, where millions of customer data are stored.

So why not just linux? Here, too, it is usually the many components that lead to security gaps. (how many times has there been a privilege escalation gap)

I've always been very interested in kernel development and now I have a use case, so I wanted to ask whether my idea is too utopian or realistically feasible.
An operating system without Gui, without graphics drivers, ect. Only terminal. It should be able to process requests, protocols that should be supported: ssh, ftp, http(s). Also a rights system that I would orientate very much on Docker, rights must be given explicitly, to other programs, as well as to the file system. For the file system ext2? Also only standard commands known from Linux.

In my rather inexperienced eyes, this should be theoretically feasible. I program mainly in C#, but have also learned C. Can C# also be used as a language for something like this or is it better to go with C / C++? (purely from a performance point of view)

Please be honest, on the one hand I would be interested, as I have never dived that deep into systems and think every developer should do so, on the other hand I don't want to throw myself into a mountain of work and do nothing else for the next 30 years.

Thanks for your time reading this

xfluq wrote: ↑Wed Aug 14, 2024 3:49 pmCan C# also be used as a language for something like this or is it better to go with C / C++? (purely from a performance point of view)

From a performance point of view, language doesn't matter. Performance depends on how good you are at choosing algorithms and how good your compiler is at optimizing them.

xfluq wrote: ↑Wed Aug 14, 2024 3:49 pmI don't want to throw myself into a mountain of work and do nothing else for the next 30 years.

Then don't?

Octocontrabass wrote: ↑Wed Aug 14, 2024 9:15 pm

xfluq wrote: ↑Wed Aug 14, 2024 3:49 pmI don't want to throw myself into a mountain of work and do nothing else for the next 30 years.

Then don't?

What I meant with that, is it realistic to archive something like that in a timespan of like 3-5 years, and then make other integrations, ect? Or is it to uptopian?

xfluq wrote: ↑Wed Aug 14, 2024 3:49 pmSo why not just linux? Here, too, it is usually the many components that lead to security gaps. (how many times has there been a privilege escalation gap)

If you want to be actually realistic, then you do have alternatives. For instance, I use Alpine Linux as a base for a host OS, as an hypervisor for containers. Minimal footprint, zero accessibility from outside a management VLAN. On top of it, I mostly use Alpine Linux images in LxC containers, with the services isolated in different containers. Not docker, but LxC, as I feel it gives me a lot more flexibility. Only the containers can be accessed from the production or development networks, depending on the services they're running, and containers holding web-oriented services are never directly exposed, for example, they go through an NGINX proxy container to isolate the access to certificate keys.

Doing it this way has some advantages:

• the possibility of some security by isolating processes while keeping hardware costs down, because the only way to truly remove the possibility of escaping containers or VMs is to isolate the services in separate machines. Which is frequently unfeasible;
• reducing the chances that an update or any catastrophic problem in one service will render a lot of services unusable, because the host system has so little footprint that the need for updates will be less frequent per installation (not in the global sum of the system), as with all the containers, but if a service has problems, theoretically only that container will suffer downtime (except when there are dependencies between containers);
• reducing downtime with updates - also because of the small footprint, only containers that actually have updates might need to be rebooted or have their services restarted, hence reducing total downtime.

This actually works so well that I've productized it and it's now in production in several installations, on top of JFS partitions (which is the one that's been working best for me, as I find it to be much more stable than EXT4/3/2 and BTRFS and definitely deserves some love).

Doesn't mean that there isn't market for something new, but if you're looking for such a high level of compatibility, you could try the top-down approach instead of a bottom-up approach. Instead of starting with the kernel, start with the userland by gradually replacing the components you deem insecure with newer components, or refactoring those components to become more secure. Then you can go down the rabbit hole until everything is either replaced, refactored or confirmed secure from origin (huh, like that's ever going to realistically happen, lol).

xfluq wrote: ↑Wed Aug 14, 2024 3:49 pmIn my rather inexperienced eyes, this should be theoretically feasible. I program mainly in C#, but have also learned C. Can C# also be used as a language for something like this or is it better to go with C / C++? (purely from a performance point of view)

What I said doesn't even mean that you need to use language A or B because someone jumped on the marketing/trend bandwagon and want to look hip. You can stick to C, C++ or whatever, as long as you're careful and really get to know the language. Modern C++ isn't the devil that a lot of people in other communities try to say it is, causing a lot of companies to panic. The problem aren't the languages, it's the people. Regardless of the language, if you're meant to break something, it will happen. They ways might be different, the risk is always there, because the code is made by humans and you can be incompetent in any language. But I may just be old school and think that everyone should learn to ride a two-wheel bike instead of sticking to a bike with training wheels all their lives.

Thanks for your response, yes I also worked with the alternatives and that's the point, resource isolation and rights restriction are the best we have, in terms of security. Then virtualize the full package separately and that's it.

I know I am also just a human, but why can't there be an os that I can use and that I can rely on its safety?

Linux is a lot better, but in my opinion there really isn't an os for servers that I can simply install and say yes, it will work and there won't be any security gaps.

More code leads to more gaps, that's what I thought about as an approach - just do what's absolutely necessary and nothing more.

I would also like to develop something like this purely for the experience, but I have to get an accurate picture and not just start blindly. I have already learned from such projects in the past. From an it will take 3-6 months can very quickly become years.

The question for me is? Am I trying to develop something realistic or something utopian?

Without a team, resources and the proper prior knowledge that allows you to decide on an architecture that does not make the errors everyone else before you made? I think you know the answer. But if you take the top-down approach, you may have a shot.

If your aim is to learn about OS development then go ahead.

But, if your aim is to produce a totally secure OS in a matter of months or years, forget it. You can’t possibly know about all potential flaws, in particular what unknown flaws might exist in various processors.

Just install OpenBSD and stop worrying.

Thanks for your responses, yea you might be right, writing an own kernel is like reinventing the wheel, I might just start with Linux kernel and write code in top of that.

xfluq wrote: ↑Fri Aug 16, 2024 6:14 am Thanks for your responses, yea you might be right, writing an own kernel is like reinventing the wheel, I might just start with Linux kernel and write code in top of that.

I tried this once, and ended up with a system which refused to unmount root on every other shutdown. Granted, I wasn't exactly coding, I was assembling a minimal set of binaries and scripting them together, but it was frustrating to have just got a minimal system together only to find I'd have to do it again with differences to create an initrd. My previous experience with Linux From Scratch was over 15 years earlier, in the days before an initrd was required. Now I recall another time when I did try creating an initrd, but that was when Linux had this pivot_root mechanism which hardly worked at all; it was a nightmare!

I'm really writing this to say, "@xfluq, please please PLEASE stop with the Linux already!" I can see you're following the same path of belief and struggle that I did, and want to encourage you to hasten down the path of disillusionment! Having fallen for GNU propaganda and general Linux enthusiasm, I Truly Believed In Linux, and it was a terrible mistake. I'm not messing about when I say it was the worst choice I could have made for my purposes. I would be a much better programmer today if I hadn't wasted my time and energy grinding away at Linux. Granted, Linux libraries and documentation are much better now, they were far behind commercial development packages in my day, but Linux is incentivized to have problems. When some problems are fixed, others appear.

Linux development is largely supported by selling support contracts. Thus, its in the interests of these developers to make sure Linux needs support — to introduce subtle and insidious difficulties which drive system owners to buy support contracts. This results in Linux being the hardest system to administer and in it continuing to be difficult despite innovation.

Is the kernel exempt? Well, Linus Torvalds characterizes himself as "The corrupt and lazy bishop to Stallman's messiah," so I don't think so. Besides, I remember the udev fiasco. When Linux needed dynamic device nodes, devfs was developed. It was beautifully easy to administer, but Linus Torvalds rejected it, saying "No policy in the kernel." Instead, we got udev which almost every sysadmin I've spoken to has absolutely hated! Especially when it was new, and amongst admins who remembered devfs. mdev is nicer than udev so maybe you could use that, or you could use a BSD kernel with its own devfs, or code your own, of course. I don't think static dev nodes are a good idea any more, depending on the hardware.

Or you could find a good existing server OS. A few years ago, a sysadmin with a taste for older OSs surprised me with a little bar chart charactersing OSs by admin dificulty and how much admins were paid. Windows was less than half the difficulty of Linux for maybe 3 times the pay. VMS was far less difficult still, and you got paid a lot!

So, OSs:

Windows as a server: NOT insecure, especially if administered correctly. That myth needs to die already! It's currently reckoned to be more secure than Linux, with Linux presently holding last place in the security rankings of major OSs. (I'm really only listing Windows to highlight that.) As mentioned, it's easier to administer than Linux, though that may be changing as Microsoft is rumoured to have moved to more of a pay-for-support model like the one which has so harmed Linux.

VMS, OpenVMS: This may be the server OS you're looking for. As mentioned, it's very easy to administer. It was traditionally a multi-user OS supporting X Windows, but I doubt it was ever optimized for games. There's much need for driver development as it has only recently been ported to modern hardware: An amd64 port was released in 2020. Good if you want to develop drivers or run old hardware - MicroVAX. I wonder if drivers to run as a VM guest might be done already.

Plan 9 From Bell Labs: Extremely easy to administer! This one I can verify. Everything is scripted in simple but fairly powerful scripting languages. To install a new network service, you add a script to /rc/bin/services. Designed to run many machines from a single fileserver, servers have a different init script and run in somewhat of a different mode to 'terminals', though the distinction is small on modern powerful hardware. Supports optional per-machine init scripts too. The authorization server is designed to run on a separate machine, physically isolated from attack. Has been audited for security in the past, though I suggest checking the wiki and asking on the 9fans mailing list if you're concerned. Not very compatible with any other OS, you need to be a programmer to get the most out of it. If you've seen me complain about it, I mostly complain about the user end of things and about how it's not so easy to create Plan 9 services with Plan 9's virtual-file interfaces, and I don't really like creating very complex scripts in those little languages. That's why you need to be a C programmer, though there is a Python port too. You can script it in any language via the plain-text virtual file interfaces.

OpenBSD: One of the easiest Unixes to administer, though not nearly as easy as Plan 9. Obsessed with security. Includes quite a lot of server and some user software, all of which is audited for security. Includes the nginx web server, I've never heard a bad word about nginx, not even from Plan 9 fans.

@eekee I think you're missing a few important aspects. First, that there are several (in the thousands) distributions. And a lot of them are quite similar, true, but a great deal of them manage to escape the trends. And on the Linux ecosystem, Linux itself is a kernel, and GNU is the userspace. But not for all distributions. I don't have any love for the GNU userspace, although at the moment it's more like a necessary evil and less bad than going back to Windows. However, Alpine Linux, as I suggested, at least partly avoids that. It uses MUSL instead of GNU's GLibC, and OpenRC instead of SystemD. Much of Alpine Linux's userspace avoids anything GNU.

Also, I'd definitely want to see proper independent and impartial sources for your statement that Windows is recognized as more secure than Linux. As for ease of administration, that's highly subjective. Me, and anyone else around me, have the exact opposite opinion while being experienced in both. Besides, the closed nature of Windows devoid it of the levels of malleability and customization that are possible with Linux, especially a distribution as simple and bloat-free as Alpine, which can be fully functional in about 300MB for bare metal or 8MB on a container. A typical minimal installation of Windows takes no less than 20GB-40GB. What for? None of the functionality that Windows provides in a base installation justifies that.

Much of my opinion on the difficulty of Linux comes from a sysadmin who was, amongst other things, an Alpine Linux user. He appreciated it but still preferred OpenBSD. On his personal computers, he only used Linux on his laptops where OpenBSD drivers weren't good enough.

That guy was the most vocal one of our group, but we had a consensus which didn't change very much at all. We took great interest in the arrivals of Musl, various init systems, and minimal Linux distros, (most notably Alpine,) but none of these were good enough to put any form of Linux on a par with OpenBSD.

As for myself, I tried various Linux distros over a 13-year span and had trouble with all of them. The simpler the distro, the harder it is to try different software. I found innovative software was without exception developed on and for complex distros.

Windows administration wasn't really part of our consensus. It was only mentioned by one person, once, in the comparison with VMS and Linux which I described. I can't remember how long ago that was, I can understand that it may have become much more difficult if Microsoft has changed its business model. It's certainly not suitable for such a diverse range of uses as Linux, but note that the OP wanted an OS which was not trying to cover so many bases.

I should add here that I've grown very wary of judging code by its size. I've made many poor choices out of a desire to avoid bloat, often ending up with programs which were poorer-quality, slower, and/or outright unsuitable for my purposes. Windows' 20-40GB still seems like a lot, but I'm sure the causes are not as foolish as one might think.

It's possible that Plan 9 covers too few bases. That's why they say you should be a programmer if you want to use Plan 9, though I and another guy were able to run web and other basic tcp services easily without C programming. I wrote a web server with vhosts and cgi, he wrote a bbs, all in Plan 9 scripting languages. It has its own httpd besides this, though it doesn't natively support CGI. Someone wrote execfs to supply dynamic content to httpd.

I don't have an authoritative source for my Linux/Windows security claims, but I want to counter the pernicious myths of Linux security. The myths got started in the 90s when typical Linux servers were just as insecure and infected as typical Windows desktops. Where Linux has made improvements since, so has Windows. Add in the difficulty of maintaining Linux, and I can well believe the average Linux server today has fallen behind the average Windows server. When I heard, within the last year or so, "Linux is the least secure OS," it made sense to me.

eekee wrote: ↑Thu Aug 22, 2024 3:19 am Much of my opinion on the difficulty of Linux comes from a sysadmin who was, amongst other things, an Alpine Linux user. He appreciated it but still preferred OpenBSD. On his personal computers, he only used Linux on his laptops where OpenBSD drivers weren't good enough.

That guy was the most vocal one of our group, but we had a consensus which didn't change very much at all. We took great interest in the arrivals of Musl, various init systems, and minimal Linux distros, (most notably Alpine,) but none of these were good enough to put any form of Linux on a par with OpenBSD.

So, your only source is the report of a single person? That's far from significant. I have learned, early in my life, that one single opinion is not enough, as the human mind is highly vulnerable to several types of cognitive bias, including imprinting on the first opinion. My relatively long personal experience, which is far from anecdotal, with several flavors of BSD, countless versions of Windows, and countless versions of several Linux distributions (and DOS, QNX, MacOS, ...), as well as the experience of everyone around me, a lot of them having built successful businesses either as Linux users or Linux providers (as in providing services or software based on, or running on Linux), couldn't be more different from what you report.

eekee wrote: ↑Thu Aug 22, 2024 3:19 am As for myself, I tried various Linux distros over a 13-year span and had trouble with all of them.

Unsurprising, unremarkable and expectable in every system, not just Linux. For every single system and for every combination of OS and hardware it will be a case of YMMV. For instance, there's a lot of hate for Vista, that it was slow and unstable and I've had one single bluescreen with Vista in 10 years of running it almost 24/7 and I actually enjoyed it (and it worked like a breeze as soon as Themes and Superfetch were turned off). This is not fully deterministic. There are distributions more problematic, others that are more stable. Sometimes is a case of a specific version. Again, as with every single system out there. Systems are made by humans and, as such, will be vulnerable to being plagued with errors because humans are not perfect.

eekee wrote: ↑Thu Aug 22, 2024 3:19 amThe simpler the distro, the harder it is to try different software. I found innovative software was without exception developed on and for complex distros.

This is highly subjective. It depends greatly on what you're looking for and what your use case is. In terms of Desktop Environments, I'd agree with this for Gnome and KDE, as they are both falling prey to dependency hell. But even for the Windows based software for which there is no viable counterpart available for Linux, nowadays, with the levels of compatibility achieved by WINE and Proton, that point is becoming moot. The only reason I still kept a Windows machine around up until a year or two ago (and it was 8.1) was because of Far Cry 4. That machine has now been repurposed, as FC4 now runs flawlessly on Proton. Also, don't forget that the investment that Valve made in building Proton from WINE is paying off big time and is positively influencing other non-gaming applications as well. Last year alone, Linux doubled market share and today it sits at 4.45% if I'm not mistaken, based on recent news. And that's not counting Android Phones and all the embedded devices and appliances out there that are running Linux and we don't know about it. If we're counting that, I think the only OS that comes close to that is MINIX, as it's embedded into Intel's ME. Once more, Linux is far from perfect, but if millions of users and countless companies are trusting it not only for production but also for integration in their products, it can't be that bad...

Please note that I'm not trying to say Linux is the best, or that I love Linux more than anything else. Far from it. What I'm trying to say is that the reasons you stated to dislike it don't fit, not that there are no reasons to dislike it. Believe me, there are plenty, but then again, so is the same with every single system. In the end, it's going to be a case of which problems do you tolerate more.

eekee wrote: ↑Thu Aug 22, 2024 3:19 am Windows administration wasn't really part of our consensus. It was only mentioned by one person, once, in the comparison with VMS and Linux which I described. I can't remember how long ago that was, I can understand that it may have become much more difficult if Microsoft has changed its business model. It's certainly not suitable for such a diverse range of uses as Linux, but note that the OP wanted an OS which was not trying to cover so many bases.

Again, one single person is not enough to establish a pattern. These are not facts, and such a matter is something highly subjective that needs a consolidated pattern to gain meaningfulness. By the way, Windows as it's known today (NT based), was built with roots on VMS, a fact which seems to not be known by many.

eekee wrote: ↑Thu Aug 22, 2024 3:19 amI should add here that I've grown very wary of judging code by its size. I've made many poor choices out of a desire to avoid bloat, often ending up with programs which were poorer-quality, slower, and/or outright unsuitable for my purposes. Windows' 20-40GB still seems like a lot, but I'm sure the causes are not as foolish as one might think.

As a former Microsoft employee, I feel confident I have sufficient insight to comfortably disagree with you in the specific case of Windows bloat. Not that I will (or am allowed to) share it, but I'm confident.

eekee wrote: ↑Thu Aug 22, 2024 3:19 ambut I'm sure the causes are not as foolish as one might think.

And this just sounds like... speculation... and you didn't even offer a theory that could be considered a reasonable explanation. It's hard to take this serious, as well as the occupied size, when that contrasts with every other operating system in use. Keep in mind that it's 20-40GB for the base system, not a complete desktop with tools, games, productivity suite, graphics editors and etc. Windows has, in the past, occupied much less than that while doing... about the same as it does now? Or at least about the necessary same? Can you honestly tell me that the base installation of Windows 10 or 11 provide you with a reasonable increase of actually useful functionality (not gimmicks) for an end user, over, let's say, XP or 2000?

eekee wrote: ↑Thu Aug 22, 2024 3:19 amIt's possible that Plan 9 covers too few bases. That's why they say you should be a programmer if you want to use Plan 9, though I and another guy were able to run web and other basic tcp services easily without C programming. I wrote a web server with vhosts and cgi, he wrote a bbs, all in Plan 9 scripting languages. It has its own httpd besides this, though it doesn't natively support CGI. Someone wrote execfs to supply dynamic content to httpd.

I will not (and have not) comment on Plan 9 directly, as I do not have any meaningful experience with it, but I can speculate. The only thing I have at my disposal are previous opinions from articles (probably from El Reg, but can't be sure) about how hard it was to deal with Plan 9. However, I understand from what was reported that it's a different paradigm, so I reckon that lack of familiarity - rather than actual difficulty - might have been a key factor in those opinions. Again, I can only speculate, based on one thing which is that there is no such thing as intuitivity, only learned behaviours - "The only intuitive interface is the nipple, everything else is learned." - Scott Francis (probably) (and yes, I know that quote is an exaggeration).

eekee wrote: ↑Thu Aug 22, 2024 3:19 amI don't have an authoritative source for my Linux/Windows security claims, but I want to counter the pernicious myths of Linux security. The myths got started in the 90s when typical Linux servers were just as insecure and infected as typical Windows desktops. Where Linux has made improvements since, so has Windows. Add in the difficulty of maintaining Linux, and I can well believe the average Linux server today has fallen behind the average Windows server. When I heard, within the last year or so, "Linux is the least secure OS," it made sense to me.

As a user of many OSs and with varying levels of experience in both administration and development in a lot of them (including Linux, Windows, QNX, MacOS, Android and DOS), and as a direct observer of an entire ecosystem that deals with any or many of them, I also have to disagree. On the other hand, not that I'm defending open source, as I'm completely agnostic to licenses as long as they're not abusive or immoral, but it is possible that the opinion you heard was based on a CVE count or something. A higher CVE count DOES NOT mean a more insecure operating system. It means exactly that: that more problems were reported, not that more problems exist. There's a very distinct difference between problems that were found and problems that exist. The open nature of the Linux ecosystem means that the code is auditable by anyone with the skills, therefore making it easier to find problems, which also means that those problems can be corrected sooner, as it is the case.

I also read on your previous post about your experiences with Linux From Scratch. I've done it plenty of times, usually do it every two years for personal uses, and I also use it as a teaching tool. I haven't built a kernel in a while, but last I checked, having an initrd was not mandatory. If you build your own kernel (which is a possible path if you use LFS or distributions like Gentoo from Stage3), you can opt out of initrd altogether. In fact I've frequently customized the kernel even in distros such as Ubuntu and the like to make sure I would not need initrd or even Grub (by using the EFI stub to make the kernel directly loadable by UEFI), shortening boot times.

I won't say Linux, or the Linux ecosystem is perfect. It isn't. I have my own technical/personal reasons to dislike it, hate it, whatever. But from my point of view, your arguments seem to have no substance at all. They paint you in a light of needing to hate Linux at all cost for some reason, rather than being sustained reasons. Even this:

Linux development is largely supported by selling support contracts. Thus, its in the interests of these developers to make sure Linux needs support — to introduce subtle and insidious difficulties which drive system owners to buy support contracts. This results in Linux being the hardest system to administer and in it continuing to be difficult despite innovation.

If this is true, how is it different from ANY other system, solution, software, hardware, business model? How's it different from what Microsoft does? I'll tell you the difference: in the case of ecosystems such as Linux and other open operating systems, those support contracts are less about problems, and more about fulfilling specific use cases, integrations or development of specific features. As for your reference to udev, I won't comment on it for now - even though I have interacted directly with it in the past, I don't think I've had a sufficient amount of interactions to either agree or counter your arguments on it. So far it just worked.

So is Linux perfect? No. Do I love it? Definitely also no. But:

1. Is it a viable tool for professional purposes?
2. Is it a good learning experience?

The answer to both questions, which in my view are the fundamental questions for this thread, is: yes. For professional purposes, the World itself is proof of it.

Are there security flaws with it? Sure. Are there systems running Linux that have security flaws? You're God damn right there are. But, are ALL those flaws attributable to Linux, or are them, or at least a sufficient volume of them, attributable to the software running on Linux which would display the same flaws if the underlying system was different, like, OpenBSD, Windows, or whatever?

As for the learning experience, not only the ecosystem enjoys a great deal of relatively acceptable documentation (even when faced with BigBuda's first law of documentation: "When it comes to documentation, first it has to exist, then it has to be correct, then it has to be up to date. From those three, choose half of one."), and a community with balanced weights of people willing to help and share knowledge and those who hoard it. And, besides, it works as one hell of a gateway drug to exploring other operating systems and learning enough about the differences between different ecosystems that it helps the mind creating generalizations that allow for fast learning of new/different systems.

As for ease of administration, I can't for the life of me imagine in any way how can Windows be easier to administer. Just because the default is point and click? Not in my book. But then again, it's something highly subjective.

Source: documentation, articles and personal and professional experience (obtained and shared) as user, administrator, developer and teacher.

Religious wars never end well.

Each to their own.

iansjack wrote: ↑Thu Aug 22, 2024 11:55 pm Religious wars never end well.

Well, maybe in this case I ought to declare my loss. I'm still not entirely comfortable with Linux, but I've got to admit my opinions weren't based on the strongest possible reasonings. I've been reconsidering as I wrote all this below.

@BigBuda, I respect your experience, but I don't know how you got, "your only source is the report of a single person" from "we had consensus." Perhaps I should have made the situation clearer. Several of us found Linux excessively hard and BSDs less so. But it is notable that the more competent and capable programmers complained less about Linux. As for me, I've recently had to recognize that I'm not as good as I thought. I thought I knew what I was doing because I understood a lot of concepts, but it turns out that actually applying those concepts makes my head spin. Reading our wiki's Required Knowledge page the other day, it hit me that while I can talk about "data structures, their construction and manipulation" all day, actually designing a good data model always ends up in trying to think about too many moving parts. This is why I wrote, "competent and capable programmers", and I've put certain things to practice on my to-do list.

Plan 9 appeals because it appears to be built from very few very simple concepts, but I remember now, as I got deeper into using it, I saw that it's not as simple as it seems. Its interfaces are supposedly 'plain text', but the 'plain' part is, for my purposes, misleading. Each interface wants text structured in its own way. You can use these interfaces in a basic way with echo and cat, but more interesting uses mean mucking about with sed and awk instead of proper binary tools. (This is why Kaph will have something like a common object model.) Perhaps I should write all this down somewhere I can easily find it, because as it is, my frustrations with Plan 9 slip from my mind as they were less acutely painful than my frustrations with Linux.

I guess my conclusions about the relative security of Windows and Linux also weren't amongst the best bits of reasoning I've ever done. @BigBuda, your opinion makes sense and it looks like you have the experience to back it up. I have heard some horror stories about Linux security, but they all date from a long time ago now. Recently, my desire to spread my opinion was strengthened by some twit declaring Linux to have been "designed from the start for security." It's not the first time I've seen this opinion. File permissions and chroot impress some newbies, perhaps Dunning-Kruger syndrome gives them confidence, and of course it's very tempting to just believe that you have security, denying evidence to the contrary. I should just tell them that Windows is 3 different OSs and the one we've been using since the early 00s was "designed from the start for security."

I'm still not happy with the economics of Linux. Early in my Linux use, (1999 or 2000,) Red Hat kernels were patched to specifically fail to network with Windows. I was in love with Linux at the time, knew it powered the majority of web servers and, like many people at the time, I believed it was *the* choice for networking. Also, Microsoft's extremely unethical behaviour was well-known at the time, and saps like me didn't understand this was normal in the software industry. Thus, as Red Hat no doubt knew many techs would, I blamed Windows.

At the same time, I was very frustrated trying to understand Red Hat's init scripts. I did what i could to improve my shell script skills, and still struggled. In 2001, I got SuSE Linux and found its init scripts much easier to understand, supporting the notion that Red Hat were trying to get businesses by making things harder. It also supports the argument that you can have an easier Linux by changing distros and for many years I tried, but I never got very far. After giving up, I watched from a position of disillusionment as the majority of Linux users and distros enthusiastically adopted PulseAudio Dbus and SystemD. Two were presented with flagrantly false claims, one was criticised by leading computer scientists. All were written by Lennart Poettering who was employed by Red Hat, strengthening my opinion.

But again, I ought to consider how I failed to take advantage of all the tools available to me. For instance, disliking Debian, I didn't even want to look at run-parts. I also couldn't figure out how to code what I needed. Perhaps this was due to my devotion to shell script. I made a start on Python coding in the early 00s, but it got dropped when the social side of my life started to take all of my time. Perhaps the OP's plans of a fresh userspace might be just what Linux needs.

Exactly the plan for my BareMetal kernel.