Arch Linux Planet

Tach zusammen,

nach den insagesamt gut 10 Jahren die ich ohne archlinux verbracht habe ich mich wieder inspirieren lassen und bin zu dem leidenschaftlichen Betriebssystem zurück gekehrt.
Installiert ist Arch auf einem MacBook Air als alleiniges Betriebssystem mit xfce, also ist es jetzt ein ArchBook :-)
Läuft alles in allem rund und ich bin sehr zufrieden.

Gewiss werde ich mich das ein oder andere Mal mit ein paar Fragestellungen hier melden.

Auf ein gutes Miteinander

Bernd

Die Versionen von hplip vor Version 3.20.3-2 beinhalteten nicht die kompilierten Python Module. Dies wurde in hplip-3.20.3-2 behoben, sodass beim Upgrade die von Pacman nicht katalogisierten Dateien überschrieben werden müssen.
Falls Ihr Fehler nach dem Schema

hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists in filesystem
hplip: /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in filesystem
hplip: /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in filesystem
...usw.

während des Upgrades erhaltet, aktualisiert bitte via

pacman -Syu --overwrite /usr/share/hplip/\*

Diese Idee kam vor einigen Jahren auf, wurde aber nie vollständig umgesetzt. Ich hab mich dem angenommen und einen schnellen Server in Deutschland aufgesetzt und die nötigen Scripte für den inkrementellen Import von Updates in IPFS (Interplanetary FileSystem) geschrieben.

IPFS kann zudem in einem Cluster ausgeführt werden. Dabei kann man einen oder mehrere Server definieren, die schreiben dürfen, aber jeder kann dem Cluster "Folgen" und eine weitere Kopie speichern, Aktualisierungen vom Cluster erhalten und so Speicherplatz und Traffic für den Cluster bereitstellen.

Zudem funktioniert IPFS ähnlich wie Bittorrent, jeder der einen Teil heruntergeladen hat, bietet diesen auch wieder im Netzwerk an. Somit bekommt jeder einen viel schnelleren Download, als von einzelnen Servern und lokalere Quellen mit niedrigerem Ping werden bevorzugt bezogen.

Wenn ihr einen Server habt, mit dem ihr dem Cluster Speicherplatz und Traffic zur Verfügung stellen wollt, könnt ihr das gern tun - weitere Infos im Link am Ende.


Benutzung vom IPFS-Spiegelservers:

Ihr braucht einen IPFS-Dienst auf eurem System (Weitere Infos dazu im englischen Wiki).

Danach könnt ihr das lokal laufende Web-Gateway vom IPFS-Dienst als Quelle in der Pacman-Mirrorlist angeben, plus den Pfad der den Spiegelserver definiert:

# IPFS
Server = http://127.0.0.1:8080/ipns/pkg.pacman.store/arch/$arch/default/$repo

IPFS kann zudem zu anderen Computern im Lokalen Netzwerk eine Verbindung aufbauen, um die Daten lokal auszutauschen, anstatt sie erneut aus dem Internet zu laden. Das funktioniert mit mDNS und ist standardmäßig eingeschaltet, das reduziert also eure Downloadzeiten für Updates, da ihr unter Umständen den Download schon auf einem anderen Computer im Netzwerk durchgeführt habt.

Standardmäßig hält IPFS bis zu 10 GB in seinem Cache, das kann in den IPFS-Einstellungen verändert werden, wenn dir das zu wenig oder zu viel vorkommt. Dieser Cache wird automatisch aufgeräumt, wenn er voll ist.

Weitere Informationen zu dem Projekt findet ihr im Git: pacman.store.

Hallo zusammen,
ich lese schon seit ein paar Wochen mit, das Forum gefällt mir, ich konnte schon einige Informationen heraus ziehen, was mich bewog, mich hier richtig anzumelden. smile
Zu meiner Person: Bin 49 Jahre alt und habe seit 3 Wochen Arch Linux auf meinem Lenovo installiert. Vorher hatte ich jahrelang andere Distributionen, zuletzt Linux Mint. Durch ein youtube-Video von unicks.eu und marcuss habe ich mir mal den Spaß gegönnt und Arch Linux installiert. Ich bin von der Schlankheit und Geschwindigkeit des Systems sehr beeindruckt. Außerdem läuft jetzt unter XFCE mit Arch alles out of the box, so etwas hatte ich noch nie.

Eigentlich habe ich mir vorgenommen, das nächste Arch mit BTRFS und Vollverschlüsselung aufzusetzen, wenn die Kiste wegen eines schlechten Updates nicht mehr zu retten ist Aber ich habe das dumme Gefühl, dass das noch recht lange dauern kann, aber mal abwarten. big_smile

Viele Grüße, man liest sich!
Markus

Nachdem es in den letzten Jahren nach und nach immer stiller um ihn geworden ist, hat unser bisheriger Projektleiter Aaron Griffin (phrakture) dieses Amt nun offiziell niedergelegt. Parallel wurde ein Prozess etabliert, der künftige Wechsel auf diesem Posten geordnet gestalten soll.

Die Projektleitung bei Arch Linux hat nun Levente Polyak (anthraxx).

Die Aufgaben des Projektleiters werden unter dem oben genannten Link beschrieben. Insbesondere besteht seine Rolle darin, Arch Linux finanziell und juristisch zu vertreten. Die anderen Aufgaben kann man kurz als "Richtlinienkompentenz" umschreiben.

lariza bekommt vielleicht JS-Userskripte – und dadurch einen Follow Mode

In der README von lariza steht:

Background information
----------------------

 What lariza is and what it's not

  ...

  Especially, it's very likely that lariza will never have a "follow
  mode" like dwb, luakit or others have. I've used these browsers for
  quite some time and I've also used Firefox extensions that add a
  "follow mode". The point is, "follow mode" doesn't work anymore. This
  was a good thing ten years ago. Today, a lot of websites make heavy
  use of JavaScript or hovering. You NEED some kind of pointing device.
  I found using "follow mode" to be very frustrating today, because you
  still have to reach for the mouse all the time. So, you might as well
  just optimize your mousing workflow.

„Ten years ago“ bezieht sich auf 2004 und war vielleicht damals schon zu optmistisch.

Jedenfalls könnte sich das ändern.

2019 war ein „Jahr des Schmerzes“. Ja, klingt ein bisschen dramatisch. :) Das ganze Jahr über hatte ich es mit Schmerzen in den Handgelenken zu tun und anderen Problemen in dieser Gegend. Das ist immer noch ein bisschen ungeklärt alles und auch noch nicht ganz vorbei. Das Ding ist aber, dass es mir derzeit wirklich schwer fällt, die Maus zu benutzen. Wie da oben aber schon steht, zwingt lariza einen eigentlich genau dazu und deswegen habe ich dann aufgehört, den Browser zu benutzen. Bin zurück zu Firefox, was seine eigenen Bugs hat, und dann zu Chromium – mit Vimium als Plugin.

Vimium hat ein paar nette Shortcuts, aber vor allen Dingen auch einen „Follow Mode“. Das ist so viel komfortabler als Mausbenutzung oder ein Touchscreen. Meiner Ansicht nach sollte jeder Browser (jede UI allgemein?) sowas eingebaut haben und es sollte der Standard sein, wie wir im Web navigieren, aber nungut.

Jedenfalls ist es sprichwörtlich schmerzhaft, lariza in der aktuellen Form zu benutzen. Ich will das Projekt nicht aufgeben, also muss man da was tun.

Eine kleine Vorschau.

larizas Follow Mode

Man drücke einen Hotkey (derzeit f), um Link Hints zu aktivieren:

1.png

Man beachte, dass die Labels rechts neben den eigentlichen Links sitzen, was anders als in anderen Implementierungen ist – darauf kommen wir noch zu sprechen. Die Labels sehen dann wie kleine Pfeilchen aus, um die Verwirrung hoffentlich ein bisschen zu lindern.

Den Rest kennt man: Man tippt ein paar der Zeichen der Labels ein, um die Auswahl immer weiter einzuschränken. Als nächstes habe ich h gedrückt:

2.png

In hellem Grün die aktuelle Auswahl. Ich könnte jetzt Enter drücken, um den Link zu öffnen. Man beachte, dass das eigentliche Element nochmal hervorgehoben ist – auch darauf kommen wir noch zurück.

Dann d gedrückt:

3.png

Jetzt ist nur noch ein Label übrig, man muss aber trotzdem Enter zum Bestätigen der Auswahl drücken. Yep, auch darüber sprechen wir noch.

Zur Implementierung des Follow Mode

WebKit trennt den C-/GTK-Code von allem, was in der eigentlichen Webseite passiert. Mit anderen Worten, man kommt von C aus nicht an das DOM der Seite ran. Man muss JavaScript benutzen. lariza lässt daher schon ein kurzes Stückchen JS laufen, um die Liste der URLs für RSS-/Atom-Feeds zu bekommen.

Daraus ergeben sich ein paar Probleme.

Zuerst einmal muss natürlich auch der Follow Mode in JS geschrieben sein. Man muss ja ans DOM und das geht nur mit JS. Die Bauchschmerzen hier entstehen nicht dadurch, dass „JavaScript eine blöde Sprache“ sei, sondern dadurch, dass es eine fast komplett getrennte Welt ist – ein großer Bruch zwischen C/GTK und dieser JS-Welt. Es ist im Wesentlichen ein zweites Programm, das irgendwie mit dem ersten kommunizieren muss. Sein Code läuft asynchron zum Hauptprogramm, Input-Events sind ganz andere und so weiter.

Habe ich so gemacht, dass ich ein generisches „Userkript“-Feature eingebaut habe, so ähnlich wie surf das hat. Anders als surf führt lariza aber nach dem Laden einer Seite einfach alle Dateien aus, die sich in einem bestimmten Verzeichnis befinden.

Um ehrlich zu sein, ist der Follow Mode auch so ziemlich das einzige, wofür man Userskripte in meinen Augen sinnvollerweise einsetzen kann. Man kann jetzt an eigene Keybinds denken, aber da bitte erstmal weiterlesen. Okay, man kann mit Userskripten vielleicht noch auf lästigen Webseiten bestimmte Elemente löschen. Das war’s dann aber, glaube ich, auch. Vielleicht bin ich auch nicht kreativ genug. Trotzdem war dieser Ansatz der am wenigsten invasivste – der Diff ist winzig und lariza selbst weiß auch gar nichts von einem Follow Mode. Es sagt WebKit nur, dass es ein bisschen JavaScript ausführen soll. Wie wir gleich sehen werden, funktioniert das so einigermaßen, ist aber weit entfernt von einer perfekten Lösung und vielleicht nicht einmal eine gute.

Was ich schon nicht hinbekommen habe, ist, meine eigenen Skripte gegenüber denen der Webseite zu isolieren. Heißt also, wenn man nicht in den Userskripten alles in eine anonyme Funktion wrappt, wie unten gezeigt, dann kann die Webseite deine Variablen auslesen und beeinflussen! Oder du kannst Variablen im Code der Webseite kaputtmachen. Ziemlich nervig – und sieht auch so aus, als wäre das bei Browsern wie Chromium anders.

(function() {

    // Configuration
    var charset = "sdfghjklertzuivbn".split("");
    var key_follow = "f";
    var key_follow_new_win = "F";

    function update_highlights_or_abort()
    {
        ...
    }

    ...

}());

Das kann man nun zwar mit dieser anonymen Funktion umgehen, aber wenn es um Key-Handler geht, wird es viel schlimmer. Man kämpft nämlich gegen die Webseite an. Das Firefox-Plugin Vim Vixen hat das Problem auch (und verliert den Kampf – Key-Handler der Webseite und des Plugins triggern beide). Nur Vimium scheint dieses Problem meistens nicht zu haben, allerdings enthält dessen Code auch Kommentare wie: „Wir laufen so früh wie möglich, damit die Webseite vor uns keine Keys abfangen kann.“ Vielleicht ist es auch nur Chromium, was sich etwas geschickter dabei anstellt, die beiden Welten zu trennen. Keine Ahnung. Wenn ich so darüber nachdenke, fallen mir letztlich auch ein paar Webseiten ein, die ich auf der Arbeit nutzen muss, bei denen selbst Vimium versagt.

Das ist schon ganz schön mies. Ich konnte auch keinen Weg finden, das zu vermeiden. Vermutlich wird man eine ganz eigene JS API bauen müssen, um das Thema sauber zu lösen, damit lariza-Skripte ihre Event-Handler darüber registrieren können und nicht über das normale document.addEventListener() gehen müssen. Jeder Tastendruck würde dann zuerst an unsere eigenen Handler geschickt und, falls diese nichts damit anfangen können, auf dem normalen Wege zur Webseite. Habe ich bisher noch nicht so gemacht, weil es recht aufwändig ist (und weil es noch andere Dinge gibt, die kräftig in die Hose gehen, daher weiß ich noch gar nicht, ob sich der Aufwand überhaupt lohnen würde). Stattdessen haben wir jetzt folgenden Workaround:

Wird der Follow Mode aktiviert, dann erstellen wir ein verstecktes input-Feld und fokussieren es. Gibt man dann die Buchstaben der Labels ein, wird eigentlich in dieses Feld reingetippt. Albern, scheint aber zu funktionieren – zumindest für die Eingabe der Labels. Sollte eine Webseite schon die f-Taste zum initialen Aktivieren des Follow Modes ohne Fokus der Input-Box für sich beanspruchen, ist man wieder aufgeschmissen. Hatte kurz darüber nachgedacht, daraus ein Alt + f zu machen, aber das ist nicht sehr angenehm.

Noch ein Rückschlag war die Performance von element.getBoundingClientRect() in WebKit: Diese Funktion kann benutzt werden, um die sichtbare Position eines Elements zu berechnen. Idealerweise könnten wir damit die Labels „perfekt“ platzieren, nämlich genau bei den Elementen, auf die sie verweisen. Ist aber zu langsam. Viel zu langsam. Auf Webseiten mit vielen Links dauert die Erstellung aller Labels einige Sekunden auf meinem i7, der mit 3.4 GHz läuft. Die genannte Funktion scheint aber in Chromium schnell zu sein und Vimium benutzt sie auch, weshalb dieses Plugin sehr gute Ergebnisse erzielt.

Wir können’s aber nicht benutzen. Als Workaround platzieren wir jetzt die Labels so nahe wie möglich am referenzierten Element im DOM und hoffen dann, dass sie schon irgendwo in der Nähe auftauchen werden. Für <a>-Elemente werden sie als Kind hinzugefügt. Deswegen tauchen sie rechts davon auf.

Funktioniert aber auf „fancy“ Webseiten oft nicht richtig. Manchmal erscheinen die Labels einfach an der falschen Stelle. Deswegen wird das von einem Label referenzierte Element noch einmal bei der Auswahl hervorgehoben. Und deswegen ist auch das finale Drücken von Enter zum Öffnen eines Links notwendig, denn – jenachdem, wie fies die Webseite ist – man erwischt sonst oft aus Versehen einfach ein völlig falsches Element.

