Or reimplement SLIDE from the known, published API (ie, what anyone with money pays programmers to do when implementing almost ANY standard), and use whatever license they want.
If I could pay $5 a month for just the channels I cared about, commercial free, I'd be a happy, happy man. (Comedy Central, maybe discovery, hmmm. not much else). As it is, I don't watch TV, 'cause it fucking sucks.
BTW. The post you responded to meant exactly what you said (for many of the early adopters, cable channels == HBO, etc., plus good reception). So he was talking about covering the production, not distribution, costs.
Viewer supported channels have better content (IMO), because the viewers are the customers, not the product.
Before I go try this out on my really crappy nvidia cards, is the implication that the vendor string can change? So that caching it early on is the only way to know later? That would be crazy... It must mean something else and I'm not getting it. Or is it just a speed thing (assuming this is called fairly often)?
Just FYI, the factory is in Fairfield (near Solano), which is on highway 80 as you head away from the bay toward Sacramento. A neat place to visit, and you can buy 'defect' jelly bellies on the cheap.
When I get a marketing call (which is now very rare), as soon as I determine (or suspect) what it is, I just hang up. I don't say a word. Once you get over the 'rudeness' of it, it feels quite liberating. And since I adopted that policy, cold calls basically just stopped.
Unlike spam, there is a not-insignificant cost to phone solicitations, and they will cull the phone-lists themselves (I'm assuming) for bad-numbers or callees. They may even sell the info to others.
Right. If we actually found such a "signature" in Pi, even if we could prove Pi was normal, and that we should find any length sequence of digits in it, I would be astounded enough to have my faith in Atheism shaken (back to agnostic probably).
Knowing that the sequence does exist in Pi, doesn't change the fact that actually FINDING such a long sequence would be remarkable. We have to deal with the physical limitations of exanding Pi, after all.
So, at least as a literary device, I don't think it is invalid (but while perhaps suggestive, it isn't "proof of a creator" by any means)
The government used proven techniques and technology for sequencing the gene, while Celera used cutting edge techniques (not possible or even conceived when the Genome project started) that were not without controversy in the field. The government data was there to validate Celera's work, without which, Celera could not have finished so quickly.
Celera's accomplishment was impressive (and self-serving), but it is a comparison of apples to oranges. If Celera had used the same fundamental techniques, AND had proven to be years quicker, then you could conclude they were more efficient. As it was, since they were attempting to do a genome patent land-grab, they could choose to trade certainty of the results for speed.
Fsck reports inconsistencies when checking a RW file system, because from fsck's perspective, it IS inconsistent. Things have changed that fsck didn't see, and it (correctly) reports it. Some file systems are designed to allow fsck to work on a RW filesystem (FreeBSD soft-writes, to a limited extent).
Remounting RO "cleans up" for fsck, by flushing all pending writes to disk, and insuring that no new writes happen during fsck's run. Even on an 'idle' system, writes to the file system can and do occur (to update meta-data, if nothing else). If you REALLY want to run fsck on a RW file-system, you should at least use the "noatime" mount flag, and possibly "sync", and "dirsync" as well.
You can also use LVM, and create "snapshots" of the live filesystem, which can then be checked for consistency offline, while the original filesystem chugs along.
I agree that it is highly unlikely that the fsck errors you see are anything more than anomalies caused by your method of checking (unless you have some funky power source or radiation that is affecting a variety of systems). ext2 is considered to be quite stable (ie. wont become inconsistent over time on working hardware). Are these SCSI disks or IDE? I'd suspect the disk driver code before the filesystem code.
Well, I have to infer a lot of what you want, but why not just hack on the dhcpd source to make it more scalable? Allow it to automatically process updates of the config file, using some locking method to keep things sane (or check a database that you control, for updates)
I'm assuming the main performance issue to address is the shutdown/update/startup cycle, which you could eliminate. Other performance issues could also be addressed if need be; it is open source after all.
Furthermore, the article doesn't say how much of the total keyspace was searched (I'm assuming it was a simple exhaustive search algorithm). The time to search 50% of the keyspace, and 100% of the keyspace (corresponding to average and max time to "break" another 109 key, at the same average key checking rate) would be very useful to know.
But yes, this isn't breaking the algorithm, by any means. In fact, the contest is meant to show how infeasible a brute-force attack is against larger key sizes.
So can she still be a 'geek'? Of the Slashdot kind?
(She is hardcore into Dianetics, and at least somewhat under "church" control... This is from radio interviews I heard with her, so I wasn't distracted by her looks.:)
Well, I had a huge wart on my big toe, which grew back after being burned off with acid and a hot needle. Then my sister stepped on it at the airport in Hawaii (I was wearing slippers), ripping it clean off. This was at the baggage counter, where family were all trying to hug me and say, "hello". I bled all over the place. However, a dog came up and ate the ripped off wart, and followed me around licking up much of the blood.
The remaining wart crater scabbed over with a hard black shell, which I eventually tore off with some tweezers. The wart never came back.
In a one time pad, the frequencies of bits in the message (ie. whether the message is compressed or not, 7-bit or 8-bit), is irrelevant. You could add mountains of redundancy and it wouldn't make a lick of difference, assuming the one time key is sufficiently "random" (For practical purposes, let's just say the key should be incompressible, and unguessable).
So, the term "known plaintext attack" isn't really relevant to OTP (unless keys are reused, which is, by definition, NOT a one time pad).
What you refer to in your posting is an attack on a system that uses shorter keys than the message length, not a one time pad.
True. And that is why I said "properly used" OTP. So, if what Kip says is actually true, it may certainly be more convenient than proper OTP. But I doubt it is both, as secure, and more convenient (or even, frankly, nearly as secure and more convenient).
Re:Swapping Values Without Using a Temporary Varia
on
The Python Cookbook
·
· Score: 2
You forgot the part where A and B are declared as 'float', and so this clever trick is really stupid and/or invalid, a lot of the time.
Furthermore, I am confused by this sentence in Kip's posting:
The advantages are proof (i.e. unbreakable) against brute force attacks and known-plaintext attacks (unlike the OTP).
Which implies that the OTP is insecure with known-plaintext, or by brute-forcing, which is untrue for any correctly used OTP. So, either Kip Knight didn't express very well what he meant, or he is not as well versed in cryptography as he should be.
In any case, the proof is in the pudding. I remain skeptical of the claims.
the most notable contribution was probably NFS, and Sun gave it away long before most of us had ever heard of the GPL.
Uhhh, just to clarify, Sun published the specs to NFS, but (as far as I know), did not open source, or even publish, their code (I'll gladly accept corrections on that, BTW.)
NP posts probably started in earnest right after Episode I (about 3.5 years ago). For a while, there were many "Natalie Portman countdown posts", indicating how many days it was before you could be free to have "legally" unobjectionable impure thoughts about her.
Or reimplement SLIDE from the known, published API (ie, what anyone with money pays programmers to do when implementing almost ANY standard), and use whatever license they want.
If I could pay $5 a month for just the channels I cared about, commercial free, I'd be a happy, happy man. (Comedy Central, maybe discovery, hmmm. not much else). As it is, I don't watch TV, 'cause it fucking sucks.
BTW. The post you responded to meant exactly what you said (for many of the early adopters, cable channels == HBO, etc., plus good reception). So he was talking about covering the production, not distribution, costs.
Viewer supported channels have better content (IMO), because the viewers are the customers, not the product.
Before I go try this out on my really crappy nvidia cards, is the implication that the vendor string can change? So that caching it early on is the only way to know later? That would be crazy... It must mean something else and I'm not getting it. Or is it just a speed thing (assuming this is called fairly often)?
Just FYI, the factory is in Fairfield (near Solano), which is on highway 80 as you head away from the bay toward Sacramento. A neat place to visit, and you can buy 'defect' jelly bellies on the cheap.
When I get a marketing call (which is now very rare), as soon as I determine (or suspect) what it is, I just hang up. I don't say a word. Once you get over the 'rudeness' of it, it feels quite liberating. And since I adopted that policy, cold calls basically just stopped.
Unlike spam, there is a not-insignificant cost to phone solicitations, and they will cull the phone-lists themselves (I'm assuming) for bad-numbers or callees. They may even sell the info to others.
Right. If we actually found such a "signature" in Pi, even if we could prove Pi was normal, and that we should find any length sequence of digits in it, I would be astounded enough to have my faith in Atheism shaken (back to agnostic probably).
Knowing that the sequence does exist in Pi, doesn't change the fact that actually FINDING such a long sequence would be remarkable. We have to deal with the physical limitations of exanding Pi, after all.
So, at least as a literary device, I don't think it is invalid (but while perhaps suggestive, it isn't "proof of a creator" by any means)
I think the movie "Pi" had similar issues, BTW.
No. But possibly "normal" is.
The government used proven techniques and technology for sequencing the gene, while Celera used cutting edge techniques (not possible or even conceived when the Genome project started) that were not without controversy in the field. The government data was there to validate Celera's work, without which, Celera could not have finished so quickly.
Celera's accomplishment was impressive (and self-serving), but it is a comparison of apples to oranges. If Celera had used the same fundamental techniques, AND had proven to be years quicker, then you could conclude they were more efficient. As it was, since they were attempting to do a genome patent land-grab, they could choose to trade certainty of the results for speed.
You may want to include some 'lore' about important files that were lost without any backups.
Fsck reports inconsistencies when checking a RW file system, because from fsck's perspective, it IS inconsistent. Things have changed that fsck didn't see, and it (correctly) reports it. Some file systems are designed to allow fsck to work on a RW filesystem (FreeBSD soft-writes, to a limited extent).
Remounting RO "cleans up" for fsck, by flushing all pending writes to disk, and insuring that no new writes happen during fsck's run. Even on an 'idle' system, writes to the file system can and do occur (to update meta-data, if nothing else). If you REALLY want to run fsck on a RW file-system, you should at least use the "noatime" mount flag, and possibly "sync", and "dirsync" as well.
You can also use LVM, and create "snapshots" of the live filesystem, which can then be checked for consistency offline, while the original filesystem chugs along.
I agree that it is highly unlikely that the fsck errors you see are anything more than anomalies caused by your method of checking (unless you have some funky power source or radiation that is affecting a variety of systems). ext2 is considered to be quite stable (ie. wont become inconsistent over time on working hardware). Are these SCSI disks or IDE? I'd suspect the disk driver code before the filesystem code.
aw crap. Next time I'll shut up.
geo is pronounce jee-oh, not gooey.
gee, Oh!
Well, I have to infer a lot of what you want, but why not just hack on the dhcpd source to make it more scalable? Allow it to automatically process updates of the config file, using some locking method to keep things sane (or check a database that you control, for updates)
I'm assuming the main performance issue to address is the shutdown/update/startup cycle, which you could eliminate. Other performance issues could also be addressed if need be; it is open source after all.
Furthermore, the article doesn't say how much of the total keyspace was searched (I'm assuming it was a simple exhaustive search algorithm). The time to search 50% of the keyspace, and 100% of the keyspace (corresponding to average and max time to "break" another 109 key, at the same average key checking rate) would be very useful to know.
But yes, this isn't breaking the algorithm, by any means. In fact, the contest is meant to show how infeasible a brute-force attack is against larger key sizes.
"cryptographic hash" != "checksum"
What you propose is not feasible, if a hash like SHA or even MD5 is used.
And the next time, the first kid gets 7/8 and the second gets 1/8.
And the next time, the first kid gets 15/16 and the second gets 1/16.
etc...
So can she still be a 'geek'? Of the Slashdot kind?
:)
(She is hardcore into Dianetics, and at least somewhat under "church" control... This is from radio interviews I heard with her, so I wasn't distracted by her looks.
Well, I had a huge wart on my big toe, which grew back after being burned off with acid and a hot needle. Then my sister stepped on it at the airport in Hawaii (I was wearing slippers), ripping it clean off. This was at the baggage counter, where family were all trying to hug me and say, "hello". I bled all over the place. However, a dog came up and ate the ripped off wart, and followed me around licking up much of the blood.
The remaining wart crater scabbed over with a hard black shell, which I eventually tore off with some tweezers. The wart never came back.
'nuff said.
In a one time pad, the frequencies of bits in the message (ie. whether the message is compressed or not, 7-bit or 8-bit), is irrelevant. You could add mountains of redundancy and it wouldn't make a lick of difference, assuming the one time key is sufficiently "random" (For practical purposes, let's just say the key should be incompressible, and unguessable).
So, the term "known plaintext attack" isn't really relevant to OTP (unless keys are reused, which is, by definition, NOT a one time pad).
What you refer to in your posting is an attack on a system that uses shorter keys than the message length, not a one time pad.
True. And that is why I said "properly used" OTP. So, if what Kip says is actually true, it may certainly be more convenient than proper OTP. But I doubt it is both, as secure, and more convenient (or even, frankly, nearly as secure and more convenient).
You forgot the part where A and B are declared as 'float', and so this clever trick is really stupid and/or invalid, a lot of the time.
Furthermore, I am confused by this sentence in Kip's posting:
The advantages are proof (i.e. unbreakable) against brute force attacks and known-plaintext attacks (unlike the OTP).
Which implies that the OTP is insecure with known-plaintext, or by brute-forcing, which is untrue for any correctly used OTP. So, either Kip Knight didn't express very well what he meant, or he is not as well versed in cryptography as he should be.
In any case, the proof is in the pudding. I remain skeptical of the claims.
the most notable contribution was probably NFS, and Sun gave it away long before most of us had ever heard of the GPL.
Uhhh, just to clarify, Sun published the specs to NFS, but (as far as I know), did not open source, or even publish, their code (I'll gladly accept corrections on that, BTW.)
NP posts probably started in earnest right after Episode I (about 3.5 years ago). For a while, there were many "Natalie Portman countdown posts", indicating how many days it was before you could be free to have "legally" unobjectionable impure thoughts about her.