How many would it take for there to be only ONE!!

Every Linux distribution seems to have it's own set of unique packages which identify it from others. It doesn't matter which distribution it is, the situation is true for all of them. But what would happen if a number of users starting packaging those applications (often for configuration) on their own systems, but intended to be run on another? How many unique packages are there in existence, that if all of them were combined, there would be ONE system with the power of all the separate distributions?

Of course, there would have to be a target chosen for doing this. And I'm going to suggest a target out of my own familiarity, and for it's universal packaging system. By universal, I mean it doesn't require anything not already provided on most other systems. So think about this...

Slackware has always used standard tar files for it's packages. Consequently, you only need to untar those packages in your root directory for them to be installed. That's exactly how I first started running Slackware. I did it from a system with package database which I had so thoroughly broken, that I needed something to recover it. Slackware became my rescue system. I installed it like a parasite, but with the purpose of healing, not inflicting damage.

One of the nice things about Slackware, is the fact it's packaging tools are all bash scripts. You don't need anything other than tar, gzip (now xz) and bash to build and install Slackware packages. Things simply can't be any easier than that. Provided that you have the Slackware pkgtools (package) installed on your system (by simply untarring it in your root directory), you could run any SlackBuild (the scripts often used to build Slackware packages) on any Linux system.

So what packages does your distribution have that could be recreated for Slackware, providing the full functionality of the original build system on our new target system? Would you be willing to try, just for the fun or curiosity of it?

Shingoshi

That would miss the point of WHY there are so many distributions.

Some of these are commercial. Novell (Suse) and RedHat would have no interest into combining into ONE unless it was THEIR one. Fedora was create specifically to mollify the folks that were annoyed at RedHat for taking away the non-commercial distribution.

Oracle created its own Linux because it says RedHat's lifecycle doesn't fit them well.

CentOS was created because people wanted non-commercial installs of what is in RedHat but didn't want to be bleeding edge like Fedora.

Some of the reasons are philosophical/political. I wasn't able to get motif for Fedora because of Fedora's philosophy but it comes with RedHat. For Fedora I was able to get lesstif as it does fit their philosphy and provides the libraries that motif would have provided.

Other distros do things like rename FireFox as IceWeasel due to their philosophy.

Some are religious. Most of those who use the package management in Debian love Ubuntu and other Debian based distributions whereas folks like me much prefer RPM/YUM.

Even within distributions two different installations might not choose the same packages. Imagine the difference in what you would want on a server designed solely for DNS as opposed to a corporate mail server. The packages you choose for a system you plan to use as a personal workstation might be completely different than one you intend to put the company's production database on.

OpenSource = Freedom

I daresay most Linux folks would hate the idea of ONE distribution.

Also imagine how big that distribution would have to be to incorporate all the packages. You'd HAVE to choose some over others at which point you run up against the religious debates. If someone told me I had to have emacs instead of vim I'd puke. Other "true believers" in emacs would call me an apostate.

I was simply opening this up as a point of discussion. And I'm interested in individual users, not the corporate excuses for open-source. But as far as those corporate interests go, there are the following:

SuSE has YaST and a number of other tools which distinguishes it from others. It also has unique cluster tools others don't have.
Redhat has many configuration tools. Some of which are specialized for things like clusters.

And then there's the issue of customized kernels, like those used for running clusters (my special interest here). In the past, I repackaged the openMosix kernels to run Slackware. But now, there are others which are attempting to replace it. But they're intended to run on the systems that created them. Same is true for many Debian packages (the creation of which I find to be a nightmare). Debian, with all of it's convoluted dependencies, makes it almost impossible to build their packages on any other system except Debian.

And you bring up the perfect example of renaming packages arbitrarily. That stands as a purely artificial contrivance and has no bearing upon the usability of any system, except to isolate it from the others. My basic premise is that no package should be renamed, unless it is for the sake of continuity. An example would be my renaming libg15 to g15-lib, so that all of my packages for the Logitech G15 keyboard are grouped together by their prefix (g15-*).

