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

[arQon]

So I really wonder what this is going to be.

Given that it's Red Hat, I'd have thought the answer was obvious: it's 1% something that will benefit them in some immediate practical way, and 99% a way to land grab another piece of the stack so that it can be welded into GNOME, systemd, and every other technology that they control until Linux has all the flaws and monolithicity of Windows, and anyone competing with any part of the Red Hat empire has to fold under the weight of trying to disentangle that part from the whole mess.

They've been flogging this particular dead horse since, what, 2015 or so, and they're still not giving up despite nobody wanting it. The only difference is that now they've got so much crap so deeply embedded that this time they'll probably get away with it.

[kylew77]

Given that it's Red Hat, I'd have thought the answer was obvious: it's 1% something that will benefit them in some immediate practical way, and 99% a way to land grab another piece of the stack so that it can be welded into GNOME, systemd, and every other technology that they control until Linux has all the flaws and monolithicity of Windows, and anyone competing with any part of the Red Hat empire has to fold under the weight of trying to disentangle that part from the whole mess.

They've been flogging this particular dead horse since, what, 2015 or so, and they're still not giving up despite nobody wanting it. The only difference is that now they've got so much crap so deeply embedded that this time they'll probably get away with it.

I agree 100%, Linux used to be an OS I was proud to use now it is largely controlled by RedHat and I hate their gnome infested systemd future. I try to run *BSDs but they have rough edges compared to Linux.

[Mordrag]

Given that it's Red Hat, I'd have thought the answer was obvious: it's 1% something that will benefit them in some immediate practical way, and 99% a way to land grab another piece of the stack so that it can be welded into GNOME, systemd, and every other technology that they control until Linux has all the flaws and monolithicity of Windows, and anyone competing with any part of the Red Hat empire has to fold under the weight of trying to disentangle that part from the whole mess.

They've been flogging this particular dead horse since, what, 2015 or so, and they're still not giving up despite nobody wanting it. The only difference is that now they've got so much crap so deeply embedded that this time they'll probably get away with it.

Speak for youreself, I actually quite like GNOME and systemd.
Its pretty ironic that kylew77 says himself that the RedHat infested Software works better :O.

[jacob]

Given that it's Red Hat, I'd have thought the answer was obvious: it's 1% something that will benefit them in some immediate practical way, and 99% a way to land grab another piece of the stack so that it can be welded into GNOME, systemd, and every other technology that they control until Linux has all the flaws and monolithicity of Windows, and anyone competing with any part of the Red Hat empire has to fold under the weight of trying to disentangle that part from the whole mess.

They've been flogging this particular dead horse since, what, 2015 or so, and they're still not giving up despite nobody wanting it. The only difference is that now they've got so much crap so deeply embedded that this time they'll probably get away with it.

So what is actually your point? That RedHat should not be allowed to develop free and open source software (in practice, develop proprietary instead)? Or that Linux shouldn't be a modern, real OS, and remain a DYI bazaar held together by ductape shell scripts?

[oiaohm]

I agree 100%, Linux used to be an OS I was proud to use now it is largely controlled by RedHat and I hate their gnome infested systemd future. I try to run *BSDs but they have rough edges compared to Linux.

Really the systemd problem is way more complex. You have to remember when systemd started the Linux kernel did not have pidfd_open. Only way to create something equal to pidfd_open without having that syscall is use cgroups under Linux.

https://brauner.github.io/_img/2019_...pes_pidfds.pdf page 6 here is important. FreeBSD has the pd syscalls to handle PID recycling and openbsd and netbsd don't go recycling PID numbers. Remember this is a feature only added in 2019 to Linux to have proper process handling so that you single the right process all the time and terminate the right process all the time.

But pid_open is the tip of the Linux kernel process tree problem.

The reality here is all init/service management systems on Linux without pidfd_open support and cgroups issues. Systemd cgroup usage to work around the issue pidfd_open issue had overhead.

Items like runsv that attempt service management without pidfd_open or cgroups by put a wrapper program around find they have issue due to Linux PID tree allowing items to get disconnected from their starting process. Cgroup around process deal with the Linux kernel PID tree horrible behavour.

