I'm new to Linux. I'm lukewarm about it, but there are certain big holes in my knowledge.

Specifically, suppose I want to build a Linux app from source. Are the distros similar enough that they share the same directory conventions for installed programs? If so, what directory do I need to "make" in, in order for the app to work? Also, what entries do I need to make to any config files (presumably under /etc but correct me if I'm wrong) so that all I need to do is type the program name into Bash and it would start up the executable.

My level of knowledge is: I've got a decent familiarity with MS-DOS and that's about all (so I'm thinking about the equivalent to PATH instructions, bein in any directory to do a compile then link, then copying an executable binary file to wherever, etc). Please consider this when replying to this post. Do I really need to know about how the GUI works, or the libraries used by Linux programs, or other advanced stuff? I expected to avoid concerning myself about such things by installing a mainstream distro, but do I need to rethink? Can I just learn how to install stuff that other people programmed, without having to learn about how Linux works (because I'd rather not)?

Thanks in advance

Compiling Programs from Source -
http://www.linuxquestions.org/linux/...ms_from_Source

Filesystem Hierarchy Standard
http://www.pathname.com/fhs/

The more you know the easier things are, just like with anything else. Having said that, installing any of the top 20 distros on distrowatch.com is pretty painless.

It all depends on what you want to get from using Linux. Most big distros have their own package repositories and package managers that make installing programs relative simple.

Start by running a livecd like PCLinuxOS, then once you are comfortable with the way things work install one of the distros from distrowatch.com. The filesystems are pretty much the same although differernt distros can install apps a little differently.

One of the Linux for Dummies books is a great place to start out.

I don't think Linux will ever be "turn-key" in the way that Windows is-at its best. The benefit in Linux is in contrast to Windows at its worst.

If your computing needs are simple, then it is entirely possible to set up and maintain a Linux machine without ever opening a terminal and typing a command. When something is not right, however, many "helpers" (eg here at LQ) will immediately start giving you command to type.

But never mind all this---the way to find out if it is going to work for you is to grab a "distro" and dive in. While I recommended the Debian family--eg Ubuntu, Kubuntu, Mepis--you cannot go wrong with something in the top 5 on the "hit list" at Distrowatch.com

Thanks for the suggestions. If it makes things any clearer, I've been using DSL Linux for quite some time (although you will appreciate that "using" bundled applications and installing DSL binaries doesn't really amount to any learning), and I'm only encountering difficulties now that I want to install Slab (a hard disk recorder which is source-code only) and Muse (an audio program that in theory can be installed either with a Debian binary - providing that tons and tons of drivers and libs are already installed - or by compiling the source code as well as obtaining the other libraries and stuff for which there are no binaries). To install these apparently super-duper applications (Slab and Muse), it seems you really need to know what you're doing. This is where I come unstuck.

I hit up the other forum post here about the directories used in Linux, with a view to printing it out. But it was 55 pages long! And to use Linux effectively, I think I would also need to learn BASH scripting and the basic Unix commands. By that time I would be able to roll my own distro. This kind of fruitless learning is what I'm trying to avoid.

The funny paradox of this is: I find it easy to just "use" the Linux systems (Dynebolic and DSL so far). But there is an incredible learning curve just to do simple things. I'm sure if I knew how the kernel was working, how X-Windows works (for instance, why is it apparently a server-client local loopback?) and where all the libraries are kept and what they do, it would be easy because it's probably very well-designed and tweakable.

But why is any of it source-code in the first place? Am I going to poke around and "improve" Muse for instance? I don't think so.

