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

today's leftovers

  • Clear Linux Has A Goal To Get 3x More Upstream Components In Their Distro
    For those concerned that running Clear Linux means less available packages/bundles than the likes of Debian, Arch Linux, and Fedora with their immense collection of packaged software, Clear has a goal this year of increasing their upstream components available on the distribution by three times. Intel Fellow Arjan van de Ven provided an update on their bundling state/changes for the distribution. In this update he shared that the Clear Linux team at Intel established a goal this year to have "three times more upstream components in the distro. That's a steep growth, and we want to do that with some basic direction and without reducing quality/etc. We have some folks figuring out what things are the most desired that we lack, so we can add those with most priority... but this is where again we more than welcome feedback."
  • The results from our past three Linux distro polls
    You might think this annual poll would be fairly similar from year to year, from what distros we list to how people answer, but the results are wildly different from year to year. (At the time of the creation of each poll, we pull the top 15 distributions according to DistroWatch over the past 12 months.) Last year, the total votes tallied in at 15,574! And the winner was PCLinuxOS with Ubuntu a close second. Another interesting point is that in 2018, there were 950 votes for "other" and 122 comments compared to this year with only 367 votes for "other" and 69 comments.
  • Fedora Strategy FAQ Part 3: What does this mean for Fedora releases?
    Fedora operating system releases are (largely) time-based activity where a new base operating system (kernel, libraries, compilers) is built and tested against our Editions for functionality. This provides a new source for solutions to be built on. The base operating systems may continue to be maintained on the current 13 month life cycle — or services that extend that period may be provided in the future. A solution is never obligated to build against all currently maintained bases.
  • How open data and tools can save lives during a disaster
    If you've lived through a major, natural disaster, you know that during the first few days you'll probably have to rely on a mental map, instead of using a smartphone as an extension of your brain. Where's the closest hospital with disaster care? What about shelters? Gas stations? And how many soft story buildings—with their propensity to collapse—will you have to zig-zag around to get there? Trying to answer these questions after moving back to earthquake-prone San Francisco is why I started the Resiliency Maps project. The idea is to store information about assets, resources, and hazards in a given geographical area in a map that you can download and print out. The project contributes to and is powered by OpenStreetMap (OSM), and the project's entire toolkit is open source, ensuring that the maps will be available to anyone who wants to use them.
  • Millions of websites threatened by highly critical code-execution bug in Drupal

    Drupal is the third most-widely used CMS behind WordPress and Joomla. With an estimated 3 percent to 4 percent of the world's billion-plus websites, that means Drupal runs tens of millions of sites. Critical flaws in any CMS are popular with hackers, because the vulnerabilities can be unleashed against large numbers of sites with a single, often-easy-to-write script.

  • Avoiding the coming IoT dystopia
    Bradley Kuhn works for the Software Freedom Conservancy (SFC) and part of what that organization does is to think about the problems that software freedom may encounter in the future. SFC worries about what will happen with the four freedoms as things change in the world. One of those changes is already upon us: the Internet of Things (IoT) has become quite popular, but it has many dangers, he said. Copyleft can help; his talk is meant to show how. It is still an open question in his mind whether the IoT is beneficial or not. But the "deep trouble" that we are in from IoT can be mitigated to some extent by copyleft licenses that are "regularly and fairly enforced". Copyleft is not the solution to all of the problems, all of the time—no idea, no matter how great, can be—but it can help with the dangers of IoT. That is what he hoped to convince attendees with his talk. A joke that he had seen at least three times at the conference (and certainly before that as well) is that the "S" in IoT stands for security. As everyone knows by now, the IoT is not about security. He pointed to some recent incidents, including IoT baby monitors that were compromised by attackers in order to verbally threaten the parents. This is "scary stuff", he said.

