Hello,  I have an HP Pavillion dv2000 laptop that's about 1 year old.  The
hardware is exactly as it came from HP.   The preinstalled Win Vista on the
laptop got broken and I want to try something new.  I am fairly computer
knowledgable.  I have made many home-built PCs, however this is the first
laptop I ever owned and I've never seriously used Linux.  Now I am thinking
I will try Ubuntu on this laptop.  I've heard that driver support for some
Linux distros lags way behind.  Do you suppose I will have driver issues
between Ubuntu and this HP Pavillion 2000 ?  I do want to use the wireless
internet and the sound hardware. I don't mind spending a little time
searching for drivers. But what if drivers aren't available or they have a
lot of bugs?

Does anybody here use Ubuntu on a HP Pavillion?
I hope someone here will give me some advice about this.

TIA.  Bill S.

<fake disbelief>

        Really?  How on Earth could that be possible?

</fake disbelief>

:p

So in other words, you do have at least *some* GNU/Linux experience... ;-)

Yes, we hear that all the time as well, but funnily enough, this is all but
true.  In fact, the Linux kernel as used by most distributions are the most
recently available /vanilla/ sources - i.e. the official kernel sources as
they come from Linus Torvalds and the kernel developers - at the time of
the start of the distribution's development cycle, added with some
distribution-specific patches that add functionality or fix bugs - the
bugfixes are usually backported from the in the meantime newer /vanilla/
kernel.

In every GNU/Linux distribution that I personally know of, the kernel always
comes with *all* available GPL'ed drivers installed on the hard disk.  In
other words, there is no jukeboxing with CDs or DVDs afterwards anymore,
unlike in Windows, which largely relies on driver CDs from the hardware
manufacturers.

There will of course always be stuff that's not supported, but this doesn't
have anything to do with lagging behind.  Much rather, it has all the more
to do with the fact that certain drivers are proprietary software and may
not be distributed freely with a GNU/Linux distribution, but then you can
still fetch those drivers from the manufacturer's website.  They are
usually free of charge, but not freely licensed.

Among the proprietary drivers, you will find a lot of drivers for wireless
ethernet chipsets, and of course the proprietary nVidia and ATi drivers.
GNU/Linux does usually come with drivers that can get nVidia or ATi
videocards to work, but those free drivers won't support hardware 3D
acceleration.

Still, most of the common hardware out there today is supported in one way
or another in GNU/Linux, either by the hardware manufacturer offering their
drivers under the GPL - upon which case the source code will be included
into the kernel or related projects such as X.Org - or by the kernel
developers' efforts to reverse-engineer the hardware.  

Hardware support has been an ongoing struggle for many years due to the fact
that many hardware manufacturers refuse(d) to open up their source code or
even develop drivers for the Linux kernel - or any other non-Microsoft OS
for that matter.  

In the last five years or so, there has been a shift from this paradigm,
which was caused by the great endorsement of GNU/Linux by some
big-reputation vendors, such as IBM, Hewlett-Packard, Sun Microsystems, SGI
(formerly Silicon Graphics), Dell, Novell, AMD, Intel, and many, many
others.  Not only are they running GNU/Linux on (a lot of) their own
machines instead of their own proprietary UNIX systems - well, Sun is
pushing their Solaris development via the OpenSolaris platform, but
GNU/Linux is seriously gaining ground over proprietary UNIX, simply because
it supports just about all platforms in existence - any many other hardware
vendors (such as Adaptec, LSI et al) are actively cooperating on the
development of the Linux kernel.

Add to all of the above the fact that Vista turned out to be quite not the
success Microsoft had hoped for, with XP SP3 now also breaking on AMD
platforms, and you will understand that most hardware vendors are now
*finally* getting the message that GNU/Linux is here to stay and that it's
a robust and reliable system that deserves attention.  They have little
choice, because by not supporting GNU/Linux - which only keeps gaining in
momentum and marketshare - would mean that those hardware vendors could be
missing out on a lot of sales.  

Sure, there will always be some who still don't get the message and who
prefer taking their chances on supporting Crimosoft only, just because they
are companies run by pointy haired bosses for whom only a corporate name
has any meaning.

With regard to wireless LAN drivers, the Linux kernel also has something
very nifty, called /ndiswrapper./  It's a kernel driver ABI that accepts
wireless LAN drivers for Windows and loads them into the running Linux
kernel as if they were native Linux drivers.

Either way, a *short* overview of what's supported on GNU/Linux:
- wireless: anything with an Orinoco or Atheros chipset is supported
natively, many other vendors offer proprietary Linux drivers,
and /ndiswrapper/ can come in handy if they only offer a Windows driver.
- graphics: 2D is supported natively for most cards in existence, but 3D
usually requires proprietary drivers.  The big names are ATi and nVidia,
but Intel is also moving into the graphics market now and is offering Free
& Open Source drivers.
- USB 2.0 is supported, and thus also most modern USB storage devices.
- most digital cameras are supported as USB storage devices.
- memory card readers are supported.
- serial-attached SCSI, parallel SCSI and SATA are supported.  SATA RAID on
the motherboard is usually a software RAID that requires a Windows-specific
driver, but you can use the disks as regular SATA and use Linux software
RAID instead.  Most true hardware RAID adapters are supported.
- winmodems are usually *not* supported, because they are not real modems
and rely on a Windows driver to do the actual modem work.  Some can be made
to work - I believe Lucent has a few of them.  External modems and internal
real modems are always supported.
- most Epson and HP printers are supported.  Laser printers that understand
PostScript or HP's PCL are always supported.  Stay away from Canon; they
are MS- (and Apple-)only with just about everything they make, albeit that
some of the stuff can be made to work in GNU/Linux, no thanks to Canon
itself.
- most soundcards are supported natively, either through ALSA - which is the
default and best choice in terms of quality - or through OSS.  Recent
systems usually come with either an AC97 codec or an Azalia codec (Intel
HDA).
- for laptops, suspend-to-RAM and suspend-to-disk are supported, via ACPI.
- multiprocessing systems, multiple cores per processor, hyperthreading and
NUMA architectures are supported and quite better balanced than on any
version of Windows.
- PAE is supported for 32-bit systems on processors that support it, and if
enabled in the kernel.  Most distributions ship multiple kernels, some of
which have PAE and/or SMP enabled, alongside leaner single-core,
non-hyperthreading, single-socket, low-mem-only (890 MB) kernels.
- a lot of GNU/Linux suppliers (but not all) offer 64-bit versions of their
distro.  These distros have to make use of some 32-bit software for the
proprietary stuff - e.g. Flash, win32 codecs - but that also applies to
64-bit Windows installations.
- certain Windows applications are supported via /wine,/ which is a Windows
ABI for UNIX systems.  Not everything works, but there are commercial
versions of /wine/ available that handle more Windows applications if you
need that, e.g. Crossover Office for MS Office, Cedega for anything that
would need DirectX.
- Microsoft-proprietary document formats can be opened, modified and saved
via OpenOffice or KOffice.  Open Document Format is supported and is the
native document format in the latest versions of each.
- Windows-specific filesystems can be read and written to - although I'm not
well-versed on the current status of writeability to NTFS - but the system
itself should of course be installed on any of the Linux-supported
filesystems with UNIX permissions.  You can currently choose
from /ext2,/ /ext3/ (= /ext2/ with journaling), /ext4/ (= /ext3/ with the
directories saved to another disk than the files), /reiserfs,/ /XFS/
and /JFS./  Many other UNIX filesystems can be read only or are still
experimentally supported.
- the common CD and DVD filesystems are supported, and then some.
- Wacom tablets are supported.

And the list goes on... ;-)

Probably not that many, since HP is an endorser of the Linux kernel
development and is even offering systems with GNU/Linux pre-installed.

For wireless, see above.  Orinoco and Atheros are well-supported chipsets.
Others may require proprietary drivers or can be made to work
using /ndiswrapper/ and the Windows-specific driver.

Most soundcards are supported - see above, again. ;-)

FOSS (Free & Open Source) drivers typically don't have a lot of bugs, and
according to a survey, proprietary software typically has about 500 times
the amount of bugs of a comparable amount of FOSS code.

I repeat, most stuff is supported, and if it isn't, then you bought the
wrong hardware. ;-)

I neither run Ubuntu nor do I have an HP Pavillion, but I hope my advice was
helpful nevertheless. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