more to your point. When you untar you should get a directory of the source files. Log on as root and get in a terminal window, or sudo yourself in a terminal window. Navigate to the directory where the sources are. The should be specific instuctions in a readme or something similar. But in a general sense you would first type ./configure, and wait a few while the configuration goes on. When the root prompt returns, type make. This will compile source files into the needed binaries. Again it will be a few moments to minutes. When the prompt returns type make install. Your prog will install and it should be put into whatever folders the programmer specified, creating any new ones it may need. Now this is typical, but readme will reveal any different procedures, and also clue you in on flags which you may set to get a particular compilation. Also it tells what command you can issue after installation to make the source files clean again, so you can store it away, or pass it along to someone. I store all my source packages, against the possibility that something may need to be reinstalled. Or sometimes I'd like to recompile with different flags. (Usually the result of not reading the readme, and getting a less than great install.) Finally the readme will tell what commond you need issue to run the installed program and where you find it. Some programs show up in your desktop environment menus and some don't. The best way to get that to happen is to let your package manager program do your installs if it will install from source. You can learn how to package sources into rpms or debs if your package manager requires those. Most packages can be obtained in either source or rpm anyway so you can pick and choose.

All this presumes your source are in C language. Most packages are, and you need gcc and its tools and libs, of course

Most software comes in source because they are either platform independent or yes, open source and therefore changeable. And who knows, you might decide one day you could make MUSE better. Various open source liscences require source code in the pack anyway. And when you compile on your machine you get a program that is specially tuned for your machine.

Thanks that was very helpful! So what you're saying is that subject to any specific instructions contained in the readme, it doesn't matter which directory I'm in, as along as it's the directory containing the source files, and that I'm root, and that furthermore I don't even need to list the names of the source files, because 'make' will handle that when I call it twice. It sounds much easier than I expected.

Good. Got all that stuff.

Aha! But how many different types of platforms is someone going to run a desktop app like Muse on? Probably only on x86, AMD64 or Mac. It doesn't need to be that portable.

Almost nobody is a good enough coder to understand and improve these types of apps. It's apps by experts, for experts to tweak, and because it's open source, companies are less interested in making dough out of it. No capitalists and no non-expert involvement equals nobody who *needs* to make the "consumer" happy. Frustrating if you just want to use your computer. Do the cops, firemen, nurses, etc. have the time or inclination to become good enough at C-coding to make good use of open-source? They probably don't for the most part.Anyway, I'm going way OT here so I'd better call it a night. Thanks for the help.

Many things to talk about here, thanks!

Firstly, the need to compile from source is greatly diminished now. Years ago it was the only way, then prepackaged binaries became more "the norm", and now it has reached a point where only the super adventurist or those interested in the sharpest point of the bleeding edge of progress need to install from source. If the apache guys release a new source package on Monday, there is going to be a .deb (Debian based package for it) on Tuesday or Wednesday. The .rpm (different package type) will also be in the low single digit days behind it. Now somebody in the Debian/Ubuntu/Mepis etc team had to compile that source, list the dependencies, and throw all that info into the .deb, but 99%+ of the people who use it never look at the source, and really don't need to. Beyond the work of compiling, there also is the maintenence. Say somebody finds a flaw in the aforementioned apache package. The .deb gets bumped in version from 2.0.36-1 to 2.0.36-2, and everybody running it uses their update program to automatically be notified, grab the newest version, put it in place, and be done with it. The poor S.O.B. who compiled it doesn't get a handy software notice that a new version is out, they have to find that release info on their own (then again, so do the package makers for .deb and .rpm), download the source, recompile, find out last time they did so forth, and so on.

For the most part, people compiling from source either do it in their home directory, or in /usr/local. The files that come from the compilation usually end up in /usr/local, so I tend to start there. That way if a package author wasn't specific about where to go, friendly /usr/local/bin is usually high in the $PATH, and anything made in /usr/local/ tends to dump its executables in there. As mentioned, with well written software, you can unzip and compile anywhere you like, and it will end up in a good spot, usually.

Yeah, mostly, but no. You probably would hit 99% of users with software that will build on those archietctures, but what if my home system is an alpha machine my school had no more need of? What if my rich parents bought me an ia64 (intel 64 bit)? Debian installs to all of these architectures - [alpha] [amd64] [arm] [hppa] [i386] [ia64] [m68k] [mips] [mipsel] [powerpc] [sparc]. I don't even know what a few of those are, but if people make OSes to run on them, then the code released should at least allow me to compile it on anything.

Peace,
JimBass