Earlier quoted context omitted.
Let's chat about Windows 11 right-click menu. I'm pretty sure they hid all the application menu extensions to avoid worst-case performance issues.
Exactly it. 3rd parties injecting their extensions harmed performance, which people turn around and blame Microsoft for.
7-Zip for Windows can now use more than 64 CPU threads for compression
181–190 of 220 posts
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#182Earlier quoted context omitted.
If you're expecting a "mobile first" or similar GUI where most of the screen is dedicated to whitespace, basic features involves 7 or more mouse clicks and for some reason it all gets changed every ~6 months then yes the 7zip GUI is terrible. Desktop software usability peaked sometime in the late 90s, early 2000s. There's a reason why 7zip still looks like ~2004
When compared to it's contemporaries the 7-zip GUI is noticeably worse. Back in 2004 WinRar and WinZip were both clearly superior.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#183Earlier quoted context omitted.
Not that many people care about zstd; I would assume most 7-zip users care about the convenience of the gui.
It's been a long time since I used Windows, but back in the day I used 7-Zip exactly because it could open more or less $anything. That's also why we installed it on many customer computers. On Linux bsdtar/libarchive gives a similar experience: "tar xf file" works on most things.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#184Earlier quoted context omitted.
Not that many people care about zstd; I would assume most 7-zip users care about the convenience of the gui.
.. but 7-zip has a pretty terrible GUI? Hence why PeaZip is so popular, and J-Zip used to be before it was stuffed with adware.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#185Earlier quoted context omitted.
No, they're just not going to work with you.
im okay with that. That being said, I have not had a single issue delivering zip files with lzma, and i KNOW that I have gotten MANY from the random sources. I would also expect people to be able to decode h265 in an mp4 file. Your proposal seems, to word it bluntly, retarded. You would have mp4 frozen for h264 for ETERNITY, and then invent a new format as replacement? or you would just say "god has bestowed upon the…
If your customer is stuck in the 90s because his 90s technology works perfectly fine and he has no intention to fix things that are not broken. Then deliver stuff that is compatible with 90s technology. He will be happy, will continue to work with you and you will make money.
If your customer is using the latest technologies and values size efficiency, then use the latest codecs.
I usually default to being conservative, because those who are up to date usually don't have a problem with bigger files, but those who are not are going to have a problem with recent formats. Maybe overly so, but that's my experience with working with big companies with decades long lifecycles.
Your job is not to lecture your customer, unless he asked for it. And if he asked for it, he probably expects better arguments that "update your software, idiot". Your job is to deliver what works for him. Now, of course, it is your right to be picky and leave money on the table, I will be happy to go after you and take it.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#186Earlier quoted context omitted.
I understand that security has to compromise for the real world, but a self-extracting archive is possibly one of the worst things one could use in terms of security.
why? and why does it have to be a compromise? You're assuming things because things are already done insecurely. You can authenticate the self-extractor as well as the extracted content. The user gets a nice message "This is a 7zip self-extracting archive sent to you by Bob containing the files below". As an incident responder, I've seen much more of regular archives being used to social engineer users than self-extr…
however, once extracted, jar files do contain executable code, and that is a security issue. the java model pays attention to security, but if code can do something, it can do something bad. if it can't do something, it's not very useful, is it.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#187Earlier quoted context omitted.
Most linux distributions have zip support with zstd.
The `zip` command on Ubuntu is 6.0, which was released in 2009 and does not support zstd. It does support bzip2 though!
You probably mean the "unzip" command, which https://infozip.sourceforge.net/UnZip.html lists as 6.0 being the latest, released on 20 April 2009. Relevant to this discussion, new in that release are support for 64-bit file sizes, bzip2 compression method, and UTF-8 filenames.
The "zip" command is listed at https://infozip.sourceforge.net/Zip.html as 3.0 being the latest, released on 7 July 2008. New in that release are also support for 64-bit file sizes, bzip2 compression method, and UTF-8 filenames.
It would be great if both (or at least unzip) were updated to also support LZMA/XZ/ZSTD as compression methods, but given that there have been no new releases for over fifteen years, I'm not too hopeful.
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#188Earlier quoted context omitted.
> Copyright (c) 1989 - 2014, 2018, 2019, 2020, 2022 Mostly it seems nutty that, after all these years, they’re still updating the zip spec instead of moving on to a newer format.
.7z and .tar.* have existed for at least 20 years now, but you are unlikely to see a wild 7z file and .tar.* is isolated to the UNIX space
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#189Earlier quoted context omitted.
Here are some examples of what I was doing in one case https://www.hydrogen18.com/blog/apk-the-strangest-format.htm... I was running "zstd --ultra --threads=0" which I assumed was asking it for the absolute maximum
I think your mistake was to use --ultra without a compression level. I redid your experiments with rust-wasm-1.83.0-r0.apk: size perc c.time d.time uncompressed: 290072064 - - gzipped original: 105255109 36.29% - bzip2 -9: 107099379 36.92% 21.1s 11.0s bzip3 -b511: 73539847 25.35% 28.9s 32.0s xz --extreme -9: 71010672 24.48% 142.0s 3.1s lzip -9: 70964413 24.46% 173.5s 5.3s zstd --ultra -22: 48288499 16.64% 155.6s 0.4s…
Re: 7-Zip for Windows can now use more than 64 CPU threads for compression
#190Wow, a program that doesn't matter anymore has been very very minimally enhanced on a platform that doesn't matter anymore, benefitting the 7 users that have more than 64 real cores with Windoes and are regularly compressing archives so large that it doesn't drastically reduce the compression ratio to split it into more thsn 64 sections. Posting this link to hn has consumed more human potential than the thing it is d…