Thanks for the good info.  I am tinkering with Ubuntu already - I just got
it via Torrent.  I'm going to figure out a way to dual boot XP and Ubuntu.
I think XOSL might work.  And keep the Ubuntu hidden from WinXP

Bill S.

news:xemVj.34714$_k2.28122@newsfe11.ams2...

...

read more »

XOSL or comparable bootmanagers are nice, but in my humble opinion they are
a solution for a problem that doesn't exist, or at least not in the
GNU/Linux world. ;-)

GNU/Linux comes with its own bootloader, or actually, two of them.  The
original bootloader was LILO (LInux LOader), but more and more
distributions are switching over to GRUB (GRant Unified Bootloader) now.

The main difference between both is that GRUB offers more functionality, and
that its configuration is done in realtime, whereas modifications to the
LILO menu need to be written to the bootloader explicitly via an additional
command.  This is because LILO accesses its configuration and its kernels
(or partition bootsectors) via direct logical block addresses, while GRUB
can read a filesystem and reads its files via filesystem access.

GRUB is actually more than a bootloader; it's a miniature real mode OS,
capable of reading filesystems and equipped with an actual miniature shell
for emergencies.  It's also got more options than LILO, but be advised that
if you use /ext3/ on your */boot* filesystem - or on the root filesystem if
you don't have a separate */boot* - you need the latest version of GRUB due
to an incompatibility between the older GRUB and /ext3/ introduced in the
latest version of the /ext3/ filesystem layer.

Both GRUB and LILO are capable of booting GNU/Linux as well as Windows, OS/2
or DOS, alongside other operating systems (for GRUB).  Both are capable of
fooling an operating system into thinking it's installed in another
partition type or on another disk than it physically is.  Both are capable
of chainloading, i.e. using one bootloader to call up another bootloader.

The best course of action for installing XP and Ubuntu alongside of
eachother is to first install XP on a blank hard disk.  Give XP just enough
room for itself, its swapfile and its applications, and have it sit on an
NTFS filesystem.  Then create a second partition from within XP, which you
format as FAT32 - /vfat/ in UNIX-speak.  Use this partition for documents
that need to be shared between Windows and GNU/Linux.  Don't make this
partition too big either.

Next, reboot your system with the Ubuntu CD/DVD and proceed with the
installation.  Most newbies will require two partitions, i.e. one for the
root filesystem itself - which will be mounted on "/" - and one for swap;
the Linux kernel prefers swap partitions rather than swapfiles, although
you _can_ also use swap files.  A swap partition is formatted in a special
way and does not have a filesystem on it.  It's also not mounted anywhere
into the filesystem hierarchy but is mounted onto the kernel directly as
virtual memory.

Now, whereas most newbies will opt for an installation of all files in the
system onto one single filesystem - i.e. the root partition - this is
actually a Windows-induced concept, since Windows requires to be installed
into one partition.  This is not the case for UNIX-style operating systems.
Certain files need to be present on the root partition, but others can be
split off onto other partitions just as easily, or onto logical volumes.

There are various benefits from spreading the filesystem hierarchy over
multiple partitions or logical volumes.  You can use different filesystem
types per partition, or format certain partitions with different block
sizes, or have certain filesystems mounted read-only during normal system
operation, or use again other mount options.

The minimum that I would advise is to use at least a separate filesystem for
your own files.  GNU/Linux is a UNIX-style operating system, and thus a
multiuser operating system.  That means that you should not work from
within the root account - unlike in Windows, where user accounts have
Administrator privileges by default - but instead you should do all of your
work from an unprivileged user account, and only use the root account - in
Ubuntu, root cannot log in directly but one must use /sudo/ to gain root
privileges instead - for system maintenance.

The reason why I mention this in the context of partitioning - although it
is advise to be heeded! :-) - is that unprivileged user accounts have their
home directories under */home* - while in GNU/Linux, the root account has
its home in */root.*  Your home directory will contain your work files and
directories - they should _not_ be called folders :p - as well as a number
of hidden files with "per user" configuration settings for various
programs.  Hidden files in UNIX are files whose name begins with a period.

These are the directories you will find in a typical GNU/Linux root
directory...:
- /             : the root directory itself
- */bin*        : binaries needed at boot time and in single user maintenance mode
- */boot*       : kernels and GRUB configuration files, may be split off and made
                  read-only
