dd if=/dev/random of=/dev/blog

On 23 October, 2009 it was announced on MacOSForge that Apple had decided to discontinue any and all development on the porting of the ZFS file system. I know that I am not the only one to say this but I am not surprised. Supposedly there were legal reasons behind this action but in the end, who cares? They are the ones losing out to continue with an out dated and still limiting file system.

Now Apple has recently been hiring file system developers to develop a next generation file system to replace the traditional HFS+ but (as Robin Harris has previously stated) how long will it take before it becomes stable and accepted by the general public? Traditionally it takes 5+ years before a file system is considered somewhat stable and ready for production use. It wasn’t until recently that ZFS was starting to make its impact in the enterprise scene. Though my question is, to whom will this next generation file system cater to? I am to assume that it will be for the general end user utilizing Mac devices that “don’t require the weight of the ZFS features and functionality” ; or so it has been said regarding the topic of Apple abandoning the ZFS project. If that is the case and is the primary focus of the new file system, how will this impact their server market share? We already know that there is no such thing as a perfect file system that will perform ideally in every arena it is thrown into. Some will excel more than others and is entirely dependent on its implementation and workload.

In past posts, I have always stressed the importance of the file system and what is integrated within the file system. I routinely point out the numerous drawbacks and limitations of the NTFS driver. Sure, Microsoft compensates for the “lack of features” with applications, services and additional APIs to fill in all those gaps. A good example is VSS (shadow copy). This can impact performance as it is taking file system concepts out from kernel mode and into user land and consuming user mode resources. All these feature should and need to be incorporated into the file system driver. That way we can ensure that there is stability and consistency with all functions the file system performs. Even the general layout is not ideal for traditional computing over large storage media; as the fragmented large seeks between the MFT and the file data can put a lot of stress on the magnetic device. Going back to HFS+ and sort of on the same topic (although the concept is a bit different), the same could be said about Apple’s Time Machine and it running as an application on top of the driver.

One thing that I hold to heart when it comes to file systems is the ability and flexibility to tune it even without taking the mounted device(s) off-line. Most modern UNIX and Linux file systems offer a lot of tunable features (built into the driver!). For instance (through the ZFS character device node) I can dynamically alter file system variables (man 1 zfs). For this example I will focus on access times. Let us say I am using an SSD and decide that it would be more cell friendly and better performing to disable file access times on the root mount.

To view current settings and disable this feature you would type the following in the command-line terminal:

I just hope that Apple is prepared for the journey they are about to embark on. They obviously have file system development experience, and I have no doubts that they have the talent. Do they have the patience and time to invest?

Yesterday afternoon I was really bored at work and had eventually navigated to a website dedicated to Easter Eggs that could be found on an operating system, software application and more. Naturally I went to the list of operating systems and started looking up the operating systems which were accessible to me. As I read through the Linux and UNIX related ones, I had already known some but there were a few that I was interested in trying.

Seeing how I was on an OpenSolaris laptop I decided to first look through the SunOS list. Unfortunately none of them seemed to work. It would appear that they were taken out. But I did remember one from many years ago that a friend (Marian Lakov) had shown me. Originally found on an installation of RHEL, it was in the man page for the xorg.conf file.

Listed under the VIDEOADAPTER SECTION you will read the following: Nobody wants to say how this works. Maybe nobody knows…

If you know of any hidden secret(s) that is not listed on the site posted earlier, please feel free to share.

Before I continue with my entry, I just wish to note that VirtualBox 2.2.4 has been released. You can review the Changelog here.

Anyways, whenever virtualizing a non-Windows operating system which utilizes the X Windowing system over VirtualBox, it may be beneficial to have some flexibility on supported resolutions for the GUI. For example, I was using OpenSolaris 2008.11 and VirtualBox seems to create a “virtual” monitor where the operating system (specifically X) is unable to read the monitor’s EDID information to obtain supported resolution information (among other things). As a result of this, by default X assigns 800×600@60 and 640×480@60 as supported display formats. When you are working on a wider screen that supports something larger, this makes for an uncomfortable computing experience; especially with limited graphical space on the virtual client.

