And, being the raving geniuses that they are, they store the on-camera key on a little serial EEPROM just like network card makers and everyone else use for unique identifiers ('93C46...), and the hacker cuts its clock pin to set the key to 00-00-00-00-00-00-00-00....:-)
just under $1K/G, a 30G model I recently held in my hand was worth much more than my car
Gotcha beat, I can buy a regular CompactFlash card at Best Buy that's worth more than my car. (...insensitive clod!...)
All that aside, each bit of a typical Flash memory is rated at only 100,000 ~ 1M write/erase cycles...in fact, for all but the most expensive, there's no guarantee against cells failing considerably earlier, or even defective / "soft" cells from the factory. (Typically expressed as a percentage, e.g. smallnum% bad bits, with the first sector of memory certified bad-bit-free).
Is there any information on how these Flash drives stack up, reliability-wise, against conventional magnetic HDDs?
I want an automatically-actuated "asshole mirror". I keep one in the center console for those special occasions, but it just isn't the same. It's for that asshole, you know the one, in the SUV who sits two inches off your back bumper giving you a suntan with his brights. That's when the asshole mirror comes out - hm, down a little...a little to the left...Bingo! He's slowing way down....wait a minute dude, that wasn't supposed to mean "pull into that ditch over there and burst into flames". Damn.
Conversely though, I wonder if compression artifacts could be one of the very things the algorithm looks at. Your digital camera takes a picture, compresses it with JPEG and produces subtle (to the eye) artifacts. Now start moving things around in the image (lets assume for the moment you're not even grafting in UFOs), and now the artifacts have moved with them, and can be identified as not being where the JPEG algorithm would put them. Of course, to make it look convincing, you've probably used some smoothing, airbrushing, feathering etc. filters, which will have obliterated artifacts entirely in some places. Finally, suppose you do graft in a UFO--where does this picture come from, and does it have compression artifacts of its own? Even if it came from the same camera, differences in the images mean differences in the compression. But the UFO's probably been resized, rotated, etc., further messing up the artifacts. Of course, just like when you move stuff around in the same image, they're not going to match up anyway. I think this would be a very easy thing for an algorithm to look at.
Of course, you could just save the doctored foto itself as a low-quality JPEG - but a) if it's going in a newspaper, do you want low quality?, and b) you're still just adding your own artifacts to the original - it's going to be some pretty severe compression before they're undetectable.
Nowadays I'd really have to recommend against catch-all accounts.
We used to run a catch-all at a server I administer, it had been a thing of beauty for a number of years. Few spams to never-existant addresses (the occasional crap addressed to "info@" and "sales@" were about it), and the convenience of never having to keep track of the made-up-on-the-spot email addresses given out to shady people, registrations, etc. A few addresses got into the hands of hardcore spammers; these were replaced with an autoresponder politely directing live humans to another address.
Then, early this year, some Windows virus-or-other came out which sent mails to random and other novelly-generated addresses (joe@, bob@, username from another domain @yourdomain.com), and spread rapidly. Within a couple days, the catch-all account (read: my inbox) was receiving upward of 10,000 (yes, that's not a typo) copies of these huge Windows viruses per day.
Not only this, but those couple of autoresponders were also being hammered by mails from forged addresses, causing them to send a "this address is deprecated, please use..."-type mail (or lots of them) to people who never sent mail to that address in the first place. This included the administrator of one particular Debian-related mailing list, who I remember as being rather rude, threatening to get our domain UDPed, blacklisted, sent to Detroit or whatever is today's preferred form of vengeance from someone closer to the backbone than you are.
Needless to say, life with catch-alls ended for us in short order (with a couple months of occasional "what happened to your address, it's dead!" from people sending to addresses I didn't remember to create after removing the catch-all functionality), and life + my inbox returned to normal.
As I understand it, you can also send in a board layout made in another program (e.g. Eagle, ORCAD, etc.) : see the FAQ near "Gerber" (a popular board-design file format).
My favorite fill-in address. I'm surprised it doesn't have more of a google following, although it hasn't actually been "valid" (in the fuck-a-spammer sense) for a number of years. Still, it seems like it should be a pretty clear indication to an address-demanding site/service, of how the user expects them to make use of the information...
Of course, if a fill-in form is ever wise to that one, I can always consult the list.
Ahh..the Highly Increased Paperwork for (medical) Administrators Act.
A while back I consulted with an office (in this case, dental) to ensure that they were in compliance with the Act before it took effect. One thing I found was that the office's actual privacy practices didn't (and didn't need to) change one bit - information is only allowed to be given out in the same special circumstances as before, e.g. releasing information to a legal guardian, pursuant to court order, or in certain cases for the purpose of identifying a body via dental records.
What the Act DID do is roughly double the amount of paperwork that has to be retained and dealt with for each patient. This went from "charts" to "charts + HIPAA disclosure notice and signature + any special requests or deviations as required"...
Whoever calls an LM78xx/LM317/etc. a linear supply, try leaving off the little 0.1u capacitor near the input terminals and move the larger, typically electrolytic filter cap some distance away. They may classify technically as "linear" because they don't involve a chopper/PWM driving a transformer, but there is still a current-hungry transistor at the input being switched rapidly on and off...
I am seeing arguments for blocking Internet kiddie porn based on supply and demand--that is, if paedophiles can no longer download kiddie porn, there's less of a 'market' for it, and thus less child abuse to generate the pictures. But on the other hand, if the average paedophile can no longer satisfy his urges by downloading porn, will he be more inclined to actually go out and molest some children? Just something to think about.
Because it would not make sense to reject mail from every customer of a given ISP just because one of their users is wormed. Otherwise, every mail.ISP.com server would be immediately blocked for sourcing more than 2 viruses in 25 hours, since few ISPs will have a 0% infected customer base.
Why is it repeated? "In case it didn't get it right the first time".
Sadly, I've actually seen this. More sadly, this is because I wrote that code. Most sadly yet, it needed it--the processor didn't get it right the first time, and I was at a loss to figure out why.
This was a PIC18 microcontroller, actually not that long ago, with a project deadline approaching fast. The assembler program I was writing would occasionally experience what, if I didn't 'know better', would seem like hardware demons. Monkey with the code a bit, the bug would go away, and so I wrote it off as bad programming, i.e. "some incredibly stupid mistake that I'm not catching". With about a week to the deadline, things started to get very bizarre very fast. Things like RETURN instructions that didn't return, registers holding some random data after being cleared, and the behavior of code at location x being influenced by code at location (further than x) that hadn't been executed yet. In the obvious frustration that ensued, the almost-production code contained lines like the following (except for the mangled formatting of course; that's Slashdot's doing):
In desperation I resort to the resort engineers resort to when no other resort remains, which is to Read The Friendly Manual (in this case, looking through the 300-some pages of datasheets). Brief mention is made of consulting their 'errata sheet' for the latest processor errata. I think I did go looking for this once long before, and decided this document was buried cleverly enough that I shouldn't waste my time continuing to look for it, since a measly 8-bit micro would never contain a showstopper like the Pentium FDIV bug (affecting 1 in every few zillion long divisions), right?
Y-y-y-yeeeeah. Anyway, I chase down the errata sheet for this micro, for real this time, and find the following smack on the first page:
Certain code sequence and placement may cause the corruption of a few bits in the instruction fetch when the part is used above 4 MHz. A corrupted instruction fetch will cause the part to execute an improper instruction and result in unpredictable outputs.
Microchip cannot predict which code sequences and placement will cause this failure. If this failure mechanism exists in your system, it should be evident during statistically significant preproduction testing (minimum suggested sample size 100 units) of your particular code sequence and placement.
Now, the rated speed of this chip is 40 MHz (not 4!), and we were of course running it at 40, because if we wanted to run slower, we'd have bought slower chips.
In the end, crisis narrowly averted by changing all the system clocks from 40MHz to 4MHz, hacking all the timing-dependent code to compensate, and demoing a slower (but working) prototype. (And of course, a lab-wide resolution not to buy chips from Microchip again.)
Lesson for today: Always look up those errata sheets, kids.
Slashdot Mirror
And, being the raving geniuses that they are, they store the on-camera key on a little serial EEPROM just like network card makers and everyone else use for unique identifiers ('93C46...), and the hacker cuts its clock pin to set the key to 00-00-00-00-00-00-00-00.... :-)
Haha...shit, I thought you were joking until I clicked on the link.
Translation: Need someone to threaten anti-spyware companies and get us dropped from detecion.
Or, they could install this thing, called a driver...
And all this time I thought it stood for Terminate & Suckup Resources.
just under $1K/G, a 30G model I recently held in my hand was worth much more than my car
Gotcha beat, I can buy a regular CompactFlash card at Best Buy that's worth more than my car. (...insensitive clod!...)
All that aside, each bit of a typical Flash memory is rated at only 100,000 ~ 1M write/erase cycles...in fact, for all but the most expensive, there's no guarantee against cells failing considerably earlier, or even defective / "soft" cells from the factory. (Typically expressed as a percentage, e.g. smallnum% bad bits, with the first sector of memory certified bad-bit-free).
Is there any information on how these Flash drives stack up, reliability-wise, against conventional magnetic HDDs?
You clicked the goatse link?!?
I want an automatically-actuated "asshole mirror". I keep one in the center console for those special occasions, but it just isn't the same. It's for that asshole, you know the one, in the SUV who sits two inches off your back bumper giving you a suntan with his brights. That's when the asshole mirror comes out - hm, down a little...a little to the left...Bingo! He's slowing way down. ...wait a minute dude, that wasn't supposed to mean "pull into that ditch over there and burst into flames". Damn.
Conversely though, I wonder if compression artifacts could be one of the very things the algorithm looks at. Your digital camera takes a picture, compresses it with JPEG and produces subtle (to the eye) artifacts. Now start moving things around in the image (lets assume for the moment you're not even grafting in UFOs), and now the artifacts have moved with them, and can be identified as not being where the JPEG algorithm would put them. Of course, to make it look convincing, you've probably used some smoothing, airbrushing, feathering etc. filters, which will have obliterated artifacts entirely in some places. Finally, suppose you do graft in a UFO--where does this picture come from, and does it have compression artifacts of its own? Even if it came from the same camera, differences in the images mean differences in the compression. But the UFO's probably been resized, rotated, etc., further messing up the artifacts. Of course, just like when you move stuff around in the same image, they're not going to match up anyway. I think this would be a very easy thing for an algorithm to look at.
Of course, you could just save the doctored foto itself as a low-quality JPEG - but a) if it's going in a newspaper, do you want low quality?, and b) you're still just adding your own artifacts to the original - it's going to be some pretty severe compression before they're undetectable.
...holding hands.
What inform the consumer?!? But then we can't sue for spilling hot coffee on our laps, or dying from cigarettes (takes a drag).
That settles it. First thing I'm going to do after I die is sue a cigarette company. Fuck 'em.
(and catchalls in general)
Nowadays I'd really have to recommend against catch-all accounts.
We used to run a catch-all at a server I administer, it had been a thing of beauty for a number of years. Few spams to never-existant addresses (the occasional crap addressed to "info@" and "sales@" were about it), and the convenience of never having to keep track of the made-up-on-the-spot email addresses given out to shady people, registrations, etc. A few addresses got into the hands of hardcore spammers; these were replaced with an autoresponder politely directing live humans to another address.
Then, early this year, some Windows virus-or-other came out which sent mails to random and other novelly-generated addresses (joe@, bob@, username from another domain @yourdomain.com), and spread rapidly. Within a couple days, the catch-all account (read: my inbox) was receiving upward of 10,000 (yes, that's not a typo) copies of these huge Windows viruses per day.
Not only this, but those couple of autoresponders were also being hammered by mails from forged addresses, causing them to send a "this address is deprecated, please use..."-type mail (or lots of them) to people who never sent mail to that address in the first place. This included the administrator of one particular Debian-related mailing list, who I remember as being rather rude, threatening to get our domain UDPed, blacklisted, sent to Detroit or whatever is today's preferred form of vengeance from someone closer to the backbone than you are.
Needless to say, life with catch-alls ended for us in short order (with a couple months of occasional "what happened to your address, it's dead!" from people sending to addresses I didn't remember to create after removing the catch-all functionality), and life + my inbox returned to normal.
That's an Amazon infringement - twice!
As I understand it, you can also send in a board layout made in another program (e.g. Eagle, ORCAD, etc.) : see the FAQ near "Gerber" (a popular board-design file format).
Nothing, apparently...mine has a traffic ranking of 1, too, but the server takes off into hiding if it ever gets linked on /....
You're not getting my Timex Sinclair!
Use a domain less than 3 chars - can't exist, according to standards
Don't tell x.org that, they'll be ever so pissed.
My favorite fill-in address. I'm surprised it doesn't have more of a google following, although it hasn't actually been "valid" (in the fuck-a-spammer sense) for a number of years. Still, it seems like it should be a pretty clear indication to an address-demanding site/service, of how the user expects them to make use of the information...
Of course, if a fill-in form is ever wise to that one, I can always consult the list.
Ahh..the Highly Increased Paperwork for (medical) Administrators Act.
...
A while back I consulted with an office (in this case, dental) to ensure that they were in compliance with the Act before it took effect. One thing I found was that the office's actual privacy practices didn't (and didn't need to) change one bit - information is only allowed to be given out in the same special circumstances as before, e.g. releasing information to a legal guardian, pursuant to court order, or in certain cases for the purpose of identifying a body via dental records.
What the Act DID do is roughly double the amount of paperwork that has to be retained and dealt with for each patient. This went from "charts" to "charts + HIPAA disclosure notice and signature + any special requests or deviations as required"
There frequent flyers carried their biometric identifiers (fingerprint & iris) with them between airports on a smart card"
Did anyone else read this thinking, "oww, oww, oww..."
Whoever calls an LM78xx/LM317/etc. a linear supply, try leaving off the little 0.1u capacitor near the input terminals and move the larger, typically electrolytic filter cap some distance away. They may classify technically as "linear" because they don't involve a chopper/PWM driving a transformer, but there is still a current-hungry transistor at the input being switched rapidly on and off...
I am seeing arguments for blocking Internet kiddie porn based on supply and demand--that is, if paedophiles can no longer download kiddie porn, there's less of a 'market' for it, and thus less child abuse to generate the pictures. But on the other hand, if the average paedophile can no longer satisfy his urges by downloading porn, will he be more inclined to actually go out and molest some children? Just something to think about.
Because it would not make sense to reject mail from every customer of a given ISP just because one of their users is wormed. Otherwise, every mail.ISP.com server would be immediately blocked for sourcing more than 2 viruses in 25 hours, since few ISPs will have a 0% infected customer base.
Har har har. Now shaddap and get me a towel.
...Ninnle?
Is it too kinky for Google, or have I just been trolled?
let x=0;
let x=0;
Why is it repeated? "In case it didn't get it right the first time".
Sadly, I've actually seen this. More sadly, this is because I wrote that code. Most sadly yet, it needed it--the processor didn't get it right the first time, and I was at a loss to figure out why.
This was a PIC18 microcontroller, actually not that long ago, with a project deadline approaching fast. The assembler program I was writing would occasionally experience what, if I didn't 'know better', would seem like hardware demons. Monkey with the code a bit, the bug would go away, and so I wrote it off as bad programming, i.e. "some incredibly stupid mistake that I'm not catching". With about a week to the deadline, things started to get very bizarre very fast. Things like RETURN instructions that didn't return, registers holding some random data after being cleared, and the behavior of code at location x being influenced by code at location (further than x) that hadn't been executed yet. In the obvious frustration that ensued, the almost-production code contained lines like the following (except for the mangled formatting of course; that's Slashdot's doing)
call showREG ; debug - show what's in register REG
clrf REG ; debug - force REG contents = 0
call showREG
clrf REG
clrf REG
clrf REG
clrf REG ; WTF?!?!?
call showREG
In desperation I resort to the resort engineers resort to when no other resort remains, which is to Read The Friendly Manual (in this case, looking through the 300-some pages of datasheets). Brief mention is made of consulting their 'errata sheet' for the latest processor errata. I think I did go looking for this once long before, and decided this document was buried cleverly enough that I shouldn't waste my time continuing to look for it, since a measly 8-bit micro would never contain a showstopper like the Pentium FDIV bug (affecting 1 in every few zillion long divisions), right?
Y-y-y-yeeeeah. Anyway, I chase down the errata sheet for this micro, for real this time, and find the following smack on the first page:
Certain code sequence and placement may cause the corruption of a few bits in the instruction fetch when the part is used above 4 MHz. A corrupted instruction fetch will cause the part to execute an improper instruction and result in unpredictable outputs.
Microchip cannot predict which code sequences and placement will cause this failure. If this failure mechanism exists in your system, it should be evident during statistically significant preproduction testing (minimum suggested sample size 100 units) of your particular code sequence and placement.
Now, the rated speed of this chip is 40 MHz (not 4!), and we were of course running it at 40, because if we wanted to run slower, we'd have bought slower chips.
In the end, crisis narrowly averted by changing all the system clocks from 40MHz to 4MHz, hacking all the timing-dependent code to compensate, and demoing a slower (but working) prototype. (And of course, a lab-wide resolution not to buy chips from Microchip again.)
Lesson for today: Always look up those errata sheets, kids.