This I understand.
What I meant to ask is if anyone noticed the upgrade-process being slower, not the system performance after upgrading

I have a local mirror of slackware-12.2 & slackware-current, so upgrading the machines in the network is usually quite fast (no downloading of packages over slow lines while upgrading, just once a night rsync-ing the mirror).
I was wondering if changing to xz (de-)compression slowed things down in a way we can actually notice.

I got your idea But I use slackpkg to do upgrading system.(I do keep a rsync in local but not upgrade from it) AFAI can tell is most of the time is cost on network transfer and the upgrading process have no difference psychological.

Lasse, I have a deep sense of vindication in having advocated lzma from years ago.
And now that xz is reality in Slackware, there can be no question that I was right to do so.
Thank you for this sense of "I told you so", to everyone who argued against me for these past few years.

Starting back a few years ago, I started using pkgtools-tukaani (and tukbuild) for building my packages with lzma compression. Then with the help of src2pkg, I also started using lzma to compress my man pages. Now I will be switching once more. This time to xz. And in the same vein of logic, I have also been compressing the binary files in each package with upx-ucl. Again, it saves a lot of space and has virtually no effect on performance. upx is the same compressor that NASA used to transfer data between Earth and the Mars Explorer. So if they had sense enough to use it, I figured I should too. Maybe sometime in the future, Pat may actually start compressing man pages also. That's a bigger possibility than him compressing binaries with upx-ucl. So I'll just sit back and enjoy the fact that I'm receiving benefits that few if any others see as relevant.

Again, Thank you Lasse!
Shingoshi

I think it's important to consider the speed of decompression, RAM usage, as well as compression ratio. So, don't think there is an ultimate right answer to this. I usually prefer gz over other compression algorithms because it's very fast at compression / decompression, uses little RAM, and has decent compression ratio. From what I've seen lzma is slower to decompress and requires more RAM. It's always a trade off ... always.

The next step is to get xz parallelized like pigz (http://www.zlib.net/pigz/). This one is new to me.
Edit: I just created the pigz package in a few seconds using src2pkg.
There's also pbzip2 (http://compression.ca/pbzip2/) as well. This one I've used myself.

Shingoshi

I wonder if the entire system was rebuilt. Noticed some cleaned up SlackBuilds, and a couple of gcc 4.3 fixes. I submitted some info on flac, considering it doesn't build on current, and was getting ready to submit a handful of others. The ones I had, have already been added.

[Edit] Deleted my previous statement as it was wrong.
Just tried decompressing a mesa.tgz file. The file is around 85MB. It took about 5 seconds using both gz and xz the first time and 4 seconds for gz and 6 seconds for xz the second time to produce the .tar. I did not get fractions of a second so they're probably not too far apart.

If many people are using the rsync this could tie up the servers for a bit. It might be useful to offer a script to batch convert (some of) the existing tgz files on the end users machine. I don't understand enough about the scripting language to try this.

[Edit] Deleted erroneous statement about mesa, drm, etc., versions. I was comparing a slackware version to a git version and thought the slackware version was newer but upon review it's not.

Decompressing and installing a .txz package does not take 1.5x as long as a .tgz package. The decompression will be a bit slower but it will add much, much less than 50% extra time. Note that package decompression is only part of the package installation time.
Also I've verified that the -current installer still works on hardware that is equipped with just 64 MB of RAM.

There are no such updates to slackware-current, I do not know where you got that idea?

Eric

maybe the text in the tar-1.22-i486-2 package should be changed now:

I no longer use rsync. So I'm not familiar with the issues that are being raised about it. I used to use rsync when I did Gentoo distfiles updates some time ago. But, I was also using deltas (emerge-delta-webrsync) of the sources so that I was only downloading the differences between the older (existing) sources, and the newer sources. All that I remember was how fast and how much time was saved for each download. So my question is how could this be used for Slackware, now that some (think they) are experiencing lower performance as a result of the new .txz package format.

Shingoshi

You are right, wishful thinking on my part. These are probably too unstable still to consider even for -current.

rsync is not used by the actual upgrade process.

I use SlackPkg to maintain the boxes up-to-date (both stable & -current machines).
To avoid all systems downloading the same packages, I maintain a mirror of Slackware-12.2 & Slackware-current on a local ftp server. It is synchronized every night with rsync, when internet traffic is low.

Is there a way to make Ark from KDE 3.5.10 recognize the new txz compression format?

I installed the new a/xz package from current. I added the x-txz file association, modified the ark.desktop file and Konqueror now lists the *.txz files as XZ Archive. Double-clicking opens Ark, but I don't know of a way to add xz files to the drop-down list.

If there is no way to do this then that would be unfortunate.

This is untested completely (not even compile tested), and I probably missed some needed bits, but it should get you on the right track: see the attachment for a diff to kdeutils-3.5.10.

Attached Files

kdeutils-3.5.10-support_xz_and_lmza_stuff.diff.txt (4.4 KB, 45 views)

I see, well that's good to hear.