Fedora 33 met Gnome 3.38 en bestandssysteem btrfs is uit

Fedora 33 is officieel uitgebracht. Het besturingssysteem draait op Gnome 3.38 en maakt voor het eerst gebruik van btrfs als standaard bestandssysteem. De makers hebben ook functies doorgevoerd voor Fedora IoT.

Versie 33 van Fedora Workstation is officieel uitgebracht voor alle desktopgebruikers. De desktopvariant maakt gebruik van de Gnome 3.38-gui die vorige maand uit kwam. Nieuwe gebruikers van het besturingssysteem kunnen daarin gebruik maken van een nieuwe Tour-app om het OS te leren kennen. Verder zijn de meeste veranderingen in Gnome 3.38 cosmetisch van aard. Zo krijgt Fedora 33 ook ondersteuning voor geanimeerde bureaubladachtergronden.

Een belangrijke vernieuwing in het OS is dat Fedora voortaan gebruik maakt van btrfs als standaard bestandssysteem. Dat was sinds Fedora 11 altijd ext4, maar volgens de ontwikkelaars is btrfs beter geoptimaliseerd voor ssd's. Het bestandssysteem ondersteunt bestandscompressie, al wordt dat een opt-in-feature.

Fedora 33 wordt ook geleverd met bijgewerkte system library-packages, zoals Python 3.9, Ruby on Rails 6 en Perl 5.32. Gebruikers die KDE verkiezen boven Gnome, zien standaard EarlyOOM ingeschakeld en op beide gui's is nano voortaan de default editor.

Gnome 3.38

The Fedora Project waarschuwt gebruikers ook dat secure boot in bepaalde gevallen kan worden uitgeschakeld, al zegt het bedrijf dat dat bij slechts een klein deel van de gebruikers zo is. Het bedrijf verwijst naar de recent ontdekte Boothole-kwetsbaarheid in grub2 waarmee secure boot te omzeilen is. Het certificaat waarmee de Fedora-bootloader wordt ondertekend, wordt vanwege Boothole op termijn vervangen. Dat gebeurt voor de meeste gebruikers pas halverwege volgend jaar, maar gebruikers die andere besturingssystemen draaien of bepaalde firmware-updates hebben gekregen, kunnen daar mogelijk al last van hebben. In dat geval raden de ontwikkelaars aan secure boot uit te schakelen tot er een update met een nieuw certificaat beschikbaar is.

Naast de desktopvariant brengt Fedora 33 ook een wijziging mee voor de iot-component. Fedora 33 IoT, dat onlangs de officiële Edition-status kreeg, krijgt nu ondersteuning voor Platform Abstraction for Security of Parsec, een api om hardware beter te beveiligen. Fedora 33 is te downloaden op getfedora.org.

Door Tijs Hofmans

Nieuwscoördinator

28-10-2020 • 17:00

58

Reacties (58)

Sorteer op:

Weergave:

Prachtig mooi project, Fedora, denk dat veel mensen onderschatten hoeveel werk die developers van Red Hat verrichten. En het mooie van free software is dat dan het hele Linux ecosysteem (en zelfs daarbuiten) van die arbeid mee kan profiteren.
Vlak Debian,CanonicaL (Ubuntu) ook niet uit. Persoonlijk vind ik apt(get) veel relaxter werken, geen onnodige dependency hell meer.
Fedora gebruikt DNF. Ik denk niet dat er een meer gebruiksvriendelijke en snelle package manager bestaat.. Het vroegere YUM was al superstabiel en geavanceerd, DNF is een waardige opvolger.

Zelf ben ik tevreden over Ubuntu (PopOS) maar vooral omdat het wat laagdrempeliger werkt dan RHEL.

