Okay, here's what's on my mind. The more I try to learn how to use Linux, the more I find myself trying to understand it by comparing it to Windows, but I don't mean that as in which one is better or something, I mean this:

First question: In Windows, when you install a program, it has a default location, C:\Program Files\
In Linux, where are things installed to? Because more often than not, if I manage to install something, there's no shortcut on the desktop, no shortcut in the taskbar menu's, and I never find the program, or how to turn it on.

Second question: What are the common linux file extensions, what are they for, how are they handled to get them to where they can be installed, and how are they installed?
I assume .RPM in Linux is basically the same thing as .EXE in Windows, right? What Linux extensions act/are handled similarly to what Windows extensions?

It would greatly help me, as I'm sure it would help other newbies, to know what each file type is/does, and instructions on how to install a program regardless of the extension, so that when we go to install something, run something, or whatever, we know what to do and how to do it.

If anyone could provide answers to the questions above, It would greatly help my, and probably other's, understanding and comprehension of Linux .

Thanks!


Tib

Some interesting questions there!

I can't shed any light on them as I'm in the same position as you, but I'd be interested to hear some answers

J

Trying to understand Linux in terms of Windows terminology is a losing battle. For one thing, "extensions" on file names mean absolutely nothing except insofar as they help the user identify what type of file it is. The OS will look at the file and decide for itself. If you renamed a .mp3 file .rpm, then opened it, Linux would play you a song, not try to install it.

Installing programs is best done by using your distribution's package management system. For Fedora, that would be "yum", and for Ubuntu it would be "aptitude" or "apt-get".

Spend some time reading about the package manager you want to use, and when you successfully install an application with it, you will probably find it on the menu. If you really want to know where the various files get placed within the file system, you need to study the File Hierarchy System, but that's well beyond your needs at this point.

Just a few answers:

Where do programs go? There are few rules, but many conventions. Mostly, you will find the system stuff in /bin or /sbin. and the user stuff in /usr. sometimes, people will put non-standard things in /opt. (I do this for anything not installed by the package manager)

Menus: If you install with the package manager, the menus should get updated automatically. Otherwise, you have to do it by hand.

.rpm vs .exe: NOT the same thing. .rpm denotes a particular package format, whereas .exe is the extension of a Windows executable file. An .rpm package can be used to install executable files (which do not have an extension in Linux)

There are many reasons to try and ALWAYS use the package manager / repository system to install SW.

In Linux there is no C:\Program Files\. programs that use a graphical interface usually install in /usr/X11R6/bin, but not nessecarily. Usually to run a program that has no menu entry or icon, you just type its name in the terminal and press enter for example, to launch firefox, type firefox

.rpm and .exe are completely different, .rpm is more like .msi, rpm files are the file that the package manager uses to install programs. programs usually have no extension in linux, because linux only cares if you have the permissions to execute it. Other then that, most extensions generally do the same thing as they do in windows, like a mp3 file will be called <file>.mp3

actual programs are usualy installed somewhere in the $PATH or at least a link is.

to see the path run

Most programs that use X11 are stored in /usr/X11R6/bin

on my computer(fedora 7 upgraded to 8) I do not even have a /usr/X11R6/bin/ folder

there is no such thing as /use anyways, so it wouldn't suprise me, /usr/X11R6/bin, exists on Ubuntu, Slackware, Debian and Gentoo for sure

There is a publication on the www.tldp.org website called the Linux Filesystem Hierarchy System that explains the file system.

The /bin directory is where the core utilities are found. These can be run by both root and a normal user and are needed for a minimal installation. The /sbin/ directory contains admin programs needed for the system to run. the /lib directory contains static and dynamic libraries needed for the system to run. The /etc/ directory contains configuration files. One big difference between windows and Linux is that windows stores it's configuration settings in opaque registry files whereas in Linux they are normal text files.

The /usr/ directory contains it's own hierarchy with /usr/bin, /usr/sbin/, /usr/lib directories. When you install a package, it usually uses /usr/ for the base installation directory. After /home, the /usr directory will probably be the largest on your system, and will grow with time as you add more programs.

There are also personal configuration files contained in your home directory in hidden files and hidden directories. For example, if you use KDE, there is a ~/.kde/ directory. Individual configuration files for KDE programs can be found in $HOME/.kde/share/apps/<program name>/. This is a KDE convention.

You asked about extensions. When using a web browser, it will use mime-types which depend on the extension of a file, but the Linux system itself doesn't rely on the extensions. For example, the "x" bit will determine whether a program can be executed. For a script, the first line often contains a line like "#!/bin/bash" which tells the kernel to run the script in a bash shell. It could also have "#!/usr/bin/perl" or "#!/usr/bin/tcl" instead to run perl or tcl scripts instead.

There is the file system which can analyse files and filesystems based on a database of what it finds looking at the contents.

