23 ms·

> Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this

> Since most major distros use systemd by default, it is important that also most of them fix the same fundamental problems the same way; and I really hope this new oomd finally fixes thrashing behavior. Solving problems in multiple different ways is the only reason we have multiple distros serving different needs. Unification is not always a positive thing.

lmilcin 6y ago
I second that. I feel like I have less and less choice. I can either accept all systemd provides or switch to some fringe distro. I switched from Windows to Linux 20 years ago to have more choice.
- kaba0 6y ago
  I really don’t get this mentality. Where are you limited exactly? You can trivially view and edit every single service file to achieve basically anything. But a modern system does require some building blocks. I mean, the linux kernel is similarly limiting you to eg. have a file-oriented abstraction, and you can’t just swap it out to a different kernel. Systemd is much more modular than that for example.
  - lmm 6y ago
    Pre-systemd you actually could switch out the kernel on Debian - you could be running Hurd or the FreeBSD kernel, but the rest of the OS would still be Debian.
    - kaba0 6y ago
      I believe it is only correlation, not causation. I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features. But I’m not sure about this. Aren’t you referring instead to debian itself providing packages for all of them and the package manager running on each distro? Because I can’t really believe you could just swap out the kernel and be on your way in most cases. If it is the latter, than it was more due to the fact that debian maintainers voted against supporting other systems, because it is a great amount of additional work.
      - lmm 6y ago
        > I believe it is only correlation, not causation. It's a bit more direct than that - previous init systems were kernel-agnostic whereas systemd is explicitly tightly coupled to Linux and udev, and encourages the rest of userland to be tightly coupled to it. > I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features. I wouldn't say "more advanced" - in many ways FreeBSD jails are a better technical solution than Linux's various container systems.
  - zepearl 6y ago
    I think that lmilcin was referring to "either use systemd on distribution X or switch to another distribution". E.g. in Gentoo you can choose to use SystemD or OpenRC, but I think that most other distros don't provide such a choice.
    - kaba0 6y ago
      Most don’t provide such a choice, because it’s a huge undertaking to basically package and maintain 2+ versions of everything, especially when one is unified among distros and often created upstream. And of course after a certain size it has to do with network effects, but it was chosen based on merits — for example debian voted multiple times on the issue and I would say their voting system puts most countries’ to shame. I believe up until recently the vote on debian was basically use systemd but if the maintainer wants to, they can also support alternative init systems, but there was not much interest. But of course anyone can help the fringe distros on another init systems to make them less fringe.
      - zepearl 6y ago
        > Most don’t provide such a choice, because it’s a huge undertaking to basically package and maintain 2+ versions of everything Yes, I absolutely agree regarding the effort. (not sure about that vote - I honestly didn't follow that discussion) In parallel, some software (cannot recall - maybe the Gnome window mgr) does rely (in its original form) on SystemD being there => I don't think that's fair, kind of forcing the distros that want to offer it to adopt it => I don't like it - I do see the advantage of having that kind of integration, but I still don't like it :P
        spiralx 6y ago
        Gnome's dependency on logind came about because there originally was a dependency on a different library that one person had written, had pretty much stopped working on, and nobody wanted to take on maintaining it or adding it to Gnome itself. The dependency no longer exists because some people took logind from systemd, made it a standalone package and called it elogind lol, and now you can use that instead of logind.
- viraptor 6y ago
  Or disable the elements you don't want and switch to a different implementations. What exactly are you missing right now?
  - turminal 6y ago
    Switching to different implementations is getting harder with every systemd release.
    - viraptor 6y ago
      Have you got examples for what got harder to replace?
      - turminal 6y ago
        The era when running gnome or any of its derivatives without systemd comes to mind. If it weren't for Gentoo's forks of systemd components, the whole situation would be much worse in general.
    - prussian 6y ago
      I literally work on a device that is still uses an inittab (hopefully changing that in 2021). the only limiting factor is yourself. 1) eudev works 2) elogind works 3) you can still use sysvinit or literally the multitude of others
      - turminal 6y ago
        > I literally work on a device that is still uses an inittab. The fact that this is so rare it has to be pointed out like this kind of speaks for itself. > 1) eudev works 2) elogind works 3) you can still use sysvinit or literally the multitude of others. I am aware of these and use them on nearly all my machines. Note that both elogind and eudev required a significant amount of work by the Gentoo community when they were pulled out of the systemd codebase.
