planetLINA

Yes, it’s true. I haven’t blogged for a LONG time. Sometimes I find blogging to be a harmless way to vent my annoyances, and I guess I haven’t been all that annoyed lately.

Well this week I started using Solaris.

We are getting set to test LINA on some new platforms - branching out into other ‘nix’s, starting with BSD and Solaris. So I’m setting up test machines, and I’m thinking it’s all UNIX, right? I mean, how hard can it be?

To digress a little… This blog is addressed to a very small audience. As far as I can tell, lazy cheaters simply don’t use Solaris, unless, like me, they find themselves thrown together with it through some cruel twist of fate. If that is the case for you, you may find the following tips useful, if you’re running OpenSolaris 2008.05 anyway.

Installing OpenSolaris is actually quite pleasant, a huge step forward in usability from a Solaris 9 install I did a couple years back. A few nice click-throughs and it’s up, with a pretty Gnome interface and everything. I’m amazed. I begin to wonder if Solaris could possibly have become a lovely GUI-guided experience with plenty of back-patting and hand-holding. Would I be forced to retract all the snarky comments I’ve made lately about the non-usability that seems to permeate all things Sun?

So I go to set up the network.

Exploring the drop-down menus I find System-Administration-Network. Cool! I click on it, and it gives me this:

Okey dokey. I like the handy link, especially useful because the whole point is that networking is actually NOTworking. So I guess I need to figure out what NWAM is, or at least how to disable it. This brings us to our first lesson:

• Starting and stopping services
  Yes, there is a menu item called “Services” under System-Administration. Unfortunately, it does not appear to offer a complete list of services. I could find nothing that might be our friend NWAM. So the next stop is /etc/init.d. This directory is oddly vacant, save for some legacy scraps, and luckily a README file. This is the first breadcrumb on the trail. And this is the where the trail leads, in a nutshell.
  To see all services and their status, type:
  svcs -a
  Aha! There’s nwam, as svc:/network/physical:nwam. So how do we temporarily disable it,whatever it is, just until the next boot? Simple. Just type:
  svcadm disable -t network/physical:nwam
  And there you have it!
  Now, going back to System/Administration/Network, we get:
  
  Sweet! A few clicks and I have the network up and running in DHCP mode.
  And then I go to test it. I type ‘ping openlina.com‘ at the command line. And I get: ‘ping: unknown host openlina.com‘. Drat!

Oh, you wanted DNS with that network?
As a first shot at debugging, I try ‘ping 209.85.26.3‘. Success! So it’s just not resolving domain names. I guess that kind of thing is considered a bonus in Solaris land. What, don’t you know the IP address? You must be a lazy cheater.
Why, yes I am. So I figured out how to make DNS work, as a service to my fellow sloths:

1. As root, edit the file /etc/nsswitch.conf
2. Change the line that says ‘hosts: files‘ to ‘hosts: files dns‘

And there you have it. No need to even restart the network. See how friendly Solaris is!

Installing packages
So by now you may have noticed that the only available console text editor is vi. If you’re a lazy cheater like me, you may find this unacceptable. So you open the package manager by going to System/Administration/Package Manager and hunt around a little. The only available text editor is something called SUNW-gnome-text-editor, which turns out to be gedit. Yuck. What if you want something simple and friendly, like nano? Are more repositories available?
The answer lies at sunfreeware.com. Clearly by and for geeks, this website is nonetheless home to all manner of interesting and useful little Solaris apps. To find the right ones, just choose your Solaris version and hardware from the list on the right. So can this repository be added to the Package Manager? I couldn’t find a way to do this, but perhaps someone with a longer attention span could. Luckily, it turns out that installing packages by hand is not quite rocket science, once you know how. This is how it’s done:

1. Select the package you want from the download page for your system. The relevant page for Solaris10 on Intel is www.sunfreeware.com/indexintel10.html. Warning - do NOT try to make sense of this page. Simply observe that there is a list of applications at the right. Choose one, say nano-2.09, and click on it.
2. Now click on the link that appears at the top of the page and download the corresponding gzipped package file to your desktop. In the case of nano, the file is nano-2.0.9-sol10-x86-local.gz.
3. Open a terminal and go to your desktop by typing “cd /export/home/username/Desktop“.
4. Uncompress the package by typing “gunzip nano-2.0.9-sol10-x86-local.gz“
5. Install by changing to root (”su”) and typing “pkgadd -d gunzip nano-2.0.9-sol10-x86-local“.
6. Now type “nano” at the command line and note that you get the response “bash: nano: command not found“. This is because the default sunfreeware install location is /usr/local/bin, and this is not on your path.
7. Remedy this by editing the file /export/home/username/.bashrc. Add ‘:/usr/local/bin‘ to the end of the line that starts with ‘export PATH‘. After you do this close your terminal window and open a new one in order to set the new path.
8. Now type “nano” at the command line and note that you will get a response complaining about the fact that ncurses is not installed. Remedy this by downloading and installing ncurses-5.6 from sunfreeware.com, as above.
9. Now, type “nano” at the command line, and it will work!

