While the decision by the US Library of Congress to create exceptions to the Digital Millennium Copyright Act for unlocking cellphones and jailbreaking iPhones (among other things) in the USA are very welcome, the reaction has been just a touch too euphoric. Not by everyone, mind you. Dan Gilmore begins to explain why this isn't a solution, and Wendy Seltzer nudges close to the problem as well. But plenty of people think they've been granted more than they really have.

Background

What's happened? Well, the DMCA makes it an offence in the USA to circumvent technical copyright protections created by the manufacturer. The law was aimed at protecting digital restriction measures (DRM, other people may expand the term differently!) but through poor drafting also provided a welcome legal weapon for ink cartridge manufacturers, cellphone makers and a variety of other classes of technical business to lock their competitors out of the market.

Notably, it was probably an offence to unlock a cellphone or jailbreak an iPhone in the USA under the DMCA. In US law, the Library of Congress are able to define copyright uses that are exempted from DMCA cover, and after pressure from the Electronic Frontier Foundation (EFF) they have applied a three-year exception for several common acts including these and making DVD backups.

There are two big reasons I'm only vaguely impressed, and neither of them are down to the fact that I live in a different jurisdiction where the trend is opposite. One concerns market power and its potential abuse, the other concerns global trade. Both lead to a toxicity which is harmful to digital liberty in general.

Market Power

First, market power. This action only removes one weapon (admittedly a nasty one) from the arsenal that is available to Apple and other behemoth corporations to control the market in which they operate. Unlike printer manufacturers, they can no longer file suit against you under the DMCA when you want to operate outside the patterns they have deemed acceptable for their customers and partners. They should probably never have been able to - copyright already has plenty of exceptions concerning fair use and reverse engineering that should have been respected when the DMCA was created. But Apple won't have a problem enforcing their will without it. The contractual terms they are able to impose on both their partners and their customers do the trick perfectly well.

Yes, participation is optional, but to avoid getting burned you have to stay out of their kitchen completely. As a customer it's too late to discover your device is incompatible with something you want to do after you've invested in it for a few months, and as a partner it's too late to discover your business is too close to something Apple would rather control and own once you've submitted the app to the store. They can't have you thrown in jail so easily any more, but they can just as easily prevent you participating and impose sanctions if you fight back.. They will no doubt continue to do so as capriciously as they have already.

Having just got a great Android phone, I'm less gloomy about this than I was; Android is a powerful Foundation to Apple's Empire (as long as there's no Mule - check Wikipedia if you're behind on your Asimov). It's possible that the removal of the DMCA as a blunt instrument may be enough to balance the market forces and promote true competition, facilitated by open source.

Global Trade

Second, global trade. US legal norms for technology businesses for patents and copyrights may still be forming (for patents they are still "only" the result of case law), but that hasn't stopped the US Trade Representative (USTR) and US trade missions globally from treating them as if they were handed down on stone tablets. They have been using conformance with "US norms" as a trading card in their rough games of political poker with various world governments. You know the sort of thing. "Nice export industry you have there for your agricultural produce. It would be a shame if anything happened to it. You can make sure it doesn't if you legislate to prevent your citizens harming our noble media industries." Kipling wrote about it eloquently, but people are still paying the USTR-geld.

Which is probably the intent of the copyright- and patent-dependent companies sponsoring the action anonymously through their trade associations. If they can get foreign governments to make hard rules where they can only persuade their own governments to make soft rules, the battle is all but won for them. They can use "international harmonisation" as the justification to get the draconian rules reinstated. That seems to be the reason ACTA has been given so much endorsement by the USA, as well as why they have been so keen on veiling its proceedings in secrecy. It's not just USTR either - the equivalent functions in the European Commission seem to be working just as hard against their citizens' interests.

Muted Applause

