Bottom line is that after three hard drive failures in the course of a little over a month (yes, I have a third Seagate drive misbehaving massively, randomly corrupting data)
Are you/sure/ your power supply is sufficient and your drive(s) are sufficiently cooled?
Two issues: firstly, how often are you actually restoring from tape? Decryption isn't slow compared to physically getting the tape from offsite. If someone loses the tape that same information is gone forever, too. And, in any event, I work (ob plug) on a hardware tape encryption product that solves all these problems.
In many cases the law does the right not-heavy-handed thing here -- if you lose tapes with my info on it you get a scandal. If you lose tapes with my encrypted data on it you haven't leaked any information at all, and don't even need to report it.
At least in Christianity, free will is assumed. If there were no free will, our love for God would mean nothing, because we wouldn't have any alternative.
So a mathematical theorem means nothing, because starting from those axioms there is no alternative to it?
It's certainly interesting, although the article is sparse on details (how much pressure?).
Note that keeping this substance under pressure is likely to be harder than keeping a superconductor cooled. Keeping a superconductor cooled isn't that hard, given that it isn't generating resistive heat. All you need to do is keep it well insulated and refrigerate the LN2 enough to make up for heat loss.
Your old pocket calculator could factor 20 digit numbers?
In any event, the feasibility of large scale quantum computation is a prediction of QM. All we need to do is to build a system which decoheres less than 1-3% of the time that we can manipulate and we can correct the rest of the errors. We don't have to scale up/that/ much further than we already have.
175 miles isn't that much lower than the ISS. There isn't much atmosphere that high up-- the atmospheric drag is "needs a nudge every once in a while" and not "needs heat shield".
The problem is that an orbit at 175 miles wouldn't be remotely geostationary, because it would be circling too fast; presumably it's just at LEO while on it's way up.
So, you didn't read the article. (or "the first part" is "the first page", or IHBT)
The popular perception is wrong; quantum computers aren't as powerful as the popular perception would have them. They can't just try exponentially many paths in parallel. They can cause those paths to interfere with each other to occasionally get an exponential speedup, or in general to get a quadratic speedup.
Sure, 128 bit WEP isn't brute forceable but it's easily broken by the same sorts of attacks that break 40 bit WEP.
If all parties avoid weak IVs it becomes harder, but enforcing that is harder than just using WPA.
Right now, WPA-PSK with a nontrivial key should be sufficient; switch to something else if it starts showing weaknesses. Anything else is overkill for anything resembling a typical home setup... but 128 bit WEP is severe underkill!
I wondered btw. why my 8 years old firewall supports AES encryption (for VPN) with 2048 bits strength but no currently available products supports more than 256 bits.
Because 256 bit AES is believed secure. Even 128 bit AES is secure unless we find some fairly major attacks -- 2**128 is HUGE. 2**256 is 2**128 times larger than *that*. If you turned the entire planet into a gigantic (conventional) computer you could break 128 bit AES but not 256 bit AES. 256 bit AES would likely be unfeasible if you had the power of a large *galaxy*. A small city isn't going to cut it.
A quantum computer might do it, but if one would be much help then a 2048 bit AES key would be not much harder than a 256 bit one.
Thus, you don't see current products with more than 256 bit AES. If you see someone pushing larger key sizes for AES right now I'd be reluctant to trust them -- they probably do not know what they're talking about!
The energy in uranium would last for millions of years, by my back of the envelope calculations, at current rates of consumption.
I'll admit that "millions of years" is not necessarily "fucking close" to "5-10 billion years" but it's enough time to figure out something better.
Of course, in the future we'll use more energy than we do now, but even then we will not run any danger of running out of uranium on Earth anytime soon; Earth couldn't even dissipate the heat if we tried to burn it all up in a human-civilization timeframe.
The nasty case here is that, as far as mv is concerned, the write is complete as soon as it's done writing to cache.
Your test of interrupting the mv in the middle doesn't hit this case because mv hasn't finished yet. If the cached write then fails there's nothing it can do. Unless mv uses uncached writes or does a sync you're gong to have this sort of problem.
Just because a problem was solved in a 25 page paper does not mean it isn't a suitable homework problem, even if you didn't manage to find the solution yourself.
It's not like you'd be expected to write up in the detail they gave. More likely than not the *real* major fruit of the paper (the general approach) was covered in class, and you're just proving a corollary.
Half the trick to courses like that, IME, is to relax and just take it as a series of fun problems. Courses like that are never graded on a 70/80/90 scale, so stressing about the grade you get on any particular assignment, or even on a series of assignments, is just counterproductive.
Actually, you can change from GPLv2 to GPLv3 (once GPLv3 actually exists) implicitly if you're using standard GPL with the suggested language
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. You can license under only GPLv2, if you want. The Linux kernel is (for the most part) so licensed, which means that a move from 2 to 3 would require license from every contributor.
Sure, I'm paying twice as much for an apartment here on the SF peninsula (working across the street from EA, no less) than I would have in Champaign. I'm also paying somewhat higher taxes. On the other hand, my basic living expenses are a small fraction of my salary, and Amazon and Newegg are no cheaper in Champaign than they are in San Francisco.
I mean, heck, it's not like you're going to buy a car for $20K here but get the same car for only $12K in Champaign.
And, as I see it, there is no reason a company in Champaign should pay me less just because it is cheaper there. My work is no less valuable in Champaign than it is here. Sure, I could live comfortably on around what I pay for just rent here, but why should my employer pocket the difference?
A much better tactic would be to sue the FSF over something they did wrong and since they probably don't have much in the way capital to actually be awarded the foudation itself. A take over. You can then null and void any limitations to GPL code you don't like for everyone. A clause in the GPL gives the FSF power to relicence code however they want; and that kind of power is an asset. You could make all code public domain if you wanted or sell specific projects code to closed source companies for a profit. I'm surprised microsoft and the old unix companies havn't tried this. The question is what to sue over... but lawyers are pretty crafty.
(OB IANAL)
The FSF only has control over two things: the GPL itself and code whose copyright has been granted to them. Changing the former only works if the license version used is not fixed (eg, the "or any later version" language). There are several safeguards even against a hostile later license: firstly, that the license specifically says that later changes will have the same spirit, so one might argue that a GPLv3 with a "BlueCoder gets all rights" clause would not even *be* a later version of the GPL. Alternatively, it might be enforceable by contract; that language might be interpretable as a contract between the FSF and people using the GPL license that the license will not so change. Even failing that, there'd be estoppel arguments.
Even for code with FSF assigned copyright, similar contract and estoppel arguments might apply. They might own the copyright, but the copyright was assigned with the understanding that the FSF would use it in good faith. A change in FSF leadership couldn't just sell it all off, I think. (but IANAL)
The second argument doesn't work, in that there *is* no such "internal use" exception. (I believe the FSF does not consider internal use to be distribution, but that doesn't give you a way out.)
The problem with any "make an ABI compatible stub" approach is that you need that stub to not be a derivative work of the library! You might be able to pull that off, but at minimum it would probably require a clean room reverse engineering approach.
One legitimate effect of this is that the GPL-linking business has no teeth for a library with a standard ABI; assuming there isn't any header produced non ABI code, you could link against such a library without your program being a derivative work. (but IANAL; I might be wrong.) As such, there's no reason (barring it, itself, being derivative of GPL) for such a library to be GPL in the first place.
It is completely absurd for a filesystem to kill a disk. If you were getting those errors (with the "drive ready" and "seek complete" bits being set being most common) it *strongly* suggests that either your disk is broken or it is improperly powered.
If you're actually using that disk, still, have a look at it with smartctl. In particular, run "smartctl -t long" on it, and have a look at the results. If it doesn't pass that, don't even think of trusting it with your data.
The catch as applies to the contestants "space station" is that for them to experience gravity of even close to normal Earth gravity, they would have to be at a very low altitude (compared to true low-earth orbit)
Actually, LEO is really almost negligibly close to the Earth's surface compared to, say, geosynchronous orbits.
However, no matter how close to the surface your orbit might be, you will not feel any downward force. The entire craft is accelerating downward at on the order of 9 and some odd ms^{-2}, and you with it; You don't feel any force because you're falling downward with the craft.
Slashdot Mirror
Bottom line is that after three hard drive failures in the course of a little over a month (yes, I have a third Seagate drive misbehaving massively, randomly corrupting data)
Are you /sure/ your power supply is sufficient and your drive(s) are sufficiently cooled?
Anyone who can send a single fake reply can send 10,000 fake replies to different ports.
Not if you already need to send 10000 (or 1000, or 100...) fake replies to guess the transaction ID.
Two issues: firstly, how often are you actually restoring from tape? Decryption isn't slow compared to physically getting the tape from offsite. If someone loses the tape that same information is gone forever, too. And, in any event, I work (ob plug) on a hardware tape encryption product that solves all these problems.
In many cases the law does the right not-heavy-handed thing here -- if you lose tapes with my info on it you get a scandal. If you lose tapes with my encrypted data on it you haven't leaked any information at all, and don't even need to report it.
At least in Christianity, free will is assumed. If there were no free will, our love for God would mean nothing, because we wouldn't have any alternative.
So a mathematical theorem means nothing, because starting from those axioms there is no alternative to it?It's certainly interesting, although the article is sparse on details (how much pressure?).
Note that keeping this substance under pressure is likely to be harder than keeping a superconductor cooled. Keeping a superconductor cooled isn't that hard, given that it isn't generating resistive heat. All you need to do is keep it well insulated and refrigerate the LN2 enough to make up for heat loss.
Your old pocket calculator could factor 20 digit numbers?
/that/ much further than we already have.
In any event, the feasibility of large scale quantum computation is a prediction of QM. All we need to do is to build a system which decoheres less than 1-3% of the time that we can manipulate and we can correct the rest of the errors. We don't have to scale up
175 miles isn't that much lower than the ISS. There isn't much atmosphere that high up-- the atmospheric drag is "needs a nudge every once in a while" and not "needs heat shield".
The problem is that an orbit at 175 miles wouldn't be remotely geostationary, because it would be circling too fast; presumably it's just at LEO while on it's way up.
So, you didn't read the article. (or "the first part" is "the first page", or IHBT)
The popular perception is wrong; quantum computers aren't as powerful as the popular perception would have them. They can't just try exponentially many paths in parallel. They can cause those paths to interfere with each other to occasionally get an exponential speedup, or in general to get a quadratic speedup.
Note that a determined intruder can break WPA as well.
No. A determined intruder can break your password if it is shoddy, but if you have a sufficiently good password that is not feasible.
Sure, 128 bit WEP isn't brute forceable but it's easily broken by the same sorts of attacks that break 40 bit WEP.
If all parties avoid weak IVs it becomes harder, but enforcing that is harder than just using WPA.
Right now, WPA-PSK with a nontrivial key should be sufficient; switch to something else if it starts showing weaknesses. Anything else is overkill for anything resembling a typical home setup... but 128 bit WEP is severe underkill!
I wondered btw. why my 8 years old firewall supports AES encryption (for VPN) with 2048 bits strength but no currently available products supports more than 256 bits.
Because 256 bit AES is believed secure. Even 128 bit AES is secure unless we find some fairly major attacks -- 2**128 is HUGE. 2**256 is 2**128 times larger than *that*. If you turned the entire planet into a gigantic (conventional) computer you could break 128 bit AES but not 256 bit AES. 256 bit AES would likely be unfeasible if you had the power of a large *galaxy*. A small city isn't going to cut it.
A quantum computer might do it, but if one would be much help then a 2048 bit AES key would be not much harder than a 256 bit one.
Thus, you don't see current products with more than 256 bit AES. If you see someone pushing larger key sizes for AES right now I'd be reluctant to trust them -- they probably do not know what they're talking about!
The energy in uranium would last for millions of years, by my back of the envelope calculations, at current rates of consumption.
I'll admit that "millions of years" is not necessarily "fucking close" to "5-10 billion years" but it's enough time to figure out something better.
Of course, in the future we'll use more energy than we do now, but even then we will not run any danger of running out of uranium on Earth anytime soon; Earth couldn't even dissipate the heat if we tried to burn it all up in a human-civilization timeframe.
linux caches writes to floppies until umount
The nasty case here is that, as far as mv is concerned, the write is complete as soon as it's done writing to cache.
Your test of interrupting the mv in the middle doesn't hit this case because mv hasn't finished yet. If the cached write then fails there's nothing it can do. Unless mv uses uncached writes or does a sync you're gong to have this sort of problem.
O(n^n) is not O(n!). O(log(n^n)) = O(log(n!)); the two differ by on-the-order-of a constant factor in the exponent.
"Super-exponential" just means that it's larger than k^n for all k, as I've encountered it. I've never seen it used to refer to any specific function.
Just because a problem was solved in a 25 page paper does not mean it isn't a suitable homework problem, even if you didn't manage to find the solution yourself.
It's not like you'd be expected to write up in the detail they gave. More likely than not the *real* major fruit of the paper (the general approach) was covered in class, and you're just proving a corollary.
Half the trick to courses like that, IME, is to relax and just take it as a series of fun problems. Courses like that are never graded on a 70/80/90 scale, so stressing about the grade you get on any particular assignment, or even on a series of assignments, is just counterproductive.
Nowadays it consistently works if one of the two endpoints is not behind NAT, at least for AIM.
$80k in San Fran is as good as $45k in Champaign.
That's total bullshit.
Sure, I'm paying twice as much for an apartment here on the SF peninsula (working across the street from EA, no less) than I would have in Champaign. I'm also paying somewhat higher taxes. On the other hand, my basic living expenses are a small fraction of my salary, and Amazon and Newegg are no cheaper in Champaign than they are in San Francisco.
I mean, heck, it's not like you're going to buy a car for $20K here but get the same car for only $12K in Champaign.
And, as I see it, there is no reason a company in Champaign should pay me less just because it is cheaper there. My work is no less valuable in Champaign than it is here. Sure, I could live comfortably on around what I pay for just rent here, but why should my employer pocket the difference?
I call bullshit on that. Would you like to provide a cite?
I mean, I'm anything but a MS apologist, but when I interned there the majority of people I worked with were over 30.
Sure. Satire can be informative even if it isn't funny.
I'd argue "insightful" rather than "informative", though.
A much better tactic would be to sue the FSF over something they did wrong and since they probably don't have much in the way capital to actually be awarded the foudation itself. A take over. You can then null and void any limitations to GPL code you don't like for everyone. A clause in the GPL gives the FSF power to relicence code however they want; and that kind of power is an asset. You could make all code public domain if you wanted or sell specific projects code to closed source companies for a profit. I'm surprised microsoft and the old unix companies havn't tried this. The question is what to sue over... but lawyers are pretty crafty.
(OB IANAL)
The FSF only has control over two things: the GPL itself and code whose copyright has been granted to them. Changing the former only works if the license version used is not fixed (eg, the "or any later version" language). There are several safeguards even against a hostile later license: firstly, that the license specifically says that later changes will have the same spirit, so one might argue that a GPLv3 with a "BlueCoder gets all rights" clause would not even *be* a later version of the GPL. Alternatively, it might be enforceable by contract; that language might be interpretable as a contract between the FSF and people using the GPL license that the license will not so change. Even failing that, there'd be estoppel arguments.
Even for code with FSF assigned copyright, similar contract and estoppel arguments might apply. They might own the copyright, but the copyright was assigned with the understanding that the FSF would use it in good faith. A change in FSF leadership couldn't just sell it all off, I think. (but IANAL)
OB: IANAL
The second argument doesn't work, in that there *is* no such "internal use" exception. (I believe the FSF does not consider internal use to be distribution, but that doesn't give you a way out.)
The problem with any "make an ABI compatible stub" approach is that you need that stub to not be a derivative work of the library! You might be able to pull that off, but at minimum it would probably require a clean room reverse engineering approach.
One legitimate effect of this is that the GPL-linking business has no teeth for a library with a standard ABI; assuming there isn't any header produced non ABI code, you could link against such a library without your program being a derivative work. (but IANAL; I might be wrong.) As such, there's no reason (barring it, itself, being derivative of GPL) for such a library to be GPL in the first place.
Common Lisp does not even have lists as an intrinsic type. What it does have are cons cells...
A list is typically just a value and another list. A cons cell *is* a list that just happens to support some extra operations.
It is completely absurd for a filesystem to kill a disk. If you were getting those errors (with the "drive ready" and "seek complete" bits being set being most common) it *strongly* suggests that either your disk is broken or it is improperly powered.
If you're actually using that disk, still, have a look at it with smartctl. In particular, run "smartctl -t long" on it, and have a look at the results. If it doesn't pass that, don't even think of trusting it with your data.
The catch as applies to the contestants "space station" is that for them to experience gravity of even close to normal Earth gravity, they would have to be at a very low altitude (compared to true low-earth orbit)
Actually, LEO is really almost negligibly close to the Earth's surface compared to, say, geosynchronous orbits.
However, no matter how close to the surface your orbit might be, you will not feel any downward force. The entire craft is accelerating downward at on the order of 9 and some odd ms^{-2}, and you with it; You don't feel any force because you're falling downward with the craft.