OpenBSD 6.9 erschienen

CommanderZed

CommanderZed

OpenBSD User
Teammitglied
Guten Tag,

das OpenBSD Team hat das 50. Release, OpenBSD 6.9 veröffentlicht.

Es ist vor allem ein Release mit vielen kleineren und mittelgroßen Änderungen, hier die wichtigsten:

-> Bessere Unterstützung der powerpc64 und arm64 Architektur
-> Erste Schritte in Richtung des Supports von Apple M1 Chips
-> RAID1C Support - Kombination von Raid 1 und Verschlüsselung (Noch nicht Boot-Fähig)
-> Eine sehr große Anzahl an Verbesserungen aus so ziemlich allen Bereichen inkl. Wifi, VMM, SMP, PF, OpenSMTP, httpd, OpenSSH e.t.c.
-> Diverse neue und verbesserte Treiber
-> Aktualisierte Packages inkl. PHP 8, Firefox 88 und Chromium 90.

Hier befindet sich wie immer eine Übersicht der wichtigsten Änderungen

Und hier wie immer eine detaillierte Übersicht der Änderungen zum vor-release

Wie immer kann einfach über sysupgrade aktualisiert werden, alle wichtigen Infos zum Upgrade gibts unter https://www.openbsd.org/faq/upgrade69.html

Da ich "raus gehört" habe das einige Neuerungen der letzten Jahre sich noch nicht breit herumgesprochen haben möchte ich auch noch auf folgendes Hinweisen:

OpenBSD besitzt seit einigen Releases mit

syspatch pkg_add -u und sysupgrade

ein komplettes Framework um alle Updates automatisch durchzuführen.

Dazu gehören die Binary Patches für Sicherheitslücken e.t.c. innerhalb eines Releases (syspatch), Sicherheitsupdates für alle kritischen Pakete (PHP, Browser e.t.c.) innerhalb eines Releases mit pkg_add -u und der releasewechsel mit sysupgrade.
Bei den Updates innerhalb eines Releases ist lediglich ein Neustart der Dienste oder ein Systemneustart nötig.

Das sysupgrade holt automatisch die Tarballs, startet in den RD-Kernel neu und sofern keine Probleme auftauchen entpackt er selbsttätig alle tars und startet dann in den aktuellen release Kernel nochmal neu.
Beim nächsten boot wird sysmerge automatisch gestartet und alle automatisch möglichen Änderungen durchgeführt. Anschließend ist dann noch etwas Handarbeit nötig:

-> sysmerge ggf. manuell aufrufen für nicht automatisch mögliche Configänderungen

-> Die unter https://www.openbsd.org/faq/upgrade69.html#RmFilesbeschriebenen Dateien löschen.

-> pkg_add -u ausführen um alle Pakete zu aktualisieren

Die ersten beiden Schritte dauern idr. wenige Minuten, das pkg upgrade hängt natürlich von vielen Faktoren ab ;)

Auch möchte ich da drauf hinweisen das mit vmm/vmd inzwischen eine Virtualisierungslösung zur Verfügung steht, die für kleinere Szenarien durchaus verwendbar ist und u.a. auch Linux unterstützt.
 
Das waren noch Zeiten, wo es gar keine Möglichkeiten für Updates gab. So nach dem Motto: "Unsere Software ist fehlerfrei. Die braucht keine Updates" :-)
 
Für meine ersten Unixe (SCO Xenix 268 und Interactive Unix) gabs tatsächlich nie Updates. Lag vielleicht an den Quellen meiner Diskettenstapel ... :cool:
 
Zwei Punkte hab ich noch vergessen, villeicht ja für das ein-oder-andere Nutzungszenario interessant:

-> Mit VEB ist eine Lösung zur Bildung virtueller Switche u.ä. hinzugekommen. Es gab vorher schon eine ähnliche Lösung mit bridge die auch weiter gepflegt, aber die neue ist schneller, besser Strukturiert e.t.c. - In diesem undeadly Artikel gibt es mehr details
-> Zwei optional zu nutzende Daemons sind hinzugekommen um Netzwerkverbindungen in typischen Notebookuseszenarien leichter zu verwalten - einmal dhcpleased für DHCP und einmal resolvd für DNS (Im endeffekt Verwaltung der resolv.conf)

(Beide sind für mich tatsächlich sehr sehr praktisch)

berni51 schrieb:
Mal ehrlich: Kann man den Update- und Upgrade-Vorgang noch besser und einfacher machen? Ich glaube nicht. :)
Zum Vergrößern anklicken....

Ich glaube auch nicht, bei mir läuft der jetzt schon durch viele Releases genauso stabil wie ich das bei Qualitätssoftware von OpenBSD gewohnt bin, und die bedienung ist nich schwerer als ein apt-get update oder so, und man hat deutlich weniger Ärger ;)

Zu den Patches in grauer Vorzeit:

Es gab ja in den 80ern z.B. einen Computergesteuerten Linearbeschleuniger der aufgrund eines Softwarefehlers viele Menschen verstrahlt hat und sogar Menschenleben gekostet hat https://de.wikipedia.org/wiki/Therac-25 - da gabs dann ja auch nen Patch
 
CommanderZed schrieb:
Zu den Patches in grauer Vorzeit:
Zum Vergrößern anklicken....
Manchmal hab ich ja so das Gefühl, das durch das Internet und damit verbundene einfache Patchbarkeit auch die Softwarequalität gelitten hat. Früher war patchen halt auch wirklich ein Riesenaufwand. Dementsprechend erpicht war man auch, die Software in möglichst fehlerfreien/fehlerarmen Zustand auszuliefern. Während man heutzutage eher ausliefert und wenn irgendwas schief läuft (kriegt man ja teilweise sogar via Telemetrie mit), patcht man halt nach.

Gut. Das kann man jetzt nicht verallgemeinern. Aber so als Tendenz würde ich das schon so sehen. Jetzt vielleicht weniger bei den BSDs. Aber insgesamt schon.
 
Also dazu möchte ich ganz klar sagen: JANEIN :)

Ich finde es ist ganz eindeutig so das mit der Verbreitung des Internets, also in den späten 90ern, die Softwarequalität deutlich gesunken ist. Man denke an Windows 98, NT 4.0, die damaligen Word & Co versionen, Browser, PC-Spiele, Software aller art e.t.c.

Die Software davor war eindeutig stabiler, aber halt auch deutlich, teilweise sehr deutlich weniger Komplex.

Nochmal nen ordentlichen schub bekommen hat dieser effekt meiner Meinung nach in den 2000ern, als man auch noch mehr, und schnellebigere Features oft mit Druck auf den Markt bringen wollte und musste und gleichzeitig sich das Patchen im Internet weiter verbreitet hat. Diese zeit ist jetzt aber auch schon deutlich über 10 Jahre her.

Seit dem ist es gefühlt etwas besser geworden, zumal die Entwicklung auch eher im anderen Bereich (Smartphones & Co) derartig revolutionär war. Hier helfen sicher auch einige der moderneren Ansätze in der Softwareentwicklung.
Allerdings wird auch gleichzeitig weithaus mehr und wesentlich komplexere und vernetztere Software verwendet, was den Effekt evtl. auch wieder etwas zunichte macht (Und nicht immer ist diese komplexität auch sinnvoll)
 
CommanderZed schrieb:
Die Software davor war eindeutig stabiler, aber halt auch deutlich, teilweise sehr deutlich weniger Komplex.
Zum Vergrößern anklicken....
Das mit der Komplexität stimmt zwar. Taugt aber nur begrenzt als "Entschuldigung" warum die Qualität leidet.
Ganz einfach, weil sich auch die Entwicklungsseite verbessert hat. Softwareentwicklung war noch nie so einfach wie heute.

CommanderZed schrieb:
Allerdings wird auch gleichzeitig weithaus mehr und wesentlich komplexere und vernetztere Software verwendet, was den Effekt evtl. auch wieder etwas zunichte macht (Und nicht immer ist diese komplexität auch sinnvoll)
Zum Vergrößern anklicken....
Das kommt auch als Effekt hinzu. Überbordende Komplexität auch an Stellen, wo es gar nicht nötig wäre. Das ist aber ganz klar die Kategorie: selbstzugefügtes Leid.

Und klar. Featuritis hat auch sein Anteil daran. Es ist halt offenbar viel attraktiver eine Software die zwar fehlerhaft ist aber dafür viele Features hat rauszubringen, als eine solide Software die wenig Features hat. Hier reagiert man zugegebenermaßen auch auf die Anforderungen die sich aus dem Markt ergeben.

