Just like computer languages, our "human" languages lend themselves to particular uses, i.e. they are good for some things, and bad for others.
Example: You can easily write a code parser in prolog to verify its correctness... in fact you can write a prolog compiler in prolog with little to no difficulty...
However in C/C++ writing a code parser is a huge pain in the ass. Also, when was the last time you cranked out a C++ compiler (that is correct!) in a few lines.
However prolog does not have many of the features (OO) that C++ has... so it is good for some things, not others...
My point: Some computer languages are good for some things, and not for others...
This is extremely true for human languages. Some languages such as german lend themselves very well towards technical description. Ever see technical manuals from Europe? They are mostly in German for a reason... it is very easy to describe physical aspects of machines in German.
Another example: Mainland chinese. There are many many dialects spoken in China... however they all share several common features. They lend themselves very well to poetry and literature. The descriptive capability of the language is "better" than English...
So why do we end up using English? Well, its easy. And many people don't like the answer (because Americans think thier language is superior because "everyone" speaks it) The answer is because English is terse, and weak, and unambiguous. There is some ambiguity dont, get me wrong, but we don't exactly have 2000 different words for the sun, like some languages do. We have a limited vocabulary, and the language itself is short and to the point. This is why we use it to code in.
What do other countries code in? Most romance languages are very similar to English, so in Europe it is not uncommon for there to be code in other languages (how do they compile it? I dont know). However in India, China, Japan, most people code in English, as it is significantly less ambiguous then thier own languages. Also, who wants a keyboard with 4000 symbols on it? Romance languages also feature a limited but usefull character set, which also plays an important role.
Im sure there will be flames now, but if you stop and think, how many synonyms do you know for earth? The Native Americans had several dozen. We have very few.
On the website it states it's the world smallest computer. That is BS. There is a site at stanford that has a K6 processor and an LCD with a 340mb hard disk for about twice the price of this. The real difference? The other one is about 5 inches by 3 inches.
You know a lot of people went around religiously chanting that this was not a real product, and the pictures had been faked. You were all idiots. Next time why don't you sit back and look at the facts before you join the ranks of zealots.
Yes, it was hard to tell, but you saw tons of things like "I zoomed in real close on the picture, and I see that the font is not an Apple font, so the picture is a fake". Fools.
This is amazingly *not* new. There has been a method of emailing people that uses this *exact* same method for 2 years now. That method allowed transfer of files only through emailing them. This project seems to take it a little further (not much though). I cannot remember the name of the project, but Im sure someone will post it below somewhere. Additionally, the point here is not to say the data could not be unencrypted along the way. The primary focus here is to hide the sender and the reciever as much as possible. For all of you who are saying things like "this won't work" and "we need proof of concept" and "this is trivial to crack" you are incorrect. It *will* work. There *is* proof of concept (with the email network that is amazingly similar) and its almost impossible to crack without gathering information from each server along the route. You all need to think about the scale on which this could be done. Sure between 5 servers, no big deal. But you would inentionally create long routes in order to hide the reciever and sender. When your data goes through 200 servers each time, and is slightly decrypted for each step, then there is a good amount of peace of mind there. The web page does not describe what they are planning in very much detail. That is probably why there is so much confusion. After reading the web page I wonder if he knows what he is doing. The idea would work though -Kevin Kamel
This article is a bunch of BS. I work in the field they speak of, and there is *no freakin way* that they would be able to deorbit any significant amount of debris with this method.
There is so much debris there, all of it moving with different attitude and velocity. To send up a single sattelite or a hundred or a thousand would not be able to deal with the situation. Everything that you have ever read about this topic has been conservative at best. It is so out of control that they are now trying to launch a PR campaign (this sattelite) to try and look mildy responsible.
The biggest problems are larger pieces of debris (over 10cm), since they have enough inertia to plow right through our functioning sattelites. So its over 10cm, and moving at tremendous velocity. How the hell do they think they are going to catch it for one (radar is accurate, but accurate down to cm? mm? no way) and the amount of force required to deccelerate the object would quickly deplete the fuel reserves of the spacecraft.
Additionally there isn't very much to be gained by decellerating debris anyway. Changing its inclination yes, but slowing it down? I can't see how that would help at all. Debris under about 1000km usually exits (unless its abnormally dense) in 25-30 years anyway (which is the current NASA NPD).
Probably the best thing that anyone can do (and they are doing it)is to monitor current programs and make sure they won't produce MORE debris. This way in a few years (40 or so) the biggest and most dangerous debris will have burned up, and we will have less debris to deal with.
For more information check out orbitaldebris.jsc.nasa.gov, that is the website for the Code QS program that tries to monitor current spacecraft and make sure they are compliant with the new guidelines. There is also a quarterly OD newsletter there.
Well, let see here. Supposedly this affects all kernels 2.2.15 and lower. Oddly Im 2.2.14, and I can't seem to reproduce this. I tried some of the source posted here, I tried some of my own code, and I tried some other stuff Ive found related to this. None of it seems to do what everyone says.
I thought this problem was part of the default kernel? Perhaps I didn't choose to compile a piece of the kernel that effected this?
It is a relatively unknown fact that NASA can no longer support a mission to the moon. Yes, we had the technology, no we don't have it anymore. It was accidentally (dont even ask how, its ridiculous) destroyed. The ELV that took men to the moon in the 60s no longer exists, and there have never been attempts to create another one like it. In addition, I find it *extremely* unlikely that NASA would support (and they WOULD need NASA support) a mission like this. It's frankly too risky technologically (they would need to proof test everything, that takes YEARS), safety (they would need to PROVE everything was safe, also years), and even the Orbital Debris aspects (something that takes several months to prepare) would be unlikely to pass the guidelines. It just isn't going to happen. I wish it would, but it won't. And yes, I am informed, I work at GSFC. Kevin Kamel
Ive said it once and Ill say it again. The author is a jackass. He never seems to know exactly what he is talking about. While Linux is not invincible as most would believe, it is arguably *much* better than windows 95/98 with respect to virii. Although I agree with the author with his idea that everyday people, who run *everything* as root are prone to problems, if you are a competent *ix user, even an admin, you are far better protected from Virii than you would be on a win 95/98 (and I bet Milly too...) KAMEL
For those who are unaware, nvidia has a poor history relating to OGL already. I hate to see what they would do to a project like this.
Right now nVidia is poorly supporting thier own OGL glx modules for linux.
First they claimed they would open up and provide all necessary knowledge to write good gl modules for thier cards. They lied.
Then finally they were convinced that *some* level of support was required, so they started to write thier own glx modules. They are actually pretty good and the source it provided....
HOWEVER, they are not fostering any development by other teams whatsoever. They dont document how thier hardware works, and other groups have a very difficult time understanding what the hell is going on within the code.
For example you know from the code that someone is playing with register XX, but you cant actually figure out what that register does, or how to manipulate it properly... kind of annoying, especially when nvidia has problems fixing thier own bugs (and the performance aint so hot either)
Seeing how SGI has been partially helpfull to Brian Paul and Kilgard in the past, I hope that this project will turn out OK. I just wouldnt expect nvidia to be very much help here...
This is a FINAL release of Mandrake 7. It isnt the beta anymore. The beta RPMS was released officially last month. User created ISOs followed.
This version is in fact FINAL. They still have many bugs to fix, but they are releasing it anyway.
Everyone here seems to think this is an extension of the beta program. It is not. They are going to use the ISO images they are distributing now in the retail copies they will start selling in february.
I own one of the optical mice, actually I bought it the first day it was released in stores.
It has several issues people should know about though. It doesnt work on glass or reflective surfaces (the LED doesnt get picked up properly by the imager on them), also it doesnt work too well with glazed surfaces (like a shiny table surface), it does work really well on textured surfaces though, a mouse pad works well, so does a book cover etc.
It has some really bad problems with fast mouse moving though. You cant just move the mouse around ultra quick as one would in a game of quake. The optical "camera" inside the mouse cant track the surface fast enough, so it loses its tracking and the mouse goes crazy. Sucks. The only solution is the crank the mouse to a high resolution in whatever game your playing (assuming the game requires quick mousing).
The mouse also works great under windows (both USB and PS2), and works well under Linux (ps2), however it cannot function as a serial device, as the current supplied by the serial port is not enough to supply the LED and camera within the mouse, so using a PS2 to serial converter will not work.
All in all its a pretty neat device, and works with everything after a bit of tweaking. I personally hate cleaning ball mice, so I really like it.
Slashdot Mirror
Just like computer languages, our "human" languages lend themselves to particular uses, i.e. they are good for some things, and bad for others.
Example: You can easily write a code parser in prolog to verify its correctness... in fact you can write a prolog compiler in prolog with little to no difficulty...
However in C/C++ writing a code parser is a huge pain in the ass. Also, when was the last time you cranked out a C++ compiler (that is correct!) in a few lines.
However prolog does not have many of the features (OO) that C++ has... so it is good for some things, not others...
My point: Some computer languages are good for some things, and not for others...
This is extremely true for human languages. Some languages such as german lend themselves very well towards technical description. Ever see technical manuals from Europe? They are mostly in German for a reason... it is very easy to describe physical aspects of machines in German.
Another example: Mainland chinese. There are many many dialects spoken in China... however they all share several common features. They lend themselves very well to poetry and literature. The descriptive capability of the language is "better" than English...
So why do we end up using English? Well, its easy. And many people don't like the answer (because Americans think thier language is superior because "everyone" speaks it) The answer is because English is terse, and weak, and unambiguous. There is some ambiguity dont, get me wrong, but we don't exactly have 2000 different words for the sun, like some languages do. We have a limited vocabulary, and the language itself is short and to the point. This is why we use it to code in.
What do other countries code in? Most romance languages are very similar to English, so in Europe it is not uncommon for there to be code in other languages (how do they compile it? I dont know). However in India, China, Japan, most people code in English, as it is significantly less ambiguous then thier own languages. Also, who wants a keyboard with 4000 symbols on it? Romance languages also feature a limited but usefull character set, which also plays an important role.
Im sure there will be flames now, but if you stop and think, how many synonyms do you know for earth? The Native Americans had several dozen. We have very few.
Just another example...
On the website it states it's the world smallest computer. That is BS. There is a site at stanford that has a K6 processor and an LCD with a 340mb hard disk for about twice the price of this. The real difference? The other one is about 5 inches by 3 inches.
Without the LCD its even thinner.
You know a lot of people went around religiously chanting that this was not a real product, and the pictures had been faked. You were all idiots. Next time why don't you sit back and look at the facts before you join the ranks of zealots.
Yes, it was hard to tell, but you saw tons of things like "I zoomed in real close on the picture, and I see that the font is not an Apple font, so the picture is a fake". Fools.
This is amazingly *not* new. There has been a method of emailing people that uses this *exact* same method for 2 years now. That method allowed transfer of files only through emailing them. This project seems to take it a little further (not much though). I cannot remember the name of the project, but Im sure someone will post it below somewhere. Additionally, the point here is not to say the data could not be unencrypted along the way. The primary focus here is to hide the sender and the reciever as much as possible. For all of you who are saying things like "this won't work" and "we need proof of concept" and "this is trivial to crack" you are incorrect. It *will* work. There *is* proof of concept (with the email network that is amazingly similar) and its almost impossible to crack without gathering information from each server along the route. You all need to think about the scale on which this could be done. Sure between 5 servers, no big deal. But you would inentionally create long routes in order to hide the reciever and sender. When your data goes through 200 servers each time, and is slightly decrypted for each step, then there is a good amount of peace of mind there. The web page does not describe what they are planning in very much detail. That is probably why there is so much confusion. After reading the web page I wonder if he knows what he is doing. The idea would work though -Kevin Kamel
This article is a bunch of BS. I work in the field they speak of, and there is *no freakin way* that they would be able to deorbit any significant amount of debris with this method.
There is so much debris there, all of it moving with different attitude and velocity. To send up a single sattelite or a hundred or a thousand would not be able to deal with the situation. Everything that you have ever read about this topic has been conservative at best. It is so out of control that they are now trying to launch a PR campaign (this sattelite) to try and look mildy responsible.
The biggest problems are larger pieces of debris (over 10cm), since they have enough inertia to plow right through our functioning sattelites. So its over 10cm, and moving at tremendous velocity. How the hell do they think they are going to catch it for one (radar is accurate, but accurate down to cm? mm? no way) and the amount of force required to deccelerate the object would quickly deplete the fuel reserves of the spacecraft.
Additionally there isn't very much to be gained by decellerating debris anyway. Changing its inclination yes, but slowing it down? I can't see how that would help at all. Debris under about 1000km usually exits (unless its abnormally dense) in 25-30 years anyway (which is the current NASA NPD).
Probably the best thing that anyone can do (and they are doing it)is to monitor current programs and make sure they won't produce MORE debris. This way in a few years (40 or so) the biggest and most dangerous debris will have burned up, and we will have less debris to deal with.
For more information check out orbitaldebris.jsc.nasa.gov, that is the website for the Code QS program that tries to monitor current spacecraft and make sure they are compliant with the new guidelines. There is also a quarterly OD newsletter there.
Well, let see here. Supposedly this affects all kernels 2.2.15 and lower. Oddly Im 2.2.14, and I can't seem to reproduce this. I tried some of the source posted here, I tried some of my own code, and I tried some other stuff Ive found related to this. None of it seems to do what everyone says.
I thought this problem was part of the default kernel? Perhaps I didn't choose to compile a piece of the kernel that effected this?
It is a relatively unknown fact that NASA can no longer support a mission to the moon. Yes, we had the technology, no we don't have it anymore. It was accidentally (dont even ask how, its ridiculous) destroyed. The ELV that took men to the moon in the 60s no longer exists, and there have never been attempts to create another one like it. In addition, I find it *extremely* unlikely that NASA would support (and they WOULD need NASA support) a mission like this. It's frankly too risky technologically (they would need to proof test everything, that takes YEARS), safety (they would need to PROVE everything was safe, also years), and even the Orbital Debris aspects (something that takes several months to prepare) would be unlikely to pass the guidelines. It just isn't going to happen. I wish it would, but it won't. And yes, I am informed, I work at GSFC. Kevin Kamel
Ive said it once and Ill say it again. The author is a jackass. He never seems to know exactly what he is talking about. While Linux is not invincible as most would believe, it is arguably *much* better than windows 95/98 with respect to virii. Although I agree with the author with his idea that everyday people, who run *everything* as root are prone to problems, if you are a competent *ix user, even an admin, you are far better protected from Virii than you would be on a win 95/98 (and I bet Milly too...) KAMEL
For those who are unaware, nvidia has a poor history relating to OGL already. I hate to see what they would do to a project like this.
Right now nVidia is poorly supporting thier own OGL glx modules for linux.
First they claimed they would open up and provide all necessary knowledge to write good gl modules for thier cards. They lied.
Then finally they were convinced that *some* level of support was required, so they started to write thier own glx modules. They are actually pretty good and the source it provided....
HOWEVER, they are not fostering any development by other teams whatsoever. They dont document how thier hardware works, and other groups have a very difficult time understanding what the hell is going on within the code.
For example you know from the code that someone is playing with register XX, but you cant actually figure out what that register does, or how to manipulate it properly... kind of annoying, especially when nvidia has problems fixing thier own bugs (and the performance aint so hot either)
Seeing how SGI has been partially helpfull to Brian Paul and Kilgard in the past, I hope that this project will turn out OK. I just wouldnt expect nvidia to be very much help here...
This is a FINAL release of Mandrake 7. It isnt the beta anymore. The beta RPMS was released officially last month. User created ISOs followed.
This version is in fact FINAL. They still have many bugs to fix, but they are releasing it anyway.
Everyone here seems to think this is an extension of the beta program. It is not. They are going to use the ISO images they are distributing now in the retail copies they will start selling in february.
I own one of the optical mice, actually I bought it the first day it was released in stores.
It has several issues people should know about though. It doesnt work on glass or reflective surfaces (the LED doesnt get picked up properly by the imager on them), also it doesnt work too well with glazed surfaces (like a shiny table surface), it does work really well on textured surfaces though, a mouse pad works well, so does a book cover etc.
It has some really bad problems with fast mouse moving though. You cant just move the mouse around ultra quick as one would in a game of quake. The optical "camera" inside the mouse cant track the surface fast enough, so it loses its tracking and the mouse goes crazy. Sucks. The only solution is the crank the mouse to a high resolution in whatever game your playing (assuming the game requires quick mousing).
The mouse also works great under windows (both USB and PS2), and works well under Linux (ps2), however it cannot function as a serial device, as the current supplied by the serial port is not enough to supply the LED and camera within the mouse, so using a PS2 to serial converter will not work.
All in all its a pretty neat device, and works with everything after a bit of tweaking. I personally hate cleaning ball mice, so I really like it.
KAMEL