Wave Fronts

Nothing

On looking into an empty bottle in highschool English Composition

Posted at 12:07AM Jun 23, 2006 by microwaves in Art  |  Comments[0]

Java Portability

Solaris(IBM AIX/Linux)-specific interruptible I/O is a case in point about Java portability headaches.

One source of great tension with Java programming is between the desire to use it as a general tool and the desire for it to be a truly portable platform. This is demonstrated sharply with high performance and specialized settings in which "interruptible I/O" is deemed useful, while practical issues prevent this feature being provided for Java Standard Edition (Java SE) in all operating environments. For instance this program below does nothing visible on Solaris, but prints "hello" with Sun Java SE on Linux and Windows:

public class Foo {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        System.out.println("hello");
    }
}

First impressions of this program's behavior on Solaris roughly translate to "The hell you say!" followed by "Java is broken on Solaris!" There are a number of "symptoms" of interruptible I/O that catch users off guard and in a few cases one is led to wonder if it might be best to do without this feature whose flip side is that it allows "breaking out" of I/O operations that folks really want to be able to escape from. One could argue that the semantics are just funky and I admit to not knowing where they are written down. In fact I'd love to hear of any other versions of Java SE that support interruptible I/O. IBM Linux Java SE prior to their version 5 does support interruptibility similar to that of Sun Java SE, but it isn't clear if this "feature" extends across many other implementations. In any case, I think this is an appropriate test case for a discussion of portability.

I like to present things backwards sometimes, so let me start with the last thing on my mind, which is to wonder what could be done to "fix" interruptible I/O? That is, what could be done to make this feature less surprising or problematic?

An obvious solution would be to yank this feature where it is OE or vendor-specific and this proposal is a Sun change request. More on this later. But the key issues for this solution are the questions of who is dependent on this nonportable interruptible I/O and what they have as an alternative. The answers seem to be "almost nobody" and "java.nio" respecitively.

But more basic than this, of course, is Sun's pledge to maintain backward compatibilty "no matter what." But are some problems painful enough that they should be exceptions to this rule? The fact that Java SE on Solaris (and pre-5.0 SE on IBM AIX, Linux, etc) have such different behavior poses a terrible problem for unsuspecting developers. But even if this "acute pain" is beyond reasonable, can we leave users in the lurch? I think not, or at least not in any kind of short timeframe.

More on this later.
2

Posted at 10:42PM Jun 22, 2006 by microwaves in Java  |  Comments[0]

Black Thursday for Engineering?

Hoping I'm wrong

  (found on the 'Net while searching for the
    real psalm. Adapted slightly.)

  ***********
  Psalm 6.111
  ***********

  The FlipFlop is my Synchronizer, I shall
   not want.
  He maketh me pipeline my whole circuit,
  He leads me to program more EPROMs,
  He restores my sanity.

  He guides me in paths of synchronicity
   for his clock's sake.
  And lo, though I walk through the valley
   of the shadow of CMOS,
  I will fear no intermediate voltages,
   for He is gated,
  His one or His zero,
   they comfort me.

  He prepares a haven for me
   in the presence of metastability,
  He annoints my design with blocks,
   my logic shall rationalize.
  Surely good reviews and no recalls will
   follow me all the days of this fiscal
   year, and I will create the right buzz
   forever.

----

Wishing all of you safe passage,
dear friends at Sun.

Posted at 12:00AM Jun 22, 2006 by microwaves in General  |  Comments[0]

Intelligent Multiboot Support for Windows, Linux and Unix

Multiboot selection should be possible with a single command line or GUI, trivial to accomplish locally or remotely, and generally available.

There ought to be a way to trivially utter to my computer:
Reboot with a boot menu choice like "3:5" where "3" means "first menu choice three" and "5" means "first menu choice three's fifth menu choice."

Why? I'm sitting here in the living room with a Powerbook, and my Sun Ultra-20 is sitting nine feet below me running Solaris 10. Should I have to get up, hike to the basement, do an init 6, and step through the above choices manually just so I can run a command that is only available to me through another operating environment choice?

Surely the keepers of Grub and its Windows multiboot equivalent can agree to about three bits of shared state to support this feature? Guys: how about lunch in Portland for a nice chat and agreement that a command like "init -- 3:5 6" will just do the right thing? Of course a remote desktop would need an icon/dialog set that you click a few times (no keyboarding, please). Do this and the world will thank you. And you can spend the lunch just getting to know each other!

This would serve well until virtualization becomes so easy and available that something like the following can be uttered:
as

for example:

javac | `as ddeal/FC4 tac` | less

Posted at 03:47AM Jun 18, 2006 by microwaves in Operating Environments  |  Comments[0]

Belated OpenSolaris Birthday Celebration

OpenSolaris is the next OE on my list to learn about.

I couldn't make Mozilla speak IRC at the office and couldn't take the time to go find something that worked. So I missed the celebration of the first birthday of OpenSolaris. Here's a progression cum evolutionary tribute.

This is an incomplete and not quite correctly ordered list of the operating environments I've spent a reasonable amount of time using or that I had a hand in writing:
Univac Exec VIII
Univac APL
Unnamed OE (I wrote this on the bare metal of a Data General Nova 1200 while we [Univ. of Alabama Huntsville Isolation Lab] were waiting for our Nova 2+software order to be filled. It used a decent quality 300 baud cassette tape drive of some sort and a very nice 300 baud thermal paper terminal)
Data General RTOS
Data General RDOS
Data General timeshare doc system
Data General AOS
Data General Easy (DG too stupid to ship this)
Texas Instruments DX10
Business Application Systems BASPort
(Wrote part of one VM, one native assembler, one native linker, a native debugger, and various other bits and pieces long forgotten. Other members of the BASPort team included Steve Goldman, Bob Leivian, Don Parce, George Franzen, and my name memory just collapsed. Forest Earl Gilmore managed us [RIP, dear friend].)
SWTP 6800 MIKBUG
SWTP 6809 UNIFLEX (+ Bob Uiterwyk's Basic: Bill's Altair Basic blew chunks)
MSDOS
DRDOS
Unnamed OEs inside Network Products BabyMux, BabyNet and Commponent products (I wrote these with Steve Schleimer and others)
Version 7
System III
Opus Unix
BSD
SVR4
Mach
Linux
Solaris

And now, at long last, OpenSolaris is well and truly in the world. Some times you have to be patient before you end up with something really, really good designed for the long haul. I'm looking forward to running OpenSolaris on an Ultra-20 in my basement as soon as I can. But the download's going to have to get easier.

So:
Happy birthday to you,
Happy birthday to you,
Happy birthday OpenSolaris,
Happy birthday to you,
And many morrrrrrrrrrrre!
21

Posted at 11:04PM Jun 15, 2006 by microwaves in Operating Environments  |  Comments[1]