Fryboyter

Deutschsprachiger Usenet-Server mit Schwerpunkt Arch Linux

Unter der IP 84.200.213.109 steht seit einigen Tagen ein Usenet-Server zum diskutieren (nicht zum Downloaden) bereit. Schwerpunkt ist im Grunde (Arch-)Linux. Folgende Gruppen sind derzeit vorhanden:

  • admin.news.groups: Alles Rund um den den Server. Z. B. um neue Gruppen vorzuschlagen.

  • alt.nerd: Für Dinge rund um dien IRC-Server irc.malte-bublitz.de

  • alt.nerd.themenabend: Planung für eventuell stattfindenden Themenabende

  • comp.os.linux: Für das ganze Linux-Gedöns

  • comp.os.linux.archlinux: Für Arch Linux im Speziellen

  • comp.os.bsd: Für die BSDler unter uns

Das ganze ist nicht auf meinem Mist gewachsen sondern auf dem von Malte Bublitz. Ich rühre hier nur etwas die Werbetrommel, da ich es interessant finde abseits von Foren diskutieren zu können. Oldschool sozusagen. Bisher ist es noch etwas leer, wie man sieht, aber vielleicht ändert es sich ja.

Usenet Server

Der Server ist nun unter nntp.flying-sheep.de erreichbar.

Linux | OSBN

Arch Linux Bug Squashing Day am 17. November 2012

Am 17. November ist es mal wieder soweit. Die Gemeinschaft hinter Arch Linux ist aufgerufen Käfer zu terminieren.

Im Grunde ist das recht einfach. Man sucht sich bestimmte Pakete heraus, überprüft ob die gemeldeten Bugs noch aktuell sind und meldet diese ggf. an Upstream Sollte es dort bereits einen Patch gegeben, testet man diesen ob er auch funktioniert.

Zur Kommunikation zwischen den Archern dient hier der IRC-Kanal #archlinux-bugs (irc.freenode.net).

Mein derzeitiger Lieblingskäfer wurde zwischenzeitlich sogar schon zertreten. Consolekit, was bei mir den Bootvorgang ziemlich verzögert hat und was schon seit längerem nicht mehr gewartet wird, ist zugunsten von polkit und systemd-logind entfernt worden. Und ja, ich mag systemd.

Linux | OSBN

Arch Linux setzt auf systemd

Nun ist es offiziell. Auch Arch Linux wird zu systemd wechseln. Diesen Schritt sind schon einige Distributionen wie Mandriva, Mageia, Fedora oder OpenSuse gegangen. Ich finde die Entscheidung gut.

In absehbarer Zeit wird wohl alles unter systemd laufen (einige Unit scheinen noch zu fehlen) und die rc.conf vermutlich wegfallen. Für einige Archer ist das scheinbar ein Horrorszenario, da angeblich Arch Linux ohne rc.conf nicht mehr Arch Linux ist. Allen McRae hat dazu und zu diversen anderen Änderungen in der letzten Zeit (wie z. B. der Symlink von /lib nach /usr/lib), die auf Kritik bei den Anwendern gestoßen sind, einen guten Beitrag in seinem Blog geschrieben.

Ich werde dies mal als Anlass nehmen und meine Arch-Linux-Installation so weit wie möglich auf systemd umstellen. Bisher läuft hier noch ein Mischbetrieb aus einer alten rc.conf mit allem drum und dran und systemd.

Nachtrag (21.08.2012): Tomegun (einer der Entwickler) hat sich im englischsprachigen Arch-Linux-Forum dazu geäußert wie der Umstieg bisher geplant ist und hat auch einige Punkte genannt warum umgestiegen wird.

Linux | OSBN

Arch Linux wird noch "nerdiger"

Bei Arch Linux ist soweit ich es sehe AIF entfernt worden. Wohl weil es stellenweise ziemlich fehlerhaft ist und sich der betreffende Entwickler nicht mehr darum kümmern kann/will.

Derzeit läuft der Spaß nun komplett über die Konsole mittels der Arch Install Scripts ab. Eine recht kurze Zusammenfassung gibt es hier und da gibt es eine etwas ausführlichere Anleitung.

Im Grunde genommen ist die neue Installation also kein Hexenwerk, wird aber vermutlich doch einige abschrecken, die Arch ausprobieren möchten. Oder wie sehr ihr das?

OSBN | Allgemein

Arch Linux schneller starten

Eigentlich ist es mir egal, wie schnell die bei mir installierten Betriebssysteme starten. Zumindest wenn es nicht mehrere Minuten dauert. Aber gestern ist bei mir mal wieder der Spieltrieb ausgebrochen. Darum habe ich mir mal den Bootvorgang von Arch Linux vorgenommen. Als erstes habe ich mir mal angesehen wie schnell das System derzeit startet. Da ich systemd einsetze habe ich das mit dem Befehl systemd-analyze gemacht. Hier wird angezeigt, welche Services usw. wie lange gebraucht haben. Sortiert wird das ganze von lange bis kurz. Insgesamt hat das System gut 30 Sekunden gebraucht (da ich die alten Werte nicht gespeichert habe, bitte folgende zwei Beispiele nur als Beispiele ansehen).

systemd-analyze Startup finished in 11278ms (kernel) + 19325ms (userspace) = 30603ms

Im Grunde also ein Wert, bei dem zumindest ich nicht meckern kann. Dank meines Spieltriebs wollte ich aber trotzdem mal sehen, was möglich ist. Als nächstes haben ich mir mittels systemd-analyze blame anzeigen lassen, was wie lange zum starten gebraucht hat.

systemd-analyze blame
2802ms systemd-readahead-collect.service
2756ms systemd-readahead-collect.service systemd-readahead-replay.service
2727ms systemd-logind.service
2669ms media-WindowsD.mount
2668ms media-WindowsC.mount
2664ms console-kit-daemon.service
2620ms network.service
2600ms dbus.service
1465ms systemd-remount-fs.service
1273ms systemd-udev-trigger.service
1094ms dev-mqueue.mount
1090ms sys-kernel-debug.mount
890ms systemd-user-sessions.service
850ms systemd-sysctl.service
827ms dev-hugepages.mount
609ms systemd-vconsole-setup.service
460ms console-kit-log-system-start.service
451ms systemd-modules-load.service
308ms systemd-tmpfiles-setup.service
306ms media-WindowsD.mount
239ms systemd-udev.service
156ms openvpn@NL4.service
123ms home.mount
43ms tmp.mount
39ms upower.service
16ms udisks2.service
5ms boot.mount
1ms rtkit-daemon.service
1ms sys-fs-fuse-connections.mount

Da ich e4rat verwende habe ich mittels systemctl disable systemd-readahead-collect.service systemd-readahead-replay.service die beiden vergleichbaren systemd-Services deaktiviert, da diese recht lange gebraucht haben. Viel mehr konnte ich nicht deaktivieren, da ich leider alle andere was langsam gestartet wurde, brauche. In der mittels systemd-analyze blame erzeugten List ist mir allerdings noch aufgefallen, dass es relativ lange dauert, bis zwei NTFS-Partitionen gemountet werden. Da ich diese nicht sofort nach dem Start und auch nicht regelmäßige brauche, habe ich mir mal die /etc/fstab vorgenommen. Systemd bietet hier die Möglichkeit, bestimmte Partitionen erst zu mounten, wenn man auf die Mountpoints zugreift. Das sollte wieder etwas bringen. Also habe ich einen Blick in die fstab geworfen. Eine der betreffenden Einträge sah z. B. so aus.

UUID=DE084E95084E6C99 /media/WindowsC ntfs-3g default 0 0

Hier muss nun das default gegen noauto,comment=systemd.automount ausgetauscht werden, so dass wir folgenden Eintrag erhalten.

UUID=DE084E95084E6C99 /media/WindowsC ntfs-3g noauto,comment=systemd.automount 0 0

So wird in diesem Fall die Partition die über /media/WindowC angesprochen wird, erst dann gemountet, wenn man auf den Mountpoint zugreift. Und schon hat das System wieder etwas schneller gebootet. Wirklich schneller wurde der Spaß aber erst, als ich auch noch den Eintrag für /home angepasst habe. Das hat richtig etwas bewirkt. Als letztes habe ich dann noch die unnötigen Terminals, wie hierbeschrieben deaktiviert. Und was hat mir das ganze jetzt gebracht? Etwas Spass an der Freude und ein System, dass nun in ca. 18 Sekunden anstelle von 30 bootet. Ich vermute allerdings, dass man den Bootvorgang noch weiter optimieren könnte. Aber dafür müsste man, wenn man den diversen Anleitungen vertraut, zu sehr ins System eingreifen. Das lasse ich mal lieber.

Linux | OSBN