2007-04-27 14:32:00
Ever since Apple switched to Intel processors in their systems and Parallels came out with their Parallels Desktop software it's been possible to run Windows, Linux and other Unices inside virtual machines on your Mac. That's totally great, since it allows you to run various test systems without needing additional hardware!
A lot of people also got Solaris 10 to run in PD, although some ran into a little bit of trouble. Well, not anymore! Sun has created a pre-installed Solaris Express image for use with Parallels Desktop. This allows you to immediately get up and running with Solaris, without even having to go through any of the normal installation hoops.
I know what I'll be doing when I get my Macbook in ;)
Thanks to Ben Rockwood for pointing out this little gem.
kilala.nl tags: unix, apple, sysadmin,
View or add comments (curr. 0)
2007-04-18 14:38:00
One of the obvious down sides to using a scripting language like ksh as opposed to a "real" programming language like Perl or PHP (or C for that matter) is that, for each command that you string together, you're forking off a new process.
This isn't much of a problem when your script isn't too convoluted or when your dataset isn't too large. However, when you start processing 40-50MB log files with multiple FOR loops containing a few IF statements for each line, then you start running into performance issues.
And as I'm running into just that I'm trying to find ways to cut down on the forking, which means getting rid of as many IFs and pipes as possible. Here's a few examples of what has worked for me so far...
Instead of running:
[ expr1 ] && command1
[ expr2 ] && command1
Run:
[ (expr1) && (expr2) ] && command1
Why? Because if test works the way I expect it to, it'll die if the first expression is untrue, meaning that it won't even try the second expression. If you have multiple commands that complement eachother then you ought to be able to fit them into a set of parentheses after test cutting down on more forks.
Instead of running:
if [ `echo $STRING | grep $QUERY | wc -l` -gt 0 ]; then
Run:
if [ ! -z `echo $STRING | grep $QUERY` ]; then
More ideas to follow soon. Maybe I ought to start learning a "real" programming language? :D
EDIT:
OMG! I can't believe that I've just learnt this now, after eight years in the field! When using the Korn shell use [[ expr ]] for your tests as opposed to [ expr ].
Why? Because the [ expr ] is a throw-back to Bourne shell compatibility that makes use of the external test binary, as opposed to the built-in test function. This should speed up things considerably!
kilala.nl tags: unix, work, writing, sysadmin,
View or add comments (curr. 0)
2007-04-16 16:38:00
When writing shell scripts for my customers I always try to be as clear as possible, allowing them to modify my code even long after I'm gone. In order to achieve this I usually provide a rather lengthy piece of opening comments, with comments add throughout the script for each subroutine and for every switch or command that may be unclear to the untrained eye.
In general I've found that it's best to have at least the following information in your opening blurb:
* Who made the program? When was it finalised? Who requested the script to be made? Where can the author be reached for questions?
* A "usage" line that shows the reader how to call the program and which parameters are at his disposal.
* A description of what the program actually does.
* Descriptions for each of the parameters and options that can be passed to the script.
* The limitations imposed upon the script. Which specific software is needed? What other requisites are there? What are the nasty little things that may pop up unexpectedly?
* What are the current bugs and faults? The so-called FIXMEs.
* A description of the input that the program takes.
* A description of the output that the program generates.
Equally important is the inclusion of debugging capabilities. Of course you can start adding "echo" lines at various, strategic points in the script when you run into problems, but it's oh-so-much nicer if they're already in there! Adding those new lines is usually a messy affair that can make your problems even worse :( I usually prepend the debugging commands with "[ $DEBUG -eq 1 ] &&", which allows me to turn the debugging on or off at the top of the script using one variable.
And finally, for the more involved scripts, it's a great idea to write a small test suite. Build a script that actually takes the real script through its loops by automatically generating input and by introducing errors.
Two examples of script where I did all of this are check_suncluster and check_log3 with the new TEC-analysis.sh on its way in a few days.
So far, TEC-analysis.sh checks in at:
* 497 lines in total.
* 306 lines of actual code.
* 136 lines of comments.
* 55 lines of debugging code.
Approximately 39% of this script exists solely for the benefit of the reader and user.
kilala.nl tags: work, unix, writing, sysadmin,
View or add comments (curr. 0)
2007-04-06 10:57:00
Yay! There wasn't much reason for my doubting :) I passed with a 690 score (on a 200-930 scale), which boils down to 87% of 73 questions answered correctly. Not bad... Not bad at all...
Next up: ITIL Foundations!
kilala.nl tags: work, lpi, unix, studying,
View or add comments (curr. 7)
2007-04-03 23:41:00
The LPIC-102 summary is done. You can find it over here, or in the menu on the left. Enjoy!
kilala.nl tags: work, lpi, writing, studying, unix, sysadmin,
View or add comments (curr. 0)
2007-04-03 23:37:00
Ruddy heck, what a day! All in all it took me around thirteen hours, but I've finally finished my LPIC-102 summary. 41 pages of Linuxy goodness, bound to drag me through the second part of my LPIC-1 exams.
Argh, now I'm off to bed. =_= *cough* Let's hope I don't get called for any stand-by work.
kilala.nl tags: writing, work, lpi, unix,
View or add comments (curr. 2)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.