Monday Jun 25, 2007

Brain surgery: /usr/ccs tumor removed

Sometimes it just takes way too long to remove brain damage. Way back when Solaris 2.0 was forming, someone had the bright idea to move the  C compilation system from /usr to /usr/ccs. I suppose the idea was that since you no longer had to compile the kernel, the C compiler no longer needed to be in the default user environment.  I think the same gremlin also removed /usr/games entirely, another long-time staple.  This move also coincided with the "planetization of Sun" idea, so the compilers were split off to become their own profit and loss center.  IMHO, this is the single biggest reason gcc ever got any traction beyond VAXen.  But I digress...

No matter what the real reasons were, and who was responsible (this was long before I started working at Sun), I am pleased to see that /usr/ccs is being removed. I've long been an advocate of the thought that useful applications should be in the default user environment. We should never expose our company organization structure in products, especially since we're apt to reorganize far more often than products change. IMHO, the /usr/ccs fiasco was exposing our customers to pain because of our organizational structure.  Brain damage. Cancer. A bad thing.

I performed a study of field installed software a few years ago. It seems that Sun makes all sorts of software which nobody knows about because it is not installed by default, or is not installed into the default user environment. I'm very happy to see all of the positive activity in the OpenSolaris community to rectify this situation and make Solaris a better out of the box experience.  We still have more work to do, but removing the cancerous brain damage that was /usr/ccs is a very good sign that we are moving in the right direction.

Tuesday Apr 03, 2007

San Diego OpenSolaris Users Group forming

We're starting a San Diego OpenSolaris Users Group. Everyone is invited to participate, especially those in the San Diego area. We're planning on meeting the first Wednesday of every month, except for July 4th, 2007, which is a holiday. The first meeting will be Wednesday May 2. For more information, see the website, join the e-mail list, or monitor the forum.

Tuesday Feb 13, 2007

Solaris Express Developer Edition solves "support" problem

Last month, I blogged about open source Solaris Nevada build 55. I normally don't single out specific Nevada builds as worthy of a blog entry -- not because I think they are unworthy, but because they come out every two weeks which gets to be a lot of regular work to blog about.

So, why is build 55 so special? It is the first build which has become known as the Solaris Express Developer Edition. This is a milestone release because it is available with a support contract. Many people don't care about support, and you will often hear them complaining about the fact that Solaris 10 doesn't have some version of an application which was just put up on the web last week. The quality process involved in producing, distributing, and supporting a large software product, such as Solaris, takes time to crank through. If you really want the lastest, greatest, and riskiest version of Solaris, then you need to be on a Solaris Express release. The problem is that we couldn't provide a support contract for Solaris Express. That problem is now solved. Those who demand support and want to be closer to the leading edge can now get both in the Solaris Express Developer Edition.

Go ahead, give it a try. Then hang out with the Solaris community at the website where there is always interesting discussions going on.


Monday Jan 01, 2007

Nevada build 55 -- nice!

Over the holiday break I installed Solaris Nevada build 55 on a few machines.  This is an important build and I think you'll see lots of people talking and blogging about it.  Here are a few reasons why I think it is cool:

  • StarOffice 8 is now integrated. Previous Nevada builds had StarOffice 7, which meant that I had to install and patch StarOffice 8 separately.  This significantly reduces the amount of time I needed to get my desktop up to snuff.
  • Studio 11 is now integrated.  This is another time saver.
  • NetBeans 5.5 is also integrated.  I use NetBeans quite a bit for Java programming. I fell in love with refactoring and the debugging environment.  I also do quite a bit of GUI work, and NetBeans has saved me many hundreds of hours of drudgery.
  • NVidia 3-D drivers are integrated.  Still more installation time savings.
I do install every other build of Nevada, and these changes have significantly reduced the time it takes for me to go from install boot to being ready as my primary desktop.  More importantly, it shows that once we can get past some of the (internal political) roadblocks, we can create a richly featured, easy to install, open source Solaris environment that showcases some of the best of Sun's technologies.

BTW, one of the cool things I've been playing with over the break is the integration of StarOffice with NetBeans. There are NetBeans wizards which you can use to create add-ons for StarOffice. Check out how easy it is to add a function to StarOffice Calc!

Tuesday Jun 28, 2005

Solaris NV and NForce3 update

I've blogged in the past about using Solaris on NVidia NForce3 chipsets. Here is an update.

For Solaris NV build 14 or later, and (I think) the latest Solaris Express release, you should be able to find the SUNWnge package.

# pkginfo SUNWnge
system SUNWnge Nvidia CK8-04 GE driver

This package is targeted at the NVidia NForce4 chipset. But it does seem to work well with the NForce3 chipset, too. You will need to coerce it into finding the proper device driver alias for the ethernet interface. There is good news, as the audio interface driver alias change I previously blogged about is no longer needed. Solaris should find the audio properly, out of the box. create an entry in the /etc/driver_aliases file to bind the driver as follows:

nge "pci10de,df"

The interface should plumb as nge0.

I won't guarantee this will work for anyone, but it seems to work for me. Preliminary testing is going well. If I don't find any problems, I'll try to find out how to get this alias added to the main Solaris 10 distribution and on the HCL page.

Tuesday Jun 14, 2005

Oh my god!

Oh my god! Its full of source!
Starchild Dave Bowman

Monday Jun 13, 2005

What? What's going to happen?

"What? What's going to happen?"

"Something wonderful."


"I understand how you feel. You see, it's all very clear to me now. The whole thing. It's wonderful."

