Linked by Thom Holwerda on Mon 7th Sep 2009 22:38 UTC, submitted by EvilWells
Debian and its clones Developer Frans Pop, author of debtree, posted an article showing the evolution in size of the GNOME desktop environment in recent Debian releases. The picture he paints isn't particularly pretty: the default GNOME install has increased drastically in size over the years.
Thread beginning with comment 382797
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by kaiwai
by cjst on Tue 8th Sep 2009 15:36 UTC in reply to "RE[2]: Comment by kaiwai"
cjst
Member since:
2009-03-30


" We don't need leaders and heavy organizations, community driven model is much better


Which is why the community-driven model has resulted in such a rat's nest? We really do need someone to take the rains and say to all the developers: "This is where we are going, if you don't like it go code somewhere else or start your own project." A thousand people pulling in a thousand little directions is precisely the problem. They need to lay it down and stick to it.
"

Note also that Linux kernel development doesn't work this way either. Patches that don't adhere to the (high) standards of the Linux kernel get rejected, and there's a leader namely Linus.

Distros should do the same. Reject apps/libraries written in exotic languages, with exotic dependencies, not modular or fork them.

Reply Parent Score: 1

RE[4]: Comment by kaiwai
by darknexus on Tue 8th Sep 2009 18:29 in reply to "RE[3]: Comment by kaiwai"
darknexus Member since:
2008-07-15

Exactly. The community development of the Linux kernel works well because there is a leader who is willing to stomp on a few egos to get the results he wants. Distros really aren't the problem though, it's the upstream software in general that has the issues for the most part. Sure, distros can patch the heck out of it and maybe apply a Linux kernel-like model to such patch submissions, but that doesn't get to the root of the problem: the fact that most of the software is simply not tested the way it should be and the developers having little interest in fixing bugs that they don't find important. It's all well and good if someone in distro x starts patching it, but then distro y may do so in an incompatible way and before you know it we're even more fragmented than we were.

Reply Parent Score: 2

RE[5]: Comment by kaiwai
by cjst on Tue 8th Sep 2009 19:15 in reply to "RE[4]: Comment by kaiwai"
cjst Member since:
2009-03-30

Exactly. The community development of the Linux kernel works well because there is a leader who is willing to stomp on a few egos to get the results he wants. Distros really aren't the problem though, it's the upstream software in general that has the issues for the most part. Sure, distros can patch the heck out of it and maybe apply a Linux kernel-like model to such patch submissions, but that doesn't get to the root of the problem: the fact that most of the software is simply not tested the way it should be and the developers having little interest in fixing bugs that they don't find important. It's all well and good if someone in distro x starts patching it, but then distro y may do so in an incompatible way and before you know it we're even more fragmented than we were.


I don't think it would create de facto compatibility problems if standards were imposed upon userland software.

Out of my mind, right now there are the following libraries on my system which are duplicated (I spent a some time minimizing the number of dependencies on my system).

libid3tag
id3lib
taglib

gnutls
openssl

libmcs
xfconf

libmpg123
libmad

cdparanoia
libcdio

mac
ffmpeg

audiofile
libsndfile

libarchive
libzip

libexif
exiv2

libdownload
curl
libsoup

libgsasl
cyrus-sasl

gstreamer
xine

* other misc. cruft:

boost

* some more are being worked on as we speak

thunarvfs
libsexy
libglade
gtk+

It's just crazy. I bet I'd be using less than 64Mb of RAM at bootup after one of each of these is decided upon.

Reply Parent Score: 1