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

Static Linux

sta.li

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Static Linux

#11

Post by mwilliamson »

bch wrote: post #6
spiritplumber wrote: post #2

Wonder if it helps with dep hell...

It would for a certain class of hell. You won't get issues w/ resolving symbols in dynamic libs, but you _would_ open yourself to feature disparity across different apps that use similar libs. For example, if you've got a Client-A that uses libfoo feature X(v1), and Client-B that shipped w/ and links against libfoo feature X(v2), it might be frustrating -- this scenario is part of the promise (and responsibility) of…

And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.

Re: Static Linux

#12

Post by vezzy-fnord »

saysjonathan wrote: post #9
vezzy-fnord wrote: post #7

Earlier quoted context omitted.

A similarly interesting project is the musl-based Sabotage Linux with its own tiny but concurrent package manager: https://github.com/sabotage-linux/sabotage

Much of the bootstrapping of Morpheus appears to have come from Sabotage Linux, especially the use of musl-cross[0]. I thought I remember seeing numerous references to Sabotage in the docs but now I can't seem to find them. Anyhow, definitely another interesting project in a similar vein. The biggest difference I see, from a base perspective, is the choice of coreutils replacement: Sabotage uses Busybox while Morpheu…

The README for hbase characterizes it differently:

   hbase is a collection of programs that complements sbase
   and ubase. It's meant to be a temporary project that
   will shrink and die once sbase and ubase gets
   implementations of most of the programs included. hbase
   mostly contains programs taken from the Heirloom project,
   but also has other programs, such as patch taken from
   FreeBSD and mk taken from plan9port.
So it's not a rewrite, but rather a temporary code dump for "miscellaneous utilities". Skimming at the code confirms this.

Re: Static Linux

#14

Post by saysjonathan »

vezzy-fnord wrote: post #12
saysjonathan wrote: post #9

Earlier quoted context omitted.

Much of the bootstrapping of Morpheus appears to have come from Sabotage Linux, especially the use of musl-cross[0]. I thought I remember seeing numerous references to Sabotage in the docs but now I can't seem to find them. Anyhow, definitely another interesting project in a similar vein. The biggest difference I see, from a base perspective, is the choice of coreutils replacement: Sabotage uses Busybox while Morpheu…

The README for hbase characterizes it differently: hbase is a collection of programs that complements sbase and ubase. It's meant to be a temporary project that will shrink and die once sbase and ubase gets implementations of most of the programs included. hbase mostly contains programs taken from the Heirloom project, but also has other programs, such as patch taken from FreeBSD and mk taken from plan9port. So it's…

Correct. When I said 'rewrite', I mean 'update of some'.

Re: Static Linux

#16

Post by Lerc »

mwilliamson wrote: post #11
bch wrote: post #6

Earlier quoted context omitted.

It would for a certain class of hell. You won't get issues w/ resolving symbols in dynamic libs, but you _would_ open yourself to feature disparity across different apps that use similar libs. For example, if you've got a Client-A that uses libfoo feature X(v1), and Client-B that shipped w/ and links against libfoo feature X(v2), it might be frustrating -- this scenario is part of the promise (and responsibility) of…

And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.

The tools for updating security fixes should be applicable for the applications just as easily as the libraries. The applications would have to be rebuilt which should be automated. If the library changes anything that causes the build to fail, much better to find that out at that time than to have the failure occur when it dynamically links on end user machines.

There would be inevitable bandwidth costs in updating like this, but that is the trade-off that is Explicitly made by choosing to go with static.

Re: Static Linux

#17

Post by ultramancool »

Cool idea. Not enough people seem aware of executable packers like UPX http://upx.sourceforge.net/ though.

These are excellent tools to keep the size down when using large static binaries. By compressing the file on disk and decompressing in memory you often wind up with a smaller and sometimes even faster loading (depending on disk IO speed vs decompression speed) package. I got a static Qt binary from 4 MB down to 1.3 with upx --lzma. Very nice stuff.

Re: Static Linux

#18

Post by bch »

Lerc wrote: post #16
mwilliamson wrote: post #11

Earlier quoted context omitted.

And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.

The tools for updating security fixes should be applicable for the applications just as easily as the libraries. The applications would have to be rebuilt which should be automated. If the library changes anything that causes the build to fail, much better to find that out at that time than to have the failure occur when it dynamically links on end user machines. There would be inevitable bandwidth costs in updating…

> The tools for updating security fixes should be applicable for the applications just as easily as the libraries...

I don't think anybody would disagree, but you can't dismiss out-of-hand this required effort. The point is there are pros and cons. Its arguable that one really ought to have a build-server to mitigate the effect/work. For an OS/distribution, this would be a repository of binaries that are maintained, and you could do an (eg) apt-get update and have the proper software fixed (for your "enterprise" or similar software, a similar in-house mechanism) -- if everything is static, the act of replacing the binaries on the end-machine ought to be relatively simple for binary replacement, with the effort for library maintenance moved to maintaining an "out of band" record of what libs ea. app is using, so that when you have a flaw in libxyz that client-a, client-b, and client-c are using, you _know_ you need to update the source for client-[a-c] one way or another -- it boils down to a case of responsibility -- are you going to build safeguards into the link/run mechanism (dynamic libs) and have it adopt a certain amount of responsibility or move the cost upfront to build/maintenance and manage the responsibility yourself (with some other appropriate tooling)...

Re: Static Linux

#19

Post by spiritplumber »

Lerc wrote: post #16
mwilliamson wrote: post #11

Earlier quoted context omitted.

And that feature disparity includes security updates. If a library is updated with a security fix, you'll need to update everything that uses that library to get the fix, rather than just the shared dynamic library.

The tools for updating security fixes should be applicable for the applications just as easily as the libraries. The applications would have to be rebuilt which should be automated. If the library changes anything that causes the build to fail, much better to find that out at that time than to have the failure occur when it dynamically links on end user machines. There would be inevitable bandwidth costs in updating…

That's a problem for me - most of my stuff lives on sub-56k radio or satellite links. Thanks for the explanation!!!

Re: Static Linux

#20

Post by Lerc »

ultramancool wrote: post #17

Cool idea. Not enough people seem aware of executable packers like UPX http://upx.sourceforge.net/ though. These are excellent tools to keep the size down when using large static binaries. By compressing the file on disk and decompressing in memory you often wind up with a smaller and sometimes even faster loading (depending on disk IO speed vs decompression speed) package. I got a static Qt binary from 4 MB down to…

The downside to tools like UPX is that the executable code is actively transformed on load. This limits the ability to use shared memory for multiple concurrent executions of the same executable.

If the OS loads executables by mmap and load on page-hit, you can potentially save memory by not ever loading unused parts of an executable. a transform-on-load requires the entire program to be loaded before execution begins.

Post reply on HN