How to Install Anything

I really don't want to consider switching Distro's I am just getting familar with Linux, and so far I like Ubuntu.

On the other note I have tried this as the root user. First thing I did was access sudo su. So any other idea's or solutions I really would love to get this to work.

I have to decline on this one. Using a distro that doesn't have 'make' and the rest of the compile tools is not worth the effort. The enduser often doesn't grasp how much work they signed up for. One member was flaming mad about zero support for a years old version of Red Hat. Again the issue was fairly simple to solve by moving to a current version but they refused and flamed anyone that noted that it was time to move up.

Change distros and you'll find it a lot easier to deal with.

Bob

It's pretty sad if Ubuntu doesn't come with make(1) and gcc(1). But if you wanted a software development environment you'd have chosen a fatter distro. Ubuntu is about end-user-friendly workstations. They say they chose only a small subset of Debian so they could concentrate on quality, not breadth. End users don't run make very much.

So maybe you wanted gcc and make on your pretty GNOME station. It's a reasonable request. Try looking for them in Synaptic. If that doesn't work, try typing "apt-get install make gcc". What the hell, if you break Synaptic by running the lower level command, it's probably easy enough to fix.

Thank You very much your help it is greatly appreciated. I have done what you have told me and for the first time I feel as though I am getting somewhere. However the procedures you outlined did not work. The computer has not detected the NIC therefore there is no eth0 however the e1000 file is shown in the /etc/modules so that does mean that the driver was loaded successfully.

You did give me instructions if the NIC was not detected. However the instructions you gave did not do anything. Do you have anymore suggestions? Thanks in advanced.

If e1000 is in /etc/modules, it means the Debian/Ubuntu installer saw it. If there is no eth0 in "ifconfig -a" then the currently running kernel did not see it. /etc/modules is not a list of modules currently loaded. It is a list of modules the boot script should try to load at boot time.

Look at the output of "lsmod" to see if e1000 is actually loaded. Immediately after booting, get a root shell and go "dmesg | less" to see the messages from the kernel during the boot. If the boot script tried to load e1000, there will be a line announcing that. It might even show a copyright or an email address of the driver's author. (but don't send email there.) Then there will either be a line showing the condition of eth0 (link is up or down, half or full duplex, 100 or 1000 Mbps...) or there will be an error message about why the module failed to load.

If there was no attempt to load the driver, the boot script is not reading /etc/modules properly. You should still be able to load the module with "modprobe e1000" creating an eth0 interface manually. If e1000 fails to load, it will say why. Or at least it will say failed. If it didn't say anything, it loaded correctly.

If the driver load failed, something is different between your system at install time and now. Do "lspci" to see what is on your PCI bus. You should see an Intel NIC there. Do "lspci -v | grep -A 6 Ethernet" to find out more about it. (That filter is Global Regular Expression Print, And Six lines after.) Try " ifconfig -a | grep -A 9 ^eth " The circumflex says eth must be at the beginning of the line.

If the NIC is there, and it really is an Intel 10/100/1000 chip, and e1000 doesn't load and create an eth0, something is really strange. Are you sure you did "ifconfig -a | less" and hit spacebar enough to see the entire report? Did you leave off the " -a"? Then interfaces that aren't up yet won't show. -a means All.

Swapped the hard drive out in favor of another machine. Apparently my assurance of the NIC card be fully operational was not correct. Although Windows XP was installed and supported by myself before putting Ubuntu on the sytem the NIC card performed flawlessly in the domain. I am currently running diagnostics to ascertain what happened between the Windows to Linux transition. The final clue for me is when I looked at the PCI component list and the NIC was not included on that list.

However the machine that I did swap with had no problem what so ever the driver and the NIc booted up flawlessly and my network connectivity is flowing like a charm. I am very happy that this issue is resolved because I do like Ubuntu, I have tried Fedora and didn't care for it as much as I do Ubuntu. So I'd like to thank you.

I still have one question though. It is my original question "How do you install anything?" Software wise, I read the instructions off of the vender and online resources but I am not having any luck. All the instructions for different applications seems to have a similar setup cd to the programs directory after untar and then

./configure
make
make install

Thats all well in good except the make command is not recognized in Ubuntu neither is the ./configure, so I can't figure out how to install anything. Do you have any tips or instructions? Is it this difficult to install software in general. Or is it as easy as installing in either Windows or Mac Os? Thanks a lot.