My positive reaction to the decision by the Library of Congress is thus more out of a sense of gratitude toward the Electronic Frontier Foundation (EFF) and their excellent and insightful team than any long-term relief. It was largely their work that produced this advance and it will likely be their work that holds back the process I've outlined. No wonder the media industry puppets hate this sort of organisation. But no-one should believe for a moment that this development makes it OK to jailbreak your iPhone. Doing that is asking for trouble. Its masters have merely been pushed back a layer in their defences, and temporarily at that.

[Also posted to my ComputerWorldUK blog and to Opensource.com]

31 Jul 2010 1:42pm GMT

• Announcement - Illumos Project
  "A number of the community leaders from the OpenSolaris community have been working quietly together on a new effort called Illumos, and we're just about ready to fully disclose our work to, and invite the general participation of, the general public." (from the announcement on opensolaris-discuss)
• Brazilian Government Signs OpenJDK Manifesto
  Concerned about Oracle's approach to communities, the Brazilian Government has signed up to testing and using open source Java platforms (notably OpenJDK) instead of the proprietary one. (Linked page is in Portuguese - translation)

31 Jul 2010 1:39pm GMT

A rather large and interesting putback for SMF/FMA related technologies went into Open Solaris yesterday. It will be available in build 146.

PSARC/2009/617 Software Events Notification Parameters CLI
PSARC/2009/618 snmp-notify: SNMP Notification Daemon for Software Events
PSARC/2009/619 smtp-notify: Email Notification Daemon for Software Events
PSARC/2010/225 fmd for non-global Solaris zones
PSARC/2010/226 Solaris Instance UUID
PSARC/2010/227 nvlist_nvflag(3NVPAIR)
PSARC/2010/228 libfmevent additions
PSARC/2010/257 sysevent_evc_setpropnvl and sysevent_evc_getpropnvl
PSARC/2010/265 FMRI and FMA Event Stabilty, 'ireport' category 1 event class, and the 'sw' FMRI scheme
PSARC/2010/278 FMA/SMF integration: instance state transitions
PSARC/2010/279 Modelling panics within FMA
PSARC/2010/290 logadm.conf upgrade
6392476 fmdump needs to pretty-print
6393375 userland ereport/ireport event generation interfaces
6445732 Add email notification agent for FMA and software events
6804168 RFE: Allow an efficient means to monitor SMF services status changes
6866661 scf_values_destroy(3SCF) will segfault if is passed NULL
6884709 Add snmp notification agent for FMA and software events
6884712 Add private interface to tap into libfmd_msg macro expansion capabilities
6897919 fmd to run in a non-global zone
6897937 fmd use of non-private doors is not safe
6900081 add a UUID to Solaris kernel image for use in crashdump identification
6914884 model panic events as a defect diagnosis in FMA
6944862 fmd_case_open_uuid, fmd_case_uuisresolved, fmd_nvl_create_defect
6944866 log legacy sysevents in fmd
6944867 enumerate svc scheme in topo
6944868 software-diagnosis and software-response fmd modules
6944870 model SMF maintenance state as a defect diagnosis in FMA
6944876 savecore runs in foreground for systems with zfs root and dedicated dump
6965796 Implement notification parameters for SMF state transitions and FMA events
6968287 SUN-FM-MIB.mib needs to be updated to reflect Oracle information
6972331 logadm.conf upgrade PSARC/2010/290

31 Jul 2010 12:34pm GMT

Its that time of the year again. Happy SysAdmin Day everyone.

If today is dragging, might want to refresh your memory of the great OddTodd... always a pick-me-up.

30 Jul 2010 6:25pm GMT

30 Jul 2010 4:00pm GMT

• Apple Ships More Mobile Phones Than Motorola For The Second Quarter In A Row
  More a statement of Motorola's decline that Apple's advance, but still a significant sign of a market transition that I am sure will continue as "phone" becomes an app on a mobile device.
  (tags: Motorola Apple Phone mobile)
• Dell and HP to Certify and Resell all Three Oracle Operating Systems on their x86 Server Computers
  Clean and tidy announcement ties up all the loose ends Oracle created a few months back.
  (tags: Oracle Solaris Linux HP Dell)

30 Jul 2010 12:15pm GMT