Welcome to the problem the Linux kernel has some unique design faults that come about because of fixing particular problems. Yes Linux world used sysvinit based init system design for a long time then you wake up sysv the real one did not have the PID recycling or PID disconnecting from parent in the PID tree as a problem. Instead had the problem you run out of PID I crash problem because I never reuse them.

You look at times like devuan with the knowledge. SysVinit still not have cgroup or pidfd_open support. OpenRC cgroup support is not fully fleshed out and only come into existance after systemd. , Runit these days has cgroup support and this only comes after systemd has already done it.

Systemd is a change that need to happen. Yes doing service management right for the Linux kernel unique PID recycling and PID tree mess requires some special handling. Does this make creating init system and service management solutions harder yes it does.

Why is gnome and kde both getting very infected by systemd on Linux simple its the most developed solution that deals with the unique issues with process management Linux kernel has. Most of these unique issues with the Linux kernel were created before Redhat was a company.

Reality here users want to know what application has eaten them out of house and home when system stalls out. Only way to know this is cgroups with Linux due to process tree not being stable. This is only one issue systemd addresses that was a problem on Linux but its not the only one.

We had a problem. People kept on trying to make service management across Unix one size that fits all. Completely forgetting Linux kernel is not related to Unix by source at all. Yes Linux kernel in the Unix world when it comes to process and resource management like a person needing a size 20USD shoe they are not going to find what they need in a general shoe store yet the only option they had for a long time was to take size 12 shoes cut them up and kind of make them kind of fit.

Biggest complaint about systemd is mostly they have gone and made a platform unique solution when this is really required. Next complaint is getting rid of the old scripting. Sorry the way bash and unix shell scripts handle processes is designed around the presume PID and PID tree is stable and this is not the Linux kernel.

Hard reality we have systemd from redhat replacing the old init system using features that work. We don't have a replacement shell script that also can use the features that work for Linux.

There is a lot more here.

[coder]

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

Eh, lots of people said the same thing about Microsoft Windows. The problem with Microsoft was that it was closed and their anti-competitive behavior crowded out other options.

I can see a similar concern with Redhat, being that their software projects are evolving into a monolith that similarly crowds out practical alternatives. As long as it works of you and does everything you want, then that's great for you.

One thing I find ironic is that the Open Source world should be more attuned to the concept of freedom than most. You would therefore expect the community to be more concerned about the foreclosure of practical alternatives. Whether it's by the sort of aggressive market practices that made Microsoft infamous, or by simply depriving small projects of opportunity and oxygen by the systemd ecosystem's tight integration is almost beside the point.

BTW, I'm not a systemd hater. I just like freedom more, and find the lack of practical alternatives rather unsettling.

[coder]

So what is actually your point? That RedHat should not be allowed to develop free and open source software

Nice false dichotomy. Obviously, nobody is in a position to "allow" or "disallow" them to do anything.

(in practice, develop proprietary instead)? Or that Linux shouldn't be a modern, real OS, and remain a DYI bazaar held together by ductape shell scripts?

Again, with the false dichotomies. Just because a Redhat project solved real problems doesn't mean there aren't other approaches towards solving those same problems, or that nobody else would have done anything if Redhat didn't.

What I'd rather see is open standards and open implementations, like we had with X11 and POSIX. Or, at the very least, maybe trying to establish solutions more by creating an ecosystem, rather than developing their own internal projects which they subsequently entrench via their dominant market position.

[oiaohm]

What I'd rather see is open standards and open implementations, like we had with X11 and POSIX. Or, at the very least, maybe trying to establish solutions more by creating an ecosystem, rather than developing their own internal projects which they subsequently entrench via their dominant market position.

POSIX and X11 is part of the problem. POSIX and X11 is what really broke Unix world. It called using the "Lowest common denominator" to solve a problem it does not fit.

POSIX standard never got anything like pidfd stuff and many other items because all the Unix solutions did not have uniform process trees so need unique ways of solving these problems.

X11comes about from the same faulty idea. We can make something that does not care what the kernel limits/defects/security are under it then wonder why we end up with a broken security mess.

Redhat over a decade did try to work with the ecosystem on lots of these problems.

Again, with the false dichotomies. Just because a Redhat project solved real problems doesn't mean there aren't other approaches towards solving those same problems, or that nobody else would have done anything if Redhat didn't.

This has a problem. This ignores the decades of time that Redhat raised issues with existing designs with the Linux kernel and got told the solution has to be cross platform and/or posix compatible. Yes remember posix compatible equals feature incomplete so unable to solve particular problems.

Redhat actions are because there are real problems that need solving not being kept on swept under rug.

coder is about time you take off those rose colour glasses and have a proper look at X11 and Posix and notice people using these things to ignore problems is major cause of Redhat and other commercials going systemd and other parts.

Yes your complete post there is a write up that almost exactly word for word what some parties would use to ignore fundamental problems of process control be it termination or resource control the Linux systems had prior to redhat doing systemd and other parts.

Lot of people forgot that logind at first was meant for consolekit and it was to solve a particular problem session management that did not have a decent solution. Yes got refused from merge guess why it was using platform unique code to solve a problem that could only be solved with platform unique code. Yes the start of systemd yes it was the lead developer of systemd who got that slap in the face.

There is a lot deeper story here and its not a good one. Hard reality is bridges with redhat were broken before systemd. Different parties are to blame. Please note I am not saying Redhat has not done wrong here. But Redhat was also stone walled by different parties when they were hitting real problems.

Think about how many people were saying just use sysvinit to redhat when that absolutely cannot solve the service management solution.

Creating an ecosystem is not easy. Having ecosystem comes impossible at times when parties solidly go and ignore the other parties problems. Remember Redhat has a ecosystem they have to take care of their paying customers.

[coder]

POSIX and X11 is part of the problem. POSIX and X11 is what really broke Unix world. It called using the "Lowest common denominator" to solve a problem it does not fit.

That's not the fault of open standards. In the case of POSIX, that's the fault of trying to create them after-the-fact.

X11comes about from the same faulty idea. We can make something that does not care what the kernel limits/defects/security are under it then wonder why we end up with a broken security mess.

Trying to look at X11 with the hindsight of 3-4 decades is also rather unfair.

They were imperfect analogies that I hastily reached for, to show there are better ways. Perhaps Khronos or W3C standards would've been better examples to consider.

[oiaohm]

That's not the fault of open standards. In the case of POSIX, that's the fault of trying to create them after-the-fact.

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.

Trying to look at X11 with the hindsight of 3-4 decades is also rather unfair.

No the problem with X11 starts from day one. The idea of being platform netural to the extreme. Yes this lead to X11 usermode drivers having x86 emulator. There are some very big lessons we need to learn.

They were imperfect analogies that I hastily reached for, to show there are better ways. Perhaps Khronos or W3C standards would've been better examples to consider.

Khronos eglstreams and gbm issues we have had failure to cooperate and understand each other sides limitations again.

W3C we have seen all browsers do their own unique things.

Creating an ecosystem is not easy. Having ecosystem comes impossible at times when parties solidly go and ignore the other parties problems.

This line of mine is just as true with Khronos and W3C. Yes there are times in Khronos and W3C history where the ecosystem falls apart.

When the ecosystem falls apart first stage it work out why it fell apart. Redhat case their requirements were not being meet and were being blocked from being meet. We see the same thing with eglstreams and gbm yes the eglstreams model by Nvidia really would not do what wayland compositors need the thing to be able todo.

Ok people want to hate systemd and redhat using their market force. This forgot Redhat has its market force because of it customer base and ecosystem . Redhat cannot change to a path that does not solve the problems their ecosystem/customers need solved or they will lose their market force/customers.

Redhat market force and money for it developers all come about because Redhat is addressing their customers needs.

Please note I said "ignore other parties problems" not that you agree with the parties solution. To make a proper ecosystem solution you need to know the problems everyone is trying to solve and be making solution that covers more of those problems.

Why did redhat decide to bundle so much software with systemd simple they wanted a solution that when you run a test suite and it says it works everything does and not having to be working out does X version of consolekit work with Y version and dbus..... When you look closer majority of the hate against systemd is mostly Redhat trying to address the problems that effecting them. Of course those complaining have not been putting up different solutions to address Redhat problems sothey go a different way.

coder I can see what the problem is here. I cannot see a solution that will make everyone happy. More being bundled with each other fixes a set of problems while at the same time causing a set of problems. We have a stack of doubled sided sword problems here.