Hilf’s word.

This article is right on. There is plenty of evidence to suggest that Windows is indeed more reliable than Linux. Don’t get me wrong. I love Open Source and Linux (eh…I like OpenBSD better) as much as the next guy, but there is this sort of cultural movement within the Linux community to stick their fingers in their ears and sputter nonsense whenever someone actually competes with Linux (or open source in general). I suspect that there are some level heads within the Linux community, particularly among developers, that know all this. But for a large segment, as soon as you say “Windows does _____ well, and Linux could stand some improvement in the area of ____”, you don’t get back reasoned responses. You get “Quit spreading FUD, you M$ fanboy. Linux is l334 and wipes the map with Winblows. W()()t!”.

Until the Linux community sort of collectively wakes up and smells the coffee, they will continue to not be competitive with Microsoft, even in some of their pet areas, like reliability.

What Hilf says about testing is particularly true with open-source software. Microsoft, in the Windows division at the time that I worked there, employed over 2,500 people just for testing – and I mean *real* testing, with a plan, recorded results, etc. Linux probably has under 500 active contributors, and no structured testing plan. Microsoft has a lab where they test thousands of printers – linux has thousands of users that send in dmesg and bug reports.

There’s simply no comparison.

I’m the first person that would just love it if, say, OpenBSD could utilize resources like that, because I think they have a fantastic process in place, and they do generate code that has as high a quality as can be expected without such resources. With them, they’d be unstoppable.

http://ezine.daemonnews.org/200603/dermouse.html

This is an interesting way of dealing with backups. It might be interesting to see it ported to OpenBSD, although it would have to be desired by many for it to actually be accepted.

I’m not sure how desirable it would really be. Would people really want to either (a) completely fill up their networks with backup data or (b) have to add another knob to a system that is philosophically opposed to adding knobs whenever possible?

A brainteaser posted by John Derbyshire:

A rope hangs over a pulley. On one end is a weight. Balanced on the other end is a monkey of equal weight. The rope weighs 4oz. per foot. The age of the monkey and the age of its mother together equal 4 years. The weight of the monkey is as many pounds as its mother is years old. The mother is twice as old as the monkey was when the mother was half as old as the monkey will be when the monkey is three times as old as the mother was when the mother was three times as old as the monkey. The weight of the weight plus the weight of the rope is half as much again as the difference between twice the weight of the weight and the weight of the monkey. How long is the rope?

Lego Difference Engine by Andrew Carol.

One of the coolest lego creations I’ve seen.

Pic:

I often like to derive an unimpl_error class (or something like it) so that as I’m fleshing out various parts of a piece of software, I can mark something as unimplemented by throwing an exception. I suppose a // TODO comment would serve the purpose, but for some reason, I like the exception idea. That way, if I forget that I didn’t write some function, if I try to call it I’ll get my reminder

Anyway, I do this often enough that I thought it deserved to go in my collection of design patterns and idioms.

#include

class unimpl_error : public logic_error
{
public:
unimpl_error(std::string &msg) throw()
: std::logic_error(msg) {}
};

I am currently working on an iostream sockets library for C++. See bigthicket.us for an overview in Dinkumware-style header documentation (which is now very out of date, but it still gives you the rough idea).

I’ve probably spent roughly one man-week on it (rough estimate). I now partly understand why there isn’t an existing implementation like this. It’s not easy. Why bother with inheriting from standard library classes when you can just write direct wrapper classes and go about writing socket-based network software just like before?

Getting the sockstream class to write to a socket and have a server receive it was pretty easy. Almost trivial, I’d say.

Accepting connections and receiving data on them is another ballpark alltogether. Buffering for incoming data is much more complex than it is for outgoing data, which is tricky to deal with, because I don’t want to rewrite all of std::streambuf. I want to inherit as much as possible from std::streambuf and only provide minimal overloading of virtual functions to get the functionality that I want. The standard documents have been very helpful so far, and so I will continue to rely on them to aid my understanding of all the plumbing involved.

Anyway, all that is to say, I can understand now why the existing C++ sockets wrappers were written the way they were.