Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

User Journal

Journal: Ping

Journal by Lodragandraoidh

I haven't written here in 5 years or so...thought I would throw a pebble in and see what ripples come back to me.

Operating Systems

Journal: A new computer science metaphor is needed...

Journal by Lodragandraoidh

I have recently seen some poor metaphors regarding computers and software.

This is my attempt to clarify the issue for the community in more simple terms (see notes below for more technical explanation if so inclined):

1. A computer is a simulation device which can simulate anything at all, given unlimited resources.

2. In practice we (programmers) build a subset of simulations that are most useful or entertaining for the users (because that pays the bills).

3. An operating system is a simulation that allows us to more easily manipulate our computer to run other simulations and communicate to and through ever more complex and sophisticated devices (sound cards, video cards, network interface cards, joysticks, mice, etc) that we hang off the side.

4. A very small subset of programmers have made an ungodly amount of money selling said simulations. The article kind of loses focus at this point and goes off on a tangent - I won't burden the reader here with that.

5. The CLI will not die simply because its utility and expressiveness outweigh the lack of utility and expressiveness found in pure graphical interfaces. The future is begining now - and is a hybrid - both the CLI and GUI coexisting for mutual benefit leveraging the strengths of both in ways far more sophisticated than we can envision today.

My own editorial: Until people stop reading altogether, or natural speach recognition becomes a reality, keyboards will be around for the foreseable future.

Notes (numbered to reference the numbered sections above):

1. The term simulation is defined in the dictionary as the " representation of the operation or features of one process or system through the use of another". This term is quite common in general use; everyone knows what a 'flight simulator' is for example. A computer program is really just a simulation. A bit of history will illustrate this point:

Alan Turing came up with the concept of a Turing Machine which could be used as a general purpose device to simulate any other machine or process using very simple instructions in building block fashion to produce more complex simulations. The brilliant scientist John Von Neumann further extended the idea* to encompass the first stored program computer architecture for practical use (which exists in modified form in all present PC computer cpus).
*(Though this is debated; it is true he worked at Princeton University in New York when Turing was a graduate student between 1936 and 1938 - Von Neumann even asking him to stay on as his assistant - to which he declined. What would the world have been like from such a partnership, had not WWII interceded?)

It is interesting to note that modern computer chips do not have what we think of as the basic instruction set - Assembler - hardcoded into the chip. Instead the Assembler instruction set is itself a simulation running on a far simpler 'micro code' instruction set that is hardcoded into the chip.

I think a better metaphor for computer software (which encompasses everything running on a computer, from the OS to what we think of as applications) is a series of of small boxes within larger boxes, which themselves are inside of a larger box. Some of the boxes may have more than one box inside of them (like the OS running multiple applications, for example). The largest 'lower level' boxes have the ability to serve as simulation 'stage' for the boxes that they contain. At the highest levels (the small boxes at the 'top' of the stack) they may or may not have facilities for doing further simulation (now-a-days it is more prevelant to see applications that have macros up to and including full-blown programming languages and interpreters for creating your own simulations within the instruction sets provided). The OS is simply one of the larger boxes near the bottom of the stack.

2. Sometimes the users are ourselves; this is why we see a plethora of noddy programs/simulations that don't do much usefull for larger audiences.

3. See the 'boxes-within-boxes' metaphor in number 1 above.

4. Not much more can be said. I will state my own philosophical view: I think it is more useful to programmers and to society as a whole to invent more flexible and open simulations that allow computers (and other less-general purposes devices) to communicate more seamlessly and make them a true and natural tool to augment our senses and intellect. It is not impossible -- we just have to dream it up and make it happen.

Operating Systems

Journal: OS Wars

Journal by Lodragandraoidh

I come bearing an olive branch. I stand astride the precipice seperating CLIs and GUIs, Linux and Windows, plain text versus proprietary file formats.

The questions I hear always revolve around the core principle that there is something universally 'right' or 'wrong' about operating systems - and that we can discern those qualities.

The reality is nowhere near this black and white paradigm. The truth is each one of us individually holds the key to that answer, and we are all correct!

Given the truth of that statement, isn't it silly for us to argue about any OS aspect without prefacing it with 'For me...'? For me, Linux is the best development workstation OS. For me, Windows is a toy that lets me play some of the more interesting games available.

For you, this might be different, but then again, who am I to tell you how to enjoy your CPU cycles?

User Journal

Journal: Moving the immovable object...

Journal by Lodragandraoidh

Un pobre guey (593801) pointed out the basic futility behind my sig in this article.

While not perfect, by any means, I did come up with some pretty good stuff - which I intend to massage into something more useful over time.


Life is about that [struggling for what is right against greed and stupidity]. However, our performance is rarely as consistent as our best intentions.

Conversely, the same thing can be expressed as:

Life will always be about furthering our greedy desires, despite our stupidity, at the expense of truth.

It all depends on where you mostly fall in the desire/righteousness continuum.

[commenting upon Un Pobre's suggestion that these ideals get 'crushed on a vast scale on a daily basis']

The key to not becoming disheartened is to pick your battles carefully. That way you aren't always getting squashed. Know when it is most useful to expose your hand, and when it is better to work quietly behind the scenes.

Overall, it is much better to gather 10,000 allies quietly over time, than to run out into sunlight alone and get squashed right away - unless you are into being a martyr. Patience and sacrifice = success. Sacrifice alone = death.

I do not advocate blind sacrifice. I do advocate struggling for what is right - but smartly, with your eyes open.


Journal: Banish 'Programmer' from your vocabulary...

Journal by Lodragandraoidh

Here is my advice to those of you looking for a steady job in the computer field (or trying to keep the one you've got):

Stop thinking of yourself as a 'Programmer' or a 'Coder', or a 'DBA' or whatever narrowly defined field you think you are in. From now on you are a 'System Integrator', 'System Developer', 'Computer Guru'. Stand up straight - stick out that chin - be proud of who you are.

Learn as much as you can about iterative/agile development - characterized by rapid prototyping, frequent incremental releases, and a really meaningful feedback loop with your customers and team members that addresses the three key questions: What did we do not so well this iteration? What did we do very well this iteration, and finally, what can we do to improve ourselves for the next iteration?

Avoid the strict waterfall method (where specifications are defined in detail - often taking many weeks or months - before implementation - during which specifications are frozen until final release. At which point the application is 'maintained' - usually by a different group than who developed it - and changes have to go through a review process - many months - and vye for IT resources with other projects; I have lived through these - and it is not pretty); build quickly to get something in the hands of the users so they can give you feedback and shape the design where it needs to go. With vendors and internal IT development teams it is sometimes an uphill battle to break them of old bad habits - but its a good fight that pays dividends in the end.

Learn portable tools First, then everything else Second. By this I mean don't specialize in .Net or Visual Basic before you learn Python, Perl, Java and C/C++(GCC). Be able to prototype quickly on whatever hardware and OS your customer may have available (don't tie yourself to a particular architecture/OS) with minimal setup on your part. Ideally, build a tool archive that has the things you need on it - ready to go with templates for standard functionality - this will impress your clients.

One suggestion for a client-server web enabled application toolkit (90% of my projects fall into this category) is to have a tar/zip file containing Zope with your favorite products (extension modules) installed - as well as example applications, and Python - for scripting, and rapid GUI development - again with modifiable examples of stock applications you have developed available for rapid prototyping. If you have internal customers - have a machine set up this way so you can do the prototyping quickly and get feedback as soon as possible.


Don't be afraid of change. Be flexible - and make your customers so happy - they come back to you for more quality tools. Figure out who your customers are and what they want - then give it to them without having to be asked - it is easier to beg forgiveness for something useful, than to get permission to build it before hand.

Keep your technical skills up; practice your craft by building small applications that exercise some aspect of a language you are not familiar with. Keep up on the development, system integration and various standards swirling around - be like Bruce Lee: take what works, and discard the rest. Don't waste your energy trying to master every fad. Know where all of the best 'wheels' are - and use them; don't reinvent the wheel if you don't have to. If all else fails - reinvent the wheel. Remember - the only true measurement is working tools; build many and often.

Finally, examine yourself. Are you the best Computer Guru/System Integrator you can be? Are you doing the right things to satisfy your customers? More importantly, are you satisfied with your job, or would you be happier in some other line of work (there are plenty of other unemployed IT workers ready and willing to step into your empty slot).

User Journal

Journal: 1010 Commandments

Journal by Lodragandraoidh

He traveled far and wide from coast to coast, and gathered warm clothing against the frigid blasts of the 15 ton airhandlers, and avoided the slings and arrows of 48 volt DC power supplies. And lo, he found inscribed upon a lowly cabinet in an empty corner of the data centre floor...

The 1010 Commandments:

0001: Thou shalt not covet thy neighbor's information.

0010: Thou shalt not hold any OS above the one true POSIX Compliant OS

0011: Thou shalt not worship graven languages, like Visual Basic, C#, or

0100: Thou shalt not spread pestulence, disease, or internet worms in

0101: Thou shalt keep the backup day and make it holy.

0110: Thou shalt regression test agressively, for this is the way to

0111: Thou shalt patch frequently, and tithe heavily for every bug that
            is found.

1000: Thou shalt not let marketroids and suits guide your projects; this
            is the path to perdition.

1001: Thou shalt share thy computer science knowledge freely with all
            those who grok; for all others: RTFM and FAQ.

1010: Thou shalt not use proprietary standards, in all its cloven forms;
            just as Eve was seduced by the fork tongued devil, so too will
            you be expelled from the raised floor of the data center for
            your transgressions.

User Journal

Journal: ATT begat USL; USL begat Novell; Novell begat Sco...

Journal by Lodragandraoidh

Sco begat Caldera; Caldera renamed Sco; Sco shat on Linux.

Somewhere in there USL begat BSD; BSD broke free.

Things continue to look dark. The totalitarian internet dictatorship enterprise (TIDE) is rising swiftly now. How long will it last? Will we survive it? What of our children? I remember, as a child, having fantasies of surviving a nuclear holocaust. I would pack all of my 'survival gear' into my backpack, food, extra clothes, gear (my trusty compass and swiss army knife), as well as books that I thought important to preserve ('Alas Babylon', 'Lucifer's Hammer' et al). Things never got quite as bad as my nuclear winter nightmares, and I have learned that we are never fully prepared for the increasingly unexpected happenings of adult life.

I keep telling myself that reality is always somewhere inbetween my worse nightmares and my best wishes. I hope that holds true. Hope is a rare commodity now. Perhaps we have to make the world the way that is right by being active - being that lone voice crying out against the screaming hurricane and the enveloping tapestry of night; maybe waiting will only plunge us into darkness faster...what will happen as we stand by and do nothing?

The first rule of Animal Farm: Don't talk about Animal Farm....

User Journal

Journal: GOOOOOOAL!!!

Journal by Lodragandraoidh

Back on dry land with a new gold tooth, and a healthy appreciation for the vagaries of wood...

Considering my troll, several funnys, and a handful of insightfuls later, and still no moderation points...I kick around the idea of becoming invisible electronically:

No more credit cards - chop them all up. No more ATM transactions; and cancel my direct deposit - cash and carry from this day forward. Select various facial artifices, prosthetic noses, cheekbones, change the color of my eyes and dye my hair in a rotating basis. Clothing to mask my gait. A cabin in the back woods away from prying video cameras. Inside of the cabin, a metal lined room with isolated power - a digital oasis with no contact with the outside world - just me and my perl scripts, happily beeping away...until that day when they finally come to see me - having missed my monthly diatribe mailed from the local trading post - to find my bloated corpse perched in my last resting place, green fuzz encrusted Funyons and empty bottles of Bicycle Ale encircling me like a wreath, a faded 'EFF' poster created with ASCII art leaning forlornly to one side upon the dingy wall above the monitor, holding steady at the soft white glow of a boot prompt.

Are we staring down the maw of the digital dark age? Are we entering an electronic 'Spanish Inquisition'? Does the all seeing eye rein supreme? More importantly, where is Hagbard, and what is he doing about it?

Real programmers don't write in BASIC. Actually, no programmers write in BASIC after reaching puberty.