37 ms·

Stali: A new static Linux distribution

185 points by antoinealb 10y ago

brudgers 10y ago
20160825 stali for RPi stapi.img.gz available for download Now for Raspberry Pi, it appears if my decryption is correct.
simophin 10y ago
I still don't understand why systemd sucks
- JdeBP 10y ago
  static linux isn't really a reaction to systemd. What it is a reaction to is exemplified both by what the blurb on its WWW spends most of its time on, and indeed by its very name: dynamic linking. "Executing statically linked executables is much faster" ... "Statically linked executables are portable" ... "Statically linked executables use less disk space" ... "Statically linked executables consume less memory" -- http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/ http://wayback.archive.org/web/20090525150626/http://blog.ga...
  - arjun1296 10y ago
    I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck.
    - modifieddog 10y ago
      > I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. If I remember correctly, the argument goes someting like this: modern compilers, i.e. something as recent as the Plan 9 toolchain or a GCC version from this millenium, usually compile in only the necessary code with static linking, and not whole libraries. With dynamic linking, you always have to load the whole library into memory, which supposedly pays off only with heavily used libraries such as libc (e.g. think about how many libraries used by Firefox/Chromium are used by other programs). So the hope is (combined with a general strive for small programs), since text pages are shared between processes and statically linked programs only include the absolute necessary code you end up with a smaller memory footprint. (I'm not sure whether you save disk space, but I don't think that would be a problem nowadays. Heck, look at go binaries.) And I guess, the linker could do more whole-program-optimization on a statically linked program, since all the coude is available. > For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck. Generally you would want to have a proper build system. In case of StaLi, they have one global git repository (/.git). An update is simply "git pull && make install". I don't know if this process is slower or faster than binary updates, but if they strive for small programs/binaries, then I guess it doesn't matter as much. Source-based distributions, such as Gentoo, have the advantage that you don't have to wait for someone to publish an upgraded binary, you can compile it yourself, instead. This might give you a slight edge for security vulnerabilities.
      - pjmlp 10y ago
        Modern compilers?! Static linking was already like that in MS-DOS compilers.
        modifieddog 10y ago
        > Modern compilers? I was being partially ironic. It seems that the common assumption is still that you (statically) link in the whole library. Then, of course, binaries get really huge. But when you link in only what's necessary, the overhead is probably relatively small (when was the last time you used all of libc?). The other thing is (which you can see in this thread, as well), people seem to think that you can do things only the way we are doing them now without ever questioning whether these things are still apropriate and how they originally came into existence. ("There has to be dynamic linking", "we have to use virutal memory", "there have to be at least 5 levels of caches", etc.) To my knowledge, all the reasons regarding saving space, security, and maintenance were all made up after the fact (and aren't necessarily true, even (or especially) with modern implementations). Originally, dynamic linking was intended for swapping in code at runtime (was it Multics or OS/360?), which you can't do anymore today. Furthermore, dynamic linking (as it is done today) is really complex. In contrast, static linking is much simpler (=> fewer bugs/security holes). I think we should reconsider if the overhead is worth it or not (do you really care whether your binaries make up 100MB or 200MB on your 1TB HDD?). For embedded devices: yes, space does matter, but you probably don't run a full fledged Ubuntu desktop on you IoT device, anyway. You use different approaches (e.g. busybox, buildroot, etc.).
      - 0xcde4c3db 10y ago
        > you always have to load the whole library into memory Not really. You do have to mmap it, but it can be demand-paged (executables are handled this way on most modern systems, which is why compressed executables are usually a bad idea). IIRC, what saves time is mostly not having to do the actual linking part where the references are resolved. This can be precomputed and stashed in the binary (an optimization well-known to Gentoo+KDE users), but that confuses some package managers, breaks some uses of dlopen()/dlsym(), and has issues with ASLR.
- striking 10y ago
  Here are a pair of links that you may have missed under the "Don’t use systemd (read more about why it sucks)" line item. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The first link reads like a sort of 99 Theses, while the second is a dissertation on why people will never get along on the subject of systemd.
  - anon4711 10y ago
    I take the attribution in the first link (references to "Führerbunker" and "Führer") to mean that the author is comparing Lennart Poettering to Hitler. That's not funny, it's just very, very inappropriate.
    - striking 10y ago
      I didn't write the linked content, nor did I choose the links. If you feel strongly about this, consider contacting the authors of the story.
      - anon4711 10y ago
        I didn't mean to imply that you did; sorry if that came out wrong.
