BSD for Linux Users: An Introduction

BSD means a few things in the Open Source / Operating System world:

The Berkeley System Distribution, a variant of UNIX that stemmed from the original AT&T UNIX, originally developed by Computer Systems Research Group (CSRG) of the University of California, Berkeley [1]
One or many of a number of BSD distributions - a "flavour" of the original, modified by the vendor to suit the purpose of the distribution in question. Examples might be FreeBSD, NetBSD, OpenBSD and Dragonfly BSD. Note that these are not "Unix-like" as Linux is, but actually based from and including code from the original BSD - minus the code from AT&T, hence the version they are based upon is known as "4.4BSD-Lite".
The actual kernel of one of these distributions, in the same way as Linux is the main kernel of distributions such as Ubuntu, Fedora or Mint, although there are other choices of kernel for some distributions.
One or many BSD communities around the world to support and help develop these distributions, such as forums, help desks, etc.
A set of permissive non-copyleft licences which said distributions and kernels are distributed under [2][3] which allow redistribution provided that the original copyright notices are left in the associated media, and pose no other restrictions other than an optional "no endorsement" clause.

Following is a summary of some of the main distributions.

FreeBSD: the most popular BSD distribution, recognised by its support for running servers and famously run on [4]

PC-BSD: touted as "user-friendly", offering an easy install process and simple package installations from self-contained packages. [5]

OpenBSD: supposedly the most secure operating system, boasting "Only two remote holes in the default install, in a heck of a long time!" [6]

NetBSD: a distribution with a small install size, a popular base and excelling at portability with "formal releases for 53 architectures [7], and has integrated ports for four others", celebrating 20 years since its foundation this year.

Dragonfly BSD: a 10-year-old (so still relatively young) distribution famous for its extremely speedy filesystems. [8]

Debian GNU/kFreeBSD [9], the Debian distribution compiled to work on top of a BSD-type kernel rather than a Linux one, which has the upshots of being able to be used on top of BSD-supported filesystems, those compatible with BSD licences (but not the GPLv2 [10] used by Linux [11]) such as ZFS [12] (edit 2021: archived) (licenced under the CDDL [13]), and all the while using the familiar GNU tools common to the Debian GNU/Linux distribution.

Next time: BSD Licences and why they are good, bad and/or certainly not ugly.

References

[1] https://en.wikipedia.org/wiki/Berkeley_Software_Distribution 4 [2] https://opensource.org/licenses/BSD-2-Clause

[3] https://opensource.org/licenses/BSD-3-Clause

[4] https://www.freebsd.org/

[5] https://www.pcbsd.org/

[6] https://openbsd.org/

[7] https://www.netbsd.org/about/portability.html

[8] https://www.dragonflybsd.org/features/

[9] https://www.debian.org/ports/kfreebsd-gnu/

[10] https://www.gnu.org/licenses/gpl-2.0.html

[11] https://www.kernel.org/doc/linux/COPYING

