Applications and bundled libraries

Posted Mar 19, 2010 15:38 UTC (Fri) by dbruce (guest, #57948)
Parent article: Applications and bundled libraries

"It can work for a few hundred packages easily enough to do it the 'apt-get way'. It can scale upwards to several thousands. But to be on par with something like what Windows provides you have to scale to millions and you have a shitload of programs that nobody in the Debian project (or Fedora or Redhat or anybody else) will never be aware of, much less know enough to package and build them for end users.

There is just simply no chance in hell that a centrally managed, closed system like the current package management status quo can ever hope to scale and meet the diverse needs of the average population."

I don't buy that at all. The fact that there are "millions" of Windows programs available (assuming that is even true, which I doubt) just points out the inefficiency of closed-source development, where it is not possible to build on someone else's program without explicit licensing, fees, etc. The "millions" of programs are the problem with Windows, not an advantage of Windows. When I show people a Linux system, they invariably are more impressed by centralized package management than by any argument concerning freedom.

If you look at everything that is in Debian, it is hard to come up with a niche that isn't covered. Some of the OSS programs may lack important functionality, but in principle they could be improved to cover everything that their commercial counterparts provide.

I just don't see any need to provide "millions" of programs. If you have some need that isn't addressed by the ~25K packages in Debian, it probably requires a custom application anyway.

Applications and bundled libraries

Posted Mar 31, 2010 6:30 UTC (Wed) by oblio (guest, #33465) [Link]

Oh come on!

You really think that 25.000 applications can replace millions? No they can't.

First of all, if you look really closely, those aren't 25.000 applications. They're 25.000 *packages* - including libraries (who cares about those?), documentation, meta packages, maybe even development versions of packages (sources).

Secondly, you're forgetting about statistics and evolution. More variation and competition means there's a greater chance of success. Only a small percentage of applications are any good.

Thirdly, for each niche there are many design decisions. Out of 10.000 crappy applications for a certain niche, you'll have 100 decent applications, 10 really good ones, and 3 great ones, each having a different design philosophy (therefore you can't replace great application A with B or C).

Should I write my own "custom" application for everything that doesn't fit that tight collection of 25.000 "applications"? (answer: no, on Windows you find a tool already made for 99% of regular desktop activities)

Applications and bundled libraries

Posted Apr 8, 2010 18:27 UTC (Thu) by wookey (guest, #5501) [Link] (3 responses)

Whilst I am a huge fan of 'the Debian way' of central package management, it really isn't true to say that the current (large) pile covers most areas. There are big gaps in no doubt many areas; I've recently noticed them in two: energy monitoring/control and building design. There are an awful lot of handy Windows apps for things like calculating beam loadings in buildings, and many more for specifying vendor's products like hot water tanks and ventilation equipment. Very few of those are free software, but they probably could be and either they all need adding to the distro repositories or we need a more modular mechanism for installing developer/vendor-supplied apps. I believe autopackage is intended to fill that role but it hasn't been very popular so far (possibly because the internals are pretty ugly). I mention it because no-one else has so far - maybe something like that is worth more effort.

On the energy monitoring front there are plenty of things like mango, diyzoning, owfs and temploggerd whcih are basic apps for this stuff but none are in Debian yet (or weren't last time I looked). No doubt they will be at some point but until then anyone wanting to use them has an installation problem. I tried local building but found this to be very hard indeed for the two java-based apps there when targeting an arm box. Obviously that wasn't something the developers had tried.

I do agree with those who say that developers should not be doing packaging and system integration. They are not well-placed to understand the issue of less-common architectures, complex system interactions and really have better things to be doing with their time.

I am inclined to agree that a bit more modularisation of distro repositories would be a good thing. Ubuntu's model of 'core stuff', 'common stuff' and 'everything else' is a step in this direction. Debian's monlithic tools are becoming stretched, especially on small systems (where the package management overhead can amount to 40% of the rootfs storage requirement). I'm not sure there are 'millions' of applications, but there are many tens of thousands and dealing with that efficiently is a challenge.

One other thing which I don't think has been said loudly enough in this debate is that users really do value stability. The central repository model does provide a lot more of that than the 'install random stuff off the net' model. It really is worth something, and whilst they also value being able to install 'latest' of a few apps there is a real potential tradeoff there which needs to be managed somehow. The users I deal with are _much_ more interested in having a stable system than they are in the latest and greatest. They only upgrade apps when they find they need to for some significant feature. Making that easy and reliable _and discoverable_ for them is where we have much room for improvement.

I find that the Debian backports model works pretty well for this, and could be greatly extended to provide a much larger chunk of the new stuff users want. However it is not a particularly discoverable mechanism - not helped at all by the way many users are used to the Windows model of 'just click here to install this stuff'. There is a significant element of user education to get them to stop and think for a mo and see if what they want is already in the packaging system, or would be if they/it added a suitable repo. Most software websites don't help at all with this, as they encourage the Windows model and rarely mention the 'distro' model.

So, it's a thorny issue, and I agree there is room for improvement, but I also feel that the good part of what we have is very valuable, to everybody, including naive users on laptops, even if they don't really appreciate it. Make it easier to go outside that model by all means, when necessary, but try hard not to just make thing unreliable and/or insecure as a result.

Applications and bundled libraries

Posted Apr 8, 2010 18:41 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

I build pretty stripped down debian systems, and I don't see anywhere near the '40% of rootfs is package management' overhead that you describe. people who install fatter systems would see even less as much of the overhead is constant (there are a handful of files per package, but they are tiny compared to the rest of the package)

Applications and bundled libraries

Posted Apr 9, 2010 13:20 UTC (Fri) by wookey (guest, #5501) [Link] (1 responses)

That stat comes from the fact that the (emdebian-grip) rootfs for the product I am currently working on is about 60Mb unpacked, and after you do your first apt-get update at which point it is about 100Mb. Those numbers are from memory, but the point is that on a small system the overhead is significant. Debian's package list alone is 25Mb, and the package cache is another 13Mb on this box I have to hand. This desktop box has 60Mb of apt cache and package lists. Clearly 60Mb on a 4Gb system is not a big deal at all, and even on a 60Mb system we still find it useful enough that we choose to use it. We used to use ipkg which is enormously slimmer, and necessary if you don't have the storage to support apt/dpkg, but apt/dpkg do work a lot better when things get a little complex.

Applications and bundled libraries

Posted Apr 9, 2010 18:46 UTC (Fri) by dlang (guest, #313) [Link]

Ok, your systems is stripped down more than mine is :-)

if you don't do an apt-get clean after doing the update debian will keep the .deb files of the packages that you downloaded around (in /var/cache/apt/archives)

if you are wanting your product to update directly from debian's public servers then you need to plan to support the large package list (any way for them to split the package list is going to put _someone's_ critical package in an optional repository), but you can run your own repository and only put packages in it that you want to make available to your product. This will also save you time in the updates.

a minor point, I'll also point out that most of this space is in /var, which is not what most people would think of when you said it was in the rootfs