Announcement

Collapse
No announcement yet.

Systemd 239 Is Being Prepped For Release With Many Changes

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

  • #11
    Originally posted by jrch2k8 View Post

    fair enough but this "SR-IOV virtual functions and NPAR partitions" is not something anyone on its right mind will let it go as default without checking thoroughly since this is really hardcore high density virtualization server stuff and this was needed in that sector to be more up to par with VmWare ESXi hence this will not affect any average Joe user desktop ever, is not even usable by default or with regular desktop hardware.

    about "RestrictNamespaces= unit property" this should be null for end users on any decent distro as Arch, Sure, RH, etc. but I will give you 50% chance here because crappy distro do exists.

    about "systemd-resolve tool has been renamed" I do agree since average Joe may use this tool but also I agree on the why they did it since keeping an uniform naming scheme is important but I think Arch and all other decent distros will simply symlink systemd-resolve -> resolvectl in the meantime to keep it low profile and maybe add some warning to inform the users to use the new name.
    1) Just because those are unlikely to hit every single user, it doesn't mean that it won't hit somebody.

    2) Just because big distros have maintainers that will fix it to behave consistently it doesn't that breaking changes are ok.
    Not even sure what is the "default" policy here, but I would imagine that redefining attributes inside configs should behave as expected e.g.:

    attr = a
    attr = b
    attr == b

    This actually makes more sense than _sometimes_ treat assignment as union on a set.
    attr = a
    attr = b
    attr == { a, b }

    But maybe that's just me.

    3) How much harder would it be to provide a wrapper that prints extra message "this will stop working at some point in the future" and keeps backward compatibility in the first place?

    Comment


    • #12
      Originally posted by tpruzina View Post
      3) How much harder would it be to provide a wrapper that prints extra message "this will stop working at some point in the future" and keeps backward compatibility in the first place?
      From your second post:
      The systemd-resolve tool has been renamed to resolvectl (it also remains available under the old name, for compatibility)

      Comment


      • #13
        Originally posted by droste View Post
        From your second post:
        The systemd-resolve tool has been renamed to resolvectl (it also remains available under the old name, for compatibility)
        Hm, point taken, I would have sworn that that comment wasn't there when I have read the changelog initially.

        Edit:

        You got me confused because you haven't actually quoted me properly:
        * The systemd-resolve tool has been renamed to resolvectl (it also remains available under the old name, for compatibility), and its interface is now verb-based, similar in style to the other <xyz>ctl tools, such as systemctl or loginctl.
        The wording suggests that it isn't backwards compatible (syntax has changed), but it's my understanding now that if you go trough symlink, original syntax is accepted (e.g. it _is_ actually backwards compatible).
        https://github.com/systemd/systemd/p...2906a312b68fe9
        Last edited by tpruzina; 06-12-2018, 02:23 PM.

        Comment


        • #14
          If systemd is already running before we log in, why not just get rid of a log-in manager and make systemd require a password

          Comment


          • #15
            Originally posted by caligula View Post

            Funny. People complain how systemd is worse than <insert your favorite alternative here>. However when they fix systemd bugs and improve it in other ways, the people will complain even more and more.
            Once you hate something badly enough, everything it does is offensive. Not sure if this link will work.

            https://i.pinimg.com/236x/bd/ae/a6/b...e-journals.jpg

            (I'm picking on the people with an irrational dislike of systemd, not systemd itself.)

            Comment


            • #16
              Originally posted by dlocklear01 View Post
              If systemd is already running before we log in, why not just get rid of a log-in manager and make systemd require a password
              dealing with passwords in an init system is agains security principles and against the Unix philosophy of keeping each daemon's scope focused on a specific topic.
              That functionality is implemented in dedicated daemons, not in the main init system.

              If you need a simpler password dialog than logind+graphical login manager, the systemd project offers a simpler daemon called systemd-ask-password which works fine without a login manager (using plymouth), or without a graphical user interface at all (console or serial console). https://www.freedesktop.org/software...-password.html

              Comment


              • #17
                Systemd sucked for a little while when it first came in, but now that it's stabilised meh. It doesn't really change things one way or another. The only concern I have about it is if there's some gaping security hole in it.

                Comment


                • #18
                  Originally posted by DMJC View Post
                  The only concern I have about it is if there's some gaping security hole in it.
                  That's a tradeoff I can accept. With shell scripts you're almost always sure there is some obscure way you didn't think of where someone could abuse your script.

                  Comment


                  • #19
                    Originally posted by dlocklear01 View Post
                    If systemd is already running before we log in, why not just get rid of a log-in manager and make systemd require a password
                    Don't give them ideas

                    Comment


                    • #20
                      Originally posted by dlocklear01 View Post
                      If systemd is already running before we log in, why not just get rid of a log-in manager and make systemd require a password
                      There already is logind (part of the systemd suite), which manages seats and sessions, and PAM, which provides an authentication API. The actual login managers nowadays do little more than display a message asking users to enter their login name and password. So this is arguably one of the rare cases where we don't need more systemd.

                      Comment

                      Working...
                      X