News Linux: Ubuntu 18.04 LTS Beta setzt wieder auf X.Org

[mensch183]

Ich sage es ehrlich:
Mir geht das inzwischen auf den Sack wenn ständig das Interface geändert wird. Wenn ich mal mit Linux zu tun habe, ist das quasi immer eine Umstellung, selbst wenn es alles Ubuntu ist... läuft ja quasi nirgends überall die aktuellste Version...

Niemand zwingt dich, die zerkonfigurierten, inkompatiblen Standard-GUIs der Distris zu verwenden. Die sind für den Betrieb in gemischten Umgebungen ungeeignet. Das war früher auf den zig Unixen der verschiedenen Herstellen so und hat sich heute, wo fast nur x86-Linux übrig ist, nicht verbessert.

Die Lösung des Problem ist noch immer die gleiche:
Nutze eine simple GUI, z.B. einen klassischen Window-Manager. Die GUI-Konfiguration und ggf. auch Binaries für alle nötigen Plattformen legst du irgendwo in $HOME und kopierst sie bei Bedarf auf neuen Rechner, wenn die nicht sowieso das gleiche $HOME per NFS o.ä. haben.

 

[Bigfoot29]

@andy_m4:
Danke für den langen Post.

systemd hat durchaus gute Ansätze. Mag ich nicht verneinen. Danke auch für die Liste der Init-Systeme. Bei Gentoo wundert mich die Aufstellung ein wenig. Als ich mal versucht hab, das zum Laufen zu bekommen, bekam ich glaube ich auch systemd als Default vorgesetzt... kann ich aber im Detail jetzt nicht mehr sagen.

Ich bin ebenfalls mit ifconfig groß geworden. Schon allein die Tatsache, dass mir jetzt selbst auf einem lokalen Server(!) regelmäßig irgend ein Prozess versucht, die Netzwerk-Einstellungen zu überschreiben, weil ich die derzeit noch klassisch über ein RC-Skript fest setze, ärgert mich maßlos. (Das Skript gehört zu einem Xen-Setup, für das virtuelle Netzwerk-Schnittstellen nacherzeugt und konfiguriert werden.) Ich kann es nicht abschalten, obwohl die /etc/network/interfaces klar gepflegt ist. Das geht schon seit "Debian Jessie" so und ich hab nicht die Zeit, ständig Dinge nachzufixen, die andere kaputtmachen. (Weswegen ich bislang Debian so schätzte.)

Damit sind wir auch beim Kern, warum ich bislang bei Ubuntu blieb: Ich hatte zwar meine ersten Berührungspunkte mit SuSe 5.0, bin aber letztlich erstmit Debian voll in die Linux-Welt eingestiegen. Ausflüge zu Mandriva, Arch oder Gentoo waren am Ende alle eine Test-Episode. BSD-Technisch hatte ich mich durchaus auch mal versucht, scheiterte aber am Aufsetzen in einer VM und als dann von "Von der Raadt" (heißt er glaube ich) der einzige Lösungsansatz in der Form dokumentiert war, dass man doch gefälligst keine VMs verwenden sollte, weil sich xBSD (weiß es grade nicht) zu fein ist, auf VMs laufen zu MÜSSEN und "deren Fehler zu beheben", war meine Episode wieder vorbei. Dabei war der Initial-Kontakt gar nicht mal schlecht. Ich hab damals mein Casio Casiopeia von WinCE 2.0 mit NetBSD (glaube ich) zum Laufen bekommen. Aber das ist halt viele Monde her. Allerdings komme ich auch mit Debian so langsam echt auf Kriegsfuß. Früher war es so, dass man sich drauf verlassen konnte, dass ein Debian-Release einen Feature-Freeze hatte. Was haben sie mitten im Lebenszyklus gemacht? "Hier, neuer Firefox. Vergesst eure Addons. Wir wissen, ihr wollt das doch auch?!". Bei Ubuntu hätte ich das ja noch erwartet. Aber von Debian? :/

