Archive for June 2005
I’ve just read the interview with Theo de Raadt(TdR) and I just need to get my thoughts into words.
First I need to say that of course he is right. You don’t get to run the OpenBSD project without knowing what you talk about most of the time. The only problem, from my point of view, is that he’s evaluating OpenBSD from an administrator’s point of view.
I’ll address a few of the points where I think he’s overly negative about Linux and I’ll end with a few of my own points.
Linux developers are the slaves of corporations
Well, of course he’s right, but I think TdR would agree that they are in good company. Especially if one considers the bigger picture. The kernel on its own is useless piece of code without the rest of software that makes up a useful Linux system. That software is largely shared with *BSD, and several large pieces in there are supported by corporations, GNOME, Qt (the GUI toolkit used in KDE), GCC, Apache… The list goes on and on. All of these things are available on *BSD as well, and they make those OSs usable as well.
Linux is of lower quality than *BSD
He’s probably right. The *BSD maintainers are well-known for being demanding when it comes to what code makes it into the kernel. The problem with Linux adopting a similar style is that it’d reduce the momentum that Linux enjoys at the moment, without that momentum Linux would become less popular. It’d probably lead to several kernel developers moving onto some other OS project where they have a chance of getting there code in. Linus has a hard job balancing quality and speed of implementation, so far he’s been doing a good job. Sure, a few patches have been merged that should have been left out, but so far the Linux community has reacted fast enough to avoid disaster.
TdR also forgets to point out a crucial difference between *BSD and Linux. All of the *BSDs are both a kernel and a distribution. In the case of Linux there is a separation between kernel and distributions, for good and for bad. What it does allow is a more relaxed attitude with the kernel. There’s more freedom since some of the work is shifted to others. In this case it works in favour of Linux, even though it works against it in other situations.
Linux is getting to be as bloated as Windows
Yes. I can’t argue with that. It’s getting big, yes, but Windows’ biggest problem–the backwards-compatability requirement–is not weighing Linux down at all. Entire subsystems have been replaced with better solutions, and the old code is being phased out. I don’t believe Microsoft has ever done that.
“Linux people do what they do because they hate Windows.”
He continues: “We do it becuase we love Unix.”
“All generalisations are evil!”
I wonder if TdR hasn’t been reading too many Linux vs. Windows postings on /.. It’s just such a silly statement!
I recently bought a Toshiba laptop. I installed Ubuntu on it, and almost everything worked on it right away. I needed to tweak a few things, install a few more packages to get it to the point where Linux was a replacement for Windows (functionality-wise I mean, I wasn’t even considering running Windows as my main OS on it). Could I have done it with *BSD? Maybe! I don’t know. Looking at *BSDs laptop pages suggest some success with installing them on laptops. My particular model is not mentioned anywhere–there are two pages, besides my own, on running Linux on it. I am absolutely sure I would have to spend a considerable amount of time configuring a *BSD system on it if I got it to install successfully.
That is the kind of experience a modern OS has to offer in order to attract regular users today. AFACS *BSD doesn’t offer it! As long as they don’t they will be satisfied with being second to Linux in most user’s eyes. Administrators, or power users, are a different matter.
It might even be that TdR should be thankful for Linux. User-friendly Linux distributions are attracting much attention from people today. Chances are many of them will be bitten by Unix bug and then they might be moving onto *BSD for their server needs. When I buy a server for home use I know I’ll be putting OpenBSD on it.
I’ve received the Ubuntu Hoary CDs
The first one is already passed out—to my brother.
We took my Dad and Kristina to Nando’s. This time we went to the one on Regent Street. Again the food was good. Dita went the same way as the last time and ordered the quarter chicken, hot. I decided to try the chicken burger. Again we weren’t disappointed, and our guests enjoyed it as well. We’ll probably be bringing all our guests from overseas to Nando’s in the future.
The last day of my Dad’s and Kristina’s stay we spent checking out Oxford. Taking off rather late in order to avoid any peak hour traffic we didn’t arrive until just in time for lunch. The day was perfect, sun shining, but not terribly warm. Great for exploring a city.
We dropped in at the Museum of Oxford. A typical local museum telling the story of the city and the university. It’s almost too much information contained in the relatively few rooms. Items and informational texts all over the place, after a while we did skim over things. It should also be noted that they don’t have a toilet for visitors, the closest one is apparently in the Town Hall.
Then we strolled down to Christ Church. After a few fotographs, and looking at a group of Japanese tourists we coughed up the Â£4.50 per person and went in. After taking in the atmosphere of the place, especially the Hall, we went looking for a place to eat. The folder we had picked up at the tourist information mentioned a place called Chutney on St. Michael Street. We found it, but was immediately put down by the lack of prices on the menu displayed outside. A quick look at the menu inside revelead the place was expensive, for an Indian restaurant. That was probably the reason for the covered-up prices outside. Just up the same street we found a place called Makan La, with Malay food. Reasonable prices, and it turned out the food was good as well!
On the way back we passed time by counting the roundabouts. 45!!
According to an article on ElReg there will be support for Windows in Xen later this year. I am already dreaming of migrating my work desktop to Xen, running Windows in one ‘machine’ and a real OS in another. The few things I need Windows for can all be done through RDP… Ahh, I can’t wait!
The benefits and limitations of using
StrongNameIdentityPermission has been covered in several posts on the net:
One thing that they don’t mention, which most people might think is obvious, is that
StrongNameIdentityPermission means nothing when calling the managed code from unmanaged code. Since umanaged code can’t be signed (at least not in the same meaning as managed code can) it isn’t too surprising. What is a bit surprising might be that the call into the assembly is permitted. I was hoping that the magic in the .Net framework would put a stop to it all. No
This means that someone who wants to circumvent the access control doesn’t have to bother with delayed signing and extracting the public key from the ‘protected’ assembly. It also means that the ‘attacker’ doesn’t have to be able to write to the GAC, only read from it (something all users have permission to do). Writing unmanaged code that calls managed code isn’t too difficult.
I’ve been looking into .Net the last few days. Especially the interplay between managed and unmanaged code relating to COM (COM+) components. The most amazing thing is how much thing the framework will do for you implicitly. E.g. there is no visible difference in the source between instantiating a COM component and instantiating an object of a class. From a run-time perspective there is a huge difference of course, but the source for the managed code looks the same. No use of CoCreateInstance() anywhere!
I can clearly see how this is an appealing feature from the coder’s point of view. It means the deployment can be decided very late. You wan’t class A to be a COM component? Sure, why not? All it takes is adding an attribute to a class, that can be done at the very late in development. In short the COM-isation doesn’t have to happen until the very last step. Decision time is pushed as far back as possible. Cool! Right?
Explicitness does have a lot going for itself:
- It makes the developer think about what he’s doing.
- It also forces some things to come up to the surface early on.
In the example with managed COM components the thing that doesn’t surface until it’s too late is access control. When pushing the deployment decisions to the end of a project there is little incentive to put access control in the code during development. By the time it’s clear where the access control is needed it’s too late to put it in, unless you want to blow your dead line.
So, in the end the lack of explicitness will require the developer to know more about the framework and how it works… the irony is that this is what the magic was put there to prevent.