- vetinari 6y ago
  Well: http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/
  - dane-pgp 6y ago
    Linux is, or at least was, about Freedom; and Freedom is about choice. You may not mind the decisions others make on your behalf, or care about the options that are no longer possible, but that doesn't mean that Linux hasn't lost some of its identity.
    - vetinari 6y ago
      Yes and no. Yes, in the sense, that if you want, you can eventually make it the way you want. No in the sense, that others won't do it for you; they will make linux distribution the way they consider it best, not how you consider it the best. So if you want to pick and choose the components the way you want and not the way the distributions consider the best, be ready to put in the manhours.
- lmm 6y ago
  I'd strongly recommend switching to FreeBSD. It's pretty similar to Linux of 20 years ago: some things might require a bit of manual configuration, but it's rock solid after you've done that.
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    Including graphics programming experience of GNU/Linux 20 years ago.
Nextgrid 6y ago
I mean there's always a way to configure/disable it, but a counter-argument would be that if there's an optimal solution to the OOM problem, I would prefer that all distros use it. Just like you can mostly expect filesystem behavior to be consistent no matter which distro, so should be the OOM behavior if a "good" solution is found.
- gmueckl 6y ago
  You can't expect filesystem to behave consistently across filesystem and media types because these exist to solve different issues and involve different design decisions. The same thing goes for out of memory handling: no size fits all. The kind of handling strategy you need depends on the kind of system you build. Exactly this kind of flexibility and lack of unification is what made Linux so ubiquitous.
  - kreetx 6y ago
    I think what the OP means is that you can be in any filesystem without needing to put much thought into it (regardless of the very real differences in implementation). Advanced users who want to interface with the details can do that, but for the rest of us consistency can be good.
    - robertlagrant 6y ago
      Isn't the same level of detail needed for init as for different filesystems?
    - gmueckl 6y ago
      Except that file systems aren't consistent on Linux. FAT and NTFS can't represent Unix permission bits. File systems reorder operations internally in some ways user space programs don't expect. NFS mounts may not be able to guarantee exclusive file locks...
      - kreetx 6y ago
        Absolutely. What I'm saying is that I personally don't need to know about this. I suspect that OOM's behavior is of similar effect to most developers.
kaba0 6y ago
When we talk about an OS that on desktop has minuscule user share, it is not too clever to further fragment that. I believe there are only a handful of people who knows enough to create a proper init system (similarly, sound and graphics) and do it for the community. The alternative is that more complicated features will simply not be implemented on linux. Also, just look at the before-systemd landscape, there was much more difference in the repositories, and nowadays even more niche distros can trivially package almost everything since .service files are unified. Also, they are quite flexible, so I don’t feel that anything would be lost.
- turminal 6y ago
  > When we talk about an OS that on desktop has minuscule user share, it is not too clever to further fragment that. True, but desktop usage is only one of many things linux is used for. All the "unification" efforts ala systemd try to handle all of those use cases. I don't see why the init system on my server has to be the same as the one on my ultrabook, because only a fraction of what they should do is shared. Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface. > I believe there are only a handful of people who knows enough to create a proper init system (similarly, sound and graphics) and do it for the community. I don't think Linux graphics or sound situations have much in common with the init system situation, except perhaps the fact that Poettering tried to fix sound as well.
  - kaba0 6y ago
    > I don't see why the init system on my server has to be the same as the one on my ultrabook, because only a fraction of what they should do is shared Well, not even the kernel should be shared —- but most of us is okay with having the same kernel, but at most configured differently. I see it the same way in the case of systemd, of course your ultra book doesn’t need I don’t know how many services, but the basics are very much the same. And to be honest, I’m happy to use the same knowledge/tools on a server machine and a laptop. > Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface. That’s just security by obscurity...