I flew on a US-based airline recently. It was unavoidable. Anyway, it was cold in the cabin. Much colder than usual. In fact, had I coughed or sneezed I would have started a snow storm in there. Now, I'm generally ok with a bit of a chill, but this was way beyond what even I could stand. So, I looked around for some blankets and when I couldn't find any I simply asked a flight attendant. I thought it was a pretty common and easily fulfilled request. Guess not. I was greeted with this response: "Blankets are for our first class and business class customers only." I was third class so I didn't qualify and was obviously not worthy of a blanket. Blankets are reserved for the special people. Ok. But mere minutes later and right after the safety instructions a flight attendant grabbed the microphone and gleefully announced this to entire plane: "If there is anything we can do to make your flight more enjoyable, please don't hesitate to ask." I wondered why they didn't see the disconnect. I guess they haven't implemented the technology to segregate audio messages like they segregate people.

Filed under: Communications Tagged: Customer Service

30 Jul 2010 11:54am GMT

New announcement about Solaris support on non-Oracle servers:

• Oracle today announced Dell and HP will certify and resell Oracle Solaris, Oracle Enterprise Linux and Oracle VM on their respective x86 platforms.

29 Jul 2010 10:19pm GMT

Main link:

• The State of Open Source: Startup, Growth, Maturity or Decline?

  O'Grady has come to the same conclusion that I did at OSCON, namely that the "open source bubble" may be over - the period where it was assumed open source would be directly monetised - and it's time for a resurgence of the traditional approach of many parties with their core business elsewhere synchronising fragments of their interests with fragments of the interests of others. The announcement of OpenStack was iconic, but there were plenty of other signs once I'd started looking for them.

  There's naturally plenty of scope for variety, but I am certain that businesses whose leverage of open source extends only to the licence and not the community will find it increasingly hard to survive. Those whose revenue is derived from software must have models that at worst cope with and at best leverage the presence of many interests in the communities upon which they depend.

Other links:

• Oracle shuts down open source test servers
  Oracle shut down its three PostgreSQL build farm servers without warning…"If they had given us, say, three months warning, I'd have been less peeved," Dunstan told iTnews. "It can't have been costing them much - the thing pretty much runs itself, and they can't be short on hardware."

• Dell's fraud settlement explodes PC market myths
  "Intel's rebates amounted to 38 per cent of Dell's operating profit in the fiscal year 2006, and rose to 76 per cent (or $720m) in one quarter alone, Q1 2007. While almost all of the Intel funds were incorporated into Dell's component costs, Dell did not disclose the existence, much less the magnitude, of the Intel exclusivity payments." - Entirely jaw-dropping disclosure shows Dell was not the profitable behemoth it appeared. I wonder just how much of this Intel has done over the years?

• Cloud Privacy Heatmap
  "Do you know where your data is in the cloud?" Fascinating map to explore that summarises the privacy legislation in each country around the world.

29 Jul 2010 5:39pm GMT

DHCP, DHCP, DHCP everywhere!

Most everyone is used to using DHCP. It's used at coffee shops and wireless networks to acquaint traveling laptops with their DNS and router settings as well as, of course, to provide the machines an IP address too. However, corporate and enterprise use of DHCP is often reasonable too. One can use dynamic DNS updates to handle having a static reference for a machine traveling on various networks. When network migrations are necessary (i.e. say your Fortune 500 gets bought by another) and you need to move thousands of machines, it's much easier to simply tell your DHCP server to migrate the machines than have to log on to each and every machine and change network settings.

How does DHCP apply to the OpenSolaris Automated Installer?

The OpenSolaris Auto Installer uses DHCP to allow administrators to perform hands-off installations. The Auto Installer client (machine to be installed) receives its IP address, subnet mask, router, DNS server and boot image all though DHCP. The installadm(1M) tool which one uses to configure an Auto Installer server provides the commands for a Solaris DHCP server but below are the steps for an ISC DHCP server as is common on Linux and even Solaris shops which are simply more comfortable with ISC's DHCP implementation.

