Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oasis: a small statically-linked Linux system

github.com

Post reply on HN
Print view View original

111–120 of 169 posts

Re: Oasis: a small statically-linked Linux system

#111

Post by qppo »

ChiefOBrien wrote: post #107
gameswithgo wrote: post #15

Earlier quoted context omitted.

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 lov…

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…

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.

Re: Oasis: a small statically-linked Linux system

#112

Post by Someone »

robocat wrote: post #103
retrac wrote: post #46

Earlier quoted context omitted.

> every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Back in the dark ages, some mainframe operating systems like MVS normally stored executables as object files, and would link the program every time you executed it. Has the on-disk space savings and updateable libraries of dynamic linking, without most of the complexity. I believe th…

It was for personal operating systems (and ancient mainframes) that had a multitasking OS but without any MMU support in the hardware. Relocatable executables were required so that you could load multiple executables at different addresses within the single address space of the memory. This is now called Position Independent Code[1]. Modern MMUs meant that the OS would define specific addresses for use by a program,…

There’s a difference. Position independent means you can move the executable anywhere and run it.

Relocatable means the binary has enough information to fix any absolute addresses in the code after that move. That’s extra work, and means you cannot have the same physical memory mapped to different virtual addresses in different processes, and that you have to either swap out the relocated memory, or repeat the relocation when you swap in the code again (I’m not aware of any OS doing the latter, and don’t see a nice way to do it, but it is a possibility).

https://en.wikipedia.org/wiki/Position-independent_code:

“In computing, position-independent code[1] (PIC[1]) or position-independent executable (PIE)[2] is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address.”

https://en.wikipedia.org/wiki/Relocation_(computing):

“Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses.”

Re: Oasis: a small statically-linked Linux system

#113

Post by Spivak »

ChiefOBrien wrote: post #107
gameswithgo wrote: post #15

Earlier quoted context omitted.

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 lov…

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…

As a primarily Linux developer I'm super jealous of COM. It reminds me a lot of dbus with more legacy cruft but also a lot better designed.

Re: Oasis: a small statically-linked Linux system

#114

Post by jbverschoor »

pixl97 wrote: post #67
gameswithgo wrote: post #43

Earlier quoted context omitted.

>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…

>Which, is why I mostly use windows. Oh, Windows can have dependency hell. And even worse is when you have a WinSXS blowout and you're trying to figure out why that subdirectory is using up 80GB of space for an unknown reason.

DLLHell

Re: Oasis: a small statically-linked Linux system

#115

Post by [deleted] »

mittermayr wrote: post #8

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 m…

[deleted]

Re: Oasis: a small statically-linked Linux system

#116

Post by nybble41 »

Subsentient wrote: post #88
nybble41 wrote: post #71

Earlier quoted context omitted.

It could be done. Obviously you would only run one of the main functions (via a wrapper) per process invocation and you would need to rename conflicting global symbols at some point before the link step, but this is basically how tools like busybox work. If the application uses global constructors or init functions then those would require special handling since they bypass main—C tends to work better than C++ in thi…

It could be done if you heavily patched everything you linked in, or developed an entirely new compiler, or both, but as-is, no.

Apart from the global initializers, everything necessary could be accomplished with a reasonable-length shell script applying "objcopy --redefine-syms" to the object files between the compilation and linking steps to add application-specific prefixes to all external symbols defined in any of the application's object files, without any changes to the source code or the compiler. I'm not saying it would be trivial, but it wouldn't require writing an entirely new compiler.

Source: I've implemented programs similar to busybox before by merging programs originally intended to be compiled separately, albeit on a smaller scale than an entire Linux distribution.

Re: Oasis: a small statically-linked Linux system

#117

Post by jacobr1 »

zamadatix wrote: post #92
mittermayr wrote: post #8

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 m…

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…

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.

Re: Oasis: a small statically-linked Linux system

#118

Post by harry8 »

oh no, LD_PRELOAD= hax won't work! LGPL is d00med!

Beyond that dynamic linking seems like a great solution to a problem posed by hardware constraints from 30 years ago. Like a lot of CS. Eg most uses of linked lists. (Can't wait for the abuse I'll cop for that).

Re: Oasis: a small statically-linked Linux system

#119

Post by SubjectToChange »

ChiefOBrien wrote: post #107
gameswithgo wrote: post #15

Earlier quoted context omitted.

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 lov…

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…

Stable ABIs don't seem like a good solution though. It is preferable that the system running the code should make the decisions on how best execute it. Especially as hardware becomes more specialized and diverse. Additionally, guarantees of stability necessarily increase maintenance burdens, so they should be avoided whenever possible.

IMO, the best solution would be something like SPIR-V. That is, programs are shipped in an intermediate representation which a platform-specific compiler would reduce to the final program. That way no stable ABI is needed, there is less maintenance for distros and toolchains, and end users still get high quality binaries.

Of course there are issues with protecting the intermediate representations of programs from reverse engineering. But the combination of strong DRM with obfuscation should satisfy most software vendors. After all, most companies are comfortable shipping Java based programs.

Re: Oasis: a small statically-linked Linux system

#120

Post by zik »

AnIdiotOnTheNet wrote: post #78
Subsentient wrote: post #72

Earlier quoted context omitted.

>>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static I disagree, I tend to want the opposite. I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked, and OS facilities like libc to be statically linked.

> I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked These fall under "GUI" in the "base system" category in my opinion. > and OS facilities like libc to be statically linked. If you're not being sarcastic right now, I'm really curious as to your reasoning.

I'm not OP but statically linking a compact libc like musl gets you just the parts of libc that you need and nothing more. This can be a lot more efficient than a dynamically linked program which has to bring in the entire bloated mess of glibc.

Whether this is a benefit when you're duplicating bits of libc across every executable in your entire system is unclear to me though.

Post reply on HN