Hi guys I'm new to Linux and there are some concepts I dont yet understand.

I have a Dell t3610 workstation that can run Red Hat 7 and Suse 10 according to the manufacturer's spec sheet, and I was wondering if this means I can run any linux OS, because I've heard some say the drivers are in the linux kernel itself, however others have told me that drivers are in fact OS specific. I'm confused, which is correct?

And as a follow up, is it safe to install other OS's than listed in the manufacturers spec sheet e.g. Ubuntu or CentOS, this computer is going to do some pretty heavy calculations that could take days to finish and I'd rather not have it catch fire in the middle of the night due to some bad drivers or something, if that is even possible.

Welcome to LQ, &Linux!!! Yes, it's totally safe to try other distros.
The keyword here is: modules (excuse old link) &one more: lm_sensors
A useful keyword for web-searches is : wiki Got a Mac? VirtualBox

(P.S.: What I'm about to say applies to Linux and to every other(!) operating system ...)

Anytime the computer makes any sort of access to any sort of external device, the operating system must be the system component which actually does it, because only the operating system can access the system's hardware (or its attached devices) directly.

By convention, the operating system uses "drivers" – which are part of the operating system – to manage each particular type of device. The drivers, whether they be compiled-into the kernel or separately loaded as modules, serve to "insulate" the rest of the kernel from device-specific details. Drivers provide "an abstraction," applicable to any sort of device, thereby enabling the rest of the operating system to manage devices more generically. (The OS asks the drivers to do something, and they expect the drivers for "that device" to know how to cause "that device" to do their bidding.)

You can also see the term, "driver," used in conjunction with "user-land," or non-operating-system-kernel, environments. For example, the software to drive a particular optical scanner, or a particular type of laser printer, might not need to be part of the kernel. (Whereas the driver for an externally-attached disk drive ... would.)

- - -

In this case, the manufacturer is basically telling you that they have tested two specific (and, well-known, popular ...) flavors of Linux with their machine. They're not suggesting that other distributions would not work also. In fact, it is very likely that any other distro of comparably-recent vintage would work just fine.

3 members found this post helpful.

If you look in /lib/modules and burrow down to kernel/drivers/ you'll find things like nouveau.ko: they are the drivers that plug into the kernel. In order for each to fit, it has to be compiled for the exact version of the kernel that your distro is using, with any customisation that the distributer has done. In other words, the source code for the nouveau driver for Nvidia cards is downloaded and compiled by each distribution, just as they do with software. But where the result of compiling applications should be the same, the kernel objects will vary very slightly from distro to distro, because they have to work successfully with one specific kernel.

As sundialsvcs said, manufacturers and programmers can't check their product against every distro available, but they can run a couple of well known ones. If CentOS is OK, then so will be Red Hat and Suse Enterprise (same Linux Standard Base), and if Ubuntu runs, then so will Mint and a host of others.

Yes and Yes. Drivers are in the kernel. Some distros have drivers not available in ALL distros by default. There's been more than one distro that I've had to slap a kernel from another distro on to find it useful, so you could (in theory) run any distro if one works well for you. Most drivers (that are supported) trickle down into the mainstream kernel which affects all distros in a good way. Just two years after the fact in several cases. So the older your hardware is, the better the odds that any distro will do. At least with mainstream / supported hardware.

Yes it should/will run any Linux distro. I've recently bought a refurbished T3600, and it's running Slackware64 14.2 perfectly. I've also tried Mint and Debian onit with no problems. No fire, yet.

I've had such a problem with fires in the middle of the night because I used the wrong distro!

The only exceptions are hardware manufactured by outfits that provide poor or no support to Linux, so that kernel developers cannot incorporate the drivers.

Perhaps the best example of this is Broadcom wireless chipsets. They generally do not work out of the box, but you can generally get them working.

Thanks guys, things make more sense now. If I have gotten this correctly, the kernel has some drivers, while some drivers are extra modules. A small follow up question, how is backwards compatability driver-wise, e.g. if the 3.10 linux kernel works alright on my pc's hardware is it a safe bet that newer kernels like the 4.* kernels will as well?


Please do elaborate!

The was a major change going from 2.4.x to 2.6.x kernels which likely deprecated a lot of drivers. Some proprietary drivers ceased support at 3.4.x kernels. But the open drivers are pretty good for most of that class of hardware. There's a general push to deprecate anything 32 bit at this point. Beyond that if it works now, it should always work (or can be made to work). It's what makes linux so useful, you don't have to throw out your printer with every new release. Although that's probably the cheaper option these days relative to ink costs.

How did a serious discussion of kernel drivers devolve into nonsensical comments about printers. First of all printer drivers for specific models are not kernel mode drivers so they aren't part of this discussion. Second the ink comment only applies to cheap giveaway printers. If you buy a $300-400 megatank/ecotank printer the ink can cost 0.5c a page. And no throwing away a printer is not cheaper than buying ink as new cheap printers come with 40% or so 'starter' cartridges.

>"if 3.x has working driver, will 4.x?"
Almost always, except very obsolete devices might be dropped (basically).
Sidenote: some distros are dropping support for 32bit cpu

>"my AwsomeMachines catch fire with wrong distro"
FUDjoke, but in very rare cases, like overclocked home-built PCs,
with inadaquate cooling/heat-sinks, a cpu/gpu could fail.
A little web-searching will alleviate concerns. Zero imho for your Dell.

Jump in & install wildly Practice makes perfect

Probably more of a compatibility parallel (and a jibe at microsoft). Printers tend to NOT work with the next version of windows. Where printers that work in linux tend to remain working for a long as the printer works and the connection method to the printer has hardware for it. Having just spent $30-ish on a usb to parallel port adapter so I can finally dump the old desktop that dims the lights and is probably a fire hazard, with specs that make a raspberry pi look like a super computer. You still need kernel support for the connection methods: USB, Parallel Port, Ethernet, Wifi, ... ... ... As I need to download a 1G file from apple for my apple usb ethernet dongle to have a driver in windows which just works out of the box in linux (module: asix).

Indeed: "printer drivers are part of the printing subsystem – usually CUPS – not part of the kernel."

"Printer drivers serve an analogous purpose, to CUPS, that "kernel-level drivers" serve to the kernel: they "abstract away" the differences between one device and another. CUPS (and more-generally, your application) addresses the printer in a generic way, relying upon a particular driver to take care of all device-specific or model-specific details.

Such drivers are sometimes called, "personality modules."

The concept is also called an "abstraction layer."

The kernel, of course, must have some hardware-driver support for the particular method (e.g. "a USB cable") by which the printer might be physically attached to the system. (Because this is fundamentally necessary in order to successfully move data to-and-from any(!) device, and to service any interrupts that it may generate.) But, this is where the kernel's involvement officially ends.™ Having made it possible for you to talk to the device, and for the device to talk to you (and to interrupt you), the kernel doesn't give a damn what the two of you actually say to one other.