Whooo, I'm back, after a rather long hermithood. In that time, I have learned much of the ways of rpm.
I got roused from hermithood by the latest e-mail from our fearless leader. I sent a rather lengthy reply that was part rant, and he suggested I post it here as well. So here goes:
I remember someone writing an editorial many months ago, bringing up a problem we might not like to admit with Linux: bloat. Seems an odd accusation to level at Linux, but in the process of building packages, I've realized there _is_ a bloat problem.
The bloat problem is tied to shared library dependencies. Libraries upon libraries are stacked up in Linux, and dependencies can easily become a tangled mess.
As an example, let's take window managers. A great many people favor one window manager, and one window manager only. Perhaps it's Gnome+Sawfish. Perhaps it's KDE. Perhaps it's GNUstep+WindowMaker.
The problem is that a lot of the popular X11 applications (Mozilla, GIMP, xchat, etc.) like to tie themselves to certain window manager controls. Imagine the current dilemma:
I happen to like using xchat for IRC chatting. I happen to prefer it over ksirc, even though I happen to prefer KDE over Gnome. Trouble is, if I compile xchat against gnome libraries, I end up having to install some or all of Gnome just to use xchat--even though I don't like gnome all that much and might never use gnome as a window manager, xchat still ends up depending on it. Can I compile xchat without gnome dependencies? Yes, but I lose a few little features like tearable menus.
These are the hard decisions. Do we go all-out, include all features of everything, and make it all a bloated dependency web? Or do we try to keep it where one can install something without installing five hundred other packages he might never use directly?
Quite frankly, when we have several thousand choices, freedom of choice can bury us.
</rant>
Now for a proposal for some form of direction:
Building packages is no problem. That's the least of our worries. At this point, I have enough package-building experience and enough archived packages to hold us well into the next year. Right now, we need to add the stuff that _we_ plan to create.
I say we first start with a simple text-based system, no XFree86, just terminals and a few necessary utilities. Then we start developing our own administration utilities. I had some ideas for a MaxAdmin setup tool built upon the ideas of the scoadmin utility from OpenServer and UnixWare; I say begin with a curses-based version of what we want MaxAdmin to be. We need to start by determining what we want this utility to look like.
I can currently provide a set of RPMs to get a minimal development system up and running quickly. They're currently built for a minimum of i486 architecture; at this point, I believe that's the common denominator we should stick with. Compiling for i586 or above would mainly just be a speed boost; compiling for i486 over i386, though, actually enables some rather critical features related to atomic locking in threads. And honestly, when you can pick up a used 486 from a local computer store for $20, there's not much reason to go with a 386 anymore. The 386 has become completely obsolete.
By the way, do we have any experienced PAM hackers on board? I'd really like to pull in PAM support, but linux-PAM seems pretty broken.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I somewhat agree with you that Linux is currently bloatware, that is unavoidable. Yes, it has dependency issues...so does M$ Windoze -- well one issue that I have run into many times, and that is with the VBRUN*.DLL (where * is the version number) when programs require it -- I can see Linux in the futre where dependencies are not an issue; but that is probably a few years away. Also, I'll be posting on the "Project Help Wanted" board for PAM hackers as per your request.
Michael
Your friendly neighbourhood Founder & Project Manager
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PAM is written in C/C++. The actual tarballs are apparently maintained at ftp://ftp.kernel.org/pub/linux/libs/pam/
One thing about the bloatware aspect is that we're not just competing against Windows--we're competing against *BSD as well, and also other Linux distros.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-11-15
Some distributions will say that they run on a 386. However, you can't do anything useful with it anymore IMHO. I agree completely... we should develop for the higher-end systems only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whooo, I'm back, after a rather long hermithood. In that time, I have learned much of the ways of rpm.
I got roused from hermithood by the latest e-mail from our fearless leader. I sent a rather lengthy reply that was part rant, and he suggested I post it here as well. So here goes:
I remember someone writing an editorial many months ago, bringing up a problem we might not like to admit with Linux: bloat. Seems an odd accusation to level at Linux, but in the process of building packages, I've realized there _is_ a bloat problem.
The bloat problem is tied to shared library dependencies. Libraries upon libraries are stacked up in Linux, and dependencies can easily become a tangled mess.
As an example, let's take window managers. A great many people favor one window manager, and one window manager only. Perhaps it's Gnome+Sawfish. Perhaps it's KDE. Perhaps it's GNUstep+WindowMaker.
The problem is that a lot of the popular X11 applications (Mozilla, GIMP, xchat, etc.) like to tie themselves to certain window manager controls. Imagine the current dilemma:
I happen to like using xchat for IRC chatting. I happen to prefer it over ksirc, even though I happen to prefer KDE over Gnome. Trouble is, if I compile xchat against gnome libraries, I end up having to install some or all of Gnome just to use xchat--even though I don't like gnome all that much and might never use gnome as a window manager, xchat still ends up depending on it. Can I compile xchat without gnome dependencies? Yes, but I lose a few little features like tearable menus.
These are the hard decisions. Do we go all-out, include all features of everything, and make it all a bloated dependency web? Or do we try to keep it where one can install something without installing five hundred other packages he might never use directly?
Quite frankly, when we have several thousand choices, freedom of choice can bury us.
</rant>
Now for a proposal for some form of direction:
Building packages is no problem. That's the least of our worries. At this point, I have enough package-building experience and enough archived packages to hold us well into the next year. Right now, we need to add the stuff that _we_ plan to create.
I say we first start with a simple text-based system, no XFree86, just terminals and a few necessary utilities. Then we start developing our own administration utilities. I had some ideas for a MaxAdmin setup tool built upon the ideas of the scoadmin utility from OpenServer and UnixWare; I say begin with a curses-based version of what we want MaxAdmin to be. We need to start by determining what we want this utility to look like.
I can currently provide a set of RPMs to get a minimal development system up and running quickly. They're currently built for a minimum of i486 architecture; at this point, I believe that's the common denominator we should stick with. Compiling for i586 or above would mainly just be a speed boost; compiling for i486 over i386, though, actually enables some rather critical features related to atomic locking in threads. And honestly, when you can pick up a used 486 from a local computer store for $20, there's not much reason to go with a 386 anymore. The 386 has become completely obsolete.
By the way, do we have any experienced PAM hackers on board? I'd really like to pull in PAM support, but linux-PAM seems pretty broken.
Well, I somewhat agree with you that Linux is currently bloatware, that is unavoidable. Yes, it has dependency issues...so does M$ Windoze -- well one issue that I have run into many times, and that is with the VBRUN*.DLL (where * is the version number) when programs require it -- I can see Linux in the futre where dependencies are not an issue; but that is probably a few years away. Also, I'll be posting on the "Project Help Wanted" board for PAM hackers as per your request.
Michael
Your friendly neighbourhood Founder & Project Manager
By the way, what language is PAM written in, so that I may add requirements to the posted job?
Michael
PAM is written in C/C++. The actual tarballs are apparently maintained at ftp://ftp.kernel.org/pub/linux/libs/pam/
One thing about the bloatware aspect is that we're not just competing against Windows--we're competing against *BSD as well, and also other Linux distros.
Some distributions will say that they run on a 386. However, you can't do anything useful with it anymore IMHO. I agree completely... we should develop for the higher-end systems only.