The security would lie in the fact that it looks different from different angles. So if you scan it/photocopy it/whatever, you only get *one* angle on it, and thus there is no easy way to get a digitized version of the watermark to feed to that other Xerox printer.
Give it a rest. We are quite aware that perfect security checking is impossible, just like the halting problem. IT IS NOT POSSIBLE, EVEN IN THEORY, TO WRITE AN ALGORITHM WHICH TELLS WHETHER ANY GIVEN HOLE IS EXPLOITABLE. Even doing this effectively in a substantial minority of cases would be an amazing feat.
However, perhaps the tool is still useful for bug checking. People still use IDSs and other similar security tools, even though they aren't perfect, and give both false positives and false negatives.
Not checking the results of malloc() isn't the worst thing you can do. If malloc returns EBUYMOREMEMORY, usually the worst you can do is segfault. That sort of thing is in the "bugs" category, and is not usually exploitable except for DoS attacks.
The nastier bugs are generally buffer overflows, not authenticating data, and interpolating passed strings into commands without escaping them. Occasionally you see other exploitable bugs (bad user authentication, man in the middle or eavesdropping, etc), but these must be at least 95% of the easily exploitable ones.
Mutation engines and polymorphic encryption can be pretty evil for this sort of thing. Basically you encrypt most of the worm (doesn't have to be good encryption, it's just there to confuse scanners), and then have the decryption engine mutate (change order of instructions, values of literals for a different key). This sort of thing confuses the hell out of scanners for quite awhile.
Hm. I guess a biscuit is sort of like a scone. But generally a biscuit is salty and has more butter than a scone, and less sugar. People sometimes dip them in gravy. I don't know of any British equivalent, as it seems to be more or less unique to the American South. You might as well ask for an equivalent to grits.
Why the fuck must people use silly units like "milliamp-hours?"
The reason for mAh is very simple, actually. The number is used to calculate battery life of a device. The current draw on almost all small electronic components is rated in milliamps. So you want them rated in mAh to get a lifetime in hours with one division, no conversion factor.
If you were to rate them in Coulombs, you'd get a lifetime rating in kiloseconds.
This is also the reason we measure household energy in kWh instead of MJ, and speed in km/h (or mi/h) instead of in m/s: the time unit that you care about in these circumstances is hours, not seconds.
Anyway, at least they're using the metric system. Lots of things are still predominantly measured in annoying units like feet, pounds per sqaure inch, tablespoons and fluid ounces.
I don't recall the brand name, but Fry's electronics sells 2300mAh NiMH batteries (at least they did as of last week, when I was there). I don't think they're worth it for most purposes, though, because they cost $13/4 instead of $10/4 for the 2000mAh ones.
And I bet you can get higher if you're willing to pay more, be it in uber-fancy NiMH batteries or else just standard LiIon ones.
Umm the standard for the AA sized battery is 1.5v - you go sticking batteries that put out two and a half times the expected voltage into sensitive devices and they will.. I dunno, maybe not like it.
Hm. He did say it was AA form factor, not an actual AA battery. I would guess it's a camera battery, and when you put it in (the right kind of) camera, it works quite well.
Also, I think a higher-voltage battery like that would be great for use on a breadboard in my electronics lab... it's just fewer batteries to hook up that way.
It's a sarcastic statement. The older iPod never had that feature and never advertised it, and now that it's in the newer ones, the owners of the older iPods are petitioning Apple to backport it.
Apple doesn't have any real reason to do so. It'd be nice PR to add the feature, but not adding it is incentive to buy a new iPod. Although I don't own an iPod, I personally think they should add it for PR reasons (it makes the company look friendly, improves people's view of the quality of its products, etc). Who knows whether they will.
That said, pudge is still being an asshole. When users request a new feature in a project, the developers should either reject it for a reason (even if that reason is "No, we want you to upgrade"), or put it on the to-do list. What they shouldn't do, and what bystanders especially shouldn't do, is sarcastically slag those users because they got what they paid for.
Heh. Don't worry, I'm not an antimac troll. I have an eMac at college, and my family might get a G5. I believe that their benchmarks are at least close to reasonable this time around.
Their past ones, for the later G3 and the G4, were total bullshit. The computers were good, but fast they were not. And Apple kept pulling all these specialized benchmarks out to make them look faster. Clock speed may not be the be-all and end-all, but it is still important, and the G3-G4 were sorely lacking.
Now, on RISC vs CISC, you are just plain wrong. Both architectures have their advantages and disadvantages. CISC is not inherently slower or hotter. Just look at the Transmeta Crusoe proc. It used VLIW, which can be viewed sort of like CISC to the extreme, and it was really efficient and pretty fast too. (This is sort of a stretch; VLIW shares some of the benefits of both RISC and CISC, but still, CISC does some things very well). I personally prefer RISC because it's easier to code for, but that only matters if you're writing compilers or firmware.
In terms of laptops, while the G5 runs cooler than a Pentium, it still runs quite a bit hotter than the G4 and especially the G3. You most likely don't need that sort of power in a laptop, unless you're gonna replace your desktop with it. I doubt Apple will come out with G5 laptops for some time. The best proc to get in a medium-fast laptop would be the Crusoe for its high efficiency, but consider a G3 or a VIA cool-running X86.
I wonder how cool and power-efficient Intel or IBM could make a laptop proc if they didn't push for insane clock speeds. I'd be perfectly happy with a cheap, power-efficent laptop running at 500 MHz x86, or even less with a G5-like system. The keywords being cheap and power-efficient; I'd just use it for email, programming and web anyway.
Apple benchmarked their new G6 processor against the latest 10 GHz Pentium V. They say that despite its lower clock speed, it runs their suite of PhotoShop 8 filters almost four time faster than the Pentium.
Seriously, Hans Reiser is benchmarking his own file system, and he's using benchmarks that make his system look good. Like the SpriteLFS, his filesystem has a log structure for sequential writing, which makes it look really good in tests like he performed where you write the files once.
Compare a database load, where you write small chunks of big files all the time. Without the repacker (like the cleaner in LFS), the disk becomes horribly fragmented. With the repacker, you have to include the slowdown of this background process defragging your hard disk. Ick.
I'll trust his benchmarks when he presents a final, stable release, with the repacker on, and tests it under workloads such as would be encountered on a server. I might use it on my homebox even if it sucks on a server, but it would be nice to know that he considers his structure's impact on other workloads.
At an acting convention, all the actors went to a convenience store which sold candy by the pound, and each bought one jelly bean, skittle or m&m, walking separately through the checkout line. Cost 'em about 3c apiece, and confused the hell out of the cashier.
Well, for one thing, you wouldn't want each user to vote with a simple public key; that would let anyone know who voted for whom. There are some very good PKI voting protocols out there, but here is a simple one that prevents at least mass cheating. You could cheat a few people by disconnecting them, but too many people and they would have evidence of vote fraud.
You prove your identity to the voting org (with a registration number or whatever), sign something with your public key to indicate that you requested a ballot, and they blindsign your vote. Blindsigning has the property that the signer does not know the contents of the message.
Then you wait a bit, and submit your vote (through a proxy), and they sign it again so that you can prove you submitted it.
Publishing the list of votes allows people to verify that their votes have been counted, and if it is broken down by some index with high geographical spread, say the last digits of a hash of the vote (to avoid per-county breakdowns), even people with a slow connection can verify their votes. The only disadvantage to this scheme is that everyone would have to know who voted, or else officials could inject extra votes.
Some better protocols use another stage, in which the votes are uploaded encrypted, and then the keys are uploaded later after addition to the static list has been confirmed, that sort of thing. This would be fairly secure voting over the internet, esp if the voting software were open-source and signed by the govt. I'm sure that a security researcher could poke plenty of holes in my scheme, but there are certainly protocols out there which can detect vote fraud.
While I don't entirely agree with the trollmod, his post was sarcastic and called Apple users gay... and he didn't refute the parent, he said he agreed with this one particular point, but that Apple sucks otherwise.
About being uninterested in Windows: Perhaps he has studied it and come to the conclusion that it does not meet his needs now, and will not in the near future. To use your providers analogy, I am not interested in AOL, because I do not believe that it will live up to my requirements in a service.
And I think in this case, he's entirely uninterested in their phony piece of software, but he hates the company and its marketing tactics with a vengeance. I mean, as a skinny geek I'm uninterested in weight-loss plans, but I really hate those stupid ads they send out for them.
BTW, your note on Linux only holds for good Windows software. I really, truly don't care when Bonzai Buddy comes out for Linux.
I used sentences in my War & Peace example for simplicity, they're not a good choice.
If each book has 1024 pages, and each page has 64 sentences, and you have 512 books, then that's 25 bits of entropy, or about 32 million sentences to guess. That's as many as a 2-word diceware password or 5 alphanumeric characters (ignoring case). It's stronger than those, because to crack the sentence you'd need an electronic library, but it sure would be a pain to type.
It turns out that even if you picked a random sentence from the Library of Congress, that would be at most 40-something bits, as there are only order of trillions of sentences in the LOC (although you'd have to have the electronic LOC to crack it, which only the govt could be expected to do). If you're going to pick a password from a book, start with a random word on a random page on a random book in the largest library that's convenient, use the next n words, and memorize the sentence(s) they're in.
Diceware passwords are strong and really not that hard to memorize. You can learn a 5-word one in a few minutes, type it fast, and only distributed.net or larger could attack it. Go 7 words and you're probably out of reach of the govt for the next decade.
Well, it's easy if all possible outcomes are equally likely. It's just log_2 (# of outcomes). So flipping n fair coins has n bits of entropy.
If they're not equally likely, then it's messier. I don't recall the formal definition, but I think it goes something like this in the case of passwords: if your nth guess has probability P_n of being right, then entropy is
sum (all n) P_n log_2 (n)
That is, the entropy is the average number of bits you'd need to encode a randomly selected password if you had perfectly-tuned compression. This assumes that you can generate those guesses in descending order of likelyhood without wasting too much CPU though.
The entropy measurement applies better to a corporate password policy, or something like the inkblot system, or a PIN, where an attacker could reasonably know how your passwords are generated (at least what sorts of things are likely to end up as passwords). If you mangle a word out of an old Russian dictionary, and the attacker doesn't guess this, she'll have to pretty much do a brute-force search.
Slashdot Mirror
It looks different from different angles.
Since your scanner can only see it from one angle, it can't resolve the waxy stuff vs the non-waxy.
The security would lie in the fact that it looks different from different angles. So if you scan it/photocopy it/whatever, you only get *one* angle on it, and thus there is no easy way to get a digitized version of the watermark to feed to that other Xerox printer.
... with -O2
Aren't most binary packages built with -O3?
Give it a rest. We are quite aware that perfect security checking is impossible, just like the halting problem. IT IS NOT POSSIBLE, EVEN IN THEORY, TO WRITE AN ALGORITHM WHICH TELLS WHETHER ANY GIVEN HOLE IS EXPLOITABLE. Even doing this effectively in a substantial minority of cases would be an amazing feat.
However, perhaps the tool is still useful for bug checking. People still use IDSs and other similar security tools, even though they aren't perfect, and give both false positives and false negatives.
Not checking the results of malloc() isn't the worst thing you can do. If malloc returns EBUYMOREMEMORY, usually the worst you can do is segfault. That sort of thing is in the "bugs" category, and is not usually exploitable except for DoS attacks.
The nastier bugs are generally buffer overflows, not authenticating data, and interpolating passed strings into commands without escaping them. Occasionally you see other exploitable bugs (bad user authentication, man in the middle or eavesdropping, etc), but these must be at least 95% of the easily exploitable ones.
Mutation engines and polymorphic encryption can be pretty evil for this sort of thing. Basically you encrypt most of the worm (doesn't have to be good encryption, it's just there to confuse scanners), and then have the decryption engine mutate (change order of instructions, values of literals for a different key). This sort of thing confuses the hell out of scanners for quite awhile.
Oh, so that's how those elemental damage swords work, that deal both fire and cold damage...
Hm. I guess a biscuit is sort of like a scone. But generally a biscuit is salty and has more butter than a scone, and less sugar. People sometimes dip them in gravy. I don't know of any British equivalent, as it seems to be more or less unique to the American South. You might as well ask for an equivalent to grits.
... we can always use Babelfish!
err...
Why the fuck must people use silly units like "milliamp-hours?"
The reason for mAh is very simple, actually. The number is used to calculate battery life of a device. The current draw on almost all small electronic components is rated in milliamps. So you want them rated in mAh to get a lifetime in hours with one division, no conversion factor.
If you were to rate them in Coulombs, you'd get a lifetime rating in kiloseconds.
This is also the reason we measure household energy in kWh instead of MJ, and speed in km/h (or mi/h) instead of in m/s: the time unit that you care about in these circumstances is hours, not seconds.
Anyway, at least they're using the metric system. Lots of things are still predominantly measured in annoying units like feet, pounds per sqaure inch, tablespoons and fluid ounces.
I don't recall the brand name, but Fry's electronics sells 2300mAh NiMH batteries (at least they did as of last week, when I was there). I don't think they're worth it for most purposes, though, because they cost $13/4 instead of $10/4 for the 2000mAh ones.
And I bet you can get higher if you're willing to pay more, be it in uber-fancy NiMH batteries or else just standard LiIon ones.
Umm the standard for the AA sized battery is 1.5v - you go sticking batteries that put out two and a half times the expected voltage into sensitive devices and they will .. I dunno, maybe not like it.
Hm. He did say it was AA form factor, not an actual AA battery. I would guess it's a camera battery, and when you put it in (the right kind of) camera, it works quite well.
Also, I think a higher-voltage battery like that would be great for use on a breadboard in my electronics lab... it's just fewer batteries to hook up that way.
It's a sarcastic statement. The older iPod never had that feature and never advertised it, and now that it's in the newer ones, the owners of the older iPods are petitioning Apple to backport it.
Apple doesn't have any real reason to do so. It'd be nice PR to add the feature, but not adding it is incentive to buy a new iPod. Although I don't own an iPod, I personally think they should add it for PR reasons (it makes the company look friendly, improves people's view of the quality of its products, etc). Who knows whether they will.
That said, pudge is still being an asshole. When users request a new feature in a project, the developers should either reject it for a reason (even if that reason is "No, we want you to upgrade"), or put it on the to-do list. What they shouldn't do, and what bystanders especially shouldn't do, is sarcastically slag those users because they got what they paid for.
D'oh. Oh, well, point still stands. Silly to bash non-Americans while plagiarizing them at the same time.
Where should we put our All-American Bashing-statements? You know, the ones that insult all other countries because we're #1?
.sig you copied from a French artist?
Dunno. How 'bout under that
Heh. Don't worry, I'm not an antimac troll. I have an eMac at college, and my family might get a G5. I believe that their benchmarks are at least close to reasonable this time around.
Their past ones, for the later G3 and the G4, were total bullshit. The computers were good, but fast they were not. And Apple kept pulling all these specialized benchmarks out to make them look faster. Clock speed may not be the be-all and end-all, but it is still important, and the G3-G4 were sorely lacking.
Now, on RISC vs CISC, you are just plain wrong. Both architectures have their advantages and disadvantages. CISC is not inherently slower or hotter. Just look at the Transmeta Crusoe proc. It used VLIW, which can be viewed sort of like CISC to the extreme, and it was really efficient and pretty fast too. (This is sort of a stretch; VLIW shares some of the benefits of both RISC and CISC, but still, CISC does some things very well). I personally prefer RISC because it's easier to code for, but that only matters if you're writing compilers or firmware.
In terms of laptops, while the G5 runs cooler than a Pentium, it still runs quite a bit hotter than the G4 and especially the G3. You most likely don't need that sort of power in a laptop, unless you're gonna replace your desktop with it. I doubt Apple will come out with G5 laptops for some time. The best proc to get in a medium-fast laptop would be the Crusoe for its high efficiency, but consider a G3 or a VIA cool-running X86.
I wonder how cool and power-efficient Intel or IBM could make a laptop proc if they didn't push for insane clock speeds. I'd be perfectly happy with a cheap, power-efficent laptop running at 500 MHz x86, or even less with a G5-like system. The keywords being cheap and power-efficient; I'd just use it for email, programming and web anyway.
Apple benchmarked their new G6 processor against the latest 10 GHz Pentium V. They say that despite its lower clock speed, it runs their suite of PhotoShop 8 filters almost four time faster than the Pentium.
Seriously, Hans Reiser is benchmarking his own file system, and he's using benchmarks that make his system look good. Like the SpriteLFS, his filesystem has a log structure for sequential writing, which makes it look really good in tests like he performed where you write the files once.
Compare a database load, where you write small chunks of big files all the time. Without the repacker (like the cleaner in LFS), the disk becomes horribly fragmented. With the repacker, you have to include the slowdown of this background process defragging your hard disk. Ick.
I'll trust his benchmarks when he presents a final, stable release, with the repacker on, and tests it under workloads such as would be encountered on a server. I might use it on my homebox even if it sucks on a server, but it would be nice to know that he considers his structure's impact on other workloads.
At an acting convention, all the actors went to a convenience store which sold candy by the pound, and each bought one jelly bean, skittle or m&m, walking separately through the checkout line. Cost 'em about 3c apiece, and confused the hell out of the cashier.
Well, for one thing, you wouldn't want each user to vote with a simple public key; that would let anyone know who voted for whom. There are some very good PKI voting protocols out there, but here is a simple one that prevents at least mass cheating. You could cheat a few people by disconnecting them, but too many people and they would have evidence of vote fraud.
You prove your identity to the voting org (with a registration number or whatever), sign something with your public key to indicate that you requested a ballot, and they blindsign your vote. Blindsigning has the property that the signer does not know the contents of the message.
Then you wait a bit, and submit your vote (through a proxy), and they sign it again so that you can prove you submitted it.
Publishing the list of votes allows people to verify that their votes have been counted, and if it is broken down by some index with high geographical spread, say the last digits of a hash of the vote (to avoid per-county breakdowns), even people with a slow connection can verify their votes. The only disadvantage to this scheme is that everyone would have to know who voted, or else officials could inject extra votes.
Some better protocols use another stage, in which the votes are uploaded encrypted, and then the keys are uploaded later after addition to the static list has been confirmed, that sort of thing. This would be fairly secure voting over the internet, esp if the voting software were open-source and signed by the govt. I'm sure that a security researcher could poke plenty of holes in my scheme, but there are certainly protocols out there which can detect vote fraud.
While I don't entirely agree with the trollmod, his post was sarcastic and called Apple users gay... and he didn't refute the parent, he said he agreed with this one particular point, but that Apple sucks otherwise.
I don't think this is a case of Mac zeal.
About being uninterested in Windows: Perhaps he has studied it and come to the conclusion that it does not meet his needs now, and will not in the near future. To use your providers analogy, I am not interested in AOL, because I do not believe that it will live up to my requirements in a service.
And I think in this case, he's entirely uninterested in their phony piece of software, but he hates the company and its marketing tactics with a vengeance. I mean, as a skinny geek I'm uninterested in weight-loss plans, but I really hate those stupid ads they send out for them.
BTW, your note on Linux only holds for good Windows software. I really, truly don't care when Bonzai Buddy comes out for Linux.
Yes. He did do it in seconds. But it wasnt 1-100, it was some weird arith sequence.
Forgive me, but where on Earth would you use silencer in the Swedish artillery?
Ummm... Sweden?
I used sentences in my War & Peace example for simplicity, they're not a good choice.
If each book has 1024 pages, and each page has 64 sentences, and you have 512 books, then that's 25 bits of entropy, or about 32 million sentences to guess. That's as many as a 2-word diceware password or 5 alphanumeric characters (ignoring case). It's stronger than those, because to crack the sentence you'd need an electronic library, but it sure would be a pain to type.
It turns out that even if you picked a random sentence from the Library of Congress, that would be at most 40-something bits, as there are only order of trillions of sentences in the LOC (although you'd have to have the electronic LOC to crack it, which only the govt could be expected to do). If you're going to pick a password from a book, start with a random word on a random page on a random book in the largest library that's convenient, use the next n words, and memorize the sentence(s) they're in.
Diceware passwords are strong and really not that hard to memorize. You can learn a 5-word one in a few minutes, type it fast, and only distributed.net or larger could attack it. Go 7 words and you're probably out of reach of the govt for the next decade.
Well, it's easy if all possible outcomes are equally likely. It's just log_2 (# of outcomes). So flipping n fair coins has n bits of entropy.
If they're not equally likely, then it's messier. I don't recall the formal definition, but I think it goes something like this in the case of passwords: if your nth guess has probability P_n of being right, then entropy is
sum (all n) P_n log_2 (n)
That is, the entropy is the average number of bits you'd need to encode a randomly selected password if you had perfectly-tuned compression. This assumes that you can generate those guesses in descending order of likelyhood without wasting too much CPU though.
The entropy measurement applies better to a corporate password policy, or something like the inkblot system, or a PIN, where an attacker could reasonably know how your passwords are generated (at least what sorts of things are likely to end up as passwords). If you mangle a word out of an old Russian dictionary, and the attacker doesn't guess this, she'll have to pretty much do a brute-force search.