FreeBSD 13.0 is verschenen

Het Release Engineering-team van FreeBSD heeft versie 13.0 van het besturingssysteem vrijgegeven. De release moet onder andere prestatieverbeteringen brengen. Ook zijn enkele verouderde GNU-tools verwijderd.

Het gaat om de eerste release van de stabiele 13-branche van FreeBSD. Het ontwikkelteam somt de wijzigingen op die bij de release zijn doorgevoerd. Zo hebben de lang-, lld- en lldb-utilities en compiler-rt-, llvm-, libunwind- en libc++-libraries een update ontvangen naar versie 11.0.1. Daarnaast zijn enkele verouderde onderdelen verwijderd, zoals meerdere drivers, de GNU-debugger die aanwezig was voor crashinfo, binutils 2.17 en gcc 4.2.1.

Nieuw is verder dat er in-kernel encryptie is voor TLS 1.0 tot en met 1.3 en dat de 64bit-Arm-architectuur de tier 1-status heeft gekregen. FreeBSD 13.0 is beschikbaar voor amd64, i386, powerpc, powerpc64, powerpc64le, powerpcspe, armv6, armv7, aarch64 en riscv64. De software is te installeren via bootable ISO-images, netwerken of, voor sommige architecturen, via USB-geheugensticks. De release van FreeBSD 12.0 vond in december 2018 plaats.

Reacties (33)

[CurlyMo]

Met misschien IMHO wel de mooiste ontwikkeling. Namelijk dat Linux en FreeBSD vanaf nu de dezelfde codebase gebruiken voor ZFS. Hierdoor zijn ZFS features op Linux en FreeBSD op hetzelfde moment beschikbaar wat de uitwisseling tussen systeem ten goede komst. Op naar een shared codebase tussen alle (populaire) OS' dus incl. Windows en OSX.

[Maurits van Baerle]

Wat @CurlyMo zegt. Dit is eigenlijk wel een Tweakers premium achtergrondverhaal waard.

Normaal zie je in de Open Source wereld toch vooral partijen die splitsen, forken en hun eigen weg gaan. Vaak nog met ruzie ook. Met OpenZFS is er eigenlijk het tegenovergestelde gebeurd.

De Illumos, FreeBSD en ZFS on Linux ontwikkelaars zijn juist samengekomen met een hoop ontwikkelaars uit de commerciële storage hoek (onder meer iXsystems, Delphix en Nexenta Systems) en hebben hun beste implementaties gemerged.

Daardoor krijgen de Linux gebruikers nu bijvoorbeeld voor het eerst TRIM ondersteuning en krijgen de FreeBSD gebruikers verbeterde TRIM ondersteuning omdat de TRIM implementatie die Nexenta heeft gedoneerd beter was dan die versie die voorheen open source was en in FreeBSD zat.

Het voordeel is nu dan ook dat nieuwe features zoals Native Encryption, Zstd compressie, Sequential Resilvering, Persistent L2ARC etc. (binnenkort, in OpenZFS 2.1 die nu in Release Candidate fase, zit komt daar ook nog dRAID bij!) vrijwel tegelijk voor een hele reeks besturingssystemen uitkomen (zodra die OS-en upgraden naar de nieuwste versie van OpenZFS). Niet meer het gedoe dat sommige features alleen op Debian werken maar niet op FreeBSD of andersom.

In praktijk zijn er nu eigenlijk nog maar twee moderne implementaties van ZFS. De closed source versie van Oracle (en het gerucht gaat dat Oracle de interesse verloren is en die hele afdeling heeft opgeheven) en de open source versie van OpenZFS.

Het betekent dus ook veel meer uitwisselbaarheid omdat je voor het eerst een ZFS schijf uit Proxmox kunt debuggen op een Mac of een schijf uit een FreeBSD server kunt bewerken op Ubuntu.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 18:43]

[rob12424]

Het is opzich een goed idee om hier een plus artikel aan te wijden. Maar dan zie ik liever een plus artikel aan de LSB standaard. Met dit als uitbreiding; https://nl.m.wikipedia.org/wiki/Linux_Standard_Base

Veel mensen weten dit niet eens. De orginele oprichter hiervan is overigens de oprichter van Debian (Ian)

Welk voordeel heeft ZFS uiteindelijk nog tegenover Btrfs? Ik begreep dat dat eigenlijk de opvolger was.

[El_Bartholomew]

Verwijzend naar je linkje, Linux volgt eigenlijk Posix niet meer echt dankzij mensen zoals Lennart Poettering met systemd en pulseaudio waardoor systemen zoals BSD juist in een hoek gedrongen werden met het risico op minder ondersteuning van bedrijven ivm drivers ed.

[YaPP]

Linux volgt eigenlijk Posix niet meer echt dankzij mensen zoals Lennart Poettering met systemd en pulseaudio

Ik snap dat spelen op de persoon niet. Zonder mensen zoals Lennart Poettering was het hele bootproces, netwerkinteractie en audiosupport van Linux nog steeds een losse verzameling aan shell scripts. Hij heeft zijn nek uitgestoken om Linux op een hoger niveau te tillen, robuuster te krijgen en het nieuwe eeuw in te tillen. Hiervoor krijgt hij buitengewoon veel commentaar over zich heen.

Dit commentaar is vooral geargumenteerd door "zo deden we dat in de jaren 70/80" niet. en "waarom moeten we veranderen". De centrale coordinatie ontbrak totaal voor systemd. Er was geen coherent beeld waardoor dingen los van elkaar dingen deden en soms tegen elkaar in gingen.

Nu draait Linux er (na groeipijnen, lang leve te weinig Q&A) veel beter door, boot sneller, en kan het blijven concurreren met andere desktop systemen waarin dit soort interfaces al jaren gemeengoed zijn. Dat Linux nog helemaal in de war kon raken van laptops te vroeg dichtklappen, een afgebroken suspend, een extra monitor aansluiten, of audio output niet kan managen terwijl je kabels omplugt kan in de 21e eeuw gewoon niet.

[Reactie gewijzigd door YaPP op 22 juli 2024 18:43]

[CurlyMo]

Hier wordt een vals dilemma gepresenteerd. Tegenover een boot proces gebouwd op shell scripts staat systemd. Maar dat is natuurlijk niet waar. De kritiek is simpelweg dat systemd de kern visie van linux breekt. Namelijk doe één ding en doe dat goed. Sta vervolgens toe dat al die enkelvoudige functionaliteiten aan elkaar kunt knopen. Systemd doet niet één ding goed, maar doet (teveel /) vele dingen in één. Of je dat goed of slecht vind is een tweede.

[Reactie gewijzigd door CurlyMo op 22 juli 2024 18:43]

[rbr320]

Systemd is in zijn geheel inderdaad een complete service laag voor Linux, maar het bestaat nog steeds uit vele losse binaries die door een team aan ontwikkelaars zijn geschreven, dus lang niet allemaal door Lennart Poettering zelf. Die verzameling losse binaries voldoen dus nog steeds aan de filosofie dat je per programma of script 1 ding goed doet.

Daarnaast zou ik ook willen beargumenteren dat SysVinit met zijn start scripts die 1 ding doen, dat ding helemaal niet zo goed doen. Als een proces na gestart te zijn door sysVinit alsnog crasht dan is er geen enkel ander proces dat dat door heeft en corrigeert of rapporteert. Dit was een van de vele tekortkomingen aan het Linux boot proces waar meerdere partijen aan zijn gaan werken om op te lossen. De twee bekendste initiatieven daartoe zijn Upstart van Canonical en systemd, ontwikkelt bij Red Hat door een team onder leiding van Lennart Poettering.

Overigens vind ik een deel van de kritiek die de persoon Lennart Poettering krijgt wel terecht, hij kan nog wel eens slecht reageren op kritiek en bijvoorbeeld ook op bug reports die gedaan worden over zijn code. Desalniettemin is systemd wel echt een verbetering ten opzichte van sysVinit wat betreft het starten en vooral draaiend houden van een Linux systeem en bijbehorende services. Of daar ook bij hoort dat systemd taken op zich moet gaan nemen zoals DNS resolven, de tijd bij houden en wat dies meer zij kun je over twisten, maar er is niets dat je er van weerhoudt om deze systemd services uit te schakelen en weer terug te gaan naar de bekende alternatieven zoals resolvconf en ntpd/chrony.

Overigens een interessante video over de controverse rondom systemd, verteld vanuit het perspectief van een BSD ontwikkelaar: the tragedy of systemd

[rob12424]

Ligt eraan welke Linux, ik ben het deels met je eens, al kwam die discussie van de LSB meer ter sprake door upstart VS init en de concurrentie tussen Ubuntu en Fedora destijds.

Dat vindt ik wel mooi aan Debian, het is ook jammer dat Ian er niet meer is; wie is er voor init en wie is er voor systemd: Okey we houden gewoon beiden aan, maar focussen vooral op systemd

[84hannes]

Op naar een shared codebase tussen alle (populaire) OS' dus incl. Windows en OSX.

Is er niet wat te zeggen voor verschillende implementaties van dezelfde standaard? Als er iets mis is met één implementatie is het fijn als er alternatieven zijn. Dat is van toepassing bij een beveiligingsfout maar ook bij simpelweg afwijken van de standaard. De enige reden waarom standaarden moeten bestaan en kunnen bestaan is in mijn ogen het bestaan van verschillende implementaties.

