Announcement

Collapse
No announcement yet.

Lennart Talks Up The Power Of systemd-sysext For Testing /usr Changes

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

  • #51
    Originally posted by Terrablit View Post
    Although, if you've got some Lennart hate to spare, please direct it at him
    I mean, most of us can agree that Lennart is not precisely the most agreeable maintainer out there. That doesn't mean systemd isn't useful.

    Comment


    • #52
      Originally posted by sinepgib View Post
      I mean, most of us can agree that Lennart is not precisely the most agreeable maintainer out there. That doesn't mean systemd isn't useful.
      I have no personal experience with Lennart and without making any judgment about him (either positive or negative) I would simply point out that an agreeable maintainer is not necessarily a good maintainer and vice-versa. For a very long time at least Linus was a notoriously unpleasant person (at least when dealing with pull requests and reviewing code) but no-one can deny that he has been probably the best and most successful project manager in the history of FOSS.

      Comment


      • #53
        Originally posted by Terrablit View Post
        And yes, even the things referenced weren't the first of their kind. Niche solutions that aren't maintained are great for historical purposes, but pulling them out when a new solution comes is just weird hipster elitism.
        Those historical solutions aren't being pulled out of existence, they will always be available in git repos and probably even in non-systemd distros' package repositories. The mainstream distros don't pull them out because of hipster elitism, but because maintaining something always has a cost in terms of effort, manpower and/or money. Well funded, commercially oriented distros like Ubuntu or Fedora will always prefer investing into new "visible" features while community ones like Debian or Arch need to prioritise what their scarce resources should be used on.

        There is also another issue. I don't have any actual data to back this theory up but it is my gut feeling that when some people continuously complain about the issues they run into with systemd while others never had any such problems, it could be because the former are trying to use a systemd-based system as if it was a traditional system, and they try to achieve their needs using scripts and classic *nix tools rather than using systemd tools and units. Obviously these two approaches don't always mix very well and I think having two "authorities" in the OS to handle /usr overlays would be another huge source of problems.

        Comment


        • #54
          Originally posted by NobodyXu View Post

          What you are describing is effectively containers.
          Although it's uncommon in the Linux world, some OSes and environments make it much easier for local users to install additional software for their own private use. For Linux distros, it could make sense to restrict it to distro packages and share a consistent set of dependencies. Now that's not exactly containers, even though I'm proposing using namespaces and mounts to get around the unified filesystem hierarchy Linux distros and toolchains adhere to. GoboLinux or Android could drop the files somewhere assuming they solved the other problems, Debian and Fedora can't.

          Not sure this is actually doable, it still requires a lot of cooperation from package managers, even though it kinda solves the problem with 3rd party code not being relocatable within the filesystem.

          Comment


          • #55
            Originally posted by edgmnt View Post

            Although it's uncommon in the Linux world, some OSes and environments make it much easier for local users to install additional software for their own private use. For Linux distros, it could make sense to restrict it to distro packages and share a consistent set of dependencies. Now that's not exactly containers, even though I'm proposing using namespaces and mounts to get around the unified filesystem hierarchy Linux distros and toolchains adhere to. GoboLinux or Android could drop the files somewhere assuming they solved the other problems, Debian and Fedora can't.

            Not sure this is actually doable, it still requires a lot of cooperation from package managers, even though it kinda solves the problem with 3rd party code not being relocatable within the filesystem.
            I heard of Gobo before, sounds really interesting as each package is installed in its own prefix, essentially independent from others.
            They claim that installing multiple versions of the same package is easy and they can install package from any distro.

            Comment


            • #56
              If I'm understanding this correctly, it's something similar to DLL isn't it? A bit more versatile maybe?

              If I'm understanding it right, it sounds cool. If appimage and flatpak and snap and whatever want to imitate the way windows users install and run programs, this kind of thing is highly necessary, it could also maybe benefit applications like steam.

              Comment


              • #57
                Originally posted by jacob View Post

                Those historical solutions aren't being pulled out of existence, they will always be available in git repos and probably even in non-systemd distros' package repositories. The mainstream distros don't pull them out because of hipster elitism, but because maintaining something always has a cost in terms of effort, manpower and/or money.
                Yeah, I agree with all of this. I'm not particularly worried that anyone's going to nuke old repositories or erase history. When I said:

                Niche solutions that aren't maintained are great for historical purposes, but pulling them out when a new solution comes is just weird hipster elitism.
                I meant that pulling out incomplete, niche solutions that weren't completed or didn't get much traction in order to show that we already have something that does this and thus shouldn't accept anything new that's remotely similar is weird hipster elitism. Like when a modern music artist tries something new and that hipster guy says "Nah, The Velvet Underground did that back in 196X" as if music started and ended with them.

                You can't even announce a new project without every Tom, Dick and Neckbeardy swinging by to talk about some old rando project that was almost kind of similar. Not sure if the intention is to belittle the challenger or exclude competition, but it definitely feels like a weird flex to talk about them. Like seeing a friend on a date and telling them about all those dates you've been on before, and how this one isn't anything special. Because of that one time where you almost left the coffee shop with the other person or whatever.

                I wrote a bunch of shit that I tossed for brevity. Like how Snowflake's sort of neat idea for a per-process user would be obtuse to manage and got effectively replaced by containers, which is probably why it hasn't been updated in almost a decade. And how Puppy's various data packaging and overlay approaches like SFS files, pupsaves (apparently a full drive overlay?), AppImages, etc all sort of work halfway, but end up with some users juggling multiple pupsave files or fiddling with settings to find what will actually work with an application. Honestly a lot of Puppy's innovation doesn't make sense to me. Much of it seems like it's intended to hide user data (and even installed apps) from other computer users. A use case that seems better suited with a regular portable encrypted volume. Or by admitting you like porn or whatever.

                I still don't think systemd-sysext will replace everything (e.g. flatpak). I don't even think that's the intention. It's a component with a few clear use cases that's intended to be built upon - not forever used as-is.

                Comment

                Working...
                X