David Kanter (dkanter@realworldtech.com) on 5/9/06 wrote:
---------------------------
>Kernel_Protector (kernelprotector@yahoo.com) on 5/9/06 wrote:
>---------------------------
>>What Tanenbaum says is perfectly correct.
>
>According to you.
>
>>According to my view, since its a kernel, its design should be planned good.
>>variable codes(codes which interact with hardware, daily new hardwares appears)
>>Vs fixed codes(or not frequently changing codes and 100% >reliable codes and does not deal with hardware)
>>only fixed codes should be running in kernel space with full priviledges and variable
>>codes should be running in user space.
>
>
>No amount of planning can substitute for seeing what is going on. If you try to
>freeze software in stone and never change it over the course of 10 years, you're going to be very very sorry.
>
>>if IPC, Memory management those which has a complete programming which wont have
>>bugs(since the codes for these may be small and which wont have any frequent code
>>change) only runs in the kernel and everything else(remaining drivers) which might
>>have code change even daily runs in the user-level, will result in a good secured and reliable OS.
>
>Has it occurred to you that these functions might need to change over time?
>
>>regarding performance,
>>i like to say this...
>>i had a program which took 15 minutes to complete with a pentium II processor.the
>>same program took 7 mintues to complete with a pentium III processor. and it took
>>only 2 or 3 minutes in a pentium IV processor.
>
>Do you write code which can run efficiently (> 90% speed up) on N threads, for
>arbitrary N? If not, I wouldn't count on that any more.
>
>Besides, just because hardware gets faster isn't an excuse to write bad software.


Umm, I think you are being a touch disingenuous here. He said nothing about writing bad code. He said it is worth the tradeoff in performance to have more secure code which is less prone to attack. The balance is always somewhere in the middle but it is totally disingenuous to act like he was referring to bad coding.

Bad coding is throwing everything together with no plan and no thought for performance. You can intentionally decide that a certain technique is worth the tradeoff in performance without being a bad coder.