The problem is that really flexible software is really hard to develop and really hard to audit for security and correctness, not to mention usability. It's like the flying car: the benefits of having a car that can fly are completely swamped by the problems it creates, technical as well as logistical as well as economical.
Reuse doesn't make programming easier. It makes it harder.
The difference is that overclocking is a bloody waste of time!
A car that was fast in the 80s is a car that is fast in the 90s is a car that is fast in 00s -- a computer that was fast two years ago is slow and pathetic today.
Last i checked groomed, a virus actually did something to exploit a program. This program, whatever, is a trojan. The user has to accept it (click it).
No, actually it has multiple attack vectors.
The worm fill find another host, own it, and well buddy, it is out of your hands now. And no user double clicked it.
Well, I suppose it's a lost cause (as with the "hacker" term), but I it can't hurt to point out that it really doesn't make much sense to call this program a "trojan".
The article suggests that this is a "trojan" because it lets attackers stealthily take control of your computer. But that was not what was remarkable about the historical Trojan horse. What was remarkable about it is that it was presented as a gift. The distinguishing characteric of a trojan is that it has a friendly outward appearance but contains a deadly payload. That's certainly not the case with Phatbot.
Rather, I'd say that Phatbot is a virus, because a) it is malicious and b) it doesn't rely on deception to spread itself. This is, again, subtly different from a worm, which generally aren't malicious, just annoying.
Of course it's water under the bridge at this point.
remember apache vs tux? the big argument for tux was that being in kernelspace you saved copies, overhead, etc. but the apache group proved you could have a userspace solution that was faster than any kernelspace solution.
Apache is a very bad example. First of all, because your claim is simply untrue: Tux is, and has always been, a lot faster than Apache for serving static files. Apache might beat Tux on some specific tasks, because it can afford to throw more resources at a problem, but it is quite clear that being a part of the kernel is the single most important factor contributing to Tux' speed. Secondly, Apache has been a favorite benchmark of kernel developers for a long time, so a lot of work has focused on making Apache perform well. One of the greatest improvements to Apache performance, in fact, came with the addition of the sendfile() system call.
So using Apache as an example to show that kernelspace support doesn't improve performance doesn't hold up.
anyway, you don't have to use realtime priority in order to get low latency, as the lowlatency patches have shown.
That may all be true, but it's not what JACK's authors recommend.
In fact, the list of recommendations for running JACK is stringent and contains a number of very esoteric items such as having to mount a RAM based filesystem on/tmp.
The question is, at what point do the hacks and the hassle required to make the userspace solution work well exceed the ugliness of just putting (key elements of) the stuff in the kernel.
oss does NOT work "fine" with the Delta 1010. You have no control over channels or formats
I'm not sure what you mean. Are we talking about the same thing? I mean the non-free OSS drivers. They work very well and offer plenty of control. Not sure about support for the other cards you mentioned.
no, what you are asking for is not realtime priority.
I'm not the one asking for realtime priority. JACK is the one asking, begging, for realtime priority.
what you are asking for is low latency. you just don't know it.
Of course the issue is low latency. That is the whole point of moving support for the thing to kernel space, because having it entirely in userspace is wasteful and inefficient (additional memory copies, IPC overhead, context switches, scheduling issues).
i doubt your 8 year old 60mhz powermac will mix 64 channels of 48khz 16bit stereo audio, low latency suitable for professional studios.
No, of course the PowerMac can't do that, it doesn't have the memory bandwidth or the CPU power. But the software architecture supports it, if the processing power is there.
The problem with JACK and friends is that you can have ample processing power, in the form of bus bandwidth, memory bandwidth, and CPU throughput, and still have problems recording a miserable 2 channel 16 bit stream. There is no excuse for that. It has nothing to do with the fact that JACK is aimed at professional studios. It just means that JACK is very, very inefficient.
you seem to be revolving around build a kernel solution based on oss purely for games and nothing else. everyone else is aiming higher than that -- a generic solution which can handle both games and pro audio, both ends of the spectrum.
No, not at all. I just want something that's efficient. Whether its used for pro-audio or for games is completely irrelevant. Being "professional" doesn't mean you have to be cumbersome and inefficient.
oss is depreciated because its api is simply incapable of driving anything beyond very basic audio cards in any basic way. good luck doing serious multichannel work with eg ADAT card and oss.
That's just nonsense. OSS works fine with lots of high-end audio cards, like the Delta 1010. There is really no difference between using ALSA to record and play back the bits or using OSS.
But yes, ALSA does provide more control, and that is nice. I like ALSA. I don't want to start an OSS vs ALSA war. All I was doing is showing that kernel level mixing solution for Linux exist (in the form of OSS dmix), and that it outperforms all the userspace solutions in terms of performance and ease of use.
this has already been argued to death on linux-kernel and other mailing lists, and the conclusions resulted in artsd and jack -- both userspace. apparently nobody else was able to come up with a compelling argument. i'm willing to hear yours though.
These discussions rarely get anywhere. After a couple of messages, a few people (who have no affinity with audio whatsoever) start repeating the "policy should be in userspace" mantra, and because that sounds good theoretically, people think it makes sense. But it's just dogma. It's impossible to provide a compelling argument against dogma.
To get something approaching reliable performance, JACK and all its clients must be run as root with realtime priority. These privilege elevations make the system just as prone to security problems and system lockups as a kernel component would have done -- arguably more so, since a kernel component wouldn't require all the clients to run with elevated privileges. Even then, performance is still very poor (my 8 year old 60MHz PowerMac does a better job than JACK).
JACKs operating requirements just scream "I need to be in the kernel!". But dogma prevents that.
In addition, JACK just doesn't satisfy the requirements for a software mixer, viz. it doesn't provide transparant mixing of several applications' sound outputs without considerable configuration hassles. And it doesn't provide it all for applications which don't use the JACK API A kernel level solution would be able to provide this support naturally, without any configuration.
On the other hand we have 4-Front's (non-free, I think) OSS dmix kernel level software mixer, which puts all the Linux userspace solutions to shame for speed and convenience. But since OSS is out of fashion, most GNU/Linux users will probably never get to enjoy it, and there will continue to be pointless discussions about how userspace mixing is just as good as kernelspace mixing when clearly it isn't, and how you need a multi-GHz multi-Xeon machine just to mix a few audio channels...
what happens when a kernel driver runs the system out of ram? you deadlock, or worse.
No. Having a driver that doesn't check whether memory allocations succeed, that is to say buggy code, kills the system.
Anyway I don't see what any of this has got to do with the issue at hand. I suppose you mean to say that it's risky to put a software mixer into the kernel because of the possibility that it might contain bugs that might kill the system.
Obviously whether something needs to be in the kernel needs to be carefully considered. And whether a full software mixer should be in the kernel is arguable. But we really need some kind of support to improve performance and lessen the configuration hassle (with all the fragility that comes with it). It wouldn't be a first, either. The kernel contains lots of hacks and features to better support the needs of a wide range of applications, such as Samba, WINE, DOSEMU, Java, X, PPP and Apache.
There is no natural law that says some things must be in the kernel and others not. Ultimately it comes down to necessity. I think it is, and so far haven't seen anything that would lead me to believe otherwise.
resource starvation in userspace is generally non-fatal. not so in kernelspace.
Eh? The kernel has to deal with resource starvation because it is responsible for allocating them.
Seriously, when you have to apply kernel patches and run applications with real-time priority as root (which means the box is borked when something goes wrong anyway) to get some semblance of usability, then something is wrong.
hint: win32 uses a userspace software mixer. works well enough
Which userspace software mixer is that? As far as I know both DirectSound and MCI sit on top of KMixer, which is a kernel component.
there are other ways to exploit a mixer than number of channels to mix.
There are also many ways to constrain resource consumption. Arguing that a mixer in the kernel is bad because it might use resources is a non-starter -- that's what those resources are there for.
No, not really. Sure, you could possibly beat JACK into doing something like it, but it's way too cumbersome for the casual user, and it doesn't work with apps that don't support JACK. JACK has a completely different purpose, similar to something like ReWire.
the Alsa Project's longstanding philosophical refusal to move software mixing into the central driver means you still can't expect Linux to run games on any random piece of desktop PC hardware.
How does a kernel level mixer help games to run on random desktop PC hardware? Even more to the point, how does the lack of same prevent games from running on random desktop PC hardware? You can write a mixer in ten lines of code, it's not exactly hard.
What the Kalman filter does is predict the future state of a model based on previous estimates and measurements. It takes into account the expected measurement error and the expected modeling error, and dynamically adjusts it's "confidence" in both model and measurements based on the estimation errors. The Kalman filter is an optimal filter, in that it can be shown to minimize the estimation error.
The beautiful thing about Kalman is that it works with partial data, that is, it can be applied recursively, "as the data are coming in". This is what makes it so suitable for realtime applications, as well as the fact that it is very robust in the face of temporary sensor failure.
Kalman is frequently used in tracking and control applications. Interestingly, Kalman filtering was also recently applied to the problem of task scheduling in the Linux kernel in the Entitlement Based Scheduler. There's lots of info about Kalman filtering on the web, use Google if you want to know more.
I choose my stupid recursion algorithm just because it makes it possible to produce a small predictible program that takes long time to execute.
The problem with the recursive algorithm (as a benchmark) seems to be that it is so rudimentary that it leaves no room for the C compiler to perform significant optimizations. And in so far as C benefits from having lower overhead, this benefit just drowns in the inherent slowness of the algorithm.
Anyway, when I started programming Java back in 1998 execution times were typically 25 times slower than for C. Those days are over
Certainly Java has gotten a lot faster since then.
(and for amateurs, like me, who dont know how to produce optimal code with a c-compiler Java might in fact be the better choice).
I would not say that. If the algorithm isn't so slow as to completely overwhelm the compiler optimizations and runtime overhead, then getting optimal performance out of non-trivial Java programs is I think harder than getting good performance from a similar C program.
But your point stands, proving that isn't as easy as it used to be.
I've repeated your tests on my machine (Linux 2.4, Pentium III, gcc 3.2.2, JDK 1.4.2_01). I get pretty much identical results to yours without any tweaking, with tweaking the best C program is some 30% faster than the Java program.
But when I eliminate the recursion in your program like this:
int fib2(int x) {
int i, l, n, r = 0;
if (x==0 || x==1)
return 1;
for (l=1, n=1, i=2; ix; i++) {
r = l + n;
n = l;
l = r;
}
return r; }
The C program is consistently 2 to 4 times faster than the Java version. I even get some runs where the C program is 100 times faster than the Java version, but I suppose those are flukes/unreliable data.
Interesting. Of course all it proves is that Java can be faster than C on a contrived toy benchmark, which I don't think anybody contests. But an interesting result nevertheless. It's worth noting that the Java program spends 8x as much system time than the C program though.
Out of curiosity, did you try -fomit-frame-pointer? -Os?
Why should it be impossible for independant third parties to develop drivers for graphics adapters? What is the valuable IP that, say, ATI, will lose through such an arrangement? What secrets are there that cannot be exposed? How can somebody like Nvidia steal it, given that ATI has a head start of at least half a year to get the hardware up to production quality and then another half year for the software? This argument just doesn't work.
Not really. Apple bought NeXT at the end of 1996 under leadership of Gil Amelio, with the express purpose of using NeXTStep as the basis of the new OS (or whatever the proper capitalization is). This was perhaps a year or so after they dumped their ill-fated Copland next-gen OS project and needed a new OS fast. Be was the other company that was rumored for an Apple buy-out.
I agree with most of your criticisms wrt branding, but I think you are completely distorting the point when it comes to the distinction between open source and free software.
The open source movement aims for better software. They claim the open source development methodology achieves this. (A claim which, by the way, I think is preposterous and nonsensical.)
The free software foundation aims for a better world, by protecting people's freedom to share and use information.
I really don't see how you can claim they mean the same thing.
Or it recovers more locally, like "sorry, this SMTP connection will be terminated because it has a string buffer overflow". The server itself will go on working.
But does that matter if it just dropped an important piece of mail? And what about potential bugs in the recovery code? After all, that code is least likely to get good testing.
No, there is nothing "buggy" about relying on built-in protection mechanisms and throwing a low-level exception under unexpected conditions.
I don't think you should be handling errors that you didn't anticipate. That's not exactly what you're saying, but it comes damned close.
Your idea that programmers have to check every single piece of data manually comes from C
It's not about manual versus automatic. What I balk at is the idea that you can write useful programs without awareness of things such as how many characters an array will hold. An off-by-one error may still lead to data loss even if the environment can recover from it gracefully.
But languages are supposed to make programming easier.
"Easy" is not a one-dimensional property. I think C is easy, for example, because it gives you a great degree of control: I find few things as frustrating as fighting garbage collectors or abysmal performance characteristics.
The correct way of dealing with buffer overflow problems is to make them not happen in the first place. That means that all pointers need to have bounds associated with them.
And then what? Program oversteps its bounds and is terminated? Granted, you've prevented a possible buffer overflow and exploit, but the program is still severely broken.
The real problem is ultimately the use of C
The problem is that people write buggy code. Buggy code won't work right no matter how many protection mechanisms you build into the environment.
Slashdot Mirror
The problem is that really flexible software is really hard to develop and really hard to audit for security and correctness, not to mention usability. It's like the flying car: the benefits of having a car that can fly are completely swamped by the problems it creates, technical as well as logistical as well as economical.
Reuse doesn't make programming easier. It makes it harder.
The difference is that overclocking is a bloody waste of time!
A car that was fast in the 80s is a car that is fast in the 90s is a car that is fast in 00s -- a computer that was fast two years ago is slow and pathetic today.
But it doesn't need help to spread between machines. At least that's what I gather from the links referenced in the story.
Last i checked groomed, a virus actually did something to exploit a program. This program, whatever, is a trojan. The user has to accept it (click it).
No, actually it has multiple attack vectors.
The worm fill find another host, own it, and well buddy, it is out of your hands now. And no user double clicked it.
So can a virus.
Well, I suppose it's a lost cause (as with the "hacker" term), but I it can't hurt to point out that it really doesn't make much sense to call this program a "trojan".
The article suggests that this is a "trojan" because it lets attackers stealthily take control of your computer. But that was not what was remarkable about the historical Trojan horse. What was remarkable about it is that it was presented as a gift. The distinguishing characteric of a trojan is that it has a friendly outward appearance but contains a deadly payload. That's certainly not the case with Phatbot.
Rather, I'd say that Phatbot is a virus, because a) it is malicious and b) it doesn't rely on deception to spread itself. This is, again, subtly different from a worm, which generally aren't malicious, just annoying.
Of course it's water under the bridge at this point.
remember apache vs tux? the big argument for tux was that being in kernelspace you saved copies, overhead, etc. but the apache group proved you could have a userspace solution that was faster than any kernelspace solution.
/tmp.
Apache is a very bad example. First of all, because your claim is simply untrue: Tux is, and has always been, a lot faster than Apache for serving static files. Apache might beat Tux on some specific tasks, because it can afford to throw more resources at a problem, but it is quite clear that being a part of the kernel is the single most important factor contributing to Tux' speed. Secondly, Apache has been a favorite benchmark of kernel developers for a long time, so a lot of work has focused on making Apache perform well. One of the greatest improvements to Apache performance, in fact, came with the addition of the sendfile() system call.
So using Apache as an example to show that kernelspace support doesn't improve performance doesn't hold up.
anyway, you don't have to use realtime priority in order to get low latency, as the lowlatency patches have shown.
That may all be true, but it's not what JACK's authors recommend.
In fact, the list of recommendations for running JACK is stringent and contains a number of very esoteric items such as having to mount a RAM based filesystem on
The question is, at what point do the hacks and the hassle required to make the userspace solution work well exceed the ugliness of just putting (key elements of) the stuff in the kernel.
oss does NOT work "fine" with the Delta 1010. You have no control over channels or formats
I'm not sure what you mean. Are we talking about the same thing? I mean the non-free OSS drivers. They work very well and offer plenty of control. Not sure about support for the other cards you mentioned.
no, what you are asking for is not realtime priority.
I'm not the one asking for realtime priority. JACK is the one asking, begging, for realtime priority.
what you are asking for is low latency. you just don't know it.
Of course the issue is low latency. That is the whole point of moving support for the thing to kernel space, because having it entirely in userspace is wasteful and inefficient (additional memory copies, IPC overhead, context switches, scheduling issues).
i doubt your 8 year old 60mhz powermac will mix 64 channels of 48khz 16bit stereo audio, low latency suitable for professional studios.
No, of course the PowerMac can't do that, it doesn't have the memory bandwidth or the CPU power. But the software architecture supports it, if the processing power is there.
The problem with JACK and friends is that you can have ample processing power, in the form of bus bandwidth, memory bandwidth, and CPU throughput, and still have problems recording a miserable 2 channel 16 bit stream. There is no excuse for that. It has nothing to do with the fact that JACK is aimed at professional studios. It just means that JACK is very, very inefficient.
you seem to be revolving around build a kernel solution based on oss purely for games and nothing else. everyone else is aiming higher than that -- a generic solution which can handle both games and pro audio, both ends of the spectrum.
No, not at all. I just want something that's efficient. Whether its used for pro-audio or for games is completely irrelevant. Being "professional" doesn't mean you have to be cumbersome and inefficient.
oss is depreciated because its api is simply incapable of driving anything beyond very basic audio cards in any basic way. good luck doing serious multichannel work with eg ADAT card and oss.
That's just nonsense. OSS works fine with lots of high-end audio cards, like the Delta 1010. There is really no difference between using ALSA to record and play back the bits or using OSS.
But yes, ALSA does provide more control, and that is nice. I like ALSA. I don't want to start an OSS vs ALSA war. All I was doing is showing that kernel level mixing solution for Linux exist (in the form of OSS dmix), and that it outperforms all the userspace solutions in terms of performance and ease of use.
this has already been argued to death on linux-kernel and other mailing lists, and the conclusions resulted in artsd and jack -- both userspace. apparently nobody else was able to come up with a compelling argument. i'm willing to hear yours though.
These discussions rarely get anywhere. After a couple of messages, a few people (who have no affinity with audio whatsoever) start repeating the "policy should be in userspace" mantra, and because that sounds good theoretically, people think it makes sense. But it's just dogma. It's impossible to provide a compelling argument against dogma.
To get something approaching reliable performance, JACK and all its clients must be run as root with realtime priority. These privilege elevations make the system just as prone to security problems and system lockups as a kernel component would have done -- arguably more so, since a kernel component wouldn't require all the clients to run with elevated privileges. Even then, performance is still very poor (my 8 year old 60MHz PowerMac does a better job than JACK).
JACKs operating requirements just scream "I need to be in the kernel!". But dogma prevents that.
In addition, JACK just doesn't satisfy the requirements for a software mixer, viz. it doesn't provide transparant mixing of several applications' sound outputs without considerable configuration hassles. And it doesn't provide it all for applications which don't use the JACK API
A kernel level solution would be able to provide this support naturally, without any configuration.
On the other hand we have 4-Front's (non-free, I think) OSS dmix kernel level software mixer, which puts all the Linux userspace solutions to shame for speed and convenience. But since OSS is out of fashion, most GNU/Linux users will probably never get to enjoy it, and there will continue to be pointless discussions about how userspace mixing is just as good as kernelspace mixing when clearly it isn't, and how you need a multi-GHz multi-Xeon machine just to mix a few audio channels...
what happens when a kernel driver runs the system out of ram? you deadlock, or worse.
No. Having a driver that doesn't check whether memory allocations succeed, that is to say buggy code, kills the system.
Anyway I don't see what any of this has got to do with the issue at hand. I suppose you mean to say that it's risky to put a software mixer into the kernel because of the possibility that it might contain bugs that might kill the system.
Obviously whether something needs to be in the kernel needs to be carefully considered. And whether a full software mixer should be in the kernel is arguable. But we really need some kind of support to improve performance and lessen the configuration hassle (with all the fragility that comes with it). It wouldn't be a first, either. The kernel contains lots of hacks and features to better support the needs of a wide range of applications, such as Samba, WINE, DOSEMU, Java, X, PPP and Apache.
There is no natural law that says some things must be in the kernel and others not. Ultimately it comes down to necessity. I think it is, and so far haven't seen anything that would lead me to believe otherwise.
resource starvation in userspace is generally non-fatal. not so in kernelspace.
Eh? The kernel has to deal with resource starvation because it is responsible for allocating them.
Seriously, when you have to apply kernel patches and run applications with real-time priority as root (which means the box is borked when something goes wrong anyway) to get some semblance of usability, then something is wrong.
hint: win32 uses a userspace software mixer. works well enough
Which userspace software mixer is that? As far as I know both DirectSound and MCI sit on top of KMixer, which is a kernel component.
there are other ways to exploit a mixer than number of channels to mix.
There are also many ways to constrain resource consumption. Arguing that a mixer in the kernel is bad because it might use resources is a non-starter -- that's what those resources are there for.
No, not really. Sure, you could possibly beat JACK into doing something like it, but it's way too cumbersome for the casual user, and it doesn't work with apps that don't support JACK. JACK has a completely different purpose, similar to something like ReWire.
software mixing is a baaaad idea in kernelspace, since there's potentially no upper bound on the cpu usage.
I'm not sure what you mean. The user can just set a limit on the number of channels to mix.
userspace is where you want to do mixing.
Unless you want something that performs well and works without hours of setup and testing hassle.
the Alsa Project's longstanding philosophical refusal to move software mixing into the central driver means you still can't expect Linux to run games on any random piece of desktop PC hardware.
How does a kernel level mixer help games to run on random desktop PC hardware? Even more to the point, how does the lack of same prevent games from running on random desktop PC hardware? You can write a mixer in ten lines of code, it's not exactly hard.
What the Kalman filter does is predict the future state of a model based on previous estimates and measurements. It takes into account the expected measurement error and the expected modeling error, and dynamically adjusts it's "confidence" in both model and measurements based on the estimation errors. The Kalman filter is an optimal filter, in that it can be shown to minimize the estimation error.
The beautiful thing about Kalman is that it works with partial data, that is, it can be applied recursively, "as the data are coming in". This is what makes it so suitable for realtime applications, as well as the fact that it is very robust in the face of temporary sensor failure.
Kalman is frequently used in tracking and control applications. Interestingly, Kalman filtering was also recently applied to the problem of task scheduling in the Linux kernel in the Entitlement Based Scheduler. There's lots of info about Kalman filtering on the web, use Google if you want to know more.
I choose my stupid recursion algorithm just because it makes it possible to produce a small predictible program that takes long time to execute.
The problem with the recursive algorithm (as a benchmark) seems to be that it is so rudimentary that it leaves no room for the C compiler to perform significant optimizations. And in so far as C benefits from having lower overhead, this benefit just drowns in the inherent slowness of the algorithm.
Anyway, when I started programming Java back in 1998 execution times were typically 25 times slower than for C. Those days are over
Certainly Java has gotten a lot faster since then.
(and for amateurs, like me, who dont know how to produce optimal code with a c-compiler Java might in fact be the better choice).
I would not say that. If the algorithm isn't so slow as to completely overwhelm the compiler optimizations and runtime overhead, then getting optimal performance out of non-trivial Java programs is I think harder than getting good performance from a similar C program.
But your point stands, proving that isn't as easy as it used to be.
I've repeated your tests on my machine (Linux 2.4, Pentium III, gcc 3.2.2, JDK 1.4.2_01). I get pretty much identical results to yours without any tweaking, with tweaking the best C program is some 30% faster than the Java program.
But when I eliminate the recursion in your program like this:
int fib2(int x) {
int i, l, n, r = 0;
if (x==0 || x==1)
return 1;
for (l=1, n=1, i=2; ix; i++) {
r = l + n;
n = l;
l = r;
}
return r;
}
The C program is consistently 2 to 4 times faster than the Java version. I even get some runs where the C program is 100 times faster than the Java version, but I suppose those are flukes/unreliable data.
Interesting. Of course all it proves is that Java can be faster than C on a contrived toy benchmark, which I don't think anybody contests. But an interesting result nevertheless. It's worth noting that the Java program spends 8x as much system time than the C program though.
Out of curiosity, did you try -fomit-frame-pointer? -Os?
Why should it be impossible for independant third parties to develop drivers for graphics adapters? What is the valuable IP that, say, ATI, will lose through such an arrangement? What secrets are there that cannot be exposed? How can somebody like Nvidia steal it, given that ATI has a head start of at least half a year to get the hardware up to production quality and then another half year for the software? This argument just doesn't work.
Not really. Apple bought NeXT at the end of 1996 under leadership of Gil Amelio, with the express purpose of using NeXTStep as the basis of the new OS (or whatever the proper capitalization is). This was perhaps a year or so after they dumped their ill-fated Copland next-gen OS project and needed a new OS fast. Be was the other company that was rumored for an Apple buy-out.
This doesn't make the slightest bit of sense.
If God is omnipotent, then how can he be incapable of making man understand creation?
If God comes to us in ways we understand, then how come he never appears to a nuclear physicist?
I agree with most of your criticisms wrt branding, but I think you are completely distorting the point when it comes to the distinction between open source and free software.
The open source movement aims for better software. They claim the open source development methodology achieves this. (A claim which, by the way, I think is preposterous and nonsensical.)
The free software foundation aims for a better world, by protecting people's freedom to share and use information.
I really don't see how you can claim they mean the same thing.
Or it recovers more locally, like "sorry, this SMTP connection will be terminated because it has a string buffer overflow". The server itself will go on working.
But does that matter if it just dropped an important piece of mail? And what about potential bugs in the recovery code? After all, that code is least likely to get good testing.
No, there is nothing "buggy" about relying on built-in protection mechanisms and throwing a low-level exception under unexpected conditions.
I don't think you should be handling errors that you didn't anticipate. That's not exactly what you're saying, but it comes damned close.
Your idea that programmers have to check every single piece of data manually comes from C
It's not about manual versus automatic. What I balk at is the idea that you can write useful programs without awareness of things such as how many characters an array will hold. An off-by-one error may still lead to data loss even if the environment can recover from it gracefully.
But languages are supposed to make programming easier.
"Easy" is not a one-dimensional property. I think C is easy, for example, because it gives you a great degree of control: I find few things as frustrating as fighting garbage collectors or abysmal performance characteristics.
The correct way of dealing with buffer overflow problems is to make them not happen in the first place. That means that all pointers need to have bounds associated with them.
And then what? Program oversteps its bounds and is terminated? Granted, you've prevented a possible buffer overflow and exploit, but the program is still severely broken.
The real problem is ultimately the use of C
The problem is that people write buggy code. Buggy code won't work right no matter how many protection mechanisms you build into the environment.