Toward a New Kind of Linux Distribution
An anonymous reader writes "Progeny co-founder Ian Murdock wrote a weblog entry that has been reprinted at Newsforge. He talks about how current distros are built from the top down, making a 'one-size-fits-all' solution of technology. He proposes making a modular solution that encompasses building modules so distros can include only the technology they need to suit their purpose, kinda like building from the bottom up. Interesting read, good arguments, potential for a new Linux community."
Progeny co-founder Ian Murdock wrote
Wouldn't it be worth mentioning that he is founder of Debian as well?
Note to self: get smarter troll to guard door.
Many options are selected at compile time, rather than in configuration files, for instance processor selection. My php configuration includes "--with-mcrypt --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir". The number of different downloads for any pre-compiled distribution will be enormous.
Rock Linux isn't a Linux distribution: it's a distribution build kit, that allows you to build your own tailored distribution from sources, with your choice of configuration options.
Even if there aren't currently the options that you want, the simple text-mode configuration files allow you easily to add your own.
They started by making products designed for single roles, with a database server, a groupware and messaging server, and a fileserver.
Modularity is great for large organizations, but at this point it would be foolish to fall into MS's line of thinking, that you need a separate server for each role in the industry. It would behoove us to try harder to break down the barriers between servers so that they can act in a cohesive, stable and seamless fashion, whether there is one server, five servers, or five thousand servers.
And that's why we need a stronger LVM!
Interesting. I'd always felt that this is how Linux really works the best., rather than being a giant 1 gig hunk of software, I can pick and choose the parts I want to play with. This leads to lots of mistakes early on, but over time, you learn how to optimize and reevaluate what you need and where, with the end result of understanding your system that much better. So my question is: Was this a suggestion for Linux in general, or a suggestion for a new type of business model?
His idea sounds very close to Morphix. It allows easy building of customized live-cd distributions. It supplies its own installer too.
But isn't/wasn't this what BeOS intended to do? On the one hand it would be nice, it would be compact as opposed to having 3! cd's full of stuff, yet at the same time, they'd better have a squadron full of developers who would change things on the fly considering the speed at which things change.
MoFscker
Diversity is certainly a strength of Linux.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Never mind that Ian Murdock is also a founder of Debian, and that Progeny has always been built on Debian; what objective reason is there for building this kind of OS on Gentoo rather than Debian?
First of all, Debian is quite modular and simple. In fact, Lindows uses it behind their "click 'n' run" front end, and its supposed to be amazingly smooth. Debian can be used for more finely grained options, but can also be used for a modular system as described Murdock.
Plus, lets be honest; source distributions just aren't going to cut it in an environment where package installation speed is important.
There is mkcd, which allows you to create custom Mandrake CDs with the software and options you want.
And mandrake has a customizable auto bootup/install via drakx (mdk's installer system).
Add all of the above, and a little knowledge about SRPMS (if you want true customization), and it works rather well. Also Mandrake's public download edition is 100% FLOSS, so there are no issues about redistributing the software (unless *you* add some non-FLOSS stuff on your own, heh)
Sunny Dubey
This article is by Ian Murdock, who is the Ian in Debian. The logo isn't there because of a direct relationship to the subject of the article; the Debian logo is there because of a direct relationship to the author.
Notice that his current project (Progeny) is about companies looking to build on a 'distribution neutral platform', and the link in the article goes to a page about 'Progeny Componentized Linux.' Believe or not Gentoo is not the only highly configurable linux game in town: Progeny seems to be playing that game, but at the enterprise not the consumer level. He's definitely not thinking of Gentoo for this role. He's talking about Progeny.
I think PLD (Or in English) tries to be highly modularized:
no restrictions for a set of packages that must be included in the distribution. The user can have access to every package already prepared for PLD. If something had been prepared in conjunction with other packages, it means somebody did need it, and maybe someone will need that package in the future
Now, this is not to suggest that PLD does this well, or that it does this actually implements what Progeny is suggesting, but it's still a starting point.
People keep saying "should be done like Gentoo" or "Debian is like this".What Ian is trying to say is everyone needs to cooperate on this and build a framework which all distros can use.
In my eyes one of the problems Linux has is libraries and their versions. you can't simply take an executable and guarantee it will run on another Linux installation (unless you statically link).
After my first stage 1 install of Gentoo I felt the same way. This is a lot of fun but and great for desktop but i can't administer 80 boxes like this. After using it for a few months I fell in love with how well it works and I have used RedHat, Suse, Debian, Slack and others.
So I decided we would try it at work. We made a master build server, shared the portage directory through NFS, made a few scripts and standardized config files and now setup is only slightly longer than RedHat was. Our install documentation is not any harder to follow and it looks like upgrades and patches are going to be a lot easier as well. And we don't get the hell of some servers running 7.1 some running 7.3 and the the two new ones on 9.0 and lets keep all there different upgrade rpms around.
SuSE Linux is mostly what you describe.
But indeed this is what is required for a desktop Linux.
No toolkit of modules, but a standard install that sets up a standard Linux installation that can be made user-friendly, can be well debugged, can be optimized w.r.t. parameter settings, etc.
The point of Gentoo is that using the source for installation allows much finer grained dependency resolution.
For example, take vim. Depending on what you have installed, it may or may not have Perl integration, Python integration, an X UI, ctags support, make or ANT integration, and so on.
A binary distribution needs to provide a different binary for every possible combination of those, if it's going to allow fine-grained choice around what the Linux system has installed. Either that, or you have to turn off a lot of functionality which could be turned on, in case the dependencies aren't installed.
With Gentoo, the binary's dependencies are determined at install time, so you can have a single package which supports all the possible combinations of other components the user might have chosen to install. If I have Perl but no Python dev tools and opted not to have Python integration, no problem, vim is built appropriately from the same package everyone else is using.
In practice, the binary distributions seem to provide only two versions of vim, a "minimal" terminal-only one, and an "everything, including X" version. Personally, I don't want either of those--I want most things, excluding Python and X. Gentoo lets me have that, Debian doesn't because it doesn't have a vim-perl-ant-make-nox-nopython package.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
My organization is standardizing on it for critical servers, and I think it does a lot of what this article talks about. On install, it asks which services you want to run ... and it ONLY installs what is absolutely necessary to run them. It's pretty lightweight, but gets the job done. And it's also hardened like you wouldn't believe, with most services preconfigured to run in a chroot() jail, something the others should have been doing from the start IMHO.
Website
Because Gentoo isn't well-tested, QA'd and enormously reliable. It's a playpen for the latest bleeding-edge goodies. It's not ultra stable.
Wrong. Please troll again. Gentoo is much much faster in some cases.
However, once the app is installed, it is much faster than the generic i386 cruft you get from normal distributions
Hmm, I don't think so: Debian News mentions a Debian package being faster thanks to O2 instead of O3. Now this has nothing to do with Gentoo as a distro, but are you aware of the best settings for every package you install?
Also, quite a lot of distributions compile for >= 586
Nice link, I especially found the quote Can you conclude that "Gentoo is faster than Mandrake?" No. This is a limited test. It is likely that Mandrake is faster for some things. Also, we tested load-time performance only to be informative.
No, I'm not aware of the best settings for every package I install; neither are you or anyone else for that matter. But I am aware that a good compiler + good compile options + prelinking can yield faster performance on the average. That is what Gentoo offers.
Great! The more the merrier. However, as a binary distro becomes more mainstream, optimizations become less and less of a option (especially for commercial distros where support costs are a real concern). GCC allows for some fairly fine grained compile options, if that is your choice. That is the main strength of Gentoo; a user has as much choice and freedom to tweek the software as (s)he wants.
The power of Rock isn't in installing a single package, built from source, on your system, though it can do that.
Rock allows you to create your own bootable CD from which you can install your own custom Linux distribution.
1) download Rock (mostly shell scripts and configuration files, and a *very* small number of patches to packages)
2) unpack it
3) select your configuration options - choose from a range of targets - minimal LAMP server, desktop, or create your own list of packages - select your target processor, and any configuration options you want - e.g. build postfix with mysql support.
Some of these are available as tick boxes in the curses based configuration tool, if not you can easily edit a text file.
4) download the sources you need
5) start build
6) drink beer, sleep, whatever
7) create ISO image, burn to CD
8) boot from CD, use curses based installation and configuration tool to install new system.
When you building a large number of boxes to be shipped to customers, and over which you want total control, Rock is superb. I can strip my distribution down to the bare minumum, and easily apply only those security patches or upgrades to new releases of packages I have tested.
If you call a function many times, it will be in the cache most of the times that it is called. If you do not call it many times, any cache miss that might occur when it is called has negligible performance impact.
Inlining functions will increase code size because some functions will be inlined in many places. Increasing code size will generally increase cache misses simply because it occupies more space in the cache.
Every package management system which supports dependencies (apt, portage, ports, etc etc) will do this. KDE is just a package which depends on all those other packages. In fact this is how it works in the real world anyway: A full KDE3.x environment is made up of such and such libraries, such and such applications, and so on. They just release a new ebuild for the new KDE version, which depends on all the new versions of the component pieces, and when you emerge -u kde all of those packages will be upgraded in order, because the system tracks dependencies. It handles it in much the same way as debian, actually, in that you can make things depend on and provide virtual/foo (for instance vim supplies virtual/editor.) You can also have packages depend on actual packages, with specified version numbers, or you can specify a version >=, etc. Of course you probably know this stuff, but I felt it was worth mentioning here. Anyway apt provides dependencies so debian has the same feature.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
http://www.rubyx.org/
From the Rubyx page:
Rubyx is an operating system, created and maintained by rubyx, a script written in the ruby language.
The script grew out of the need to create highly specialised linux installations for a massive multi-player online game, but has become a viable operating system for general use. It is working and usable (it's running this website) and package support grows daily.
The Rubyx script actually builds your own customizsed distro with pretty-much whatever you want in it.