Am 16. Juni 2022 18:45:46 MESZ schrieb Norbert Zawodsky :

Am 16.06.22 18:19 schrieb Eric Schirra:

...

Am 16. Juni 2022 18:05:28 MESZ schrieb Stefan :

...

Hallo zusammen,

ich habe gehört, das SUSE SLE und openSUSE(?) nach SLE 15 komplett umkrempeln will.

Wenn ich das als Nicht-IT'ler richtig verstanden habe, soll SUSE demnächst aus einem minimalen Betriebssystemkern (Micro OS) und Anwendungscontainern bestehen.

Das hört sich für mich nach überbordender Komplexität, steigendem Resourcenbedarf und vollgemüllten Festplatten an.

Unter einem Anwendungscontainer stelle ich mir so was wie Flatpak vor. Das heißt sämtliche Binaries der Anwendung und alle Libraries befinden sich in diesem Container. Wenn 10 verschiedene Anwendungen eine bestimmte Library benötigen, habe ich dann demnächst ein und dieselbe Library 10mal in 10 unterschiedlichen Containern auf der Festplatte liegen?

Wenn ich jede Anwendung in einem Container laufen habe, erhöht das doch auch bestimmt den Resourcenbedarf (CPU, RAM) oder?

Ist dieses System auch für den Desktop geplant?

Ist das so schrecklich wie es sich anhört? All diese Fragen habe ich mir auch gestellt. Und auch für mich hört es sich genauso schrecklich an.

Aber es wird sicher viele geben, die alle möglichen unmögliche Gründe dafür angeben werden.

