Skip to content

Zurück auf liquidprompt ...

linux Nachdem ich jetzt rund 1,5 Jahre Powerline genutzt habe, bin ich mit der Neuinstallation zurück auf Liquidprompt gewechselt.

Es gibt drei Gründe dafür: Zum Einen ist Liquidprompt deutlich schneller als Powerline und das merke ich sofort. Zum Anderen merkt man Powerline an, dass es "eigentlich" für die ZSH gemacht wurde und die Bash, na ja, rudimentärer unterstützt wird, weil sie vermutlich deutlich weniger Möglichkeiten für den Prompt bietet als ZSH. Weiterhin ist die Konfiguration deutlich einfacher ...

Wermutstropfen ist, dass das Projekt Liquidprompt nur sehr langsam bis gar nicht weiterentwickelt wird. Die ältesten nicht gelösten "Issues" sind knapp sieben Jahre alt.

Aber es tut seinen Job und das sogar sehr schnell und gut.

Fedora 30 ...

fedora Trotz der wirklich guten Erfahrungen, die ich mit dem Update von Fedora gemacht habe, habe ich mit der Version 30 - "aus Gründen" - eine komplette Neuinstallation gemacht.

Neben der "Datenhygiene" war dieses Mal der Grund, dass ich das Desktop Environment von KDE nach XFCE gewechselt habe.

Einer der Hauptgründe ist, dass ich kaum KDE-eigene Programme genutzt habe und gefühlt jede Tastenkombination mit einer Funktion belegt ist. XFCE ist deutlich schlanker, was die Menge der mit installierten Software betrifft und der weitgehende Verzicht auf Desktop Effekte macht die Arbeit gefühlt schneller.

Ich will nicht verhehlen, dass ich verärgert darüber bin, dass sich bei Borgbackup ein alter Fehler eingeschlichen hat, interessanterweise hat die Installation via pip in einem "Virtual Environment" auch nicht funktioniert. Wenn ich wieder zu Hause bin, werde ich einen Bugreport erstellen.

Am Rande bemerkt, bei Linux ist so etwas relativ leicht machbar.

devLUG ...

linux

Diesen Beitrag möchte ich gerne einmal nutzen, um über die devLUG zu informieren.

Die devLUG ist eine deutschsprachige "virtuelle" Linux User Group mit realen Menschen (deshalb ist das "virtuell" in Anführungszeichen).

Das Ziel der devLUG ist die Erstellung, Verbreitung und Förderung von Free/Libre Open Source Software (kurz FLOSS), insbesondere aber nicht ausschliesslich im Zusammenhang mit Linux­basierenden Betriebssystemen und Distributionen.

Um dieses Ziel zu erreichen, bedient sich der Verein moderner Kommunikationsmittel, die auf Verbindungen über das Internet basieren.

Wir sind in der devLUG an einen Punkt gekommen, ernsthaft über eine Vereinsgründung nachzudenken. Ohne die Gründung kommt es immer wieder zu Situationen in denen es aus verschiedenen auch rechtlichen Gründen nicht weitergeht.

Selbstverständlich bringt die Gründung eines - vielleicht sogar gemeinnützigen - eingetragenen Vereins einige Nachteile mit sich, jedoch denken wir, dass die Vorteile für die devLUG überwiegen.

Die "Aktiven" unter uns haben sich schon mal Gedanken gemacht, was sie in der devLUG sehen und was das Ziel sein soll.

Aktivitäten rund um Linux und FLOSS (Free/Libre Open Source Software), Nutzung von digitalen Möglichkeiten zur Kommunikation, Aktivitäten können Workshops, Anleitungen, Hilfe (zur Selbsthilfe), Podcasts, ... sein. Ziel ist es von und miteinander zu lernen, Linux User Groups im deutschsprachigem Raum miteinander zu vernetzen, Synergien zu nutzen, dezentrale Strukturen aufzubauen.

Wir wollen versuchen, uns kleine Ziele zu setzen welche auf virtuellen Stammtischen besprochen werden können. Dies können kleine online Workshops sein oder vieles andere mehr.

Wenn jemand Interesse an der Gründung eines Vereins für die virtuelle Linux User Group hat, kann sich einfach hier melden oder uns im IRC-Kanal #devlug aufFreenode (hinter dem Link verbirgt sich ein Webchat) vorbeischauen.

