The biggest problem in making software is debugging. Writing code is simple, every monkey can do it. With enough monkies with typewriters and a few smart people filtering the monkey output you can even get something that improves over time. But to get real products that are usable, you need lots of competent people doing slow and hard work behind the scenes. Linux development is more and more moving towards a model where the real work is pushed to become Somebody Elses Problem.
And people wonder why BSDs are getting more and more popular. Seesh.
"Relative debugging" seems to be what people have always been doing. Dump some state and comapre it to an expected state. Most frameworks for regression tests do something like that.
The best debugging method is to have a fast build environment so that you can add one printf, rebuild, reproduce the bug, move the printf to an even better place, rebuild and reproduce, etc. The more you rely on your tools to do the work for you, the less you understand the code and the less you understand the code, the more bugs you will make in the future.
Redoing all those benchmarks without the strange libraries that the author uses and instead using plain syscalls shows that what the benchmarks measure is how the benchmark code performs, not the actual syscalls.
A real bind benchmarks has a O(1) time on OpenBSD and NetBSD.
The connect latency benchmark seems seriously confused. And since I don't find any source for it, I must conclude (based on the rest of the benchmarks) that it must be flawed in some way.
The "read one byte from each page" benchmark on OpenBSD performs that badly because the file used doesn't fit in the buffer cache.OpenBSD doesn't use all the memory for the file cache. When the file fits in the buffer cache OpenBSD has a performance comparable to linux 2.4. Anyone with half a clue about how a computer works would have listened to the disk and noticed that it's making noise.
And the rants about ipv6 only show that he doesn't know how to write proper ipv6 code and instead relies on a compatibility interfaces that were created for lazy programmers to allow for quick conversion of old ipv4 programs into ipv6.
The author is clueless and the benchmarks more often measure the performance of the benchmark itself than the operating system.
The work that needed to be done to switch i386 to ELF has been ready for a long time. But doing such a switch is a huge pain for the developers and users, so it was delayed for as long as possible. Same thing was with other architectures. alpha switched to ELF when the alpha port was almost dead and was violently revived by redoing lots of code and completly changing everything. sparc switched to ELF after a bug was discovered in how the dynamic linker worked. The dynamic linker didn't map the code segments executable which didn't really work after the kernel was taught to honor the executability bit on memory mappings (that was done to get non-exec stack). And i386 swichted because that was the only way to get proper non-exec stack.
OpenBSD does big disruptive changes only when it's really necessary and when those changes come, all disruptions are clustered thightly.
Of course SCO won't sue anyone. They are done, they have inflated their stock price, they have collected "insurance" money, they have managed to start the best FUD campaign against free software ever and they are getting away with it. They will profit on this for years to come and the Linux community will sit there like a bunch of fools thinking they have actually won by making SCO back off.
Everything depends on if IBM will spend money to continue the fight.
The copyright owners of the code SCO claimed was theirs should sue SCO to at least make them pay a small price for copyright violation (claiming that you own something that you don't own the copyright for is a copyright violation, at least in some countries), but as far as I know, only whoever wrote BPF would have a decent case with a chance of winning.
Slashdot Mirror
The biggest problem in making software is debugging. Writing code is simple, every monkey can do it. With enough monkies with typewriters and a few smart people filtering the monkey output you can even get something that improves over time. But to get real products that are usable, you need lots of competent people doing slow and hard work behind the scenes. Linux development is more and more moving towards a model where the real work is pushed to become Somebody Elses Problem. And people wonder why BSDs are getting more and more popular. Seesh.
"Relative debugging" seems to be what people have always been doing. Dump some state and comapre it to an expected state. Most frameworks for regression tests do something like that.
The best debugging method is to have a fast build environment so that you can add one printf, rebuild, reproduce the bug, move the printf to an even better place, rebuild and reproduce, etc. The more you rely on your tools to do the work for you, the less you understand the code and the less you understand the code, the more bugs you will make in the future.
There are no shortcuts to good code.
Redoing all those benchmarks without the strange libraries that the author uses and instead using plain syscalls shows that what the benchmarks measure is how the benchmark code performs, not the actual syscalls.
A real bind benchmarks has a O(1) time on OpenBSD and NetBSD.
The connect latency benchmark seems seriously confused. And since I don't find any source for it, I must conclude (based on the rest of the benchmarks) that it must be flawed in some way.
The "read one byte from each page" benchmark on OpenBSD performs that badly because the file used doesn't fit in the buffer cache.OpenBSD doesn't use all the memory for the file cache. When the file fits in the buffer cache OpenBSD has a performance comparable to linux 2.4. Anyone with half a clue about how a computer works would have listened to the disk and noticed that it's making noise.
And the rants about ipv6 only show that he doesn't know how to write proper ipv6 code and instead relies on a compatibility interfaces that were created for lazy programmers to allow for quick conversion of old ipv4 programs into ipv6.
The author is clueless and the benchmarks more often measure the performance of the benchmark itself than the operating system.
The work that needed to be done to switch i386 to ELF has been ready for a long time. But doing such a switch is a huge pain for the developers and users, so it was delayed for as long as possible. Same thing was with other architectures. alpha switched to ELF when the alpha port was almost dead and was violently revived by redoing lots of code and completly changing everything. sparc switched to ELF after a bug was discovered in how the dynamic linker worked. The dynamic linker didn't map the code segments executable which didn't really work after the kernel was taught to honor the executability bit on memory mappings (that was done to get non-exec stack). And i386 swichted because that was the only way to get proper non-exec stack. OpenBSD does big disruptive changes only when it's really necessary and when those changes come, all disruptions are clustered thightly.
Of course SCO won't sue anyone. They are done, they have inflated their stock price, they have collected "insurance" money, they have managed to start the best FUD campaign against free software ever and they are getting away with it. They will profit on this for years to come and the Linux community will sit there like a bunch of fools thinking they have actually won by making SCO back off. Everything depends on if IBM will spend money to continue the fight. The copyright owners of the code SCO claimed was theirs should sue SCO to at least make them pay a small price for copyright violation (claiming that you own something that you don't own the copyright for is a copyright violation, at least in some countries), but as far as I know, only whoever wrote BPF would have a decent case with a chance of winning.