Bei BSD tu ich mich derzeit noch schwer, da es eben schon wieder umlernen ist. Ich bin nicht mehr in dem Alter, in dem es mir leicht fällt, mich alle paar Monate in eine neue OS-Schematik und -denkweise einzuarbeiten. Paketmanager, "Laufwerke", Tools, Lösungswege... Da wäre vermutlich selbst ein Gentoo einfacher zu verstehen... Oder gibt es da Empfehlungen? Insbesondere auf dem Server sehe ich da durchaus Möglichkeiten, die Hypervisor-Ebene mit Host-OS im Laufe des Jahres zu ersetzen.

Was das Coding angeht: Klar, Linux IST OpenSource. Aber es ist doch eine andere Nummer, ob man nur mal ein Paket runterlädt, eine Zeile anpasst und das Ding neu kompiliert (bei Ubuntu 17.04 ging für Ryzen nach Erscheinen der Distribution nichtmal das für den Kernel, weil selbst mitgebrachte Tools nicht miteinander funktionierten), oder ob man ein völlig neues Feature in einen Display-Server implementiert, der einzelne Fenster aus einem Display identifizieren per Schnittstelle irgendwo anders hin anbieten kann...

Wie Du siehst, habe ich primär etwas gegen Snaps. Gut möglich, dass FlatPaks da besser sind. Letztlich bleiben aber Systeme, deren Libs im Paket mitkommen, immer ein Risiko.

Virtualisierung ist nicht gut vs. Docker is geil:
Da sieht man, wie unterschiedlich Leute ticken. Es kommt halt immer drauf an, was man tun will. BSD Jails sind weitestgehend eigenständige Container. Wenn man aus der BSD-Welt kommt, ist es lächerlich, was da gerade in der Linux/Windows-Welt vor sich geht. Ich selber bin mit Xen (und seinen Möglichkeiten der Paravirtualisierung) groß geworden. Ich virtualisiere da nach Aufgabenumfeld. Das hat den Vorteil, dass ich zwar mehr Overhead als ein BSD-Jail habe, aber weniger Software-Framework um den Container/die VM, die ggf. verrückt spielen können. Und wenn man sich anschaut, was man für Docker allein schon alles kennen muss, wenn man da mal was debuggen will... gute Nacht.

Regards, Bigfoot29

 

[andy_m4]

Mir reicht es ja wenn meine Hand voll Tools die ich brauch X unterstützt und ich irgendwo einen X-Server als Aufsatz starten kann. Aktuell läuft mein X-Server eh meistens auf einem Windows, weil Linux nur auf dem Server in der Ecke am laufen ist...

X-Kram auf dem Server? Auweia :-)

Prinzipiell gäbe es noch eine bessere Lösung: Tools zur echten Remote-Administration. Müsst mal schauen ob es mittlerweile brauchbare Tools für meine Zwecke gibt.

DA ich das meiste über die Kommandozeile administriere, reicht mir da i.d.R. ein ssh Zugang.

Denn an sich müssten die wohl gar nicht auf dem Server laufen. Aber kennt da jemand z.B. was mit dem ich KVM/QEMU die VMs remote einrichten kann und auch die grafische Konsole der VM bekomme?

Na die VM selbst remote anzeigen zu lassen ist ja kaum noch ein Thema, da die ganzen Dinger inzwischen VNC oder RDP beherrschen.
Die Administration selbst ... wie gesagt, da greif ich dann eher zu Kommandozeilentools.
Da aber X.org überall noch verfügbar ist, geht natürlich auch das immer noch.
Und Wayland bietet ja auch die Möglichkeit für remote-Fulldesktop. Das bemängelte Problem bei Wayland ist ja nicht, dass remote überhaupt nicht geht, sondern das (bisher) kein effizientes Protokoll gibt (was im LAN aber irrelevant ist) und das Du nicht nur einzelne Fenster (seamless-mode) übers Netz schicken kannst.

Bisher hol ich mir da wie gesagt den virt-manager per SSH X-Forwarding auf den Client.

Genau.

Sowas wie die Admin-Tools von VMware wären nicht schlecht ;-)

