Packaging with the Solaris IPS
I needed to package some software for Solaris 11 and of course wanted to use the Image Packaging System, IPS, the new package management system that replaces the old SVR4 package format that Solaris 10 and previous releases used. To the casual observer, it looks like IPS brings "easy" package management to Solaris - it is now possible to quickly search for - and install - a package from the internet, and updates are easily retrieved as well. This seems to work smoothly - just like on Debian for example - which has had this functionality for more than a decade... Well, better late than never!
Since the system is not just new, but quite different from what it replaces, I started looking for primers and tutorials to figure out how to get started. A word of caution: IPS does things differently, and there are some tutorials on the net which attempt to fight IPS instead of working with it - this leads to complicated and silly ways of building packages the wrong way, and this will cause problems for your end users. What you really want, is to go to the official Oracle documentation and read the developer guide which is well written and does a very good job of explaining why IPS is different and walks you through an example of creating a package.
So far, I am fairly impressed with IPS - it is the first packaging system (and I have used quite a few - from DEC Unix and HP-UX to NetWare, Debian, Red Hat, Windows and what have you) where I did not have to script to create a user account. Scripting, by the way, is disallowed by IPS for the simple reason that you cannot validate a package if the installation executes scripts because you cannot (generally) validate the result of a script. Instead of using all the provided tools for generating manifests from older packages, I simply wrote the .p5m manifest files myself and generated .p5p repository archives from them. In the future I guess I should make sure the repositories are on-line, so that the users can get their software updates along with the operating system updates when they run pkg update.
Running - the beginning
I have been biking a lot the past few years, but I have not been running much. In fact, I have almost not been running at all. Because of the biking, I'm in reasonably good shape (resting heart rate in the 40s, body fat below 15% and so on) but I just cannot run. My legs just won't do it. It hurts, especially the days after a run. So, I decided to go ahead and start running regularly.
In order to fit everything into a tight schedule, what I can do is, that I can make two weekly runs - one in the morning and one in the evening, on a single day of the week. The run will be 8.4km in each direction (to and from work). That's it. Clearly, running twice a day on a single day of the week is not going to be an optimal training schedule by any stretch of imagination, but this is that I have to work with.
The reason for this post, is the rapid change I experienced over the first four weeks (four times two runs). I have put some key numbers in the table below.
| Run | Avg moving pace | Efficiency | Avg. HR | Pain following |
|---|---|---|---|---|
| 1A | 5:06 [min/km] | 13.1 [m/kC] | 161 [bpm] | - |
| 1B | 5:26 [min/km] | 12.7 [m/kC] | 159 [bpm] | Severe leg pain for 4 days |
| 2A | 4:51 [min/km] | 13.5 [m/kC] | 161 [bpm] | - |
| 2B | 5:10 [min/km] | 13.1 [m/kC] | 154 [bpm] | Some leg pain for 4 days |
| 3A | 4:44 [min/km] | 13.9 [m/kC] | 162 [bpm] | - |
| 3B | 4:56 [min/km] | 13.8 [m/kC] | 157 [bpm] | Only slight soreness for a day |
| 4A | 4:34 [min/km] | (N/A) | (N/A) | - |
| 4B | 4:43 [min/km] | 14.7 [m/kC] | 158 [bpm] | Nothing |
Personally I was very surprised to see the numbers change this much over just four training days (two sessions a day, one day a week, for four weeks). Due to illness I have had to skip two weeks, so it will be interesting to see how much damage that did, and how the numbers will progress from there. I would expect the average pace to stabilize first, and see the energy efficiency continue to grow further. I am curious by the way - what energy efficiency do you have as an experienced runner?
Making a roomba negotiate a doorsill
Having just become a Roomba owner, I was faced with the challenge of wanting the robot to negotiate a slightly large doorsill in a narrow doorway, as the robot should move form the livingroom to adjacent rooms. The manual says that you should lave at least 1 meter of open space from the front of the lighthouse - but this is difficult when the doorway itself is less than one meter. Second, the doorsill is a two-step construction with a 2cm climb followed a few centimeters later by a 1cm climb.
By default, the roomba could not reliably pass the sill. It frequently got stuck on the 2cm climb, and it bumped into the side of the door frame opposing the lighthouse.
Solution 1: Smooth the climb
To allow the robot to better negotiate the 2cm climb, smoothed it out a bit
with a ramp. This is a proof of concept - I will make one that fits better and
hopefully matches the colour of the floor or sill, but I needed a prototype
quickly.
Solution 2: Traverse closer to lighthouse
The robot cannot measure its distance to the
lighthouse as such (it has no laser based range finder, sonar or other means of
establishing distance aside from bumping into things or sensing "large objects
approaching"), so how does it decide which distance to keep to the lighthouse?
I could not find any documentation on this, so my best guess was that the
lighthouse is projecting an infrared beam from the top, at a downward angle
towards the opposing side of the door frame. The robot will then approach when
the beam has the right height, relative to the floor space of the robot. See,
this even worsens my problem - not only is the door frame too narrow already,
the lighthouse sits elevated on the doorsill while the robot is 3 cm below on
the floor, and will therefore traverse the doorsill even further away from the
lighthouse (since the lighthouse is elevated, the robot needs more distance to
the lighthouse for the infrared beam to reach the right height). The simple
solution is to glue two rubber spacers on the two back feet of the lighthouse, so that
it is tilted slightly forwards. This changes the angle of the infrared beam, and the robot
will find the right height of the beam closer to the lighthouse. I have no confirmation
that my theory behind this holds, but the solution works like a charm.