Older blog entries for dfenwick (starting at number 5)

We bought a pile of HP T5515 thin clients at our lab. The box itself is pretty cool, sporting a caruso processor, 128MB of RAM, 128MB of flash RAM, and other sundries. It comes with a thin client Linux build that HP produces for it that has Xfce as the desktop environment.

Unfortunately they omitted Xnest from the build and they force all rdesktop sessions into full screen mode, which drives me bananas. So I went out to the HP site to see what I had to do to create a new build environment for the box. It told me to go visit Metrowerks to get the build environment for the thin client. Mind you, we paid $450 for these boxes in an effort to save money. Metrowerks wants $7000 just for the build environment. That's more than all of the clients we purchased cost us. Just for the build environment. Argh.

So I started looking for options. The thin client world in Linux is all over the place. LTSP has a decent build, but it's somewhat server-centric. I'd like to put the build on the 128MB flash RAM (that acts as an IDE drive within the kernel.) I installed a distribution then hacked it apart and moved it to my Solaris server, along with the PXELinux environment and got a client booting into LTSP. Then I looked at the build. It doesn't have Xnest either. Argh.

I looked at a few other distributions (PXES, ThinStation, etc.) and none of them provide what I'm really looking for in a thin client distribution.

So I've started the process of building my own distribution based on the LTSP distribution. More appropriately, I'm going to submit some modules to the LTSP distribution to make it more like what I'm looking for in a thin client build.

I've basically been running "thin" client architectures for years, but back in the day we called them X terminals. I must say, though, that with the open source projects that are out there, the universal thin client architecture is finally becoming a reality. It's really nice being able to run X, RDP, Citrix, or even standard terminal sessions on a single client with a very small build.

I've been thinking about emulators lately. Most of the machines that have a microprocessor or microcontroller operate similarly. I've been working out whether it would be feasible to write an emulator creator, with which you could describe components of the emulator, including all of the various hardware contained within it.

In basic terms, a CPU is really quite simple to describe. Take an instruction and do something with it. Most of them are linear, and even those CPUs that provide separate pipelines could probably be described.

This thought process came about because, as a former musician, I own a pile of synthesizers. One of them I own, A Roland W-30 music workstation, is basically a self-contained computer. It has an Intel 8098 (a variant of the Intel 8096) microcontroller on the system board. It also has a SCSI interface, floppy disk drive, and an LCD display. The workstation, which started production in 1989, went end of life by 1992 or so, and Roland discontinued building new operating system releases for it by 1994. Unfortunately there are features I've always wanted to have in the W-30, but never got around to doing anything about.

Another owner of a W-30 plucked out the EEPROMs from his W-30 and ripped all of the BIOS-level routines from them. I spent a month or two reverse engineering the entire operating system of the box to understand it, hoping I might be able to add the features I was looking for on it. After a while it became apparent that I'd probably have to write an emulator for it. That's when I stopped because I didn't have time to work on it.

This past week I started writing an emulator for it. It's not hard, it's just very time consuming. I've got many of the opcodes working and I have a plan of attack for building the emulators for the other components in the box. But while I've been looking at it, I've realized I could probably build a much more generalized emulator builder.

Anyway, I wonder if someone has already come up with something like this. If anyone knows of something like this, please post.

After reading the story about Alan Kay from yesterday's diary entry, I decided to give Squeak a try.

Some background: I worked for a company many years ago that built Smalltalk environments. Actually, I worked for that company twice. The first time I worked there, I wrote MacIntosh applications for one of our clients using a combination of MPW and Smalltalk. I left the company for about 5 years when there was a big lull in the business. During that time, my boss built a Smalltalk environment called Agents OS for the MacIntosh. That link will take you to his latest product, which is a system called SmallScript.

Anyway, about 5 years after I left, my old boss called and we got to talking about building a Windows version of AOS. I was newly married at the time and had just purchased a house. But I packed up my 4 computers, all my books, and some assorted other things like clothes into my 4-Runner, and drove to California with the intention to move there because I believed in what he was doing. Unfortunately, due to life-happenings, it didn't work out.

