commit a52c602300a78379968b2aefb2e4d8a345186c3c parent e5a9c45f2801b15b6ae603cfd7271720df8d7545 Author: Anselm R Garbe <anselm@suckless.org> Date: Sat, 1 Jul 2017 22:33:37 +0200 merge in ev and sta.li Diffstat:
| A | ev.suckless.org/_werc/config | | | 3 | +++ |
| A | ev.suckless.org/_werc/tpl/master.tpl | | | 45 | +++++++++++++++++++++++++++++++++++++++++++++ |
| A | ev.suckless.org/impressum.md | | | 17 | +++++++++++++++++ |
| A | ev.suckless.org/index.md | | | 50 | ++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | ev.suckless.org/satzung.md | | | 91 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | sta.li/_werc/config | | | 3 | +++ |
| A | sta.li/build.md | | | 41 | +++++++++++++++++++++++++++++++++++++++++ |
| A | sta.li/faq.md | | | 146 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | sta.li/filesystem.md | | | 26 | ++++++++++++++++++++++++++ |
| A | sta.li/index.md | | | 43 | +++++++++++++++++++++++++++++++++++++++++++ |
| A | sta.li/installation.md | | | 42 | ++++++++++++++++++++++++++++++++++++++++++ |
| A | sta.li/technologies.md | | | 29 | +++++++++++++++++++++++++++++ |
| A | sta.li/upgrade.md | | | 18 | ++++++++++++++++++ |
| A | sta.li/wiki.md | | | 71 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | suckless.org/logo.svg | | | 5 | +++++ |
| A | suckless.org/people/more_people.md | | | 74 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
16 files changed, 704 insertions(+), 0 deletions(-)
diff --git a/ev.suckless.org/_werc/config b/ev.suckless.org/_werc/config @@ -0,0 +1,3 @@ +siteTitle='suckless.org e.V.' +siteSubtitle='' +menuTitle='about' diff --git a/ev.suckless.org/_werc/tpl/master.tpl b/ev.suckless.org/_werc/tpl/master.tpl @@ -0,0 +1,45 @@ +<!doctype html> +<html> +<head> + <title>%($pageTitle%)</title> + <link rel="stylesheet" type="text/css" href="/pub/style.css"> + <meta charset="utf-8"> +</head> +<body> + <div id="header"> + <a href="/">%($"siteTitle%)</a> <span id="headerSubtitle">%($"siteSubtitle%)</span> + </div> + + <div id="menu"> + <span class="right"> + <a href="http://suckless.org">suckless.org</a> + </span> + </div> + <div id="content"> +% if(! ~ $#handlers_bar_left 0) { + <div id="nav"> +% for(h in $handlers_bar_left) { +% run_handler $$h +% } + </div> +% } + + <div id="main"> + +% run_handlers $handlers_body_head + +% run_handler $handler_body_main + +% run_handlers $handlers_body_foot + + </div> + + </div> + + <div id="footer"> + <span class="right"> + © 2015-2016 suckless.org e.V. | <a href="http://ev.suckless.org/impressum">Impressum</a> + </span> + </div> +</body> +</html> diff --git a/ev.suckless.org/impressum.md b/ev.suckless.org/impressum.md @@ -0,0 +1,17 @@ +Impressum +========= +Verantwortlich für diese Seiten gemäß §10 MDStV ist der suckless.org e.V. mit Sitz in Landshut, Deutschland. +Der suckless.org e.V. wurde im Vereinsregister vom Registergericht des Amtsgericht Landshut unter der VR-Nr. 200753 eingetragen. + +Anschrift +--------- +suckless.org e.V.<br/> +c/o Anselm Garbe<br/> +Veldener Str. 23<br/> +84036 Landshut<br/> +Germany<br/> + +E-Mail +------ +* Vorstand (Chairs): <chairs@suckless.org> + diff --git a/ev.suckless.org/index.md b/ev.suckless.org/index.md @@ -0,0 +1,50 @@ +suckless.org e.V. +================= +At [slcon 2](http://suckless.org/conference/2015) eight conference attendees +founded a legal entity for suckless.org, the "suckless.org e.V.". + +suckless.org e.V. is a registered association in Landshut, Germany, with its +own legal entity. Please refer to the [statutes](/satzung) for further info. +Please note that we are working on a translation into English. + +suckless.org e.V. organizes a yearly membership meeting, which will regularly +take place during the suckless conference. + +Board +----- +The board of suckless.org e.V. was elected at the foundation meeting on Oct 30 +2015 in Budapest. It consists of: + +* First chair: Anselm R Garbe +* Second chair: Laslo Hunhold + +Treasurer +--------- +The treasurer was elected at the foundation meeting on Oct 30 2015 in Budapest as well. Our treasurer is: + +* Jan Klemkow + +Membership +---------- +You can join suckless.org e.V. by sending us a written letter or an email indicating that you want to become a member. + +Please state your: + +* Real name +* Nickname +* Birthday +* Contact details + +We will get back to you asap. The current membership fee is 1 EUR per year. It will be collected in advance. + +Membership cancellation +----------------------- +You can cancel your membership of suckless.org e.V. by sending us a written +letter or email at any time. There is no refund of the membership fee, though. + +Donations +--------- +Our treasurer is currently working on setting up an infrastruture to collect +donations. As registered association we can issue invoices (under German law) +for your donation, that you can use in your (German) tax declaration. + diff --git a/ev.suckless.org/satzung.md b/ev.suckless.org/satzung.md @@ -0,0 +1,91 @@ +Satzung +======= + +§1 — Name und Sitz +------------------ +(1) Der Verein führt den Namen "suckless.org". Er soll in das Vereinsregister +eingetragen werden und danach den Namen "suckless.org e.V." führen. + +(2) Der Verein hat seinen Sitz in Landshut. + +§2 — Zweck +----------- +(1) Der Zweck des Vereins ist die Förderung von Freier Software. Freie Software im +Sinne dieser Satzung ist Software, die der Definition von Open-Source-Software +der "Open Source Initiative (OSI)" entspricht. Der Verein verfolgt keine +wirtschaftlichen Interessen. + +(2) Der Vereinszweck wird erzielt durch die eigene Entwicklung freier Software +und die Bereitstellung von Kommunikationsplattformen, sowie durch die +Ausrichtung von Vortrags-, Vorführungs- und Diskussionsveranstaltungen. Die +Ergebnisse der Vereinsarbeit stehen der Allgemeinheit offen. + +§3 — Mitgliedschaft +------------------- +Mitglieder des Vereins können alle volljährigen Personen werden, die einen +schriftlichen (auch per E-Mail) Aufnahmeantrag beim Vorstand des Vereins +gestellt haben. Lehnt der Vorstand die Aufnahme ab, kann der Beitrittswillige +die Mitgliederversammlung berufen. Diese entscheidet endgültig über die +Mitgliedschaft. + +§4 — Ende der Mitgliedschaft +---------------------------- +Die Mitgliedschaft endet durch Tod, Austrittserklärung oder Ausschluss. Der +Austritt erfolgt durch schriftliche (auch per E-Mail) Erklärung gegenüber dem +Vorstand. Über den Ausschluss beschließt die Mitgliederversammlung mit einer +Mehrheit von drei Vierteln der anwesenden Mitglieder. + +§5 — Mitgliedsbeiträge +---------------------- +Von den Mitgliedern werden Beiträge erhoben. Die Höhe des Jahresbeitrags wird +in der Mitgliederversammlung bestimmt. + +§6 — Organe des Vereins +----------------------- +Organe des Vereins sind Vorstand und Mitgliederversammlung. + +§7 — Vorstand +------------- +(1) Der Vorstand des Vereins besteht aus dem 1. Vorsitzenden, dem 2. Vorsitzenden +und dem Schatzmeister. Der Verein wird gerichtlich und außergerichtlich durch +den 1. und 2. Vorsitzenden je allein vertreten. + +§8 — Amtsdauer und Beschlussfassung des Vorstandes +-------------------------------------------------- +Der Vorstand wird von der Mitgliederversammlung auf die Dauer von zwei Jahren, +vom Tag der Wahl an gerechnet, gewählt. Der Vorstand bleibt jedoch auch +nach Ablauf seiner Amtszeit bis zur Neuwahl des neuen Vorstandes im Amt. +Der Vorstand fasst seine Beschlüsse in Vorstandssitzungen, die vom +1. Vorsitzenden oder 2. Vorsitzenden schriftlich, telefonisch oder per E-Mail +einberufen werden. + +§9 — Mitgliederversammlung +-------------------------- +Mindestens einmal im Jahr findet eine ordentliche Mitgliederversammlung statt. +Sie beschließt vor allem über die Beiträge, die Entlastung und die Wahl des +Vorstandes und über Satzungsänderungen. Eine außerordentliche +Mitgliederversammlung ist auf Verlangen eines Drittels der Mitglieder +einzuberufen. Die Einberufung zu Mitgliederversammlungen erfolgt durch den +Vorstand mit einer Frist von zwei Wochen schriftlich (auch per E-Mail) unter +Bekanntgabe der Tagesordnung. Die Tagesordnung kann durch Mehrheitsbeschluss in +der Mitgliederversammlung in der Sitzung ergänzt oder geändert werden; dies +gilt nicht für Satzungsänderungen. Die Mitgliederversammlung fasst ihre +Beschlüsse mit der Mehrheit der erschienenen Mitglieder. Stimmenthaltungen und +ungültige Stimmen bleiben außer Betracht. + +§10 — Beurkundung der Beschlüsse der Vereinsorgane +-------------------------------------------------- +Über die Beschlüsse des Vorstandes und der Mitgliederversammlung ist eine +Niederschrift aufzunehmen, die vom 1. Vorsitzenden oder dem 2. Vorsitzenden und +einem von der Versammlung gewählten Protokollführer zu unterzeichnen ist. + +§11 — Auflösung +--------------- +Die Auflösung kann nur in einer besonderen, zu diesem Zweck und mit einer Frist +von einem Monat einzuberufenden außerordentlichen Mitgliederversammlung mit +einer Mehrheit von drei Vierteln der erschienenen Mitglieder beschlossen +werden. Die Versammlung beschließt auch über die Art der Liquidation und die +Verwertung des verbleibenden Vermögens. + +Vorstehende Satzung wurde am 30. Oktober 2015 errichtet. +Sowie am 21. Dezember 2015 geändert. diff --git a/sta.li/_werc/config b/sta.li/_werc/config @@ -0,0 +1,3 @@ +siteTitle='stali' +siteSubtitle='' +menuTitle='about' diff --git a/sta.li/build.md b/sta.li/build.md @@ -0,0 +1,41 @@ +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 @@ -0,0 +1,146 @@ +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 @@ -0,0 +1,26 @@ +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 @@ -0,0 +1,43 @@ +About +===== +stali is a brand new **sta**tic **li**nux distribution based on the original pre-2010 +plans of the [suckless.org](http://suckless.org) project, but with a couple of revised goals: + +stali goals +----------- +* Follow the suckless [philosophy](http://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](http://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](http://core.suckless.org/sbase), [ubase](http://core.suckless.org), ...) +* Upgrade/install using git, no package manager needed + +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](http://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 @@ -0,0 +1,42 @@ +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/technologies.md b/sta.li/technologies.md @@ -0,0 +1,29 @@ +Software that stali might adopt +=============================== + +* base system + * [sbase](http://git.suckless.org/sbase/) + * [ubase](http://git.suckless.org/ubase/) +* init + * [sinit](http://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](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 + * [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 @@ -0,0 +1,18 @@ +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 @@ -0,0 +1,71 @@ +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](http://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/logo.svg b/suckless.org/logo.svg @@ -0,0 +1,5 @@ +<?xml version="1.0" ?> +<!-- Copyright (c) 2015, Laslo Hunhold <dev@frign.de> --> +<svg xmlns="http://www.w3.org/2000/svg" width="22.5" height="15" version="1.1"> +<path style="fill:#1177aa" d="m 0,15 22.5,0 0,-9.375 -18.75,0 0,-1.875 18.75,0 0,-3.75 -22.5,0 0,9.375 18.75,0 0,1.875 -18.75,0 z" /> +</svg> diff --git a/suckless.org/people/more_people.md b/suckless.org/people/more_people.md @@ -0,0 +1,74 @@ +More people +=========== + +The following people are/were involved mainly in wmii and dwm development as +developers and contributors. If you are missing, feel free to add yourself. + +* Alexandre DE DOMMELIN (contributed a theme and works on PHP based theme configurator) +* Andrew Milkovich (patches, updates) +* [Anthony Martin](http://pbrane.org) (ality) (developer, bug fixes, documentation) +* AntThyKem (contributed rpm package) +* Bernhard Leiner (wmipager improvements) +* Bob Crochelt (various feedback) +* Brian Dorsey (contributed various feedback) +* carmee (contributed various feedback) +* chem (bugs and various feedback) +* Christian Schneider (provides the Slackware package) +* Christof Musik (various feedback, small fixes) +* [Christoph Wegscheider](http://www.wegi.net) (python bindings of old libixp, former irc logging) +* Daniel Baumann (Debian packaging) +* Daniel Wäber (wabu) (fixes and patches) +* † Denis Grelich (ex-maintainer) +* Fabian Braennstroem (contributed archlinux packages) +* Fernan Bolando (one of the most active WMI testers, contributed various ideas and feedback concerning the slot) +* Fernando T. C. Lemos (contributed several themes) +* Filippo Erik Negroni (contributes wiki documentation to dwm) +* Dr. Frank Boehme (one of the first WMI users, contributed various ideas) +* Frank Ehmsen (contributed several bug reports and various good feature requests) +* Gabriel (various feedback, various color schemes) +* Gavin McCullagh (contributed various ideas) +* Georg Neis (Developer, documentation, tests) +* grayrest (great ideas for the menu, select-frame policy beside many other valuable ideas) +* Hannes Klas (contributed themes and maintains some translations in the Wiki) +* Henning Bekel (various feedback concerning the ratpoison shortcut handling) +* Dr. Johann Pfefferl (several patches which fixed many issues) +* John Pham (Debian Packager, Sysadmin) +* Jonas Domeij (various feedback concerning wmii, default wmi-10 theme) +* Jukka Salmi (fixes and patches) +* [Kai Hendry](http://hendry.iki.fi) (sales) +* Kathryn Andersen (contributed nice theme and valuable newbie feedback) +* Kris Malfettone (various feedback concerning wmir) +* Malte Zorn (various feedback) +* Marcel Manthe (Developer of PATH expansion in wmi-10 input mode) +* Marcin Pawlik (contributed Control-keys patch for input mode) +* Mark Weinem (contributed various ideas) +* Markus Lindorfer (contributed patch to compile on Solaris) +* Martin Moncrieff (various feedback concerning Mathematica issues) +* Mathieu L (contributed various feedback) +* Matthew Allen (contributed several themes and great art assets, works on the WMI mascot) +* Michael Ihde (provided several fixes to the container.h class and documentation) +* [Nico Golde (nion)](http://www.ngolde.de) (testing, fixes, wmii-2 blue theme, [ii developer](http://tools.suckless.org/ii/)) +* [Norman Golisz](http://www.zcat.de) (documentation) +* Norman Köhring (pSy) (developer of szs) +* Oliver Kopp (contributed various feedback) +* Oliver Rendgen (Documentation) +* PEYROUX Jean (BSD Port Maintainer (all platforms)) +* Rainer Trusch (contributed several bug reports and some ideas) +* Rajesh Menon (contributed various feedback) +* Robert Lillack (contributed some ideas to the new window concept) +* Ryan Sorensen (provided various debug input) +* Salva Peiro (gualteri) (user & translation guide-es) +* Sander van Dijk (developer) +* Sebastian Hartmann (Manual pages for wmii) +* Sebastian Roth (several bugfixes in C and Makefiles, Doxyfile) +* Stefan Kuttler (inventor of the WMI project name) +* Stefan Tibus (fixes and patches) +* Steffen Liebergeld ("A guide to wmii" author) +* Steve Hoffman (various feedback, small fixes) +* Szabolcs Nagy (fixes and patches) +* Tobias Walkowiak (provided various feedback) +* Tuncer Ayaz (contributed some grammar fixes for the Improved GUI concepts paper) +* Uwe Zeisberger (code review, bug fixings) +* Wilson Oliveira (contributed the wmizer tool) +* yiyus || Jesus Galan (dwm patches a go-go) +
