3 ms·

Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes. I recall also that a guy hacking around with Linux on the M1 found

Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes. I recall also that a guy hacking around with Linux on the M1 found a CPU feature for VM optimisation that isn't implemented in macOS. Again, would love to add support for that, but I can't.

easton 5y ago
I’ve been feeling that too as I’ve been trying to do little bits of open source. Windows has a ton of little bugs that probably wouldn’t take much to fix, but the feedback goes into a black hole. I asked someone at Microsoft about it one time on GitHub, they said “that’s broken, but even if we started the work now and fixed it, you won’t see it for a year”. I get there’s good reasons for that sometimes, but other times things just don’t work right.
- marcodiego 5y ago
  Actually, for mature critical parts of a linux distro, even small changes can take years to reach end users. I bet that changing the compression used by apt would need a little study of libapt, than understand the process to send the patch... in the specific case of apt, you'll have to write unit tests and persuade developers to accept your changes. If it is accepted you'll may have to wait maybe even 3 years for it to finally reach an Ubuntu LTS when it will finally be deployed to end users who limit themselves to LTS versions by OEM vendors. In the end, I understand them. A good balance between stability and new features is needed.
  - bombcar 5y ago
    The advantage on Linux and friends is that if you really want or need the fix you can apply it yourself.
  - hparadiz 5y ago
    This is why I love using Gentoo. I'll sometimes see bug fixes hours after they are made.
  - pxc 5y ago
    Adding a new compression format is some work, but apt (like most package managers) supports a range of compression formats and you don't have to do anything to tell it to use a different one; it figures it out from the package archive file itself. The dpkg patches required to add zstd support for .deb packages are pretty small, but they've also languished in Debian for a couple years.[1] But Debian's bureaucracy seems especially slow to move, and in general this kind of issue (inefficient compression in a packaging format) is not the kind of issue Linux distros suffer the worst from. Ubuntu, Fedora, Arch, NixOS, GuixSD, Solus, and Void Linux are all already using zstd compression for OS installation, packaging, or both. That pretty much covers your bases for downstream distros and also oddball, niche things. openSUSE will presumably switch to using zstd compression for packaging when they change defaults from zypper to dnf for their high-level package manager. A lot of Linux package managers just use FreeBSD's libarchive for all of their compression needs, which covers a ton of formats. Presumably Apple could do the same with their imaging tools. — 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664
- dylan604 5y ago
  >even if we started the work now and fixed it, you won’t see it for a year So, fix it. Let it be fixed, and then no longer an issue. But because it won't be deployed until a year out, it's not going to be fixed. That's just dumb.
steve_adams_86 5y ago
There could be a good reason for it not being implemented by Apple, but I agree. At least knowing why it’s not yet or if it will be implemented would be nice, but it’s generally a black box.
coldtea 5y ago
>Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes As if you could do that for a random distro you've used? Good luck trying to get them to change how they compress updates upstream, accept your patches, and so on. More realistically you could just change to another distro with a different method of updating. But then again if your issue was not with something distro-dependent, but something like a core tool you want to use (regardless of distro, say, Wayland, Gnome, or GIMP, or GCC), you'll again either have a hard time getting into the community, sending patches, and having them accepted and integrated, or a hard time maintaining them on your own branch. There are issues with Gnome for example, with thousands of user complaints, that haven't been touched for years (e.g. preview in file picker, iirc is a classic example).
- c7DJTLrn 5y ago
  I don't know where you're getting this from but most userspace projects are very open to patches and change especially if it brings objective improvements. The only project I know of that is more conservative is GNOME. In that case I could always fork if I wanted to introduce something that wasn't accepted upstream.
KennyBlanken 5y ago
You don't get your choice in compression technology used by a Linux distribution. If there's some linux distro out there that does offer that choice, that's a waste of resources.
- c7DJTLrn 5y ago
  Completely wrong. Initramfs compression is configurable on most distributions for example.
- howinteresting 5y ago
  Most Linux distros have adopted zstd, and you almost certainly never need anything else. But even so, packages can be compressed in one of several different formats typically.

easton 5y ago

I’ve been feeling that too as I’ve been trying to do little bits of open source. Windows has a ton of little bugs that probably wouldn’t take much to fix, but the feedback goes into a black hole. I asked someone at Microsoft about it one time on GitHub, they said “that’s broken, but even if we started the work now and fixed it, you won’t see it for a year”. I get there’s good reasons for that sometimes, but other times things just don’t work right.

marcodiego 5y ago
Actually, for mature critical parts of a linux distro, even small changes can take years to reach end users. I bet that changing the compression used by apt would need a little study of libapt, than understand the process to send the patch... in the specific case of apt, you'll have to write unit tests and persuade developers to accept your changes. If it is accepted you'll may have to wait maybe even 3 years for it to finally reach an Ubuntu LTS when it will finally be deployed to end users who limit themselves to LTS versions by OEM vendors. In the end, I understand them. A good balance between stability and new features is needed.
- bombcar 5y ago
  The advantage on Linux and friends is that if you really want or need the fix you can apply it yourself.
- hparadiz 5y ago
  This is why I love using Gentoo. I'll sometimes see bug fixes hours after they are made.
- pxc 5y ago
  Adding a new compression format is some work, but apt (like most package managers) supports a range of compression formats and you don't have to do anything to tell it to use a different one; it figures it out from the package archive file itself. The dpkg patches required to add zstd support for .deb packages are pretty small, but they've also languished in Debian for a couple years.[1] But Debian's bureaucracy seems especially slow to move, and in general this kind of issue (inefficient compression in a packaging format) is not the kind of issue Linux distros suffer the worst from. Ubuntu, Fedora, Arch, NixOS, GuixSD, Solus, and Void Linux are all already using zstd compression for OS installation, packaging, or both. That pretty much covers your bases for downstream distros and also oddball, niche things. openSUSE will presumably switch to using zstd compression for packaging when they change defaults from zypper to dnf for their high-level package manager. A lot of Linux package managers just use FreeBSD's libarchive for all of their compression needs, which covers a ton of formats. Presumably Apple could do the same with their imaging tools. — 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664
dylan604 5y ago
>even if we started the work now and fixed it, you won’t see it for a year So, fix it. Let it be fixed, and then no longer an issue. But because it won't be deployed until a year out, it's not going to be fixed. That's just dumb.

steve_adams_86 5y ago

There could be a good reason for it not being implemented by Apple, but I agree. At least knowing why it’s not yet or if it will be implemented would be nice, but it’s generally a black box.

coldtea 5y ago

>Yikes. As a Linux guy my instinct is to go in and fix that but I can't :( it hurts sometimes As if you could do that for a random distro you've used? Good luck trying to get them to change how they compress updates upstream, accept your patches, and so on. More realistically you could just change to another distro with a different method of updating. But then again if your issue was not with something distro-dependent, but something like a core tool you want to use (regardless of distro, say, Wayland, Gnome, or GIMP, or GCC), you'll again either have a hard time getting into the community, sending patches, and having them accepted and integrated, or a hard time maintaining them on your own branch. There are issues with Gnome for example, with thousands of user complaints, that haven't been touched for years (e.g. preview in file picker, iirc is a classic example).

c7DJTLrn 5y ago
I don't know where you're getting this from but most userspace projects are very open to patches and change especially if it brings objective improvements. The only project I know of that is more conservative is GNOME. In that case I could always fork if I wanted to introduce something that wasn't accepted upstream.

KennyBlanken 5y ago

You don't get your choice in compression technology used by a Linux distribution. If there's some linux distro out there that does offer that choice, that's a waste of resources.

c7DJTLrn 5y ago
Completely wrong. Initramfs compression is configurable on most distributions for example.
howinteresting 5y ago
Most Linux distros have adopted zstd, and you almost certainly never need anything else. But even so, packages can be compressed in one of several different formats typically.