[12] [https://web.archive.org/web/20140908152050/http://www.freebsd.org/doc/handbook/filesystems-zfs.html] (https://web.archive.org/web/20140908152050/http://www.freebsd.org/doc/handbook/filesystems-zfs.html) (edit: archived)

[13] https://opensource.org/licenses/CDDL-1.0

Comments

No comments yet...

What Free Software needs

Permalink | Author: Dan Dart | Published: 2009-07-05 13:21:00 UTC | Tags: bsd. competition free linux packages standardisation windows

When I was young, I remember wanting SUSE 9.2 Professional. It seemed like a good stable system with many good reviews. Afterwards (luckily) the distribution switched to GPL and I managed to acquire a copy of 9.3. It was very good for its time, its acheivements vastly outstepping anything I had previously seen. With instant search, good photo management, and all the rest, it seemed to be a good stepping stone onto which further development could be put upon.

A while later, I find that "cool" features seem to be getting less and less common. With the advent of Compiz a few years ago, coolness in the desktop rose a little, but with less common other features, and small incremental updates in most distributions, computing was getting a little more boring, with little to wow about. We now need a good jump up, or proprietary software will catch up. KDE 4 recently has been a downfall, mainly because people disliked it from being so very different to the very stable and mature 3.5 series, which I was in fact excited about at the time. When the "broken" Microsoft Vista followed after KDE 4's (premature) release, people managed to give Vista bad hype for being so out of step with current needs that it would not run software that ran on previous releases flawlessly. Between now and then, KDE 4 and Vista have largely sorted out their concerns. Ever since Vista SP1 and KDE 4.2, I think a lot more people are happy with either release. But many people still dislike this new "dark" theme over the previous light theme, and as such prefer to stick to the "dead" XP or the less-supported KDE 3.5.

Other problems we in the Free Software community face are:

Lack of standardisation. Yes, as much as I hate to say it, standard ways of doing things are waning. Especially in the Linux community, 500 different distributions are not a good way of doing things. Factoring out the "useless" distributions, based on whether they have been done before, how useful a distribution is, whether the same effect could be copied painlessly in another distribution, I think maybe 50 might remain.

Lack of standard package formats. As much as I still hate to say it, all Linux distros need one defining package format. Right now it is considered too difficult to develop for Linux, as there are so many formats to develop for. DEB, RPM, RUN, Autopackage, TAR.GZ, TGZ, and others make it difficult to develop for. I think we need a standardised package format and standard repositories that all distros can pull from. Having different ones means that it is currently difficult and long-winded to document how to install software on all current distributions. Here is what I think we need:

One format. One format, one download link for Linux, one way of packaging. Easy, simple.

One repository. One website serving download links for every conceivable package, in an installable static format (including every library it requires) or dynamic (for short downloads).

Every application. There are far too many repositories. There are in excess of 50 for Ubuntu and openSUSE. Why can't they just all be in the same place? Of course, to keep freedom-lovers happy, split it into free and non-free but essentially it's easier to get what you want now.

Every proprietary game or application maker can now package their game or application into ONE single format, upload it to ONE server (if necessary) or ONE CD/DVD/USB, and allow use or play to EVERY free software user.

Standard Libraries. GNOME and KDE are in pretty much fair competition. I cannot dispute or argue against it. Choice is paramount, but applications that don't work are unacceptable. If there were a library that could be used to create desktop applications that would run fairly on each, and not look foreign on one or the other, then it should be developed upon by everyone trying to provide a fair experience. People don't always have the libraries that are needed by some obscure piece of software, so they should be readily available, or the application should use something more common.

Backward/Forward Compatibility. Proprietary module or "driver" creation is impossible in Linux. If a hardware manufacturer wishes to hide the functionality of their driver, they cannot release binary-only drivers in Linux currently. I know that manufacturers should be encouraged to develop freely, but if there is no chance of this, there is no chance of that hardware working on Linux. The license makes it difficult but I believe that if a manufacturer provides one of those "Driver CDs" in that standard package format above with Module Versioning support on in the kernel, drivers do not have to wear out.

The kernel seems to not like modules from a past or future kernel, mainly because it is not at all stable, but also because Module Versioning does not work by default in most distros by default. Looking at Windows, applications and drivers from a number of years ago will work in today's release, and (in general) releases before the release of the application or driver. We need this back-forward compatibility for proprietary software vendors (who can't be convinced to switch to free) not to have to either release their code or keep compiling their code for each kernel or new release.

A hopeful fix I'm in the process of creating a browser-based desktop environment that will hopefully overcome all that, and allow for major cool features as well as ultra compatibility and ease of use for new users. It isn't Linux, or anything to do with current free software but it can lie on top of Linux/Solaris/BSD/Windows/Mac/whatever if the user so wishes.

https://web.archive.org/web/20100107134808/http://xenon.kevinghadyani.com/ (edit 2021: archived)

Comments

Dan Dart (URL) said on 2009-07-06T01:07:54.836Z:

@xenom Distros do different things but maybe if we had stable, testing, etc repos for enabling?

@P. Static Oh no, mine is doing way more than fixing these problems. I'd love current distros to overcome this and standardise with each other. Otherwise, maybe a "1-click install" for new repos and packages is in order, which integrates with their package manager, whatever it may be.

P. Static (URL) said on 2009-07-05T16:24:15.792Z:

so, the problem is that there are too many distros doing things too many different ways, and your solution is... to make a new, completely different distro? ;)

Unknown (URL) said on 2009-07-05T15:02:00.026Z:

The package system problem come only with propriary software, with FOSS, the package are the problem of package maintainer of the different distributions. The one format is not a real problem for devellopers. If they want to make a package for distribution it is their problems, else it is the package maintener's problem. One repository for all distribution is not technically possible, because distribution have different package update system and motivation, many just take stable version (like Debian Stable) and other are bleeding-edge and rolling-release (like ArchLinux) and this is really good, I don't imagine using Debian on my personnal computer and ArchLinux on company server. I also think on different compilation options.

The lack of standard librairies is a problem, but not a big problem, we can easily have 2 ou 3 different librairies without problems.

BSD for Linux Users: An Introduction

Comments

Post a comment:

What Free Software needs

Comments

Post a comment: