why is linux software often distributed source only???
 

why is linux software often distributed source only???

because of this i am not able use a lot of programs because I DONT KNOW HOW TO COMPILE FROM SOURCE!!!

I WOULD RECOMMEND EVERYONE TO DISTRIBUTE OPEN SOURCE SOFTWARE *IN BOTH SOURCE *AND* BINARY FORM*

BUT *PLEASE DONT USE RPMS*, THEY COMPLICATE SOFTWARE INSTALLATION, BECAUSE SOMETIME I ONLY NEED *ONE SINGLE FILE* IN THE RPM!!!!

OR ELSE I WILL NEED AN RPM UNPACKER!!!

-------------------------------------------------------------------
(*I'm not yelling, I'm just trying to get attention*)

You can use mc, the midnight commander, to inspect and I believe (untested) unpack rpms.

Source is vendor neutral, and 99% of programs can be installed using
"./configure && make && make install"

The problem with binary distribution is that there are many different formats. Distributions differ in where they put their files: some use /opt, other use /usr/local for the same purpose. Configuration files can be in different places, too. It would be difficult to provide packages for all architectures and distributions.

The reason for rpms and other binary packages is that they allow greater automation of installation, for instance, when using yum or apt-get.

Hope this makes things clearer,

Samsara

answer, binary installer wizards are harder to write and too much effort for most linux programmers to want to deal with.

Re: why is linux software often distributed source only???
 

STOP SHOUTING.

1. because linux targets several platforms ranging from i386 toAMD-64, and Motorolla CPU's, Sparc, Alpha, the cpu list goes on and on. Not to mention the differences in system Bus's, little endian versus big endian, etc.. One thing is constant with those, GCC works on all the platforms, a compiled binary does not. So you release sourcecode that will compile in GCC and keep one archived file for everyone. Saves you band width and storage space on the server just to mention a few benefits.

There is usually a MAKEFILE in the package and usually a README that tells you what make commands you can use to install the program. If not there is usually a script which will handle everything for you. Such as Firefox from mozilla you run the file called firefox-install and it will take care of everything for you. Or such as the kernel source, there is a readme file that talks about how to make the kernel. modules, etc. even tells you about rerunning lilo and setting everything up.

Now which linux distro are you using, BTW?

Wanting to shout louder
 

I am inclined to agree with, "User222". Hii... of course, I am newbie to linux to the boot! (Started trying using SuSe 9.1 Personal only since a 24 days back). Yes even rpm's are problem for a guy like me. I really miss those click, setup and wizard, and loo FINISH in the windows. Can anyone suggest any downloadable tutorial for Kinder garden user of linux like Me. No body around here in my place uses linux.... hell but I like the feel of difference in linux.

RPMs and other such packages are distro-specific, source code is universal. Binaries compiled for a generic, work-anywhere install, will never be as small & fast as a binary compiled for your specific architecture. Source code is available as soon as it's released, binaries & packages need somebody else to take the source code & do some additional legwork. Besides, not knowing how to compile is an affliction that only strikes new Linux users and it's easily curable :)

Compiling isn't the devil's work. Here's a short guide that'll allow you to install the vast majority of source code.

Create a directory in your /home directory called, say, source/ - not strictly necessary, but it keeps things tidy.

Download the source code into the source/ directory. It'll almost certainly be a tar'd and zipped file, something like foo.tar.gz, foo.tar.bz2, or foo.tgz

If it's a .gz file, gunzip it. If it's a .bz2, bunzip2 it

You now have a .tar file. The command tar -xvf foo.tar will take your tar file and create an organised set of directories from it. In your source/ directory, you will now have a file called foo.tar, and a directory called foo/

cd foo

At this point, it's time to compile the source code. The Holy Trinity of Compilation is:

./configure
make
make install

The first step configures the build for your computer: It finds where you keep files, what hardware you're using, that sort of thing.

The second step actually builds the program from the source code. What it DOESN'T do is put the files it builds into the right places. Everything it builds, it builds in the foo/ directory.

To actually put the files where they need to go, you need the third step, make install. This simply moves the files from foo/ to where they need to go. The problem with this is, you probably don't have permission to write to the necessary directories. Thus step three must be performed as root.

So, once you've done make, issue the command su -m

This command will log you in as root, but leave you in the directory foo/

Now, make install, and then log back out of root.