- justinsaccount 10y ago
  Because people like to complain more than they like to actually build a usable alternative. Edit: here's a great example from one of the links in the other comment: suckless complaining about "sysv removed" in systemd. Link takes you to this changelog entry: "The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays." So, code was removed from the init daemon itself and moved into a standalone utility that does one specific job. Systemd is now both being blamed for bloating init, and for splitting functionality out into a separate tool that does one thing.
  - bnolsen 10y ago
    runit on void linux runs great. it's tiny, easy to understand and very fast. and it doesn't try to take everything over.
  - clarry 10y ago
    > Because people like to complain more than they like to actually build a usable alternative. More like people have had perfectly usable alternatives but now the hivemind is more or less forcing something else onto them. I don't need to build a new init system, I have one that works, thank you. Please don't give me systemd.
    - justinsaccount 10y ago
      The one I had did not work so I am happy to have systemd now.
  - qwertyuiop924 10y ago
    They built many. runit, s6, nosh, bsdinit, openrc. But yeah, it is being blamed for bloating init, because for one thing, cron isn't init's job. And that's just the start.
- bitwize 10y ago
  Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.
  - DigitalCannon 10y ago
    Maybe they're far worse to you.. You also have the option of creating something yourself if everyting sucks so much.
  - thescribe 10y ago
    As someone who has found runit to meet my needs I don't think I have any reason to make peace with systemd. I feel like part of what people object to about systemd is the 'one true way to linux' thing.
    - vacri 10y ago
      Right now what I'm objecting to with systemd is that this system replaces syslog, has been created and driven by the enterprise linux distro, with full-time experienced linux devs, and has been released and used in production for years... ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache.
      - vidarh 10y ago
        That is "replaces" syslog (you can still have it forward to syslog if you insist) is one of the best parts. After getting used to journald I have no desire to ever go back to dealing with syslog. > ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache. What are those "dirty hacks"? You can trivially use logstash or similar or you can forward log entries to a remote syslog-compatible endpoint. Incidentally the same that people usually do with syslog.
  - striking 10y ago
    I cannot even begin to describe how silly your comment is. Since when were politicians even comparable to programs? Do we "elect" a init system, as one nation united under Torvalds? I'm hoping I was just trolled by an HN-flavored Markov Chain.
- morganvachon 10y ago
  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.
  - billforsternz 10y ago
    I am puzzled that you had an Atom based netbook from around 2010 that shipped with any kind of Windows 10.
- Annatar 10y ago
  Because it's a Windows monolithic approach to startup, shutdown and dependency management, as well as being a poor copy of Solaris' service management facility, smf(5).
JdeBP 10y ago
( 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.
- striking 10y ago
  > The actual installation steps of the doco are "TODO". Building a kernel and such can be done like this: http://sta.li/build http://sta.li/build I assume that's how that part of installation works. They could have documented that more nicely, though... (Also, I use dwm. It works out of the box, using it on a stock Arch system is as simple as compiling, installing, and adding it to .xinitrc. And configuration has been made extremely simple also. It's not obvious at all, but it works for the particular niche I fit into.)
- startling 10y ago
  > Installation uses HTTP to fetch a boot volume image. This is a problem with all of the suckless software and it, well, sucks.
saynsedit 10y ago
Sucks less until it starts to suck more. It's religion not science. Classic NIH.
- lifthrasiir 10y ago
  I don't doubt that this won't fly in the traditional sense, but at the very least NIH is also a wheel for diversity. It is clearly interesting to see what can be done there.
- icebraining 10y ago
  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 10y ago
    Exactly my point. Philosophy has its place in software engineering but often it's not on a pedestal.
    - icebraining 10y ago
      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 10y ago
        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.
yellowapple 10y ago
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.
plexu 10y ago
Um... Sounds too much like Stalin?
viraptor 10y ago
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.
- codemac 10y ago
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59159 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59159 is an older reference, and that's 16 years ago..
- icebraining 10y ago
  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
- Arnt 10y ago
  IIRC that worked in the summer of 1992, and was blocked sometime that year or the next.
micro_softy 10y ago
Any plans to include i386?
qume 10y ago
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 10y ago
  Static linking is a virtue now? I don't understand the advantages.
  - qznc 10y ago
    Google Go and Rust promote it. However, deploying web services is different than Linux distro.
    - rkangel 10y ago
      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 10y ago
        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 10y ago
        > 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
paulddraper 10y ago
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.
- giovannibajo1 10y ago
  You'd run "pkg-manager upgrade", just like you do with dynamic linking.
  - jtietema 10y ago
    Yep but now instead of fetching 1 updated library, you depend on everybody and their cat to rebuild their binaries and publish updated versions.
    - smegel 10y ago
      You would thing a distro like this would be more like gentoo...you recompile stuff as needed (which for openssl means almost everything).
      - cheiVia0 10y ago
        Gentoo is dynamically linked, so you only recompile if there's an ABI break - a major version - not a patch/minor release. And, you only recompile the stuff that directly links to it. With static linking, you literally need to recompile everything that uses the library in any form, for every single change. So of there's a security fix in openssl and LibreOffice uses openssl, you need to recompile LibreOffice. If QEMU uses libssh2 which uses openssl, you need to recompile QEMU, even though it doesn't use openssl directly. With Gentoo you just recompile openssl and that's it. And if there a fix to glibc, you need to recompile EVERYTHING because everything would be statically linked to it.
        ngrilly 10y ago
        You don't have to recompile everything. If your system keeps a cache of object files, you only have to relink everything, which is quicker.
mkj 10y ago
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.
- tedunangst 10y ago
  -fPIE? Works on OpenBSD.
- viraptor 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
Why not Stalin? Catchier and easier to remember. :-)
- h4nkoslo 10y ago
  The name is taken. https://github.com/barak/stalin https://github.com/barak/stalin