Wenn's wirklich so kommt, wird's nach ca. 20 dann leider doch Zeit die Distribution zu wechseln. :-(

Gruß Eric

Aber wohin wechseln? Was ich so gehört habe - ist aber nur eine Gerüchte Information - geht angeblich ubuntu den gleichen schwachsinnigen Weg...

Die sind doch schon teilweise dort. Ich glaub der Firefox ist es, gibt es zum Beispiel standardmäßig nur noch als Snap.

google-fu rules: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/ N6TTE7ZBY7GFJ27XSDTXRF3MVLF6HW4W/

Am 16.06.22 22:10 schrieb Richard Kraut:

Am Donnerstag, dem 16.06.2022 um 20:46 +0200 schrieb Mathias Homann:

...

Stimmt. Und damit wird das für mich schon mal 100% unbrauchbar - snaps können nicht mit $HOME wasa ausserhalb von /home liegt. Es ist nicht nur der FF, sondern auch der Chromium und der GNOME- Taschenrechner z.B.

Die (wenigen) Befürworter, die ich kenne argumentieren immer damit "Speicher kostet heutzutage eh nix". Auf der anderen Seite predigen alle, dass man mit Resourcen "nachhaltig" und sparsam umgehen soll. Da zählen Edelmetalle und Strom genauso dazu. Mir ist schon klar dass es ein enormer Aufwand ist ein build-system am Laufen zu halten, für (m Betriebssysteme) x (n Gui [Qt] Versionen) x (o sonst-noch-was Versionen) .... Nur, dann wäre es klüger, von den einzelnen Komponenten weniger neue Versionen pro Zeiteinheit zu produzieren. Ich halte diese Entwicklung für einen Rückschritt von 30 Jahren, in die Zeit als jedes Programm alle nötigen Libraries "statisch" gelinkt hat. War ja de facto nichts anderes als das Neue jetzt. Als dann die dynamischen libraries kamen, war es ja angeblich ein Quantensprung vorwärts.

Am 16.06.2022 um 18:19 schrieb Eric Schirra:

Am 16. Juni 2022 18:05:28 MESZ schrieb Stefan :

...

Hallo zusammen,

ich habe gehört, das SUSE SLE und openSUSE(?) nach SLE 15 komplett umkrempeln will.

Wenn ich das als Nicht-IT'ler richtig verstanden habe, soll SUSE demnächst aus einem minimalen Betriebssystemkern (Micro OS) und Anwendungscontainern bestehen.

Das hört sich für mich nach überbordender Komplexität, steigendem Resourcenbedarf und vollgemüllten Festplatten an.

Unter einem Anwendungscontainer stelle ich mir so was wie Flatpak vor. Das heißt sämtliche Binaries der Anwendung und alle Libraries befinden sich in diesem Container. Wenn 10 verschiedene Anwendungen eine bestimmte Library benötigen, habe ich dann demnächst ein und dieselbe Library 10mal in 10 unterschiedlichen Containern auf der Festplatte liegen?

Wenn ich jede Anwendung in einem Container laufen habe, erhöht das doch auch bestimmt den Resourcenbedarf (CPU, RAM) oder?

Ist dieses System auch für den Desktop geplant?

Ist das so schrecklich wie es sich anhört?

All diese Fragen habe ich mir auch gestellt. Und auch für mich hört es sich genauso schrecklich an.

Aber es wird sicher viele geben, die alle möglichen unmögliche Gründe dafür angeben werden.

Wenn's wirklich so kommt, wird's nach ca. 20 dann leider doch Zeit die Distribution zu wechseln. :-(

Gruß Eric

Da bist du dann bestimmt nicht der Einzige. Ich schiebe den Wechsel auch schon seit Jahren vor mir her, da persönlich ich die SUSE Philosophie schon lange überhaupt nicht mehr gut heiße. Da wird einerseits auf Biegen und Brechen an uralten Kernel festgehalten und dort wasweißich für Backports eingebaut, oder andere Pakete, wie beispielsweise das vergammelte Python 3.6, welches auch schon im OS 13.1 vorhanden war, krampfhaft am Leben gehalten. Für mich völlig unverständlich so etwas. Tumbleweed ist für mich da auch keine Alternative, ich hab keinen Bedarf an einem OS das für mich nie einen stabilen Status hat. Ubuntu kannste auch knicken. Die finden immer ein paar Jahre irgendwas ganz toll, um es dann sang- und klanglos wieder in die Tonne zu treten. Mit so etwas kann ich auch nix anfangen. Werde dann wohl nach aktuellem Stand der Dinge vollständig auf Debian wechseln und SuSE dann nach 30 Jahren endgültig Lebewohl sagen. Manfred

Am 16.06.22 um 18:19 schrieb Eric Schirra:

Am 16. Juni 2022 18:05:28 MESZ schrieb Stefan :

...

Hallo zusammen,

ich habe gehört, das SUSE SLE und openSUSE(?) nach SLE 15 komplett umkrempeln will.

Wenn ich das als Nicht-IT'ler richtig verstanden habe, soll SUSE demnächst aus einem minimalen Betriebssystemkern (Micro OS) und Anwendungscontainern bestehen.

Das hört sich für mich nach überbordender Komplexität, steigendem Resourcenbedarf und vollgemüllten Festplatten an.

Unter einem Anwendungscontainer stelle ich mir so was wie Flatpak vor. Das heißt sämtliche Binaries der Anwendung und alle Libraries befinden sich in diesem Container. Wenn 10 verschiedene Anwendungen eine bestimmte Library benötigen, habe ich dann demnächst ein und dieselbe Library 10mal in 10 unterschiedlichen Containern auf der Festplatte liegen?

Wenn ich jede Anwendung in einem Container laufen habe, erhöht das doch auch bestimmt den Resourcenbedarf (CPU, RAM) oder?

Ist dieses System auch für den Desktop geplant?

Ist das so schrecklich wie es sich anhört? All diese Fragen habe ich mir auch gestellt. Und auch für mich hört es sich genauso schrecklich an.

Aber es wird sicher viele geben, die alle möglichen unmögliche Gründe dafür angeben werden.

Wenn's wirklich so kommt, wird's nach ca. 20 dann leider doch Zeit die Distribution zu wechseln. :-(

Gruß Eric

Hallo Alle, ich bin vor Leap 42.3 beu Ubuntu "gelandet" - weil damals das Upgrade nicht funktionierte. Mit Kubuntu bin ich sehr zufrieden! :) von TOM -- Dipl.-Ing. TOM (Thomas) Claßen Dorotheenstr. 14 06108 Halle (Saale) mobil: 0177 - 285 88 17

Hallo Manfred, ich bin nicht per se gegen jegliche Neuerungen in der Linux Welt. Ich bin nur persönlich enttäuscht, da für mich bisher ein großer Vorteil von Linux war, das es ressourcenschonend auf älterer und nicht so leistungsfähiger Hardware lief. Auch das eine Library nur einmal auf einem System vorhanden ist stellt für mich ein riesiges Plus dar. Im Laufe der letzten Jahre habe ich nach und nach bei unseren Rechnern in der Familie Core i Prozessoren durch Celeron Prozessoren ersetzt. Das spart eine Menge Strom und mit XFCE als Desktopumgebung laufen die Rechner zügig (und völlig lautlos, da passiv gekühlt). Ich werde auf jeden Fall bis Leap 15.5 bei openSUSE bleiben. Dann muss ich einfach mal testen ob meine vorhandene Hardware mit ALP zurecht kommt und im Zweifel auf eine klassische Linux Distro wechseln (die es dann hoffentlich noch gibt). Es scheint ja im Moment auch noch gar nicht festzustehen wie das neue Produkt im Einzelnen aussehen wird. Ein Teil meiner Familie und ich nutzen openSUSE seit 9 Jahren als einziges Desktopbetriebssystem und sind sehr zufrieden damit. Wir würden auch gerne weiterhin openSUSE einsetzen. Viele Grüße Stefan Am 17.06.22 um 07:52 schrieb Manfred Haertel, DB3HM:

Stefan schrieb:

...

Wenn ich das als Nicht-IT'ler richtig verstanden habe, soll SUSE demnächst aus einem minimalen Betriebssystemkern (Micro OS) und Anwendungscontainern bestehen.

Das hört sich für mich nach überbordender Komplexität, steigendem Resourcenbedarf und vollgemüllten Festplatten an.

Unter einem Anwendungscontainer stelle ich mir so was wie Flatpak vor. Das heißt sämtliche Binaries der Anwendung und alle Libraries befinden sich in diesem Container. Wenn 10 verschiedene Anwendungen eine bestimmte Library benötigen, habe ich dann demnächst ein und dieselbe Library 10mal in 10 unterschiedlichen Containern auf der Festplatte liegen?

Wenn ich jede Anwendung in einem Container laufen habe, erhöht das doch auch bestimmt den Resourcenbedarf (CPU, RAM) oder?

Ich wollte eigentlich nichts dazu schreiben, aber bei soviel Novitäten-Skepsis wie ich die hier gelesen habe, muss ich dann doch mal.

Früher waren die Linux-Benutzer innovativ. Sind sie jetzt nur noch konservativ, während woanders der Zug abfährt?

Novitäten-Skepsis ist nicht per se schlecht. Ich habe - immer noch - eine gewisse Skepsis gegen den systemd, auch wenn ich seine Vorteile mittlerweile zu schätzen weiß. Auch bei Wayland habe ich eine große Skepsis, aber das scheint sich jetzt wenigstens in die richtige Richtung zu entwickeln.

Aber man darf nicht gegen alles sein, nur weil man sich umgewöhnen muss!

Der Trend zu den Containern - den sehe ich sehr positiv.

Effektiv ist es doch schon so, dass professionelle Software, sofern sie unter Linux überhaupt existiert, sich sowieso schon alle Libraries mitbringt, weil alle Distris ihr eigenes Süppchen kochen und sich kein Software-Hersteller drauf verlassen kann, welche Libraries denn grade auf dem System drauf sind. Und genau deswegen sind die professionellen Pakete ja alle so groß.

Man hat doch heutzutage drei oder vier verschiedene Video-Konferenz-Programme auf dem System. Natürlich nicht die Web-Versionen, die gibt es zwar, aber die können dann wieder irgendwas nicht, was vorausgesetzt wird. Diese Pakete enthalten oft nicht nur einen eingebetteten Chrome-Browser, sondern auch noch viele Dutzend Bibliotheken, weil man eben der Distri nicht traut. Jedes Video-Konferenz-Programm natürlich andere. Und so geht es munter weiter.

Wenn man nur Open Source einsetzt, hat man (in der Regel) keine Probleme, dann kümmert sich die Distri drum, dass Anwendungen und Libraries passen.

Nur, so funktioniert die Welt nicht. Wenn man noch berufstätig und mindestens noch zeitweise ins Home-Office "verbannt" ist (und ich gehe nicht davon aus, dass sich das bald oder überhaupt noch mal ändert, ist viel zu bequem für die Arbeitgeber und die Arbeitnehmer glauben momentan auch noch, dass es für sie gut ist), braucht man halt vier Video-Konferenz-Programme, ein oder mehr Remote-Zugangs-Programme und eine Handvoll Authentifizierungs-Programme (OK, die laufen meistens auf den Handies).

Unter Windows klickt man maximal auf einen Installer, im Zweifelsfall sind die von der IT-Abteilung ausgegebenen Windows-Laptops so aufgesetzt, dass man gar nichts tun muss und einfach alles immer "magisch" da ist. Will man aber zuhause Linux nutzen, "ist immer alles so kompliziert" - laut IT-Abteilung und auch nicht nur für die IT-Abteilung, auch für den Anwender, wenn man ehrlich zu sich selbst ist als Linux-Anwender.

Nein, das gehört unter Linux systematisiert, statt hundert eigene Süppchen. Und Container existieren und sie sind hier die Lösung. Und dann werden auch kommerzielle Firmen Linux besser unterstützen.

Und für den Anwender ändert sich erst mal gar nichts. Der Taschenrechner wird wohl auch weiterhin eine "normale" Applikation sein (eventuell auch Teil eines Desktop-Containers), schon der Browser nicht, und das mit Recht. Der ist doch DAS Einfalls-Tor für Malware. Ab in den Container und Ruhe ist. Und für Downloads über den Browser wird es schon eine standardisierte Lösung geben - weil Container ja eben ein Standard-Weg sind und kein Anwendungs-spezifischer Sonderschnitz. Wird vielleicht etwas umständlicher, aber viel, viel sicherer.

Und ob eine Anwendung im Container und wenn ja in welchem oder "einfach so" läuft, braucht mich nicht zu kümmern. Ich muss sie vielleicht mit einem anderen Kommando installieren, wenn sie im Container läuft, das ist alles, und selbst das kann und wird die Distri vor mir verbergen. Und zum Aufruf klicke ich auf ein Icon oder gebe ein Kommando ein - und was das macht, ist mir doch egal.

Nein, DAGEGEN habe ich (fast) keine Skepsis.

On 17.06.22 20:11, Richard Kraut wrote:

Am Freitag, dem 17.06.2022 um 07:52 +0200 schrieb Manfred Haertel, DB3HM:

...

Effektiv ist es doch schon so, dass professionelle Software, sofern sie unter Linux überhaupt existiert, sich sowieso schon alle Libraries mitbringt, weil alle Distris ihr eigenes Süppchen kochen und sich kein Software-Hersteller drauf verlassen kann, welche Libraries denn grade auf dem System drauf sind. Und genau deswegen sind die professionellen Pakete ja alle so groß.

Von welcher "professionellen" Software reden wir hier? Ich habe hier auf meinem PC z. B. Bitwig Studio, welches vom Anbieter neben Mac und Windows auch nativ für Linux in den klassischen Paketformaten DEB und RPM angeboten wird.

Du kannst Dir mit 'rpm -ql' den Inhalt Deines Paketes anschauen. Mach das bitte und laß uns wissen, ob Bitwig die SuSE Libraries nutzt oder seine eigenen mitschleppt. Viele Grüße Ulf

Ich hab ein bisschen überlegt, ob ich drauf antworten soll, aber ich mach's einfach mal... Richard Kraut schrieb:

Am Freitag, dem 17.06.2022 um 07:52 +0200 schrieb Manfred Haertel, DB3HM:

...

Früher waren die Linux-Benutzer innovativ. Sind sie jetzt nur noch konservativ, während woanders der Zug abfährt?

Welcher Zug soll denn das sein?

Naja, ich habe das Gefühl, dass z.B. Windows in mindestens mancherlei Hinsicht in den letzten Jahren innovativer war als Linux. Aber das ist natürlich gneauso pauschal wie meine Aussage, auf die Du geantwortet hast. Sprich, das ist einfach eine subjektive und pauschalisierte Zusammenfassung aus meiner Sicht und DARÜBER sollten wir nicht streiten.

...

Aber man darf nicht gegen alles sein, nur weil man sich umgewöhnen muss!

Ich denke es geht hier eher weniger ums Umgewöhnen. Es gibt berechtigte Kritikpunkte am klassischen Paketsystem als auch bei den Containerformaten.

Dem stimme ich (auch wieder in der Pauschalität) zu.

...

Der Trend zu den Containern - den sehe ich sehr positiv.

Würdest Du das noch immer so positiv sehen, wenn Deine Linux- Installation an Stelle von z. B. 12 GB Speicherplatz plötzlich, wohlgemerkt mit dem selben Softwareumfang, 60 GB benötigen würde?

Und bei noch umfangreicheren Installationen noch mehr.

In einer Zeit, wo die meisten Festplatten sich im Terabyte-Bereich bewegen und auch erschwinglich sind, ist der Unterschied zwischen 12 und 60 GB mit Verlaub ein Mückensch*ss.

...

Effektiv ist es doch schon so, dass professionelle Software, sofern sie unter Linux überhaupt existiert, sich sowieso schon alle Libraries mitbringt, weil alle Distris ihr eigenes Süppchen kochen und sich kein Software-Hersteller drauf verlassen kann, welche Libraries denn grade auf dem System drauf sind. Und genau deswegen sind die professionellen Pakete ja alle so groß.

Von welcher "professionellen" Software reden wir hier?

Die Beispiele, die ich benutze, habe ich ja im Anschluss gebracht. Im Home-Office brauche ich Video-Konferenzen und Fernzugang. Andere Menschen brauchen andere Software. Aber im Home-Office saßen und sitzen noch viele, die ich kenne. Und da sind eben seit März 2020 so einige Notwendigkeiten "hochgekocht", die es vorher in der Form nicht gab. Ich habe bewusst "professionelle" Software geschrieben und nicht "kommerzielle", weil viele dieser Produkte auch zumindest auf der Client-Seite kostenlos sind. Ich meine eben Software, hinter denen eine Firma mit Gewinn-Absicht steckt. Die auch ein wenig auf den Aufwand zur Pflege und zum Support schauen muss und die jeden Weg gehen wird, um den so gering als möglich zu halten. Und unter Linux gibt es eben allein ein Dutzend "große" Distris, die alle unterschiedlich ticken und ein bis zwei mal im Jahr Updates rausbringen, die dann wieder anders ticken. In dem Falle eben durch neue Versionen von Libraries, die dann auf die kommerzielle Software "nicht passen". Manche unterstützen deswegen eben Linux lieber gar nicht. Oder geben es wieder auf. Manche schreiben ihre Software auch in Java, damit sie (auch) unter Linux läuft. Um dann festzustellen, dass "die falsche" Version der Java Runtime installiert ist. Also bringt man die richtige auch gleich mit. Samt zugehöriger Libraries. Aua. Den Teufel mit dem Beelzebub oder gleich einer ganzen Armee von Beelzebuben ausgetrieben.

...

Man hat doch heutzutage drei oder vier verschiedene Video-Konferenz-Programme auf dem System.

Ähhhmmmm. Nope.

Du vielleicht nicht, ich schon. :-) Und jeder, der mit mir konferieren möchte, hat so seine Vorlieben, mit welcher Software das geht.

...

Natürlich nicht die Web-Versionen, die gibt es zwar, aber die können dann wieder irgendwas nicht, was vorausgesetzt wird. Diese Pakete enthalten oft nicht nur einen eingebetteten Chrome-Browser, sondern auch noch viele Dutzend Bibliotheken, weil man eben der Distri nicht traut. Jedes Video-Konferenz-Programm natürlich andere. Und so geht es munter weiter.

Ersteinmal muss eine Linux-Version eines Programms geben. Sonst bringen auch die Container nichts.

Natürlich, wie gesagt, meine Rede. Die typischen Reaktionen der Software-Firma sind: Entweder alle oder zumindest die kritischen Libraries selbst mitbringen (und dann statisch linken oder LD_LIBRAY_PATH setzen oder ganz krude Dinge machen) oder es eben ganz sein lassen.

Apropos Unterschiede bei Web- und Clientversionen. Zumindest ist Microsoft, bis jetzt, dafür bekannt, dass es seinen Teams Linux-Client auch eher Stiefmütterlich behandelt im Vergleich zur Windows-Version.

Würde ich auch so machen, wenn ich ein eigenes Betriebssystem verkaufen möchte. :-) Aber das ist nur EIN Aspekt der ganzen Geschichte.

