5 ms·

The lwn thread this responds to is hilarious: http://lwn.net/Articles/364528/ http://lwn.net/Articles/364528/ The mainstream Linux distributions are the forkie

by blasdel 17y ago

The lwn thread this responds to is hilarious: http://lwn.net/Articles/364528/ http://lwn.net/Articles/364528/ The mainstream Linux distributions are the forkiest projects to ever exist, as a point of immense pride: "we have 20k+ forked packages in our repository!". Their whole sense of purpose is built around taking software from upstream and then mutilating it arbitrarily: * License wank * Freezing it at an arbitrary version number for 6 months to 3 years * Patching it so that it works with your frozen dependencies * Independently backporting a random set of 'security' patches * Disabling features, often for ideological reasons * Dismembering it into separate packages * Rearranging its files to fit into a reverse hierarchy (which completely breaks any worthwhile language-specific module system) * Patching it to use a non-standard default configuration (often the personal preferences of the packager) This is the heat death of the universe calling the kettle black. It's a lumber warehouse proprietor picking the mote out of a customer's eye. I hope their heads fall off.

senko 17y ago
Deltas (ie. patches you apply on top of upstream release when making a package) are not forks. Sane distros do that instead of forking for most packages if they have to change anything. Also, most package maintainers know the smaller the delta the less work they have to do, so it's in their own interest to minimise the changes (or try to push changes upstream). (Note: I'm not a Fedora user so can't say whether Fedora, referred to in the article, belongs in that group) OTOH, code dumps of forked projects containing a mix of upstream and modified code without clear indication which code was pulled and which added/modified are a nightmare to work with. [EDIT: not to say Google doesn't, as in the submitted article it's clear that they're trying.]
DarkShikari 17y ago
ffmpeg is one of the most notorious victims of this. Some examples of utter stupidity that has befallen many mainstream distros. 1. Arbitrarily disabling functionality due to worries about patents. For example, disabling all of the encoders, despite the fact that the decoders and encoders infringe by and large the same patents, owned by the exact same people, covered by the same royalty agreements. In other words, package managers at best attempting to look as if they were doing something when they in fact weren't, and at worst just being outright dishonest (Debian, some others). The actual reality is that it is probably impossible to compile ffmpeg without violating a patent. 2. Disabling all assembly optimizations because they saw it in a guide somewhere, and then wondering why everyone is unable to play back anything above SD video (too many to count). 3. Disabling all assembly optimizations because the package maintainer had a broken GCC installation and wasn't able to get the assembly code to compile properly (Macports). 4. Disabling all assembly optimizations because someone felt like hooking up USE flags for every single configure option, and then forgetting to set the defaults accordingly (Gentoo). 5. Packaging separate versions of ffmpeg for every single backend that uses it (gstreamer, mplayer, chromium) for no apparent reason other than to waste disk space. Oh, and configuring them all slightly differently, of course. 6. Packaging two separate sets of ffmpeg libraries, one with basic features and one with kitchen-sink features, but only packaging one actual ffmpeg frontend, resulting in a frontend that doesn't realize how it was actually configured (since the .so files are from the enhanced version, but the binary is from the non-enhanced version), resulting in very confused developers dealing with bug reports where the ./configure flags reported by ffmpeg are wrong (Ubuntu). 7. Dismembering ffmpeg into sub-library packages (libavcodec, libavformat, libavdevice), despite the fact that they come together and have interdependencies. This caused massive breakage when someone made a change to libavutil that only affected the internal API, and so the major version wasn't updated, and... (Ubuntu and many others). What a mess. (Note many of the distros I listed have since fixed their practices, so it's not all bad news.)

by blasdel 17y ago

senko 17y ago

Deltas (ie. patches you apply on top of upstream release when making a package) are not forks. Sane distros do that instead of forking for most packages if they have to change anything. Also, most package maintainers know the smaller the delta the less work they have to do, so it's in their own interest to minimise the changes (or try to push changes upstream). (Note: I'm not a Fedora user so can't say whether Fedora, referred to in the article, belongs in that group) OTOH, code dumps of forked projects containing a mix of upstream and modified code without clear indication which code was pulled and which added/modified are a nightmare to work with. [EDIT: not to say Google doesn't, as in the submitted article it's clear that they're trying.]

DarkShikari 17y ago

ffmpeg is one of the most notorious victims of this. Some examples of utter stupidity that has befallen many mainstream distros. 1. Arbitrarily disabling functionality due to worries about patents. For example, disabling all of the encoders, despite the fact that the decoders and encoders infringe by and large the same patents, owned by the exact same people, covered by the same royalty agreements. In other words, package managers at best attempting to look as if they were doing something when they in fact weren't, and at worst just being outright dishonest (Debian, some others). The actual reality is that it is probably impossible to compile ffmpeg without violating a patent. 2. Disabling all assembly optimizations because they saw it in a guide somewhere, and then wondering why everyone is unable to play back anything above SD video (too many to count). 3. Disabling all assembly optimizations because the package maintainer had a broken GCC installation and wasn't able to get the assembly code to compile properly (Macports). 4. Disabling all assembly optimizations because someone felt like hooking up USE flags for every single configure option, and then forgetting to set the defaults accordingly (Gentoo). 5. Packaging separate versions of ffmpeg for every single backend that uses it (gstreamer, mplayer, chromium) for no apparent reason other than to waste disk space. Oh, and configuring them all slightly differently, of course. 6. Packaging two separate sets of ffmpeg libraries, one with basic features and one with kitchen-sink features, but only packaging one actual ffmpeg frontend, resulting in a frontend that doesn't realize how it was actually configured (since the .so files are from the enhanced version, but the binary is from the non-enhanced version), resulting in very confused developers dealing with bug reports where the ./configure flags reported by ffmpeg are wrong (Ubuntu). 7. Dismembering ffmpeg into sub-library packages (libavcodec, libavformat, libavdevice), despite the fact that they come together and have interdependencies. This caused massive breakage when someone made a change to libavutil that only affected the internal API, and so the major version wasn't updated, and... (Ubuntu and many others). What a mess. (Note many of the distros I listed have since fixed their practices, so it's not all bad news.)