See, Solaris is not that bad!

Share This

I guess we just need to accept the fact that the last hours of testing always stretch into days.At least this time each of us has actually gone home to sleep occasionally, between naps on the floor.

We have sixteen operating systems to support, and every single freaking one is quirky. We’d taken two small testing shortcuts, these past weeks. First, we’d been doing our main testing on just one-each of the main OS flavors - XP representing Windows, Leopard Intel representing Mac and Fedora7 standing up for UNIX. Second, we’d been testing hand-built installers, in order to speed up the turn-around time between bug discovery and bug stomp. Rebuilding from scratch takes at least a half day, while patching code is nearly instantaneous. We were eager to keep moving forward. No time for details like testing OS variants or building out the fixes.

And oh boy, did we pay for our impatience.

We expected glitches when we expanded to the full spectrum of OS’s. Some of the OS variants are puzzlingly unique when it comes to permissions, services and supported packages. Some are downright diabolical. We already knew that. Going from testing with our three little friends to including the whole mangy lot is like inviting the whole extended family over for dinner. It’s invariably messy, and it always goes on too long.

The installers generated by the build system should have been identical to the hand-built ones, and they almost were. There were only about two or three features that didn’t quite make it into the build system intact. Yeah, we’ve been doing continuous test builds, and yeah they were working to the extent that they were spitting out installers every day like chickens laying fat little eggs, but we were just watching those eggs fall into the basket, never noticing that they had started to get a tiny bit scrambled. Because of the 12-24 hour lag time between fix and build completion there were always fresher fixes to be fried up. And now we’re paying, with a 12-24 hour wait as we test each missing feature. Sure would have been nice if we’d been verifying the built installers as we went along.

Important testing note: Always test what you actually plan to use. At least occasionally.

Ok, better go check on those chickens.

I’m going to be SO happy when this is done.

Share This

I’m reading a very good book right now: Made to Stick by Chip and Dan Heath. You really ought to read it yourself, so I won’t go into much detail, but the basic premise is that if you frame your idea like an urban legend or a proverb, people will understand it, and spread it.

Which ideas become part of the common unconscious? What does everyone just know? Let’s see…

• An apple a day keeps the doctor away.
• Don’t take candy from strangers.
• Campbell’s chicken soup is mmm mmm good.
• If you’re throwing out the bathwater, check it for babies first.

What do these ideas have in common? Short, sweet, nice rhythm. A child could easily make them into colorful posters.

So the big question is, how do we do this with LINA?

We’ve got a tough one. LINA’s silent and invisible. It will mean different things to different people. To a software developer it will be a revolutionary breakthrough. To the head of an IT department it will be better than aspirin. To my mom it will be this thing she clicked on to make other things on her computer work.

What’s our sound-bite? Our tag-line? Our elevator pitch?

Invsible system-hopping super-bunnies? That lay eggs and grow wool and give milk? That future-proof your business while you are sleeping?

We’re working on it. Stay tuned.

Share This

Hi!

As the newest member of the LINA team and VP of Product Quality I want to share my view of the wonderful, wacky LINAverse such as our adventures interviewing for a new CEO, the perils and pitfalls of working in a very old, but elegant bank building in Alameda, and the surprising adventures that can befall someone who is open to them just walking three blocks to work!

I hope to see you soon.

Release-week has actually become somewhat routine now. Yeah, we all sleep less and make stupider jokes. But really we’re getting pretty good at the whole thing. Now that the xml-based test system is clunking along fairly robustly, I can largely administer the builds from home. Which means Nile can call me at three A.M. with some fixes checked in, and I can drag myself out of bed and type a few characters and have the whole thing humming along again. No tougher than feeding an infant. In fact a lot less messy. And definitely preferable to our old test-week routine, where we took turns napping and pacing, with an occasional break for a groggy consultation followed by mad typing.

It helps that we’ve been testing lazily in the background during this whole release cycle, banging the kinks out of both the test system and the code itself. This time around we’re entering the formal testing period armed with a robust build machine. When all goes well, we can wander in in the morning and pluck its fruits for hand-testing. This leaves us a lot more time and brain space for other efforts, like rigorous usability testing, business-plan writing, and website design. Not to mention Haiku writing for the forum.

Mainly we’re fueled by excitement over this release. Everything’s starting to work nicely, rather than just limping along. We’re very much looking forward to letting this one out of its cage.

Share This