...

Wenn man nur Open Source einsetzt, hat man (in der Regel) keine Probleme, dann kümmert sich die Distri drum, dass Anwendungen und Libraries passen.

Die Befürchtungen gehen aber dahin, dass es zukünftig neben dem Kernel nur noch ein minimales Grundsystem im Userland gibt und der Rest nur noch aus den Containern besteht.

Auch das würde MICH nicht stören. Naja, würde es doch, wenn es plötzlich 1000 Container gäbe. Aber die wird es schon deswegen nicht geben, weil das System auch für den Distri-Hersteller noch beherrschbar sein muss. Also wird man Dinge logisch zusammenfassen und man pickt sich halt ein Dutzend Container zusammen, die man braucht. Die Idee mit dem minimalen Grundsystem, auf dem verschiedene "Identitäten" laufen können (wenn auch damals noch ohne Container) ist übrigens auch nicht neu, eher gute 3 Jahrzehnte alt. Damals zeitweise als Microkernel ein Buzzword. Professor Tanenbaum hat es mit Minix vorgemacht, wie das geht. Übrigens tatsächlich ein geniales System, wenn auch heute hoffnungslos veraltet. Was mich nicht daran hindert, immer mal wieder meine schnuckelige Minix-VM zu booten. :-) Und selbst Microsoft hatte den Microkernel für Windows NT 3.1 noch als Design-Prinzip, was auch der Hauptgrund war, weswegen ich damals auch große Hoffnung in dieses System gesetzt habe. Hat auch prinzipiell funktioniert, mit Windows NT 3.1 wurden drei Subsysteme ausgeliefert, die auf dem Kernel liefen. Dummerweise waren zwei davon letztendlich nutzlos. Aber es ging ums Prinzip, und das hat funktioniert. Aber das hat damals leider keiner verstanden (manche noch nicht mal registriert, auch weil das ausgerechnet Microsoft damals keiner zugetraut hat). Weder die Benutzer haben es verstanden (auch nicht die erfahrenen) noch die Manager bei Microsoft. Und so wurde das von Anfang an ein wenig halbherzig implementiert und verschwand mit NT 4.0 völlig. Die Idee war dann auch tot. Hat sich halt nicht durchgesetzt. Technisch möglich wäre es schon gewesen. Wäre das damals "eingeschlagen", würde die IT heute ganz anders aussehen. Aber das ist eigentlich ein anderes Thema.

