OpenSolaris bijeenkomst, Amersfoort, 8/10/2009

Zegt het voort...

De eerstvolgende bijeenkomst van de NLOSUG (OpenSolaris User group NL) zal plaatsvinden op donderdag 8 october, waar we weer te gast zijn bij Sun in Amersfoort.

Om onze gastheer en de catering een goede schatting te geven van het aantal bezoekers, graag aanmelden via email op nlosug@sun.com, onder vermelding van: Aanmelding-NLOSUG-okt2009

AGENDA

19:00 Welkom

19:30 Opening

• Update on NLOSUG
  Bart Muijzer
  Operating Systems Ambassador - Sun Microsystems
• What's New in OpenSolaris
• Boekbespreking
  Jan E. Kuba van Bijnen
  Unix/Solaris system & network consultant
• Confused by Solaris-es
  Bart Muijzer
  Operating Systems Ambassador - Sun Microsystems

PAUZE

• Contributing to OpenSolaris Repositories
  Eric R. Reid
  Staff Engineer at ISV engineering - Sun Microsystems
  

22:00 Afsluiting


Locatie:
Sun Nederland B.V.,
Saturnus 1,
3824 ME Amersfoort ( Route )

NL Opensolaris User Group

A new little icon for the UWIN ksh console

I've been using the korn shell for over twenty years now. Not only on solaris/opensolaris, but I also use it on windows, through the Uwin project, a port of the ast toolkit - a portable set of all standard unix tools, including the shell, but also nawk and the usual cat,sed,tr, list of tools.

Today, I finally created an icon for the UWIN shell console - the original icon, with the letters UWIN in bright colours is not displayed on the console window title bar. It is too large, and the title bar reverts to the standard C:\ icon.

I never paid much attention to it, but tonight I figured out the issue - the title bar icon should be no larger than 16x16 pixels. Once I realised that, a new fitting icon was created quickly, and here it is:



Yes, it's tiny. It's also just what I want for the shell window in my windows quick launch toolbar.

Here's a bigger view of the design. Getting the dollar sign sharp at three pixels wide was a bit of a challenge, but I was quite satisfied.


There's a zip here with the icon as a windows .ico, plus the .png above, and the development version with an odd colour in the background, which can easily be turned transparant when you save with Irfanview.

I've modeled the icon after the 16x16 Windows CMD icon. That is, I've used the measurements of the frame, although the pixels are mine.

Author: Henk Langeveld, shell icon, Oct 2008: zip
Copyleft: This is a free work, you can copy, distribute, and modify it under the terms of the Free Art License http://artlibre.org/licence/lal/en/

In addition, the files can be distributed under the Common Public License
http://www.opensource.org/licenses/cpl1.0.txt

Update:
Windows actually uses multi-page ICO files. For the title bar and toolbars it'll look for a 16x16 bitmap or substitute another icon of that size. For the desktop it will use the largest icon available. Does anyone know of a simple method of combining icons in a single file? Free tools preferred. I did see a method using Photoshop, which seems a bit of overkill...

Enjoy

The trouble with /var in unix systems

Mike Gerdts suggests using /var/share for sharing data between boot environments in his March 2008 post Future of OpenSolaris Boot Environment management.

The trouble with unix /var is that it is a grabbag, in that it is used both for storing system data (i.e., identity), as for storing application data.

/var/ is intended for variable data that should persist through a reboot: short lived temp files, spool directories for transient files (printing,mail), and whatever data applications might wish to store (/var/opt).

However, as said above, it also contains data about a systems 'identity', specific settings like cronjobs, printer settings, network configuration, definitions of services that altogether make up what the box 'is'. This also includes the list of installed software in /var/sadm. At some point these all moved into /var from /usr or /etc in ancient unix past.

Root was supposed to be small then, and did not contain a lot that could change, limiting the risk of a long fsck if there were a lot of modified files in the root fs. With just enough stuff to allow the system to boot, if you lost any other filesystem, if you had at least a running system you could attempt to repair or restore whatever was broken.

