Slashdot Mirror

Gentoo's great, if you have a Pentium-or-better machine (for the partially-built distro) and a bootable CD-ROM. Don't even bother if you can't boot from CD, and good luck if you try to do a "live" install from an existing Linux installation. A good alternative is LFS, which accomplishes much of what Gentoo has set out to accomplish but without all of the superfluous extras. More importantly, LFS is meant to be built using an existing (if possibly broken) Linux platform. If building a Linux system from scratch is what you're looking for, LFS certainly delivers.

I guess that a side effect would be for the /usr/bin directory to become composed entirely(?) of links. Still, I've done that already when trying out a new version of Python, and it didn't seem to cause any problems. (I suppose that the other bin directories probably wouldn't be affected that way. Especially /bin and /sbin, since they might be needed when other partitions weren't mounted.

I run a system based loosely on Linux from scratch, which adopts a link farm approach like you describe. My /usr/bin (and /usr/blah directories generally) indeed do have hundreds and hundreds of symbolic links. This probably impacts performance, but I've not noticed it on my K6-3/400 PC with old slow IDE disks. Using some simple perl scripts to create, retarget and clean up symbolic link farms, package management is simple. The key benefit is that the metadata associating a file with its package is the symbolic link itself - it is logically incapable of becoming out of sync.

My work-around for the root file system is as follows. Each package I keep in /usr/pkg/packagename-version. Things destined for /usr/bin live in /usr/pkg/packagename-version/bin and so on. Things which need to end up in (say) /sbin live in /usr/pkg/packagename=version/root/sbin. I cp -a the contents of these root subdirectories into /.

This mechanism is a comprimise, but works quite well. I can compare files in root fs directories against those in /usr/pkg/*/root to find which file came from which package. Updating is a simple cp -a.

Why not do the same for /usr, and avoid the symbolic link farms? Primary reason is that while copying into the root fs those files that need to be there might take up 30MB or so, doing the same for /usr would mean an extra 500MB or more of duplicated data. The other reason is that for those packages which aren't too tied to their location in the filesystem, differing versions can be present on the system simultaneously.

Time required to load Red Hat on a P3 workstation - 5 minutes...

Sounds like it's time to dump Redh*t. LFS on a Celery 433, with Apache, Samba, Squid, OpenSSH, and qmail added, takes maybe half a minute (if that) from end-of-POST to login prompt. Even if it was configured as a workstation (with X) instead of a server (without X), I doubt that it'd take anywhere near 5 minutes to load up.

SuSE makes their distribution available to be installed via FTP, but their download site it so slow that it usually doesn't work.

That's why they have mirrors...you can install from those, and they're usually fairly quick. (That said, I usually build Linux From Scratch. You need an existing Linux system to kickstart the LFS build, though, and SuSE is what I used before LFS.)

RedHat 7.1 is the OS that convinced me to give up Macintosh. I loved it as a desktop machine.

That said, I'm currently running Debian on my work machine and one of my home machines because I enjoy the ease of upgrades. My absolute preference is to compile everything from scratch.

Other good ways to learn linux:

Gentoo: the portage package management utility is based off the BSD ports system and downloads, compiles, and installs programs instead of using binaries for increased optimization. The only graphical configuration tools are the ones the user 'emerges' using the portage system. Much like Slackware and Linux from Scratch, you have complete control over your system.

Linux From Scratch: step-by-step instructions to compile your very own Linux from the ground up. Excellent docs that are worth a read even if you don't decide to install it.

I made a Linux From Scratch install a few years back to learn about linux. What I ended up with after I'd got everything exactly how I wanted was basically slackware without the packaging system. Now ima slack junkie :)

I'd highly recommend trying the LFS project if you wanna learn about linux. The list of world mirrors for the site is http://www.linuxfromscratch.org

I'll say this. Because of Slackware's "raw" way of doing things, Linux isn't really as intimidating as it once was when I was but a newbie. Redhat's RPMs were nice, but I always wondered where everything was going, what it was doing behind the scenes, etc.

Having used Slack, that mystique is gone, and I'm okay now with the basic internals of Linux. I just grew comfortable with it since Slackware exposes it all. Hell, I'm even toying with doing Linux from scratch. As someone pointed out before, Slackware is one of the best ways to truly learn Linux.

A few years ago, I installed Slackware on a spare box and thought it was a nice distro. As you said, this is really nice if you want to learn how your OS works rather than just using it.

I don't use it anymore because all of my boxes (including my server) are running linux from scratch which while being much longer to setup (especially the first time), it is the ultimate learning experience. Everything on my workstation was compiled manually by me, including the shell, the compiler, X, etc...

One good thing about slack and linuxfromscratch is that you *know* exactly what is installed on your machine.

Lazy wimp. Go build your own distro.

In all seriousness, LFS is great when you've got a fast spare machine to play with and want to learn about how Linux works (I've got a "play box" just for this purpose), but I love Slackware for when I need absolute stability and resource efficiency. Good for desktops and servers, 486s to P4s. Thanks for the work, Patrick!

-Lx?

Nope, you're wrong. All Redhat installations get the sendmail software installed. Only certain configurations get sendmail turned on as a network service, and this is the "custom" that you're thinking about.

Believe me, a "custom install" under Redhat gives you little control over what software goes on (although, thank god, it does give you at least some control over what network services are turned on). Until you've built your own Linux system entirely from sources you've never seen a custom install :-).

For me, numerous packages is not a selling point. I run Linux because I want precise control over what's running on my machine, whether it be a desktop or a server. I don't want layers upon layers of crud.

Example: You cannot install recent Redhat versions without installing sendmail, because cron needs sendmail, and a redhat install needs cron. But I don't want sendmail. In many cases I don't want cron. If I want sendmail functionality, I'll install something less gargantuan and less cumbersome. And if I want cron functionality, I'll install something substantially cleaner than the heavily-heavily patched Vixie cron that comes from redhat.

For me, the perfect "distro" (it's not even really that) is Linux From Scratch. Complete control over everything!

Anyway, I would suggest that source being available via file-sharing networks would meet the requirement ONLY if that's basically where you got the binaries too...

However, there is an availability issue. If the distribution methods can result in the binaries being available while the source is not, there is a problem. Simplest solution would probably be to bundle the source and binaries together...

Of course, I only bother with the source myself, ever since I found this wonderful book. ;)

I'd like to see source code shared on such a basis. I wonder if anyone has a good idea for a decentralized version of something like cvs. :P

Mandrake's installer beats any Windows installation hands down (of course Windows users rarely install it, but anyway); if someone not familiar with the Linux vs. Windows FUD were shown the installation of Win2K (for example) and an 8.x Mandrake, they'd simply laugh if they were told that Windows is the "user friendly" one. And RedHat's not far behind (behind Mandrake that is, not Windows) in that department, either.

Of course you'll always have the extra step of selecting software to install to complicate things. I just love it when people use these arguments - "Linux is too dificult - it comes with software!"

I have a R*dh*t box at work (that was set up by a total incompetent, which makes things even worse) that's screaming for an upgrade...while I can get LFS going in not much time now, I think I'll end up giving Gentoo a shot when the time comes.

I would suggest that anyone wanting real control over a linux box use the LFS (linux from scratch) distrobution. You can find it here LSF.ORG .

This is truly the way to make a customized system. The Problem with the BSD ports system is that It tells you what is the best version to run. If you do it this way you will have a complete understanding of your system.

In Short: If you really want a geeked out version of linux. Do it from scratch with LFS.

If you really want to get into it hardcore, go for linux from scratch. Because anyone who didn't personally compile every bit of open-sourced software on their system is a lightweight.

Sure the software is free, but you still pay for the bundling and the distribution of the software, and there is no specification as to how or how much they charge for those services...

It is free if you want to build your own distro...
People often times criticize linux for not being free, for being company-controlled (like RedHat). This is wrong. Linux is free as in speech to do whatever you need it to do, and free as in beer if you know how to install everything from the ground up. ( Linux From Scratch comes to mind...)
True, the admin's time is not free, but then again, he's already on the payroll, his time has already been factored in to daily/weekly/monthly operating costs. I know many companies turn to IT contracting companies so they can point fingers when the crap hits the fan.
If you grab sack and do the job right and take responsability for your own internal OS installation, building a linux server won't cost much money out-of-pocket.
Many companies won't do this, and so they claim that linux isn't free, that you have to pay companies like RedHat and SuSE for their work, when in reality, they'd rather pay someone for their work than do it themselves. and then complain about why they had to pay someone else.
My point: I don't blame companies for forking over a couple million dollars for a company to come in and do it right, but i hate when they complain that it isn't free 'like people say it is'.
wow... does that make sense?

After using many versions of Slackware, I finally tried Redhat at version 5.1. Actually I had tried it at a way earlier version and it never successfully installed. But 5.1 worked OK. The reason I tried it was I bought a Sun Sparc 5 and wanted to try Linux on it. Redhat seemed to be OK, so I later tried it on a couple other i386 systems, and that was working OK ... for a while. As it turns out, I needed to make upgrades before RPMs became available (see next paragraph). I also needed to make some changes in how things were built. The RPM system started getting out of sync with what was actually installed. The system ran just fine, but soon it got to a point where some packages I was installing with RPM would not install because the RPM database thought things were not installed which actually were (but weren't installed from RPM, so I can understand why it didn't know this). So I ended up having to do forced installs. And that ended up making it more out of sync. By the time I had gotten to Redhat version 6.0, I was getting fed up with it. I switched back to Slackware (and Splack for Sun Sparc eventually came out and I use that, too) and am happy again, with well running systems. And I am now exploring LFS.

You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that. If I get some package which is just a TGZ source file tree (because the developer was writing good portable code, but not using Linux to develop on), why should I, in the system administrator role, have to be one to make a package out of it? I'll agree it doesn't take more brains than needed to properly install the majority of source code, but I won't agree that it is easy (in terms of time spent) to do. At least I have the brains to actually check the requirements of what a given package I'm compiling needs, and make sure it is there by the time it is actually needed. The dependency may not be needed until it is run, so I have the flexibility of installing in whatever order I like. Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.

Let me repeat fetta's question with my +1 bonus, to see if someone will notice this and answer:

What's the downside of using the --no-g++-exceptions switch?

I know I would like to find out the answer to that one. Also, mav's comment about Linux From Scratch was terrific -- I'm now cruising through all the hints and really, this is quite a huge resource. I wish I had known about it earlier in my Linux life.

...let them take over! Run something sane, fast and highly customisable like WindowMaker and create shortcuts or menus for your favourite g- and k-based apps.

If you really have to use KDE and want some serious speed increases, then compile both KDE and Qt from source with the switch --no-g++-exceptions. This is a hint from Linux from Scratch which works very well.

I was a little disappointed by the article; I've tried Mandrake, RedHat, and Debian but my current system is one I built from ground up from source. There's a lot of lip-service paid to the merits of really learning linux and its internals, through things like the Power-up to Bash prompt HOWTO, but I don't see many people actually doing it.

I've only been using linux since December, but I think building my own system has taught me a thing or three that someone who has used, for example Mandrake for a few years wouldn't know.

There's much to be said for learning by doing. I was expecting a little more than a listing of ready-made distros.

People have been predicting that it will take a dumbing down of some sort for linux to become a viable alternative on the desktop. Is this it?

I havent tried this form of package managment myself but i think this is basicly what you guys are talking about:

more_control_and_pkg_man.txt

i've heard others say it works well for them.
adam

Life is made more difficult because there is buggy and/or broken hardware out there. I don't blame Redhat for accomodating this hardware, but by doing so they are making their distribution more complicated and less useful for those "in the know".

Redhat also, of course, distributes the non-kernel binaries optimized for Intel 80386 CPU's when the vast vast majority of installs are going on Pentium-class or better machines. And it doesn't help any that Redhat is using and distributing a very nonstandard version of GCC; see what the GCC developers say about such branches and what application developers say about this branch.

To actually learn a lot about Linux and all the associated tools that make it work, I highly recommend the Linux From Scratch method: build everything from source! You can optimize the build to your machine and end up with not only better performance, but a vastly superior knowledge of everything that used to be "under the hood".

It builds and bootstraps a basic utilitarian GNU/Linux installation all from source packages.

I think its great as both a production system and an educational build/install process.

The nice part is you end up with a fully functional linux you have built yourself. You will know _every_ package installed and why.

And all the mystery of linux will be revealed in your build process, its very educational.

Now, there is an partner group with the linux from scratch folks called automated linux from scratch.

From the automated linux from scratch site:

"Automated Linux From Scratch or ALFS, is a project that aims to create a generic framework of an extenable system builder and package installer using XML to describe the process.
It's main goal is to automate the process of creating a LFS system."

I have never used it, but I have used the straight linux from scratch and it is wonderful.

It builds and bootstraps a basic utilitarian GNU/Linux installation all from source packages.

I think its great as both a production system and an educational build/install process.

The nice part is you end up with a fully functional linux you have built yourself. You will know _every_ package installed and why.

And all the mystery of linux will be revealed in your build process, its very educational.

Now, there is an partner group with the linux from scratch folks called automated linux from scratch.

From the automated linux from scratch site:

"Automated Linux From Scratch or ALFS, is a project that aims to create a generic framework of an extenable system builder and package installer using XML to describe the process.
It's main goal is to automate the process of creating a LFS system."

I have never used it, but I have used the straight linux from scratch and it is wonderful.

It builds and bootstraps a basic utilitarian GNU/Linux installation all from source packages.

I think its great as both a production system and an educational build/install process.

The nice part is you end up with a fully functional linux you have built yourself. You will know _every_ package installed and why.

And all the mystery of linux will be revealed in your build process, its very educational.

Now, there is an partner group with the linux from scratch folks called automated linux from scratch.

From the automated linux from scratch site:

"Automated Linux From Scratch or ALFS, is a project that aims to create a generic framework of an extenable system builder and package installer using XML to describe the process.
It's main goal is to automate the process of creating a LFS system."

I have never used it, but I have used the straight linux from scratch and it is wonderful.

Well, it never did this under other kernels; in fact it stayed up for 2½ months under 2.4.2 it was finally taken out by a power failure. Im sure the box has problems, as it is a hodgepodge of old hardware (still has a 5¼ drive!), but the random-reboot problem only began under 2.4.17. Rebooting under an older 2.4.* brought it under control again. I didnt take the time to investigate exactly what was wrong with it.

In general, I dont like using packages due to the opaqueness of everything (type RPM -U and just hope it quietly installs hundreds of files in different places?); and am currently working on building a system from the ground up on the machine.

Red Hat Linux binaries and source still fit on one DVD, some versions of Slackware fit on a CD-ROM, an LFS install can be squeezed into 8 MB, and floppyfw (Linux for a dedicated packet-filtering firewall) fits on a 1.4 MB floppy.

Well put.

I'd like to see something like this, but managed but a 'config demon' which has access controls and allows sharing a centralized config with other hosts over the network (ok, you could do it by mounting the config dir via NFS or Samba...).

The demon would provide the API/abstraction and would store each APP's config file in a human readable format. Then supply X and ncurses front ends so those without X aren't stuck editing some scary XML file.

So besides just talking about it, is anyone interested in doing it? I'd be interested in getting involved in a project. I've been tinkering with LFS so I'd have a blank slate to experiment with this very problem.

Now if we could find a way to fix the init scripts while we're at it...

Basing this distro on RedHat is probably the only innovation offered up here; I assume this is where the relative ease of use of the resulting distro comes from. As for minimal resource distros, you needen't go all that far... linux.org has an interesting list.

True, most of the minimal resource distros there lack things such as X and decent installers.

Besides, imho the proper way to install a minimal requirements linux on a machine is Linux from Scratch, though this, to reiterate a previously made point, sort of blows the whole 'ease of use' issue out of the water.

So my understanding would be that RULE is linux for the poor desktop.

This, by the way, could be the main thrust of the desktop push; windows pretty much has the high-end desktop market wrapped up; why not stage an attack from the ranks of those 486's stashed away in the closet?

• DFI Socket 7 motherboard
• 192 Mbyte SDRAM
• AMD K6II/500 CPU
• A 20 Mbyte drive
• El-Cheapo tiny graphics card

The whole system draws less than 50 Watts. (Of course I added a second hard drive to bring power consumption up to 60 Watts later, but it's still pretty good.)

The system runs a custom Linux From Scratch install. A very minimal system, but with a very carefully selected set of services: sshd, Apache, BIND, and Postfix for mail.

The goal (which I achieved) was a UPS hang-time of over 2 hours on a small little UPS. Important for what is my only 24x7 server box.

If I were to build a low-power system today, I'd go for a VIA C3 without any doubt. I've seen several of these systems that run quite nicely without even a CPU fan. That's one less moving part!

Long gone are the Slackware days where you'd download a minimal kernel/utilities package and then compile only the apps you need, by yourself, and understand everything.

Wrong. I entered those days quite recently, with Linux From Scratch. LFS isn't exactly a "security solution," but it's hard to break into a machine when there's nothing running on any port except ssh.

I still use Corel 1.0 and 1.2 on both machines at home. It was the first Linux OS I tried, and I don't feel much like changing. The only time I wan't running Corel was when I made my own Linux from Scratch distro. Also, where can I get the download for all the Corel Office suites? Every since Xandros took over, I cannot get any of the cool stuff that came with the Corel Updater.

I do not agree. When I first started using Linux I loved the freedom to upgrade the kernel. After that I was forced to learn about kernel patches and configuring and making my own patches because all kind of hardware didn't work on my laptop. I got so intrested in these processes that I upgraded X, KDE and some small things. By that time my (Redhat) installation was such a mess I started all over with LFS. I would not have learned so much so fast if I didn't start with upgrading!

Never confuse distro X with Linux. Go over to the Linux From Scratch page- Linux can be very small indeed when custom tailored to its' environment. When the distros try to be 'one solution for everyone' they are guaranteed - proven thanks to Microsoft - that bloat will inevitably ensue.

As a counterpoint- I don't want to argue *BSD versus Linux - nor KDE versus GNOME - nor EMACS versus Vi. Can't we realize that these differences empower us- indeed, challenge us- to find the 'most superior' solution? After all, without a struggle, there can be no change.

but now I use LFS

I have an old 486 lying around, but I don't have any DOS install disks lying around. Anyone where I could find them? This sounds like it would be cool to try out. ... ...

What do you need DOS for? If you are looking for coolness, hike over to Linux From Scratch and install Linux onto your 486's hard drive directly from source code!

You can also check out Linux From Scratch if you'd like to compile with your own optimization options. Personally, even though I tend to compile my Linuces from scratch nowadays, I still don't do any optimization.

Actually, for my next system, the options will be something more like -march=powerpc. :)

So, if [AOHell] were really to acquire RH I fear that they would break that one too.

You say that as if Redh*t isn't broken already. LFS is the One True Linux. :-)

There's countless others, but I don't feel like looking for them.

I remember back when binary packages weren't released for damn near anything - after all, with gcc, everyone could have a C compiler. Wanted to run the newest afterstep or fvwm? Guess what? Download the source.

For linux, it's the distribution's job to provide binaries. For other systems like solaris and HP-UX there are places like Sun Freeware or HP-UX Software Porting Archive to get it. Some projects do so as a courtesy, but it's hardly required.

For something like XFree86, a binary distribution would almost certainly screw up your linux distribution's packaging system. Very few people would be able to utilize a binary distro of X that isn't tailored for their flavor of linux.

Besides, if you run something like linux from scratch then you don't want to download binaries anyway.

O.K., here's how - from The LFS Hint (read all of it, there are some helpful details about customizing the install that the XFree86 Build doc doesn't explain, read that too though.)

Download & extract: X410src-1.tgz, X410src-2.tgz, X410src-3.tgz

Install with (from inside the xc/ directory that the archives extract to):

make World &&
echo /usr/X11R6/lib >>/etc/ld.so.conf &&
make install &&
make install.man &&
/sbin/ldconfig

1. I wanted to know and also decide what is where. Automatic installation efficiently takes away your decision of whether Apache should remain in /usr/local/apache, /opt/services/apache or /home/apache (which I happen to prefer) or whatever you like.
2. I wanted to have the decision about do I need X to run nethack, or that my PHP module doesn't support MySQL at all but PostgreSQL instead. With a prebuilt package you might find out that to install say vim to your 486 with 280MB hard disk, you need to install X because the prebuilt vim happens to be linked against X libraries.
3. After I install any library (version) not known by the distro-of-choice my self, I efficiently render the dependency stuff broken so I end up compile it yourself system anyway.
4. Automated updatings are basicly nogood. What if my computer had updated to 2.4.15 as soon as it was released. I wound't mind that on a test machine but for my primary workstation I prefer having somebody else finding the worst problems first. Also IF the system breaks after update done manually, at least I can say what actually was updated. You need to use the update but if you don't, it's of no value.

The optimized for specific hardware thing might be an issue for a 386 which you want to run as fast as possible but really doesn't matter that much on modern hardware on which you often can't even find much difference with a program compiled with or without optimizations.

The great parts of compiling something yourself are so great because of the lack of automation, not because the compilation itself.

The thing is with Windows XP that it doesn't load ANYTHING at bootup. On my Athlon 800, it takes about 1 minute to log into my user once I've clicked it in the login screen. And I can forget about tweaking or disabling things.

But you might be interested in knowing what is the fastest OS I've ever seen at booting: Linux From Scratch. The BIOS took longer than the booting itself. 10 seconds after I had pressed the power button, I was ready to log in and every daemon was loaded. And the best part was that I knew what was going on.

If you like removing RedHat packages and recompiling them the way you want (I do! :) ) you might like to try Linux From Scratch

For those too lazy to follow the link, LFS is instructions on building a working (minimal/basic) linux system from sources. This can be quite a bit of work, but in return you get to have a lot of say in how your system works (depending on how adventurous you happen to be), although there are excact instructions (with the reasons for many of the choices).

Also there is the ALFS project (automated LFS) and the nALFS tool (which is great, I've built an entire system using it), which make it much easier to rebuild your system, if need be.

If you would like a system where you decide how things are done, LFS is certainlly worth a try.

Look at other distros or - even better - Build your own with Linux From Scratch as a starting point.

that seems to be spreading to other linuces (xinetd, vi=vim, and so on)

The basic LFS install is without xinetd, but is with Vim. If you don't want to install Vim, though, you're completely free to install whatever you do want.

If only someone would mix all of the BSD userland stuff with the Linux kernel...

In which case GNUStep is not for you. It's so completely and utterly different than anything you've ever seen that "running vi" doesn't make sense in the UI model.

Actually I'm using Grub w/ Linux, too. Works pretty nice. And I'm planning on upgrading my lilo-based system at work to grub the hard way (I've actually recompiled everything from scratch a la Linux From Scratch. Then I want to install grub and upgrade to ext3.)

HowTo Build a Minimal Linux System from Source Code

Linux from Scratch

Now if someone can tell me why programs (so far MAKEDEV and Lilo) won't run from
harddrive /dev/hdd1 I'll be a happy little linuxer