Siehst du, du lernst nicht aus und deswegen sollte man /home Repos meiden…
Sogar mein /home Repo.
Aber das sag ich ja schon die ganze Zeit.
3 Likes
Yast war immer das was SuSE ausgezeichnet hat.
Beispiel Samba Freigabe:
Yast kümmert sich um alles, vor allem bei SELinux echt nett. Was habe ich bei Fedora schon geflucht wegen dieser unsinnigen Syntax von SELinux.
Der wirkliche Charme von Windows ist das man alles wichtige mit der Maus machen kann, Yast war schon immer der gelungenste Gegenentwurf, egal was die Shell Gurus erzählen…
Auch wenn die DEs inzwischen vieles können…
3 Likes
Cockpit hat auch ein Modul für Samba-Konfiguration, soviel ich weiß.
1 Like
Yast ist und bleibt einfach state of the art - auch wenn leider diverse Funktionen inzwischen weggefallen sind. Da kommen cockpit und Dein Myrlin nicht mit! Es gibt derzeit keine wirkliche Alternative zu Yast - und Yast war dereinst eines der herausragenden Argumente für Suse/OpenSuse!
2 Likes
LOL - Myrlyn ist nichts anderes als der Code von YaST2 sw_single, aus YaST herausoperiert (plus ein paar Dutzend Bugfixes und der Code, um Repos zu laden und die Transaktion durchzuführen). Das steht auch so ganz klar auf der Projekt-Homepage.
Es sollte auch niemals ein Ersatz für all die anderen YaST-Module sein, von denen die allermeisten inzwischen überflüssig sind, wie oben erklärt.
3 Likes
Ich möchte mich hier ausdrücklich bei shundhammer für Myrlyn bedanken. Es ist bis auf die fehlende Übersetzung ein mindestens gleichwertiger Ersatz für die YaST Paketverwaltung.
Die Frontends für PackageKit sind wegen mangelnder Features keine Alternative, sondern eher ein Spielzeug und so sehen sie auch aus.
Die kritischen Stimmen zu Myrlyn kann ich auch deshalb nicht nachvollziehen, weil kaum eine andere Distribution eine graphische Paketverwaltung bietet, die die Möglichkeiten der Kommandozeile so weitgehend abbildet.
2 Likes
Leider kommt die Kritik oft von Leuten die sich mit dem Thema nie wirklich richtig beschäftigt haben. Oder irgend ein obsoletes YaST Modul zum letzten Mal vor 20 Jahren verwendet haben und jetzt rumnölen weil es endlich beerdigt wird (und es seit 15 Jahren eh nicht mehr funktioniert). Ist aber leider oft so…
Da gab es im englischen Forum einen Thread (neben unzähligen anderen), welcher auflistet dass YaST an sich obsolet ist, da 99% der Funktionen von andern Werkzeugen übernommen wird.
2 Likes
Leider kommt die Kritik oft von Leuten die sich mit dem Thema nie wirklich richtig beschäftigt haben. Oder irgend ein obsoletes YaST Modul zum letzten Mal vor 20 Jahren verwendet haben und jetzt rumnölen weil es endlich beerdigt wird (und es seit 15 Jahren eh nicht mehr funktioniert). Ist aber leider oft so…
Da gab es im englischen Forum einen Thread (neben unzähligen anderen), welcher auflistet dass YaST an sich obsolet ist, da 99% der Funktionen von andern Werkzeugen übernommen wird.
Und Myrlyn ist geil. Schon allein deshalb weil es das kann was YaST Software nie konnte: zypper dup
P.S.: Forum Software scheint manchmal zu zicken…deshalb der doppelte Beitrag.
2 Likes
Es sollte ein OpenYAST gestartet werden unabhängdig und alle LINUX disros !
Das ist aus mehreren Gründen unrealistisch:
-
Wer sollte das tun? Wer hat all das Wissen dazu? Wer hat die Zeit dazu?
Das ist nichts, was man mal so nebenher machen kann. YaST2 wurde seit Ende 1999 entwickelt, veröffentlicht im Mai 2000 mit SuSE Linux 6.4. Das YaST-Team hatte seit Anfang 2000 ca. 10 Entwickler, zwischendurch ca. 15, seit den letzten Jahren 12. D.h. es stecken ca. 12*25 = 300 Mannjahre Entwicklungszeit darin. Das sind auch für eine gut laufende Firma ansehnliche Kosten.
Das macht niemand nach Feierabend, und bezahlen will es auch niemand.
-
Ein Admin-Werkzeug für alle Distributionen - das klingt utopisch und wird es wohl auch bleiben. Cockpit geht in diese Richtung, aber es muß eben immer wieder verallgemeinern, so daß manche Spezialsachen der Distros auf der Strecke bleiben. Die Stärke von YaST war ja immer, daß es genau auf SUSE zugeschnitten war; das wäre es dann nicht mehr.
-
Den vorhandenen YaST2 als Basis nehmen? Klar, kann man; wenn man sich entsprechend einarbeitet, was auch schon verdammt zeitaufwendig ist. Und trotzdem wird man immer wieder mit
grep -Ri sonstwas ~/src/yast/*suchen und rätseln müssen. Kann man tun, macht aber keinen Spaß.Und dann hat man noch lange keinen YaST für alle Distros, nur für SUSE.
-
YaST oder irgendwelche anderen Admin-Werkzeuge zu pflegen, Bugs zu fixen, Bug-Reports zu bearbeiten ist nicht sexy. Das macht niemand freiwillig; nur gegen entsprechendes Schmerzensgeld.
Die ersten Bestrebungen, YaST für eine Entwickler-Community zu öffnen, gehen zurück bis ca. 2004 oder so. Die Handvoll Community-Entwickler, die das auch getan haben, kenne ich alle persönlich. Ist noch jemand davon übriggeblieben? Ich glaube nicht.
Und dafür haben wir uns ewige Zeiten den Arsch auf gerissen, Doku zu schreiben, hochoffizielle APIs einzuführen, Tutorials zu schreiben und sonstwas; alles für die Katz’. Das hat niemanden interessiert.
Und man darf nicht vergessen, daß man auch das alles pflegen muß; veraltete Doku ist viel schlechter als gar keine Doku, weil sie vorspiegelt, daß Sachen beschrieben sind, und in Wirklichkeit stimmt das alles schon lange nicht mehr.
Es ist bezeichnend, daß es im Lauf der Zeit ca. viermal so viele neue Chat-Clients von der Community gab als neue YaST-Module. Chat-Clients galten lange als sexy; YaST-Module nicht.
-
Wie lange würde so ein Projekt aktiv am Laufen gehalten werden? Auch wenn es ein paar gutmütige Entwickler gäbe, die so etwas anstoßen, wie lange würden die durchhalten, bis sie es frustriert hinschmeißen?
Seit Anbeginn aller (YaST2-) Zeiten war YaST2-Bashing schick; nicht zuletzt von innerhalb SUSE. Am Anfang denkt man sich seinen Teil, dann antwortet man auf den Mailing-Listen, auf denen man schon wieder mal von der Seite angekackt wurde, irgendwann denkt man nur noch frustriert “was für ein arroganter, toxischer Haufen”. Und irgendwann wird es eben zuviel, und man sucht sich eine andere Spielwiese.
Wer macht dann die Arbeit?
6 Likes
korrekt, Yast hat immer SuSE und später SUSE und openSUSE ausgezeichnet, leider denken viele nur an moderne und laufende Rechner mit einer UI, sicherlich, da gibt es für, ich denke alles, irgendwelche Alternativen, sicherlich, Cockpit hat unter openSUSE auch so einige Funktionen, wenn ich es richtig gesehen habe mehr als unter anderen Distros, auch wenn es z.B. eine offene Firewall oder was auch immer für “Klimmzüge” zur Absicherung erfordert, aber ich bin z.B. bei der Partitionierung geplatzt weil es halt nicht die Möglichkeiten aus Yast gibt, und nein, weder GParted, noch die Partitionverwaltung etc. stehen hier zur Verfügung da es ein Minimalsystem ohne UI auf aarch64 ist.
Ich habe dann zum Schluss frustriert die fstab und crypttab auf einem anderen Gerät bearbeitet um wieder zu booten.
Eine UI und auch Cockpit benötigen aber immer einen Rechner mit einer ziemlich großen Paketinstallation mit dem entsprechenden Ressourcen um eine Grafische Oberfläche zu haben bzw. evtl. einen 2. Rechner mit einem Browser zum Einrichten, von der Absicherung abgesehen.
Leider ist keine der Lösungen so richtig z.B. für kleine Geräte ohne UI oder ohne Netzwerk bzw. mit nicht korrekt eingerichteten Netzwerk oder z.B. “gecrashter” Grafik zu nutzen.
Es sind auch noch genug “alte” Geräte im Umlauf, da Yastmodule einfach als obsolet zu nennen ist aus meiner Sicht auch nicht ganz ok, selbst Modems haben z.B. im FAX oder Funkbereich noch ihr dasein und sind dort nicht einmal gering verbreitet.
Wenn eine Person oder von mir aus 100 etwas nicht mehr benötigen heißt noch lange nicht das es nicht noch anderen Personen gibt welche es nutzen.
Ich benötige, zumindest privat, im Augenblick keine Windowsunterstützung, für mich ist z.B. Samba und der Domänencontroller im privaten unnötig, könnten also raus, ich weiß aber das vermutlich Millionen, oder mehr, anderer Personen das benötigen, genauso wie es im Firmenumfeld benötigt wird, also darf ich es nicht als unnütz abstempeln.
Für defekte Geräte ist z.B. ein TFTP Server interessant, sicherlich nicht Millionen Personen welche das benötigen aber auch für so einige nicht unnütz, sicherlich auch ich habe jetzt x Jahre keinen TFTP Server gebraucht aber noch Geräte im Einsatz wo er bei Problemen, welche hoffentlich nie wieder auftreten, mit hoher Wahrscheinlichkeit benötigt wird.
Ich habe das jetzt x Wochen mit diversen Installationen auf diversen Systemen und Containern ohne Yast probiert, openSUSE bzw. Suse begeben sich damit in die Reihe aller anderen Distros, sicherlich, openSUSE ist zu anderen Distros immer noch komfortabel, selbst auf der Kommandozeile, aber es ist kein Vergleich ohne Yast, das ist von der usability ein Schritt zurück in das letzte Jahrtausend.
Natürlich ist Entwicklung nicht einfach, wenn man es als Hobby macht und es zum Zwang wird noch weniger, ich habe dafür auch aus beruflicher und privater Sicht Verständnis.
Sicherlich, man kann nicht alle Leute zufrieden Stellen, es gibt auch jede Menge unangenehme Personen über deren Hintergrund ich lieber nicht nachdenke, auch da habe ich meine Erfahrung.
Aber im Sinne der Distro denke ich nicht dass das eine sehr kluge Entscheidung war, hier wäre aus meiner Sicht vielleicht eher mehr Marketing für das Alleinstellungsmerkmal Yast besser gewesen.
1 Like
Werkzeuge wie YaST2 sind meines Erachtens Segen und Fluch zugleich.
Ende 2000 habe ich meine ersten Schritte mit SuSe Linux Professional 7.1 (?) unternommen und war, nach zehn Jahren MS-DOS/MS-Windows, zunächst froh in YaST2 ein GUI-Werkzeug zu haben, das mir erlaubte alle notwendigen Aufgaben der Systemadministration zu erledigen.
Aber als ich dann Ende 2004 (immer noch ein Linux-Greenhorn) Ubuntus Warty Warthog ausprobieren wollte, kam das böse Erwachen:
- Wie konfiguriere ich mein Netzwerk?
- Wie lege ich Benutzer an?
- Wie installiere ich Software?
- …
Um so etwas nicht noch einmal erleben zu müssen, habe ich mir angewöhnt, Werkzeuge wie YaST2 (“wrapper”) möglichst zu meiden.
1 Like
Darum geht es meines Erachtens überhaupt nicht. Yast war die zentrale Kommandozentrale für SuSE/openSUSE. Und das war ein einzigartiger Vorteil von SuSE/openSUSE, das hatte in dieser Form keine andere Distri! Dass es scheibchenweise andere Möglichkeiten gab, das System zu managen, ist eine andere Frage.
Klar, über die Jahre entfielen Modulfunktionen, weil sie nicht weiter entwickelt wurden. Wären sie weiter entwickelt worden, wäre Yast weiterhin unschlagbar und es bedürfte der anderen Möglichkeiten nicht, das System zu administrieren.
Und dass es für eine “Kommandozentrale” ein Bedürfnis gibt, beweist ja gerade auch die Entwicklung von Cockpit - nur das Cockpit gegenwärtig nicht ansatzweise das kann, was Yast derzeit konnte.
Was ich nicht beurteilen kann: Offensichtlich ist Yast auf Qt5 angewiesen (könnte man wahrscheinlich an Qt6 anpassen) und Ruby scheint ein Problem zu sein. Andererseits: Wenn ich sehe, dass das Software-Modul von Yast zu Myrlin weiter entwickelt werden konnte (dafür Dank an shundhammer - wo bleibt eigentlich die Übersetzung ins Deutsche 
???), bleibt die Frage, weshalb das nicht für die übrigen Module klappen sollte! Aber bitte: Ich kann das alles nicht und konsumiere nur openSUSE und seine Produkte! Und andere finden sich offensichtlich nicht!
Und von daher: Yast ist unschlagbar, schade, dass es das nicht mehr geben wird!
Ach ja, zu Myrlin: Da gibt es schon den einen oder anderen Nachteil im Verhältnis zu Yast!
2 Likes
Ach ja, der Vorschlag von Svenunglaube: Es legt den Finger in die Wunde! Die Vielzahl von Distris unter Linux - die leider viele der Nutzer der proprietären System von einem Wechsel abhält! Es wäre schön, wenn man sich unter Linux auf Standards besser verständigen könnte, dazu gehörte dann vielleicht auch die Fähigkeit, eine einheitliche Kommandozentrale für die Verwaltung der eigenen Distribution zu schaffen. Derzeit zerfleddern die Systeme eher noch weiter.
1 Like
Was für ein Unsinnn. Wie bereits mehrfach von Stefan in diversen Threads erklärt, ist Myrlyn kein Ersatz für YaST. Myrlyn ist die Weiterentwicklung für das YaST Software Modul. Myrlyn hat einige entscheidende Vorteile zum alten YaST Software Modul. Aber damit muss man sich halt mal beschäftigen und auch den Unterschied zwischen “YaST” und einzelnen “YaST Modulen” verstehen.
Eine minimale Suche bringt erstaunliches hervor… Freiwillige vor.
3 Likes
Anstatt wie SVENUNGLAUBE unrealistische Forderungen in Fettdruck zu stellen oder wie matbhm Nachteile bei Myrlyn zu finden, die dann aber nicht konkretisiert werden, sollte man die Realitäten sehen, die shundhammer benannt hat und als YaST Entwickler besser als jeder User kennen sollte. Die sind nun mal, dass YaST tot ist und wenigstens die Paketverwaltung in Form von Myrlyn dank shundhammer’s Freizeit Engagement überlebt hat.
6 Likes
Also das muss ich ja mal loswerden, meine Hochachtung das man sich im Jahr 2026 freiwillig mit der Kommandozeile und Konfigurationsdateien auseinandersetzt aber selbst für mich in meiner Tätigkeit als Admin gehört das nicht mehr in dieses Jahrtausend auch wenn es leider oftmals keine andere Möglichkeit gibt.
Ich greife gerne zu jeder Minimal-UI, falls es die dann gibt, weil in der Regel da auch die derzeitigen Einstellungen als Anzeige vorliegen und man auch evtl. Konfigurationsfehler schneller sieht.
1 Like
Das sind dann solche Admins die grandios scheitern, wenn mal die GUI gecrasht ist. 
3 Likes
Was aber gar wohl in dieses Jahrtausend gehört ist, dass ein Systemadminstrator die von ihm betreuten Systeme jederzeit und für alle Anwendungsfälle optimal konfiguriert und dabei trotzdem (kosten-)effizient arbeitet.
Es gibt durchaus rationale/wirtschaftliche Gründe auf Kommandozeile und Konfigurationsdateien zurück zugreifen:
-
Der Bau einer GUI-Applikation, die das Potential einer Anwendung voll auszuschöpfen vermag, ist oft wirtschaftlich nicht vertretbar. Wer sich die Dokumentation von z.B. SAMBA oder NetworkManager einmal durch liest, der wird schnell erkennen, dass die zur Konfiguration verfügbaren GUI-Applikationen nur einen (kleinen) Teil der möglichen Konfigurationsvarianten abdecken.
-
Eine GUI-Applikation zur Anwendungskonfiguration muss kontinuierlich mit der Entwicklung der Anwendung synchronisiert bleiben. Das ist oft nicht umsetzbar (und verursacht weitere Kosten).
-
Jede GUI-Applikation zur Anwendungskonfiguration stellt eine weitere Ebene und somit zusätzliches Fehlerpotential dar. Da Fehlersuche in GUI-Applikationen meist deutlich komplexer und arbeitsaufwändiger ist, als die Fehlersuche in Konfigurationsdateien entstehen auch hier wieder zusätzliche Kosten.
-
Die Nachverfolgung von Konfigurationsänderungen gestaltet sich bei der Verwendung von GUI-Applikation zur Anwendungskonfiguration aufwändiger (mehr Kosten) als bei der manuellen Änderung von Konfigurationsdateien mit einem Texteditor.
Der negativste Aspekt an einer GUI-Applikation zur Anwendungskonfiguration ist meiner Meinung nach jedoch die Abhängigkeit, die sie (bei ausschließlicher Verwendung) erzeugt.
Das ist mir bei meinem Abstecher zur “Warty Warthog” im Jahr 2004 schmerzhaft bewusst geworden. Und die Tatsache, dass das vorliegende Thema existiert, ist letztendlich auch ein weiterer Beweis dafür.
3 Likes
Das ist ein sehr guter und wichtiger Punkt, und genau daran scheiden sich die Geister: YaST hatte ja immer den Ansatz, 90% (oder zumindest 80%) der Normalfälle abzudecken; meistens ist es ja ein Fall von “das kann ja nicht so schwer sein, XY zu konfigurieren”. Samba-Server oder -Client sind in der Regel ziemlich einfach, genauso NFS-Server oder Client; die meisten Dienste, für die es ein YaST-Modul gibt (oder gab), sind ja so.
Man kann damit ziemlich schnell mit wenig Aufwand sehr viele Benutzer glücklich machen, die sich vorher nie vorgestellt hatten, daß sie mal ihren eigenen Samba- oder Druck-Server aufsetzen würden, der alle PCs zuhause, in der Kleinfirma oder im Vereinsheim bedienen konnte.
Und dann war da noch die einstellige, aber unvermeidliche Anzahl der Klugscheißer, die irgendeinen völlig abstruse Anwendungsfall hatte, und natürlich damit in Bugzilla vorstellig wurden. Und schon kann man für die restlichen 10% der Fälle und die 3% der Anwender, die solche Fälle haben, nochmal den gleichen oder gar den doppelten Aufwand betreiben, das auch noch abzudecken; nur um sich ein Dreivierteljahr später, wenn endlich Zeit war, das auch zu implementieren, anzuhören, daß man ja als begnadeter Distro-Hopper gleich nach dem Bug-Report zu SchlonzOS oder WrglBrmpfLinux gewechselt ist, wo das (aber nur das) einfach so funktioniert.
Und wenn man das eingebaut hat, muß man es ja auch pflegen. Man muß selber den Testaufbau haben, damit man das überhaupt jemals in Aktion sehen kann. Und wenn jemand anders kommt, der einen Fehler entdeckt, muß man sich auch darum wieder kümmern. Und wenn der, der das geschrieben hat und sich damit auskennt, das Team oder gar die Firma verläßt, muß sich ein anderer armer Tropf einarbeiten.
Kann man alles machen, aber das ist eine völlige Fehlinvestition; für so viel Entwickleraufwand kann man ganz andere Probleme lösen, die viel mehr Benutzern helfen.
Wir hätten so etwas schon viel früher im Keim ersticken sollen; “es ist für die 90% Allerweltsbenutzer gedacht, die den Normalfall haben, nicht für Nerds mit ihrem Spezialfall; lies die Doku und ändere eben mal eine Konfigurationsdatei per Hand” finde ich eine faire Aussage.
Aber irgendwer (typischerweise im Haus; jemand, der das nicht selber machen mußte) kam immer mit einem Totschlagargument wie “aber wir wollen doch das beste Linux aller Zeiten bauen!” (selber mehr als einmal erlebt). Also verballert man die knappen Entwicklerkapazitäten für Nischenprobleme.
Da bleibt kein Raum mehr für Kreativität oder echte Innovation; das ist nur noch stumpfes Features Abhaken.
Ja, eben. Die YaST-Entwickler sind Experten für YaST und interessierte Amateure auf allen möglichen Spezialgebieten. Man kann nicht Experte für alle Subsysteme einer Linux-Distribution und gleichzeitig Experte für YaST-Infrastruktur und YaST-UI sein.
Es ist realistisch, die 90% für irgendein Subsystem abzudecken, wenn man sich ein bißchen eingelesen hat und ein bißchen experimentiert; dann weiß man, welche Konfigurationsdateien man wie generieren kann.
Rückwärts sieht es schon wieder anders aus: Ein /etc/sudoers anhand von ein paar wenigen Eingaben zu schreiben, ist einfach. Aber das auch wieder einzulesen und korrekt (!) und allgemeingültig (!!) zu parsen, um das wieder im gleichen Eingabeformular darzustellen, das geht schlicht nicht (und das ist auch der Grund, warum das YaST sudo-Modul wieder beerdigt wurde).
Alles, was über die 80-90% hinausgeht, ist ein Faß ohne Boden; das ist der Versuch, die Welt-Formel in Code zu gießen (das Ergebnis ist natürlich 42).
5 Likes