Well, my stint in *buntu is over, and it ends with an award to openSUSE: this is the first Linux distro I've returned to.
Kubuntu is nice, and I'm happy that I've tried it out, but it's not for me. It's nice enough if you want a simple desktop system, and APT rocks (especially with the aptitude front-end). But it's just not as good as openSUSE, sorry.
This post was originally published at sinewalker.wordpress.com on 1 May 2006.
I posted this reply to an Ask Slashdot: Do Kids still program? I found myself commenting all over that thread… it must be close to my heart :-) Reproducing here, and exploring a little further.
Many of the observations made on Slashdot are right. I wonder what it is that drives me to hack, that is missing from what is covered? Why do I like to hack, and why would it be passed over by kids these days? Or would it?
This post was originally published at sinewalker.wordpress.com on 4 April 2006.
I'm sure this observation has been made elsewhere, but I can't find reference to it online.
Have you ever noticed the prolific use of mystical/fantastical words in computer jargon? I'm sure there is a significance, or at least a tongue-in-cheek pointing to the wizardly ways of early and contemporary computer experts. It is funny I suppose, and when you look at how wide-spread it is, it may be revealing of the hacker psych.
This post was originally published at sinewalker.blogspot.com.au on 24 March 2006.
This is a pretty neat shot of the in-flight entertainment system on an Airbus A330 having a boot-up issue. Note, the kernel is Linux.
Originally uploaded by milliped.
This photo has a big rant in the flickr comments about whether or not it's a Linux crash. Well, what's a Linux crash? Most of the public Windows crashes do not involve the Windows kernel (except for blue-screens) but they get called Windows crashes. So, to be fair, this is a Linux crash, even if it appears that the kernel itself is fine.
This post was originally posted at sinewalker.blogspot.com.au on 10 February 2006.
Was thinking about the Free as in Freedom, vs Free as in Beer analogy and I found a problem with the Free as in Beer offering.
Beer is actually already nearly Free as in Freedom, since the process to produce your own beer, and many good recipes are public domain. So maybe the analogy should be “free as in Coke™”. This works better, because someone can give away Coke bottles full of CocaCola™, and this is not the same as being given the secret recipe to make your own Coke.
Just a thought, anyway.
This post was originally posted at sinewalker.blogspot.com.au on 24 January 2006.
In reference to this Slashdot articleabout Diebold electronic voting data availability.
Adopting Open voting/documententation standards would curtail these sorts of issues, without the FUD of forcing constituents to switch… However, I think that blaming it on Diebold is only a scape-goat to hide corruption in the voting system, so it's likely to remain…
This post was originally published at sinewalker.blogspot.com.au on 27 October 2005
The great thing about Linux is that all the definitive documentation (including the source code) comes with the OS.
You know, I'm finding that for a lot of the “beginner” linux distro's, this is not true. Yes, the source is available but it doesn't come with the OS.
Granted, not everyone wants to fill their harddrives with source tarballs or SRPMs on the off chance they might want to read them, but only a few distro's I know come with source, and those are not necessarily for noob's. the main example that comes to mind is Gentoo (since it's a “ports”-like distribution). This is not to wax lyrical on the benefits of Gentoo for learning Linux (Gentoo has many weaknesses in that regard too, among its inappropriateness as a general OS for noob's), just that it's the only one I've found where the source comes with the OS.
Other distro's with source “available” are Debian and Fedora (on extra CDs you have to download, and Fedora locks the source into SRPMs which is another learning hurdle to leap over, especially bad if all you want to do is read the source comments, or documentation not included in the binary RPM). It makes me feel like a 2nd-class citizen, that the source is somehow “open” but you have to know the secret handshake to get at it.
All of this, just to say: while reading source docs is a laudable habbit and I share your wish to encourage it, I can also see how it is difficult for most Linux noob's to form this habbit so long as the source doesn't actually come with the OS, which for a great many distro's it does not. The extra steps to download (and in many cases extract from SRPMs) the source are probably enough of a deterrent to forming this habit.
unfortunately, hacker habbits require hacker motivation :-(
This post was originally published at sinewalker.blogspot.com.au on 18 July 2005
In reference to this Slashdot question about Mainframe Culture
Appart from the obvious religious stuff about GUI (or lack of) and user-centred interfaces (or lack of), the biggest difference, and the biggest advantage that Mainframe brings is it's culture of process and change control. It is something you should strive to let your Mainframe masters pass on to the *nix/windoze padawans before they die of old age.
I am a *nix padawan, but, crocky technology asside, I'm frequently impressed by my Mainframe elders, their ability to deploy code to Production environments that works *the first time* nearly every time, and their ability to communictate technical changes necessary to fix broken code in the middle of the night in the 0.1% of cases where they failed to get it working first time.
Key values that I have picked up from my masters, and which should be inherrited by both *nix and PC/Mac enclaves are focused around Engineering principles. Mainframe guru's program like a civil engineer builds a bridge. No shortcuts are taken unless it can be proven that it is safe to do so. Testing is carried out in stages and test results must be submitted with the change request before a program migrates to Production. If a program must “abend” (Abnormal End) then it should do so noisily and with as much information as possible. If it finishes cleanly, little information is needed other than this fact.
These closely follow the advice Raymond has encoded in his book, but there is probably much more that your Mainframe gurus know that you should cherrish and extend to your newer team members.
Forget about the religious wars, the technology changes and the “focus” of your programmers on users or other programmers. Get the real truth from your Mainframe masters who have seen it all pass before them but have learned the hard way how to make a stable computer environment that stays up, even on cruddy mainframe technology. If their attitudes were adopted by people fluent in today's fantastic systems, all people would benefit.
The sad fact is that, in today's environment, especially after the dot-com cowboys set Upper Management expectations, following Process is just too slow, or too expensive. Convincing management that a bigger cost up front will result in a lower cost in the long run is also futile when mgt sees it as “normal” for computer systems to break. After all, their Windows machine on their desk has been doing that for 20 years now, so it must be normal, right?
What matters most to managers or clients when deploying new systems these days seems to be “time to market”, and the only consent to quality is that the IT dept/company follows check-list processes like CMMI or ISO9000 which do not address the real issues and put too much into the Process rather than the Result. Also, when the system breaks, it's typically at the expense of the IT company that built it, or was stupid enough to agree to use the off-the-shelf product in the first place, so there is nothing to drive a change of behaviour from the clients.