Language Selection

English French German Italian Portuguese Spanish

Beastie of an OS

Filed under
Reviews
BSD
-s

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:
other=/dev/hda1
table=/dev/hda
label=FreeBSD

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 xorg.conf.new, and one can test their configuration with Xorg -config xorg.conf.new. 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 tuxmachine.tuxmachines.org 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC 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

Graphics: RenderDoc, Mesa, and Vulkan

  • RenderDoc 1.17 Released For This Leading Open-Source Graphics Debugging Tool - Phoronix

    RenderDoc 1.17 released this week as the newest version of this leading cross-platform, cross-API graphics debugging utility. RendertDoc 1.17 continues to be a gem for developers working with Vulkan and OpenGL along with Direct3D 11/12. RenderDoc as the MIT-licensed frame-capture-based graphics debugger works extremely well for game/engine developers as well as GPU driver developers in working through different issues.

  • DMA-BUF Feedback Support For Wayland Lands In Mesa 22.0's EGL Code - Phoronix

    Landing in Mesa on Black Friday was DMA-BUF Feedback support within the EGL code as another important step forward for Wayland. Introduced earlier this week was Wayland Protocols 1.24 and the primary addition to that collection of protocols is DMA-BUF feedback support. The DMA-BUF "feedback" support is important for Wayland multi-GPU systems where needing to know more information about the GPU device used by the compositor and for being able to efficiently exchange buffers between the secondary and primary GPUs.

  • RADV Vulkan Driver Finally Adds VK_KHR_synchronization2 Support - Phoronix

    The Mesa Radeon Vulkan driver "RADV" has added support for the prominent VK_KHR_synchronization2 extension introduced earlier this year. Added back in February with Vulkan 1.2.170 was VK_KHR_synchronization2 for simplifying the core synchronization APIs of this industry-standard graphics API. VK_KHR_synchronization2 makes Vulkan synchronization handling easier to deal with Those interested in the changes with the "synchronization2" revision can see this Khronos blog post going over the Vulkan synchronization handling in detail along with the changes from this extension.

Kernel: Futex2, Fixes, and Other New Features for Linux 5.16

  • Futex2 Brings Linux Gaming To The Next Level - Invidious

    Futex2 has been a work in progress by Valve and collabora for a very long time and it seems like it's finally going to make it's way into the kernel.

  • Patch out for Alder Lake Linux bug that reminds of the Windows 11 Ryzen CPPC issue - Neowin

    Linux boss Linus Torvalds merged earlier today several important patches for Intel CPU generally related to performance states (P-states) on Linux.

  • Linux 5.16 Merges Fix For One Of The Intel Alder Lake Issues - Phoronix

    Merged this Friday afternoon into the Linux 5.16 development kernel is fixing a performance issue affecting some Intel Alder Lake motherboards. The fix merged a short time ago is the item previously covered within Linux ITMT Patch Fixes Intel "Alder Lake" Hybrid Handling For Some Systems. As explained in that prior article, TurboBoost Max 3.0 / ITMT (Turbo Boost Max Technology) code within the kernel isn't being enabled for some systems, particularly if overclocking or even any memory XMP / optimal settings. The ASUS Z690 board I've been primarily using for the i9-12900K was affected as are numerous other boards. I've also heard reports of some motherboards running purely stock are even having this issue.

  • Intel Preparing USI Stylus Support For Linux - Phoronix

    Intel open-source driver engineers have been working on USI stylus support for the Linux kernel. The Universal Stylus Initiative (USI) aims to offer interoperability of active styluses across touchscreen devices. The Universal Stylus Initiative has a goal of allowing all styluses that comply with USI to work across devices. USI is backed by the likes of Google who wants to see USI working uniformally across Chromebooks, Dell and other hardware vendors, Intel is also involved and leading the upstream Linux support patches, and peripheral vendors like Logitech are also supporting the standard. Other big names like Wacom, Samsung, and many other players from desktop to laptops to mobile.

Open Hardware/Modding With LineageOS and Arduino

  • Ham Radio Gets Brain Transplant | Hackaday

    Old radios didn’t have much in the way of smarts. But as digital synthesis became more common, radios often had as much digital electronics in them as RF circuits. The problem is that digital electronics get better and better every year, so what looked like high-tech one year is quaint the next. [IMSAI Guy] had an Icom IC-245 and decided to replace the digital electronics inside with — among other things — an Arduino.

  • My phone - November 2021

    My current phone is the Google Pixel 3a from 2019. It’s running the LineageOS operating system without the Open GApps stack (GApps is short for “Google Apps”). This means there’s no proprietary software or tracking from Google on the phone by default.

  • PiGlass V2 Embraces The New Raspberry Pi Zero 2 | Hackaday

    Well, that certainly didn’t take long. It’s been just about a month since the Raspberry Pi Zero 2 hit the market, and we’re already seeing folks revisit old projects to reap the benefits of the drop-in upgrade that provides five times the computational power in the same form factor. Take for example the PiGlass v2 that [Matt] has been working on. He originally put the Pi Zero wearable together back in 2018, and while it featured plenty of bells and whistles like a VuFine+ display, 5 MP camera, and bone conduction audio, the rather anemic hardware of the original Zero kept it from reaching its true potential.

October/November in KDE Itinerary

Since the last summary KDE Itinerary has been moving with big steps towards the upcoming 21.12 release, with work on individual transport modes, more convenient ticket access, trip editing, a new health certificate UI, better transfer handling and many more improvements.

New Features
Current ticket access A small but very convenient new addition is the “Current ticket” action, which immediately navigates you to the details page of the most current element on the itinerary. That comes in handy when having to show or scan your ticket and avoids having to find the right entry in the list in a rush. This action is now also accessible from jump list actions in the taskbar on Linux, or app shortcuts on Android. Combined with the easily accessible barcode scanmode mentioned last time it’s now just two clicks or taps to get ready for a ticket check. Read more