In my case, my laptop’s wide screen has a native resolution of WXGA (1280×800). So I had plenty of extra room to work with. WhileVirtualBox allows you to fullscreen a virtual client, I like to multitask and this would limit my multitasking. I wanted to create a display configuration that would utilize most of the 1280×800 while allowing me to manage multiple other applications/windows on my host operating system. So I figured to write those entries manually in my xorg.conf file. This is located at /etc/X11/. So I began to play around with some standard display formats.

By default, OpenSolaris had the following under the “Screen” section:

Below that I added:

I then reloaded X by rebooting the virtual client and once the operating system came back up, all those options were available. No more default 800×600 and 640×480. In the image below you will notice that the OpenSolaris Virtual Client is displaying at a 1024×600.

Added Note 3Jun09: Please refer to Comments 1-3 for information on Guest Additions.

For those of you who are regular visitors, you may already know that before I started playing with GNU/Linux (2001/2) I was using FreeBSD. And while I continue to use GNU/Linux, I still hold an emotional tie to BSD-based operating systems. It was not until recently that I had decided to give the latest version of PC-BSD a try. This is version 7.1: Galileo Edition. A side note: PC-BSD is a desktop oriented version of FreeBSD intended to be extremely user friendly, primarily because of their implementation of their PBI package management system along with other features.

Installation

So I downloaded and began the installation of PC-BSD. The installation process was fairly quick and very simple. I am not complaining when I say this but I was a bit surprised to find the generic FreeBSD (actually PC-BSD) text only boot screen asking for the user to initiate the Default installer or any of the other options (which includes starting the installer with the experimental ZFS support). When I select the Default or when the boot screen times out to the Default, all components are loaded into memory and X loads into the graphical portion of the installation process. It is the same thing for the boot loader after the OS has been installed.

The graphical portion of this process went through the generic menus of “agreeing to the terms of the BSD licensing agreement”, along with obtaining preliminary root/user account information/configuration (such as default shell to even enabling auto-login). It also went through the process of selecting a disk device for UFS (default: with soft updates) file system and OS installation. NOTE: There is an option (for the advanced user) to customize the disk layout; and you can also use the original UFS file system without the soft updates or a third option of UFS with journaling enabled.

Just before the installer begins to copy all files to disk, you are prompted with an option of additional applications to install which range from Amarok, Filezilla, Firefox, Opera, OpenOffice, Pidgin, the source code, VLC and more. After all is confirmed, you just sit back and wait for the installation to complete and the system is rebooted.

Usability

The default graphical environment for this distribution is KDE 4.x. While I have always been more of a GNOME user (personal opinion: it is also easy to develop apps for GNOME with GTK+ and pyGTK), KDE 4 does look nice. While it takes some time to get used to it, I can respect the KDE community’s vision and implementation. They are challenging the norm and pushing the boundaries into a newer way of treating the desktop.

For a new user, everything has been categorized properly. From basic system configuration to other basic functionality. The one thing that I did want to try out with PC-BSD was the Push Button Installer (PBI). Instead of the pkg/rpm/deb/etc. packaging methods of installing applications, the PBI offers a graphical interface similar to the ones found on Microsoft Windows and the Mac OS X series of Operating Systems. This is great for users coming from that environment! You can view all available PBI application in the pbiDIR.

This installer works great and what I enjoy the most about it is if a PBI package requires the usage of WINE (installed by default), you do not need to bother to do anything else. The PBI takes care of everything for you and you can execute it like a normal Windows executable.

The best part of utilizing the PBI method is that there is a sense of consistency on where application programs get installed; and that is in the /Programs path. As much as this pains me to say, I wish to see more consistency with the /opt path in Linux.

Conclusion

While I only skimmed the surface with this article as I primarily wanted to emphasize the PBI application installation system, there is still so much more to do with PC-BSD. From the Wardens to Jails, and everything else that most GNU/Linux and UNIX users may be familiar with, PC-BSD is worth a try. It is extremely user friendly. And from the point of installation with auto-updates running in the background and having the right applications installed, I can see someone coming from a Windows environment and having little problems settling in. The development teams involved have done an excellent job in packaging this OS together.