
Stali: A new static Linux distribution - antoinealb
http://sta.li/
======
JdeBP
( Also discussed previously at
[https://news.ycombinator.com/item?id=8819085](https://news.ycombinator.com/item?id=8819085)
and
[https://news.ycombinator.com/item?id=7261559](https://news.ycombinator.com/item?id=7261559)
)

Interesting points:

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- Everything not obviously covered by a fairly simplified hierarchy is put into /sucks , without fixing the problem of /etc still being a grab-bag miscellany.

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- /dev being for devices is a "Linux assumption".

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- There is no /usr/local .

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- /.git goes unmentioned. (-:

* [http://sta.li/filesystem](http://sta.li/filesystem) \-- Half a decade ago, it was claimed that it has no /lib . This is contradicted here.

* [http://dwm.suckless.org/](http://dwm.suckless.org/) \-- "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."

* [http://sta.li/installation](http://sta.li/installation) \-- Installation uses HTTP to fetch a boot volume image.

* [http://sta.li/installation](http://sta.li/installation) \-- The actual installation steps of the doco are "TODO".

* [http://sta.li/technologies](http://sta.li/technologies) \-- The Korn shell is the default.

* [http://sta.li/technologies](http://sta.li/technologies) \-- uses Gerrit Pape's runit, tinydyndns, and socklog

* Commentators a few years ago assumed no kernel modules or initrd. There isn't "official" word on this, however.

* Nor is there official word on PAM, which logically falls foul of a _no dynamic linking_ philosophy too.

~~~
onli
> [http://dwm.suckless.org/](http://dwm.suckless.org/) \-- "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."

The worst thing about that attitude is that the suckless programs I tried are
full of bugs and usability problems. I actually liked the idea of building
simplified core programs, without the bloat and bc stuff of the environment
around them, and thus opted to use st with a multiplexer. But if the result is
that one has a terminal where you can't copy stuff properly because it does
not handle linebreaks, or where you can't use ssh properly because the moment
you scroll all text gets distorted, that is not excellence, it's just bad. And
if they had more users they maybe would find those bugs, and get the help they
seem to need.

And the whole "we are cool, we configure in source code" is just lazy. It's
not like they gain anything from that, the spared lines of code pale in
comparison to the effort needed to organize the configuration at distro level.

~~~
jstimpfle
> And the whole "we are cool, we configure in source code" is just lazy.

Right. A little config file parsing library does not harm (and can be just
copied into the project) but goes a long way for user experience.

Look at icewm, one of my favourite software projects. Yes, it's written in 60K
lines of C++, but it's rock solid, fast and flexible. The configuration
mechanism is powerful and an example of "no bullshit" design.

~~~
onli
I just wish icewm had a more active project. I reported a bug and never got
feedback, it also was never fixed. But yes, apart from that it is a great WM,
and especially the configuration is what makes it great. My choice as well.

------
paulddraper
I really like the idea of static linking.

Then I think about how I'd patch the next inevitable openssl bug.

Then I don't like it as much.

~~~
qznc
I guess the "suckless" answer would be to not use OpenSSL.

~~~
spoiler
Who knows, we might soon get SuckleSSL. :)

Jokes aside, they have a bizarre philosophy and attitude, especially when you
consider their software is most of the time buggy, and… Well, sucky.

~~~
degobah
It's hard to take them seriously when they include statements like this on
their FAQ: "Of course Ulrich Drepper thinks that dynamic linking is great, but
clearly that’s because of his lack of experience and his delusions of
grandeur."

------
gdamjan1
"FHS sucks" \- and then they make an even worse hierarchy. at least modern
distros moved all distro-contents to a single /usr (possibly read-only,
snapshoted, etc) mount point.

#suckmore

~~~
jstimpfle
I don't know what a good hierarchy is, but with symlinks it should not be so
important where the mountpoints are. So why not keep opportunities to split
distro contents into convenient directories living under "/"?

Also separating writable from read-only content, or having volumes with
different performance characteristics, makes sense in certain situations. Why
not have these mountpoints directly under "/"?

~~~
gdamjan1
When distro-packaged content is in /bin and /sbin (and /lib, /usr etc), you
can't easily have those 4 directories in a single image that you can
atomically handle (upgrade, snapshot, mount, share, etc) and you must have
them together on the /.

That's why Android has /system, and Linux has /usr now.
([https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...](https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/)).

Ideally, and we are getting there, / should be tmpfs/rootfs, it's populated
with the needed structure by the initramfs, the distro is mounted on /usr
(readonly squashfs perhaps?), user data is /home, system data is /var,
configuration is /etc. And the system should boot with empty /home /var and
/etc ideally. Soon...

~~~
jstimpfle
If you want all in one file system, make symlinks. Problem solved.

------
viraptor
I'm confused about some claims / justifications. For example:

> A user can easily run dynamic library code using LD_PRELOAD in conjunction
> with some trivial program like ping.

No... Not sure if it ever worked, but it's definitely not possible for many
years now.

Also the link to the ASLR effectiveness paper was valid in 2004. That means
they're still testing 32bit systems and effectively say scanning 64bit systems
the same way is unfeasible.

~~~
icebraining
Yeah, that's outdated, but there have been a few related bugs in the dynamic
linker not that long ago, like LD_AUDIT:
[http://seclists.org/fulldisclosure/2010/Oct/344](http://seclists.org/fulldisclosure/2010/Oct/344)

------
faragon
I love the "suckless" philosophy [1], and I'm glad that Stali sticks
explicitly to it.

[1] [http://suckless.org/philosophy](http://suckless.org/philosophy)

~~~
bitwize
Too bad it prodyces buggier, _suckier_ code.

------
sdegutis
> _" Follow the suckless philosophy"_

I used to love the idea of the suckless philosophy, until I forked `st` to
make it work on OS X by removing globals and by separating the terminal
emulator logic from the X11 logic, and asked[1] on the mailing list if they'd
be interested in merging my changes. The responses I got made me never want to
use any suckless software ever again.

[1]
[http://lists.suckless.org/dev/1408/23366.html](http://lists.suckless.org/dev/1408/23366.html)

~~~
yesco
Wow that was really disheartening to read. Definitely didn't expect that level
of childishness.

------
pjmlp
I thought we were happy to leave behind static linked OSes back in the 90's,
other than targeting embedded deployments....

~~~
INTPenis
One of the first things I read was support for arm and RPi so I assume it's
targeting the IoT.

~~~
Narishma
RPi is used for a lot more than IoT.

------
qume
Shocked that it takes a fringe project to be promoting static linking and
cleaning up the filesystem.

Would love to hear the linux grandfathers chime in...

~~~
copperx
Static linking is a virtue now? I don't understand the advantages.

~~~
qznc
Google Go and Rust promote it. However, deploying web services is different
than Linux distro.

~~~
rkangel
I don't know about Go, but Rust doesn't promote it. Rust compiles a whole
binary at once (for full program optimisation), but that binary can be a
dynamic library or executable. How you then build the operating system on top
of that is up to you.

~~~
qznc
Recently, ripgrep was on the frontpage. It says "Linux binaries are static
executables" [0]. If I run ldd on cargo, it spits out the usually glibc
dependencies, but Rust libraries are statically linked. It seems to be the
default behavior of cargo? I would describe that as "promote static linking".

Personally, I don't judge this as good or bad. There is no simple answer.
Static linking has clear disadvantage wrt security patches. On the other hand,
it makes little sense to dynamically link tiny libraries, e.g. a queue data
structure.

[0]
[https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

~~~
burntsushi
> It says "Linux binaries are static executables" [0].

They are. Running `ldd` on cargo doesn't confirm or deny this. You need to run
`ldd` on the binary distributed:

    
    
        $ curl -sLO 'https://github.com/BurntSushi/ripgrep/releases/download/0.2.1/ripgrep-0.2.1-x86_64-unknown-linux-musl.tar.gz'
        $ tar xf ripgrep-0.2.1-x86_64-unknown-linux-musl.tar.gz 
        $ ldd ./ripgrep-0.2.1-x86_64-unknown-linux-musl/rg
                not a dynamic executable
    

This is not the default output on Linux. You need to compile with musl instead
of glibc:
[https://news.ycombinator.com/item?id=12565268](https://news.ycombinator.com/item?id=12565268)

------
simophin
I still don't understand why systemd sucks

~~~
morganvachon
That's a loaded question, and I'm only qualified to answer from my perspective
and experience. My biggest gripe with it has always been that it is alpha-
quality software, even today, that has a central role in an otherwise mature
OS ecosystem. It has been widely adopted (some would say forced or tricked
into adoption by a few distros) and therefore all the major Linux
distributions are now running at an alpha level while its creators try to
figure out exactly what they want it to be. That was the state of Linux in the
late 90s, a state that it overcame during the 2000s, but now it's regressing
again.

First it was "just an init to replace SysV", something I could get behind, and
back in 2012 or so I was actually excited about it. Then it started growing,
replacing individual components of GNU/Linux with a monolithic mega-app that
has more in common with Windows NT based OSes than with anything UNIX-like.
Gone is the philosophy of "do one thing and do it well", replaced with "do
everything no matter the quality of the results".

I've always been a Slackware user since I started messing with Linux in the
late 90s, and these days I find it getting faster and better while mainstream
Linux distros slow down and grow more and more bugs. One of my benchmark
systems for observing the growing bloat of modern OSes is an Atom based
netbook from around 2010. It shipped with Windows 7 Starter, which it ran
acceptably but not great.

Recently I tested Windows 10, Slackware 14.2, Ubuntu 14.04, Ubuntu 16.04,
Debian unstable, OpenBSD, and Elementary OS Loki on it. Slackware was the
fastest OS on it by a wide margin, followed by OpenBSD, then Debian, Ubuntu
14.04, Elementary, Windows, and Ubuntu 16.04 dead last. Guess which of those
(not counting Windows) do not have systemd? Yep, Slackware and OpenBSD. Maybe
it's a coincidence, but given how Ubuntu 16.04 on my modern workstation gets
progressively slower with each systemd update, whereas Slackware on the same
machine continues to chug along with no issues, that's telling.

All of that said, systemd was and maybe still is a good idea, if only they can
stop trying to reinvent the wheel and instead fix the spokes they broke along
the way. I can't say I'm happy about eroding the UNIX philosophy from Linux,
but if systemd is the future of Linux then it damn well needs to be a stable
future.

~~~
pjmlp
The irony of the eroding the UNIX philosophy from Linux is that most real UNIX
systems, meaning AIX, HP-UX, Solaris, NeXTSTep (cough macOS), Tru64,... do
have something similar to systemd.

Sometimes shouting "UNIX philosophy" in GNU/Linux forums reminds me of
emigrants that keep traditions of their home countries alive that are long out
of fashion back home.

~~~
throwaway2048
commercial unixes haven't been relevant for decades. Unix is linux these days.

~~~
mort96
How about the second largest desktop OS in the world, OS X (or now macOS)?
That's BSD.

~~~
riffraff
OSX is actually a certified UNIX
[http://www.opengroup.org/openbrand/register/](http://www.opengroup.org/openbrand/register/)

~~~
SSLy
and systemd was modelled partially after its launchd

------
yellowapple
Hasn't stali been around for at least a little while now? I don't think "brand
new" is quite right :)

Looks like a neat distro, though. It's been on my bucket list to try.

------
saynsedit
Sucks less until it starts to suck more. It's religion not science. Classic
NIH.

~~~
icebraining
Nonsense. They have a clear philosophy on what makes software suck less, it
doesn't matter where it comes from.

[http://suckless.org/philosophy](http://suckless.org/philosophy)

~~~
saynsedit
Exactly my point. Philosophy has its place in software engineering but often
it's not on a pedestal.

~~~
icebraining
I was responding to the "NIH" comment. It's not NIH syndrome if it doesn't
matter where it comes from.

 _Philosophy has its place in software engineering but often it 's not on a
pedestal._

That's a philosophy in itself, as is pragmatism or adherence to science. You
just happen to disagree with theirs.

~~~
saynsedit
Meh. I don't buy the "moderate valuing of philosophy is a philosophy"
argument. If everything is a philosophy then nothing is a philosophy.

My point is, suckless products can actually suck despite following their
"philosophy." It's not only the UI, although strictly adhering to the "UNIX"
philosophy has its flaws. No, it's the suckiness of the source code that I'm
talking about, e.g. dwm is composed of ad-hoc internal abstractions and
special cases based on arcane X11 WM domain knowledge, not to mention the
suckless comment "philosophy": that comments are a sign of bad code therefore
don't use them.

Their "philosophy" is narrow-minded and overly simplistic, like a religion.
It's also not based in truth, just biased anecdotes, e.g.

 _" Most hackers actually don’t care much about code quality."_

...What? Is there a source for this information?

Their "philosophy" only makes sense for the smallest toy programs. Notice how
there is no suckless kernel, It would likely be a heaping pile. Dogma loses,
science wins.

~~~
Touche
> Meh. I don't buy the "moderate valuing of philosophy is a philosophy"
> argument. If everything is a philosophy then nothing is a philosophy.

Nope, all ideas are philosophy. Just as all matter is made up of atoms. You
can't escape philosophy no matter how hard you try.

~~~
saynsedit
Except "all matter is made of atoms" has been empirically shown and is
scientifically consistent, whereas "all ideas are philosophy" is just
meaningless abstract gibberish. It's not the same.

~~~
Touche
Luckily pragmatism really is a philosophy, with an actual documented history.
Is that scientific enough for you?

~~~
saynsedit
It doesn't matter. Engineering disciplines don't need a philosophy. Imagine if
bridge builders had bridge building philosophies. It's nonsense.

------
brudgers
_20160825 stali for RPi stapi.img.gz available for download_

Now for Raspberry Pi, it appears if my decryption is correct.

------
mseidl
This project has been around for a while.

------
fhemn3
There is a video with the recent changes.

[http://suckless.org/conferences/2016](http://suckless.org/conferences/2016)

[http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe-
stali_learn...](http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe-
stali_learnings_and_beehive_observation.webm)

------
lutusp
> Achieve better memory footprint than heavyweight distros using dynamic
> linking and all its problems

If this is really effective in reducing executable size, it's supremely
ironic, since the original point of dynamic linking was to reduce the overall
size of groups of executables by sharing common function libraries.

~~~
loup-vaillant
More likely, they're saying mainstream distros are so bloated even dynamic
linking can't save them: dynamic linking does reduce memory footprint, but
that only _mitigates_ bloat.

~~~
mbel
I think that "dynamic linking and all its problems" imply that some of the
bloat comes from the dynamic linking itself. At least that's how I read it.

I believe argument here goes beyond the sole fact of introducing dynamic
linker and includes the fact that dynamic linking may encourage duplication of
functionality in applications ending up in bloated system (on the other hand
static linking doesn't seem to do anything to discourage bloat).

~~~
loup-vaillant
I've read around here that static linking allow compilers to remove dead code
(unused symbols) from the relevant libraries. The same cannot be done for
shared libraries, because you never know which symbols are unused —if any.

------
scott_karana
Why is static linking supposed to REDUCE memory usage and binary size? Am I
missing something really obvious?

Eg, if five different binaries are statically linked against the same version
of OpenSSL, won't it be in memory and on disk four times more than it would be
on a dynamic system?

~~~
qznc
Many applications only use parts of libraries, then the linker can throw the
unnecessary parts away.

~~~
infinity0
How do I get it to do that?

    
    
      $ cat test.c 
      #include <stdio.h>
      int main() { printf("Hello, World!\n"); }
      $ gcc -o test1 test.c && ls -lgG test1
      -rwxr-xr-x 1 6712 Sep 28 10:24 test1*
      $ gcc -static -o test1 test.c && ls -lgG test1
      -rwxr-xr-x 1 800904 Sep 28 10:24 test1*

~~~
ericbb
I always use dynamic linking but I thought it'd be fun to try making a small,
static hello-world. The following assumes x86-64 Linux (and is a total hack
that "works for me" NO WARRANTY!).

    
    
        $ cat test.c
        static int sys_write(int fd, const void *buf, unsigned long n)
        {
            asm("mov $1,%rax; syscall");
        }
        
        static void sys_exit(int status)
        {
            asm("mov $60,%rax; syscall");
        }
        
        void _start(void)
        {
            char s[] = "Hello, World\n";
            int r = sys_write(1, s, sizeof(s) - 1);
            sys_exit(r == -1 ? 1 : 0);
        }
        $ gcc -nostdlib -static -o test test.c && ls -lgG test
        -rwxr-xr-x 1 1480 Sep 28 11:47 test
    

More to the point of your question, if you want to see the effect you're
looking for, I think you need to link to a libfoo.a library that includes some
module.o that your program doesn't use.

~~~
ericbb
I like this one even better:

    
    
        $ cat test.c
        void _start(void)
        {
            __asm__(
                "movabsq $6278066737626506568,%rax\n\t"
                "movq %rax,-32(%rsp)\n\t"
                "movl $1684828783,-24(%rsp)\n\t"
                "movw $10,-20(%rsp)\n\t"
                "movq $1,%rax\n\t"
                "movq $1,%rdi\n\t"
                "leaq -32(%rsp),%rsi\n\t"
                "movq $13,%rdx\n\t"
                "syscall\n\t"
                "movq $60,%rax\n\t"
                "movq $0,%rdi\n\t"
                "syscall");
        }
        $ gcc -nostdlib -static -Os -o test test.c && strip test && ls -lgG test
        -rwxr-xr-x 1 864 Sep 28 14:22 test
    

864 bytes! :)

------
praptak
Has anyone actually tested the claim of static linking improving performance?

The dynamic linking might not be free in terms of cycles but a huge part of
the code is already in memory rather than on disk at the time the binary
starts.

------
mkj
Is there any work on ASLR for quasi-static binaries? So you have no external
linking (good for distribution and unsurprising dependencies), but still
relocate at runtime.

~~~
viraptor
In stali, or in general? For stali there's a slightly confusing FAQ entry:
[http://sta.li/faq](http://sta.li/faq) / "Aren’t statically linked executables
less secure?"

> it is simple to use position-independent code in static executables and
> (assuming a modern kernel that supports address randomization for
> executables) fully position-independent executables are easily created on
> all modern operating systems. [...] Thus we consider this as an issue with
> low impact and this is not a real focus for us.

So I don't know if they do it or not. If I read it correctly, they just ignore
something they say is easy to do.

But in general, as mentioned, there's normally nothing that prevents you from
compiling PIE C code even if you use -static.

~~~
Retr0spectrum
I'm assuming that even with PIE, the relative positioning of the statically
linked libraries is constant. That means you only need a single address leak
to be able to ROP to anywhere.

~~~
viraptor
That's how I understand it as well (it's a single rel/ro segment). But then
again, in most cases you only need any address anyway. Rop gadgets are
everywhere...

------
unicornporn
Why not Stalin? Catchier and easier to remember. :-)

~~~
h4nkoslo
The name is taken.

[https://github.com/barak/stalin](https://github.com/barak/stalin)

------
micro_softy
Any plans to include i386?

------
martinsb
It is quite hard to take seriously any project that so much uses word "suck"
to describe other projects, i.e., other people work, or their approaches.

~~~
Annatar
Why? Most software out there sucks. Computers suck. Most people are
unbelievably bad at designing and writing software. Very few of us are RJ
Micals or Adam Leventhals, or Jeff Bonwicks. Most people have major issues
with reasoning and implementation when it comes to writing software. It's the
reality.

~~~
qwertyuiop924
Ironically, suckless.org is a bunch of plan9 elitists. The plan9 elitists are
similar to solaris elitists, but have radically different beliefs, and
probably believe that Bonwick and Leventhal and the rest should be jailed for
working on ZFS, DTrace, Zones, SMF, etc.

------
plexu
Um... Sounds too much like Stalin?

------
Annatar
_Ignore FHS of Linux, it simply sucks._

Wow. Just wow. So these guys don't understand UNIX. Like they're going to do
it better than the fathers of UNIX at AT&T (who came up with the specification
on which the FHS is based). Yeah, OK.

 _Achieve better performance than any other x86_64 or arm distribution, as
only statically linked binaries are used_

Wow. So not only do they not understand UNIX, but now every process will have
memory allocated for every symbol in the ELF header, and any application
linking with the same set of libraries will have their own copy of the same
machine code, and the startup will be longer, because every application will
be larger. Any patching which will need done, all affected applications will
need recompiled. Why does this remind me of Windows?

 _Achieve better memory footprint than heavyweight distros using dynamic
linking and all its problems_

Yeah, of course! Why try to rack your brains designing versioned interfaces
and making sure libraries are backward compatible, when you can just
statically link everything and create tremendous overhead in terms of
maintenance and security? No point in writing linker map files and having the
runtime linker present the correct version of the API to the application,
riiiggghhhttt?

Is this a case of more Windows people getting onto the Linux bandwagon, and
just completely not getting it, or what?

~~~
72deluxe
Windows? Have you ever heard of DLLs?

~~~
yrro
My Windows system currently has 21 copies of zlib1.dll on it, each shipped by
a different program. While I have no doubt that Windows programmers have heard
of DLLs, they clearly haven't grasped the idea of shared libraries.

~~~
72deluxe
The problem in that case is developers not putting their DLLs in a system
directory! Windows will use WinSXS to avoid problems with different versions
(DLL hell).

Once loaded into memory, DLLs save loading the same code twice. See
[http://www.ksyash.com/2011/01/dll-
internals/](http://www.ksyash.com/2011/01/dll-internals/)

~~~
JdeBP
This hasn't seen an airing in a while, because it became accepted wisdom years
ago. You're encouraging a bad design that the world has learned better than to
employ.

* [http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...](http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-directory.html)

~~~
Annatar
_This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the
application's own subtree rooted at "\Program Files\company\product\"._

This plainly shows just how poorly thought-out Windows is, to paraphrase:

 _we didn 't design a directory tree like UNIX, and we don't have a proper
runtime linker like UNIX, so we are going to swipe using the bin/ directory
like on UNIX because we don't know where else to put stuff, and while we're at
it, we will rename bin/ to Bin/ because we don't know any better, and also
while we're at it, we'll dump all the dynamically linked libraries which the
application needs into that mis-named Bin/ directory._

Because Windows doesn't have a proper operating system structure, nor does it
have a clean structure (case in point C:\Program Files (x86)\, even if your
Windows is 64-bit), nor does it have a runtime linker with the functionality
equivalent to ld.so.1 (the only way to get anything close to
-Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and
$ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE).

How amateurishly bad can one get? _Wintendo_ is a gift that just keeps on
giving...

