Keep in mind that HAL is very different in Linux versus in Windows. In Windows HAL is a kernel-level thing.
In Linux the kernel dynamicly adapts itself to new hardware so that a hal like what Windows uses is unnessicary.
In Linux you have a program/daemon called udev combined with linux hotplug to dynamicly detect and configure hardware.
Hal for Linux is a bit higher level thing for desktop applications. You can think of it as a database of current hardware configurations presented to applications via dbus. Dbus is a simple mechanism for applications and subsystems to make annoucements and to communicate to one another.
It's not a big deal, but for boot-up time conifguration of hardware you want to muck around udev.
(udev is something that is relatively new. older Linux systems may not have it.)
Now X.org is a completely different beast from the Linux kernel. Linux has very good dynamic hotplug and configuration support for hardware... X.org has _none_. It's configuration is a bit stone age.
X.org has it's own set of drivers that needs to be configured for it to boot, and of course that is taken care of through the /etc/X11/xorg.conf file.
So for X to work when moving from machine to machine you need to have a mechanism to edit a new xorg.conf file.
Most people end up doing it manually since you only have to do it once for a new machine. But if your moving very often you probably want a setup program to do it automaticly.
To do this in Debian or Ubuntu you can run:
dpkg-reconfigure xserver-xorg
It'll ask a lot of questions... It's easier just to edit xorg.conf manually. Just look for the section containing the video driver and delete the line dealing with PCI stuff (it's not needed) and then replace the driver name with something that will work with your hardware. VESA is unaccelerated video that will work with everything.
A alternative way to do it is to install xdebconfigurator.
You can use that if your building a Debian/Ubuntu image that you want to deploy on many different machines. Or you want to make a livecd or install debian on a USB key or something like that. It will try to reconfigure X on the fly. Usually works.
In the future X.org will tie into the dbus/udev/hal infrastructure to autoconfigure it self and xorg.conf file will be optional. But it doesn't work that way yet.
machine dependant files are....
/etc/X11/xorg.conf
/etc/lilo.conf (if your using lilo)
/boot/grub/menu.lst (if your using grub. This is the default for most systems)
/etc/fstab
Other then that hardware should be autodetected.
Sometimes just moving from one machine to another machine will take no effort.
The problem that occurs is like this....
In Linux you have the /dev/ directory.
This contains files that represent hardware resources, and they are presented in files to make it easy for programmers to interact with them.
for example:
/dev/null -- blackhole, you redirect output from programs to make that output 'go away'.
/dev/zero -- file of infinate zeroes.
/dev/input/mice -- mouse output
Harddrives are represented by...
/dev/hd? -- IDE harddrives.
/dev/sd? -- SCSI harddrives.
Then /dev/hd?? or /dev/sd?? represent partitions on those drives... so /dev/hda1 would be the first partition on the first IDE harddrive.
/dev/sdb4 would be the fourt partition on the 2nd scsi drive.
Now with modern SATA drives, USB mass storage, some IDE drivers and other things end up using the Linux kernel SCSI subsystem. So they end up _appearing_ as SCSI drives to userland. So they appear as /dev/sd** whatever.
So the problem happens when these files are referenced in /etc/fstab and then you move that harddrive or image to a different machine and then the order of things change. If the order changes then the filenames change and thus the system won't boot anymore.
To fix it you boot up in knoppix or whatever and edit /etc/fstab and then edit the kernel parameters in /boot/grub/menu.lst to the correct values.
Now with GRUB or Lilo things can get a bit hairy also. They are independant from the Linux kernel so they have their own paticular way to find partitions and such. So often they need to be fixed. I am not sure there is a easy way to deal with that sort of thing.
Now for a perminate solution to the /etc/fstab and kernel boot time parameters is made avaible to us by Udev.
The /dev/sd** stuff is more or less legacy thing. People use it because it works and people are familar with it. With the introduction of Udev those /dev names can be (and are) dynamicly created and realy you can easily (more or less) change how udev works so that those /dev/ files can be anything.
So if your building a linux image that will be working on a wide veriaty of hardware you can reference filesystems by file system label or by UUID.
Also you can change udev rules so that instead of having a partition show up as /dev/sdc3 or whatever it can show up as a /dev/rootdrive or whatnot.
That way you can migrate from machine to machine and not have a issue finding root.
Except for the whole bootloader problem, which I am not sure about the correct way to deal with that.
Hope all that makes sense.