Und natürlich passiert all das tief im DOM der Seite. Das CSS der Webseite greift also auch für unsere Labels. Manchmal erscheinen sie daher in Großbuchstaben, weil die Webseite das so will. Oder sie haben ein kleines Icon, weil die Webseite das :before-Pseudoelement benutzt. Oder andere Elemente überdecken unsere Labels, weil, tja, die Webseite das so will. Das führt uns schließlich zum nächsten Abschnitt.

Ein Follow Mode in dieser Form kann nur unvollständig sein

Man schaue sich nur die Bugtracker von Vimium oder Vim Vixen an. Selbst diese Plugins funktionieren nicht immer. Vimium ist eigentlich verdammt gut, aber trotzdem, manchmal geht’s nicht.

Ist keine Überraschung. Webseiten sind keine passiven Dokumente. Jedenfalls heute nicht mehr. Es sind Applikationen. Und als Programmierer eines Follow Mode kämpft man ständig gegen sie an. Man kann sich das so vorstellen: Man denke an ein normales in C geschriebenes Programm für X11 und dann hat man ein anderes Program, das im selben Adressraum läuft und versucht, alle „klickbaren“ Elemente zu finden. Du weißt, wo der Ziel-Framebuffer ist, und es gibt eine kleine „API“, um grundlegende Elemente wie Buttons zu finden. Im Wesentlichen hat man aber keine Ahnung, was alles klickbar ist, weil jeder Pixel aufgrund von irgendwelchem Code klickbar gemacht sein könnte. Und dann muss man gegen das interne Fokussystem der Anwendung kämpfen. Und gegen ihr Eventsystem. Und überhaupt. Ich weiß jetzt nicht, ob das der bestmögliche Vergleich ist, aber so ungefähr fühlt sich das an. Das kann vielleicht für einfachere Programme wie leafpad noch funktionieren, aber nicht für sowas wie Blender. Es wird immer eine unvollständige Lösung sein.

Die wichtigsten Beispiele:

  • An vielen HTML-Elementen können JavaScript-Funktionen dranhängen. Wie finden wir die? Wenn die Webseite element.addEventListener() benutzt, gibt es, soweit ich weiß, keine Möglichkeit, die registrierten Handler aufzulisten.
  • Wie behandelt man Hovering? Rein mit CSS kann man schon Hover-Menüs bauen. Um die zu öffnen, müssten wir dann ein Hovern über dem Root-Element simulieren oder was … ?
  • Wie behandelt man „halb-native“ Element wie die Controls eines <audio>-Tags, die im DOM gar nicht auftauchen?
  • Selbst, wenn wir element.getBoundingClientRect(), benutzen könnten, hätten wir damit nur die Bounding-Box eines Elements. Wo platzieren wir also das Label? Oben links? In der Mitte? Wir haben keine Ahnung, was der User als „das Element“ oder „den klickbaren Bereich“ wahrnimmt. Das kann also immer noch sehr missverständlich sein, insbesondere bei großen Elementen.
  • Natürlich der bereits genannte Kampf um die Key-Events.

Ich behaupte, wenn man das sauber lösen will, muss man das in der Rendering-Engine selbst machen. Oder am besten vereinfacht man das Web wieder und entfernt die ganzen feschen Features, die oftmals ohnehin keine Verbesserung von irgendwas bringen.

Aus genau diesen Gründen habe ich damals keinen Follow Mode für lariza gebaut und auch nie geplant gehabt. Wenn ich nicht diese Probleme mit den Handgelenken hätte, wäre mir meine Zeit viel zu schade, um mich damit auseinanderzusetzen, aber, ja, hab’s dann doch gemacht, weil es besser ist als gar nichts.

Abschließende Gedanken

Wahrscheinlich wird lariza höchstens das Feature der Userskripte bekommen. Ich bin noch nicht sicher, ob ich follow_mode.js bundlen oder in ein eigenes Repo packen werde. Außerdem muss ich das alles noch weiter testen und ausprobieren. Vielleicht werfe ich es doch wieder weg, falls es einfach nicht gut genug ist.

Ich würde auch gerne vermeiden, lariza in noch so einen „vi-artigen Browser“ zu verwandeln. Davon gibt’s genug. Außerdem ist das super viel Arbeit. Im Moment ist lariza klein und das ist sehr gut so.

Aber … ja, der Follow Mode macht einige Designkonzepte von lariza kaputt. Plötzlich gibt es einen Mix aus „alle Browser-Hotkeys werden in C behandelt und sind mit Alt gepräfixt“ und „drücke f, um einen besonderen Modus in der JavaScript-Welt zu aktivieren“. Fühlt sich wie eine Mischung aus Emacs und vi an. Einfach nicht sauber. Ich habe da dann das Bedürfnis, die existierenden Hotkeys aufzuräumen und ein paar Konzepte anzupassen, aber dann wäre man eben bei genau einem vi-artigen Browser.

Um ehrlich zu sein, hätte ich den Follow Mode gerne als rein optionales Feature. Schon alleine, weil er so wackelig ist und oft kaputt geht.

Trotz aller Hürden macht (mir – in der derzeitigen Situation) die Benutzung des Browsers gleich viel mehr Spaß, wenn es einen Follow Mode gibt. :) Es ist so eine typische 80%-Lösung, aber wenn es funktioniert, dann ist es toll und sehr angenehm.

vain
TL;DR: In some circumstances, you may find usable Kerberos TGTs on a system you compromised - these allow you to impersonate a user that already changed its password (e.g. because the user got suspicious or a PAM solution is in place). Intro On a recent project, I was tasked with the usual goal: Start from the ground and find a way to take over the company - in the end, if possible, somehow become Domain Admin.

PulseAudio Mini EQ

09.02.2020
PulseAudio Mini EQ

Meine derzeitige Wohnung hat ’ne schlechte Akustik. Harte Wände, harter Boden, kein Teppich. Teure Lautsprecher lohnen sich nicht und nachdem mein altes Setup schließlich kaputt ging, habe ich einfach zwei ganz billige Speaker gekauft:

main speakers

Die sind gut genug für ein bisschen Hintergrundmusik oder Podcasts.

Aber … der Raum hat natürlich immer noch eine schlechte Akustik und jetzt sind auch noch die Lautsprecher schlecht. Äh. Ja.

Ich könnte natürlich Akustikelemente kaufen, Absorber oder Diffusoren. Bin ich aber zu faul für.

Mir ist dann kürzlich aufgefallen, dass ich die gefühlte Qualität stark verbessern kann, indem ich die Mitten reduziere. Die Audio-Nerds hassen mich dafür jetzt, aber ganz ehrlich: Ich mag den typischen HiFi-Sound, dem die Mitten fehlen. Ich finde Mitten einfach nicht besonders angenehm.

Okay, wie wende ich den EQ denn an? Man ist heute ja ohnehin quasi gezwungen, PulseAudio zu verwenden, also kann ich es auch damit machen.

Zuerst habe ich es mit PulseEffects probiert, was aber viel zu overpowered war. Dann pulseaudio-equalizer-ladspa probiert, was viel leichtgewichtiger ist. Hat auch ganz gut funktioniert, aber hat auch seine Problemchen. Zum Beispiel nimmt es an, dass man nur eine Soundkarte hat. Ich habe zwei. Eine dedizierte USB-Soundkarte mit einem Paar dedizierter Lautsprecher im PC-Gehäuse spielt ständig ratterplatter ab. Ja, sorry, mag ich halt. :-)

USB soundcard speakers inside case

pulseaudio-equalizer-ladspa hat dann ratterplatter ständig auf das falsche Output-Device geschoben.

