8 ms·

In the specific case here, 7z is your friend for all zips and compressed files in general, not sure I've ever used unzip on Linux. Related to that, the Unix ph

by adwf 1y ago

In the specific case here, 7z is your friend for all zips and compressed files in general, not sure I've ever used unzip on Linux. Related to that, the Unix philosophy of simple tools that do one job and do it well, also applies here a bit. More typical workflow would be a utility to tarball something, then another utility to gzip it, then finally another to encrypt it. Leading to file extensions like .tar.gz.pgp, all from piping commands together. As for versioning, I'm not entirely sure why your Debian and Ubuntu installs both claim version 6.00, but that's not typical. If this is for a personal machine, I might recommend switching to a rolling release distro like Arch or Manjaro, which at least give upto date packages on a consistent basis, tracking the upstream version. However, this does come with it's own set of maintenance issues and increased expectation of managing it all yourself. My usual bugbear complaint about Linux (or rather OSS) versioning is that people are far too reluctant to declare v1.00 of their library. Leading to major useful libraries and programs being embedded in the ecosystem, but only reaching something like v0.2 or v0.68 and staying that way for years on end, which can be confusing for people just starting out in the Linux world. They are usually very stable and almost feature complete, but because they aren't finished to perfection according to the original design, people hold off on that final v1 declaration.

DonHopkins 1y ago
The "Unix Philosophy" is a bankrupt romanticized after the fact rationalization to make up excuses and justifications for ridiculous ancient vestigial historic baggage like the lack of shared libraries and decent scripting languages, where you had to shell out THREE heavyweight processes -- "[" and "expr" and a sub-shell -- with an inexplicable flurry of punctuation [ "$(expr 1 + 1)" -eq 2 ] just to test if 1 + 1 = 2, even though the processor has single cycle instructions to add two numbers and test for equality.
- chubot 1y ago
  ??? This complaint seems more than 20 years too late Arithmetic is built into POSIX shell, and it's universally implemented. The following works in basically every shell, and starts 0 new processes, not 2: $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ zsh -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ busybox ash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 YSH (part of https://oils.pub/ https://oils.pub/ ) has a more familiar C- or JavaScript-like syntax: $ ysh -c 'if (1 + 1 === 2) { echo hi }' hi It also has structured data types like Python or JS: $ echo '{"foo": 42}' > test.json $ ysh ysh-0.28$ json read < test.json ysh-0.28$ echo "next = $[_reply.foo + 1]" next = 43 and floats, etc. $ echo "q = $[_reply.foo / 5]" q = 8.4 https://oils.pub/release/latest/doc/ysh-tour.html https://oils.pub/release/latest/doc/ysh-tour.html (It's probably more useful for scripting now, but it's also an interactive shell)
  - DonHopkins 1y ago
    20 years doesn't even get you back to the last century, it's more like 48 years since 1977 when Bourne wrote sh. As one of the authors of the Unix Haters Handbook, published relatively recently in 1994, and someone who's used many versions of Unix since the 1980's, of course I'm fully aware that those problems are hell of a lot more than 20 years old, and that's the whole point: we're still suffering from their "vestigial historic baggage", arcane syntax and semantics originally intended to fork processes and pipe text to solve trivial tasks instead of using shared libraries and machine instructions to perform simple math operations, and people are still trying to justify all that claptrap as the "Unix Philosophy". Care to explain to me how all the problems of X-Windows have been solved so it's no longer valid to criticize the fallout from its legacy vestigial historic baggage we still suffer from even today? How many decades ago did they first promise the Year of the Linux Desktop? The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Why it took THREE processes and a shitload of context switches and punctuation that we are still stuck with to simply test if 1 + 1 = 2 in classic Unix [TM]: [ "$(expr 1 + 1)" -eq 2 ] Breakdown: expr 1 + 1 An external program used to perform arithmetic. $(...) (Command substitution) Runs expr in a subshell to capture its output. [ ... ] In early shells, [ (aka test) was also an external binary. It took THREE separate processes because: Unix lacked built-in arithmetic. The shell couldn't do math. Even conditionals ([) were external. Everything was glued together with fragile text and subprocesses. All of this just to evaluate a single arithmetic expression by ping-ponging in and out of user and kernel space so many times -- despite the CPU being able to do it in a single cycle. That’s exactly the kind of historical inefficiency the "Unix Philosophy" retroactively romanticizes.
    - chubot 1y ago
      I'm aware it used to be that way, but it's long been fixed It's fine to hate Unix, but you should update your examples :)
      - DonHopkins 1y ago
- verandaguy 1y ago
  > TWO heavyweight processes If you're going to emphasize that it's two processes, at least make sure it's actually two processes. `[` is a shell builtin. > `eval` being heavy If you want a more lightweight option, `calc` is available and generally better-suited. > inexplicable flurry of punctuation It's very explicable. It's actually exceptionally well-documented. Shell scripting isn't syntactically easy, which is an artifact of its time plus standardization. The bourne shell dates back to 1979, and POSIX has made backwards-compatibility a priority between editions. In this case: - `[` and `]` delimit a test expression - `"..."` ensure that the result of an expression is always treated as a single-token string rather than splitting a token into multiple based on spaces, which is the default behaviour (and an artifact of sh and bash's basic type system) - `$(...)` denotes that the expression between the parens gets run in a subshell - `-eq` is used for numerical comparison since POSIX shells default to string comparison using the normal `=` equals sign (which is, again, a limitation of the type system and a practical compromise) > even though the processor has single cycle instructions to add two numbers and test for equality I don't really understand what this argument is trying to argue for; shell scripting languages are, for practical reasons, usually interpreted, and in the POSIX case, they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance. Their main priority is ease of interop with their domain. If I wanted to test if one plus one equals two at a multi-terabit-per-second bandwidth I'd write a C program for it that forces AVX512 use via inline assembly, but at that point I think I'd have lost the plot a bit.
  - DonHopkins 1y ago
    I was quite clear that this is HISTORICAL baggage whose syntax and semantics we're still suffering from. I corrected it from TWO to THREE and wrote a step by step description of why it was three processes in the other comment. That's the whole point: it was originally a terrible design, but we're still stuck with the syntactic and semantic consequences even today, in the name of "backwards compatibility". > they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance Even now you're bending over backwards to make ridiculous rationalizations for the bankrupt "Unix Philosophy". And you're just making my point for me. Does the Unix Philosophy say that the shell should be designed to be slow and inefficient and syntactically byzantine on purpose, or are you just making excuses? Maybe you don't think YOUR shell scripts have to be fast, or easy to write, read, and maintain, or perform simple arithmetic, or not have arsenals of pre-loaded foot guns, but speak for yourself.
- whatnow37373 1y ago
  Shell != Unix (philosophy) as I’m sure you are aware. The unix philosophy is having a shell and being able to replace it, not its particular idiosyncrasies at any moment in time. This is like bashing Windows for the look of its buttons.
- pjmlp 1y ago
  The "Unix Philosophy" is some cargo cult among FOSS folks that never used commercial UNIX systems, since Xenix I haven't used any that doesn't have endless options on their man pages.
  - anthk 1y ago
    Well, we are set by your "Windows philosphy", and forget NT being a VMS rehash, we would still be using the crappy W9x designs with DOS crap back and forth. Even Risc OS seems to do better even if it doesn't have memory protection too (I think it hasn't, I didn't try it for more than a few days).
    - pjmlp 1y ago
      Thing is there is no "Windows philosphy" cargo cult, and I don't worship OSes nor languages, all have their plus and minus, use any of them when the situation calls for it, and it is a disservice to oneself to identify themselves to technology stacks like football club memberships given at birth.
      - anthk 1y ago
        Neither I am a sole Unix user; I have Risc OS open (Apache 2.0?) on an RPI to experiment something else beyond Unix/C. But Windows it's too heavyweight, from 8 it has been a disaster. And the NT kernel+explorer can be really slim (look at ReactOS, or XP, or a debloated W7). The problem it's that Apple and MS (and RedHat) are just selling shiny turds wasting tons of cycles to do trivial tasks. Worse, you can't slim down your install so it behaves like a sane system for 1GB of RAM. I can watch 720p@30FPS videos under a n270 netbook with MPV. Something even native players for WXP can't do with low level direct draw calls well enough. The Windows > XP philosophy among RedHat and Apple it's: let bloat and crap out our OSes with unnecesary services and XML crap (and interpreted languages such as JS and C#) for the desktop until hardware vendors idolize US so the average user has to buy new crap to do the same task ever and ever. Security? Why the fuck does Gnome 3 need JS at first? Where's Vala, where it could shine here and Mutter could get a big boost and memory leaks could be a thing of the past?
- eesmith 1y ago
  I realized the hype for the Unix Philosophy was overblown around 1993 when I learned Perl and almost immediately stopped using a dozen different command-line tools.
  - anthk 1y ago
    Ken Thompson and Unix folks agree with you. The point is... Perl was a solution to the former Unix (BSD/GNU) bloatings. When you have a look at Plan 9 (now 9fron) with rc as a shell, awk and the power of rio/acme scripting and namespaces among aux/listen... Perl feels bloated and with the same terse syntax as SH derived shells.
    - eesmith 1y ago
      I've been using Python almost full time since 1998 so, to misquote Dijkstra, I am mentally mutilated beyond regeneration.
    - bmacho 1y ago
      Is plan9 awk different?
      - anthk 1y ago
        Not much; what makes AWK shine it's the I/O in plan9; it's trivial to spawn sockets (literally from the command line), either plain text or encrypted. Also, rc it's much simpler than Bash.
  - whatnow37373 1y ago
    I realized the hype for composing $thing$s was overblown around 1993 when I learned I could just have "A Grand Unified $thing$" and almost immediately stopped using a dozen different $thing$s. Then, a decade or two later, I realized the Grand Unified $thing$ was itself composed, but not by me so I had no control over it. Then I thought to myself, how great would it be if we decompose this Grand Unified $thing$ into many reusable $thing$s? That way we can be optimally productive by not being dependent on the idiosyncrasies of Grand Unified $thing$. And so it was written and so it was done. We built many a $thing$ and the world was good, excellent even. But then one of the Ancients realized we could increase our productivity dramatically if we would compose our many $thing$s into one Grand Unified $thing$ so we wouldn't have to learn to use all these different $thing$s. And so it was written and so it was done. Thus goes the story of the Ancients and their initiation of the most holy of cycles.
- a-french-anon 1y ago
  I don't see what crusty implementation details have to do with a philosophy. In fact, UNIX itself is a poor implementation of the "UNIX" philosophy, which is why Plan 9 exists. The idea of small composable tools doing one thing and doing it well may have been mostly an ideal (and now pretty niche), but I don't think it was purely invented after the fact. Just crippled by the "worse is better".
pxc 1y ago
I came here to make the same recommendation. Just use p7zip for everything; no need to learn a bunch of different compression tools.
- setopt 1y ago
  If you use `atool`, there is no need to use different tools either – it wraps all the different compression tools behind a single interface (`apack`, `aunpack`, `als`) and chooses the right one based on file extensions.
  - Sander_Marechal 1y ago
    There's also `unp`, the universal unpacker.
  - pxc 1y ago
    I'll check this out. I actually don't love p7zip's CLI.
setopt 1y ago
> Related to that, the Unix philosophy of simple tools that do one job and do it well, also applies here a bit. More typical workflow would be a utility to tarball something, then another utility to gzip it, then finally another to encrypt it. Leading to file extensions like .tar.gz.pgp, all from piping commands together. I do this for my own files, but half of the time I zip something, it’s to send it to a Windows user, in which case zip is king.
- issafram 1y ago
  fyi latest version of Windows 11 supports native opening of 7zip files
Squossifrage 1y ago
Info-Zip Unzip 6.00 was released in 2009 and has not been updated since. Most Linux distros (and Apple) just ship that 15-plus-year-old code with their own patches on top to fix bugs and improve compatibility with still-maintained but non-free (or less-free) competing implementations. Unfortunately, while the Info-Zip license is pretty liberal when it comes to redistribution and patching, it makes it hard to fork the project; furthermore, anyone who wanted to do so would face the difficult decision of either dropping or trying to continue to support dozens of legacy platforms. Therefore, nobody has stepped up to take charge and unify the many wildly disparate mini-forks.
tecleandor 1y ago
Was there any problem with 7z some years ago? I feel like I've been actively avoiding it for having the feeling that I've read something bad about it, but I can't remember what. But I could've mixed it with something else. It sometimes happens to me.
- oblio 1y ago
  Hard to say for sure, did SourceForge put malware in their installers many millennia ago?
  - tecleandor 1y ago
    Ah, I think I might remember a couple RCE they had... [0] So for Windows use I then started to recommend a fork called NanaZip [1] that enabled some Windows security features (CFG, CET, Package Integrity Check...) and added support for additional formats that other forks already had [2] [3]. --- 0: https://en.wikipedia.org/wiki/7-Zip#Security 1: https://github.com/M2Team/NanaZip 2: https://github.com/mcmilk/7-Zip-zstd 3: https://github.com/myfreeer/7z-build-nsis
    - jcotton42 1y ago
      NanaZip also works with the Windows 11 File Explorer context menu changes.
aragilar 1y ago
The issue in this case is upstream is dead, so there are random patches. Same thing happened to screen for a bit.

by adwf 1y ago

DonHopkins 1y ago

The "Unix Philosophy" is a bankrupt romanticized after the fact rationalization to make up excuses and justifications for ridiculous ancient vestigial historic baggage like the lack of shared libraries and decent scripting languages, where you had to shell out THREE heavyweight processes -- "[" and "expr" and a sub-shell -- with an inexplicable flurry of punctuation [ "$(expr 1 + 1)" -eq 2 ] just to test if 1 + 1 = 2, even though the processor has single cycle instructions to add two numbers and test for equality.

chubot 1y ago
??? This complaint seems more than 20 years too late Arithmetic is built into POSIX shell, and it's universally implemented. The following works in basically every shell, and starts 0 new processes, not 2: $ bash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ zsh -c '[ $((1 + 1)) = 2 ]; echo $?' 0 $ busybox ash -c '[ $((1 + 1)) = 2 ]; echo $?' 0 YSH (part of https://oils.pub/ https://oils.pub/ ) has a more familiar C- or JavaScript-like syntax: $ ysh -c 'if (1 + 1 === 2) { echo hi }' hi It also has structured data types like Python or JS: $ echo '{"foo": 42}' > test.json $ ysh ysh-0.28$ json read < test.json ysh-0.28$ echo "next = $[_reply.foo + 1]" next = 43 and floats, etc. $ echo "q = $[_reply.foo / 5]" q = 8.4 https://oils.pub/release/latest/doc/ysh-tour.html https://oils.pub/release/latest/doc/ysh-tour.html (It's probably more useful for scripting now, but it's also an interactive shell)
- DonHopkins 1y ago
  20 years doesn't even get you back to the last century, it's more like 48 years since 1977 when Bourne wrote sh. As one of the authors of the Unix Haters Handbook, published relatively recently in 1994, and someone who's used many versions of Unix since the 1980's, of course I'm fully aware that those problems are hell of a lot more than 20 years old, and that's the whole point: we're still suffering from their "vestigial historic baggage", arcane syntax and semantics originally intended to fork processes and pipe text to solve trivial tasks instead of using shared libraries and machine instructions to perform simple math operations, and people are still trying to justify all that claptrap as the "Unix Philosophy". Care to explain to me how all the problems of X-Windows have been solved so it's no longer valid to criticize the fallout from its legacy vestigial historic baggage we still suffer from even today? How many decades ago did they first promise the Year of the Linux Desktop? The X-Windows Disaster: This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins. https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Why it took THREE processes and a shitload of context switches and punctuation that we are still stuck with to simply test if 1 + 1 = 2 in classic Unix [TM]: [ "$(expr 1 + 1)" -eq 2 ] Breakdown: expr 1 + 1 An external program used to perform arithmetic. $(...) (Command substitution) Runs expr in a subshell to capture its output. [ ... ] In early shells, [ (aka test) was also an external binary. It took THREE separate processes because: Unix lacked built-in arithmetic. The shell couldn't do math. Even conditionals ([) were external. Everything was glued together with fragile text and subprocesses. All of this just to evaluate a single arithmetic expression by ping-ponging in and out of user and kernel space so many times -- despite the CPU being able to do it in a single cycle. That’s exactly the kind of historical inefficiency the "Unix Philosophy" retroactively romanticizes.
  - chubot 1y ago
    I'm aware it used to be that way, but it's long been fixed It's fine to hate Unix, but you should update your examples :)
    - DonHopkins 1y ago
verandaguy 1y ago
> TWO heavyweight processes If you're going to emphasize that it's two processes, at least make sure it's actually two processes. `[` is a shell builtin. > `eval` being heavy If you want a more lightweight option, `calc` is available and generally better-suited. > inexplicable flurry of punctuation It's very explicable. It's actually exceptionally well-documented. Shell scripting isn't syntactically easy, which is an artifact of its time plus standardization. The bourne shell dates back to 1979, and POSIX has made backwards-compatibility a priority between editions. In this case: - `[` and `]` delimit a test expression - `"..."` ensure that the result of an expression is always treated as a single-token string rather than splitting a token into multiple based on spaces, which is the default behaviour (and an artifact of sh and bash's basic type system) - `$(...)` denotes that the expression between the parens gets run in a subshell - `-eq` is used for numerical comparison since POSIX shells default to string comparison using the normal `=` equals sign (which is, again, a limitation of the type system and a practical compromise) > even though the processor has single cycle instructions to add two numbers and test for equality I don't really understand what this argument is trying to argue for; shell scripting languages are, for practical reasons, usually interpreted, and in the POSIX case, they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance. Their main priority is ease of interop with their domain. If I wanted to test if one plus one equals two at a multi-terabit-per-second bandwidth I'd write a C program for it that forces AVX512 use via inline assembly, but at that point I think I'd have lost the plot a bit.
- DonHopkins 1y ago
  I was quite clear that this is HISTORICAL baggage whose syntax and semantics we're still suffering from. I corrected it from TWO to THREE and wrote a step by step description of why it was three processes in the other comment. That's the whole point: it was originally a terrible design, but we're still stuck with the syntactic and semantic consequences even today, in the name of "backwards compatibility". > they usually don't have to be fast since they're usually just used to delegate operations off to other code for performance Even now you're bending over backwards to make ridiculous rationalizations for the bankrupt "Unix Philosophy". And you're just making my point for me. Does the Unix Philosophy say that the shell should be designed to be slow and inefficient and syntactically byzantine on purpose, or are you just making excuses? Maybe you don't think YOUR shell scripts have to be fast, or easy to write, read, and maintain, or perform simple arithmetic, or not have arsenals of pre-loaded foot guns, but speak for yourself.
whatnow37373 1y ago
Shell != Unix (philosophy) as I’m sure you are aware. The unix philosophy is having a shell and being able to replace it, not its particular idiosyncrasies at any moment in time. This is like bashing Windows for the look of its buttons.
pjmlp 1y ago
The "Unix Philosophy" is some cargo cult among FOSS folks that never used commercial UNIX systems, since Xenix I haven't used any that doesn't have endless options on their man pages.
- anthk 1y ago
  Well, we are set by your "Windows philosphy", and forget NT being a VMS rehash, we would still be using the crappy W9x designs with DOS crap back and forth. Even Risc OS seems to do better even if it doesn't have memory protection too (I think it hasn't, I didn't try it for more than a few days).
  - pjmlp 1y ago
    Thing is there is no "Windows philosphy" cargo cult, and I don't worship OSes nor languages, all have their plus and minus, use any of them when the situation calls for it, and it is a disservice to oneself to identify themselves to technology stacks like football club memberships given at birth.
    - anthk 1y ago
      Neither I am a sole Unix user; I have Risc OS open (Apache 2.0?) on an RPI to experiment something else beyond Unix/C. But Windows it's too heavyweight, from 8 it has been a disaster. And the NT kernel+explorer can be really slim (look at ReactOS, or XP, or a debloated W7). The problem it's that Apple and MS (and RedHat) are just selling shiny turds wasting tons of cycles to do trivial tasks. Worse, you can't slim down your install so it behaves like a sane system for 1GB of RAM. I can watch 720p@30FPS videos under a n270 netbook with MPV. Something even native players for WXP can't do with low level direct draw calls well enough. The Windows > XP philosophy among RedHat and Apple it's: let bloat and crap out our OSes with unnecesary services and XML crap (and interpreted languages such as JS and C#) for the desktop until hardware vendors idolize US so the average user has to buy new crap to do the same task ever and ever. Security? Why the fuck does Gnome 3 need JS at first? Where's Vala, where it could shine here and Mutter could get a big boost and memory leaks could be a thing of the past?
eesmith 1y ago
I realized the hype for the Unix Philosophy was overblown around 1993 when I learned Perl and almost immediately stopped using a dozen different command-line tools.
- anthk 1y ago
  Ken Thompson and Unix folks agree with you. The point is... Perl was a solution to the former Unix (BSD/GNU) bloatings. When you have a look at Plan 9 (now 9fron) with rc as a shell, awk and the power of rio/acme scripting and namespaces among aux/listen... Perl feels bloated and with the same terse syntax as SH derived shells.
  - eesmith 1y ago
    I've been using Python almost full time since 1998 so, to misquote Dijkstra, I am mentally mutilated beyond regeneration.
  - bmacho 1y ago
    Is plan9 awk different?
    - anthk 1y ago
      Not much; what makes AWK shine it's the I/O in plan9; it's trivial to spawn sockets (literally from the command line), either plain text or encrypted. Also, rc it's much simpler than Bash.
- whatnow37373 1y ago
  I realized the hype for composing $thing$s was overblown around 1993 when I learned I could just have "A Grand Unified $thing$" and almost immediately stopped using a dozen different $thing$s. Then, a decade or two later, I realized the Grand Unified $thing$ was itself composed, but not by me so I had no control over it. Then I thought to myself, how great would it be if we decompose this Grand Unified $thing$ into many reusable $thing$s? That way we can be optimally productive by not being dependent on the idiosyncrasies of Grand Unified $thing$. And so it was written and so it was done. We built many a $thing$ and the world was good, excellent even. But then one of the Ancients realized we could increase our productivity dramatically if we would compose our many $thing$s into one Grand Unified $thing$ so we wouldn't have to learn to use all these different $thing$s. And so it was written and so it was done. Thus goes the story of the Ancients and their initiation of the most holy of cycles.
a-french-anon 1y ago
I don't see what crusty implementation details have to do with a philosophy. In fact, UNIX itself is a poor implementation of the "UNIX" philosophy, which is why Plan 9 exists. The idea of small composable tools doing one thing and doing it well may have been mostly an ideal (and now pretty niche), but I don't think it was purely invented after the fact. Just crippled by the "worse is better".

pxc 1y ago

I came here to make the same recommendation. Just use p7zip for everything; no need to learn a bunch of different compression tools.

setopt 1y ago
If you use `atool`, there is no need to use different tools either – it wraps all the different compression tools behind a single interface (`apack`, `aunpack`, `als`) and chooses the right one based on file extensions.
- Sander_Marechal 1y ago
  There's also `unp`, the universal unpacker.
- pxc 1y ago
  I'll check this out. I actually don't love p7zip's CLI.

setopt 1y ago

> Related to that, the Unix philosophy of simple tools that do one job and do it well, also applies here a bit. More typical workflow would be a utility to tarball something, then another utility to gzip it, then finally another to encrypt it. Leading to file extensions like .tar.gz.pgp, all from piping commands together. I do this for my own files, but half of the time I zip something, it’s to send it to a Windows user, in which case zip is king.

issafram 1y ago
fyi latest version of Windows 11 supports native opening of 7zip files

Squossifrage 1y ago

Info-Zip Unzip 6.00 was released in 2009 and has not been updated since. Most Linux distros (and Apple) just ship that 15-plus-year-old code with their own patches on top to fix bugs and improve compatibility with still-maintained but non-free (or less-free) competing implementations. Unfortunately, while the Info-Zip license is pretty liberal when it comes to redistribution and patching, it makes it hard to fork the project; furthermore, anyone who wanted to do so would face the difficult decision of either dropping or trying to continue to support dozens of legacy platforms. Therefore, nobody has stepped up to take charge and unify the many wildly disparate mini-forks.

tecleandor 1y ago

Was there any problem with 7z some years ago? I feel like I've been actively avoiding it for having the feeling that I've read something bad about it, but I can't remember what. But I could've mixed it with something else. It sometimes happens to me.

oblio 1y ago
Hard to say for sure, did SourceForge put malware in their installers many millennia ago?
- tecleandor 1y ago
  Ah, I think I might remember a couple RCE they had... [0] So for Windows use I then started to recommend a fork called NanaZip [1] that enabled some Windows security features (CFG, CET, Package Integrity Check...) and added support for additional formats that other forks already had [2] [3]. --- 0: https://en.wikipedia.org/wiki/7-Zip#Security 1: https://github.com/M2Team/NanaZip 2: https://github.com/mcmilk/7-Zip-zstd 3: https://github.com/myfreeer/7z-build-nsis
  - jcotton42 1y ago
    NanaZip also works with the Windows 11 File Explorer context menu changes.

aragilar 1y ago

The issue in this case is upstream is dead, so there are random patches. Same thing happened to screen for a bit.