[wiki] [sites] added note about where sta.li sites now reside || Anselm R Garbe

From: <git_AT_suckless.org>
Date: Mon, 31 Aug 2015 22:15:36 +0200

commit 21c30612eff6e4824588ce75cca95e973d405241
Author: Anselm R Garbe <anselm_AT_garbe.us>
Date: Mon Aug 31 22:15:13 2015 +0200

    added note about where sta.li sites now reside

diff --git a/sta.li/README b/sta.li/README
new file mode 100644
index 0000000..3059665
--- /dev/null
+++ b/sta.li/README
_AT_@ -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
deleted file mode 100644
index 1cb3240..0000000
--- a/sta.li/_werc/config
+++ /dev/null
_AT_@ -1,3 +0,0 @@
-siteSubtitle='stali - static linux'
diff --git a/sta.li/faq.md b/sta.li/faq.md
deleted file mode 100644
index 179dfe8..0000000
--- a/sta.li/faq.md
+++ /dev/null
_AT_@ -1,146 +0,0 @@
-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
-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
-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
-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
-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
deleted file mode 100644
index bdd8233..0000000
--- a/sta.li/filesystem.md
+++ /dev/null
_AT_@ -1,29 +0,0 @@
-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
deleted file mode 100644
index 2ad57e0..0000000
--- a/sta.li/index.md
+++ /dev/null
_AT_@ -1,36 +0,0 @@
-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.
-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
deleted file mode 100644
index b04241e..0000000
--- a/sta.li/masterplan.md
+++ /dev/null
_AT_@ -1,58 +0,0 @@
-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.
-* 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
-[bootstrap](https://github.com/pikhq/bootstrap-linux) and
-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
-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
-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
deleted file mode 100644
index 79e69b6..0000000
--- a/sta.li/sandbox.md
+++ /dev/null
_AT_@ -1,42 +0,0 @@
-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.
-* follow the UNIX philosophy
-* each executable is statically linked
-* 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
deleted file mode 100644
index 57bb8c7..0000000
Binary files a/sta.li/stali.png and /dev/null differ
diff --git a/sta.li/technologies.md b/sta.li/technologies.md
deleted file mode 100644
index 1844c9b..0000000
--- a/sta.li/technologies.md
+++ /dev/null
_AT_@ -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)
Received on Mon Aug 31 2015 - 22:15:36 CEST

This archive was generated by hypermail 2.3.0 : Mon Aug 31 2015 - 22:24:11 CEST