Slashdot Mirror

It's not in CVS yet (server down, other issues), but Linux from Scratch builds GCC 3.2.1 for most people out of the box with the same commands as 3.2. Also, many have reported that they have built LFS with glibc 2.3.1, and have experienced huge speed increases. I know a few on the IRC channels who have successfully built glibc 2.3.1 with no changes to the commands used in LFS 4.0. Note that GCC 3.2.1 is required for glibc 2.3.1.

The Dutch LFS FTP mirror was also hosted at the University of Twente, which means it's also down. The Dutch HTTP mirror should work properly, since it's outside utwente.nl space.
Last news is that HP (Who supplied most of the UT backbone equipment) is on its way with emergency equipment to have things up and running somewhere tomorrow.

I'd mod this up if I had mod points. I think RedHat is the one as well. They seem to understand the need for uniformity in the desktop area with their latest Bluecurve work. RedHat 8.0 is very polished.

But in the meantime, while the distro wars rage on, I'm having a lot of fun with LFS: Linux from scratch

LFS is the way to go to make old hardware new again, IMHO. Hardware is only as old as the software it runs, so going with an antique distro is just make your old computer old again. If you build an LFS machine, you can keep it useful while still keeping current.

Also, have you thought about a thin client/diskless node setup? is a great example of one of the many type of distros like this...

Your best bet is to roll your own, following the instructions at Linux From Scratch. It takes some time, but you can squeeze every bit of performance out of that machine that way.

In other words, was there any redeeming factors Debian had over any other distribution?

This is exactly what Linux from scratch was for.

http://www.linuxfromscratch.org

Also includes a CowboyNeal load of documentation!

Great! but as tiny linuxes go, ramf has support for Reiserfs, and a lot of people I know rely on tomsrtbt . Almost all of the information in the IBM page submitted here is already available, but it's really nice to see IBM providing a stable home for this type of information -- while the original linux from scratch server flounders (was it those big bandwidth bills from being /.ed did it in?) and the first cool rescue thing I used, cclinux, has all but disappeared. sigh!

So thanks, IBM. This time.

Without them. LFS all the way baby. GTK2, X4.2.1, XFT, all the bonuses.

Too bad that this happened to LFS. I have no experience running an LFS machine but the idea has a certain appeal to me (I am a Gentoo convert however).

As good as Gentoo is, some of the Gentoo ebuilds needed to use hints from LFS. A clear example was How to compile Java 2 SDK Source (available from Sun) using gcc3 so that you can use it as a plugin for your shiny new gcc3 compiled mozilla.

Again, I'm very comfortable with the amount of flexibility and ease of use that Gentoo provides me.

Too bad that this happened to LFS. I have no experience running an LFS machine but the idea has a certain appeal to me (I am a Gentoo convert however).

As good as Gentoo is, some of the Gentoo ebuilds needed to use hints from LFS. A clear example was How to compile Java 2 SDK Source (available from Sun) using gcc3 so that you can use it as a plugin for your shiny new gcc3 compiled mozilla.

Again, I'm very comfortable with the amount of flexibility and ease of use that Gentoo provides me.

See http://hints.us.linuxfromscratch.org/hints/cdrw-hi nt.txt

The degree of divergence between the two determines whether it is appropriate to send the bug report to either or both. In most (but not all) cases the distro will be lagging behind the OSS package bugfixes so it's very likely that it's already been fixed.

The real solution, of course, is to ditch all distros and build everything from sources yourself.

Not trolling here, but after starting to read Gentoo's installation pages, I opted out to do a Linux system from scratch instead. Maybe I'm just lazy.

You're being very selective with your "everything" description.

Does Windows have a net-based install that only requires a couple of floppies to get going? Does Windows have a unified scheme where you can pull down whole libraries of software from either a command line, text-based, or full GUI interface? Does Windows have the ability to customize its kernel? Does Windows have tab-based, minimal, and even mouseless GUIs?

Linux offers choice. People are choosing to make programs that are similarly functional to those offered by Microsoft, but that doesn't mean that Windows is setting the standard for everything.

Besides that, there's a lot of crossover. A lot of programs run on both Windows and Linux. Emacs. Vim. Mozilla. Perl. Python. Ruby. Nethack. Windows doesn't set these standards either.

