Announcement

Collapse
No announcement yet.

Arch Linux Is Switching To Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • WorBlux
    replied
    Originally posted by Ibidem View Post
    You mean we should move init into the kernel? Linux isn't a microkernel, after all. :P
    A daemon/server is the wrong way to handle hardware events, IMHO. Linux actually provides a much cleaner and simpler approach which udev ignores:
    a hotplug "helper" command, set up by (example)
    Code:
    echo /sbin/mdev >/proc/sys/kernel/hotplug
    This is what mdev does.
    Fine for embedded systems with a few known a and tested components. You save resources and overhead, but you can get race conditions and and a lot of process forking. Using a socket to daemon helps guarantee consistency.

    Being able to start/stop services based on hardware events seems to be a pretty handy thing. (Why the heck does ubuntu on a desktop still bring up the battery monitoring service? Or bluetooth, when you have no Bluetooth adapters connected?)

    Interestingly enough the hotplug executable is considered the child of PID 1 when created.
    Originally posted by Ibidem View Post
    I can't speak for "the average developer", but I can write a working init.d script in a few minutes, and have a pretty good expectation of it working right. Also you can do some testing in regular userland, depending on the daemons involved...
    No experience with unit files.
    That works for the quirks of every disto?
    Originally posted by Ibidem View Post
    Then why is KMS so highly esteemed?
    And what's the point of Modular Xorg?
    KMS gives you a little more control and handle errors better.
    X was modular to maintainability issues, and to make it possible to use some parts of x in an embedded system. No X is being pulled into different projects and slowly being killed. However at the time it make sense to smash as of this common and vital functionality together.

    Originally posted by Ibidem View Post
    Unix also has several other approaches to IPC (for example, sockets...). Some of those are well-suited to this scenario.
    Which systemd does use. It opens up a socket and buffer even before a service is finished initializing.
    Originally posted by Ibidem View Post
    A single large program with 5 functions and 5 options per function will have 25 options. The number of ways those can be combined is pretty large (several million if you use up to 10 options). A single binary (in one address space) has potential for various problems that multiple binaries (= multiple address spaces) may not face. So you have a chance of hitting an untested corner case.
    If each program uses a defined interface (the point of standardization), you can have ~30 possible combinations of flags per program, giving 160 scenarios to test, as long as each program properly handles the interfaces.(Note: if buffer overflows and such bugs were impossible, the same would be true of a particularly modular single binary. Unfortunately, they aren't impossible.)
    If you don't use a defined interface, you're doing something wrong.

    Now there are some things systemd is doing right/modularly. But when init might get its own copy of fsck (quote not handy, but ISTR something about plans for that that on Poettering's website), there is something that's _not_ modular. And with 10+ different filesystems on Linux, that's simply a bad idea.
    In fact, I consider any project where that could be considered to be too misguided to trust with critical system components.
    I would like to see the source/quote, google's not finding it for me.

    There is an fsck service, which does essentially the same thing as the fsck init script.

    If anything I'd imagine if there was it's own copy, it would be a straightfoward fork that could be passed arguments via a socket, rather than needing some sort of shell. I can't imagine why they'd need or want to touch the functional logic of it.

    Leave a comment:


  • Ancurio
    replied
    This is it. I am officially switching back to Yggdrasil.

    Leave a comment:


  • elanthis
    replied
    Originally posted by Ibidem View Post
    Then why is KMS so highly esteemed?
    Because the kernel actually needs to control video modes for its own purposes, such as VT switching, early boot up, OOPS messages, debugging, etc.

    There's also a reason that only KMS has been moved into the kernel, and all the meat of the video services are still in userland where they belong.

    The kernel has no need to play OGGs or such directly itself. Only your applications need that. Hence, there is no need for any portion of the sound server to be in the kernel, aside from the raw hardware interface bits.

    Leave a comment:


  • Ibidem
    replied
    Originally posted by WorBlux View Post
    Yes, it's designed to be the core system.

    Is there really a good reason to seperate device management from service management.
    You mean we should move init into the kernel? Linux isn't a microkernel, after all. :P
    A daemon/server is the wrong way to handle hardware events, IMHO. Linux actually provides a much cleaner and simpler approach which udev ignores:
    a hotplug "helper" command, set up by (example)
    Code:
    echo /sbin/mdev >/proc/sys/kernel/hotplug
    This is what mdev does.
    System logger -- curent system loggers don't really log all that well. Improvements can be made. By integraging the interface into the init system, you can verify what process a message is actually from. Rotation is integral rather than an afterthought cron process. Both things are hard to do well unless you have interface built into the init system to do so.

    Session manager. Probably extraneous but also modular and optional. I can see the advantage of having the session manager talk to the init. On systems setup for single user or to autologin, having this crosstalk can prioritize services needed to get to a usable session first.
    Linux however especially on the desktop is moving away from Unix. The kernel is budding some really cool features, let's make use of them to solve problems traditionally associated with Unix.

    From a developers perspective a single unit file is a lot easier to make than a dozen different system V scripts.
    I can't speak for "the average developer", but I can write a working init.d script in a few minutes, and have a pretty good expectation of it working right. Also you can do some testing in regular userland, depending on the daemons involved...
    No experience with unit files.
    In addition some of the most Unix of programs weren't designed that way. Take X for instance. It used to do gpu mode-setting, input handling, graphic memory management and a whole lot of other stuff.. It simply made sense to do it that way as it solved a lot of problems.
    Then why is KMS so highly esteemed?
    And what's the point of Modular Xorg?
    The primary UNIX philosophy is to do what works. You don't necessarily want small programs piped together where the inter-process communication is not linear and unidirectional.
    Unix also has several other approaches to IPC (for example, sockets...). Some of those are well-suited to this scenario.

    A single large program with 5 functions and 5 options per function will have 25 options. The number of ways those can be combined is pretty large (several million if you use up to 10 options). A single binary (in one address space) has potential for various problems that multiple binaries (= multiple address spaces) may not face. So you have a chance of hitting an untested corner case.
    If each program uses a defined interface (the point of standardization), you can have ~30 possible combinations of flags per program, giving 160 scenarios to test, as long as each program properly handles the interfaces.(Note: if buffer overflows and such bugs were impossible, the same would be true of a particularly modular single binary. Unfortunately, they aren't impossible.)
    If you don't use a defined interface, you're doing something wrong.

    Now there are some things systemd is doing right/modularly. But when init might get its own copy of fsck (quote not handy, but ISTR something about plans for that that on Poettering's website), there is something that's _not_ modular. And with 10+ different filesystems on Linux, that's simply a bad idea.
    In fact, I consider any project where that could be considered to be too misguided to trust with critical system components.

    Leave a comment:


  • WorBlux
    replied
    Originally posted by TobiSGD View Post
    The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
    The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.

    This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

    IMHO, with the change to systemd Arch developers have lost any reason to keep this line on their Wiki:

    I am glad the the developers of my preferred distro are not willing to make the change to systemd, because they really follow the KISS principle and the Unix philosophy.
    Thanks, Mr. Volkerding.
    Yes, it's designed to be the core system.

    Is there really a good reason to seperate device management from service management.

    System logger -- curent system loggers don't really log all that well. Improvements can be made. By integraging the interface into the init system, you can verify what process a message is actually from. Rotation is integral rather than an afterthought cron process. Both things are hard to do well unless you have interface built into the init system to do so.

    Session manager. Probably extraneous but also modular and optional. I can see the advantage of having the session manager talk to the init. On systems setup for single user or to autologin, having this crosstalk can prioritize services needed to get to a usable session first.

    Linux however especially on the desktop is moving away from Unix. The kernel is budding some really cool features, let's make use of them to solve problems traditionally associated with Unix.

    From a developers perspective a single unit file is a lot easier to make than a dozen different system V scripts.

    In addition some of the most Unix of programs weren't designed that way. Take X for instance. It used to do gpu mode-setting, input handling, graphic memory management and a whole lot of other stuff.. It simply made sense to do it that way as it solved a lot of problems.

    The primary UNIX philosophy is to do what works. You don't necessarily want small programs piped together where the inter-process communication is not linear and unidirectional.

    Leave a comment:


  • ninez
    replied
    Originally posted by liam View Post
    We recently had a pretty major linux audio dev (apparently involved with rosegarden and jack;if nine zis reading this he could tell us more specifics) commenting on the thread about Klang. He discussed pulseaudio and seemed to understand why Lennart made the decisions he did. Given the limitations of Alsa, pulse was the best we could do. It works around Alsa where it can and gives us a modern sound server which, if alsa drivers could be fixed (apparently an enormous undertaking, according to the dev), would give us something very similar to coreaudio functionality.
    That seems pretty impressive to me.
    Funnily enough - I am reading it, liam

    Paul Davis isn't involved with RoseGarden, but is the Original Author/Designer of Jack audio connection kit, as well as the Daw; Ardour (cross-platform, Mac and Linux - if you include the Work Done jointly by Harrsion Consoles, their version called 'Mixbus' then there is a Windows port, as well). He has also been involved in some other projects, Notably; he was one of 2 of the original programmers who helped start Amazon.com.

    http://en.wikipedia.org/wiki/Paul_Da...8programmer%29
    http://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
    http://ardour.org/
    http://jackaudio.org/

    I've also via the jack-dev-list heard him discuss other low-level plumbing he had been involved with in the past, although i can't remember all of the specifics (something to do with schedulers, but i don't think it was to do with linux). he is definitely a very intelligent, talented programmer (among other areas of expertise, which are listed in Wikipedia). The guy really knows his stuff.

    Paul in the KLANG thread (page 5-7);
    http://phoronix.com/forums/showthrea...e-Kernel/page5

    cheerz!
    Last edited by ninez; 08-15-2012, 06:02 PM.

    Leave a comment:


  • curaga
    replied
    So you are saying he refuses to take any advice? Can you provide some evidence for that?
    Sorry, I don't have any links at hand. Basically just what I've read around on lwn and other places.

    From memory it went something like "bsd can go die", "udev without systemd is deprecated and will be impossible in the future", paraphrasing.


    I don't know what Ulrich and Joerg have created but I don' lt know that it matters.
    Joerg Schilling made cdrtools, the best burning kit around for something like 15 years and going. The one all the GUIs used. I haven't had a single bad burn using cdrecord in all this time, where competitors (Nero on Windows, wodim on Debian) have given me coasters.

    Ulrich Drepper coded most of glibc.

    Both are generally considered to be jerks. But the difference to Lennart is that their products are actively useful, and haven't harmed even close to as many people as Pulse alone.

    Leave a comment:


  • liam
    replied
    Originally posted by curaga View Post
    He's not obnoxious like the other luminaries, but he does have a "my way or the highway" thing. Just read his comments on linux, bsd, udev, or a variety of other topics.

    At least Joerg and Ulrich made good software, not something that broke things for a lot of people.
    So you are saying he refuses to take any advice? Can you provide some evidence for that? From what I've read of his conversations he will seemingly engage almost endlessly with someone. If in the end he isn't convinced, at leqst he seems to be engaging with those who offer genuine, technical critiques.
    About his "my way or the highway" methor, assuming that it is actually the casel that would only matter if he headed projects for which no alternatives exist. In point of fact he only works on plumbing level functions where he feels linux could be improved. He's not a distro leader, or a project leader of any kind except for the software he is currently working on (pulseaudio is now mostly handled by others like Arun).
    I don't know what Ulrich and Joerg have created but I don' lt know that it matters. Lennart is a serious developer who wants to make the linux desktop better. No one's code is perfect but he seems to make the right high level decisions. Consider pulseaudio. We recently had a pretty major linux audio dev (apparently involved with rosegarden and jack;if nine zis reading this he could tell us more specifics) commenting on the thread about Klang. He discussed pulseaudio and seemed to understand why Lennart made the decisions he did. Given the limitations of Alsa, pulse was the best we could do. It works around Alsa where it can and gives us a modern sound server which, if alsa drivers could be fixed (apparently an enormous undertaking, according to the dev), would give us something very similar to coreaudio functionality.
    That seems pretty impressive to me.

    Leave a comment:


  • curaga
    replied
    He's not obnoxious like the other luminaries, but he does have a "my way or the highway" thing. Just read his comments on linux, bsd, udev, or a variety of other topics.

    At least Joerg and Ulrich made good software, not something that broke things for a lot of people.

    Leave a comment:


  • ShadowBane
    replied
    Originally posted by liam View Post
    He designed pulseaudio but he's only a developer, distros could either take it or not. If there was a problem blamw the distros like you would for anything else since, ultimately, they are responsible for breakage.
    I don't think it's his personality since he seems pretty mild-mannered, especially as compared to some of our luminaries
    People seem to miss the fact that nothing depended on it until pulse became widely adopted. Also, distros don't adopt things unless they think it will benefit the end user, so there obviously was a perceived problem that PA solved.

    I will agree with the personality assessment as well. Even in that one talk when that guy who wants to write KLANG was bashing all of his stuff he seemed to be rather calm about it (well, he did seem to get a little annoyed as it went further in, but the guy had been spewing FUD and bad info for the better part of half an hour by that point.)

    Leave a comment:

Working...
X