RedHat heeft overigens mega veel voor linux betekent. In 1999 was RedHat episch. Ik zat toen op 13-14 jarige leeftijd bij een computerclub (CCL) waar een aantal engineers van Philips RedHat draaiden. Magische tijd..
Ik werk momenteel als engineer bij Philips en we werken nog steeds met RedHat.
Gebruikt Philips RedHat op de desktop of voor andere toepassingen?
Veel meer dan het bovenstaande mag ik helaas niet vrijgeven.
Redhat trekt idd een groot deel van de kar als het op linux ontwikkeling aankomt, maar poets ook de overige distributies niet uit. Denk daarbij aan SuSE, Debian, Ubuntu, etc.
Ik vind het belachelijk dat je gedownload wordt. Ook canonical doet veel goede dingen, al zal het nooit mijn os worden. Teveel dependancy hell mee gehad... ;)
Maar serieus, die ellende bestaat aan beide kanten ongeveer even erg. Hoe erg? Vijftien jaar geleden was het soms wat onhandig, tegenwoordig eigenlijk nooit meer. Ja, als ik zelf pakketten bouw.

Edit: verdammte autocorrect

[Reactie gewijzigd door Heidistein op 31 juli 2024 20:47]

autocorrect weer gewerkt? gedownmod moet het zijn? :D
ik kaap deze thread even,

het probleem dependency hell is inmiddels opgelost door de wetenschap (Universiteit Utrecht) daaruit is de Nix package manager ontstaan, waar dus dependency hell issues niet bestaan. Na een upgrade kun je ook altijd terug naar exact de vorige versie van je systeem, dus upgraden is 100% veilig.

Nix verslaat dus rpm, deb, en alle anderen omdat ze het dependency probleem als een wiskundige probleem hebben geformuleerd en opgelost.

NixOS - onderschat revolutionair
Opvallend genoeg lijken de flags van nix-pkgs op die van RPM (-q en -e iig). Voor een Debian gebruiker zols @zvbhvb even wennen.

Ook geestig hoe fijn snapshots werken. Geen btrfs of ZFS nodig.

De Nix package manager is te gebruiken op ongeveer elk OS. Dus bijv ook op macOS (Homebrew bevat de meeste software maar heeft security issues). Wilde laatst Linuxbrew op een Synology proberen maar had geen (recente) Ruby. Met Nix zo opgelost.

NixOS/Nix is ook uitermate geschikt voor devops. Je hebt ook niet eens root nodig voor Nix.
Je hebt ook niet eens root nodig voor Nix.

Ook niet als je een nieuwe kernel(-module) installeert?
Dat is mischien wel heel vrijgezind op een server.

[Reactie gewijzigd door zvbhvb op 31 juli 2024 20:47]

Vindt het jammer dat Tweakers geen aandacht aan NixOs wil besteden. Is volgens mij wel een van de grotere Nederlandse distributies.
Goh, en dat terwijl RHEL eerder juist gestopt was met btrfs.
Aangezien Fedora de beta voorloper is van RHEL, zou btrfs dan ook weer in RHEL belanden?
Ben benieuwd wat er is veranderd; is het nu stabiel genoeg?

@Eonfge/@sebati, bedankt voor de uitleg!
Ikzelf ben ook btrfs fan, bij mij werkt het al 10 jaar ofzo prima.
Maar dat geldt niet voor iedereen; bijv omtrent parity RAID en ENOSPC (of defrag die CoW dwarszit) waren er al heel lang issues. En ik begrijp dat SUSE n feature blacklist hanteerde om bepaalde bugs te vermijden. Leuk als dat werkt, maar elegant is anders natuurlijk.

Het droppen van btrfs door RH, interpreteerde ik als dat ze er gewoon geen vertrouwen meer in hadden dat het zou verbeteren.
Dus ja dan is het voor mij wel goed nieuws als nu (na SUSE en Facebook) ook RH als grote speler er meer vertrouwen in heeft en investeert.

[Reactie gewijzigd door N8w8 op 31 juli 2024 20:47]

Van de geruchten die ik erover hebt gehoord: Het was toen nog niet klaar voor het niveau van Enterprise support dat Red Hat aanbied. Als RHEL iets ondersteund, dan vraagt Red Hat daar veel geld voor en dan steken ze er veel moeite in om het werkende te krijgen en te houden. BTRFS was voor hun gewoon nog niet goed genoeg in 2015.

We zijn nu 5 jaar verder en Fedora wilt het wel een nieuwe kans geven. Belangrijker nog, is dat Fedora een Linux distributie is die zich richt op ontwikkelaars die graag de laatste software willen gebruiken. Fedora is niet voor de standaard consumenten (zover die bestaan in Linux) maar voor een gespecialiseerde groep nerds. En om deze nerds BTRFS te laten testen voordat het in RHEL terug komt, is heel logisch.

