systemd 250 Released With A Huge Number Of New Features, Improvements

[coder]

That's obviously not going to happen, the major distro's switched to systemd a decade ago because it's the superior solution.

Just because it solved some real problems doesn't mean there aren't legit complaints against it. You're trying to paint this as a black & white issue, but it's more complex than that.

Personally, I don't hate every single thing systemd did. I just hate the way it's swallowing more and more userspace facilities. The devs literally seem to know of no boundaries or have a willingness to solve some particular problem as a completely separate, standalone project.

Merry xmas everyone

Thanks, you too!

[coder]

The Linux kernel cannot do all imaginable use-cases. So there is a finite number of use cases. So in theory it possible to standardise for all Linux kernel supported use cases.

The kernel should be more generic than the userspace. The role of a particular userspace install + configuration is largely to tailor the install to a particular usage model.

[intelfx]

So, rather than actually query the device about itself, you think a bolt-on database is a better solution?

Sometimes it's necessary to have a fallback or override being supplied at a layer above the driver, for devices which either don't support such a query or report the wrong value. However, the place to start is with a device-level query. And sure, if the driver's existing API is rich enough that you can implement that query entirely in userspace, I'm fine with that. Yet, I'm sure that's not true for a large number of these devices.

I'm not sure what you are arguing here for. If the driver API (and the hardware interface) is rich enough, then sure, you can query the device about itself. If not (and these cases make up the overwhelming majority of the problem space), then you have no option other than a "bolt-on" database and this is what hwdb is.

You seem to imply that there is a third possibility, when the driver API is not rich enough to support querying the device, but the device can still be queried. How?

My main point was really that there's no reason this should be bound to systemd. I think this service should be separate, so that it can be installed & upgraded independently of systemd.

hwdb is not really bound to systemd, it's a part of udev. And you can absolutely upgrade it independently of systemd, if you so desire.

[coder]

I'm not sure what you are arguing here for. If the driver API (and the hardware interface) is rich enough, then sure, you can query the device about itself. If not (and these cases make up the overwhelming majority of the problem space), then you have no option other than a "bolt-on" database and this is what hwdb is.

In the short term, sure. However, the focus should be on adding the ioctls to the driver APIs, as the long-term solution, while using a bolt-on database as a band aid.

You seem to imply that there is a third possibility, when the driver API is not rich enough to support querying the device, but the device can still be queried. How?

I was allowing the possibility that the driver supports a general query of some sort, but isn't smart enough to parse out the relevant bits. This could be harnessed by a userspace component, assuming the format of the response is somehow regular enough, for some class of devices, that userspace could do that reliably for them.

[oiaohm]

The kernel should be more generic than the userspace. The role of a particular userspace install + configuration is largely to tailor the install to a particular usage model.

Lot of these case this turns out to be horrible no when you are talking about the Linux kernel.

https://www.kernel.org/doc/htmldocs/kernel-api/API-call-usermodehelper.html

The reality here is the Linux kernel calls out to userspace to perform particular operations for the Linux kernel at lower privilege than kernel mode.

So the user space has to be so far tailored to match the linux kernel and the Linux kernel is so far tailored to match the supported user space.

The reason why hwdb and udev was first merged into systemd was that the project of udev had suffered from quite a few https://en.wikipedia.org/wiki/Bus_factor critical Bus Factor events. Yes this is where the core developer gets taken out of action for some reason and there is no body able to take that person place. Yes this Bus Factor problem has happened to most of the projects that merged into systemd.

You think about it lot of people buy off the shelf suits and clothing and wear them. No they don't fit them perfectly but they are cost effective less labour is required to make. This is exactly the same problem in fact.

The more tailored the userspace is to a particular usage model the higher the maintenance cost goes. Yes this result in items where its not worth updating the operating system. And the more tailored the userspace the more unique knowledge that is required to maintain so the more likely the critical bus factor will happen where critical core person is remove from development by death, retirement or employment resulting in development and maintenance stall.

The reality we need the kernel and the core userspace to be as generic as possible covering as many usage models as they can with very little duplication so make the process cost effective and bus factor safe.

