Wow, they are going to zip it with a different algo. That’s fucking amazing!
Faster installation, I don’t know what I will do with all that extra time!
Plus, faster downloads, that’s even more free time.
Mozilla really know how to innovate.
Best company evvvvaaarrr
Give 2 millions bonus to that CEO!
Well, now you mention it, the motivation here may be to reduce their bandwidth costs? Probably not 2 million, but every € counts…
It’s a little boring but not bad news. Why the hate?!
The .tar.xz format decompresses more than twice as fast as .tar.bz2, allowing you to get up and running in no time
$ time tar xjf firefox-134.0b3.tar.bz2 real 0m9.045s user 0m8.839s sys 0m0.450s $ time tar xJf firefox-135.0a1.en-US.linux-x86_64.tar.xz real 0m4.903s user 0m4.677s sys 0m0.510sNice! Presumably it’d be twice as fast if disk was infinitely fast or something. Unfortunately by testing this I’ve already used up a hundred times more time than I’ll ever save as a result of it.
I am curious too. You tested two different versions, one beta and the other current nightly (different content). It’s okay for a quick test, but you can actually have a much closer test. Both nightly and only one day difference:
- bz2: https://archive.mozilla.org/pub/firefox/nightly/2024/11/2024-11-26-20-51-18-mozilla-central/firefox-135.0a1.en-US.linux-x86_64.tar.bz2
- xz: https://archive.mozilla.org/pub/firefox/nightly/2024/11/2024-11-27-09-56-17-mozilla-central/firefox-135.0a1.en-US.linux-x86_64.tar.xz
I run this quick test multiple times and on average these are typical results (don’t forget to delete the unpacked folder between each runs):
$ time tar xjf firefox-135.0a1.en-US.linux-x86_64.tar.bz2 real 0m5,784s user 0m5,700s sys 0m0,371s $ time tar xJf firefox-135.0a1.en-US.linux-x86_64.tar.xz real 0m1,699s user 0m1,621s sys 0m0,315sOn my system that consistently gets results around 10s and 5s so the difference is sort of interesting. Mine’s a Ryzen 3600, maybe newer CPU features are of substantial benefit to xz.
Fixing their damn sandbox would be something truly useful.
Implementing a fork server so Flatpak AND Android Firefox can stop being fucking insecure for no reason.
Why do they not just ship normal packages (.deb, .rpm, etc.) or an official flatpak that functions properly?
The Flatpak is official.
But it doesn’t work properly.
How doesn’t it work properly for you?
Doesn’t go full screen on media correctly. Leaves the media the same size and adds massive grey bars to the receiving screen space. Interestingly, the flatpaks of every Firefox-based browser I’ve tried do the same.
Certainty, this is a you problem.
All this under wayland?
Yeah
Has no filesystem sandbox whatsoever. They just pretend it is fine, causing uBlue devs and others to think it is okay to remove native Firefox
I think the “etc” shows how f***ed up it might be to package for every single distro. Releasing a tar with no extra bloat and letting each community doing its own things over it is probably one of the best approaches?
But it makes finding a properly functioning official package more difficult for newer users, and really the etc. was superfluous. You only really need .deb, .rpm, and whatever arch uses. There is a flatpak, but it doesn’t work properly.
I think, you’ve answered your own question? There’s a lot of different formats for Linux. Getting them all correct and working on the different distributions is significantly trickier than just bundling a self-contained archive.
Having said that, they do actually provide a DEB repo since a few months ago: https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions-recommended
They officially publish the snap, the flatpak and a deb in an apt repo.
Interesting, I always assumed they would be using a pretty optimal algorithm with their
.tar.bz2format, because they obviously benefit quite a bit from smaller downloads. Good to know that.tar.xzis actually better.XZ is quite slow for compression when single threaded. When run in parallel it uses a significant amount of RAM. It creates some of the smallest files and is fast to decompress compared to other well-compressed alternatives.
Source: https://linuxreviews.org/Comparison_of_Compression_Algorithms
Thanks. 🙂
Yes, use the format that was almost backdoored a few months ago! I’m sure it has a very strong development team behind it! /s
I would call it the format that has the most eyes on it now.
My point is that it had an overworked maintainer who was easily persuaded into giving the project to someone else. I highly doubt it has gotten a solid team behind it now.
It wasn’t “easy” at all, they had to put in over 2 years of useful contributions before there was chance to insert the malware. If you’re worried just stay on an older version, it should still open new files perfectly fine.
It was easier than taking over zstd for sure
Yes, projects backed by multi-billion dollar companies do tend to be more resistant to that kind of attack.
🤷
What? More compression?
Here I am wondering why in 2024 we don’t have the option to automatically decompress downloaded files like Apple users supposedly can.
Ahh well, I guess that’s why these designers don’t work for apple. They’re not good enough.
Btw how are they the only ones hopping on to XZ?? Like, everyone is switching to zstd currently.
