• 10 Posts
  • 117 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle


  • Right now overlays requires elevated privilèges, but ideally it shouldn’t. Rewriting the Linux kernel to implement per user namespaces like plan9 does would allow unprivileged actions from any user (just like if any user was sitting in a container, overlayed from the base system).

    I know we’re not there, and that’s not the direction development is going, but this thread is about dreams, right ? 😉

    About the XDG specs, they serve a totally different purpose so they’re out of the discussion IMO. I’m not advocating against env variables. Just $PATH which is a workaround as I see it, but your mileage may vary. As for your “issue” with steam, of course this is the best way to solve it. Because of today’s OS limitation. My point is that with a better designed namespacing implementation, there would be more elegant solutions to solve it (and would get rid of the need to use LD_LIBRARY_PATH too, or literally any *_PATH env variable)




  • You missed my point. The reason $PATH exists in the first place is because binaries were too large to fit on a single disk, so they were scattered around multiple partitions (/bin, /sbin, /usr/bin, etc…). Now, all your binaries can easily fit on a single partition (weirdly enough, /usr/bin was chosen as the “best candidate” for it), but we still have all the other locations, symlinked there. It just makes no sense.

    As for the override mechanism you mention, there are much better tools nowadays to do that (overlayfs for example).

    This is what plan9 does for example. There is no need for $PATH because all binaries are in /bin anyways. And to override a binary, you simply “mount” it over the existing one in place.














  • % pm -i | wc -l
    55
    

    That’s how many software I packaged myself. They are installed to /usr/local using an alternative package manager because I couldn’t be bothered with making an appropriate .deb.

    And as to explain how this alternate workflow is less complex, here’s how I go about installing a program:

    % git clone git://git.z3bra.org/human ~/code/human
    Cloning into '/home/z3bra/code/human'...
    remote: Enumerating objects: 53, done.
    remote: Counting objects: 100% (53/53), done.
    remote: Compressing objects: 100% (53/53), done.
    remote: Total 53 (delta 28), reused 0 (delta 0), pack-reused 0
    Receiving objects: 100% (53/53), 9.35 KiB | 195.00 KiB/s, done.
    Resolving deltas: 100% (28/28), done.
    % cd $_
    % pack
    CC human.c
    LD human
    install -D -m 0755 human /tmp/tmp.rfnbLyIQOz/usr/local/bin/human
    install -D -m 0644 human.1 /tmp/tmp.rfnbLyIQOz/usr/local/man/man1/human.1
    
            > /tmp/human@0.3.tbz
    
    installed human (0.3)
    % pm -i human
    usr/
    usr/local/
    usr/local/bin/
    usr/local/bin/human
    usr/local/man/
    usr/local/man/man1/
    usr/local/man/man1/human.1
    

  • Talking for myself and not OP: What’s complex about apt and yum is the package format per se. The cli is very straightforward and “just works”, but whenever you want something that’s not packaged and need to package it yourself, you gotta fasten your seatbelt and prepare for the complex task of creating an RPM or a DEB package.

    I know there are tools to help with that, but I’ve created packages for many distros (Debian, CentOS, Alpine, Arch, Void and Crux), and rpm/deb are just way more complex to create than the alternatives.