If you still don't believe that Linux is different than Windows, try doing a LFS or Gentoo install. Then come back here and tell me that Windows is setting the standards for everything.

Great troll! I was sure you are serious and then I almost died laughing when I read:

"Compare the Debian install to Gentoo or Linux from Scratch. Neither of these two distros have an installer, yet the installs are simple, straight-forward, logical and achievable. How is it that these two distros, having no installer, can wipe Debian's floor when it comes to installation?"

I have yet to see a better troll!

For those of you who don't know Linux From Scratch, let me quote How things are going to be done section from Chapter 1:

We are going to build the LFS system by using a previously installed Linux distribution such as Debian, SuSE, Slackware, Mandrake, RedHat, etc. We will use the existing Linux system as the development platform, because we need tools like a compiler, linker, text editor, and other development tools to build our system. Ordinarily, the required tools are available by default if we selected "development" as one of our installation options when we installed a Linux distribution.

After you have downloaded the packages that make up an LFS system, we will create a new Linux native partition and filesystem. Here is where the LFS system will be compiled and installed.

The next step, Chapter 5, will discuss the installation of a number of packages that will form the basic development suite which is used to build the actual system, or needed to resolve circular dependencies. For example, you need a compiler to build a new compiler, and you need a shell in order to install a new shell. The packages in this chapter will be linked statically.

Static linking describes a method of compiling software so that it does not require the presence of libraries when building is complete. The resulting program is able to function on its own. The program is able to do so because the pieces of the program that would normally remain in the libraries are copied from the libraries and built right into the program. Ordinarily, software is built with dynamic linking. This conserves storage space and increases the efficiency of many programs. We statically link our software in Chapter 5 because we will, in theory, be moving our development system to a virtual environment where the already mentioned libraries will be absent. If the software is built dynamically, our development suite will not function. Since the libraries we are talking about are provided by our distribution Linux, the goal of Chapter 5 is to build a development environment where those libraries are not required and is therefore independent of the distribution.

In Chapter 6 we will build and install our final system. We will use the chroot program to enter a virtual environment and start a new shell whose root directory will be set to the partition where we built all the Chapter 5 software. This is very similar to rebooting and instructing the kernel to mount our LFS partition as the root partition. The reason that we don't actually reboot, but instead chroot, is that creating a bootable static system requires additional work which simply isn't necessary. As well, we can continue to use our platform system while we are building LFS. While software is being compiled and installed you can simply switch to a different VC (Virtual Console) or X desktop and continue using your computer normally.

When all the software from Chapter 6 is installed, Chapters 7, 8 and 9 will help us finalize our installation. We will set up our boot scripts in Chapter 7. In Chapter 8 we will build our final linux kernel and set up the Linux boot loader. Chapter 9 has some pointers to help you after you finish the book. Then finally, you reboot your system and boot into your new LFS system, and start to really use it.

This is the process in a nutshell. Detailed information on the steps we will take are discussed in the chapters and package descriptions as you progress through them. If something isn't completely clear now, don't worry. It should become very clear shortly.

Please read Chapter 2 carefully as it explains a few important things you should be aware of before you begin to work through Chapters 5 and later.

For those who still doesn't get it: Linux From Scratch is a book! As the author, Gerard Beekmans, says in the subtitle: "This book describes the process of creating a Linux system from scratch, using nothing but the sources of the required software." You make the system bootable in 8th chapter after long hours of building every piece of software manually, after writing your own boot scripts and everything else.

Once again: This is absolutely the best troll I've ever read on Slashdot.

Moderators: please give it +5 Funny because it really deserves it! I write it as AC secretely hoping that someone will answer to the parent taking it seriously, before reading my explaination. Greetings.

Great troll! I was sure you are serious and then I almost died laughing when I read:

"Compare the Debian install to Gentoo or Linux from Scratch. Neither of these two distros have an installer, yet the installs are simple, straight-forward, logical and achievable. How is it that these two distros, having no installer, can wipe Debian's floor when it comes to installation?"

I have yet to see a better troll!

For those of you who don't know Linux From Scratch, let me quote How things are going to be done section from Chapter 1:

We are going to build the LFS system by using a previously installed Linux distribution such as Debian, SuSE, Slackware, Mandrake, RedHat, etc. We will use the existing Linux system as the development platform, because we need tools like a compiler, linker, text editor, and other development tools to build our system. Ordinarily, the required tools are available by default if we selected "development" as one of our installation options when we installed a Linux distribution.

After you have downloaded the packages that make up an LFS system, we will create a new Linux native partition and filesystem. Here is where the LFS system will be compiled and installed.

The next step, Chapter 5, will discuss the installation of a number of packages that will form the basic development suite which is used to build the actual system, or needed to resolve circular dependencies. For example, you need a compiler to build a new compiler, and you need a shell in order to install a new shell. The packages in this chapter will be linked statically.

Static linking describes a method of compiling software so that it does not require the presence of libraries when building is complete. The resulting program is able to function on its own. The program is able to do so because the pieces of the program that would normally remain in the libraries are copied from the libraries and built right into the program. Ordinarily, software is built with dynamic linking. This conserves storage space and increases the efficiency of many programs. We statically link our software in Chapter 5 because we will, in theory, be moving our development system to a virtual environment where the already mentioned libraries will be absent. If the software is built dynamically, our development suite will not function. Since the libraries we are talking about are provided by our distribution Linux, the goal of Chapter 5 is to build a development environment where those libraries are not required and is therefore independent of the distribution.

In Chapter 6 we will build and install our final system. We will use the chroot program to enter a virtual environment and start a new shell whose root directory will be set to the partition where we built all the Chapter 5 software. This is very similar to rebooting and instructing the kernel to mount our LFS partition as the root partition. The reason that we don't actually reboot, but instead chroot, is that creating a bootable static system requires additional work which simply isn't necessary. As well, we can continue to use our platform system while we are building LFS. While software is being compiled and installed you can simply switch to a different VC (Virtual Console) or X desktop and continue using your computer normally.

When all the software from Chapter 6 is installed, Chapters 7, 8 and 9 will help us finalize our installation. We will set up our boot scripts in Chapter 7. In Chapter 8 we will build our final linux kernel and set up the Linux boot loader. Chapter 9 has some pointers to help you after you finish the book. Then finally, you reboot your system and boot into your new LFS system, and start to really use it.

This is the process in a nutshell. Detailed information on the steps we will take are discussed in the chapters and package descriptions as you progress through them. If something isn't completely clear now, don't worry. It should become very clear shortly.

Please read Chapter 2 carefully as it explains a few important things you should be aware of before you begin to work through Chapters 5 and later.

For those who still doesn't get it: Linux From Scratch is a book! As the author, Gerard Beekmans, says in the subtitle: "This book describes the process of creating a Linux system from scratch, using nothing but the sources of the required software." You make the system bootable in 8th chapter after long hours of building every piece of software manually, after writing your own boot scripts and everything else.

Once again: This is absolutely the best troll I've ever read on Slashdot.

Moderators: please give it +5 Funny because it really deserves it! I write it as AC secretely hoping that someone will answer to the parent taking it seriously, before reading my explaination. Greetings.

Great troll! I was sure you are serious and then I almost died laughing when I read:

"Compare the Debian install to Gentoo or Linux from Scratch. Neither of these two distros have an installer, yet the installs are simple, straight-forward, logical and achievable. How is it that these two distros, having no installer, can wipe Debian's floor when it comes to installation?"

I have yet to see a better troll!

For those of you who don't know Linux From Scratch, let me quote How things are going to be done section from Chapter 1:

We are going to build the LFS system by using a previously installed Linux distribution such as Debian, SuSE, Slackware, Mandrake, RedHat, etc. We will use the existing Linux system as the development platform, because we need tools like a compiler, linker, text editor, and other development tools to build our system. Ordinarily, the required tools are available by default if we selected "development" as one of our installation options when we installed a Linux distribution.

After you have downloaded the packages that make up an LFS system, we will create a new Linux native partition and filesystem. Here is where the LFS system will be compiled and installed.

The next step, Chapter 5, will discuss the installation of a number of packages that will form the basic development suite which is used to build the actual system, or needed to resolve circular dependencies. For example, you need a compiler to build a new compiler, and you need a shell in order to install a new shell. The packages in this chapter will be linked statically.

