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

[oiaohm]

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?

Read the posts or do I have to post the 4000 page history document of these events Included the detailing of the Posix design flaws.

[oiaohm]

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.

There is a problem. https://www.baeldung.com/linux/pid-file yes person wrote this in 2021 and its wrong. Guess what .PID files don't work correctly on Linux and did not even in 0.1 Linux kernel this is a day 1 design issue.

https://securitylab.github.com/research/ubuntu-apport-CVE-2019-15790/

Its covered in this security bug. Linux kernel does PID recycling. POSIX standard for writing scripts presumes PID will not be recycled. This is why POSIX standard for scripts has putting PID value into .pid file as a valid action. Reality pid value in a .pid file is to be totally no trusted without some means of secondary checking. Secondary checking does the PID own to the correct cgroup of course that means you had created cgroups when you started the service.

The reality is posix standard script does not include anything for processing tracking that in fact works correctly with the Linux kernel. PID value shoved into a .pid file works on many Unixs due to restrictions on PID recycling. Now PID tree issues of Linix I could give security bugs on that. Yes so you terminate pid of a service you only kill part off it as part of it as disconnected it self from the pid tree so no longer look like it was started by the service.

My posts have started pid issues and pid tree issue over and over again. PID recycling feature of Linux has lots of dangers this is the PID problem. The means to remove relationship between two PIDs that Linux supports the PID tree breaking feature also has lots of dangers this is the PID tree problem.

You restrict yourself to either the POSIX define API for C or the POSIX define shell script language you find yourself unable to correctly manage services under the Linux kernel. We are talking over 5000+ documented CVE here effecting lots of different services. Yes there code presumes Linux kernel in Posix conformance when the Linux kernel is not resulting in a security bug.

At some point you have to admit up to the Linux kernel issue. Shell neutrality claim people make fail to see that they have tied their hands to the point they cannot manage services safely on Linux. How do you get cgroup information on process using posix only shell features the answer is you don't.

How do you use the pidfd interface from posix shell limited features to prevent PID recycling messing with your actions again you you cannot. Something interesting is freebsd init system yes is written is shell script but they have not limited themselves to Posix shell script features because their init shell scripts can use "process file descriptors". So be it Linux or freebsd you are stuffed doing process management if you restrict yourself to Posix shell features or Posix C API features. Remember both linux and freebsd have PID recycling.

https://bug-bash.gnu.narkive.com/qmN6b7Dk/aix-and-interix-also-do-early-pid-recycling

The nightmare here is the PID recycling problems that Posix shell script does not deal with is not Linux or Freebsd exclusive problem. This problem effects operating systems that are formally branded Unix. The reality here Posix shell or C API defined interfaces are not good enough for service management and has not been for decades.

People forgot that early Unix never recycled PID values instead once you allocated the last PID value the system just crashed and POSIX standards fairly much still presume this is case and have never been evolved to deal with correctly with any kernel that recycles PID values. How many more CVE do we have to have before people accept the POSIX method does not work correctly and has to be replaced.

[arQon]

Your scenario involves Canonical integrating them to force GNOME users to use Upstart

It does, but that's because we're dealing with someone who (seemingly) genuinely doesn't understand why that's even a bad thing.

> but it needn't be nearly so coercive. In fact

Yes, I know.
Not everybody does though - and the thing is, from a user perspective it doesn't *matter*. Even if Canonical acted with such obvious malice, what's the recourse for a user? Despite what forum posters proclaim, people don't actually inspect "the source", let alone modify it, and that holds true even for the tiny minority like you and I that even have the skillset to do so in the first place. Whether the mythical Canonical is "evil" or just any one of lazy, inept, or just rushed, the end result is effectively the same. (Well, really, the "deliberately malicious" case is *easier* to deal with, but the EEE-style approach isn't just harder to fight, it's also far more common, intentional or not).