marcodiego 6y ago
I really think fundamental problems should be solved the same way on major distros. Leave the exotic and creative ways for problems that are not fundamental or for minor distros. The feeling that you can solve fundamental problems the same way on any major distro is valuable.
- turminal 6y ago
  Agreed, but systemd is leaning very much towards "every problem should be solved the systemd way". I'm totally fine with the idea of all distros having better oom behavior (which I hope is what systemd-oomd does), but I don't like how that implies having to use systemd for a lot of other problems as well.
  - addicted 6y ago
    It’s fairly clear to me that the problem isn’t that Systemd is leaning towards everything should be solved the SystemdD way. The real problem is that almost no one has been able to create alternatives to SystemD’s solutions to the vast majority of problems it chooses to tackle that are as well developed or effective as the SystemD solution.
    - dane-pgp 6y ago
      Of course, if someone did create a better way to solve these problems, but it wasn't compatible with systemD, then no one would use it, because they are locked into systemD. You might then ask why no one created these better solutions 6 years ago before systemD gained its stranglehold on distributions, but that's like asking why systemD itself didn't add all these features 6 years ago.
      - growse 6y ago
        We were all "locked into" shell scripts for service management not so long ago. Either open source and software freedom affords us endless amounts of choice and capability to create, inspect, modify and use whatever software we like, or we're all forced to use systemd against our will. Which is it? Systemd doesn't have a stranglehold over anything - that misinterprets the power dynamic. It's got large adoption, because it's actually useful.
pjmlp 6y ago
Yeah, hence why the only Linux based OSes that matter on the desktop only borrow the Linux kernel, while providing an unified experience to app developers and users.
- turminal 6y ago
  The unified experience of being hostile and abusive. (not sure how any of this is relevant to this discussion)

lmilcin 6y ago

I second that. I feel like I have less and less choice. I can either accept all systemd provides or switch to some fringe distro. I switched from Windows to Linux 20 years ago to have more choice.

kaba0 6y ago
I really don’t get this mentality. Where are you limited exactly? You can trivially view and edit every single service file to achieve basically anything. But a modern system does require some building blocks. I mean, the linux kernel is similarly limiting you to eg. have a file-oriented abstraction, and you can’t just swap it out to a different kernel. Systemd is much more modular than that for example.
- lmm 6y ago
  Pre-systemd you actually could switch out the kernel on Debian - you could be running Hurd or the FreeBSD kernel, but the rest of the OS would still be Debian.
  - kaba0 6y ago
    I believe it is only correlation, not causation. I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features. But I’m not sure about this. Aren’t you referring instead to debian itself providing packages for all of them and the package manager running on each distro? Because I can’t really believe you could just swap out the kernel and be on your way in most cases. If it is the latter, than it was more due to the fact that debian maintainers voted against supporting other systems, because it is a great amount of additional work.
    - lmm 6y ago
      > I believe it is only correlation, not causation. It's a bit more direct than that - previous init systems were kernel-agnostic whereas systemd is explicitly tightly coupled to Linux and udev, and encourages the rest of userland to be tightly coupled to it. > I think it has more to do with the linux kernel being much more advanced than the others, and some of the userspace depending more and more on these advanced features. I wouldn't say "more advanced" - in many ways FreeBSD jails are a better technical solution than Linux's various container systems.
