I did an informal sampling of 15 randomly selected comments, and did not encounter a single pro-Micro$oft comment. It looks like the DOJ is simply choosing to ignore these comments.
Our only hope is that Judge Kotaler-Kelly is principled enough not to accept the proposed settlement as satisfactory. I she stands up to these goons, I will vote for here as President in the next election!
Why rewrite the kernel and daemons? What can be done in any high level language that cannot also be done in C or C++? Answer: nothing. So why would it be necessary to rewrite the kernel and daemons in another language?
Simply providing security minded functions in a library, e.g. snprintf() and vsnprintf(), and employing them is all that is really needed.
Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications. This isn't likely to change any time soon.
It is already possible to use adaptive non-linear control theory to drive a car at speeds very near the limit of controllability. I have personally worked on such a controller algorithm, and can testify to it's robustness and accuracy.
If you can specify an ideal "line" around the racetrack, I should think that a robot could be competetive with a skilled human driver. The winner will be determined by his/her/it's ability to squeeze out the last 1% of the car's performance potential.
The apparent need for printed manuals is primarily because the increase in information "real estate" they provide. One of the most useful features of the *nix desktops is the multiple virtual desktop feature. I usually set my up so that Ctrl+Up moves me one desktop up, Ctrl+Left one desktop to the left, and so on (I use KDE or Enlightenemnt+Gnome, depending on my mood). This combined with a 19" monitor is actually better than printed docs because my monitor is actually bigger than a book. I open the docs on one desktop, and the program in another, and flip between them with the Ctrl+arrow keys. I say, quit killing trees!
Complicated failover systems are expensive, and may not failover correctly anyway. If you want to test the failover functionality, you must use a non-production setup, or jeapordize your production data. For many cases, having a set of RAIDed drives that can be quickly swapped from the failed server to a standby server is sufficient. It is certainly cheaper, and much simpler.
Sheesh, I wonder how I've been running a business with "whereware" and "wishware" for the last four years? I must be dreaming about replying to your post with my "whereware" browser, huh?
I did an informal sampling of 15 randomly selected comments, and did not encounter a single pro-Micro$oft comment. It looks like the DOJ is simply choosing to ignore these comments.
Our only hope is that Judge Kotaler-Kelly is principled enough not to accept the proposed settlement as satisfactory. I she stands up to these goons, I will vote for here as President in the next election!
Go Judge K-K!!!!Why rewrite the kernel and daemons? What can be done in any high level language that cannot also be done in C or C++? Answer: nothing. So why would it be necessary to rewrite the kernel and daemons in another language?
Simply providing security minded functions in a library, e.g. snprintf() and vsnprintf(), and employing them is all that is really needed.
Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications. This isn't likely to change any time soon.
I think it would be more appropriate to classify virus writers as "vandals", and treat them as such legally.
It is already possible to use adaptive non-linear control theory to drive a car at speeds very near the limit of controllability. I have personally worked on such a controller algorithm, and can testify to it's robustness and accuracy.
If you can specify an ideal "line" around the racetrack, I should think that a robot could be competetive with a skilled human driver. The winner will be determined by his/her/it's ability to squeeze out the last 1% of the car's performance potential.
The apparent need for printed manuals is primarily because the increase in information "real estate" they provide. One of the most useful features of the *nix desktops is the multiple virtual desktop feature. I usually set my up so that Ctrl+Up moves me one desktop up, Ctrl+Left one desktop to the left, and so on (I use KDE or Enlightenemnt+Gnome, depending on my mood). This combined with a 19" monitor is actually better than printed docs because my monitor is actually bigger than a book. I open the docs on one desktop, and the program in another, and flip between them with the Ctrl+arrow keys. I say, quit killing trees!
Complicated failover systems are expensive, and may not failover correctly anyway. If you want to test the failover functionality, you must use a non-production setup, or jeapordize your production data. For many cases, having a set of RAIDed drives that can be quickly swapped from the failed server to a standby server is sufficient. It is certainly cheaper, and much simpler.
Sheesh, I wonder how I've been running a business with "whereware" and "wishware" for the last four years? I must be dreaming about replying to your post with my "whereware" browser, huh?