Where to get ISC DHCP for Solaris?

Software from ISC is usually very stable and well maintained to be easy to compile. However, Solaris seems to have changed a bit from the expectations of ISC DHCP. In my testing, on build 132, I found that ISC DHCP 4.0.0 from Sun Freeware, the ISC DHCP 4.1.0 from pkg.opensolaris.org/contrib and the ISC DHCP 4.1.1 off ISC's download page would all not respond to DHCPDISCOVER's on the wire (but it would report a DHCPOFFER in the logs still just to confuse things). I suspect a compilation issue I saw while compiling 4.1.1 (but I have no actual knowledge why responses are not getting on the wire):

ld: warning: symbol `MD5_version' has differing sizes:
        (file ../dst/libdst.a(md5_dgst.o) value=0x4; file /lib/libcrypto.so valu
e=0x76);
        ../dst/libdst.a(md5_dgst.o) definition taken

However, ISC's 4.2.0a1 worked flawlessly! You can get their 4.2.0 alpha from their download page and easily compile it with pfexec pkg install SUNWhea SUNWgcc; ./configure; make; make install.

Great, I have ISC DHCP compiled and installed, but how do I Configure this thing?

Normally the issue is not installation and compilation but configuration. For the OpenSolaris Auto Installer there are a number of things to think about:

• IP addresses
• Subnet mask
• Router address
• DNS server and search domain
• Boot server
• Boot file
• The Auto Installer client's architecture

Networking primitives (IP address, subnet, router, DNS)

Without some vital information, even fully functional networks seem useless. The use of an IP address, the subnet mask for the network and a router to get off the network all fit this bill. For most intents and purposes DNS is also in this same boat -- though some administrators may not find DNS as necessary. To get ISC DHCP to serve these pieces of information require certain directives.

A basic network

In one's dhcpd.conf a basic network is very easy to define, it looks like the following, here defining for the 192.168.0.0/24 network to serve out IP addresses between 2-100 and with a router of 192.168.0.1:

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.2 192.168.0.100;
  option routers 192.168.0.1;
}

DNS

To add DNS information to one's dhcpd.conf is similarly easy. If one wants each subnet served to get different DNS info one may put the lines in the subnet block or else the directives can go at the beginning of the file and apply to all subnets served:

option domain-name "example.com";
option domain-name-servers 192.168.0.1;

Boot server and boot file

Now, for the Auto Installer specific pieces: to boot a machine, one needs a machine to download a boot file from and the name of such a boot file. These pieces of information will be given by the installadm create-service [...] command when setting up a Auto Installer service. For example:

Boot server IP (BootSrvA) : 192.168.0.1
Boot file      (BootFile) : install_test_ai_x86
GRUB Menu      (GrubMenu) : menu.lst.install_test_ai_x86

The boot server in ISC DHCP terms is the next-sever directive and the boot file is the filename directive. To make it simple, just add these to your subnet group:

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.2 192.168.0.100;
  option routers 192.168.0.1;
  filename "install_test_ai_x86";
  next-server 192.168.0.1;
}

If you're using a SPARC Auto Installer service, you can use the same directives for the BootFile object. What about the GrubMenu entry you ask? Well, that's unnecessary and will be removed (see bug 7481) so do not worry about it; similarly, SPARC does not need a next-server (BootSvrA) directive.

What if you have both SPARC and X86 architectures?

If you have both SPARC and X86 machines in your Auto Installer environment then there are are some simple ways to define classes to provide your SPARC machines their correct boot-file and X86 machines their boot-file and boot-server. This allows one to have a default service for each architecture on the network.

A PXE boot class?

If you want a specific way to separate out your SPARC and X86 clients, then one uses ISC DHCP's class directive and applies all boot specific information there. To create a class for X86 hardware booting, then you can use the following class definition:

class "PXEBoot" {
  option dhcp-class-identifier "PXEClient";
  filename "install_test_ai_x86";
  next-server 192.168.0.1;
}

SPARC class

To define a class to match SPARC clients, one uses ISC DHCP's class directive and applies all boot specific information there. Note, you do not need a next-server directive for SPARC:

class "SPARC" {
  match if ( substring (option vendor-class-identifier, 0, 5) = "SUNW." ) and not
           ( option vendor-class-identifier = "SUNW.i86pc" );
  filename "http://192.168.0.1:5555/cgi-bin/wanboot-cgi";
}

Now, SPARC clients will request a lease and get SPARC specific information, while X86 clients will request and get information specific to an X86.

The entire dhcpd.conf looks like:

# option definitions common to all supported networks...
option domain-name "example.com";
option domain-name-servers 192.168.0.1;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is an easy way to discriminate on SPARC clients
class "SPARC" {
  match if ( substring (option vendor-class-identifier, 0, 5) = "SUNW." ) and not
           ( option vendor-class-identifier = "SUNW.i86pc" );
  filename "http://192.168.0.1:5555/cgi-bin/wanboot-cgi";
}

# This is a class to discriminate on PXE booting X86 clients
class "PXEBoot" {
  option dhcp-class-identifier "PXEClient";
  filename "install_test_ai_x86";
  next-server 192.168.0.1;
}
        
# This is a very basic subnet declaration
subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.2 192.168.0.100;
  option routers 192.168.0.1;
}

27 Jul 2010 8:06pm GMT

• EFF Wins New Legal Protections for Video Artists, Cell Phone Jailbreakers, and Unlockers
  Congratulations to the EFF on this victory for digital liberty. We mustn't over-state the victory, however. The DMCA is still an unnecessarily broad act that chills innovation and liberty for Americans and sets a norm that endangers digital liberty worldwide. Moreover, the acts they have caused to be decriminalised are still covered contractually by the ridiculous terms applied to customers. So the fight for digital liberty is far from over.
  (tags: DMCA EFF iPhone DRM Copyright Freedom ACTA)
• The Public Access Crusade of Carl Malamud
  Carl has personally catalysed more change than most organisations can manage collectively and I am sure is one of the heroes of the internet revolution.
  (tags: Internet Transparency gov2.0 Copyright freedom)

27 Jul 2010 5:17pm GMT

• How Will You Measure Your Life?
  Worthwhile reading for a Monday from Clayton Christensen.
  (tags: Business Management Philosophy Zeitgeist)
• Good-bye, Sun
  Bryan Cantrill says his farewells but rehosts his blog promisingly at dtrace.org and makes this great observation: "One of Sun's greatest strengths was that we technologists were never discouraged from interacting directly and candidly with our customers and users, and many of our most important innovations came from these relationships."
  (tags: Sun OpenSolaris DTrace)

26 Jul 2010 4:34pm GMT

I finally managed to get the SRSS 4.2 server software running on my setup. Note that SRSS 4.2 is the server version that is included with the Sun Ray 5.0 download.

First up I needed to install the software. It comes packaged as a zip file (srss_4.2_solaris.zip), extracting into srss_4.2.

It looks like if you want the web configuration interface you need to install tomcat from this distribution too. You can find this in srss_4.2/Supplemental/Apache_Tomcat/apache-tomcat-5.5.20.tar.gz. I installed it like this.

$ gzcat apache-tomcat-5.5.20.tar.gz | (cd /opt ; pfexec tar xf -)
$ cd /opt
$ ln -s apache-tomcat-5.5.20 apache-tomcat

You can then do the srss install, answering the questions asked (not included here as I forgot to record it). The symlink above means that you can sensibly accept the default location for Tomcat.

$ cd srss_4.2
$ pfexec ./utinstall

This is unfortunately not enough to get us going. When I went to run /opt/SUNWut/sbin/utadm -L it immediately complained about not being able to find the DHCP server stuff. I have no interest whatsoever in installing the DHCP stuff. After some poking around I found that all I really needed to do was to edit /etc/opt/SUNWut/auth.props and make the setting

allowLANConnections = true

But that's not all, …

I was still getting the 26B on the Sun Ray DTU on attempting to utswitch to the new machine.

This error code apparently means "Waiting for X". Fortunately there was a wonderful wiki entry on getting SRSS 4.1 working with OpenSolaris 2009.06. I'll re-document it as there were some things that I did not need to do (as they had been addressed in SRSS 4.2) and others which I thought less than clear.

You need the motif libraries. Sorry, no way around it, it's linked against them. Fortunately they are available in the opensolaris.org repository.

$ pfexec pkg install SUNWmfrun SUNWtltk SUNWdtbas

I saw the following error in /var/log/gdb/:11.log (11 being the session number it allocated me).

ld.so.1: Xnewt: fatal: libXfont.so.1: open failed: No such file or directory

Ahhh this was because some libraries moved. To fix it you need to do the following

# cd /usr/lib
# ln -s xorg/libXfont.so .
# ln -s xorg/libXfont.so.1 .
# ln -s xorg/libfontenc.so .
# ln -s xorg/libfontenc.so.1 .
# cd sparcv9
# ln -s ../xorg/sparcv9/libXfont.so .
# ln -s ../xorg/sparcv9/libXfont.so.1 .
# ln -s ../xorg/sparcv9/libfontenc.so .
# ln -s ../xorg/sparcv9/libfontenc.so.1 .

I also created /etc/opt/SUNWut/X11/fontpath with the following contents

/usr/share/fonts/X11/100dpi
/usr/share/fonts/X11/100dpi-ISO8859-1
/usr/share/fonts/X11/100dpi-ISO8859-15
/usr/share/fonts/X11/75dpi
/usr/share/fonts/X11/75dpi-ISO8859-1
/usr/share/fonts/X11/75dpi-ISO8859-15
/usr/share/fonts/X11/encodings
/usr/share/fonts/X11/isas
/usr/share/fonts/X11/misc
/usr/share/fonts/X11/misc-ISO8859-1
/usr/share/fonts/X11/misc-ISO8859-15
/usr/share/fonts/X11/Type1

Finally I had to edit /opt/SUNWut/lib/xmgr/gdm/remove-dpy since gdmdynamic arguments appear to have changed. Replacing

gdmglue="; gdmdynamic -b -d "'$UT_DPY'

with

gdmglue="; gdmdynamic -d "'$UT_DPY'

Just to make sure everything had "taken", I rebooted the box.

It looks like this did the trick. I am able to /opt/SUNWut/bin/utswitch -h sb2000-b and login correctly and actually get a usable desktop.

As I've done a bit of work on vesvi since I synced the filesystems onto sb2000-b I'll need to sync those over again before I start trying to use this as my desktop for a bit before physically moving the disk over to vesvi (and all of the associated network reconfiguration and probably creating another certificate for imapd).

I can see the light at the end of the tunnel and it is not an oncoming train.

It should go without saying (but I'll say it anyway). Getting Sun Ray running like this OpenSolaris completely voids any warranty and support. Don't do it if you don't know what you are doing.

26 Jul 2010 8:47am GMT

Phoronix published a sensationalist article last week claiming that my regular e-mail updates of our biweekly builds somehow signified some out of the ordinary newsworthy event, without bothering to do even the most basic of fact checking. While I pointed this out in their forums within hours of publication, I'm still seeing it cited by other web magazines that don't bother to fact check, as well as in various e-mails and blogs, so am publishing a more complete explanation here of why it really is a non-event.

The article claimed:

As the first email of its kind in months, Alan Coopersmith who is a known X.Org contributor and longtime Sun Microsystems employee now working for Oracle, has written a new email entitled "IPS distro-import changes needed for X packages for nv_145." Alan immediately began this public email by saying, "Just when you thought you'd never see another one of these biweekly mails..."

Sadly, all they needed to do to disprove the claim that it was the "first of its kind in months" was simply follow the links from the e-mail archive page they linked to, to see that I had sent a similar message two weeks earlier for the previous biweekly build nv_144. In fact, if they checked the archives for previous months, they would have found that, except for missing build 143 (a mistake on my part), I've sent these approximately every two weeks for every biweekly build for a very long time.

Perhaps I'd confused the article's author with the offhand comment he seems to have misinterpreted, but explaining that requires a bit of background explaining what these e-mails are and why I send them in the first place.

As many OpenSolaris users know, over the course of the last couple of years, we've been transitioning from the old SVR4 package system used in Solaris 2.0 through Solaris 10 to the new Image Packaging System (also sometimes known as "IPS" or "pkg(5)") being developed by a team of Solaris engineers and community members. Initially, we maintained two parallel distros, Solaris Express: Community Edition (SXCE), which was built using the SVR4 packages and the old Solaris installer that worked with them, and OpenSolaris (originally codenamed "Project Indiana"), which was built using the IPS packages and the new Caiman install software designed to work with them. The teams providing the package contents continued to deliver SVR4 packages, and the OpenSolaris distro team converted those to IPS.

One of the goals of the OpenSolaris distro was to provide a set of ISO install images and package repository that was completely, freely redistributable, so that it could be easily mirrored, copied, and downloaded without having to deal with the various encumbrances required by some of the third-party licenses in the traditional Solaris and SXCE packages. Unfortunately, at that time, we had not yet finished separating the encumbered code from the open source code in our X packages so that they could be included, since when Sun made its proprietary fork of X11R6 in the early 90's, the engineers never figured we'd be open sourcing Solaris a decade later and need to easily separate out the encumbered bits they were merging into the main code base.

The initial Developer Preview releases of the OpenSolaris distro thus included a set of X packages that Moinak Ghosh built from the Fully Open X (FOX) project work we'd done to rebuild our source trees from the ground up using the open source code from the X11R7 modular releases in order to ensure everything was either open source or cleanly separated out. Over the first few months, we migrated from those to the packages our team delivered to the OS as we integrated the FOX project work into our main source tree. Because these changes weren't always obvious to the external observer, I started sending notes for each biweekly build to let the team maintaining the SVR4 to IPS conversion tables know which parts of our packages they could now include, as well as any other changes they needed to know about, such as version number changes. (Our SVR4 X packages all used the same version number, a holdover from the monolithic X source days, but we've migrated to using the upstream version numbers as much as possible in the new X IPS packages.) I did this not only to try to help the distro building team, but also to help myself keep on top of the changes they made in converting our packages, so that we could understand issues users hit and know how to help them, and to learn better what we'd need to do when it came time for us to start building the IPS packages ourselves.

Last year, Sun announced that the time had finally come to start converting the builds to generate IPS packages directly, taking the next step in transitioning off SVR4 and ending the production of the SXCE distro, since the SVR4 packages used to build it would no longer be made. The ON consolidation went first, converting the packages containing the kernel, drivers and core utilities in build snv_136. The Install consolidation went next, in build snv_143, and X followed in build snv_144.

So, when I wrote "Just when you thought you'd never see another one of these biweekly mails...", I simply meant that after build 144, all the X packages are already delivered in IPS format, so there are no SVR4 to IPS conversion files to update for them any more, so I won't need to send those - except in cases like we had in 145, where I relocated one of the files that was listed as a dependency in one of the other packages still being converted by the distro builders, so they needed to update the dependency statement for it to list the new path to the file.

Despite what Phoronix seems to have assumed, I was not in any way referring to the limbo state the OpenSolaris distro is currently in (and unfortunately, as much as I'd like to explain that, I can't), nor stating anything about build 145 that is fundamentally different than the previous builds. It should come as no surprise to anyone that while build 134 was the last build to be publicly released, we have continued work on the Nevada builds after that - after all as we've said since 2005, Nevada is the code name for the development branch in which we're working towards the next full release of Solaris (i.e. not another Solaris 10 update release, but the one we may someday call Solaris 11) - while that's been released under various forms, as the OpenSolaris open source code, or via the binary releases of the original Solaris Express, Solaris Express: Community Edition, Solaris Express: Developer Edition, or the OpenSolaris 2008.05, 2008.11, and 2009.06 distros, we've always kept driving towards the same goal, with biweekly builds assembled to test the current progress.

My mail is hardly the only externally visible sign of this - you can see changelogs for the major consolidations (ON, SFW, X, and Desktop/JDS) for build 144 (the last fully finished build, as 145 is just finishing pre-integration testing now, with a delivery deadline of Monday for packages to be included, and the distro build process starting after that. Of course, the sources are also available, and there's plenty of activity on the various commit notification and discussion mailing lists showing that we're continuing to work away on Nevada.

So unfortunately, Phoronix succeeded in making a mountain out of a molehill, confusing their readers and fellow webzine authors, but likely meeting their goal of driving more traffic to their site to generate page views for their ad revenue as people passed the link around twitter, IRC & email or linked to it from their blogs & articles. As others have pointed out, checking the facts or contacting the developers to find out the story is less juicy than it seems doesn't play well with that business model (and that's not just true for Phoronix - look at any number of the columnists for other web-based "trade publications" that generate traffic via controversial posts, and the more outraged the community gets over them and angrily passes them around to denounce, the better their numbers are - you can just imagine how many of their articles are designed to bait Groklaw or Slashdot readers).

26 Jul 2010 5:53am GMT

In Februrary 1996, I came out to Sun Microsystems to interview for a job knowing only two things: that I wanted to do operating systems kernel development -- and that I didn't particularly want to work for Sun. I was right on the first count, but knew I was wrong on the second just moments into my first conversation with Jeff. He was emphatic that I should join him in forging the future, sharing both my enthusiasm for what was possible and my disdain for the broken, busted and boogered-up. Fourteen years later, I don't for a moment regret my decision to join Jeff and Sun: we fostered an environment where the OS was viewed not as a regrettable drag on progress, but rather as a nexus of innovation -- incubating technologies that today make a real difference in people's lives.

In 2006, itching to try something new, Mike and I talked the company into taking the risk of allowing several of us to start Fishworks. That Sun supported our endeavor so enthusiastically was the company at its finest: empowering engineers to tackle hard problems, and inspiring them to bring innovative solutions to market. And with the budding success of the 7000 Series, I would like to believe that we made good on the company's faith in us -- and more generally on its belief in innovation as differentiator.

Now the time has come for me to venture again into something new -- but this time it is to be beyond the company's walls. This is obviously with mixed emotion; while I am excited about the future, it is very difficult for me personally to leave a company in which I have had such close relationships with so many. One of Sun's greatest strengths was that we technologists were never discouraged from interacting directly and candidly with our customers and users, and many of our most important innovations came from these relationships. This symbiosis was critically important at several junctures of my own career, and I owe many of you a profound debt of gratitude -- both for your counsel over the years, and for your willingness to bet your own business and livelihood on the technologies that I helped develop. You, like us, are innovators who love nothing more than great technology, and your steadfast faith in us means more to me than I can express; thank you.

As for my virtual address, it too is changing. This post will be my last at blogs.sun.com; in the future, you can find my blog at its new (permanent) home: http://dtrace.org/blogs/bmc (where comments on this entry will be open). As for e-mail, you can find me at the first letter of my first name concatenated with my last name at acm.org.

Thank you again for everything; take care -- and stay in touch!

26 Jul 2010 12:19am GMT

ON flag day emails are archived automatically to an internal server and then mirrored externally. Unfortunately, folks sometimes give the internal URL when referring to a particular flag day message, which doesn't do you much good if you don't have access to the Oracle/Sun internal network.

While it would be preferable to have the external URL to start with, the mapping from the internal URL to external URL is pretty simple. Replace "onnv.sfbay.sun.com" with "static.opensolaris.org/on". So, for example,

http://onnv.sfbay.sun.com/flagdays/pages/20100303235050.html

becomes

http://static.opensolaris.org/on/flagdays/pages/20100303235050.html

25 Jul 2010 10:44pm GMT