And now that you bring up the issue of naming, I would like to see all of those numerous Gnome packages installed under a single directory named, what else of course, but Gnome. Then every package would be installed with their dashes/hyphens changed to slashes, creating subdirectories for each package under the main Gnome root directory. But that's just me. I don't know how many if any others have thought of the same thing. I just hate seeing a single directory consumed by packages all starting with the same name. I think the name of any project should preface any other identification used for packages created for that project. Less confusion.

But then, maybe I would be breaking my own rules here. It's just something I wanted to discuss openly for group consideration.

Shingoshi

I think to a certain extent, perl and python are perfect examples of good organization. I just wish others would follow that example. Subpackages should be handled like modules, all children of a single master package.

Shingoshi

There is to much variety in the way distros set them self up to make it possible. Not to mention the decision to include Gnome, KDE, or both. The tool chain, kernel version, and core system services can seriously throw things out of wack if you try mixing packages.

Originally Posted by lumak There is to much variety in the way distros set them self up to make it possible. Not to mention the decision to include Gnome, KDE, or both. The tool chain, kernel version, and core system services can seriously throw things out of wack if you try mixing packages.

1.) Do we really have to limit the user's choice as to what applications they may want to run?
2.) How much better would it be to have a single build environment for all of the packages provided by the distribution?

The second point is the one I'm really concerned with, as I'm attempting to build just such a computer, as a community resource for all the developers of the many projects provided. That's where my attention is directed now. That's why I'm building such a powerful computer as the one I'm working on now.

All of the projects supported by the distribution would allow their developers remote access to build and test their packages in a common environment. Ensuring that there are fewer problems experienced by the end user. That's my personal goal. Putting my money where my mouth is, so to speak.

Shingoshi

I'd suggest you start on something a little simpler.

World peace comes to mind!

That said, your points are not without merit.

Rgds

Originally Posted by billymayday I'd suggest you start on something a little simpler. World peace comes to mind! That said, your points are not without merit. Rgds

I have never been known for thinking simple. It has never been a part of my being. I am a "what if" person. I think of what's possible, and then how to go about it. It's something I find to be the most entertaining of all. That having been said. Take a look at my blog, and you'll get a better idea of who I am and how I think.

I think to live, I live to think...
Shingoshi

Maybe you need nix. I keep meaning to put aside some time to look into it more.

Originally Posted by syg00 Maybe you need nix. I keep meaning to put aside some time to look into it more.

This is a concept that I've discussed with others. It is something that has always made sense to me. It doesn't make any sense at all to break dependencies of other packages, simply because another package is being updated.

That's about the worst example of collateral damage that I can think of. And with the presence of very large disks on the market now, there's really no excuse for not doing this.

Keep in touch with me! This is something we can explore together, and communicate about our results. I think it really is worth the effort.

Shingoshi

Originally Posted by Shingoshi This is a concept that I've discussed with others. It is something that has always made sense to me. It doesn't make any sense at all to break dependencies of other packages, simply because another package is being updated. That's about the worst example of collateral damage that I can think of. And with the presence of very large disks on the market now, there's really no excuse for not doing this. Shingoshi

Iafter close to 15 years of working with GNU/Linux I can say that :
1. part of freedom mis to make various distributions including messy and buggy ones
2. if we do want to help others to USE distributions than we come to the issue of functionality which is not always so colorful although presence of messy code and bugs may be quite disturbing but inspiring too.
3. I think that distributions should offer framework for people to use packaging in a much easier way and solution that you proposed is something that it is really worth to try.
4. Packaging (and not only packaging) should not be a part of exclusive identity of distributions. That "exclusive" approach without alternatives is a place where freedom may disappear.
5. I would suggest more work on the development of solutions and need to provide frameworks so people can really USE those distributions in a more efficient way. I guess corporations such as Novell and RedHat would like that.


Thanks,

veki

SuSE has YaST and a number of other tools which distinguishes it from others.