Ich sag mal: Wenn die Kunden dem Softwarehersteller seine buggy Software vor die Füße werfen würde, dann würde sich das ändern. Und die Softwareindustrie pflegt ja auch fleißig diesen Mythos, das keine Software fehlerfrei sein kann was auch weitestgehend kritiklos so akzeptiert wird. Und auf regulatorischer Seite (Stichwort Produkthaftung) kommt ja aus der Politik auch nicht allzuviel.

Im Gegenteil. Mit fehlerhafter Software wird sogar noch ein Geschäft gemacht. Ich sag nur: Wartungsvertrag.
Heißt ja nix anderes: Du verkaufst den Kunden ein fehlerhaftes Produkt und lässt ihn dann noch mal für die Nachbesserung löhnen. :-)
Oder Du vermietest Deine Software noch noch. Sprich: Du machst Cloud. Sozusagen das Vendor-Lockin noch weiter ausgebaut.
 
double-p schrieb:
Kann ich nicht "unterschreiben"
Zum Vergrößern anklicken....
Na wenn das mal keine überzeugende Argumentation ist. :-)

double-p schrieb:
und einfacheres patchen fuehrt dazu, dass die auch eingespielt werden.
Zum Vergrößern anklicken....
Jaein.
Dafür, das es inzwischen so einfach ist, wird immer noch viel zu wenig/zu spät eingespielt. Das sieht man ja schön an den ganzen "Hacks". Wie oft heißt es da: "Patch war verfügbar aber wurde (noch) nicht eingespielt".

Heute hast Du teilweise sogar relativ häufig Fälle, das Patches nicht eingespielt werden, weil die könnten ja was kaputt machen. Updates sind nicht mehr unbedingt etwas, worauf man sich freut weil Fehler behoben werden. Sondern weil nicht selten eben auch lediglich alte bekannte Probleme gegen Neue getauscht werden. Da wartet dann der Admin nach dem erscheinen des Patches lieber erst mal ein paar Wochen ab. Und wenn in der Zeit nix in den diversen Medien aufploppt , dann spielt er ihn auch bei sich ein.

Und umso fehlerhafter Software ist, umso höher ist auch der Patchbedarf.
Umso eher werden Patches auch mal gemieden oder in einem "Patchday" zusammengefasst.
 
Andy_m4 schrieb:
Da wartet dann der Admin nach dem erscheinen des Patches lieber erst mal ein paar Wochen ab. Und wenn in der Zeit nix in den diversen Medien aufploppt , dann spielt er ihn auch bei sich ein.
Zum Vergrößern anklicken....

N guter Admin liest eigentlich das Advisory und wenn es benötigt wird, spielt er es mit entsprechender Dringlichkeit ein, oder lässt es bis zu nem Wartungsfenster. Das löst idr auch viel Probleme mit dem "patchen" :)
 
Leider sind viele Anwendungen, gerade in der Windows-Welt, immer noch die Hölle zum Quadrat zu aktualisieren. Wer zum Beispiel mal das "Glück" hatte einen Exchange aktualisieren zu dürfen, weiß aus eigenem Schmerz, was ich meine. :/
 
Nicht zu vergessen, das selbst wenn es geht Patches auch nicht immer eingespielt werden "dürfen". Weil da zum Beispiel ein bestimmter Ist-Zustand (ironischerweise manchmal sogar noch security-)zertifiziert ist und wenn Du da was patchst gilt der Zustand nicht mehr und damit ist auch die Zertifizierung hinfällig. Da muss dann ggf. erst langwierig neu zertifiziert werden usw.

Auf der anderen Seite erhält man als Angreifer durch die Patches auch wertvolle Informationen. Man kann dann nämlich einfach sich die Dateien angucken: Vor dem Patch - nach dem Patch
und kommt dadurch dem Problem relativ schnell auf die Spur. Demensprechend schnell gibts dann auch Exploits und auch Angriffe in freier Wildbahn. Ein Patch sollte also nach erscheinen möglichst schnell eingespielt werden.
Wenn Du da irgendwie erst in ein paar Wochen ein Wartungsfenster machst oder gar Dein System noch neu zertifizieren musst, dann ist das halt höchstproblematisch weil so viel Zeit zwischen Veröffentlichung des Patches und dem eigentlichen einspielen vergeht.

Beim Thema Softwarequalität wird ja auch manchmal argumentiert, das wenn man die Qualität erhöhen würde wollen (sei es nun durch Regularien oder wie auch immer), dann auch die Kosten steigen würden. Weil halt Qualitätssicherung etc. auch mit Aufwand verbunden ist. Das ist zweifelsohne richtig.
Auf der anderen Seite: Die Update-Infratruktur verursacht auch kosten. Die Admins die Updates prüfen und einspielen arbeiten auch nicht für Luft und Liebe. Und wenn mal ein Security-Problem durchschlägt ist das teilweise auch mit durchaus enormen Kosten verbunden.
Wäre mal spannend zu gucken, was letztlich billiger wäre. Ich hätte da so meine Zweifel, das es zugunsten der gelebten Realität ausgeht.

Man könnte jetzt denken, das der Markt das dann schon regelt. Wenn hohe Softwarequalität letztlich billiger ist, dann wird sich das auch über kurz oder lang durchsetzen.
Allerdings ist das ja nicht das Anreiz-System welchem die Markteilnehmer ausgesetzt sind.
Das sieht nämlich eher so aus:
Für den Softwarehersteller ist es natürlich attraktiv seine Produkte billiger anzubieten. Und er muss zwar die Patches schreiben, kann aber die Kosten für das einspielen auf die Kunden abwälzen. Entweder in dem die halt Admins beschäftigen die das machen müssen oder indem er das selbst als "Service" verkauft.

Für den Käufer ist das ebenfalls attraktiv. Aus BWL-Sicht ist es besser einen Euro morgen auszugeben als heute. Weil die Quartalszahlen sollen ja gut aussehen. Also schiebe ich die Kosten lieber in ein späteres Quartal. Dann muss ich mich zwar dann mit dem Problem herumschlagen, aber bis dahin hab ich vielleicht schon was Anderes gefunden. Falls ich danach den Job überhaupt noch habe und sich nicht sowieso mein Nachfolger damit herumplagen muss.
Da ist es unattraktiv eine Lösung zu kaufen die vielleicht das zehnfacher kostet, selbst wenn die dann auch 10 oder 20 Jahre hält ohne Mucken zu machen.
Außerdem ist es auch aus anderen Gründen unattraktiv eine langfunktionierende Lösung zu haben. Weil Du hast dann zwar keine Bugs und kriegst auch durch Updates keine neuen Bugs, aber Du kriegst halt auch keine neuen Features (ob man die braucht oder nicht sei mal dahin gestellt; es wird uns ja auch gerne eingeredet das man die brauch :) ).

Das Phänomen hat man übrigens auch in der physischen Welt. Wenn ich überlege, wie lange man früher ein Fernsehgerät hatte. Und wenn das mal kaputt ging, hat man nicht einfach bei Amazon ein neuen bestellt oder ist mal schnell rüber zum MediaMarkt gefahren, sondern dann kam der Fernsehmonteur und hat den repariert. Kann sich heute gar keiner mehr vorstellen. :-)

Aber das soll jetzt nicht als ein "früher war alles besser" missverstanden werden. Auch früher gabs Schrottsoftware genauso wie es heutzutage auch qualitativ hochwertige Software gibt.

Aber so als Trend mein' ich das durchaus so wahrzunehmen. Auch in der eigenen Erfahrungswelt. Wenn es früher ein Problem gab, dann hab ich immer zuerst geguckt, obs an mir liegt. Weil es halt auch ganz häufig letztlich so war das ich dann irgendwo was falsch gemacht hab und deshalb die Software nicht so funktionierte wie sie sollte und nicht irgendein Bug.
Wenn es heute ein Problem ist, starte ich erst mal neu oder "resette". Oder guck im Bugtracker. Weil es eben häufig so ist, das das das Problem löst bzw. ich da fündig werde und es seltener sich als Bedienfehler herausstellt.
 
Ich glaube den Punkt das man Dinge ja auch gerne noch Updates, Wartungsverträge, neue Versionen e.t.c. Verkaufen möchte ist ein wichtiger Punkt.

Es gibt ja durchaus einige Unternehmen die an zu guten Produkten die man zu selten neu kaufen musste dann auch Wirtschaftlich gescheitert sind :)

