Language Selection

English French German Italian Portuguese Spanish

Review: DesktopBSD 1.6 RC2

Filed under
Reviews
BSD

After a nice weekend away in Hilton Head, SC, enjoying the nice sun and the company of family and friends, I am back with another review of a BSD-based system. DesktopBSD 1.6 RC2, released April 13, aims to provide a system that is easy to use but maintains the power and functionality of BSD.

My use of BSD goes back a number of years (late 1990’s) and the latest releases of the standard distributions (Free/Open/Net) haven’t changed much since then. The capabilities have increased, but the look and feel of each OS remains pretty much the same. The original three haven’t made many usability strides since then. (I’m sure some BSD die-hards will have something to say about this. I’m sure I’ve missed some major ones, so feel free to enlighten me.)

In any case, it is good to see that others are stepping up to the plate to bring the BSD line more up to date with what the mainstream operating systems are doing. It is not necessarily about eye candy but ease of system use and configuration that is important. Perhaps the BSD camps do not feel it is necessary to have easy to use administration tools and completely ready to use desktop systems from the install, but I do. Clearly the possibilities are endless, considering what the latest Linux distributions have been able to achieve, and what Apple has brought about with Mac OS X (which has a lot of BSD-based code in it).

Full Story.

More in Tux Machines

Leftovers: Gaming

Leftovers: Software

today's howtos

ACPI, kernels and contracts with firmware

This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware. Read more