Static linking describes a method of compiling software so that it does not require the presence of libraries when building is complete. The resulting program is able to function on its own. The program is able to do so because the pieces of the program that would normally remain in the libraries are copied from the libraries and built right into the program. Ordinarily, software is built with dynamic linking. This conserves storage space and increases the efficiency of many programs. We statically link our software in Chapter 5 because we will, in theory, be moving our development system to a virtual environment where the already mentioned libraries will be absent. If the software is built dynamically, our development suite will not function. Since the libraries we are talking about are provided by our distribution Linux, the goal of Chapter 5 is to build a development environment where those libraries are not required and is therefore independent of the distribution.

In Chapter 6 we will build and install our final system. We will use the chroot program to enter a virtual environment and start a new shell whose root directory will be set to the partition where we built all the Chapter 5 software. This is very similar to rebooting and instructing the kernel to mount our LFS partition as the root partition. The reason that we don't actually reboot, but instead chroot, is that creating a bootable static system requires additional work which simply isn't necessary. As well, we can continue to use our platform system while we are building LFS. While software is being compiled and installed you can simply switch to a different VC (Virtual Console) or X desktop and continue using your computer normally.

When all the software from Chapter 6 is installed, Chapters 7, 8 and 9 will help us finalize our installation. We will set up our boot scripts in Chapter 7. In Chapter 8 we will build our final linux kernel and set up the Linux boot loader. Chapter 9 has some pointers to help you after you finish the book. Then finally, you reboot your system and boot into your new LFS system, and start to really use it.

This is the process in a nutshell. Detailed information on the steps we will take are discussed in the chapters and package descriptions as you progress through them. If something isn't completely clear now, don't worry. It should become very clear shortly.

Please read Chapter 2 carefully as it explains a few important things you should be aware of before you begin to work through Chapters 5 and later.

For those who still doesn't get it: Linux From Scratch is a book! As the author, Gerard Beekmans, says in the subtitle: "This book describes the process of creating a Linux system from scratch, using nothing but the sources of the required software." You make the system bootable in 8th chapter after long hours of building every piece of software manually, after writing your own boot scripts and everything else.

Once again: This is absolutely the best troll I've ever read on Slashdot.

Moderators: please give it +5 Funny because it really deserves it! I write it as AC secretely hoping that someone will answer to the parent taking it seriously, before reading my explaination. Greetings.

The only problem i went on with mandrake was that `perldoc` wasnt there... i had to install it manually (what a great pain), even if i select all the .*rpm at the install,,,,,

now if someone wants to avoid such non-friendly problems, consider installing a linuxfromscratch... at least is it doesnt have something you badly need, you're the only responsible :P

freddo
--
http://freddo.netfirms.com/
--

There are no hacker-made Linux anymore: everybody use well-supported distros like Red Hat, Mandrake, Conectiva.

I guess that makes me nobody, then. I suppose there are more nobodies out there as well.

I don't run Gentoo, but I built my system with LFS. I wanted to build my system from source for a reason other than optimizations: dependencies.

I like not having programs I use be dependant on some bizarre unknown little library or program that Red Hat or Mandrake saw fit to link to something important. (Requiring Sendmail to run a simple cron daemon? Requiring the installation of Vi?) When you build from source, you know that you won't be getting any missing library errors, and you know that your program won't die mysteriously because it can't find an odd little support program in the path.

No, I'm an LFSer so I compiled it myself. However, I can't find any evidence that the cracker actually bothered with my system. No warez, no modified passwords, nothing suspicious in the logs, no suspicious timestamps. Of course, none of this really means anything since I was negligent enough to compile sendmail as root and root can reverse any of the above. For all I know, /usr/bin/insert_obscure_utility_here has been modified to make me a drone in a future DDoS.

On the bright side, I tested the malicious code and it seems to error out on my system, but I can't be sure since port 6667 on Eli's system is no longer open.

Oh, and Eli - perhaps the cat is responsible. My port scan of you indicated no obvious vulnerabilities unless your OpenSSL is unpatched. But Snuffy has physical access, no? Also, perhaps you might want to put a disclaimer on your webpage?

Of course my definition of "problem" may be different from yours. If ./configure says clearly that I need a library and I can go to freshmeat or the application's website and download and install that library, I don't consider that to be a "problem".

This distribution autodetects a tonne (I'm Canadian) of hardware. It runs off of the CD, however, you can set it up to store configuration settings on the hard disk. Thus, if you have any problems, you simply reboot.

I would take a look at LFS 4.0 in combination with the sources for Knoppix. Roll your own distro based on them. An added benefit of doing things this way: you can redefine the default settings so that nothing ever needs to be written to the hard disk.

Because it's a troll. It gets discussion started...

It makes us (the users) look like the next generation zealots. I have a better idea - learn what distros do what things and at what difficulty and then choose for yourself. Suit your own needs, dammit.

Exactly! Over the past 8 or so years I've used Redhat, Debian, Mandrake, a couple of BSD's, and LFS. Now I use Gentoo because it suits me - and I think it would suit nearly everyone who has an interest in LFS. I can't see why most people, even those who want the flexiblity of a source based system, would spend the time to maintain an LFS based system unless they had nothing on a computer except learn about how the computer works. You have no time left over to take advantage of what the computer can actually do for you -- save you time. How much different are your compile time choices going to be from the ebuild's defaults? And if they are different, then edit the ebuild file.

LFS is just tedious to maintain. Which is part of the reason why it's perfect for an embedded system. You get exactly what you need, nothing more, and you never change it.

As others have said, lfs is great for getting your hands dirty and learning some stuff. Gentoo is for after your hands are dirty and you want to clean them up...

LFS is a wonderful experience to install. I'm not discouraging anyone from going out and installing LFS. I just believe that after you've done it once, you don't need to do it again - and that's where Gentoo comes in. Gentoo essentially is what Automated LFS aims to be.

LFS is brilliant, yeh, so it make take a good couple hours and maybe even give you some hassles, tho I had none, but at the end of the day it is all worth it. My LFS systems have all given me less hassles then any distro I've run, granted they take a tad longer to setup. For those of you that dont feel like enduring the proccess there is also a distro called LRs-Linux, which has a few setup options, including a LFS setup. You can find that here. There's also the automated LFS project which has a similiar affect, tho that requires an already setup installation like LFS, have a look here.

From: LFS Book 4.0 - Chapter 1.1, Section 2

We are going to build the LFS system by using a previously installed Linux distribution such as Debian, SuSE, Slackware, Mandrake, RedHat, etc. We will use the existing Linux system as the development platform, because we need tools like a compiler, linker, text editor, and other development tools to build our system. Ordinarily, the required tools are available by default if we selected "development" as one of our installation options when we installed a Linux distribution.

Okay, so what do these people mean by "Linux From Scratch"? Installing another distro first to install "required tools" is in my view not installing from scratch. I was hoping to be able to install a very, VERY base HD based distro for my two antique 486s with just the standard stuff (GCC, shell, GNU utils and iptables) for use as a router/NAT gateway but that is quite far out of the question now. Huge disappointment from something with such a promissing name.

i started using linux a little over two years ago. i went to linuxworld 2000 in nyc and came home with free copies of several distrobution's cds. i went cold turkey off of windows and into redhat. after about a month, i realized that i wasn't really learning much from redhat.
that night i decided i was going to find a distro that i liked. i installed everything (suse, turbolinux, debian, conectiva). finally, i installed slackware an was amazed at its simplicity. it was remarkably voodoo-free. there were no crazy scripts to confuse me, everything made sense.
now i use debian. i forget when or why i made the switch. i still love slack, but i'm hooked on debian's package management and software availability. slackware is the best distro to *learn* linux on. it forces you to do things yourself, and that's important. it's not quite as hardcore as linux from scratch, and i've heard crux and gentoo are similar, but slack will always hold a special place in my heart.

Thanks Pat.

From the Article: "I don't have a problem with commercial versions of Linux (Slackware is one, after all). My main concern is that everyone plays by the rules, and I've heard about things (like binary only releases and beta testers forced to sign non-disclosure agreements) that just don't seem compatible with the GNU General Public License. Hopefully the Free Software Foundation is keeping a close eye on the situation."

I hear many fl4mz0rs spouting off about how this distro 'blows' and this other one '0wnz0rz', etc. And many times their beef with the distrobutions is that they cater to the mainstream (Windows?) users, rather than to the old-school-bloatless-speedfreak user.

I just want to clear this up for any fl4mz0rz listening. GNU/Linux will not ever be ruined by any company who releases a distrobution.
Anyone can make a linux distrobution, and because of this, if you ever see that all the distrobutions of linux are heading down the road to Redmond, you can learn (now thats a novel idea) how to make your own (if it's important enough to you). The atrocities mentioned abover are not good practice for companies, but do not hurt the GNU/Linux community very much because educated users will not support companies who do them.

To install LFS you must use an existing Linux install on the machine to create your LFS system, using the existing system's compiler and the 'chroot' command.

With Gentoo, I believe you can install it off an existing system as well, just by downloading the system tarball, untarring it on a new partition, and again using the 'chroot' command to then compile and install the system.

If you don't have an existing system, you can just use a Linux boot floppy such as tomsrtbt, boot with that, set up the network/internet connection, and then download/chroot from there, which is what I did on a laptop with no bootable CDROM drive.

Try it!
Mark.

No that's why linux has linux from scratch.

Having used Unix since 1992, GNU/Linux since 1998, and successfully building Linux From Scratch I'm not a newbie. But Mandrake is still my distro of choice.
While on the surface it has an easy to use GUI for just about anything it is still GNU/Linux under the hood, and can still be hacked through config files if you like that sort of thing. After all, the GUI is just a front end to the config files.
The purists out there can have no quarrel with Mandrake since it is both LSB1.2 compliant and 100% free software.
The only problem I have with Mandrake is that they neglect to use the word GNU in the name, but apart from that Mandrake is easily the best general purpose distro out there for both newbies and old farts alike.

Hi, I'm the article submitter. :)

where does one stop with the attributions?

Did you read the FAQ? I was hoping a few folks would and think about the ideas presented, even if they don't agree.

I did a little experiment today; I downloaded all the source code for Linux From Scratch, and moved all the GNU code into a directory. The uncompressed GNU code takes up 341648 bytes. The uncompressed Linux code (counting the kernel, the manpages, and modutils) takes up 155872 bytes.

Since you mentioned X, I uncompressed XFree86 4.1.0 and counted it: 289624 bytes. (I was actually surprised; I expected X to be bigger than GNU.)

For the record, this is not all the GNU software, either. Emacs, for example, is not counted (that would've put it way over the top), and LFS chooses many alternatives where GNU packages exist.

Now, when you talk about the tail wagging the dog, if you want to call GNU the tail, the tail is bigger than the dog. :)

Is the kernel the OS, or are the utils the OS?

Did you read the FAQ? This issue is addressed. There's some truth to both views.

Does kernel32 or command.com makes Windows the "Windows OS"?

That's what GNU is saying. Most people would say the Windows OS consists of those pieces, plus the GUI, plus many utilities. And when you say you got RedHat Linux, do you mean you got the version of Linux, the kernel, distributed by RedHat, or do you mean you got an OS comparable to Windows? Which sense are you using the term OS in there?

The hoster I work for runs its systems on Linux from Scratch. In our opinion the most Linux distro's are much too bloated with all kind of stuff we never need on our servers. LFS gives us the possibility to do things exactly the way we want them to. Oh, we also run the Dutch LFS mirror :).

Where I think Red Hat have made mistakes [...] is by modifying code rather than commissioning the GNOME and KDE teams to do it on their behalf.

My God, you're right! How dare Red Hat take Free/open-source code and use it the way the licenses mean for it to be used?

If KDE developers are going to whine about Red Hat modifying code that the KDE developers damn well gave them the right to modify, then they're definitely in the wrong business.

Forking code is prefectly natural in the open-source world. There are a few forks of the Linux kernel (probably more in various in-house projects around the world), you have GNU emacs and XEmacs, etc., etc. Generally, this is a good thing, as new ideas get tested out without needing the "blessing" of the official code tree maintainer. (As I recall, the original USB support started off as a forked project without Linus' blessing, until something usable was available.)

All Red Hat has done is forked the KDE and GNOME desktops to create a unified look for both of them. Yes, Red Hat will have to redo all of their changes when KDE 3.1 and GNOME 2.0.2 come out. That's their perogative, and I'm pretty sure they realized what they were doing when they made the decision.

It boils down to three options:
1) Learn to use Red Hat's desktop environment
2) Replace Red Hat's with another; it probably wouldn't take long for some enterprising people to create a set of RPMs from the "official" KDE/GNOME releases
3) Start using a different distribution; maybe rolling your own is the best answer if you want things exactly your way?

Jay (=

Bah. Gentoo is for people who can't handle Linux From Scratch and want to appear l33ter than Slackware.

You have to build the sun jre from source code. This is something that Gentoo 1.3/1.4 users have had to do for quite some time, and it is quite a pain in the bum. You can find instrutcions on how to go about building the jre from soure here.

well, yes and no. This screenshot was taken just after loginprocess, which was started as "kdm". So this is kde memory footprint just after the login (okey, not only kde's footprint).
But, I didn't run any other programs, other that was started during the boot process, which shall be cups, the nfs (portmap and rpc.statd) and the gpm program. (I'm running LFS on my computer).

1. Compile the system. There's a fanastic guide at linuxfromscratch.org.
2. Set the fstab up to place all read-write hierarchies on a tmpfs filesystem. This include tmp, var, and portions of etc. Have copies of the initial state of thse filesystems in a separate directory on the CD and set the bootscripts up to untar them at bootup.
3. Compile a highly compatible kernel. Basically, enable most things that cannot be compiled as modules and compile all modules.
4. Use devfs with compatibility links. it cuts down on confusion as to what devices exist.
5. Create an ISO of the filesystem, being sure to enable all options required for bootable CDs.
6. Install lilo into the boot sector of the ISO.
7. Burn the CD.
8. Reboot and pray.

Sure it will have it's problems, but right now it does not. More users and more bad or poorly written apps will cause bloat and decay.

I agree; which is part of the reason I quit using Mandrake and rolled my own LFS system. Anything I'm not sure about I make install to /opt/whatever, then add the /opt/whatever/lib path to ld.so.conf. This way I can check out new apps, and if they don't make the grade, I just rm -rf the whole directory. My whole system has stayed pretty clean this way.

--Jon

It's clear that Forgent is going after companies that develop browsers, sell image editing tools, etc., but on your typical Unix/Linux platform these tools often are "just" linked to libjpeg where the real encoding and decoding is done. In this case might they try to go after anyone whose name appears in the libjpeg sources? Ack!

Having C:\Windows and C:\Program Files is okay on a windows box; they're just points of no-entry, aka advanced stuff you never need to look at. Instead you have "My Documents" to put documents into, and "My Pictures" for pictures. As you get more advanced you could even install a new program. It goes, logically into Program Files, and you get a link automaticly in the start menu.

Now lets look at the linux version. There's /home/joeuser, which has nothing. You could add, say, documents, pictures to it. So now we have those two nice folders. Now Joe is feeling brave and starts learning about his computer. He finds in his home dir: .bash_history, .kde3, .mcop, .mozilla, .qt, .bashrc, .DCOPserver_localname_localname_0, .ICEauthority, .kderc, .mcoprc and .xftcache.

Okay, well, so be it - just ignore all of that. Now Joe wants to install NewCoolApp. He starts the installer that was written up for TechnophobeLinux, which kindly asks him to provide the administrator password for the installation. Said and done, and the installer spews files all over his disk. They go into /bin, /usr/bin, /usr/local/whatever, /usr/share/whatever, a bunch of man directories, some in /etc, and maybe some in /opt/whatever as well.

Honestly, how many people here have actually read the guidelines for filesystem layout? I know which stuff goes in /bin as opposed to /usr/bin (which is also mostly different on different distributions btw...), but Mr. User is most likely to have one partition for everything on his simple desktop system, and none of it matters. Say what you want about the stupidity of putting apps in C:\Program Files\Vendor\ProgramName but at least it's fairly obvious that the "program files" end up under "Program Files" (duh) and possibly C:\Win(NT|dows)\System, which kinda makes sense since they're system files.

Joe is going to have a lot of questions rather quickly. For instance, why isn't there user stuff in /usr? Who is /usr/share shared with? What's optional with /opt and why isn't the rest optional? And why is my home directory full of config files if config files go into /etc? And why are there at least two */bin dirs (containing not only binaries but other runnable files btw)?

Say what you want about the Windows registry, but at least it's not laying around in plain view in Joe's home directory. And separating /bin and /usr/bin makes perfect sense on a server handled by a skilled person who could actually do something if /usr would be unavailable anyway - Joe certainly wouldn't be able to poke around the system using /bin and /sbin tools to set things right.

If you're truly going for an easy-to-use idiot-friendly linux, you're going to have to take some tough decitions. Toss the old layout out the window, pick something like /apps, /config, /system, /documentation, or whatever - and spend a long time compiling stuff from scratch to make it work. I once had plans to do this but never reached anything usable (see LFS for a good beginning). You will probably be flamed until you glow red from people saying you're fragmenting the standard and what-not, but sorry guys, the current layout is for server-techs, not for Joe.

(Sorry about the rant)

If you feel like actually doing something like that, feel free to contact me.

But what if I don't want to go through RedHat? Why should I have to go through some company to roll my own distro?

Case in point. I love and use Perl for much of my work. I want and will build it from source. But if I want X-Windows, GNOME, and much, much more installed via RPMS from my Redhat CDs, I have to install the Perl RPMS. This is unacceptable to me. I recognize that RPMS make some things easy for Joe User, but they often make the basics impossible for me.

Tarballs are dead they say. Long live tarballs!

The more common people try to make common sense, the less sense it makes.

www.linuxfromscratch.org - They'll be glad to help you desing your own setup and guide you through the steps required to run off of a read-only medium. Most of the info is in the hints archive, I believe.

Why sit around and wait for somebody else to compile the images for you? Use a source based disto dammit, one that grabs the source to your system and then compiles it. As other people commented before, most linux apps are allready 64bit ready. Because most needs to be compileable on MIPS/ALPHA/SPARC platforms.

GCC(and binutils) supports compiling to x86-64 , this is still experimental though. But searching/looking abit in the mailinglist archives @ x86-64.org show that stuff like qt allready are comiling fine, only needing a wee-change in the makefile(Link).I think thats quite impressive, and im willing to bet good money that GCC has production class x86-64 support by the time the processor is actually available to buy.

So, armed with gcc and a version of Gentoo, Linux From Scratch or any other sourcebased disto that supports compiling the entire system from scratch. You will beable to create/compile your very own system, which can be WAY more optimized that anything a vendor does(i cant really see how its possible for a precompiled kernel images cant be optimized to a system).

The the only bad thing about thiese kinda of disto s is that big large packages as x/gnome/openoffice/what-ever takes for ever to compile. But on 64bit processor, who cares =)

"I say we need to take back our Linux and make it be know that's it's from the people for the people. "

Nobody has run off with it. The people can eat their fill. It was pretty clear from his recent interview that UnitedLinux isn't for the people, it's a package with a bow on it for business, addressing their concerns. Which is fine. That's part of the beauty of Linux, no one can have a monopoly on it -- not Linux hippies, not business, not anyone, but everyone is free to use it, and there's a flavour for pretty much everyone. After reading his interview it was pretty clear to me that I'll never be using UnitedLinux, but that's fine, I've got more than enough other choices. Heck, I can even build it from scratch. And I have.

Is this the first big "unofficial" fork of the Linux kernel? We've had different trees, but those have been maintained by people who are very close to kernel-development (I only know of AC, but I belive there are more), but this tree seems to have come out of nowhere? I hope this isn't the event that marks the beginning of Linux following of the old Unix history.

I guess that's the idea of a modular and open-source kernel, you can add things you want, remove things you don't want, but somehow adding patches from "outsiders" make me feel I'm not running a *real* Linux system - The way Linus Intended(TM).

OTOH, My LFS system is unique, with changes that make it different to standard Linux systems - including patches in the kernel - and I love the thing, so I guess there's no need to feel "guilt" over it.

Let's turn this topic around a bit and collect links to free books that can be found on the net. My favourites are:

• Dive Into Python - an excellent Python book aimed at experienced programmers
• Thinking in Java - concentrates on OOP principles. Check out Thinking in Python/C++/C# on the same site
• Secure Programming for Linux and Unix HOWTO - calls itself a HOWTO but it's practically a book
• Linux From Scratch - build your own linux distribution