KDE: Slackware's Plasma5, KDE Community 'Riot' (Matrix), Kdenlive Call for Testers/Testing

  • [Slackware] Python3 update in -current results in rebuilt Plasma5 packages in ktown
    Pat decided to update the Python 3 to version 3.7.2. This update from 3.6 to 3.7 broke binary compatibility and a lot of packages needed to be rebuilt in -current. But you all saw the ChangeLog.txt entry of course. In my ‘ktown’ repository with Plasma5 packages, the same needed to happen. I have uploaded a set of recompiled packages already, so you can safely upgrade to the latest -current as long as you also upgrade to the latest ‘ktown’. Kudos to Pat for giving me advance warning so I could already start recompiling my own stuff before he uploaded his packages.
  • Alternatives to rioting
    The KDE Community has just announced the wider integration of Matrix instant messaging into its communications infrastructure. There are instructions on the KDE Community Wiki as well. So what’s the state of modern chat with KDE-FreeBSD? The web client works pretty well in Falkon, the default browser in a KDE Plasma session on FreeBSD. I don’t like leaving browsers open for long periods of time, so I looked at the available desktop clients. Porting Quaternion to FreeBSD was dead simple. No compile warnings, nothing, just an hour of doing some boilerplate-ish things, figuring out which Qt components are needed, and doing a bunch of test builds. So that client is now available from official FreeBSD ports. The GTK-based client Fractal was already ported, so there’s choices available for native-desktop applications over the browser or Electron experience.
  • Ready to test [Kdenlive]?
    If you followed Kdenlive’s activity these last years, you know that we dedicated all our energy into a major code refactoring. During this period, which is not the most exciting since our first goal was to simply restore all the stable version’s features, we were extremely lucky to see new people joining the core team, and investing a lot of time in the project. We are now considering to release the updated version in April, with KDE Applications 19.04. There are still a few rough edges and missing features (with many new ones added as well), but we think it now reached the point where it is possible to start working with it.

Preliminary Support Allows Linux KVM To Boot Xen HVM Guests

As one of the most interesting patch series sent over by an Oracle developer in quite a while at least on the virtualization front, a "request for comments" series was sent out on Wednesday that would enable the Linux Kernel-based Virtual Machine (KVM) to be able to boot Xen HVM guests. The 39 patches touching surprisingly just over three thousand lines of code allow for Linux's KVM to run unmodified Xen HVM images as well as development/testing of Xen guests and Xen para-virtualized drivers. This approach is different from other efforts in the past of tighter Xen+KVM integration. Read more

Servers: Kubernetes, SUSE Enterprise Storage and Microsoft/SAP

  • Kubernetes and the Cloud
    One of the questions I get asked quite often by people who are just starting or are simply not used to the “new” way things are done in IT is, “What is the cloud?” This, I think, is something you get many different answers to depending on who you ask. I like to think of it this way: The cloud is a grouping of resources (compute, storage, network) that are available to be used in a manner that makes them both highly available and scalable, either up or down, as needed. If I have an issue with a resource, I need to be able to replace that resource quickly — and this is where containers come in. They are lightweight, can be started quickly, and allow us to focus a container on a single job. Containers are also replaceable. If I have a DB container, for instance, there can’t be anything about it that makes it “special” so that when it is replaced, I do not lose operational capability.
  • iSCSI made easy with SUSE Enterprise Storage
    As your data needs continue to expand, it’s important to have a storage solution that’s both scalable and easy to manage. That’s particularly true when you’re managing common gateway resources like iSCSI that provide interfaces to storage pools built in Ceph. In this white paper, you’ll see how to use the SUSE Enterprise Storage openATTIC management console to create RADOS block devices (RBDs), pools and iSCSI interfaces for use with Linux, Windows and VMware systems.
  • Useful Resources for deploying SAP Workloads on SUSE in Azure [Ed: SUSE never truly quit being a slave of Microsoft. It's paid to remain a slave.]
    SAP applications are a crucial part of your customer’s digital transformation, but with SAP’s move to SAP S/4HANA, this can also present a challenge.