Einen Stammtisch gibt es auf Freenode in dem angegebenen Kanal, jeweils um 20:30 Uhr und alle zwei Wochen im Wechsel Dienstag / Donnerstag. Die nächsten Termine sind: 30. April, 16. Mai, 28. Mai, 13. Juni. Generell gibt es aber immer jemanden, der im Freenode-Kanal #devlug ansprechbar ist. Wir freuen uns auf Euren Besuch.

Ein Friendica-Forum wartet ebenfalls auf Euren Besuch.

Mein Arbeitsplatz ...

linux

Systemadministrator (aktueller "Jobtitel Senior System Engineer Linux/Unix") bin ich schon relativ lange und so lange ich diesen Job mache, so lange schraube ich und verbessere mein Arbeitssetup.

Das berufliche "Virtual Desktop"-Betriebssystem ist leider Windows, aktuell in der Version 10, via Thin Client, wobei ich bis auf Mailclient und Webbrowser (via SSL Interception Proxy) nur Zugriff auf die Linux- und Solaris-Infrastruktur benötige.

Dafür habe ich sehr vieles ausprobiert. Wir haben einen Remote Desktop mit NoMachine, den ich lange genutzt habe - vor allem, da ich ihn auch über beide Monitore strecken kann - aber so richtig warm geworden bin ich damit nicht. In einem anderen Kontext nutzen wir xrdp und auch X2Go habe ich getestet. Auf der Gegenseite läuft jeweils ein Red Hat Enterprise Linux 7 mit KDE 4 als Desktop (privat bin ich auf Fedora 29 mit KDE Plasma).

Nach allem Hin und Her bin ich mittlerweile bei PuTTY und - falls ich wirklich einmal (sehr selten) Grafik brauche - XMing, das reicht für mich völlig aus.

In PuTTY gibt es vier Settings, die ich jedem empfehlen möchte, der ernsthaft damit arbeitet.

  1. Unter Window / Behaviour habe ich "Full screen und Alt-Enter" gesetzt, damit lässt sich PuTTY in einem rahmenlosen Vollbild-Fenster betreiben.
  2. Unter Window / Selection ist die "Action of mouse buttons" auf "xterm (Right extends, Middle pastes)" gesetzt. Ihr wisst schon ... alter Sack ... Schwierigkeiten umzugewöhnen ... besser es funktioniert so wie auf jedem gewohnten Linux Desktop.
  3. Ebenfalls unter Windows / Selection gibt es den Punkt "Paste to clipboard in RTF as well as plain text" - gerade in Verbindung mit Outlook als Zwangsclient hilft das sehr, formatierte Dinge (inklusive Farben) aus der Shell zu pasten.
  4. Unter Connection / SSH / X11 muss natürlich "Enable X11 forwarding" eingeschaltet sein, sonst wird das nichts mit XMing.

Apropos XMing, das wird über einen Shortcut mit folgenden Parametern gestartet: Xming.exe :0 -clipboard -multiwindow -xkblayout ch -xkbvariant de

Was das ganze Setup aber zu meiner Administrationslösung macht, ist tmux. Meine Konfiguration findet Ihr am Ende das Artikels. Vielleicht erläutere ich sie einmal in einem weiteren Blogposting.

Bis vor kurzem habe ich immer ClusterSSH benutzt, wenn ich auf mehreren Systemen gleiche Befehle ausführen musste. Das hat auch mit XMing super funktioniert, bringt aber eine Inflation an Fenstern mit sich.

Daher bin ich richtig froh, dass ich tmux-xpanes entdeckt habe. Das Tools ist mit einer Fullscreen Terminal-Session via tmux einfach unschlagbar.

Meine zwei Monitore sind jetzt wie folgt aufgeteilt. Der linke Monitor trägt den ganzen Windows-Kram und der rechte eine PuTTY-Session im Fullscreen mit tmux. Das ist für mich perfekt.

# .tmux.conf
# Dirk Deimeke

set -s escape-time 1
set -g base-index 1
setw -g pane-base-index 1

bind r source-file ~/.tmux.conf \; display "Reloaded!"
bind S set-window-option synchronize-panes

bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

bind -r C-h select-window -t :-
bind -r C-l select-window -t :+

bind -r H resize-pane -L
bind -r J resize-pane -D
bind -r K resize-pane -U
bind -r L resize-pane -R

set -g default-terminal "xterm-256color"

set -g status-fg black

setw -g window-status-fg black
setw -g window-status-bg default
setw -g window-status-attr dim

setw -g window-status-current-fg white
setw -g window-status-current-bg red
setw -g window-status-current-attr bright

set -g pane-border-fg green
set -g pane-border-bg black

set -g pane-active-border-fg white
set -g pane-active-border-bg yellow

set -g message-fg white
set -g message-bg black
set -g message-attr bright

#### COLOUR (Solarized 256)

# default statusbar colors
set-option -g status-bg colour235 #base02
set-option -g status-fg colour136 #yellow
set-option -g status-attr default

# default window title colors
set-window-option -g window-status-fg colour244 #base0
set-window-option -g window-status-bg default
#set-window-option -g window-status-attr dim

# active window title colors
set-window-option -g window-status-current-fg colour166 #orange
set-window-option -g window-status-current-bg default
#set-window-option -g window-status-current-attr bright

# pane border
set-option -g pane-border-fg colour235 #base02
set-option -g pane-active-border-fg colour240 #base01

# message text
set-option -g message-bg colour235 #base02
set-option -g message-fg colour166 #orange

# pane number display
set-option -g display-panes-active-colour colour33 #blue
set-option -g display-panes-colour colour166 #orange

# clock
set-window-option -g clock-mode-colour colour64 #green
 

Docker-Hilfe ist hilfreich ...

docker Prinzipiell finde ich es ja super, dass die Docker-Kommandos eine eingebaute Hilfsfunktion haben, aber manchmal ist die Hilfe schon anders als erwartet.

Ich war mir nicht sicher, ob ich zuerst den Quell- oder Zieltag angeben muss beim Docker-Tag-Kommando:

$ docker tag --help

Usage:  docker tag IMAGE[:TAG] IMAGE[:TAG]

Tag an image into a repository

Options:
      --help   Print usage

Hotel-WLAN ...

linux Am vergangenen Wochenende durfte ich einmal mehr in einem Hotel zu Gast sein, das ein kaputt konfiguriertes WLAN hatte. Manchmal frage ich, was die Dienstleister befürchten, wenn sie den Zugang so kastrieren.

Für mich ist elementar, dass ich via SSH auf meine Server zugreifen kann, aber Port 22 ausgehend war geblockt. Das habe ich relativ schnell in den Griff bekommen, in dem ich via "Remote Console" auf einem meiner Server sslh installiert habe. sslh nimmt Verbindungen auf Port 443 (https) an und entscheidet mit dem Handshake an welchen Dienst die Verbindung "übergeben wird". Das klappt problemlos und ziemlich gut, wenn der WLAN-Administrator nicht auf Protokollebene blockt.

Zugriff geht dann via:

ssh -p 443 user@sslh-server.example.net


Die Weiterverbindung auf andere Server lässt sich dann mittels folgendem Befehl realisieren (das geht auch transparent mit der unten aufgeführten Lösung):

ssh -o ProxyJump=user@sslh-server.example.net user@ziel.example.com


Für reine SSH-Verbindungen ist das prima, aber es gibt ja zum einen noch andere Dienste (unter anderem Usenet, Protokoll nntp, Port 119), die ich auch noch nutzen möchte.

Da kommt dann das Tool sshuttle zum Einsatz. sshuttle benutzt SSH, um darüber alle tcp-Verbindungen plus DNS mittels Paketfilterregeln weiter zu leiten. Um die lokalen Regeln anzupassen wird sudo-Zugriff auf den root-Account benötigt.

sshuttle --dns --remote=user@sslh-server.example.net:443 0/0


Für mich funktioniert das und es macht "falsch" konfigurierte Netzwerke benutzbar.

Powerline ...

linux Ich habe jetzt einmal meinen Prompt von Liquid Prompt auf Powerline umgestellt, weil es damit ein wenig konsistenter ist, da sowohl die Shell wie auch Vim und tmux unterstützt werden.

Bei Fedora 27 ist Powerline direkt dabei, bei CentOS muss man Powerline "von Hand" installieren, das Verfahren wird auch bei anderen Distributionen funktionieren.

Fedora 27:
dnf install powerline tmux-powerline vim-powerline
systemctl enable powerline
systemctl start powerline


CentOS 7:
yum install python-pip
pip install powerline-status

cd /usr/share/fonts
curl -LO https://github.com/powerline/powerline/raw/develop/font/PowerlineSymbols.otf
fc-cache -vf /usr/share/fonts/

cd /etc/fonts/conf.d/
curl -LO https://github.com/powerline/powerline/raw/develop/font/10-powerline-symbols.conf


.bashrc
export POWERLINE_BASH_CONTINUATION=1
export POWERLINE_BASH_SELECT=1

# Fedora 27:
source /usr/share/powerline/bash/powerline.sh

# CentOS 7:
source /usr/lib/python2.7/site-packages/powerline/bindings/bash/powerline.sh


.vimrc
# Nur CentOS 7:
set rtp+=/usr/lib/python2.7/site-packages/powerline/bindings/vim/

# Fedora 27 und CentOS 7:
set laststatus=2


.tmux.conf
# Fedora 27:
source /usr/share/tmux/powerline.conf

# CentOS 7:
source /usr/lib/python2.7/site-packages/powerline/bindings/tmux/powerline.conf

while true ...

linux Neben vielen anderen Pluspunkten ist die Shell etwas, was ich an Linux besonders mag.

Bis vor kurzem habe ich meine LaTeX-Präsentationen und andere Dokumente mittels Makefile und einer Endlos-Schleife entwickelt. Dokumentbetrachter wie beispielsweise Okular oder Evince (Adobe Reader kann es nicht) erlauben es, dass eine gerade angeschaute Datei verändert werden darf und zeigen die Veränderungen auch direkt an.

Dazu benutze ich ein (nahezu) generisches Makefile (make clean löscht beispielsweise alle Temporärdateien):
.PHONY: clean
.DEFAULT_GOAL := lessons-learned.pdf

clean:
        find . \( -name '*.dvi' -o -name '*.aeb' -o -name '*.aux' -o -name '*.idx' -o -name '*.ilg' -o -name '*.ind' -o -name '*.ivz' -o -name '*.ivz.xml' -o -name '*.log' -o -name '*.pic.xml' -o -name '*.toc' -o -name '*.nav' -o -name '*.out' -o -name '*.snm' -o -name '*.vrb' -o -name '*~' -o -name '*.pdfpc' -o -name '*.fls' -o -name '*.fdb_latexmk' -o -name '*.xdv' \) -delete

lessons-learned.pdf:    *.tex *.png # *.jpg
        xelatex lessons-learned
        xelatex lessons-learned
        xelatex lessons-learned


Und der Rest wird durch eine Endlossschleife erledigt:
while : # oder while true
do
  make -q || make
  date
  sleep 5
done


Allerdings hat sich dieses Verfahren erledigt, nachdem ich bei Sujeevan von latexmk gelesen habe.

Seit dem reicht ein:
latexmk -pvc -xelatex lessons-learned.tex
make clean

Supportzeiträume ...

linux Weil ich ab und zu mal danach gefragt werde, habe ich einmal die Supportzeiträume gängiger paketbasierter Linuxdistributionen zusammengesucht.

Kritik und Korrekturen sind ausdrücklich erwünscht.

Bei Korrekturen wäre ein offizieller Link sehr hilfreich

Eingeschränkter Support:

Eingeschränkter Support bedeutet insbesondere, dass nicht alle Pakete unterstützt werden.

Bei Debian LTS sind nicht alle Pakete enthalten. Bei Red Hat Enterprise Linux wird eine ELP (Extended Life Phase) Lizenz benötigt, um weiteren eingeschränkten Support zu bekommen, SUSE erfordert ein Extended Support Package. Bei Debian und OpenSUSE wird der langfristige Support über ein separates Team gewährleistet und nicht vom Securityteam der jeweiligen Distribution.

Überblick:




















