from Hacker News

Sta.li: Static Linux

by Xyzodiac on 2/19/14, 3:06 AM with 98 comments

  • by ChuckMcM on 2/19/14, 5:20 AM

    Ah kids, they crack me up!

    Lot of fun reading that, I looked around briefly but couldn't find my email archive from Sun, but I was in the kernel group when folks got the idea that "Gee if you shared the text segment of libraries, that would give you more memory for your buffer cache or user pages!" One of the guys in my group re-wrote the linker to scan through and realign text segments so that the maximum number of read-only pages (and thus shareable) could be allocated. And of course code that had static buffers and what not (go look at the 4.1BSD code, they were everywhere). It made my Sun 3/75 which had, wait for it 32 Megabytes of RAM (yes, less than the L2 cache in some machines these days) run quite a bit faster. Took a long time to get right too.

    Shared libraries gave you three distinct advantages, one you cut down on the working set size, two you cut down on file load time, and three it became possible to "interpose" on the library and run two versions of the library at the same time for backwards compatibility.

    Building a static system might be fun but for a 64 bit system, building one where libraries were fixed in the address space in flash or something might actually be even better.

  • by kev009 on 2/19/14, 8:08 AM

    In case it's not obvious: if you static link to a library, say libpng, and a vuln hits, every binary that linked to libpng potentially needs to be rebuilt and distributed.

    If the OS has rigid dependency tracking (maybe source distros like Gentoo, or a cryptographically tracked binary distribution like freebsd-update), maybe you can live with that.

    So there's some trade off of "dll hell" for binary hell, and perhaps some other security advantages to dynamic libs. IMHO shared libraries are pretty well understood now days and static linking should be avoided unless you have a very good reason.

  • by khc on 2/19/14, 4:20 AM

    From the FAQ:

    "Also a security issue with dynamically linked libraries are executables with the suid flag. A user can easily run dynamic library code using LD_PRELOAD in conjunction with some trivial program like ping. Using a static executable with the suid flag eliminates this problem completely."

    Have the authors actually tried this? Using LD_PRELOAD with suid programs won't work.

  • by davidp on 2/19/14, 4:45 AM

    I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

  • by vinkelhake on 2/19/14, 4:42 AM

    On binary sizes:

    > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb.

    That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc).

    There's also a lot of handwaving on memory usage in the FAQ.

  • by chj on 2/19/14, 3:36 AM

    "The reason why dynamic linking has been invented was not to decrease the general executable sizes or to save memory consumption, or to speed up the exec() -- but to allow changing code during runtime -- and that's the real purpose of dynamic linking, we shouldn't forget that."

    Not sure about "changing code during runtime", but one of the great benefits of dynamic-link libraries are for writing plugins. And I don't think it would take much time for an app to look up its own plugin folder.

  • by default_name on 2/19/14, 10:03 AM

    It's not meant to be just another Linux distribution. It will be whole new system with Linux kernel at the core. It will be more in line with BSDs. That's why static linking will make sense. Your updates are just rsync away.

    As I see it suckless.org community prefers 'linking' in form of shell scripts or communication via pipes, ideally via system's VFS.

    You will get lean and minimalistic base system. If something will not share same ideals it will not be in the base system (like glib[c]?, bash, Firefox). It is possible that dynamic linking will be allowed in /emul chroot as stated in 'Filesystem' page.

    I see sta.li as rock solid minimalistic base system, which you can use on it's own (how I belive many suckless.org folks will use it) or as a base system, that you can build upon. Even more than that, you will be able to use sta.li components in generic distributions with ease, because of static linking.

    Go-lang is in my opinion next step for Bell Labs folks in lean development for the masses. Don't take this too literally ;) Plan 9 [1] was first step, but people did not want whole new system. Inferno [2] was next one, but VM system was too much also. Go allows to use some of Plan 9 features in edible form for the masses. Without requirement to install specific system or VM to run your programs. That to some extent is what makes sta.li's ideals similar to go-lang's.

    Development of sta.li is at slow pace, but many experiments are under development [3]. Probably some of them will be included in sta.li. Most probably sta.li will include X11, but we are seeing some developments with Wayland [4].

    [1] - http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [2] - http://en.wikipedia.org/wiki/Inferno_%28operating_system%29 [3] - https://github.com/henrysher/sinit - http://galos.no-ip.org/sdhcp - http://git.suckless.org/dmc/ [4] - https://github.com/michaelforney/swc

  • by prewett on 2/19/14, 8:53 AM

    Building Gentoo with USE=static might be a good way to experiment without have to build an entire new distribution. Try one with the flag, one without, do the same operations in each and watch the memory usage and time to completion.

  • by ch215 on 2/19/14, 6:23 AM

    The developer, Anselm Garbe, gave a talk about Stali (among other things) at last year's Suckless conference...

    http://www.youtube.com/watch?v=Zu9Qm9bNMUU

    I'm not qualified to comment on Stali itself but, more generally, I can't recommend Suckless software highly enough.

    Since I switched to Linux a few years back I've found myself using more and more of their programs--DWM, Dmenu, ST, Tabbed, Slock and Surf.

    Before, I'd hop from one window manager, terminal or browser to another but, for me, Suckless programs just tend to stick because of the minimal philosophy.

  • by vezzy-fnord on 2/19/14, 3:29 AM

    It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.

  • by nathell on 2/19/14, 12:17 PM

    One useful set of gcc flags to consider when building a statically-linkable library/executable and aiming to reduce executable size is -Os -ffunction-sections -fdata-sections -Wl,-gc-sections.

    This causes gcc to put each function in a separate section in the resulting object file, and the -gc-sections option makes ld strip the sections that are not reachable by calls from main (basically a tree-shaker).

  • by cgh on 2/19/14, 5:24 AM

    I enjoyed this from their description of their dwm window manager, which took me back to the general state of Linux circa 1999:

    "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though."

  • by mrich on 2/19/14, 7:20 AM

    They missed a chance to call a project 'Stalin'.

  • by Ziomislaw on 2/19/14, 4:12 PM

    Stali currently does not exist, but there are others statically linked distros out there, ie. http://starchlinux.org/

  • by mrottenkolber on 2/19/14, 1:38 PM

    I like what the guys are doing and would love to try it out, but frankly the page didn't change much for the last two years and all the discussion of strategy isn't worth much without a working distribution with which you can experiment.

    Furthermore I suspect the scope of stali will be so narrow that I will never be able to run say a CL implementation on it. Pretty much the same as Plan9, I love the design but it's practically useless for me. :(

  • by ommunist on 2/19/14, 11:08 AM

    For this kind of thing Stal.in is a better domain name.

  • by oofabz on 2/19/14, 9:35 AM

    The group behind Sta.li also makes a great terminal emulator. It is notable for supporting font antialiasing without depending on the large GTK or QT libraries - it uses Xft directly. And it is much smaller than even xterm or rxvt.

    http://st.suckless.org/

  • by julie1 on 2/19/14, 3:51 AM

    I was dreaming of it, and knew that no matter how much it was itching I could never scratch it. Thanks

  • by matiasb on 2/19/14, 3:56 AM

    Sounds good, what about Golang based tools? (considering the default static binary generation)

  • by anon35 on 2/19/14, 7:16 AM

    Static linking also relative in a discussion about coupling and OS dependencies : http://unix.stackexchange.com/a/38914/17683

  • by jbb555 on 2/19/14, 9:12 AM

    With the use of link time code generation too, this could be better than expected perhaps?

  • by paulannesley on 2/19/14, 8:48 AM