Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsLinux: Ubuntu 18.04 LTS Beta setzt wieder auf X.Org
andy_m4
Ich hab eh nur wenig Verständnis für etwaige Probleme. Denn letztlich gibt es ja nur ein Linux und ein Linux-Ökosystem, aus denen die Distributoren schöpfen. Mehr als bestimmte Voreinstellungen und vielleicht distributionsspezifische Tools wie der Installer dürften die Distributionen ja gar nicht so großartig unterscheiden.
Zudem bedient sich ubuntu bei Debian (wo man ja viele Probleme gar nicht kennt). Daher ist es nicht nachzuvollziehen, warum es mit ubuntu Probleme gibt, wenn man ne andere Desktop-Umgebung nimmt.
Gegenüber Distros wie Arch oder Debian z.B. ist halt vieles automatisiert. Was den Einsteiger erfreut, lässt den Arch oder Debian Profi die Haare zu Berge stehn.
Ubuntu als Einsteiger ist sicher nicht das schlechteste aber die Desktops Unity oder jetzt die Gnome-Shell brechen halt stark mit Gewohntem, weshalb ich es nicht als erste Wahl bei den Ubuntu-Derivaten für Umsteiger sehe, sondern eher Xubuntu oder Mate.
Klar, der Anstieg des Desktop-Anteils ist eher langsam, dafür aber auch stetig.
Das ist aber nicht belegt! Der Anteil ist imho stabil irgendwo zwischen 2 und 3 %. Es gibt halt keine umfassende belastbare Erfassung. Sind alles nur Stichproben mit unzuverlässiger Aussagefähigkeit.
Linux ist längst Mainstream. Wer dem aus den Weg gehen will, greift nicht zu Linux.
Aber letztlich ist das in den letzten 10 Jahren schon der dritte schwere Nackenschlag gegen Linux. Man sprach mal von zentraler, einfach zu verstehender Konfiguration, one task, one tool, shared libraries (als Alternative zur DLL-Hölle), remote (X-)Terminals.
Zentral ist die Konfiguration ja durch das /etc-Verzeichnis. Einfach zu verstehen ist Geschmackssache. :-)
Bigfoot29 schrieb:
Was haben wir? systemd, was sich wie ein Krebsgeschwür ausbreitet, nicht vollständig(!) konfigurierbar ist und von einem Maintainer stammt, dem fremde Meinungen schon immer egal waren,
Die Vorteile von systemd überwiegen offenbar. Zumindest sind bestimmte Vorteile nicht von der Hand zu weisen.
Das es nicht vollständig konfigurierbar ist, nun gut. Diesen Kompromiss hast Du aber bei jedem Programm.
Wenn es den Use-Case von vielen Benutzern abdeckt, muss es auch nicht unbedingt bis ins kleinste konfigurierbar sein. Und zu wem es nicht passt, der nimmt halt was Anderes.
Das Problem ist tatsächlich, dass sich inzwischen feste Abhängigkeiten darauf bilden. Aber das hast Du immer irgendwie, wenn Du einen zentralen Systembestandteil hast. Als Extrembeispiel: Der Kernel ist auch nicht austauschbar. Oder auch andere Sachen sind ein Problem, wie die bash-Orientiertkeit (statt POSIX-Standard). Oder versuch mal die glibc auszutauschen.
Bigfoot29 schrieb:
Flatpak/Snap und Co, die die zentrale Lib-Wartung ad absurdum führen
Gut. Wobei Flatpak ja jetzt Pakete nicht ersetzen soll, sondern ergänzen. Ne Möglichkeit ein Programm weitgehend distributionsunabhängig anbieten zu können, ist halt für manche Fälle interessant. Zudem bietet Flatpak ja auch Security-Features. Das macht es auch interessant, wenn man einfach nur mal ein Programm ausprobieren will.
Dem Problem, dass Du da evtl. doppelte Libraries drin hast versucht man mit Runtimes zu begegnen. Das sind letztlich Libraries-Sets zu dem das jeweilige mit Flatpak gepackte Programm Abhängigkeiten hat. So besteht viel weniger die Notwendigkeit, dass jedes Programm ne eigene Kopie von Bibliotheken rumschleppt und die Runtimes wiederum lassen sich zentral aktualisieren.
Ich würde das also generell gar nicht mal verteufeln. Es kommt (wie so oft) darauf an, wie man es einsetzt.
Und mal ehrlich. Das klassische Paketmanagement hat auch so seine Macken. Da werden auch gerne mal überflüssige Abhängigkeiten mitgeschleppt, weil sich da eben nicht gezielt auswählen lässt, ob ich bestimmte Programmfeatures nutzen will oder nicht.
Bigfoot29 schrieb:
Stellt sich halt nur die Frage: Wer macht es besser? Eines der BSDs?
Die Frage ist ja, was dieses besser bedeutet. Jeder hat halt andere Vorstellungen davon. Das macht es schwierig einen Konsens zu finden. Im Grunde ist da BSD da das passende Stichwort. Zum Beispiel geht es ja bei FreeBSD gar nicht darum, dass man ein fertig vorkonfiguriertes System installiert, sondern es bildet lediglich die Grundlage, damit der Nutzer ein auf sich individuell zugeschnittenes System zusammenbasteln kann. Wie Du eingangs sagtest: Ein Basis-System was zentral aktualisiert wird.
Bigfoot29 schrieb:
Im Prinzip ist es ähnlich wie bei den Smartphones. Angeblich - so sagen die Hersteller - wöllten die Kunden ja alles, was gerade völlig schief läuft... keine Klinkenbuchse mehr, Glas (welches bei jedem Fall des Telefons garantiert bricht) auf der Telefon-Rückseite oder Displays so weit in die Ecken der Telefone, dass einerseits eine Einhand-Bedienung zwangsläufig Fehlbedienungen auslöst und andererseits auch kaum noch gegen Stürze zu schützen ist, ohne dass man einen Großteil des Telefons im Regeleinsatz in einer Extra-Hülle verstecken muss, Fingerabdruckssensoren wegen dieses Schwachsinns auf der Rückseite, so dass man sein Telefon auf dem Schreibtisch liegend eben nicht mal eben antippen (und entsperren) kann...
Gut. Firmen bauen primär nie das, was Kunden wollen, sondern was sich verkaufen lässt. Klar kann man dabei Kundenwünsche nicht unberücksichtigt lassen, aber das ist dann eher Mittel zum Zweck. Klar wird auch viel über Style verkauft (Aplle verdient sehr gut daran). Es geht gar nicht darum, dass ein Produkt gut ist, sondern dass es stylisch ist. Und die Werbung suggeriert das auch. Auf so nem Werbebanner kannste halt auch nicht viel Text mit Features drauf machen (den sich eh keiner durchlesen würde. Aber wenns chic aussieht, das lässt sich halt prima bewerben. Und Werbung ist nun mal nicht unwichtig für den Verkauf.
Deshalb ist ja Open-Source auch eigentlich ein guter Gegenentwurf. Weils da halt mehr auf "es funktioniert wie es soll" ankommt. Da hast Du dann eher das Problem, dass Du viele Techniker hast und die sind auch super darin Programme für Techniker zu entwerfen, aber eben weniger gut für den sogenannten Otto-Normal-Anwender.
Bigfoot29 schrieb:
Beide "Industrien" ziehen ihr Ding durch, weil sich die Leute viel zu wenig gegen die Probleme wehren. .
Naja. Was heißt "nicht ausreichend gedacht".
Es betrifft halt nur nen kleinen Teil der User. Und dann ist das folgerichtig für ein paar Prozent da unnötig Ballast mit reinzubringen.
Das Ziel von Wayland war ja ne moderne und vor allem aber schlanke Alternative zu X11 zu bringen. Das würde ja dem widersprechen irgendwelche exotischen Funktionen einzubauen.
Zu mal ja remote prinzipiell geht. Es geht nur eben in der Praxis noch nicht bzw. halt via VNC usw. Ist nicht elegant und auch nicht effizient, aber wenn wir mal ehrlich sind, ist auch X11 nicht effizient. Das geht im LAN noch ganz gut aber über Internet stößt man sehr schnell an Grenzen. Ohne die NX-Bibliotheken würde es nicht wirklich Spaß machen.
Bigfoot29 schrieb:
Ärgerlich ist es dennoch, dadurch weiter an Komfort zu verlieren. Und das Versprechen, ähnlich gute Multi-Monitor-Lösungen wie unter Windows zu liefern, stehen bei Wayland noch aus. (Im Vergleich zu einer X-Session erkennt die aktuelle Wayland-Sitzung nichtmal mehr meinen Monitor.)
Wayland ist halt noch stark in Entwicklung. Das es da noch Kinderkrankheiten gibt, ist normal. Da würde ich auch eher den schwarzen Peter bei ubuntu sehen, dass die halbfertige Sachen als Standard reinnehmen.
Aber gut: Bei ubuntu weiß man ja auch, worauf man sich einlässt. :-)
@Jesterfox: So herum wird das wohl auch weiter funktionieren. Allerdings kann man Wayland-Anwendungen nicht mehr auf diese Weise nutzen, da ihnen die - Latenzerzeugende - X-Server-Zwischenschicht fehlt, um Server und Client unabhängig voneinander betreiben zu können.
Ja, das wird problematisch sobald Anwendungen den X-Support fallen lassen (aktuell sind die Anwendungen ja oft Hybride die mit beidem laufen) oder neue Anwendungen kommen die ihn erst gar nicht haben.
Das Problem an Lösungen mit VNC usw. ist halt das sie eine laufende graphische Session am Remote-System erfordern und oft auch den kompletten Desktop abbilden und keine einzelnen Anwendungen. Aber gerade das ist es was den Charme von X ausmacht. Mein Server läuft rein mit der Konsole ohne grafisches System. Trotzdem kann ich remote über SSH X-Forwarding ein grafisches Tool starten (meistens benutz ich es für den virt-manager um meine VMs zu konfigurieren)
Solange die meisten graphischen Anwendungen mit einem Toolkit wie GTK+ oder Qt geschrieben werden, entscheidet sich dort, ob sie unter X.org laufen - und die Toolkits werden X.org noch lange unterstützen. Andersherum wird ein Schuh daraus: Solange viele Anwendungen noch harte Abhängigkeiten gegenüber X.org haben, verzögert sich die breite Nutzung von nativen Wayland-Anwendungen.
Gegenüber Distros wie Arch oder Debian z.B. ist halt vieles automatisiert. Was den Einsteiger erfreut, lässt den Arch oder Debian Profi die Haare zu Berge stehn.
Ja. Nichtsdestotrotz haben solche Distributionen ihre Berechtigung. Das ist ja das praktische an Linux. Es sind halt sehr viel unterschiedliche Distributionen machbar und daher für jeden was dabei.
Mein Problem mit ubuntu ist auch weniger, dass es einsteigerfreundlich ist, sondern dass es halt trotzdem viele Probleme einschleppt.
SO nach dem Motto: Die Idee ist gut, die Umsetzung ähm .... könnte besser sein.
K-BV schrieb:
Ubuntu als Einsteiger ist sicher nicht das schlechteste aber die Desktops Unity oder jetzt die Gnome-Shell brechen halt stark mit Gewohntem,
Kommt halt drauf an. ubuntu hat offenbar das bestreben ansich ein Interface zu bieten und nicht zwangsläufig sich an Windows-Anwender zu orientieren.
Denn die Windows-GUI ist ja eigentlich nicht besonders gut. Das "jeder" damit umgehen kann liegt an deren Verbreitung.
K-BV schrieb:
weshalb ich es nicht als erste Wahl bei den Ubuntu-Derivaten für Umsteiger sehe, sondern eher Xubuntu oder Mate.
Was sich aber mit dem von Dir Genannten widerspricht, da man ja nur beim vanilla-ubuntu die beste Unterstützung hat.
K-BV schrieb:
Das ist aber nicht belegt! Der Anteil ist imho stabil irgendwo zwischen 2 und 3 %. Es gibt halt keine umfassende belastbare Erfassung. Sind alles nur Stichproben mit unzuverlässiger Aussagefähigkeit.
Zahlen hab ich auch nicht parat. Aber ich sehe halt in meinem Umfeld, dass da mehr und mehr Linux genutzt wird. Ich beobachte auch, dass in Communities wo man als Linux-Nutzer eher als Exot galt nu Linuxer fast die Mehrheit stellen.
Das halt auch in staatlichen Stellen vermehrt auf Linux & Open Source gesetzt wird (leider mehr im Ausland als hierzulande, wo ja beispielsweise LiMux eingestampft wird).
Und für SuSE und Redhat scheint es ja auch lohnenswert zu sein eine Desktop-Ausgabe ihrer kommerziellen Distributionen rauszubringen.
Gut, diese Wahrnehmung ist subjektiv. Aber wie Du schon sagtest, mit konkreten Zahlen wird es eher schwierig.
Zudem gibt es noch ein anderes Problem. Das liegt eben in der Natur prozentualer Darstellung. Wenn die Gesamtzahl der Nutzer zunimmt kann zwar der Anteil der Linux-Desktops stagnieren oder gar rückläufig sein, aber in absoluten Zahlen dennoch zunehmen.
Und gerade durch Smartphones und Tablets sind halt viele Computernutzer hinzugekommen, die den herkömmlichen Computer bisher nur sporadisch oder gar nicht genutzt haben. Die haben aber iOS oder Android und nicht unbedingt ein Linux.
Das verschleiert sicher auch ein bisschen die Zunahme der Linux-Nutzung.
K-BV schrieb:
aber in nahezu allen anderen Bereichen ist es omnipräsent.
Ja. Was ich aber auch wieder als Problem sehe. Statt eines Monopolisten wie Microsoft/Windows hat man jetzt eben den Monopolisten Linux. Es gibt so einen gewissen Trend Software Linux-only zu machen die dann nicht mehr so ohne Weiteres zu anderen Systemen portierbar ist.
Früher haben die Linuxer immer geschimpft, dass Software nur für Windows gemacht wird und inzwischen ist es aber so, dass Software zunehmend speziell für Linux entwickelt wird. Das genannte systemd ist ja ein Beispiel dafür. Und jetzt, wo es auch noch Abhängigkeiten darauf gibt ist die abhängige Software auch de facto linux-only.
Aber es zeigt wieder mal ganz deutlich wo es bei Linux hakt.
KDE sei ein fantastischer Desktop und die von Kubuntu übernommenen Pakete von guter Qualität. In einer Umgebung wie Linux Mint habe sich der Plasma-Desktop jedoch mehr und mehr als „eine andere Welt“ erwiesen, so Lefebvre. Das Entwicklungstempo der KDE-Entwickler sei für eine Distribution, die auf Ubuntu LTS aufsetzt, zu hoch. Dadurch sei die Einbindung und Pflege der nötigen Backports mit zuviel Aufwand verbunden, die dafür benötigte Zeit könne besser an anderer Stelle der Distribution eingesetzt werden.
Die Vorteile von systemd überwiegen offenbar. Zumindest sind bestimmte Vorteile nicht von der Hand zu weisen.
Das es nicht vollständig konfigurierbar ist, nun gut. Diesen Kompromiss hast Du aber bei jedem Programm.
Wenn es den Use-Case von vielen Benutzern abdeckt, muss es auch nicht unbedingt bis ins kleinste konfigurierbar sein. Und zu wem es nicht passt, der nimmt halt was Anderes.
Das Problem ist tatsächlich, dass sich inzwischen feste Abhängigkeiten darauf bilden. Aber das hast Du immer irgendwie, wenn Du einen zentralen Systembestandteil hast. Als Extrembeispiel: Der Kernel ist auch nicht austauschbar. Oder auch andere Sachen sind ein Problem, wie die bash-Orientiertkeit (statt POSIX-Standard). Oder versuch mal die glibc auszutauschen.
Das gute wie schlechte an der Sache ist halt, dass es schwierig ist mit RedHat zu konkurrieren. Fedora und RHEL haben eine Zeit lang Upstart genutzt, anscheinend war man damit aber nicht zufrieden und hat sich dann was eigenes gestrickt. Dabei kann man RedHat dann auch kaum vorwerfen, dass sie primär für die eigenen Kunden entwickeln. Debian, Ubuntu und SUSE waren nicht gezwungen das zu übernehmen, nur hätte man sich dann eben (weiterhin) selbst um eine Alternative kümmern müssen.
So hat man jetzt ein Stück weit einen Vendor-Lock-in, aber auch einen einheitlichen Standard.
Gut. Wobei Flatpak ja jetzt Pakete nicht ersetzen soll, sondern ergänzen. Ne Möglichkeit ein Programm weitgehend distributionsunabhängig anbieten zu können, ist halt für manche Fälle interessant. Zudem bietet Flatpak ja auch Security-Features. Das macht es auch interessant, wenn man einfach nur mal ein Programm ausprobieren will.
Ja. Was ich aber auch wieder als Problem sehe. Statt eines Monopolisten wie Microsoft/Windows hat man jetzt eben den Monopolisten Linux. Es gibt so einen gewissen Trend Software Linux-only zu machen die dann nicht mehr so ohne Weiteres zu anderen Systemen portierbar ist.
Früher haben die Linuxer immer geschimpft, dass Software nur für Windows gemacht wird und inzwischen ist es aber so, dass Software zunehmend speziell für Linux entwickelt wird. Das genannte systemd ist ja ein Beispiel dafür. Und jetzt, wo es auch noch Abhängigkeiten darauf gibt ist die abhängige Software auch de facto linux-only.
systemd als Init-System ist ein denkbar schlechtes Beispiel. Das Interna die (teils) im Kernelspace laufen genau auf dieses Sytsem zugeschnitten sind ist recht logisch. Die Komplexität die daraus resultierend würde verschiedene BSD-Kernel und NT-Kernel mit zu unterstützen wäre der Horror. Sowohl was Bugs, Sicherheit als auch Performance anginge.
Du solltest dich um in Richtung Linuxmonopol wenn auf Anwendungen versteifen die nicht zwingend im Kernelspace laufen müssen um ihre Funktion bereitzustellen.
######################################
Bei dem systemd Gemecker. Hat eigentlich irgendwer konkrete Anwendungsfälle, bei denen er mit systemd Probleme hatte die sich aus systemd ergaben?
Hab ich mir auch schon mal gedacht. Ich mein ein Programm welches seine eigene GUI mitbringt.
Die Frage ist dann nur wie kommuniziert es dann mit der Außenwelt.
Über APIs die Internetfunkionalität beinhaltet oder gar eigene Routinen?
Auf jeden Fall ist die ganze Abhängikeitsgeschichte ein Hemmnis.
Selbige in Windows mit den ganzen Runtimes. C und Dotnet in 1000 Versionen.
Alles von irgendetwas Abhängig bis irgendwo mal ein Glied in der Kette fehlt.
Früher schrieb man Programme die alles integriert hatten.
Sogar Speicher -/Fenstermanagement und GUIs.
Klar war es oft Mehrarbeit.
Dafür war es aber schaissegal ob es in DOS, Win3 oder Win98 lief.
Ab XP wurde dann aber leider die Umsetzung eigener grafischer (DOS) Oberflächen
und Programme gestrichen. Es lief nur noch Textmode.
Inernetfunktionalität ist Netzwerkfunktionalität, ob die IPs im lokalem oder Internet hängen macht eigentlich nichts aus.
Es gibt verschiedene Möglichkeiten. Entweder man setzt unter Windows auf Cygwin um unix kompatible Umgebung unter Windows nutzen zu können. Genauso kann man das Programm gegen MinGW_w64 linken. Wobei die MinGW-Bibliotheken die Netzwerkfunktionalität zur Verfügung stellen zur API von Windows kompatibel sind. Oder aber man schreibt den Netzwerkteil einfach zweimal. Einmal gegen die Bibliotheken der glibc (unix) und einmal gegen die winsock2.h von Windows.
Die Abhänigkeitsgeschichte ist nicht nur Hemmnis sondern auch ein riesiges Plus. Ohne Bibliotheken und Schnittstellen müsste man den Kram jedesmal selber schreiben was bei Zeiten ein Wildwuchs inkompatiblen, nicht mehr wartbarem Gefrickel ergäbe.. Dann lieber Systembibliotheken mit fixer APIs und Abhänigkeiten zu diesen!
Ansonsten weichen ja nur die Produkte davon so außerordentlich krass ab, wobei selbst das langsam aufweicht.
Keine Ahnung, da KDE nun wirklich nicht zu meinen präferierten GUIs gehört, aber selbst im hiesigen Linuxmintforum, hat man ziemliche lange nicht so recht den Sinn der eigenen KDE-Distro eingesehen und auf Kubuntu verwiesen. Wobei das auch gut und gern noch die Zeit gewesen sein könnte, als sich Canonical und KDE/Bluesystems noch lieb hatten.
Das "Eingeständnis" von Lefebvre heißt übersetzt ja nur, wir haben mal wieder nicht genug Geld und Leute und ist der nächste Schritt zurück, nachdem sie dem Releasezyklus von Ubuntu schon nicht mehr folgen konnten und die ganzen Zwischenversionen einstampfen mussten. Hätte Lefebvre von Anfang an sich auf eine Kernmarke konzentriert und mehr in die Systempflege gesteckt anstatt mit Gewalt alle Nischen besetzen zu wollen, wäre er imho besser gefahren.
andy_m4
Zitat Zitat von K-BV Beitrag anzeigen
weshalb ich es nicht als erste Wahl bei den Ubuntu-Derivaten für Umsteiger sehe, sondern eher Xubuntu oder Mate.
Was sich aber mit dem von Dir Genannten widerspricht, da man ja nur beim vanilla-ubuntu die beste Unterstützung hat.
Nicht unbedingt! Der Unterbau ist gleich, klar. Ein Derivat/Communityprojekt wie Xubuntu ist aber schlichtweg ausgereift und erfordert eher Systempflege als Fortentwicklung. Dazu brauchte es aber nicht unbedingt die Manpower von Canonical. Darüber hinaus ist es bei Ubuntu ja relativ strikt geregelt, was sich offizielles Derivat nennen darf und was nicht. Da unterscheidet sich Ubuntu schon von anderen Distros. So gab es z.B. schon länger eine Ubuntu-Mate Version, die aber via Fremdquelle eingespeist wurde. Ergo kein Ubuntu! Da der Projekteiter aber bei Canonical seine Brötchen verdient, kann man hier von einer entsprechenden Einbettung ins Ubuntu-Ökosystem sprechen.
Früher haben die Linuxer immer geschimpft, dass Software nur für Windows gemacht wird und inzwischen ist es aber so, dass Software zunehmend speziell für Linux entwickelt wird. Das genannte systemd ist ja ein Beispiel dafür. Und jetzt, wo es auch noch Abhängigkeiten darauf gibt ist die abhängige Software auch de facto linux-only.
Ich seh das eher als eine logische Entwicklung. BS-gesteuerte Hardware/Technologie hat ja rasant zugenommen außerhalb des klassischen Bereichs. Für die Hersteller war es daher ein logischer Schritt, ein BS zu nehmen, das uneingeschränkt und vor allem kostenfrei zur Verfügung steht, aber trotzdem aktuell gehalten wird. 2 von diesen 3 Kriterien hätte Windows z.B. nicht erfüllt bzw. erfüllen können.
So haben wir aktuell also die Situation, dass die Welt mit Windows verwaltet und mit Linux betrieben wird. Um es etwas grob zu umschreiben!
Ich habe alle Ubuntu Versionen mit Upstart bei mir auf dem Desktop gehabt und auch selbst diverse Upstart Definitionen geschrieben. So einen instabilen Schr*t hatte ich schon lange nicht mehr erlebt. War dann auch der finale Grund, warum ich nach vielen Jahren dankend auf Ubuntu verzichtet habe.
Und übrigens gab es schon davor Alternativen zum init.d System, die ausgereift waren, aber Ubuntu musste natürlich mal wieder seinen eigenen M*st auskübeln.
Schon interessant, dass Ubuntu inzwischen fast alle seine Eigenentwicklungen gegen die Wand gefahren / eingestellt hat und das übernimmt, was alle machen. Vielleicht wird's so langsam Zeit, dass man sich das wieder anschauen kann.
Das gute an upstart (gegenüber SysIV-Init) war, dass es ereignisorientiert war. Es wurden eben nicht wie beim klassischen Init Start-Skripte einfach nacheinander gestartet, sondern Start-Skripte waren voneinander abhängig. Wenn Du nen Apache-Webserver gestartet hast, hat der halt genugt, ist der Netzwerkdienst schon gestartet. Oder Du konntest auf Ereignisse reagieren (zum Beispiel wenn Hardware angesteckt wurde). Außerdem erlaubte Upstart das parallele Starten von Diensten, die nicht voneinander abhängig waren.
Das große Problem an Upstart war, dass Du diese Abhängigkeiten von Hand einpflegen musste, während sie systemd selbst berechnet. Außerdem bietet systemd die von MacOS X bekannte Socket activation, ein sehr eleganter Mechanismus um Dienste zu starten.
Man muss also ganz klar zugeben, dass systemd handfeste Vorteile hat. Klar gibt es auch Kritikpunkte (die ich auch durchaus teile), aber letztlich ist es das Beste was für Linux wir haben
Particle010 schrieb:
Dabei kann man RedHat dann auch kaum vorwerfen, dass sie primär für die eigenen Kunden entwickeln. Debian, Ubuntu und SUSE waren nicht gezwungen das zu übernehmen, nur hätte man sich dann eben (weiterhin) selbst um eine Alternative kümmern müssen.
Was ja auch dank Open-Source nicht schwer wäre. Man müsste ja nicht mal etwas eigenes aus dem Boden stampfen. Man könnte die Teile von systemd übernehmen, die man gut findet. Offenbar ist der Leidensdruck nicht groß genug, so das man die Arbeit an dem Init-System anderen überlässt.
Particle010 schrieb:
So hat man jetzt ein Stück weit einen Vendor-Lock-in, aber auch einen einheitlichen Standard.
Durchaus. Nicht unbedingt wegen systemd als Init-Dienst aber als Framework. Und weil es auch bestimmte Sachen erzwingt.
Zum Beispiel wo bestimmte Dateien liegen. Und da sieht man auch, dass systemd nicht unbedingt nach Redhats Nase tanzt.
Die Datei hostname wird von systemd direkt unter /etc/ erwartet (wie es zum Beispiel auch bei Debian, ubuntu usw. schon immer war). Bei Redhat lag die vorher noch irgendwo unter /etc/sysconfig/ wenn ich mich recht erinnere.
Ergänzung ()
Piktogramm schrieb:
systemd als Init-System ist ein denkbar schlechtes Beispiel.
Es ist suboptimal. Aber wenn Du aufmerksam gelesen hast, ging es gar nicht um systemd direkt, sondern die Abhängigkeiten die es darauf gibt. Zum Beispiel der GNOME-Kram der darauf angewiesen ist. Das ist natürlich nicht die Schuld der systemd-Entwickler, sondern der GNOME-Leute. Ändert aber nichts daran, dass es ein Trend zu Linux-only gibt.
Piktogramm schrieb:
Bei dem systemd Gemecker. Hat eigentlich irgendwer konkrete Anwendungsfälle, bei denen er mit systemd Probleme hatte die sich aus systemd ergaben?
Naja. Immerhin kam es dazu, dass Bug-Reports ignoriert wurden und solche Geschichten. Das das Team hinter systemd halt "schwierig" und nicht unbedingt kompromissbereit wäre. Gut. Das sind sicherlich auch oftmals subjektive Wahrnehmungen.
Dinge die ich aber echt problematisch finde sind solche Sachen, dass z.B. der Google-Nameserver hart eincodiert ist (oder war?). Begründet wurde das damit, dass wenn der Resolver nicht konfiguriert ist, dass dadurch dann die Namensauflösung trotzdem sichergestellt werden soll.
Ist für mich ein No-Go. Wenn DNS kaputt ist, soll es nicht mehr funktionieren. Dann wird der Fehler für mich auch offensichtlich. Ist immer noch besser als wenn Daten irgendwo hin abfließen, wo ich sie nicht haben will.
Gleiches gilt für den NTP-Client. Da fragt man sich schon, was das soll.
Das Init-Binary ist zu groß (hat ja auch viele Aufgaben). Das ist deshalb ein Problem, weil wenn es sich mal aufhängt dann nicht nur ein Dienst ausfällt, sondern mehrere und dann noch relativ Zentrale.
Ich bin schon beim Linux-Kernel nicht so glücklich darüber, das man da einen großen monolithischen Block hat.
Lustig ist ja, dass wir mit Wayland den Klotz X11 endlich los werden und mit systemd wieder einen neuen bekommen. :-)
Und vielleicht wird es irgendwann genauso schwer ihn wieder los zu werden.
@andy_m4:
Ich gebe Dir bei vielen Dingen Recht. Ich tue mich nur bei systemd unendlich schwer. Das System nutzt, da man später mal stateless arbeiten will und damit noch kein "/etc" existiert, mittlerweile Konfigurationsdateien, die in "/lib/systemd/system" liegen, nur um das sicherzustellen. Dass man zwar sagt "da nur kucken, nicht anfassen", macht es nicht besser. Klar kann man ZUSÄTZLICHE Daten unter "/etc/systemd/system" anlegen, aber die korrigieren dann nicht zwingend das Verhalten, was systemd meint, was immer so zu sein habe.
Von der erzwungenen Umstellung des eth-Namensschemas. Es gab früher schon genügend Lösungen, eth-Bezeichnungen ganz klar und über jeden Reboot zweifelsfrei zu definieren. Auch hier musste man extra für systemd und seinen später-mal-möglichen stateless-Ansatz querschießen. Wenns nach Pöttering gegangen wäre (siehe seine Antworten auf den Thread damals, hab es nur noch im Kopf und keinen Link mehr dazu), hätte er das alte Verhalten gern ganz abgeschaltet. Da waren dann nur zu viele Leute dagegen. Trotzdem wurde ein bestehendes System ohne Not zuerstört und mit dem Achselzucken versehen "nehmt doch 'networkd' und schon wäre es euch egal". Pöttering hat schon mit pulseAudio ein gruseliges Produkt abgeliefert, was auch nach 10 Jahren nich nicht fehlerfrei zum Laufen zu bekommen ist. HDMI-Knacken/-Hall, Audio-Aussetzer, ...) Und jetzt traut man ihm nicht nur ein Init-System sondern ein ganzes Init-Framework an?
Was "hostname" angeht, wird er sich schlicht Konventionen gebeugt haben müssen. Selbst Microsoft setzt diese Dateien (wie die hosts-Datei) direkt unter "etc/" an.
Was Wayland angeht, bin ich ansonsten recht weit bei Dir. Es stört mich halt, weil ich Teil dieser kleinen Gruppe bin und ich hätte mir gewünscht, dass man gesagt hätte "klar, wir wissen, dass es euch gibt und wir haben einen langfristigen Plan, damit auch IHR nicht hinten runterfallt". Aber dazu müssen die Jungs wohl erstmal selber das System - auch hier wieder nach Jahren - stabil genug bekommen. Andererseits darf man bei Wayland auch nicht vergessen: Das machen einige Jungs zwar in Anstellungsverhältnis, aber viele auch freiwillig. Und ich habe immer gesagt, dass ich auf Wayland nicht wirklich rumhacke, weil sie sich zumindest anbieter-unabhängig Mühe geben. (Und sie haben meinen Respekt, dass sie damals nVidia den Mittelfinger gezeigt haben. )
Zu "Snap"s: Und da liegt der Hase im Pfeffer: Ubuntu nutzt halt Snaps und kein anderes, weniger gefährliches System. Und das sogar in der Basis-Installation bzw. lässt zu, dass bestehende Basis-Tools auf Snaps umgestellt werden. Programme kann man auch heute problemlos testen, wenn sie sich an die Regularien halten und sich schlicht mit User-Rechten ins User-Verzeichnis installieren lassen würden (oder gleich eine sauberes OOtB-Archiv mitbrächten, wie einige Programme auch heute schon zeigen, dass es ginge). Auch zeigen ZFS, XFS(?) und soweit ich weiß auch btrfs, dass inline-Snapshots durchaus möglich sind und man auch auf diese Weise eine fehlerhafte oder ungewollte Paketinstallation problemlos wieder loswerden kann. Einige Betriebssysteme nutzen das sogar schon heute, um im Problemfall nach (OS-)Upgrades mit einem einzigen Reboot wieder zurückrollen zu können.
Und so weh mir das tut: Das Sicherheitskonzept unter Linux ist ein Chaos. Wir haben Datei-Berechtigungen, die nur auf Userebene und Gruppen funktioniert, aber nicht den Zugriff mehrerer Einzeluser erlaubt, ohne dass man diese User in Gruppen packt, wir haben ein halbes Dutzend Sicherheits-Systeme im Kernel, die seit 10 Jahren nicht fertig werden und stattdessen immer neue Implementierungen hinzugefügt werden, die Einzel-Probleme adressieren, die dann von den Software-Entwicklern wieder berücksichtigt werden müssen, wir haben einen Kernel-Maintainer, der Sicherheitsupdates wie Feature-Updates behandelt... die Liste ließe sich unendlich fortsetzen. Das einzig halbwegs sichere Linux-OS ist "Qubes OS", weil es die Anwndungen halt gleich in ganze eigene VMs auslagert. Und das Konzept dort braucht so eine halbgare Lösung wie "Snap" nun definitiv nicht. Bei allen anderen Lösungen spachtelt man nur etwas mehr Farbe über die Ruine, die beim kleinsten Sturm umfallen wird und die bisher nur das Glück hatte, dass es bislang wenig Stürme gab und wenn, dann recht schnell die gröbsten Risse gekittet wurden.
Ich setze als Betriebssystem auch Linux ein. Ubuntu insbesonders. Weil es eines der besseren Lösungen war, wenn man sich aus den schlechten Alternativen die beste auswählen muss. Aber wenn man sich historisch anschaut, wo Linux her kam, was man damals schon hatte und was man seitdem nicht konsequent weiterentwickelt sondern verschlimmbessert hat, kommt einem schlicht das Heulen.
Nicht unbedingt! Der Unterbau ist gleich, klar. Ein Derivat/Communityprojekt wie Xubuntu ist aber schlichtweg ausgereift und erfordert eher Systempflege als Fortentwicklung.
Denn sehe ich das Problem nicht.
Wie gesagt, weiter oben hast Du noch auf ubuntu-Derivate geschimpft so a-la
K-BV schrieb:
Nur bleib ich dann doch lieber beim unverbastelten Original mit vollem Ubuntu-Support-Status, wenn es denn unbedingt eine Ubuntu-basierte Distro sein muss.
und nu klingt das wie eine Relativierung. Wäre ja auch nicht dramatisch. Aber wäre jetzt schon schön zu wissen, was nu stimmt. :-)
K-BV schrieb:
Ich seh das eher als eine logische Entwicklung. BS-gesteuerte Hardware/Technologie hat ja rasant zugenommen außerhalb des klassischen Bereichs. Für die Hersteller war es daher ein logischer Schritt, ein BS zu nehmen, das uneingeschränkt und vor allem kostenfrei zur Verfügung steht, aber trotzdem aktuell gehalten wird. 2 von diesen 3 Kriterien hätte Windows z.B. nicht erfüllt bzw. erfüllen können.
So haben wir aktuell also die Situation, dass die Welt mit Windows verwaltet und mit Linux betrieben wird. Um es etwas grob zu umschreiben!
Wobei das vermutlich auch nur daran liegt, dass man an den Schulen "Windows" lernt und an der Uni Linux versteht.
Die Zeile ist in vielerlei Hinsicht mehrdeutig. Einerseits wollen heute viele von Windows nicht weg, weil sie nie was anderes gelernt haben. In den Schulen wird Windows beigebracht. Selbst die Argumentation, man könne ja LibreOffice oder Python verwenden, um Dokumentenarbeit oder Programmieren zu lernen, wird abgebügelt, weil selbst die Lehrer oft nicht viel mehr als ihre Windows-Welt kennen. Und hat man seine Schäfchen mal drauf indoktriniert, dass nicht der Wolf sondern der Schäfer das Problem ist, weil: Mit ein paar Verlusten ist ja immer zu rechnen, kriegt man das auch nicht mehr aus deren Kopf. (Nicht umsonst gibt es an Schulen und Unis Programme, um kostenlos Microsoft-Produkte beziehen zu können.)
Andererseits lernt man an den Unis oft, dass es halt Betriebssysteme gibt, die für die eigenen Anwendungen und Anwendungszwecke viel praktikabler sein können. Entsprechend ist in der Ingeneurs-Kategorie die "Ablehnung alles non-Windowschem" bei weitem nicht so groß. Man denkt deutlich praktischer und ist auch bereit, die nötige Zeit zu investieren um anschließend deutlich effektiver sein zu können. Dass ein OS mehr ist als nur eine GUI, zeigt sich eben erst dann, wenn man sich mit den Details des Betriebssystems auseinandersetzt. Und letztlich designen (oder betreiben) Ingeneure unsere Produktiv-Welt. (Andererseits läuft auch eher sicherheitskritische Hardware wie ATMs oder selbst deutsche Panzer nicht mit QNX oder einem speziell dafür angepassten OS sondern mit Windows...)
Obwohl ich keinen Linux-Experte bin und auch nicht unbedingt sein möchte, kann ich trotzdem eine recht objektive Meinung zu den bisherigen Diskussion führen.
systemd
Leider habe ich mich mit systemd gar nicht beschäftigt, um die bisherigen Aussagen zu bestätigen oder widerlegen. Was ich aber so herauslese sind alle mit systemd zufriedend, obwohl es noch nicht perfekt sei. Da frage ich mich, warum gibt es kein Fork oder andere systemd-Alternativen, die sowohl Vorteile von systemd mit sichbringen als auch die Nachteile beseitigen. Das könnten doch die Kritiker selbst tun oder?
Wayland
Viele sagen, dass Xorg sehr alt und angestaub sei und hofften auf einen Ersatz. Als Wayland angekündigt wurde, jubelten viele User und auch Entwickler. Habe das Gefühl, dass die lange Entwicklungszeit eher auf das eher skeptische Blick vieler Entwickler zurückführt. Vielleicht hat man in Wayland keinen richtigen Vertrauen mehr?
PulseAudio
Wie systemd ist Pulseaudio das beste was in der jeweiligen Linux-Bereich zur finden ist. Soweit ich noch weiss ist Lennart Poettering auch selber überrascht, wie schnell PulseAudio aktzeptiert wurde, obwohl es in der Entwicklung offensichtliche Schwierigkeiten gab.
Generell habe ich mit PulsAudio keine Probleme und alles funktioniert bisher prima. Wenn es eine ernsthafte und bessere PulseAudio-Alternative gibt oder gäbe, dann würde PulseAudio vermutlich schneller ersetzt werden. Nur die Frage, ob es so was gibt? Pipewire von RedHat?
Generell kann ich verstehen, dass viele mit der neusten Entwicklungen im Linux einverstanden sind. Aber bis da jemand eine "Wunderheilung" für alle Probleme des Linux-Desktop, wird es entweder noch Jahre dauern oder nie geben.
systemd I: Es gibt Versuche, das zu tun. Leider gibt es mittlerweilen Software, die sich auf systemd als OS-Kernbestandteil verlässt. - Auch etwas, was früher unüblich war. Allein, diese Features nachzuimplementieren und den Rest bei "init" zu belassen, kostet halt Zeit und Manpower. Die muss man aber eben anders als beim von RedHat finanzierten systemd erstmal haben.
Wayland:
Da ist im Moment niemand skeptisch. Leider hat Ubuntu mit Mir - bis zu seiner Abkündigung - da viel Porzellan zerschlagen anstatt Wayland weiterzuentwickeln. Ansonsten gilt halt wie immer: "Es gibt ein bestehendes System. Warum also etwas übereilen?" RedHats Community-Distribution liefert Wayland ja schon seit knapp einem Jahr als Default-Server aus. Nur besteht eben kein Druck, gerade für lang supportete Distris jetzt direkt auf Wayland zu gehen, wenn da nächstes Jahr noch größere Änderungen kommen, die man zurückporten müsste. So muss man nur das bestehende X noch weiterpflegen. Und alternativ kann man Wayland ja auch in 18.04 nutzen.
PluseAudio:
Es gab vorher reines Alsa, welches mit weiteren Sound-Deamons wie "esound" und Co die gleichen Möglichkeiten hatte wie PulseAudio heute. Und anders als PA waren diese Lösungen ausentwickelt. Einziges Problem: Die User wussten davon nichts und mussten sich einlesen. Taten sie das, hatten sie eine rockstabile Audio-Umgebung. Es gab selbst für die DBox2 (Sat-Reciever für Premiere/Sky) ein esound-Plugin, womit man das Audio des eignen PC per Netzwerk an den Verstärker geben konnte, an dem die dBox ja sehr wahrscheinlich hing. Andererseits war PulseAudio damals gerade in der Anfangs-Phase nur ein Zusatz (wie es Alsa zu OSS war) und es schadete daher nicht, es mit anzubieten. Es war auf etwas mehr Bedien-Komfort ausgelegt, was die User offensichtlich gern annahmen und die auftretenden Probleme auf Alsa oder ihre Hardware schoben. Die am meisten gelesene und immer funktionierende Lösung war damals nämlich "deinstalliere mal pulseaudio". Dass man bei PA dann doch wieder händisch in Konfigurationen rumfummeln muss, um time slices anzupassen oder anderweitig an selbst für geübte User schrägen Parametern zu drehen, um dadurch Seiteneffekte zu minimieren, die offensichtlich nichts mit den Problemen zu tun hatten, die man hatte, lernte man erst mit den Jahren. Hätte man das von Anfang an gewusst, wäre das Zeug vermutlich nie über das Staging hinausgekommen.
systemd II:
Und genauso arbeitet heute auch systemd. Für 99% der User halbwegs problemlos, dafür verzweifeln heute 1% an der Lösung vollständig. Mit dem Vorgänger-System gab es immerhin Workarounds. Heute hat man notfalls Pech gehabt oder muss hoffen, dass kaputte Dinge in der nächsten Version gefixt werden. Ich erinnere mich da noch an völlig obstruse Diskussionen, dass invalide Konfigurationsoptionen in einer systemd-config-Datei keinen Alarm schlagen, weil "das ja in einer zukünftigen systemd-Version unterstützt werden können möge". Da gab es kein Flag "be permissive and allow future config parameters/ignore warnings", nein, es war die einzige Option. JEDES gute Programm meldet ungültige Konfigurationsparameter. Nur Pöttering streitet sich bis aufs Messer, dass seine Lösung die einzig Richtige ist. Und wie gesagt: So jemandem überlässt man ein Init-Framework, welches neben dem Kernel und dem X-Server selbst gerade zum dritten monolitischen Monster wird. (Es war mal ein System, welches lediglich dafür sorgte, dass Prozesse korrekt gestartet werden und dass nachvollziehbar ist, wann und warum man das tat.)
Okay, GANZ so kurz ist es leider nicht geworden... :/
@andy_m4:
Ich gebe Dir bei vielen Dingen Recht. Ich tue mich nur bei systemd unendlich schwer. Das System nutzt, da man später mal stateless arbeiten will und damit noch kein "/etc" existiert, mittlerweile Konfigurationsdateien, die in "/lib/systemd/system" liegen, nur um das sicherzustellen. Dass man zwar sagt "da nur kucken, nicht anfassen", macht es nicht besser. Klar kann man ZUSÄTZLICHE Daten unter "/etc/systemd/system" anlegen, aber die korrigieren dann nicht zwingend das Verhalten, was systemd meint, was immer so zu sein habe.
Ich sehe auch systemd nicht vorbehaltlos als gut an. Es kann aber in bestimmten Fällen (vielleicht sogar die meisten?) eine gute Option sein.
Wenn es nicht passt, nimmt man etwas Anderes.
Das Problem ist eher, dass systemd inzwischen so verbreitet ist, dass Du eben kaum noch eine Distribution kriegst, die das nicht hat. Zumindest ist die Auswahl inzwischen sehr eingeschränkt.
Bigfoot29 schrieb:
Von der erzwungenen Umstellung des eth-Namensschemas. Es gab früher schon genügend Lösungen, eth-Bezeichnungen ganz klar und über jeden Reboot zweifelsfrei zu definieren. Auch hier musste man extra für systemd und seinen später-mal-möglichen stateless-Ansatz querschießen.
Ja. Solche Sachen finde ich auch eher nervig. Ich mein, ich kann die Gründe für das neue Namensschema nachvollziehen. Trotzdem ist es eben ärgerlich, wenn man immer wieder umlernen muss (ohne das für ein selbst da wirklich ein Vorteil bei rauskommt).
Genauso wie die Distributionen neuerdings meinen mir ifconfig wegnehmen zu wollen. Man soll jetzt ip nehmen.
Da frag ich mich, was soll so ein Sch**ß- Seit Jahrzehnten war ifconfig immer da und man hat sich dran gewöhnt. Mag sein, dass ip besser ist. Aber für Standardsachen reicht mir einfach ipconfig.
Was will ich wissen, wenn ich ifconfig benutze? Wieviel Interfaces gibt es. Haben die ne IP-Adresse, gibts gedroppte Packages?
Wird alles hübsch angezeigt wenn man es so aufruft. ip dagegen zeigt mir nur ne Palette an Optionen an, mit denen ich mich dann erst beschäftigen muss.
Gut. Ich könnte mir ein Alias anlegen. Den ich dann aber auf einer anderen Maschine nicht habe.
Bigfoot29 schrieb:
Wenns nach Pöttering gegangen wäre (siehe seine Antworten auf den Thread damals, hab es nur noch im Kopf und keinen Link mehr dazu), hätte er das alte Verhalten gern ganz abgeschaltet. Da waren dann nur zu viele Leute dagegen. Trotzdem wurde ein bestehendes System ohne Not zuerstört und mit dem Achselzucken versehen "nehmt doch 'networkd' und schon wäre es euch egal".
Ja. Wobei Linux ja generell sehr volatil ist. Da finde ich ein BSD sehr viel angenehme da kontinuierlich. Klar dauert es da länger, bis da mal neue Features reinwandern, die sind dann aber auch wirklich ausgereift und da gibts keine großen Änderungen mehr.
Und die werfen auch nicht irgendwelches Zeug um, was seit Jahrzehnten seinen Dienst tut.
Da musste schon ne sehr gute Begründung haben, wenn Du allein ein Kommandozeilenparameter ändern willst.
Im Ergebnis hast Du halt ein sehr solides System, wo Du selten diesen Effekt hast "Warum geht das plötzlich nicht mehr?"
Im Linux-Umfeld ist es eher so, dass man neue Sachen recht früh bringt. Dann wirds aber irgendwie noch 3x geändert oder komplett durch was Neues ersetzt. Die Methode hat sicherlich auch ihre Vorteile. Aber eben auch ihre Nachteile.
Vor 10 Jahren war Linux bei mir noch ganz klar gesetzt, wenn es darum ging ne Maschine zu bestücken. Inzwischen (nachdem ich vermehrt insbesondere im FreeBSD-Umfeld unterwegs bin) ist das nicht mehr so.
Bigfoot29 schrieb:
Pöttering hat schon mit pulseAudio ein gruseliges Produkt abgeliefert, was auch nach 10 Jahren nich nicht fehlerfrei zum Laufen zu bekommen ist. HDMI-Knacken/-Hall, Audio-Aussetzer, ...)
Ja. Wobei ich so viel Probleme mit PulseAudio gar nicht hatte. Kommt aber auch daher, dass ich da kein "Early Adaptor" war. Ich hing ziemlich lange noch beim Plain-ALSA. Im Prinzip würde das mir immer noch reichen. Das einzige Feature von PulseAudio was ich wirklich nutze ist, dass sich mehrere Audioprogramme damit nicht blockieren.
Bigfoot29 schrieb:
Und jetzt traut man ihm nicht nur ein Init-System sondern ein ganzes Init-Framework an?
Ja. Gut. Das macht er ja nicht alleine. :-)
Und man muss ja auch sagen, so schlecht ist systemd nicht. Manche Sachen sind echt praktisch. Problematisch ist sicher so ein wenig, dass man zuviel will. Das ist, glaube ich, auch der Knackpunkt weshalb es so viele Kritiker gibt.
Eigentlich ist man sich ja auch einig, dass SysIV-Init einfach überholt ist. Und das systemd viele richtige Ideen umsetzt. Als problematisch wird eher die konkrete Ausprägung gesehen.
Was mich eher irritiert ist, dass es zwar Kritiker gibt aber letztlich doch alle systemd hinterherrennen. Ist ja nicht so, als wenn Init-IVund upstart die einzigen Alternativen wären.
Dazu werf ich einfach mal diesen Gentoo-Link in den Raum: https://wiki.gentoo.org/wiki/Comparison_of_init_systems
Bigfoot29 schrieb:
Was "hostname" angeht, wird er sich schlicht Konventionen gebeugt haben müssen.
Naja. Das war so eine Datei, zu der es keine Konvention gab. Selbst der ''Filesystem Hierarchy Standard'' sagte dazu nix. Deswegen hat es ja auch jeder so gemacht, wie er es für richtig hielt.
Bigfoot29 schrieb:
Was Wayland angeht, bin ich ansonsten recht weit bei Dir. Es stört mich halt, weil ich Teil dieser kleinen Gruppe bin und ich hätte mir gewünscht, dass man gesagt hätte "klar, wir wissen, dass es euch gibt und wir haben einen langfristigen Plan, damit auch IHR nicht hinten runterfallt".
Nu muss man dazu sagen, Wayland hat eine komplett andere Architektur als X.org. Ist ja nicht so, dass man dieses Feature vergessen hätte und es nu noch nachrüsten müsse oder in der Art. Es war von Anfang an bewusst(!) nicht vorgesehen.
Wayland ist ein Display-Server. Und der kümmert sich darum und nur darum. Sowas wie Netzwerktransparenz gehört da gar nicht in das Level auf dem Wayland läuft. Mit anderen Worten: Die Wayland-Leute sagen einfach: "Das ist nicht unsere Baustelle." womit sie aus Sicht der Wayland-Architektur natürlich vollkommen recht haben.
Das sich da einige X.org-Anwender im Regen stehen gelassen fühlen ist nachvollziehbar.
Andererseits ist Open-Source halt auch keine Einbahnstraße. Man kann sich nicht hinstellen und sagen "Ich will das und das Feature" und dann "rumlamentieren" wenn es nicht kommt.
Und Open-Source bietet mehr als alle anderen Entwicklungsmodelle die Möglichkeit an der Entwicklung zu partizipieren. Jeder hat die Möglichkeit sich einzubringen und/oder sich auch sich mit anderen zusammentun, die die gleichen Featurewünsche haben und sich dann zu überlegen, wie man das realisieren könnte.
Nur rumzujammern ob der "blöden" Waylandentwickler ist mir da ehrlich gesagt ein wenig dünn.
Bigfoot29 schrieb:
Aber dazu müssen die Jungs wohl erstmal selber das System - auch hier wieder nach Jahren - stabil genug bekommen. Andererseits darf man bei Wayland auch nicht vergessen: Das machen einige Jungs zwar in Anstellungsverhältnis, aber viele auch freiwillig. Und ich habe immer gesagt, dass ich auf Wayland nicht wirklich rumhacke, weil sie sich zumindest anbieter-unabhängig Mühe geben. (Und sie haben meinen Respekt, dass sie damals nVidia den Mittelfinger gezeigt haben. )
Ja. :-)
Möglicherweise läuft es ja auch eher auf eine Koexistenz von X.org und Wayland hinaus. Auf absehbare Zeit wird es eh so sein und danach .... gibts dann sicherlich auch für solche Fälle wie Netzwerktransparenz ausgereifte Lösungen.
Dann siehts so aus:
Wem Wayland reicht, der greift dazu (gerade auf Enduser-Desktops oder Small-Devices a-la Tablet wird das so sein und schon vor allem Ressourcen/Akku). Wer volle X.org-Power benötigt, greift halt weiterhin zu X.org.
Insofern würde ich da ohnehin noch relativ entspannt sein.
Bigfoot29 schrieb:
Zu "Snap"s: Und da liegt der Hase im Pfeffer: Ubuntu nutzt halt Snaps und kein anderes, weniger gefährliches System. Und das sogar in der Basis-Installation bzw. lässt zu, dass bestehende Basis-Tools auf Snaps umgestellt werden.
Gut. ubuntu dachte ja auch mal, upstart wäre ne gute Idee (und ist dann doch wieder davon weg). ubuntu dachte auch mal, Wayland ist nicht zu gut wie machen Mir.
Insofern muss man sich vielleicht gar nicht so viel Sorgen machen, wenn ubuntu wieder mal ein Alleingang macht. Denn wenn einer inzwischen Know-How angesammelt hat solche Sachen in den Sand zu setzen, dann sind es die ubuntu-Leute. :-)
Und nicht zuletzt spricht ja nix dagegen z.B. Flatpak auch unter ubuntu einzusetzen.
Bigfoot29 schrieb:
Programme kann man auch heute problemlos testen, wenn sie sich an die Regularien halten und sich schlicht mit User-Rechten ins User-Verzeichnis installieren lassen würden (oder gleich eine sauberes OOtB-Archiv mitbrächten, wie einige Programme auch heute schon zeigen, dass es ginge).
Klar gibs auch Alternativen dazu. Flatpak versucht halt ein paar gute Sachen zu vereinen.
Bigfoot29 schrieb:
Auch zeigen ZFS, XFS(?) und soweit ich weiß auch btrfs, dass inline-Snapshots durchaus möglich sind und man auch auf diese Weise eine fehlerhafte oder ungewollte Paketinstallation problemlos wieder loswerden kann.
Ja. Dateisysteme mit Snapshots sind ne feine Sache.
Bigfoot29 schrieb:
Und so weh mir das tut: Das Sicherheitskonzept unter Linux ist ein Chaos. Wir haben Datei-Berechtigungen, die nur auf Userebene und Gruppen funktioniert, aber nicht den Zugriff mehrerer Einzeluser erlaubt, ohne dass man diese User in Gruppen packt, wir haben ein halbes Dutzend Sicherheits-Systeme im Kernel, die seit 10 Jahren nicht fertig werden und stattdessen immer neue Implementierungen hinzugefügt werden, die Einzel-Probleme adressieren, die dann von den Software-Entwicklern wieder berücksichtigt werden müssen, wir haben einen Kernel-Maintainer, der Sicherheitsupdates wie Feature-Updates behandelt... die Liste ließe sich unendlich fortsetzen.
Da hast Du absolut Recht und sprichst mir sozusagen aus der Seele. Schon vor Jahren hab ich da mit Linuxern diskutiert. Die sehen das natürlich völlig anders (selbst die, die einsehen, dass es Chaos ist, sehen das eben dann als Wettbewerb der Ideen; kann man auch durchaus so sehen; für den Anwender ist es trotzdem Sch**ße).
Mit ganz oben auf der Liste die ich mir bei Linux wünschen würde ist ein durchdachtes und vor allem durchgängiges Sicherheitskonzept. Nun gut. Man muss auch sagen, dass Linux als UNIX-Klon eben auch viele Sachen ererbt hat. Die quasi schon mit dem erscheinen von Linux veraltet waren (Linux hätte ja die Chance gehabt schon vom Start weg alles besser zu machen; für ein freies UNIX gabs ja bereits BSD).
Man hätte auch was mit Microkernel machen können. Die Torvalds-Tanenbaum-Diskussion, da muss ich sagen, dass Tanenbaum natürlich recht hatte. Torvalds Sicht war verständlich. Ein monolithischer Kernel lässt sich leichter entwickeln ist ist zudem schneller. Nur gerade durch die Hardwareentwicklung ist Performance weitestgehend obsolet geworden.
Ein Linux mit Microkernel wäre heut weit besser aufgestellt. Auch Sicherheitsmäßig.
Aber ich schweife etwas ab.
Ansonsten. Ja. Die vielen sich überschneidenen Sicherheitsframeworks/-konzepte sind schön. Auch hier wieder das Problem der Volatilität. Arbeitet man sich irgendwo ein, weiß man nicht, obs in zwei Jahren noch weiter entwickelt wird.
Bigfoot29 schrieb:
Das einzig halbwegs sichere Linux-OS ist "Qubes OS", weil es die Anwndungen halt gleich in ganze eigene VMs auslagert.
Ja. Qubes OS ist eine interessante Geschichte. Zumindest insofern, dass es zeigt, was sich aus Linux sicherheitstechnisch rausholen lässt. Trotzdem kann ich mich nicht so mit dem Gedanken anfreunden für jede Domäne quasi eine eigene VM zu haben. VMs sind einfach zu schwergewichtig. Ich bin generell aber etwas kritisch zum Thema VMs eingestellt.
VMs können ne gute Möglichkeit sein Systeme zu virtualisieren und abzutrennen. Aber die Notwendigkeit sehe ich in der UNIX-Welt eher weniger. Weil man da traditionell schon immer mehr darauf geachtet hat, dass Prozesse sauber getrennt sind (anders als in der Windows-Welt, wo VMs eine enorme Verbesserung bedeuten, wenn man sich dann schon mit Windows abquälen muss *g*).
Auch den ganzen Docker-Kram sehe ich eher zwiegespalten. Vermutlich auch hervorgerufen durch den Mis-use. Es wird eben gerne für Sachen eingesetzt, wo ich es lieber bleiben lassen würde. So ähnlich ist es auch mit VMs.
Sicherheit hängt unmittelbar mit der Komplexität des Systems zusammen. Umso komplexer ein System ist, umso mehr mögliche Fehlerstellen und damit potentielle Sicherheitslücken gibt es auch. Und VM bringen eben relativ viel Komplexität mit rein. Und dann muss man immer gucken, ob es unterm Strich etwas bringt.
Bigfoot29 schrieb:
Und das Konzept dort braucht so eine halbgare Lösung wie "Snap" nun definitiv nicht. Bei allen anderen Lösungen spachtelt man nur etwas mehr Farbe über die Ruine, die beim kleinsten Sturm umfallen wird und die bisher nur das Glück hatte, dass es bislang wenig Stürme gab und wenn, dann recht schnell die gröbsten Risse gekittet wurden.
Ja. Das Bild wird auch immer etwas verzerrt. Der "Blackhat" der auf fiese Weise Sicherheitslücken ausnutzen will, der nimmt natürlich auch erstmal den bequemsten Weg.
Und solange es erfolgreich genug ist, wenn man SPAM-Mails verschickt a-la "Wegen eines Softwarefehlers müssen sie ihr Passwort bestätigen: Gehen sie dazu auf xyz" so lange ist halt auch der Antrieb relativ gering, irgendwelche Lücken zu suchen und auf raffinierte Weise zu nutzen (oder man hält sich das eben für Bereiche vor, wo man es braucht wie Spionage u.ä.).
Dadurch ist die Gefahr nicht unbedingt sichtbar. Jeder kann gegenüber Kritikern zurecht darauf verweisen: "Ich weiß gar nicht was ihr habt. Bisher gabs noch nicht ein erfolgreichen Angriff".
Es muss halt erst wieder das Kind in den Brunnen fallen, bevor sich was bewegt. Hat man ja auch wieder schön an Meltdown/Spectre bestaunen können. Kritiker haben schon immer moniert, dass es keine gute Idee ist, Kernel-Pages in den Userprozess-Adressraum einzublenden. Wurde aber doch gemacht, weil: Programm läuft schneller.
Tja. Und nu mussten sie es halt doch machen. Und wer weiß, wie lange die Lücken schon in gewissen Kreisen bekannt waren. Das da theoretisch ein Problem mit dieser Art von CPU-Mikroarchitektur bestehen könnte, ist ja schon seit Jahren bekannt. Meltdown und Spectre sind ja lediglich konkrete Angriffswege die sich aus der Grundproblematik ergeben.
Bigfoot29 schrieb:
Ich setze als Betriebssystem auch Linux ein. Ubuntu insbesonders. Weil es eines der besseren Lösungen war, wenn man sich aus den schlechten Alternativen die beste auswählen muss.
Was mich ja ein wenig verwundert. :-)
Aus meiner Sicht ist ja ubuntu eher so das Einsteiger-Linux. Wenn man dann in der Linux-Welt heimisch geworden ist, nimmt man was Anderes. Wenn man den Debian-Style mag halt dann das Original Debian Linux.
Bigfoot29 schrieb:
Aber wenn man sich historisch anschaut, wo Linux her kam, was man damals schon hatte und was man seitdem nicht konsequent weiterentwickelt sondern verschlimmbessert hat, kommt einem schlicht das Heulen.
Ja. Wie gesagt: Ich bin inzwischen ja so weit, dass Linux nicht mehr unbedingt das bevorzugte System ist. Andere Mütter haben halt auch schöne Töchter. Außerdem profitieren von der Bewahrung gewisser Diversität letztlich immer alle.
Linux hat sich als hochflexibel erwiesen und ist trotzdem eben nicht das System für alle und für alle Anwendungsszenarien.
Gruß
Andy
Ergänzung ()
Bigfoot29 schrieb:
Andererseits lernt man an den Unis oft, dass es halt Betriebssysteme gibt, die für die eigenen Anwendungen und Anwendungszwecke viel praktikabler sein können.
Wobei das sehr abgenommen hat. Vor 20 Jahren war es tatsächlich noch so, dass die meisten Rechner irgendwelche UNIX-Kisten waren. Klar gab es auch nen Windows-Pool oder ein Mac-Pool. Aber das Gros der Rechner war eben irgendein UNIX.
Heutzutage haben die Windows-Rechner deutlich zugenommen. Aber es passt ins Bild. Als Lehrprogrammiersprache wird häufig Java eingesetzt, die ich als Lehrsprache eher für suboptimal halte. Aber es ist eben der Trend sich der Wirtschaft zu nähern.
Man kann das befürworten. Ich sehe es eher skeptisch. Nicht zuletzt, weil es bisher gerade ein Pluspunkt der Unis war nicht dem Diktat der Wirtschaft unterworfen zu sein und man auch Dinge lernen konnte und sollte, die nicht in irgendeiner Weise unmittelbar Profit abwerfen. Man konnte sich weiter außerhalb des Mainstreams bewegen. Und gerade da entstehen ja die Sachen, die wirklich Fortschritt bringen. Und das geht mir so ein wenig unter. Ich will jetzt nicht schwarzmalen oder so. Und es ist ja auch nur mein subjektives Empfinden.
Wem Wayland reicht, der greift dazu (gerade auf Enduser-Desktops oder Small-Devices a-la Tablet wird das so sein und schon vor allem Ressourcen/Akku). Wer volle X.org-Power benötigt, greift halt weiterhin zu X.org.
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...
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. 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? Bisher hol ich mir da wie gesagt den virt-manager per SSH X-Forwarding auf den Client. Sowas wie die Admin-Tools von VMware wären nicht schlecht ;-)
andy_m4 schrieb:
Auch den ganzen Docker-Kram sehe ich eher zwiegespalten. Vermutlich auch hervorgerufen durch den Mis-use. Es wird eben gerne für Sachen eingesetzt, wo ich es lieber bleiben lassen würde. So ähnlich ist es auch mit VMs.
)
