11 ms·

As a relatively new Linux user, I often find the "versioning" of bundled system utilities also to be a bit of a mess, for lack of a better word. A classic exam

As a relatively new Linux user, I often find the "versioning" of bundled system utilities also to be a bit of a mess, for lack of a better word. A classic example, at least from my experience, is `unzip`. On two of my servers (one running Debian and the other an older Ubuntu), neither of their bundled `unzip` versions can handle AES-256 encrypted ZIP files. But apparently, according to some Stack Overflow posts, some distributions have updated theirs to support it. So here is what I ran into: 1. I couldn't easily find an "updated" version of `unzip`, even though I assume it exists and is open source. 2. To make things more confusing, they all claim to be "version 6.00", even though they obviously behave differently. 3. Even if I did find the right version, I'm not sure if replacing the system-bundled one is safe or a good idea. So the end result is that some developer out there (probably volunteering their time) added a great feature to a widely used utility, and yet I still can’t use it. So in a sense, being a core system utility makes `unzip` harder to update than if it were just a third-party tool. I get that it's probably just as bad if not worse on Windows or macOS when it comes to system utilities. But I honestly expected Linux to handle this kind of thing better. (Please feel free to correct me if I’ve misunderstood anything or if there’s a better way to approach this.)

lukan 2y ago
No idea, I feel your confusion, I just use 7z and it could handle my zip needs so far (There are always a million ways to do anything on linux). But I assume, you should be able to update unzip without issues. And if no critical service depends on it, just update and see.
- DonHopkins 2y ago
  [flagged]
  - eli 2y ago
    Why the hostile comments?
    - donnachangstein 2y ago
      This guy has been ranting and raving here longer than I can remember or thought to make an account so I assume he is HN royalty and that's why it's tolerated. That said it doesn't really bother me if I understand the circumstances.
      - sbuk 2y ago
        “This guy” is Don Hopkins who, amongst a long list of achievements in the field of computer science specializing in human computer interaction and computer graphics, is one of the authors of the UNIX haters handbook - specifically the extremely prescient chapter 7 "The X-Windows Disaster", published when Linux was in its infancy. You don't have to like what he is saying, but he has decades of experience and research behind what he says. Know where your field came from. The longer you can look back, the farther you can look forward - sadly something a vocal minority of the community refuses to do. https://www.donhopkins.com/home/resume.html https://www.donhopkins.com/home/resume.html
        eli 2y ago
        Neat. But to be clear: my complaint was the rude and dismissive attitude, not the substance.
        sbuk 2y ago
        When you've been saying the same thing for the last 40 years, and seeing the same responses, more often than not made by people who don't understand where this all comes from, and which do not really counter what you're saying, you'd be rude and dismissive - especially whith the dogma that surronds the "UNIX philosophy", which, in case you aren't aware, wasn't actually put forward by anyone heavily involved with UNIX development. Some empathy with the protagonist whould help. But I get your point...
        lukan 2y ago
        I once got a mail back from dang, about why my account got restricted. (Limited posts per day) "I made plenty of good comments, but this one thread counts as flame war and he has to go by the worst, not by the best comments" I thought about replying with some Don Hopkins comments, that were way worse than what was here and he is clearly not restricted. But I didn't, as I don't do Kindergarten, I just took a time off from HN. But it definitely is not equal standards. So I respect Don Hopkins for his knowledge and experience, but not his style of communication sometimes.
  - jdwithit 2y ago
    Settle down, Beavis. Not everyone is running Linux in a 24/7 production environment. I hear some people even fart around with it at home for fun. I've been in pager rotations for most of the last 20 years so I'm sympathetic to that. If some genius symlinked unzip to 7z with no testing in production and caused an incident I'd be real mad. But uh I don't think that's remotely what OP was suggesting here.
    - lukan 2y ago
      Indeed. Which is why I said: "if no critical service depends on it, just update and see" It did not sound like OP was running a hospital infrastructure. And I never did either, nor intend to. I try to have a linux that does what I want on my computer. 7z was helpful to me, so I shared it, that's it.
