Choosing the development environment.

So now that I have decided on Smalltalk as the primary language for my OS, it is time to talk about Smalltalk implementations. This ignores the ASM and low-level C that will initially be required to bootstrap the computer and VM which I will talk about in another post. I need a Smalltalk implementation that is compatibly licensed for what I plan to do with it. I need a Smalltalk that has good documentation available. I would like a Smalltalk that is self-hosted, in simpler terms a Smalltalk implementation written in itself. I want a modern Smalltalk that is still being maintained and used. I want a Smalltalk that does not feel like a Toy.

Before I write about what implementation I have chosen, lets first examine Smalltalk systems I have looked at in the past. In the past when I have looked at Smalltalk, I never found any good alternatives for my grand plans. I had seriously considered creating a brand new implementation based on the Smalltalk-80 specs and details found in the Blue Book.

GNU Smalltalk is an open source Smalltalk that does not heavily focus on the GUI and integrated development environment, in fact they have a pun "The Smalltalk for those who can type."  One of the great things I love about the Smalltalk-80 system was the GUI providing its own IDE in the run-time environment. Although being able to run in a headless or text only mode will probably be important while boot strapping an OS prior to having a GUI API available, the lack of a good GUI class library could hinder development once I get a graphical subsystem in place.

In addition GNU Smalltalk's GPL license on the VM would severally limit my licensing options through its viral nature. All though I love open source, I have come to dislike the GPL because of this viral nature. This is why we can't have nice things... ZFS on Linux? Sure there are ways around this, I am blogging from a Linux system running a tainted kernel with a ZFS root. It was a pain to setup, and because of license incompatibilities between the GPL (Linux kernel) and the CDDL (ZFS file-system from Sun) never the twain shall meet; unless someone decides to create a clean room implementation under the GPL. The GPL would be great, if all open source was written against the GPL. I want to borrow what I consider the best ideas from other libraries and systems, some of which may be incompatible with GPL. Most open source licenses are generally compatible with one another BSD, MIT, Apache, CDDL, MPL when it comes to linked binaries and API calls. Because of this I can not allow myself or the code to become tainted from GPL sources.

Another possibility would be Little Smalltalk. However Little Smalltalk is not a true Smalltalk-80 based system. The fact that it is small ( the interpreter is < 1800 lines of code ) would make the system easier to understand as a basis for building an OS on top of. Most links I can find for downloads appear to be broken and the parts I can find appear to be implemented on top of Java. I like Java, but I did not choose to build my system on a jvm, but rather on a Smalltalk-80 like core. This means that Little Smalltalk is not suitable for my needs.

Public Domain Smalltalk (PDST) is yet another implementation of Little Smalltalk. The license is great, having been released to the public domain, I can do what ever I want with it. Like Little Smalltalk, it is relatively small, which would make understanding the core system easier. Unfortunately it does not appear to be actively developed, and most links and references to it appear to be dead.

Squeak Smalltalk is an open source Smalltalk system that is nearly perfect for my needs. It is a self-hosted portable Smalltalk-80 implementation. In fact it is rumored that some of the object instances found in the image were from the original Xerox PARC system. This appears to be the legacy of those original developers of Smalltalk-80, it first went to Apple from Xerox, and eventually Apple released it under an open source license.

The portions of the Squeak code that came from Apple were originally released under the 'Squeak' license, and eventually re-licensed under the Apache License, Version 2.0. Those portions still carry copyright notices from both Xerox and Apple. The remainder is under the MIT License which is very open source license. Squeak is still being actively developed, improved, and used in the real world. There seems to be a good amount of documentation available.

So now my readers, if any, are probably assuming I decided to go with Squeak as my base development platform. That would be close, but no cigar. I had one last desire: an implementation that did not feel like a toy. Large portions of Squeak and its images focus around Etoys. Alan Kay continued working on development of Squeak as a platform for Etoys. Etoys is intended for child education, and is a great idea. I applaud Alan Kay for this work; however because of this Squeak eschews standard GUI interfaces, and feels unprofessional.

That covers most of the Open Source implementations of Smalltalk that I am aware of, so what else can I look at? There is one last free Smalltalk available, Smalltalk/X from Exept Software AG. Although it is not technically open source, it is freely licensed, with a few exceptions. Since I do not plan on making a military system, patenting food, animal, or human genomes, work with genetic-engineering or produce landmines I am free to make a commercial system with Smalltalk/X royalty free. Smalltalk/X includes the C source code and will run on Linux for bootstrapping my OS. The only real problem I have with it is that Exept is a German based company. Most of the documentation links I have found do not have an English page, or the English page is not properly linked. Some can be guessed by changing a portion of the URL /de/ to /en/. This lack of good English documentation is a show-stopper, and I am not even sure if Smalltalk/X is truly self-hosted.