- zepearl 6y ago
  I think that lmilcin was referring to "either use systemd on distribution X or switch to another distribution". E.g. in Gentoo you can choose to use SystemD or OpenRC, but I think that most other distros don't provide such a choice.
  - kaba0 6y ago
    Most don’t provide such a choice, because it’s a huge undertaking to basically package and maintain 2+ versions of everything, especially when one is unified among distros and often created upstream. And of course after a certain size it has to do with network effects, but it was chosen based on merits — for example debian voted multiple times on the issue and I would say their voting system puts most countries’ to shame. I believe up until recently the vote on debian was basically use systemd but if the maintainer wants to, they can also support alternative init systems, but there was not much interest. But of course anyone can help the fringe distros on another init systems to make them less fringe.
    - zepearl 6y ago
      > Most don’t provide such a choice, because it’s a huge undertaking to basically package and maintain 2+ versions of everything Yes, I absolutely agree regarding the effort. (not sure about that vote - I honestly didn't follow that discussion) In parallel, some software (cannot recall - maybe the Gnome window mgr) does rely (in its original form) on SystemD being there => I don't think that's fair, kind of forcing the distros that want to offer it to adopt it => I don't like it - I do see the advantage of having that kind of integration, but I still don't like it :P
      - spiralx 6y ago
        Gnome's dependency on logind came about because there originally was a dependency on a different library that one person had written, had pretty much stopped working on, and nobody wanted to take on maintaining it or adding it to Gnome itself. The dependency no longer exists because some people took logind from systemd, made it a standalone package and called it elogind lol, and now you can use that instead of logind.
viraptor 6y ago
Or disable the elements you don't want and switch to a different implementations. What exactly are you missing right now?
- turminal 6y ago
  Switching to different implementations is getting harder with every systemd release.
  - viraptor 6y ago
    Have you got examples for what got harder to replace?
    - turminal 6y ago
      The era when running gnome or any of its derivatives without systemd comes to mind. If it weren't for Gentoo's forks of systemd components, the whole situation would be much worse in general.
  - prussian 6y ago
    I literally work on a device that is still uses an inittab (hopefully changing that in 2021). the only limiting factor is yourself. 1) eudev works 2) elogind works 3) you can still use sysvinit or literally the multitude of others
    - turminal 6y ago
      > I literally work on a device that is still uses an inittab. The fact that this is so rare it has to be pointed out like this kind of speaks for itself. > 1) eudev works 2) elogind works 3) you can still use sysvinit or literally the multitude of others. I am aware of these and use them on nearly all my machines. Note that both elogind and eudev required a significant amount of work by the Gentoo community when they were pulled out of the systemd codebase.
vetinari 6y ago
Well: http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/
- dane-pgp 6y ago
  Linux is, or at least was, about Freedom; and Freedom is about choice. You may not mind the decisions others make on your behalf, or care about the options that are no longer possible, but that doesn't mean that Linux hasn't lost some of its identity.
  - vetinari 6y ago
    Yes and no. Yes, in the sense, that if you want, you can eventually make it the way you want. No in the sense, that others won't do it for you; they will make linux distribution the way they consider it best, not how you consider it the best. So if you want to pick and choose the components the way you want and not the way the distributions consider the best, be ready to put in the manhours.
lmm 6y ago
I'd strongly recommend switching to FreeBSD. It's pretty similar to Linux of 20 years ago: some things might require a bit of manual configuration, but it's rock solid after you've done that.
- deleted 6y ago
  [deleted]
- pjmlp 6y ago
  Including graphics programming experience of GNU/Linux 20 years ago.

Nextgrid 6y ago

I mean there's always a way to configure/disable it, but a counter-argument would be that if there's an optimal solution to the OOM problem, I would prefer that all distros use it. Just like you can mostly expect filesystem behavior to be consistent no matter which distro, so should be the OOM behavior if a "good" solution is found.