soraminazuki 2y ago
Distros are independent projects, so that's to be expected IMO. Though some level of interoperability is nice, diverse options being available is good. That said, most distros have bsdtar in their repositories so you might want to use that instead. The package might be called libarchive depending on the distro. It can extract pretty much any format with a simple `bsdtar xf path/to/file`. AES is also supported for zips. macOS includes it by default and Windows too IIRC, in case you're forced to become a paying Microsoft product^Wuser.
__MatrixMan__ 2y ago
It is a mess. My suggestion is to just rely on the built-in stuff as little as possible. Everything I do gets a git repo and a flake.nix, and direnv activates the environment declared in the flake when I cd to that dir. If I write a script that uses grep, I add the script to the repo and I add pkgs.gnugrep to the flake.nix (also part of the repo). This way, it's the declared version that gets used, not the system version. Later, when I hop from MacOS to Linux, or visa versa, or to WSL, the flake declares the same version of grep, so the script calls the same version of grep, again avoiding whatever the system has lying around. It's a flow that I rather like, although many would describe nix as unfriendly to beginniners, so I'm reluctant to outright recommend it precisely. The important part is: declare your dependencies somehow and use only declared dependencies. Nix is one way to do that, but there's also docker, or you could stick with a particular language ecosystem. python, nodejs, go, rust... they all have ways to bundle and invoke dependencies so you don't have to rely on the system being a certain way and be surprised when it isn't. A nice side effect of doing this is that when you update your dependencies to newer versions, that ends up in a commit, so if everything breaks you can just check out the old commit and use that instead. And these repos, they don't have to be for software projects--they can just be for "all the tools I need when I'm doing XYZ". I have one for a patio I'm building.
- Spivak 2y ago
  This is the way, system packages are for the system. Everything you need lives in .local or in your case /nix. The amount of tooling headaches I've had to deal with is pretty close to zero now that I don't depend on a platform that by design is shifting sand.
adwf 2y 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 2y 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 2y 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)
mistrial9 2y ago
forthright point of view and more power to that.. however in this case the weight falls on one small bit there - the same version number. There is information missing somehow someways
ciupicri 2y ago
Some Linux distributions patch their unzip package, e.g. Fedora https://src.fedoraproject.org/rpms/unzip/tree/f42 https://src.fedoraproject.org/rpms/unzip/tree/f42
cogman10 2y ago
Debian and Ubuntu tend to want to lock the version of a system tools to the version of the OS. Debian tends to have long release cycles, but is very stable. Everything will work perfectly together on stable (in fact, testing tends to be almost as good at stability vs other OSes). Ubuntu is basically Debian with "but what if we released more frequently?". If you want the latest tools, then you'll have to settle for a less stable OS (sort of). Nix and Arch come to mind. Neither are super user friendly. If you want stable and the latest tools, Gentoo is the way to go. However, it's even more intimidating than Arch. If you want stability and simplicity, then the other way to go is sacrificing disk space. Docker/podman, flatpak, appcontainers, and snap are all contenders in this field. Windows and Mac both have the same problem. Windows solved this by basically just shipping old versions of libraries and dynamically linking them in based on what app is running.
- thayne 2y ago
  "stable" as used to describe debian (and Ubuntu) means "does not change", which includes adding new functionality.
  - damentz 2y ago
    Correct, another way of looking at it is from a programming angle. If Debian fixes a bug that breaks your tool, then Debian is unstable. Therefore, to maintain stability, Debian must not fix bugs unless they threaten security. The term "stable" is the most polluted term in Linux, it's not something to be proud of. Similar to how high uptime was a virtue, now it just means your system probably has been pwned at some point.
- odo1242 2y ago
  Fedora strikes a pretty good tradeoff on the “is user friendly” and “has latest tools regardless of system version” balance, I would say.
  - rurban 2y ago
    Exactly. Much more stable and much more uptodate as Debian derivates. But much less packages also.
neckro23 2y ago
It is even worse on MacOS, because Apple bundles the BSD versions of common Unix utilities instead of the (generally more featureful) GNU versions. So good luck writing a Bash script that works on both MacOS and Linux...
- petre 2y ago
  Just use zsh on MacOS.
  - ElectricalUnion 2y ago
    Using zsh will not fix the fact that other, non-shell POSIX utilities will not suddenly have useful GNU extensions. Also, zsh is not installed by default on most distros.
    - petre 2y ago
      MacOS userspace was forked from FreeBSD, that's why it bundles non-GNU extensions. Also the FreeBSD userspace has since then incorporated GNUisms. Why they went with Bash 2 as the defualt shell is beyond me. I always switched to and used Zsh which had a more recent version. Now I'm also using it on Linux and FreeBSD, because I want a consistent shell.
      - Squossifrage 2y ago
        The macOS userspace was never forked from FreeBSD or any other BSD. If anything, it was forked from NextSTEP. In actual practice, it is a collection of individual components taken from a variety of sources. When development of Mac OS X began in 1999, most command-line tools and a large part of libc were derived from either NetBSD or OpenBSD via NextSTEP. Over the years, there has been a shift toward FreeBSD. Apple maintain a collection of GitHub repositories of their Open Source components where you can see the evolution from one release to the next. Most of them have XML metadata indicating the origin of each individual component.
      - wkat4242 2y ago
wmf 2y ago
If I want to mess around with something without endangering the system I put it in ~/bin. You could compile unzip from source and rename it something like ~/bin/newunzip. If it doesn't work just delete it.
tame3902 2y ago
unzip is a special case: upstream development has basically stopped. The last release was in 2009[0]. (That's the version 6.0.) Since then there were multiple issues discovered and it lacks some features. So everybody patches the hell out of that release[1]. The end result is that you have very different executables with the same version number. [0]: https://infozip.sourceforge.net/UnZip.html https://infozip.sourceforge.net/UnZip.html [1]: here the build recipe from Arch, where you can see the number of patches that are applied: https://gitlab.archlinux.org/archlinux/packaging/packages/unzip/-/blob/main/PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/un...
- blueflow 2y ago
  I maintain a huge number of git mirror of git repositories and i have some overview of activity there. Many open source projects have stopped activity and/or do not make any new releases. Like syslinux, which seems to be in a similar situation as unzip. And some projects like Quagga went completely awol and don't even have a functional git remote. So unzip is not really that special, its a mode general problem with waning interest.
  - erinnh 2y ago
    Quagga got forked though and is actively being developed. FRRouting is the fork.
  - tame3902 2y ago
    I wasn't trying to imply that unzip is the only one. But the way I learned that unzip is unmaintained was pretty horrible. I found an old zip file I created ages ago on Windows. Extracting it on Arch caused no problem. But on FreeBSD, filenames containing non-ASCII characters were not decoded correctly. Well, they probably use different projects for unzip, this happens. Wrong, they use the same upstream, but each decided to apply different patches to add features. And some of the patches address nasty bugs. For something as basic as unzip, my experience as a user is that when it has so many issues, it either gets removed completely or it gets forked. The most reliable way I found to unzip a zip archive consists of a few lines of python.
procaryote 2y ago
Compressing and encrypting as separate operations would bypass this issue. A symmetrically encrypted foo.zip.gpg or foo.tgz.gpg would work in a lot more places than a bleeding edge zip version. Also you get better tested and audited encryption code
NoboruWataya 2y ago
I use Arch on my personal laptop daily but have Debian installed on a VPS, and this is one aspect of Debian that bugs me (though I totally understand why they do it). I am so used to having the latest version of everything available to me very quickly on Arch, I am quite commonly stung when I try to do something on my VPS only to find that the tools in the Debian repos are a few versions behind and don't yet have the features I have been happily using on Arch. It's particularly frustrating when I have been working on a project on my personal laptop and then try to deploy it on my VPS only to find that all of the dependencies are several versions behind and don't work. Again, not a criticism of Debian, just a friction I noticed moving between a "bleeding edge" and more stable distro regularly.
- everfrustrated 2y ago
  If you want the latest version of everything you are looking for Debian Unstable
aragilar 2y ago
unzip 6.0 is from 2009 (see the manpage or https://infozip.sourceforge.net/UnZip.html https://infozip.sourceforge.net/UnZip.html). I suspect there are patches floating around (so YMMV as to which patches are applied), or someone has aliases/symlinked some other implementation as "unzip" (like Apple has done here, though unlike unzip rsync is maintained). Try using atool (which wraps the various options for different archives and should hopefully fix your problem) or the tools provided by https://libzip.org/documentation/ https://libzip.org/documentation/. Practically, what you're hitting is the problem when upstream is dead, and there is no coordination between different distros to centrally take over maintenance.
dazzawazza 2y ago
On of the many reasons I switched to FreeBSD over 20 years ago. Kernel and user-space developed together. No surprises, just consistent productivity.
sneak 2y ago
I feel there is an opportunity for a modern go or rust utility that does compression/decompression in a zillion different formats with a subcommand interface “z gzip -d” or “z zstd -9” or “z zip -d” or “z cpio -d” or similar. Maybe I’ll write it.
MisterTea 2y ago
> As a relatively new Linux user, You need to understand that you are now in Unix land which means you compose this pipeline using programs that perform each step of the processes. So when creating an encrypted backup you would use: `tar -c /home/foo | gzip | aescrypt >backup.tgz.aes` or something to that effect. This lets you use whatever compression program in the pipe. Breaking this composability leads to the kind of problem you are complaining about. It also removes the ability of splitting this pipeline across machines allowing you to distribute the compute cost.

lukan 2y ago

No idea, I feel your confusion, I just use 7z and it could handle my zip needs so far (There are always a million ways to do anything on linux). But I assume, you should be able to update unzip without issues. And if no critical service depends on it, just update and see.

DonHopkins 2y ago
[flagged]
- eli 2y ago
  Why the hostile comments?
  - donnachangstein 2y ago
    This guy has been ranting and raving here longer than I can remember or thought to make an account so I assume he is HN royalty and that's why it's tolerated. That said it doesn't really bother me if I understand the circumstances.
    - sbuk 2y ago
      “This guy” is Don Hopkins who, amongst a long list of achievements in the field of computer science specializing in human computer interaction and computer graphics, is one of the authors of the UNIX haters handbook - specifically the extremely prescient chapter 7 "The X-Windows Disaster", published when Linux was in its infancy. You don't have to like what he is saying, but he has decades of experience and research behind what he says. Know where your field came from. The longer you can look back, the farther you can look forward - sadly something a vocal minority of the community refuses to do. https://www.donhopkins.com/home/resume.html https://www.donhopkins.com/home/resume.html
      - eli 2y ago
        Neat. But to be clear: my complaint was the rude and dismissive attitude, not the substance.
        sbuk 2y ago
        When you've been saying the same thing for the last 40 years, and seeing the same responses, more often than not made by people who don't understand where this all comes from, and which do not really counter what you're saying, you'd be rude and dismissive - especially whith the dogma that surronds the "UNIX philosophy", which, in case you aren't aware, wasn't actually put forward by anyone heavily involved with UNIX development. Some empathy with the protagonist whould help. But I get your point...
        lukan 2y ago
        I once got a mail back from dang, about why my account got restricted. (Limited posts per day) "I made plenty of good comments, but this one thread counts as flame war and he has to go by the worst, not by the best comments" I thought about replying with some Don Hopkins comments, that were way worse than what was here and he is clearly not restricted. But I didn't, as I don't do Kindergarten, I just took a time off from HN. But it definitely is not equal standards. So I respect Don Hopkins for his knowledge and experience, but not his style of communication sometimes.
- jdwithit 2y ago
  Settle down, Beavis. Not everyone is running Linux in a 24/7 production environment. I hear some people even fart around with it at home for fun. I've been in pager rotations for most of the last 20 years so I'm sympathetic to that. If some genius symlinked unzip to 7z with no testing in production and caused an incident I'd be real mad. But uh I don't think that's remotely what OP was suggesting here.
  - lukan 2y ago
    Indeed. Which is why I said: "if no critical service depends on it, just update and see" It did not sound like OP was running a hospital infrastructure. And I never did either, nor intend to. I try to have a linux that does what I want on my computer. 7z was helpful to me, so I shared it, that's it.

soraminazuki 2y ago

Distros are independent projects, so that's to be expected IMO. Though some level of interoperability is nice, diverse options being available is good. That said, most distros have bsdtar in their repositories so you might want to use that instead. The package might be called libarchive depending on the distro. It can extract pretty much any format with a simple `bsdtar xf path/to/file`. AES is also supported for zips. macOS includes it by default and Windows too IIRC, in case you're forced to become a paying Microsoft product^Wuser.

__MatrixMan__ 2y ago

It is a mess. My suggestion is to just rely on the built-in stuff as little as possible. Everything I do gets a git repo and a flake.nix, and direnv activates the environment declared in the flake when I cd to that dir. If I write a script that uses grep, I add the script to the repo and I add pkgs.gnugrep to the flake.nix (also part of the repo). This way, it's the declared version that gets used, not the system version. Later, when I hop from MacOS to Linux, or visa versa, or to WSL, the flake declares the same version of grep, so the script calls the same version of grep, again avoiding whatever the system has lying around. It's a flow that I rather like, although many would describe nix as unfriendly to beginniners, so I'm reluctant to outright recommend it precisely. The important part is: declare your dependencies somehow and use only declared dependencies. Nix is one way to do that, but there's also docker, or you could stick with a particular language ecosystem. python, nodejs, go, rust... they all have ways to bundle and invoke dependencies so you don't have to rely on the system being a certain way and be surprised when it isn't. A nice side effect of doing this is that when you update your dependencies to newer versions, that ends up in a commit, so if everything breaks you can just check out the old commit and use that instead. And these repos, they don't have to be for software projects--they can just be for "all the tools I need when I'm doing XYZ". I have one for a patio I'm building.

Spivak 2y ago
This is the way, system packages are for the system. Everything you need lives in .local or in your case /nix. The amount of tooling headaches I've had to deal with is pretty close to zero now that I don't depend on a platform that by design is shifting sand.

adwf 2y 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 2y 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 2y 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)

mistrial9 2y ago

forthright point of view and more power to that.. however in this case the weight falls on one small bit there - the same version number. There is information missing somehow someways

ciupicri 2y ago

Some Linux distributions patch their unzip package, e.g. Fedora https://src.fedoraproject.org/rpms/unzip/tree/f42 https://src.fedoraproject.org/rpms/unzip/tree/f42

cogman10 2y ago

Debian and Ubuntu tend to want to lock the version of a system tools to the version of the OS. Debian tends to have long release cycles, but is very stable. Everything will work perfectly together on stable (in fact, testing tends to be almost as good at stability vs other OSes). Ubuntu is basically Debian with "but what if we released more frequently?". If you want the latest tools, then you'll have to settle for a less stable OS (sort of). Nix and Arch come to mind. Neither are super user friendly. If you want stable and the latest tools, Gentoo is the way to go. However, it's even more intimidating than Arch. If you want stability and simplicity, then the other way to go is sacrificing disk space. Docker/podman, flatpak, appcontainers, and snap are all contenders in this field. Windows and Mac both have the same problem. Windows solved this by basically just shipping old versions of libraries and dynamically linking them in based on what app is running.

thayne 2y ago
"stable" as used to describe debian (and Ubuntu) means "does not change", which includes adding new functionality.
- damentz 2y ago
  Correct, another way of looking at it is from a programming angle. If Debian fixes a bug that breaks your tool, then Debian is unstable. Therefore, to maintain stability, Debian must not fix bugs unless they threaten security. The term "stable" is the most polluted term in Linux, it's not something to be proud of. Similar to how high uptime was a virtue, now it just means your system probably has been pwned at some point.
odo1242 2y ago
Fedora strikes a pretty good tradeoff on the “is user friendly” and “has latest tools regardless of system version” balance, I would say.
- rurban 2y ago
  Exactly. Much more stable and much more uptodate as Debian derivates. But much less packages also.

neckro23 2y ago

It is even worse on MacOS, because Apple bundles the BSD versions of common Unix utilities instead of the (generally more featureful) GNU versions. So good luck writing a Bash script that works on both MacOS and Linux...

petre 2y ago
Just use zsh on MacOS.
- ElectricalUnion 2y ago
  Using zsh will not fix the fact that other, non-shell POSIX utilities will not suddenly have useful GNU extensions. Also, zsh is not installed by default on most distros.
  - petre 2y ago
    MacOS userspace was forked from FreeBSD, that's why it bundles non-GNU extensions. Also the FreeBSD userspace has since then incorporated GNUisms. Why they went with Bash 2 as the defualt shell is beyond me. I always switched to and used Zsh which had a more recent version. Now I'm also using it on Linux and FreeBSD, because I want a consistent shell.
    - Squossifrage 2y ago
      The macOS userspace was never forked from FreeBSD or any other BSD. If anything, it was forked from NextSTEP. In actual practice, it is a collection of individual components taken from a variety of sources. When development of Mac OS X began in 1999, most command-line tools and a large part of libc were derived from either NetBSD or OpenBSD via NextSTEP. Over the years, there has been a shift toward FreeBSD. Apple maintain a collection of GitHub repositories of their Open Source components where you can see the evolution from one release to the next. Most of them have XML metadata indicating the origin of each individual component.
    - wkat4242 2y ago

wmf 2y ago

If I want to mess around with something without endangering the system I put it in ~/bin. You could compile unzip from source and rename it something like ~/bin/newunzip. If it doesn't work just delete it.

tame3902 2y ago

unzip is a special case: upstream development has basically stopped. The last release was in 2009[0]. (That's the version 6.0.) Since then there were multiple issues discovered and it lacks some features. So everybody patches the hell out of that release[1]. The end result is that you have very different executables with the same version number. [0]: https://infozip.sourceforge.net/UnZip.html https://infozip.sourceforge.net/UnZip.html [1]: here the build recipe from Arch, where you can see the number of patches that are applied: https://gitlab.archlinux.org/archlinux/packaging/packages/unzip/-/blob/main/PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/un...

blueflow 2y ago
I maintain a huge number of git mirror of git repositories and i have some overview of activity there. Many open source projects have stopped activity and/or do not make any new releases. Like syslinux, which seems to be in a similar situation as unzip. And some projects like Quagga went completely awol and don't even have a functional git remote. So unzip is not really that special, its a mode general problem with waning interest.
- erinnh 2y ago
  Quagga got forked though and is actively being developed. FRRouting is the fork.
- tame3902 2y ago
  I wasn't trying to imply that unzip is the only one. But the way I learned that unzip is unmaintained was pretty horrible. I found an old zip file I created ages ago on Windows. Extracting it on Arch caused no problem. But on FreeBSD, filenames containing non-ASCII characters were not decoded correctly. Well, they probably use different projects for unzip, this happens. Wrong, they use the same upstream, but each decided to apply different patches to add features. And some of the patches address nasty bugs. For something as basic as unzip, my experience as a user is that when it has so many issues, it either gets removed completely or it gets forked. The most reliable way I found to unzip a zip archive consists of a few lines of python.

procaryote 2y ago

Compressing and encrypting as separate operations would bypass this issue. A symmetrically encrypted foo.zip.gpg or foo.tgz.gpg would work in a lot more places than a bleeding edge zip version. Also you get better tested and audited encryption code

NoboruWataya 2y ago

I use Arch on my personal laptop daily but have Debian installed on a VPS, and this is one aspect of Debian that bugs me (though I totally understand why they do it). I am so used to having the latest version of everything available to me very quickly on Arch, I am quite commonly stung when I try to do something on my VPS only to find that the tools in the Debian repos are a few versions behind and don't yet have the features I have been happily using on Arch. It's particularly frustrating when I have been working on a project on my personal laptop and then try to deploy it on my VPS only to find that all of the dependencies are several versions behind and don't work. Again, not a criticism of Debian, just a friction I noticed moving between a "bleeding edge" and more stable distro regularly.

everfrustrated 2y ago
If you want the latest version of everything you are looking for Debian Unstable

aragilar 2y ago

unzip 6.0 is from 2009 (see the manpage or https://infozip.sourceforge.net/UnZip.html https://infozip.sourceforge.net/UnZip.html). I suspect there are patches floating around (so YMMV as to which patches are applied), or someone has aliases/symlinked some other implementation as "unzip" (like Apple has done here, though unlike unzip rsync is maintained). Try using atool (which wraps the various options for different archives and should hopefully fix your problem) or the tools provided by https://libzip.org/documentation/ https://libzip.org/documentation/. Practically, what you're hitting is the problem when upstream is dead, and there is no coordination between different distros to centrally take over maintenance.

dazzawazza 2y ago

On of the many reasons I switched to FreeBSD over 20 years ago. Kernel and user-space developed together. No surprises, just consistent productivity.

sneak 2y ago

I feel there is an opportunity for a modern go or rust utility that does compression/decompression in a zillion different formats with a subcommand interface “z gzip -d” or “z zstd -9” or “z zip -d” or “z cpio -d” or similar. Maybe I’ll write it.

MisterTea 2y ago

> As a relatively new Linux user, You need to understand that you are now in Unix land which means you compose this pipeline using programs that perform each step of the processes. So when creating an encrypted backup you would use: `tar -c /home/foo | gzip | aescrypt >backup.tgz.aes` or something to that effect. This lets you use whatever compression program in the pipe. Breaking this composability leads to the kind of problem you are complaining about. It also removes the ability of splitting this pipeline across machines allowing you to distribute the compute cost.