...

Nur, so funktioniert die Welt nicht. Wenn man noch berufstätig und mindestens noch zeitweise ins Home-Office "verbannt" ist (und ich gehe nicht davon aus, dass sich das bald oder überhaupt noch mal ändert, ist viel zu bequem für die Arbeitgeber und die Arbeitnehmer glauben momentan auch noch, dass es für sie gut ist), braucht man halt vier Video-Konferenz-Programme, ein oder mehr Remote-Zugangs-Programme und eine Handvoll Authentifizierungs-Programme (OK, die laufen meistens auf den Handies).

Bei uns in der Firma (produzierendes Gewerbe) gab es kein Homeoffice und wird es wird auch keines geben. Außer es käme eine gesetzliche Pflicht hierzu. Nach unserem Chef ist die persönliche Anwesenheit von x und y unbedingt erforderlich.

Naja, bei mir ist es halt im weitesten Sinne Dienstleistungs-Gewerbe und da kann eigentlich fast jeder (außer dem Facility Management) von zuhause arbeiten, jedenfalls den größten Teil der Zeit. Und es bleibt auf absehbare Zeit erwünscht. Mir wäre es lieber, wenn es anders wäre, aber auch das ist ein anderes Thema.

...

Unter Windows klickt man maximal auf einen Installer, im Zweifelsfall sind die von der IT-Abteilung ausgegebenen Windows-Laptops so aufgesetzt, dass man gar nichts tun muss und einfach alles immer "magisch" da ist. Will man aber zuhause Linux nutzen, "ist immer alles so kompliziert" - laut IT-Abteilung und auch nicht nur für die IT-Abteilung, auch für den Anwender, wenn man ehrlich zu sich selbst ist als Linux-Anwender.

