commit 98fe6910f17fcd371bc22eaeb365a1bb8dbe942e
Author: Anselm R Garbe <ans...@garbe.us>
Date: Wed Jan 31 21:38:26 2018 +0100
removed sta.li -- will be hosted elsewhere
diff --git a/sta.li/README b/sta.li/README
deleted file mode 100644
index 30596655..00000000
--- a/sta.li/README
+++ /dev/null
@@ -1 +0,0 @@
-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 824eea35..00000000
--- a/sta.li/_werc/config
+++ /dev/null
@@ -1,3 +0,0 @@
-siteTitle='suckless.org'
-siteSubtitle='stali - static linux'
-menuTitle='about'
diff --git a/sta.li/build.md b/sta.li/build.md
deleted file mode 100644
index 32d117a1..00000000
--- a/sta.li/build.md
+++ /dev/null
@@ -1,41 +0,0 @@
-Build stali from source
-=======================
-
-We require a recent x86\_64 based linux system as build environment, on Debian
we require
-
- ; sudo apt-get install build-essential
-
-(on other distros you will need at least gmake)
-
-Create a build directory
-
- ; mkdir stalibuild-root
- ; cd stalibuild-root
-
-Retrieve the stali toolchain
-
- ; git clone http://git.sta.li/toolchain
-
-Retrieve the stali src
-
- ; git clone http://git.sta.li/src
-
-Retrieve the kernel source
-
- ; cd src
- ; git clone http://git.sta.li/sys.x86_64 # for x86_64 platform
- ; git clone http://git.sta.li/sys.pi # for Raspberry Pi platform
-
-Build stali
-
- ; export STALISRC=/path/to/stalibuild-root/src
- ; cd src
- ; vi config.mk # fit your needs, esp. DESTDIR and TARGETS
- ; make
-
-Install stali in DESTDIR
-
- ; make install
-
-You have now built stali from source.
-
diff --git a/sta.li/faq.md b/sta.li/faq.md
deleted file mode 100644
index a39754cd..00000000
--- a/sta.li/faq.md
+++ /dev/null
@@ -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 musl in about 7kb. Linking OpenBSD's stripped
[ksh](https://github.com/bobertlo/openbsd-pdksh), which
-will be stali's default shell, statically against musl 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 musl 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
deleted file mode 100644
index 4479a043..00000000
--- a/sta.li/filesystem.md
+++ /dev/null
@@ -1,26 +0,0 @@
-Filesystem
-==========
-
- / - the root home
- /bin - all executables
- /sbin -> /bin # softlink pointing to /bin
- /boot - all boot files
- /etc - system configuration
- /home - user directories
- /var - spool, run, log, cache
- /share - man pages, locales, dependencies
- /include - include/headers
- /lib - static libraries for building stuff
- /mnt - mount points
- /usr -> / # softlink pointing to /
-
-Based on the Linux assumption:
-
- /dev - devices
- /proc - proc files
- /sys - sys files
-
-For crap stuff:
-
- /sucks - stuff that sucks, like ugly gnu library dependencies, or
systemd fake handlers
-
diff --git a/sta.li/index.md b/sta.li/index.md
deleted file mode 100644
index 66be8f70..00000000
--- a/sta.li/index.md
+++ /dev/null
@@ -1,49 +0,0 @@
-
-
-About
-=====
-stali is a brand new **sta**tic **li**nux distribution based on the original
pre-2010
-plans of the [suckless.org](//suckless.org) project, but with a couple of
revised goals:
-
-stali goals
------------
-* Follow the suckless [philosophy](//suckless.org/philosophy)
-* Target x86\_64 and arm (RPi) support
-* Use custom stali.mk Makefile's for the base system (except Linux kernel so
far)
-* Ignore FHS of Linux, it simply sucks. Use a decent [filesystem](/filesystem)
structure instead
-* Don't use systemd (read
[more](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/) about why it
[sucks](//suckless.org/sucks/systemd))
-* Make everything [musl libc](http://www.musl-libc.org/) based
-* Achieve binary size reduction (through the avoidance of glibc and other
bloated GNU libraries)
-* Achieve better performance than any other x86\_64 or arm distribution, as
only statically linked binaries are used
-* Achieve better memory footprint than heavyweight distros using dynamic
linking and all its problems
-* Achieve better ABI stability and long-term maintenability of the static
binaries (compared to their dynamic counterparts)
-* Minimize security threat vector - potential flaws only on a per static
binary basis (say good bye to the famous LD\_PRELOAD and .so dependency
resolver problems)
-* Include a hand selected collection of the best tools for each task
(including [sbase](//core.suckless.org/sbase), [ubase](//core.suckless.org),
...)
-* Upgrade/install using git, no package manager needed
-
-Source
-------
-Check out all repositories at [git.sta.li](http://git.sta.li).
-
-Download
---------
-* 20160825 stali for RPi [stapi.img.gz](http://dl.sta.li/stapi.img.gz)
available for download.
-* 20160402 second [stali.iso](http://dl.sta.li/stali.iso) available for
download.
-
-Contributing
-------------
-Join the [suckless community](//suckless.org/community) to
-discuss further development of stali.
-
-Some related links
-------------------
-* 20160407 [InfoWorld
article](http://www.infoworld.com/article/3048737/open-source-tools/stali-distribution-smashes-assumptions-about-linux.html)
on "Stali distribution smashes assumptions about Linux"
-* [musl libc](http://www.musl-libc.org/)
-* [morpheus](http://morpheus.2f30.org/) - a statically linked musl based distro
-* [oasis](https://github.com/michaelforney/oasis) - a statically linked
musl/suckless/OpenBSD/plan9port based distro
-* [bare](http://bare.li/) - a bare linux distro
-* [Bifrost/Linux](http://bifrost.slu.se/) - a minimalist Linux distro for USB
media
-* [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)
diff --git a/sta.li/installation.md b/sta.li/installation.md
deleted file mode 100644
index 117a7092..00000000
--- a/sta.li/installation.md
+++ /dev/null
@@ -1,42 +0,0 @@
-Installation
-============
-
-Raspberry Pi 2+
----------------
-Download the [stapi.img.gz](http://dl.sta.li/stapi.img.gz) and flash your sd
-card for the Pi 2+. It should boot out of the box.
-
-PC
---
-
-Prepare a disk partition for stali, we recommend formatting it with ext4fs
-
-Mount the disk partition
-
- ; sudo su
- # mkdir /mnt/rootfs-x86_64
- # mount /dev/sdX /mnt/rootfs-x86_64
-
-Clone rootfs-x86\_64
-
- # cd /mnt
- # git clone http://git.sta.li/rootfs-x86_64
-
-Setup the system
-
- # cd /mnt/rootfs-x86_64/etc
- # # adjust rc.init/exit, etc.
-
-Prepare chroot
-
- # mount -t proc proc /mnt/rootfs-x86_64/proc
- # mount --rbind /sys /mnt/rootfs-x86_64/sys
- # mount --rbind /dev /mnt/rootfs-x86_64/dev
-
-chroot into stali
-
- # chroot /mnt/rootfs-x86_64 /bin/sh
- # # build a custom kernel, setup system/bootloader etc # TODO
-
-Finish the installation and boot into stali.
-
diff --git a/sta.li/logo.svg b/sta.li/logo.svg
deleted file mode 100644
index 11582c71..00000000
--- a/sta.li/logo.svg
+++ /dev/null
@@ -1,6 +0,0 @@
-<?xml version="1.0" ?>
-<!-- Copyright (c) 2016, Laslo Hunhold <d...@frign.de> -->
-<svg xmlns="http://www.w3.org/2000/svg"; width="101" height="15" version="1.1">
-<path style="fill:#222222" d="M 73 0 L 73 15 L 76.5 15 L 76.5 15 L 95.5 15 L
95.5 11.25 L 76.5 11.25 L 76.5 0 L 73 0 z M 97.5 0 C 97.5 0 97.5 0 97.5 0 L
97.5 15 C 97.5 15 97.5 15 97.5 15 L 101 15 C 101 15 101 15 101 15 L 101 0 C 101
0 101 0 101 0 L 97.5 0 z " />
-<path style="fill:#1177aa" d="M 0 0 L 0 9.375 L 18.75 9.375 L 18.75 11.25 L 0
11.25 L 0 15 L 22.5 15 L 22.5 5.625 L 3.75 5.625 L 3.75 3.75 L 22.5 3.75 L 22.5
0 L 0 0 z M 24.375 0 L 24.375 3.75 L 33 3.75 L 33 15 L 36.875 15 L 36.875 3.8 L
46.875 3.75 L 46.875 0 L 24.375 0 z M 48.75 0 L 48.75 15 L 52.5 15 L 52.5 9.375
L 67.5 9.375 L 67.5 15 L 71 15 C 71 10 71 0 71 0 L 48.75 0 z M 52.5 3.75 L 67.5
3.75 L 67.5 5.625 L 52.5 5.625 L 52.5 3.75 z " />
-</svg>
diff --git a/sta.li/technologies.md b/sta.li/technologies.md
deleted file mode 100644
index a268b395..00000000
--- a/sta.li/technologies.md
+++ /dev/null
@@ -1,29 +0,0 @@
-Software that stali might adopt
-===============================
-
-* base system
- * [sbase](//git.suckless.org/sbase/)
- * [ubase](//git.suckless.org/ubase/)
-* init
- * [sinit](//git.suckless.org/sinit/)
-* 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](//dwm.suckless.org)
- * [nowm](https://github.com/patrickhaller/no-wm)
-* dyndns
- * [tinydyndns](http://smarden.org/tinydyndns/)
-* dhcp
- * [sdhcp](https://core.suckless.org/sdhcp)
-* shell
- * [loksh](https://github.com/dimkr/loksh)
- * [mksh](https://www.mirbsd.org/mksh.htm)
diff --git a/sta.li/upgrade.md b/sta.li/upgrade.md
deleted file mode 100644
index 64ae420d..00000000
--- a/sta.li/upgrade.md
+++ /dev/null
@@ -1,18 +0,0 @@
-Keep up-to-date with upstream stali
-===================================
-
-Precondition: You have successfully installed stali.
-
-Keep up-to-date as follows:
-
- # cd /
- # git pull
-
-Done.
-
-Alternatively you can also downgrade or checkout a specific release:
-
- # cd /
- # git checkout 0.1
-
-Done.
diff --git a/sta.li/wiki.md b/sta.li/wiki.md
deleted file mode 100644
index 8aa1978f..00000000
--- a/sta.li/wiki.md
+++ /dev/null
@@ -1,71 +0,0 @@
-This wiki
-=========
-If you would like to contribute new content, you can clone this wiki to your
-local host using the following command:
-
- git clone git://git.sta.li/sites
-
-or
-
- git clone http://git.sta.li/sites
-
-To push your changes to the queue for the review by the suckless moderators,
-use:
-
- git push
-
-The review of your changes might take one day, due to the different timezones
-we all live in.
-
-Please make sure to pull for incoming changes before you push your changes, to
-minimize problems.
-
-The wiki repository above is world-writable.
-
-Rules
------
-* If any abuse happens, we will disable world-writable access. Keep this in
mind!
- We kindly ask you to not destroy the way we like to collaborate
- with the community.
-* Please do not add files bigger than *100kb*.
-* Please do not add any binary files except screenshots or images related to
our software.
- You are allowed to add your code patches to the wiki if you do not have an
- external web server to serve them to the community. The extension of patches
- should be `.diff`.
-* The extension of newly created Markdown files has to be `.md`.
-* Please do not add HTML files or inline JavaScript.
-
-Changes
--------
-The incoming changes to the wiki are all sent to the wiki@
-mailinglist. See [community](//suckless.org/community) for how to
-subscribe to this list.
-
-Moderators
-----------
-If you are a moderator, you will likely need the following procedure to pull
-the changes into the main repository:
-
- cd /var/www/sites
- sudo -u www-data git checkout .
- sudo -u www-data git pull
-
-These commands can be found at /usr/local/bin/updatewiki for your convenience.
-
-The checkout is needed to prevent local atime changes to stop the pull. Please
-keep on using www-data, so the webserver can access everything.
-
-For managing the patches (reject/modify etc.) of course the other git commands
-apply too.
-
-Repositories
-------------
-
-This is for moderators.
-
-There is a script in /usr/local/bin/newrepo with the usage
-
- newrepo $reponame
-
-It should be used to create new git repositories.
-
diff --git a/suckless.org/index.md b/suckless.org/index.md
index 237f97d4..1a37c5dc 100644
--- a/suckless.org/index.md
+++ b/suckless.org/index.md
@@ -65,10 +65,6 @@ Videos of the [slcon 2016 talks](conferences/2016) are now
available.
----------
[slcon3](conferences/2016) Preliminary schedule now published. If you want to
attend please register until: **2016-09-01**.
-2016-04-02
-----------
-[stali ISO](http://dl.sta.li/stali.iso) pre-release. See
[stali](http://sta.li) for more details.
-
2015-12-19
----------
[surf 0.7](//surf.suckless.org) released:
[download](//dl.suckless.org/surf/surf-0.7.tar.gz)
@@ -183,7 +179,7 @@ We applied as a mentoring organisation for GSoC 2010. See
our [project ideas for
2010-02-13
----------
-Some of us will visit [CLT2010](http://chemnitzer.linux-tage.de/2010/). Anselm
will give a
[talk](http://chemnitzer.linux-tage.de/2010/vortraege/detail.html?idx=308)
about [stali](http://sta.li) on the second day of CLT2010 at 17:00.
+Some of us will visit [CLT2010](http://chemnitzer.linux-tage.de/2010/). Anselm
will give a
[talk](http://chemnitzer.linux-tage.de/2010/vortraege/detail.html?idx=308)
about stali on the second day of CLT2010 at 17:00.
2009-12-28
----------
diff --git a/suckless.org/project_ideas.md b/suckless.org/project_ideas.md
index ffa974a8..e3cec637 100644
--- a/suckless.org/project_ideas.md
+++ b/suckless.org/project_ideas.md
@@ -49,7 +49,7 @@ non-chroot'ed cross-compile environments and often completely
fail to produce
statically linked libraries or executables. Also they are
extremely slow and bloated.
-The [stali](http://sta.li/) build system is not using autotools for good
+The stali build system is not using autotools for good
reason, however many UNIX/Linux open source packages do. To create statically
linked libraries out of the ld arguments we need an ld wrapper or
re-implementation that creates static libraries or executables. This would
