[wiki] [sites] removed sta.li -- will be hosted elsewhere || Anselm R Garbe

From: <git_AT_suckless.org>
Date: Wed, 31 Jan 2018 21:38:59 +0100

commit 98fe6910f17fcd371bc22eaeb365a1bb8dbe942e
Author: Anselm R Garbe <anselm_AT_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
_AT_@ -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
_AT_@ -1,3 +0,0 @@
-siteSubtitle='stali - static linux'
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
_AT_@ -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
_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 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
-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 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
-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 4479a043..00000000
--- a/sta.li/filesystem.md
+++ /dev/null
_AT_@ -1,26 +0,0 @@
- / - 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
_AT_@ -1,49 +0,0 @@
-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
-Check out all repositories at [git.sta.li](http://git.sta.li).
-* 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.
-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
_AT_@ -1,42 +0,0 @@
-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.
-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
_AT_@ -1,6 +0,0 @@
-<?xml version="1.0" ?>
-<!-- Copyright (c) 2016, Laslo Hunhold <dev_AT_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 " />
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
_AT_@ -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
_AT_@ -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
-Alternatively you can also downgrade or checkout a specific release:
-	# cd /
-	# git checkout 0.1
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
_AT_@ -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
-	git clone http://git.sta.li/sites
-To push your changes to the queue for the review by the suckless moderators,
-	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.
-* 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.
-The incoming changes to the wiki are all sent to the wiki_AT_
-mailinglist. See [community](//suckless.org/community) for how to
-subscribe to this list.
-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.
-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
_AT_@ -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**.
-[stali ISO](http://dl.sta.li/stali.iso) pre-release. See [stali](http://sta.li) for more details.
 [surf 0.7](//surf.suckless.org) released: [download](//dl.suckless.org/surf/surf-0.7.tar.gz)
_AT_@ -183,7 +179,7 @@ We applied as a mentoring organisation for GSoC 2010. See our [project ideas for
-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.
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
_AT_@ -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
Received on Wed Jan 31 2018 - 21:38:59 CET

This archive was generated by hypermail 2.3.0 : Wed Jan 31 2018 - 21:48:23 CET