example:
There are other differences as well. Linux has a monolithic kernel. The Windows NT kernel is a microkernel (in theory at least). Minix also has a microkernel, and GNU is developing a microkernel as well. There is an ongoing debate on which is better. A monolithic kernel is easier to write for and debug and so Linux kernel development reached critical mass quicker. The hurd kernel hasn't attracted as many developers.

In Windows, you run a binary executable to install driver files when adding equipment. In Linux, you modprobe a kernel module so that the equipment is recognized. Often, manufacturers don't support Linux and it is up to Linux developers to write these kernel modules on their own. An irony is that because Linux has been running on 64 bit systems for quite some time (beginning with DEC's Alpha chip) many of drivers developed for linux also have 64 bit versions. On Linux you will have better luck with 64 bit drivers than on 64 bit Vista!

Unix has design feature that "everything is a file". The C language was developed on and for Unix. So there are features of Unix that were inherited by Windows via the Standard C Library. Also Windows 2000 and later used the BSD Networking code for it's IP stack (without the attribution required by the BSD license at the time). When Linux was being developed, BSD was involved in a court case, so the Linux developers developed there own. This was done mostly by Alan Cox.

Linux uses the bash shell be default. It is on every linux machine. At work when our Adtec server was being installed, we found that all of the old spots that had less then 6 characters in the name had to be renamed with preceding 0's. In Linux, with such a problem, the first instinct is to write a one or two liner in the shell. In Windows, the installers downloaded a GUI mass rename utility on the web, installed it and ran it.

In Linux, the source is in the open. Windows is propriety, as well as most programs you install. Even the configuration is opaque in a registry, whereas in Linux, text files are used. The open vs opaque may be the main philosophical difference between windows and Linux and even characterizes open standards. Some RFCs submitted by windows contain riders making Windows standards less than open standards. Linux is developed around open standards. Complying with standards is very important. Windows will embrace an open standard and modify it so that it is only useful for Windows, leveraging their monopoly to make the standard less useful. Examples: Kerberos modifications, Active Directory (based on LDAP), Java, their Open XML (with opaque tags). Security wise, the philosophical Open/Opaque difference causes Windows to be reactive whereas Linux must be proactive in its bug fixes.

Ahhhhhh thank you thank you thank you THANK YOU! Those replies answered many questions I had.

Also, about how to install things, I realize it's better to use the software manager that comes with whatever distro I'm using, but like, for example, I'm unable to find drivers for my ATI graphics card, as well as monitor, they're not in the repository, nor does linux have them in the system, and ATI's website says their drivers are only for Red Hat Enterprise, and two other dirsto's (neither of which I use). I was wondering how to install different types of files, because when I'm unable to find something in the default repositories, I have to find it online manually, and there's usually 3-4 different types of files, such as .BIN .RPM .TAR(i think?) .SRC.RPM(source code?), and it all comes down to the fact that if it doesn't install itself when I double-click on it, I might as well delete it, cause I haven't a clue what it is, or how to run/install it.

I was also wondering, what does it mean when something has to be "recompiled"? from what I've read, do you download the source code for something, and have your installation compile the source code itself? so that it's compiled specifically for your distro?....or do I have that all wrong? lol, and if I have it right, how does it all work/what're the commands for it :-P.

Thanks!


Tib

.rpm files install with the command rpm -ivh or in fedora they should install when you double click on them. tarballs are sourcecode, they are kinda like zip files, to untar them the commands are:
for tar.gz
tar xvzf <filename>.tar.gz
for tar.bz2
tar xvjf <filename>.tar.gz
for tar
tar xvf <filename>.tar
src.rpm files are source rpms, I forget what do with them at the moment
when you compile software, you change the source code from human readable format to machine readable format. You download the source for a program yourself, and untar it(see above). to compile software usually you type
./configure
make
make install
./configure checks that you have all the stuff needed to build the file
make compiles the sourcecode
make install copies the resulting files to the right locations
when you compile something, you compile it for your processer, it makes it slightly faster, because its optimized for your machine

Tarballs are not always source code.

You are my HERO! lol.

Okay, so you would open the terminal, go to the directory with the tar/gz/bz2 file, and execute the right command for that file type to decompress it? and then if it's the source code, you compile it/install it, or if it's then just an RPM, you double-click it to install? or run the command: rpm -ivh <filename>.rpm ?

When compiling the source code for a program, do you open the terminal, go to the directory with the decompressed source code, and just type the commands:

./configure
make
make install

? or do you have to specify the source code? Asking just to be sure :-P.



Tib

A helpful piece of info that I didn't learn early on:

When you start experimenting with ./configure ; make ; make install you're eventually going to run in to the problem where your program compiled and installed but when you type the name of that program, it doesn't launch.

The reason for this can sometimes be that "make install" deposits your program to /usr/local/bin (or some other location) which may not be in your $PATH.

So at that point you'll have to type /usr/local/bin/program_name, or modify your path. Or what I eventually learned to do was look inside the files in the source directory to see where the configure script would throw things. Or you can append --prefix=/usr to the ./configure statement.

Same thing can happen with man pages too.