aporem.net

Again, I have to reduce the frequency of my posts.
In order to not fall even further behind, I will post from now on only once a week, i.e. the next post will be on March 6.

Either time is passing by faster than I can write or I write less frequently as time passes, but any way I put it the result is the same…

Commonly, one thinks of enterprise grade hardware as more reliable and overall more robust to failures than off the shelf equipment.
Apparently, as far as hard drives are concerned, this is simply false!

I came across this proceedings article of the “5th USENIX Conference on File and Storage Technologies”.
It’s quite a long read, so for the roundup you better read this.
Or even shorter: there is no difference between the reliability of SATA, SCSI and FC drives.

Anyhow, consider that this analysis takes nothing but the mean time to failure into account. Neither the performance nor the guarantee options, which of course can differ dramatically.
Anyway, this is not the point on which the report wants to focus. It emphasises the fact that a broken disk has to be replaced without regard to its type and that the overall time spent on replacing erroneous hardware can be calculated independently.

As a consequence, this gives the cheaper mass market SATA drives a strong stand in large installations (where the number of drives attached to the controlling entity eradicates the performance difference between the single SATA and FC drives).

I like reading rumour sites. Especially the Mac community has both a long tradition and a (un)healthy appetite for rumours. But lately this fondness was put to a test by the huge amount of fake or badly fact-checked reports and posts.

Fortunately, there are still some sites where people keep their common senses and where this development is seen with much concern.
Therefore I want to spread the word of a post which sports a six-point check list to keep you sane in these crazy days.

I want to close my post with the same last line:
“Keep your wits about you, and happy rumor-mongering!”

I’ve found yet another vim tip article. While skimming through the text I wondered, how many times I’ve already read some “tips and tricks” posts but failed to actually use the information to increase my productivity.
This time it was even worse, for if even a simple text editor offers much more functionality that you possibly could need, how about more advanced applications?

But then I reassured to myself that probably the whole set of features is used by the whole user base and that it would be impudent to believe that a single person can make use of the complete feature set.

Therefore I decided that ignorance is the only way out and actually decided not to trouble myself with this cool new feature.

I’ve found an article about memory management in C/C++, one of the mysteries in software development.
The author, Cameron Laird, tries to give both an introduction to the problem as well as to show up some ways to get through it.

What starts of as a myth-busting article, soon gets down to reality. From the beginning, Cameron Laid makes clear that there is no silver bullet approach, for albeit several decades of attention to the memory management of C/C++ the problems could not be eradicated.

After these introductory warnings, the author tries to give a categorisation of the mishaps that happen. There is a code snipplet for every mistake: memory leak, misassignements, dangling pointers and array bound violations are all presented in a clear and concise way.

The rest of the article concentrates on ways to avoid the common pitfalls:
First and foremost he suggests diligence & discipline. This is not truly a method to address memory problems but a sound coding style helps overall readability and with some remarks one can keep track of memory usage.

Static code checkers can go over the code on their own and probably find problems the developer didn’t thought of. It is an automated mechanism for code review, a 2nd pair of eyes if you like.
The prerequisite for a static code check is an error and warning free compilation of the sources. The author points out correctly that reality is different and even nowadays most programmers simply don’t care.

Finally, memory libraries and run time memory tools are discussed. Unfortunately, the article falls short on this topic only stating the inclination of the author towards the live tools.

Conclusively, the article is fun to read but falls short in giving practicable advices or to serve as a starting point for further reading.

Lately, I seem to develop a passion for articles that are inclined to start flame wars in their comments.

The blog post I came across is quite old (at least for blog standards: it’s from January 13, 2006!) but it picks up a timeless theme: is it better to reuse code or reimplement?

This time the author (Rick Copeland) gives us “three reasons why you shouldn’t write your own web framework”: waste of time of the developer, waste of time of all the other people looking for a web framework and diminished impact of the developers work.

While all the points he discusses are perfectly reasonable and as a alternate solution he promotes to help out in existing open source frameworks, he doesn’t mention the fundamental principle beneath this article: you need do be an advanced and seasoned programmer.

This is also resembled in the comments, since most of the responders seem to have difficulties reading other peoples code and adopting the programming style of a project. And then there is also the fear that one is left behind in the acknowledgements or is otherwise not as visible as creating a one man project.

From a personal point of view, I’m compassionate about the difficulties people have reading other’s code, but being a good programmer means exactly being good at reviewing one’s own or other peoples code. So it makes pretty much sense to learn to read well (yes, it’s something different than writing!).
The objections against contributing to a large(r) project based on the fear that one doesn’t get appropriate credits are really childish demeanor. The reputation one gains from being a good team player and a willing learner is much greater than the fame one gets from a one man project. Of course one gets more attention being the lead developer or the founder of a project, but how many are known to a broader public? Just those of large foundations — a status one will never aquire with a one man band.

Go contribute!

I want to clarify some differences between desktop systems, development environment and production systems. Although every mature operating system can serve in all three roles, there is still a lot to consider in picking the best operating system for a particular job.

A good desktop system is up to date to the latest trends while stable enough not to break your habits. Updating works without hassles and is usually done in the background. All in all, you don’t have to take care of it and enjoy working in a distraction free environment.

A development environment can be either a stripped down desktop or a blown up production system. Since the state of the machine plays an important role during compilation and testing, all (automatic) updates should be disabled and the regular cleanup of the environment should be as strict as possible. After all you don’t want to chase a bug in your code while in real it’s a changed shared library.

Finally, a production system is the minimal system required to run your production code. Minimal doesn’t mean “barely adequate”. The administrative tools should be hand picked and identical across all production machines on this site. Logs and other system information should not be diagnosed on the live system but sent to a dedicated host for backup and analysis. Every software not needed for system operations or by the production software is considered superfluous and should be deleted. Especially all compilers and not needed script engines.

Although these guidelines are straight forward and don’t favour one of the three categories it is amazing to see which emotions are connected to them.
For example, just Mac OS X and Windows battle for the desktop system, other OS being very careful in their ambitions into this region. Or the fact all Linux distributions want to be “server grade”.

I came across an interesting article on “Playing with Wire” where Alexander Ljungberg sums up his bad experiences with Gentoo as a server operating system.

Usually, these kind of posts start a flame war. Surprisingly, it was very lightweight. First, the author took great lengths to explain all his perceptions and to give an objective summary and second the comments were on the subject, too.
But except of the style of the flame war, there is more to the story.

I found very notable that there is a lack of understanding what “server operating system” really means. It has very little to do with the general ability of the operating system to run production code (especially if it is very generic, like a web server or your own) but with all the extra features which ensure that the production code really can run (unattended) for any length of time. Downtime for operating system maintenance should be as short as possible, the replication of the production environment as reliable as possible and excessive monitoring capacities should be available at short hand.

As the author states and I can second, Gentoo fails on all of these criteria. But this isn’t necessarily a bad thing. An operating system isn’t worth less just because it isn’t good as a server operating system.
Gentoo has simply an other target group. It is a very comfortable desktop operating system (like Ubuntu) and a perfect fit as a development environment.

I don’t understand why this seems to be such an embarrassment for some Gentoo enthusiasts.