This might be another good reason to delay the net installer. Changes are set for 2019-12-27
Thanks for the heads up on this.
Here is the line that bothers me.
“I encourage every Arch Linux project maintainer to check their own code for hardcoded xz extensions, you probably know your code best.”
New Year, new iso?
Here is a link with more information on Zstd
Am I bad because I can think about reading that is Pied Piper?
It is about speed… A main interest at the moment for arch Developers… As far as I understand.
We do not have much packages and I do not know exactly what for hardcoded xz extensions are used… Do we use it I do not think so
It will may effect package maintainers at archrepo and AUR
As far as I know, the old extension .xz will be supported too. So zstd will be just the default compression.
That’s why I’m not expecting issues for our packages from this change.
Let’s just hope all Arch tools will be compatible with each other.
But sooner or later we will see how it goes.
The major problems will be on running systems, like yesterday’s update, the Net-intaller installs a fresh system according to the new Arch standards.
The system EndeavourOS is offering isn’t relying heavily on modified packages, like other Arch-based distro’s.
In my opinion, being close to Arch is a blessing in this case, the offline installer might encounter problems after install.
Packages will migrate one after the other. It won’t break a lot of things. Well, let’s hope so.
Anyway, my current Archlinux installation (from february 2018) survived all kernel update since 4.15.x, a new Mate version, and many more things… Not sure other distributions would have handled this without being reinstalled
I see that the zstd package is already installed on EndeavourOS currently.
I had heard that Arch devs were considering changing the kernel’s compression to zstd, but didn’t know it was going to be such a widespread change. It worked fine when I tested it with Dracut last month, so here’s to hoping for a smooth transition.
I think the installed systems will have to deal with another manual intervention but besides from that, I expect it will be done relatively smooth.
Read the link in this article, it’s very informative:
yea I do read your article already and much more around it… but I do still not know why arch was choosing zstd as there are other faster lossless opensource compression algorithms out there?
They do follow what other distros will use, good for cooperation and on the view of a universal implementation …
The other alternatives, from what I got from other articles are faster, but less reliable. It seems Zstd is the fastest and stable among those.
Again, I also had a hard time getting the right info on this because every article I read about it was pretty coloured.
From the Arch-Dev mailing list: Zstd rollout complete