I haven't touched Smalltalk since then, which is a travesty because Smalltalk is probably the most elegant environment I've ever worked in. Squeak is a Smalltalk environment. The group they've assembled for Squeak is like an all-star list of players from the Smalltalk world: Dan Ingalls, Alan Kay, Ted Kaehler, John Maloney, and Scott Wallace.

I played with it all last night, and it took me back to my days of writing Smalltalk applications on the Xerox 6085 workstation when I worked in a small artificial intelligence lab in the late 1980s. It's a really nifty environment with the kernel built in none other than Smalltalk. It has all of the normal extensibility you'd find in a Smalltalk environment. Best of all, the Squeak Team wants to keep it "open" so people can extend it to their heart's desire.

Either you'll love Smalltalk or you'll hate it. Either way, it's what drove the object train.

I recently read an interview with Alan Kay at The Queue entitled: Big talk with the creator of Smalltalk--and much more and it was, yet again, one of the most informative interviews I've read in a long time. I once had the pleasure to have met and talked to Alan Kay many years ago. His grasp of what computer science "should" be is deeper than anyone I've ever met.

Of particular interest in the article, his comment about C++ was revealing:

"You have to be a different kind of person to love C++. It is a really interesting example of how a well-meant idea went wrong, because [C++ creator] Bjarne Stroustrup was not trying to do what he has been criticized for. His idea was that first, it might be useful if you did to C what Simula did to Algol, which is basically act as a preprocessor for a different kind of architectural template for programming. It was basically for super-good programmers who are supposed to subclass everything, including the storage allocator, before they did anything serious. The result, of course, was that most programmers did not subclass much. So the people I know who like C++ and have done good things in C++ have been serious iron-men who have basically taken it for what it is, which is a kind of macroprocessor." - Alan Kay - 2005

That's probably the most accurate depiction of C++ I've ever read.


Ahkh: Speed doesn't really bother me that much. What bothers me more than anything is the underlying responsiveness of X. Grabbing with the cursor is one of those things. If I grab a corner of a window to resize it, in MS Windows and on the MacIntosh, I'm greeted with an instant (< 1ms) response time on the interaction. In X on ALL of my platforms, many times I'll grab and EXPECT that 1ms responsiveness to often times I'm greeted with a rubber band selector for desktop icons. I usually have to click and wait a few milliseconds (3 - 5) before I am guaranteed my selection.

You do bring up a good point about overall application responsiveness though. It takes upwards of 10 seconds for FireFox to display on some of my machines. It doesn't even render a window for 10 seconds. It sits with the application launch icon in the environment. Sure, I can go do other things, but I'm not doing other things at that particular moment in time. This is yet another reason I don't think X will ever be embraced by the common desktop user. We're dead center in the instant gratification generation.

pbor: One of the biggest flaws I see a lot in open source GUI applications these days is this odd desire for developers to add features for no better reason than to add them. While some folks might appreciate having a file icon in a MRU dropdown, the sad fact is this leads to code bloat and it conveys very little information to the end user. Sure, the metaphor is there, but metaphors were really fun when there were only 50 desktop applications, but with 500 - 1000 desktop applications, the whole concept of trying to remember 500 - 1000 icons plus all of the metaphoric icons within those applications becomes unreasonable.

I'm glad you guys are making the effort to actually look at performance bottlenecks within GEdit, as it seems that many of the open source developers are not. Although I use GEdit rarely, I do use it.

Is it unreasonable for people to question the use of large, by desktop territory standards, toolbar? Do we really need Undo and Redo options in a toolbar? Do we really need ANY of those types of toolbars on a text editor?

As much as this sounds like blasphemy to the open source community, I don't like Linux as a desktop operating system. Now don't get me wrong - I love Linux as an operating system. It makes a really awesome server. Unfortunately, even though I've written many applications for X, I do not like X. I don't like it the same way my friends at Apple Computer Corporation 9 years ago didn't like Windows 95.

I remember a discussion I had with my buddy Scott Boyd back in 1996 about Windows 95. He said "It's the lack of a hardware cursor that just feels wrong." I argued that it really shouldn't make a difference. 9 years later, I know he was right.

It's the nit-pick things that bother me about X. It just doesn't feel "crisp." It always feels like I'm running in an emulator, and because of the way X works, it's really what I'm doing.

