Am 17.02.23 um 20:08 schrieb Christian Boltz in Re: ALP (was: Re: Monitorkalibrierung):
- ein paar SUSE-Entwickler haben in der Hackweek daran gearbeitet, auf Basis von ALP eine "traditionelle" Distribution zu bauen. Die ist wohl ähnlich wie Leap, wenn auch bisher mit weniger Paketen. Details: https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll - von einem anderen SUSE-Entwickler kam ein Hinweis, dass ALP eine Platform ist und daraus mehrere Produkte entstehen können/werden. Auch da kam ein Hinweis, dass eins dieser Produkte eine "traditionelle" Distribution sein könnte.
Uns so wird es IMHO wohl auch (hoffentlich) kommen. Ein openSUSE ohne die von so vielen (stillen Usern) genutzte Desktop-Oberfläche wäre ein herber Verlust für SUSE. Diese User würden schnell auf eine andere Distribution wechseln ("Ich brauche nur was um unkompliziert zu arbeiten ..."). Und dann wäre Schritt für Schritt auch die Migration der Systeme die von diesen Usern betreut werden, eingeleitet. Die Idee hinter ALP finde ich bestechend. Aber es muss eben Images geben die als Container problemlos die bisherigen Versionen fortschreiben. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am Samstag, 18. Februar 2023, 10:08:43 CET schrieb Bernd Nachtigall:
Am 17.02.23 um 20:08 schrieb Christian Boltz in Re: ALP (was: Re:
Monitorkalibrierung):
- ein paar SUSE-Entwickler haben in der Hackweek daran gearbeitet, auf Basis von ALP eine "traditionelle" Distribution zu bauen. Die ist wohl ähnlich wie Leap, wenn auch bisher mit weniger Paketen. Details: https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll - von einem anderen SUSE-Entwickler kam ein Hinweis, dass ALP eine Platform ist und daraus mehrere Produkte entstehen können/werden. Auch da kam ein Hinweis, dass eins dieser Produkte eine "traditionelle" Distribution sein könnte.
Uns so wird es IMHO wohl auch (hoffentlich) kommen. Ein openSUSE ohne die von so vielen (stillen Usern) genutzte Desktop-Oberfläche wäre ein herber Verlust für SUSE. Diese User würden schnell auf eine andere Distribution wechseln ("Ich brauche nur was um unkompliziert zu arbeiten ..."). Und dann wäre Schritt für Schritt auch die Migration der Systeme die von diesen Usern betreut werden, eingeleitet.
Die Idee hinter ALP finde ich bestechend. Aber es muss eben Images geben die als Container problemlos die bisherigen Versionen fortschreiben.
Also. Damit ich das richtig verstehe. Ohne Polemik. Hier ein paar Fragen. ALP und alles was aktuell und vielleicht später darauf beruht, beruht auf container? Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. ALP und alles was aktuell und vielleicht später darauf beruht ist immutable? Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. ALP und alles was aktuell und vielleicht später darauf beruht unterstützt, zumindest bis jetzt, nicht wirklich KDE? Das ist meiner Meinung nach nicht "suse-traditionell". Und das will ich nicht. Also andere Distri. ALP und alles was aktuelle und vielleicht später darauf beruhen müssen nach einem t-u _immer_ rebootet werden? Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. ALP und alles was aktuelle und vielleicht später darauf beruhen sollten nicht manuell upgedatet werden, sondern immer nur automatisch? Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. So. Das Ergebnis ist für mich eindeutig. Und auch im geschäftlichen Bereich spricht alles dagegen. Wenn also alles so kommt wie man zumindest bis jetzt rauslesen kann, gibt es nur eine Lösung. Andere Distri nach ca. 30 Jahren!. :-( Gruß Eric
Am 18.02.23 um 10:38 schrieb Eric Schirra:
Am Samstag, 18. Februar 2023, 10:08:43 CET schrieb Bernd Nachtigall:
Am 17.02.23 um 20:08 schrieb Christian Boltz in Re: ALP (was: Re:
Monitorkalibrierung):
- ein paar SUSE-Entwickler haben in der Hackweek daran gearbeitet, auf Basis von ALP eine "traditionelle" Distribution zu bauen. Die ist wohl ähnlich wie Leap, wenn auch bisher mit weniger Paketen. Details: https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll - von einem anderen SUSE-Entwickler kam ein Hinweis, dass ALP eine Platform ist und daraus mehrere Produkte entstehen können/werden. Auch da kam ein Hinweis, dass eins dieser Produkte eine "traditionelle" Distribution sein könnte.
Uns so wird es IMHO wohl auch (hoffentlich) kommen. Ein openSUSE ohne die von so vielen (stillen Usern) genutzte Desktop-Oberfläche wäre ein herber Verlust für SUSE. Diese User würden schnell auf eine andere Distribution wechseln ("Ich brauche nur was um unkompliziert zu arbeiten ..."). Und dann wäre Schritt für Schritt auch die Migration der Systeme die von diesen Usern betreut werden, eingeleitet.
Die Idee hinter ALP finde ich bestechend. Aber es muss eben Images geben die als Container problemlos die bisherigen Versionen fortschreiben.
Also. Damit ich das richtig verstehe. Ohne Polemik. Hier ein paar Fragen.
ALP und alles was aktuell und vielleicht später darauf beruht, beruht auf container? So wie ich das (bisher) verstehe ist ALP nur ein Minimalsystem was mit Containern je nach Bedarf erweitert wird. Ich setze jetzt schon Distributionen ein die einen Teil ihrer Funktionalität in Containern ausführen. Läuft einwandfrei und ist (durch den Hersteller) leicht zu warten. Zudem laufen die Teile die in den Containern überall wo Container laufen können. Also auch in der hochgelobten Cloud (örgs, aber man kann ja eine Docker-Umgebung auch selbst betreiben.)
[Refrain]
Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri.
ALP und alles was aktuell und vielleicht später darauf beruht ist immutable? Keine Ahnung. Frag jemanden der das weiß. Aber was wäre schlecht daran?
Snip Refrain
ALP und alles was aktuell und vielleicht später darauf beruht unterstützt, zumindest bis jetzt, nicht wirklich KDE? Ich denke es wird Container geben die die bisherige Desktop-Umgebung bereitstellen. Sollte die fehlen wäre es wirklich ein herber Verlust. Dann wäre ein openSUSE nicht mehr als Desktop-OS zu gebrauchen.
Snip Refrain
ALP und alles was aktuelle und vielleicht später darauf beruhen müssen nach einem t-u _immer_ rebootet werden? Eben das soll nach meinem Verständnis vermieden werden.
Snip Refrain
ALP und alles was aktuelle und vielleicht später darauf beruhen sollten nicht manuell upgedatet werden, sondern immer nur automatisch? ??
Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. Ja, das hast Du schon ein paarmal gesagt ...
Hört sich für mich ein wenig wie die Aufregung um/gegen/wegen systemd an. Das war auch ein ganz schrecklicher Eingriff in alles mögliche und das sichere Ende von Linux ... und läuft heute ganz vorzüglich.
So. Das Ergebnis ist für mich eindeutig. Und auch im geschäftlichen Bereich spricht alles dagegen. Im geschäftlichen Bereich? Da wird eingesetzt was sicher läuft und einen guten Support (1st-Level SUSE-Partner und 2nd-Level SUSE) bietet. (OK, außer bei M$, das wird eingesetzt weil alle glauben sie hätten keine andere Möglichkeit.)
Wenn also alles so kommt wie man zumindest bis jetzt rauslesen kann, gibt es nur eine Lösung. Andere Distri nach ca. 30 Jahren!. :-( Ich weiß nicht was du da rauslesen kannst, ich warte mal ab.
Denn, wie hat schon Karl Valentin gesagt? "Prognosen sind schwierig, vor allem wenn sie die Zukunft betreffen." In diesem Sinne, es bleibt spannend. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Bernd Nachtigall schrieb:
ALP und alles was aktuell und vielleicht später darauf beruht unterstützt, zumindest bis jetzt, nicht wirklich KDE? Ich denke es wird Container geben die die bisherige Desktop-Umgebung bereitstellen. Sollte die fehlen wäre es wirklich ein herber Verlust. Dann wäre ein openSUSE nicht mehr als Desktop-OS zu gebrauchen.
Also in meiner MicroOS-VM *läuft* KDE und zwar letztendlich das ganze KDE in einem eigenen Container (und das SDK in noch einem Container). manfred@localhost:~> flatpak --user list | grep KDE KDE Application Platform org.kde.Platform 5.15-21.08 KDE Software Development Kit org.kde.Sdk 5.15-22.08 Und es läuft sogar performant. Was im Moment nur mit vielen Klimmzügen geht ist (mal wieder) das Remote-Ausführen von X-Anwendungen, was ich nun mal gerne mache (zwischen verschiedenen VMs). Aber selbst das geht. Vieles geht aber noch nicht oder ich glaube zumindest, dass es nicht geht, weil ich dem Paradigmen-Wechsel noch nicht so recht folgen kann. Siehe die Sache mit dem Compiler, da war das auch erst so: Man muss erst mal auf die Idee kommen, dass man IRGENDEINE IDE als Container installieren muss, die man vielleicht gar nicht braucht, die dann aber auch den Compiler enthält, den man dann - wenn man weiß wie - auch wieder auf der Kommandozeile ausführen kann, wenn man mal schnell was compilieren will. Na gut, so soll man wahrscheinlich in Zukunft eben nicht mehr arbeiten, sondern *immer* die IDE benutzen. Und hier liegt auch denke ich das Problem. Die Akzeptanz eines Systems steht und fällt damit, wie "heimisch" sich die Leute damit fühlen. Wenn ich was Neues einführe, mache ich es am besten eben NICHT zum Zwang. Ich biete es an, wer es nutzen will (und kann), soll es nutzen, und wenn es gut ist, werden es schon viele Leute "freiwillig" nutzen und irgendwann kennt man es gar nicht mehr anders. Pulseaudio hat ja auch nicht ALSA obsolet gemacht und Wayland nicht X11. Und selbst nach der Einführung von systemd konnte man und kann man bis heute System-V-init-kompatible Scripte auf /etc/init.d benutzen. Das alte und das neue System arbeiten in perfekter Harmonie zusammen und der User merkt es unter Umständen nicht mal, was er grade benutzt. So geht das. Mein bisheriger Eindruck ist, dass bei ALP das eben nicht so gemacht wird. So ein bisschen erinnert mich das an die Kacheln unter Windows 8. Das war auch zu radikal und das wollte keiner. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 18. Februar 2023 18:00:42 MEZ schrieb "Manfred Haertel, DB3HM"
Bernd Nachtigall schrieb:
ALP und alles was aktuell und vielleicht später darauf beruht unterstützt, zumindest bis jetzt, nicht wirklich KDE? Ich denke es wird Container geben die die bisherige Desktop-Umgebung bereitstellen. Sollte die fehlen wäre es wirklich ein herber Verlust. Dann wäre ein openSUSE nicht mehr als Desktop-OS zu gebrauchen.
Also in meiner MicroOS-VM *läuft* KDE und zwar letztendlich das ganze KDE in einem eigenen Container (und das SDK in noch einem Container).
manfred@localhost:~> flatpak --user list | grep KDE KDE Application Platform org.kde.Platform 5.15-21.08 KDE Software Development Kit org.kde.Sdk 5.15-22.08
Und es läuft sogar performant.
Was im Moment nur mit vielen Klimmzügen geht ist (mal wieder) das Remote-Ausführen von X-Anwendungen, was ich nun mal gerne mache (zwischen verschiedenen VMs). Aber selbst das geht.
Vieles geht aber noch nicht oder ich glaube zumindest, dass es nicht geht, weil ich dem Paradigmen-Wechsel noch nicht so recht folgen kann.
Siehe die Sache mit dem Compiler, da war das auch erst so: Man muss erst mal auf die Idee kommen, dass man IRGENDEINE IDE als Container installieren muss, die man vielleicht gar nicht braucht, die dann aber auch den Compiler enthält, den man dann - wenn man weiß wie - auch wieder auf der Kommandozeile ausführen kann, wenn man mal schnell was compilieren will. Na gut, so soll man wahrscheinlich in Zukunft eben nicht mehr arbeiten, sondern *immer* die IDE benutzen.
Und hier liegt auch denke ich das Problem. Die Akzeptanz eines Systems steht und fällt damit, wie "heimisch" sich die Leute damit fühlen.
Wenn ich was Neues einführe, mache ich es am besten eben NICHT zum Zwang. Ich biete es an, wer es nutzen will (und kann), soll es nutzen, und wenn es gut ist, werden es schon viele Leute "freiwillig" nutzen und irgendwann kennt man es gar nicht mehr anders.
Pulseaudio hat ja auch nicht ALSA obsolet gemacht und Wayland nicht X11. Und selbst nach der Einführung von systemd konnte man und kann man bis heute System-V-init-kompatible Scripte auf /etc/init.d benutzen. Das alte und das neue System arbeiten in perfekter Harmonie zusammen und der User merkt es unter Umständen nicht mal, was er grade benutzt. So geht das.
Mein bisheriger Eindruck ist, dass bei ALP das eben nicht so gemacht wird.
So ein bisschen erinnert mich das an die Kacheln unter Windows 8. Das war auch zu radikal und das wollte keiner.
Nix für ungut. Aber Wayland z.B. läuft bei mir, und auch bei anderen, immer noch nicht fehlerfrei und produktiv. Etliche größere Soundanwendungen laufen immer noch nicht unter pipewire. Und wenn ich Mal zum Testen ein flatpack installiere dauert das ca. 10 Mal so lange wie ein übliches rpm. Da will ich gar nicht wissen wie lange ein komplette Desktop Umgebung dauert... Und für ein Compiler Brauch ich ein extra Container? Was ein Quatsch. Und für die Desktop Umgebung noch Mal ein Container. Was soll das? Du schreibst zwar es läuft, zählst aber eigentlich selbst lauter Nachteile auf. Achja, Gnome in Alp is laut wiki beta und kde Alpha. Und ob das dann Mal aus Alpha kommt... Also wo liegt nun der benefit mit Alp, außer das es was neues wäre? Eigentlich nur für die suse HR und BWL Abteilung. Für Anwender sehe ich keinen. Gruß Eric
Eric Schirra schrieb:
Nix für ungut. Aber Wayland z.B. läuft bei mir, und auch bei anderen, immer noch nicht fehlerfrei und produktiv.
Bei mir übrigens auch nicht, zumindest nicht nativ. Mit dem X11-Backend läuft es gut und ich kann es ausprobieren. Keiner treibt mich dahin, es benutzen zu MÜSSEN.
Achja, Gnome in Alp is laut wiki beta und kde Alpha. Und ob das dann Mal aus Alpha kommt...
Da bin ich überzeugt von. Die Frage ist nur wann. Und dafür, dass es Alpha ist, läuft es schon mal recht gut. Eigentlich schon besser als frühe finale Version von KDE 4 und KDE 5...
Du schreibst zwar es läuft, zählst aber eigentlich selbst lauter Nachteile auf.
Tue ich das? So eine Mail ist kurz, da entsteht schon mal ein falscher Eindruck. Eigentlich weiß ich noch nicht so richtig, was ich von ALP halten soll. Container find ich erst mal gut. Das ist ja auch alles nicht neu. chroot gibt es seit 1979. Ja, chroot hat diverse Einschränkungen. Und genau deswegen gibt es ja auch jetzt flatpak und andere Tools, die genau da ansetzen und eine perfekte Container-Lösung samt - wichtig - Softwareverwaltung bereitstellen. Und ja, es hat den großen Vorteil, dass Anwendungen einheitlich und ohne individuelle Anpassung auf allen Linux-Distributionen zur Verfügung gestellt werden können, OHNE Krücken wie LD_LIBRARY_PATH und Konsorten benutzen zu müssen. Das ist besonders auch für Software von kommerziellen Anwendern wichtig - man denke nur an das halbe Dutzend Video-Konferenz-Anwendungen, was sich auf jedem Rechner sammelt. Ich würde sogar so weit gehen, dass ich sage, Linux MUSS sowas anbieten, um endlich auch in diese Welt Einzug halten zu können und nicht von kommerziellen Firmen weiterhin so stiefmütterlich behandelt zu werden. Die WOLLEN halt nicht 20 Versionen für 20 verschiedene Linux-Distris bereit stellen. Was man genau genommen sogar noch verstehen kann. Container haben einen objektiven Nachteil. Das ist der Speicherbedarf auf Festplatte. Andererseits wird die wahre Zukunft wohl die sein, dass man Container direkt aus der Cloud startet, womit der Nachteil nicht mehr besteht. Und ja, mit DEM Gedanken tue ich mich schwer. Da gehen die subjektiven Nachteile los. Wir erleben hier eine Art Paradigmen-Wechsel, der sogar ziemlich schnell voran geht. Junge ITler arbeiten einfach anders als wir seit 30 oder 40 Jahren und die setzen sich grade massiv durch und haben kein Verständnis dafür, wenn sich Leute damit schwer tun. Ja, da sind wir wieder bei der Generation Y, und hier meine ich das wirklich absolut ernst. Das gibt es auch in ganz anderen Bereichen des täglichen Lebens. Bargeld? Wofür? Auch bei Kleinstbeträgen wird mittlerweile schon an vielen Stellen Kreditkartenzahlung ERWARTET. Ein Aha-Erlebnis von mir dazu: Hier in der Nähe gibt es ein Parkhaus, wo man die Parkgebühren nur noch per Kreditkarte bezahlen kann. Ein Schild weist zwar darauf hin, aber das kann man schon mal übersehen. Ein Rentner, der wohl gar keine Kreditkarte besitzt, stand dann hilflos vor dem Kassenautomaten und hat sich bei der örtlichen Zeitung beschwert und die hat in ihrer Print-Ausgabe und auf Facebook darüber berichtet. Auf Facebook gab es eigentlich nur hämische Kommentare dazu. Der Rentner habe sich gefälligst anzupassen. Genau so hämisch, wie vor 35 Jahren der Kassierer, der mir beim Zahlen eines größeren Betrags erklärte, es stünde zwar da ein Schild, dass sie Kreditkarten annehmen, er würde das aber gar nicht einsehen und ich würde die Leute aufhalten. Warum erzähle ich das? Weil ich beweisen will, dass der gerade stattfindende massive Paradigmen-Wechsel eben keine IT-spezifische Sache ist. Das was damals schlecht war ist heute gut und umgekehrt (zumindest auf manchen Gebieten). Und es gibt eigentlich nur eine Konsequenz daraus: Anpassen. Würde ich ja sogar, ich halte mich ja für anpassungsfähig, aber der permanente Druck dazu erzeugt bei mir halt eher Trotz-Reaktionen. Auch wenn die Feststellung vielleicht nervt (besonders die jungen Leute): Auch das ist eine Generationen-Frage. Vielleicht wird auch ALP auf diese Art und Weise durchgedrückt. Aber nur Suse allein wird das nicht schaffen. Und dass andere mitziehen, zumindest jetzt schon, kann ich nicht erkennen. Aber, zurück zum Gedankengang: Die Container adressieren auch eben die veränderten Arbeitsweisen. Siehe auch meine Gedanken zu IDEs und Compilern aus den anderen Mails. Die *Container* werden sich also kaum aufhalten lassen, die Cloud auch nicht, ebenso wenig die Kartenzahlung im Parkhaus und Automatikgetriebe bei Autos. Entscheidend ist aber folgendes: Auch wenn sicher ist, dass wir eine Veränderung erleben, ist für mich wirklich die Frage, ob es klug ist, diese Veränderung sozusagen "revolutionär" (per ALP) durchzudrücken, oder ob es nicht besser ist, "auf die Evolution zu setzen", oder, wie man früher manchmal gesagt hat, "das geht sowieso seinen sozialistischen Gang". Beides anbieten, niemanden abschrecken, was sich durchsetzt ist zwar eh klar, aber gib ihnen ein paar Jahre dafür. Funktioniert bei Wayland ja auch schon 15 Jahre lang so, ahem. Und NOCH ist Barzahlung nicht generell verboten, um dieses Analogon noch mal zu bemühen. Für mich privat ist die Konsequenz aus ALP die, dass ich mittlerweile eine MicroOS-VM habe und eine Debian-VM, in welchen ich ab und zu testweise versuche, dasselbe zu erledigen wie in meiner Opensuse-Arbeits-VM - um mich an beide Alternativen zu gewöhnen. Auf welchen Weg ich setze, werde ich zum gegebenen Zeitpunkt entscheiden. Und beruflich bin ich froh, schon vor einiger Zeit im Vorgriff auf die Rente kürzer getreten zu sein und meine Führungsposition abgegeben zu haben. :-) Sonst wäre nämlich genau ich in der Pflicht, entscheiden zu müssen, wie es DA weiter geht. Und offen gestanden, das wäre mir zu konfliktreich. Ich bin wahrlich niemand, der Konflikten besser aus dem Weg geht, aber das brauche ich wirklich nicht. Da kann man fast nur verlieren... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 18.02.23 um 18:00 schrieb Manfred Haertel, DB3HM: (...)
Und selbst nach der Einführung von systemd konnte man und kann man bis heute System-V-init-kompatible Scripte auf /etc/init.d benutzen. Das alte und das neue System arbeiten in perfekter Harmonie zusammen
Jepp, aber nach meiner Wahrnehmung kam die Kompatibilität des systemd zum init.d erst später. D.h. erst wurde systemd lauffähig gemacht (und eingesetzt) und später kamen die Helper-Skripte hinzu die die alten init.d Startskripte lauffähig machten. (Und das war IMHO wenig problematisch da systemd deutlich besser ist als einige Leute es wahrhaben woll(t)en ;-) Ich denke hier wird es ebenso. Erst mal ALP in der Struktur ans fliegen kriegen. Und dann die Kompatibilität herstellen. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am 18. Februar 2023 16:39:59 MEZ schrieb Bernd Nachtigall
Am 18.02.23 um 10:38 schrieb Eric Schirra:
Am Samstag, 18. Februar 2023, 10:08:43 CET schrieb Bernd Nachtigall:
Am 17.02.23 um 20:08 schrieb Christian Boltz in Re: ALP (was: Re:
Monitorkalibrierung):
- ein paar SUSE-Entwickler haben in der Hackweek daran gearbeitet, auf Basis von ALP eine "traditionelle" Distribution zu bauen. Die ist wohl ähnlich wie Leap, wenn auch bisher mit weniger Paketen. Details: https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll - von einem anderen SUSE-Entwickler kam ein Hinweis, dass ALP eine Platform ist und daraus mehrere Produkte entstehen können/werden. Auch da kam ein Hinweis, dass eins dieser Produkte eine "traditionelle" Distribution sein könnte.
Uns so wird es IMHO wohl auch (hoffentlich) kommen. Ein openSUSE ohne die von so vielen (stillen Usern) genutzte Desktop-Oberfläche wäre ein herber Verlust für SUSE. Diese User würden schnell auf eine andere Distribution wechseln ("Ich brauche nur was um unkompliziert zu arbeiten ..."). Und dann wäre Schritt für Schritt auch die Migration der Systeme die von diesen Usern betreut werden, eingeleitet.
Die Idee hinter ALP finde ich bestechend. Aber es muss eben Images geben die als Container problemlos die bisherigen Versionen fortschreiben.
Also. Damit ich das richtig verstehe. Ohne Polemik. Hier ein paar Fragen.
ALP und alles was aktuell und vielleicht später darauf beruht, beruht auf container? So wie ich das (bisher) verstehe ist ALP nur ein Minimalsystem was mit Containern je nach Bedarf erweitert wird. Ich setze jetzt schon Distributionen ein die einen Teil ihrer Funktionalität in Containern ausführen. Läuft einwandfrei und ist (durch den Hersteller) leicht zu warten. Zudem laufen die Teile die in den Containern überall wo Container laufen können. Also auch in der hochgelobten Cloud (örgs, aber man kann ja eine Docker-Umgebung auch selbst betreiben.)
[Refrain]
Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri.
ALP und alles was aktuell und vielleicht später darauf beruht ist immutable? Keine Ahnung. Frag jemanden der das weiß. Aber was wäre schlecht daran?
Snip Refrain
ALP und alles was aktuell und vielleicht später darauf beruht unterstützt, zumindest bis jetzt, nicht wirklich KDE? Ich denke es wird Container geben die die bisherige Desktop-Umgebung bereitstellen. Sollte die fehlen wäre es wirklich ein herber Verlust. Dann wäre ein openSUSE nicht mehr als Desktop-OS zu gebrauchen.
Snip Refrain
ALP und alles was aktuelle und vielleicht später darauf beruhen müssen nach einem t-u _immer_ rebootet werden? Eben das soll nach meinem Verständnis vermieden werden.
Snip Refrain
ALP und alles was aktuelle und vielleicht später darauf beruhen sollten nicht manuell upgedatet werden, sondern immer nur automatisch? ??
Das ist meiner Meinung nach nicht "traditionell". Und das will ich nicht. Also andere Distri. Ja, das hast Du schon ein paarmal gesagt ...
Hört sich für mich ein wenig wie die Aufregung um/gegen/wegen systemd an. Das war auch ein ganz schrecklicher Eingriff in alles mögliche und das sichere Ende von Linux ... und läuft heute ganz vorzüglich.
So. Das Ergebnis ist für mich eindeutig. Und auch im geschäftlichen Bereich spricht alles dagegen. Im geschäftlichen Bereich? Da wird eingesetzt was sicher läuft und einen guten Support (1st-Level SUSE-Partner und 2nd-Level SUSE) bietet.
Nö. Für Linux muss man kämpfen und es darf dann nichts kosten. Denn es gibt ja das tolle Win.... Und der Support selbst,.... Naja lassen wir das besser. (OK,
außer bei M$, das wird eingesetzt weil alle glauben sie hätten keine andere Möglichkeit.)
Wenn also alles so kommt wie man zumindest bis jetzt rauslesen kann, gibt es nur eine Lösung. Andere Distri nach ca. 30 Jahren!. :-( Ich weiß nicht was du da rauslesen kannst, ich warte mal ab.
Alle obigen Fragen waren eigentlich rhetorischer Natur. Ich konnte das aus mehreren Quellen "rauslesen". Berichte von Suse, Berichte von externen Medien, susewiki, elementkanal, usw. Gruß Eric
participants (3)
-
Bernd Nachtigall
-
Eric Schirra
-
Manfred Haertel, DB3HM