The best you can hope for in this theoretical scenario is that some saint makes a PPA, but that will die out when he loses interest, which is going to be a year if you're lucky, because none of us have the time or energy to keep dealing with this crap on a constant basis, even without getting into the domain knowledge and code quality aspects of the problem.

Everything you said is true. The problem isn't that you're wrong, it's that Linux hasn't been the domain of "hobbyists" and "the community" for 15 years now, and that's the reality we live in. The last time anyone took any notable "freedom" action was Devuan, and even ignoring all the abuse they got from the ignorant over it I'm honestly quite surprised that they've lasted as long as they have. I don't expect to see another rebellion that *successful* ever again, and it's not like Devuan is taking the world by storm.

[coder]

Read the posts or do I have to post the 4000 page history document of these events Included the detailing of the Posix design flaws.

No, I haven't found them worth my time. You get onto tangents and we end up debating completely unrelated stuff.

It also seems like you use long posts to exhaust the other party, as if trying to win by attrition. I'm not going to play that game with you, not only because it's a poor use of my time, but also because it feels like you're just here to win arguments rather than to participate in a collaborative search for the truth.

And when you do post links (which is not often enough), it seems like you're just scraping the internet for anything that even remotely seems to support your point, rather than trying to educate yourself and then bringing us along with you.

So, I guess what I'm saying is I need you need to do a better job of respecting my time and respecting the discussion, in order for me to respect your participation.

[coder]

people don't actually inspect "the source", let alone modify it, and that holds true even for the tiny minority like you and I that even have the skillset to do so in the first place.

There are two cases in which I definitely do read the source:

1. When I hit a bug (even if it's in my own code), it's nice to be able to do source-level debugging.
2. When I'm trying to use an API that's insufficiently documented.

A 3rd case is where people are using static analysis tools to look for bugs or security vulnerabilities. I think this is becoming increasingly common and the tools are improving in sophistication.

[oiaohm]

No, I haven't found them worth my time. You get onto tangents and we end up debating completely unrelated stuff..

Answer I simple question then. But before you do I recommend reading my prior posts here. If you don't you will screw up again.

https://www.phoronix.com/forums/foru...38#post1339938

How with the defects of the Linux PID system has Gnome/KDE/XFCE/X11 DE session management worked correctly prior to systemd?

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Come on now coder answer those questions.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

[coder]

Answer I simple question then.

No, because you're naively presuming that if Redhat didn't fix it, nobody else would have. If it's a problem worth fixing, it probably would've gotten fixed. Just because Redhat solved a problem and got their solution accepted doesn't make them a savior, as you seem to be implying.

I'm not trying to demonize them, either. Someone needn't be acting with malicious intent to cause harm or pose a threat.

[oiaohm]

No, because you're naively presuming that if Redhat didn't fix it, nobody else would have. If it's a problem worth fixing, it probably would've gotten fixed. Just because Redhat solved a problem and got their solution accepted doesn't make them a savior, as you seem to be implying.

coder I have point out a fundamental flaw. This is a fundamental flaw that upstart was attempt to fix but method chosen did not work. Systemd is the second attempt to fix the same fundamental flaw and the first to get it to work.

Remember systemd to get it fixed was not simple. cgroupv1 was not suitable so cgroupv2 had to be created. Then cgroupv2 still had a problem leading to pidfd being created.

Remember the fundamental flaw effects system wide service management and X11 DE/Wayland DE session management.

Commercial distributions like redhat and SUSE and Ubuntu end up with their customers complaining about repeating CVE so have had to attempt to come up with solutions. SUSE did attempt also try out upstart as well.

If it's a problem worth fixing, it probably would've gotten fixed.

This is true. This is why systemd is end up everywhere.

No, because you're naively presuming that if Redhat didn't fix it, nobody else would have.

This start off with the false presume. You miss that Canonical tried to fix this problem first. Systemd was Redhat attempt to fix upstart failure.

Canonical funded upstart failed because they did not put a team of user-space and kernel space developers on the problem. You can look at other attempts to fix the problem as well that failed for the same reason.

nobody else would have.

Wrong here. The problem is fairly much no one else could have back then. No one else had the integrated user-space and kernel space teams. Remember the lead developer of cgroups in the Linux kernel at the time of start systemd was also at redhat. This was having everyone required to solve the problem service management/session management in the one company under the same manager.

The reality here is "not nobody else would have " bunt instead "nobody else could have." Linux kernel modifications were required because there was a total fundamental problem. Linux kernel PID recycling and PID tree breaking was that bad that there was no valid way to make service/session management at all before the systemd development caused kernel changes of cgroupv2 and pidfd.

Now it gets worse cgroups2 and pidfd are part of the kernel now. Busybox init solutions have not updated to support either. Sysvinit is still just as broken as it always was. Openrc has part cgroup2 support and is still missing pidfd.

KDE and Gnome moving their session management to systemd because that simpler.

nobody else would have.

This is also important when KDE and Gnome developers have a functional solution sitting in front of them in systemd to solve their session management problems correctly why should they both reinventing the wheel.

Next coder answer me thing thinking cgroupv2 has been since 2016 and pidfd has been out since 2019 what other solutions other than systemd for session and service management have completely implemented the features to work right?.

https://www.smart-jokes.org/everybody-somebody-anybody-and-nobody.html

You need to get to know these jokes. The reality here I am not presuming if Redhat didn't fix it nobody else would have. The history over the past years says quite simple that Redhat fixed and everyone else is using Redhat fix instead of investing their time to make their own fix. Like it or not coder nobody else is putting up alternative that is complete.

You also have to remember this problem of leaving it to nobody and it be nobody was going on in the sysvinit days.

Coder here is a horrible question. Coder please explain why someone is going to full time developers to make alterative to systemd when systemd does in fact work?

Remember what I said that the Linux 5% of diversity in my prior posts is serous-ally lacking funding. The funding does not exist to make properly functional alternatives to systemd. Heck the funding to start the process make a proper working solution to replace sysvinit (yes what leads up to upstart existence) that took some serous getting.

Coder hard reality here in the complete history of Linux and every OS in existence a part time developer or hobbyist developer has never made service management solution that works right. Every case that you have service management that works right the person worked on it full time for at least 2 years.

Coder don't complain about the length of this post.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly? << You really do need to sit down and answer this question. This is critical what options do KDE/Gnome... have for a working solution other than code it themselves. The horrible answer they only have 1 option because no other options have been made. Yes if you had answered that question I would not have done this long post.


How with the defects of the Linux PID system has Gnome/KDE/XFCE/X11 DE session management worked correctly prior to systemd?

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Come on now coder answer those questions.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

Coder now before wasting my time again answer the questions.

[coder]

Coder now before wasting my time again answer the questions.

Here's something I think we can agree on: let's just stop wasting each others' time, period.

I pretty much don't even read your posts, any more. So, if you don't reply to mine, then we won't have a problem.

I'm not making any promises, and I'm not asking for any on your part. But you've been warned: when you try to engage me, you'll be doing so on my terms, not yours.

[oiaohm]

Here's something I think we can agree on: let's just stop wasting each others' time, period.

I pretty much don't even read your posts, any more. So, if you don't reply to mine, then we won't have a problem.

I'm not making any promises, and I'm not asking for any on your part. But you've been warned: when you try to engage me, you'll be doing so on my terms, not yours.

How with the defects of the Linux PID system has Gnome/KDE/XFCE/X11 DE session management worked correctly prior to systemd?

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Come on now coder answer those questions.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

So can I take it since you will not answer any of this questions you are 100 percent deterred to be totally clueless on these topics?

Coder you started saying things that are not based on facts. Answering those questions should show that there is a fundamental flaw that needs fixing driving particular set of actions. Yes there is total lack of alternatives when you have to solve those fundamental flaws. Commercial selling support contracts to customers with liability risks.