I've been silently waiting for a "good" replacement to usurp X as the desktop GUI of choice for a long time now. Unfortunately, trying to replace X with just about anything else these days is going to be very difficult. The momentum of the graphical operating environments that ride on top of X (KDE, GNOME to name a couple) is enormous, and having to either rewrite a lot of the code or figuring out how to build a compatibility layer would be a huge undertaking.

In the past 3 years, it's gotten better, but there's really only so much a developer writing software on top of of the libXt, libXm, or even libX can do. They're still at the mercy of how X performs, and it just doesn't feel right to me.

A little bit of my history in the free software environment.

I wrote my first free software back in 1981, as a 16-year-old. Back then I had a borrowed Apple ][ and after I figured out how it worked, I realized that there had to be easier ways to make efficient algorithms work. AppleBasic was highly inefficient, and I was writing a lot of routines in machine language to optimize my code. At that point, I realized it was ridiculous for me to continue to write in machine language, so I wrote an assembler in AppleBasic. I posted that on Compuserve, and it went completely unnoticed forever.

In 1987, I got into MIDI. Back then, MIDI was a brand new phenomenon. Most computer people had never heard of it and most musicians had no idea how to use it. I started exchanging code with others via bulletin boards. Back then, bulletin boards and modems were one of the few ways to transfer applications around. I wrote an interrupt service routine for Roland's MPU-401 (then the only MIDI capable interface for the IBM-PC) and shared it with others on the local Washington MIDI User's Group. I then added some SYSEX routines to it that allowed me to dump and restore patches from my Roland D-50 synthesizer. This later became part of my master plan to build a patch editor for the D-50, which never happened.

In 1991, as a member of the MINIX community on a variety of online resources (Compuserve, BitNET, etc.) we were having discussions on how to improve the MINIX kernel when Linus Torvalds posted the first of the LINUX kernels. I still have those kernels on 3.5" floppy disks. They are version 0.11 and 0.12.

Thus spawned a bunch of activity I had in the LINUX community. I helped the first of the distribution teams (in this case, the Yggdrasil folks) get their distribution debugged. I finally ended up purchasing the 1.0 version of Yggdrasil INCLUDING the binary Motif version they sold just so I could port a bunch of commercial Motif applications I'd written to the Linux platform.

In 1994, I bumped into Andrew Tridgell online and found he was writing software that would allow my SunOS machine to serve up files as if it were a Windows file share. This was exciting, since the company I worked for was running Windows for Workgroups on the PCs and connecting to the Sun servers via NFS (using Sun's PCNFS product.) I absolutely HATED the wedge that was required for PCNFS in Windows for Workgroups, so I figured out how Samba worked and got it loaded on all of our servers. This was the beginning of my Samba relationship.

In 1994 and 1995, I was very active in the Samba mailing lists as well as promoting Samba, as well as debugging code and submitted some patches to existing code. My forte was reverse engineering on the wire, though. During that time I reverse engineered much of the browser wire transactions, and started a development group that began writing the browser code. Before we even got off the ground, Andrew Tridgell basically finished the preliminary browser code, and clients connected to Samba all over the planet suddenly were joining workgroups and advertising their shares with Samba servers. During that year I also started the two Samba USENET News groups.

In 1996, lkcl was working on some new things for Samba and asked that I try out his additions on my private development servers. Eventually I was invited to the Samba development team. In 1997, I set up a site to allow Luke and Paul Ashton to share their debugging information for the NT Domain reverse engineering project. I was invited to the Samba development team in late 1996, more as a strong advocate than a developer. Over the last 8 years, I've silently been waiting for the right time to produce a reasonable Samba management GUI. It looks like Samba 4 is the right time to do such, and I've already started work on it.

I run a combination of operating systems at the house. I've got 5 or 6 Linux boxes, 3 or 4 Windows boxes, quite a bit of stuff running in VMWare on each of those boxes, I run Solaris 9 x86 in a VMWare session, and I run a variety of CD-BOOT environments for a variety of purposes.

I've been actively writing software since 1980. The majority of my work has been commercial work. I've had some of my source code released using a variety of useable copyrights (I rewrote a large part of SNACC - an ASN.1 compiler - to do DER instead of BER for a project, for example.)

It's been a fun ride.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!