- parski 10y ago
  Word.
martinsb 10y ago
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.
- txdv 10y ago
  His site is calles suck less so i guess it is his moto
- lsh 10y ago
  lighten up and pull that stick out
- Annatar 10y ago
  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 10y ago
    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.
scott_karana 10y ago
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?
- marmaduke 10y ago
  If you took the "one tool one purpose" thing to an extreme, you'd only have one binary with OpenSSL compiled in, right? Given some familiarity with the suckless ideology, it seems that it is the simplicity of static linking, not conservative use of disk space, which is its virtue. For, if anyone groks the tool chain perfectly but lacks disk space, I'd like to hear the secret.
  - Retr0spectrum 10y ago
    > you'd only have one binary with OpenSSL compiled in So then any process that wanted to use crypto etc. would have to call this binary? That just seems like a very inefficient way if implementing dymanic linking...
    - JdeBP 10y ago
      You have the wrong metric. The metric should be the efficiency of the mechanism in implementing SSL. Now look at things like Gerrit Pape's sslio , http://smarden.org/ipsvd/sslio.8.html http://smarden.org/ipsvd/sslio.8.html . Note that the subject at hand purportedly uses several of Gerrit Pape's other tools.
- qznc 10y ago
  Many applications only use parts of libraries, then the linker can throw the unnecessary parts away.
  - infinity0 10y ago
    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*
pjmlp 10y ago
I thought we were happy to leave behind static linked OSes back in the 90's, other than targeting embedded deployments....
- INTPenis 10y ago
  One of the first things I read was support for arm and RPi so I assume it's targeting the IoT.
  - Narishma 10y ago
    RPi is used for a lot more than IoT.
faragon 10y ago
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 10y ago
  Too bad it prodyces buggier, suckier code.
mseidl 10y ago
This project has been around for a while.
Annatar 10y ago
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 10y ago
  Windows? Have you ever heard of DLLs?
  - yrro 10y ago
    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 10y ago
      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/
lutusp 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      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.
gdamjan1 10y ago
"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 10y ago
  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 10y ago
    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/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...). 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 10y ago
      If you want all in one file system, make symlinks. Problem solved.
  - Touche 10y ago
    If I have to set up a bunch of symlinks to get basic packages to work my distro has failed me.
tibbarrabbit 10y ago
This is hilarious
- sctb 10y ago
  Please make sure to comment civilly and substantively on Hacker News. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
praptak 10y ago
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.
sdegutis 10y ago
> "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 10y ago
  Wow that was really disheartening to read. Definitely didn't expect that level of childishness.
fhemn3 10y ago
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_learnings_and_beehive_observation.webm http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe-stali_learn...

185 points by antoinealb 10y ago

20160825 stali for RPi stapi.img.gz available for download Now for Raspberry Pi, it appears if my decryption is correct.

simophin 10y ago

I still don't understand why systemd sucks

