
Sta.li: Static Linux - Xyzodiac
http://sta.li
======
ChuckMcM
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.

~~~
eekee
that one paragraph... if i were you i'd be wishing i could edit that comment!
you most certainly do not "cut down on file load time." the linking process is
a complex task, especially if it's to be performed with any efficiency. i
remember when starting a large dynamically linked executable was a glacial
process on linux, far slower than the time necessary to read the entire
executable from disk. no sensible system loads the entire executable when it's
statically linked.

your claim of running two library versions at the same time is downright
hilarious! this is far harder with dynamic linking, where you need to be sure
of loading the right library on every launch of the affected programs than it
is with static, where the libraries are just built in to the executables.

~~~
ChuckMcM
To be clear, loading data from disk takes _milliseconds_ and re-computing
addresses takes _nanoseconds_. Yes, in less than one tenth the time it takes
to read the part of the libraries you have linked into your binary from disk,
you can locate and fixup any link references.

This part I don't get "no sensible system loads the entire executable when
it's statically linked." If you're a statically linked executable, by
definition the entire file is headed into memory, if there was something in
the library you didn't use it got edited out in the link step. Now you may
mmap the file and fault it in as you go along, but you are going to have the
whole thing read.

~~~
haberman
> To be clear, loading data from disk takes milliseconds and re-computing
> addresses takes nanoseconds.

I think the literature surrounding prelink pretty strongly contradicts this
assertion. See:

[http://people.redhat.com/jakub/prelink/prelink.pdf](http://people.redhat.com/jakub/prelink/prelink.pdf)

[http://lwn.net/Articles/341305/](http://lwn.net/Articles/341305/)

[http://lwn.net/Articles/341309/](http://lwn.net/Articles/341309/)

------
kev009
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.

~~~
qznc
That vuln problem works the other way round as well. When a new libpng
vulnerability is introduced all executables using the shared library are
affected, while static-lib users with an older version are fine.

~~~
danieldk
But in general, all binaries in a distribution are compiled against the same
version of a library, namely the one that is distributed with it. I don't see
that changing in a distribution that was fully statically linked.

Even in the unlikely case where binaries are statically linked against
different versions of a library. You'd still have to check against which
version each binary is compiled.

Of course, you also gain in security, since all kind of library preloading
attacks are not possible anymore.

------
khc
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.

~~~
CUViper
Right - at least with glibc, ld.so unsets most LD_* variables and more for
both setuid and setgid programs. Grep for UNSECURE_ENVVARS in glibc source to
get the whole list and see how it's used. I'd be very surprised if any other
libc implementation didn't do the same.

------
davidp
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?

~~~
cgh
Static linking doesn't necessarily link the entire library, unless the entire
thing compiles to a single .o file. Linkers are smart enough to only link in
the object files needed by the program. So assuming you are only linking in
well-designed libraries, I guess it's possible that statically-linked software
will be smaller since it will leave out the stuff you aren't using.

~~~
spc476
I recently played around with this, taking a rather small project (around
15,000 lines of code), putting it all into a single file and compiling. It did
produce a smaller executable, but the _real_ gain was in making every function
static (since it's all in a single file). Doing that, a total of 41 functions
were eliminated (either inlined or not used at all).

Was it worth the effort? Eh. But it was instructive and I'd like to attempt
(when I get some time) to try a larger project.

~~~
exDM69
Some popular software like SQLite combine all their sources into one big
source file called Amalgamation and then compile that. Their benchmarks show
modest but not negligible performance gain.

There's a lot of work going on in link time optimization at the moment, both
in LLVM and GCC. It's not quite ready for prime time, it still takes more than
a small change in your Makefile to deploy it (e.g. dealing with linkers etc).

With LLVM toolchain you can compile C code (or other high level code) into
LLVM IR, link the IR files together and run that through the optimizer.

You will notice that modern optimizers will want to inline everything if
possible and a lot of functions will be missing from the resulting binary.
Boundaries of object files are perhaps the biggest obstacle in optimization
today.

------
vinkelhake
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.

~~~
ploxiln
Yeah - so your stripped and dynamically linked executable is just about as
large as a statically built one... and yours still has to link glibc.

I can build busybox (a multi-call all-in-one executable, use symlinks to refer
to the binary with the name of a tool and it acts like that tool), with init
and bourne shell and the minimal set of command-line tools (coreutils remakes
and util-linux remakes) into a 600KiB executable statically linked with
uclibc. Combined with a linux kernel, I can boot with it. Meanwhile, my glibc
is 2MiB.

Modern computers are really amazing. And it's also amazing that the
understandable trend of letting software get bigger and slower as long as it
doesn't really cause problems on current hardware has resulted in such
astounding (though mostly harmless) waste.

All that said, these stali project pages have existed for years, and there's
nothing interesting to show for it. Not that many people really buy into this
thing (including me).

~~~
vinkelhake
Busybox is great and it's specifically built to be tiny. I don't really know
what the stali guys are going for. Are they building something to compete with
busybox or something more general? If it's the latter then a user will
probably have a lot of programs that use way more of the standard library than
"hello world" does.

As it stands, the FAQ entry is comparing apples and oranges. Comparing full-
featured and dynamically linked programs to statically linked, but feature-
limited ones is only interesting if you can get by with the feature-limited
version. I suspect we're in agreement.

------
chj
"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.

------
default_name
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](http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)
[2] -
[http://en.wikipedia.org/wiki/Inferno_%28operating_system%29](http://en.wikipedia.org/wiki/Inferno_%28operating_system%29)
[3] \-
[https://github.com/henrysher/sinit](https://github.com/henrysher/sinit) \-
[http://galos.no-ip.org/sdhcp](http://galos.no-ip.org/sdhcp) \-
[http://git.suckless.org/dmc/](http://git.suckless.org/dmc/) [4] -
[https://github.com/michaelforney/swc](https://github.com/michaelforney/swc)

------
prewett
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.

~~~
default_name
It's not that easy. Many libraries can't be statically linked, some programs
will break if it will be statically linked. It is impossible to link
statically with glibc. Even if it would be possible it's pointless. You will
need another lean libc, like musl. Than go figure list of bugs found by musl:
[http://wiki.musl-libc.org/wiki/Bugs_found_by_musl](http://wiki.musl-
libc.org/wiki/Bugs_found_by_musl)

~~~
justincormack
There is an experimental Musl gentoo stage I think now.

------
ch215
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](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.

------
vezzy-fnord
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.

~~~
plorkyeran
© 2006-2013 for something still not released certainly isn't promising.
Glancing at the git logs
([http://git.suckless.org/?s=idle](http://git.suckless.org/?s=idle)) there is
some ongoing work, so the project isn't totally dead at least.

~~~
herokusaki
Can you compile the world with static linking on Gentoo Linux or any of the
BSDs? If so, that could serve as a substitute.

------
nathell
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).

------
cgh
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."

~~~
GFK_of_xmaspast
I don't miss the general state of linux circa 1999 one bit.

~~~
hnisnotreddit
I, for one, miss spending 10 hours fully compiling GNOME 0.99.8 and
Englightenment 0.15 from CVS every week on my Pentium 133 running Linux
Mandrake.

Over the past 17 or so years I've been using linux full-time, I've experienced
3 or 4 of the "sweet spots", or times where using linux was superior to
everything else on the market. GNOME 1.x with Enlightenment 0.15 (vs Win98)
was the second one (the first, I'm told, was E DR0.13 with CmdrTaco's task
managing app and Hand of God theme vs Win95). I believe we are currently at
the end of another sweet spot with KDE 4.x being put out to pasture, as it
completely destroys the UX of Windows 7/8 and Mountain Lion.

But don't knock the state of linux circa 1999. Sure, you had to ensure your
sound cards had OSS drivers, and Winmodems sucked, but it was a superior
experience to Win9x even back then.

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

~~~
nathell
That name is already taken:
[http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)](http://en.wikipedia.org/wiki/Stalin_\(Scheme_implementation\))

------
Ziomislaw
Stali currently does not exist, but there are others statically linked distros
out there, ie. [http://starchlinux.org/](http://starchlinux.org/)

------
mrottenkolber
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. :(

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

------
oofabz
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/](http://st.suckless.org/)

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

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

~~~
_ak
Ever since uriel died, the suckless project doesn't really appreciate Go
anymore.

~~~
eekee
many people in uriel's cat-v community don't either. part of the problem is
go's community and its web focus. the other part is cat-v is now focused on a
plan 9 fork, and go solves problems which don't come up much on plan 9, or
which are already largely solved.

------
anon35
Static linking also relative in a discussion about coupling and OS
dependencies :
[http://unix.stackexchange.com/a/38914/17683](http://unix.stackexchange.com/a/38914/17683)

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

------
paulannesley
MONDAY, FEBRUARY 1, 2010 Stali:
[http://wayback.archive.org/web/20110727064007/http://eleveni...](http://wayback.archive.org/web/20110727064007/http://elevenislouder.blogspot.com/2010/02/stali.html)

