Pinderkent

A few weeks back, at the end of December, FreeBSD 7.0-RC1 was released. FreeBSD 7 will no doubt prove to be quite revolutionary. For one thing, this will be the first major FreeBSD release in a number of years. FreeBSD 6.0 was released in November of 2005, so there has been quite some time for the development of FreeBSD 7 to take place.

If you're unfamiliar with what FreeBSD 7 will bring, I'd suggest that you look over the excellent What's cooking for FreeBSD 7? Web page. As you can see, the amount of change FreeBSD 7 will bring is quite significant.

I'm particularly looking forward to FreeBSD's support for ZFS. ZFS alone is a rather revolutionary filesystem originally developed at Sun for Solaris. It addresses many of the difficult issues we face when it comes to dealing with the huge datasets that are becoming all too common these days.

Having support for ZFS available in FreeBSD will be a major win for those who already have extensive FreeBSD infrastructure in place, but need the features that ZFS offers. So it will become possible for them to continue using FreeBSD, rather than having to integrate Solaris into their network infrastructure. This proves very helpful in maintaining an effective, reliable server environment.

Another major improvement will be the use of the new jemalloc userland memory allocator. While phkmalloc has served us well for some time now, jemalloc has been designed from the ground-up to take into account the multiprocessor systems that are becoming virtually ubiquitous today. For those of us who are dealing with heavily threaded software running on multiprocessor systems, there is evidence that jemalloc will bring some significant performance gains.

Also of importance are the improvements to the networking stack. With gigabit (or faster) network cards being the norm these days, FreeBSD's support for TCP/IP Segmentation Offload (TSO) and Large Receive Offload (LRO) will no doubt prove to be very useful. Along with the new sendfile() implementation, and the improved sosend() functionality, we will likely see some large networking performance boosts.

There are, of course, many other improvements that have been made. There are security enhancements, improved audio support, libthr becoming the default threading library, updated support for executing Linux binaries, and the new SCHED_ULE replacement, just to name a few.

It's time for those of us in the IT profession to start considering the use of FreeBSD 7. The new features and improvements offered by this release will no doubt have a great impact for many of us. We will be getting better support for storing huge amounts of data, networking performance improvements to help us better transmit that data, and userland performance improvements to better let us manipulate it. And we can't forget to thank the many FreeBSD developers and contributors for all of the time and effort they have put into creating such an excellent operating system.

Today I was reading about the "Reduced Functionality" capability of Windows Vista. According to that article, Microsoft has now enabled this capability, which renders a "nongenuine" copy of Windows essentially unusable.

Frankly, I just can't see why anybody would want to use Windows Vista. I'm sure the questionable nature of this sort of functionality is quite obvious to most. And it's also pretty obvious how the misidentification of an installation as being "nongenuine" could be quite disasterous. A completely legitimate installation of Vista locking up accidentally because of such functionality could cost an individual or business a great deal of time and money.

Beyond that, we have readily-available, high-quality alternative operating systems that don't bother with such nonsense. These days, Ubuntu provides a very usable desktop or workstation OS. There are other Linux distributions that are more suited for server-oriented tasks. FreeBSD is another alternative for desktop/workstation and server usage. Of course, there are also NetBSD, OpenBSD, and DragonFly BSD. And we can't forget OpenSolaris.

Using such systems is just the safest thing to do. First of all, you get access to virtually all of the software used on such a system. Even if you have no interest in modifying or redistributing it, having the code available allows for inspection, should that be necessary.

The redistribution of such software is usually allowed, and often encouraged. With ISO images typically available for (free) download from the distribution or project itself, one has to worry little about accidentally obtaining pirated software.

And in terms of functionality, the essentials are all there. For many people, the transition would be quite easy. Those who use software like Firefox and OpenOffice.org on Windows could immediately use those same products on Linux, BSD or OpenSolaris.

The hardware support Linux offers today is excellent. For the past few years, I've encountered far more hardware supported out-of-the-box by Linux than I have with the Windows installations I have performed. The need for installing a separate driver is often nil.

So when it comes down to it, it really just doesn't make much sense why any person or organization would subject themselves to Windows Vista. The benefits just aren't there, and the dangers appear to be many. And what's more, there are free alternatives out there that can perform the same tasks just as well, if not better. It's really a no-brainer: Linux, OpenSolaris and/or BSD is the way to go!

I read today about the finstall effort for FreeBSD. It is a GUI installer for FreeBSD. Although it sounds like a helpful tool for some users, I don't think I'd want it to replace the existing sysinstall installation system.

One of the main benefits of sysinstall is that it's not a GUI installer. This means that it has relatively minimal requirements when it comes to video hardware. Furthermore, it is very usable when using only the keyboard. Thus, it isn't necessary to even have a mouse available. So it remains a very viable option, especially in hardware-limited situations.

Another benefit is that it's well-tested. It's been used in several major releases of FreeBSD now, and can be considered quite mature. For those of us who have used FreeBSD for a long time, we're quite familiar with how it works, and what its limitations are. It will no doubt take much time and effort to bring finstall to the quality level that sysinstall currently exhibits.

Being written in C, sysinstall is quite performant. This is important on older systems, which might not cope as well with the overhead of the Python-based finstall. Thankfully, those behind the finstall project seem to realize this, and have indicated in their blog entry that for the backend, "a C version that can be included in FreeBSD base system is planned."

I wish the best of luck to the finstall developers in their quest to develop a GUI installer for FreeBSD. But I do hope that FreeBSD retains the sysinstall installer, or at least a tool that is equivalent in most ways.

