Skip to content

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.

Termux ...

android Termux ist eine Linux-Umgebung (und Terminal-Emulator) für Android, damit wäre schon fast alles gesagt, wenn es nicht so toll und zu dem noch Open-Source-Software wäre :-)

In der App lassen sich nämlich Pakete via apt nachinstallieren und das ohne, dass man für das Gerät root-Rechte benötigt. Neben den üblichen Verdächtigen, wie beispielweise openssh oder vim gibt es auch ein Paket für Taskwarrior, das direkt funktioniert. Zusammen mit dem Taskserver lässt sich so auch bequem synchronisieren.

Der Entwickler ist sehr aktiv und steht Paketwünschen sehr wohlwollend gegenüber. Am einfachsten kann man vermutlich einfach einen Request im entsprechenden GitHub-Projekt einstellen.

Den Tipp zu Termux hat mir Wim (hast Du eigentlich eine Webseite?) auf der OpenRheinRuhr gegeben.

Migration zu Hetzner ...

centos Man, was ist das nervig.

Aufgrund eines Irrtums, der sich durch Hören dieser Folge (ab 01:29:32) des empfehlenswerten Podcasts Rechtsbelehrung aufklärte, werde ich mit meinem root-Server wieder nach Deutschland umziehen. Ich hatte das hier schon mal angemerkt.

Mit Bekannten teile ich mir einen Backupserver bei Hetzner und da liegt es natürlich nahe mit dem Server auch zu Hetzner zu gehen. Das Preis-/Leistungsverhältnis für den EX40 ist einfach ungeschlagen. Der Server, wie auch der andere Server der Bekannten, läuft mit CentOS und sehr schnell, also so wie er soll.

Mein neuer Server stand in Rechenzentrum 20 und "fühlte" sich immer sehr langsam an, vor allem das Installieren dauerte ewig. Nun, EPEL-Repositories sind aktiviert und ich bekam den Server kurz vor dem Release von Fedora 23, daher dachte ich, es lag daran. - So war es aber nicht.

Ich habe einen nmap auf Port 22 eines Servers in einem anderen Rechenzentrum bei Hetzner gemacht und der dauerte 16.5 Sekunden, von einem anderen Server bei Hetzner (ebenfalls nicht im gleichen Rechenzentrum) dauerte es 0.07 Sekunden und von zu Hause 0.2 Sekunden.

Das spricht sehr stark dafür, dass etwas im Routing nicht sauber funktioniert und die Pakete den "falschen (langsamen) Weg nehmen". Der Hetzner-Support versuchte das Problem mit dem Rettungssystem (Debian) nach zustellen, aber da funktionierte alles zufriedenstellend. Sie verweigerten Support für das installierte System, was ich verstehe, bei einem root-Server ist man auf sich alleine gestellt.

Also habe ich den Server mit dem offiziellen CentOS-Image neu installiert und danach nichts anderes gemacht als nmap zu installieren. Das Problem war wieder da.

Jetzt ist für mich klar, dass da irgendetwas im Zusammenspiel von CentOS mit dem Routing Probleme bereitet.

Aber auch jetzt fand der Support kein Problem, ich gehe davon aus, dass es nie unter CentOS nachgestellt haben und sie boten mir an, einen Austauschserver zu bekommen. Aufgrund der Prozesse sollte ich den alten Server kündigen und den neuen bestellen, sie würden dann an der gleichen Stelle einen neuen Server bereitstellen. Das hätte das Problem meiner Ansicht nach nicht gelöst.

Glücklicherweise kann man einen Server innerhalb von zwei Wochen stornieren, das habe ich gemacht. Dann habe ich einen neuen Server bestellt und darum gebeten ihn nicht im gleichen Rechenzentrum 20 bereitzustellen. Das dauert knapp 24 Stunden und, was soll ich sagen, im Rechenzentrum 21 gibt es das gleiche Problem.

Man, das nervt.

Also wieder storniert und neu bestellt und jetzt darauf geachtet, dass der Server in ein Rechenzentrum kommt, wo ich weiss, dass es funktioniert.

Das ist halt der Nachteil, wenn man zu einem Grosshoster geht und dort wirklich Probleme hat. Die grosse Anzahl an Systemen können nur durch einen standardisierten Prozess verwaltet werden. Lösungen, die ausserhalb dieser Prozesse liegen, funktionieren halt nicht. Nicht falsch verstehen, das ist kein Vorwurf, es geht nicht anders. Aber es nervt.

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.