Version: Release: Support: Limited Support:
Debian 7, Wheezy (oldstable) 04.05.2013 24.04.2016 05.2018
Debian 8, Jessie (stable) 25.04.2015 ca 04.2018 05.2020
Ubuntu 12.04 LTS, Precise Pangolin 26.04.2012 26.04.2017 ESM
Ubuntu 14.04 LTS, Trusty Tahr 17.04.2014 04.2019
Ubuntu 16.04 LTS, Xenial Xerus 21.04.2016 04.2021
Ubuntu 16.10, Yakkety Yak 13.10.2016 04.2017
CentOS 6 10.07.2011 30.11.2020
CentOS 7 07.07.2014 30.06.2024
Red Hat Enterprise Linux 5, Tikanga 14.03.2007 31.03.2017 31.03.2020
Red Hat Enterprise Linux 6, Tikanga 10.11.2010 30.11.2020 30.11.2023
Red Hat Enterprise Linux 7, Tikanga 10.06.2014 30.06.2024 30.06.2027
openSUSE Leap 42.1 04.11.2015 05.2017
openSUSE Leap 42.2 16.11.2016 ca 05.2018
SUSE Linux Enterprise Server 11 23.03.2009 31.03.2019 31.03.2022
SUSE Linux Enterprise Server 12 27.10.2014 31.10.2027 31.10.2027
Fedora 24 21.06.2016
Fedora 25 22.11.2016


Standard-Support-Zeiträume:

Debian supported bis "next stable + 1 Jahr", LTS bis fünf Jahre nach Erscheinen (Releasezyklus "fertig, wenn es fertig ist").

Ubuntu supported bis neun Monate nach Erscheinen, LTS fünf Jahre nach Erscheinen. Release alle sechs Monate, LTS-Versionen alle zwei Jahre. Seit neuestem bietet Ubuntu eine Extended Security Maintenance für LTS-Versionen (Link in der Tabelle oben), die käuflich erworben werden kann. Danke Mario!

CentOS bis zehn Jahre nach Erscheinen des korrespondierendes RHEL Releases.

RHEL bis zehn Jahre nach Erscheinen, ELP bis 13 Jahre nach Erscheinen.

openSUSE, Major Release soll mindestens 36 Monate unterstützt werden, Minor-Releases bis 18 Monate nach Erscheinen.

SLES analog RHEL.

Fedora, Support bis zum Erscheinen des zweiten Nachfolgreleases plus ein Monat, keinen Langzeitsupport, neue Releases alle sechs Monate.

Neues Notebook ...

gedanken Nicht zuletzt, weil die VGA-Schnittstelle insbesondere auf Veranstaltungen ausstirbt und mein Notebook doch ziemlich "in die Jahre" gekommen ist, habe ich mich auf die Suche nach etwas Neuem gemacht und festgestellt, dass das gar nicht so einfach ist.

Dabei dachte ich das meine Anforderungen nicht so wahnsinnig hoch sind.
  • Weniger als zwei Kilo
  • 12" bis maximal 14" (kleiner ist besser)
  • Full HD Auflösung (mehr ist besser)
  • HDMI (gerne auch mit Adapter)
  • 16 GB RAM (zur Not auch 8 GB)
  • 256 GB SSD (mehr ist besser)
  • Dockingstation (!) oder Portreplikator
  • Möglichkeit, Netzwerk via Kabel zu verwenden (würde auch mit Adapter gehen, so häufig brauche ich das ausserhalb der Dockingstation nicht, eigentlich nur bei Vorträgen)
  • Englisches oder Schweizerdeutsches Tastaturlayout
  • kein optisches Laufwerk nötig
  • Muss mit Linux laufen, kein Windows nötig
  • Preisobergrenze 2000 CHF, es darf aber auch weniger sein


Für mich spannend ist, dass gerade das "Musskriterium" Dockingstation (oder Portreplikator) die Auswahl auf ein Minimum reduziert hat.

Mit dem Dell XPS 13 Developer Edition (wird mit Ubuntu ausgeliefert) hatte ich gehofft, fündig geworden zu sein. Der Support hat leider auf meine Anfragen nicht geantwortet, aber dankenswerter Weise hat mir ein lieber Bekannter einen Kontakt vermittelt, bei dem ich alle Fragen loswerden konnte.

