{"id":2251,"date":"2020-04-13T15:00:00","date_gmt":"2020-04-13T15:00:00","guid":{"rendered":"https:\/\/icrowdnewswire.com\/?p=2507952"},"modified":"2020-04-13T15:00:00","modified_gmt":"2020-04-13T15:00:00","slug":"not-actually-linux-distro-review-deux-ghostbsd","status":"publish","type":"post","link":"http:\/\/ipsnews.net\/business\/2020\/04\/13\/not-actually-linux-distro-review-deux-ghostbsd\/","title":{"rendered":"Not actually Linux distro review deux: GhostBSD"},"content":{"rendered":"

FreeBSD-derived GhostBSD welcomes users directly into a full desktop experience.<\/h2>\n
\"If<\/section>\n
When I began work on the FreeBSD<\/a> 12.1-RELEASE review<\/a> last week, it didn’t take long to figure out that the desktop portion wasn’t going very smoothly.<\/p>\n

 <\/p>\n

I think it’s important for BSD-curious users to know of easier, gentler alternatives, so I did a little looking around and settled on GhostBSD<\/a> for a follow-up review.<\/p>\n

History<\/h2>\n

GhostBSD is based on TrueOS<\/a>, which itself derives from FreeBSD Stable. It was originally a Canadian distro, but—like most successful distributions—it has transcended its country of origin and can now be considered worldwide. Significant GhostBSD development takes place now in Canada, Italy, Germany, and the United States.<\/p>\n

The history of desktop-oriented BSD distros is a turbulent one. For several years, Kris Moore’s PC-BSD was the go-to for “I want BSD, but I also want a ready-to-go desktop.” Eventually, ixSystems<\/a>—home of the FreeNAS<\/a> storage distro, and the company Moore is vice president of engineering for—came to rely heavily on the server-side features developed into PC-BSD.<\/p>\n

The need at ixSystems for the foundation of PC-BSD without the associated desktop led to a rename and a fork. PC-BSD’s underpinnings became TrueOS, and the desktop-friendly distribution—now based on TrueOS—became Project Trident<\/a>.<\/p>\n

This state of affairs didn’t last long. A year later, Project Trident declared unhappiness with TrueOS and BSD in general—mostly due to hardware support, or lack thereof. In January 2020, Trident rebased<\/a> itself on Void Linux<\/a>, which its developers found to be “the most BSD-like” of the potential Linux upstream distros they examined.<\/p>\n

Project Trident’s departure for more Linux-y waters left several potential contenders for a desktop-focused BSD distribution. These include FuryBSD<\/a>, MidnightBSD<\/a>, DesktopBSD<\/a>, and GhostBSD<\/a> itself.<\/p>\n

I’ve tested PC-BSD fairly extensively in the past but have no history with any of the current desktop BSD choices. I chose GhostBSD for a first look, solely due to its prominence in Google search results for “desktop BSD distro.”<\/p>\n

Live installation environment<\/h2>\n

<\/p>\n

\"The\"After<\/p>\n

GhostBSD’s installation process is a pretty radical departure from FreeBSD’s, although the underlying roots are still there. After defaulting or selecting multi-user boot, the user is presented with an ncurses<\/a> ASCII menu allowing X (the graphical display server) configuration.<\/p>\n

It’s a bit of a shame that the installer isn’t yet capable of simply autodetecting the graphics environment the way typical Linux installers do. But to be fair, the manual selection could also make things easier for slightly wonky hardware—the option to fallback to simple vesa mode is staring you right in the face, after all, should you try a direct Intel\/AMD\/Nvidia driver and fail.<\/p>\n

I’m doing an installation in a virtual machine, so I selected vesa. Two seconds or less after hitting enter, a fully functional MATE<\/a>-based live desktop was up and running, with a link to the installer script prominently placed on the desktop. I didn’t mess around in the live desktop—I double-clicked the installer immediately.<\/p>\n

Installation<\/h2>\n

<\/p>\n

\"GhostBSD\"GhostBSD\"With\"GhostBSD<\/p>\n

GhostBSD’s installation process is tremendously more straightforward than FreeBSD’s. After double-clicking the installer, you’re asked to select a disk configuration. Like FreeBSD, we’re offered the chance for a ZFS root setup, including multiple disk topology.<\/p>\n

The mouse was, for some reason, extremely unresponsive and erratic in this menu and required significant patience. This is probably an artifact of the VM installation; I strongly suspect it would not have been an issue on bare metal.<\/p>\n

The options I was given here were a little different from FreeBSD’s. Instead of telling me little white lies about what a vdev is, GhostBSD asked me to select a “pool type.” The options available were single disk, two disk mirror, three disk RAIDz1 (similar to RAID5—a stripe with single parity), four or five disk RAIDz2 (similar to RAID6—a stripe with dual parity), or “2+ disk stripe.”<\/p>\n

“Force ZFS 4K block size” is an optional checkbox here, and I made sure it was selected. My disks are advanced format (4K sector size) disks, so if ZFS installs with 512-byte sectors, performance will be bad. Unfortunately, it doesn’t seem that the checkbox setting was actually honored—more on that later.<\/p>\n

Although I wanted a pool of mirrors eventually, one two-disk mirror was fine for the moment. I selected a single two-disk mirror, with plans to zpool add<\/code> my remaining two disks as another mirror vdev after installation completed.<\/p>\n

With disk configuration complete, GhostBSD asked me to create a user account. It did not present this as an “optional” process, and it didn’t drag the process out, either. Hostname, friendly username, real username, password, and default shell are all configured on a single screen, along with a password strength identifier. The default shell offered was fish—I don’t know fish, but I left it as-is to get the normal out-of-box experience.<\/p>\n

Like just about every password strength identifier, the one in GhostBSD’s user setup screen was pretty useless—it informed me that “Password1!” was a strong password. Oh, well.<\/p>\n

With both the machine and myself named and a nice “strong” password entered, GhostBSD got on with the process of installing itself. Installation did not take very long.<\/p>\n

Although this was in general a very simple, easy, and friendly setup experience, GhostBSD’s installer dropped a minor note at the very end. Once the installer had finished, it just dumped me back out at the desktop, without offering to reboot—and without letting me know I’d need to reboot, in order to get into my freshly installed system.<\/p>\n

This isn’t likely to throw many people who are actually interested in trying out a BSD, of course—but it’s an easy paper cut to fix.<\/p>\n

First boot<\/h2>\n

<\/p>\n

\"I\"Now\"Ta-da!<\/p>\n

First boot into the new GhostBSD system was a bit of a mixed bag. GhostBSD booted rapidly and got right into the desktop. Applications also popped open instantly, with none of FreeBSD’s feeling of lag or sluggishness.<\/p>\n

The question was, where were the application launchers? I didn’t realize it yet, but the top MATE panel had crashed, leaving a blank black bar behind. The empty black panel blended into the default background well enough that I spent a confused first few minutes thinking the system was just a bit on the primitive side.<\/p>\n

Right-clicking an empty area on the desktop offered me an Open in Terminal<\/code> option in the context menu, so I did that. Although I was using fish<\/code>, an unfamiliar shell, it didn’t get in the way—the delete key wasn’t a beeping tilde machine like FreeBSD’s version of sh<\/code>, and the basic functionality one would expect from a shell was intact.<\/p>\n

From here, I became root with the su<\/code> command (sudo<\/code> is also preinstalled and available in GhostBSD). After stumbling once on syntax—pkg install<\/code>, not pkg add!<\/code>—installing Firefox from the command line went exactly as it should, and rapidly. GhostBSD uses its own repository—http:\/\/pkg.us.ghostbsd.org\/stable<\/code> was preconfigured for me—and it had plenty of bandwidth available.<\/p>\n

There was no Firefox icon on the desktop after pkg<\/code> finished doing its thing, and I still hadn’t twigged to the crashed MATE top panel, so I right-clicked the desktop again. Create Launcher<\/code> is another of the context menu options there, so I did that, browsed to \/usr\/local\/bin<\/code>, and presto—there was a shiny new Firefox icon on the desktop, which did just what it should.<\/p>\n

Firefox’s application launch was very snappy, again unlike my experience with FreeBSD and Gnome3. In fact, Firefox launched on GhostBSD a bit quicker than it does in my host operating system, Ubuntu 19.10.<\/p>\n

Finding the missing bits<\/h2>\n

<\/p>\n

\"Firefox\"Diving<\/p>\n

I was still frustrated with how primitive everything seemed, however snappy. Surely everything didn’t need to be done by hand like this? And where were the system tools—a GUI-based package selection system, volume controls, and so forth?<\/p>\n

Finally, I spotted the small black area at the top of the desktop and right-clicked it. This produced a new context menu, most importantly including Reset Panel<\/code>. Oh, hey, how about that—there’s all my missing functionality!<\/p>\n

With the panel reset, it was obvious what the procedure was supposed<\/em> to be here. A new user should have been able to click the Applications menu, go to Internet, and find Firefox in there. A single-click opens Firefox from the panel; a right-click offers the option to create a new launcher for it either on the desktop or in the top panel itself.<\/p>\n

This is also where missing tools like system information, volume controls, and so forth had been lurking. GhostBSD suddenly felt a lot more functional—it had just needed one shrewd kick to get going.<\/p>\n

With everything working properly, next I dove back into the MATE Terminal to add my remaining pair of disks. Before doing so, I checked ashift<\/code>, the ZFS property that defines the minimum block size on disk. Unfortunately, despite having made certain the “Force ZFS 4K block size” option was checked during installation, I discovered ashift<\/code> set to 9—meaning 2^9, or 512-byte sectors.<\/p>\n

As snappy as GhostBSD felt so far, it would have been even better if it had been using the correct hardware blocksize like I asked it to. Fortunately, the VM’s underlying storage is a very fast solid state pool, so the omission hadn’t made things too painful.<\/p>\n

Unfortunately, ashift<\/code> is immutable once set. So I sighed, did a zpool add tank mirror \/dev\/vtbd2 \/dev\/vtbd3<\/code> to get my remaining pair of virtual disks added to the pool, and went on my way.<\/p>\n

The disk sector size issue would have been a much bigger disappointment—and problem!—in real life, but it wasn’t worth derailing a VM test for.<\/p>\n

A quick look at GhostBSD’s Control Center<\/h2>\n

<\/p>\n

\"Software\"Software\"A<\/p>\n

Most of GhostBSD’s MATE Control Center is quite pleasant and modern. One unfortunate exception is Software Station, GhostBSD’s GUI-based package management app.<\/p>\n

I don’t want to oversell Software Station’s problems, here—it’s perfectly functional, although it is a bit primitive and could use a considerable amount of developer love. In particular, it desperately needs resizable columns.<\/p>\n

Software Station is broken into categories that veteran FreeBSD users will immediately recognize from the ports tree. Each package’s information is broken out into fixed-width columns—and the ones for Package Name, Version, and Size are all significantly wider than necessary. As a result, very little of the package descriptions are visible without scrolling horizontally right.<\/p>\n

The Package Name column is littered with names like at-spi2-atk<\/code>, eflite<\/code>, py37-atspi<\/code>, and so forth. Those names must be brief for command line management, but they won’t mean much to a new user—or to many well-established users. Scrolling horizontally all the way right to read the friendly package description, in turn, hides everything but the version number and size.<\/p>\n

Again, to be fair, we’re in a VM here—and its resolution, 1024×768, would be absurdly low on bare metal. Much more data would be visible without scrolling on a full 1080p desktop. On the other hand, a budget laptop’s 1366×768 display would have been nearly as cramped as this one.<\/p>\n

Adding insult to injury, GhostBSD’s vesa driver wouldn’t let me choose a higher resolution than 1024×768 at all. Again, this wouldn’t likely be an issue on real hardware—but it wouldn’t have been an issue in a typical Linux VM, either.<\/p>\n

Conclusions<\/h2>\n

GhostBSD is a perfectly reasonable choice for a desktop distribution. It still lags behind most of its mainstream Linux counterparts in one or two places, but I didn’t discover any real show-stoppers or WTFs.<\/p>\n

There were no obvious performance issues, and GhostBSD might in fact have been a little snappier than Ubuntu 19.10, the host operating system it was virtualized under. Audio worked out of the box, and with Firefox installed, YouTube videos played well.<\/p>\n

Google Chrome is still going to be a no-go under GhostBSD—at least without truly Herculean efforts. I did search for Chrome installation stories, but all I found were “you can’t have that under BSD” answers. This won’t matter for YouTube, but it will present significant stumbling blocks for users who need Chrome plugins or streaming websites that depend on proprietary Chrome features.<\/p>\n

I liked GhostBSD’s ZFS installer dialog much better than FreeBSD’s—but I was deeply disappointed in its failure to honor its own “Force ZFS 4K block size” checkbox. That would have been a major stumbling block and source of performance problems on a real installation and real hardware.<\/p>\n

Most disks will truthfully report their own block size, and ZFS will honor it—but some, like the Samsung Pro SSDs in my workstation, lie through their teeth and claim to have 512 byte sectors. This is a legacy of Windows XP, which would cough up a hairball when presented with a disk with any hardware blocksize other than 512 byte.<\/p>\n

A veteran ZFS user could likely work around the block size issue. We didn’t test this specifically, but it should be relatively simple to pull a terminal after pool creation and before installation, destroy the pool GhostBSD created, and replace it with a new one with the proper ashift<\/code> setting.<\/p>\n

Absent a specific desire for BSD under the hood, I’d have a tough time recommending GhostBSD in place of one of the more mainstream Linux distributions. But that’s a pretty high bar to hurdle, and I would not<\/em> have any issues recommending GhostBSD to a user—even one new to Unix-like operating systems—who does specifically want a BSD-based desktop.<\/p>\n

Most of the few warts I found in GhostBSD are eminently fixable, and polish is clearly important to its community and dev team. I suspect that the majority of the issues I discovered in this review will be fixed in its next release.<\/p>\n

The good<\/h2>\n