- */dev*        : nowadays its population exists in RAM
- */etc*        : configuration files and System V /init/ scripts
- */home*       : user accounts, may be split off
- */lib*        : system libraries; _note:_ on 64-bit x86 systems */lib* is a link
                  to */lib64* and there will also be a */lib32* as well
- */media*      : the parent directory of mountpoints for removable storage media
- */mnt*        : a generic temporary mountpoint for various filesystems
- */opt*        : add-on software, may be split off and mounted read-only
- */proc*       : a virtual filesystem representing kernel data
- */root*       : the root user's home directory
- */sbin*       : system binaries needed at boot time and single user maintenance
                  mode (i.e. runlevel 1)
- */sys*        : like */proc,* a virtual filesystem representing kernel data and
                  used by the /udev/ system to populate */dev,* among other things
- */tmp*        : temporary files, may be split off onto a partition or better yet
                  would be to use a /tmpfs/ for it, i.e. a RAM-based filesystem
- */usr*        : all software for multiuser mode, and the bulk of the
                  installation; may be split off and should then be made read-only
- */var*        : variable files such as logs, print spools et al; may be split off

Eventually, there may also be a */srv* directory, but not all GNU/Linux
distributions feature this, and those that do typically leave it empty.
The idea is that you use */srv* for shareable user data, e.g. files that
need to be worked on by multiple users of the same system, or that need to
be shared over the network.

If you follow my advice, you could mount your two Windows partitions on a
directory under */mnt,* e.g. */mnt/fat32* or */mnt/win_d.*  That way, you
can access them from within GNU/Linux and share files with your Windows
environment.  However, do _not_ attempt to install your home directory or
any other system directory onto them, because GNU/Linux requires
filesystems that support UNIX-style permissions, and Windows filesystems do
not.

While the above listing is one of directories, some of which can be
mountpoints to filesystems on other partitions or logical volumes, these
filesystems, disks et al are all represented under */dev* as device special
files.  Some are block devices - such as hard disks, partitions on hard
disks, logical volume groups, logical volumes, RAID filesystems et al - and
others are character devices - such as your mouse, the console, the
soundcard, the video adapter, etc.

If you follow my advice of having two partitions for Windows and the
recommended minimum three for GNU/Linux, your partitioning layout would
look like this...:
- */dev/sda1*   = the Windows C: drive
- */dev/sda2*   = the extended partition container
- */dev/sda5    = the Windows D: drive (with FAT32)
- */dev/sda6    = the GNU/Linux root filesystem
- */dev/sda7    = the GNU/Linux swap partition
- */dev/sda8    = the GNU/Linux */home* filesystem

Should you wish to split off more filesystems from the root filesystem, then
you must keep in mind that SATA and SCSI only support up to 15 partitions
in total per disk - or if you have multiple disks in a real hardware RAID
configuration, on the entire RAID array.

As you can see, the device special files denoting the partitions carry
numbers.  The hard disk itself however also exists as a device special
file, */dev/sda* (and */dev/sdb* for a second hard disk, and so on).

These device special files can be manipulated as regular files in the sense
that they can be read or written to from a given offset up to an other
offset.  As such, when you install your bootloader - provided that you use
either LILO or GRUB - you should install it in the master boot record of
your hard disk, i.e. on */dev/sda.*  This will write the bootloader to the
first few bytes of the hard disk, outside of the partitions, which is where
the master boot record lives.  For chainloading, a second GRUB or LILO
would then be written to a given partition's bootsector.  

However, that is something you don't need to know about right now as it
doesn't pertain to your situation.  When the installer asks you where you
want to place the bootloader - this will be GRUB in Ubuntu - just answer
*/dev/sda,* without any numbers to it.

The reason why there are device special files is that in UNIX, everything is
a stream of data, and a stream of data is a file.  All your hardware, they
are all files that are written to and read from.  Everything is very
logical and orderly.  All configuration files are in human-readable plain
text.

There is probably a ton more that I should tell you about, but at this very
moment I've been awake for over 24 hours already and my mind is a bit
blurry right now. ;-)  

Either way, I trust I've given you some useful information.  I have given
...

read more »