The foo program has been installed. You probably want to get rid of the foo directory, so:

cd ..
rm -r foo/

You probably also don't want the unzipped source code. Either delete it, or zip it back up small again. I recommend bzip2 over gzip, but it's up to you.

This won't install absolutely everything, but it's a reasonable guide to compiling from source that'll work for most simple stuff. The more complex stuff, RTFM! :)

Mudang: I don't use SUSE, but I thought that YAST does all the nice point-n-clicky stuff for RPMs.

The reason why compiling from source or installing from RPM/DEB isn't newbie-friendly is because your distro is supposed to package the software for you. When distros include a software package, presumably they've tested and configured it for you.

Most end-users should be using their distro's package tool to install/uninstall software: yum for Fedora, urpmi for Mandrake, YAST for SUSE, apt-get and Synaptic for Debian (and derivatives Knoppix, Libranet, Ubuntu, etc), Point-N-Click for Linspire, pkgtool for Slackware etc. These tools provide the "brain-dead" interface for user-installed software.

If you want to install software from source or from binary packages (rpm, deb), then you are essentially a leading-edge user, and you will have to accept that there will be some complexity as a result.

Also, if you are installing from source on an rpm/deb/tgz based system, you should consider using checkinstall instead of 'make install'. Checkinstall monitors the installation, and creates a package for your distro's package database, so that uninstalling is easier.

Can you explain a bit more..... I mean what if I had to do all above stuffs in the windows?? even a bit of comparision might help me! .... PLEASE DO NOT LAUGH AT ME....lol!!

If by "in the windows" you mean via a GUI - The only thing I can suggest is opening an xterm/aterm/konsole/whatever and doing it from there.

90% of the power of Linux is in the command line - trying to do everything graphically will cripple you. Sorry, but that's just the way it is. MS Windows revolves around pretty pictures. Linux has a few pretty pictures, but it's designed around text.

This is not 100% true either. A lot of things are making thier way to being used and done under Xwindows. The kernel now comes with make xconfig option etc... Eventually you'll be able to right click a file in a browser, and enter a comamnd line options, its just the linux community has a few crusty old conservative types it needs to get rid of. ;)

and by linux you mean unix there, but look at OSX, apple did a nice job of making a unix variant that is mainly gui based and configured, now if steve jobs would pull his head out of his ass and port that OS to an X86 platform.........

Which will be useless if you don't know the command line options in the first place, right?

So you'll still need to know command line stuff, right?

So the command line and working with text will still be important things to know, right?

Besides, that's the possible future. Right now, you can do far more with the command line than you can with any GUI. Hence my point still stands. You need to use the command line to use Linux to its full potential.

Hi Oneandoneis2,

I am getting around your idea a bit. The sad thing is that 'am not so familiar with Linux command structure or convention. But I suppose using Konsole/X Terminal in Linux would be analogues to using Command console in say WinXp. So my query was, is there any similarity of operation (not in textual form though) of logic using the Konsole/XTerm and writing command in DOS ways.

The immediate concern of mine is that I am unable to configure my PCtel Modem to work in my Linux OS. There is driver given alongwith the modem and configuration instruction given for linux. But almost a month and am still not able to do it. Hence I went for a External Modem D-Link V.92 Voice/Fax/Phone and its working fine (Presently Iam assessing the net through it). However I wish, I could make my WinModem to work also.

In the driver CD of the Pctel Modem a folder named Linux is present, I am pasting below what I show after opening a file called, "Install":


PCTEL Linux PCI driver, version 0.9.2
-------------------------------------

Description
-----------
This package contains the PCTEL driver for various PCTEL modems for linux.
It is meant for kernel 2.4.x, up to 2.4.18 so far.

Installation
------------
0) Unpack the tarball by typing "tar zxvf pctel-0.9.2.tar.gz"

1) Go into that directory by typing "cd pctel-0.9.2"

2) Find out what chipset you have in your board:

3) ./configure
Options:

--with-hal=hal
Select one of: pct789, cm8738, i810, sis, via686a

--with-kernel-includes=/path/to/my/kernel-sources/include
If you don't have your kernel sources at /usr/src/linux, specifiy
your includes

4) Compile the modules by typing "make"

5) If everything went fine, get root by typing "su"

7) Install the drivers by typing "make install"

8) You are now ready to use your modules.
Type "insmod pctel" and "insmod ptserial".