Those of us who are serious users of UNIX or UNIX-like systems have no doubt looked at ��ric L��v��nez's excellent UNIX Timeline at some point. If you haven't, I suggest that you do! The amount of information it offers is truly spectacular. But looking at it today, I came to a somewhat sad realization: the UNIX world has become quite homogenized.

This history of UNIX starts out in September of 1969. From then until after the release of UNIX TSS Fourth Edition in November of 1973, we see no forking or derivation. Between Fourth Edition and Fifth Edition, we see some forking starting to take place, in the form of PWB/UNIX and MERT. We witness more and more branching, up until 1981.

It is around that point that I think UNIX really starts to enter a 20-year period of significant growth and "individuality". Between 1980 and 1984, we see some pretty significant divergence. First, many of the major UNIX variants begin their lives. XENIX starts on August 25, 1980, while 4.0BSD is released in October of 1980. UNIX System III comes out in November of 1981. QUNIX (the precursor to QNX) hails from 1981, as well. HP-UX starts its life in 1982. Two of the most important UNIX variants begin at this time, too: SunOS 1.0 is released in February of 1982, followed by UNIX System V in January of 1983.

The period between 1984 and 1989 is truly a glorious time in the history of UNIX. SunOS blossomed during this period, with SunOS 2.0, 3.0 and 4.0 being released. We have the major 4.2BSD and 4.3BSD releases. Mach arises in 1985. The roots of AIX go back to 1986, which is also when IRIX began. With an impact still felt by Mac OS X users today, we have the release of NeXTSTEP 0.8 on October 12, 1988, and the release of NeXTSTEP 1.0 on September 18, 1989. Although not derived from UNIX itself, the development of Minix started during this time period (and we all know the impact it would later have on Linus and Linux).

Mind you, those are just the variants that ended up having the most significant impact on the UNIX computing world. As is clearly visible on the timeline, there were numerous other variants, with many focusing on a specific platform or domain. Regardless, what we notice is that this was an era of growth and innovation. There was a lot of diversity.

This trend continues into the 1990s. We have major events like the beginning of Linux in 1991, and the release of Solaris 2.0 in July of 1992. UnixWare came out in November of 1992. NeXTSTEP continued to evolve. On the BSD front, we see NetBSD, BSD/OS and FreeBSD arise. But now notice the trend on the timeline; we see far less sharing of code and ideas between the variants. This is especially evident between 1998 and 2001.

At this point, most of the activity is between Darwin, Mac OS X and Mac OS X server. We see some transfers of code and concept, such as XFS from IRIX to Linux. But otherwise, there's little interaction between the different variants.

Things are really starting to look bland between 2004 and today. In terms of actively-developed UNIX or UNIX-like operating systems, we're down to only a handful. The BSD world is perhaps the most diverse, where we have NetBSD, PC-BSD, DragonFly BSD, OpenBSD and FreeBSD. Other than that, the most active variants are Mac OS X, Linux, Solaris, HP-UX, Minix and AIX. IRIX has become mostly irrelevant, as have Tru64 UNIX, OpenServer and UnixWare.

We will have to wait and see what the future will bring. But it looks like it will likely be pretty isolated to only a few major UNIX or UNIX-like systems: FreeBSD, Mac OS X, Solaris, and Linux. Although activity will continue on HP-UX and AIX, no doubt, their influence may very well be minimal.

I have mixed feelings over how things have evolved. On one hand, we do have more powerful features concentrated in a smaller number of systems. And these systems are fairly prevalent, and well-constructed. But the diversity of the 1980s and early 1990s brought upon change and innovation at an exciting pace. A balance between the two extremes would likely be best, although it is suspect whether we will ever get there.

Today I shared the experience a friend had with one of the companies he works with. It involved a failed transition from what was mainly a console-based suite of applications powered by Sun systems and Oracle, to an AJAX and Web-based system running on Windows, .NET and SQL Server. It seems that that entry was submitted to Reddit, and so I've been reading some of the comments that were left there.

Some of the comments were quite insightful. But there were two that I found to be just plain funny! Here is the first comment, and here is the second comment.

In those comments I am accused of being "biased against windows and ajax" and guilty of "discrimination against Windows & dot-Net". Well, I would like to address those allegations!

First of all, I've been doing this long enough to not get to attached to certain products or technologies. In the end, it's all about solutions that work to solve the client's problems in an efficient and financially-sound way. I'm glad that I get to mostly work with Solaris, HP-UX, AiX, FreeBSD, Linux and other UNIX-like systems. But I've worked with Windows many times before. As long as the job gets done properly, I really don't care what software is being used.

In this case, my feelings regarding Windows, .NET and SQL Server have absolutely no impact on the problems that that company experienced with their transition. Beyond hearing about it from my friend, I had no involvement with the development of the old system, nor any involvement with the development of the new system.

Furthermore, the fact remains that the old, UNIX- and Oracle-based system worked just fine. The new .NET-based system did not work in a suitable manner. Pointing out that certain software did not perform in an adequate fashion in a certain situation does not indicate bias. All it indicates is that the software in question was not capable of performing what needed to be done.

Likewise, the AJAX-based UI proved inefficient compared to the previous curses-based interface. That's just how things worked out. Again, my feelings, thoughts or biases would have had absolutely no impact on the situation, as I was not involved.

I do thank the two comment authors for their thoughts and opinions. However, I also urge them to be more careful in the future when accusing others of bias. Just because a particular technology fails to work in a particular situation, and this failure becomes a topic of discussion, there is not necessarily bias against that technology. Sometimes technology fails. We must admit this, and learn from such failures.