VPN-Verbindung in die Firma einrichten und via RDP über den VPN-Tunnel auf seine Arbeitsumgebung zugreifen. Die Infos für das VPN müssen eben die Admins raus rücken. Der Rest ist dann nicht mehr wirklich kompliziert.

VPN-Tunnel sind ja "normalerweise" nicht gewünscht, weil die ja "zuviel" ermöglichen. So kenne ich es und so finde ich es eigentlich auch richtig. Lieber "reine Fernsteuerung" ohne die Möglichkeit des Datentransfers, dann kann man auch nichts versehentlich von zuhause einschleppen. Tja, und die reine Fernsteurung läuft dann "am liebsten" halt über eine (bestimmte :-) ) kommerzielle Software und da muss man sich - natürlich wieder - einen Fat-Client installieren, weil die Browser-Variante wieder nicht alles kann und schon ist man wieder genau auf der Schiene, dass das unter Linux - laut Admins - "irgendwie viel zu umständlich geht" (zumal man noch Hand an die Config-Dateien anlegen muss, auch weil es sonst subtile Probleme gibt) und daher auch kein Support für Linux geleistet wird. Und ja, auch da sind wieder eine Tonne von der Software mitgebrachte Libraries dabei.

PS: Ich habe auch schon für eine Firma gearbeitet, in welcher man sich nur "Admin" nennen durfte, wenn man auch mit Linux konnte. 😋️

Ich bin ja selber Admin. Aber halt auf der Windows-Seite eher schwach. :-) Unter Windows ist übrigens auch nicht alles sehr einfach. Gerade irgendwelche ADS-Konstrukte, "die man heute so braucht", sind nur mit erheblichem Insider-Wissen zu verstehen. Aber auf dem Desktop, da funktioniert unter Windows tatsächlich "das was man so braucht" (z.B. im Home-Office) "einfach so". Und tatsächlich ohne nennenswerte Support-Last. Dass ich vieles unter Linux machen will, wird toleriert. Dass es da aber erkennbar immer ein bisschen hakt, an subtilen Stellen, wird mit Skepsis betrachtet. Übrigens auch von mir, denn es könnte anders sein. Wird es nun einfacher für das kommerzielle Unternehmen, Linux zu unterstützen, so würde dies vielleicht anders werden, so zumindest meine Hoffnung. Und da könnten Container ein Schritt in die richtige Richtung sein.

...

Nein, das gehört unter Linux systematisiert, statt hundert eigene Süppchen. Und Container existieren und sie sind hier die Lösung.

Linux ist _nur_ der Kernel

Im engeren Sinne ja, ich meinte es jetzt aber erkennbar im Sinne von "die Summe aller Distributionen, die mit einem Linux-Kernel und dem GNU-Userland arbeiten". :-)

und es lebt von seiner Vielfalt. Das ist seine Stärke.

Das stimmt auf jeden Fall. Das sollte man auch nicht aufgeben. Die Lösung ist also NICHT eine einzige Linux-Standard-Distribution und sonst gibt es keine mehr. Übrigens interessant, dass sich hier die Vielfalt gehalten hat, während sonst in der IT ja alles zu einer einzigen Lösung drängt. Die man dann als "Standard" definiert. Zumindest im Manager-Denken. Die Lösung ist ein Ansatz, der es kommerziellen Firmen einfacher macht, ALLE Distributionen zu unterstützen. Mit möglichst wenig Aufwand. Das fehlt heute einfach noch und da verspreche ich mir von den Containern eben einiges. Aber vielleicht kommt ja auch was ganz anderes. Wer weiß das schon.

