Saturday, July 17, 2010

Birth of a new Distro, Part 1: Dependency Overload or NeoDependency Hell

I am by no means an expert on operating systems. But I do use them.  I have used various systems, from Windows, to GNU/Linux, and to the three major flavors of BSD.  I have used many distributions based on the major players in the Linux world, and the few flavors of distributions based on the *BSDs.  Each one has positives and negatives.  And, like a good tool box, each works well when it's implemented where it works best. 

Recently, though, I've been playing with the distro (distribution) that I use daily, Ubuntu.  I noticed while trying to remove apps (software applications and, here, libraries) I don't use, the uninstaller wants to remove either my desktop environment (de) gnome, or wants to remove other apps that I use often.  This  issue is common across many distros of Linux, at the least.  I am unsure about *BSDs, as I did not notice at the time I operated those systems.

This is a new dependency hell.  At one time, dll hell and rpm hell were well known.  In those instances, different apps needed different versions of a library while on the same operating system.  Now, the hell is removing these apps, which now want to also remove major parts of the system.  Along with this dependency removal hell is the dependency overload on installation.  Many applications bring in large amounts of dependecies (and, in Debian, even recommended apps).  The term should be dependency Overloading (DO) or NeoDependency Hell (NDH)

Dependency Overloading seems to occur more often in distributions that focus on binary packages.  Compile based systems would only need whatever software is required to compile a package.  These systems require a local build environment, which sometimes requires as much space as NDH binaries.

The compiled system would also build packages according to the local system, instead of vanilla packages meant to run on various hardware.

Again, I am no expert.  Even though I have ran compiled based distros, such as Gentoo, I ran them in a time that I barely understood the system, so I cannot fully comment on their installation or removal processes.

Now that the Kernel can ID much of the hardware, and, with the help of scripts, can dynamically load modules per system, it is time to leverage this detection mechanism with one of the greatest ideas release into the open source community, the Live-CD/DVD.  The marriage of a live environment not actually running on the host systems hard drives (hdd) and the great detection mechanisms built into the kernel, a compiled system could be built lean, installed clean.

A newly installed system via the live compile method would require less hdd space.  Since the introduction of large gigabyte drives, the mantra has been, "why worry, we have the space," which also goes along with the RAM manra of, "if memory is too small, we can cheaply add more."

These two mantras are attributing to the bloating systems of today.  Data should be the focus of hdd space use, not the operating system.  No more ram than necessary should be used, whether the requirement is 8MB or 8GB.

I was lead down this road while simply trying to install a small LAMP web server that would only serve a few pages.  But some of the simplest solutions required nearly 2GB hdd space, yet only needed about 80MB of RAM.  Since my server would be dedicated to doing one thing, not being a desktop requiring uninterrupted multimedia playback, why did it require nearly 2GB hdd space?

I searched for an implementation that could fit into less than a few hundred MB on a hdd.  I found TinyCore and a Puplet (a GNU/Linux Puppy distribution community derivative) conveniently called, WebserverPuppy.  While TinyCore did not have any type of web server installed by default, the entire OS is a less than 11MB iso(CD/DVD image) file.  WebserverPuppy requires under 75MB.  The issue I have with the Puppy version is something that Puppy has always used, root only.

I would rather my server not be run in root mode.  TinyCore (TC) has both user and root modes.  I also found that binaries installed on TC required minimal dependencies.  But one that bothered me was a dependency of MySQL, PHP.  While I intended on installing PHP, having it as a dependency of MySQL didn't settle well with me.  MySQL does not require PHP to function, so such a dependency is NDH to others that don't require PHP.  Now, I have to question every application available for install on TC, does it have NDH

Inspired by these two light distributions, I set to find a distribution that does not have DO.  None have caught my eye.  So, if you know of a distribution that has excellent hardware detection in the Live-CD/DVD environment, installs light, and has no Dependency Overloading, let me know.

Otherwise, I am beginning work on a new project that at least will be able to successfully detect all hardware in a live environment, compile or install binaries per the detected hardware, yet be light on the hdd and in RAM.  At this time, this experimental project is called Jet-Fu, Just Enough To FUnction.

Whatever functionality is required, this distribution should only fulfil the requirement, no more, no less.

No comments:

Post a Comment