Als Linux gebruiker en vrijwilliger bij sommige projecten, draai ik ook Fedora. Nog geen BTRFS want daarvoor moet je een nieuwe installatie doen, maar Fedora is wel ideaal als je de nieuwere componenten wilt, zonder de risico's van Arch of de mismanagement van Manjaro.

De update had 1 hick-up: Ik moest eerst even gstreamer1-plugins-bad-freeworld verwijderen omdat deze een conflict gaf. Daarna de update in 15 minuten afgerond.

[Reactie gewijzigd door Eonfge op 31 juli 2024 20:47]

Kan me ook herinneren dat daar wat politiek en praktische zaken aan ten grondslag lagen... SUSE ondersteunde toen juist al wel BTRFS in SLES en SLED. RedHat had met name of XFS ingezet en daarvoor de meeste ontwikkelaars beschikbaar en dan moet je een praktische keuze maken. Wanneer SUSE een technology kiest zullen ze daar niet zo snel vanaf stappen, zo hebben ze ook heel lang ReiserFS als default filesysteem gebruikt.

"SUSE has decided to let the world know it has no plans to step away from the btrfs filesystem, and plans to make it even better."
https://www.theregister.com/2017/08/25/suse_btrfs_defence/

"RedHat supporting something means they have to commit to having it work, but currently they don't have any BTRFS experts, their filesystem group is all XFS people. So they can't give BTRFS support without expending additional effort."
https://www.reddit.com/r/...t_on_the_future_of_btrfs/
Ik snap de overstap van ext4 naar xfs niet echt: xfs levert soms lege bestanden op naar een server crash, iets wat bij ext4 nauwelijks voorkomt.

Wel goed dat RH eindelijk btrfs gaat ondersteunen. Een filesystem met snapshot support kan echt een levensredder zijn als er een fatale rpm update is geweest en je makkelijk de vorige snapshot van je root volume kan gebruiken.
Je stapt dan ook niet over van ext4 naar XFS, maar gebruikt al XFS uit het verleden.
XFS stamt uit de tijd toen ext3 en ReiserFS net om de hoek kwamen kijken of nog niet bestonden. Het is ontwikkeld door SGI op Irix en gaat ervanuit dat je hardware betrouwbaar is. Waar ext2/3/4 na een aantal disk errors overgaan op read-only modus, zegt XFS gewoon "onbetrouwbare hardware, filesystem shutdown, dikke doei".
Ext4 is inmiddels volwassen als je de juiste opties instelt, heb je geen XFS meer voor nodig.

Btrfs is nog volop in ontwikkeling. Inmiddels is het meeste al behoorlijk volwassen, maar er gaat nog wel eens wat mis.
zonder de risico's van Arch of de mismanagement van Manjaro.
Ik gebruik Manjaro anders al jaren probleemloos.
Wat is er dan met mismanagement bij manjaro?
Korte samenvatting: https://github.com/vizs/manjarno

Maar meest duidelijke is nog wel dat ze tot tweemaal hun SSL certs lieten verlopen.

[Reactie gewijzigd door Cilph op 31 juli 2024 20:47]

"Fedora is niet voor standaard consumenten"
Ik neem aan dat je het niet zo zwart-wit bedoeld, maar als gebruiker van e-mail, webbrowser en af en toe een gamepje (standaard genoeg?), is mijn distro-hopping tijd een aantal jaar geleden gestopt toen ik fedora 27 uitprobeerde.
Natuurlijk probeer ik nog weleens wat anders uit, maar altijd op een aparte partitie.
Misschien was het iets te kort door de bocht, maar doorgaans zie je consumenten eerder voor Ubuntu, Linux Mint of Pop OS gaan.

Fedora werkt uiteindelijk overal, maar er zijn bepaalde punten waarop zij zicht richten. Fedora heeft bijvoorbeeld geen non-free software. Voor vele is NVidia ondersteuning uiteindelijk belangrijker dan FLOSS purisme, en bij Fedora heb je dan RPM-Fusion nodig. Voor mij prima, voor vele een brug te ver.

Als ik mensen kan helpen met installeren, dan help ik ze graag op weg met Fedora, maar als ik iemand een USB Stick moet meegeven, dan vertrouw ik het meeste op Pop OS.
Dat is zeker waar. Ik raad beginners altijd Ubuntu aan, omdat ze al genoeg tegenstrijdige dingen horen, en hulp is makkelijk te vinden. Zelf vind ik het niet fijn werken. Een aantal vrienden van mij zijn nu al een paar jaar tevreden gebruikers van Ubuntu.
Het was al stabiel genoeg; SUSE had BTRFS toen reeds in hun SLES en SLED distributies. Gebruikt zelf voor m'n desktop als jaren openSUSE Tumbleweed met BTRFS en heeft me tot nu toe nog niet in de steek gelaten. Ook in een aantal SLES en openSUSE LEAP (is binary compatible met SLES release) installaties gebruikt ik het en ook daarin nog geen problemen ondervonden. Nu zal ieder filesysteem op z'n tijd wel eens problemen ondervinden door een bug. Hoewel ik voor essentiële data partities vaak EXT4 gebruikt in servers zie je ook vaak zoals Red Hat dat ook doet dat XFS in bepaalde scenario's aanbevolen worden en juist met XFS heb ik statistisch de meeste problemen ondervonden (onherstelbare filesysteem na server crash). Gek genoeg is het enige filesysteem dat me nog nooit in de steek heeft gelaten na een harde crash "Novell NSS", dat nog steeds gebruikt kan worden als onderdeel van Micro Focus Open Enterprise Server icm een SLES server.
Volgens mij gebruiken Synology/Qnap NAS systemen tegenwoordig ook BTRFS.
Ben ik gelukkig dus niet de enige die meerdere fs crashes uitsluitend met XFS heeft gehad. Ik dacht dat het aan mij lag omdat iedereen altijd de robuustheid van XFS prijst. Draai nu al jaren met btrfs en ext4 en met beide nooit problemen....
Ik heb dezelfde ervaringen met xfs. Met ext4 eigenlijk nooit lege files gezien na een crash.
Was het bij mij maar bij een paar lege files gebleven (na een unsafe shutdown), maar in plaats daarvan had ik compleet corrupte filesystemen waar niks meer af te krijgen was....
Dat heb ik ook wel meegemaakt, maar dat heeft ook wel met de geschiedenis van XFS op SGI MIPS/IRIX machines te maken, waar er altijd redundante stroomvoorziening was en er geen sprake was van unsafe shutdowns. Jaren geleden heb ik problemen die ik met XFS ondervond, gemeld bij de ontwikkelaars die inmiddels bij Red Hat in dienst waren en meegeholpen bij het testen.

Het grappige was dat er corruptiebugs waren onder Linux/MIPS, maar die waren op een gegeven moment verholpen. Helaas heb ik op dit moment geen MIPS machines meer om mee te testen, tenzij ik iets uit China kan importeren met een moderne Loongson chip. Nu heb ik eigenlijk nergens echt last van, maar ik draai op het moment geen server met XFS.

Als ik een extra ARM machine heb, zal ik daarop specifiek als test een distributie volledig op XFS draaien. Op mijn Powermac G5 heb ik er ook geen problemen mee, maar die staat niet zo vaak aan vanwege de problematische ondersteuning in moderne (big-endian) PPC64 distributies zoals Debian en OpenSUSE.
De hele backend van Facebook (en ik hoorde/las ergens laatst ook Google?) draait op btrfs, dus ik denk wel dat het stabiel is idd ;) Met elke nieuwe kernel release wordt btrfs ook nog steeds beter en beter. Het enige wat je nog niet moet doen is Raid 5 / 6 gaan gebruiken met btrfs. Ik ben er zelf al een tijdje mee aan het spelen en ik hoop echt dat btrfs de nieuwe standaard gaat worden in Linux. Ik was ook aangenaam verrast toen ik voor het eerst hoorde dat een grote speler als Fedora nu ook default btrfs gaat gebruiken, dat gaat een flinke boost geven. De voordelen zijn enorm, snapshots van disks maak je in een (paar) seconde(n) en compressie is ook een mooie toevoeging. Het is alleen niet een install & forget filesystem, COW wil je bv niet aan hebben staan op folders met databases en subvolumes moet je ook even plannen.
# MySQL en PostgreSQL haar bestanden staan hier
chattr -R +C /var

# Veel softwares hun SQLite bestanden staan hier
chattr -R +C /home/*/.cache
chattr -R +C /home/*/.local
Bij RedHat gebruikten ze nog XFS, maar die mist features als CoW. Nooit begrepen waarom ze niet aan de gang zijn gegaan met btrfs. He zit het met RAID5 write hole is dat nog steeds een issue.
Ik hoor nu voor het eerst van btrfs, maar ik kan er nu al om lachen.
Btrfs, an abbreviation for b-tree file system, (pronounced as "butter fuss",[11] "better F S",[8] "butter F S",[12] "b-tree F S",[12] or simply by spelling it out)
Voor servers en een NAS een van de betere bestandsystemen. Jammer alleen dat raid 5 nog niet helemaal stabiel is anders had ik het ook gebruikt voor me fileserver thuis. Momenteel draait deze op zfs maar zou gezien de prestaties graag overstappen naar btrfs. Dit kan echter alleen in combi met mdadm raid en btrfs daarbovenop zoals Synology dat ook doet. Daarnaast is het al een lange tijd beschikbaar dus dat je er niet van hebt gehoord zegt meer over jou dan over btrfs.
Ik ben op het moment bezig met een zelfbouw NAS met 8x 10tb en twijfel nog steeds tussen btrfs en zfs. btrfs is zoveel flexibeler maar raid6+1c4 begint pas vanaf kernel 5.5 pas ergens op te lijken (mits je space_cache=v2 zet anders raakt je data corrupt). En dan nog zijn er veel risico's aan verbonden.

Maar als mijn keus toch voor mirror ipv parity gaat dan is btrfs een duidelijke winnaar door de flexibiliteit t.o.v. zfs. Disk toevoegen of verwijderen, maakt niet eens uit welke grootte. Het kan allemaal zonder problemen.

Er is iedere maand weer vooruitgang en in kernel 5.10 komen er wat hele mooie performance patches aan, maar helaas is al sinds ongeveer het begin van btrfs een grote rode waarschuwing op de wiki/raid56 pagina.

Berichten van de developers als deze schrikken me nogal af:
https://lore.kernel.org/l...5.GD10769@hungrycats.org/
https://lore.kernel.org/l...4.GX10769@hungrycats.org/

Punt dat ik probeer te maken is dat het al heel héél lang een work in progress is maar er echt nog hele grote stappen gemaakt moeten worden voor parity data opslag.

[Reactie gewijzigd door DaanHetEendje op 31 juli 2024 20:47]

"butterface" denk ik aan... She's got a great personality, but her face...
Maar waar is BTRFS nu werkelijk voor aanbevolen?
Hmm ik dacht dat puur obv prestaties (random R/W) voor een SSD waar het OS op staat, EXT4 simpelweg veel sneller is. BTRFS kies je dan om de snapshots mogelijkheid en extras ter voorkoming van corruptie, maar juist dat laatste is toch bij een OS schijf minder van belang? Dat is voor je dataschijven handig.
En snapshots kan je imiteren door TimeShift te gebruiken (die kan rsync als alternatief gebruiken voor snapshots).
Checksumming tegen datacorruptie zal inderdaad vooral belangrijk zijn voor dataschijven, snapshots zijn echter bij uitstek geschikt voor je root partitie. Een COW snapshot is geen backup, gaat het origineel verloren dan is je snapshot ook niks meer waard. Maar als jij een kritische upgrade uitvoert op je systeem, of je wilt gewoon even KDE uitproberen, dan zijn snapshots zeker handig. Als iets niet goed gaat of het bevalt je niet, dan doe je gewoon een rollback.

Ik gebruik Fedora en ben zelf blij met LVM. Het enige wat me erg stoort is dat Fedora nog steeds geen /boot op LVM accepteert, ook al ondersteunt grub2 dat prima.

[Reactie gewijzigd door woopdiedoo op 31 juli 2024 20:47]

Idee is dat je voor een systeemupdate en snapshot maakt, als het systeem dan herstart en merkt dat de update niet goed gegaan is en het systeem niet meer omkomt de snapshot automatisch wordt terug gerold; dit is nog experimenteel maar onder andere de OpenSUSE Tumbleweed experimenteert hiermee. Ze willen eigenlijk helemaal af van een major release per x periode omdat ook zo'n systeem nadelen heeft. Wanneer je continue integratie hebt met goede geautomatiseerde test functionaliteiten kunt je een systeem continu updaten en waarborg je de beschikbaarheid van het systeem met de snapshot functies. Een praktijkvoorbeeld zijn IOT apparaten, welke veelal niet worden geupdate en dus vaak een een veiligheidsrisico vormen. Voor een mechanisme te introduceren wat ervoor zorgt dat systemen op een veilige manier updates kunnen afhandelen kunnen IOT apparaten dus bij blijven met patches met minimale inspanning van de leverancier.
Thin provisioned LVM kan ook goed snapshotten. Met wyng-backup heb je zelfs het equivalent van send/receiver van ZFS, is alleen een hobby project op het moment.
Phoronix heeft het een tijd geleden getest.
Ja ik had dat al eens gelezen maar kon er geen conclusie uit trekken behalve dat XFS en F2FS de visuals flink vertroebelen als je EXT4 met BTRFS wil vergelijken (de schaal is groter doordat F2FS vaak veel sneller is, waardoor de verschillen tussen eerder genoemde kleiner zijn).

Beetje rare vergelijking want F2FS is volgens mij niet voor SSDs bedoeld maar voor SD/MMC achtige opslag kaartjes.
Dus Red Hat gaat voor Btrfs en Canonical (Ubuntu) voor ZFS.

Ik gebruik al een tijdje ZoL (ZFS) en naast compressie ondersteunt het sinds 0.8 ook native encryption. Als je er eenmaal bekend mee bent werkt het erg fijn. Ik heb nooit Btrfs geprobeerd omdat ik al gewend ben aan hoe ZFS werkt, en het al heel lang stabiel is terwijl Btrfs twee jaar geleden nog als experimenteel werd beschouwd.

Een partij als Red Had doet zo'n uitspraak echter niet luchthartig, dus zal Btrfs vanaf nu naast ZFS ook een serieuze optie zijn.

Meest gehoorde nadeel van ZFS is dat de licentie (CDDL) niet GPL compatibel genoeg zou zijn in tegenstelling tot Btrfs (GPL) en dat dit tot problemen kan leiden.

Canonical (Ubuntu) zegt daarover:
We at Canonical have conducted a legal review, including discussion with the industry’s leading software freedom legal counsel, of the licenses that apply to the Linux kernel and to ZFS.

And in doing so, we have concluded that we are acting within the rights granted and in compliance with their terms of both of those licenses. Others have independently achieved the same conclusion. Differing opinions exist, but please bear in mind that these are opinions.
edit:
Overigens gebruik ik ZFS vooral als datastorage/RAIDZ/volumemanager op harde schijven. Mijn bescheiden home op een SSD gebruikt gewoon ext4.

[Reactie gewijzigd door Sando op 31 juli 2024 20:47]

Oracle maakt rare sprongen. Bij Redhat valt veel meer te halen, die kunnen minder makkelijk zo'n risico nemen.
Je moet ook geen ZFS van Oracle gebruiken, gewoon OpenZFS. Dat is wat FreeBSD, Ubuntu, TrueNAS, XigmaNAS etc. gebruiken. Dan heb je niets met Oracle te maken aangezien die vroeg codebase geforkt is.

Net zoals je MariaDB gebruikt in plaats van Oracles MySQL of AdoptOpenJDK in plaats Oracles Java Development Kit.

[Reactie gewijzigd door Maurits van Baerle op 31 juli 2024 20:47]

Lood om oud ijzer. Heeft nog steeds het licentie/distributie probleem.

Datzelfde probleem bestaat met binaire modules, maar die creëren veel minder risico. Als de shim constructie van NVIDIA niet legaal is kan NVIDIA geen rechtszaak aanspannen. Met ZFS kan Oracle dat wel.
Het probleem van ZFS en Linux is dat ZFS de CDDL gebruikt. Dat is een gewoon een erkende open source license alleen eentje die niet compatibele is met de GPL die de Linux kernel gebruikt.

Het probleem met OpenZFS en Linux is dus niet Oracle maar de combinatie CDDL en GPL.