gmueckl 6y ago
You can't expect filesystem to behave consistently across filesystem and media types because these exist to solve different issues and involve different design decisions. The same thing goes for out of memory handling: no size fits all. The kind of handling strategy you need depends on the kind of system you build. Exactly this kind of flexibility and lack of unification is what made Linux so ubiquitous.
- kreetx 6y ago
  I think what the OP means is that you can be in any filesystem without needing to put much thought into it (regardless of the very real differences in implementation). Advanced users who want to interface with the details can do that, but for the rest of us consistency can be good.
  - robertlagrant 6y ago
    Isn't the same level of detail needed for init as for different filesystems?
  - gmueckl 6y ago
    Except that file systems aren't consistent on Linux. FAT and NTFS can't represent Unix permission bits. File systems reorder operations internally in some ways user space programs don't expect. NFS mounts may not be able to guarantee exclusive file locks...
    - kreetx 6y ago
      Absolutely. What I'm saying is that I personally don't need to know about this. I suspect that OOM's behavior is of similar effect to most developers.

kaba0 6y ago

When we talk about an OS that on desktop has minuscule user share, it is not too clever to further fragment that. I believe there are only a handful of people who knows enough to create a proper init system (similarly, sound and graphics) and do it for the community. The alternative is that more complicated features will simply not be implemented on linux. Also, just look at the before-systemd landscape, there was much more difference in the repositories, and nowadays even more niche distros can trivially package almost everything since .service files are unified. Also, they are quite flexible, so I don’t feel that anything would be lost.

turminal 6y ago
> When we talk about an OS that on desktop has minuscule user share, it is not too clever to further fragment that. True, but desktop usage is only one of many things linux is used for. All the "unification" efforts ala systemd try to handle all of those use cases. I don't see why the init system on my server has to be the same as the one on my ultrabook, because only a fraction of what they should do is shared. Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface. > I believe there are only a handful of people who knows enough to create a proper init system (similarly, sound and graphics) and do it for the community. I don't think Linux graphics or sound situations have much in common with the init system situation, except perhaps the fact that Poettering tried to fix sound as well.
- kaba0 6y ago
  > I don't see why the init system on my server has to be the same as the one on my ultrabook, because only a fraction of what they should do is shared Well, not even the kernel should be shared —- but most of us is okay with having the same kernel, but at most configured differently. I see it the same way in the case of systemd, of course your ultra book doesn’t need I don’t know how many services, but the basics are very much the same. And to be honest, I’m happy to use the same knowledge/tools on a server machine and a laptop. > Having one tool that covers all the use cases just sounds like a very good way to increase the attack surface. That’s just security by obscurity...

marcodiego 6y ago

I really think fundamental problems should be solved the same way on major distros. Leave the exotic and creative ways for problems that are not fundamental or for minor distros. The feeling that you can solve fundamental problems the same way on any major distro is valuable.

turminal 6y ago
Agreed, but systemd is leaning very much towards "every problem should be solved the systemd way". I'm totally fine with the idea of all distros having better oom behavior (which I hope is what systemd-oomd does), but I don't like how that implies having to use systemd for a lot of other problems as well.
- addicted 6y ago
  It’s fairly clear to me that the problem isn’t that Systemd is leaning towards everything should be solved the SystemdD way. The real problem is that almost no one has been able to create alternatives to SystemD’s solutions to the vast majority of problems it chooses to tackle that are as well developed or effective as the SystemD solution.
  - dane-pgp 6y ago
    Of course, if someone did create a better way to solve these problems, but it wasn't compatible with systemD, then no one would use it, because they are locked into systemD. You might then ask why no one created these better solutions 6 years ago before systemD gained its stranglehold on distributions, but that's like asking why systemD itself didn't add all these features 6 years ago.
    - growse 6y ago
      We were all "locked into" shell scripts for service management not so long ago. Either open source and software freedom affords us endless amounts of choice and capability to create, inspect, modify and use whatever software we like, or we're all forced to use systemd against our will. Which is it? Systemd doesn't have a stranglehold over anything - that misinterprets the power dynamic. It's got large adoption, because it's actually useful.

pjmlp 6y ago

Yeah, hence why the only Linux based OSes that matter on the desktop only borrow the Linux kernel, while providing an unified experience to app developers and users.

turminal 6y ago
The unified experience of being hostile and abusive. (not sure how any of this is relevant to this discussion)