Recent Features
| |||||||||||||
Changes and complaintsChanges and complaintsPosted Feb 23, 2012 14:46 UTC (Thu) by NAR (subscriber, #1313)In reply to: Changes and complaints by michaeljt Parent article: Changes and complaints They want to have the latest version of whatever they are actively following available while the rest just stays as it was or improves slowly and predictably. This goes against the whole philosophy of distributions Exactly. I might want the latest Firefox with the latest plugins, but I do not want new desktop toolbars or menus. I can do this on Windows, on a supported(!) OS I've got a user interface that didn't change in 15 years (there's a Win95 theme for XP and even for Vista) and the newest browsers. Would I be able to run the latest Firefox on Debian woody? I hardly think so. And as a user I absolutely don't care if Windows has "unmaintenable, unprofessional, messy" code to achieve backwards compatibility, I'm only interested in the result.
(Log in to post comments)
Changes and complaints Posted Feb 23, 2012 16:26 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I've been wondering quite a bit about how this would be achievable on a modern Linux. Obviously statically linking would solve some of the problems, and I suspect that the larger disk and memory consumption would hurt more psychologically (those who noticed it at all) than in any noticeable way. Possibly with faster loading as a compensation prize. I'm not sure if the extra network bandwidth for updates would be painful (particularly in places with less of the stuff available), though one could imagine getting the static binaries unlinked from a distribution and linking them on arrival. Nonetheless, there is a lot of infrastructure that you really want to share, like graphical tool kit plug-ins and configuration, which might get rather painful if you were using different static versions of the tool kit libraries in different applications. (Evil voices inside me wonder about using the system copy of Python to access the installed tool kit, with script that can handle various versions of Gtk+ and Qt, and shipping a static fall-back in case that fails.)
Changes and complaints Posted Feb 23, 2012 16:47 UTC (Thu) by khim (subscriber, #9252) [Link] I've been wondering quite a bit about how this would be achievable on a modern Linux. Modern Linux is fine. Modern GLibC is fine. Modern Xlib and few other pieces are fine. Even dpkg/rpm are fine! They system breaks apart at the next level: sadly it was not a design goal for all these fancy repos to give you choice. They are designed with "everything must be of the latest version" approach. Nonetheless, there is a lot of infrastructure that you really want to share, like graphical tool kit plug-ins and configuration, which might get rather painful if you were using different static versions of the tool kit libraries in different applications. Right. That's why you should design you plugin systems to be upgradeable and side-by-side installable. This is not that hard, but it must be an explicit design goal. As long as answer to "how can I install some program" is "it should come from your distribution repo" we are stuck with all these problems. P.S. The funny thing is that while developers are hurt by distributors they often depend on them, too: they provide new versions of things which are not compatible with older ones and not parallel-installable, simultaneously! This only works because distributor repos make it possible.
Changes and complaints Posted Feb 23, 2012 16:57 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> Modern Linux is fine. Modern GLibC is fine. Modern Xlib and few other pieces are fine. Even dpkg/rpm are fine!
> They system breaks apart at the next level: sadly it was not a design goal for all these fancy repos to give you choice. They are designed with "everything must be of the latest version" approach.
Quite agree. I was including your "next level" in my vague "modern Linux".
> Right. That's why you should design you plugin systems to be upgradeable and side-by-side installable. This is not that hard, but it must be an explicit design goal. As long as answer to "how can I install some program" is "it should come from your distribution repo" we are stuck with all these problems.
Again, I agree, but my musings were/are about how to force what we have now into working with applications taken from other sources without things becoming too fragile. Not saying my evil thought above falls into that category!
Changes and complaints Posted Feb 23, 2012 19:01 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
It's not a design choice of Firefox to be very compatible. Linux distributions are about integration.
Want the latest Firefox with your Stable Debian system? http://mozilla.debian.net/ .
It works because there's a dedicated Debian packager maintaining this. But hey, the packages from Mozilla.com only work because of dedicated packagers, right?
The plug-ins of Firefox are really not designed to be installed as system packages (though from what I hear, the said packager is working on it).
Another question: a bug in libpng is discovered and fixed. What packages should be rebuilt?
Changes and complaints Posted Feb 23, 2012 19:29 UTC (Thu) by lacos (subscriber, #70616) [Link]
"Another question: a bug in libpng is discovered and fixed. What packages should be rebuilt?"
The base system's provider would rebuild the shared lib and push the update. All dependent base system apps would benefit.
The vendor providing the extra package (statically linked with a specific version of libpng) should monitor all libs they link statically into the app. When there's a security advisory for libpng, they should backport the fix (or grab the new upstream release if appropriate), rebuild their app with the fixed lib, and push the product via a separate channel.
I have the impression this is how Firefox works on Windows. (Except they may not link statically, just maintain their private set of DLLs.)
Changes and complaints Posted Feb 24, 2012 9:37 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
> The vendor providing the extra package (statically linked with a specific version of libpng) should monitor all libs they link statically into the app. When there's a security advisory for libpng, they should backport the fix (or grab the new upstream release if appropriate), rebuild their app with the fixed lib, and push the product via a separate channel.
I don't even see why they need to do this manually. Linux distributions today handle security updates almost transparently to the system user, and this could be pushed up a level so that the statically linked "extra" package is automatically rebuilt and re-downloaded by its users. Granted, it ought to be tested first, but that doesn't really happen now in the dynamically linked situation we have.
Changes and complaints Posted Feb 23, 2012 19:35 UTC (Thu) by khim (subscriber, #9252) [Link] It works because there's a dedicated Debian packager maintaining this. But hey, the packages from Mozilla.com only work because of dedicated packagers, right? Right. But there are a difference: you need one packager for Windows (90% of market), one packager for MacOS (7% of market) and one packager for iOS and one packager for Android (which are already significantly more popular then Linux) - yet you need dozen of packagers for Linux. Another question: a bug in libpng is discovered and fixed. What packages should be rebuilt? Ah, the infamous "security" strawman. Yes, all packages must be rebuilt in MacOS and Windows case but only one package in Linux case. Except it's not true: Firefox bundles it's own fork of libpng anyway thus it must be rebuilt, too. The problem with this approach is that it just does not work. If users are not using your platform then it does not really matter how secure it is. Sure, if we are discussing some kind of military OS then it may make some sense… except it fails there, too: military starts from most popular OS, not from the most secure one.
Changes and complaints Posted Feb 24, 2012 0:51 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>one packager for Windows, yet you need dozen of packagers for Linux.
Judging from the fact that VMware, NVIDIA and ATI do not seem to give a damn about organized distro integration and instead produce self-extracting sh archives that spew untracked files into one's system, it seems more like there is just one person responsible for the Linux package, and the remaining 10 members of the team know how to edit the Windows MSI.
Meanwhile, it would not be all that hard to use [an own instance of] a potent cross-distro build system like Open Build Service to cater for a number of distros in two swoops.
Changes and complaints Posted Feb 24, 2012 12:17 UTC (Fri) by khim (subscriber, #9252) [Link] Judging from the fact that VMware, NVIDIA and ATI do not seem to give a damn about organized distro integration and instead produce self-extracting sh archives that spew untracked files into one's system, it seems more like there is just one person responsible for the Linux package, and the remaining 10 members of the team know how to edit the Windows MSI. Well, that's certainly sensible choice: this about how much marketshares differ thus it's prudent allocation of resources. Meanwhile, it would not be all that hard to use [an own instance of] a potent cross-distro build system like Open Build Service to cater for a number of distros in two swoops. Yes, it's possible, but it does not solve the whole problem. It's not as hard to build your package (well, this is a problem, too, but a [relatively] minor one). It's the fact that you need to [test] it. Single self-extracting sh archive solves this problem to some degree, cross-distro build system does not. And even single self-extracting sh archive requires a lot of distro-specific code to handle [supposedly] trivial things (like the ability to run per-machine or per-session background process). All these things are just a band-aids and don't solve the core problem.
Changes and complaints Posted Feb 23, 2012 22:46 UTC (Thu) by misc (subscriber, #73730) [Link]
> They are designed with "everything must be of the latest version" approach.
No, that's designed of "everything must be of a specific version", which is the only sane way of designing it without having a combinatorial explosion.
Sure, someone could do a distribution with everything "old" except firefox. Still, some people would complain, because there is the new kde, etc. And if this was so easy, someone would have done it already.
The truth is that the only way to do it is to use something like gentoo ( DIY distribution ), and I see few people doing it. So either the drawbacks of gentoo are not enough to convince people to use it, even if binary one do not satisfy them, or the vocal minority is just that, a minority.
Changes and complaints Posted Feb 24, 2012 0:11 UTC (Fri) by khim (subscriber, #9252) [Link] No, that's designed of "everything must be of a specific version", which is the only sane way of designing it without having a combinatorial explosion. Well, there are another way: actually build interchangeable components. Create some kind of "core OS" and make sure other subsystems don't share anything. This is how it's done in other OSes, after all. ie, how to test that you installation is good for kde 3 and 4, for gnome 2 and 3, with and without specific part, be it new and old xorg, with or without pulseaudio Well, OS exist to give users the ability to run the software of their choice. If it can not provide this capability even for small subset of the available software then something is most definitely rotten in the state of Denmark. Sure, someone could do a distribution with everything "old" except firefox. Still, some people would complain, because there is the new kde, etc. And if this was so easy, someone would have done it already. True. It's not easy. Does not make the problem any smaller. Either you need the ability to "pick and choose" or you need to actually make upgrades smooth and unnoticeable. No GNOME3 or KDE4 "revolutions". The truth is that the only way to do it is to use something like gentoo ( DIY distribution ), and I see few people doing it. Does not work either. Gentoo allows you to toggle different knobs. But different version? Nope. You can push some packages back and forth - but to very limited extent. Even mix of x86 and ~x86 is often problematic!
Changes and complaints Posted Feb 23, 2012 19:32 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
hmm, I do just this very easily on Ubuntu, I install the PPA for firefox and it gets upgraded frequently to the latest and greatest, while the rest of my system remains the same.
I don't choose to use Unity or Gnome, and I find the KDE desktop to be consistent enough across the updates to not be an issue for me. I guess I don't use enough "Desktop Features", even the early 4.x versions weren't a real problem for me.
Changes and complaints Posted Feb 23, 2012 19:55 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
> Would I be able to run the latest Firefox on Debian woody? I hardly think so.
Not sure about Debian, but I personally run CentOS5 and download the latest Firefox right from Mozilla and run it with very little hassle... (I had to obtain a newer libstdc++ than the system one, and place it in the firefox install directory... Which, granted, an average user isn't going to want to do, but it CAN be done, at least...)
|
|||||||||||||