Announcement

Collapse
No announcement yet.

Systemd 236 Is Being Prepped For Release This Month With Many Changes

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

  • Systemd 236 Is Being Prepped For Release This Month With Many Changes

    Phoronix: Systemd 236 Is Being Prepped For Release This Month With Many Changes

    Lennart Poettering has begun his release wrangling process in getting systemd 236 ready for release this month...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    A bit offtopic but...

    I run Arch Linux and got hit by this bug:
    Submission type: Bug report After System upgrading (2017-10-12) systemd-235.0-1-x86_64.pkg.tar.xz on Arch Linux, no user X11 Usersession login was possible. Plasma, XFCE4, Gnome failed, by thorwing...



    If I use the proposed solution to comment the line "IPAddressDeny=any" in /ur/lib/systemd/system/systemd-logind.service I can once again login, but it takes an incredibly long time and my sound stops working. Does this new release include a fix for this login issue?

    Comment


    • #3
      nothing wrong with systemd

      it works, not the coolest solution ever but still works

      Comment


      • #4
        Before you leave a comment, I'd ask you to remember that all these folks did was write some code and open-source it. Nobody forced Debian/Ubuntu/Arch/Fedora/[your fav distro] to use it.

        Edit: Actually, they probably had a hand in Fedora using it come to think of it, but the point still holds I think...
        Last edited by kaprikawn; 01 December 2017, 08:47 AM.

        Comment


        • #5
          Originally posted by debianxfce View Post
          Poettering and other redhat idots do not realise that some embedded devices can use old 3.18 android based kernels only if you want all the hw bells and whistles working
          They are not supporting crap hardware manufacturers that don't even bother to have open drivers.

          Amlogic is worse than NVIDIA, as at least NVIDIA provides a driver that works with the latest (ish) kernel/xorg, and can work on wayland with GNOME.

          I am jealous to distributions that use sysv or openrc.
          Debian works fine without systemd as they still have sysv or something like that.

          Comment


          • #6
            Originally posted by AdamOne View Post
            nothing wrong with systemd
            Is there ever? Opened the bug referenced by the other guy expecting NOTABUG resolution and I wasn't disappointed.
            Poetterings philosophy is the very opposite of "we don't break userspace". Just don't stick your head too high or he will call you "arch monkeys" like he did with us (gentoo users).

            Comment


            • #7
              Originally posted by debianxfce View Post
              I am jealous to distributions that use sysv or openrc.
              Maybe some people just enjoy complaining? I'm not sure I understand your comment:


              Comment


              • #8
                Originally posted by debianxfce View Post
                Arm is the manufacturer of the gpu in Amlogic socs.
                Mali is only 3D core, you don't need it with XFCE.
                Armlogic is a shit because their hardware decoding accelerator does not have an open driver, among other things like audio and some HDMI issues that had to be worked around.

                Comment


                • #9
                  Originally posted by tpruzina View Post
                  Is there ever? Opened the bug referenced by the other guy expecting NOTABUG resolution and I wasn't disappointed.
                  Yeah, it's yet another case of an old program doing dodgy things that gets blocked by systemd.

                  How bad are systemd devs for asking downstream to fix their unsafe shit. waah waah waah.

                  From His divine post:

                  Quite frankly, loading a module into every process that implicitly opens it up to network communication, and thus adds a network attack surface to every single process (even to something as insignificant and benign as ls) is a questionable choice. I am pretty sure such NSS modules should never talk to the network directly, but do so via a locked down, local daemon that can sanitize communications. Either use nscd or such (which is a basically a generic, caching NSS proxy), or sssd or anything like it.

                  Comment


                  • #10
                    Originally posted by kaprikawn View Post
                    Before you leave a comment, I'd ask you to remember that all these folks did was write some code and open-source it. Nobody forced Debian/Ubuntu/Arch/Fedora/[your fav distro] to use it.
                    Nobody forced them no, but the whole thing is still essentially a botched implementation of the much needed replacement for init. The fact that something needed to be made doesn't mean you can't criticize the botched implementation of it. Same goes for pottering's previous blunder, pulseaudio.

                    Also, kind of funny how the people who complain about people writing negative comments about systemd showing up before the people they complain about has now become the norm in systemd-related news articles...
                    Last edited by L_A_G; 01 December 2017, 10:56 AM.

                    Comment

                    Working...
                    X