Linux unterstützt leider die Dockingstation nicht und nach Erfahrung des Kontaktes - hier noch einmal in aller Form DANKE! - ist die HiDPI-Unterstützung bei Linux noch (sagen wir einmal) ausbaufähig.

Für mobile E-Mail und vieles andere reicht sicher mein Tablet inklusive Tastatur. Um "richtig" arbeiten zu können, braucht es aber etwas mehr. Gerade die Arbeiten an der vierten Auflage unseres Buchs (geplanter Erscheinungstermin viertes Quartal 2016, um der Frage vorzubeugen) möchte ich nicht mit dem Tablet erledigen.

Tatsächlich sind nach dem Reinfall nur drei Hersteller übrig geblieben. Wobei das so nicht richtig ist, es sind zwei plus ein Hersteller. Lenovo (ein Thinkpad, so wie immer), Dell (Latitude, warum nicht mal was anderes?) und Apple (leider - oh - ohne Dockingstation). Interessant ist, dass Apples Notebook günstiger sind als die von Lenovo im gleichen Leistungssegment.

Als alter Sack hätte ich auch gerne etwas wertiges und nicht unbedingt ein Gerät, das komplett aus Plastik besteht.

Ich habe mich jetzt für ein Dell Latitude E7450 entschieden. Ausschlaggebend war zum Einen, dass es komplett durch Linux unterstützt wird (Chipsatz ist Broadwell und nicht Skylake) und zum Anderen, dass ich es durch Lösen von zwei Schrauben erweitern kann.

Eckdaten:
  • Core i7 Prozessor
  • 8 GB RAM (werde noch einmal 8 GB separat bestellen)
  • 256 GB SSD
  • Gigabit Netzwerkschnittstelle
  • HDMI
  • E-Dock
  • 1,5 Kilogramm
  • 3 Jahre Vor-Ort-Support


Neben dem, dass Dell anscheinend Platz machen möchte für die nächste Generation scheint es die Geräte bereits am Lager zu haben. Konfigurationsänderungen speziell dieses Modells waren nur in sehr geringem Umfang möglich (ich benötige aber auch nichts anderes), gibt es reichlich Rabatte.

  • Kostenloser Versand
  • 35% Rabatt
  • Sie bekommen eine Docking-Station für den halben Preis ausgewählten Dell Latitude
  • ProSupport Plus zum Preis von ProSupport


Über die Linux Foundation hätte ich 10% Rabatt auf Hardware und 20% Rabatt auf Peripherie bekommen, aber das war gar nicht nötig.

Windows mit Linux-Kernel?

linux Mit der letzten Ankündigung bin ich tatsächlich der Meinung, dass wir den Beginn der Umstellung von Windows auf einen Linuxkernel sehen. Es mehren sich die Zeichen, dass die Integration von Windows und Linux - durch Microsoft getrieben - immer stärker wird.



Dem vorangegangen sind eine Reihe von anderen Meldungen.

Windows Containers mit Docker.

Der Datenbankserver MS SQL wird auf Linux portiert.

OpenSSH wird in Windows Server 2016 enthalten sein.

Nebenbei: Wer es schafft das Takswarrior-Kommando "task color" im Linux-Subsystem von Windows 10 zu zeigen, bekommt ein Taskwarrior-T-Shirt und einen Sticker (Twitter) ;-)

openSUSE Leap 42.1 ...

linux Da kann man mal sehen, wie viel Zeit es braucht bis ein Artikel fertig wird ...

Wer einen Distributionstest sucht, sollte meiner Ansicht nach lieber bei Pro-Linux oder Michael Kofler nachlesen.

Meine Anmerkung ist eher "philosophischer Natur" ;-)

Zum Einen finde ich es klasse, dass sich bei OpenSUSE endlich wieder etwas getan hat. Tot gesagte leben bekanntlicherweise länger. SUSE war "meine Einstiegsdroge" in die Linuxwelt und ich hätte es sehr schade gefunden, wenn diese Distribution einfach sang- und klanglos verschwunden wäre.