JdeBP 10y ago
static linux isn't really a reaction to systemd. What it is a reaction to is exemplified both by what the blurb on its WWW spends most of its time on, and indeed by its very name: dynamic linking. "Executing statically linked executables is much faster" ... "Statically linked executables are portable" ... "Statically linked executables use less disk space" ... "Statically linked executables consume less memory" -- http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/ http://wayback.archive.org/web/20090525150626/http://blog.ga...
- arjun1296 10y ago
  I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck.
  - modifieddog 10y ago
    > I refuse to believe that disk space is less as it can leverage other libraries in the deps list to load at run time and other can use it too. If I remember correctly, the argument goes someting like this: modern compilers, i.e. something as recent as the Plan 9 toolchain or a GCC version from this millenium, usually compile in only the necessary code with static linking, and not whole libraries. With dynamic linking, you always have to load the whole library into memory, which supposedly pays off only with heavily used libraries such as libc (e.g. think about how many libraries used by Firefox/Chromium are used by other programs). So the hope is (combined with a general strive for small programs), since text pages are shared between processes and statically linked programs only include the absolute necessary code you end up with a smaller memory footprint. (I'm not sure whether you save disk space, but I don't think that would be a problem nowadays. Heck, look at go binaries.) And I guess, the linker could do more whole-program-optimization on a statically linked program, since all the coude is available. > For static executable the same dependent library will have to linked to all binaries. Maintenance is a pain in the neck. Generally you would want to have a proper build system. In case of StaLi, they have one global git repository (/.git). An update is simply "git pull && make install". I don't know if this process is slower or faster than binary updates, but if they strive for small programs/binaries, then I guess it doesn't matter as much. Source-based distributions, such as Gentoo, have the advantage that you don't have to wait for someone to publish an upgraded binary, you can compile it yourself, instead. This might give you a slight edge for security vulnerabilities.
    - pjmlp 10y ago
      Modern compilers?! Static linking was already like that in MS-DOS compilers.
      - modifieddog 10y ago
        > Modern compilers? I was being partially ironic. It seems that the common assumption is still that you (statically) link in the whole library. Then, of course, binaries get really huge. But when you link in only what's necessary, the overhead is probably relatively small (when was the last time you used all of libc?). The other thing is (which you can see in this thread, as well), people seem to think that you can do things only the way we are doing them now without ever questioning whether these things are still apropriate and how they originally came into existence. ("There has to be dynamic linking", "we have to use virutal memory", "there have to be at least 5 levels of caches", etc.) To my knowledge, all the reasons regarding saving space, security, and maintenance were all made up after the fact (and aren't necessarily true, even (or especially) with modern implementations). Originally, dynamic linking was intended for swapping in code at runtime (was it Multics or OS/360?), which you can't do anymore today. Furthermore, dynamic linking (as it is done today) is really complex. In contrast, static linking is much simpler (=> fewer bugs/security holes). I think we should reconsider if the overhead is worth it or not (do you really care whether your binaries make up 100MB or 200MB on your 1TB HDD?). For embedded devices: yes, space does matter, but you probably don't run a full fledged Ubuntu desktop on you IoT device, anyway. You use different approaches (e.g. busybox, buildroot, etc.).
    - 0xcde4c3db 10y ago
      > you always have to load the whole library into memory Not really. You do have to mmap it, but it can be demand-paged (executables are handled this way on most modern systems, which is why compressed executables are usually a bad idea). IIRC, what saves time is mostly not having to do the actual linking part where the references are resolved. This can be precomputed and stashed in the binary (an optimization well-known to Gentoo+KDE users), but that confuses some package managers, breaks some uses of dlopen()/dlsym(), and has issues with ASLR.
striking 10y ago
Here are a pair of links that you may have missed under the "Don’t use systemd (read more about why it sucks)" line item. http://suckless.org/sucks/systemd http://suckless.org/sucks/systemd http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The first link reads like a sort of 99 Theses, while the second is a dissertation on why people will never get along on the subject of systemd.
- anon4711 10y ago
  I take the attribution in the first link (references to "Führerbunker" and "Führer") to mean that the author is comparing Lennart Poettering to Hitler. That's not funny, it's just very, very inappropriate.
  - striking 10y ago
    I didn't write the linked content, nor did I choose the links. If you feel strongly about this, consider contacting the authors of the story.
    - anon4711 10y ago
      I didn't mean to imply that you did; sorry if that came out wrong.
