Doomed said:
I just formated a HP Compaq dc5700 (small form) buisness comp and
Installed Xubuntu on it. I am finding out that getting drivers for
this thing isn't as straite forward as windows. I went to HP site and
(no suprise) no support for linux there. I tried the internal search
for drivers tool and it came up blank. Also, once I find drivers I'll
have to learn how to install them. I know I'm going to have to learn
unix cmd line. A really good tute on all this would be nice. I'm doing
some searching on my own but If someone has a favorite tute to suggest
for beginners and where to find drivers. One that can pretty much
spoon feed me at first till I get the hang of it.
Thanks,
Doomed Soul
I don't know if I can do a good job on the subject, but I'll try.
http://en.wikipedia.org/wiki/Xubuntu
So underneath, it's Ubuntu, and you'd look to the ubuntu.com site
for help. Sometimes, there will be a HOWTO on a particular issue,
which is hosted there. The quality of those, can vary considerably.
Hardware level interface issues ("drivers") aren't uniformly treated.
Some parts of your hardware get treated better than others.
The kernel contains a lot of the low level drivers already. The
kernel is developed separately from each distro. A central body
works on the kernel, and then each distro "builds" their own
version of the kernel. That means, going into a tick box menu,
and turning on the inclusion of support for various pieces of hardware.
Then, after a ten minute compile session, the kernel is baked and
ready to be used. (Your LiveCD will already have several kernel
files, all baked and ready to go. So a new user doesn't have to
learn about this, right away.) This is an example of the interface,
to set hundreds of different options. You'd be surprised the
things you miss in here, the first time you go through it.
http://newbiedoc.sourceforge.net/images/menuconfig.gif
Disk interfaces should be integrated into the kernel, and generally,
all the tick boxes will be turned on when the kernel is built.
Linux isn't inherently a GUI equipped OS. It can also be operated
in a text only mode. And many admins, when setting up Linux servers, will
have no use for setting up a GUI for the computer. They may even
SSH into the box, and remotely administer it. (You could run a Linux
box, "headless" if you want.)
The GUI, when provided, is based on Xwindows. Currently, this would
be referred to as Xorg (the supporting site would be x.org). Xorg has
some elements built into the kernel (such new innovations as
"kernel mode setting" for example). But Xwindows doesn't always start
properly (for example, I work a fair bit with Linux distros running
within Virtual PC 2007, and see a lot of failures there). If you're
booting a box with your Live CD though, chances are you'll get some
level of GUI support, see a login box and so on.
By default, Xorg may use a "VESA driver" for the graphics. That is
a generic driver. Since virtually all graphics cards support some
basic VESA operating modes, that guarantees you'll see a GUI (a lot
of the time). You can then switch to a binary blob driver, such as
going to the Nvidia or ATI sites, and getting their Linux packages.
You may see an improvement in OpenGL performance by doing so. (Maybe
your copy of Quake3 will run faster. I've had Quake3 running in Linux,
using map files from a Quake CD.)
For wireless, sometimes the recommended recipe is an "ndiswrapper" and
an actual Windows binary for the wireless gear. In that case, you
might Google on the name of your wireless, and see how it's supported.
You use programs such as "lspci", "lsusb", "lshw", to list the hardware
contents of the computer. That gives you the necessary hints, as to
what to Google for when resolving hardware interface issues.
In summary:
1) Drivers don't mean quite the same thing as they do in Windows. In
Windows, the subject is treated more uniformly. Linux can support
hardware, either in kernel space, or in user space. For example,
webcams would have been user space a couple years ago, but for
reasons that escape me, they've moved the webcams into kernel space.
The first kernel space version of webcam support I tried, crashed!
Most impressive.
2) Attack your hardware subsystems one at a time. You're going to learn
about hardware sooner or later. For example, a lot of distros, don't
enable sound by default, and it'll take you a day or two to sort that
out. Some distros have the nerve, to set the volume to zero on each
boot, so you have to do crap each time you startup. Again, not that
impressive.
3) Some distros, simply have better user land support than others. The
folks at Ubuntu mean well, but the community based help provided is
very uneven. By comparison, the Gentoo distribution may be laughed at,
for its reliance on building from source. But the recipes the Gentoo
community provide, all work, and work well. With Gentoo, I was able
to build an environment from scratch, learning as I went. Most of the
time was spent compiling. The recipes were all there. With Ubuntu,
frequently I'm forced to separate the bad advice from the good advice.
This was particularly hard with PulseAudio, as the community gave the
impression that PulseAudio could not be removed (safely) with package
manager. I eventually tried it myself, only to find that the impact
of doing so was minimal. Not nearly as earth shattering, as the community
advice would make it seem. (The package manager wanted to remove something
called "desktop", which looked scary by implication, but the word "desktop"
was poorly chosen, and I suspect was done that way on purpose.)
With Gentoo, it was even easier, as by setting a flag for "minus PulseAudio",
the environment built, seamlessly, without it.
No matter what distro you're going to use, you are going to learn something.
You'll end up in a terminal window eventually. In fact, on my Gentoo
virtual machine, the only thing I populated in the Gnome desktop manager,
was a command to launch a terminal. None of the other stuff has been
set up. I've got a Firefox button somewhere, so starting a browser isn't
too hard.
So each piece of hardware you work on, could either have drivers
already in the kernel, or it could involve something as crude as
a Linux wrapper around a Windows binary (that actually works pretty
well). And you learn about each case, one at a time. It's not like
slipping in a driver CD, and bingo-bongo, all the hardware works.
It takes a bit more work than that. Some hair loss. Some cursing
and swearing. You get the idea.
As for fixing bugs, once you've been Googling a lot, you'll find
that the rate of bug fixing is pretty slow. Some of the bugtracker
threads I've read, users can suffer the same problems, over three
different distro releases. So some things simply get no attention
at all. However, if something didn't work on Linuses desktop, then
I bet it would get fixed
A little publicity, works wonders for
bugs.
*******
A worst case scenario for Linux, is
1) Being trapped in a distro, where the GUI is broken and Xorg
won't run. Now, you can't (easily) run a web browser. You
can use Lynx of course, but much of the content is invisible
that way.
2) Your stupid Ethernet interface won't start. My batting average
with that stuff, is simply terrible. Sometimes I go in, do an
"ifconfig" and there is no "eth0". Or, I'll have an etho, but
the environment doesn't have a working "ifup" and "ifdown". It
takes eons, to sort that out (if ever!). I've been defeated
on a number of occasions.
3) Anything that prevents your web browser from running, is the
hard part. If your LiveCD can browse to the web, chances are you
can find a HOWTO. And then, you might just fix it. But if you
can't get the GUI running, Firefox won't run, or the network
interface is broken, then those are tough to put right. One
of the reasons I do so much work and testing in VirtualPC 2007,
is I can use my Windows Firefox, and sort issues with the
Linux running in a window. That's much easier to deal with.
This is what Linux looks like, running inside a window on your
WinXP desktop. You hold down the <alt> key, and then you can
move the mouse cursor outside the window. You can minimize this
window, and then you're back staring at your Windows desktop.
I have more than half a dozen distros set up in such an
environment. VPC2007 isn't the best, because the Linux crowd
now use a lot of facilities, that aren't emulated in VPC2007.
And that's why I had to work so hard, to beat them into shape.
I'm still not finished. (Most of my issues right now, are
audio.)
http://www.linuxlinks.com/portal/content/reviews/Windows/Screenshot-VirtualPC1.png
HTH,
Paul
