The Tribune acquired customized software for the upgrade from an outside provider, and it contained a "coding error," he said.
As you pointed out, QA should have caught something this basic. There had to be a lot of careless decisions made here, and none of them are necessarily any one coder's fault. Blaming a "coding error" is simple, and makes people forget that a manager didn't do their job correctly. I've seen this particular scenario played out a dozen times before:
Last Monday Suzy Manager shouted at her team, "The schedule says we install on July 18th, so this damned product damned well better be installed on July 18th, you all got that?!"
But the vendor's ship dates slipped, and testing dates got pushed back, even though there was nothing particularily important about July 18th; except for Suzy Manager's promise to the CIO that she'd get WhizBang 2.0 installed by July 18th. And she would, too -- she had 25 points on her review riding on that very promise.
By the 14th, when a new patched version arrived that fixed the bug they discovered on the 10th, Suzy was visibly distressed. "They damn well better have that transmit bug fixed, they've been dragging their feet long enough."
Perhaps the testers just kept testing the version from the 10th instead of upgrading to the version of the 14th. It was beautiful on Saturday, so maybe the tester called in with a bad case of 'weekend flu.' Perhaps they got the patch late Friday afternoon, and the vendor swore up and down that it was just one little bug, our guy knows it's fixed, don't worry, it's better now. Whatever -- Suzy was under the gun, so she simply said "ship it."
Regardless, some nameless coder is flapping in the breeze today. Suzy is probably running around the IT department at the Tribune screaming, "we'll never buy code from those bastards again, I swear!" in a vain attempt to deflect criticism from her department.
But the CIO usually knows better, and Suzy knows the CIO knows better, and she's already sent out her interview suit to the cleaners. Even so, she'll feign total surprise to her department as she boxes up the little wooden carving she picked up during a drinking cruise to Mazatlan a couple years ago. A couple of tears later, she's interviewing over at Microsoft Consulting Services.
Or, maybe I'm completely off the mark. Perhaps they've been testing the code for a month and it's worked fine, but they installed the new code with the old libraries, or the new libraries with the old code, or the destinations were SP2 with some new security turned on. Of course, the QA department should be testing the installation packages as well, but we all know that in hindsight, right? As Yogi Berra might once have said (were he an IT manager,) "In theory, there's no difference between the lab and production, but in production there is."
Re:Never been a fan of the VoIP
on
VoIP Questioned
·
· Score: 1
I haven't made the switch to VoIP or cable telephone either, but I'm seriously considering it for several reasons.
First, cost: I get my internet and my TV through the same pipe at the moment (Comcast.) I think they'll offer me a package deal if I sign up for telephone over the cable. Also, I believe the individual features are cheaper. In addition to the phone bill, I'm spending extra money every month for such crap as caller ID, conference calling, etc. This is simple stuff, they have to go out of their way to NOT give it to me because their switches have had it for years and years.
Second, convenience: One less bill to deal with, one less company to hassle with. I've had problems with my land-line company switching long distance carriers. It takes a lot of time and a lot of "press 3 for a representative" to get any service from the phone company.
Third, quality: I live less than 1km from a christian AM radio transmitting tower. Their signal used to inject itself into my phones on a semi-regular basis. "Hi, how are you -- ]]]BZZZZ[[[ REPENT YOU SINNERS ]]]BZZZZ[[[ -- sorry about that." (Or maybe it really was Jesus?) I had to run around with.1uf capacitors to try to scrub that crap from my lines. At least with IP telephony, I'm not talking over a 7km antenna wire. The IP packets themselves are immune to that sort of interference.
My concerns are: will a single-provider jack me around in the future? I have cell phones, so that may not be a big deal. I'm only slightly concerned about E911 service, and by using Comcast's phone service I think the "local provider" concept still holds.
Hmm. The more I think about it the less happy I am with my old two-pair....
Secrecy is actually handled very well. I apologize for neglecting to explain it in detail.
You are given the ballot inside a cardboard folder that is slightly shorter than the ballot. The bottom two inches of the folder are glued shut. The top portion of the ballot that sticks out is always reserved for printed instructions, and is never used for actual votes. Before leaving the booth, the voter places the ballot inside the folder. The voter holds the folder at the sealed bottom area. That area of the folder is printed with "hold here" instructions and has a helpful picture of a hand grasping at something.
When you approach the counter, the judge will help you position the top of the ballot into the counting machine. The machine sucks the paper in very rapidly; even if the folder is withdrawn early the ballot is moving so rapidly that the eye can't distinguish the marks as it speeds by. (The complete-the-arrows are always arranged in a single vertical column, meaning you can't rely on seeing a mark on the left indicating a democratic vote vs. a mark on the right indicating a republican vote.)
I left out this description before because it's fairly complex to describe, although it's very simple in practice. In the booth you put the ballot in the folder. You then walk to the machine and then stick the tip of the paper into the machine. Zzzzip! Done.
On many occasions I've deliberately tried to be careless with the secrecy of my ballot just to see how the election judges react. So far, they've always done things like averting their eyes when they realize that the folder is opened in front of them, or that the ballot is hanging out far enough to display a vote. Sometimes they'll say something; I've had one try to push the folder closed in my hands. I've tried taking the ballot out of the folder to visibly put it in the machine -- that was a big no-no with them. I'm sure they consider me a typical "stupid voter" who can't read or follow instructions (unless they're reading this, in which case the game is up.:-)
As far as a spoiled ballot that the machine rejects, I don't know how they maintain secrecy since I've never deliberately spoiled one to find out. It could be that the machine just keeps the paper inside, but blinks a red light or buzzes or something. The judge would probably then instruct the voter to press a button to retrieve their ballot and then have them drop it in the officially sealed "spoiled ballot box." It could also be that the machine reverses the paper before it's completely left the folder.
I like the system because I can see the thought and effort that went into making it simple to use, cheap to make and maintain (a couple dozen glued cardboard folders plus a primitive optical scanner will serve each precinct) and still performs well at maintaining secrecy.
Having animated GIFs of cavorting donkeys and braying elephants or shiny pictures of candidates' teeth won't personally "add to my voting experience". I'd be very concerned about the security I'm promised but can never see. The current system lays it all out in front of me.
Our ballots are on large paper where you use a felt-tipped marker to "complete the arrow" to vote for the candidate of your choice. The voter takes the ballot from the booth, and feeds it into an electronic counter under the eye of an election judge. If the ballot has no errors, it's pulled in completely and dropped into the bin beneath. If the voter has misvoted (stray mark on the ballot or two candidates marked for the same position) the motor of the counting machine reverses the ballot back to the voter. The puzzled voter is then offered a replacement ballot by the election judge and sent back to the booth, while the old ballot is officially counted as spoiled.
The paper is still the ballot. If you want, it's your right to hang around the polling place until they close, then watch the judges count the ballots.
I'm comfortable with our system. The arrows are easy to figure out, and they're a very positive and permanent indicator. If the machine can't read them, the voter is warned immediately, before they've left their opportunity behind.
Frivolous entries like that demonstrate the biggest problem with the Wikipedia. Since anyone can be an editor, it really means that ANYONE can be an editor.
Sure, this sort of entry might get pulled out by someone, but at what point can you completely trust the Wikipedia?
What really needs to be done is make each device have a seperate off and on button. That would fix all the problems.
Ahh, but they do already have separate on and off buttons. You just don't know it yet.
Many of the brands have discrete "power on" vs "power off" codes. Note the annoying difference between "codes" and "buttons". The remote doesn't support separate switches because adding a second button adds to the cost, while not adding to usability as far as the humans are concerned.
This guy's page for example, shows Sony TV set codes. Note how code 21 is "power", but code 46 is "power on" and code 47 is "power off". The trick is to getting these codes into your learning remote without having the source to teach them from. Try Remote Central for the most complete set of device codes on the net. You'll need a way to get these codes into your remote, though. Try searching for JP1 to learn how to make a cable to talk to an All In One remote.
I believe the Harmony remotes make heavy use of this function to make sure all devices are sync'd with the remote control at every power-on opportunity.
This is the text of the comments I sent them. I tried carefully to close the loopholes I saw remaining in the document.
Hi,
I'd like to make a few comments on the proposed Fair Weather Policy.
Statement 4 is confusingly worded: "To advance the weather, water and climate enterprise, NWS will provide information in forms accessible to the public as well as underlying data in forms convenient to others." Does this mean that only finished products will be available to the public, while the 'underlying data' will be somehow restricted to 'others'? Please clarify this statement to indicate that the data in all forms will always be made available to the public in a timely fashion, (to the best of your abilities, of course.)
The most disturbing proposal is statement 6 in which you propose a procedure to listen to outside interests who request you "discontinue products and services." The NOAA and NWS must be the sole decision maker as to whether a specific product needs to be discontinued, and then only because the NWS has internally determined that it is being unused or underutilized, is too expensive to maintain, or has been replaced by a better product. You need to change this statement to indicate only that you will request public comment in the event that the NWS announces they wish to discontinue a specific service due to disuse.
The NDFD and XML feeds are brilliant examples of the quality data you can provide to all Americans. Shutting them down at the request of commercial enterprises who might feel threatened by your fine work effectively steals this work from those of us who paid you for it in the first place.
I have a 2002 Ranger (4.0L w/4WD) and I get between 15-17 mpg. The sticker said 20 highway 17 city. I have to admit that my foot weighs more than average, and my commute consists of 16 miles each way of so-called "rush" hour freeways. I almost never put true "highway" miles on it (and certainly not at 55 mph.;-)
The 15 mpg figure is winter, and the 17 mpg figure is summer. I don't know if Minnesota's ethanol program is responsible for the poorer mileage, or if it's just more spinning the tires than usual and the occasional drop into 4WD, or (most likely) the typically slower traffic in snowy conditions.
To think I traded in my 1992 Ranger which got 20 mpg for this one... sigh... Oh, well, it's nice having brakes again.
That's actually a very common trick in the mainframe world to radically improve performance. It's usually combined with dumping the table to a flat file beforehand. Nested selects suck CPU at the same rate an application would. Raw code, with the same knowledge of the data as is required to perform the join, can be far, far faster than torturing SQL to do what you need.
A buddy of mine who consults to our mainframe group on performance issues recently was given a deeply nested join (6 or 9 levels) that the predictor estimated would take hundreds of years of CPU to run. By simply replacing the straight SQL with parameterized SQL they dropped it to 25 hours of run time. Still not good enough for a nightly job. Dumping the tables to flat files, performing the function in code, and recreating the table with the data took 20 minutes of CPU, which was finally an acceptable number for the job.
He's just annoyed that he doesn't get a cut of the $$$ savings when he pulls these rabbits out of his hat.
A keykatcher(tm) is a piece of hardware that the bad guy (or your employer) sticks between your keyboard and your PC.
Knoppix, Linux, DOS, OS/2 -- the OS doesn't matter. The keykatcher is hardware dongle-like thing, looks like an elongated keyboard plug. And all it does is keeps the last 65K of keystrokes you've typed.
You can download it to a floppy without removing it from the PC (if you're running Windows) or you can remove it, download it to a different PC and replace it later. Or, you can remove it, download it to a different PC, and then place it on the next guy's keyboard.
So, the truly paranoid person now has to cut-n-paste bits of their password with the mouse, and hope the bad guys haven't installed Back Orifice.
I keep my taskbar double tall, and still manage to fill it beyond the squish point. I usually have between 4 and 8 Dev Studios running, Outlook, a phone message retriever, two or three command windows, SQL query analyzer, the odd telnet or seven, and Mozilla (with a half dozen tabs or so.) If I wasn't constantly consulting on half a dozen different projects simultaneously, it might be easier.
Believe me, the tabs are not hard to love.
You might like them better if you change the preference to always leave tab bar on. I like having the little "new tab" icon always present so I can insta-google (i HATE searching from the address bar. That's for URLs, not random text.)
Because in many (most?) fields of employment, COBOL is far more widely used than ASM.
Retail, banking, most all of the big financial companies all have decades of legacy COBOL programs hanging around that need maintenance and upgrades. It's not uncommon for a Fortune 500 company to have several hundred programmers writing in COBOL, but have fewer than a dozen programmers capable of writing in assembler. Of those, perhaps one or two is fluent enough to maintain an ancient BAL (Basic Assembly Language) program.
There are many more jobs for COBOL speakers than there are for BAL speakers. A community college's primary focus is very different from that of a research university. They are there to teach skills that will make its students employable. A COBOL coder can get a job. A BAL coder can get in the unemployment line behind the IBMer with 20 years BAL experience.
Re:A whole 'herd' of new excuses?
on
WiFi Gone Wild
·
· Score: 1
Good point. I wonder if they'd be better off with a pair of leg stimulators -- something like ACE bandages holding electrodes on their forelegs that would zap them making them think they were snakebit or something. Of course, panicking a cow isn't likely to be a productive action either. Maybe the "feeling" of something hard would cause them to back up and turn around, like a Roomba bumping into a chair leg.
Another possibility would be to have more than one electrode pair on the collar. Just as you turn a horse by annoying it with the bit, you might be able to "turn" the cows by zapping the side you want them to avoid.
Finally, if the ranchers are worried about labor costs they might be better off installing remote control gates rather than rely on hired hands to open and close them.
Anyway, I thought it was a cool idea, and I'm sure they did too. There are just a few bugs to work out, cow cooperation being the biggest.
As an aside, cows on Australian ranches of the sort described in the article are most likely beef cattle. Meat production isn't affected by stress nearly as much as milk production is.
Re:A whole 'herd' of new excuses?
on
WiFi Gone Wild
·
· Score: 2, Informative
No, I read the link. And the "virtual fences" don't work the same way as they do for dogs. The dog radio containment systems I'm familiar with use a buried antenna wire to mark the dog's range -- if the dog approaches the wire, they're corrected. The cow collars actually have GPS receivers, and the rancher downloads a "virtual fence" to the collar. The corrections come whenever the collar detects the animal has strayed, and the cow is "rewarded" by not being shocked when it's heading home.
The cow collars sound a lot better than the ordinary radio dog collar, because they work both ways. If Fido ever jumps beyond his radio fence, he is corrected for attempting to go back home over the antenna, so he is rewarded for NOT coming home.
Of course GPS accuracy isn't as important with cows as it is with dogs. In the suburbs, the 12-60 feet of error of the average GPS receiver would let Fido crap in the neighbor's yard or get run over in the driveway. In the country, it's really only important to keep the cows off the roads. Whether or not they stray too close to Charlie's pasture isn't as big a deal.
A whole 'herd' of new excuses?
on
WiFi Gone Wild
·
· Score: 4, Funny
"Sorry, my access point grazed out of range."
"How would you like your firewall? Rare, medium, or well?"
I can just hear him now: "Uhh, the ancient Sumerians used to connect their teletypes together with DB-25P terminated cables wired in a null modem fashion. They found that if they crossed DTR to DCD and RTS to CTS that they could emulate the behavior of DCE modem equipment without actually having a modem present. Can I get another beer here?"
I bought a cheap tiny tripod I keep in my camera bag for those occasions. It's a Q-POD mini, and was about $20. Folded up, it's literally less than half the size of my palm pilot (9 x 3 x 1cm, or 3.5 x 1.5 x.75in), weighs about as much as the pilot, and I always have it with the camera. It has an adjustable tilting head and telescoping legs that let me get it level on uneven surfaces like rocks, car hoods, etc.
My only complaint (very minor) is that it has a coin-slot on the screw that attaches to the bottom of the camera, instead of a knurled thumb screw. I know there wasn't space for a whole big knob, but it takes longer to attach to the camera than I'd like.
I purchased a separate hot-shoe flash. I've always been disgusted with the performance of the built-in flashes on virtually every camera I've owned or used. Simple optics dictate that they're all going to give your subjects red-eye (or epileptic seizures in a feeble attempt to avoid it.) A separate flash unit holds the lamp farther from the objective lens, which helps reduce red-eye.
The Canon flash I bought for my G2 has two adjustable axes, one to tilt the flash up, the other to rotate the flash from side to side. You don't have to get so fancy. (I find that I rarely have need for the side-to-side rotation, for example.) But even a fixed-aim hotshoe flash can be connected by a rotating mount to your camera, and you can then point it in whatever direction you need.
If budget is a concern (my flash unit was about $250 from a local dealer, known for their service but not for their low prices) you can try using a diffuser in front of your flash. It's simply a piece of translucent white plastic that you snap in front of your flash. You can even jury-rig up a homemade version, but there's no guarantee you'll get even colors or lighting from a cut-up milk jug. You can also try various reflectors (I suppose tinfoil would work) to get it to bounce up or around, but those probably won't hold up well, and your camera's going to look like it's held together with duct tape.:-( Check and see what your camera manufacturer offers, or there may be third-party add-on products out there to do this for you.
Dude! How'd you mount your liquid-cooling thermal transfer block to your phone's CPU? I rigged up this thing with duct tape and paper clips, but I had to use far more Arctic Silver than I should have...
...and I probably should have posted this anonymously, but "what the hell"!
Set the camera up for a two or more second exposure. Cover the lens with a black hat. Be careful not to touch the camera, just surround the lens with a black, non-reflective opaque object, such as a hat. Trip the shutter, wait a second or so for the vibrations to settle down, then remove and replace the hat to expose the picture.
It's a trick that's worked since chemical photography was invented, and it still works with digital today. (I've done it with outdoor night photos.)
One problem with extremely long exposures in the dark that is peculiar to digital is that noise in the sensors becomes extremely apparent. You might see "static" or "snow" on extremely long, dark exposures. If that's a problem you encounter, try keeping the camera as cool or cold as possible (don't put it in the freezer and frost the thing, though!) That means leave it out in the cold rather than tightly held in your jacket, for example; and spare the LCD display as much as possible as the EL panels really warm them up.
A simple suggestion I'd have for you regarding the flash is to bounce it. Whenever I'm forced to use a flash, I like to bounce it off the ceiling whenever possible. (Ceilings are usually bright white, whereas walls that look white indoors may sometimes be off-white, giving an unnatural tint to the subject.)
I'm still working on trying to get Proxomitron to block the javascript popups from packetnews.com, but I haven't had much success yet. For whatever reason, the bit that restores the window.open() functionality allows the javascript to open the popup window.
Those guys have some really suspicious looking javascripts that make me way uncomfortable. I'm teaching proxomitron to cut most of that crap out, but it's still not good to see Mozzie allowing scripts to pull this in the first place. Sigh...Mozzie is becoming more like aaaiiiIEeeee every time someone whines about "lack of compatibility."
I bought one. I think it was "Let's Knife" or somesuch.
They're a happy Japanese girl band. I liked what they did with the Powerpuff girls song, (when you got a kid, you watch a lot of Nickelodeon.) so I figured "what the hell."
I probed it for a few minutes yesterday afternoon. It uses an ECB (Electronic Code Book) scheme, which is a really naive way to implement encryption.
They do many things wrong.
First, it looks like an 8-byte block cypher is used. My first guess is DES, but as I only examined the output files, and didn't actually run their program inside a debugger, I can't tell how they mash the password into the key they feed their algorithm. While an 8 byte block doesn't necessarily mean much security-wise, it indicates they're not using any of the more modern block cyphers in any mode that has a larger block size.
It looks like they start off using the password to encrypt 24 bytes of NULLs, starting at offset 0x00000028. Why three times? Can't say yet. But that's a handy-dandy crib built right into the format of the file, which is extremely useful for testing password guesses.
Next, starting at offset 0x00000040, each 8 bytes of the file is encrypted with the password. This is done in an ECB fashion, with no mixing of data from one block into the next, as in CFB or OFB encryption modes. That means that if you have 8 bytes that are repeated further down in the file, you know they mean the same 8 bytes of output as the first time you encountered those 8 bytes. It's a big weakness in that if I ever decode anything at all from you, I can repeat that same decoding on any other encrypted files I've collected from you. It's called a dictionary attack, and any ECB is vulnerable to it (which is why ECBs aren't considered secure.)
There is also no indication of an Initialization Vector (IV). An IV is usually as simple as encrypting a block of 8 random bytes to "salt" a CFB mechanism, so that even the first block between two otherwise identical encryptions won't fall to a dictionary attack. ECBs don't use this (or if they did they would vary it from file to file, which this scheme doesn't.)
There's other header and trailer stuff in the file, and I'm assuming that consists of the "orginal file name, original file date" kind of stuff used to restore the file to its original condition. The trailing stuff is probably a checksum of the original file to ensure a successful decoding.
The user interface is simple enough. And it installs itself to your chip easy enough. But security wise, it's just not there at all. Internally it smells like a very naive and weak DES implementation. I wouldn't trust it with my password, let alone my data.
Re:I'm confused why more people don't see ...
on
RFID Leaders Talk Privacy
·
· Score: 2, Interesting
Passive tags are already in widespread use in anti-shoplifting security applications today. They have an effective range of roughly 6-10 feet, based on manufacturer, tag technology, etc.
One of the major selling points of RFID is that the tag itself will not only be the "magic barcode" but it will also serve as a security tag to prevent unpaid-for merchandise from walking out the door. It will save the not-inconsiderable cost of a second tag that exists only for security purposes.
The concerns are that you could be found "guilty by RFID association."
Let's say you're careful about purchasing anonymously, only paying cash for everything -- shirt, shoes, underwear, etc, no matter where you shop. But, if you so much as purchase a single RFID tagged packet of gum with a credit card, and then walk through the scanners at the door, it would be very possible to scan the rest of the RF tags that permeate your clothing, and build up a database of "shirts, shoes, underwear, all associated with a packet of gum purchased by one Ann A Thema, credit card #123-456-789." Then, you change clothes, come back the next day with the same shoes on but a different RFID-tagged pair of pants, shirt, underwear, etc., they can throw all of those items into their Ann A Thema bucket based upon your assoication with the shoes, which they associated with your gum yesterday.
Pretty soon, your entire wardrobe is cataloged by Walmart. One little slip-up and *bam* -- all anonymity is lost.
OK, so Walmart now knows that you came in Friday and purchased a red shirt at 4:23. The bank down the street was robbed by a guy in a new red shirt at 5:15. The cops subpoena every store in the neighborhood that sold shirts on that day. You pop up as a match in WalMart's database, and you then get to spend a day explaining to the police that you were just sitting at home alone at 5:15, you weren't out robbing anybody.
John Ashcroft's wet dreams? Maybe. One thing is it can't happen without RFID. Ordinary barcodes are removed after purchase. But RFID is the tag that keeps on tagging.
Slashdot Mirror
As you pointed out, QA should have caught something this basic. There had to be a lot of careless decisions made here, and none of them are necessarily any one coder's fault. Blaming a "coding error" is simple, and makes people forget that a manager didn't do their job correctly. I've seen this particular scenario played out a dozen times before:
Last Monday Suzy Manager shouted at her team, "The schedule says we install on July 18th, so this damned product damned well better be installed on July 18th, you all got that?!"
But the vendor's ship dates slipped, and testing dates got pushed back, even though there was nothing particularily important about July 18th; except for Suzy Manager's promise to the CIO that she'd get WhizBang 2.0 installed by July 18th. And she would, too -- she had 25 points on her review riding on that very promise.
By the 14th, when a new patched version arrived that fixed the bug they discovered on the 10th, Suzy was visibly distressed. "They damn well better have that transmit bug fixed, they've been dragging their feet long enough."
Perhaps the testers just kept testing the version from the 10th instead of upgrading to the version of the 14th. It was beautiful on Saturday, so maybe the tester called in with a bad case of 'weekend flu.' Perhaps they got the patch late Friday afternoon, and the vendor swore up and down that it was just one little bug, our guy knows it's fixed, don't worry, it's better now. Whatever -- Suzy was under the gun, so she simply said "ship it."
Regardless, some nameless coder is flapping in the breeze today. Suzy is probably running around the IT department at the Tribune screaming, "we'll never buy code from those bastards again, I swear!" in a vain attempt to deflect criticism from her department.
But the CIO usually knows better, and Suzy knows the CIO knows better, and she's already sent out her interview suit to the cleaners. Even so, she'll feign total surprise to her department as she boxes up the little wooden carving she picked up during a drinking cruise to Mazatlan a couple years ago. A couple of tears later, she's interviewing over at Microsoft Consulting Services.
Or, maybe I'm completely off the mark. Perhaps they've been testing the code for a month and it's worked fine, but they installed the new code with the old libraries, or the new libraries with the old code, or the destinations were SP2 with some new security turned on. Of course, the QA department should be testing the installation packages as well, but we all know that in hindsight, right? As Yogi Berra might once have said (were he an IT manager,) "In theory, there's no difference between the lab and production, but in production there is."
First, cost: I get my internet and my TV through the same pipe at the moment (Comcast.) I think they'll offer me a package deal if I sign up for telephone over the cable. Also, I believe the individual features are cheaper. In addition to the phone bill, I'm spending extra money every month for such crap as caller ID, conference calling, etc. This is simple stuff, they have to go out of their way to NOT give it to me because their switches have had it for years and years.
Second, convenience: One less bill to deal with, one less company to hassle with. I've had problems with my land-line company switching long distance carriers. It takes a lot of time and a lot of "press 3 for a representative" to get any service from the phone company.
Third, quality: I live less than 1km from a christian AM radio transmitting tower. Their signal used to inject itself into my phones on a semi-regular basis. "Hi, how are you -- ]]]BZZZZ[[[ REPENT YOU SINNERS ]]]BZZZZ[[[ -- sorry about that." (Or maybe it really was Jesus?) I had to run around with .1uf capacitors to try to scrub that crap from my lines. At least with IP telephony, I'm not talking over a 7km antenna wire. The IP packets themselves are immune to that sort of interference.
My concerns are: will a single-provider jack me around in the future? I have cell phones, so that may not be a big deal. I'm only slightly concerned about E911 service, and by using Comcast's phone service I think the "local provider" concept still holds.
Hmm. The more I think about it the less happy I am with my old two-pair....
You are given the ballot inside a cardboard folder that is slightly shorter than the ballot. The bottom two inches of the folder are glued shut. The top portion of the ballot that sticks out is always reserved for printed instructions, and is never used for actual votes. Before leaving the booth, the voter places the ballot inside the folder. The voter holds the folder at the sealed bottom area. That area of the folder is printed with "hold here" instructions and has a helpful picture of a hand grasping at something.
When you approach the counter, the judge will help you position the top of the ballot into the counting machine. The machine sucks the paper in very rapidly; even if the folder is withdrawn early the ballot is moving so rapidly that the eye can't distinguish the marks as it speeds by. (The complete-the-arrows are always arranged in a single vertical column, meaning you can't rely on seeing a mark on the left indicating a democratic vote vs. a mark on the right indicating a republican vote.)
I left out this description before because it's fairly complex to describe, although it's very simple in practice. In the booth you put the ballot in the folder. You then walk to the machine and then stick the tip of the paper into the machine. Zzzzip! Done.
On many occasions I've deliberately tried to be careless with the secrecy of my ballot just to see how the election judges react. So far, they've always done things like averting their eyes when they realize that the folder is opened in front of them, or that the ballot is hanging out far enough to display a vote. Sometimes they'll say something; I've had one try to push the folder closed in my hands. I've tried taking the ballot out of the folder to visibly put it in the machine -- that was a big no-no with them. I'm sure they consider me a typical "stupid voter" who can't read or follow instructions (unless they're reading this, in which case the game is up. :-)
As far as a spoiled ballot that the machine rejects, I don't know how they maintain secrecy since I've never deliberately spoiled one to find out. It could be that the machine just keeps the paper inside, but blinks a red light or buzzes or something. The judge would probably then instruct the voter to press a button to retrieve their ballot and then have them drop it in the officially sealed "spoiled ballot box." It could also be that the machine reverses the paper before it's completely left the folder.
I like the system because I can see the thought and effort that went into making it simple to use, cheap to make and maintain (a couple dozen glued cardboard folders plus a primitive optical scanner will serve each precinct) and still performs well at maintaining secrecy.
Having animated GIFs of cavorting donkeys and braying elephants or shiny pictures of candidates' teeth won't personally "add to my voting experience". I'd be very concerned about the security I'm promised but can never see. The current system lays it all out in front of me.
Our ballots are on large paper where you use a felt-tipped marker to "complete the arrow" to vote for the candidate of your choice. The voter takes the ballot from the booth, and feeds it into an electronic counter under the eye of an election judge. If the ballot has no errors, it's pulled in completely and dropped into the bin beneath. If the voter has misvoted (stray mark on the ballot or two candidates marked for the same position) the motor of the counting machine reverses the ballot back to the voter. The puzzled voter is then offered a replacement ballot by the election judge and sent back to the booth, while the old ballot is officially counted as spoiled.
The paper is still the ballot. If you want, it's your right to hang around the polling place until they close, then watch the judges count the ballots.
I'm comfortable with our system. The arrows are easy to figure out, and they're a very positive and permanent indicator. If the machine can't read them, the voter is warned immediately, before they've left their opportunity behind.
Sure, this sort of entry might get pulled out by someone, but at what point can you completely trust the Wikipedia?
Ahh, but they do already have separate on and off buttons. You just don't know it yet.
Many of the brands have discrete "power on" vs "power off" codes. Note the annoying difference between "codes" and "buttons". The remote doesn't support separate switches because adding a second button adds to the cost, while not adding to usability as far as the humans are concerned.
This guy's page for example, shows Sony TV set codes. Note how code 21 is "power", but code 46 is "power on" and code 47 is "power off". The trick is to getting these codes into your learning remote without having the source to teach them from. Try Remote Central for the most complete set of device codes on the net. You'll need a way to get these codes into your remote, though. Try searching for JP1 to learn how to make a cable to talk to an All In One remote.
I believe the Harmony remotes make heavy use of this function to make sure all devices are sync'd with the remote control at every power-on opportunity.
Hi,
I'd like to make a few comments on the proposed Fair Weather Policy.
Statement 4 is confusingly worded: "To advance the weather, water and climate enterprise, NWS will provide information in forms accessible to the public as well as underlying data in forms convenient to others." Does this mean that only finished products will be available to the public, while the 'underlying data' will be somehow restricted to 'others'? Please clarify this statement to indicate that the data in all forms will always be made available to the public in a timely fashion, (to the best of your abilities, of course.)
The most disturbing proposal is statement 6 in which you propose a procedure to listen to outside interests who request you "discontinue products and services." The NOAA and NWS must be the sole decision maker as to whether a specific product needs to be discontinued, and then only because the NWS has internally determined that it is being unused or underutilized, is too expensive to maintain, or has been replaced by a better product. You need to change this statement to indicate only that you will request public comment in the event that the NWS announces they wish to discontinue a specific service due to disuse.
The NDFD and XML feeds are brilliant examples of the quality data you can provide to all Americans. Shutting them down at the request of commercial enterprises who might feel threatened by your fine work effectively steals this work from those of us who paid you for it in the first place.
Thank you for your consideration.
The 15 mpg figure is winter, and the 17 mpg figure is summer. I don't know if Minnesota's ethanol program is responsible for the poorer mileage, or if it's just more spinning the tires than usual and the occasional drop into 4WD, or (most likely) the typically slower traffic in snowy conditions.
To think I traded in my 1992 Ranger which got 20 mpg for this one ... sigh ... Oh, well, it's nice having brakes again.
A buddy of mine who consults to our mainframe group on performance issues recently was given a deeply nested join (6 or 9 levels) that the predictor estimated would take hundreds of years of CPU to run. By simply replacing the straight SQL with parameterized SQL they dropped it to 25 hours of run time. Still not good enough for a nightly job. Dumping the tables to flat files, performing the function in code, and recreating the table with the data took 20 minutes of CPU, which was finally an acceptable number for the job.
He's just annoyed that he doesn't get a cut of the $$$ savings when he pulls these rabbits out of his hat.
Knoppix, Linux, DOS, OS/2 -- the OS doesn't matter. The keykatcher is hardware dongle-like thing, looks like an elongated keyboard plug. And all it does is keeps the last 65K of keystrokes you've typed.
You can download it to a floppy without removing it from the PC (if you're running Windows) or you can remove it, download it to a different PC and replace it later. Or, you can remove it, download it to a different PC, and then place it on the next guy's keyboard.
So, the truly paranoid person now has to cut-n-paste bits of their password with the mouse, and hope the bad guys haven't installed Back Orifice.
Believe me, the tabs are not hard to love.
You might like them better if you change the preference to always leave tab bar on. I like having the little "new tab" icon always present so I can insta-google (i HATE searching from the address bar. That's for URLs, not random text.)
Retail, banking, most all of the big financial companies all have decades of legacy COBOL programs hanging around that need maintenance and upgrades. It's not uncommon for a Fortune 500 company to have several hundred programmers writing in COBOL, but have fewer than a dozen programmers capable of writing in assembler. Of those, perhaps one or two is fluent enough to maintain an ancient BAL (Basic Assembly Language) program.
There are many more jobs for COBOL speakers than there are for BAL speakers. A community college's primary focus is very different from that of a research university. They are there to teach skills that will make its students employable. A COBOL coder can get a job. A BAL coder can get in the unemployment line behind the IBMer with 20 years BAL experience.
Another possibility would be to have more than one electrode pair on the collar. Just as you turn a horse by annoying it with the bit, you might be able to "turn" the cows by zapping the side you want them to avoid.
Finally, if the ranchers are worried about labor costs they might be better off installing remote control gates rather than rely on hired hands to open and close them.
Anyway, I thought it was a cool idea, and I'm sure they did too. There are just a few bugs to work out, cow cooperation being the biggest.
As an aside, cows on Australian ranches of the sort described in the article are most likely beef cattle. Meat production isn't affected by stress nearly as much as milk production is.
The cow collars sound a lot better than the ordinary radio dog collar, because they work both ways. If Fido ever jumps beyond his radio fence, he is corrected for attempting to go back home over the antenna, so he is rewarded for NOT coming home.
Of course GPS accuracy isn't as important with cows as it is with dogs. In the suburbs, the 12-60 feet of error of the average GPS receiver would let Fido crap in the neighbor's yard or get run over in the driveway. In the country, it's really only important to keep the cows off the roads. Whether or not they stray too close to Charlie's pasture isn't as big a deal.
"How would you like your firewall? Rare, medium, or well?"
I can just hear him now: "Uhh, the ancient Sumerians used to connect their teletypes together with DB-25P terminated cables wired in a null modem fashion. They found that if they crossed DTR to DCD and RTS to CTS that they could emulate the behavior of DCE modem equipment without actually having a modem present. Can I get another beer here?"
My only complaint (very minor) is that it has a coin-slot on the screw that attaches to the bottom of the camera, instead of a knurled thumb screw. I know there wasn't space for a whole big knob, but it takes longer to attach to the camera than I'd like.
The Canon flash I bought for my G2 has two adjustable axes, one to tilt the flash up, the other to rotate the flash from side to side. You don't have to get so fancy. (I find that I rarely have need for the side-to-side rotation, for example.) But even a fixed-aim hotshoe flash can be connected by a rotating mount to your camera, and you can then point it in whatever direction you need.
If budget is a concern (my flash unit was about $250 from a local dealer, known for their service but not for their low prices) you can try using a diffuser in front of your flash. It's simply a piece of translucent white plastic that you snap in front of your flash. You can even jury-rig up a homemade version, but there's no guarantee you'll get even colors or lighting from a cut-up milk jug. You can also try various reflectors (I suppose tinfoil would work) to get it to bounce up or around, but those probably won't hold up well, and your camera's going to look like it's held together with duct tape. :-( Check and see what your camera manufacturer offers, or there may be third-party add-on products out there to do this for you.
It's a trick that's worked since chemical photography was invented, and it still works with digital today. (I've done it with outdoor night photos.)
One problem with extremely long exposures in the dark that is peculiar to digital is that noise in the sensors becomes extremely apparent. You might see "static" or "snow" on extremely long, dark exposures. If that's a problem you encounter, try keeping the camera as cool or cold as possible (don't put it in the freezer and frost the thing, though!) That means leave it out in the cold rather than tightly held in your jacket, for example; and spare the LCD display as much as possible as the EL panels really warm them up.
A simple suggestion I'd have for you regarding the flash is to bounce it. Whenever I'm forced to use a flash, I like to bounce it off the ceiling whenever possible. (Ceilings are usually bright white, whereas walls that look white indoors may sometimes be off-white, giving an unnatural tint to the subject.)
I'm still working on trying to get Proxomitron to block the javascript popups from packetnews.com, but I haven't had much success yet. For whatever reason, the bit that restores the window.open() functionality allows the javascript to open the popup window.
Those guys have some really suspicious looking javascripts that make me way uncomfortable. I'm teaching proxomitron to cut most of that crap out, but it's still not good to see Mozzie allowing scripts to pull this in the first place. Sigh...Mozzie is becoming more like aaaiiiIEeeee every time someone whines about "lack of compatibility."
They're a happy Japanese girl band. I liked what they did with the Powerpuff girls song, (when you got a kid, you watch a lot of Nickelodeon.) so I figured "what the hell."
I feel I paid for Proxomitron in one sitting. :-(
They do many things wrong.
First, it looks like an 8-byte block cypher is used. My first guess is DES, but as I only examined the output files, and didn't actually run their program inside a debugger, I can't tell how they mash the password into the key they feed their algorithm. While an 8 byte block doesn't necessarily mean much security-wise, it indicates they're not using any of the more modern block cyphers in any mode that has a larger block size.
It looks like they start off using the password to encrypt 24 bytes of NULLs, starting at offset 0x00000028. Why three times? Can't say yet. But that's a handy-dandy crib built right into the format of the file, which is extremely useful for testing password guesses.
Next, starting at offset 0x00000040, each 8 bytes of the file is encrypted with the password. This is done in an ECB fashion, with no mixing of data from one block into the next, as in CFB or OFB encryption modes. That means that if you have 8 bytes that are repeated further down in the file, you know they mean the same 8 bytes of output as the first time you encountered those 8 bytes. It's a big weakness in that if I ever decode anything at all from you, I can repeat that same decoding on any other encrypted files I've collected from you. It's called a dictionary attack, and any ECB is vulnerable to it (which is why ECBs aren't considered secure.)
There is also no indication of an Initialization Vector (IV). An IV is usually as simple as encrypting a block of 8 random bytes to "salt" a CFB mechanism, so that even the first block between two otherwise identical encryptions won't fall to a dictionary attack. ECBs don't use this (or if they did they would vary it from file to file, which this scheme doesn't.)
There's other header and trailer stuff in the file, and I'm assuming that consists of the "orginal file name, original file date" kind of stuff used to restore the file to its original condition. The trailing stuff is probably a checksum of the original file to ensure a successful decoding.
The user interface is simple enough. And it installs itself to your chip easy enough. But security wise, it's just not there at all. Internally it smells like a very naive and weak DES implementation. I wouldn't trust it with my password, let alone my data.
One of the major selling points of RFID is that the tag itself will not only be the "magic barcode" but it will also serve as a security tag to prevent unpaid-for merchandise from walking out the door. It will save the not-inconsiderable cost of a second tag that exists only for security purposes.
The concerns are that you could be found "guilty by RFID association."
Let's say you're careful about purchasing anonymously, only paying cash for everything -- shirt, shoes, underwear, etc, no matter where you shop. But, if you so much as purchase a single RFID tagged packet of gum with a credit card, and then walk through the scanners at the door, it would be very possible to scan the rest of the RF tags that permeate your clothing, and build up a database of "shirts, shoes, underwear, all associated with a packet of gum purchased by one Ann A Thema, credit card #123-456-789." Then, you change clothes, come back the next day with the same shoes on but a different RFID-tagged pair of pants, shirt, underwear, etc., they can throw all of those items into their Ann A Thema bucket based upon your assoication with the shoes, which they associated with your gum yesterday.
Pretty soon, your entire wardrobe is cataloged by Walmart. One little slip-up and *bam* -- all anonymity is lost.
OK, so Walmart now knows that you came in Friday and purchased a red shirt at 4:23. The bank down the street was robbed by a guy in a new red shirt at 5:15. The cops subpoena every store in the neighborhood that sold shirts on that day. You pop up as a match in WalMart's database, and you then get to spend a day explaining to the police that you were just sitting at home alone at 5:15, you weren't out robbing anybody.
John Ashcroft's wet dreams? Maybe. One thing is it can't happen without RFID. Ordinary barcodes are removed after purchase. But RFID is the tag that keeps on tagging.