[CurlyMo]

Ik heb liever dat 8 serieus goede ontwikkelaars (want dat zijn het stuk voor stuk) naar dezelfde codebase kijken, dan 4 koppels van 2 naar hun eigen implementatie van een gedeeld principe.

[WarriorXK]

Het probleem daarmee is dat je samenwerking moet hebben tussen de verschillende partijen over hoe bepaalde features gebouwd moeten gaan worden. Hoewel dit niet perse slecht is, zal dit wel zorgen voor vertragingen en conflicten, waarna er potentieel weer 2 losse forks zullen ontstaan.

[fwsmit]

De twee partijen hoeven alleen maar het eens te zijn over de standaard. Ze kunnen zelf kijken hoe ze het implementeren.
Aan de andere kant zorgt het er ook voor dat er meerdere implementaties zijn die met elkaar concureren, wat in mijn ogen alleen maar een goed ding is. Kijk maar naar c compilers. Je hebt meerdere implementaties die allemaal een ander nut hebben. Zo gebruik ik zelf clang voor real time code checken en gcc voor het compilen zelf.

[beerse]

Als het om 'closed source' zaken zou gaan heb je een heel goed punt. Vooral bij communicatie zaken en bij zaken zoals de extreme veiligheid die ze in vliegtuigen 'eisen'. Dan heb je 2 (of meer?) onafhankelijke implementaties van de zeflde functionaliteit.

Maar dit zouden dan 2 'onafhankelijke' opensource projecten worden. Omdat het opensource is zet ik bewust 'onafhankelijk' tussen haakjes: Ze kunnen immers uitgebreid bij elkaar spieken. En in dat geval zeg ik dat 1 team voor de deel ontwikkeling (hier ZFS) die dan door 2 kampen (FreeBSD en Linux) worden overzien. Dat beschouw ik gevoelsmatig ook als zeer veilig. Laten de wiskundigen en beveiligings-goeroes daar maar een gefundeerde uitspraak over doen. Enneh, nee, dus niet komen met het argument van 2 implementaties. Die heb ik zojuist doorgezaagd omdat ze bij opensource niet onafhankelijk zijn.

[goarilla]

Mja dit is een filesystem, device mapper, raid layer, ... Je wilt toch geen data corruptie omdat verschillende teams de standaarden anders interpreteerden ?

[Streamert]

Dat kon inderdaad geen kwaad. Vanwege de betere driver ondersteuning, en meer ervaring mbt beheer, bij Linux gebruik ik toch al jaren Linux ipv BSD icm ZFS. Hoewel BSD misschien weer betere beheer tools heeft mbt ZFS.

[Saeverix]

bij Linux gebruik ik toch al jaren Linux ipv BSD icm ZFS

BSD is geen Linux, BSD en Linux zijn beide een Unix gebaseerd OS.
https://en.wikipedia.org/wiki/Unix-like

[Streamert]

BSD is geen Linux, BSD en Linux zijn beide een Unix gebaseerd OS.

Dat beweer ik toch ook niet? Het gaat mij hier om ZFS waar @CurlyMo aan refereert.

[Reactie gewijzigd door Streamert op 22 juli 2024 18:43]

[Alex3]

Als je de komma achter beheer wegdenkt in Streamerts bericht is het duidelijker.

[hsb85]

Wat bedoel je met de tweede 'Linux'? Lijkt mij dat je een bestandsysteem benoemt, maar Linux is naar mijn weten geen bestandssystem. Ik gebruik zelf overigens BTRFS (icm met openSUSE) en ik ben daar wel fan van eigenlijk.

[psychicist]

Ik draai de afgelopen weken al FreeBSD 13.0 release candidates op een oudere laptop en ik moet zeggen dat alles prima en snel werkt, zelfs met ZFS op een harde schijf.

De laatste keer dat ik het even gedraaid had, was ongeveer 3 jaar geleden. Dit wordt voor mij een permanent systeem voor FreeBSD en ik zie wel hoe dat in de loop der tijd blijft draaien. Nu alleen nog even een freebsd-upgrade uitvoeren naar de release.

[goarilla]

Encrypteer jij je schijf en/of dan met geli of native zfs encryption ?

[freshy98]

IIRC kun je no booten van ZFS encrypted pools. Dus word het GELI.

[psychicist]

Ik weet niet wat het verschil tussen beide is, maar ik heb op mijn laptop encryptie met geli ingeschakeld. Ik wil op mijn desktop ook wel native ZFS encryptie gebruiken, maar dan moet ik eerst een paar ssd's aanschaffen.

Of ik moet mijn OpenBSD installatie verwijderen, maar daar heb ik even geen zin in.

[batjes]

Niemand heeft ooit de moeite genomen om deftige ext drivers voor Windows te bouwen. ZFS is er ook nog steeds niet en zal waarschijnlijk nooit gaan komen. Microsoft gaat het zeer waarschijnlijk niet zelf implementeren. Redelijk wat ZFS features zitten ook al in NTFS.

[Reactie gewijzigd door batjes op 22 juli 2024 18:43]

[deludi]

ZFS is van een heel ander kaliber dan NTFS. Je kunt beter ZFS met REFS vergelijken.

[beerse]

Voor ext heb je gelijk, dat zou er al lang moeten zijn. Maar microsoft heeft daar al jaren de boot afgehouden. Ook is er een mis-match in de rechten-structuur. Natuurlijk zijn daar vertalingen in te doen maar die worden beter/makkelijker/gestructureerder/controleerbaarder afgevangen door netwerk protocollen zoals naar keuze smb en/of nfs.

Voor zfs moet je het met iets meer afstand bekijken. ZFS is ook maar een implementatie van een aantal features. Zoals een journaled file systeem en redundancy-on-the-fly en wat zfs nog meer aan functionaliteit biedt. En ja, dergelijke zaken is microsoft al jaren in ntfs en nog veel meer in ReFS aan het invoeren. Maar ook hier is het de structuur en architectuur die daar in mee speelt.

Dus tip: Kijk bij microsoft ook naar ReFS (sinds W2016 voor productie):
https://en.wikipedia.org/wiki/ReFS
https://docs.microsoft.co...torage/refs/refs-overview

[Reactie gewijzigd door beerse op 22 juli 2024 18:43]

[Maurits van Baerle]

Er is wel een port van OpenZFS voor Windows. Die heet OpenZFSonWindows.

Die wordt door dezelfde ontwikkelaar onderhouden als de OpenZFS port voor macOS, daarom lijken die twee websites ook als twee druppels water op elkaar.

Waarschijnlijk wordt de macOS versie dit jaar nog geupgrade naar Tier 1 door het OpenZFS project. Dan staat de macOS versie op dezelfde voet als de FreeBSD en Linux versie. Windows naar Tier 1 laat waarschijnlijk nog wel even op zich wachten omdat dat mogelijk wat complexer is.

[ProjWorld]

Nu Windows WSL heeft, is dit ook niet meer echt nodig?

Ik kan sinds WSL2 zonder problemen vanuit de Windows VM een ext2/3/4-schijf benaderen op een andere machine.

[whiner]

Waarom is iedereen zon fan van zfs. Het enige dat ik er overlees is dat je achterlijk veel geheugen nodig hebt om het lekker te laten werken.

[Maurits van Baerle]

Dat is alleen als je dedup aan zet. En als je je moet afvragen of je dedup aan moet zetten dan is het antwoord altijd nee. Compressie heb je in vrijwel elk geval meer aan dan aan dedup. Gewoon uitlaten dus.

Ik heb virtual machines draaien met maar 1 Gig aan RAM en zelfs die draaien gewoon ZFS.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 18:43]

[CurlyMo]

Jaren een VPS gehad met 1GB geheugen die prima ZFS draaide.

[jvnknvlgl]

Jammer van al het gedoe rond de kernel-implementatie van WireGuard, dat had deze release nog net iets beter gemaakt. Lang verhaal kort: een developer had de opdracht van een bedrijf om een kernel-implementatie te maken van WireGuard, de kwaliteit blijkt ontzettend brak terwijl het al wel goedgekeurd was door developers van FreeBSD die niet goed hadden opgelet en zelfs al in productie werd verkocht door het bedrijf in kwestie. Gelukkig zijn onder andere de bedenker van WireGuard (Jason Donenfeld) en anderen er op tijd achtergekomen, en ligt het werk nu apart voor een toekomstige versie van FreeBSD.

Daarnaast: ik gebruik de RCs al een tijdje op mijn oude ThinkPad X220, niet veel over op te merken. Het lijkt een solide release te zijn, maar ik heb er niet genoeg gebruik van gemaakt om echt een oordeel te kunnen vellen. Ik ben zelf toch net meer fan van Linux, Fedora Silverblue in het bijzonder, dus ik zal er niet snel full-time naar overstappen. Toch is het altijd goed om te zien dat de 'buren' ook mooi werk afleveren!

[shintek]

Heeft iemand ervaring met het installeren van FreeBSD op een Power Mac G5 (PPC64)? Open Firmware / boot menu spuugt de disc telkens uit. USB boot is ook vrij lastig.

[Reactie gewijzigd door shintek op 22 juli 2024 18:43]