Linux – What are the main differences between Unix and Linux kernels today

It is very tempting to want to define the differences between BSD and Linux. Just like Gilles said in the comments, it is not an easy task since they're so numerous and disparate. Very often, the differences won't even be noticeable at the user's level; everything has been worked out so that the OS behaves as you would expect a Unix to.

Moreover multiple distributions are available for each. No matter what you say about Linux/BSD generally, you'll often find a distribution that contradicts it.

The following is a list of comparisons I found scattered over the web.

• Here on U&L, a user has defined the following differences:

Big differences are (in my opinion of course):

• Userland (Linux uses GNU while BSD uses BSD)
• Integration (Linux is a collection of different efforts, BSD is much more unified at the core)
• Packaging (Linux typically manages installed software in binary packages - BSD typically manages a "ports" tree that you use to build software from sources)

Notice the word typically in his last point. Some Linux distributions will manage source code and conversely some BSDs will manage binary packages.

• Matthew D. Fuller has a lengthy comparison between BSDs and Linux you may want to look into. The article will compare both on Design level, Technical differences, Philosophies and finally address common Myths. Here are some excerpts:

BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC.

--

BSD is designed. Linux is grown. Perhaps that's the only succinct way to describe it, and possibly the most correct.

• User vivek on FreeBSD forums writes:

Key differences:

1. FreeBSD full os. Linux is kernel. Linux distribution is os (100+ majro disrtos).
2. FreeBSD everything comes from a single source. Linux is like mix of lot of stuff.
3. BSD License vs GPL
4. FreeBSD Installer
5. BSD commands (ls file -l will not work) vs GPL command (ls file -l will work)
6. FreeBSD better and updated man pages.
7. BSD rc.d style booting vs Linux SysV style init.d booting

Here are some articles describing the history of each:

• Written by Dave Tyson, this article describes the history of many Unix variants (including of course BSD and Linux).

• Scott Barman describes how both operating systems came to be and how it forged his opinion:

I will give one "solid" opinion: If I had to choose one system that would act as my router, DNS, ftp server, e-mail gateway, firewall, web server, proxy server, etc., that system would run a BSD-based operating system. If I had to choose one system that would act as my desktop workstation, run X, all the application I like, etc., that system would run Linux. HOWEVER, I would have no problem running Linux as my work horse server or running the BSD-based system on my desktop.

Further reading

• This question here on U&L, compares existing BSDs, highlighting what they have in common.

In the case of Linux, a task (kernel internal idea of a thread; threads can share resources, like memory and open files; some run only inside the kernel) can run in userland, or (it's thread of execution) can transfer into the kernel (and back) to execute a system call. A user thread can be highjacked temporarily to execute an interrupt (but that isn't really that thread running).

That a process is a "system process" or a regular user process is completely irrelevant in Unix, they are handled just the same. In Linux case, some tasks run in-kernel to handle miscellaneous jobs. They are kernel jobs, not "system processes" however.

One big caveat: Text books on complex software products (compilers and operating systems are particularly egregious examples) tend to explain simplistic algorithms (often ones that haven't been used in earnest for half a century), because real world machines and user requirements are much too complex to be handled in some way that can be described in a structured, simple way. Much of a compiler is ad-hoc tweaks (particularly in the area of code optimization, the transformations are mostly the subset of possibilities that show up in practical use). In the case of Linux, most of the code is device drivers (mentioned in passing as device-dependent in operating system texts), and of this code a hefty slice is handling misbehaving devices, which do not comply to their own specifications, or which behave differently between versions of "the same device". Often what is explained in minute detail is just the segment of the job that can be reduced to some nice theory, leaving the messy, irregular part (almost) completely out. For instance, Cris Fraser and David Hanson in their book describing the LCC compiler state that typical compiler texts contain mostly explanations on lexical analysis and parsing, and very little on code generation. Those tasks are some 5% of the code of their (engineered to be simple!) compiler, and had negligible error rate. The complex part of the compiler is just not covered in standard texts.