Login
Newsletter
0
Von klopskind am Mo, 14. Oktober 2019 um 15:22

typisch Troll ;)

0
Von klopskind am Mo, 14. Oktober 2019 um 15:18

1. openSUSE wird hier meines Empfindens nach nicht grundsätzlich schlecht geredet. Tamaskan hat keine Märchen verbreitet, sondern lediglich einen kritischen Einwand geäußert.

2. Ich kann nicht erkennen, inwiefern jene Kritik etwas mit alten Versionen von openSUSE oder YaST zu tun hätte. Meiner Warte ging es um den aktuellen Zustand in openSUSE und anderen Distributionen bzw. deren Vergleich.

3. Handelt es sich tatsächlich um "Bashing", wenn mehrere Distributionen simultan für die selben Dinge kritisiert werden? Genau das hat Tamaskan doch getan: so wurden neben openSUSE auch Debian und Ubuntu genannt. Fedora als ein Alternative. (Wobei Ubuntu wie Fedora auch ein Werkzeug fürs Release-Upgrade mitbringt. Aber das nur Rande.)

4. Die Plausibilität der von Ihnen suggerierten Absichten nicht nur Tamaskans (siehe die letzten zwei letzten Sätze Ihres Kommentars) kann ich in diesem Zusammenhang nur mit Mühe erkennen.

0
Von eugeniak2 am Mo, 14. Oktober 2019 um 15:13

10 Jahre openSUSE, danach 4 Jahre Arch und Debian Sid.

0
Von klopskind am Mo, 14. Oktober 2019 um 14:59

Doch, will man. Einfach, weil man es kann.
Die Betonung liegt hier offensichtlich auf "kann". Nicht jeder weiß, was die Software welches Pakets tut, wie sie arbeitet, wann/wie/wo sie ihren Zustand speichert, welche Bibliotheken sie dabei nutzt und ggf. nachlädt, usw. Es hängt ganz stark von der Software und den spec-/control-Skripte der einzelnen Pakete abhängen (die der DEB-Pakete sollen per Richtlinie idempotent sein [0] - Wer prüft das bitte?; in der RPM-Welt sieht es vermutlich ganz ähnlich aus.), die dort aktualisiert wird. Und dieses Verhalten ist mitunter nicht nur paket- sondern auch versionssepzifisch/-abhängig.

Zudem können sich weitere, von Entwicklern oder Paketierern unbeabsichtigte oder unvorhergesehene Fehlerquellen einschleichen.

Ist doch nicht so schwer, nach Aufruf von [...]
Kann es an dieser Stelle nicht bereits "zu spät" sein? Szenario: Dienst A1 wird aktualisiert während er läuft. Er soll neugestartet werden, wofür aber dessen Zustand serialisiert werden muss. Tut er das mithilfe eines noch gestarteten Prozesses A2, geschieht dies mit den aktualisierten Komponenten/Bibliotheken, welche der Dienst A1 noch nicht geladen hatte, was zu einer fehlerhaften Serialisierung des Zustands führen kann (z.B. soname-Inkrement mangels Abwärtskompatibilität). Der Zustand könnte bspw. eine Konfiguration, ein Benutzerprofil, ein Arbeits- oder Brechnungsfortschritt oder eine Datenbank sein.

Und das wäre nur ein einziges Szenario. Letztlich geht es eigentlich darum, den Zustand des Systems strikter von den Daten zu trennen. Da hilft ein Separierung der Durchführung der Aktualisierung vom Rest, z.B. mittels Neustart, ungemein. Genau deswegen existieren etwaige Bestrebungen, Entwicklungen und Alternativen.

In diesen Zeiten, in denen read-only Systeme oder Container am laufenden Band neu erstellt angepasst, zusammengesetzt, neu erstellt, (neu-)gestartet oder/und beendet werden, spielt diese Form der Systemaktualisierung ein untergeordnetere Rolle (auch für die Entwickler/Paketerierer!), siehe Kubic, Project Atomic / Atomic Host, Silverblue, CoreOS, Docker, Kubernetes etc.

Verschiedene Systeme haben hier unterschiedliche Anforderungen. Aber die müsste der Nutzer kennen. So entstehen bspw. auf dem Desktop folgende Probleme, [1].

Eine Anekdote darf nicht fehlen: Ich persönlich hatte auch mal mit einem Fall zu tun, bei dem Firefox aktualisiert wurde während es lief. Dann wurde eine neue Firefox-Instanz gestartet (nicht besonders "schlau", wenn man es denn weiß), und nach dem Schließen beider Instanzen, gab es bei darauffolgenden Starts einen Dateiformatkonflikt einer Datei des Benutzerprofils. Ich glaube mich zu erinnern, dass es eine von Firefox erstellte und verwendete SQLite-Datenbankdatei betraf.