You should see in your logs ("tail /var/log/messages") something like:
May 16 23:28:17 suba kernel: PCTel initialization. Country code is 2.
May 16 23:28:17 suba kernel: PCTel device[00:11.0](0x88) found "PCTel Inc HSP MicroModem 56 (rev 01)" IOBASE 0xe800 IRQ 9.
May 16 23:28:17 suba kernel: PCTel driver version 0.9.2 [5.05c-4.27.215 (09-14-2001)]] (PCT789) (2001-08-18) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled.
May 16 23:28:17 suba kernel: PCTel driver built on [Linux 2.4.8 i686 unknown] with [2.95.3].
May 16 23:28:17 suba kernel: ttyS15 at 0xe800 (irq = 9) is a PCtel

Notes:
You can always uninstall the modules by typing "make uninstall". If you
need to recompile the modules, "make clean" and "make" are your friends.

Questions, Infos, Support
-------------------------
see README



---
Jan Stifter, 2002-03-04
j.stifter@[no-spam]medres.ch
http://www.medres.ch/~jstifter/pctel/

2001-08-05: Updated for Linux 2.4.7.
- Daniel Caujolle-Bert <segfault@club-internet.fr>

2001-08-08: Some bugs fixes/cleanups.
- Daniel Caujolle-Bert <segfault@club-internet.fr>

2001-10-29: some fixes/cleanups.
- JS

HAA, ALL OF THE ABOVE MAKES LITTLE SENSE TO ME AS OF NOW.
Anticipating encouragement from thee.

You may find http://linmodems.technion.ac.il/pcte...x/welcome.html worth a look, and http://www.peacefulaction.org/sayami...l#INSTALLATION even more so.

Internal modems can be a right sod to get working in Linux, because they often have the software do things that the hardware should do, and of course the software is only released for Windows. However, since you have linux drivers, you should be ok.

0) Unpack the tarball by typing "tar zxvf pctel-0.9.2.tar.gz"

This is a bad first step. It'll try and unpack the file to the CD, which won't work.
I would say start with copying pctel-0.9.2.tar.gz to your home directory, and THEN unpacking it. If you want to do this from the GUI, go ahead. If you want to do it from the command line, then it'd be something along the lines of:

cd /mnt/cdrom/linux - or wherever the CD ROM mounts
cp pctel-0.9.2.tar.gz ~/ - the ~/ is a shortcut that means "my home directory"
cd - The cd command on its own takes you back to your home directory.
ls This is equivalent to the DOS dir command, and lists the files in your current directory - it should show the pctel file. Once you know it's there, it's time for:
tar zxvf pctel-0.9.2.tar.gz

1) Go into that directory by typing "cd pctel-0.9.2"

2) Find out what chipset you have in your board:

3) ./configure
Options:

--with-hal=hal
Select one of: pct789, cm8738, i810, sis, via686a

--with-kernel-includes=/path/to/my/kernel-sources/include
If you don't have your kernel sources at /usr/src/linux, specifiy
your includes

You almost certainly have your kernel files in /usr/src/linux, so ignore the kernel bit.
The chipset, hopefully you know or can find with the paperwork that came with the modem. Or maybe on the CD. If not, you may have to open up your case and look at the modem.
Once you know what your chipset is, use the appropriate choice, such as:
./configure --with-hal=sis or
./configure --with-hal=pct789 - whatever is appropriate

4) Compile the modules by typing "make"

This, at least, is straightforward :)

5) If everything went fine, get root by typing "su"

Same here

7) Install the drivers by typing "make install"

8) You are now ready to use your modules.
Type "insmod pctel" and "insmod ptserial".

This ought to work. It might not work after rebooting, in which case you'll need to alter the config files to automatically load the modules on bootup. . .

Hello oneandoneis2,
Thanks a lot, I'll try and hopefully succeed. Before that, I 've figured out for myself that I need to know more about linux language and its ways. Any suggestion of links to start from scratch.
Thanks again.

I have to agree with the sentiment that installing programs for Linux isn't as easy as it should be. There should be an install program (in fact, I might try writing it myself when I have time) that takes a gzip/bzip2 source tarball as input and installs it automatically. It should be trivial to write... and it will hide the output of the commands, because do I really care about seeing 50000 lines of g++ command-line arguments when compiling a large program? I do not. Plus there are often hundreds of warnings, which evidently are meaningless, but annoying.