A perfect example of the "religious" arguments I was discussing. You think YaST "distinguishes" SuSE whereas an RPM/Yum afficionado like myself would say it has no value.

Funny that I mentioned commercial reasons as only one of the reasons for different versions and you responded to that and ignored all the other reasons which aren't commercial.

Also your argument that people's choices are being limited is specious. Since it is all open source people can compile in and use whatever they want. I'd argue that it is YOU that is trying to limit people's choices by forcing us all into one distro model.

Luckily the very nature of Open Source software insures you'll never succeed in your quest to make the rest of use what you think "distinguishes" YOUR preferences.

Try compiling YaST on any system other than SuSE, and you'll see how dependent it is on the environment in which it is intended to run.

And I don't know if you were speaking to me or not. But you were the one who mentioned a NEED to choose between multiple applications of similar functionality. KDE vs Gnome. Vim vs Emacs. I don't think there needs to be any decisions made by the distribution itself. I think it should be left entirely to the user.

Shingoshi

Try compiling YaST on any system other than SuSE, and you'll see how dependent it is on the environment in which it is intended to run.

Not being a user of YaST I can't say whether it is dependent on the environment in which it runs. For Yum and Apt-Get what you can get is dependent on external sources (repositories) and I'm guess YaST is too and your complaint is that no such repositories exist for distros other than SuSE. The freedom here comes in the fact that anyone (including the person that bemoans the fact they don't exist) could create repostiories for those other distros. There ARE people that prefer the Debian type of package management and make it work for distros designed for Yum/rpm.

It was certainly me that suggested putting every possible package in every possible distro would require more than the 10-15 CDs or single DVDs they currently ship on. I was arguing that one has all the freedom in the world to do what they want. However some things require others to agree with them and when they don't another distro is apt to be born.

There are literally thousands of different packages and no one needs or wants all of them. Given that - one has to do paring which means someone is making THEIR choice which might not agree with MY choice and neither of those may agree with Billbob's choice. Off the top of my head I can think of 3 different vi implementations and two different ksh implementations I've used on Linux and would guess there are more. Those are all just within the "species" of app if you will. Expand it to "genus" (e.g. editors and shells) and the choices become nearly boundless.

In that taxonomic model we are probably doing the "class" of mammals at present. Trying to push all that back into a single species is a losing cause.

I realize that the size of any comprehensive system that would be "shipped" would be exceedingly large. That's absolutely correct. But I think any distribution could ship a smaller core set of packages, including only those to boot the computer, while also having bash as the default shell, providing links for a text based browser. Essentially, you only need what is required to get the system running, followed by the means to select and install the packages you want. If it were determined that X was a necessity, then Xfce could be included explicitly for it's small footprint on system resources. Basically, it would kind of like getting a library card. You don't get all of the books in the library, only the layout of the library showing where everything you might want can be found.

And as far as handling all of those numerous variations on individual packages, that can also be easily handled. Gentoo has a function for emerge which uses deltas to only make the changes that occur from version to another. The result is significantly smaller downloads, and less global network traffic. That same technology can be used for selecting which features any user would want in any package. You would only need to apply the patches providing those features, to the exclusion of those you don't want. And you could also remove any set of features as well, by the same means. The extent of choice would be much greater than it is now, with less justification for having so many distributions.

The choice of the user, would exist in the package manager. I'm going back to my experience with FreeBSD here. They used to install a system with nothing more than two (yes 2) floppies. Now they may be a bit more. But with those two floppies, you could completely configure your system hardware, and then select which packages you wanted to install. Of course, everything was done over the network. So you needed a network connection to start with. However, they also provided a set of cds as well.

If any distribution were to use the delta method, you would only need the basic source of any package. Even if you don't want to compile packages, the compiled packages can be patched as well. So there's no excuse for not doing this. Install the basic package and then run deltas against it to install any additional features the user would want. From that point on, the specialization would be provided by the package manager. That's just how I think things should be done. And you would have much more choice in the end.

Shingoshi