Angeschaut, wie es funktioniert, und natürlich ist es gar nicht so kompliziert. Es benutzt das in PA bereits eingebaute Modul module-ladspa-sink, um Audio durch irgendeinen LADSPA-EQ zu routen und das war’s.

Alles klar, einfach neugeschrieben und nun habe ich PulseAudio Mini EQ. Benutzt denselben internen Mechanismus, hat aber ein anderes UI (war mir wichtig, dass ich es schnell an- und ausschalten kann – wenn ich Kopfhörer aufhabe, will ich natürlich keinen EQ) und verschiebt nur jene PA-Clients auf das virtuelle LADSPA-Device, die derzeit auf der „Hauptsoundkarte“ spielen. ratterplatter tut das nicht und wird daher nicht angefasst.

Mal gucken, wie lange ich das so benutze.

screenshot

vain
Wie C ein struct aus einer Funktion zurückgibt

In C kann man neben einfachen Dingen wie int oder char * auch ganze structs zurückgeben:

struct Foo
{
    char name[13];
    int age;
};

struct Foo
fill(void)
{
    struct Foo out;

    ...

    return out;
}

Fand ich immer etwas eigenartig, weil man Arrays nicht returnen kann – außer natürlich, sie sind wie oben in einem struct versteckt. Naja, nicht abschweifen.

Die Frage ist, was unter der Haube passiert, wenn man ein struct returned. Gemäß cdecl wird sowas wie ein int in einem Register zurückgegeben:

https://en.wikipedia.org/wiki/X86_calling_conventions#cdecl

Ein ganzes struct passt da meistens nicht rein. Der Wikipedia-Artikel gibt auf meine Frage eigentlich auch schon die Antwort, aber, faul wie ich bin, habe ich beim ersten Mal nicht so weit gelesen. :-) Stattdessen ein kleines Experiment gemacht:

#include <stdio.h>

struct Foo
{
    char name[13];
    int age;
};

struct Foo
fill(char this, char that, char whatever)
{
    struct Foo out;

    out.name[0] = this;
    out.name[1] = that;
    out.name[2] = whatever;
    out.name[3] = 0;
    out.age = 32;

    asm("# fill a");
    return out;
    asm("# fill b");
}

int
main()
{
    struct Foo joe;
    asm("# a");
    joe = fill('J', 'o', 'e');
    asm("# b");
    printf("[%s] %d\n", joe.name, joe.age);
    return 0;
}

Den Code mit ein bisschen Inline-Assembler gespickt und dann das Ergebnis angeschaut:

clang -O0 -Wall -Wextra -o bla.S -S bla.c

Man sieht diesen Abschnitt:

#APP
# a
#NO_APP
leaq    -56(%rbp), %rdi
movl    $74, %esi
movl    $111, %edx
movl    $101, %ecx
callq   fill
movl    -40(%rbp), %ecx
movl    %ecx, -16(%rbp)
movups  -56(%rbp), %xmm0
movaps  %xmm0, -32(%rbp)
#APP
# b
#NO_APP

Zur Erinnerung: rdi, rsi, rdx und rcx sind die ersten vier Register, um Parameter an die Funktion zu übergeben. Mein fill() hat aber auf Ebene des C-Codes nur drei Parameter, also … hat der Compiler offensichtlich einen zusätzlichen dort versteckt: leaq -56(%rbp), %rdi, einen Pointer auf den lokalen Stack der aufrufenden Funktion. Nachdem fill() zurückkehrt, werden Daten von dort gelesen und nach -32(%rbp) kopiert, einer anderen Stelle auf dem lokalen Stack.

Und das ist die Antwort. Der C-Compiler fügt einen versteckten Parameter ein und die aufgerufene Funktion kann dann dorthin schreiben.

Interessanterweise benutzt clang hier mit xmm0 eines der SSE-Register für diesen Kopiervorgang. Bei gcc sieht das so aus:

#APP
# 29 "bla.c" 1
    # a
# 0 "" 2
#NO_APP
    leaq    -64(%rbp), %rax
    movl    $101, %ecx
    movl    $111, %edx
    movl    $74, %esi
    movq    %rax, %rdi
    call    fill
    movq    -64(%rbp), %rax
    movq    -56(%rbp), %rdx
    movq    %rax, -32(%rbp)
    movq    %rdx, -24(%rbp)
    movl    -48(%rbp), %eax
    movl    %eax, -16(%rbp)
#APP
# 31 "bla.c" 1
    # b
# 0 "" 2
#NO_APP

Ein paar Instruktionen mehr. Ist jetzt kein bedeutungsschwangerer Vergleich, weil wir eh -O0 benutzt haben, aber trotzdem interessant.

Noch eine Randbemerkung zu den Arrays: Ich sehe nicht so richtig einen Grund, weshalb es – in der Theorie – nicht möglich sein sollte, Arrays fester Länge zu übergeben. Immerhin geht’s ja, wenn sie in einem struct sind, weil die Größen eindeutig definiert sind. In einer kleinen Mathe-Bibliothek, die ich mal geschrieben habe, benutze ich das sehr häufig:

struct mat4 {
    GLfloat v[16];
};

struct mat4
mat4_identity(void)
{
    struct mat4 m = {0};

    m.v[0] = 1;
    m.v[5] = 1;
    m.v[10] = 1;
    m.v[15] = 1;

    return m;
}

Damit kann man dann irgendwo im Code das Folgende schreiben, was in meinen Augen die Lesbarkeit gegenüber der manuellen Benutzung von Pointern deutlich erhöht:

void
something(void)
{
    struct mat4 a;

    a = mat4_identity();
}

Oder gar:

void
something(void)
{
    struct vec3 r, t;
    struct mat4 a;
    struct quat4 q;

    a = quaternion_to_rotational_matrix(q);
    r = mat4_mult_vec3(a, t);
}
vain

Das von Arch Linux mitgeliefert rsync hat bislang, entgegen einem sonst verfolgen Prinzip, eine in der Codebasis von rsync mitgelieferte und dort mehr schlecht als recht gewartete angepasste Version der zlib verwendet, um so die Komaptibilität zu mit der Option --compress erstellten Repos zu wahren. Diese Option hat es bis zu rsync Version 3.1.0 gegeben. Die Nachfolgeversion rsync 3.1.1 ist nun auch schon fünfeinhalb Jahre alt.

Die Arch-Entwickler haben sich daher entschieden, des Option nicht mehr zu unterstützen. Wer eine Synchronisation von Verzeicnissen machen will, die mit --compress erstellt wurden, wird also Probleme bekommen und sollte rsync nicht aktualisieren.

Zwar liegen hier seit Monaten mehrere fertige Artikel technischer Natur auf der Platte, nur kann ich davon noch nichts veröffentlichen, daher zu Abwechslung mal etwas aus dem Unterhaltungssektor.

Vor einigen Tagen habe ich mir X4: Foundations gekauft, da der Einstieg im ersten Szenario etwas anstrengend ist stelle ich nun als …

Thorsten Töpper
Ein paar Gedanken zu for, goto, Lesbarkeit

nullprogram.com ist eines der besten Blogs, die ich kenne. Quasi jeder Artikel ist interessant und ich lerne etwas neues.

Heute hat er einen Artikel zu purgeable memory veröffentlicht. Kurze Zusammenfassung des Konzepts: Es geht um Speicher, der vom Kernel freigegeben (nicht geswappt!) werden kann, falls es die globale Arbeitslast im System erfordert. Der eigene Code muss damit natürlich umgehen können.

Die Idee dahinter ist: Eine der Berechnungen, die der Code durchführt, dauert eine Weile und nimmt spürbar Speicher in Anspruch. Das Ergebnis will man mehrfach verwenden, zwischen den Verwendungen liegen aber größere zeitliche Pausen. Außerdem ist es schneller, die Berechnung einfach nochmal durchzuführen, als auf den Kernel zu warten, bis der irgendwas aus dem Swap wieder rausgeholt hat.

Als Beispiel gibt es diesen Codeschnipsel:

/* Version 0: Original code */

uint32_t *texture = 0;
struct png *png = png_load("texture.png");
if (!png) die();

/* ... */

for (;;) {
    if (!texture) {
        texture = purgeable_alloc(png->width * png->height * 4);
        if (!texture) die();
        png_decode_rgba(png, texture);
    } else if (!purgeable_lock(texture)) {
        purgeable_free(texture);
        texture = 0;
        continue;
    }
    glTexImage2D(
        GL_TEXTURE_2D, 0,
        GL_RGBA, png->width, png->height, 0,
        GL_RGBA, GL_UNSIGNED_BYTE, texture
    );
    purgeable_unlock(texture);
    break;
}

Eine Textur wird geladen und in einem OpenGL-Kontext verwendet. texture ist also eine langlebige Variable. Man denke beispielsweise an ein Menü in einem Spiel: Das Menü wird nur ab und zu mal aufgerufen und zeigt immer dasselbe Hintergrundbild – unsere texture. Das Menü soll sich schnell öffnen, also würde man die nötigen Daten gerne im Speicher behalten. Auf der anderen Seite: Wenn das Menü nur selten aufgerufen wird, muss das dann wirklich im Speicher bleiben? Wäre nett, zwingend notwendig ist es aber eben nicht. Also könnte man purgeable memory dafür verwenden.

Mir geht es jetzt um die for-Schleife da oben.

Die hat mich am Anfang ziemlich verwirrt. Warum ist da eine Schleife? Warum ist sie endlos? Müssen wir da vielleicht etwas mehrfach probieren, weil es fehlschlagen könnte? Einen Moment später sind mir dann continue und break aufgefallen und dann hat’s geklingelt.

Was eigentlich passiert, ist das (Pseudocode):

if (texture not loaded)
    load texture;
else /* texture was once loaded */
    if (kernel has purged the memory in the meantime)
        mark texture as "not loaded";
        TRY AGAIN FROM THE TOP;

use texture in OpenGL;
mark texture memory as purgeable;

Mit anderen Worten, die for-Schleife wird benutzt, um ein goto zu vermeiden.

Ein Vorteil dabei ist, dass die geschweiften Klammern unmissverständlich klarmachen, wo dieser Abschnitt beginnt und endet. Es kann keine unerwarteten Sprünge von woanders im Code geben, also wird eine der größten Fallen von goto ausgeschlossen.

Auf der anderen Seite habe ich den Eindruck, dass dieses Konstrukt nicht unbedingt „besseren“ Code erzeugt. Man muss es zweimal lesen und es ist auch gar keine Schleife. Es ist eher ein „probier’s nochmal“-Mechanismus.

Wenn man’s mal verstanden hat, ist es trivial. Es ist aber eines dieser Dinge, die so eine kleine „Barriere“ erzeugen. Wenn solche Tricks an sehr vielen Stellen benutzt werden, wird der Code unzugänglicher und es kann auch recht schwer für neue Leute im Team werden. Ich bin da natürlich keine Ausnahme und mache sowas auch. Klar, wenn man Code selbst schreibt, versteht man immer alles und alles ist trivial. Man vergisst zu leicht, dass man selbst auch irgendwann wieder „neu im Team“ ist, einfach weil man nach ein paar Jahren, in denen man den Code nicht angefasst hat, diese Tricks auch alle wieder vergessen hat. Das ist jetzt keine neue Erkenntnis, aber sie gerät eben allzu leicht in Vergessenheit.

Mit einem goto sähe es so aus:

/* Version 1: goto */

load_texture:
    if (!texture) {
        texture = purgeable_alloc(png->width * png->height * 4);
        if (!texture) die();
        png_decode_rgba(png, texture);
    } else if (!purgeable_lock(texture)) {
        purgeable_free(texture);
        texture = 0;
        goto load_texture;
    }
    glTexImage2D(
        GL_TEXTURE_2D, 0,
        GL_RGBA, png->width, png->height, 0,
        GL_RGBA, GL_UNSIGNED_BYTE, texture
    );
    purgeable_unlock(texture);

Ist das besser? Ich denke schon. Es gibt keine Verwirrung über eine Schleife mehr. Die unzutreffenden Vokabeln continue und break sind weg. Man liest das Label zuerst, ist also gewahr, dass da ein goto kommen wird. Label und goto sind auch recht nah beieinander. In meinen Augen ist das durchaus besser verständlich.

Ich benutze goto ab und zu, bin aber immer vorsichtig. Es muss einen guten Grund dafür geben. Es muss dabei helfen, Code zu schreiben, der besser verständlich ist. In diesem Fall hier wäre das in meinen Augen gegeben.

Die offensichtliche Frage ist aber, ob wir den Sprung überhaupt brauchen. Wie wäre es damit:

/* Version 2: Restructured code */

if (texture && !purgeable_lock(texture)) {
    purgeable_free(texture);
    texture = 0;
}

if (!texture) {
    texture = purgeable_alloc(png->width * png->height * 4);
    if (!texture) die();
    png_decode_rgba(png, texture);
}
glTexImage2D(
    GL_TEXTURE_2D, 0,
    GL_RGBA, png->width, png->height, 0,
    GL_RGBA, GL_UNSIGNED_BYTE, texture
);
purgeable_unlock(texture);

Der Code wurde umstrukturiert und es gibt jetzt kein „probier’s nochmal“ mehr. Der Pseudocode dazu sieht so aus:

if (kernel has purged our memory)
    reset pointer;

if (texture not loaded)
    load texture;
use texture in OpenGL;
mark texture memory as purgeable;

Ein bisschen hässlich ist, dass der Check für texture == NULL dupliziert ist. Es ist außerdem wichtig, dass man es nicht als else if schreibt, weswegen ich die leere Zeile drinhabe.

Geht es noch prägnanter? Was wir ja eigentlich machen wollen, sieht so aus:

if (texture not available)
    load texture;
use texture in OpenGL;
mark texture memory as purgeable;

Es gibt keine Schleife, keinen Sprung, nichts. Die Absicht ist klar formuliert. Kriegen wir das hin? Im Moment nicht. Nehmen wir aber mal an, die API der Bibliothek würde sich leicht ändern:

  • NULL-Pointer unterstützen: purgeable_lock() würde einfach False oder 0 zurückgeben.
  • Bei fehlgeschlagenen Locking-Versuchen automatisch den Speicher freigeben (wie im ursprünglichen Artikel vorgeschlagen).

Dann könnte man das machen:

/* Version 3: Altered API */

if (!purgeable_lock(texture)) {
    texture = purgeable_alloc(png->width * png->height * 4);
    if (!texture) die();
    png_decode_rgba(png, texture);
}
glTexImage2D(
    GL_TEXTURE_2D, 0,
    GL_RGBA, png->width, png->height, 0,
    GL_RGBA, GL_UNSIGNED_BYTE, texture
);
purgeable_unlock(texture);

Das ist die knappste und prägnanteste Variante, die ich finden konnte.

Auf der anderen Seite ist das wieder eine Grauzone. In Variante 3 muss man nämlich mehr mitdenken:

  • Falls texture == NULL ist, tut die Bibliothek nichts und returned False. Wir müssen jetzt das PNG decoden.
  • Falls texture != NULL ist:
    • Locking hat geklappt? Alles gut, war ja schon decoded.
    • Locking fehlschlagen? Dann müssen wir das PNG erneut decoden.

Je älter ich werde, desto mehr stört mich sowas. Es ist nur ein Funktionsaufruf, ich muss aber mehrere Situationen und Codepfade im Kopf durchsimulieren. Wenn man nicht aufpasst, vergisst man den Fall mit NULL vielleicht sogar. Selbst, wenn wir die Bibliothek also wie oben geändert hätten, würde ich den Code eher so schreiben:

/* Version 4: Altered API and explicit check */

if (!texture || !purgeable_lock(texture)) {
    texture = purgeable_alloc(png->width * png->height * 4);
    if (!texture) die();
    png_decode_rgba(png, texture);
}
glTexImage2D(
    GL_TEXTURE_2D, 0,
    GL_RGBA, png->width, png->height, 0,
    GL_RGBA, GL_UNSIGNED_BYTE, texture
);
purgeable_unlock(texture);

Die Prüfung auf texture == NULL ist dabei nicht zwingend notwendig, weil das ja auch die Bibliothek für uns macht. Ich glaube trotzdem, dass es sinnvoll ist, das explizit auszuschreiben, weil der Leser jetzt sofort weiß, dass es bei diesem if um zwei verschiedene Fälle geht: Das PNG wird decoded, wenn es das allererste Mal ist oder falls der Speicher weggeworfen wurde.

Als Schlussbemerkung: Ich schreibe lieber texture == NULL statt !texture, aus genau denselben Gründen. Es ist ein Pointer und wir prüfen, ob er NULL ist. Länger, aber dafür glasklar.

vain

Im Zuge einer Aufräumaktion unter den Xorg-Paketen kann es zu Fehlermeldungen kommen:

:: installing xorgproto (2019.2-2) breaks dependency 'inputproto' required by lib32-libxi
:: installing xorgproto (2019.2-2) breaks dependency 'dmxproto' required by libdmx
:: installing xorgproto (2019.2-2) breaks dependency 'xf86dgaproto' required by libxxf86dga

Dann muss manuell eingegriffen werden:

pacman -Rdd libdmx libxxf86dga && pacman -Syu

Den primus_vk-Paketen vor Version 1.3-1 fehlten enige soname-Verlinkungen. Die ist in 1.3-1 korrigiert worden. Dadurch müssen schon vorhandene Dateien, die zu keinem Paket gehören, und somit durch pacman nicht getrackt werden, überschrieben werden.

Wenn Ihr also eine Fehlermeldung folgender Art bekommt:

primus_vk: /usr/lib/libnv_vulkan_wrapper.so.1 existiert im Filesystem
primus_vk: /usr/lib/libprimus_vk.so.1 existiert im Filesystem

so ist die --overwrite-Option von Pacman zu verwenden,

pacman -Syu --overwrite=/usr/lib/libnv_vulkan_wrapper.so.1,/usr/lib/libprimus_vk.so.1

, oder die den Konflikt auslösenden Dateien sind manuell zu löschen.

Alle offiziellen Kernel-Pakete (linux, linux-lts, linux-zen and linux-hardened) installieren von sich aus keine eigentlichen Kernel mehr nach /boot.

Dieser Installationsschritt wird über mkinitcpio-hooks erledigt. Normalerweise sollte hier kein manuelles Eingreifen nötig sein. Ausnahme sind unter Umständen Neuinstallationen.

Dahinter steckt das Bestreben, die Kernelpakete in sich geschlossener zu halten und den Boot-Prozess flexibler gestaltbar zu halten.

Zur Zeit hat mkinitcpio Hooks zum Hinzufügen der Kernel von und des Löschens aus /boot. In naher Zukunft wir auch dracut solche Hooks besitzen und mkinitcpio nach und nach ersetzen.

Der Kompressionsalgorithmus zstd bietet gegenüber xz schnellere Kompression und Dekompression, ohne bei der Kompressionsrate gegenüber xz deutlich zurückzufallen. Die Einführung wird Paketinstallationen mit pacman also ohne spürbare Nachteile schneller machen.

Das kürzlich herausgebrachte Release 5.2 bringt alle Wrkzeuge mit sich, um Pakete mit zstd zu komprimieren. Dazu wird eine Version von libarchive benötigt, die Unterstützung für zstd bietet. Diese ist 3.3.1, und sie ist
vor über einem Jahr (September 2018) in die Repos gekommen. Wer also seit einem Jahr kein Update mehr gemacht hat, sollte dies schleunigst tun.

Auch Benutzerskripte, in der die Dateierweiterung pkg.tar.xz irgendwie hardkodiert ist, sollten angepasst werden - oder besser so umgeschrieben werden, dass die Dateiendung egal ist. Die neue Endung wird pkg.tar.zst sein.

Die Gruppe base wurde durch ein gleichnamiges Metapaket ersetzt.
Alle Benutzer sind angehalten, dieses Paket mittels

pacman -Syu base

zu installieren.
Systeme ohne dieses Paket werden im offiziellen Forum nicht mehr unterstützt.

Mein Weg zu Arch

Ich möchte euch hier mal meinen Weg zu Archlinux darlegen. Vielleicht findet es der ein oder andere ja ein wenig Interessant.

Bis vor 2 Monaten habe ich meine Linuxserver unter Proxmox mit Debian betrieben. Einen kleinen Teil lief und läuft immer noch auf einem Gentoo (CS1.6 und CSS Dedicated Server).
Ich habe unter Debian beispielweise Samba als PDC betrieben, NFS-Server, Apache2, MySQL uvm.. Man glaubt nicht wieviel man irgendwann am Laufen hat, wenn man gut zurecht kommt.

Nun bekam ich aber das erste mal mit Debian Probleme. Benutzte Debian schon seit Version 3. Ich wollte einen Versionsupgrade machen von Version 9.9 auf Version 10.
Das lief einigermaßen gut, einigermaßen. Stuzig wurde ich erst, als ich wie gewohnt per RSYNC meine Daten auf meinen Backupsystem übertragen wollte, merkte ich, dass das Tool rsync einfach weg war.
Hmmm ok. Kann ja mal passieren, dachte ich mir. Nachinstalliert und gut dachte ich.
Als ich aber dann merkte, dass mein Mailserver (Postfix, Dovecot, Amavisd-NEW, Spamassassin, ClamAV) auch nicht mehr seinen Dienst verrichtete, dachte ich mir warum hat mich das System nicht über Änderungen der Configfiles benachrichtigt, wie immer?
Da war ich dann doch soweit. Ich habe das erste mal drüber nachgedacht über einen Wechsel. Aber es auch gleich wieder verworfen.
Nun waren noch 3 PCs dran und noch 4 Laptops. Ich mache es kurz und knapp. Bei jedem dieser Systeme hat der Versionsupgrade überhaupt nicht funktioniert. Ich war mehr als verdutzt. Regelrecht frustriert. Ich wollte es nicht glauben.
Was war nur los mit meinem geliebten Debian? Das kenne ich so nicht. Ich bin vorgegangen wie immer. Alles lief schief. Ich hatte nie vorher Probleme mir Versionsupgrades. Und jetzt bei jedem System. Oh mein Gott. Jetzt habe ich echt Arbeit vor mir.

Jetzt habe ich Recherche betrieben. Ich habe mich sehr schnell dazu entschieden: Ich brauche ein Rolling Release Linux...
Klar, dachte ich als erstes an mein hochgeschätztes Gentoo. Aber Aufgrund der doch relativ großen Anzahl der Pakete, die ich für meinen Hauptserver brauche schnell wieder verworfen. Läuft ja nicht auf Xeons in meinem Fall.
Nur, wenn ich nichts anderes finde wäre ich auf Gentoo gegangen und hätte Compiliert bis die Schwarte kracht. Ich finde Gentoo megatoll. Optimieren, einschränken, einfach tolle Distri. Aber auf einem C2750 virtuell 4vCPUs, neee, eher nicht. Außerdem habe ich ja ein Gentoo laufen, wie vorher schon erwähnt.
Ich mache es nun kurz. Alle möglichen RollingRelease Linuxe virtuell mal angetestet. Aber... Die einzige "andere" RollingRelease-Distri, die in meinen Augen für mich funktioniert mir auch gefällt war ARCHLINUX. Die Entscheidung war gefallen.

Also neue virtuelle Hülle angelegt und begonnen:
Das tolle Wiki von Archlinux genutzt und die Installation begonnen. Jaaaa, ich bin natürlich voll in die erste Hürde ungebremst reingerannt.
Ich will mein System mit LVM2 und ich will /usr als eigene Partition. Der ein oder andere kann es sich schon denken. Ich habe nach der Installation eine Neustart gemacht und das System ist gecrashed. Denn es konnte weder mit LVM2 etwas anfangen, noch /usr finden.
Man kann natürlich darüber streiten, ob das nun so sein muss oder nicht. Aber ich will es so, mein System, meine Regeln. Ich will LVM2, /usr ist eine eigene Partition.
Wieder Recherche und irgendwie habe ich es einfach nicht hinbekommen. Ich war irgendwie zu blöd, da irgendwas zu finden. Also habe ich mir das System im CHROOT genauer angesehen. Nach einer gewissen Zeit habe ich dann etwas gefunden.
Im nachhinein war es total klar. Ich musste dem System/Kernel ja sagen, dass ich /usr als eigene Partition betreibe und auch darauf hinweisen, dass ich LVM2 nutze.
Jetzt lief es:
Hier nun mein Aufbau der HDD:

Dateisystem                      Typ      Größe Benutzt Verf. Verw% Eingehängt auf
dev                              devtmpfs  4,2G       0  4,2G    0% /dev
run                              tmpfs     4,2G    799k  4,2G    1% /run
/dev/sda6                        btrfs      33G     95M   30G    1% /
/dev/mapper/vg_arch-lv_usr       btrfs      54G    2,9G   49G    6% /usr
tmpfs                            tmpfs     4,2G     13k  4,2G    1% /dev/shm
tmpfs                            tmpfs     4,2G       0  4,2G    0% /sys/fs/cgroup
/dev/sda1                        ext2      723M     75M  641M   11% /boot
/dev/mapper/vg_arch-lv_var       ext4       32G    4,2G   28G   14% /var
/dev/mapper/vg_arch-lv_root      ext4       22G     47M   21G    1% /root
/dev/mapper/vg_arch-lv_home      ext4       43G    113M   42G    1% /home
/dev/mapper/vg_arch-lv_tmp       ext4       27G    122M   26G    1% /tmp
/dev/mapper/vg_arch-lv_usr_share ext4       53G    2,6G   50G    5% /usr/share
/dev/mapper/vg_arch-lv_srv       ext4       43G    342M   42G    1% /srv
/dev/mapper/vg_arch-lv_var_log   ext4       32G    1,6G   30G    6% /var/log
/dev/mapper/vg_data-lv_smb2      ext4      2,2T    206G  2,0T   10% /smb2
/dev/mapper/vg_arch-lv_backup    xfs        89G     13G   76G   15% /backup
/dev/mapper/vg_data-lv_smb1      xfs       1,6G     36M  1,6G    3% /smb1
/dev/mapper/vg_arch-lv_var_tmp   btrfs      27G     18M   25G    1% /var/tmp
/dev/mapper/vg_arch-lv_opt       btrfs      38G    211M   36G    1% /opt
/dev/mapper/vg_arch-lv_usr_local jfs        33G    233M   32G    1% /usr/local
/dev/mapper/vg_data-lv_smb3      btrfs      11T    5,0T  5,7T   47% /smb3

Die meisten Serverdienste habe ich ohne jeglichen Probleme zum Laufen bekommen. Horde/IMP war nicht ein Problem, welches durch ARCH bekommen habe, sondern durch die Pakete selbst. Ich musste es durch pear installieren. Beim Debian gab es in den Repos Pakete. War dadurch bei Debian einfacher, aber ich habe es ja geschafft.
Nachdem ich so ungefährt 2 Wochen mit ARCH gearbeitet habe, habe ich mich auch dafür entschieden es auf den 3 PCs und den 4 Laptops zu installieren. Bei einem System hatte ich dann Probleme mit der Deutschen Lokalisierung auf der Console.
Naja, mein Fehler. Mir wurde hier im Forum super geholfen. An dieser Stelle noch mal vielen Dank für jegliche Hilfe, die ich da bekommen habe. Auch, wenn meine Fragen mal nicht so dolle waren.
Meine Hauptdistri ist nun ARCH. Ich habe aber dennoch andere Distributionen am Laufen. Mein Jumpserver läuft unter FreeBSD (komme ich super zurecht mit), Gentoo für die Spieleserver, CentOS für mein Gitlab mit SELinux, und ein virtuelles Debian, wo ich beobachten will wie es da weiter geht.

Kurzum: Ich mag Debian immer noch. Ich hoffe es zumindest auf meinem Urarltlaptop (Thinkpad T41p 32Bit Pentium M) mal wieder sinnvoll nutzen zu können. Jetzt läuft erstmal Archlinux32 auf dem Uraltlaptop.

Ich bin auf jeden Fall echt froh, dass es Archlinux gibt. :-)

Aufgrund eines Paketierungsfehlers in Versionen vor 1.6-2 erfordert eine Aktualisierung des Paketes libbloom unter Umständen einen manuellen Eingriff. Hintergrund ist, dass in älteren Versionen ein symbolischer Link nicht enthalten war, der nun ab 1.6-2  enthalten ist, was einen Dateikonflikt auslöst.

Wird die Datei

/usr/lib/libbloom.so.1

also als schon existierend angemeckert, so sollte sie gelöscht oder mittels pacman mit der --overwrite Option überschrieben werden.

Die Aktualisierung von mariadb auf 10.4.6-1 oder nachfolgende Versionen bringt die Notwendigkeit mit sich, manuell einzugreifen. Arch Linux übernimmt ein neues Ablageortesystem vom MariaDB-Projekt.

Dir Haupt-Konfigurationsdate wurde von

 /etc/mysql/my.cnf 

nach

 /etc/my.cnf 

verschoben. Die nachgelagerten Konfigurationsdateien wurden folglich analog von

 /etc/mysql/my.cnf.d/

nach

/etc/my.cnf.d

verschoben. Hat man hier Anpassungen vorgenommen, müssen die Dateien und Verzeichnisse entsprechend verschoben werden.

Instanziierte Dienste werden nicht mehr in seperaten Dateien konfiguriert, sondern in der Hauptkonfigurationsdatei.                       

Wie immer bei einer Aktualisierung bei mariadb ist die DB anschließen zu stoppen und neu zu starten.

systemctl restart mariadb.service && mariadb-upgrade -u root -p
grep.asm – Schritt 3: Reguläre Ausdrücke erkennen

Voriges Posting dieser Serie.

Okay, was ist hier los, warum dauert das so lange? Hat viele Gründe, zwei davon sind besonders ausschlaggebend.

Der erste ist RSI. Der menschliche Körper mag es wohl nicht so sehr, 8 bis 16 Stunden pro Tag Tastatur und Maus zu bedienen, tagein, tagaus, für ein paar Jahrzehnte, viel davon unter Stress – und dann noch ein bisschen was oben drauf. Eines Tages waren da also Schmerzen in den Händen und die gingen nicht mehr weg. Vorboten habe ich zumindest keine wahrgenommen. Meh. Der Heilprozess ist noch im Gange und diesen Text schreibe ich mit einem albernen Workaround im Schneckentempo, aber es ist besser als nichts. Vielleicht irgendwann später mal mehr zu diesem Thema.

