Language Selection

English French German Italian Portuguese Spanish

Beastie of an OS

Filed under

Once a distro goes into beta 3, most of the major choices are in place. In looking at the 3rd testing versions of distributions, one can get a fairly good idea of what a distro might be like once it's released. The only experience I've had with a BSD clone or derivative was with my PC-BSD review some months ago. That install was as simple as 1, 2, 3... or click, click, click. I'd heard the horror stories about other BSD installs, yet downloaded 6.0 beta 3 with hope. Was this going to be a brain-burning, hair-pulling, data-losing proposition? What happened with my attempted FreeBSD 6.0 Beta 3 install?

As this is my first foray into FreeBSD, this isn't so much a "what's new" as it is a "what's here".

First off, the install was much easier than running it... at first. But as with many new things, once you learn how, you wonder why you were nervous to begin with. The installer was easy enough. I had read the docs on FreeBSD before and as I recall, it sounded like a cross between lfs and gentoo. But if that was true then, it certainly isn't true now. The FreeBSD installer was a nice ascii graphical type installer that walks one through the install in much the same manner as Slackware. Can you install Slackware? Then you can install FreeBSD. In fact it even looks very much like Slackware's.

The most difficult step for the newcomer might be the fdisk step. I even experienced a sweaty-palm moment. The FreeBSD fdisk didn't seem to see all my partitions, or rather it saw the extended partition as one big empty slice. I toyed with the idea of inputting the start and end block numbers in and seeing if it installed on the correct partition, but chickened out of that. It was already complaining that it didn't agree with the geometry reported for the partitions it did see. I chose to put FreeBSD on the first partition of the drive - former spot reserved for, if not the current home of, Windows. It is now a Unix slice.

The rest of the install is fairly straight forward. One picks out the type of install they'd like, if I recall correctly, something like: developer, developer + kernel, developer + kernel + X11, etc., or as I chose ALL. It takes about 10 minutes to install the system, then it asks about packages and ports. I chose many many packages I'd need including KDE, gnome, and all the other window managers available during install. Turns out there are many many more available through their package manager. This step takes some time, probably a 1/2 hour or so, but then it gets to the configuration portion. It asks some questions about your net connection preferences, root password, setting up users & groups, and some other hardware. All this was quite easy to follow and complete.

I didn't choose to install its bootloader, instead I googled and discovered one only needs an entry in their linux lilo.conf very similar to ones we used for Windows. In fact, it's almost exactly like that. Mine looks like so:

Then run lilo and yippee! Upon reboot, lilo hands off to the FreeBSD
bootloader and your new system boots as desired.

One is booted to a terminal for logging in. First thing I always do is setup X. I fired up my console browsers in an attempt to download the NVIDIA drivers, but that failed as NVIDIA changed their site since I last downloaded their drivers with a text browser. I used to think how nice that one could use Links/Lynx to do that, but now their stupid javascript license agreement ruins it. So, I improvised. Since my FreeBSD is still not seeing anything in my extended partition, I had to make other arrangements. This was all in vain as the install bombed out very early on. It shot an error something about NOOBJ is deprecated to NO_OBJ or some such and I knew it was vesa for me. Xorg NV drivers lock my machine up fairly tight no matter the boot options I use.

However, there was no /etc/X11/xorg.conf skeleton in place and copying one from another install wasn't an option, so I was left to run Xorg -configure. This sets up a test file in /root called, and one can test their configuration with Xorg -config If it works well, then you can cp it to /etc/X11/xorg.conf, and I did.

Now to start KDE, or actually more accurately, KDM. I wanted to be able to check out all the window managers and figured KDM was my best bet. But where the heck was it? As with many Linux commands, fortunately "which" is in my BSD Unix clone and it worked quite well. I found xinit was located in /usr/X11R6/bin and kdm was located at /usr/local/bin/kdm. So su to root and issue the command /usr/X11R6/bin/xinit /usr/local/bin/kdm and we are in business. In the future to expedite things, I learned startkde was in /usr/local/bin/startkde. One finds the standard and complete KDE 3.4.2 upon startup or one of many other window managers.



