It's not as good as it sounds (at least in the/. blurb). He isn't claiming superconductors block graviational fields, he's claiming they block "gravitomagnetic" fields, which is the gravitational analog of the magnetic field. What you would normally consider a gravitational field would be a "gravitoelectric" field.
That being said, it still would be immensely cool. For one thing, it would correspond to the first detection of gravity waves!
Whether he is right or wrong is imaterial (to the scientific process), his theory is interesting enough that some experimentalist will pick this up and run with and then we'll find out whether the theory is correct (or not).
Actually, Raymond is an experimentalist, and is already working on the experiment! (He's also a very nice guy.)
If you really can't wait, make a woody netinst cd with the Progeny installer. Or can you not type "apt-get install pgi" successfully?
Although, I am also highly optimistic about pgi, I'm afraid this is easier said than done. The pgi installer-maker requires you to have a full debian mirror locally available. Alas, I don't have that kind of free disk space myself, and I'm guessing most people don't.
Someone will probably make one of these available with the progeny installer after woody's release.
I agree with you here. I think a pgi woody installer will be very helpful, and am certain that someone will make images available.
You should try debian. Debian works very hard to make sure their packages work on all their platforms (which, of course, includes powerpc). This involves seeking out and fixing the endianness/signed char issues that keep packages from being portable. Eventually those patches (in theory, at least) make their way upstream.
That being said, even on debian, other architectures are in a sense second class, since most of the developers use the i386 platform. This means that packages get autobuilt more slowly on powerpc, for example, but on the whole, it's a great powerpc distro.
This is a great point, what I see as the most significant effect of piracy. Allowing piracy of its software is how microsoft (and adobe, and others) maintains its monopoly.
Because the expensive products are available for free to anyone willing to pirate them (read individuals), it is virtually impossible for their competitors to gain market share. Who would buy a $25 word processor instead of buying MS Word, when they could just copy MS Word from a friend?
Even more so for photoshop. I have more than one friend who justify pirating photoshop because they would never pay for it anyways. But the big loser to piracy is not the major corporations, since individuals would never pay $600 for photoshop anyways, but rather their competitors, who try to sell cheaper versions, or Free Software competitors such as gimp.
As I see it, the single best way to harm the existing monopolies would be to eliminate piracy, and I think that would be a Good Thing.
I'd say because you would want a full sized keyboard and 15" screen, which wouldn't go into an ibook. And by not miniaturizing the other parts, you could cut costs significantly relative to a laptop.
I'm sorry, but Qt (for X windows anyways) is available under the GPL. How can it get more open source than that? Admittedly, Qt is not cross-platform and open source, but KDE isn't cross-platform anyways.
I am not an expert on quantum computing, but I am a physicist and have some idea of what would be needed to actually make such a beast.
* is semi-conductor quantum computing any more viable in the long-term than whatever other vaporous methods are being investigated?
Well, that's sort of hard to say. It's not at all clear that there is a viable method for making a quantum computer. Certainly the Purdue work here is a long way from creating a quantum computer.
* how different is it in terms of the equipment required, and what would this mean for scalability?
Well, they don't have a method for fabricating any sort of computer (or even an xor or controlled not gate) out of these things, but you'd be lucky to run it at liquid helium temperatures (4K).
* which method of quantum computing would require the least power, and could be likely to be miniaturised the best? At the moment it seems the actual computing area is very small, but the equipment required to read output is inhibitively large
Well, I think with a quantum computer power consumption is not an issue, the question is whether you can create a computer with hundreds of qubits. There is also the problem that a quantum computer is an analog rather than a digital computer, so achieving the necesary precision is a challenge, to say the least.
* how fast, really , would a semi-decent quantum processor be, compared to a semi-decent silicon one? (This may seem like an ignorant or even trolling question, so I apologise in advance)
It's a good question. A quantum computer would be extremely slow. However, for a couple of problems (such as factorization of very large numbers), a quantum computer may be many orders of magnitude faster than a conventional computer.
The biggest issue (as I mentioned before) is that it is an analog computer, which means that unlike a digital computer, any small stray electromagnetic fields will introduce errors into the computation, which is quite a serious issue. My personal belief is that quite likely quantum computation is not possible, although I must admit that I haven't looked into it all that carefully. Certainly, switching to analog computing seems like a step backwards, and could be expected to put a practical limit on the size of such a computer, which may very well keep it from being useful.
Perhaps I should mention that debian treats ppc pretty much the same as i386, which means stable doesn't have up to date packages, but if you go testing or unstable you get pretty much the same packages as i386, all but the buggy codes that won't compile due to endianness issues or stuff like that. But even those packages are often ported over (with bugs fixed) eventually, since they can't get into testing if they won't compile on all supported platforms.
I'm sure the mandrake install is easier than debian's, though...
I disagree with his statement that the type of a file is immutable data. It is not. I have, many times, created a text file, written some html, and renamed it ".html" to load it in a web browser.
I'm afraid you misunderstood his definition of immutable. In this example, you changed the data, and what was originally a plain text file became an HTML file. His definition of immutable was that if the file data changed, then its type did not change.
Also, it didn't mean that the metadata need be unchangable, since it could be changed to reflect greater precision, or if it was wrong in the first place. For example, an html file is a text file (but more). So it is entirely reasonable to change the type from text to html (provided it actually is).
slashdot.pl and slashdot.txt should NOT collide on my desktop...
I agree that slashdot.pl and slashdot.txt should not collide, but that is just because they are part of the name. They should also not be required to be a given type.
How hard is it to change a bash script to a different shell? Change the first line.
I agree that metadata should be readily accessible. The only reason it is tough on a mac is because it was intended to be difficult, so that new users would have trouble shooting themselves in the foot.
How would you like it if you had to name all your executable perl scripts ending with.pl?
You don't, because the operating system specifies an (optional) header section to every executable file, which allows it to determine which program to run the file with. This is metadata, of the magic number variety. It is data added to the beginning of the file, for the sole purpose of determining its type (ok, in this case it also specifies the path to the perl executable and any flags to be passed it, but ignore that for a moment).
The reason we have such magic numbers (which are also in most other standard file types, ps, gif, jpeg, etc) is because there are no common operating systems which support file types, so applications are on their own, and are forced to include what is properly (in my opinion) metadata in the file data itself. As long as we are going to store this data, why not have it in a standard location where it can be used by the rest of the operating system?
In fact, for proper design, a filesystem should only be concerned with the minimum features necessary to store and retrieve data.
On the contrary, that would mean that the file system shouldn't support file ownership, permissions or dates. None of these are strictly necesary, but they certainly can be darn convenien, and I definitely would rather be using a file system that supports them.
In fact, heck, we don't even need to have the file system store the filename! Why not simply store it in a block at the beginning of a file? If you want to be POSIX compliant, the operating system could strip it off before passing the data to an application, so it really wouldn't cause a problem, would it?
A file system should support all the metadata which can most conveniently be dealt with at the file system level. True, every file could have a date modified section, which each application updates every time it modifies the file, but this would be inconvenient and error prone, since any application could easily mess it up. By supporting this at the file system level, the modification date is considerably more reliable.
File types are not as straightforward as modification dates, since without application support the OS has no way of knowing what the file type is. On the other hand, file type is very useful information, useful enough that most programs want to mess up my filenames with it. If they're going to go to the trouble of doing that, they can certainly go to the trouble of defining a file type.
Because linux is based on unix, and has blindly followed unix, not windows. Also, linux supports a vast number of file systems, which means that the metadata would have to either be stored on all those file systems, or the OS would have to be able to live without it, which would probably lead to it being ignored by most of the software.
Unless metadata is implemented consistently, its use can do more harm than good. ("I copied this jpeg (named 'picture') to my windows partition and back again, and now I can't view it!")
I agreee that this is a problem, although not necesarily the end of the world.
Perhaps more serious is his choice to only offer an extended complex type, making it essentially useless for numerical computation (and who else is really using complex numbers?). I suppose there are some numerical codes that don't use much RAM or libraries such as LAPACK, but I doubt there are very many of them...
It's a shame, because it looks like his array support is quite nice, which is something that C has certainly been missing.
Apple current top-end dual 800Mhz PowerMac G4 runs AltiVec code at over
5GFLOPS. My older dual 450Mhz can run up to 3.2GFLOPS...
I'm sorry, but altivec is useless for any sort of scientific computation. It can only deal with single precision floats, and then it is only able to do four adds simultaneously.
There are good reasons to use powerpc processors (or better, POWER processors) for scientific work, but altivec is not one of them.
For servers, it is useful to have a system that doesn't get totally hosed from time to time. I run unstable at home, but for work would definitely not want to run unstable. I'd want a system that just works, and that is what stable is supposed to do.
Except, I hope, for those of us in California, who should be turning our home computers off daily to save power... (unless of course running a server at home).
One of my biggest complaints about Linux is that there isn't a modern open source Fortran compiler for it.
Interestingly, one of my biggest complaints about FORTRAN is that there isn't a modern open source Fortran compiler on any platform...
Also, the f90 compilers on many platforms all seem to have their own idiosyncrasies, which can make bug tracking a pain... of course I may be biased by the fact that I just spent several hours yesterday tracking down a bug in our code that only showed up on one out of the 10 platforms we run our code on, and even then only shows up in particular systems.
On the other hand, last a fellow student spent a day or two looking for a bug, and finally found that the problem was that the C preprocessor at NCSA doesn't (at least by default) support ANSI C, so maybe fortran isn't any worse...
Some of the benchmarks there are silly is speed of kernel compile really that important? All that matters to me is that it compiles properly and in a relatively timely manner.
The importance of the kernel compile time is that it serves as a measure of compile times in general, which is quite a reasonable benchmark for programmers.
I would say the office and gaming benchmarks are also reasonable, since probably most of the readers (at least many of them) will never run a database on their computer, but may be tempted to buy the latest and greatest chip, only to find out that it's slower than an athlon at 2/3 the clock speed.
I personally am glad they ran enough tests to show that the pentium is still behind the athlon on FP performance, which is the only thing I care about (except perhaps compile time), as I run floating point stuff at work (physics stuff).
Your typical day would be: get up, tune your radio to the most obscure underground station around, drop the watch in front of it, and do whatever you want for the day without the watch. Spoiling the stats for fun and profit.
Sorry. The watch has a motion sensor and temperature detector, intended to see whether you are awake or asleep, and so it wouldn't register anything if you take it off, except that you had taken it off...
My god! Is there really no Debian user at all reading this?
I had been asking myself the same question!:)
On the other hand, I suspect that the OSX interface is a heck of a lot friendlier than apt... albeit much less powerful (with respect to installing new software and removing software).
I have a question (perhaps off-topic on this post).
I read the document about how LOMAC works, and if I understand it properly, if I installed it on my debian system, `apt-get upgrade` would fail, because the.debs would have been downloaded over the network.
In fact, it would be impossible to install any software that was downloaded off the web. This is consistent with security, since for all we know the debian mirror I downloaded from has been compromised, but sounds awfully inconvenient.
Is there a good way around this problem? Or is LOMAC just designed to work conveniently on systems (say, debian stable, rather than unstable) in which you don't need to install or upgrade software very often?
I don't think you understand how jabber is supposed to work... with jabber nothing is centralized, and no server needs to know of all the users that are online (I think this is the whole point). Say, for example, I run my own server, and have only three people on my buddy list. As long as I'm online, my server only needs to contact the servers of those three people to see if they are also online. I don't see how this is so terribly bandwidth intensive.
By the n = c_vac/sqrt(eps*mu) definition you mentioned, if both eps and mu are negative, the index of refraction is still positive. Perhaps the article meant to say 0 n 1 (still interesting; for example, laser-solenoid fusion is a wacky idea needing n1). Or possibly the researchers are using a more generalized definition of n. (General press is not the best place to get scientific details or scientifically accurate terms.)
Good point! I obviously wasn't thinking much about what I was writing.:) However, the sqrt actually has two roots, a negative and a positive one, and when doing these materials one has to be very careful, since one is the correct root and the other is wrong.
It turns out that (solving Maxwell's equations) for negative epsilon and mu, the correct (as in most physically meaningful) index of refraction is negative. I have a friend who's worked on this kind of stuff, and it's very confusing, with the phase velocity and group velocity end up pointing in opposite directions. Very weird stuff.
Not necessarily. There are designs for sails which will have a "lightness" as high as 3 (lightness = photon pressure / gravitational force). Nobody's built one yet, of course.
I would be curious to see information on these designs. Certainly with such a design one could leave the solar system (although it would take an awfully long time to get to another star...).
You should look up the heliogyro concept for the Halley rendezvous probe, with careful attention paid to the planned trajectory. It makes a jog out, falls back in, and catches the comet shortly after perihelion... and stays with it. That's not "spiralling out slowly" by any definition, and that probe could have been built 20 years ago. (Should have been, too.)
I'm looking but haven't found any helpful info on the Halley rendezvous probe, but what you're describing sounds like the probe would slingshot around either a planet or the comet itself, in which case the solar sail isn't providing the primary power to the probe which is allowing it to do anything other than "slowly spiral". The primary power would be coming either from the kinetic energy of the planet which is being slighshotted around, which is the conventional way of doing intra-solar travel.
However, if you wanted to leave the solar system, it seems unlikely that you could get enough energy for it by slingshotting around planets, and even if you could, there would be very little reason to use a solar sail to do it, since all of your maneuvering would be within the solar system, and could be done using conventional propulsion.
Slashdot Mirror
I would presume VCD, which means it's rather heavily compressed (to the point of introducing noticable artifacts).
That being said, it still would be immensely cool. For one thing, it would correspond to the first detection of gravity waves!
Actually, Raymond is an experimentalist, and is already working on the experiment! (He's also a very nice guy.)
Although, I am also highly optimistic about pgi, I'm afraid this is easier said than done. The pgi installer-maker requires you to have a full debian mirror locally available. Alas, I don't have that kind of free disk space myself, and I'm guessing most people don't.
Someone will probably make one of these available with the progeny installer after woody's release.
I agree with you here. I think a pgi woody installer will be very helpful, and am certain that someone will make images available.
You should try debian. Debian works very hard to make sure their packages work on all their platforms (which, of course, includes powerpc). This involves seeking out and fixing the endianness/signed char issues that keep packages from being portable. Eventually those patches (in theory, at least) make their way upstream.
That being said, even on debian, other architectures are in a sense second class, since most of the developers use the i386 platform. This means that packages get autobuilt more slowly on powerpc, for example, but on the whole, it's a great powerpc distro.
This is a great point, what I see as the most significant effect of piracy. Allowing piracy of its software is how microsoft (and adobe, and others) maintains its monopoly.
Because the expensive products are available for free to anyone willing to pirate them (read individuals), it is virtually impossible for their competitors to gain market share. Who would buy a $25 word processor instead of buying MS Word, when they could just copy MS Word from a friend?
Even more so for photoshop. I have more than one friend who justify pirating photoshop because they would never pay for it anyways. But the big loser to piracy is not the major corporations, since individuals would never pay $600 for photoshop anyways, but rather their competitors, who try to sell cheaper versions, or Free Software competitors such as gimp.
As I see it, the single best way to harm the existing monopolies would be to eliminate piracy, and I think that would be a Good Thing.
I'd say because you would want a full sized keyboard and 15" screen, which wouldn't go into an ibook. And by not miniaturizing the other parts, you could cut costs significantly relative to a laptop.
I'm sorry, but Qt (for X windows anyways) is available under the GPL. How can it get more open source than that? Admittedly, Qt is not cross-platform and open source, but KDE isn't cross-platform anyways.
* is semi-conductor quantum computing any more viable in the long-term than whatever other vaporous methods are being investigated?
Well, that's sort of hard to say. It's not at all clear that there is a viable method for making a quantum computer. Certainly the Purdue work here is a long way from creating a quantum computer.
* how different is it in terms of the equipment required, and what would this mean for scalability?
Well, they don't have a method for fabricating any sort of computer (or even an xor or controlled not gate) out of these things, but you'd be lucky to run it at liquid helium temperatures (4K).
* which method of quantum computing would require the least power, and could be likely to be miniaturised the best? At the moment it seems the actual computing area is very small, but the equipment required to read output is inhibitively large
Well, I think with a quantum computer power consumption is not an issue, the question is whether you can create a computer with hundreds of qubits. There is also the problem that a quantum computer is an analog rather than a digital computer, so achieving the necesary precision is a challenge, to say the least.
* how fast, really , would a semi-decent quantum processor be, compared to a semi-decent silicon one? (This may seem like an ignorant or even trolling question, so I apologise in advance)
It's a good question. A quantum computer would be extremely slow. However, for a couple of problems (such as factorization of very large numbers), a quantum computer may be many orders of magnitude faster than a conventional computer.
The biggest issue (as I mentioned before) is that it is an analog computer, which means that unlike a digital computer, any small stray electromagnetic fields will introduce errors into the computation, which is quite a serious issue. My personal belief is that quite likely quantum computation is not possible, although I must admit that I haven't looked into it all that carefully. Certainly, switching to analog computing seems like a step backwards, and could be expected to put a practical limit on the size of such a computer, which may very well keep it from being useful.
I'm sure the mandrake install is easier than debian's, though...
I'm afraid you misunderstood his definition of immutable. In this example, you changed the data, and what was originally a plain text file became an HTML file. His definition of immutable was that if the file data changed, then its type did not change.
Also, it didn't mean that the metadata need be unchangable, since it could be changed to reflect greater precision, or if it was wrong in the first place. For example, an html file is a text file (but more). So it is entirely reasonable to change the type from text to html (provided it actually is).
slashdot.pl and slashdot.txt should NOT collide on my desktop...
I agree that slashdot.pl and slashdot.txt should not collide, but that is just because they are part of the name. They should also not be required to be a given type.
How hard is it to change a bash script to a different shell? Change the first line.
I agree that metadata should be readily accessible. The only reason it is tough on a mac is because it was intended to be difficult, so that new users would have trouble shooting themselves in the foot.
How would you like it if you had to name all your executable perl scripts ending with .pl?
You don't, because the operating system specifies an (optional) header section to every executable file, which allows it to determine which program to run the file with. This is metadata, of the magic number variety. It is data added to the beginning of the file, for the sole purpose of determining its type (ok, in this case it also specifies the path to the perl executable and any flags to be passed it, but ignore that for a moment).
The reason we have such magic numbers (which are also in most other standard file types, ps, gif, jpeg, etc) is because there are no common operating systems which support file types, so applications are on their own, and are forced to include what is properly (in my opinion) metadata in the file data itself. As long as we are going to store this data, why not have it in a standard location where it can be used by the rest of the operating system?
On the contrary, that would mean that the file system shouldn't support file ownership, permissions or dates. None of these are strictly necesary, but they certainly can be darn convenien, and I definitely would rather be using a file system that supports them.
In fact, heck, we don't even need to have the file system store the filename! Why not simply store it in a block at the beginning of a file? If you want to be POSIX compliant, the operating system could strip it off before passing the data to an application, so it really wouldn't cause a problem, would it?
A file system should support all the metadata which can most conveniently be dealt with at the file system level. True, every file could have a date modified section, which each application updates every time it modifies the file, but this would be inconvenient and error prone, since any application could easily mess it up. By supporting this at the file system level, the modification date is considerably more reliable.
File types are not as straightforward as modification dates, since without application support the OS has no way of knowing what the file type is. On the other hand, file type is very useful information, useful enough that most programs want to mess up my filenames with it. If they're going to go to the trouble of doing that, they can certainly go to the trouble of defining a file type.
Because linux is based on unix, and has blindly followed unix, not windows. Also, linux supports a vast number of file systems, which means that the metadata would have to either be stored on all those file systems, or the OS would have to be able to live without it, which would probably lead to it being ignored by most of the software.
Unless metadata is implemented consistently, its use can do more harm than good. ("I copied this jpeg (named 'picture') to my windows partition and back again, and now I can't view it!")
Perhaps more serious is his choice to only offer an extended complex type, making it essentially useless for numerical computation (and who else is really using complex numbers?). I suppose there are some numerical codes that don't use much RAM or libraries such as LAPACK, but I doubt there are very many of them...
It's a shame, because it looks like his array support is quite nice, which is something that C has certainly been missing.
I'm sorry, but altivec is useless for any sort of scientific computation. It can only deal with single precision floats, and then it is only able to do four adds simultaneously. There are good reasons to use powerpc processors (or better, POWER processors) for scientific work, but altivec is not one of them.
For servers, it is useful to have a system that doesn't get totally hosed from time to time. I run unstable at home, but for work would definitely not want to run unstable. I'd want a system that just works, and that is what stable is supposed to do.
Except, I hope, for those of us in California, who should be turning our home computers off daily to save power... (unless of course running a server at home).
Interestingly, one of my biggest complaints about FORTRAN is that there isn't a modern open source Fortran compiler on any platform...
Also, the f90 compilers on many platforms all seem to have their own idiosyncrasies, which can make bug tracking a pain... of course I may be biased by the fact that I just spent several hours yesterday tracking down a bug in our code that only showed up on one out of the 10 platforms we run our code on, and even then only shows up in particular systems.
On the other hand, last a fellow student spent a day or two looking for a bug, and finally found that the problem was that the C preprocessor at NCSA doesn't (at least by default) support ANSI C, so maybe fortran isn't any worse...
I think I'm blabbing on, so I'll shut up now.
The importance of the kernel compile time is that it serves as a measure of compile times in general, which is quite a reasonable benchmark for programmers.
I would say the office and gaming benchmarks are also reasonable, since probably most of the readers (at least many of them) will never run a database on their computer, but may be tempted to buy the latest and greatest chip, only to find out that it's slower than an athlon at 2/3 the clock speed.
I personally am glad they ran enough tests to show that the pentium is still behind the athlon on FP performance, which is the only thing I care about (except perhaps compile time), as I run floating point stuff at work (physics stuff).
Sorry. The watch has a motion sensor and temperature detector, intended to see whether you are awake or asleep, and so it wouldn't register anything if you take it off, except that you had taken it off...
I had been asking myself the same question! :)
On the other hand, I suspect that the OSX interface is a heck of a lot friendlier than apt... albeit much less powerful (with respect to installing new software and removing software).
I have a question (perhaps off-topic on this post).
.debs would have been downloaded over the network.
I read the document about how LOMAC works, and if I understand it properly, if I installed it on my debian system, `apt-get upgrade` would fail, because the
In fact, it would be impossible to install any software that was downloaded off the web. This is consistent with security, since for all we know the debian mirror I downloaded from has been compromised, but sounds awfully inconvenient.
Is there a good way around this problem? Or is LOMAC just designed to work conveniently on systems (say, debian stable, rather than unstable) in which you don't need to install or upgrade software very often?
I don't think you understand how jabber is supposed to work... with jabber nothing is centralized, and no server needs to know of all the users that are online (I think this is the whole point). Say, for example, I run my own server, and have only three people on my buddy list. As long as I'm online, my server only needs to contact the servers of those three people to see if they are also online. I don't see how this is so terribly bandwidth intensive.
Good point! I obviously wasn't thinking much about what I was writing. :) However, the sqrt actually has two roots, a negative and a positive one, and when doing these materials one has to be very careful, since one is the correct root and the other is wrong.
It turns out that (solving Maxwell's equations) for negative epsilon and mu, the correct (as in most physically meaningful) index of refraction is negative. I have a friend who's worked on this kind of stuff, and it's very confusing, with the phase velocity and group velocity end up pointing in opposite directions. Very weird stuff.
I would be curious to see information on these designs. Certainly with such a design one could leave the solar system (although it would take an awfully long time to get to another star...).
You should look up the heliogyro concept for the Halley rendezvous probe, with careful attention paid to the planned trajectory. It makes a jog out, falls back in, and catches the comet shortly after perihelion... and stays with it. That's not "spiralling out slowly" by any definition, and that probe could have been built 20 years ago. (Should have been, too.)
I'm looking but haven't found any helpful info on the Halley rendezvous probe, but what you're describing sounds like the probe would slingshot around either a planet or the comet itself, in which case the solar sail isn't providing the primary power to the probe which is allowing it to do anything other than "slowly spiral". The primary power would be coming either from the kinetic energy of the planet which is being slighshotted around, which is the conventional way of doing intra-solar travel.
However, if you wanted to leave the solar system, it seems unlikely that you could get enough energy for it by slingshotting around planets, and even if you could, there would be very little reason to use a solar sail to do it, since all of your maneuvering would be within the solar system, and could be done using conventional propulsion.