sites

public wiki contents of suckless.org
git clone git://git.suckless.org/sites
Log | Files | Refs

commit 21c30612eff6e4824588ce75cca95e973d405241
parent c7db79f08ec6d6d0b2747ba988285367b7e887e5
Author: Anselm R Garbe <anselm@garbe.us>
Date:   Mon, 31 Aug 2015 22:15:13 +0200

added note about where sta.li sites now reside

Diffstat:
Asta.li/README | 1+
Dsta.li/_werc/config | 3---
Dsta.li/faq.md | 146-------------------------------------------------------------------------------
Dsta.li/filesystem.md | 29-----------------------------
Dsta.li/index.md | 36------------------------------------
Dsta.li/masterplan.md | 58----------------------------------------------------------
Dsta.li/sandbox.md | 42------------------------------------------
Dsta.li/stali.png | 0
Dsta.li/technologies.md | 34----------------------------------
9 files changed, 1 insertion(+), 348 deletions(-)

diff --git a/sta.li/README b/sta.li/README @@ -0,0 +1 @@ +Moved to [git.sta.li/sites](http://git.sta.li/sites) diff --git a/sta.li/_werc/config b/sta.li/_werc/config @@ -1,3 +0,0 @@ -siteTitle='sta.li' -siteSubtitle='stali - static linux' -menuTitle='about' diff --git a/sta.li/faq.md b/sta.li/faq.md @@ -1,146 +0,0 @@ -FAQ -=== - -Aren't statically linked executables huge? -------------------------------------------- -It depends. Linking a stripped hello world program with glibc results in 600kb. -Linking it with uclibc in about 7kb. Linking OpenBSD's stripped [ksh](git://github.com/dryfish/openbsd-pdksh.git), which -will be stali's default shell, statically against uclibc results in a 170kb -binary -- linking it dynamically against glibc results in 234kb. -Of course this won't scale with every binary, for example we expect surf -being about 5-6MB in size, but the normal Unix userland will be rather small, -compared to most popular linux distros. - -See also - -* <http://9fans.net/archive/2008/11/142> - -Aren't whole libraries linked into a static executable? -------------------------------------------------------- -No. Good libraries implement each library function in separate object (.o) -files, this enables the linker (ld) to only extract and link those -object files from an archive (.a) that export the symbols that are -actually used by a program. Additionally, link-time optimization and -dead code elimination (available in most modern GNU and LLVM based toolchains) -allows for the extraction of necessary code on a _function-by-function_ basis, -while eliminating _all_ unused library code, resulting in a smaller, faster, -and more secure executables. - -See also - -* <http://9fans.net/archive/2002/02/21> - -What's wrong with glibc? ------------------------- -We think nearly everything is wrong with it. Its enormous complexity, -its lack of good structure and well separated object files -(otherwise linking trivial programs wouldn't result in 600kb overhead) and -even worse than that, its design decision to use dlopen for certain -"separated" library features (NSS, locales, IDN, ...), which makes it nearly -impossible to use glibc for static linking in non-trivial programs. -Unfortunately, for certain tools we will ship glibc for pragmatic reasons. - -Of course [Ulrich Drepper thinks that dynamic linking is -great](http://people.redhat.com/drepper/no_static_linking.html), but clearly -that's because of his lack of experience and his delusions of grandeur. - - -Aren't statically linked executables less secure? ----------------------------------------------- -Several people argue (with implicitly requiring ABI-stability) that dynamically -linked executables benefit from security fixes in libraries they depend on. -While this is true to some extent, statically linked executables aren't -en-masse affected by vulnerabilities in the dynamic libraries installed on your -system in the first place. - -We know that there is some overhead in re-compiling all affected executables if -a dependent library is insecure, but we don't see this as a critical -disadvantage, because we also focus on a small and maintainable userland, where -only one tool for each task exists. - -Another argument often heard is that static functions have predictable -addresses, whereas dynamic linking provides the ability of address -randomization. We have two answers to this. The first is: 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](https://en.wikipedia.org/wiki/Position-independent_code) -are easily created on all modern operating systems. The second is: In reality, -address randomization is predictable and we usually see the same addresses when -a dynamic library is loaded or has been pre-loaded again and again. Thus we -consider this as an issue with low impact and this is not a real focus for us. - -If you are really concerned about the security of statically linked executables, -have a look at what [great ldd exploits](http://www.catonmat.net/blog/ldd-arbitrary-code-execution/) exist. - -Another security issue with dynamic linking is versioning, see [this -excerpt](http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols) -for some insight. - -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. - -Apart from that we link against libraries with low footprint (eg uclibc instead -of glibc when possible). This leads to an increased likelihood -of lesser vulnerabilities, simply because lesser code contains fewer bugs from -a statistical point of view. - -See also: -* [On the Effectiveness of Address-Space Randomization](http://benpfaff.org/papers/asrandom.pdf) - -Aren't statically linked executables consuming more memory? --------------------------------------------------------- -We believe that due to the small size of the base system the opposite will be -the case. First of all, the kernel will load each static executable's .rodata, .data, -.text and .comment sections only once for all instances into memory. -Second, because each static binary has only been linked with the object files -necessary, it has already been optimized at linkage time for memory -consumption. When loading it, we don't require the kernel to map all -dependent dynamic libraries into memory from which our binary might only use 5% -of the functions they provide. So, in reality, the memory footprint is becoming -less, and the dead code hold in memory (or paged) reduces overall consumption. -This is also true for programs, like surf, which don't use all webkit/gtk/glib -functions. - -Isn't starting statically linked executables slower? ----------------------------------------------------- -In nearly all cases the answer is "No". In the theoretical case of a huge static -executable, the payload might be loading the executable into memory; but we -focus on small, static executables. In experiments, the execution time of a static -executable was about 4000% faster than its dynamically linked counterpart -when no dependent libraries (except glibc) were pre-loaded, and 100% faster when -the dependent libraries were pre-loaded. We believe the overhead for looking up -all needed symbols in the dynamically loaded libraries seems to be very -expensive. On modern hardware this is only noticeable with endlessly executing -the static and dynamic executable in a loop for several minutes and counting -the number of executions. - -A general conclusion is, the more dynamic libraries an executable depends on, -the slower it'll start, regardless if the libraries are preloaded or not. -This also means that usually big static executables (which we try to avoid) -easily outperform dynamic executables with lots of dependencies. If a big -static executable is already running, executing another one is nearly -instantaneously, because the payload is already in the memory. In the dynamic -case the startup is not instantaneously because the dynamic linker has to make -sure that there were no updates in the dependencies. - -So all in all dynamic executables are painfully slow, regardless of what -inelegant hacks people came up with in the past. There is zero evidence that -dynamic linking makes executables faster. There is only some evidence that -preloading dynamic libraries vs not preloading dynamic libraries improves the -startup of dynamic executables. But the introduction of preloading comes at a -cost as well, the kernel will have to do much more work when supporting such -contrivances. - -Dynamic linking also greatly increases the complexity of the kernel VM and -makes it much slower. And kludgy solutions to this make things more -complicated and add many more points of total failure. - -See also --------- -* [A Web OS? Are You Dense?](http://web.archive.org/web/20120509105723/http://teddziuba.com/2008/09/a-web-os-are-you-dense.html) -* [Breaking the links: Exploiting the linker](http://www.nth-dimension.org.uk/pub/BTL.pdf) -* [On the Effectiveness of Address-Space Randomization](http://benpfaff.org/papers/asrandom.pdf) - diff --git a/sta.li/filesystem.md b/sta.li/filesystem.md @@ -1,29 +0,0 @@ -Filesystem -========== - -This is a editable proposal for a filesystem layout that -will fit the changed principles of the OS. - - /bin - all executables - /boot - all boot files - /dev - devices - /etc - system configuration - /home - user directories - /root - the root home - /var - spool, run, log, cache - /share - man pages, locales, dependencies - /devel - development environment - /devel/include - /devel/lib - /devel/src - -Based on the Linux assumption: - - /sys - sys files - /proc - proc files - -For old style emulation: - - /emul - chroot for packages that are too infected - - diff --git a/sta.li/index.md b/sta.li/index.md @@ -1,36 +0,0 @@ -![stali](/stali.png) - -static linux is based on a hand selected collection of the best tools for each -task and each tool being statically linked (including some X clients such as -st, surf, dwm, dmenu), - -It also targets binary size reduction through the avoidance of glibc and other -bloated GNU libraries where possible (early experiments show that statically -linked binaries are usually smaller than their dynamically linked glibc -counterparts!!!). Note, this is pretty much contrary to what Ulrich Drepper -reckons about static linking. - -Due to the side-benefit that statically linked binaries start faster, the -distribution also targets performance gains. - -Contributing ------------- - -Sta.li is still in a design phase. You can contribute by adding ideas -to the [sandbox](http://sta.li/sandbox) or by working on -[the masterplan](http://sta.li/masterplan). - -Join the [suckless community](http://suckless.org/community) to -discuss further development of sta.li. - -Some related links ------------------- -* [morpheus](http://morpheus.2f30.org/) - a statically linked musl based distro -* [starch linux](http://starchlinux.org/) - a statically linked archlinux variant -* [Bifrost/Linux](http://bifrost.slu.se/) - a minimalist Linux distro for USB media -* [$6M libc](http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html) - Bionic is a nice library, though only usable for sane stuff -* [ldd arbitrary code execution](http://www.catonmat.net/blog/ldd-arbitrary-code-execution/) - Nice exploit -* [static linking](http://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/) - My old blog entry -* [blog post about stali](http://wayback.archive.org/web/20110727064007/http://elevenislouder.blogspot.com/2010/02/stali.html) -* [On the Effectiveness of Address-Space Randomization](http://benpfaff.org/papers/asrandom.pdf) -* [musl libc](http://www.musl-libc.org/) diff --git a/sta.li/masterplan.md b/sta.li/masterplan.md @@ -1,58 +0,0 @@ -04.04.2012 - -The Masterplan -============== - -Building a different OS with a complete different mindset from -what is mainly used is difficult and time-consuming. To keep -the ideals of suckless in its design and principles there needs -to be a certain guideline how to accomplish sta.li. - -Steps ------ - -* Get a static base environment working -* Allow the emulation of the old dynamically-linked environment -* Make the installation user-friendly -* Maintain the community - -1.) Get a static base environment working ------------------------------------------ - -Steps in this direction have been done in the -[sabotage](https://github.com/rofl0r/sabotage), -[bootstrap](https://github.com/pikhq/bootstrap-linux) and -[morpheus](http://morpheus.2f30.org) -Linux distributions. They should serve as a base for further -a further extension to make a base environment which can be -used by the average suckless user. - -2.) Allow the emulation of the old behaviour --------------------------------------------- - -In this step some easy way to emulate the old dynamic linking, -which will allow to use pre-existing packages for other -distributions, is needed to be implemented. - -A proposal for the emulation directory is '/emul'. All applications -running below this directory will be run in a chroot under this -path. - -Linux is still struggling with Windows compatibility, which brought -really obscure design decisions to the Open Source environment. It -will take a long time to convert active developers to our principles. - -3.) Make the installation user-friendly ---------------------------------------- - -For this step the Arch Linux way of text installation could be -simply copied. The GUI way of Ubuntu will stop people from -thinking. - -4.) Maintain the community --------------------------- - -Maintaining an Open Source community isn't just maintaining the -status quo. It needs templates and tutorials on how to spread -the suckless ways of thinking and being productive. The web is -not a part of this. diff --git a/sta.li/sandbox.md b/sta.li/sandbox.md @@ -1,42 +0,0 @@ -Sandbox -======= - -Ideas that could be worthwhile for the development of sta.li -will be collected here. Just add them using the known ways -of suckless wiki editing. - -Principles ----------- - -* follow the UNIX philosophy -* each executable is statically linked - -Ideas ------ - -* maybe a different format to ELF -* kernel is a monolithic Linux kernel - * still make less used modules loadable (all kind of USB) -* system loader is linux loader -* no initrd -* make the whole system a ramdisk -* a basic initsystem -* updating is rsyncing the build files and rebuilding what is needed -* all applications need dbus to be removed - -Quick Ideas ------------ - -* use nldev + mdev/smdev for device management - * add a »dev« command for controlling mdev/smdev - * make some minor/major/netlink extractor to a script -* use busybox as first userland, then gradually move to sbase + ubase -* use svc for services -* first use X11 for graphics until Wayland is getting sane - * if kernel graphics is getting faster use a framebuffer - -Needed application replacements -------------------------------- - -* new bluetooth stack without dbus -* simple mDNS without dbus diff --git a/sta.li/stali.png b/sta.li/stali.png Binary files differ. diff --git a/sta.li/technologies.md b/sta.li/technologies.md @@ -1,34 +0,0 @@ -Software / Techologies sta.li could use -======================================= - -This list is a proposal of software, which sta.li should include. The rules -are: Be as simple as possible and as useful as possible. - -* base system - * [sbase](http://git.suckless.org/sbase/) - * [ubase](http://git.suckless.org/ubase/) -* init - * [sinit](http://git.suckless.org/sinit/) - * [cinit](http://www.nico.schottelius.org/software/cinit/) -* services - * [runit](http://smarden.org/runit/) - * [svc](http://git.r-36.net/svc/) -* logging - * [socklog](http://smarden.org/socklog/) -* documents - * [ted](http://www.nllgg.nl/ted/) -* udev - * [mdev](http://lists.busybox.net/pipermail/busybox/2005-December/017183.html) - * [nldev](http://git.r-36.net/nldev/) - * [smdev](http://git.2f30.org/smdev/) -* wm - * [dwm](http://dwm.suckless.org) - * [nowm](https://github.com/patrickhaller/no-wm) -* dyndns - * [tinydyndns](http://smarden.org/tinydyndns/) -* dhcp - * [sdhcp](http://galos.no-ip.org/sdhcp) -* shell - * [rc](http://plan9.bell-labs.com/sys/doc/rc.html) - * [loksh](https://github.com/dimkr/loksh) - * [mksh](https://www.mirbsd.org/mksh.htm)