Many ports get installed into /usr/local with FreeBSD and there is no /opt directory. In fact the directory structure may be similar in some ways to Linux, but to me, it was more different than alike. Many binaries are located in /usr/libexec and /usr/X11R6/libexec. But how does one find something not in their path? As you might recall in Linux systems, you can't use locate or slocate until you build the database, and regularly update it. But "which updatedb" didn't turn up anything. Thank goodness for google. To build and update that locate database, one needs to issue /usr/libexec/locate.updatedb

The kernel sources are located in /usr/src/sys/i386/ and the modules reside in /boot/kernel. I don't know which kernel I'm actually running, as uname -a reveals

tuxmachine# uname -a
FreeBSD 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 i386

I supposed I was still thinking Linux and expecting 2.6something. I try to remember we're dealing with a horse of a different color here. Anyway, at this point, if support for something wasn't in default, then I just won't use it. Maybe later.

One of those things not in the default kernel build was support for my bttv card. But sound was there and instead of modprobe snd_emu10k1, one issues kldload snd_emu10k1. For convenience I googled again and found that /boot/defaults/loader.conf is where one sets up their modules to autoload upon boot. Some commandline equivalents might be:

  • kldload = modprobe
  • kldunload = rmmod
  • kldstat = lsmod

But what about installing other software? I always like to have mplayer installed and GIMP is a must-have. But what do I do? Well, google of course. I found that the installer for FreeBSD is pkg_add. A lot of software is located in /usr/ports/. One could just navigate to the package directory of choice and issue a make install or one can use pkg_add <name of package>. Using the -r flag tells it to search remotely and get the latest available. It tries to sort out dependencies as well, but if there are issues, one might try portupgrade <package name> Mplayer isn't available, but gimp is as well as bash_completion.

There are many similarities between FreeBSD and Linux, but there are subtle differences as well. One major difference is the naming convention of devices. For example, ethX are vrX and hdX are acdX. As stated the directory structure is quite a bit different and I found commandline flags must be typed before the filename.

So, all in all, I found FreeBSD to be a capable desktop system. I've experienced a few konqueror crashes, but no other stability problems. I think their strongpoint is still in the server market and I'd probably appreciate it more there. If one checks in with Netcraft, they will find that almost 1/2 of the longest running systems by average uptime are FreeBSD.

I now recall how it feels to be the newbie stumbling around in a strange operating system. One wonderful resource where I found some answers to some of my issues is the BSDWiki. There is also some documentation as well as latest news on the FreeBSD website. I could very easily adapt to FreeBSD if something catastrophic happened where all the Linuxes (Lini?) suddenly vanished off the face of the earth. I can't say what's new in this release since the last stable or even the other betas, but I can state that many of the applications are of the lastest (stable) versions available. Try it, you might like it!

I have some additional Screenshots in the gallery.

More in Tux Machines

Kernel News: Linux 4.10 in SparkyLinux, Wayland 1.13.0, and Weston 2.0 RC2

  • Linux Kernel 4.10 Lands in SparkyLinux's Unstable Repo, Here's How to Install It
    The trend of offering users the most recent Linux kernel release continues today with SparkyLinux, an open-source, Debian-based distribution that always ships with the latest GNU/Linux technologies and software versions. SparkyLinux appears to be the third distro to offer its users the ability to install the recently released Linux 4.10 kernel, after Linux Lite and Ubuntu, as the developers announced earlier that the Linux kernel 4.10 packages are now available from the unstable repository.
  • Wayland 1.13.0 Display Server Officially Released, Wayland 1.14 Lands in June
    Bryce Harrington, a Senior Open Source Developer at Samsung, announced today the release and general availability of the Wayland 1.13.0 for GNU/Linux distributions that already adopted the next-generation display display server. Wayland 1.13.0 has entered development in the first days of the year, but the first Alpha build arrived at the end of January, along with the Alpha version of the Weston 2.0 compositor, including most of the new features that are present in this final release that you'll be able to install on your Linux-based operating systems in the coming days.
  • Weston 2.0 RC2 Wayland Compositor Arrives With Last Minute Fixes
    While Wayland 1.13 was released today, Bryce Harrington today opted against releasing the Weston 2.0 reference compositor and instead issue a second release candidate. Weston 2.0 is the next version of this "playground" for Wayland compositor technologies since the new output configuration API had broke the ABI, necessitating a break from the same versioning as Wayland.
  • [ANNOUNCE] weston 1.99.94

KDE Leftovers

  • Fedora 25 KDE: disappointing experience
    Fedora is not a frequent guest on the review deck of Linux notes from DarkDuck blog. The most recent review was of Fedora 22 back in July 2015. That was a review of the GNOME version, the most native for Fedora. You are probably aware of the tight link between the GNOME project and RedHat, the Fedora Project main sponsor.
  • [Video] Ubuntu 17.04 Unity 8 - KDE apps native on Mir
  • Plasma in a Snap?
    Shortly before FOSDEM, Aleix Pol asked if I had ever put Plasma in a Snap. While I was a bit perplexed by the notion itself, I also found this a rather interesting idea. So, the past couple of weeks I spent a bit of time here and there on trying to see if it is possible.
  • QStringView Diaries: Advances in QStringLiteral
    This is the first in a series of blog posts on QStringView, the std::u16string_view equivalent for Qt. You can read about QStringView in my original post to the Qt development mailing-list, follow its status by tracking the “qstringview” topic on Gerrit and learn about string views in general in Marshall Clow’s CppCon 2015 talk, aptly named “string_view”.
  • Making Movies with QML
    One of the interesting things about working with Qt is seeing all the unexpected ways our users use the APIs we create. Last year I got a bug report requesting an API to set a custom frame rate for QML animations when using QQuickRenderControl. The reason was that the user was using QQuickRenderControl as an engine to render video output from Qt Quick, and if your target was say 24 frames per second, the animations were not smooth because of how the default animation driver behaves. So inspired by this use case I decided to take a stab at creating such an example myself.
  • How to Create a Look and Feel Theme
  • United Desktop Theme for KDE Plasma 5.9
  • KDE Talks at FOSDEM
    The continuation of the original talk from Dirk Hohndel and Linus Torvalds about the port of Subsurface from Gtk to Qt, now with mobile in mind.

SteamVR for Linux, Benchmarks of HITMAN on NVIDIA

  • SteamVR for Linux is now officially in Beta
    Valve have put up SteamVR for Linux officially in Beta form and they are keen to stress that this is a development release. You will need to run the latest Steam Beta Client for it to work at all, so be sure to opt-in if you want to play around with it.
  • Valve Publishes A SteamVR Developer Build For Linux
    Valve has begun rolling out their SteamVR Linux support by announcing today a beta/developer build of their VR support for Linux. Valve's SteamVR for Linux page was updated today to reflect the build becoming public via the Steam beta channel, "This is a development release. It is intended to allow developers to start creating SteamVR content for Linux platforms. Limited hardware support is provided, and pre-release drivers are required. Linux support is currently only available in the "beta" branch, make sure you are using SteamVR[beta] before reporting issues."
  • HITMAN Linux Benchmarks On 12 NVIDIA GPUs
    Last week Feral Interactive released the much anticipated port of HITMAN for Linux. While at first it didn't look like this Linux game port would work out for our benchmarking requirements, thanks to Feral it does indeed work for another interesting Linux gaming test perspective. For our initial HITMAN Linux benchmarks are tests from 12 NVIDIA GeForce GPUs while our Radeon tests will come tomorrow.

Meet Flint OS, a Chromium OS Fork for Raspberry Pi & PCs That Runs Android Apps

Will Smith from Flint Innovations Limited is informing Softpedia today about their up and coming Linux-based operating system for PCs and Raspberry Pi devices, Flint OS, based on the open-source Chromium OS project. These days, we see more and more developers and entrepreneurs launching new operating systems based on Chromium OS, which Google uses with much success for its Chrome OS on many Chromebooks that you can purchase today. But Flint OS is somehow a bit special, not only because it provides support for both Raspberry Pi SBCs and x86 computers with either Intel or Nvidia GPUs, but because it uses Android apps. Read more Also: KaOS 2017.02 Is Out with Linux 4.9.10, KDE Plasma 5.9.2, and X.Org Server 1.19.1