Blah, etc. Blah

My time at Sun has come to an end along with a host of others in the great RIF of 2009.

Maybe I'll be back when Sun needs more people.

Hey look!  I've got an opinion on MySQL too!

As far as I can tell, this doesn't change anything except that Sun will begin to collect the support contract revenue.

I suspect that even if Sun did absolutely nothing to the code, this purchase would pay for itself eventually, but I'm confident that Sun/MySQL will not sit on their hands.  Which makes me think there's a lot more coming back from this.

So as MySQL gets better, more support contracts, more money.  I simply cannot see this as a bad thing.

Dropping a $billion might be a bit shocking, but it smacks of fantastic financial health to me.  They either have it in cash, or they have a plan good enough to convince a lender that it was a great idea.  Either way, it still means Sun has the means to spend the money to make money.

I was trying to post this in response to Ben Rockwood but all I got was "Spam is not appreciated" so I must have done something wrong at some point.

So there it is.  My opinion.  It's not deep, or well-reasoned.  But it's mine.

I was surfing about and found a Mac OS X software deal that seems too good to be true:

Here's my invitation for you to have a look.  Clicking this link will credit me for having invited you.  I'm just letting you know so that the hostile full-disclosure-police won't attack me:

    https://www.macheist.com/buy/invite/97623

Thanks. 

I wrote a script in attempt to help me learn a little bit about zfs.

Since I don't have an array with a lot of disks, this script uses the poor-man's technique of using files instead of disks.  It works the same way as disks would work.  We can think of it as using zfs in slow-motion. 

Please comment and modify the script to facilitate learning zfs.  Please let me know if it was helpful to you.

Here's the script: zpool-spare-demo

 

I was in the Boston area last week (Bedford/Burlington to be accurate) on the Middlesex Turnpike where I saw a car with a bumper sticker that read:

  More trees
  Less Bush

Which I understood as some form of Eco-Political statement about loving the environment and not preferring the current administration (or possibly the former Bush administration).  Whatever.

The funny thing was...  as we slowed down for this car to make a left turn, they flicked out a lit cigarette which made the bumper sticker all the more ironic.

No matter what the bumper sticker says, this person doesn't love the environment and no matter who's in office they would hate them because they have no respect for authority (such as the littering laws).

All hail the god of do whatever I want.  Membership is the cost of a bumper sticker.

If you love the environment, keep your butts to yourself and just by accident you might actually show some form of respect for the rest of us.

Update: The latest version is here.

I was reading some Sun blogs tonight and found the other Jonathan's blog which reminded me of a script I wrote a long time ago.  This script does basically the same thing, but has a nice mnemonic name and does a little input checking for my own sanity.  Also, I must confess to a little bit of cleanup in the code since I'll be laying it out here on the web.

I hope this is useful to you. 

#!/bin/ksh

########################################################################################
#
# Program : mntiso
#
# Purpose : Mount an ISO image so we don't need to burn a CD or DVD to view the content.
#
# Author  : Dale Sears
#
# Version : 0   (Initial Version)
#
# Notes   : I think this script could use a few more features.  Here are some ideas 
#           that I didn't bother to implement:
#
#           It's rather root-centric in the defaults...  There *are* other users, and
#           maybe they don't have root access to mkdir /iso
#
#           What if I wanted /iso/image1.iso AND /iso/image2.iso mounted at the same time
#           for diffs or some other purpose?  I could mount things like so:
#
#                ~/iso/image1.iso/
#                ~/iso/image2.iso/
#
#           Check for spaces in filename?  It could happen, and it would break
#           my lame script.
#
#           Use getopts:
#   
#             -f   Force the mount by unmounting what is mounted on MOUNTPOINT.
#             -h   Usage.
#             -?   Usage.
#             -m   Set the mount point different from the default.
#
#           I probably could have implemented a few of these instead of writing
#           all of this...
#
#######################################################################################


MOUNTPOINT=/iso

usage() {
        echo
        echo "Usage: "
        echo "       $0 /the/fully/qualified/path.iso"
        echo
}


######################################################################
# How many args?
######################################################################
if [ $# -ne 1 ]
then
        usage; exit 1
fi


######################################################################
# Check for leading / on the ISO arg (needed by lofiadm):
######################################################################
case "$1" in

        /* ) ISO="$1"
             break
             ;;

         * ) usage
             exit 1
             ;;
esac


######################################################################
# Remove possibly existing lofi device for the given ISO:
######################################################################
/usr/sbin/lofiadm -d "$ISO" 2> /dev/null


######################################################################
# Add lofi device for the ISO:
######################################################################
LOFIDEVICE=`/usr/sbin/lofiadm -a "$ISO" 2> /dev/null`

if [ -z "$LOFIDEVICE" ] 
then
        echo 
        echo 'Uh, oh... : No lofi Device.'
        echo 
        echo "Perhaps $ISO is already mounted?"
        echo 
        echo "To unmount and try again, use this:"
        echo 
        echo "   umount $MOUNTPOINT; $0 $ISO"
        echo 
        exit 2
fi


######################################################################
# Check for $MOUNTPOINT and create as needed:
######################################################################
if [ ! -d "$MOUNTPOINT" ]
then
        /bin/mkdir -m 555 "$MOUNTPOINT"
fi


######################################################################
# We've passed enough tests, let's try to mount the ISO and 'mount'
# will complain if $MOUNTPOINT is a file or is busy:
######################################################################
/sbin/mount -F hsfs -o ro $LOFIDEVICE $MOUNTPOINT

I was recently at a customer site trying to determine why a Sun Fire v880 server would not consistently establish a link with the network equipment on the other end of a 1-Gig fiber.

I tried to configure ce.conf to force the link to 1-Gig instead of allowing it to auto-negotiate.  It might be that I was too lame to understand the examples in the ce.conf man pages, or maybe the man pages need a little help there.

Anyway, I ended up modifying a custom init script which the customer had written to tweak the /dev/ce driver at boot time.  They had the right idea, which was to force the link to a certain speed, but the problem was that they had multiple instances of this 1-Gig fiber card.  Our customer had mistakenly thought that if they did the following commands, they would operate on *all* instances of the /dev/ce type:

    ndd -set /dev/ce adv_autoneg_cap 0
    ndd -set /dev/ce adv_1000fdx_cap 1

This situation seems perfectly reasonable to me since the interface names are 'ce0' and 'ce1' and we wanted to modify all of the interfaces, so we operate on /dev/ce driver with ndd and "It should just work!"  But things are not always so intuitive in UNIX.  I think this is what might be called a "modal interface with no visual feedback" and it defies all forms of intuition.  It's my opinion that when using ndd to operate on any driver and there exists more than one instance, ndd should emit a message to STDERR with a warning that multiple instances exist and it should also inform the user about which instance will receive the given changes.  Of course, ndd should have an option to make it suppress said messages...

OK, where was I...  Oh yeah, for a while, I also thought like the customer that using ndd on /dev/ce would operate on all of the ce* interfaces until it hit me like a brick that I needed to add a little tweak to their init script to make ndd operate on each instance like so:

    ndd -set /dev/ce instance 0          <---- added
    
    ndd -set /dev/ce adv_autoneg_cap 0   <---- original
    ndd -set /dev/ce adv_1000fdx_cap 1   <---- original
    
    ndd -set /dev/ce instance 1          <---- added
    ndd -set /dev/ce adv_autoneg_cap 0   <---- added
    ndd -set /dev/ce adv_1000fdx_cap 1   <---- added

They were so close!

It's easy to understand once you see the solution, but we needed to set the 'instance' parameter of the /dev/ce driver to "point to" a certain instance of the driver and then make the necessary changes.  So, ndd will only operate on the default instance (instance 0) without explicitly setting the 'instance' parameter.

I hope that was interesting and helpful enough to keep you from falling into the same little trap.

Think of a nice Sun server and all of it's massive horsepower as available to every user (almost) 

The Solaris operating system is simply fantastic at sharing resources, so it can seem at times that everyone has a server with a lot of muscle under their desk.  In my experience, it's not probable that everyone else on the system will be doing something at the same time as myself.  So, I really do feel like I have the server all to myself.

Now imagine that server having a multitude of video cards installed in it, and the video cables can stretch for hundeds or even thousands of miles with a display at the end.

That's a silly illustration, but that's the fundamental concept of the SunRay Server software, except there are not a bunch of video cards, in fact, the server may not have one.  All of those displays are virtual, and they're accessible through the network, using SunRay clients.

Now think of each SunRay client as a place to send one of those virtual displays.  The questions becomes; "Which display will get sent to which SunRay client?"

Enter the SmartCard...  Each user has one SmartCard assigned, and whichever SunRay client receives the user's card, that is where their virtual display will be sent.  Oh yeah!  This "sending of the display" is optimized in many ways, like compression and sending only the changed bits of the virtual display to the SunRay client display.  Also note that this virtual display is encrypted before it is sent to the SunRay client.

I happen to think this is the perfect manifestation of "The network is the computer" because I can go anywhere within Sun (and I have), insert my card and my display (or session) is sent to me over the network.  My session has been sent to El Segundo California, Broomfield Colorado and Boston Massachusetts.  That's coast-to-coast, friends!

Marco, I realize that my description of how this technology works may not meet the "detailed information" requirement of your post, but here are some resources that may prove to be useful:

http://www.sun.com/software/sunray/index.jsp
http://www.sun.com/software/sunray/faqs.jsp
http://www.sun.com/software/sunray/features.jsp
http://www.sun.com/software/sunray/techspecs.jsp
http://www.sun.com/software/sunray/success.jsp

I hope that My attempt to illustrate the basic concepts of the SunRay client architecture is helpful.

Can somebody tell me why the whole world has not tossed out the Winsmell architecture and replaced every desktop with a tasty new SunRay client?

It's like watching people suffer from a deadly illness while we hold out the cure with an open hand as they pass by.

They seem to rather die than take the medicine.  The software is available for the asking.  The only way we can make this medicine easier to take would be to deliver the DVD's unsolicited to each and every person in America, very much like AOL.

I DO NOT believe everyone trying to manage a bunch of PC's is stupid.  That would be too easy.

I DO believe we are not shouting loud enough for people to hear us and they simply do not know that we have the cure.  Even if I'm wrong, and managers are making well-informed decisions to avoid using SunRay clients in their enterprise, it must mean that we're doing something wrong.

So what is the hold up?  Why don't we see millions of PC's getting replaced with SunRay clients?

I'm pretty fond of this:

In my ~/.exrc file I have mapped "F" to format from the current
location to the end of the paragraph:

    $ cat .exrc
    :map F !}fmt -65

I'm pretty sure this is not an original thought.  I'll give
credit to the man page of fmt and probably "UNIX Power Tools" I
like it because it formats my plain old ASCII text to 65
columns.

I've been doing this for more than ten years, and when I get a
new account it's one of the first things I notice missing, so I
repair it right away.

It sounds trivial, I'm sure, but there it is...  one of my
quirks, wide open for the world to see.

I hope you're happy.  I am.