Oh, don't get me wrong. Kim's no one to love. He's a sleazeball as greasy as they come, and I have no delusions that he's doing this for any altruistic reasons.
I have my own well-considered system of ethics, but as you imply, we will never see a universal consensus. I'll skip past the last few millenia of philosophical debate and take you right to the time-tested standard:
Civil disobedience is flagrantly ignoring a law because it is unjust. If they ignore you, the sense of the law erodes. If they arrest you, you become a martyr. Either way you win. MegaUpload, The Pirate Bay, and all the positive things I mentioned earlier are civil disobedience.
DOS attacks aren't like refusing to go to the back of the bus... They're sugar in the gas tank. Anonymous vandalism isn't going to generate sympathy from your fellow citizens.
I hope these script kiddies aren't so foolish as to make the same mistakes twice.
Fuck that. I hope they do. DOS attacks are the lamest, most degenerate hacktivism ever. It doesn't change anyone's minds, it doesn't help create a better system, and it just causes damage in the process. The only thing it accomplishes is sating some primal desire for revenge, so I hope they get filtered out of the pool so the rest of us can go back to creating instead of defending.
You want to try to make things better but you're feeling disenfranchised? Subvert the system. Work on decentralized DNS replacements. Work on anonymity networks. Work on improving Bitcoin to make it a serious contender. Generate content and release it for free.
I disagree. Parallel is disappearing fast; serial still has a useful niche as the ultimate in simple communications, so it has a reason why it's hanging on.
VGA is completely irrelevant in the current age of flat panels. When's the last time anyone you know even considered buying a CRT? Analog video is dead, and good riddance.
DVI will hang on for a while, but the high pin count (big connectors, bulky relatively expensive cables, complicated PCB routing) will cause market pressure toward DisplayPort, HDMI, and other lower pin count standards.
The skin-drag effect is only a minor source of inefficiency in most boats. The viscosity drag dominates at low speed and displacement waves are the big one at high speed. The former you fight with a good hull shape. The latter requires increasing the length of the boat.
On the other hand, planing hulls might benefit a little. I'm not sure how big the effect would be.
As for fouling, Teflon would be a better defense, but barnacles will find a way to stick to anything.
My other half has an old iPhone on TMobile, no data plan. It works just fine. There's no visual voice mail but it knows the number to call to retrieve it the old way.
We shouldn't create laws just because someone might do something stupid. That's part of the mentality that creates the convoluted mess of laws we have now.
Wait until people are actually doing something stupid, and if they won't stop after it's pointed out, then make a law.
60-70% IPA actually kills bugs better than pure, which is why the stuff at the drug store is usually 70%. I've heard two explanations why: #1, it doesn't coagulate the proteins at the surface as much and therefore does a better job getting inside the critters; #2, it evaporates an order of magnitude slower, whereas 100% disappears from your skin or the surface being cleaned within seconds.
I care when it's gotten to the point where there is literally nothing to watch that doesn't leave me feeling disgusted. I don't care what any individual is doing, but as a society it cannot be good that programming has gotten so low; filling our brains with this stuff is not going to advance us anywhere, so why are we wasting valuable spectrum on it?
Wipe it out and replace it with something intelligent.
BTRFS is journaled (the log tree), so you don't lose data due to a power failure. It just replays the journal when you mount it again.
btrfsck is only really needed to recover from something unanticipated happening. Like software bugs. The kind that you'd expect in a new filesystem. So it's absolutely not ready for prime-time until a fsck is released.
For non-critical systems it's completely usable for people who like to experiment with the new toys. I've been using it for a year on my laptop (including multiple power losses and other shenanigans) with no problems.
My experience so far:
Good:
Snapshots (and subvolumes) are a killer feature. Having hourly and daily versions of everything is wonderful. I have subvolumes for root (@) and/home (@home). If I want to roll back my entire system but keep my homedir, I can simply: "cd/snap ; mv @ @-2012.01.04-broken ; btrfs subv snap @-2012-01-02--00-40-39-apt @ ; reboot". Translated - Save a copy of my current root; create a new root from the last snapshot that was automatically created when I last ran apt-get ; then reboot (all shutdown continues in the @-2012.01.04-broken subvolume, it doesn't corrupt the new @). Killer. Feature.
Bad:
fsync is god.awful.slow. And dpkg does a whole lot of fsync. It's completely unacceptable performance, and either btrfs has to get faster or dpkg has to be a little more miserly with fsync. If dpkg could send write barriers instead of syncs it'd probably solve it, but who knows. For the time being: "apt-get install eatmydata; ln -s `which eatmydata`/usr/local/bin/aptitude ; ln -s `which eatmydata`/usr/local/bin/apt-get" . eatmydata preloads a library that overrides sync and fsync (they're simply ignored). dpkg is now screaming fast, but I run the risk of completely screwing its metadata if there's a crash or poweroff while it's doing something. So the solution is I have a/etc/apt/apt.conf.d/80-snapshot that creates a snapshot before every apt run. If something goes wrong, I just roll back the system like I mentioned under Good.
So in summary: Some good, some bad, definitely not fully baked yet, but completely usable if you're adventurous. No fsck required. Yet. Keep backups.:)
Some of the problems you're describing have to do with Transport Mode. Tunnel Mode encapsulates the whole IP packet, and creates an actual shared private network between your endpoint and the VPN server. If you enable UDP encapsulation it also traverses uncooperative NAT.
Tunnel Mode can be done in userspace since it's able to spit out complete packets on a TUN interface. Basically it's everything you want, except overly complicated and hard to figure out in the way that any too-generalized system tends to be.
it *never* works [by design] if two people on the same network are connecting to the same endpoint from behind the same nat firewall
That's true of Transport Mode, but Tunnel Mode (where entire IP packets are encapsulated instead of just the data) deals with that situation just fine. If you enable UDP encapsulation it also traverses uncooperative NAT.
I used to do this back when processors didn't have good power management.
Now you don't have to. This is what frequency scaling (SpeedStep / Cool'n'Quiet) is for. It automatically underclocks and undervolts the processor when it's idle, then spins it up to full when you're ready to use it.
Interestingly, it actually draws less energy to go to full speed for a moment when it has work to do. It uses more power for the burst, but it gets back to sleep sooner for a net savings. For this reason there isn't much to be gained by going even lower.
End users and vendors alike will dismiss any threat as merely theoretical until it's actively being exploited. The real question is when to release, not if.
Re:That's how money works - a shared hallucination
on
The Bitcoin Strikes Back
·
· Score: 4, Informative
For instance, a break through in prime factorization (or however bitcoins are created) that is kept secret could mean that someone generates a ton of money out of thin air, which are impossible to identify apart from normal bitcoins (as they would be legitimate bitcoins).
They're created through brute forcing SHA256 hashes to meet a specific criteria. As the global hashrate rises, a difficulty factor is automatically adjusted to keep generation constant at 300 per hour.
If you invent an inexpensive piece of hardware that can push several orders of magnitude more SHA256 hashes per joule, you will successfully capture a disproportionate percentage of those 300 coins per hour. You do not get to generate unlimited coins - you just asymptotically approach 300/hour.
In fact, this has already happened: hashing used to be done on CPUs at about 10-20 MHash/s per core; then the RadeonHD happened. Suddenly some people had access to hundreds / thousands of "cores" (they're vector processors, practically miniature Crays for $200 a pop for this problem), pushing 500-1000 MH/s per GPU. Hashrate surged by orders of magnitude as people bought 58xx and 59xx cards as fast as they could make them, and difficulty rose in lockstep. End result: CPUs are now irrelevant and Radeons are marginally profitable if you have cheap power. It wasn't a problem.
It's also easy to switch to a new proof-of-work if someone completely breaks SHA256.
There are some significant weaknesses in Bitcoin, but this isn't one of them.
I'm pretty far off to one end of the nerd-jock spectrum. I had no problems breathing, but it was interesting being barely able to lift my own arms: I couldn't lift them directly from my sides and had to increase leverage by bending them at the elbow and then pushing like a bench press.
While I don't think they need top-notch athletes, I can definitely say that physical fitness in the top few percentiles is a reasonable requirement for the job. There's no way I could reach up to punch an abort button in less than a second if it was necessary during launch.
Slashdot Mirror
Oh, don't get me wrong. Kim's no one to love. He's a sleazeball as greasy as they come, and I have no delusions that he's doing this for any altruistic reasons.
But at least he's doing something interesting.
But who decides if it is unjust?
I have my own well-considered system of ethics, but as you imply, we will never see a universal consensus. I'll skip past the last few millenia of philosophical debate and take you right to the time-tested standard:
Whoever wins in the end.
Explain it to me, then. What don't I understand?
Civil disobedience is flagrantly ignoring a law because it is unjust. If they ignore you, the sense of the law erodes. If they arrest you, you become a martyr. Either way you win. MegaUpload, The Pirate Bay, and all the positive things I mentioned earlier are civil disobedience.
DOS attacks aren't like refusing to go to the back of the bus... They're sugar in the gas tank. Anonymous vandalism isn't going to generate sympathy from your fellow citizens.
I hope these script kiddies aren't so foolish as to make the same mistakes twice.
Fuck that. I hope they do. DOS attacks are the lamest, most degenerate hacktivism ever. It doesn't change anyone's minds, it doesn't help create a better system, and it just causes damage in the process. The only thing it accomplishes is sating some primal desire for revenge, so I hope they get filtered out of the pool so the rest of us can go back to creating instead of defending.
You want to try to make things better but you're feeling disenfranchised? Subvert the system. Work on decentralized DNS replacements. Work on anonymity networks. Work on improving Bitcoin to make it a serious contender. Generate content and release it for free.
Don't destroy. Create.
I disagree. Parallel is disappearing fast; serial still has a useful niche as the ultimate in simple communications, so it has a reason why it's hanging on.
VGA is completely irrelevant in the current age of flat panels. When's the last time anyone you know even considered buying a CRT? Analog video is dead, and good riddance.
DVI will hang on for a while, but the high pin count (big connectors, bulky relatively expensive cables, complicated PCB routing) will cause market pressure toward DisplayPort, HDMI, and other lower pin count standards.
The skin-drag effect is only a minor source of inefficiency in most boats. The viscosity drag dominates at low speed and displacement waves are the big one at high speed. The former you fight with a good hull shape. The latter requires increasing the length of the boat.
On the other hand, planing hulls might benefit a little. I'm not sure how big the effect would be.
As for fouling, Teflon would be a better defense, but barnacles will find a way to stick to anything.
My other half has an old iPhone on TMobile, no data plan. It works just fine. There's no visual voice mail but it knows the number to call to retrieve it the old way.
"Never let the facts get in the way of a good story"
We shouldn't create laws just because someone might do something stupid. That's part of the mentality that creates the convoluted mess of laws we have now.
Wait until people are actually doing something stupid, and if they won't stop after it's pointed out, then make a law.
Nope. This is with old fashioned spinning media.
It's a known problem. Google "btrfs dpkg"... it's just a question of which side wants to tackle it first.
60-70% IPA actually kills bugs better than pure, which is why the stuff at the drug store is usually 70%. I've heard two explanations why: #1, it doesn't coagulate the proteins at the surface as much and therefore does a better job getting inside the critters; #2, it evaporates an order of magnitude slower, whereas 100% disappears from your skin or the surface being cleaned within seconds.
I care when it's gotten to the point where there is literally nothing to watch that doesn't leave me feeling disgusted. I don't care what any individual is doing, but as a society it cannot be good that programming has gotten so low; filling our brains with this stuff is not going to advance us anywhere, so why are we wasting valuable spectrum on it?
Wipe it out and replace it with something intelligent.
I don't think it's exposed yet, but hey, that's what the future is for.
I suspect there are plenty of userspace operations that need ordering but that don't actually need the performance hit of guaranteed durability.
BTRFS is journaled (the log tree), so you don't lose data due to a power failure. It just replays the journal when you mount it again.
btrfsck is only really needed to recover from something unanticipated happening. Like software bugs. The kind that you'd expect in a new filesystem. So it's absolutely not ready for prime-time until a fsck is released.
For non-critical systems it's completely usable for people who like to experiment with the new toys. I've been using it for a year on my laptop (including multiple power losses and other shenanigans) with no problems.
My experience so far:
Good:
Snapshots (and subvolumes) are a killer feature. Having hourly and daily versions of everything is wonderful. I have subvolumes for root (@) and /home (@home). If I want to roll back my entire system but keep my homedir, I can simply: "cd /snap ; mv @ @-2012.01.04-broken ; btrfs subv snap @-2012-01-02--00-40-39-apt @ ; reboot". Translated - Save a copy of my current root; create a new root from the last snapshot that was automatically created when I last ran apt-get ; then reboot (all shutdown continues in the @-2012.01.04-broken subvolume, it doesn't corrupt the new @). Killer. Feature.
Bad:
fsync is god.awful.slow. And dpkg does a whole lot of fsync. It's completely unacceptable performance, and either btrfs has to get faster or dpkg has to be a little more miserly with fsync. If dpkg could send write barriers instead of syncs it'd probably solve it, but who knows. For the time being: "apt-get install eatmydata; ln -s `which eatmydata` /usr/local/bin/aptitude ; ln -s `which eatmydata` /usr/local/bin/apt-get" . eatmydata preloads a library that overrides sync and fsync (they're simply ignored). dpkg is now screaming fast, but I run the risk of completely screwing its metadata if there's a crash or poweroff while it's doing something. So the solution is I have a /etc/apt/apt.conf.d/80-snapshot that creates a snapshot before every apt run. If something goes wrong, I just roll back the system like I mentioned under Good.
So in summary: Some good, some bad, definitely not fully baked yet, but completely usable if you're adventurous. No fsck required. Yet. Keep backups. :)
Some of the problems you're describing have to do with Transport Mode. Tunnel Mode encapsulates the whole IP packet, and creates an actual shared private network between your endpoint and the VPN server. If you enable UDP encapsulation it also traverses uncooperative NAT.
Tunnel Mode can be done in userspace since it's able to spit out complete packets on a TUN interface. Basically it's everything you want, except overly complicated and hard to figure out in the way that any too-generalized system tends to be.
it *never* works [by design] if two people on the same network are connecting to the same endpoint from behind the same nat firewall
That's true of Transport Mode, but Tunnel Mode (where entire IP packets are encapsulated instead of just the data) deals with that situation just fine. If you enable UDP encapsulation it also traverses uncooperative NAT.
I used to do this back when processors didn't have good power management.
Now you don't have to. This is what frequency scaling (SpeedStep / Cool'n'Quiet) is for. It automatically underclocks and undervolts the processor when it's idle, then spins it up to full when you're ready to use it.
Interestingly, it actually draws less energy to go to full speed for a moment when it has work to do. It uses more power for the burst, but it gets back to sleep sooner for a net savings. For this reason there isn't much to be gained by going even lower.
End users and vendors alike will dismiss any threat as merely theoretical until it's actively being exploited. The real question is when to release, not if.
For instance, a break through in prime factorization (or however bitcoins are created) that is kept secret could mean that someone generates a ton of money out of thin air, which are impossible to identify apart from normal bitcoins (as they would be legitimate bitcoins).
They're created through brute forcing SHA256 hashes to meet a specific criteria. As the global hashrate rises, a difficulty factor is automatically adjusted to keep generation constant at 300 per hour.
If you invent an inexpensive piece of hardware that can push several orders of magnitude more SHA256 hashes per joule, you will successfully capture a disproportionate percentage of those 300 coins per hour. You do not get to generate unlimited coins - you just asymptotically approach 300/hour.
In fact, this has already happened: hashing used to be done on CPUs at about 10-20 MHash/s per core; then the RadeonHD happened. Suddenly some people had access to hundreds / thousands of "cores" (they're vector processors, practically miniature Crays for $200 a pop for this problem), pushing 500-1000 MH/s per GPU. Hashrate surged by orders of magnitude as people bought 58xx and 59xx cards as fast as they could make them, and difficulty rose in lockstep. End result: CPUs are now irrelevant and Radeons are marginally profitable if you have cheap power. It wasn't a problem.
It's also easy to switch to a new proof-of-work if someone completely breaks SHA256.
There are some significant weaknesses in Bitcoin, but this isn't one of them.
Space Academy survivor here - It pulls 3 Gs.
I'm pretty far off to one end of the nerd-jock spectrum. I had no problems breathing, but it was interesting being barely able to lift my own arms: I couldn't lift them directly from my sides and had to increase leverage by bending them at the elbow and then pushing like a bench press.
While I don't think they need top-notch athletes, I can definitely say that physical fitness in the top few percentiles is a reasonable requirement for the job. There's no way I could reach up to punch an abort button in less than a second if it was necessary during launch.
Which is why, even^H^H^H^H especially as a software engineer, I'm against putting batteries and chips in every gorram thing that does not need it.
FTFY
That won't work if you want to make use of the warranty, which is what this thread was about. :)
Water damage detectors at least have a hint of it being the consumer's fault (even if they get tripped by other things in practice).
"Warranty void if product breaks" is easily understood by the customer as "no warranty". So why not just have no warranty?
If it breaks a second time it likely won't be in the same spot. And if it was, at least you got the extra runtime.
As for the warranty... What's the point of a warranty that's void if the device breaks?