Ich denke, dass es genügend realistische Hinweise dafür gibt, dass offline-Upgrades robuster sind als online-Upgrades - insbesondere dann, wenn jemand nicht 100% weiß, was sie/er tut.


Quellen:
[0] - Debian-Richtlinie: idempotente Maintainer-Skripte
[1] - "dnf update" considered harmful

0
Von Oiler der Borg am Mo, 14. Oktober 2019 um 14:42

wäre mir die Nutzung wohl deutlich zu *eckig* :down:

0
Von blablabla233 am Mo, 14. Oktober 2019 um 14:38

typisch arroganter Mensch

0
Von blablabla233 am Mo, 14. Oktober 2019 um 14:34

OpenBSD ist tendenziell schon schon bisschen mehr auf sicherheit unter allen umstaenden bemueht wie es andere "Distros" sind, und nein ich sage nicht OpenBSD sei sicherer.
Mit der Lizenz hat das nat nichts zu tun.

0
Von flipster am Mo, 14. Oktober 2019 um 13:24

typisch arroganter linuxer

0
Von flipster am Mo, 14. Oktober 2019 um 13:23

wat wer bist du denn ???? ^^

0
Von flipster am Mo, 14. Oktober 2019 um 13:23

ich hab mit bsd und anderen offenen und/oder freien lizensen auch kein problem. mich wundert nur das eine offiziell zertifzierte gnu distro sich ausgerechnet bei openbsd bedient. openbsd hat einen schwerpunkt auf sicherheit: sagt hyperbola dann das gnu/linux alleine nicht sicher ist? gpl über alles aber für die sicherheit is uns bsd lieber?

wie gesagt ich hab mit bsd gar kein problem. bsd is mir fast schon lieber weil die leute dort viel relaxter und nich so arrogant sind. nicht so viele fanatiker wie bei der fsf

0
Von Drubadix am Mo, 14. Oktober 2019 um 13:18

Du weißt doch gar nicht, ob überhaupt jemand von den Nettrunner - Rolling Leuten bezahlt worden ist.
Eventuell wurde nur der Platz auf einem Webserver gefördert.
Im Zweifelsfall war es aber eine gute Sache.
Seit Jahren fördert Blue Systems freie Entwicklungen wie kwin und Calamares ohne damit Geld zu machen.
Da würde ich jetzt nicht so ab lästern.

0
Von msi am Mo, 14. Oktober 2019 um 13:14

Was ich geschrieben habe, ist kein "Abrutschen" und nicht "dürftig begründet". Das sind nachprüfbare Fakten. Und die stellen Studenten der "Theoretischen Wolkenkuckucksheimologie" natürlich immer vor Probleme.

Vor Probleme stellt vielmehr das hier geäußerte Ressentiment.

Tu Dir keinen Zwang an.

Na, a bisserl Zwang ist schon hier und da vonnöten.

Klar, das Verbiestert-Sauertöpfische gehört ja auch zur Linken wie die Beule zur Pest.

Wer oder was alles so zur Linken gehört, interessiert mich zumeist nur als Material der Kritik. Allerdings verfahre ich in dieser Kritik dann – das unterscheidet uns wesentlich – nicht nach der sehr deutschen Manier, diese Linke, die ja aus – wenn auch zum Teil sehr abstoßenden – Menschen besteht, zu einer hochansteckenden Infektionskrankheit zu stilisieren, die konsequenterweise auszurotten wäre.

Dein restliches Gebabbel zu kommentieren, spar ich mir.

L’Chaim!

0
Von blablabla233 am Mo, 14. Oktober 2019 um 12:51

Die Beer-License und die WTFPL sind so oder so die einzig wirklich freien.
Mit ISC, MIT und BSD2/3 komm ich aber auch klar :-)

0
Von Anonymous am Mo, 14. Oktober 2019 um 12:44

Ich auch ;)

Üblicherweise ist das ein Euphemismus für "wir stampfen ein erfolgloses Produkt ein und schmeißen ein paar Leute raus, deren Gehalt wir ohnehin nicht mehr zahlen können.

Aber im vorliegenden Fall ist das wohl eher ungeschickte Wortwahl, denn Blue Systems ist ja mehr ein Hobby eines reichen Wurstfabrik-Erben und braucht nicht so aufs Geld zu gucken.

0
Von blablabla233 am Mo, 14. Oktober 2019 um 12:37

Klar kannst Du das, die frage ist ob Du das Personal, die Zeit, und die Absicherung hast.
Die scheinbare "Garantie" und das "Wissen" ist ja genau das was bei Enterprise den Unterschied macht.
Ist dem Admin egal gefaelt dem Management aber unglaublich....und am ende sagen die was geht (was meist nicht optimal ist...das wissen wir wohl beide)

