Discussion on:

bITs and blogs

blog root

It's a dangerous thing to run a blog about one's IT career. It's the technically proficient who are most likely to read a website like this, and who are most likely to read a tech-related blog, and it's the technically proficient on whom I'm most likely to want to make a good impression as my career advances. Blogs are a good way to make bad impressions on people you've never even met. Blogs are self-conscious things. They assume an audience, and without that audience there's no point to them. Sure, you might think of the idea of a private journal or diary, but blogs are not that at all: they're very public things. If you're reading one that isn't your own, you'll find it difficult to justify such a thing on purely private grounds without lying to yourself in the process. As such, you should expect that every blog you read is written with its audience in mind. Things will always be censored to some degree, in some way, or will be made intentionally shocking for the "benefit" of the audience. You'll see a lot of passive-aggressive behavior in blogs, a lot of pity-seeking, a lot of trend-chasing and a lot of trend-resisting, and a lot of attempts to spread ideas and opinions to infect the minds of others. This blog is no exception. Keep that in mind whenever you read what I have to say about someone else here, and keep that in mind whenever you read anyone else's blog entries, too. Blogs can be great advertising. People link to things they want other people to see. Sometimes they use those links to advertise themselves by making their own blogs seem interesting by way of what they link. Sometimes they advertise things they support or other online endeavors of theirs by linking to them. Often, they do both at once. It's typical to see people throwing gratuitous links to things into their blogs to drive up traffic and to show how cool they are, and also to drive traffic to whatever it is they're linking. What that will sometimes translate to in TR blogs is links to businesses that TR members run or that employ them, in hopes of increasing business. I'll do that too, right now, just to get it out of the way. Here's one of my employers: Wikimedia Foundation Here's what you've probably already seen of the Wikimedia Foundation: Wikipedia As of this writing, I'm a thirtyish professional computer geek: I work both as a datacenter technician (for the above-linked nonprofit organization) and as an IT consultant (as an employee of a consultancy, mostly doing 1. web development and 2. unix/linux systems implementation and management). I'm an ethical theorist with very strong and well thought out political opinions, and that spills over into my analyses of IT industry trends quite a bit. I'm an INTJ, a "synthesist", the focus of whose strengths is apparently in qualitative analysis, according to the personality tests. I'm also "smart" and "lazy", according to Rommel's leadership metrics. Perhaps I should explain that: Field Marshal Erwin Rommel, despite taking orders from a bunch of murderous, genocidal Nazis (but I repeat myself), was a brilliant military commander in World War Two. He has made interesting statements about the desirable qualities of leaders, and if he wasn't hampered by basically insane superiors (Hitler, in short), he may well have won the Second World War for Germany. I'll just directly quote what he said about how he selected leaders within his command. "Men are basically smart or dumb and lazy or ambitious. The dumb and ambitious ones are dangerous and I get rid of them. The dumb and lazy ones I give mundane duties. The smart ambitious ones I put on my staff. The smart and lazy ones I make my commanders." Enough about me. What do you think of me? In case you're interested, you can look up Field Marshal Rommel at Wikipedia.

Good read in fact even as I am trying to move away from IT again, I know I will become more involved in the fall. So you just may keep my interest in IT alive.

As for looking up Erwin Johannes Eugen Rommel, I always thought you were a we bit younger that, but it is a good picture if it's recent.

And you're right in saying that he was a brilliant commander, I've seen several biographies and history recreations that accredit him well. There are a lot of things Germany did that were very clever, yet they are often looked at as being so inferior, I feel a great deal of that actually came later in the war when hitler had deteriorated mentally from his STD's.

Every so often a post comes along that represents a real paradigm shift. This is one such post. I never real thought about the impact of a "simple" blog turning on you from a career point of view. I'll have to watch what I write from now on...oh, man, I hope this doesn't sound too stupid..darn first impressions. Thanks for the terrific post!

I think it took alot of guts to be the first one to take the step into blogging on TR. After all, you are putting a more personal side of you out for all to see; it makes you very vulnerable. Its different than posting to the TR forum because that only shows your view on that particular subject.

I'm not sure what to think of blogging yet as a medium. Its a great advertising technique I have to agree and it also offers anyone anywhere their 15 minutes of fame. I've been looking at alot of blogs lately because I'm working on one for work and the sad thing is that many of them have no comments to their daily posts. They all work so hard too. I still don't think that makes them useless though. Its actually a good outlet for the person involved and it does give you a web presence all your own. A blog is truly a modern day diary about what you thought about on that day.

The Desert Fox is an interesting choice to mention. You must be a history buff. You have also compared yourself to the smart and lazy ones that became commanders. Thats good. I don't think I'd say I was one of the dumb and lazy ones ever in my blog; though I don't know, smartness doesn't guarantee popularity.

Ok, tell me, what is an INTJ?

OK American Voter, apparently you didn't follow the links to the Jungian paradigm of the human spirit and you've never done a Myers-Briggs personality profile. None of this will make sense to a Freudian, much less to someone who isn't interested in psychology as a way of studying the human spirit. So here's the decoding of INTJ, made as short as possible.

I: introverted, not extroverted. Jungian use of the terms, basically an extrovert is slowly energized by dealing with ANY other people whereas an introvert is slowly drained.

N: guided by intuition, not senses.

T: processes using thoughts, not feelings.

J: trusts judgment, not perception.

Any three of these vectors occurring together are the obvious formula for the anti-"people person." A geek, someone who lives internally and keeps his own counsel. All four of them together are the classic IT professional, "Give me a computer any day, I'll never understand people."

I was a textbook INTJ, with four strong vectors, the first time I took this test about 25 years ago. Over the years I've mellowed. Now my N and J are less strong, and I'm right on the borders between I and E and between J and P.

There's hope for geeks.

BTW Joseph Campbell was a magnificent popularizer of Jung's work. He worked heavily with "archetypes," images that occur in our "collective unconscious," e.g. in nearly all cultures and eras. You can transpose a discussion in Jungian jargon into one involving Greek gods or Shakespeare's characters to make it more accessible.

The concept of the archetype itself is wonderfully accessible. To a pragmatist it's a preprogrammed synapse that happens to be included in our brains because sometimes nature is random. To an evolutionary biologist it's an instinct that at one time was a survival trait so the individuals who had it were around to pass down their genes. To a spiritualist it's a legend that was breathed into us by the Goddess on our way down the birth canal.

Actually, DC_GUY, I didn't see any links to explain INTJ in the post. I have never taken a Myers-Briggs test though I do know what they are about. Many years ago I worked in a contract position for an outplacement agency for executives. They relied heavily on those tests for placement purposes.

Thanks for your explanation, it was very in a nutshell. I'm glad to hear that you've mellowed over the years. I think you should rephrase that and say you've grown. Geeks today have to have it all.

Well. Oz_Media has created a wanted poster inspired by my own subtly personalized TechRepublic user icon. I might as well commemorate and chronicle the occasion here, as my first non-introductory TRB post. Here 'tis: Wanted: Apotheon Feel free to have a good chuckle. I know I did. Oz_Media has passed copyright for the image to me (TR logo included under fair use), and I hereby provide it to the public under terms of CCD CopyWrite with fair use restrictions in place as regards the TR logo.

So this person named Kat said something about Godzilla, and that inspired this post. She wants everyone to "know" that this was all her idea. Yeah, right. _______ vs. _______ That's right, folks, Tokyo is in trouble again. An epic battle between titanic monsters looms, and untold destruction will result. It's Mozilla Versus Microsoftra! Sadly, that's all I've got. I'm lacking in originality right now. I rather imagine a big red dinosaur stepping on some pathetic little multicolored butterfly/moth thing, then going on about its day like nothing happened. Could be fun. As I was composing this, doing searches for icons and so on, I did make the k3wlest monster noises, though. You really missed out on quite a show here. The other four people here (one of them about two years old), on the other hand, were much amused. Well, maybe frightened. It's hard to say. Roar.

The Washington State House and Senate passed Engrossed Substitute House Bill 1012. This means that spyware is now illegal in the great State of Washington, home of Microsoft (in Redmond, Washington). In fact, Microsoft helped support the passage of the bill, along with eBay. Does anyone else here see the irony of this? Here's Microsoft, purveyor of some of the worst spyware on the planet (especially by the broad standards of Bill 1012 ), supporting the passage of a law in its own home state that will effectively make a criminal organization of it. Consider what you know of Microsft's planned "Black Box" functionality for Longhorn, its inclusion of spyware-riddled software such as MSN Messenger and Windows Media Player in Windows already, and its recent use of Windows Update functionality to remove competing products from end-users' computers. Now read this description of what is defined as "spyware" according to the new Washington law: software that opens "multiple, sequential, stand-alone advertisements in the owner or operator's internet browser", logs keystrokes, takes over control of the computer, modifies its security settings, falsely represents "that computer software has been disabled", or prevents "through intentionally deceptive means, an owner or operator's reasonable efforts to block the installation or execution of, or to disable, computer software by causing the software that the owner or operator has properly removed or disabled automatically to reinstall or reactivate on the computer". The only question now is whether the EFF and ACLU will get together and sue the crap out of Microsoft as they should. One can only hope.

I'm not much of a fan of MMORPGs. They just seem like a tremendous waste of time to me. They're misnamed: they should be called MMOAGs, or something, for "Adventure" rather than "Roleplaying". Computer roleplaying games of any kind are just roleplaying games without the roleplaying.