Gut möglich, dass es als Alternative ne Weboberfläche gibt.
Ansonsten war ja, was remote-Administration von Servern über WebGUI angeht, Webmin immer ne gute/brauchbare Vairante. Vielleicht haben die ja inzwischen auch Unterstützung für Virtualisierungskram.

 

[Jesterfox]

Auf dem Server hab ich nur X-Clients am laufen, das ist ja gerade das schöne dass das ganze Konstrukt ohne grafische Oberfläche am Server auskommt, was mit Wayland (oder auch VNC) nicht mehr der Fall wäre.

Webmin hab ich sogar am laufen, vor allem für die Samba Freigaben, die krieg ich darüber am schnellsten eingerichtet und kann auch die Updates fürs System recht einfach anstoßen. Und so wie es aussieht gibt es tatsächlich was für die KVM Administration, ist mir bisher noch nicht aufgefallen... muss ich mir mal anschauen.

Die Oberfläche vom Guest brauch ich vor allem fürs erste Installieren, danach kann ich ja direkt mit dem OS da drin übers Netzwerk interagieren (aktuell eine pfsense und ein Windows 10). Irgendwie muss das wohl über VNC wohl auch direkt gehen, hatte aber bisher keine verständliche Anleitung dafür gefunden :-(

 

[andy_m4]

Bei Gentoo wundert mich die Aufstellung ein wenig.

Gentoo orientiert sich in vielen Sachen ziemlich an den BSDs. Insofern ist man da durchaus recht offen mehr als eine Möglichkeit offen zu lassen.

Ich bin ebenfalls mit ifconfig groß geworden. Schon allein die Tatsache, dass mir jetzt selbst auf einem lokalen Server(!) regelmäßig irgend ein Prozess versucht, die Netzwerk-Einstellungen zu überschreiben, weil ich die derzeit noch klassisch über ein RC-Skript fest setze, ärgert mich maßlos.

Stimmt. Das ist auch so eine Geschichte. Vor allem, weil man nicht immer unmittelbar herausbekommt, wer denn nu der Übeltäter ist. Und da gibts ja nu inzwischen zahlreiche Möglichkeiten. Von WLAN-Skripten, NetworkManager ... bis nu auch noch systemd.

Was Automatismen angeht, bewegt man sich ja da durchaus auf Windows zu. Und bekommt dann zunehmend auch ähnliche Probleme.

BSD-Technisch hatte ich mich durchaus auch mal versucht, scheiterte aber am Aufsetzen in einer VM und als dann von "Von der Raadt" (heißt er glaube ich) der einzige Lösungsansatz in der Form dokumentiert war, dass man doch gefälligst keine VMs verwenden sollte, weil sich xBSD (weiß es grade nicht) zu fein ist, auf VMs laufen zu MÜSSEN und "deren Fehler zu beheben", war meine Episode wieder vorbei.

Ja. Das war dann vermutlich OpenBSD.
Theo de Raadt ist ne streitbare Persönlichkeit, man muss allerdings anerkennen was die OpenBSD-Leute so leisten. Gerade in Hinblick auf Sicherheit. Viele Sachen die woanders eingebaut wurden, waren zuerst in OpenBSD.
Das überall beliebte OpenSSH stammt auch aus OpenBSD.

Was VMs angeht, kann ich gar nix genaues sagen. Wie gesagt, ich bin eher bei FreeBSD. Und die haben sogar ne eigene Virtualisierungslösung namens bhyve. VirtualBox läuft ebenfals. Xen auch. Sowohl als Gast als auch als Host.

Bei BSD tu ich mich derzeit noch schwer, da es eben schon wieder umlernen ist. Ich bin nicht mehr in dem Alter, in dem es mir leicht fällt, mich alle paar Monate in eine neue OS-Schematik und -denkweise einzuarbeiten. Paketmanager, "Laufwerke", Tools, Lösungswege...

Dafür ist die Entwicklung kontinuierlicher. Bei Linux verbringt man viel Zeit damit, zu lernen, weil sich was verändert hat. Oder weil irgendein Automatismus irgendwo auf undurchsichtige Weise eingreift. Oder weil irgendwelche Änderungen funktionierende Lösungen kaputt machen.
DIe Hardwareunterstützung ist ebenfalls ok (auf Server sowieso). Und die Softwareauswahl .... Du hast eigentlich so ziemlich all das, was Du auch unter Linux einsetzen kannst.

Da wäre vermutlich selbst ein Gentoo einfacher zu verstehen...

Gentoo wäre ja schon the half way to FreeBSD. :-)

