> That is certainly an issue. On the other hand: > > free: > total used free shared buffers cached > Mem: 3114664 794856 2319808 0 57404 404636 > -/+ buffers/cache: 332816 2781848 > Swap: 4032304 0 4032304 > > I've got the RAM (*). What I don't have time for is dependency > hell. Which at best costs me hours at inopportune times, and > at worst means deleting applications that I've invested data in. > All my apps should not be so tightly bound together. That makes > my system too fragile.
Keith, Certainly dependency management can be difficult, but consider the fact that every distribution has to support the libraries they release. Each time a vulnerability comes out in libfoo, they'd have to back patch it in every version of the library. If they try to support some old version of libfoo that even the upstream developers don't support anymore, then that can lead to huge headaches for the distribution's maintainers. Instead, users are free to install their own libraries and manage their own legacy dependencies if they wish. For instance, with Debian-based systems (and likely others, which I can't speak to) it is also relatively easy to build your own backports from the Debian source packages and host your own apt server that lets you manage those dependencies yourself in the way you want, overriding the builds of specified packages in the mainline distribution. <rant> And finally on the topic of memory consumption, even though this is a small piece of the issue, I regularly run up against memory limits on my 2GB desktop. Yes, I am planning on buying more RAM, but it seems that every application likes to assume they can use as much RAM as they want because it is so cheap now. I run *lots* of apps at once and regularly have to fight with those apps that are memory hogs simply because the developers are too lazy to think through what really needs to be in memory. Note that using more memory than I have available is bad enough, but it also leads to computation bottlenecks in modern systems. The speed of memory continues to diverge from the speed of CPUs. The more useless junk you store in memory, the more you blow your CPU's cache on pointless garbage and the more time you spend loading and accessing stuff from RAM. It still makes sense to design software around not using too much memory, particularly in an age where everything is going mobile. </rant> Now, with all that I've said in favor of the current model, I do feel your pain when it comes to using particular groups of software packages. Many of the libraries supporting Linux GUIs are incredibly fragmented with many ugly interdependencies. I am not a GUI developer, but I suspect many Gnome and KDE libraries implement duplicate functionality throughout the code, even within their own projects, because they don't organize the code well enough to provide good code reuse. Consider the X11 clip board vs the Gnome/GTK/etc clipboards. I don't know what all standards and APIs exist for this, but I do know it is an utter pain in the ass to copy and paste text between different applications on my system. My preferred terminal program, urxvt, supports traditional X copy/paste (select the text to copy, middle click to paste) which I really like. Most other applications on my system also support this style of copy/paste. However, recently i've noticed Java GUIs do not support this (anymore?). I can't copy from my terminal and paste into Java apps, and since uxrvt doesn't support Windows-style 'CTRL-V' for paste (as it is a terminal that interprets this other ways), I can't paste from Java to urxvt. Apps like Firefox support both methods of copy paste and OpenOffice.org seems to change its policies on what kinds of copy/paste it supports with every minor release (sometimes pasting web page text as simple text, other times pasting it as formatted text, and this is different between CTRL-C copies vs X11 copies). It is just brain-numbing and foolish that this stuff isn't better standardized. Surely this clipboard complexity comes along with weird library dependencies, according to what apps support what methods. Overall this is just a sign of bad design though, rather than a fault of the distribution's maintainers do keep supporting multiple releases of the bad designs. Regards, tim _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