Das zieht sich ja durch enorm viele Branchen, aber bei der IT und Unterhaltungselektronik Branche als "ganz weiten Begriff" ist es wirklich ganz besonders "krass", vor allem auf Kosten der endlichen Ressourcen unseres Planeten, aber teilweise auch auf Kosten der Konsumenten, der Funktionalität e.t.c.
 
Andy_m4 schrieb:
Nicht zu vergessen, das selbst wenn es geht Patches auch nicht immer eingespielt werden "dürfen". Weil da zum Beispiel ein bestimmter Ist-Zustand (ironischerweise manchmal sogar noch security-)zertifiziert ist und wenn Du da was patchst gilt der Zustand nicht mehr und damit ist auch die Zertifizierung hinfällig. Da muss dann ggf. erst langwierig neu zertifiziert werden usw.
Zum Vergrößern anklicken....
Meiner Erfahrung nach werden inzwischen eher die Entwicklungsprozesse als die Software zertifiziert. Wobei Softwarezertifizierung gerade in meinem Bereich eher machbar ist, da immer von der Prämisse ausgegangen wird, dass die Geräte an einem reinen Feldnetz hängen, das nicht vom Firmennetz aus erreichbar ist.
 
Das Problem ist halt auch irgendwo systemimmanent. Die Wirtschaft muss wachsen. Wenn sie nicht wächst, dann wird das schnell zum Problem. Wachstum heißt aber nix anderes als das ich im kommenden Jahr mehr produzieren muss als im Vergangenen.
Irgendwann ist aber halt der Markt gesättigt. Als Ausweg um doch weiter zu wachsen kann man natürlich seinen Kram ins Ausland verkaufen. Aber über kurz oder lang ist natürlich auch dort jeder versorgt.
Die andere Sache die man machen kann ist die Produktzyklen zu verkürzen.

Im Grunde haben wir heutzutage eine Überproduktion. Wir produzieren mehr als wir brauchen. Benötigen dazu aber auf der anderen Seite Ressourcen, die immer knapper werden (vom Umweltaspekt und der daraus abgeleiteten Zerstörung der Lebensgrundlagen ganz abgesehen).
Eine durch und durch verrückte Handlungsweise, was aber glücklicherweise immer mehr ins öffentliche Bewusstsein gelangt. Ob das reicht, um "die Kurve zu kriegen" wage ich aber dennoch zu bezweifeln. Das Kind musste schon bisher immer erst in den Brunnen fallen, bevor sich etwas ändert. Es hat noch nie gereicht darauf hinzuweisen, das es bereits gefährlich nah am Brunnenrand herumkrabbelt.

Aber so langsam kommen wir thematisch von OpenBSD ab. Nicht das das noch Ärger gibt. :-)
 
Kamikaze schrieb:
Meiner Erfahrung nach werden inzwischen eher die Entwicklungsprozesse als die Software zertifiziert.
Zum Vergrößern anklicken....
Ja. Wobei ich die Kritik (oder vielleicht besser gesagt: Skepsis) eher generalisiert sehen würde. Hat uns der "Zertifizierungsquatsch" eigentlich je irgendwie was signifikantes gebracht, außer das halt einfach mehr Leute daran beteiligt sind die "Taschen vollstopfen" konnten und man damit werben kann, das man zertifiziert ist?

Die Kernkraftwerke in Fukushima waren auch zertifiziert.

Zertifizierung verhindert keine Probleme. Das ist auch gar nicht ihre Aufgabe, auch wenn Man das gemeinhin gerne glaubt. Zertifizierung dient vor allem dazu, Schuld abzuwälzen. Das wenn es ein Problem gibt man immer darauf zeigen kann: "Wir waren doch zertifizert".
Der zweite Punkt ist, das Zertifizierung Geld und Aufwand kostet. Und was in die Zertifizierung fließt, kann halt nicht ins Produkt fließen.

Um mal wieder ein bisschen on-topic zu werden. OpenBSD ist weder zertifiziert noch steckt ein zertifizierter Entwicklungsprozess dahinter.
In der anderen Ecke steht zum Beispiel Windows Server, was irgendwie diverse Common-Criteria-Zertifizierungen vorweisen kann.
Welches würde man jetzt wohl als sicherer ansehen? :-)

Ich weiß. Das Beispiel ist sehr plakativ (und es lassen sich natürlich genausogut Gegenbeispiele finden), aber ich glaub' es wird klar, was ich sagen will. :-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben