Mozilla biedt Firefox op Linux aan als .tar.xz-package vanwege betere compressie

Mozilla gaat Firefox op Linux voortaan aanbieden als .xz-package. De tarballs worden vanaf de eerste Nightly-versie met die compressie ingepakt, in plaats van het huidige .bz2. Dat is volgens Mozilla sneller en beter compatibel met meer distro's.

Mozilla schrijft in een blogpost dat het die nieuwe compressie vanaf de recentste Nightly-release aanbiedt. Versie 135.0a1 staat inmiddels op de downloadpagina. Die is te downloaden in .tar.xz-formaat. De browser heeft dan een grootte van 75,3MB. De verandering geldt alleen voor nieuwe gebruikers die de browser opnieuw installeren en niet voor bestaande.

De browsermaker verandert daarmee de compressie van .tar.bz2. Mozilla zegt dat installatiepackages met .xz zo'n 25 procent kleiner worden dan .bz2-packages en dat gebruikers de browser daarmee sneller kunnen downloaden. Ook het installeren zou daarmee sneller zijn omdat .xz snellere decompressie heeft. Mozilla zegt verder dat meer moderne Linux-distro's .xz ondersteunen en dat het formaat daarmee beter compatibel is.

De .tar.xz-package maakt gebruik van het lzma-compressiealgoritme. Daarmee maakt Mozilla een ietwat opvallende keus, omdat veel gebruikers in een discussieticket ervoor pleitten om Zstandard te gebruiken als compressiepackage. Die .zst-packages zouden namelijk nog snellere decompressie hebben dan .xz. Mozilla zegt echter dat de betere compressie van .xz belangrijker is, naast de betere compatibiliteit.

Xz kwam eerder dit jaar nog in het nieuws toen bleek dat een van de twee hoofdontwikkelaars van xz-utils een achterdeur in de veelgebruikte software had ingebouwd. Tweakers schreef daar destijds een achtergrondverhaal over.

Reacties (54)

[Blokker_1999]

Het zal Mozilla niet alleen om de snellere downloads en installatie gaan, maar met kleinere paketten vereist dat van hun en hun mirrors ook minder bandbreedte. Want maakt het echt zoveel uit dat de download 5 seconden langer duurt en de installatie 10 seconden meer nodig heeft? Zo gehaast is niemand uiteindelijk.

[Kees]

Wat mij meer verbaast is hoeveel mensen blijkbaar nog de tarball gebruiken in plaats van het package management systeem van hun OS.

Het is veel gemakkelijker om 'apt/dnf/apk install firefox' te doen en dan blijft hij ook nog up-to-date uit zichzelf. Dus tenzij die tar.xz door firefox zelf gebruikt word om zichzelf te updaten zou ik niet verwachten dat er heel erg veel verkeer naar hun package gaat.

[dmantione]

Eén van de toepassingen is als je een specifieke versie nodig hebt in je eigen directory. Ik had laatst bijvoorbeeld de noodzaak voor een browser die Netscape-plugins ondersteunde, ik ga dan natuurlijk niet aan de geïnstalleerde browser knoeien, maar downloadde de laatste Firefox die nsplugin-ondersteuning had even onder een directory in mijn homedirectory. Dat vanuit de tarball.

[pietervdstar]

Op ubuntu is dat nu snap install, en niet iedereen is even blij met snap. Uiteraard kan je dan naar een andere linuxversie, maar dat is een andere discussie. Ik kannbegrijoen waarom iemand dit installeerd buiten een package manager om.

[Kees]

Onder ubuntu kun je het ook naar apt forceren. En zelfs dan zou ik eerder https://packages.mozilla.org/apt gebruiken dan het handmatig downloaden en instaleren.

Een geldige reden zou kunnen zijn dat je hem op een usb stick wil zetten zodat je firefox altijd bij je hebt, maar dat zou ik teveel moeite vinden, elke pc heeft wel een browser en ze werken allemaal.

[Crim]

Bij mij werd Firefox uit de apt repo na een tijdje weer automatisch vervangen door de snap.

[pietervdstar]

Is inderdaad de betere optie

[cricque]

Of gewoon mint gebruiken ? Dat zou normaliter allemaal via apt moeten gaan en geen snaps standaard

[Terr-E]

Een geldige reden zou kunnen zijn dat je hem op een usb stick wil zetten zodat je firefox altijd bij je hebt,

Zou je dan niet beter .AppImage kunnen gebruiken?
(Ja ik weet dat het niet officieel door Mozilla ondersteund is)

[ArmEagle]

Ik ben heel erg blij met mijn Firefox in home die zichzelf kan updaten.

En ik heb een grote hekel aan Chromium die via Snap is geïnstalleerd, wat een eigen update (venster) vereist, buiten Apt om.

Een browser heeft bijna dagelijks updates. Doe dat vooral lekker volautomatisch bij het opstarten.

Ja, voor Apt zou dat met unattended upgrades kunnen. Maar dat is nog steeds pull in plaats van push.

[UPPERKEES]

Of gewoon een Flatpak

[Killemov]

Nee! Doe dan maar Firefox in Docker ...

[UPPERKEES]

Dat kan ook, met Toolbx of Distrobox. Maar Flatpak is toch wel wat beter Je klaagt toch ook niet over je apk op Android?

[Grimm]

Het is veel gemakkelijker om 'apt/dnf/apk install firefox' te doen

Het is veel gemakkelijker om 'zypper/apt/dnf/apk install firefox' te doen

[Killemov]

Hey, nog een SuSe gebuiker! Leap of Tumbleweed?

[Grimm]

Uitsluitend Leap, sinds jaren, zowel op het werk als thuis.

[Jehare]

Precies! Tumbleweed hier, zat ook Leap maar dat werd me soms toch te outdated (zeker met pakketten als steam, discord, spotify, liep soms wel 10 versies achter), maar Tumbleweed is top.

[SillieWous]

Voor de packages die Mozilla zelf onderhoudt klopt dat wellicht. Maar wanneer een distro de pacakges zelf bouwt zullen ze de source moeten downloaden. Dan zijn tarballs toch wel echt enorm handig.

[Omega]

Zeer weinig mensen gebruiken de Firefox tarball, deze is voornamelijk bedoeld voor distro maintainers die deze tarball gebruiken om Firefox te packagen voor hun distro. Sommige distros compileren Firefox zelf met eventuele patches en tegen een specifieke omgeving, veel kleinere distros die hebben hier niet altijd de tijd of middelen voor.

[CAPSLOCK2000]

Wat mij meer verbaast is hoeveel mensen blijkbaar nog de tarball gebruiken in plaats van het package management systeem van hun OS.

Dat verbaast mij ook, ik vraag me af of dit nieuwtje niet een beetje uit proportie is getrokken. Wisselen van compressiemethode of is iets dat al duizenden applicaties hebben gedaan zonder er een nieuwsbericht over te schrijven. Ik kan me niet voorstellen dat er echt veel mensen zijn die de tarbal zelf downloaden.
De groep die dat wel doet zijn volgens mij vooral geavanceerde gebruikers en dat zijn er gewoon niet veel. Het voelt een beetje als bike-shedding waarbij een of ander relatief onbelangrijk detail veel te veel aandacht heeft gekregen van mensen met stevige meningen.


Heel misschien heeft het nog iets te maken met geautomatiseerde build-systemen. Misschien dat er hordes aan systemen ieder dag opnieuw Firefox downloaden, het drie seconde gebruiken als deel van een of andere test en het dan weer weggooien en opnieuw gebruiken.

[Marve79]

Is dat echt een probleem? Bandbreedte zat toch tegenwoordig. En zeker met die CDN's wordt alles in de buurt gecached.

[Blokker_1999]

Het kost allemaal geld

[Jerie]

Klopt, Hetzner in VS schroeft aabtal TB flink terug bij hun pakketen van 20 TB / maand naar bijvoorbeeld 2 TB. Dit i.v.m. eerlijkere prijzen kleinverbruik versus grootgebruik. Echter de prijzen gaan ook omhoog, dus marketing BS.

[Marve79]

Ja maar het is ook nog enkel de Firefox voor Linux. Hoeveel gaat dat nou werkelijk schelen? Het is niet dat dat nou zo heel veel wordt gebruikt.

[Christoxz]

Een developer zegt bijvoorbeeld ook dat het sneller compressed, wat weer tijd bespaart in de CI pipeline, dat betaal je vaak, dan niet altijd, per seconden.

We care about the size of what we ship to users because it impacts how much external bandwidth we use.
We care how long our CI pipeline takes, and the longest compressing the archive/installer takes, the worst it is for us. That is even compounded by the fact that we do that twice(!), and I think we should change that.

Gaat het een wereld van verschil maken? Nee.
Kan het kwaad om ergens te beginnen aan een verbetering? Nee, ook niet.

Je kunt er meer over lezen hier: https://bugzilla.mozilla.org/show_bug.cgi?id=1710599

[freaq]

Nou het staat op practisch elke server.
Dus dat is toch best wel wat.

[Marve79]

Hoezo meeste servers hebben toch geen UI? Bij ons geen enkele en we hebben honderden Linux servers. Daar staat echt geen Firefox op.

Bovendien maken de meeste servers gebruik van de Yum en apt repositories dus dat hoeft Mozilla niet te betalen.

[Reactie gewijzigd door Marve79 op 29 november 2024 08:54]

[Mijzelf]

Firefox op een Linux server? Het zal wel voorkomen, maar ik denk dat de meeste Linux servers geen GUI hebben, en dus ook geen Firefox.

[zordaz]

Inderdaad.
...plus dat de meeste Linux gebruikers het niet eens op deze manier installeren, maar gewoon via de package manager van hun distributie of wellicht tegenwoordig als Flatpak of Snap.

[Marve79]

Ja precies dus echt gerommel in de marge dit. Een developer die zich verveelt en die meer fan was van xz.

[ultimasnake]

Dat is ook de enige reden die ik me kan bedenken. Dir paar MB meer maakt haast nergens ter wereld meer indruk en sneller installeren is relatief. Het is ook niet alsof je binnen x-seconden je browser geïnstalleerd moet hebben ‘of anders’… of dag iemand voor chrome kiest omdat die nu eenmaal installeert in 55 seconden ipv 60…

[eheijnen]

Voor een paar downloads en installs maakt het weinig uit. De gebruiker merkt daar minder van, zeker hier waar de meesten "stevige" verbindingen hebben,

Maar dit is natuurlijk op een andere schaal aan de kant van Mozilla .Kan best zijn dat ze hun downloads en updates bij een hyperscaler hebben ondergebracht en dat (flink) op de rekening scheelt. Het is ook nog eens groener doordat er minder energie wordt verbruikt....

[MazeWing]

Ik vraag me af of dit echt noemenswaardig verschil gaat maken op dusdanig kleine bestanden. Het verschil is nog geen 20 MB en volgens mij zijn de meeste computers dusdanig snel dat dit onmerkbaar op de achtergrond plaatsvindt.

Als Call of Duty, met updates van soms wel 100+ GB, hier gebruik van zou maken dan zou dat natuurlijk een ander verhaal worden...

[SpankmasterC]

Voor de gebruiker maakt het niet zoveel uit, voor Mozilla scheelt het een kwart van hun verstuurde data, en dat is natuurlijk wel significant

[laptopleon]

Nou ja, alleen de verstuurde data naar Linux-gebruikers dan, veruit de minderheid. Dat zijn ook nog vaak instituten waar de gebruikers niet ieder voor zich hun computer zelf installeren, maar waar dat door een systeembeheerder geautomatiseerd is, vanuit de lokale server, dus maar één download voor vaak honderden gebruikers. Daarnaast blijft het kruimelwerk, 35% van 75 MB = 26 MB besparen terwijl we massaal avond aan avond 4K video bingen.

Maar goed, wordt allebei prima ondersteund dus niet heel spannend in de praktijk allemaal.

[kuurtjes]

Dat is 20 MB maal x aantal gebruikers.

[kozue]

Doet er uiteindelijk niet zoveel toe. Vrijwel niemand op Linux download Firefox van de mirror. Daar hebben we distro pakketten voor (deb, rpm, etc), of zelfs Snap als je van bloat, traagheid en problemen houdt. Maar de laatste keer dat ik Firefox van een officiële mirror heb gedownload kan ik me niet meer herinneren.

[ArmEagle]

Zoals ik hierboven net al schreef op een ander bericht in dezelfde hoek;
Ik vind het erg fijn dat Firefox (in home) gewoon zichzelf kan updaten. Zeker gezien hoe vaak er updates zijn voor browsers en hoe belangrijk ze zijn.

[kozue]

Die updates komen ook in je distro package manager mee hoor. Zelf erger ik me juist altijd aan die updates, want voor iedere x.y.1 flutfix wil Firefox zichzelf gaan herstarten. En aangezien ik vrijwel alles in privévensters doe moet ik dan alles opnieuw opzoeken want die worden niet onthouden 😞

[ArmEagle]

Nee. Snap updates heb ik echt altijd los van de distro (Ubuntu 22.04). Het komt wel in een 'application update' (o.i.d.) venster. Maar altijd los van APT.

Kan je misschien een deel met containers doen, in plaats van prive vensters?

Ik heb liever security fixes zo snel en makkelijk mogelijk.

Extra toevoeging: ik had net updates van beide. Aan het einde van de APT updates zag ik wel een regel over snap updates. Heb ik nog nooit eerder gezien. Maar Chromium staat zelf ook nooit in die lijst van te updaten programma's.

[Reactie gewijzigd door ArmEagle op 2 december 2024 08:57]

[owndampu]

zoiets dacht ik ook, misschien zullen een paar distro's zelf deze tarball downloaden en dan repackagen in hun format, ipv het zelf compileren vanaf source met bepaalde flags of optimalizaties. Maar dat is volgens mij erg beperkt.

[elmuerte]

Daarmee maakt Mozilla een ietwat opvallende keus, omdat veel gebruikers in een discussieticket ervoor pleitten om Zstandard te gebruiken als compressiepackage. Die .zst-packages zouden namelijk nog snellere decompressie hebben dan .xz. Mozilla zegt echter dat de betere compressie van .xz belangrijker is, naast de betere compatibiliteit.

Geen opvallende keus. Er is genoeg over gepraat en mee getest. zstd is misschien wel sneller in decompressie, maar de file size is groter, en decompressie heeft meer resources nodig.

[Jerie]

Dit dus.

Je kunt best beargumenteren tussen LZMA en ZSTD. Maar bz2 is objectief minder goed dan beide. Het is dus altijd een verbetering. Afhankelijk van omstandigheden is ZSTD betere keus, maar hoe dan ook het verschil is marginaal. Bz2 vervangen door één van beide is de juiste keus.

[damouze]

De beste compatibility krijg je nog immer uit compressiemethoden als compress, gzip of bzip2.

Voor mij voelt dit echt meer aan als "XZ is de laatste hype, dus dat gebruiken we maar". Persoonlijk zou ik er niet voor kiezen om een container formaat te gebruiken waar je dan vervolgens een container met andere bestanden inkiepert. En al zeker niet als dit containerformaat niet al te lang geleden een grote security breach bleek te bevatten.

Niewer is niet altijd beter.

[Ventieldopje]

Waarom XZ? Ik dacht dat dat project toch wel een pijnlijke dood was gestorven na het hele gedoe met de backdoor (die er al weer uit is).

Kunnen ze niet beter ZSTD gebruiken?

[Room42]

Dat staat ook in het artikel benoemd, in de laatste twee alinea's:

De .tar.xz-package maakt gebruik van het lzma-compressiealgoritme. Daarmee maakt Mozilla een ietwat opvallende keus, omdat veel gebruikers in een discussieticket ervoor pleitten om Zstandard te gebruiken als compressiepackage. Die .zst-packages zouden namelijk nog snellere decompressie hebben dan .xz. Mozilla zegt echter dat de betere compressie van .xz belangrijker is, naast de betere compatibiliteit.

Xz kwam eerder dit jaar nog in het nieuws toen bleek dat een van de twee hoofdontwikkelaars van xz-utils een achterdeur in de veelgebruikte software had ingebouwd.

[Jazco2nd]

Hoe is dit een volwaardig nieuwsartikel waard. Linux is tegenwoordig net zo simpel als iOS als het om updates en apps gaat. Gewoon 1 enkele app die Software heet. Dat is je app store en die regelt ook alle updates. Oersimpel en snel. Windows komt niet in de buurt.

En dan heb ik het natuurlijk niet over Ubuntu of distros waarbij eindgebruikers gehannes met repositories hebben maar over de distros die gebaseerd zijn op Fedora Silverblue zoals Universal Blue OS BASE of BlueFin of Bazzite.

Oma-proof.

[ahbart]

Was XZ niet in naam besmet door een ontwikkelaar die er kwaadaardige code in had gestopt?

[damouze]

Yup.

De ontwikkelaar was iemand die was ingesprongen voor de oorspronkelijke maintainer toen deze een sabattical nam. Helaas bleek dit niet daadwerkelijk een ontwikkelaar te zijn, maar een hele hackersgroep.

[qwertyuiop]

Firefox heeft de nare eigenschap om elke taal apart te distribueren. Zo is dat zeer ongebruikelijk binnen bijvoorbeeld macOS. En als je dan meerdere talen achteraf wilt toevoegen (als beheerder) is dat een uitdaging omdat Firefox daarin niet betrouwbaar is. Ze moeten daar gewoon eens mee stoppen. Gewoon samenvoegen tot 1 app per release.

[beerse]

Voor iedereen die zich afvraagt "Waarom?": Stel dat we dit niet doen. Dan zou je nu nog gewoon een tar-bestand opgehaald hebben. Net zo ongecomprimeerd als een iso-image. Misschien een tar-compress, de eerste compressor om het allemaal kleiner te maken. Misschien ook wel een tar-gnu-zip, gewoon omdat het dan uit de gnu-omgeving komt.

Als je dat dan vergelijkt met de security die met ssh en zo gebruikt wordt. Daar zie je niet welk encryptie systeem gebruikt wordt. Maar ondertussen weten we allemaal dat de versleuteling van eind vorige eeuw nu niet meer als veilig wordt beschouwd. Daar wordt de interne methode wel regelmatig bijgewerkt. Dat gebeurt hier met de compressie standaard dus ook. Maar hier is het zichtbaar. En ja, een beetje extra levert op veel plekken voordeel op, zeker als het niet veel extra kost.

[kozue]

Geen idee waarom je encryptie met compressie vergelijkt. Het één is een veiligheidsmaatregel en de ander een manier om simpelweg je bestandsgrootte te verkleinen. Security moet je bijhouden volgens de laatste standaarden, met compressie maakt dat niks uit (tenzij je iets geeft om het besparen van een paar bytes storage, wat tegenwoordig spotgoedkoop is).

[beerse]

Encryptie en compressie zijn beide methoden om met opgeslagen gegevens om te gaan. Waarom zouden we voor de compressie bij de oer standaard blijven en voor de encryptie wel de nieuwste standaarden opnemen en de oudere achter ons laten?

Het bijwerken van een compressie standaard heeft dan mogelijk niet zo heel veel impact maar impact heeft het wel degelijk. De eerste compressie methoden waren vooral goed in het comprimeren van ascii teksten. Het comprimeren van binaire gegevens is met nieuwere methoden steeds beter geworden. Tel daarbij dat we tegenwoordig veel gegevens comprimeren die al gecomprimeerd zijn. Oude compressie methoden gingen daar gewoon niet goed mee om.

[damouze]

Ik verbaas me hier eerlijk gezegd over. Bzip2 en gzip zijn nog immer de meest gangbare en meest compatible compressiealgoritmen. XZ is uiteindelijk niets anders dan een containerformaat dat toevallig ook compressiemogelijkheden biedt. Het heeft daarnaast ook nog eens niet het beste trackrecord als het gaat om security.

XZ lijkt wat dat betreft meer op tar, dus een directory in een tar.xz inpakken is dus een beetje dubbelop.