Page 1 of 6 123 ... LastLast
Results 1 to 10 of 55

Thread: Systemd 198 Brings "Many Big Changes"

  1. #1
    Join Date
    Jan 2007
    Posts
    14,799

    Default Systemd 198 Brings "Many Big Changes"

    Phoronix: Systemd 198 Brings "Many Big Changes"

    Lennart Poettering has announced the release of systemd 198, which he describes as bringing "many big changes" to this common Linux system service and session manager...

    http://www.phoronix.com/vr.php?view=MTMyMTY

  2. #2
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    I guess the real question is, What is it that systemd is -not- trying to be?

    It tries to be everything and yet it isnt good at anything.... I hate it.... It's ruining Linux....

    I wish LP would disappear. All he manages to write is buggy bloatware.

  3. #3
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by duby229 View Post
    It tries to be everything and yet it isnt good at anything....
    What does it do that it doesn't do the best?

  4. #4
    Join Date
    Dec 2010
    Posts
    45

    Default

    At this point my only gripe with systemd is that the configuration syntax sucks. It would be nice to be able to define multiple units in a single file, a good example would be a .socket and .service file. This probably wouldn't be popular but a limitted syntax for expressing things like conditionals would be more aesthetically pleasing than the ConditionXXX= settings along with the rest of the flat config items.

    I think I'd also prefer if they kept things like udev, logind, and journald in seperate repositories, but hey, I'm not the one burdened with maintainership so I can't complain too much.

    Other than that, systemd is a solid piece of software. A lot of times something that I start out thinking is a systemd bug turns out to be uncovering a bug in other software that I wouldn't have noticed otherwise.

    So, other than the awkward configuration, systemd gives me more control over my system and that's my bottom line.

  5. #5
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    458

    Default

    In short, systemd/systemctl are working to match up with launchd/launchctl capabilities from OS X. Good. It's been needed for a long time.

  6. #6
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,030

    Default

    Quote Originally Posted by duby229 View Post
    I wish LP would disappear. All he manages to write is buggy bloatware.
    PulseAudio and systemd running here, running fine.

  7. #7
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,303

    Default

    Ive been using systemd for a while now and havent been getting any issues at all, I think it works quite nicely. I do prefer the old fashioned comfig method but at least systemd has GUI tools to make the transition easier. IMO it makes booting noticably faster.

  8. #8
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by duby229 View Post
    I guess the real question is, What is it that systemd is -not- trying to be?

    It tries to be everything and yet it isnt good at anything.... I hate it.... It's ruining Linux....

    I wish LP would disappear. All he manages to write is buggy bloatware.
    I couldn't disagree more, systemd is far superior to the shitty hacked together bash scripts of previous init systems. Both sytemd and pulseaudio have significantly improved my linux experience.

  9. #9
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,890

    Default

    Quote Originally Posted by duby229 View Post
    I guess the real question is, What is it that systemd is -not- trying to be?

    It tries to be everything and yet it isnt good at anything.... I hate it.... It's ruining Linux....

    I wish LP would disappear. All he manages to write is buggy bloatware.
    Yeah duby you really dont have a leg to stand on....

    1) What is systemd trying to be? CoreOS. Thats been the expressed intent for a long time. Systemd is trying to remove all the fragmentation and random BS that exists at the lowest levels of the linux stack, so that the important work can keep going without worrying about random distro differences for things that shouldnt matter. (Such as where the hostname gets set, just as an example)

    2) "buggy bloatware" uh huh.... PulseAudio was buggy when it came out, sure...if you used ubuntu who packaged a pre-alpha version and called it stable. Pulse has been working just fine, gradually getting better and better since about 3years ago.

    Bloatware? Systemd is about as modular as you can get... Everything is a compile time flag, and nothing conflicts with existing solutions other than systemd vs sysv vs openrc and thats because only 1 program can register as 'init' and can claim to be PID 1. Even the journal doesn't conflict with syslog. Systemd has 2 mandatory components: systemd, journald, and udev-- and the last one you probably have on your system already.

    3) Ruining Linux? By what? Removing the fragmentation and inconsistencies? By getting rid of shell scripts and replacing them with flat ini files? If you want to argue against systemd, then bring specific technical faults with specific examples. Otherwise shutup, sit down, and let the people who actually UNDERSTAND whats going on do what they've set out to do.

  10. #10
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,551

    Default

    Those are really nice additions. Integration with the bootloader makes a lot of sense, it's an integral part of the booting process, and that's exactly what systemd is handling. And no longer needing to install Python for boot time analysis is definitely an added bonus.

    Quote Originally Posted by Ericg View Post
    Everything is a compile time flag, and nothing conflicts with existing solutions other than systemd vs sysv vs openrc and thats because only 1 program can register as 'init' and can claim to be PID 1.
    Not even that conflicts. Systemd has compatibility with OpenRC, uses some of its configuration and could even execute its script files. As for registering as init, it's directly controlled by the kernel "init" option. The user has to explicitly add it there, one way or another. So it's not a conflict, but a configuration option.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •