Fryboyter

Howl Editor

Regelmäßig sehe ich mir auf archlinux.org die Liste der kürzlich aktualisierten Pakete an. Ab und zu stoße ich hierbei auf Programme die ich bisher noch nicht kannte. Heute habe ich den Editor Howl entdeckt.

Howl ist ein Editor der für die Benutzung mittels Tastatur ausgelegt ist und der mittels Lua bzw. Moonscript anpassbar ist. Eigentlich bin ich aktuell mit den von mir verwendeten Editoren zufrieden. Mit Howl habe ich bisher nur etwas herumgespielt und somit auch nur die Spitze des Eisbergs angekratzt. Aber ich muss sagen, ich habe mich mit Howl gleich daheim gefühlt. Was vermutlich auch daran liegt, dass viele Shortcuts etwas eingängiger sind als bei anderen Editoren.

Jemand aus dem Entwicklerteam, hat auf Youtube ein Einführungsvideo erstellt, das ganz gut zeigt, was man alles mit Howl anstellen kann.

Howl wird im aktuellen Zustand bestimmt nicht vim in den Boden stampfen, aber ich finde dass er sich nicht schlecht schlägt.

Linux | OSBN

Windows PowerShell für Linux und OS X veröffentlicht

Unter Windows setze ich die PowerShell recht gerne ein, da sich damit einiges mehr bzw. einfacher machen lässt als mit dem normalen Kommandozeilenprogramm cmd.exe. Microsoft hat den Sourcecode der Powershell nun unter der MIT-Lizenz auf Github veröffentlicht. Das ganze ist aktuell als Alpha-Version gekennzeichnet.

Neben dem Sourcecode werden neben den Paketen für Windows auch Pakete für Ubuntu, CentOS und OS X angeboten. Wer will, kann somit die PowerShell auch abseits von Windows nutzen. Ich selbst werde unter Linux aber bei der ZSH bleiben. Für Arch Linux gibt es übrigens auch schon ein Paket im AUR. Allerdings scheint hier die Installation noch nicht ganz zu funktionieren.

Linux | OSBN

KB3133977 auf einem Dualbootsystem installieren

Heute habe ich seit einiger Zeit mal wieder Windows gebootet. Logischerweise haben sich hier einige Updates angesammelt, die ich lieber gleich mal installiert habe. Bis auf KB3133977 hat das auch geklappt. Nur dieses verschissene Update hat sich mit Händen und Füßen geweigert. Das Update braucht einen Neustart. Und hier gab es jedes mal den Fehler 80004005. Dieser bedeutet grob gesagt, es ist ein unbekannter Fehler beim Windows-Update passiert. Wer hätte das gedacht…

Nach einigem hin und her habe ich das Problem gefunden. Ich habe auf dem betreffenden Rechner sowohl Arch Linux als auch Windows 7 HP installiert (jeweils auf einer eigenen SSD). Gestartet werden beide mittels syslinux. Und genau das mag das Update nicht. Es ist scheinbar mal wieder eines dieser Updates der Marke “du darfst keine anderen Götter / Betriebssysteme haben neben mir”. Als ich Windows direkt über UEFI gebootet hatte (sowohl zum Einspielen des Updates als auch beim benötigten Neustart) wurde das Update anstandslos installiert. Warum einfach, wenn es auch kompliziert geht?

Allgemein

Keine Maus und Tastatur unter Windows wenn vorher Linux gestartet wurde

Hier mal wieder ein Problem aus dem Bereich “Probleme die der Mensch nicht braucht”.

Auf meinem Hauptrechner ist neben Arch Linux auch Windows 7 installiert das nur für Spiele gedacht ist. Daher wird es auch nicht so oft gestartet. In der Regel boote ich den Rechner erst mit Arch Linux und bei Bedarf mache ich einen Neustart und boote Windows. Hier habe ich nun jedes mal das Problem dass am Anmeldebildschirm weder Maus noch Tastatur funktionieren. Bemühe ich dann die Reset-Taste des Rechners und lasse Windows normal starten funktioniert die Maus als auch die Tastatur. Boote ich Windows gleich als erstes, ist auch alles in Butter. Und genau an dieser Stelle komme ich nicht mehr mit. Ich kann mir beim besten Willen nicht vorstellen, warum Arch Linux hier die Ursache sein soll.

Ein Bekannter, der Computer gerade mal nutzen kann, wollte gestern mal wieder lustig sein und hat mich gefragt, ob ich denn alle Treiber installiert hätte. Gestern hätte ich die Frage noch mit einem Ja beantwortet. Heute eher mit einem Jein. Denn genau mit dieser Frage hat er mich auf die richtige Spur gebracht. Für mein Motherboard gibt es vom Hersteller extra USB-3-Treiber. Da nach der Installation von Windows alles USB-Geräte funktioniert haben, habe ich diese scheinbar nicht extra installiert. Das habe ich gestern mal nachgeholt. Und was soll ich sagen? Jetzt funktioniert auch meine Maus und Tastatur unter Windows wenn ich vorher Arch Linux gestartet hatte.

Was aber schlussendlich das Problem mit den Treibern die Windows mitbringt auslöst, kann ich aber immer noch nicht sagen. Das wird vermutlich auch weiterhin ein Geheimnis bleiben. Ich hake das jetzt mal als “Problem gelöst, Ursache unbekannt” ab.

Allgemein

Merkitys - Live-Distribution

Urlaubszeit ist Bastelzeit. Und da ich gerade Urlaub habe bastle ich mir gerade meine eigene Live-Distribution zusammen. Als Basis nehme ich Arch Linux. Hier mal eine Zusammenfassung, was ich bisher gemacht habe.

Der komplette Vorgang erfolgt, wie im Arch-Wiki angegeben, komplett mit Root-Rechten.

Um sich eine eigene Live-Distribution zu erstellen benötigt man das Paket archiso. Dieses habe ich mir mittels pacman -S archiso kurzerhand installiert. Als nächstes habe ich mir ein Arbeitsverzeichnis erstellt (mkdir /home/benutzer/archlive). Hierbei ist zu beachten, dass der ganze Spass einiges an Speicher benötigt. Daher habe ich das Verzeichnis auch kurzerhand im Homeverzeichnis meines normalen Benutzerkontos erstellt. Beim ersten Versuch hatte ich das Verzeichnis im Verzeichnis von root erstellt und mir beim Anlegen des Isos die komplette Partition geflutet was das Betriebssystem gar nicht lustig fand…

Nun habe ich mittels cp -r /usr/share/archiso/configs/PROFILE/ /home/benutzer/archlive alle Dateien und Verzeichnisse in das eben angelegte Arbeitsverzeichnis kopiert. Jetzt kann der Spass beginnen.

Im Unterverzeichnis releng im Arbeitsverzeichnis findet man eine Datei namens build.sh. Mit dieser wird die Iso-Datei erstellt. Für meine Bedürfnisse waren allerdings Änderungen nötig. Folgende Dinge habe ich daher kurzerhand geändert.

  • Bei iso_name= habe ich archlinux gegen Merkitys ausgetauscht. Somit wird schlussendlich die Datei Merkitys-$Datum.iso erzeugt. Anstelle von $Datum wird das jeweils aktuelle Datum angezeigt an dem die Datei erstellt wurde. Also z. B. Merkitys-2014-12-03.iso

  • Ein ganzes Stück weiter unten gibt es die Zeile “mkarchiso ${verbose} -w “${work_dir}” -D “${install_dir}” -L “${iso_label}” -o “${out_dir}” iso “${iso_name}-${iso_version}-dual.iso”“. Hier habe ich das -dual entfernt, da ich eine reine 64Bit-Version haben möchte.

  • Fast ganz am Ende der Datei finden sich drei Zeilen mit folgendem Inhalt: “for arch in i686 x86_64; do”. Damit auch wirklich nur die 64-Bit-Version erstellt wird habe ich kurzerhand einfach das i686 entfernt und die Datei abgespeichert.

Im gleichen Verzeichnis findet man die Dateien packages.x86_64, packages.i686 und packages.both. In der ersten Datei werden die Pakete eingetragen die für 64 Bit gelten. In der zweiten die für 32 Bit und in der letzten für beide Architekturen. In der für 64 Bit sollten einige wenige Pakete genannt sein. Die für 32 Bit sollte leer sein und die für beide sollte den meisten Inhalt aufweisen. Da ich nur 64 Bit will habe ich daher einfach den Inhalt der Datei packages.both ausgeschnitten und unter den Inhalt der Datei packages.x86_64 eingefügt, so dass nun auch packages.both komplett leer ist. Die nun in der Datei packages.x86_64 genannten Pakete bzw. Paketgruppen sind quasi nur die Minimalinstallation. Hier kann man sich nach Lust und Laune austoben. Pro Zeile darf aber nur ein Paket bzw. eine Paketgruppe genannt werden. Fürs erste habe ich folgende Pakete/Gruppen hinzugefügt: lxde, meld, nano, xf86-video-ati, xf86-video-intel, xf86-video-nouveau, xf86-video-vesa, xorg-apps, xorg-server und xorg-server-utils. Auf eventuelle nötige Abhängigkeiten muss man hierbei nicht achten. Diese werden bei Bedarf automatisch installiert.

Da ich ohne eingreifen zu müssen automatisch lxdm und damit auch lxde ausführen möchte habe ich anschließend im Verzeichnis ~/archlive/releng/airootfs/etc/systemd/system folgenden Befehl ausgeführt: ln -s /usr/lib/systemd/system/lxdm.service display-manager.service. Das sollte eigentlich dem System mitteilen, dass lxdm automatisch gestartet wird. Erstellt man an dieser Stelle jetzt die Iso-Datei und bootet davon, wir man merken, dass es aber nicht klappt. Schuld ist hier die Datei customize_airootfs.sh welche man unter releng/airootfs/root findet. In dieser findet man die Zeile systemctl set-default multi-user.target. Und genau die verhindert dass lxdm automatisch gestartet wird. Quasi falscher Runlevel. Von daher habe ich das multi-user.target gegen graphical.target ausgetauscht. Da ich die Datei schon offen habe habe ich die Zeile “sed -i ’s/#(us_US.UTF-8)/\1/’ /etc/locale.gen\” bei der Gelegenheit gleich auf “sed -i ’s/#(de_DE.UTF-8)/\1/’ /etc/locale.gen” geändert.

Um zu verhindern, dass im Bootloader auch die Einträge für die 32-Bit-Version auftauchen habe ich weiterhin unter releng/syslinux alle Dateien mit 32 im Dateinamen (z. B. archiso_sys32.cfg) gelöscht. Abschließend habe ich nun in der Konsole das bereits erwähnte Script build.sh mittels ./build.sh -v ausgeführt. Der Parameter -v sorgt dafür dass der Vorgang etwas gesprächiger ist und man eventuelle Fehlerquellen bemerkt. Wenn alles geklappt hat, sollte man nun unter releng/out/ die Iso-Datei finden. Nach ersten Tests unter VirtualBox dürfte eigentlich alles geklappt haben. Lxdm sollte automatisch starten und man sollte sich problemlos an Lxde anmelden können. Für den bisher vorhandenen Nutzer ist aktuell übrigens kein Passwort gesetzt. Die wenigen vorhandenen Programme sollten eigentlich auch alle starten. Der Rohbau steht sozusagen.

Als nächstes werde ich wohl die Paketliste sowie das Startmenü von Lxde erweitern. Anregungen nehme ich gerne an.

Wer sich diese noch sehr eingeschränkte Live-Distribution einmal ansehen will, kann Sie unter https://spideroak.com/browse/share/datengrab/Merkitys herunterladen. Die Prüfsummen sind wie folgt.

MD5: e08e6116dff6173c906a2b91714a4992 SHA256: 4dade41774bb1faaac12decac3796b2fd3299a5fb22314e5305846acd548db18

Vermutlich werden jetzt einige sich fragen wieso ich nicht einfach eine bereits fertige Live-Distribution wie die SystemRescueCD nehme. Im Grunde genommen will ich zwei Dinge damit erreichen. Zum einen will ich archiso bzw. das Remastern einer bereits vorhandenen Arch-Live-Distribution besser verstehen. Und zum anderen will ich testen inwiefern bei einer solchen Iso-Datei Delta-Updates (mit xdelta3 erstellt) Sinn machen.

Linux | OSBN