Mike's suggestion is very sound, as it does what is required. System identity is kept in the root fs (/), while application data, whether it's persistent or transient, goes into /var/share, keeping /var as part of the root fs, even though the 'share' name may be a bit of an unlucky choice - it's used in /usr/share and other places for architecture-neutral data that can be shared with other systems (nfs clients).

ksh93 performance through builtins - a small example

I recently held a presentation for the Dutch OpenSolaris Users Group about the work of Roland Mainz on integrating ksh93. I focused on the history of unix shells, how ksh93 was accepted in the OpenSolaris project, specifically highlighting the OpenSolaris ARC process.

I did not discuss the relative merits and reasons for getting ksh93 included, but today I'll mention one reason in particular: shell script performance. Ksh93 is faster than any other POSIX conforming shell in executing code, not in the least because many standard unix commands have been included as builtins in the shell, allowing scripts to bypass fork() and exec().

Here is a comparison of two lines of code in ksh93. Their effect is exactly the same: Ten thousand times, they create and remove a unique directory. The difference is that the second time around, the ksh builtins for mkdir and rmdir are used.

glorantha 10 $ time for i in {0..9999}; do /bin/mkdir $i; /bin/rmdir $i; done

real 0m35.63s
user 0m1.44s
sys 0m1.65s
glorantha 11 $ time for i in {0..9999}; do mkdir $i; rmdir $i; done

real 0m1.44s
user 0m0.33s
sys 0m1.09s

And this explains why a builtin matters. Both the internal and external command are just as efficient if they're only invoked once. When you have to invoke an external command inside an inner loop, the unix fork()/exec() overhead add up.

But there are other ways of improving the above bit of code, if you're satisfied with a slightly different sequence of actions, and non-POSIX code due to the compact {start .. end } notation.

What I like about this code is that it's compact, and quite clear in its intention.

glorantha 12 $ time mkdir {0..9999} && rmdir {0..9999}

real 0m0.53s
user 0m0.02s
sys 0m0.51s
glorantha 13 $ time /bin/mkdir {0..9999} && /bin/rmdir {0..9999}

real 0m0.53s
user 0m0.03s
sys 0m0.48s

More later

A difference in mindset

Some of my favourite literature are unix man pages. When I got started on unix, the system (a 3B2 w/ SVR2.0 IIRC) we used at the vakgroep AIV only had printed documentation. But it had all of its man pages in neat little red binders. The format fit exactly the way I absorb information, a quick overview, followed by a linear list of features.

Commands or options listed on the left hand side, with their explanation on the right. As a quick reader, I've never had any trouble distilling the information given in a man page. If I don't understand something, I just keep on going until I either find an explanation or get lost entirely. No problem. A second reading will often put things in a different perspective. And a third or fourth careful reading may sometimes clear up some assumptions or delusions as well.

I read the man page for sh(1), ksh(1) and ksh93(1) at least once a year. And I learn from it. I know most of the features supported by the original Bourne shell, plus the differences with the non-existing POSIX shell, Sun's ksh and AT&T's ksh93. I must admit I'm not confident with most bashisms, though.

The funny thing is that, until I encountered the dummy guides, I had never considered that some people do not like to read through a full description of all the features of a piece of equipment or a piece of software. It came as quite a revelation to me that most people, in fact, do not want to understand things, they just want them to work.

So the type of documentation a geek like me prefers is more like:

option x will do ...
option y does ...

etc., while a non-technical person will prefer text like:

To perform action X, select/press/dial ...
If you want to ..., do ...

The difference is like the P/J difference in the Meyers-Briggs typology. An old style hacker/nerd prefers to be given a set of options to explore (P), where another would prefer a more goal-oriented(J) approach.

I'm not saying one approach is better than another. I'm too much of an observer for that. I like to watch and see how people differ, than take a position on one side or another.

Let us be different.