Linux

I'm trying to expand my very limited Linux knowledge. I don't understand what is meant by learning a particular distro, as when sj commented, "I think that it is still worth learning Debian...".

Isn't Linux, Linux? If I start with one distro, how much of what I learn can I expect to carry over when I load a different one? What are some of the activities that I can expect to have to relearn when I change distros?

These are the kind of questions that keep me from moving forward with my experimentation. I don't want to start with one distro and find out I haven't learned anything that will transfer. Some of the discussions make it sound like learning a new distro is comparable to learning an entire new OS.

the kernel and base cli tools are the same.
it all fits onlo one cdrom, as a live cd, and only uses about 300 megs of it.*

the problem with going between distros, which the lsb tries to address, is the different versions of the same library and applications.
If I write an application on a 2.4 kernel box, with only kde 2.0 and gnome 1.3 and gcc 2.3.3, your box has the 2.6.8 kernel and has kde 3.3 and gnome 2.4 and gcc 3.4.2.
the differences can break the application for your box.

some distros are still using the 2.4 series kernels, others are bleeding edge 2.6 series. ( 2.8 series will be out fairly soon it seems )

then the different package management tools, apt-get for debian base, rpm for red hat based, tgz for slakware based and the tar.gz / tar.bz(2) of the sources only distros.
with an application coded for debian, released in .deb, slakware and red hat and source based distros will have a battle to get it installed.
the differences in the toolchains, as well as in where every file other than the base toolset is located.

Mandriva even changes the location of the menu files for the guis, so you have to edit the sources to add thier path, or edit thier menus after installing.

the other pain is the dependancy issue.
try installing gphpedit, you need a specific version of the gnome vfs library, gtkskintilla and a few other libs, most of which have thier own dependancies, and it all needs to be installed in a specific order. ( no, there is no list of what that order is, you have to fumble it out for yourself ) oh, what's that, your distro has them all but not in the usuall place? then you have to tell the app, in the ./configure options where each and every one is installed to.

this is what he's reffering to.
it's also why a standard like the lsb is needed.

* with the sources for it all, but with also a compressed filesystem and specially patched kernel.

That clears up my confusion, although it's a bit discouraging.

I can understand apps written on an older kernel not running on a newer one. That's unfortunately no different from Windows.

I can understand different installation packages, but I don't know why someone would develop a program and then not make it available across all package managers.

I've been mentally thinking of dependencies the same way I think of Windows "DLL ****", and so far the comparison has worked.

Again, thanks. Your original post is now much clearer to me, and I can see why you feel some standards are needed.

it's not so much the differences in the kernel as in the coding for the application being set for only one version.
they use a structure of:
glibcver = 1.2 instead of glibcver >= 1.2
or, they built the app with gcc 3.2 and it won't build on a system with 3.3 because they "required" 3.2 only.

the linux kernel versions tend to maintain a significant backwards compatability. thread process handles stay the same, even though the actual handling improved.
so the fork() exec () calls work for 2.4 and 2.6 series kernels.

it's everything outsde of the kernel where the changes break compatability. :)
( don't try using kde 3 on a 2.4 kernel system, if you have a 2.6 kernel system also. )

with multiple distros, and versions on your system you find breakages that are caused by different versions of user pace software. ( I had mandrake 8.2 as well as 10.0 on same partions structure, using same home directory. the changes made between the versions broke the 8.2 for anything other than console. the commercial app I need the 8.2 for broke when the xserver broke.

The differences between Linux distributions is very like the differences between Windows versions, as you speculated. All of the basic stuff is there somewhere. The variations aren't all that bad. It mostly shows up when you try to install a software package that needs to be compiled from source code.

If you choose one of the popular distributions as your first you will be fine. Some like Red Hat, SuSE, and Mandriva, have advanced configuration tools to help you get your machine configured without a lot of pain. Debian, I have found, gives you a basic Linux environment and its apt/dselect tool. Otherwise is is just Linux. There's nothing wrong with that it's just that when you have installed Debian you have a very basic system. If you want a GUI you will have to install it after you finish installing Debian, which means that you will have to figure out how to install it, or anything else that you want. If you happen to have a need for a basic system with no frills then Debian will give you that. For instance I put Debian on another machine: AMD K6 366 MHz (like a Pentium II), 256 MB RAM, 9 GB disk. Debian easily fit on the disk with room to spare and runs very fast. It boots fast and runs fast.

I would recommend either Red Hat, SuSE, or Mandriva for your first Linux. They're all good. They're all popular. And there is enough in common between all Linux distros that learning one distro is fine for several years.

Linux is Linux under the hood. There are two major sets of filesystem hierarchy, though: one is used by RPM-based distributions, because they model their filesystem hierarchies off Red Hat, and the other is used by "the rest", and is a more traditional unixy approach to filesystem hierarchy (which means it's simpler, cleaner, and easier to understand when browsing through it the old-fashioned way). There are also three different types of package formats: .rpm, .deb, and "everything else". The .rpm packages tend to be very distro- and version-specific a lot of the time. The .deb packages are very portable between Debian-based distributions, as long as a given distribution hasn't played silly buggers with things like filesystem hierarchy or with permissions handling (think: Ubuntu). Anything not using .rpm or .deb files is probably using something unique to that distro (or small family of distros). Often, a given package type is not compatible on a distro that uses a different package type by default. Often, software that is not very well configured doesn't install properly on one distro when it was designed for another that has a different filesystem hierarchy.

When people complain, or in general discuss, "learning" a "new distro", what they're referring to mostly consists of the following:

dealing with the compatibility issues in using closed-source or half-baked software that was targeted for only one distro

dealing with differences in how package management is handled

dealing with the fact that sometimes you have to search a little harder to find where a particular configuration file might be hidden

Once you get familiar with two or three very different Linux distros, you'll have an excellent grasp of how to find stuff even when you move to yet another very different distro because, though they're very different from each other for Linux distros, they're still more alike than two Windows releases (let alone the differences between Linux and Windows). When we who've used Linux a lot complain about the differences between distros and talk about learning a new one, we're talking more about edge cases than core issues of moving from one distro to another.

Ultimately, the biggest difference you'll see between distros will be the default window manager and the way the installer looks.

The new debian-installer does provide a means for installing a default GUI setup, by the way, so you don't necessarily have a lean install of almost no software. I do recommend doing a lean install and only installing software as you need it, using "apt-get install", however. The apt system is the slickest, simplest, easiest package management system I've seen, and makes it not only possible but absurdly easy to start with a near "bare metal" install of Debian and build from there without any problems. It's the "best" (in my opinion) way of getting exactly the system configuration you want, no more and no less.

I'm not a fan of the "install everything and figure that means you have what you want" methodology. I don't need or want "everything". I just need and want what I need and want, and I very much want to not have a bunch of unnecessary cruft. Thus, I'm a fan of Debian.

like I don't agree with the standard specifying which package management system than I don't like rpm.

corrupt packages happen with all systems, when they have been transmitted over the 'net. not all the time, but I've even gotten .tar.bz2 files that couldn't be used.

The problem with rpms is that they can be build specific.

For instance a Mandriva (Mandrake) rpm may or may not work on a Red Hat/Fedora build. I HATE THAT! I hate it when things are build specific.

More and more I'm leaning towards Gentoo (the other Slack meat)