BUS1 Working On "r-linux" - A Rust Capability-Based Linux Runtime

[coder]

...

I'm not going to play this game of example and counter-example. It just distracts from the core issue, which is an increasingly monolithic and mono-cultural Linux userspace.

[oiaohm]

I'm not going to play this game of example and counter-example. It just distracts from the core issue, which is an increasingly monolithic and mono-cultural Linux userspace.

Except the reality is your statement about "increasingly monolithic and mono-cultural Linux userspace" is not as true as one would think. We have distrowatch data and the research that lead to the start of the Linux Standard Base project that said the same things. The Linux distributions in general(over 98%) for over 3 decades for the projects they have been built from at core are very mono-cultural.

The history of Linux is a poorly maintained highly monolithic and mono-cultural user-space for a majority of Linux distributions. Yes split up what was by majority of distributions deployed as basically monolithic block with unique individual version numbers is path to poor maintenance and lots of maintainer errors in distributions putting incompatible versions of parts out to end users.

coder you also have be very careful look at this history not to fall for false diversity. Yes lots of distributions offered multi init systems but in reality majority only sysvinit was configured to work out box somewhere near correct before systemd. You also find the same thing with sound servers and many other parts where there is a non functional diversity offered to end users.

Reality is even X11 servers on Linux distributions have been very monolithic in choice.

What systemd and wayland and other things in fact show is not that Linux userspace is getting more monolithic and mono-cultural because that was already the case that the Linux majority userspace has been monolithic and mono-cultural for decades but instead how under funded the less 5% of diversity the Linux world really has is. Yes thousands distributions have really masked how little diversity the Linux world has had for over 3 decades.

Hard reality here if you are going to the BSD with their central board models they in fact have less diversity than Linux distributions in their userspace make up.

coder like it or not about time us as Linux users take look at the Linux world and except the realities of it. Linux users like to make out that we are diverse bunch with our systems configured uniquely problem is in reality for a majority of things that not the case. We are far more monolithic and mono-cultural than most of us Linux users like to admit. Problem is the hard data collected by distrowatch and others exist that we can go and have a hard look in the mirror for what the Linux world really is.

This is part of the problem lot of people upset about systemd really have had an idealised idea of what the Linux world really is not the true reality. The true reality of the Linux world is over 2 decades of highly monolithic and mono-cultural user-space with maintainer-ship being poorly done for a majority of users and at some point that had to stop.

Yes coder you answer has straight up totally ignored what the reality was and is. Of course I understand it most people don't spend the time to look at the collected data by distrowatch and others to notice that their believed state of the Linux world user-space was not in fact reality for decades. The reality also explains why so many distributions migrated very quickly to systemd because the diversity did not exist for them lot of them the diversity did not exist from the day they were founded.

[lowflyer]

A crate full of rust?

[arQon]

Speak for youreself, I actually quite like GNOME and systemd.

Aside from you not obviously not even reading what I wrote, where I made no value judgement about either of those things, the whole point is that whether you *like* them or not *doesn't matter*. What does matter is that every time RH builds another piece of their empire, they tie it to all the *other* pieces so that you don't get to choose.

I think this might explain it in a way you can understand more easily:
You "quite like" GNOME and systemd. Imagine that Canonical owns GNOME instead. Now imagine that Canonical creates their own init system - we'll call it "Upstart". You don't like Upstart, and that makes Canonical sad because they think it's great and you're wrong. So they change GNOME so it only works if you boot with Upstart instead.
Now you have to choose: do you keep systemd and change to a new DE, or do you keep GNOME and switch to Upstart? Because you can't have both.

Does that help make it clear why this sort of behavior is a problem?

[coder]

Imagine that Canonical owns GNOME instead. Now imagine that Canonical creates their own init system - we'll call it "Upstart". You don't like Upstart, and that makes Canonical sad because they think it's great and you're wrong. So they change GNOME so it only works if you boot with Upstart instead.
Now you have to choose: do you keep systemd and change to a new DE, or do you keep GNOME and switch to Upstart? Because you can't have both.

Your scenario involves Canonical integrating them to force GNOME users to use Upstart, but it needn't be nearly so coercive. In fact, the more typical scenario is that someone like Ubuntu integrates them for the sake of convenience. They find some problem they can more easily solve by some degree of integration. Or maybe it's features they can more easily add to GNOME and/or Upstart, by such integration.

Maybe they even make such integration optional, but if you multiply that by many integration points, pretty soon decoupling them starts to become a complicated and fraught process. The more complicated or problematic it becomes, the fewer people do it, which leads to it becoming even more buggy and it soon becomes impractical to do. Eventually, maybe they stop making it optional, because it's extra work to do for some capability nobody uses.

[oiaohm]

Aside from you not obviously not even reading what I wrote, where I made no value judgement about either of those things, the whole point is that whether you *like* them or not *doesn't matter*. What does matter is that every time RH builds another piece of their empire, they tie it to all the *other* pieces so that you don't get to choose.

