All we have here is a couple of analyists saying they believe Compaq is likely to cut development of Digital UNIX[1] on IA-64. Nothing official. Nothing from Compaq.
Now, granted, "Shannon Knows DEC" often gave us great insights into DEC. However, Mr. Shannon also blew it many a time. He's in the business of making predictions, and like weather predictions, they aren't always right. It is also worth pointing out that while Shannon knew DEC, he prolly doesn't know Compaq all that well.
In short: This is much ado about nothing.
I'm not saying it can't happen, just that this bit of information is mere speculation from the outside, and should be taken with a large amount of salt.
[1] I refuse to use the name "Tru64". That is the stupidest name for an OS I have ever heard.
Why oh why can we not travel faster than the speed of light? I want my warp speed!!!
Far as I know, Einstein's theories are still just that -- theories. You have to actually give it (FTL travel) a go to know for sure. But what do I know...
Seriously, NASA are going to have to do some fancy dancing to keep [the common man] interested in their exploration projects.
That has always been the problem with the space science programs. People do not see an immediate benifit to going into space. There is no oil to drill for, no gold to mine, no resources to rape, no buck to be made. Or at least they think so. Pure science and abstract knowledge is all that is left, and that never sells very well to the unwashed masses.
This brief monologue from Babylon 5 is one of the best arguments I've heard for space exploration. The commander in charge of a large space station has just been asked if space exploration is a mistake...
No. We have to stay here and there's a simple reason why. Ask ten different scientists about the environment, population control, genetics and you'll get ten different answers. But there's one thing every scientist on the planet agrees on: Whether it happens in a hundred years or a thousand years or a million years, eventually our Sun will grow cold and go out. When that happens, it won't just take us. It'll take Marilyn Monroe... and Lao-Tzu... and Einstein and Morobuto and Buddy Holly and Aristophenes... and all of this... all of this was for nothing -- unless we go to the stars.
(1) X works, why fix it? (2) CORBA is slow, how can you use it? (3) It is vaporware, ignore it.
In answer to number one: Berlin does not appear to be trying to "fix" X, or anything else. Berlin is trying a new approach to GUI implementation. Yes, they have looked at a number of existing designs, but with the attitude of looking for past mistakes and things to avoid, not "Well, ABC is broken, so we sure don't want to use that!"
In answer to number two: If Berlin was trying to wrap the X wire protocol in CORBA, you can bet it would be slow. But they are not trying to give us a new X Window System. They are trying something new.
One of the key differences is: X is basically concerned with drawing primatives (dot, line, circle, square, etc.). Berlin instead focuses on GUI concepts (window, button, list box, etc.). While X has to draw an entire dialog box pixel-by-pixel, Berlin can just say, "Give me a dialog box." [1] Thus, the slower speed of CORBA matters significantly less.
Incidentally, one of the benifits of the Berlin approach is that it uses less bandwidth. X, on the other hand, uses a lot more bandwidth. Thus, Berlin (or something like it) might be well suited to, e.g., cell phones. [2]
One person mentioned what Jim Gettys had said about Berlin in the past. I was lucky enough to be present when Mr. Gettys spoke at the GNHLUG meeting in August. One of the other meeting-goers asked him about the Berlin project. He seemed fairly neutral on it, saying that X does many things wrong, and that new ideas are worth looking at. His main concern with the use of CORBA seemed to be W.R.T. latency, not raw throughput. In other words, you couldn't implement, e.g., Quake, using Berlin. But, as others have pointed out, there is no reason Berlin cannot incorporate a "high speed" link, negoiated with CORBA, but run outside of it. Indeed, there are already similar efforts with X, as plain X isn't fast enough for Quake, either.
In answer to number three: The Berlin people readily admit that they have a ways to go. Like any software project, it could fall apart and disappear. However, the key difference is vaporware claims to be ready Real Soon Now, and is often used to forstall competition. Berlin doesn't claim to be ready to sweep X away on its irresistable march to glory. [3]
Footnotes: [1] This is over-simplified, but you get the idea. [2] There are low-bandwidth X extensions that also aim to do this. [3] Or, Berlin doesn't anymore. I have read that in the past, some Berlin people were rather more zealous. [4] [4] But, in fairness, that was really an entirely different project.
You will be assimilated. Resistance is futile. Freedom is irrelevant. Standards are irrelevant. All software companies will be assimilated into the Microsoft collective.
Within 10 years, we're going to be dealing with moral questions that we never even dreamed of before.
Read Larry Niven's short story, "The Jigsaw Man". Available in the collection "Tales of Known Space", by same. Mr. Niven saw moral problems related to medical advancements like this back in the 1960's.
For example, if I see a post moderated up to "5" and I think's it's a bonehead post, I would like to de-value the opinions of the moderators who liked that post.
One problem with this is performance: It would require the intersection of moderated comments with your own preferences; I think that would either square the size of the data set or lead to lots of inefficient lists, depending on how you implemented it. I'm not saying it shouldn't be done, just something to be aware of...
There is a CONFIG_SMP flag which controls SMP operation. If defined, the kernel includes multiprocessor support code, and kernel locks are "spinlocks" which work properly accross multiple CPUs. If not defined, the locks are simple set/clear interrupt calls (since if interrupts are disabled, a single CPU machine is not going to be preempted).
I was advocating going beyond this to defining multiple levels of locking granularity, i.e., allowing you to control how finely threaded the kernel is. That is not currently done, AFAIK.
Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo.
I am fairly confident this is not the case with Linux; if you boot an SMP system with a uniprocessor kernel, the second CPU just sits idle, doing nothing more harmful then wasting power and generating excess heat.
The Linux kernel, like any multiprocessor OS, uses "locks" to protect critical sections of code which are not "thread safe". That is, for operations which will get messed up if another CPU starts monkeying with the same data structures, they put guards around any code that reads/writes those data structures.
In order to scale an OS kernel to a large number of processors, you need a larger number of locks accross smaller sections of code, so that there is less chance of contention over particular data structures. Solaris does this, which is one of the reasons it scales to 64 processors so well, but seems sluggish on a uniprocessor system. All those locks cary a significant amount of overhead.
Now, I imagine that we could define multiple "levels" of locks in the kernel. The higher the level, the more "fine grained" that lock is. If the locking functions are preprocessor macros, we could setup configuration flags that determine how fine-grained the kernel locks are.
For a single processor system, those macros simply disable/renable interrupts at lower levels, and are defined to by empty at higher levels. For a two or four CPU system, lower levels are spinlocks, but higher levels are empty, avoiding the overhead of a finely-threaded kernel. For a massively SMP machine (16+ processors), higher levels are empty and lower levels are spinlocks.
This would give you a finely-threaded kernel where the scalability wipes out the overhead of the locks on big machines, but does not impact performance on small machines.
[If he is] just providing data on his web page, which our browsers interpret as links to the forbidden items... he is just spreading his knowledge and information, which must have absolutely no restrictions whatsoever.
Oh, really? Does that mean you will not object if I publish your credit card information on my website?
(Point being: Blanket statements usually make invalid assumptions. Does yours?)
Okay, anyone out there know about the certification they discuss regarding NT?
It is an often pointed at (and laughed at) fact that NT 3.5 has been certified "C2 secure" in accordance with the NSA "Orange Book". However, the configuration used lacked a floppy drive and a network connection. In effect, NT is only secure if you don't communicate with anybody.
Microsoft has been claiming NT 4.0 will be certified Real Soon Now for years. I do not think anyone is holding their breath.:-)
http://www.linuxdoc.org is the home site for the Linux Documentation Project, which is also useful.
The uncompressed kernel source is just under 60 megabytes. Compressed, it is around 12. Text compresses very well.
Note that, in the future, if you ask a question, leaving an email address for replies is a Good Thing. All I can do here is hope you check your info page and see my reply.
While there are some definite troll elements in the original post, they do make a good point: Documentation is useful and important. And I mean, beyond the kernel source instructions themselves. There are a number of reasons for this. I thought they were well-known, perhaps not.
For one, stating the design and then implementing it has been shown to increase code quality. More importantly, it means you know what the code *should* be doing. This makes "Is this a bug?" questions much easier to solve. I've noticed a lot of patches on the linux-kernel list arise from misunderstandings due to unclear code.
Then there is the generally accepted fact that programmers of all skill levels sometimes forget things. How many here have gone back to their own code they wrote six months ago, and said to themselves, "What does this do?" I know some kernel hackers have -- that same phrase shows up in the Linux kernel source!
Linux is contributed to by tens, if not hundreds, of developers. Not *all* of them are going to be Seventh Level Hackers like Linus and Alan. For someone who is, say, just tring to implement an input device driver, it would be nice if some of the magic_kernel_functions() were explained a little clearer.
I'm not saying every function should be documented complete with purpose, arguments, return value, pre- and post-conditions. If someone wants to do that, more power to them, but I'm not saying It Must Be.
However, some things could be added, to positive effect: Top-of-file comments explaining what is contained in a file. Brief comments explaining which a function is supposed to do. A guide to where key kernel structures, macros, etc., come from.
A lot of this stuff was laid out very well in the Kernel Hacker's Guide and similar documents, but they have fallen far out of date. Documention for the 2.2 and 2.3 series kernels is very lacking.
I would try my hand at doing some of this, but frankly, I don't understand much of the kernel myself. I've been reading source lately trying to figure some stuff out, but with almost *SIXTY MEGABYTES* of kernel source, that is a lot of reading!
Place a good-sized charge of C4 (explosives) inside the case. Connect the detonator to tamper switches on all case junctions, and place cut-lines across the panels.
If anyone tries to open that computer to bypass OS and BIOS security, it'll blow itself to pieces, taking the data with it. And prolly the one doing the crack, as an added bonus.
The best place to put the device would be in a empty hard drive case. With the exception of the wiring for the tamper switches (and you could prolly get creative and hide thoses well), it would be indisquishable from a real drive. It would also put the charge right near the data it is designed to destroy.
If you're brave, use a mercury switch so the thing cannot even be moved.
If you're *REALLY* brave, connect a relay to the PSU, so the thing cannot even be *turned off*.
If you ever want access to the system again, replace the keyboard lock with a decent lock, complete with a tamper switch, and still no one will be the wiser.
This is, of course, supreme overkill, and highly dangerous to boot, but I suppose if you really don't want your data getting compromised...
DISCLAIMER: If you actually do this, and then blow up something you wanted (data, a body part, whatever), do not blame me. I said it was dangerous.
I really dislike 3Dfx. Sure, their cards have always been with the pack leaders in terms of performance, but only *if* you use their propriatary, non-portable, unextensible GLide API. Their OpenGL performance is really bad. 3Dfx is extremely protective of their API, too. If you so much as look at it the wrong way -- lawsuit city!
I really, really, *REALLY* hate propriatary APIs. It is like 3Dfx wants us back in the bad-old-days of DOS, where every program had to have its *own* drivers for every piece of hardware out there. If game XYZ didn't support your hardware, you were flat out of luck.
Frankly, it looks to me like they started out as the market leader, but have since lost their edge, and are trying to keep their strangle-hold on the industry by locking people into an API they own. (Hmmmm, sound familar? *cough*Microsoft*cough*)
While the original release of the NVidia drivers were obfusciated (run through the C preprocessor before the source was released), that was due to a lawyer popping up and causing trouble at the last mintue. I was under the impression that the next release after to XFree86 provided regular source code.
I thing Perl is great, and I think Larry Wall is one very heavy-duty hacker, but man, his speeches are we--ird. I swear, he must be high or something to come up with this stuff. It's like a CS class on acid!:-)
From a technogical standpoint, what is most lacking in the kernel? Support for a specific technology (e.g., DVD), implementation of a specific technique, a change in organization, or something else entirely?
Conversely, is there anything you think may happen or is happening that we would be better off without?
I do not agree with some of your assertions. Perhaps the Delphi code you have come across is bad, but that could simply mean you hang around with bad programmers.
I find Delphi to be a very nice GUI IDE, and OP provides most of what C++ does, and some things it does not. Personally, I like Object Pascal (OP) better then C++. But that may be because I learned Turbo Pascal before I learned C, back in the bad old days of MS-DOS.
You are right, in that the lack of C++ style templates is OP's biggest problem. However, the Delphi approach of making lists of TObject is not as bad as it seems. Delphi provides *much* better runtime type support then C++, so TObject is easily converted back to what it was.
Additionally, this lets you compile your collection classes once, and also replace them using dynamic linking. C++ requires full source for everything, and templates must be compiled for each use. Both approaches have advantages and disadvantages. I hope Borland decides to put the choice in the hands of the designer, and adds templates to OP.
Yes, Delphi uses exceptions a lot. This is because they are Delphi's error handling mechanism. Unlike C++, where it is anybody's guess how an error is reported, Delphi will *always* throw an exception. With this in mind, properly designed code is clean and *very* robust. Well done VCL code will recover from errors automatically.
Yes, the IDE gives you a global variable for your forms by default. It does this to make it easier for the VB-weenies who are writting hobby code. I always delete the global declaration immediately. If you do not, well, what can I say, you are not a very good programmer.
If you try to force C, C++, Eiffel, or some other language's mindset on Delphi, yes, you will get ugly code. But that is your fault, not the fault of Delphi. Since you snuck in a plug for Eiffel at the end, and are posting anonymously, I suspect you have an ulterior motive. In any event, I know Delphi to be a good system, and recommend that others developing for Windows (and soon, Linux) check it out.
While true, you have to realize, new hardware is *always* expensive and overpriced. The Pentium III has been on the market for what, half a year? The Athlon is just hitting now. Even the K6 commanded some $$$ when it first hit the market. The market always sells the latest and greatest at a premium, because there are those that will pay any price for *the* very fastest.
Give them some time, and prices should come down. If they don't, *then* you can start worrying.
Of course, the Athlon is supposed to be price-competitive to Intel. Since the Athlon *beats* Intel performance-wise, I'm sure the price will remain at the high-end of the spectrum. Don't expect to see an Athlon in a $399 K-Mart special any time soon.:-)
This is good news! I really like Asus. I find their motherboards are very good quality, without being hugely overpriced. Their tech support is also very good, while a lot of other brands tend to have poor documention written in broken English [1]. It is great to see that Asus has come to their senses and will be supporting Athlon, which by all rights is the best x86 CPU yet. Great to see my favorite motherboard company supporting my favorite microprocessor company!:-)
[1] Hope that doesn't sound too nasty. Often the product is quite good, just an unforunate language barrier is in place. And in their defense, they speak English one heck of a lot better then I speak... heck, I don't even know *what* their language is called, let alone how to speak it! But alas, my fault is still my condition.
It makes sense. Why should Compaq (currently stuggling) fund NT development on the Alpha, when Microsoft has billions of dollars in the bank? NT's only claim on the high-end was the Alpha: If they loose it, they loose even more prestige. If they don't want it, why should Compaq waste their time trying to force it anyway?
Now, the Alpha may be loosing its edge, what with AMD's Athlon at 650 MHz and doing well in performance, but the Alpha is still a much cleaner design then anything Intel-ish. And Merced seems to be turing into yet another extension to the x86 line, instead of leaving the 8086 behind in 1969 like it originally was going to. But that is another story...:-)
Consider that I've hit bugs in GCC but don't know jack about compiler design, and I'm in the same boat either way.:-)
Seriously, while I prefer open source tools, I've found Borland C++Builder (V4) and Delphi (V4) to be solid tools that perform very well. Borland was very responsive to bug reports in C++Builder V4. As some have said, if the tool is good and reasonably priced, open source may not be the deciding vote. I'm sure RMS would disagree, but as I said, it often does not matter.
Slashdot Mirror
All we have here is a couple of analyists saying they believe Compaq is likely to cut development of Digital UNIX[1] on IA-64. Nothing official. Nothing from Compaq.
Now, granted, "Shannon Knows DEC" often gave us great insights into DEC. However, Mr. Shannon also blew it many a time. He's in the business of making predictions, and like weather predictions, they aren't always right. It is also worth pointing out that while Shannon knew DEC, he prolly doesn't know Compaq all that well.
In short: This is much ado about nothing.
I'm not saying it can't happen, just that this bit of information is mere speculation from the outside, and should be taken with a large amount of salt.
[1] I refuse to use the name "Tru64". That is the stupidest name for an OS I have ever heard.
Far as I know, Einstein's theories are still just that -- theories. You have to actually give it (FTL travel) a go to know for sure. But what do I know...
Seriously, NASA are going to have to do some fancy dancing to keep [the common man] interested in their exploration projects.
That has always been the problem with the space science programs. People do not see an immediate benifit to going into space. There is no oil to drill for, no gold to mine, no resources to rape, no buck to be made. Or at least they think so. Pure science and abstract knowledge is all that is left, and that never sells very well to the unwashed masses.
This brief monologue from Babylon 5 is one of the best arguments I've heard for space exploration. The commander in charge of a large space station has just been asked if space exploration is a mistake...
A lot of people have posted comments like:
(1) X works, why fix it?
(2) CORBA is slow, how can you use it?
(3) It is vaporware, ignore it.
In answer to number one: Berlin does not appear to be trying to "fix" X, or anything else. Berlin is trying a new approach to GUI implementation. Yes, they have looked at a number of existing designs, but with the attitude of looking for past mistakes and things to avoid, not "Well, ABC is broken, so we sure don't want to use that!"
In answer to number two: If Berlin was trying to wrap the X wire protocol in CORBA, you can bet it would be slow. But they are not trying to give us a new X Window System. They are trying something new.
One of the key differences is: X is basically concerned with drawing primatives (dot, line, circle, square, etc.). Berlin instead focuses on GUI concepts (window, button, list box, etc.). While X has to draw an entire dialog box pixel-by-pixel, Berlin can just say, "Give me a dialog box." [1] Thus, the slower speed of CORBA matters significantly less.
Incidentally, one of the benifits of the Berlin approach is that it uses less bandwidth. X, on the other hand, uses a lot more bandwidth. Thus, Berlin (or something like it) might be well suited to, e.g., cell phones. [2]
One person mentioned what Jim Gettys had said about Berlin in the past. I was lucky enough to be present when Mr. Gettys spoke at the GNHLUG meeting in August. One of the other meeting-goers asked him about the Berlin project. He seemed fairly neutral on it, saying that X does many things wrong, and that new ideas are worth looking at. His main concern with the use of CORBA seemed to be W.R.T. latency, not raw throughput. In other words, you couldn't implement, e.g., Quake, using Berlin. But, as others have pointed out, there is no reason Berlin cannot incorporate a "high speed" link, negoiated with CORBA, but run outside of it. Indeed, there are already similar efforts with X, as plain X isn't fast enough for Quake, either.
In answer to number three: The Berlin people readily admit that they have a ways to go. Like any software project, it could fall apart and disappear. However, the key difference is vaporware claims to be ready Real Soon Now, and is often used to forstall competition. Berlin doesn't claim to be ready to sweep X away on its irresistable march to glory. [3]
Footnotes:
[1] This is over-simplified, but you get the idea.
[2] There are low-bandwidth X extensions that also aim to do this.
[3] Or, Berlin doesn't anymore. I have read that in the past, some Berlin people were rather more zealous. [4]
[4] But, in fairness, that was really an entirely different project.
You will be assimilated. Resistance is futile. Freedom is irrelevant. Standards are irrelevant. All software companies will be assimilated into the Microsoft collective.
Within 10 years, we're going to be dealing with moral questions that we never even dreamed of before.
Read Larry Niven's short story, "The Jigsaw Man". Available in the collection "Tales of Known Space", by same. Mr. Niven saw moral problems related to medical advancements like this back in the 1960's.
For example, if I see a post moderated up to "5" and I think's it's a bonehead post, I would like to de-value the opinions of the moderators who liked that post.
One problem with this is performance: It would require the intersection of moderated comments with your own preferences; I think that would either square the size of the data set or lead to lots of inefficient lists, depending on how you implemented it. I'm not saying it shouldn't be done, just something to be aware of...
I thought Linux had build flags to that effect
:-)
There is a CONFIG_SMP flag which controls SMP operation. If defined, the kernel includes multiprocessor support code, and kernel locks are "spinlocks" which work properly accross multiple CPUs. If not defined, the locks are simple set/clear interrupt calls (since if interrupts are disabled, a single CPU machine is not going to be preempted).
I was advocating going beyond this to defining multiple levels of locking granularity, i.e., allowing you to control how finely threaded the kernel is. That is not currently done, AFAIK.
Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo.
I am fairly confident this is not the case with Linux; if you boot an SMP system with a uniprocessor kernel, the second CPU just sits idle, doing nothing more harmful then wasting power and generating excess heat.
Of course, I have been wrong before. I think.
The Linux kernel, like any multiprocessor OS, uses "locks" to protect critical sections of code which are not "thread safe". That is, for operations which will get messed up if another CPU starts monkeying with the same data structures, they put guards around any code that reads/writes those data structures.
:-)
In order to scale an OS kernel to a large number of processors, you need a larger number of locks accross smaller sections of code, so that there is less chance of contention over particular data structures. Solaris does this, which is one of the reasons it scales to 64 processors so well, but seems sluggish on a uniprocessor system. All those locks cary a significant amount of overhead.
Now, I imagine that we could define multiple "levels" of locks in the kernel. The higher the level, the more "fine grained" that lock is. If the locking functions are preprocessor macros, we could setup configuration flags that determine how fine-grained the kernel locks are.
For a single processor system, those macros simply disable/renable interrupts at lower levels, and are defined to by empty at higher levels. For a two or four CPU system, lower levels are spinlocks, but higher levels are empty, avoiding the overhead of a finely-threaded kernel. For a massively SMP machine (16+ processors), higher levels are empty and lower levels are spinlocks.
This would give you a finely-threaded kernel where the scalability wipes out the overhead of the locks on big machines, but does not impact performance on small machines.
No, I have no idea if this will work.
Comments, anyone?
When a jury sides with the defendant, they have could THEN have a vote on whether the suit was frivolous
/. recently. What do you call this idea... MetaJury? MetaJustice? :-)
Hmmmm... sounds similar to a system implemented here on
[If he is] just providing data on his web page, which our browsers interpret as links to the forbidden items ... he is just spreading his knowledge and information, which must have absolutely no restrictions whatsoever.
Oh, really? Does that mean you will not object if I publish your credit card information on my website?
(Point being: Blanket statements usually make invalid assumptions. Does yours?)
Okay, anyone out there know about the certification they discuss regarding NT?
:-)
It is an often pointed at (and laughed at) fact that NT 3.5 has been certified "C2 secure" in accordance with the NSA "Orange Book". However, the configuration used lacked a floppy drive and a network connection. In effect, NT is only secure if you don't communicate with anybody.
Microsoft has been claiming NT 4.0 will be certified Real Soon Now for years. I do not think anyone is holding their breath.
http://www.kernel.org is the home site for the Linux kernel distribution.
http://www.linuxdoc.org is the home site for the Linux Documentation Project, which is also useful.
The uncompressed kernel source is just under 60 megabytes. Compressed, it is around 12. Text compresses very well.
Note that, in the future, if you ask a question, leaving an email address for replies is a Good Thing. All I can do here is hope you check your info page and see my reply.
Without those ads you are proxy-filtering out, the services you are using to complain about them would not exit. TANSTAAFL.
While there are some definite troll elements in the original post, they do make a good point: Documentation is useful and important. And I mean, beyond the kernel source instructions themselves. There are a number of reasons for this. I thought they were well-known, perhaps not.
:-)
For one, stating the design and then implementing it has been shown to increase code quality. More importantly, it means you know what the code *should* be doing. This makes "Is this a bug?" questions much easier to solve. I've noticed a lot of patches on the linux-kernel list arise from misunderstandings due to unclear code.
Then there is the generally accepted fact that programmers of all skill levels sometimes forget things. How many here have gone back to their own code they wrote six months ago, and said to themselves, "What does this do?" I know some kernel hackers have -- that same phrase shows up in the Linux kernel source!
Linux is contributed to by tens, if not hundreds, of developers. Not *all* of them are going to be Seventh Level Hackers like Linus and Alan. For someone who is, say, just tring to implement an input device driver, it would be nice if some of the magic_kernel_functions() were explained a little clearer.
I'm not saying every function should be documented complete with purpose, arguments, return value, pre- and post-conditions. If someone wants to do that, more power to them, but I'm not saying It Must Be.
However, some things could be added, to positive effect: Top-of-file comments explaining what is contained in a file. Brief comments explaining which a function is supposed to do. A guide to where key kernel structures, macros, etc., come from.
A lot of this stuff was laid out very well in the Kernel Hacker's Guide and similar documents, but they have fallen far out of date. Documention for the 2.2 and 2.3 series kernels is very lacking.
I would try my hand at doing some of this, but frankly, I don't understand much of the kernel myself. I've been reading source lately trying to figure some stuff out, but with almost *SIXTY MEGABYTES* of kernel source, that is a lot of reading!
Just my 1/4 of a byte.
Place a good-sized charge of C4 (explosives) inside the case. Connect the detonator to tamper switches on all case junctions, and place cut-lines across the panels.
If anyone tries to open that computer to bypass OS and BIOS security, it'll blow itself to pieces, taking the data with it. And prolly the one doing the crack, as an added bonus.
The best place to put the device would be in a empty hard drive case. With the exception of the wiring for the tamper switches (and you could prolly get creative and hide thoses well), it would be indisquishable from a real drive. It would also put the charge right near the data it is designed to destroy.
If you're brave, use a mercury switch so the thing cannot even be moved.
If you're *REALLY* brave, connect a relay to the PSU, so the thing cannot even be *turned off*.
If you ever want access to the system again, replace the keyboard lock with a decent lock, complete with a tamper switch, and still no one will be the wiser.
This is, of course, supreme overkill, and highly dangerous to boot, but I suppose if you really don't want your data getting compromised...
DISCLAIMER: If you actually do this, and then blow up something you wanted (data, a body part, whatever), do not blame me. I said it was dangerous.
I really dislike 3Dfx. Sure, their cards have always been with the pack leaders in terms of performance, but only *if* you use their propriatary, non-portable, unextensible GLide API. Their OpenGL performance is really bad. 3Dfx is extremely protective of their API, too. If you so much as look at it the wrong way -- lawsuit city!
I really, really, *REALLY* hate propriatary APIs. It is like 3Dfx wants us back in the bad-old-days of DOS, where every program had to have its *own* drivers for every piece of hardware out there. If game XYZ didn't support your hardware, you were flat out of luck.
Frankly, it looks to me like they started out as the market leader, but have since lost their edge, and are trying to keep their strangle-hold on the industry by locking people into an API they own. (Hmmmm, sound familar? *cough*Microsoft*cough*)
No thank you.
While the original release of the NVidia drivers were obfusciated (run through the C preprocessor before the source was released), that was due to a lawyer popping up and causing trouble at the last mintue. I was under the impression that the next release after to XFree86 provided regular source code.
Am I wrong?
I thing Perl is great, and I think Larry Wall is one very heavy-duty hacker, but man, his speeches are we--ird. I swear, he must be high or something to come up with this stuff. It's like a CS class on acid! :-)
From a technogical standpoint, what is most lacking in the kernel? Support for a specific technology (e.g., DVD), implementation of a specific technique, a change in organization, or something else entirely?
Conversely, is there anything you think may happen or is happening that we would be better off without?
I do not agree with some of your assertions. Perhaps the Delphi code you have come across is bad, but that could simply mean you hang around with bad programmers.
I find Delphi to be a very nice GUI IDE, and OP provides most of what C++ does, and some things it does not. Personally, I like Object Pascal (OP) better then C++. But that may be because I learned Turbo Pascal before I learned C, back in the bad old days of MS-DOS.
You are right, in that the lack of C++ style templates is OP's biggest problem. However, the Delphi approach of making lists of TObject is not as bad as it seems. Delphi provides *much* better runtime type support then C++, so TObject is easily converted back to what it was.
Additionally, this lets you compile your collection classes once, and also replace them using dynamic linking. C++ requires full source for everything, and templates must be compiled for each use. Both approaches have advantages and disadvantages. I hope Borland decides to put the choice in the hands of the designer, and adds templates to OP.
Yes, Delphi uses exceptions a lot. This is because they are Delphi's error handling mechanism. Unlike C++, where it is anybody's guess how an error is reported, Delphi will *always* throw an exception. With this in mind, properly designed code is clean and *very* robust. Well done VCL code will recover from errors automatically.
Yes, the IDE gives you a global variable for your forms by default. It does this to make it easier for the VB-weenies who are writting hobby code. I always delete the global declaration immediately. If you do not, well, what can I say, you are not a very good programmer.
If you try to force C, C++, Eiffel, or some other language's mindset on Delphi, yes, you will get ugly code. But that is your fault, not the fault of Delphi. Since you snuck in a plug for Eiffel at the end, and are posting anonymously, I suspect you have an ulterior motive. In any event, I know Delphi to be a good system, and recommend that others developing for Windows (and soon, Linux) check it out.
While true, you have to realize, new hardware is *always* expensive and overpriced. The Pentium III has been on the market for what, half a year? The Athlon is just hitting now. Even the K6 commanded some $$$ when it first hit the market. The market always sells the latest and greatest at a premium, because there are those that will pay any price for *the* very fastest.
:-)
Give them some time, and prices should come down. If they don't, *then* you can start worrying.
Of course, the Athlon is supposed to be price-competitive to Intel. Since the Athlon *beats* Intel performance-wise, I'm sure the price will remain at the high-end of the spectrum. Don't expect to see an Athlon in a $399 K-Mart special any time soon.
... are at Ace's Hardware.
(An anonymous coward posted the link, I am reposting for those filtering less then moderation level 1.)
This is good news! I really like Asus. I find their motherboards are very good quality, without being hugely overpriced. Their tech support is also very good, while a lot of other brands tend to have poor documention written in broken English [1]. It is great to see that Asus has come to their senses and will be supporting Athlon, which by all rights is the best x86 CPU yet. Great to see my favorite motherboard company supporting my favorite microprocessor company! :-)
[1] Hope that doesn't sound too nasty. Often the product is quite good, just an unforunate language barrier is in place. And in their defense, they speak English one heck of a lot better then I speak... heck, I don't even know *what* their language is called, let alone how to speak it! But alas, my fault is still my condition.
It makes sense. Why should Compaq (currently stuggling) fund NT development on the Alpha, when Microsoft has billions of dollars in the bank? NT's only claim on the high-end was the Alpha: If they loose it, they loose even more prestige. If they don't want it, why should Compaq waste their time trying to force it anyway?
:-)
Now, the Alpha may be loosing its edge, what with AMD's Athlon at 650 MHz and doing well in performance, but the Alpha is still a much cleaner design then anything Intel-ish. And Merced seems to be turing into yet another extension to the x86 line, instead of leaving the 8086 behind in 1969 like it originally was going to. But that is another story...
Consider that I've hit bugs in GCC but don't know jack about compiler design, and I'm in the same boat either way. :-)
:-)
Seriously, while I prefer open source tools, I've found Borland C++Builder (V4) and Delphi (V4) to be solid tools that perform very well. Borland was very responsive to bug reports in C++Builder V4. As some have said, if the tool is good and reasonably priced, open source may not be the deciding vote. I'm sure RMS would disagree, but as I said, it often does not matter.
All IMNSHO, of course.