0
Von Bert am Mo, 14. Oktober 2019 um 12:30

.. wie viele Pakete in universe und multiverse ..
https://usn.ubuntu.com/
Viel Spaß beim Suchen.

Würde Ubuntu wirklich so "schlecht" sein, würde es auf keinem Server laufen. "Nicht umsonst bieten Firmen wie Dell und Hewlett Packard Server mit diesem Betriebssystem an."

.. vergleiche das mit Debian stable ..
Unzulässig. Weil Debian immer hinterherhinkt. Veraltete Software ist natürlich immer fehlerfreier - solange sie gewartet wird. Veraltete Software nimmt man dann, wenn man keine weiteren Ansprüche hat.

Aber das Leben ist ein Kompromiss. Auch vor dem Computer. Kein Mann schafft sich eine alte Frau an, nur weil sie "so gereift" ist. ;-) Bei französischen Präsidenten, die kein Moped haben, ist das vielleicht anders. ;-)

0
Von klopskind am Mo, 14. Oktober 2019 um 12:30

Hier, extra für Sie persönlich, eine mit Kommentaren gespickte Liste "freier" Lizenzen des FSF-finanzierten GNU-Projekts, welches in diesem Kontext die selben Definitionen wie die FSF verwendet.

Merke: Falls man eine Diskussion beginnen und führen möchte, aber sich dabei nicht total disqualifizieren möchte, sollte man zuvor die Definitionen und Bedeutungen der Begriffe, die dieser Diskussion inhärent zugrunde liegen, wenigstens gelesen haben. Wenn Sie sie zusätzlich verstanden und durchdrungen haben, wird die Diskussion auch um so interessanter. ;)

0
Von anyoneirgendwer am Mo, 14. Oktober 2019 um 12:22

Nicht weil Gentoo schlecht wäre, sondern weil ich einfach eine Distribution wollte die ich auch normalen Anwendern empfehlen kann.
Wenn ich eine solche Distribution selbst nutze, kenne ich auch die Ecken und Kanten.

Solus ist wirklich super!

0
Von klopskind am Mo, 14. Oktober 2019 um 12:21

1. Ja, für das Hyperbola-Projekt ergibt es Sinn. Deren Begründungen wurden im Artikel genannt bzw. darauf verwiesen. Diese basiert auf einer Abwägung der ebenfalls im Artikel verwiesenen Grundsätze des Projekts.

2. Die Lizenzen, die OpenBSD und dessen Teilprojekte (Xenocara, LibreSSL, OpenSSH, ...) verwenden, insbesondere also modernere Varianten der BSD-Lizenz(en), sind "frei" gemäß der FSF, [0].

3. Xenocara ist im Wesentlichen ein Fork von der X11-Implementierung von X.org. Die Quelltexte letzterer stehen unter X11-Lizenz oder einer von diversen MIT-/BSD-ähnlichen Lizenzen, [1]. Als OpenBSD-Projekt enthält Xenocara neben diesen Quelltexten höchstens noch welche, die unter der von OpenBSD präferierten ISC-Lizenz oder Public Domain verfügbar sind, [2].

Obwohl mir an dieser Stelle aufgrund der Fülle der verwendeten Lizenzen bzw. dem zeitlichen Aufwand dafür, diese einzuordnen, unklar ist, inwieweit hier Punkt 2 relevant ist, gelten, bis auf einige ältere Varianten der BSD-Lizenzen, alle unter diesem Punkt genannten Lizenzen als "frei" im Sinne der FSF, [0].

4. LibreSSL ist ein Fork von OpenSSL und steht derzeit unter OpenSSL/BSD/ISC/Public Domain [3], welche ausschließlich "frei" gemäß FSF sind, [0]. OpenSSL steht nach einem Lizenzwechsel nach dem LibreSSL-Fork inzwischen unter ASLv2, welche die FSF ebenfalls als "frei" deklariert, [0].

Man könnte argumentieren, dass die ASLv2 im Sinne der FSF "freier" als der vorherige Lizenzierungszustand sei, "aber das ist eine andere Geschichte" und bringt uns wieder zum Thema der unter Punkt 1 erwähnten Abwägungen des Hyperbola-Projekts zurück.


Quellen:
[0] - Lizenzliste des GNU-Projekts samt Kommentaren (von der FSF finanziert)
[1] - X.org-Quellverzeichnis
[2] - Xenocara-Quellverzeichnis
[3] - LibreSSL-Lizenztextdatei

0
Von André Ramnitz am Mo, 14. Oktober 2019 um 12:18

...und durch den muqss-scheduler/ck-patchset ersetzt wird.

Ref 1
Ref 2


 
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten