Totally agree. It's bad enough that there are already journals with poor peer review that accept mostly anything (meaning stuff found not rigorous enough for specialized journals) - like...umm... Nature? I know at least one case where Nature published an article rejected by Phys. Rev. Letters peer review as based on a flawed assumption and then, later, Nature rejected a refutation by another researcher from the same field as 'too technical to fit our profile'. This will only make things worse.
Besides, there are already free archives like arXiv.org (and the various mirrors) where people would send articles prior to journal publishing - so scientific information is mostly available (at least some of it). Peer-reviewed (i.e. with a good guarantee of non-garbage) information is paid-for. However, the point is that for the average taxpayer the actual scientific articles are meaningless (too technical) - unless you're working in that field, in which case your employer pays for your access as one of the tools for your job. What the journals provide for free is the article abstracts (and maybe extra stuff like references) - and for the vast majority of people outside that particular field that is enough.
Actually, Alpha is being actively killed by HP as it would have wiped the floor with their new poster-child, Itanium. If I remember correctly, the more exact formulation was 'discontinued R&D, only one crippled architectural upgrade'.
As of SPARC, it looks to me like SPARC is kicking SPARC's ass - as in Fujitsu vs. Sun versions.
Finally, look at the difference between Itanium and x86/amd64-class CPUs. In theory EPIC is all fine and dandy, but... why does it need 6MB of level 3 cache to show it? Makes one wonder how a comparable cache level would affect, say, a Xeon machine (given the obvious improvement that the extra cache brought to the P4EE CPUs). A similar story would hold for Power (see for instance this result, with 128MB off-chip L3 cache).
There might not even be a 'better way' to design a general-purpose CPU. Everybody has to optimize for something. Remember Intel bolting MMX then SSE/SSE2/SSE3 on x86 only because there was a heavy demand for it? And now, given the success of amd64, adding that as well to the Pentium4-class CPUs? x86 is not standing still. But that's the same for all the 'still alive' platforms.
I don't see why RendezVous is actually needed for anything professional. Yeah, you could use RendezVous to improvise a transient grid setup. That's kid stuff though, throw together a few macs for finishing a 3dsmax school project overnight, or (as the site cleverly suggests) for local Seti@Home-type projects. Anything serious (real supercomputers, or even anything using MPI, as they just added support for it) would be running the grid 24/7 (or as close as possible), which means fixed IPs and so on, so there's no need for GUI eyecandy in the one-time 'discovering the network' step.
That out of the way, I would be curious to know how they dealt with the load-balancing stuff - do the nodes report some kind of average availability for the 'loose' screensaver-type setup? since the queue manager would have to somehow take into account non-grid loads on the nodes.
BTW, the 'Xgrid tachometer' thingy looks like a typical example of useless eyecandy, if the picture is anything like the real thing: a pretty dial that tells you nothing (are those 2GHz available on a free node, on 10 busy ones or somewhere in between? it's not exactly the same thing, you know)
They don't really mix, as they aren't soluble into each other. You add another substance to get an emulsion - it adsorbs on the interface and 'breaks' it, so you get droplets.
Information doesn't give a damn. There are lots of non-free 'information dead-ends' scattered throughout history. Information is just what it is and does not 'want' or 'not want' anything.
The principle mis-stated here is that knowledge advances (a lot) easier when information is shared. Look at the 'hard sciences' - information is not free (i.e you have to pay the subscription for the journals) but accessible, and the science grants usually cover (in various indirect forms) the access to information - so those for whom the information is relevant can share it easily. Also, education is not free everywhere (see US colleges).
Now, if you have some non-shared (proprietary) knowledge, a shared-knowledge community working in the same direction will probably achieve something equivalent soon enough - and here's where patenting ideas comes in handy for the industry. This way, even if others discover independently your 'knowledge', they can't use it. This being the normal argument for 'patenting ideas = bad' and the software patents extensions. Too bad not many people pay attention to this and are swayed by the 'information must be free' broad statements that should read 'shared information is more efficient'.
To help this confusion, there's the distinction between 'consumer-grade information' - read 'a few steps above random noise' (the category your music, video, movie examples mostly fall into) and information that belongs to a highly-organized structure. A song and a theorem are completely different degrees of information, but a branch of mathematics and the techniques for designing and implementing an OS kernel are a lot more alike.
bottom-line: somehow, the work of making and using information must be paid for. Usually that comes from the 'implementation' part - many people know the basics of the lasing effect (to build on a previous story), still enough know the principles to achieve pulse compression for high power lasers (there are enough picosecond ones around), but you can't get one for free (and they're pretty darn expensive, too). On the other hand, if all that info were 'private', then fusion attempts would only make/. in several decades... if there were a/. at all.
So yes, someone will always pay for the software - be it the binary implementation or the support part. But sharing the underlying information would help speed up the already slow pace of software development, while prevention of that, through stuff like software patents, will probably kill it completely.
Re:Scientists think Einstein was wrong?
on
Testing Relativity
·
· Score: 1
renormalization is not an issue. One does it all the time, it's not like there's an absolute scale for energy saying 'THIS is zero', all you measure are energy differences anyway. There are however things that the standard model fails to explain - neutrino mixings would be one example. The other... 'problem-to-be' is the Higgs, proving to be quite ellusive so far (if it fails to show up in the next-gen colliders too, then there's no Higgs and mass goes unexplained).
Re:Scientists think Einstein was wrong?
on
Testing Relativity
·
· Score: 2, Insightful
Quantum field theory (the framework of particle physics) has done at least as well
I wouldn't say so. The standard model is already encountering problems - granted, it's been amazingly good at predicting some stuff, but then so has been classical mechanics; depends on what kind of questions you're asking. It's just that with current technology the experiments that could fail the Standard Model tests are easier to construct than ones to fail GR tests (still waiting on the gravitational wave detector;-)
GR singularities (aka black holes) don't play well with QM
and so on. basically GR is a 'classical' theory, so any quantum effects don't belong.
Unfortunately, the kind of 'patching' that Newtonian mechanics went through to give the original QM (Hamilton-Jacobi formalism, integral invariants) does not have a working equivalent fro GR.
scripting languages and set theory fans don't grok each other's jokes it seems. You didn't even get someone asking something like "what's a russel and why's it messing up my classes, I have enough homework already!"
You're still in your own class it seems, so you're not in... uh, nevermind.
In fact a lot of people run the server VM for desktop apps because, although it uses about 10% mmore memory, it is a lot faster.
actually, that's not strictly true. Server-type and desktop-type apps are different beasts. server jvms are optimized for... server apps. Which, among other things, run for a long time, have fewer 'unexpected events' and so on... being thus easier to optimize for. So for a little starting overhead one ends up with a reasonably fast app in the long term. Desktop (java) apps usually are the opposite: don't run all that long, startup time is important, user interaction makes optimization more difficult.
so yes, if you run long enough looping benchmarks, the server vm is fine (/fast); for interactive apps, it's not the same thing.
Sun would own it just the same - check the licensing terms (there was a link to the Debian FAQ about that) - Sun gets ownership to any clean-room implementation of the specs.
now that sucks. Might as well be the writing on the wall for Java, since if Sun is not interested in paying for a port to a new platform, nobody will do it as it ends up owned by Sun anyway. See for instance the blackdown ports: IA64, amd64 are server-only, since Sun won't pay for a client (read desktop) implementation.
And we thought M$ was bad... oh well, Sun is a worthy competitor on that (level) field.
Not really. Here's a scenario for you (the debian-style):
cracker compromises a 3rd-party machine and gets the ssh tokens for a legitimate user.
cracker logs into the server - no particular preference, that server just happened to be one of those he gained access to by sniffing on ssh logins from his initial machine
cracker logs in as a legitimate user on the server (impossible to detect at this stage) and acquires, in some way or another, root access (like a nice, untraceable pam exploit)
cracker tries to secure root acces and triggers an allert in the logs (this being the 'dumb' step)
the problem is, you can't trace the initial attack vector. It can be done by any script kiddie who compromises a machine that some developper uses. However, if it's not a mere script kiddie (and covers his tracks successfully), chances are that even a competent sysadmiin can fail to discover it. Yeah, I know about read-only/remote IDS databases, remote logs, backups and so on. It's a nice overhead when you're handling a large farm and you still have to make sure the data is on a secure machine. Do you do it for all your servers? (besides, at this level of complexity you need a full-time job - at least experienced hackers will see it coming and maybe leave you alone).
that said, whoever was the sysadmin for that box picked it up - kudos for that! And if the 'dumb cracker' line means what it says (from the logs, etc) then here's hoping that it was indeed just a lone incident.
to make it formally correct: Bell's Inequality would have shown that QM is incomplete (and actually wrong) in the non-local assumptions. It being false, the non-local assumptions (with which it is formally incompatible) hold. That dows not prove QM. But the point was not to show QM is wrong (that would have been a bonus). What it says now is QM can be an incomplete theory - and it actually is. Notice that, this way, it's still correct at some level, while incomplete/incorrect at others. All you need is some type of 'non-local hidden variables' (or fields) ^_^ and you're done. The assumption of non-locality is the principle that was proven, and on a local scale that's the reason for quantum randomness.
It makes a local, deterministic description impossible.
I was only trying not to repeat 'local' too many times. (that being the initial problem, the non-locality of QM). Yes, Bell's inequality only contradicts QM on a local level.
But once you have to take 'the Universe as a whole' into account you're done. There's no possible description anymore, since you do not have access to all the controlling parameters. All you can do is approximate and thus make a global theory a moot point, since it's pretty much unprovable.
Next comes the issue of randomness. On a completely global model you have an infinite (for all practical purposes) number of degrees of freedhom. That would make it the best example of a statistical limit and we're back to the statistical interpretation of QM that the randomness is based upon.
Thus the problem with the argument for non-locality is that experimentally you can only do so much - push the unknown parameters one level up. You can never remove them completely. The ideal experiment would have to be in an environment completely out of this universe (and presumably with few participants, so you can describe them all in a non-statistical manner). So, while philosophically it is nice to say things like 'the wavefunction of the Universe', that is as unknownable sd 'the wavefunction of God'. All you see in practice is randomness.
And yes, you have then the field theories, where everything is pretty much excitations of an unknown number of global fields with an infinite number of degrees of freedhom for each. Again, back to statistics (and one usually reads "random' in connection to 'infinite degrees of freedhom')
Lucky for us we didn't discover a 'planet' with a completely liquid surface yet, to limit the 'round' criterion even more. This way astronauts making water bubbles on ISS can claim they're planet-makers;-)
The EPR paradox, as modified by Bell, is actually a test of Quantum Mechanics - on the level of some basic assumptions, including the lack of classical determinism. It was tested (mostly in the '60-'70) and found to hold w.r.t. this issue (see Phys Rev Lett 49, 91) - were Bell's inequality to be found true, it would have meant the QM assumptions were wrong, making all QM wrong. Guess what, it didn't hold true...
So, at least the general principles of QM are correct. What this means is that there are non-local effects embedded in the theory, which make a deterministic (and thus predictable, i.e. non-random) description impossible.
that's a different kettle of fish. N-body problems are not analytically solvable. That does not make them 'random'. More to the point, you have a case in which accumulated imprecisions will lead (eventually) to a complete prediction failure. However, the equations of the theory are still deterministic - given the initial conditions with enough accuracy, you can predict (with some required accuracy) the final ones, at least for a given time interval. It's just that the more precision and longer time you want, the more precise your initial conditions have to be.
In quantum mechanics, there's no such 'eventually'. Example: set up an atom in an excited state and try to predict whether it will be in the same state after 1 minute - all you can say is "will be with some probability", hence no mechanical determinism here. You can also make the time interval as short as you like.
There is. Google for Bell's inequality or the Einstein, Podolsky, Rosen paradoxfor a starting point. It does involve some more than skin-deep knowledge of quantum mechanics though.
The bottom line is there's no theory of 'local hidden variables' that would make quantum mechanics a deterministic theory in the 'classical' sense.
Add to that even if they did have a seperate root account, they'd have to set some sort of default password and most people would never bother to change it.
Here's a clue: set the root password to expire in 7 days and put a big note on top of everything in the box saying "You need to change the root password and set up a user for yourself, or you won't be able to log into your machine after 7 days. Please refer to section x.x in the user manual" - then have the manual walk them through the procedure of changing the password and the expire setting. Then, using cracklib+pam helps imposing good passwords and so on.
the user is supposed to set up his/her machine before using - at the very least cabling it up. All this Windows laziness is only giving a dumbed-down picture of users as computer monkeys who can only click on pretty icons.
SSL already adds a performance overhead. On the other hand, Java web servers have been known to handle a large number of sessions.
nice twist - changing the subject without addressing the issue.
Try this:
SSL brings overhead - so do you really want to add Java's to it? as it was pointed already several times so far, Java is a resource hog so it's unsuited for both small servers and very large-traffic ones in that.
Java is among the last places to look for computation-intensive tasks. SSL encrypting/decrypting is such a task. You might argue that the crypto libs can stay C and be called from Java, but that defeats your purpose of getting rid of that pesky C code.
yes, you can handle multiple connections in Java - provided that you don't launch different clients to handle each other, otherwise you risk running out of memory with greedy VMs contending for ram. But this is not particularly safe - one common point of failure sucks.
Best tool for the job is the answer alright, but Java isn't it in this case. However, you're free to do a Java implementation of the SSL libs and use it - just don't be surprised if widespread adoption will not follow.
Physics relies intrinsically on the notion of time - take that away and there's not much left. You might take away space too, while you're at it;-)
You're mistaken in requiring a proof of time. It's like requiring a proof of the existence of the Universe - you can't do it. It's an empirical reality. "Time" is actually meaningless in physics, too - if you want to be really picky all that has a meaning is "time interval" (between events) and that in a specific reference frame.
and about it being fictious... is that a watch that you're carrying? if so (and time is fictious), then yes, you're off your rocker:-)
Slashdot Mirror
Totally agree. It's bad enough that there are already journals with poor peer review that accept mostly anything (meaning stuff found not rigorous enough for specialized journals) - like ...umm ... Nature? I know at least one case where Nature published an article rejected by Phys. Rev. Letters peer review as based on a flawed assumption and then, later, Nature rejected a refutation by another researcher from the same field as 'too technical to fit our profile'. This will only make things worse.
Besides, there are already free archives like arXiv.org (and the various mirrors) where people would send articles prior to journal publishing - so scientific information is mostly available (at least some of it). Peer-reviewed (i.e. with a good guarantee of non-garbage) information is paid-for. However, the point is that for the average taxpayer the actual scientific articles are meaningless (too technical) - unless you're working in that field, in which case your employer pays for your access as one of the tools for your job. What the journals provide for free is the article abstracts (and maybe extra stuff like references) - and for the vast majority of people outside that particular field that is enough.
Actually, Alpha is being actively killed by HP as it would have wiped the floor with their new poster-child, Itanium. If I remember correctly, the more exact formulation was 'discontinued R&D, only one crippled architectural upgrade'.
... why does it need 6MB of level 3 cache to show it? Makes one wonder how a comparable cache level would affect, say, a Xeon machine (given the obvious improvement that the extra cache brought to the P4EE CPUs). A similar story would hold for Power (see for instance this result, with 128MB off-chip L3 cache).
As of SPARC, it looks to me like SPARC is kicking SPARC's ass - as in Fujitsu vs. Sun versions.
Finally, look at the difference between Itanium and x86/amd64-class CPUs. In theory EPIC is all fine and dandy, but
There might not even be a 'better way' to design a general-purpose CPU. Everybody has to optimize for something. Remember Intel bolting MMX then SSE/SSE2/SSE3 on x86 only because there was a heavy demand for it? And now, given the success of amd64, adding that as well to the Pentium4-class CPUs? x86 is not standing still. But that's the same for all the 'still alive' platforms.
I don't see why RendezVous is actually needed for anything professional. Yeah, you could use RendezVous to improvise a transient grid setup. That's kid stuff though, throw together a few macs for finishing a 3dsmax school project overnight, or (as the site cleverly suggests) for local Seti@Home-type projects. Anything serious (real supercomputers, or even anything using MPI, as they just added support for it) would be running the grid 24/7 (or as close as possible), which means fixed IPs and so on, so there's no need for GUI eyecandy in the one-time 'discovering the network' step.
That out of the way, I would be curious to know how they dealt with the load-balancing stuff - do the nodes report some kind of average availability for the 'loose' screensaver-type setup? since the queue manager would have to somehow take into account non-grid loads on the nodes.
BTW, the 'Xgrid tachometer' thingy looks like a typical example of useless eyecandy, if the picture is anything like the real thing: a pretty dial that tells you nothing (are those 2GHz available on a free node, on 10 busy ones or somewhere in between? it's not exactly the same thing, you know)
They don't really mix, as they aren't soluble into each other. You add another substance to get an emulsion - it adsorbs on the interface and 'breaks' it, so you get droplets.
I believe that information wants to be free
/. in several decades ... if there were a /. at all.
Information doesn't give a damn. There are lots of non-free 'information dead-ends' scattered throughout history. Information is just what it is and does not 'want' or 'not want' anything.
The principle mis-stated here is that knowledge advances (a lot) easier when information is shared. Look at the 'hard sciences' - information is not free (i.e you have to pay the subscription for the journals) but accessible, and the science grants usually cover (in various indirect forms) the access to information - so those for whom the information is relevant can share it easily. Also, education is not free everywhere (see US colleges).
Now, if you have some non-shared (proprietary) knowledge, a shared-knowledge community working in the same direction will probably achieve something equivalent soon enough - and here's where patenting ideas comes in handy for the industry. This way, even if others discover independently your 'knowledge', they can't use it. This being the normal argument for 'patenting ideas = bad' and the software patents extensions. Too bad not many people pay attention to this and are swayed by the 'information must be free' broad statements that should read 'shared information is more efficient'.
To help this confusion, there's the distinction between 'consumer-grade information' - read 'a few steps above random noise' (the category your music, video, movie examples mostly fall into) and information that belongs to a highly-organized structure. A song and a theorem are completely different degrees of information, but a branch of mathematics and the techniques for designing and implementing an OS kernel are a lot more alike.
bottom-line: somehow, the work of making and using information must be paid for. Usually that comes from the 'implementation' part - many people know the basics of the lasing effect (to build on a previous story), still enough know the principles to achieve pulse compression for high power lasers (there are enough picosecond ones around), but you can't get one for free (and they're pretty darn expensive, too). On the other hand, if all that info were 'private', then fusion attempts would only make
So yes, someone will always pay for the software - be it the binary implementation or the support part. But sharing the underlying information would help speed up the already slow pace of software development, while prevention of that, through stuff like software patents, will probably kill it completely.
renormalization is not an issue. One does it all the time, it's not like there's an absolute scale for energy saying 'THIS is zero', all you measure are energy differences anyway. There are however things that the standard model fails to explain - neutrino mixings would be one example. The other ... 'problem-to-be' is the Higgs, proving to be quite ellusive so far (if it fails to show up in the next-gen colliders too, then there's no Higgs and mass goes unexplained).
Quantum field theory (the framework of particle physics) has done at least as well
;-)
I wouldn't say so. The standard model is already encountering problems - granted, it's been amazingly good at predicting some stuff, but then so has been classical mechanics; depends on what kind of questions you're asking. It's just that with current technology the experiments that could fail the Standard Model tests are easier to construct than ones to fail GR tests (still waiting on the gravitational wave detector
and so on. basically GR is a 'classical' theory, so any quantum effects don't belong.
Unfortunately, the kind of 'patching' that Newtonian mechanics went through to give the original QM (Hamilton-Jacobi formalism, integral invariants) does not have a working equivalent fro GR.
scripting languages and set theory fans don't grok each other's jokes it seems. You didn't even get someone asking something like "what's a russel and why's it messing up my classes, I have enough homework already!"
... uh, nevermind.
You're still in your own class it seems, so you're not in
In fact a lot of people run the server VM for desktop apps because, although it uses about 10% mmore memory, it is a lot faster.
... server apps. Which, among other things, run for a long time, have fewer 'unexpected events' and so on ... being thus easier to optimize for. So for a little starting overhead one ends up with a reasonably fast app in the long term. Desktop (java) apps usually are the opposite: don't run all that long, startup time is important, user interaction makes optimization more difficult.
actually, that's not strictly true. Server-type and desktop-type apps are different beasts. server jvms are optimized for
so yes, if you run long enough looping benchmarks, the server vm is fine (/fast); for interactive apps, it's not the same thing.
and the app that will open the application/ms-mime files will show Ballmer frantically dancing his mime-encoded message on your desktop.
... a Mozilla plugin in linux too, please ^_^
Can't wait for it to happen
Sun would own it just the same - check the licensing terms (there was a link to the Debian FAQ about that) - Sun gets ownership to any clean-room implementation of the specs.
... oh well, Sun is a worthy competitor on that (level) field.
now that sucks. Might as well be the writing on the wall for Java, since if Sun is not interested in paying for a port to a new platform, nobody will do it as it ends up owned by Sun anyway. See for instance the blackdown ports: IA64, amd64 are server-only, since Sun won't pay for a client (read desktop) implementation.
And we thought M$ was bad
the problem is, you can't trace the initial attack vector. It can be done by any script kiddie who compromises a machine that some developper uses. However, if it's not a mere script kiddie (and covers his tracks successfully), chances are that even a competent sysadmiin can fail to discover it. Yeah, I know about read-only/remote IDS databases, remote logs, backups and so on. It's a nice overhead when you're handling a large farm and you still have to make sure the data is on a secure machine. Do you do it for all your servers? (besides, at this level of complexity you need a full-time job - at least experienced hackers will see it coming and maybe leave you alone).
that said, whoever was the sysadmin for that box picked it up - kudos for that! And if the 'dumb cracker' line means what it says (from the logs, etc) then here's hoping that it was indeed just a lone incident.
oh well, there were unstated elements ^_^
to make it formally correct: Bell's Inequality would have shown that QM is incomplete (and actually wrong) in the non-local assumptions. It being false, the non-local assumptions (with which it is formally incompatible) hold. That dows not prove QM. But the point was not to show QM is wrong (that would have been a bonus). What it says now is QM can be an incomplete theory - and it actually is. Notice that, this way, it's still correct at some level, while incomplete/incorrect at others. All you need is some type of 'non-local hidden variables' (or fields) ^_^ and you're done. The assumption of non-locality is the principle that was proven, and on a local scale that's the reason for quantum randomness.
It makes a local, deterministic description impossible.
I was only trying not to repeat 'local' too many times. (that being the initial problem, the non-locality of QM). Yes, Bell's inequality only contradicts QM on a local level.
But once you have to take 'the Universe as a whole' into account you're done. There's no possible description anymore, since you do not have access to all the controlling parameters. All you can do is approximate and thus make a global theory a moot point, since it's pretty much unprovable.
Next comes the issue of randomness. On a completely global model you have an infinite (for all practical purposes) number of degrees of freedhom. That would make it the best example of a statistical limit and we're back to the statistical interpretation of QM that the randomness is based upon.
Thus the problem with the argument for non-locality is that experimentally you can only do so much - push the unknown parameters one level up. You can never remove them completely. The ideal experiment would have to be in an environment completely out of this universe (and presumably with few participants, so you can describe them all in a non-statistical manner). So, while philosophically it is nice to say things like 'the wavefunction of the Universe', that is as unknownable sd 'the wavefunction of God'. All you see in practice is randomness.
And yes, you have then the field theories, where everything is pretty much excitations of an unknown number of global fields with an infinite number of degrees of freedhom for each. Again, back to statistics (and one usually reads "random' in connection to 'infinite degrees of freedhom')
Lucky for us we didn't discover a 'planet' with a completely liquid surface yet, to limit the 'round' criterion even more. This way astronauts making water bubbles on ISS can claim they're planet-makers ;-)
(hint: surface tension also makes things round)
The EPR paradox, as modified by Bell, is actually a test of Quantum Mechanics - on the level of some basic assumptions, including the lack of classical determinism. It was tested (mostly in the '60-'70) and found to hold w.r.t. this issue (see Phys Rev Lett 49, 91) - were Bell's inequality to be found true, it would have meant the QM assumptions were wrong, making all QM wrong. Guess what, it didn't hold true ...
So, at least the general principles of QM are correct. What this means is that there are non-local effects embedded in the theory, which make a deterministic (and thus predictable, i.e. non-random) description impossible.
that's a different kettle of fish. N-body problems are not analytically solvable. That does not make them 'random'. More to the point, you have a case in which accumulated imprecisions will lead (eventually) to a complete prediction failure. However, the equations of the theory are still deterministic - given the initial conditions with enough accuracy, you can predict (with some required accuracy) the final ones, at least for a given time interval. It's just that the more precision and longer time you want, the more precise your initial conditions have to be.
In quantum mechanics, there's no such 'eventually'. Example: set up an atom in an excited state and try to predict whether it will be in the same state after 1 minute - all you can say is "will be with some probability", hence no mechanical determinism here. You can also make the time interval as short as you like.
There is. Google for Bell's inequality or the Einstein, Podolsky, Rosen paradoxfor a starting point. It does involve some more than skin-deep knowledge of quantum mechanics though.
The bottom line is there's no theory of 'local hidden variables' that would make quantum mechanics a deterministic theory in the 'classical' sense.
Add to that even if they did have a seperate root account, they'd have to set some sort of default password and most people would never bother to change it.
Here's a clue: set the root password to expire in 7 days and put a big note on top of everything in the box saying "You need to change the root password and set up a user for yourself, or you won't be able to log into your machine after 7 days. Please refer to section x.x in the user manual" - then have the manual walk them through the procedure of changing the password and the expire setting. Then, using cracklib+pam helps imposing good passwords and so on.
the user is supposed to set up his/her machine before using - at the very least cabling it up. All this Windows laziness is only giving a dumbed-down picture of users as computer monkeys who can only click on pretty icons.
nice twist - changing the subject without addressing the issue.
Try this:
Best tool for the job is the answer alright, but Java isn't it in this case. However, you're free to do a Java implementation of the SSL libs and use it - just don't be surprised if widespread adoption will not follow.
Physics relies intrinsically on the notion of time - take that away and there's not much left. You might take away space too, while you're at it ;-)
... is that a watch that you're carrying? if so (and time is fictious), then yes, you're off your rocker :-)
You're mistaken in requiring a proof of time. It's like requiring a proof of the existence of the Universe - you can't do it. It's an empirical reality. "Time" is actually meaningless in physics, too - if you want to be really picky all that has a meaning is "time interval" (between events) and that in a specific reference frame.
and about it being fictious
talk is cheap, care to attach a formal proof to that?
Short answer, yes. 0.9999... is defined as a limit of {0.9, 0.99, 0.999, ...}, and as such can be trivially proved to be equal to 1.
well, no. That would make it boundless, but not infinite. I think he meant short as in 'size', not as in 'amount of time it takes to read' ;-)