What else is left? The only commercial Smalltalk system I have ever looked at is Cincom's Visualworks. In the past when I have played around with Smalltalk I have either used this or Squeak. Visualworks is a great commercial product. It has nice threading support, great system library and plugin support, one of the fastest and nicest implementations I have ever played with. The problem?  It is commercial, the license, royalties and access to the low-level VM source code and internals (or lack thereof) make this a non-starter.

So what Smalltalk implementation did I decide to go with? One I have not mentioned up until now: Pharo. Pharo is a fork of Squeak. It is intended to be an enhancement of Squeak with implementation decisions focusing on agile software engineering practices. It currently uses the same enhanced Cog VM designed for Squeak, but feels like a much more professional system without all the Etoys GUI and design philosophy. These changes are based on differences in the image and source files between a Squeak image and a Pharo image. My understanding is that you can currently take a modern Squeak OR Pharo VM, and the only differentiating factor is what image snapshot is loaded. Down the road as Pharo evolves this backward's compatibility with Squeak may go away.

So what is "Big Speech" anyway?

So "Big Speech" is a play on Smalltalk. I envision a 64-bit operating system built on a microkernel or exokernel with virtual machine support. In some ways this will probably be similar in design to the GNU Hurd with the kernel being much closer to a hyper-visor than a standard OS kernel. The primary IPC mechanism I plan on using will be a modified version of the Smalltalk message protocol. Standard OS processes and services will probably run in separate virtual machines with a Smalltalk based interpreter. I would like the OS to support Hot Updates where core pieces of both the kernel and OS services can be updated and debugged in place, similar to what is found when working in a Smalltalk image. Why should my system require a reboot after an update, when new code should be able to replace existing code with a remapping of the data and code pointers, or service providers?  Sure the update mechanism and new code may be required to provide a translation stage before the OS continues on its way but that has to be better than a full hardware reset and reboot cycle.

Although there are parts of the Smalltalk language syntax that I do not currently like, initially I will be using Smalltalk as a basis for my future system. I hope to evolve the language to improve functionality, capability and readability; although that might just be my technical experience with the "C"-like family of languages talking. I have always loved the concepts and power behind Smalltalk, I just never got to use it professionally in a way that caused me to become fluent enough with its syntax and API. Down the line I imagine being able to work with other languages that compile to my Smalltalkish VM/OS message and byte-code system, opening the door to working with other languages for modifying the system.

In many ways this OS will start out like the original Smalltalk systems developed at Xerox Parc. The original systems were nothing more than some low-level assembly to provide machine IO access,  CPU primitives, and an interpreter that loaded and ran the Smalltalk system. I plan on creating a very similar system on modern hardware with a low-level system to maintain ring-0 and resource sharing, with OS system services implemented in a Smalltalk like interpretive environment.

In my next post I plan on talking about my Smalltalk implementation choice, but for now my Smalltalk skills are rusty, so it is time for me to go and play with some tutorials.

The Adventure Begins.

Today the long awaited journey finally begins. For more than the past decade I have had ideas percolating in the back of my head. I have no foreknowledge of which, if any, of these ideas will bear fruit. In reality this is a journey I have been looking forward to starting for a long time. There is a significant chance that I will never reach the end; for I have set about to realize a dream that is so large and complex that I may not live long enough to see it fully implemented. That is OK, for it will be an adventure, a learning experience, and I hope I will have fun along the way.

Many of my friends and colleagues seem to think highly of my skills and abilities, as if I was a master at my trade. I am not. I am but a journeyman, however the adventure to complete my masterwork begins now. I suspect that much of the research, sub-projects and work I have set for my self would qualify for use in a masters thesis. I imagine that the culmination of this project would undoubtedly serve as a basis for work on a doctoral dissertation.

I have often thought, and even dreamed, of going back to obtain a master's degree, or even a PhD. At this time I do not feel that I have the money or time to devote to obtaining such a degree. The desire, no need, to work on this project has burdened my thoughts for the past several weeks. Although I may be unable to afford post-graduate studies at a university at this time, that should not stop me from perusing my first love. The minimum amount of research and self-education to start understanding all the parts needed for my project would be similar to Stanford's Systems specialization for Master students. In fact looking at the sample class 240. Topics in Operating Systems and previous syllabuses gives me some good starting points for whitepapers on things I will need to consider.

So today I start on my quest to bring about 'Big Speech', although it should be noted that I have been toying with these ideas for a long time, and have spent much time in the past few weeks with additional preliminary research. I may not create anything truly "new", although I do expect to combine some of what I consider the best existing ideas into a novel form that I hope others may find interesting or useful.

What I start now could not be done without the giants that have come before me. Such names as Alan Turing, Brian Kernighan, Ken Thompson, Dennis Ritchie, Alan Kay, Adele Goldberg, Dan Ingalls, James Gosling, and Linus Torvalds. Although I will never match their stature, they have inspired me, and provided the tools and knowledge I will build on.