I think this might explain it in a way you can understand more easily:
You "quite like" GNOME and systemd. Imagine that Canonical owns GNOME instead. Now imagine that Canonical creates their own init system - we'll call it "Upstart". You don't like Upstart, and that makes Canonical sad because they think it's great and you're wrong. So they change GNOME so it only works if you boot with Upstart instead.
Now you have to choose: do you keep systemd and change to a new DE, or do you keep GNOME and switch to Upstart? Because you can't have both.

Does that help make it clear why this sort of behavior is a problem?

Lack history and knowledge.

I guess you are not aware that you can run systemd user mode without running systemd as you system wide init and the same with upstart.

Your scenario involves Canonical integrating them to force GNOME users to use Upstart, but it needn't be nearly so coercive. In fact, the more typical scenario is that someone like Ubuntu integrates them for the sake of convenience. They find some problem they can more easily solve by some degree of integration. Or maybe it's features they can more easily add to GNOME and/or Upstart, by such integration.

Maybe they even make such integration optional, but if you multiply that by many integration points, pretty soon decoupling them starts to become a complicated and fraught process. The more complicated or problematic it becomes, the fewer people do it, which leads to it becoming even more buggy and it soon becomes impractical to do. Eventually, maybe they stop making it optional, because it's extra work to do for some capability nobody uses.

Both of you need to know history.

Canonical with upstart and unity windows manager..

https://gitlab.gnome.org/GNOME/libgtop/-/issues/14

The reality is users asked for upstart integration well before systemd integration happen. Ubuntu developers did trial upstart with unity window manager it did not turn out good. The problem is upstart choice to ptrace instead of using cgroups turned out to be highly harmful.

Also gets better the first prototype of gnome session manager being replaced by systemd was in fact done by Canonical Developer not Redhat one this was also the same developer who did the unity/upstart hybrid to find this did not work. If events had been different where upstart was not a functional disaster gnome would most likely be intergrated with upstart and systemd would not exist.

https://en.wikipedia.org/wiki/Upstart_(software)

Note Fedora 9 was using upstart. Early version of systemd for gnome and upstart for unity both had the idea that you system wide init system could be different just you would need systemd/upstart user mode for the session management.

Reality here it was not Redhat developers who pushed for the systemd integration in gnome first. In fact redhat developers were stubborn at first that they would just work out way to fix the gnome integrated session management only when this comes that they would basically be duplicating systemd user mode did the the systemd integration come supported from the Redhat Developers..

You have to remember systemd being core used by gnome only comes mainline in 2019 there were lots of debates before this.

coder and arQon you have ignored how complex Gnome and KDE session management has been under Linux. Desktop environment session management has been a very fragile process due to the PID and PID tree handling of the Linux kernel.. Yes this is why I was able to pull up open bug from 13 years ago asking for upstart integration by users there are more requests that were closed that were lost when gnome migrated to gitlab in 2018.

coder and arQon there is a real functional problem that is the driving force behind the gnome/systemd and kde/systemd intergration.that this integration systemd solves on Linux. Do note the old session managers of gnome and kde do work very well on BSD kernels that don't have the PID recycling problem and the PID tree means to delete relationship to parent process.

Linux kernel behavour is not without it problems. Yes there is always the incorrect presume that Redhat pushed for systemd integration in gnome and kde. History has Canonical developers pushing for systemd integration into gnome and Suse developers pushing for systemd integration into KDE. Both point to the same Linux kernel fundamental problems as why this change has to happen.

The force behind the usage of systemd by KDE and Gnome is a fundamental problem with the Linux kernel handling of PID(process id) and PID tree(tree of process). Major reason why commerical distributions of Linux were willing to try stuff like upstart and moved to systemd so fast is the same fundamental problem. Yes this fundamental problem is why sysvinit really was a round peg square hole problem on the Linux kernel.

Gnome and KDE design of session management prior to them starting to move to systemd or upstart was in fact based on CDE and other older X11 DE that happened to be used on Unix systems without the fundamental problems of the Linux kernel. Yes lets be cross platform/posix compadible lets forgot that Linux kernel has some very unique defects so have users have increase instability on Linux when using desktop environments was the result.

Hard reality here the problems systemd is designed to solve with PID/PID trees don't exist on the BSD or minix based operating systems.

Another hard reality is majority of the init/service management/session management options that people made over the years were not designed to work with the Linux kernel limitations. Worst majority did not even attempt instead said their code bases had to be cross platform/posix compatible so they could totally ignore kernel level issues. This lead to hacks on top attempting to work around the issue that did not work right and could never work right. Systemd developer remember caused cgroupv2 to be added and Linux kernel to finally get pidfd support by demoing the broken state of the Linux kernel.

Now this story repeats with X11 WM managers hacking around limitations of X11 protocol instead of working together to either extend X11 or develop shared dbus protocols. Basically ignoring the fundamental problems of the core part. Yes main excuse again for this behavour cross platform support.

It scary when you know really how monolithic the designs of gnome and kde session management really even prior to systemd change lot of people would not be aware they start off the same reference designs. KDE and Gnome changing to systemd mostly means instead of having two broken clones of the same thing we have one shared implementation. Yes xfce and other X11 DE have to implement their own session managers that is basically equals another broken clone of the same thing.

Good question why did no one develop a shared session manager and put it in the x.org project thinking that every X11 DE end up having to remake this same wheel?

[coder]

Both of you need to know history.

Canonical with upstart and unity windows manager..

Relax. It was just a hypothetical scenario.

[oiaohm]

Relax. It was just a hypothetical scenario.

Thing was arQon wrote it as a hypothetical scenario but with unity and upstart if the combination had worked it was not going to be hypothetical. Canonical due to this being a fix issue end user usability they were think of making using upstart as DE session manager as requirement to a Ubuntu flavours.

If the ptrace method of upstart had not failure things would have turned out very differently. The PID/PID tree problem of Linux would have been solved differently.

There is a lot of integration that traces straight back to the core Linux kernel issues. There are a lot of other issues around session management as well. Logind comes about due to limitation with the old consolekit and was first developed as a consolekit feature.

The reality every bit of integration between gnome and systemd .starts before systemd exists either with the proto code of upstart doing things or prototype patches to consolekit. All attempting to address real problems.

logind was to reduce the amount of code that every X11 DE had to implement individually. The session management usage of systemd is also about reducing the amount of code that has to be uniquely written. This is to reduce bugs and maintenance.

decoupling them starts to become a complicated and fraught process.

Remember you wrote this. Turns out this had already happened before systemd existed. The existing session managers of gnome and kde before systemd were already a complicated and fraught process. Yes KDE and Gnome to start a user service by their session manager required unique code for KDE and Gnome so do all the X11 DE with a session managers so now you are need to do your session service scripts x the number of DE you wish to support. Fragmented and complicated process already existed. This is why Canonical developers attempt to change over with upstart/unity and then pushed systemd/gnome because there is already a horrible complicated and fraught problem at the location of desktop environment session management.

Yes removing systemd with all the different things it provides is not simple. But coder you have overlooked the other side. Reinventing the wheel over and over again as what was happening with sysvinit to work around issues or with how to connect to login managers or how to manage DE session also has the effect of making the system a complete and fraught process.

Reinventing the wheel over and over again splits developer time so result in not enough developer time to do basic maintenance so you end up with a buggy mess. Yes this lead to key parts of sysvinit in fact having the developer of that section dead(really dead in ground) for 3 years without anyone noticing.

coder the starting point was in fact a buggy mess all the major commercial distributions started getting really worried about session management and service management after the fact about the developer being dead in fact came out. Centralising a stack of single developer projects under systemd means you now have more developers working with each other so better odds that if something bad happens to one of those people someone notices.

There are serous problems with what was happening before upstart started and what systemd was also about addressing. Yes what systemd did merge all the projects under one project has put the under 5% doing different stuff noses out of joint but those parties were also not looking at the big picture for what was the issues the systemd developers were attempting to address.

Yes admitting to the Linux kernel PID/PID Tree issue alone mean that many of the attempted init/session management solutions that existed before systemd for Linux should have been straight up scrapped because they could not work because they are not Linux kernel compatible. Yes admitting to the PID/PID tree issue also means that the X11 DE session management solutions used prior also need to be scrapped as they were not Linux Kernel compatible.

coder people need to remove the rose colour glasses and look back at the mess that existed. Lot of this is like saying go back to the 1990s kde and gnome for better sound support and finding the fragmented sound server mess. Yes it was simpler in 1990s to have a different sound server but it was not simpler to have all the applications you wantted to work to work. Lot of the complaints about systemd align with lot of the complaints about move to pulseaudio.

Pulseaudio has not been idea but over all its been better than the priors. Of course now pulseaudio is being replaced with pipewire without anywhere near the mess. Why without as big of mess is because the majority got to using the same design wheel.

Reality is long term systemd and pipewire domination both will make them simpler to replace in future without causing user distruption than replacement of the fragmented messes have been. Of course the barrier to entry is higher now stuff is expected to work as a complete solution. No more we alter this small bit over here and break like half the applications.

Remember systemd make it simpler to replace sysvinit by having a compatibility layer to use existing sysvinit files. pipewire replaces pulseaudio by having a compatibility layer. Openrc and runit both don't have compatibility layers to import and use systemd service files.

See the change people needed to stop going and just reinventing new wheels without any compatibility with each other. The prior process was not making working solutions instead creating fake diversity. Making compatible solutions that can provide true diversity to end users is harder.

[coder]

...

The longer your posts, the shorter my replies. If it takes you 1000 words to make your point, maybe it's not as solid as you think?

[sinepgib]

Its not just the fact of creating the standards after the fact. POSIX there was a problem that people were demanding that service managementsystems and other things be done conforming to POSIX even that it did not fit right. Shell script how many people would say that sysvinit scripts had to be 100 percent posix shell script compatible lots in fact. This is big problem this stops work on fixing the platform problem when the problem is also mirrored in POSIX due to being created after the fact.

Just a nit, but expecting boot scripts to be POSIX has little to do with platform neutrality and much more with shell neutrality. Using POSIX means it can run on busybox on embedded or in Dash for closer-to-decent performance, rather than just Bash.