Zum Anderen gefällt mir das Konzept sehr (keine Angst, ich denke derzeit nicht darüber nach, zu wechseln). Es bietet eine sehr gute Alternative zu bestehenden Distributionen, die sich (bis jetzt) bezogen auf Softwareversionen ganz grob in drei Lager einteilen liessen:
  1. Abgehangen (ich möchte nicht veraltet sagen, weil es nicht passt), stabile Software, die lange unterstützt wird. Vertreter dieser Gattung finden sich besonders bei den Server-Systemen, seltener auf dem Desktop.
    • CentOS
    • Debian
    • Ubuntu LTS
  2. Schnell drehend, relativ viele Updates, aktuelle Software, kurze Support-Zeiträume. Typische Verwendung als Desktopsystem für (ambitionierte) Endbenutzer.
    • Fedora
    • Ubuntu (ohne LTS)
  3. Ständig aktualisierend ("rolling release"), meist topaktuelle Software häufig zu Lasten der Stabilität. Wer nicht regelmässig mitspielt ("aktualisiert") manövriert sich in Schwierigkeiten.
    • ArchLinux
    • Sabayon
    • Gentoo
    • OpenSUSE Tumbleweed


Klar, dass noch wesentlich mehr Distributionen gibt, die obigen seien nur als Beispiele genannt.

Es gibt natürlich Zwitter, so lassen sich die abgehangenen Systeme durch zusätzliche (nicht vom Hauptrojekt unterstützte) Paketquellen mit aktuellerer Software bestücken.

Und diesen "Zwitter-Weg" geht jetzt auch OpenSUSE Leap. Sie bauen auf der stabilen Basis von SUSE Enterprise Linux auf und portieren aktuelle Applikationen aus Tumbleweed zurück in die Distribution und unterstützen sie auch offiziell.

In der Summe ist das eine Mischung aus der ersten und der dritten gerade genannten Kategorie. Für mich ist dieser Weg das Beste aus allen Welten für Endanwender und ich hoffe, dass einige weitere Distributionen dem Beispiel folgen werden. Allerdings, das darf man nicht vergessen, kann der hohe Takt auch zu Problemen führen.

CAs hinzufügen ...

linux Für den Fall, dass das noch jemand anderes benötigt.

Um andere Certificate Authorities (CAs) zu Linux hinzuzufügen, sind nur kleine Schritte nötig. Hier einmal am Beispiel CAcert.

Debian:
curl http://www.cacert.org/certs/root.crt -o /usr/local/share/ca-certificates/cacert_root.crt
curl http://www.cacert.org/certs/class3.crt -o /usr/local/share/ca-certificates/cacert_class3.crt
update-ca-certificates


CentOS:
update-ca-trust enable
curl http://www.cacert.org/certs/root.crt -o /etc/pki/ca-trust/source/anchors/cacert_root.crt
curl http://www.cacert.org/certs/class3.crt -o /etc/pki/ca-trust/source/anchors/cacert_class3.crt
update-ca-trust extract


ACHTUNG: In jedem Fall sollte vor dem Ausführen von update-ca-certificates bzw. update-ca-trust extract die Fingerprints der Zertifikate überprüft werden.

Schaltsekunde ...

linux So soll es sein:

05:06:02 [dirk@moas:~] $ sudo grep -i leap /var/log/messages
Jul 1 01:59:59 moas kernel: Clock: inserting leap second 23:59:60 UTC
Jul 1 02:00:00 moas ntpd[24383]: 0.0.0.0 061b 0b leap_event

nice und ionice ...

linux Ein kleiner Shorty für alle, die Last intensive Dinge mit ihren Linux-Maschinen anstellen müssen und den eigentlichen Betrieb so wenig wie möglich einschränken wollen.

Mit nice bzw. renice kann man die Priorität eines Prozesses bezogen auf die CPU beeinflussen und mit ionice kann man das gleiche auch in Bezug auf I/O tun.

Wenn man die folgenden Befehle in ein Skript schreibt, werden alle Kommandos und Kindprozesse des Skriptes mit niedrigst möglicher Priorität ausgeführt.
renice -n 19 -p $$
ionice -c 2 -n 7 -p $$


(ionice -c 3 -p $$ gibt dem Prozess nur dann I/O, wenn kein anderer Prozess I/O anfordert).

Die beiden obigen Befehle kann man natürlich auch in der aktuellen Shell (interaktiv) ausführen.