Oder gibt es da Empfehlungen?

Was Linux angeht? Nicht wirklich. Das Problem (falls man es denn als solches wahrnimmt) liegt halt im Linux-Ökosystem selbst. Da kommt man langfristig also nicht drum rum. Was man machen kann ist halt Distributionen einzusetzen, die lange unterstützt werden. Wie eben Debian (bist Du ja von ab) oder hat Redhat Linux bzw. einer seine Klone wie CentOS.

Da hat halt eine Version ne lange Laufzeit wo sich nur marginal was ändert. Das Problem sind dann eher die Upgrades, weil da halt gleich ein relativ großer Schritt gemacht wird, wo an vielen Stellen Probleme auftreten können. Wobei ja solche Distributionen schon bemüht sind den Upgradepfad so einfach/problemlos wie möglich zu machen.

Wenns dann doch ein (erneuter) Versuch mit BSD sein soll, dann ist vermutlich FreeBSD das, wonach man greifen sollte. Das dürfte auch für den Umstieg das Angenehmste sein.
Zu FreeBSD gibt es auch ein ausgezeichnetes Handbuch ( https://www.freebsd.org/doc/de/books/handbook/ ), dass eigentlich alle wichtige Fragen beantwortet.
Traditionell bekommt ja FreeBSD seine Programme als Quellcode und wird auf der Maschine kompiliert. Es gibt aber inzwischen auch Binärpakete. Das entscheidende Programm hier ist pkg. Wenn Du bisher apt-get benutzt hast, wirst Du auch schnell mit pkg zurecht kommen.
Außerdem hat FreeBSD eine sehr brauchbare Linux-Emulation (falls Du Programme brauchst, die nur als Binary für Linux vorliegen).

Mit TrueOS gibts auch ein vorkonfiguriertes Ready-To-Use Desktop-FreeBSD. Lässt sich auch relativ einfach, problemlos und fix in einer VM installieren, um mal in einem fertigen FreeBSD rumzuspielen. Für ne weitergehende ernsthafte Beschäftigung würde ich dann aber doch eher zum originalen FreeBSD greifen.

Was das Coding angeht: Klar, Linux IST OpenSource. Aber es ist doch eine andere Nummer, ob man nur mal ein Paket runterlädt, eine Zeile anpasst und das Ding neu kompiliert (bei Ubuntu 17.04 ging für Ryzen nach Erscheinen der Distribution nichtmal das für den Kernel, weil selbst mitgebrachte Tools nicht miteinander funktionierten), oder ob man ein völlig neues Feature in einen Display-Server implementiert, der einzelne Fenster aus einem Display identifizieren per Schnittstelle irgendwo anders hin anbieten kann...

Klar ist das was Anderes. Aber von nix kommt nix. Ich kann mir sogar gut vorstellen, dass es da schon was in Entwicklung gibt, wo man sich dran beteiligen kann. Und sei es nur durch Bugreports etc.

Wie Du siehst, habe ich primär etwas gegen Snaps. Gut möglich, dass FlatPaks da besser sind. Letztlich bleiben aber Systeme, deren Libs im Paket mitkommen, immer ein Risiko.

Strenggenommen gabs das Problem aber schon immer. Nämlich in statisch gelinkten Binarys die es ja schon ewig und drei Tage gibt. Bei so nem Flatpak haste wenigstens noch ne realistische Chance notfalls manuell einzugreifen. Zumal ja die sogenannten "Rumtimes" ja zentral aktualisiert werden können.
Aber letztlich kann ich mich nur wiederholen. Man muss bei der jeweiligen Technik eben wissen, was da passiert und dann gucken, obs für die eigene Anwendung passt oder nicht.

Zu Snaps kann übrigens ich nicht so viel sagen. Das es von Canonical/ubuntu kommt war Grund genug für mich, mir das erstmal nicht näher anzugucken. :-)

Da sieht man, wie unterschiedlich Leute ticken. Es kommt halt immer drauf an, was man tun will. BSD Jails sind weitestgehend eigenständige Container. Wenn man aus der BSD-Welt kommt, ist es lächerlich, was da gerade in der Linux/Windows-Welt vor sich geht.

Wobei es leichtgewichtige Container ja schon vorher in Linux gab/gibt. Man denke da beispielsweise nur an LXC
Man muss dazu sagen, dass Docker ansich ja nicht einfach nur eine weitere Containermöglichkeit ist. Das Wesentliche ist eigentlich das drum herum.

 

[fax668]

Wird so langsam grob OT, aber OpenBSD hat mit den letzten Releases sehr große Fortschritte gemacht, was die Unterstützung von VMs als Host und Guest betrifft.

 

[andy_m4]

Wird so langsam grob OT, aber OpenBSD hat mit den letzten Releases sehr große Fortschritte gemacht, was die Unterstützung von VMs als Host und Guest betrifft.

Jetzt wo Du es sagst, mein ich da auch mal was zu gelesen zu haben auf heise.de

https://www.heise.de/ix/meldung/Ope...ktionen-fuer-die-Virtualisierung-3853760.html

 

[fuyuhasugu]

X-Kram auf dem Server? Auweia

Darum heißt es ja X-Server. :-P

DA ich das meiste über die Kommandozeile administriere, reicht mir da i.d.R. ein ssh-Zugang.

Je nach Aufgabengebiet kann eine solche Minimalausstattung sinnvoll sein. Aber es gibt eben auch Anwendungsfälle, wo ein X auf dem Server sogar notwendig ist.

Und Wayland bietet ja auch die Möglichkeit für remote-Fulldesktop. Das bemängelte Problem bei Wayland ist ja nicht, dass remote überhaupt nicht geht, sondern das (bisher) kein effizientes Protokoll gibt (was im LAN aber irrelevant ist) und das Du nicht nur einzelne Fenster (seamless-mode) übers Netz schicken kannst.

Vorwärts in die Computersteinzeit! Solche Probleme waren schon vor 30 Jahren gelöst. Und die damaligen Programmierer haben eine Bruchteil der zehn Jahre Entwicklungszeit von Wayland gebraucht und Brauchbareres abgeliefert.

 

[Iapetos]

Das X11-Protokoll ist ebensowenig effizient wie VNC - sollte es darauf ankommen, wette ich eher auf letzteres. Moderne Applikationen sind mittels Toolkits wie GTK+ und Qt so weit abstrahiert, dass sowieso volle Bitmaps übertragen werden. Wer sich einredet, dass das effizienter sei als eine ordentliche VNC-Sitzung...

 

[Jesterfox]

Aber VNC funktioniert halt nur wenn auf der Remote-Kiste eine grafische Session läuft die dann übers Netzwerk gespiegelt wird. X erfordert das nicht da die grafische Ausgabe direkt übers Netzwerk verschickt wird.

 

[Iapetos]

Wozu auch immer du das brauchst. Keine graphische Applikation kann so gut sein, dass man dafür einen X-Server auf seinem Server laufen lässt. Das Ding ist sicherheitstechnisch einfach katastrophal. Und unnötig, dank hervorragender Software für die Kommandozeile.

 

[Jesterfox]

Nochmal: ich hab keinen X-Server am laufen, wozu auch? Genau das ist doch der Punkt ;-)

Und für den virt-manager hatte ich halt erst mal keine vernünftige Alternative gefunden. Werd mir mal das Webmin Modul dafür ansehen, denk aber das ich zumindest die Guest-Konsole darüber nicht bekommen werd. Aber vielleicht steig ich ja doch noch dahinter wie das mit dem VNC und den Guests funktionieren soll...

 

[Iapetos]

Okay. Ich verdaue das mal. Du könntest mal Cockpit ausprobieren, wenn du deinen Server mit einem graphischen Interface fernadministrieren möchtest.

 

[Jesterfox]

Das meiste mach ich ja mit Webmin oder auch mal über die Konsole, hab da jetzt nicht so die Berührungsangst. Aber gerade bei den VMs war das einfach nicht das wahre... für die Konfig der VMs müsste das Webmin-Modul ausreichen das es wohl mittlerweile gibt, muss ich mal probieren. Das größere Problem ist zum initialen Einrichten einer VM an deren Display zu kommen. KVM kann da wohl mit VNC "reden", aber ich hab das einfach nicht kapiert wie das gehen soll und schlussendlich eben den virt-manager über ssh getunnelt ;-)

 

[andy_m4]

Das X11-Protokoll ist ebensowenig effizient wie VNC - sollte es darauf ankommen, wette ich eher auf letzteres.

Die Wette würdest Du vermutlich verlieren. Zwar ist X11 als solches Tatsächlich nicht das Effizienteste, kann aber mit Hilfe der NX-Bibliothen enorm beschleunigt werden, was sich insbesondere bei schmalbandigen Verbindungen auswirkt. Projekte wie x2go nutzen das beispielsweise. Und es funktioniert hervorragend (meiner Erfahrung nach besser als VNC).

Moderne Applikationen sind mittels Toolkits wie GTK+ und Qt so weit abstrahiert, dass sowieso volle Bitmaps übertragen werden.

auch die verwenden letztlich die Zeichenfunktionen der darunterliegenden Plattform.
Allerdings würde sich hier tatsächlich Optimierungspotential ergeben. Wenn z.B. QT bei remote eben sagen würde "Dies ist ein Button mit der und der Größe, der Farbe und der Beschriftung. Mal mir das mal beim Remote-Client".
Das ist übrigens auch die Antwort der Wayland-Leute, wenns um Remote-Sitzungen geht. Und das wäre tatsächlich um einige Klassen effizienter als das was man heute so hat.

Wer sich einredet, dass das effizienter sei als eine ordentliche VNC-Sitzung...

Hinzu kommt beim X11-Protokoll, dass Du einzelne Fenster übertragen kannst. Du brauchst halt nicht den ganzen Desktop mit rumschleppen.
Bei VNC kannste dann höchstens sagen, welchen Abschnitt von Desktop Du haben willst. Das ist aber in der Praxis selten hilfreich (wenn Du beispielsweise ein Fenster ständig offen hast und das auch nicht verschoben etc. wird).

Ergänzung (12. April 2018)

Wozu auch immer du das brauchst. Keine graphische Applikation kann so gut sein, dass man dafür einen X-Server auf seinem Server laufen lässt. Das Ding ist sicherheitstechnisch einfach katastrophal.

Der X-Server läuft ja nicht auf dem Server. Der läuft ja auf dem Client.

Und unnötig, dank hervorragender Software für die Kommandozeile.

Obs unnötig ist, möchte ich gar nicht beurteilen. Aber klar. Umso weniger auf dem Server läuft, umso besser. Daher bevorzuge ich ebenfalls die Kommandozeile. Auch wenns hier und da mal umständlicher sein sollte.

 

[Bigfoot29]

Bei dem "X-Server" muss man aufpassen, da hier Client und Server-Rolle vertauscht sind.

Auf dem entfernten (Linux-)SERVER liefe nämlich lediglich der X-Client (der virt-manager z.B), der dann via X-Forwarding auf den X-SERVER des lokalen Rechners zugreift und dort seine Ergebnisse darstellt. Beim VNC muss tatsächlich ein X-Server auf dem Server laufen, der dann wieder Sicherheitsrisiken nach sich zieht.

@andy_m4: TrueOS schaue ich mir gerade mal an. Es zeigt erstaunlich klar, dass Verbesserungen der letzten 10 Jahre in Linux halt manchmal VOR- und manchmal NACHteile haben. Aber gerade für den Server scheint FreeBSD doch eine recht gute Lösung zu sein, nachdem man sich etwas eingearbeitet hat... na mal sehen... in einem halben Jahr steht eh eine Software-Revision an...

Regards, Bigfoot29