Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

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

  • Vim_User
    replied
    Originally posted by Chousuke View Post
    This post contains too much fun (FUD) not to bite...



    The scope of systemd is beyond OpenRC, and the problems it tackles are clearly defined. I am not an expert in OpenRC, but I am quite skeptical that anything based on shell scripts could robustly achieve what systemd does. Technically, you could emulate declarative configuration with shell scripts, but if the logic to actually launch processes is still imperative, the benefit is questionable.

    I'm not much of a fan of unit file syntax (some things look a bit ugly), but the idea behind them is superior.



    Several things in the above bit are not even wrong: systemd works, The "systemd suite" consists of several small programs (one of which is called systemd), and systemd (again, the suite) is extremely configurable. More so than sysvrc in fact, since it does not consist of brittle scripts with ill-defined dependencies. Want to launch two instances of a service? copy the script and hack away! Urgh.

    The thing is, systemd approaches the entire problem of system, service and resource management instead of suffering from tunnel vision and going "I just want these proccesses to run". I personally want the services to be managed by the system.

    I want my services to run, and thanks to systemd, I can reliably tell each process that is related to a service, I can stop services reliably (sysvinit can't, I don't know about OpenRC) and thanks to journald I don't have to wonder where the hell the log files are, what they are called and how they are rotated. This is of course just a small part of what systemd can do, but for me it's the most relevant.



    Blah blah conspiracy theories and (not-so) vague references to malicious intent. Destroying GNU/Linux? Red Hat is probably the most powerful driving force behind Linux adoption in enterprise systems nowadays, and the benefits trickle down to everyone.
    Systemd is not able to reliably start services that are dependent on each other without those services specifically being coded against systemd-libraries and/or DBus. So it is a fail by design, unless you make yourself dependent on those technologies.

    Leave a comment:


  • Chousuke
    replied
    This post contains too much fun (FUD) not to bite...

    Originally posted by xiando View Post
    Thank you very much for Gentoo and OpenRC and resistance to the SystemD world order gang..

    I see all these chicken little stories how systemd "tacles problems" that are somehow not solved and how we really need this big pile of donkey dung..
    The scope of systemd is beyond OpenRC, and the problems it tackles are clearly defined. I am not an expert in OpenRC, but I am quite skeptical that anything based on shell scripts could robustly achieve what systemd does. Technically, you could emulate declarative configuration with shell scripts, but if the logic to actually launch processes is still imperative, the benefit is questionable.

    I'm not much of a fan of unit file syntax (some things look a bit ugly), but the idea behind them is superior.

    Originally posted by xiando View Post
    I really honestly don't get exactly what it is supposed to do that OpenRC does not. As I see it systemd does not solve anything (exactly what is there that needed to be solved anyway?), it just merges a whole lot of good small programs into one big barely-working non-configurable blob.
    Several things in the above bit are not even wrong: systemd works, The "systemd suite" consists of several small programs (one of which is called systemd), and systemd (again, the suite) is extremely configurable. More so than sysvrc in fact, since it does not consist of brittle scripts with ill-defined dependencies. Want to launch two instances of a service? copy the script and hack away! Urgh.

    The thing is, systemd approaches the entire problem of system, service and resource management instead of suffering from tunnel vision and going "I just want these proccesses to run". I personally want the services to be managed by the system.

    I want my services to run, and thanks to systemd, I can reliably tell each process that is related to a service, I can stop services reliably (sysvinit can't, I don't know about OpenRC) and thanks to journald I don't have to wonder where the hell the log files are, what they are called and how they are rotated. This is of course just a small part of what systemd can do, but for me it's the most relevant.

    Originally posted by xiando View Post
    It is kind of sad that Gentoo is the only distribution that refuses this garbage and I really hope the Gentoo developers make a huge effort to keep OpenRC. As I see it the RedHat people who seem hell-bent on destroying GNU/Linux (just look at what they are doing to gtk+ etc) really want systemd everywhere (RH just happens to be a huge DoD contractors, backdoors anyone?) will try to make as much as possible depend on it in ways that are impossible to avoid. I hope the RH drones fail but it really depends on people doing their own research and thinking and that's not happening.
    Blah blah conspiracy theories and (not-so) vague references to malicious intent. Destroying GNU/Linux? Red Hat is probably the most powerful driving force behind Linux adoption in enterprise systems nowadays, and the benefits trickle down to everyone.

    Leave a comment:


  • xiando
    replied
    Originally posted by ryao View Post
    systemd is in our tree because 1 developer likes it, but Gentoo has not adopted it as its default. My opinion is that hell will freeze before we do. The general experience that we have had with the systemd developers is exactly what Linus said. A group of us started eudev when we decided that we could no longer tolerate it.

    By the way, you are thinking of sysvrc, not sysvinit. sysvinit is nothing more than /sbin/init and /etc/inittab. /etc/init.d is part of sysvrc. Quite frankly, I agree that sysvrc is awful. Gentoo uses OpenRC to replace sysvrc and it works very well for us. Many things systemd claimed to achieve over sysvinit were already done in OpenRC.
    Thank you very much for Gentoo and OpenRC and resistance to the SystemD world order gang.

    I see all these chicken little stories how systemd "tacles problems" that are somehow not solved and how we really need this big pile of donkey dung. I really honestly don't get exactly what it is supposed to do that OpenRC does not. As I see it systemd does not solve anything (exactly what is there that needed to be solved anyway?), it just merges a whole lot of good small programs into one big barely-working non-configurable blob.

    It is kind of sad that Gentoo is the only distribution that refuses this garbage and I really hope the Gentoo developers make a huge effort to keep OpenRC. As I see it the RedHat people who seem hell-bent on destroying GNU/Linux (just look at what they are doing to gtk+ etc) really want systemd everywhere (RH just happens to be a huge DoD contractors, backdoors anyone?) will try to make as much as possible depend on it in ways that are impossible to avoid. I hope the RH drones fail but it really depends on people doing their own research and thinking and that's not happening.
    Last edited by xiando; 04-22-2014, 02:19 AM.

    Leave a comment:


  • Gusar
    replied
    Originally posted by tpruzina View Post
    Blackcat still doesnt get the point, cups doesnt try to be anything other than it's purpose, fully featured printing server (and damn good one, scaling from smartphones to corporate network environment).
    And systemd is a damn good service manager, scaling from smartphones (SailfishOS) to corporate environments (RHEL 7). There are other, separate parts to it, but aside from the service manager itself they're pretty much all about doing things through dbus, and therefore you can use something else, provided it exposes a compatible dbus interface.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Blackcat still doesnt get the point, cups doesnt try to be anything other than it's purpose, fully featured printing server (and damn good one, scaling from smartphones to corporate network environment).
    It doesn't make applications depend on cups to be running or present.
    Also, you are not just talking API compatibility, you talking ABI compatibilty for your "plug and play" to work.
    And having multiple libraries to do the same thing is 'curse' of OSS system, I would argue it's a good thing, if you want one way to do it all, just get Windows.

    Leave a comment:


  • Gusar
    replied
    Originally posted by gens View Post
    you can, read last post
    if you still are thinking about API, think about how you can make a wrapper for it instead
    Well, ok, but two things: One, like I mentioned, in practice such wrappers are the exception (the example I gave with libedit/readline; gnutls has an openssl compatibility wrapper; while there might be a few more, I'm not aware of any).

    And two, the original point was that it's supposedly bad for software to directly depend on systemd. If we take wrappers as a valid option and as an argument that everything is exchangeable, then the original point is moot - because with the magic word "wrapper", a software's dependency on systemd is no more.
    Last edited by Gusar; 04-17-2014, 12:33 PM.

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    Again, what relevance does this have? The point is that you can't simply switch out libraries and app is using. How does describe the workings of alsa change this point?
    you can, read last post
    if you still are thinking about API, think about how you can make a wrapper for it instead

    Leave a comment:


  • Gusar
    replied
    Originally posted by gens View Post
    how about you stop thinking i'm out to get you
    What makes you think I think that? But you do write generic descriptions on how something works, as if I don't know these things already.

    Originally posted by gens View Post
    alsalib, like i said, supports modules

    one of them, and the best example here, is direct to file "routing"
    meaning you dont even need alsa in the kernel to use alsa
    it would not be hard to write a plugin to send sound over the network directly without a sound server or a compile time framework
    Again, what relevance does this have? The point is that you can't simply switch out libraries and app is using. How does describe the workings of alsa change this point?

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    How does a wrapper help when the app interfaces with libjpeg directly?

    This is a public forum, not a private conversation between two people.
    there is no "libjpeg" server running
    a library is an ELF file
    elf is basically a header saying "theres this and that in this file"

    for example you make a shared object like

    //whatever goes here

    open(*file_name, flags, what_goes) {
    printf("file %s was opened\n", *file_name)
    sys_open(*file_name, flags, what_goes)
    }

    and you run your program like
    LD_PRELOAD="./haxed_open.so" program

    hint: objdump -T /some/bin




    on the other thing you stated "me", so next time use "us"
    Last edited by gens; 04-17-2014, 12:16 PM.

    Leave a comment:


  • gens
    replied
    Originally posted by Gusar View Post
    And again with the stupid tone. What makes you think I don't know all of this already? And what relevance does it have? Fact remains, unless you decide to use an abstraction framework or sound server in your app, you'll have code that directly interfaces with alsa-lib, and playing sound by some other method requires writing new code for your app.
    how about you stop thinking i'm out to get you

    alsalib, like i said, supports modules

    one of them, and the best example here, is direct to file "routing"
    meaning you dont even need alsa in the kernel to use alsa
    it would not be hard to write a plugin to send sound over the network directly without a sound server or a compile time framework

    Leave a comment:

Working...
X