Pinderkent

I read an article today, written by Andrew Whitworth, that discusses Parrot and its fitness as a target platform. His article, along with other recent developments, may very well answer the question I asked nearly three years ago, Will Parrot ever truly deliver? Unfortunately, the answer appears to be a resounding No.

For those who might not be aware, Parrot is, according to their web site, a "virtual machine designed to efficiently compile and execute bytecode for dynamic languages." Although it has been in development for about a decade, there has been comparatively little to show for all of the effort that has gone into it. Sure, there have been frequent releases, but in the end we still don't have a platform that garners much attention, and we still don't see anyone really putting forth a lot of effort to target it.

Andrew's article helps highlight why both language implementors and users may be hesitant to spend time targeting Parrot. Towards the end of his article, he covers parts of the system that he thinks will be seeing major changes within the next few months. Throughout these seven points, we see some very unsettling things. The very first point, for instance, mentions that, "GC is a very internal thing, when it works properly, you don't even need to know it exists." Now, garbage collection isn't a trivial task, but it has been very well studied and implemented many times over in real-world systems. Although we can't expect any such system to be perfect, it is unsettling when we read statements like "when it works properly" regarding a ten-year-old virtual machine platform. There just shouldn't be so much doubt about such a fundamental part of a virtual machine.

The second point is no better. Just-in-time compilation, like garbage collection, is another one of those cornerstones of a VM that we should expect to be mature and robust after 10 years. It's very worrisome to read that Parrot is lacking so badly in this area, even after two major releases.

The third point is perhaps the worse of all. In it, he states, "We don't really have a good, working, reliable threads implementation now and HLLs are generally not using them." It's currently 2010, and the situation today is that almost all new desktop PCs, and even many notebooks and netbooks, have a CPU with at least two cores. Most server-grade computer systems offer several times that, with multiple CPUs, with multiple cores per CPU, and even multiple threads of simultaneous execution per core. Efficiently using these systems to their full potential currently means writing multithreaded software. Like garbage collection and just-in-time compilation, threading has been well-studied, implemented repeatedly, and is one of the major pieces of any virtual machine platform. There's just no excuse for Parrot not to have better multithreading support.

The fifth point is pretty serious, as well. It discusses packfiles, which are the files that contain Parrot bytecode, debug data, and so forth. This is one more essential part of any VM implementation that should be very mature after a decade's worth of development. It's disappointing to hear that there are still portability issues with these files after so many years.

After reading about those rather serious deficiencies, I have a hard time understanding how Andrew can suggest that, "In summary, Parrot is a good, stable platform for HLL developers to use." From what I can see, Parrot is a platform that has had a lot of time and opportunity to make something of itself, but due to various problems, from internal developer strife, to a bad reputation, to a lack of serious users, it just hasn't matured.

Since I wrote my other article about Parrot almost three years ago, we've seen major developments out of the other major VM providers. We're seeing the Java platform get better support for dynamic languages in the upcoming JDK 7 release. We've also seen Microsoft's Dynamic Language Runtime become available for their .NET platform, allowing for mature and usable language implementations like IronRuby and IronPython to be developed.

Perhaps the biggest threat of all to Parrot is LLVM. LLVM has become widely accepted by industry, and even significant open source projects like FreeBSD are integrating and supporting it. In addition to having excellent support for C, C++ and Objective-C, we're even seeing it used as the back-end for dynamic programming language implementations. Rubinius and MacRuby are two examples of Ruby implementations that support LLVM. Then there are Python implementations like Unladen Swallow and PyPy.

I just don't think that Parrot can compete with these other platforms. Parrot has spun its wheels for far too long, and just isn't as mature as the JVM, the .NET CLR, or LLVM have become. Aside from casual or hobby development, I don't see why anyone would develop a software system specifically targeting Parrot. Its future seems extremely bleak at this point.

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.