Jede Monokultur ist anfällig für Schädlinge (Malware) und andere negative Einflüsse. Siehe die Windows-Monokultur.

Oder Android. Auch wenn es auf dem Linux-Kernel basiert. :-) Aber die noch existierenden Alternativen für die Handies finde ich auch nicht besser...

Ein Container ist nur eine kleine, zusätzliche Hürde, die es zu überwinden gilt. Virtuelle Maschinen sind stärker abgekapselt und selbst hier gab es bereits Ausbrüche aus den VMs.

Ja, aber WEGEN der Komplexität von VMs, weil darin eben ein KOMPLETTES eigenes Betriebssystem läuft. Folglich gibt es mehr Angriffsvektoren. Container sind da "schmalbrüstiger" und etwas weniger komplex und zumindest potentiell sicherer. Alles hat seine Daseinsberechtigung. Ich benutze auch im Moment eher die Virtualisierung, um Dinge auf meinem PC ausprobieren zu können und an manchen Stellen auch um sie "abschotten" zu können. Eben weil mir das mit den Containern im Moment noch (!) meist "zu umständlich" ist. Aber wenn eine ganze Distri darauf basiert, dann dürfte das anders aussehen. Es ist vielleicht noch nicht das Heute, aber der Weg in die Zukunft. Gerade unter Linux.

...

Und für Downloads über den Browser wird es schon eine standardisierte Lösung geben - weil Container ja eben ein Standard-Weg sind und kein Anwendungs-spezifischer Sonderschnitz.

Welcher Standard? AppImage? Snap? Flatpak? Ein Format, welches evtl. erst noch kommt?

Keine Ahnung. Da muss sich der Markt eben noch entwickeln, wobei hier auch die Koexistenz von sagen wir drei Verfahren nicht schädlich ist. Oder es werden alle drei Container-Arten unterstützt. Oder mit einer weiteren Schnittstelle abstrahiert. Alles immer noch einfacher für die kommerziellen Software-Firmen als der Alptraum mit den vielen Distris und ihren Sonderschnitzen. Der Container "läuft einfach". Immer und überall. So zumindest die Vision.

In dem Moment, in dem Du einem Anwendungscontainer eine bestimmte Aktion erlaubst senkst Du gleichzeitig die Sicherheit.

Das ist ja immer so. Sicherheit und Funktionalität sind immer gegenläufig. Das sicherste System ist das, was ausgeschaltet ist. :-)

Und wie bekomme ich meine Erweiterungen in den Browser?

Welche Erweiterungen? :-) Chrome-Erweiterungen können doch sowieso nix mehr (außer das, was Webseiten sowieso schon können) und Firefox hat diese Schnittstelle einfach übernommen (und die Erweiterungs-Entwickler vor den Kopf gestoßen). Die Zeiten der "fetten" Browser-Erweiterungen sind vorbei. Was ich auch schade finde, aber das ist der Lauf der Zeit...

...

Ich muss sie vielleicht mit einem anderen Kommando installieren, wenn sie im Container läuft, das ist alles, und selbst das kann und wird die Distri vor mir verbergen.

Wer die Distribution wechselt, der muss sich auch ggf. auf neue Befehle zur Paketverwaltung einlassen. Das wäre bei mir das kleinere Übel. Zu viel verbergen darf die Distri aber nicht. Ich will auch was sehen.

Das ist ja bei Linux bislang immer hervorragend gelungen. Jeder kann auf der Ebene arbeiten, die ihm passt. Sich Arbeit abnehmen lassen oder auch ganz tief reingucken lassen. Heute so, morgen so. Was spräche dagegen, auch einen Container mit rpm, zypper oder yast zu installieren, so dass man nicht mehr drüber nachdenken muss, ob das ein Container oder ein "normales Programm" ist? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Am Sonntag, 19. Juni 2022, 19:18:20 CEST schrieb Richard Kraut:

So ähnlich macht das doch schon Canonical mit Ubuntu. Möchte man den Firefox oder den Chromium installieren wird zwar augenscheinlich ein deb-Paket heruntergeladen aber das ist nur ein Meta-Paket. Es enthält nur die Angaben zu den Abhängigkeiten (snapd und Co.), trägt den Browser in die Paketdatenbank ein und installiert via Script über snap den gewählten Webbrowser.

