Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 55

Thread: Systemd 198 Brings "Many Big Changes"

  1. #31
    Join Date
    Jul 2012
    Posts
    287

    Default

    Quote Originally Posted by duby229 View Post
    It's less compatible.
    It more complex.
    It does waaaaaayyyy more than service management.
    It doesnt do service management very well.
    It -IS- buggy.
    It is compatible. It is not buggy. Service management is very good (stderr output ftw!). Consistent killing + process tracking ftw. Have you actually ever administrated a sysvinit server? Never ran into the various issues or problems that just don't exist with systemd?

    Please stick to facts. I used systemd, I'm looking forward to RHEL7 with systemd.

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

    Default

    Quote Originally Posted by Nobu View Post
    systemd supports init scripts, so you don't *need* to write new scripts.

    I don't see why the opposite (an init script which reads systemd units and acts based on their content) can't be true. ;p

    Of course, it'd probably be really complicated, and you'd be better off writing a binary for your own OS which parses systemd units. To each his own, I guess. But since Linux OSs are the only ones which are using systemd (and not all of them are), and other init systems are so much better, you shouldn't have any trouble finding scripts for your OS. And if you do, since they're so easy to write, you can just make one on the fly, right?

    If you are just going to be using sysvinit compatible scripts anyway then what is the point? In that case all you've done is replaced a simple portable compatible and stable system with one that is complex nonportable incompatible and buggy.

    So what then is the point?

  3. #33
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by Ericg View Post
    "Breaks compatibility" ? It can run rc scripts just fine, you just dont get the bonuses of systemd. "They have to be written" So what? Unit files are like 10 lines of code. "They change syntax for no other reason than to change it" No they dont. They add in syntax to unit files but they dont CHANGE the syntax. Backwards compatibility exists.


    And all of this is somehow considered a good thing?



    It has the expressed and explicit goal of being a LINUX project. Not unix. If FreeBSD wants to adopt systemd all they have to do is bring the same features to their kernel that the linux kernel does. But systemd's development wont be held back because FreeBSD doesnt have developers.



    Modularity beyond any extreme, and perfectly compatibile with existing solutions. Its goal hasn't been to do just service management for years, and the developers have been honest about that.



    It does service management perfectly well... Zero problems with services since early F15



    All software is buggy. Welcome to the real world-- nothings perfect. SysV wasn't either.



    It replaces it with declarative, ini style configs. It tells systemctl what it wants to do, and systemctl manages it.



    When it became buggy and ugly and not cross-distro, when all the differences in the distro started having to write their own rc scripts because the differences couldnt be abstracted at the shell level.



    True, but sometimes "the simplest way" is also the cop-out, half-assed way-- welcome to SysV.
    My last post could be copy and pasted as a reply to your post as well.

  4. #34
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,889

    Default

    Quote Originally Posted by duby229 View Post
    If you are just going to be using sysvinit compatible scripts anyway then what is the point? In that case all you've done is replaced a simple portable compatible and stable system with one that is complex nonportable incompatible and buggy.

    So what then is the point?
    You keep shouting that systemd is buggy like sysv wasn't. Seriously have you EVER worked on a sysv system when you had to edit RC scripts or run it on a server? SysV is ugly and kludging by design.

    Its non-portable because its using features of the linux kernel. Do you know how to limit apache's processes to not use up all your resources under "Traditional unix"? You attach a nice level to the process. Well that...kind of works. I mean, apache is about 15 different processes when its idle, and up to infinite under load so thats a whole lot of nice level editting. You know how you do it under systemd? Via cgroups-- apache cant escape its own cgroup, the kernel makes sure of that. The problem? cgroups are linux specific.

    SysV was simple in that it was minimal...and that minimalism came at the price of pushing all the "hard" tasks to the clients-- clients who didnt necessarily have experience to do those hard tasks correctly.

    Offtopic: The minimalism and simplicity is the same argument of Xorg vs Wayland-- Xorg being monolithic and Wayland minimal. I bring this up because I'm sure someone is gonna call me out for being a supporter of 'minimal' wayland and being against 'monolithic' xorg, while at the same time being a supporter of 'monolithic' systemd and being against minimal 'sysV.' Why the difference stances? Experience.

    SysV's minimalism pushed the hard tasks to clients-- the applications who dont / cant care about minor differences in platforms or who dont have the experience to debug early boot problems from service management. That was wrong, the clients werent experienced enough to handle the hard things sysV shoved onto them.

    In the Wayland world its the opposite. Who are waylands clients? Graphics developers, window manager writers, people who have worked on low-level code before and are experienced with low-level design, architecture and implementation. Its okay to push the hard tasks to them, they're used to it.

    Its also the case of the init system can change over night and no one is gonna care, its meant to be abstracted away anyway. So getting init's design "wrong" is kind of like "Eh, whatever. We'll replace it and get it right." If systemd is the wrong approach, time will show. How long did it take systemd to supplant upstart and sysv? like 5years? and that was from "ive got an idea" to linux-domination. The display server on the other hand, isnt abstracted away and so it cant change over night. 5 years later and Wayland still isn't being used mainstream-ly. In that case, minimalism is key, simplicity is key.

    2 very different problems, 2 very different solutions.

    EDIT: Why use the rc scripts? You're not SUPPOSED to use the rc scripts. The compatibility is there for a stop-gap measure. Unit files are so much nicer, they dont make me want to claw my eyes out trying to read and debug.
    Last edited by Ericg; 03-08-2013 at 05:21 PM.

  5. #35
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    One of the things I do is I maintain the network for a medical management company. We serve out a popular commercial web app to our customers that handle patient appointments and records. It even handles office management for them. Of course this is on a firewalled VPN and we don't get heavy traffic. None the less I know exactly what I'm doing. Our apache servers are on freebsd. Our thinclient servers are on linux which in turn acts as a gateway to a cluster of windows terminal servers that serve out a few legacy windows clients. the actual physical workstations boot up to a minimal linux that does nothing more than run the terminal client.

    The workstations damn sure don't need systemd. Neither do the terminal servers, and it isnt capable of running on the apache servers. I didnt design the network I inherited it, and now I am in a position of maintaining it.

    EDIT: you mentioned the bloat that has been going into the linux kernel as a justification for the bloat that systemd employs... I'm sorry but I can't agree with that either..... Bloat is bad no matter where it's being put.
    Last edited by duby229; 03-08-2013 at 05:39 PM.

  6. #36
    Join Date
    Oct 2010
    Posts
    436

    Default

    Quote Originally Posted by duby229 View Post
    If you are just going to be using sysvinit compatible scripts anyway then what is the point? In that case all you've done is replaced a simple portable compatible and stable system with one that is complex nonportable incompatible and buggy.

    So what then is the point?
    Wait, are they compatible or not? You're contradicting yourself. That still leaves complex, nonportable, and buggy, I guess.

    I'll give you nonportable--that's necessitated by the design.
    It's a lot simpler than a bunch of scripts which each do the same thing that systemd does, honestly. Most of what you might want to change in an init script should be simply configured, and everything else can be written into the program itself, or some other program that is designed for that purpose. De-duplication of effort, and all.

    Buggy? I haven't encountered any bugs...at all, on any OS that used systemd, since it has become stable. That doesn't mean there are none, but I'm sure if there are any that they're easier to find, and fix, for all consumers of systemd, than it is to fix each little init script on every OS individually, taking into account each one's distribution specific changes.

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

    Default

    Quote Originally Posted by duby229 View Post
    One of the things I do is I maintain the network for a medical management company. We serve out a popular commercial web app to our customers that handle patient appointments and records. It even handles office management for them. Of course this is on a firewalled VPN and we don't get heavy traffic. None the less I know exactly what I'm doing. Our apache servers are on freebsd. Our thinclient servers are on linux which in turn acts as a gateway to a cluster of windows terminal servers that serve out a few legacy windows clients. the actual physical workstations boot up to a minimal linux that does nothing more than run the terminal client.

    The workstations damn sure don't need systemd. Neither do the terminal servers, and it isnt capable of running on the apache servers. I didnt design the network I inherited it, and now I am in a position of maintaining it.
    OK? I don't see anyone trying to get you to use systemd everywhere. We are just trying to say that systemd is a good system that deserves being the default startup manager for all the distributions that use it. It has advantages over the alternatives, but it's not like they are required by everyone. If you don't need them, well, good for you. I know I need them. There is just no reason to try and make up flaws in systemd where there are none in the first place.

  8. #38
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by Nobu View Post
    Wait, are they compatible or not? You're contradicting yourself. That still leaves complex, nonportable, and buggy, I guess.

    I'll give you nonportable--that's necessitated by the design.
    It's a lot simpler than a bunch of scripts which each do the same thing that systemd does, honestly. Most of what you might want to change in an init script should be simply configured, and everything else can be written into the program itself, or some other program that is designed for that purpose. De-duplication of effort, and all.

    Buggy? I haven't encountered any bugs...at all, on any OS that used systemd, since it has become stable. That doesn't mean there are none, but I'm sure if there are any that they're easier to find, and fix, for all consumers of systemd, than it is to fix each little init script on every OS individually, taking into account each one's distribution specific changes.
    Bitch at distro's then for not conforming to upstream. That has been alot of problems for alot of years. I use gentoo which does try to conform to upstream configurations. I don't expect that everyone will use gentoo, but if every other distro adopted gentoo's policy of not fucking with upstream configuration then that would not be a problem.

    The thing that systemd does is that it works around the problem. The problem still exists. The problem is that distro's don't conform to upstream configuration and systemd does nothing to fix that.

  9. #39
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by GreatEmerald View Post
    OK? I don't see anyone trying to get you to use systemd everywhere. We are just trying to say that systemd is a good system that deserves being the default startup manager for all the distributions that use it. It has advantages over the alternatives, but it's not like they are required by everyone. If you don't need them, well, good for you. I know I need them. There is just no reason to try and make up flaws in systemd where there are none in the first place.
    It is -not- as simple as "just don't use it" Look at what has already happened with udev. You can't easily install any system without udev today. Look at consolekit. You can't install a full desktop environment whether it be xfce or kde or gnome or lxde without pulling it in as a dependency. Systemd expounds on that problem even more. The very last thing we need to add to the list is even more buggy ass bloatware that can't easily be eliminated, or better yet, never even installed at all.

  10. #40
    Join Date
    Nov 2011
    Posts
    276

    Default

    Quote Originally Posted by duby229 View Post
    Bitch at distro's then for not conforming to upstream. That has been alot of problems for alot of years. I use gentoo which does try to conform to upstream configurations. I don't expect that everyone will use gentoo, but if every other distro adopted gentoo's policy of not fucking with upstream configuration then that would not be a problem.

    The thing that systemd does is that it works around the problem. The problem still exists. The problem is that distro's don't conform to upstream configuration and systemd does nothing to fix that.
    By upstream, you mean SystemV? You mentioned your use of FreeBSD, unknown Linux distribution those seemed to relied on those customs configuration.

Posting Permissions

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