Summary
SqueakNOS is an old idea that has gotten the kiss of life again. You want fast, simple, and OO? Check it out.
Advertisement
Years ago, the SqueakNOS - Squeak No Operating System - was started. Squeak, as you may know, is a Smalltalk system built by the godfather of OO and his consorts - Alan Kay and his friends from Xerox PARC that invented the computer as we know it, including the most prevalent programming model, Object Orientation.
SqueakNOS was an attempt to remove the OS underneath Squeak. First and foremost, I think, just because it was possible and cool - but also because having a system that really doesn't have an OS, just objects all the way down, sounds like an extremely interesting proposition.
If you don't agree with me - I'm typing this on a laptop that has a dual core processor, a SATA-300 disk, and 4 gigs of memory. So why, please tell me, is it slow and is the cursor changing into an hour glass all the time? Your answer could be "because you run Windows XP", but I don't feel that the major alternative, Linux, has that much more to offer. Apart from a much worse user experience if you like to dock and undock your laptop all the time, switching between two external monitors and the internal one. But I'm digressing - this is not about OS wars, this is about No OS...
SqueakNOS got a new boost last May, and the current version (distributed as a VMware image) really is something: it boots in a couple of seconds, has networking support, a fully loaded Squeak image, and all that with 99.9% Smalltalk and - according to the developers - just some 1400 lines of C code and 60 lines of assembly powering it all.
Think about it - you like OO development, you love the interactivity of Smalltalk (if you don't know it, what are you doing reading this post? Go off - learn it! It's worth it), and now, all of a sudden, you can write device drivers in that language. You can write an end user app that has direct access to the TCP stack (or, for that matter, to the network card). You decide where you want to tread, not the OS...
Bad idea? I don't think so. OSes have become more and more bloated over time. Take the KLOC of the Linux kernel over time as a case in point (the source used to fit on a floppy drive...). Part of the increase is due to better hardware support, but a large amount is just management stuff - bean counting, interfering with what you really want to do, limiting your options because otherwise you could do a lot of harm (or good), and in the meantime eating most of the budget. Just like real-world management, in essence.
What if your computer was a single object system all the way down, where you - the software developer - could decide what to interface with and what not? No management, all the CPU power for *you*, and if you don't like the TCP implementation, fire up the refactoring browser and change it while the system is running.
I hope that thought is intruiging to you - if so, run to the SqueakNOS download site and grab the VMware image. I promise you, you'll have fun!.
You don't really have no OS, but rather have merged one into the lower levels of the language environment. As with any new OS, the big problem are handy devices (Wifi, webcams, printers, accelerated graphics, etc) for which you don't have drivers. If you are running in a VM then you are cheating by piggy backing on some of the device support provided by the host OS.
As a developer, I don't want direct access to the TCP stack. I don't want to decide where I want to tread.
Quite frankly, its a PITA. It might be fun for the first app, but once I write a second app that starts treading on the first app's toes, I have a serious problem.
One man's bloat is another man's previously solved problem.
If you don't want to mess around with the TCP stack, don't. The fact that you can does not imply you must.
Personally, I always disliked pre-emptive, multi-ringed systems. They take liberty away and usually do that with the argument that only a subset of developers could handle the liberty. The price you pay for it is a major performance hit because you are forced to work with certain abstractions, make expensive system calls (because you need to jump from user to kernel mode and back), and have a pre-emptive multitasking engine forced down your throat.
It's a matter of taste, but I'd fancy working with a system that lacks all of the above. Because I think it'll be small, elegant and understandable and responsible developers will use it to keep it that way.
Furthermore, Scott, you are implying that current mainstream systems have solved problems. I tend to disagree - current mainstream systems are ugly, overly complex, and like large bureacracies mainly exist to support themselves. Superficially, it may look like they have solved some problems, but there are indications that they haven't. Read for example the paper The Problem With Threads (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) on the currently prevalent programming models or The Confused Deputy (http://www.cap-lore.com/CapTheory/ConfusedDeputy.html) on the currently prevalent security model.
As long as languages and operating systems put most developers into the straightjacket of these "solved problems", I fear we'll never find a way out. So that's why I'm quite excited to see a system being developed that promises to take away these shackles, and anxious to see what comes out of it.
So, by definition, we have to completely ignore application isolation? Doesn't that effectively ignore decades of OS research and put us back in the historic days computing? For example, MSDOS would allow you to modify the machine instructions for a TCP stack but that doesn't mean I would like to go back to using DOS because of it's "flexibility".
It also implies, from a practical perspective, of running one application per server, at least if you want any sort of reliability or maintainability. Didn't Microsoft hoist a similar practice upon us a few years ago, but in that case out of incompetence rather than design? Hence, it could only be useful in a server environment as a VM. Doing so merely pushes the resource and application management to the VM host and out of the No OS's control. You are basically back to square one and relying on the hosts real operating system and prioritisation algorithms. The other potential utility area for a No OS is in embedded systems. Not too many embedded programmers put Smalltalk on their systems (I can only think of one by HP) but maybe Squawk will have some uptake.
My conclusion is that this is cute, interesting, even fun, but practically useless. It will have the same market share as Wirth's Modula-3 or Oberon systems.
> So, by definition, we have to completely ignore > application isolation?
Not necessarily. Environments like a Java VM can run multiple isolated applications within a single VM/process. The simplest example of this is running untrusted applets.
I'm sorry but being able to run more than one application at a time does not suddenly and magically provide application isolation! Of course JVMs can handle multiple apps, and JEE is another fine example of that. However, proof is in the pudding. I refer you to Squawks "Isolates" where to provide application isolation, they make the shared portions of Java immutable. If immutability is the only way to prevent apps from unfairly hogging resources, then the flexibility discussed in the article is only achievable in toy environments or by delegating to some other resource manager outside of the mutable components, such as the VM host I mentioned earlier.
> only way to prevent apps from unfairly hogging resources, Many full scale operating systems are only partially successful in achieving that. I don't think immutability is the only way to manage isolation within a VM; its use in Squawk may be related to the rather cramped environment of a typical squawk system. Any technique that works for a traditional OS should also work within a VM running on bare metal. The only real difference is that, within a VM, application address spaces are isolated logically rather than via memory management hardware.
Smalltalk-80 was the first system to have a mouse, windows, icons, etc. All the graphics was quite costly and the guys at Xerox Parc built a special machine powerful enough for the graphics in Smalltalk-80 to be reasonable fast which was the Dorado Workstation. For that newly built machine Smalltalk also had to do the device IO (mouse, keyboard, screen, etc.). Remember that MS-DOS was originally released in 1981. As I understand it the point in SqueakNOS is a reminiscent revival of a historic artefact just for the fun of it. It does not need to make sense for everybody. But it's a good starting point to let history pass by the way it would have if not Steve Jobs had dropped by, seen all the cool windows and icons and then starting to develop the Mac. Because then Smalltalk would rule the graphics workstations all over the world the way it should have happened. If you can't follow, you aren't a true Smalltalker ;-).
Previous Topic
