aporem.net

This is old news, but the reactions are much more noteworthy than the act itself: Ian Murdock (the “ian” in Debian) has left the Free Software Foundation and has joined Sun Microsystems as of March 19.

As of today, his announcement already has more than 100 comments on his homepage, many of them welcome posts from Sun employees. The press resounds with this news, too.

But I wonder what this is all about. It also has been a big issue when Linux Torvalds started using Macs and then quit after a while. So what? These are professionals, so why should they limit themselves in their profession just to “stick with it”?

Nevertheless, it’s cool that “Debian goes Solaris” (or the other way round?).

I came across a short rant from chromatic. Although short, the main statement is a long-standing problem: there are many bad examples and wrong tutorials afloat. Not just that most of them are outdated, one too easily finds bad programming practices melted into howtos and code snippets.

The problem with this is that most readers won’t check the quality before absorbing the information. Thus, shortcuts (mostly bad design) are propagated instead of the programming gems everyone preaches.
Of course, there should be a purifying effect through community review, but since code snippets are mostly just copied, who reads the comments at the bottom?
So not only the inexperienced programmers get trapped within bad code, but even seasoned programmers deal with code that is much worse than their own standard.

Since I don’t believe that this article will change the world, with every programmer strive to their best on every line of code, I have a compromise to offer: containment. Separate as much of the “borrowed” code as possible. Morale will raise since the own good code is not tainted and there is also an incentive to refactor / redesign / rethink the external code before it goes to the “inner circle”.

Time, contrary to popular belief and classical physics, is not a constant. Especially not “the time” the watches tell us.
It is, after all, a mere convention, put up to help people in everyday life. Historically, noon is defined as the point in time, when the sun is at its highest point the current day.
Without travel this definition would sufficient, even though the actual time of noon differs over the year. Linking cities faster than a days travel throws this system into a huge problem of adjusting time on the go.
Unfortunately, the solution to this malaise was half backed (and another arbitrary convention), for in the summer months the evenings were too short for an urban lifestyle.
The correction to this was yet another convention, but this time not coordinated between all parts of the world, all countries nor all timezones.

All this apparently makes time keeping a complicated matter as long as local time is preferred to UTC.
For 24/7 operations, every change in time is cruelsome and hence best avoided. Thus computers keep time in a single format and adjust the output accordingly.
Since most computers are not aware of their location but the implications a certain location has in respect to time (stored in the zoneinfo file), this should be the only necessary input.
At least until a country changes its rules (like the US did). Then every zoneinfo (worldwide) has to be updated.

So if an unexplainable skew of one hour accured since last sunday, chances are high that something went wrong with that update.

Computers are a commodity. Not just the desktops at work but also the servers (as far as a certain threshold is not passed). The ever increasing rate the prices drop in respect to the computing demands adds to this effect.

The consequence is that for every odd reason a new server is set up. Of course, the benefits are apparent, since there is no interference with perhaps critical systems no dispute between business units about the sharing of costs etc. but there is no such thing as free beer.

Every new machine adds load to the network, consumes electricity, dissipates heat and needs constant monitoring and maintenance. And these costs by far exceed the costs of the original purchase. By estimates of the big consulting companies, the hardware accounts just for 20 to 33 percent of the TCOs.

So why is this happening? — Because the complexity increases even faster than any other aspect.

For example, add a new application to a running server and you will have to keep to the current constraints (libraries, interdependencies, et al.) and find out what other constraints are added. And then add another application. Soon, the list of constraints will effectively deny any change of configuration and the system is unmaintainable.

So what to do about it? — This is the challenge of current IT.