10 ms·

Thing is, why is systemd so reliant on dbus? A bus introduced to handle signaling between desktop programs. Things used to be done kernel up. But these days it

Thing is, why is systemd so reliant on dbus? A bus introduced to handle signaling between desktop programs. Things used to be done kernel up. But these days it seems that things are happening DE down. Meaning that where before if the kernel came up, i had a reasonable chance of getting a shell and firing up everything else i needed from there. But these days if you don't get to the display manager you may as well hit the reset button, because something between the kernel and the display has gotten is panties so much in a twist that there is only the Windows solution.

snaky 10y ago
Because it's the same gang of people. > Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)
- deleted 10y ago
  [deleted]
natermer 10y ago
> Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with most important: 1. User's needs/wants 2. User's applications 3. User's operational environment 4. application APIs 5. OS services 6. OS Kernel. The point of a OS is to make it easier to write and run applications. That is it. The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere. GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down. Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.
- erpellan 10y ago
  > Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000 Citation needed.
- notalaser 10y ago
  I'm not a fan of the kernel-up/desktop-down dichotomy, but please remember that "1. User's needs/wants and 2. User's application" are a) not necessarily desktop applications (in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications) and b) depend on systems software, which is anything but pleasant to write and integrate with community non-players like systemd. This binary, "user needs = true, programmer needs = irrelevant" dichotomy is very toxic to an environment that still, by and large, depends on community support for its existence.
  - rkangel 10y ago
    > in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications Don't forget that by device count, by far the largest deployment of Linux is Android. Technically not 'desktop', but close enough in this categorisation.
    - notalaser 10y ago
      I stand corrected :-). However, Android is far more restrictive in the type of applications that run on it and in the type of environment that they run in, and runs a very different stack of system tools (which doesn't include systemd). My exposure to writing Android applications is far too limited to comment on the matter without making a fool of myself.
    - pjmlp 10y ago
      Despite what many think, Android is not the same as GNU/Linux. The NDK is so constrained, with quite a few API features removed (e.g. no UNIX IPC APIs), that Google could replace the kernel by something else and only the OEMs would notice. Access to native code is only there for games and implementing Java native methods. Google likes it so much that Brillo makes these constraints even more explicit, although it is all native code.
nialv7 10y ago
I don't understand your complain... I can boot a current day kernel with init=/bin/sh just fine.
- JdeBP 10y ago
  But, in contrast, you cannot shut it down just fine without being really careful. * http://unix.stackexchange.com/a/195978/5132 http://unix.stackexchange.com/a/195978/5132 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * http://askubuntu.com/a/638165/43344 http://askubuntu.com/a/638165/43344
  - snaky 10y ago
    If not the patch from Linus himself, firmware loading would stay impossible without (broken) udev - https://lwn.net/Articles/518942/ https://lwn.net/Articles/518942/
    - digi_owl 10y ago
      Ah yes, use external leverage to force a parallelization of kernel code that worked just fine, and damn reliably, in serial form. What is it with userspace devs an a fetish for paralleliation?!
      - snaky 10y ago
        That's not how it works with free software. Patches are welcome, force is not.
      - paulddraper 10y ago
        Performance on these new fangled multi-core machines kids are using these days.
tymb 10y ago
systemd is reliant on dbus because Lennart Poettering's philosophy on Unix is slightly different than the philosophy of a great many other people. The quote here (https://www.linuxvoice.com/interview-lennart-poettering/ https://www.linuxvoice.com/interview-lennart-poettering/) summarizes it: What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was! Pid Eins goes through his own "mythbusting" around the concept that systemd is not consistent with the Unix philosophy: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html But Ken Thompson and the people who were around him had a different view. http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html (Doug McIlroy) (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. If you look through the abstracted rules esr proposes, they are often in complete contravention of the philosophy of systemd. The number of things systemd has broken by design or accident is quite substantial. The amount of things it touches in Linux is significant. It's pretty stunning to me that even experienced developers don't see anything wrong with systemd - it has had profound effects on system reliability, performance, usability, etc, most of them extraordinarily negative, for a benefit that is unclear. I think if the scope had been smaller, the vehement disagreement with the implementation/principles behind systemd would probably have been mitigated quite a bit. We are where we are. For better or for worse, systemd is taking over many Linux distributions, put there by people who have a very different view of what Unix is about. The people that support systemd are more or less supporting similar principles as Microsoft espoused for many years - an integrated system so tightly put together that it becomes difficult to tease things apart or to understand the working of the system, and an additional giant SPOF - something early Linux advocates protested about so vehemently. Those of us who know the difference use alternative distributions or BSD, the former of which is becoming harder as package maintainers and software authors are relying on systemd more and more. To be fair, commercial Linux is where the money is, and all this plays directly into Red Hat's business model. Funny, how in the end we adopt the same methods and principles we so vociferously argued against.

snaky 10y ago

Because it's the same gang of people. > Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)

deleted 10y ago
[deleted]

natermer 10y ago

> Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with most important: 1. User's needs/wants 2. User's applications 3. User's operational environment 4. application APIs 5. OS services 6. OS Kernel. The point of a OS is to make it easier to write and run applications. That is it. The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere. GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down. Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.

erpellan 10y ago
> Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000 Citation needed.
notalaser 10y ago
I'm not a fan of the kernel-up/desktop-down dichotomy, but please remember that "1. User's needs/wants and 2. User's application" are a) not necessarily desktop applications (in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications) and b) depend on systems software, which is anything but pleasant to write and integrate with community non-players like systemd. This binary, "user needs = true, programmer needs = irrelevant" dichotomy is very toxic to an environment that still, by and large, depends on community support for its existence.
- rkangel 10y ago
  > in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications Don't forget that by device count, by far the largest deployment of Linux is Android. Technically not 'desktop', but close enough in this categorisation.
  - notalaser 10y ago
    I stand corrected :-). However, Android is far more restrictive in the type of applications that run on it and in the type of environment that they run in, and runs a very different stack of system tools (which doesn't include systemd). My exposure to writing Android applications is far too limited to comment on the matter without making a fool of myself.
  - pjmlp 10y ago
    Despite what many think, Android is not the same as GNU/Linux. The NDK is so constrained, with quite a few API features removed (e.g. no UNIX IPC APIs), that Google could replace the kernel by something else and only the OEMs would notice. Access to native code is only there for games and implementing Java native methods. Google likes it so much that Brillo makes these constraints even more explicit, although it is all native code.

nialv7 10y ago

I don't understand your complain... I can boot a current day kernel with init=/bin/sh just fine.

JdeBP 10y ago
But, in contrast, you cannot shut it down just fine without being really careful. * http://unix.stackexchange.com/a/195978/5132 http://unix.stackexchange.com/a/195978/5132 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * http://askubuntu.com/a/638165/43344 http://askubuntu.com/a/638165/43344
- snaky 10y ago
  If not the patch from Linus himself, firmware loading would stay impossible without (broken) udev - https://lwn.net/Articles/518942/ https://lwn.net/Articles/518942/
  - digi_owl 10y ago
    Ah yes, use external leverage to force a parallelization of kernel code that worked just fine, and damn reliably, in serial form. What is it with userspace devs an a fetish for paralleliation?!
    - snaky 10y ago
      That's not how it works with free software. Patches are welcome, force is not.
    - paulddraper 10y ago
      Performance on these new fangled multi-core machines kids are using these days.

tymb 10y ago

systemd is reliant on dbus because Lennart Poettering's philosophy on Unix is slightly different than the philosophy of a great many other people. The quote here (https://www.linuxvoice.com/interview-lennart-poettering/ https://www.linuxvoice.com/interview-lennart-poettering/) summarizes it: What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was! Pid Eins goes through his own "mythbusting" around the concept that systemd is not consistent with the Unix philosophy: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html But Ken Thompson and the people who were around him had a different view. http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html (Doug McIlroy) (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. If you look through the abstracted rules esr proposes, they are often in complete contravention of the philosophy of systemd. The number of things systemd has broken by design or accident is quite substantial. The amount of things it touches in Linux is significant. It's pretty stunning to me that even experienced developers don't see anything wrong with systemd - it has had profound effects on system reliability, performance, usability, etc, most of them extraordinarily negative, for a benefit that is unclear. I think if the scope had been smaller, the vehement disagreement with the implementation/principles behind systemd would probably have been mitigated quite a bit. We are where we are. For better or for worse, systemd is taking over many Linux distributions, put there by people who have a very different view of what Unix is about. The people that support systemd are more or less supporting similar principles as Microsoft espoused for many years - an integrated system so tightly put together that it becomes difficult to tease things apart or to understand the working of the system, and an additional giant SPOF - something early Linux advocates protested about so vehemently. Those of us who know the difference use alternative distributions or BSD, the former of which is becoming harder as package maintainers and software authors are relying on systemd more and more. To be fair, commercial Linux is where the money is, and all this plays directly into Red Hat's business model. Funny, how in the end we adopt the same methods and principles we so vociferously argued against.