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

5 tips for making documentation a priority in open source projects

Open source software is now mainstream; long gone are the days when open source projects attracted developers alone. Nowadays, users across numerous industries are active consumers of open source software, and you can't expect everyone to know how to use the software just by reading the code. Even for developers (including those with plenty of experience in other open source projects), good documentation serves as a valuable onboarding tool when people join a community. People who are interested in contributing to a project often start by working on documentation to get familiar with the project, the community, and the community workflow. Read more

5 reasons to run Kubernetes on your Raspberry Pi homelab

There's a saying about the cloud, and it goes something like this: The cloud is just somebody else's computer. While the cloud is actually more complex than that (it's a lot of computers), there's a lot of truth to the sentiment. When you move to the cloud, you're moving data and services and computing power to an entity you don't own or fully control. On the one hand, this frees you from having to perform administrative tasks you don't want to do, but, on the other hand, it could mean you no longer control your own computer. This is why the open source world likes to talk about an open hybrid cloud, a model that allows you to choose your own infrastructure, select your own OS, and orchestrate your workloads as you see fit. However, if you don't happen to have an open hybrid cloud available to you, you can create your own—either to help you learn how the cloud works or to serve your local network. Read more

today's howtos and leftovers

  • Linux commands for user management
  • CONSOOM All Your PODCASTS From Your Terminal With Castero
  • Install Blender 3D on Debian 10 (Buster)
  • Things To Do After Installing openSUSE Leap 15.2
  • GSoC Reports: Fuzzing Rumpkernel Syscalls, Part 2

    I have been working on Fuzzing Rumpkernel Syscalls. This blogpost details the work I have done during my second coding period.

  • Holger Levsen: DebConf7

    DebConf7 was also special because it had a very special night venue, which was in an ex-church in a rather normal building, operated as sort of community center or some such, while the old church interior was still very much visible as in everything new was build around the old stuff. And while the night venue was cool, it also ment we (video team) had no access to our machines over night (or for much of the evening), because we had to leave the university over night and the networking situation didn't allow remote access with the bandwidth needed to do anything video. The night venue had some very simple house rules, like don't rearrange stuff, don't break stuff, don't fix stuff and just a few little more and of course we broke them in the best possible way: Toresbe with the help of people I don't remember fixed the organ, which was broken for decades. And so the house sounded in some very nice new old tune and I think everybody was happy we broke that rule.

Programming Leftovers

  • Podcast: COBOL development on the mainframe

    Nic reached out when COBOL hit the news this spring to get some background on what COBOL is good for historically, and where it lives in the modern infrastructure stack. I was able to talk about the basics of COBOL and the COBOL standard, strengths today in concert with the latest mainframes, and how COBOL back-end code is now being integrated into front ends via intermediary databases and data-interchange formats like JSON, which COBOL natively supports.

  • What I learned while teaching C programming on YouTube

    The act of breaking something down in order to teach it to others can be a great way to reacquaint yourself with some old concepts and, in many cases, gain new insights. I have a YouTube channel where I demonstrate FreeDOS programs and show off classic DOS applications and games. The channel has a small following, so I tend to explore the topics directly suggested by my audience. When several subscribers asked if I could do more videos about programming, I decided to launch a new video series to teach C programming. I learned a lot from teaching C, and in the process, I came across some meaningful takeaways I think others will appreciate. Make a plan For my day job, I lead training and workshops to help new and emerging IT leaders develop new skills. Outside of regular work, I also enjoy teaching as an adjunct professor. So I'm very comfortable constructing a course outline and designing a curriculum. That's where I started. If you want to teach a subject effectively, you can't just wing it. Start by writing an outline of what topics you want to cover and figure out how each new topic will build on the previous ones. The "building block" method of adding new knowledge is key to an effective training program.

  • Google's Flutter 1.20 framework is out: VS Code extension and mobile autofill support
  • Google Engineers Propose "Machine Function Splitter" For Faster Performance

    Google engineers have been working on the Machine Function Splitter as their means of making binaries up to a few percent faster thanks to this compiler-based approach. They are now seeking to upstream the Machine Function Splitter into LLVM. The Machine Function Splitter is a code generation optimization pass for splitting code functions into hot and cold parts. They are doing this stemming from research that in roughly half of code functions that more than 50% of the code bytes are never executed but generally loaded into the CPU's data cache.

  • Modernize network function development with this Rust-based framework

    The world of networking has undergone monumental shifts over the past decade, particularly in the ongoing move from specialized hardware into software defined network functions (NFV) for data plane1 and packet processing. While the transition to software has fashioned the rise of SDN (Software-defined networking) and programmable networks, new challenges have arisen in making these functions flexible, efficient, easier to use, and fast (i.e. little to no performance overhead). Our team at Comcast wanted to both leverage what the network does best, especially with regards to its transport capacity and routing mechanisms, while also being able to develop network programs through a modern software lens—stressing testing, swift iteration, and deployment. So, with these goals in mind, we developed Capsule, a new framework for network function development, written in Rust, inspired by Berkeley's NetBricks research, and built-on Intel's Data Plane Development Kit (DPDK).

  • This Week in Rust 350
  • Firefox extended tracking protection

    This Mozilla Security Blog entry describes the new redirect-tracking protections soon to be provided by the Firefox browser.

  • Karl Dubost: Browser developer tools timeline

    I was reading In a Land Before Dev Tools by Amber, and I thought, Oh here missing in the history the beautifully chiseled Opera Dragonfly and F12 for Internet Explorer. So let's see what are all the things I myself didn't know.

  • Daniel Stenberg: Upcoming Webinar: curl: How to Make Your First Code Contribution

    Abstract: curl is a wildly popular and well-used open source tool and library, and is the result of more than 2,200 named contributors helping out. Over 800 individuals wrote at least one commit so far. In this presentation, curl’s lead developer Daniel Stenberg talks about how any developer can proceed in order to get their first code contribution submitted and ultimately landed in the curl git repository. Approach to code and commits, style, editing, pull-requests, using github etc. After you’ve seen this, you’ll know how to easily submit your improvement to curl and potentially end up running in ten billion installations world-wide.