Das ist natürlich auch der Grund, weshalb dieses Posting kürzer und oberflächlicher ist, als mir lieb wäre.

Der andere Grund ist schlichtweg Motivation. Ich habe dieses Projekt (teilweise) angefangen, weil die Komplexität und die Menge an Abstraktion heutiger Software ermüdend sind. In Assembler zu programmieren, führt mich ein bisschen näher an „die Maschine“ heran. Man bekommt hier noch am ehesten mit, was eigentlich passiert. (Dabei ist mir durchaus bewusst, dass es Dinge wie Register Renaming gibt und alles ist ohnehin superskalar und out-of-order, also herrscht selbst auf ASM-Ebene Lug und Trug.) Eine Regex-Engine kann aber natürlich beliebig kompliziert werden. Will ich das wirklich in ASM implementieren? Wird das nicht ein riesiges Monstrum? Genau das, was ich vermeiden wollte?

Mir war das von Anfang an klar und ich hatte einfach gehofft, dass mir unterwegs etwas Cleveres einfallen würde.

Nope.

Dann hab’ ich endlich das hier gefunden:

https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html

Lustigerweise waren Brian Kernighan und Rob Pike auf der Suche nach einer einfachen Regex-Engine und alle existierenden waren zu groß. Also schrieb Rob Pike drei sehr kurze C-Funktionen. Damit kann man zwar nicht alle regulären Ausdrücke erkennen (natürlich), aber doch eine sehr nützliche Teilmenge:

c    matches any literal character c
.    matches any single character
^    matches the beginning of the input string
$    matches the end of the input string
*    matches zero or more occurrences of the previous character

All das in diesen drei kurzen Funktionen. Das ist einfach „wow“. Oder wie Brian Kernighan schreibt: „a superb example of beautiful code“.

Faul, wie ich bin, habe ich eine ASM-Version seiner Routinen in grep.asm eingebaut.

Und damit sind wir am Ziel angekommen. grep.asm ist, von etwaigen Bugfixes abgesehen, erst einmal fertig. Der Tag blogpost-step-3 zeigt auf die Version dieses Postings.

vain

Die propietären Grafikkartentreiber der Nvidia-340xx-Serie (und allem, was damit zusammenhängt) wurden aus den Repos entfernt, da eine vernünftige Betreuung durch die Arch-Entwickler nicht mehr gewährleistet werden kann (der letzte Rechner im Besitz segnet gerade das Zeitliche).

Benutzer einer entsprechenden Hardware wird empfohlen, auf die freien Treiber (nouveau-Paket) zu wechseln.

https://wiki.archlinux.org/index.php/No … _installed

Die PKGBUILDs wurden übrigens nicht ins AUR verschoben. Wer sie dennoch braucht, muss sie sich mittels "asp"
besorgen. Das Hochladen ins AUR ist nicht verboten.

Wie im englischen Forum beschrieben, startet systemd-timesyncd nach einem Update auf systemd-242.0-1 ggf. nicht mehr.
Es muss dann ein manueller Eingriff erfolgen:

# rm -rf /var/lib/systemd/timesync /var/lib/private/systemd/timesync

Es wurde ein neues monatliches Installationsimage veröffentlicht. Dieses trägt die Bezeichnung 2019.04.01. Anders als bei den letzten Images wird ab sofort der Kernel in Version 5.0 verwendet, was für eine höhere Hardwarekompatibilität sorgen kann. Der Download ist wie immer auf der Downloadseite in verschiedenen Formaten verfügbar.

Der Download ist für neue Arch-Nutzer interessant, oder für alle, die gern ein aktuelles Installations- bzw. Live-Image von Arch haben möchten. Für bestehende Installationen ist der Download wie immer nicht nötig.

Am Ziel angekommen

28.03.2019

Hallo liebe Community,

vielleicht kurz etwas zu meiner Geschichte. Den ersten Kontakt mit Arch Linux hatte ich vor zwei Jahren, leider habe ich es geschafft das System so zu zerschießen, dass es mir nicht mehr möglich war es irgendwie wieder zu fixen. Nach einer Zeit des Distrohopings kann ich nun stolz verkünden, das Arch Linux schon seit einigen Monaten auf meinen Produktivsystemen läuft. Und ganz ehrlich ich möchte es nicht mehr missen. Kein System lief bei mir bis jetzt so problemlos und dabei mit so aktuellen Paketen. Noch dazu habe ich bei Arch Linux so viele Freiheiten wie fast nirgends (abgesehen von Gentoo und LfS). Dafür auch nochmal von mir ein großen Dank an die Arch Linux Community. Werde versuchen mich mit einzubringen und somit etwas zurückzugeben.

Auch neu hier ...

27.03.2019

... und bin seit einer Woche mit Arch Linux auf einem meiner "älteren" Schlepptops mit Arch Linux unterwegs (T61) - und was soll ich sagen:
Insgesamt bin ich angenehm überrrascht!

Zu mir
Bj 61, Geek. Bastel gerne am Gerät wink

Nach längerer Linux_Abstinenz (letzte Versuche waren mit LM Sonya, oder Sylvia wink -  und vorherigen Ubuntu-, Debian- Katastrophen und meinen bescheidenen Suse ~5.3 Kernel-Bau-Experimenten gg. Ende der 90iger, bin ich
über den ct'uplink Podcast 25.1 vom 01.12.2018 auf ArchLinux gestolpert.
Hätte nicht gedacht, dass ich mich jemals wieder an eine "hand-made" Linux_Distro heranwage, es mich sogar wieder interessiert und mit den üblichen Stolpersteinen doch relativ geschmeidig zurecht komme wink

Aktuell sind ein paar Probleme aufgetaucht und an das Advanced Dock wage ich mich noch nicht heran. Aber mit solch einer netten, hilfsbereiten und versierten Arch Community kann ja nix mehr schiefgehen wink

Nun denn Willkommen und auf ein neues Linux-Abenteuer smile
feba

---------------------------------------------------------------------------------------------------------------------------------------
T61, Intel 965PM model 8898, cpu T5750, IGMA X3100, 4GB, SSD256, , TP Advanced Dock

Das richtige Partitionierungsprogramm

Seit der jüngsten Aktualisierung erstellt das grub-Paket nicht mehr automatisch eine Konfigurationsdatei in /boot/grub. Auch das Verzeichnis selbst fällt durch diese Änderung weg.


Siehe auch hier.

Dank an drcux, dem dies aufgefallen war.

Sehr cool !
Der neue lts-kernel 4.19.xx zeigt mir jetzt 0 Fehler nach dem Booten auf meinem System.
(journalctl -xb -p err)

Moin

10.09.2018

Hallo
ich bin der Aziz, komme ursprünglich aus Marokko und arbeite jetzt in Deutschland.
ich habe mich dazu entschieden mich in archlinux einzuarbeiten, weil ich gerne technisch rumexperimentiere, mehr über Linux verstehen möchte und gern die volle Kontrolle über mein System habe.
Außerdem finde ich pacman und das rolling release konzept sehr interessant. Nebenbei bemerkt ist auch das wiki sehr gelungen.

Ich hoffe ich werde noch viel Freude an Archlinux haben.

PS: Deutsch ist nicht meine Muttersprache und ich arbeite erst seit zwei Jahren in Deutschland, also seid bitte verständnisvoll für sprachliche Fehler ^^.