To understand my perspective, maybe it would help to understand that I started playing real, pencil-and-paper RPGs in the early-to-mid-eighties. I know what "roleplaying" really means in the abbreviation RPG. There is a lot missing from computer "RPG"s of any kind that we just don't have the technology to recreate from "real" RPGs using computers, yet. What's missing is what makes an RPG into an RPG rather than a "Choose Your Own Adventure" book.

I know some people that play MMORPGs. That's fine. To each their own. I'm not actually offended by MMORPGs, or other computer RPGs, at all. I just find them to be silly, pointless, and wastes of time. I have hobbies that are silly, pointless, and wastes of time too, probably.

Maybe. Well, maybe not, but I don't necessarily see such hobbies as being "bad". The fact that I'm very, very good at constructing arguments and recognizing spin on neutral facts makes it easy for me to chide friends for playing MMORPGs, though, so I do. It's fun. I guess that's one of my silly, pointless hobbies that wastes time. That's okay. They do the same to me about some of my own hobbies. I cheerfully accept chiding for being such a Linux geek. Such is life. Recently, though, I found myself singing entirely the wrong lyrics to the tune of Black Sabbath's "War Pigs". I'll post them here for your enjoyment. The following is released under CCD CopyWrite , just like everything else in this blog.

Dorks are gathered in their masses
Just like methods in their classes
Newbies desperate for instruction
In skills of character construction
Ships and victims bleeding, burning
Worlds of Warcraft keep on turning
City of Heroes wasting time
Poisoning their brainwashed minds
Jolt Cola!

Computer game geek hide away
From the burning light of day
Why go out and get real jobs?
They leave that to dads and moms

Time slips by, more power-ups
Adding gemstones to their hoards
Collecting golden coins and cups
Playing GUI games without boards
Save!

The world outside could just stop turning
I'd never know my house was burning
Now the MMORPGs have the power
Evercrack has stolen hours
I'm selling characters to newbies
And buying magic swords and XPs
The swivel chair I'm sitting in
Is adhering to my skin
/pizza!

I've been sorta kicking around
inside my own head over the subject of comments in the TR blogs. I'm
used to threaded comments for blogs, where you can reply to a comment
with a comment of your own directly, rather than your comment simply
being tacked onto the end of the list of "root" level comments as it is
here at TR.

I've been thinking about the advantages and
disadvantages of a threaded comments approach, and I've realized that
it's nice, for a chance, to have a blog that does not have that
feature. For one thing, it reduces the conversational tone of the blog
to a certain extent, which changes the entire character of the blog.
This way, it's more geared toward article-like blog posts and comments
directed at the blog's author, rather than becoming sort of a social
circle centered around that author. In short, it's a little more
"professional" this way.

I'll be taking advantage of this
situation as an excuse to order my blog in a particular, probably
abnormal, manner: I won't post comments in it, ever. If I have
something important enough to say that is inspired by a comment, it
will be said in a blog article. This should help cut down on the level
of fluff, among other benefits, and will probably cut down on flame
wars as well, since the ability to answer back in anger will be
severely curtailed (in part by my nonparticipation, and in part by the
lack of threading in comments).

As for the frequency of posts,
it will certainly come in crests and troughs, with multiple posts over
a day or two and several days of silence. I'll post when I feel like
it, and when I have something interesting to say. I won't post random
crap just to ensure a steady flow of words. When you read something
here, it'll be because I thought what I posted was worth saying,
whether or not it's worth reading.

I'll likely post at minimum
once a week, at least for a while, though my online activity level in
any given forum rises and falls in irregular cycles, generally. It's
not like I'm getting paid for this, after all.

As TR member AmericanVoter reminded me in a comment to a previous post, not everyone in the world knows about the Jung Typology and the derived MBTI personality tests.

Famed psychologist Carl Jung developed a theory of psychology types, known generally as Jung Typology. This begins with some general statements about how people's personalities can be described by classifying them according to categories of psychological characteristics. For instance, most of the rambling that goes on in common parlance about "introverts" and "extroverts" arises from Jung's uses of the terms, though most people misuse them terribly. Also important in Jung Typology are four modes of experience that bear the labels Thought, Feeling, Sensation, and Intuition. These have been grouped in opposed pairs, where Thought and Feeling are opposite sides of one coin, and where Sensation and Intuition are opposite sides of another. To these three (including Introversion/Extroversion) was another pairing added, consisting of Judging and Perceiving.

These four opposed pairs are assembled into a letter-code personality classification that makes up the basis of the Myers-Briggs Type Indicator, which is in turn used as the set of metrics on which many personality tests are designed. I've taken a few, and I tend to vary somewhat between two results: I'm always either an INTJ or an INTP, depending on the test and, I imagine, my mood and current personality traits. I score INTJ rather more often than INTP, and as such tend to occasionally refer to myself as an INTj, indicating a less strong attachment to the J than the other three letters in that label.

If you've been paying attention, you might by now have guessed that INTJ means I'm Introverted, Intuitive, Thinking, and Judging, primarily (though the Judging might by some measures and at some times actually be replaced by Perceiving). The INT personality types are the analytical types, and among INTs the J-types are more the qualitative variety and P-types are more the quantitative variety. In other words, INTJs are big on analyzing for value, and INTPs are big on analyzing for details. I do quite a bit of each, but for me the details of a thing are (usually) primarily useful as a means to the end, that being evaluation.

Being an INTJ suits me well as a consultant. So, too, would INTP. While INTP is probably best suited to technology implementation once all the major decisions are made, INTJ is probably best suited to making those decisions, and in advising others on the making of such decisions. In addition to having the personality type suited to that kind of work, I'm also rather intelligent. No false modesty here: I know my limitations, and to some degree I also know my strengths, and don't feel like pretending they don't exist for humility's sake.

INTs tend to make the best programmers, and Js and Ps each have their own strengths within that. They're synthesists, good at taking a series of preexisting parts and assembling them into something new and useful. They're not, however, usually the best salesmen, and that failing is one that I suffer quite notably. This is one reason I work better for a consultancy than as a consultant on my own: I'm no extrovert, which is where real sales talent lies. I rather suspect that the best salesmen are ENTJs, and that the best chairmen of the board are ENTPs, but don't quote me on that (without including disclaimers that it's just wild speculation on my part).

There is some speculation about the actual validity of the MBTI tests, including the official MBTI test whose trademark is owned by a trust that exists for that purpose, if I'm not mistaken. There are a great many copy-cat tests out there, however, which seem to be able to get away with it by virtue of the fact that the MBTI itself is derived from the theories of Carl Jung. These copycat tests are of varying worth, and when I say that I've taken many MBTI-based tests, I don't know how many were copycats and how many were officially sanctioned derivatives of the MBTI itself (though I know that at least one was just a copycat, and am not at all sure that any were "official" MBTI tests).

Here's an MBTI-like test for you:

Human Metrics Jung Typology Test

Thanks for the test. I used to be an INTP, but now I am an INTJ. 
An intersting switch I'd say.  While I don't think the INT will
change, I am surprised by the switch from P to J.  I would guess
it is because I've become far more cynical and jaded than I was 10
years ago when I first took the test

Thanks!

Wipro is a technology consulting
firm that benefits from a "strategic alliance" with Microsoft,
including "building financial models and ROI calculators for Microsoft
product deployments" and "co-product development and engineering of
Microsoft products". They're about as deeply enmeshed with Microsoft as
a company can be without actually being owned outright. Wipro is even
engaged in "managing call center operations for Microsoft product
support" and ".NET evangelism with focus on enterprise and mobility
applications". In other words, Wipro's business model is tightly tied
to developing, maintaining, and marketing Microsoft product lines and
services. This is anything but independent. For more detail, check out
the Wipro Technologies website: Wipro ? Microsoft: a strategic relationship

Recently,
Microsoft commissioned a study of patch management costs, comparing
Windows platform patch management with open source platform patch
management. Considering the above explanation of the relationship of
Wipro to Microsoft, and the fact that Microsoft commissioned the study
and reported the results, I suspect you can guess whether or not the
study favored open source software for patch management costs. Once
again, a Microsoft-commissioned study performed by a company that is
little more than a Microsoft lackey shows Microsoft undercutting the
cost of software that can be had for free. Go figure.

The study
results, in a little more detail, indicated that the patching costs
were very competitive between the Microsoft platform and the open
source software platform. It was admitted in the study that Microsoft
systems required more patching, but this is supposedly balanced by the
fact that the per-unit cost of patching for Microsoft systems was
lower. Of course, it's also claimed that patching is easier for Windows
systems ? a subjective, qualitative statement that cannot really be
statistically demonstrated in a study, and can thus be safely spouted
without worrying about the facts disproving the claim. When pinned down
on such issues, of course, Microsofties will always fall back on the
old "Windows GUIs are better!" argument. In my own experience, a simple
shell or Perl script handling sorting and distribution of apt patching
on Debian systems (for example) is about as easy as it can possibly get.

This
study, of course, actually compared corporations that use third-party
patch management software for organization and distribution of software
patches. These third-party solutions cost money to use, of course.
Interestingly, the per-unit per-patch cost that showed Microsoft's
stuff being cheaper used the same back-ends as the open source
software. Why is the per-patch per-unit cost lower? Simple: more
Windows systems were required for performing to similar standards.
Since the back-end cost was for the network, and not for the individual
units, where Windows systems require more computers in place the
per-unit cost involves a smaller division of the total cost over the
larger number of units, leading to a lower "per-unit" component of the
cost. Add to that the fact that patches are more numerous for Windows
systems than for Linux systems, and the "per-patch" component of your
cost is lower as well, because of similar division of cost between
instances. Considering that the per-patch cost division occurs on each
individual unit, that means that your total manipulation of cost
figures to produce "per-patch per-unit" costs involves dividing the
total cost by a number reached by multiplying the number of units by
the number of patches. Thus, the total cost of your solution is likely
more because of greater labor overhead (longer hours spent in
patch-management), but since that total cost for your network is
divided into such small numbers when divided by number of patches and
number of units, your per-patch per-unit cost can be significantly
lower. Thus, cleverly massaged statistics prove the sky is orange.

This would be why such
Microsoft-sponsored studies always examine per-unit costs for
distributed bulk services: multi-unit
services that only cost once can be whittled down when you split them
up over a larger number of systems, since a larger number is often
needed to achieve the same end results. Go figure. This turns the
real-world increase in financial and management resource expenditure
for a full-network solution into a decrease in resource expenditure for
each individual unit. So much the better for your study results if you
have to perform the same tasks over and over again, allowing a decrease
in expenditure for each iteration, though the total cost climbs.

Ultimately, none of this is all that
relevant to real-world costs. Real-world costs for actual patch
management and deployment are almost nothing for a knowledgeable
admin, regardless of the platform. What costs money and man-hours is
pre-deployment patch testing and post-deployment rollbacks and recovery
when patching goes awry ? and, of course, downtime from both
patch-related complications and the patching procedure itself. These
are, to the people who run these studies on the Microsoft paycheck,
irrelevant ephemera, but for those of us in the IT trenches they are
the meat and potatoes of the almighty TCO (total cost of ownership) and
administrative overhead (how much work and stress is involved in being
a system or network administrator).

Microsoft's track record in
post-deployment complications for new patches is legendary, and not
positive. The fact that most statistical analyses of system failures
during XP Service Pack 2 deployments performed by IT professionals were
in the range of 10-15% is just astounding. This sort of astronomically
high system failure rate after a patch purported to increase system
security and stability is simply unacceptable for most production
environments, and drives post-deployment recovery costs through the
roof for many administrators. Smart admins see a resulting increase in
pre-deployment patch testing because it simply becomes that much more
critical that patches are fully tested for potential problems before
deployment.

Then, of course, there's the matter of planned
downtime. Unplanned downtime is of course an incredible, and often
disastrous, addition to total cost of ownership for a given platform.
Planned downtime doesn't compare in terms of cost increases in most
environments. There's still an associated cost, though: even if
business isn't damaged overtly by planned downtime on the revenue side,
downtime of any kind tend to involve increased costs where such
concerns as the salaries of admins and contractors are concerned.

Almost
every single important patch applied to a Windows system requires a
system restart. The only time a system restart is required for a unix
system (such as Linux) patch is applied is when it's a kernel patch.
One of the major reasons for this is the system configuration scheme of
Windows, where all services are configured through a single flat-file
database. This is, to say the least, suboptimal for system uptime.

Time for some anecdotal evidence:

I've
never, in all my work as a consultant, had to recover from a Linux
system patch. Not once. All Linux system patches and upgrades worked
flawlessly for me. On the other hand, I literally paid my bills for a
while on Windows patch recovery when clients started applying SP2 to
their Windows XP systems. Linux systems used by the same clients hummed
along, undisturbed.

While I didn't service the Server 2003
systems that developed major problems with the deployment of SP1, I
know that similarly impressive spikes in the consultancy's revenue
stream occurred with that patch as well.

On top of all that, I'm
still waiting to hear about a number of patches for things that have
been languishing on Microsoft's back burner for far too long. I haven't
heard of a needed patch for the Linux systems I support that has yet
taken more than a few days to appear after the need was discovered. I
can only thank my lucky stars that my duties with the consultancy are
moving more and more into Linux and web development, and farther from
Windows system support. The stress levels have dropped considerably. I
get to design and implement, and spend less time fixing.

With
all of that in mind, and casting a scornful glance back at the
chicanery of Microsoft and Wipro Technologies, I have to ask:



Is anyone buying this?

I'm going to do Something Different here. I'm going to try to be
informative. I'll probably be mostly informative about stuff relating
to Linux in some way. Since a lot of people, even among IT
professionals, don't know a lot of the fundamentals that comprise a
good basis for understanding Linux-related stuff, I figure I should
probably start with some of those fundamentals. See how helpful I am?

First off, Linux is unix, but not UNIX, or even Unix. At least,
that's how I refer to the various states of unix-compatibility. See,
UNIX is a trademark that is assigned to a unix when it passes certain
qualifications and when someone pays for the privilege of using the
UNIX name; Unix is basically a non-term that I usually don't use, but
when I do differentiate between Unix and either UNIX or unix, what I
mean is that Unix has certain characteristics relating to a family of
related OSes that are all descended from the same ancestor, and contain
(some of) the same code as that ancestor, but isn't necessarily UNIX
because nobody bothered to get it certified. The various *BSD unices
(that's plural for unix) qualify as Unix by this standard, because
almost every single unix in existence has a core of *BSD-based code in
it. Even the original UNIX line, developed initially at Bell Labs,
contains a lot of *BSD code because *BSD code is open source but not
copyleft, meaning that anyone can see the source code but it can be
incorporated in closed-source software without any legal issues. I'll
address the various terms of software licensing in a moment, but first
I'll finally mention what makes an OS qualify as unix.

Linux (pronounced "linn-ucks" or "leen-ooks") is a unix. It is not,
however, a Unix or a UNIX. It contains original code unrelated to the
core *BSD code, and though I'm pretty sure it would qualify, nobody has
ever gotten it certified as UNIX. It is a unix, however, because it
looks like a duck, quacks like a duck, and even smells like a duck. It
conforms to POSIX standards, it does everything UNIX and/or Unix does
that makes them unices as well, and it is very nearly indistinguishable
from other unices to the casual user. Linux was created entirely from
scratch, programmatically, and was basically created by observing the
behavior of other unices and figuring out how to write code that will
do the same stuff.

Linux and *BSD are both "open source" OS families. Such proprietary
unices as SysV, Solaris, AIX, HP-UX, and so on, are not. Linux is
"copyleft", whereas *BSD is not. Here's why:

Linux is licensed under the GPL (General Public License). The
General Public License requires that when distributing binaries
(compiled, executable programs), you have to provide the source code as
well. It requires that you do not restrict others from further
distributing and modifying that code. It also requires that later
modifications and distributions of that code are released under the GPL
as well.

The various *BSD kernels are licensed under the BSD license (thus
the name). This includes FreeBSD, OpenBSD, and NetBSD, among other
(less well-known) BSD OSes. The BSD license allows you to redistribute
both binaries and source code as you see fit. It also requires that you
do not restrict others from further distributing and modifying that
code. It does not require distribution of source code, though it does
(as already noted) allow it. It does not require that later
modifications and distributions of that code are released under the BSD
license, either.

Software such as the proprietary UNIXes and Microsoft Windows are
released under standard copyright, as modified by EULAs (End User
License Agreements). Copyrighted software that is not released under
other licenses is restricted from being copied or distributed in any
form at all except in accordance with "fair use" provisions, which
pretty much state that if it's useless to you without duplicating it
you're allowed to duplicate it, but only for purposes of such use.
Other than that, everything's restricted, by and large.

Before I touch on one more licensing scheme, I'll explain how the
various open source buzzwords fit into all this. First, there's
"copyleft": if an open source license is "copyleft", that means that it
is automatically inherited by derivative works and copies. This means
that if you modify and redistribute something issued under a copyleft
license, that modified version is also distributed under the same
copyleft license.

The term "open source" refers to software for which the source code
is open for viewing, modifiable, and redistributable. A similarly
applied term, "free software", refers to source code wherein it is
required that the source code be made available to anyone that has
access to the binaries. There's another, far less used term, that
refers to software that is all about allowing you things without
requiring anything: it allows distribution and modification of binaries
and source code without requiring it, in essence. This term is
"software libre". There's some dispute over what these terms actually
mean, but the general consensus and understanding of the terms seems to
be precisely what I've relayed here. Both "software libre" and "free
software" are "open source software", but "software libre" is not "free
software", and "free software" is not "software libre".

The GPL is a free software license, an open source software license,
and it is copyleft. The BSD license is a software libre license,
an open source license, and not copyleft. The CCD CopyWrite is a
software libre license, an open source license, and it is
copyleft.

CCD CopyWrite is a license I created specifically because I saw the
need for a true software libre license that was also copyleft. In
essence, "software libre" is the state of licensing that replicates the
conditions of the public domain (absent outside influences). You can do
anything you like with your libre licensed software, and so can anyone
to whom you give it: there are no legal restrictions on modification
and distribution of the content. Only laws relating to tangential
matters apply to software libre, such as laws relating to fraud (no
lying about the performance or attribution characteristics of a piece
of software). By creating a copyleft libre license, I've set aside a
"protected public domain", wherein licensed works can be treated as
though they are within the public domain, but unlike the actual status
of public domain works they cannot be re-copyrighted and "removed" from
the public domain after modification to produce a derivative work.

There you have it. I've made some generalized statements about what
UNIX, Unix, and unix are, how Linux and *BSD fit the picture, what the
various open source software categorization buzzwords are, and some
licensing examples to fit the different categories.

Note 1: Despite spurious claims to the contrary, no Windows was
ever really POSIX compliant. Some components of the Windows NT system
have, in various versions, been POSIX compliant to one degree or
another, but it has never been a POSIX compliant OS. NTFS was at one
time POSIX compliant: whether or not it still is compliant is something
of which I'm not really sure. NTFS has undergone so many changes over
the years that it's almost unrecognizable as being related to the
filesystem that originally bore that name.

Note 2: I stated that Unixes come from a common ancestor. I did not
identify that ancestor, though I hinted at both AT&T UNIX and BSD
Unix. I made reference to BSD code in UNIXes, but did not specify how
much of the OS is traceable to BSD. This was intentional. While the
facts I've related are essentially indisputable, the opinions that can
be derived from those facts are often in reasonable dispute. Since
my purpose here isn't to address that dispute, I avoided it.


UNIX
Linux
*BSD
GNU General Public License
BSD License
CCD CopyWrite license

There's a term being bandied about in the media, and being used
improperly, with dismaying regularity. This term is one that relates to
IT professionals and enthusiasts and their shared culture. It is a term
that helps to set us apart from the rest of the world's population by
our appreciation of a certain ethic, a certain aesthetic, and a certain
metasociety that cannot be understood without exposure to, and (perhaps
more importantly) enjoyment of, the computer geek's world.

The term I'm talking about, of course, is "hacker". In the news
media, in the press releases of corporations like Microsoft, and in
mainstream cinema, the term "hacker" is divested of its real meaning
and granted instead only the sinister characteristics of the computer
criminal. This has, I think, come to pass because those outside of
hacker culture probably never bother to notice any hacking going on
around them unless it affects them directly and, once in a while, that
hacking might consist of someone testing and even penetrating the
security of computers and computer networks. To assign the term
"hacking" only to such activities, though, is the same as assigning the
term "pilot" only to terrorists who fly jumbo jets into skyscrapers,
"golfer" only to those who cheat at the game of golf, "driver" only to
those who drive while intoxicated and end up killing pedestrians, or
"parent" only to those who molest their children.

It's worse than that, actually. Not all child molesters are parents,
not all killers are drivers, not all cheaters are golfers, not all
terrorists are pilots, and not all who crack security on computers and
computer networks are hackers. Many, in fact, are script kiddies whose
closest brush with actual hackers is using a network security auditing
script some hacker wrote eight years ago. Remember that little problem
with Newsweek inaccurately reporting the contents of an FBI memo,
sparking a riot that killed 16 people? They're just as wrong, and far
more often, in the way they report computer crime.

The term "hacker" is used at times to refer to people outside of
computer system enthusiasts, and that's fine. I've yet to see a
non-computer-person misuse the term when referring to what they do.
I've even seen people refer to themselves as hackers of "reality",
meaning of course that they're screwing with the common perceptions of
the dominant paradigm. Good for them. Let's comfort the disturbed and
disturb the comfortable, and call ourselves saints and hackers for
having done so. It's pretty difficult to find any true hacker culture
outside of enthusiastic computer users, though.

The term arose with the tech model railroad club (TMRC) at MIT in
the 1960s, particularly amongst a group of members of the club who were
also involved in the goings-on of the MIT AI (artificial intelligence)
lab. From there, it began to be applied to other computing enthusiasts
unrelated to TMRC, and a vast culture of hacking arose, including its
own jargon, ethics, value system, and worldviews. As RFC 1392 ,
the Internet Users' Glossary, defines it, a hacker is "A person who
delights in having an intimate understanding of the internal workings
of a system, computers and computer networks in particular. The term is
often misused in a pejorative context, where 'cracker' would be the
correct term." There's also a reference to the term "cracker" in RFC
1392, not to be confused with the racist insult usage of the term, nor
with that usage of the term that denotes a snack food.

Early hacker history is loaded with the stories of giants who walked
the earth. Somewhere in the middle, there was a distinct paradigm shift
coinciding with the move from OSes and computers that were wedded to
each other to unix, the first really modular, portable separation of
the OS from the hardware ? or, at least, the first one that really
caught on. This can be blamed, of course, on the concurrent creation,
or synchrogenesis (to coin a term), of the C programming
language and the Unix operating system. While the Internet was already
underway before unix began to play a substantial role in it, it was
unix that gave it the first major push toward being a public
environment. The various unices have been the primary OS of choice for
hackers in general ever since. There are those few true hackers that
simply don't use the unix environment, of course, but they are an
exceedingly rare breed. Most people that work with computers outside of
the realm of unix are professionals or end-users without the real
essence of the hacker, or are strictly hardware hackers, a strange
breed indeed. Even those hackers that have created their own OSes along
the way generally came from unix and eventually came back to it, too.

In the late '70s and early '80s, the growth of the PC industry began
to see the independent and convergent evolution of a new class of
computer users. They weren't a culture, yet, though. They had terribly
underpowered little "toys" that didn't even have the ability to
effectively communicate with each other over the Internet. This is one
reason many people don't realize just how old the Internet is: if they
know anything about the history of computer networking with PCs, they
probably think back to the bad ol' days of dial-in BBSes before PCs
could touch the Internet. It was the ISPs like Prodigy and AOL that
ultimately brought the Internet to the masses (thank goodness we've
moved on to better options now), by giving PCs something to dial into
that would then connect them to all the wide world of the Internet, and
it was the web browser and email that made it something worth doing.
Then, in the early '90s, just before the release of Windows 3.11,
hacker culture met the scattered PC enthusiasts, and that convergent
evolution finally came to its merging point. Linux and BSD for the 386
were created, almost simultaneously. Both were made open source, as
well, which suited the hacker ethic perfectly. The hacker's home OS was
born, and it was twins.

Generally, one does not decide to become a hacker and pursue any set
of required tasks to get there. It's not a profession with certifying
authorities, though there is a certain amount of semi-official
recognition that cements one's place in the culture. It's not a skill
set that one acquires at school or on the job, though one is never a
hacker without skill. It's not an attitude, though without the right
attitude all you'll ever be is a programmer, or a script kiddie, or a
network administrator, or an end user, or a wannabe, or perhaps worst
of all a suit . Hacker culture is something of a meritocracy,
but mere ability isn't everything: there's also the ethic and the
aesthetic sense, for instance. It's all something you can't just study
and understand. You have to grok it.

That's not to say that hackers never disagree. They not only
disagree, but can do so very noisily, obstinately, at great length.
They even disagree regularly on subjects as fundamental as what exactly
it is to be a hacker. Find two hackers and ask them what being a hacker
means: if they don't just quote RFC 1392 or the Jargon File at you,
you'll get two different answers. You might even get three. Put them in
a room together, and they may argue it to death, and they may both end
up with different opinions than those they had when they started, but
they'll still probably disagree on some fundamental points. If both are
real hackers, though, they'll surely recognize each other as such by
the time a truce has been called and the dust has settled.

For my part, I've been called a hacker by several people who know
what the term really means, independently and without prompting. These
are people who recognize that I have some skill, and that I grok the
hacker life ? and I really do understand it on that visceral level.
It's commonly accepted (if usually unspoken) tradition in hacker culture that it's better to
be identified as a hacker by someone else, someone that knows what he
or she is talking about, and among my credentials is recognition by a
bona fide rocket scientist who's been as much a real hacker as anyone
I've met for longer than I've known there was such a thing as Linux
(and she has been using Slackware since version 1.x). Guess what: I
dispute their claims. I'm not sure I qualify. It's that pesky skill
thing, you see. I have the enthusiasm and the interest and all the rest
of it, but somehow I've just never really gotten immersed enough in
certain key activities (programming, foremost among them) to develop
more skill than that of a dabbler in hacking. I mean, really, there's
an assumption in the term "hacker" that, to be one, you have to "hack".
I've had some close brushes with activities that carry that name, and
I'm even the recent founder of a very small hacking club, of sorts, but
as for real experience in hackish activity ? well, it's a little sparse.

Some of these people who have thusly granted me title certainly know
more than I do about the matter. Perhaps I should defer to wiser heads
than mine. I know I don't want to be the wannabe that self-identifies
without proper justification, though. I'm not comfortable accepting
that apellation at this time. I may never be.

I know I get annoyed when some idiot reporter or Microsoft marketing
executive uses the term to describe something lower than the scum on
the soles of my 14-hole Doc Marten boots, though.

You know you're a real hacker if you don't want to be called one. Anyone claiming to be a hacker is a script kiddie with delusions of grandeur.

I've seen him, and probably even exchanged words with him, a couple
of times before last night. I just never realized who he was until
conversation over a table at Denny's.

Paul Kunz is
awesome. The first webserver to be set up outside of Europe was his
fault, at the Stanford Linear Accelerator Center where he spent much of
his time in 1991. He came back from meeting with Tim Berners-Lee of
CERN, the creator of the World Wide Web, and along with a couple of
colleagues got North America into the Web for the first time.

I'm an avid user of Linux. I use Debian GNU/Linux whenever I can get
away with doing so. When I have to use another distro (or, heaven
forfend, Windows) for work-related activities, I simply have less fun.
Debian makes me feel good. It's not just Debian, though: my favored
computing environment uses the GNUstep framework with the WindowMaker
window manager. It turns out that Paul Kunz was the guy that kicked off
the GNUstep project in the early '90s, too.

Last night, we sorta introduced ourselves to each other and
conversed, along with about a dozen other Linux enthusiasts at a LUG
meeting in Denny's. I couldn't believe my luck when I relized who he is
and what he's done. I even put together sort of a programming
enthusiasts' study group a few weeks ago in part so that I'd have an excuse to work
with others on learning Objective-C, the programming language in which
GNUstep is primarily implemented. Yes, I like GNUstep that much.

These days, I make more money doing web programming than anything
else. I'm using technologies that this man pioneered on this continent
about a decade and a half ago.

I guess, in a way, he's sort of a hero of mine. I certainly admire the man.

. . . and last night, I met him. He's a nice guy, very personable. I
wonder what his reaction will be when he finds out I started a
Wikipedia article about him.

Here it is, Friday morning. Every Thursday evening now, I attend T3H
meetings. I get together with some friends that have some similar
interests, and we . . . learn stuff. It is, so far, sort of a
programming study group, with the primary goal of helping its members
learn stuff. I put it together in the first place (yes, I'm the person
who organized it) from members of a local LUG as an excuse to create an
environment where I wasn't learning new programming skills alone and in
a vacuum. I wanted more people to play off of, in person, where we'd be
there specifically to help each other with new concepts and new
implementations.

It all started with Objective-C, but as of last night that has
changed. The group member who knows the most about the language was
running into a wall, in part because of a lack of the necessary skills
to be leading the charge alone and in part because he doesn't actually
know the syntax of the language well enough to be teaching it. As such,
the whole group hashed out the needs, wants, and skills of the group as
a whole. From this, we developed a new, more useful plan for the future.

This, of course, perfectly suits one of the first rules of good
software design: plan to throw the first one away, for any given value
of "one".

So, Objective-C is on the back burner (for those of us who plan to
ever revisit it). We're going in new directions. The new directions, in
this case, number three, with three different languages that we'll be
studying as a group, simultaneously.

Basically, we're going to be attacking essential concepts of
programming, in each case first in theory (by discussing the concepts),
then in usage and implementation (by discussing how they're used and,
possibly, by working up pseudocode), and finally in practice (by using
the three example languages we've chosen to give these concepts useful
form). Yes, three languages.

See, there are three different basic types of languages that we have
decided we need to learn in order to get the full run of important
theories of program design. Each of us knows at least one programming
language (and by "programming language", I mean "turing complete
language", and by "knows", I mean "has at least a functional familiarity with"), and the number of languages known with any real facility
varies between us from "one" to "half a dozen or more", but nobody has
as complete a knowledge of all three of these types of programming
language methodologies as we'd like. The three types are procedural,
functional, and object-oriented*.

The representatives of each language type are C for procedural
programming, Scheme for functional programming, and Ruby for
object-oriented programming. In addition to procedural, functional, and
object-oriented programming methodologies, however, these languages
also represent a second trinity, this time of programming aesthetics,
though this aspect of the reasons to choose the languages went largely
unremarked: the "shiny new thing", the "obscure, eccentric genius", and
the "venerable workhorse".

In Ruby, everything is an object; it is a "true", or "pure",
object-oriented language. It's the useful scripting language child of
Smalltalk and Perl, in essence. It has a reputation for power,
flexibility, rapid development, intuitive ease of learning and use, and
a whole bunch of other wonderful (if improbable, by some measures)
characteristics. It's an example of a "shiny new thing" language, as
well, fitting it into the trinity of programming aesthetics.

In Scheme, everything (or at least nearly everything) is a function.
I'm less familiar with what makes Scheme what it is than I am with
Ruby, though from what I understand it is about as close to a "true" or
"pure" functional language as you're going to get without resorting to
simply writing programs in Lambda calculus (which would be akin to
trying to communicate using English without nouns). Scheme is one of
the Lisp family of languages, which as a whole comprises one of the
canonical examples of the "obscure, eccentric genius" programming
aesthetic. In fact, the two primary approaches to Lisp seem to be
embodied in Common Lisp (a large, sprawling language) and Scheme (a
more succinct, terse language that grew from the same base). Granted, I
could be mistaken. This will be my first-ever foray into the land of
Lisp and its imitators.

Finally, of course, there's C. C is the procedural representative,
though it is not the most "true" or "pure" procedural language out
there. It is, however, procedural enough to get the point across by a
fairly wide margin, and it's a language that every serious code hacker
should know. Period. It's the language to which all modern languages
owe their compilers and interpreters, most of them owe their syntax,
and all owe their running environments. It's the language in which
operating systems are written, because you don't want to do everything
in kernel development with automatic garbage collection or object
oriented design. It's the only language developed specifically because
a high-level tool for operating system design didn't already exist. It
is, truly, the practical, pragmatic, ubiquitous, venerable old
workhorse of programming languages. Unix and C are each the other's
mother, in a strange sort of incestuous, mutually procreative,
synchrogenetic relationship. It's going to be the example language
representing procedural programming, and that's that.

Conveniently enough, most of what makes Objective-C what it is will
be covered by these languages ? particularly, C and Ruby. Objective-C
is a true superset of C, unlike that OOP (object-oriented programming)
kluge C++, which means that if you learn all of C you'll know all of
Objective-C except the OOP structure. Ruby gets its OOP structure ? its
OOP semantic elements ? from Smalltalk, which is precisely the source
of Objective-C's OOP structures. Between C and Ruby, then, Objective-C
will be only a step away. Well, good.

I've lucked out. I get to learn Ruby and Scheme from the ground up,
and I frankly haven't done much with C either. I get to learn a whole
lot of stuff here. For the small price to pay of organizing and
coordinating all this, I get to learn everything without having to
shoulder the responsibility of contributing superior expertise. I get
to go back to just being a student again. Because I have experience
with other languages (like PHP, Perl, and Object Pascal, for instance),
and because I enjoy reading books about programming theory**, I also
have free reign to comment and rattle on and not be perceived as a
prejudicial idiot. This should be great fun.

Did I mention that I get to learn? That's such a barrel of fun that
I don't know what to do with myself. Happy times are ahead.


* = Objectional? Hah. That's funny.

** = I quite strongly recommend both Eric Raymond's The Art Of
Unix Programming and The Pragmatic Programmer by Andrew Hunt
and David Thomas. They're thoroughly excellent books on programming
theory.

Let me add Beginning Linux Programming Stones and
Matthew. I also quite like Advanced Programming in the
Unix Envrionment Stevens.

A good book to pick up C is A Book on C Kelley and Pohl.

This is part one of the Understanding OSes series. Find more at the Table of Contents .
When a computer first boots, it starts up the BIOS (Basic
Input-Output System), a sort of rudimentary operating system designed
to work (hopefully) without user intervention. Its purpose is to find
and activate the bare minimum hardware needed to allow the discovery
and activation of an operating system that is actually designed to
interact with the user. The BIOS provides a central sort of
abstraction that accepts input from various devices and offers output
interfaces from which devices can receive data. This allows your
computer to trade information between components so that the processor
can access an operating system on your boot media (hard drive, floppy
disk, et cetera), load necessary bits of it into memory, and ultimately
begin running software so that it interacts with humans in the real
world in some way.

This leads to booting the operating system. Interestingly enough,
the operating system itself then has to redo everything the BIOS did,
but it has to do it in its own (generally much more complex) fashion so
that more than just the bare minimum hardware is detected and
activated, and so that more complex operations can be attempted. This
entire process is referred to as "booting", an evolution of the term
"bootstrapping", which in turn arose from the quaint image of pulling
oneself up by one's bootstraps. The idea is that the OS must create its
own foundation for operation in order to run effectively. It would be
very much like trying to lift oneself off the ground by tugging on
one's bootstraps if the BIOS wasn't there to provide a point of
leverage. In the case of large-kernel OSes (which is to say: anything
you're likely to encounter in a comparative discussion of modern OSes),
there is actually an intermediary step called the "bootloader", because
the BIOS is in fact too limited to access enough system resources to
load the entire kernel all by itself. Instead, it fires up the
bootloader, that intermediary pseudo-OS, which then in turn does for
the operating system proper what the BIOS did for it.

The most fundamental part of the operating system consists of the
kernel. In the process of discovering hardware, activating it, and
creating software interfaces with hardware (usually through the HAL, or
Hardware Abstraction Layer, in modern personal computer OSes), your OS
probably does some autoprobing. What this means is that the kernel's
boot process has a set of data describing hardware types, and it looks
around at what is available to see if anything matches the hardware
definitions in that set of data. It thus probes for hardware and keeps
track of what it finds. Where it's looking for this data is at I/O
ports, which are "addresses" of data buses. A data bus is basically a
pathway along which data can travel between hardware components, and
I/O ports are bus addresses that relate to data input and output
functionality.

If you're using an operating system that displays the results of
hardware autoprobing, you'll see a series of text messages on the
monitor of your computer (or hear it on a speech-only system, or
whatever suits your particular setup; for all I know, some of you might
operate systems by smell, though that would certainly require a very
customized setup). As it recognizes hardware at these I/O ports, your
OS kernel in some manner loads drivers: software components that
provide a means of communication between the hardware components and
the internal workings of the OS. In most modern OSes, there is a
particular part of the kernel whose job it is to gather input from
hardware and provide it to the rest of the kernel, and to pass kernel
output on to the I/O ports. That part of the kernel is the HAL, and it
provides a means for most of the kernel to be the same no matter what
hardware platform is being used to run the OS. Only the drivers and HAL
need to change between hardware platforms, providing for a great deal
of OS portability so that the hardware doesn't always have to be
exactly the same.

This all leads us to the first two major sticking points in
comparing the major personal computer OSes with which we're familiar.
How autoprobing is handled and how the HAL is designed create
significant differences in how the OS behaves under certain
circumstances. DOS and Windows (which inherits its autoprobing
capability almost unchanged from DOS, even after all this time) use a
very rigid, inflexible mechanism for hardware autoprobing. This
mechanism is bad at identifying hardware because it doesn't listen very
well. What it does, in general, is ask each I/O port "Are you this?"
over and over again for many values of "this", where each "this" is
some piece of hardware the OS has been told to expect. If you have
installed drivers tailored for a given piece of hardware at a given I/O
port, the kernel will default to that driver first and ask the hardware
"Are you this, for which I have a driver?" When there are no specific
drivers, the kernel must try only the very limited set of options given
to it at the "factory", one at a time, until it finds something that
looks like a match.

If you happen to have more than one set of drivers installed that a
particular type of hardware's answer might resemble, you might get a
hardware conflict situation. A piece of hardware that lurks beyond a
given I/O port will be asked "Are you this?" and will respond "I fit
that description", but if the driver is actually for another piece of
hardware that is simply similar enough that the OS isn't sure how to
differentiate, you get the wrong driver associated with a piece of
hardware. The autoprobe then fails. Microsoft tried to solve much of
this by introducing the PnP (Plug and Play) system, which essentially
consists of a huge database of drivers pre-installed but only activated
when hardware matches up with them, and by increasing the number of
characteristics the kernel uses to describe a hardware expectation when
probing at a given I/O port. This creates an inversely proportional
relationship between the amount of time spent autoprobing and the
likelihood that the right drivers will be identified for a given piece
of hardware.

The various unices tend to differ somewhat in how good they are at
autoprobing. This difference largely depends on how much developer time
has gone into hardware interaction performance for a given unix OS.
Some unices have placed more focus on security utilities, some on
number-crunching, and so on. Linux has, from the beginning, had a lot
of attention lavished on the performance of the kernel in relation to
hardware. One benefit of this has been a lot of attention on
autoprobing, and as a result the Linux kernel is very, very good at
autoprobing. It basically listens better than most other OSes, and is
designed to be very good at handling the data it gets from I/O ports
during autoprobing to choose driver modules. The term "driver modules"
will come up again later, by the way, in another of these articles.

There are those who theorize that it is the cleverness of the Linux
kernel's autoprobing that allowed it to be as rapidly successful among
developers (who are also users) as it has been. By being good at
autoprobing, it was easier to install than other unices: unices in
general have lacked "user friendly" installers for years, with the
exception of those proprietry unices that have been closely wedded to
proprietary hardware platforms so that autoprobing is largely
unnecessary. This means that the user who wishes to install a unix on a
given computer must do so with a fairly rudimentary installation
interface, if there is a cohesive installer at all. With the original
Linux installations, this actually had to be accomplished with no
installer whatsoever. Instead, a boot floppy was used to get started,
and part of the process involved compiling a kernel from source on the
machine on which you plan to run it. For those who know this process,
at least in theory, no further explanation is needed. For those who
don't, suffice to say that it is a long, involved process, and largely
irrelevant for this exposition on the OS boot process.

If it wasn't for the fact that it is as good at autoprobing as it
is, Linux would have taken much longer to move beyond that stage and
further advance in market share and mindshare. It attracted developers
because it is a unix, with all the power and flexibility that implies,
and because it was much easier to install than its brethren. Being an
open source project, the Linux kernel's popularity among developers
also ensured that it got more development, not only in improving on its
already clever autoprobing capability, but also on everything else it
did. As such, it broke away from the pack early and gained popularity,
performance, and functionality more quickly than it would otherwise
have done. That's the theory, anyway, and that's why it's now looking
at the situation of being a real contender for market niches previously
thought to be the sole province of Microsoft and Apple, with
bit-players like Amiga, BeOS, and NeXTstep momentarily hovering at the
fringes as technically superior, but undermarketed, alternatives.

Once hardware is identified, and drivers are in place, the first
stage of the boot process is complete. Your computer has reached what
unix hackers often call "run level 1". The next step involves running
an initiating process, often called "init". This process checks storage
media out and starts up other processes, such as unix daemons and
Windows services running in the background. These are the programs like
print spoolers, incoming mail listeners, and local web servers, which
are always paying attention for possible incoming instructions whether
from the network or from user applications that might call on them.
Once these background processes are running, the initiating process
will start up your interface (at least, that's the order of things in
theory, though Windows often violates that and unices can be made to do
so with startup scripts). In unices, getty (or equivalent) is started
to watch consoles for command line input at the shell. In Windows, a
GUI environment is started immediately, and in modern Windows versions
the console input processes aren't started at all unless the user or
some user application accesses the command line.

Then, finally, user applications and high-level demons and
background services are started. While your network may be initiated
early in the init process in Linux, for instance, networking servers
(such as an SSH server, an FTP server, and so on) are started after the
basic interface processes are begun. The same holds true for Windows.
This is because such processes actually use the interface as part of
their operation. Where the default interface is the GUI (Graphical User
Interface), where any CLI (Command Line Interface) is actually an
application running inside the GUI, this imposes quite a lot of
resource overhead on the operation of such services. This is part of
the reason that so many services in Windows have been incorporated into
the ever-more bloated kernel, and that those that haven't been
incorporated into the kernel often make use of services that behave in
unsafe ways such as by inappropriate use of RPCs (Remote Procedure
Calls), in an attempt to recapture performance otherwise lost to the
GUI's RAM and CPU demands. Such tricks to bypass the security enforced
by a strict separation of system processes from user processes are not
necessary with unices because of the fact that the GUI isn't integral
to the OS, and thus doesn't impose the same resource inefficiency on
the higher level services.

I don't mean to suggest, of course, that these are the only reasons
such things happen, or that these are the only consequences that
proceed from those causes, but they are the most relevant to this topic.

This concludes part one of the Understanding OSes series. Part two is Understanding OSes: Kernel Modularity

Tuesday morning this week (tomorrow), there will be a Wikimedia planned network outage at approximately 7AM UTC (that's 3AM EDT, which is local time for the servers in Florida). The reason is that we'll be moving the entire network from one physical location to another. The span of this outage is at this time unknown, but should't be terribly long, barring unexpected delays. The most popularly known website that will be affected by this will be Wikipedia . I think the admin devs are planning to switch access load to squids in France, providing read-only access for the bulk of the network outage, but it's entirely possible that I imagined that aspect of it all. I'm just the datacenter technician.

This means I'll be working with several others unplugging, hauling, and reconnecting servers in the wee hours of the morning. Should be fun.

16:31 d "Much of the cruft results from C++'s attempt to be
backward compatible with C. Stroustrup himself has said in his
retrospective book The Design and Evolution of C++ (p. 207), "Within
C++, there is a much smaller and cleaner language struggling to get
out.""
16:32 me . . . and it's Objective-C.
16:32 me Actually, it's probably not.
16:33 d could be java.
16:33 T c# ?
16:33 d it is cleaner and smaller, just in the wrong ways...
16:33 * T awaits the flames
16:33 d C# is java with a different syntax...
16:34 T runtime is a bit different too
16:34 T although you could argue that the language is independent from the runtime
16:34 c c# is a little better lang wise than java
16:34 c but they still suck
16:34 d
the fact you have a language that runs in a virtual machine yet has
introspection slower than Smalltalk on 20 year old hardware says
something...
16:35 T hehe, until last year washington mutual ran all their home loan software on a smalltalk app on os/2
16:36 d cool
16:37 T then they replaced it with a browser-based javaish frontend on top of MS xslt crap middleware on top of MS crap servers, spent
billions of dollars, and cut productivity down to 1/5 of what it was
16:38 d wow.
16:38 T amazing how a company like that can be so IT-stupid
16:40 me funny as hell, too
16:40 T funny if you don't work for them...
16:41 c verizon is trying to do the same
16:41 c but they havent been able to eliminate their mainframe dbs
16:41 c they cant duplicate the functionality

Of course, I blame Sun for all this. Java was a nifty idea, and some
good ideas were incorporated into it, but the truth of the matter is
that the implementations of Java that are actually advantageous are
quite limited. It's a "virtual machine"-based language, compiled to
"bytecode" that is then interpreted by a VM at runtime, which means
that execution is slow ? in some cases, slower even than languages that
use a traditional interpreter. In addition, much of the reason for
Java's failure to live up to expectations for WaMu, despite the fact
that Smalltalk is also a VM language, is that the JVM is basically
broken by design. I'm not as clear on the internals of the Java virtual
machine as some, but I know people whose judgment on the matter I trust
with nothing good to say about the JVM.

Much like Microsoft, though, Sun subscribes to the notion that
something new should be sold to everyone as a panacea. Thus, Java has
been put into use writing static platform applications, games, and even
server software. Server software! That's nuts. The whole point of Java
from the beginning was portability of client application code. What
advantages Java can provide are all best suited to client software in
unknown computing environments. For some reason, though, a language
whose implementation is anything but spry, combining the performance
and flexibility detriments of interpreted and compiled languages in one
single package, is being used for server-side dynamic webpages,
database management systems, server-side accounting software, and
everything else under the Sun. Speaking of that, I do blame Sun. Java
has been made a buzzword, and as a result it has been used in numerous
implementations that are entirely inappropriate for its use.

Java employs some C-like syntax and Smalltalk-like object oriented
structure, but manages to screw them both up; it is essentially what
Objective-C would be if designed by a marketing executive instead of a
mathematician ? broken, but capable of fairly portable code (just as
C++ is what Objective-C would be if designed by a computer scientist ?
broken, but at least a good performer). Of course, that portability can
as easily be achieved by use of framework libraries and good OOP
modularity rather than a virtual machine. You really can't fight hype,
though.

Now, we've got .NET, which is a little closer to what Java should
have been. There's even a Java spin-off language called J# that'll run
on the .NET framework (which, despite the name, is really just a
glorified VM with extensions). .NET (and its non-MS implementations,
including Mono) is almost as limited in appropriate scope as Sun's
Java, but we can expect that it will be pushed as the next great
panacea. People will be trying to use it everywhere, for everything.
ASP.NET is in full swing now, for instance, despite the inadvisability
of running .NET server-side. What good is bytecode-compiled server-side
software, anyway? Either run something interpreted (or, even better,
compile-at-runtime), or just use a compiled language for better
performance.

. . . or, you can continue training for your career as a
Pointy-Haired Boss in the grand tradition of Dilbert's manager. Have
fun with that.

So I've been absent from this blog for a bit. Get over it.
In other news, I've decided to start aggregating helpful "cheatsheets" on one of my websites. They'll be plain text files, each relating to a single area of interest. You'll be able to find them at http://www.apotheon.org/cheat for your browsing convenience.
So far, all I've got there is a set of basic executable commands that are very commonly used from the shell on Linux systems. Some of the commands are specific to the Debian distribution, at the moment, but I may eventually create a viewing script for these cheatsheets that will allow the viewer to filter the content of each cheatsheet to suit his or her needs (such as filtering out Debian-specific commands, and add in Fedora-specific commands). For now, though, it's just a text file. Since most Fedora-specific commands open captive interfaces anyway, they wouldn't really be appropriate for this particular cheatsheet.
Look forward to stuff about specific configuration files, useful captive interface tools like vim, and maybe even stuff not strictly related to computers. I also might throw some of my deep, but these days largely unused, Windows knowledge in there to help the unenlightened hoi polloi out with their own aggravations.
That is all. Carry on.

All bloated GUI apps are unstable. Really. I know some of you are
out there thinking "No, but not such-and-such an application! This
application is very stable." Well, sure, compared to (for instance)
Outlook. Compared to a daemon that runs in the background, though, or a
command-line tool, it's downright vertiginous. I mean, compare Firefox
and IE for a moment: in that context, Firefox looks rock-solid. On the
other hand, I clicked on a link about half an hour or so ago and the
entire program VANISHED, taking a dozen or so web pages in tabs with
it. I hope none of that was important. This, of course, would account
for how unstable Windows itself is. It is, after all, a gigantic,
monolithic GUI application tied together with other gigantic,
monolithic GUI apps.
Windows Mobility 2003 is friggin' ridiculous. Here's this GUI
desktop-on-a-palmtop miniature OS, with no less than four different
built-in wireless networking options, and it includes no functionality
for network browsing. None. I had to find this out the hard way,
futzing with it, reading documentation, finding more documentation to
read, and eventually calling the vendor of the device to ask them about
it. Finally, what I found out is that in order to access any network
resource you need to connect to it by direct ActiveSync, then (if you
still feel like it) by ActiveSync over the wireless network, or by
setting up Windows Terminal Services to allow you to directly connect
to one particular Windows machine. Even accessing the Web requires
something like that, as you need to specify a proxy server! This is
insane. Seriously. What good is this crap? The real joy of all this is
that the only reason I found out about WM2k3's shortcomings is that I
have to somehow get PerlCE installed on this thing and write a network
client for an inventory tracking system. More luck: I don't have an
ActiveSync cradle for the device.

Yesterday ? Tuesday ? I got a call from the organizer for the local
LUG meetings that occur on the second Tuesday of every month. He had
two things to ask of me.
The first was whether I'd be willing to run the meeting that night.
He wouldn't be able to make it, and wanted me to fill in. I pondered
for a moment, and assented.
The second was whether I had enough time to take on a part-time
network admin job in addition to everything else I'm doing. I'd put in
about twenty hours a week, fairly flexible hours, during normal
business hours. Four or five hours a day, four or five days a week. He
told me I was on his short list of people to recommend at a company
that needed such help, since he'd no longer be available to fill those
needs for that company himself. I assured him that, yes, I'd be able to
do that.
I went on to the LUG meeting, bringing two people with me who'd
never attended meetings for this LUG (one of whom was an occasional
Linux user who mostly stuck with Windows these days for reasons of
specific application needs as a musician, and the other of whom is
looking into migrating from Windows). All told, the meeting was a
success, with me at the helm. I heard only good things about my
handling, including an impromptu presentation on the installation and
use of the centericq multiprotocol IM client, and I know for sure that
at least some of those accolades were entirely honest. Judging by what
I've seen going on with the usual meeting organizer's life lately, I'm
guessing he might be sorta grooming me as a candidate to replace him as
the organizer for the meetings. If that's the case, there's an outside
possibility I may end up running LUG meetings, almost entirely by
accident ? assuming I don't run screaming the other way.
The potential job situation is an interesting proposition for me.
It'd mean I'd essentially be working part-time billable hours with
three distinct employers. One is the Wikimedia Foundation, one is an IT
consultancy, and one is a middling-sized corporation. I might even end
up with a startlingly large payday situation, and three simultaneous
employers, if I'm not careful. Add to this the fact that my IT
consultancy boss is moonlighting as the vice president of projects at
an RFID services consultancy, and he might have me get on-board there
as well, I might end up in middle-management in a fourth employer's pay
as well. Where ever shall I find the time?
Interestingly enough, if I end up with all these jobs at the same
time, I'd probably end up making the most at the RFID position, as what
I'd probably end up doing is lead development on programming projects,
most of whose development work would be contracted out with me
coordinating and writing the glue code that ties it all together. Thus,
an odd sort of middle-management, but no pointy-haired boss by any
stretch.
All four of those positions, as well as the possibility of running
LUG meetings, arise from my enthusiasm for and knowledge of Linux
systems, at least in significant part. There's also some
platform-inedependent programming and Windows expertise involved in
some of these positions, to varying degrees, but the one unifying
factor is Linux.
Don't let anyone tell you that Microsoft is the key to your IT
career. I'm Microsoft certified and, of five potential rewarding work
experiences (two of which are already actualities, and a third of which
is rewarding for reasons that don't involve pay), not one has anything
to do with my Microsoft certs. Frankly, nobody gives a rotten fig about
my MS certs.
Once in a while, it's good being me.
By the way, I do intend eventually to continue my survey of the
characteristics of OS design, and I do intend to start the next
installment with a reference to kernel modularity, but there've been a
lot of things on my plate lately (in case it wasn't obvious).

This is part two of the Understanding OSes series. Part one was Understanding OSes: Booting . Familiarity with the subject matter of part one is recommended before reading part two. Find collected links for this series at the Table of Contents .

At the center of every modern operating system is the kernel. The
kernel is, in essence, the parent program of all other programs that
make up the totality of your OS and computing environment as a whole.
The kernel, however, is not all one piece of homogenous process, at
least in theory, and the degree to which it is separable into distinct
parts is called "modularity". What modularity means changes from one
kernel design to another: in the Linux kernel, a module might the
device driver for your wireless networking card, while in the Hurd
kernel, a module might be even more fundamental, such as the operating
system's interrupt request handling functionality. In the course of
this article, I'll address kernel modularity by describing the
modularity characteristics of several major types of kernel design:
highly modular microkernel, two-part microkernel, monolithic kernel,
and megalithic kernel. I'll do this primarily by examples, though in
some cases my examples will explain the types by contrast as much as by
demonstration of the type.

The most modular OS design philosophy going in theoretical OS design
circles utilizes what is known as a "microkernel" with sort of a cloud
of modular parts floating around it, ready to be attached to and
detached from the microkernel itself to provide functionality if, and
only when, they are needed. This is meant to provide increased
security, because no more kernel is present than is needed to be in
operation at any time, thus reducing the amount of possibly compromised
code. This is meant to provide increased stability, because the
complexity of the current running system is reduced when no more than
exactly what is needed is actually running. This is meant to provide
increased performance, as there is less kernel to be loaded into memory
and to demand the attention of the processor than if everything is
loaded all the time. All of this is how a microkernel is supposed to
make your life better, in theory. As we all should know, however, in
theory there is no difference between theory and practice, and in
practice there is a difference. Make a note of that principle of theory
and practice: I use it a lot.

Unless and until microkernel development makes sudden leaps forward
in perfection of its principles of implementation, we're going to tend
to find many of the intended effects of microkernel design being
reversed. They perform like dogs because interfaces between the modular
chunks of the kernel (the microkernel and its cloud of extensions)
require communication: by analogy, compare being able to pass thoughts
around in your brain with being able to discuss those thoughts with
another human being. Their stability is good, as far as the microkernel
itself is concerned, for exactly the reasons it's theorized it should
be good, but the stability for the whole system is reduced by virtue of
the fact that increased complexity of communication across software
interfaces creates more opportunity for errors and failures to occur,
possibly causing big chunks of the system to fail if something goes
wrong. As far as anyone is aware (or so I'm given to understand),
security operates pretty much as advertised, though there are those who
are skeptical of the claim of increased security as well. I suppose, in
the end, that if the "perfect" microkernel OS were written, it would be
more stable, secure, and quick on the uptake than everything else
going, but if the "perfect" monolithic kernel were written as well, it
too would be perfectly secure, stable, and fast, so one begins to
wonder where the escalation of hypotheticals might end.

There is exactly one commonly available true microkernel OS in
current development, so far as I'm aware. That OS is GNU/Hurd. It's
still not, as of this writing, in ready-for-release form, but it's
operational. From what I understand, it's slow as molasses in
comparison with GNU/Linux system performance, but operational. I'll be
keeping an eye on its development to see where it's going.

There is also a commonly available pseudo-microkernel in current
development that might surprise you. That kernel is called Darwin, and
it's the heart of MacOS X. It is a very nearly "true" microkernel, but
that of course is shot down the tubes as far as microkernel theory is
concerned by the way Apple makes use of the Darwin kernel for the basis
of MacOS X. You see, MacOS X is built as a layered-on monolithic
kernel, with Darwin simply acting as the core of it. Ultimately, MacOS
X seems to be designed as a bilithic kernel, if I'll be allowed the
neologism, which operates pretty much indistinguishably from the way a
monolithic kernel operates.

The next step in our odyssey from microkernel to megalithic kernel
is the modular monolithic kernel. This is a somewhat effective attempt
to wed some of the better facets of microkernel and monolithic kernel
design into one single kernel design standard. The current canonical
example of this is the Linux kernel. The way the Linux kernel works is
largely indistinguishable from the way a normal monolithic kernel
works, as viewed from outside, and thus it enjoys the performance
benefits of a mostly unified operating system. Essentially, a true
monolithic kernel makes everything that is strictly part of the
necessary OS of a computer system part of the kernel, which does not
include the user interface. This is normally only possible by knowing
before you compile your kernel exactly what hardware you'll be using,
and designing the kernel to suit that hardware, then compiling it.
There are ways around this, and I don't pretend to really know anything
about them excepting the way Linux does things, so I won't comment
except on the Linux modular monolithic kernel design.

Within the Linux
kernel, there is a set of module support interfaces that allow for
kernel modules to be loaded and unloaded as needed. Linux notably uses
kernel modules for device drivers, among other purposes. Because of the
tight integration of modules with the kernel, there is minimal
performance loss in the communication between modules and kernel,
though when you compile your kernel you need to "deactivate" support
for modules you know you won't use if you want greater performance
benefits possible through absence of those modules. For those who are
familiar with Linux distributions, this is (at least theoretically) a
performance benefit of using Linux From Scratch, Debian From Scratch,
Gentoo, or really any custom-compiled kernel, assuming you are willing
(and knowledgeable enough) to configure the kernel to suit. All else
being equal, then, the combination of features of modularity and
monolithic kernel design contributes greatly to the performance of
Linux, and helps to explain how a Pentium II 366MHz Thinkpad running
Linux that I own consistently outperforms an Athlon XP 1600+ desktop
system running Windows XP Pro that I also own.

This brings us to the red-headed stepchild of kernel modularity,
Windows. There have, over the years, been aspects of Windows kernel
design that make arguments possible claiming that it is a microkernel
system, a monolithic kernel system, a bilithic kernel system, or a
megalithic kernel system (the last being a system that includes even
such normally application-level software as the user interface in the
kernel itself). Ultimately, I suppose the way to describe the somewhat
schizophrenic history of the Windows kernel is as a modular megalithic
kernel. From top to bottom, the OS itself is made up of separate, but
indivisible, parts. For instance, the user interface of Windows XP is
indeed a separate set of code from the rest of the kernel (and is,
itself, several separate programs interoperating intimately), including
the legendary OS-integrated Explorer rendering engine used to make much
of the user interface possible, but the OS itself literally will not
start and operate properly without all major modular parts of the
entire vertically integrated stack of parts running. If the UI goes
down, the entire operating system is essentially inoperable unless and
until the UI starts working again.

Technically speaking, of course, the
higher-level OS components are not part of the kernel, but there is
such an indistinct dividing line between parts of the operating system
that sometimes it can be a little hard to tell where the kernel ends
and everything else begins. Despite initiatives at Microsoft over the
years intended to implement good design principles in kernel design,
they have largely been sabotaged by the necessities of interfacing the
kernel with the rest of the operating system. The part of the OS that
is officially identified as the kernel by Microsoft, its central parent
process, is actually not a bad design, at all, in theory. In practice,
it is the axle on which the Windows wheel turns, and a stable axle
won't smooth the ride without some rubber between the wheel and the
pavement. The reasons for the evolution of the Windows system
architecture are manifold, and will be the subject of a later addition
to the Understanding OSes series.

I keep seeing people asking for advice relating to getting started
in Linux, and the advice they get is often quite disorganized, in large
part because of where they're asking. For instance: jumping into a
distro-nonspecific discussion forum such as TR, and asking for what's
the "best" distribution of Linux to use, is likely to elicit sixteen
answers from a dozen people, followed by a whole lot of debate,
sometimes highly technical and other times full of crap. Similar
problems arise with other pieces of advice for which a putative
penguinista might ask, and really it helps to find a clear, coherent
discussion of the options, along with advice on how to accomplish what
you're aiming to do that is similarly clear and coherent.
That's what I aim to do with this. Before I get anywhere near the
end of my Understanding OSes series (and I may never finish ? I'll
probably come up with ever-more stuff about which to write as I keep
learning more), I'm declaring the intent to begin a new series. Welcome
to the Windows->Linux series.
I'll probably start with some cautionary statements about if/when
you should make the leap from Windows to Linux, what to expect, and how
to get help when you need it. That's even more fundamentally important
than your choice of distro, since it'll help you out with everything
you do in your transition from one OS to another.
Table of Contents:

Linux: To Migrate or Not To Migrate

I look forward to reading your posts on this topic.  I've found
your previous posts and commments to be well reasoned and equally well
expressed.

[The text of this post was copied from an article of the same name at @political .]

In the here and now, the domestic US information technology industry is in trouble. Sales aren't as brisk as they once were, and the employment market is in the toilet. There are moments of optimism here and there, but when you turn back around you always find a dozen IT industry professionals out of work and wondering where the industry went. Meanwhile, Microsoft is pressing for more H-1B work visas so they can hire more foreign nationals domestically, claiming there just aren't enough qualified IT professionals available.

The commoditization of software is what inevitably led to this state of affairs. Microsoft essentially spearheaded the commoditization of software in the US, turning OSes into prepackaged "products" sold by unit. Microsoft is often credited with "revolutionizing" the industry in this manner, making it into a powerhouse by virtue of the commoditization of software, but the truth of the matter is that technology advances as it's needed, and it would have happened whether the software was sold as product units or not. In any case, this commodity profit model was only possible by strictly enforcing copyright law in a manner advantageous for maintaining Microsoft's revenue streams, and continued to be profitable only by lobbying for ever-stricter copyright law in Microsoft's favor. It's not only Microsoft that has done this, of course: every large proprietary software vendor has had a hand in it, but it's Microsoft that led the charge, and continues to lead it.

By making it a product rather than treating development as a service to the customer base (which would of course make Microsoft in current form entirely nonviable), these corporations have created a situation wherein software development costs can be kept to a minimum to provide greater profit margins in a "finished product" format. When it's a sealed-up "product", a program can be 98% old code and sold as something entirely new, it can be assembled from "parts" that are developed by anyone anywhere that simply comply with certain external behavioral standards, and can be made functional and featureful without the actual code being of any particular level of quality. As a result, close control over code quality isn't needed, and offshoring becomes entirely viable as a development model.

The copyrighted code is sold in executable form on a CD, and you are required by law to not make any copies of it except as possible "backups" in case the original is damaged. You are not allowed by law to install it on more than one computer at a time, and depending on circumstances you may not be legally allowed to install it on more than one computer ever. This maximizes profits, as the applications and OSes sold cost effectively nothing to reproduce in bulk quantities for sale, and with ever-cheaper offshoring development available, and the cost of transmitting finished code electronically being effectively zero, overhead for corporations like Microsoft gets smaller and smaller. As surmised in the linked article, the reason H-1B visas are desirable to Microsoft has nothing to do with not being able to find engineers. One of the major reasons for it is that Microsoft doesn't need to pay visa workers as much as domestic workers, so they can hire people here on a work visa to do the few things that simply cannot be done overseas and transmitted electronically, such as local project management.

All of this comes together to create a situation wherein computer scientists are in decreasing demand in the domestic marketplace, all while software vendors are telling the media that offshoring is reversing and domestic hiring will increase so that they can keep their customer base active. There's the first problem that rears its ugly head for software vendors: as the technical crowd is put out of work, they stop spending money on software. The very people they're putting out of work are a significant percentage of their customer base. In essence, the domestic software market is cannibalizing itself because of the consequences of a commoditized software profit model.

Linux has the ability to be the spearhead for the cure to these ills, to mix a metaphor. Open source software development, with Linux as its current poster child, short-circuits profit models that rely on software as a commodity. It emphasizes the value of development, and de-emphasizes the value of corporate bureaucracy, packaging, and marketing dollars. In short, it puts potential revenue streams back in the hands of individuals, and takes them out of the metaphorical hands of corporations. It emphasizes the value of the developer and the software support provider. It favors many small companies rather than a few multinational corporations, and demands local access to development and support talent.

If the law doesn't shift to exclude the growing influence of free/libre/open source software, FLOSS may just become the revitalizing influence needed by the domestic IT industry. Of course, corporations have strong lobbies, and FLOSS has almost no lobby at all, so there's no guarantee the law won't change tomorrow to make a domestic industry revitalization of that sort effectively impossible. We'll see.

As for me, I composed this article on a Linux machine.

Part of the problem with the IT industry is the doom and gloom. 
HR doesn't understand IT (and never will) and corporate culture wants
IT to be something it is not and never can be.

What IT needs is an image face lift.  Forget the certs, forget the
education, forget the experience, just focus on WHY the typical IT
worker looks bad to corporate america.
1) We are practicle.  We don't drive a Porsche, even though we might make $100k/year
2) We aren't socially apt.  Ok, some of us are, but many don't
have the soft skills to function like corporations want us to
3) We don't explain IT.  It is all a black box...
4) Technology should just work.  There shouldn't be any of this
"there will be downtime from 8am - 5pm for system upgrades" crap that
is floating around...If a system outage is needed, explain to your
users WHY you need to do it and WHY it will take so long.

Much of IT is considered a service, but that isn't quite right...it is something of kung fu mixed with technical knowledge.