justinsaccount 10y ago
Because people like to complain more than they like to actually build a usable alternative. Edit: here's a great example from one of the links in the other comment: suckless complaining about "sysv removed" in systemd. Link takes you to this changelog entry: "The support for SysV and LSB init scripts has been removed from the systemd daemon itself. Instead, it is now implemented as a generator that creates native systemd units from these scripts when needed. This enables us to remove a substantial amount of legacy code from PID 1, following the fact that many distributions only ship a very small number of LSB/SysV init scripts nowadays." So, code was removed from the init daemon itself and moved into a standalone utility that does one specific job. Systemd is now both being blamed for bloating init, and for splitting functionality out into a separate tool that does one thing.
- bnolsen 10y ago
  runit on void linux runs great. it's tiny, easy to understand and very fast. and it doesn't try to take everything over.
- clarry 10y ago
  > Because people like to complain more than they like to actually build a usable alternative. More like people have had perfectly usable alternatives but now the hivemind is more or less forcing something else onto them. I don't need to build a new init system, I have one that works, thank you. Please don't give me systemd.
  - justinsaccount 10y ago
    The one I had did not work so I am happy to have systemd now.
- qwertyuiop924 10y ago
  They built many. runit, s6, nosh, bsdinit, openrc. But yeah, it is being blamed for bloating init, because for one thing, cron isn't init's job. And that's just the start.
bitwize 10y ago
Hating systemd is like hating Hillary Clinton at this point. It's well past time to suck it up and make peace with your next init system/President because the only viable alternative(s) are far worse.
- DigitalCannon 10y ago
  Maybe they're far worse to you.. You also have the option of creating something yourself if everyting sucks so much.
- thescribe 10y ago
  As someone who has found runit to meet my needs I don't think I have any reason to make peace with systemd. I feel like part of what people object to about systemd is the 'one true way to linux' thing.
  - vacri 10y ago
    Right now what I'm objecting to with systemd is that this system replaces syslog, has been created and driven by the enterprise linux distro, with full-time experienced linux devs, and has been released and used in production for years... ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache.
    - vidarh 10y ago
      That is "replaces" syslog (you can still have it forward to syslog if you insist) is one of the best parts. After getting used to journald I have no desire to ever go back to dealing with syslog. > ... and still doesn't have functional centralised logging ability. People have to use dirty hacks to make it work. This is my current headache. What are those "dirty hacks"? You can trivially use logstash or similar or you can forward log entries to a remote syslog-compatible endpoint. Incidentally the same that people usually do with syslog.
- striking 10y ago
  I cannot even begin to describe how silly your comment is. Since when were politicians even comparable to programs? Do we "elect" a init system, as one nation united under Torvalds? I'm hoping I was just trolled by an HN-flavored Markov Chain.
morganvachon 10y ago
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.
- billforsternz 10y ago
  I am puzzled that you had an Atom based netbook from around 2010 that shipped with any kind of Windows 10.
Annatar 10y ago
Because it's a Windows monolithic approach to startup, shutdown and dependency management, as well as being a poor copy of Solaris' service management facility, smf(5).

JdeBP 10y ago

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

striking 10y ago
> The actual installation steps of the doco are "TODO". Building a kernel and such can be done like this: http://sta.li/build http://sta.li/build I assume that's how that part of installation works. They could have documented that more nicely, though... (Also, I use dwm. It works out of the box, using it on a stock Arch system is as simple as compiling, installing, and adding it to .xinitrc. And configuration has been made extremely simple also. It's not obvious at all, but it works for the particular niche I fit into.)
startling 10y ago
> Installation uses HTTP to fetch a boot volume image. This is a problem with all of the suckless software and it, well, sucks.

saynsedit 10y ago

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

lifthrasiir 10y ago
I don't doubt that this won't fly in the traditional sense, but at the very least NIH is also a wheel for diversity. It is clearly interesting to see what can be done there.
icebraining 10y ago
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 10y ago
  Exactly my point. Philosophy has its place in software engineering but often it's not on a pedestal.
  - icebraining 10y ago
    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 10y ago
      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.

yellowapple 10y ago

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.

plexu 10y ago

Um... Sounds too much like Stalin?

viraptor 10y ago

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.

codemac 10y ago
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59159 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59159 is an older reference, and that's 16 years ago..
icebraining 10y ago
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
Arnt 10y ago
IIRC that worked in the summer of 1992, and was blocked sometime that year or the next.