Yes the competitors to systemd do need to make sure they are not bus factor disasters. Some of them that have the lack of personal to remake hwdb tools and the like is in fact sign of not having enough developers and when you look closer they are at high risk of the bus factor problems.

Bus factor problems either you solve them in advance or end up having to suffer though them when they happen.

Yes another fact that made bus factor worse was the ability to take parts individually before systemd. This result in many of the parts having quirks added for stacks of different init systems making the knowledge required to modify them without breaking anything way higher so the people who could maintain those code bases was also reduced.

The reality is even after all the merges to increase number of developers able to take care of core parts that systemd has done there are still major bus factor risks with systemd. The problem here is the bus factor problem is the true elephant in the room that a lot of people ignore and does explain why systemd is going in it particular direction. To stop systemd going in it particular direction and going a different direction like independent parts would require solving the bus factor problems.

Most people pushing for init freedom also fail to provide answer to a bus factor problem so end using alternative init systems that are even more under resourced than systemd and at way higher risk to bus factor problems.

coder I don't have a ideal answer to this problem. Your idea that the kernel should be more generic than the user-space is unfortunately idealistic at this stage. You have basically missed seeing a very critical elephant that started systemd yes the bus factor problem. I don't have a good solve for the bus factor problems and keep init system diversity. I would be happy see someone invent a solution.

[oiaohm]

In the short term, sure. However, the focus should be on adding the ioctls to the driver APIs, as the long-term solution, while using a bolt-on database as a band aid.

https://www.kernel.org/doc/html/latest/process/botching-up-ioctls.html

The reality is each new ioctls is a new risk to botch something worse.

I was allowing the possibility that the driver supports a general query of some sort, but isn't smart enough to parse out the relevant bits. This could be harnessed by a userspace component, assuming the format of the response is somehow regular enough, for some class of devices, that userspace could do that reliably for them.

Sorry what you are calling a band aid is one of the options to have a generic query systems.

Generic support equals less room to majorly screw it up. ioctls are normally not generic.

[jacob]

So, rather than actually query the device about itself, you think a bolt-on database is a better solution?

Sometimes it's necessary to have a fallback or override being supplied at a layer above the driver, for devices which either don't support such a query or report the wrong value. However, the place to start is with a device-level query. And sure, if the driver's existing API is rich enough that you can implement that query entirely in userspace, I'm fine with that. Yet, I'm sure that's not true for a large number of these devices.

Of course the driver query takes place but of course, it's also not sufficient as you have yourself recognised. A database of known devices with their quirks, workarounds etc. is needed and all OSes have one.

My main point was really that there's no reason this should be bound to systemd. I think this service should be separate, so that it can be installed & upgraded independently of systemd.

The reason is that it's being developed by systemd developers. It's "bound" to systemd in the same way GCC is bound to GNU.

[arokh]

Just because it solved some real problems doesn't mean there aren't legit complaints against it. You're trying to paint this as a black & white issue, but it's more complex than that.

If you know anything about open source development, it is most definitely 100% black & white. You stated that distributions should accomodate for a systemd alternative, that hasn't happened and won't happen for obvious reasons that already has been discussed to death.

Tell me, what would be the incentive to do so when systemd works great and people are happy with it? From what I've seen, most of the complaints come from a lack of technical competence and understanding.

Personally, I don't hate every single thing systemd did. I just hate the way it's swallowing more and more userspace facilities. The devs literally seem to know of no boundaries or have a willingness to solve some particular problem as a completely separate, standalone project.

Why don't you elaborate on what the actual problem with that is, what should instead be done and what is your contribution to that?

[Phil995511]

What "cross-platform package installer"

It's pretty cool actually. I for one use systemd's new app install utility instead of apt-get and suchlike to get a cross-platform app management experience.

From what "cl333r" is telling us (post # 6), there would be a new feature for installing packages, it would be compatible with all distributions using systemD ... I'm trying to do some research, but I don't have not yet found more details on this point.

[jacob]

Tell me, what would be the incentive to do so when systemd works great and people are happy with it? From what I've seen, most of the complaints come from a lack of technical competence and understanding.

I guess it's the same old sense of entitlement to dictating how other people should be running their project.