3 ms·

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 t

by 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.

by easton 5y ago

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.