There are basically three ways to install free software in the free unix (GNU+Linux or *BSD) environments.

1. Use your distro. Most of the popular distributions are rather comprehensive. Chances are if you want it, it's available through the distribution's repositories and automatic package updates. Do it that way if you can. apt-get( or aptitude( or Synaptic in Debian and its derivatives such as Ubuntulinux. urpmi( or yum( or yast( in things that use Red Hat Package Manager such as SuSE and Mandriva. Maybe the package you want is in an independent repository and you have to tell Debian or Red Hat to look there. On Debian you edit /etc/apt/sources.list

2. Get pre-compiled "binaries" from the software's web site. This is called "going upstream." For example you can get the latest MySQL from www.mysql.org or Seamonkey from Mozilla.com or Openoffice.org from its site. They come packed up in compressed tarfiles and you follow the instructions to unpack them. Sometimes there is an install script after unpacking. Your Debian or Red Hat installation doesn't know they're there, so it's up to you to keep up with security and bug fix updates. You have to take some care to install them in directories your distro doesn't use for the same packages. That's what the /usr/local, /var/local, and /opt directories are for.

On Debian (including Ubuntu, Linspire, PCLinuxOS...) there is an "equivalents" procedure where you can inform the distro that one of your outside binaries satisfies certain package dependencies. For example, Debian demands *some* email transport, the mta dependency. The default is exim-lite. But you could get the latest and greatest Postfix and use that. You'd need to tell Debian that your Postfix provides "mta". Otherwise you'd "break" Debian by removing exim-lite.

3. Get the source code and compile and install it yourself. You are taking on the job that the package maintainer does for your distro. That person is often an expert software developer. You'll need GCC, GNU make, and whatever "development" library packages the source you've chosen requires. You might need "kernel headers." You might need arcane development tools like xmkmf. You might need the LaTeX and/or Docbook SGML tool chains to build the documentation. You'll sometimes have to figure out what's different between the developer's build environment and yours. My advice: try something simple that builds perfectly before you take on something your distro doesn't even have. If you can't find and get and make and install GNU gzip, don't try to make your own Tux Racer.

Many source code packages follow the GNU standards. They're put together with GNU Autoconf, which produces that ./configure script you were talking about. If they do that, you can often go "cd /usr/local/src && tar xzf whatever.tgz && ./configure && make && make install" and it will all "just work." But you'll probably want to tell ./configure to install your locally built stuff in some other directory than its default. Maybe "./configure --prefix=/my/secret/installation/directory" Try "./configure --help" to see your options. Read the README and INSTALL files in the top level directory of the unpacked tarfile.

Some developers include a top level ./debian directory in their source distributions. If so, you can usually "make debian" or "make deb" and they will produce a .deb file that you can install with "dpkg -i". This should take care of the equivalence thing for you.

If your GNU+X+Linux distribution doesn't recognize and install common, supported hardware like Intel's NICs, it's broken. Don't just complain about it in some random place. Figure out *exactly* how to make the failure happen. Go through the install again and *take notes*. (Early in the install, the installer probably asked you if it had discovered all the necessary modules to complete the install. Did you just say "huh" and blow past that, or did you make sure it had found e1000?)

Read Eric Raymond's excellent essay "How to Ask Questions the Smart Way." Google for it. Then look in your distro's Answers to Frequently Asked Questions and see if the problem comes up a lot and there's a well known workaround. Google for *that*. Find the *right* forum to ask if anyone else has seen this bug recently. Chances are you'll find several other people asking vague questions about it, and not getting any answers. Those people didn't read Raymond's essay.

Poke around your distro's web site and find its bug reporting procedure. Search it to see if a related bug has already been reported. If not, get out your notes and write a really great description, complete and concise, in the bugs for that package in that release of your distro. Whining vaguely in the wrong forum is worse than useless. Capturing a precise bug description where someone will do something about it is a *significant public service*.

Now you know where Free Software comes from. You have to give something back and even the little things help. (Why do you think I'm answering questions here?) We don't make a distinction between "developers" and "end users." We're all users and we're all developers. Some of us are just a few pages ahead of you in the manual. Others, believe it or not, are behind you. Documentation is never complete.

If your bug was good enough and the package isn't abandoned, it *will* get fixed. If your bug was "operator error" but your description was professional, they'll close it with an (perhaps impatient) explanation. If you really feel it was unreasonable to expect you not to make that error with the instructions presented, file another bug, against the installer or the documentation. Documentation bugs usually get fixed, especially when you suggest replacement text. (Usually. Don't bother reporting vagueness in the Procmail or Postfix manuals... Dr. Venema told you what Postfix does, not what it doesn't do, and that's final! Forgive him for being a genius.)

Finally, go back to that forum with the frustrated whiners, and answer the question. And tell them where they could have found the answer and why they didn't get one. But be nice about it. They just don't know how to ask Smart Questions yet. Nobody ever told them they were expected to.

I was reading up on the fluxbox theme and was wondering if anyone knows if it replaces the kde interface, or do i need to reinstall.

So by installing this repository I will have full functionality with the ./configure and make commands? Why does linux work this way, obviously this is an essential repository for a users normal use in Linux, why make it something that must be added later, why not just install all essential repositories at install? And do you also have anu other repositories that weren't installed that you feel that a user will need? Thanks a lot?

I think you missed the point a little bit. The free software community would appreciate it if you contribute, by reporting or fixing bugs or taking responsibility for a package in a distribution. But only a very small fraction of GNU+X+Linux users do that. Your distribution probably has the packages you need, ready to use. Look there first. Your distribution has instructions about getting new software. Read and understand those. Just as importantly, find the new users forum *for your distribution*, and learn to use it well.

Install the software development tools *if you want to do the kind of work package maintainers do*. Or if you want to learn how to write computer programs. Personally, I think it's an essential part of computer literacy to use a command interpreter like Bourne Shell (which leads inevitably to saving your more complex commands in files, and that's a shell script) and even write and run the simplest programs in C or Perl or something. Do the first exercise in Kernighan and Ritchie's _The C Programming Language_; it's good for you. (That is, compile and run this: main(){printf "hello, world!\n";} It means you got the tool chain working.) Build and install something from the GNU source distribution. But that's a minority opinion. Most people never touch the stuff.

The ./configure command comes with a typical GNU style Free software package. Each one is different. You can't "install" ./configure. And until you have some working knowledge of shell and make and C, you can't write one either.

print "Perl users do it more than one way!\n";

echo Shell users are too busy to do it that way.

I do, do programming, quite a few languages actualy but I do it for fun. Up to this point I do all my coding and developing on a Windows platform.

Tend to gravitate to distros that have the compile chain handy. This is one of my reasons of moving to PCLinuxOS 2007 RC3 (it's current version) is that the compile tools are pretty complete on the basic install and with Synaptic more can be fetched in a hurry.

I'm been flamed for not duplicating ready web content about how to add the compile chain to other distros but it's something I had to choose since the other path would be nothing but a dark pit of endless discussions.

Bob

The first GNU-Linux distribution I ever really used was *nothing but* tool chain. It was called "the GCC Release by H,J, Liu" and it came on something like five floppy disks. You booted the kernel from a raw image on the first, and it mounted the second at /. You made a file system on a disk partition with that system (fdisk(8), mkfs(8), and copied the working system there with "cp -a". Then you could boot your hard drive from the first floppy and make that partition bootable with lilo(. Then you could mount the remaining floppies and "tar xz" the GNU toolchain and the Linux additions (binutils and the linker) into place.

Aside from the novelty of a free unix that actually worked right, the remarkable thing about GCC Release was the documentation. It came in a couple of short emails, and told you everything you needed to know and nothing you didn't. I wish current GNU-X-Linux distros were as complete. Stuff is a lot bulkier now, and frankly a lot more is broken. Makes it harder to jump the perspective barrier from end-user to *participant*.

There was another really cool one the next year. "Milieu" was the course book for an introduction to computer science, unix, and programming. It came with the GCC tool chain, but the introduction to programming used Donald Knuth's Metafont language. Later exercises used TeX, LaTeX and C. The book had a bunch of nice figures, special fonts, and diagrams, and you could teach yourself programming and electronic typesetting by learning the tricks that made the book so attractive. It worked because the exercises were so visual and there were no forward references, and because *nothing was broken*. You could get and print a Postscript image of the book beforehand, or do the installation and *make(1)* the book with the toolchain from GNU (Stallman) and Stanford (Knuth). Came out of a little Christian college someplace. It's too bad so much of that kind of thing has been bulldozed. No shareholder value in LaTeX and Metafont.