micro_softy 10y ago

Any plans to include i386?

qume 10y ago

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 10y ago
Static linking is a virtue now? I don't understand the advantages.
- qznc 10y ago
  Google Go and Rust promote it. However, deploying web services is different than Linux distro.
  - rkangel 10y ago
    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 10y ago
      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 10y ago
        > 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

paulddraper 10y ago

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.

giovannibajo1 10y ago
You'd run "pkg-manager upgrade", just like you do with dynamic linking.
- jtietema 10y ago
  Yep but now instead of fetching 1 updated library, you depend on everybody and their cat to rebuild their binaries and publish updated versions.
  - smegel 10y ago
    You would thing a distro like this would be more like gentoo...you recompile stuff as needed (which for openssl means almost everything).
    - cheiVia0 10y ago
      Gentoo is dynamically linked, so you only recompile if there's an ABI break - a major version - not a patch/minor release. And, you only recompile the stuff that directly links to it. With static linking, you literally need to recompile everything that uses the library in any form, for every single change. So of there's a security fix in openssl and LibreOffice uses openssl, you need to recompile LibreOffice. If QEMU uses libssh2 which uses openssl, you need to recompile QEMU, even though it doesn't use openssl directly. With Gentoo you just recompile openssl and that's it. And if there a fix to glibc, you need to recompile EVERYTHING because everything would be statically linked to it.
      - ngrilly 10y ago
        You don't have to recompile everything. If your system keeps a cache of object files, you only have to relink everything, which is quicker.

mkj 10y ago

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.

tedunangst 10y ago
-fPIE? Works on OpenBSD.
viraptor 10y ago
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 10y ago
  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 10y ago
    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 10y ago

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

h4nkoslo 10y ago
The name is taken. https://github.com/barak/stalin https://github.com/barak/stalin
parski 10y ago
Word.

martinsb 10y ago

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.

txdv 10y ago
His site is calles suck less so i guess it is his moto
lsh 10y ago
lighten up and pull that stick out
Annatar 10y ago
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 10y ago
  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.

scott_karana 10y ago

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?

marmaduke 10y ago
If you took the "one tool one purpose" thing to an extreme, you'd only have one binary with OpenSSL compiled in, right? Given some familiarity with the suckless ideology, it seems that it is the simplicity of static linking, not conservative use of disk space, which is its virtue. For, if anyone groks the tool chain perfectly but lacks disk space, I'd like to hear the secret.
- Retr0spectrum 10y ago
  > you'd only have one binary with OpenSSL compiled in So then any process that wanted to use crypto etc. would have to call this binary? That just seems like a very inefficient way if implementing dymanic linking...
  - JdeBP 10y ago
    You have the wrong metric. The metric should be the efficiency of the mechanism in implementing SSL. Now look at things like Gerrit Pape's sslio , http://smarden.org/ipsvd/sslio.8.html http://smarden.org/ipsvd/sslio.8.html . Note that the subject at hand purportedly uses several of Gerrit Pape's other tools.
qznc 10y ago
Many applications only use parts of libraries, then the linker can throw the unnecessary parts away.
- infinity0 10y ago
  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*

pjmlp 10y ago

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

INTPenis 10y ago
One of the first things I read was support for arm and RPi so I assume it's targeting the IoT.
- Narishma 10y ago
  RPi is used for a lot more than IoT.

faragon 10y ago

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 10y ago
Too bad it prodyces buggier, suckier code.

mseidl 10y ago

This project has been around for a while.

Annatar 10y ago

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 10y ago
Windows? Have you ever heard of DLLs?
- yrro 10y ago
  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 10y ago
    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/

lutusp 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
    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.

gdamjan1 10y ago

"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 10y ago
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 10y ago
  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/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...). 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 10y ago
    If you want all in one file system, make symlinks. Problem solved.
- Touche 10y ago
  If I have to set up a bunch of symlinks to get basic packages to work my distro has failed me.

tibbarrabbit 10y ago

This is hilarious

sctb 10y ago
Please make sure to comment civilly and substantively on Hacker News. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

praptak 10y ago

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.

sdegutis 10y ago

> "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 10y ago
Wow that was really disheartening to read. Definitely didn't expect that level of childishness.

fhemn3 10y ago

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_learnings_and_beehive_observation.webm http://dl.sta.li/slcon/2016/slcon-2016-12-agarbe-stali_learn...