Het heeft gebruik buiten de Linux kernel nooit in de weg gestaan anders hadden Apple, Canonical, FreeBSD, iXsystems, Nexanta, Delphix, Qnap, XigmnaNAS en nog een reeks andere grote storage bedrijven nooit ZFS kunnen gebruiken.

[Reactie gewijzigd door Maurits van Baerle op 31 juli 2024 20:47]

BSD en OpenSolaris gebaseerde systemen zijn niet zo relevant.

De vraag is in hoeverre een binaire module buiten het Linux kernel valt, zeker als ze samen gedistribueerd worden. Sommigen willen dan shims en compileren bij installatie toevoegen voor extra zekerheid, maar een rechter zal onwaarschijnlijk onder de indruk zijn van dat soort trucjes.

Linus heeft ook zo zijn twijfels over de intelligentie van ZFS gebruik met Linux ...
Maar waarom denk je dat er ooit een rechter aan te pas zou komen. Op welke gronden en in welke situatie?

Is er een juridische reden om het gebruik van OpenZFS, MariaDB en AdoptOpenJDK af te raden? En waarom zou Oracle, berucht om hun gang naar de rechter voor van alles en nog wat, daar nooit gebruik van hebben gemaakt?

Ik zie de Linux Foundation ook niet zomaar naar de rechter stappen. Iedereen mag zelf bepalen welke code ze boven op de Linux kernel draaien. Het enige wat niet mag is als niet-GPL project bepaalde kernel symbols gebruiken. Maar goed, daar steekt de kernel al technisch een stokje voor, daar hoeft Linus niet voor naar de rechter te stappen.

Komt OpenZFS ooit in de Linux kernel terecht? Ik verwacht van niet, daar blijven de kernel maintainers waarschijnlijk een stokje voor steken. Komen er steeds meer partijen die OpenZFS als code of gecompileerd meeleveren met hun op Linux gebaseerd product? Ik denk het wel.

[Reactie gewijzigd door Maurits van Baerle op 31 juli 2024 20:47]

Rechtzaken kosten geld en bij Redhat is veel meer te halen dan Ubuntu, waard om op te wachten.

User space applicaties vallen niet te vergelijken met kernel modules.

Het probleem is niet de Linux foundation, het probleem is als Oracle zegt dat de CDDL is overtreden (bijv. door GPL only patent licenties in de Linux kernel) en Oracle achter je aankomt.
Redhat gaat voor Stratis. Fedora gaat voor BTRFS.
Heb hem al draaien (upgrade vanaf Fedora 32) :) Hij is saai op een goede manier. Beetje extra polish maar weinig grote user-facing veranderingen. Niet heel spannend, maar wel zo'n beetje wat je eigenlijk wilt natuurlijk.

[Reactie gewijzigd door RobinJ1995 op 31 juli 2024 20:47]

Yep. Ik ook. Ik upgrade al tijden. Nog geen neiging om een schone install te doen. Ik draai overigens de KDE spin. Ik zag wat kleine verfijningen idd. Ik moet nu nog drie systemen updaten. Mijn laptop en de systemen van mijn ouders.
Shared space tussen partities en COW _/-\o_
Iemand een idee hoe Fedora 33 samengaat met Docker tegenwoordig?
Podman moet je gebruiken, Docker heeft geen ondersteuning voor CGroupsV2, right?
ah ik dacht dat dat opgelost was in fedora 32 maar blijkt dat ze alleen de repo hebben gefixt. In lees dat ze dit misschien in Docker 20 oplossen.
Zo krijgt Fedora 33 ook ondersteuning voor geanimeerde bureaubladachtergronden.
Wat bedoelen jullie hier mee? Fedora/GNOME kan dit al tenminste sinds Fedora 7.
Heb de Silverblue[1] variant getest op een 12 jaar oude laptop[2]. Het is zo veel sneller dan de vorige standaard Fedora dat je bijna denkt dat je een nieuwe mid-range laptop gekocht hebt... totdat je Netflix gaat kijken of gaat gamen.

1 - Immutable filesystem (ostree) die in de toekomst de default Fedora versie gaat worden;
2 - Intel CPU, 3GB RAM, een discrete AMD GPU en een 120GB SATA-SSD.

Op dit item kan niet meer gereageerd worden.