..und wenn man den so installierten firefox startet kommt nur eine Fehlerdung (die man auf der grafischen Oberfläche nicht mal sieht, sondern nur wenn man's dann nach 3 Versuchen auch mal in der Shell probiert), mit dem Inhalt, dass snap nicht damit klar kommt wenn $HOME nicht mit /home anfängt. RIP Ubuntu für mein netzwerk hier. Cheers Mathias -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

Daniel Bauer schrieb:

...

Ich wollte eigentlich nichts dazu schreiben, aber bei soviel Novitäten-Skepsis wie ich die hier gelesen habe, muss ich dann doch mal.

Ich wollte auch nicht, und ich glaube auch nicht, dass eine Disusion hier irgendwelchen Einfluss auf das hat, was dann wirlich kommt.

Ich auch nicht, aber trotzdem kann man ja drüber diskutieren. Man wird ja nicht dümmer dabei.

...

Der Trend zu den Containern - den sehe ich sehr positiv.

Wird es dann nicht so ein, dass die gleiche Funktion/Library eventuell in verschiedenen Containern in unterschiedlichen Versionen vorliegt, halt abhängig davon, wann der Container von wem gemacht wurde? Dass ich also, wenn ich mehrere Programme laufen habe, unterschiedliche Verhalten/Bugs einer Funktion haben werde?

... dass dann ein Programm Videos zeigen, Musik abspielen kann und ein anderes nicht, weil es nicht die die packman-Versionen enthält? Wie kommen die packman libraries in einen opensuse-container, der diese aus rechtlichen Gründen nicht enthalten kann?

... dass wesentlich erhöhter Memory-Bedarf besteht, weil die gleiche library xmal geladen werden muss? Memory ist ja nicht gerade billig und manche Motherboards erlauben auch nicht besonders viel...

... dass das Laden eines Programms wesentlich länger dauern wird, weil jedesmal ein ganzes Paket von libraries geladen werden muss, die eventuell eigentlich "schon da" wären?

... dass Schwierigkeiten bestehen werden, wenn z.B. ein Programm ein anderes aufrufen will. Ich erinnere mich an einen Digikam-Container, der ein Bild nicht an gewisse andere auf meinem System vorhandene Programme mit "öffnen mit..." übergeben konnte, während die RPM-Version von digikam das sehr wohl kann?

Vermutlich alles davon irgendwie schon. Wobei schon die Frage ist, ob das mehrfach verwendete "wesentlich" zutreffend ist. Die Bedenken sind aber im Grunde zutreffend. Eine Container-Software könnte aber auch hergehen und z.B. eine gewisse Deduplizierung vornehmen, auch im Hauptspeicher (und ja, vielleicht vergrößert das dann wieder die Angriffsfläche für einen böswilligen Ausbruch aus dem Container). Wenn die Container mal so den richtigen Durchbruch erleben, wird es sicherlich Lösungen geben, die alle diese Bedenken etwas "mildern".

...

Effektiv ist es doch schon so, dass professionelle Software, sofern sie unter Linux überhaupt existiert, sich sowieso schon alle Libraries mitbringt, weil alle Distris ihr eigenes Süppchen kochen und sich kein Software-Hersteller drauf verlassen kann, welche Libraries denn grade auf dem System drauf sind. Und genau deswegen sind die professionellen Pakete ja alle so groß.

Ist es nicht so, dass ein RPM Angaben dazu enthält, welche Libraries es benötigt und dann ggf. mit installiert, falls nicht vorhanden?

Ja, diese Angaben sind da, wenn auch RPM nur "meckert", wenn sie nicht erfüllt sind. zypper kann sie auflösen (und fragt noch mal nach). Aber darum ging es mir nicht, daher will ich das gerne noch mal erklären. Eine professionelle Software wie - ich bleibe bei meinem Beispiel - ein Video-Konferenz-Client braucht ETLICHE Libraries. In der Regel bringt sie ja eine GUI mit, muss also irgendwie mit der Xlib arbeiten und noch einem Dutzend Libraries aus diesem Umfeld. Sie benutzt auch etliche standardisierte Dienste im Internet, z.B. WebRTC als bestes Beispiel. Dafür braucht man dann auch wieder Libraries bzw. man greift im wesentlichen auf Browser bzw. *deren* Libraries zurück (heutzutage meistens Chrome). Und hier geht das Problem los. Es gibt Abhängigkeiten der Libraries *untereinander*. Jede Distri installiert unterschiedliche Versionen der Libraries, manchmal sogar mit unterschiedlichen Config-Optionen. Und mit neueren Versionen von Libraries ändern sich auch noch manchmal die Abhängigkeiten der Libraries untereinander (meist kommt noch was dazu). Manche Libraries bringen die Distris gar nicht mit, weil sie keine Open-Source-Software sind, z.B. Chrome. Und ständig bringen die Distris Updates raus, wo sich die Abhängigkeiten wieder ändern. Wenn ich nun einen Video-Konferenz-Client schreiben will, auf welche Library soll ich mich beziehen? Auf eine 5 Jahre alte, nur weil irgendeine konservative Distri die installiert? Nur selbst dann ist nie ganz sicher, ob es auch mit neueren Versionen geht. In der Regel wird der Entwickler zu den neuesten Versionen greifen. Nur dann ist nicht sicher, ob die auch installiert ist. Also bleibt ihm nichts anderes übrig, als die selbst mitzubringen. Und das geht dann über die komplexe Abhängigkeitskette weiter. D.h. "durch die Hintertür" haben wir es bei solcher Software EH SCHON, dass viele Libraries mehrfach installiert werden. Deswegen sind die RPMs für professionelle Software ja auch so groß. Man kann ja mal reinschauen, was da alles so drin ist. Man wird immer mal wieder erstaunt sein. Dies würde durch Container nicht schlechter, sondern besser. Weil nicht jede Anwendung sich selbst überlegen muss, wie sie "ihre Version" der Libraries "einbringt", sondern es gibt ein Standard-Verfahren, eben die Container, die sich um all die Nuancen kümmern, die dabei auftreten.

...

Nein, das gehört unter Linux systematisiert, statt hundert eigene Süppchen. Und Container existieren und sie sind hier die Lösung. Und dann werden auch kommerzielle Firmen Linux besser unterstützen.

Eventuell (wahrscheinlich?) verstehe ich etwas grundsätzlich falsch. Aber ist es nicht so, dass gerade in den Containern jeder sein eigenes Süppchen kocht, während mit den "normalen" Libraries so etwas wie ein Standard besteht?

Wie oben schon geschrieben, es kocht sowieso (fast) jeder sein eigenes Süppchen und erfindet dazu das Rad neu...

...

Und für den Anwender ändert sich erst mal gar nichts. Der Taschenrechner wird wohl auch weiterhin eine "normale" Applikation sein (eventuell auch Teil eines Desktop-Containers), schon der Browser nicht, und das mit Recht. Der ist doch DAS Einfalls-Tor für Malware. Ab in den Container und Ruhe ist. Und für Downloads über den Browser wird es schon eine standardisierte Lösung geben - weil Container ja eben ein Standard-Weg sind und kein Anwendungs-spezifischer Sonderschnitz. Wird vielleicht etwas umständlicher, aber viel, viel sicherer.

Warum ist ein Container sicherer? Die Programme in Container müssen sich ja mit meinen Disks, meinem Memory, meinem Grund-System... unterhalten und wenn die da was ändern möchten, dann können sie das doch, wenn sie es können, egal ob aus einem Container heraus oder "direkt".

Die Container sind ja erst mal abgeschottet, erst mal genau so wie bei chroot. "Richtige" Container erlauben dann DEFINIERTE "Ausbrüche" aus dem Container. Eine "traditionelle" Software hat uneingeschränkten Zugriff auf das ganze System, zumindest mit den Rechten des Users. Das ist schon ein Unterschied.

Wenn ich es recht verstehe, was wohl nicht der Fall ist, dann wäre doch die Gefahr grösser, wenn ich statt einer Library aus einem offiziellen Repo, x Versionen dieser Library in x Containern habe, oder nicht?

Selbst wenn da eine vulnerable Version der Library drin wäre, wäre ja erst mal "nur" der Container angreifbar. Und wenn eine Schwachstelle in der Library im Container entdeckt wird, muss sich eben der Maintainer des Containers drum kümmern (also auch das Fingerpointing wird minimiert). Versionshaltung ist auch bei den meisten Container-Lösungen Bestandteil des Container-Systems, ebenso wie das Deployment.

Mir persönlich wird sowieso nichts anderes übrig bleiben, als dann halt zu nehmen, was kommt. Auf Windows zu wechseln ist für mich nach 20 Jahren Linux keine Alternative.

So kann man es auch sehen... Nein, Windows ist wirklich keine Alternative, das hat andere Schwächen, vor allen Dingen, dass es "zu vernagelt" ist. Und auch ansonsten sehe ich persönlich keine echten Alternativen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel

Am 18.06.22 um 17:57 schrieb Daniel Bauer:

[...]

Warum ist ein Container sicherer? Die Programme in Container müssen sich ja mit meinen Disks, meinem Memory, meinem Grund-System... unterhalten und wenn die da was ändern möchten, dann können sie das doch, wenn sie es können, egal ob aus einem Container heraus oder "direkt".

Wenn ich es recht verstehe, was wohl nicht der Fall ist, dann wäre doch die Gefahr grösser, wenn ich statt einer Library aus einem offiziellen Repo, x Versionen dieser Library in x Containern habe, oder nicht?

...

Und wer prüft diese Libs? So wie es jetzt ist, fühle ich mich da relativ sicher, immerhin schaut da die Linux Gemeinde drauf. In den Containern haben wir keinerlei Kontrolle. Ich hab keine Lust auf Virenscanner für Linux.

...

...

Nein, DAGEGEN habe ich (fast) keine Skepsis.

Mir persönlich wird sowieso nichts anderes übrig bleiben, als dann halt zu nehmen, was kommt. Auf Windows zu wechseln ist für mich nach 20 Jahren Linux keine Alternative.

Ich will das nicht und bin sicher, es wird einen Ausweg geben -- Gruss Bernd

Am Sonntag, dem 19.06.2022 um 04:57 +0200 schrieb Manfred Haertel, DB3HM:

Bernd Obermayr schrieb:

...

...

Warum ist ein Container sicherer? Die Programme in Container müssen sich ja mit meinen Disks, meinem Memory, meinem Grund-System... unterhalten und wenn die da was ändern möchten, dann können sie das doch, wenn sie es können, egal ob aus einem Container heraus oder "direkt".

Wenn ich es recht verstehe, was wohl nicht der Fall ist, dann wäre doch die Gefahr grösser, wenn ich statt einer Library aus einem offiziellen Repo, x Versionen dieser Library in x Containern habe, oder nicht?

...

Und wer prüft diese Libs? So wie es jetzt ist, fühle ich mich da relativ sicher, immerhin schaut da die Linux Gemeinde drauf. In den Containern haben wir keinerlei Kontrolle.

Das Risiko hat doch nix mit Containern zu tun. Wer garantiert Dir denn, dass heute kein böswilliges Kommando im Post-Install-Script von einem rpm drin steht? Oder eine Nicht-Open-Source-Software einen Trojaner enthält, entweder in einer heute schon mitgebrachten Library oder gleich im Executable. Und selbst in Open-Source-Software kann ich keine Millionen Code-Zeilen prüfen. Die Komplexität von Software steigt bekanntlich, zusammen mit der Leistungsfähigkeit.

Umgekehrt wird ein Schuh draus. Wenn die Software in Containern steckt und irgendwas böswilliges enthält, wird sich die Bedrohung erst mal auf den Container beschränken. Wenn sie ein Kommando enthält, was alle Daten löscht, löscht sie nur sich selbst. Soll sie doch.

Ich denke schon, dass es ein Problem ist, wenn ich x Container mit verschiedenen Versionen der selben Library im System habe: Wenn sich raus stellt, dass einige dieser Versionen fehlerhaft sind und die Übernahme des Systems ermöglichen, dann muss ich wissen, in welchen Container diese Versionen enthalten sind, auf die betreffenden Updates warten (Mehrzahl) und diese einspielen. Wenn eine Bibliothek nur an einem Ort gespeichert ist, sinkt der Aufwand beträchtlich. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@web.de / ________________________________/