Announcement

Collapse
No announcement yet.

LightDM Display Manager 2022 Status Update: Not Much Going On

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

  • #21
    Originally posted by wooque View Post
    It just works and it doesn't need more "development". They could only ruin it.
    Just like Xorg.

    (sarcasm)

    Comment


    • #22
      LightDM is the default launcher for Mint, so that means millions of users. Even with Ubuntu I personally like it and replaced GDM with it.

      Comment


      • #23
        Last time I checked LightDM was the only Display Manager properly supporting multiseat. Does anyone here know if things have changed in the meantime?

        Comment


        • #24
          Originally posted by FireBurn View Post
          I fear SDDM is going the same way, looks like nothing happens for months on end, then there will be a flurry of activity, then nothing again, not been a new release since 2020
          sddm has always been a stupid decision. KDE already had a perfectly fine LightDM front-end in the late Plasma 4.x era. Then discussions came up what to do with KDM and instead of sticking with LightDM and improving on it, a few but loud KDE developers insisted on sddm. They said that they wouldn't even contribute a Wayland back-end to LightDM because of its CLA (the CLA sucks but that's all I agree with) and they also would not support a LightDM fork because it would be "hostile" which is an absolutely insane claim to make because the GPL already gave them permission to fork which is nothing hostile at all. In the end the loud minority never did anything of substance in sddm. KDE should have never listened to them and listen to the lightdm-kde maintainers.

          Originally posted by archkde View Post
          From scratch doesn't make any sense at all, forking SDDM would be a much better starting point.
          sddm is already co-maintained by KDE developers, they just have no drive to click the release button.

          Originally posted by luno View Post
          https://wiki.archlinux.org/title/Greetd works perfectly with many frontends for Qt ,GTK , Wlr and many more it is pretty lightweight
          greetd is like LightDM (same concepts) but without the CLA which a fork could also have achieved. I don't see the point of greetd reinventing the wheel but I guess LightDM greeters could be ported over, though.... Looking at https://git.sr.ht/~kennylevinsen/greetd/log the fact that greetd only receives one commit every few months, it looks in a worse situation than LightDM https://github.com/canonical/lightdm/commits/main

          Originally posted by Luke_Wolf View Post
          They're actually not that big of programs, from scratch actually does make perfect sense.

          LightDM is 2.5k LOC
          SDDM is 16k LOC
          GDM is 65k LOC

          The real question is why are they basically all dead?
          GDM isn't dead and neither is LightDM. LightDM is just a back-end service and all the fun stuff happens in greeters. LightDM doesn't need much development. According to a comment by IIRC Robert Ancell in a Github issue, LightDM even runs perfectly fine under Wayland since years via Mir.

          Comment


          • #25
            Originally posted by Awesomeness View Post
            sddm has always been a stupid decision. KDE already had a perfectly fine LightDM front-end in the late Plasma 4.x era. Then discussions came up what to do with KDM and instead of sticking with LightDM and improving on it, a few but loud KDE developers insisted on sddm. They said that they wouldn't even contribute a Wayland back-end to LightDM because of its CLA (the CLA sucks but that's all I agree with) and they also would not support a LightDM fork because it would be "hostile" which is an absolutely insane claim to make because the GPL already gave them permission to fork which is nothing hostile at all. In the end the loud minority never did anything of substance in sddm. KDE should have never listened to them and listen to the lightdm-kde maintainers.
            The CLA is a very good reason, from a philosophical standpoint, to reject contributing to a project. If people is willing to go so far as to say the GPL isn't really free because it imposes conditions, a CLA is orders of magnitude worse as it states, even if you contribute as much as the original author, you have fewer rights than them over the whole. It would be a huge contradiction to provide an actual free desktop and then choose inequality for the display manager.
            The option to fork is a moot point here: if you're already going to diverge then you may as well get to choose how you want the whole project to be, i.e. roll your own if you want. The point of reusing another GPL is, in part, to share the codebase between the two.

            Originally posted by Awesomeness View Post
            greetd is like LightDM (same concepts) but without the CLA which a fork could also have achieved. I don't see the point of greetd reinventing the wheel but I guess LightDM greeters could be ported over, though.... Looking at https://git.sr.ht/~kennylevinsen/greetd/log the fact that greetd only receives one commit every few months, it looks in a worse situation than LightDM https://github.com/canonical/lightdm/commits/main
            Does LightDM allow a command line greeter?

            Comment


            • #26
              Originally posted by FireBurn View Post
              • 3 Nov 2020 - and a dollar short
              There is no "on wayland" - it needs to be its own wayland compositor - which is in git, I know it's being worked on here and there, but then everything goes quiet for months at a time, even the tickets asking for a new version to be tagged go unanswered
              We must understand that once the login manager is developed, there is not much work to be done, other than to close any security holes and bugs. As for wayland they are doing it, but there is no need to have it right away, because Plasma still uses Xorg by default.
              I hope that soon you will come to have wayland by default and at that point it is important to have native SDDM support on wayland, even if it is not essential.
              Simply put, there is not all this rush.

              Comment


              • #27
                Originally posted by sinepgib View Post
                The option to fork is a moot point here: if you're already going to diverge then you may as well get to choose how you want the whole project to be, i.e. roll your own if you want.
                You didn't read what you've replied to, right? The KDE developers in charge of the display manager wanted to keep using LightDM or a fork. They decided against it after a hysterical minority that sddm had to be used and that minority then never contributed to sddm despite even though they alluded to be willing on a Wayland port.

                Originally posted by sinepgib View Post
                The point of reusing another GPL is, in part, to share the codebase between the two.
                One-way code transfer from Canonical to KDE would have been possible. The point of contention was a Wayland port because back in the day Canonical was dreaming about Mir as an alternative to Wayland.

                A possible KDE fork could have continued to take code from upstream and concentrated on Wayland support.

                Originally posted by sinepgib View Post
                Does LightDM allow a command line greeter?
                I don't know. Why wouldn't it?

                Comment


                • #28
                  Originally posted by Awesomeness View Post
                  You didn't read what you've replied to, right? The KDE developers in charge of the display manager wanted to keep using LightDM or a fork. They decided against it after a hysterical minority that sddm had to be used and that minority then never contributed to sddm despite even though they alluded to be willing on a Wayland port.
                  The vocal minority could have been maintainers, your post wasn't really too clear about that. If they were maintainers it makes sense. Otherwise, yeah, I agree, if you don't put the hours you don't get a say.

                  Originally posted by Awesomeness View Post
                  One-way code transfer from Canonical to KDE would have been possible. The point of contention was a Wayland port because back in the day Canonical was dreaming about Mir as an alternative to Wayland.

                  A possible KDE fork could have continued to take code from upstream and concentrated on Wayland support.
                  Yet the point was that if you'd end up with two projects anyway, it doesn't matter that much whether you start from scratch or reuse Canonical's. The point of working in the old codebase would've been, IMO, to actually keep a single project. Soon projects diverge and one can't easily benefit from the other (well, Canonical's bullshit CLA also would have made impossible for them to take code from the fork, but who cares about those who dig their own grave really?).

                  Originally posted by Awesomeness View Post
                  I don't know. Why wouldn't it?
                  Maybe there's no greeter? I don't know, I'm asking.

                  Comment

                  Working...
                  X