9 ms·

Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for t

Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for this. Can I compile this onto a USB stick and use it as a throw-away boot Linux for maintenance tasks? Can I cross-compile this for embedded devices? What is the statically-linked advantage here? Not trying to minimize the effort, I would actually love to see more such things, but felt a bit left out as I couldn't figure out why exactly it exists.

gameswithgo 6y ago
As someone who uses linux casually, I often experience pain when I download a program, try to run it, and it fails because some dependency is not installed or is not the right version. So you try to figure out how to install it and it in turn needs a couple of things. All of this works fine if whatever package manager your distro uses has the program you want, but the package managers don't have evertying! So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to.
- Wowfunhappy 6y ago
  > So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Me too, but I'm not sure this project brings us closer to that goal. I don't need the base OS to be statically linked—in fact, that's where static vs dynamic linking matters least, because it all comes preinstalled. What I want is for everything else which I may want to install on top to be available as statically-linked binaries.
  - an_opabinia 6y ago
    Since most common applications have moved to the web, and the biggest Linux end user deployment by far, Android, was created from fresh beginnings, the idea of the user being concerned with minutia of binaries is already far along a long road to the grave.
    - krageon 6y ago
      This right here is what's wrong with the application space. The idea that this could be true leads to terrible software design and slow, bloated applications. In the current landscape is it perfectly possible (and I'd say even usual) to do most of your work and processing on local system binaries (that aren't a browser or a browser with a different name).
      - an_opabinia 6y ago
        It’s no one’s fault really. As long as people pirate software, it is economically Darwinian / inevitable that all commercial software will migrate to centrally controlled subscription gated servers. This includes open source software, if you correctly count how much of it is repackaged and sold to people this way.
        krageon 6y ago
        It has nothing to do with pirating. That sort of predatory mercantile behaviour has happened basically ever since humanity invented money. It happens because unscrupulous people are allowed more power than they should have. Stop blaming everyone else for their bad decisions.
    - Wowfunhappy 6y ago
      Eh, but if that was completely true I'd be using ChromeOS, or something similar. Perhaps some day I will—but as of 2020, I still find myself popping into a lot of native apps day-to-day.
    - jcelerier 6y ago
      99% of the apps I use aren't on the web at all
    - johnisgood 6y ago
      > Since most common applications have moved to the web No, just please no!
  - gameswithgo 6y ago
    This is true, though perhaps there is some performance benefit.
  - 1996 6y ago
    Check out kiss linux, another interesting project: k1ss.org/install I'm considering trying it: having the simplest distribution baremetal, and keeping the complexity "outside" and "contained" (docker for servers, flatpack for desktops and laptops, etc.) makes sense to me
- arendtio 6y ago
  > So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Well, every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it. Which will use quite some resources. So to actually use this you would have to reinstall (nearly) all programs once a week or so (no matter if source or binary distribution). While that is quite possible with modern internet connections, I am not sure if it solves all the problems you might think it solves. After all, even nowadays application authors could provide static packages, but many don't do it. After using quite a few distributions over the years, I like Arch Linux best at the moment, as the combination of binary distribution, with frequent updates, and the source based AUR, with the very large amount of packages, suits my needs very good.
  - gameswithgo 6y ago
    >Well, every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Well no, I could opt not to apply the bug fix if it isn't affecting me. This again is sort of serve mentality, where of course you want to get a bug fix in as quick as possible in case it is a security issue. A desktop user, maybe you don't. >After all, even nowadays application authors could provide static packages, but many don't do it. Right, and really what I would like is for application authors to just static link more, more often, on linux. Or at the least ship their programs with installers that apply the needed deps if they are not already there! That the OS itself is statically linked doesn't really matter, but perhaps it would inspire an ecosystem that does this. > I like Arch Linux best at the moment Probably suggest arch linux to someone complaining about having to track down dependencies does not make sense, since such a person is more interested in the OS just working rather than making the OS a bit of a hobby that that they want to customize. Which, is why I mostly use windows.
    - jcelerier 6y ago
      > Probably suggest arch linux to someone complaining about having to track down dependencies does not make sense, since such a person is more interested in the OS just working rather than making the OS a bit of a hobby that that they want to customize. having used Red Hat, Mandrake, Ubuntu, Debian... Arch Linuxis by far the most "just works" distro I've used
- kevin_thibedeau 6y ago
  If you need exotic libraries, you install them into /usr/local/lib with GNU Stow for secondary package management. Then point your loader there first when starting programs that depend on them. Your distro stays pristine and the program runs so everything is good.
- tonyedgecombe 6y ago
  Actually that's one problem I've never had with Linux. Even using stuff that isn't in the default package manager seems to just work.
- ChiefOBrien 6y ago
  Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then there's still companies pushing out binary blobs which break every few kernel updates. As a FOSS developer it's an eternal fight between good and evil with no winner in sight, as a propiertary developer it's pain in the ass to maintain old and new software between all the permutation of Linux distros, and as a user I get to cry because of the lack of popular software and backwards compatibility. Snaps and flatpaks are an ugly hack, literal ductape around this very fundamental problem, and clearly not the solution. GNU/Linux should have adopted COM and/or an adequete proglang with stable ABI a long time ago, and should have tried to control wasted effort put into duplicate software ecosystems (KDE and Gnome).
  - qppo 6y ago
    That's a searing hot take, to be sure. There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC. Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything or package your shared objects with your software. Then to launch the software you need a shell script that overrides the loader search path and move on with your life. The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that. The other issues of packaging software like entitlements/capability based security and code signing are similarly orthogonal. If you're shipping big software today, it needs to have everything it needs and to ignore whatever is on the user's system unless they explicitly request an override. The real tragedy of GNU is that the interchangeability of software was always possible, package managers just managed to make it accidental and explicit. Too many foot guns there.
    - wahern 6y ago
      > Then to launch the software you need a shell script that overrides the loader search path and move on with your life. > The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that. All ELF systems support the $ORIGIN RPATH macro. It lets you build and package an application exactly like, if not better than, you would a macOS bundle. Specifically, it let's you specify at compile time a library load path relative to the invoked binary. You'd specify it as $ORIGIN/../lib for the canonical bin/, lib/, etc layout.
- eeZah7Ux 6y ago
  > So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Security: a good distro provides security updates for shared libraries. With static linking it becomes too burdensome.
zamadatix 6y ago
It seems like your definition of "why this matters" is "how can this pick me up as a user" but for some projects "why this matters" is "to see if this works as well as we think it could" or similar more abstract goals. If the goal of the project is to try to be as small and simple of a Linux distro as possible by trying a different take and seeing how it pans out (which it seems like this is) then it's accomplishing it's goals whether or not it tells you how you could use such a distro were it to pan out.
- mrtweetyhack 6y ago
  So this doesn't matter
- breakfastduck 6y ago
  I don't think you're disagreeing with each other - a bit of intro text especially helps if the project is abstract.
- jacobr1 6y ago
  The description of "I built this to try something cool, but maybe someone could find a use for it!" is just fine. But it would be great to know. Likewise: "We built at company Y this for use case x and intend to support it" also tells me what is going on.
deleted 6y ago
[deleted]
crb002 6y ago
It's a joy to deploy. I loved the IBM Blue Gene/L. Like AWS Lambda, except instead of a zip you deployed a static linked binary.
fouc 6y ago
Looks like the readme was updated 3 hours after your message, and does a great job of explaining the ideas/advantages.

gameswithgo 6y ago

As someone who uses linux casually, I often experience pain when I download a program, try to run it, and it fails because some dependency is not installed or is not the right version. So you try to figure out how to install it and it in turn needs a couple of things. All of this works fine if whatever package manager your distro uses has the program you want, but the package managers don't have evertying! So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to.

Wowfunhappy 6y ago
> So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Me too, but I'm not sure this project brings us closer to that goal. I don't need the base OS to be statically linked—in fact, that's where static vs dynamic linking matters least, because it all comes preinstalled. What I want is for everything else which I may want to install on top to be available as statically-linked binaries.
- an_opabinia 6y ago
  Since most common applications have moved to the web, and the biggest Linux end user deployment by far, Android, was created from fresh beginnings, the idea of the user being concerned with minutia of binaries is already far along a long road to the grave.
  - krageon 6y ago
    This right here is what's wrong with the application space. The idea that this could be true leads to terrible software design and slow, bloated applications. In the current landscape is it perfectly possible (and I'd say even usual) to do most of your work and processing on local system binaries (that aren't a browser or a browser with a different name).
    - an_opabinia 6y ago
      It’s no one’s fault really. As long as people pirate software, it is economically Darwinian / inevitable that all commercial software will migrate to centrally controlled subscription gated servers. This includes open source software, if you correctly count how much of it is repackaged and sold to people this way.
      - krageon 6y ago
        It has nothing to do with pirating. That sort of predatory mercantile behaviour has happened basically ever since humanity invented money. It happens because unscrupulous people are allowed more power than they should have. Stop blaming everyone else for their bad decisions.
  - Wowfunhappy 6y ago
    Eh, but if that was completely true I'd be using ChromeOS, or something similar. Perhaps some day I will—but as of 2020, I still find myself popping into a lot of native apps day-to-day.
  - jcelerier 6y ago
    99% of the apps I use aren't on the web at all
  - johnisgood 6y ago
    > Since most common applications have moved to the web No, just please no!
- gameswithgo 6y ago
  This is true, though perhaps there is some performance benefit.
- 1996 6y ago
  Check out kiss linux, another interesting project: k1ss.org/install I'm considering trying it: having the simplest distribution baremetal, and keeping the complexity "outside" and "contained" (docker for servers, flatpack for desktops and laptops, etc.) makes sense to me
arendtio 6y ago
> So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Well, every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it. Which will use quite some resources. So to actually use this you would have to reinstall (nearly) all programs once a week or so (no matter if source or binary distribution). While that is quite possible with modern internet connections, I am not sure if it solves all the problems you might think it solves. After all, even nowadays application authors could provide static packages, but many don't do it. After using quite a few distributions over the years, I like Arch Linux best at the moment, as the combination of binary distribution, with frequent updates, and the source based AUR, with the very large amount of packages, suits my needs very good.
- gameswithgo 6y ago
  >Well, every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Well no, I could opt not to apply the bug fix if it isn't affecting me. This again is sort of serve mentality, where of course you want to get a bug fix in as quick as possible in case it is a security issue. A desktop user, maybe you don't. >After all, even nowadays application authors could provide static packages, but many don't do it. Right, and really what I would like is for application authors to just static link more, more often, on linux. Or at the least ship their programs with installers that apply the needed deps if they are not already there! That the OS itself is statically linked doesn't really matter, but perhaps it would inspire an ecosystem that does this. > I like Arch Linux best at the moment Probably suggest arch linux to someone complaining about having to track down dependencies does not make sense, since such a person is more interested in the OS just working rather than making the OS a bit of a hobby that that they want to customize. Which, is why I mostly use windows.
  - jcelerier 6y ago
    > Probably suggest arch linux to someone complaining about having to track down dependencies does not make sense, since such a person is more interested in the OS just working rather than making the OS a bit of a hobby that that they want to customize. having used Red Hat, Mandrake, Ubuntu, Debian... Arch Linuxis by far the most "just works" distro I've used
kevin_thibedeau 6y ago
If you need exotic libraries, you install them into /usr/local/lib with GNU Stow for secondary package management. Then point your loader there first when starting programs that depend on them. Your distro stays pristine and the program runs so everything is good.
tonyedgecombe 6y ago
Actually that's one problem I've never had with Linux. Even using stuff that isn't in the default package manager seems to just work.
ChiefOBrien 6y ago
Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then there's still companies pushing out binary blobs which break every few kernel updates. As a FOSS developer it's an eternal fight between good and evil with no winner in sight, as a propiertary developer it's pain in the ass to maintain old and new software between all the permutation of Linux distros, and as a user I get to cry because of the lack of popular software and backwards compatibility. Snaps and flatpaks are an ugly hack, literal ductape around this very fundamental problem, and clearly not the solution. GNU/Linux should have adopted COM and/or an adequete proglang with stable ABI a long time ago, and should have tried to control wasted effort put into duplicate software ecosystems (KDE and Gnome).
- qppo 6y ago
  That's a searing hot take, to be sure. There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC. Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything or package your shared objects with your software. Then to launch the software you need a shell script that overrides the loader search path and move on with your life. The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that. The other issues of packaging software like entitlements/capability based security and code signing are similarly orthogonal. If you're shipping big software today, it needs to have everything it needs and to ignore whatever is on the user's system unless they explicitly request an override. The real tragedy of GNU is that the interchangeability of software was always possible, package managers just managed to make it accidental and explicit. Too many foot guns there.
  - wahern 6y ago
    > Then to launch the software you need a shell script that overrides the loader search path and move on with your life. > The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that. All ELF systems support the $ORIGIN RPATH macro. It lets you build and package an application exactly like, if not better than, you would a macOS bundle. Specifically, it let's you specify at compile time a library load path relative to the invoked binary. You'd specify it as $ORIGIN/../lib for the canonical bin/, lib/, etc layout.
eeZah7Ux 6y ago
> So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Security: a good distro provides security updates for shared libraries. With static linking it becomes too burdensome.

zamadatix 6y ago

It seems like your definition of "why this matters" is "how can this pick me up as a user" but for some projects "why this matters" is "to see if this works as well as we think it could" or similar more abstract goals. If the goal of the project is to try to be as small and simple of a Linux distro as possible by trying a different take and seeing how it pans out (which it seems like this is) then it's accomplishing it's goals whether or not it tells you how you could use such a distro were it to pan out.

mrtweetyhack 6y ago
So this doesn't matter
breakfastduck 6y ago
I don't think you're disagreeing with each other - a bit of intro text especially helps if the project is abstract.
jacobr1 6y ago
The description of "I built this to try something cool, but maybe someone could find a use for it!" is just fine. But it would be great to know. Likewise: "We built at company Y this for use case x and intend to support it" also tells me what is going on.

deleted 6y ago

[deleted]

crb002 6y ago

It's a joy to deploy. I loved the IBM Blue Gene/L. Like AWS Lambda, except instead of a zip you deployed a static linked binary.

fouc 6y ago

Looks like the readme was updated 3 hours after your message, and does a great job of explaining the ideas/advantages.