Friday Jun 10, 2005

Something wonderful is about to happen.....

Something wonderful is about to happen.
-- Astronaut Dave Bowman

Wednesday Jun 08, 2005

Something wonderful is about to happen...

Something wonderful is about to happen.
-- Astronaut Dave Bowman

Monday Jun 06, 2005

Something wonderful is about to happen.

Something wonderful is about to happen.
-- Dave Bowman

Sunday Feb 06, 2005

Spoofing time and space with DTrace

Now that more people are convinced that they can't trust the hostids anymore, I now feel compelled to add that you can't trust time or space either. It is just as easy to spoof time on a per-pid basis as the hostid. Some counter that they could stat a file and see what time it is based on the latest mtime, but that too is fairly trivial to spoof. Still others insist that they could do an NTP lookup to a well known time server -- also spoofable. None of these methods can successfully be used to guarantee anything. Software vendors must trust their customers.

Monday Jan 24, 2005

spoofing hostids

For many years, Sun has provided hardware with a unique hostid. I never used a Sun-1, but I wouldn't be surprised if it had a unique hostid. The hostid is traditionally used by software vendors as a unique identifier for software license enforcement. For example, a software license key could be provided to a paying customer which would be a hash which could compare to the hostid. Thus, the software company could believe that the software was only operational on the host which had the proper hostid.

Back in the days of SunOS 3 and 4, it was common for people to recompile the kernel. It didn't take long before people began compiling their own system calls which returned the hostid. The sources were readily available on the various ftp sites and newsgroups of the time (this was before HTTP was invented.) Others found that the Sun workstation hostid was partially read from a nonvolatile memory which could be easily hacked via the firmware interface, and later OpenBoot. But the cleverest implementations were done in the kernel and did things like look at an environment variable for the hostid.

When SunOS 5 (part of Solaris 2) came along, compiling the kernel wasn't required or recommended. This led to a number of new ways to spoof the hostid using dynamically loadable libraries and other techniques.

Now with Solaris 10 we have an awesome tool called DTrace. Amongst the many useful things you can do with DTrace is spoof the hostid. I'll leave the details as an excercise for the truly bored, but suffice to say it takes about 6 lines of D code, more if you want to be more clever. Although the Sun execs have said that Solaris source will be available RSN, you don't need to recompile the kernel to spoof the hostid.

My advice to software vendors has remained unchanged since I started buying software back in the mid 70's: trust your customer. There is no real way to enforce licenses by supposedly unique keys on hardware. Get over it. Laser holes in floppy disks didn't work. Little serial port dongles didn't work. hostids certainly didn't work. Make all of our lives easier, and come up with a good way to win customers with your value and trust them.

Thursday Jan 20, 2005

vfstab viruses

I have been known to rant about /etc/system viruses. These occur when people blindly copy /etc/system tunables to different systems or carry them forward during OS upgrades. FYI, each Solaris release contains a document called the Solaris Tunable Parameters Guide which is intended to document /etc/system (and other) tunables and makes recommendations as to their use. While this has cut down the myths about the tunables, they still have viral characteristics.

In Solaris 10 there is another type of similar conundrum that is similar. I'll call these /etc/vfstab viruses. We do some clever things with Solaris 10 to implement some of the cool new features. Some of these need /etc/vfstab entries, specifically the contract file system (ctfs) and the kernel object file system (objfs). This means that if you install a Solaris 10 system, copy over your old /etc/vfstab (this propagating it like a virus), then you can render your Solaris 10 partially inoperative.

The lesson: you should always review changes to configuration files during OS upgrades, especially /etc/system and /etc/vfstab. Do not simply copy previous versions of these files onto the new OS. If you don't understand what the files are or what should go in them, please take some time to look at the supplied documentation.

Wednesday Dec 01, 2004

Solaris 10 on Athlon 64!

I installed Solaris 10 software Express 11/04 on one of my Athlon64 systems at home. It boots and installs as 64-bit, a pleasant surprise. This box has an MSI K8N Neo motherboard which is based on the NVIDIA nForce 3 250 Gb chipset. Out of the box, the audio and networking did not work. For a temporary network solution, I've added a PCI card... it is just too hard to transfer needed files if you aren't on any network.

For nForce 3 audio, I was able to convince the audio810 driver to work. This driver is now included in Solaris 10, since that is what we use for our Opteron-based workstations. But I had to create an entry in the /etc/driver_aliases file to bind the driver as follows:
audio810 "pci10de,ea"
I won't guarantee this will work for anyone, but it seems to work for me. Preliminary testing is going well. If I don't find any problems, I'll try to find out how to get this alias added to the main Solaris 10 distribution. Now, onto the network problem...

Tuesday Aug 31, 2004

JDS tip of the day

Calum Benson made my day.

Apparently, there is a default behaviour in Nautilus which will cause it to redraw the screen at various times. On a blazing-fast system you might not notice this, but on a slower system you can sit there and watch the redraw. Actually, I'm a firm believer in only allowing UI developers to use 5-year old machines, so they can experience their algorithmic decisions. Anyway, you can quite easily change the default or change it back if you don't like it. Here's how:

In a terminal window type, gconf-editor
Traverse the settings tree to: apps -> nautilus -> preferences
Deselect (or select, to revert): show_desktop

This seems to be working well for the way I use the Java Desktop and it is noticeably faster for some operations, especially when I have lots of windows and screens active, which I often do. YMMV.




« February 2017