I'd handwave that away by saying I'm not sure why poor AES got dragged into this mess in the first place. Despite what the OP claims, I've not heard of many people using ciphers as hash algorithms.
We said the same things about DES/3DES, Moores law, the groth of bot nets, and all that has some interesting side effects
A common misunderstanding of Moore's Law is that computers double in speed every 18 months. Were that true and it held true forever, then a 256-bit hash would fall about 100 years after it's 128-bit counterpart. (To those double-checking the math at home: the birthday paradox implies that you only effectively get the strength of half those bits.)
Horizontally scaling has a much, much worse payoff. Suppose you make a billion (2^30) node botnet running 24/7/365 dedicated to cracking hashes. That would make the project finish "just" 55 years after the 128-bit hash fell.
And if your target bumps that to 512-bit hash - SHA512 is in a lot of standard libraries today - then the Moore's law payoff comes after about 300 years and the billion-node payoff is still two and a half centuries out.
It's like the difference in upgrading from 8-bit to 16-bit CPUs, and then to 32-bit CPUs. Those went relatively quickly. It'll take a while for Mr. Moore to chew through the extra 32-bits we've given him in the last few years, though.
DES was cracked in 1998 on $250,000 or so of custom hardware, using an average of 4.5 days (so half the key space).
He was asking about 3DES, not DES. It's a whole world of pain harder to attack. According to the wiki, "NIST considers keying option 1 to be appropriate through 2030."
I'm not a doctor but my family practice guy explained it to me like this: That viral infection can make you much more susceptible to opportunistic bacterial infections. Depending on your health history, it might be reasonable and appropriate to start preventative antibiotics to ward off a likely, harder-to-fight illness.
When I ask the question, I don't expect perfection.
But I expect it from myself. I hate the feeling of walking out of the room and realizing that I made some dumb, should-be-obvious typo. I usually react to mistakes by laughing it off: "oops! Yep, I missed that. It should have been..." and moving on, but I still hate that I made them in the first place when I likely wouldn't if I'd been in a different setting.
There's a lot more going on in the interviewer's mind than playing 'cc'...
I've had it both ways. I don't write C often, but I've written some C that I'm proud of. I've been through some interviews (not for a position programming C!) where the whiteboard programming was basically "write some pseudocode to do a binary search", and then had a fun time playing "did you remember not to make an off-by-one error" and exploring other failure modes as you described in your other post. I've been through others where the interview was obsessing on whether I'd gotten the syntax right for type-punning a value stored in a char[4] to an int32_t.
I suspect you and I would have a good interview experience - regardless of who was asking the questions - but I promise that plenty of interviewers do things differently than you.
"After all, everybody in this room is taller than this pencil, but it doesn't tell me anything useful about them if that's my the only metric."
...says the guy who's metric is whether I prefer to use one specific communications device. Interesting!
And then you go on to list quite a few desirable skills that don't require a whiteboard at all. I don't mind writing sample programs at all. I do this stuff for a living and I should (and am) certainly able to explain why I've made the design choices that I have, and what the pros and cons of each of those decisions are. Can't I just tell you what happens if someone passes in NULL, or do you really require that I literally be on my feet with a marker in hand while I do it?
I don't mind if you challenge me and ask hard questions. To the contrary: I thrive on proving that I'm as good as I claim to be. I just wish I didn't have to be so artificially uncomfortable while I'm doing it.
How can I expect you to socialize ideas that you have to other engineers if you can't whiteboard them?
Why do you assume that I suck at explaining things verbally?
Tell me, why should someone have to program outside the office to show they're interested or good?
You don't have to. But without exception, every programmer I've ever respected - either in person or from a distance - has written at least some code because something inside them made them do it, not only because a boss made them. Those are the kind of people I want to surround myself with.
No worries, I can absolutely guarentee you I won't be interested in working for someone who wants people who live and breath code.
Neither would I, and that's not what I said. I just wouldn't trust a programmer who never codes for the pleasure of it, any more than I'd hire an artist who only paints for money. I'm not saying you're entire life should revolve around programming, but I'd be highly suspicious if you've never encountered a problem or puzzle and thought, "you know, I bet I could write a program to solve this for me".
I've walked away from quite a few offers, especially when I run in to people like you.
That's probably a good idea. If in 15 years you've not written anything just for the fun of it, you probably wouldn't be happy in the work environment here. The pay, benefits, and working conditions are excellent, but we like people who are passionate about what they do.
I hate having to write out-of-context, complicated, error-free programs on them when I can't rely on muscle memory to do some of the syntax that my fingers would automatically handle for me if I was typing, and where my normal brain-to-output pathways are unavailable.
Whiteboarding conveys a few things, a high level of spatial intelligence required for diagramming and modeling complex problems visually.
But none of what you're saying relates to whiteboarding specifically, and you're asserting that one specific means of communication is inherently necessary for conveying ideas. I've written articles, given talks, and presented without picking up a marker.
You may be extremely productive writing software or some such engineering activity, but you seem like an extremely low-level task oriented person
[...] because, in your opinion, I'm not using your pet tool in the same way you would. Look, I don't mind if you want to communicate that way. Seriously! If you're most comfortable thinking through problems with a board and marker, that's cool and I'm glad you found a way that works well for you. I don't hold that against you in any sense. However, neither do I give you extra credit for choosing that one specific method over the other options.
I'm a team player and not a lone wolf or cowboy coder by any stretch. I wish you wouldn't assume that I am just because I prefer other tools than you do.
Sure I have the stuff I did back at the University, but thats 5 years ago - I never program outside the job, which means anything I've done belongs to someone else; in fact, I don't even own a computer these days.
You wouldn't get past me in the interview process. The kinds of interviewees I like to see are ones that program because they like to program, because they're compelled to program, and they've chosen that as a career because they love doing it. And honestly, I don't even care what you've written on your own just as long as there's something. I happily approved a candidate who wrote a duck-hunting logging application to track his own results. I couldn't care less about duck hunting, but greatly appreciated that he took the initiative to write something that made his life easier in some way that was important to him.
If you want to get over that hurdle, get a dirt cheap used PC and explore GitHub until you find a project that personally interests you. Fork it and make some modifications, then submit a pull request. That tells me that you're actually into programming as a personal skill and not just as something to put on a resume, that you can adapt to others' coding styles and standards, and that you can communicate with coworkers and teammates. All of those instantly make you a more attractive candidate than someone who can't be bothered to do the same. And again, the kind of project doesn't particularly matter to me. In fact, you get bonus points for impressing me with how niche and unlikely your programming interests are. Make an Ethernet driver more efficient? Sweet! Embed subtitles in anime after downloading them from a web service? Cool! Added a new feature to a closet organizer because your clothes hanger ordering was suboptimal? I may not "get" it, but I'll respect your motivation to solve problems that interest you.
Don't use a "puzzle", use a problem you're encountered in your own code base (possibly changing the details but keeping the core problem).
Exactly this. During an interview with a certain large Internet company, one of my interview sessions started with "how would you design a system that supports [application we provide]?" It started with high-level stuff like proxy servers, database backends, etc. From there it drilled down to such details as HDD access latencies and IOPS, switch backplane bandwidth, etc. It was incredibly hard but also a lot of fun! By the end of that session, I had a pretty good idea of the kinds of capacity management issues they deal with and they had a good idea of the kind of thought processes I'd apply to new problems.
Of course, I didn't get the job so it could be that it demonstrated that my thought processes suck. Still, it was fun.:-)
If you get asked to do a puzzle or whiteboard test, do it, get it over with - yes you might not have access to your favorite cheat sheet, but thats life.
That's not even remotely close to why I despise whiteboard tests. They indicate poor interviewing skills on the company's part because they have no relation whatsoever to my future job duties.
The last time I wrote on a whiteboard in a real-life setting, I was standing in front of my elementary school classmates to work through long division problems. I never wrote on a whiteboard in college. I have never, not once written on a whiteboard at work. I do not anticipate that I'll ever be shoved into a room full of clients and asked to explain an outage by writing it out on a whiteboard. If I were, I'd throw the marker out the window, turn to the clients, and explain it to them verbally. As it turns out, I'm actually pretty good at that kind of stuff.
And for God's sake, don't ask me to write a program on a whiteboard. If you want to see me struggle through an unfamiliar, idiotic coding environment, give me a banjo and a Morse code cheatsheet and ask me to play a binary search with my toes. If you actually want to judge my applicable job skills, sit me down with a text editor - any text editor! - and let me use my standard hand-eye coordinated method of sending code into a computer.
So again, my problem with whiteboard coding isn't that I have trouble remember algorithms or experience difficulty explaining my thought processes. I don't. My problem with them is that they force me into an artificially bizarre environment that fails to demonstrate my actual job skills. If you want to really evaluate my performance under stress, bring in several interviewers at once and harshly grill me about my problem solving approach until I can either satisfactorily defend it or I run out screaming. That's a much better simulator for the "roomful of clients" situation.
I'm sure you've heard similar from others, but: you made my life better. I was a programming geek on my little C=64 before the Amiga ever came along, but it was the machine that opened my eyes to the possibilities. Your work shaped my attitudes, education, and career. Thanks for what you did for me - what you did for a lot of us.
You then [re]read the blocks whos CRCs match to determine if the CRC found a matching block or simply had a collision.
I know you already know this, but for the benefit of other readers: ZFS gives you the option of using no deduplication, using SHA256 as the checksum and trusting its results, or using SHA256 but verifying all collisions. I can't really see the point of not verifying collisions in "strong" hashing algorithms, though - it's not like you're going to get SHA256 collisions so frequently that you can't afford to explicitly verify them.
besides you assume that it needs to keep track of every block, when you only need to hash every file
In the context of ZFS, you're working with block-level deduplication.
if you've got 5 tb of files, 25gb doesn't seem so huge
Absolutely true! ZFS will happily store its dedupe block lists in any cache device you've added to a pool, so add a $100 SSD to that pool and get a huge performance boost at the same time.
but yes, that is a massive burden on resources
Depends what you're using it fore. Suppose you're running ZFS with dedupe on your virtualization farm's backend storage. Each of those VMs will start off with the same base image. Create a new VM by simply copying that base image and you'll only pay for the space needed to store the dedupe information. If you install a given app on 50 of those VMs, then you'll only "pay" for a little more than the size of a single installation (since the deduplication is at the block level). That can add up to a rather massive win in both storage and read bandwidth.
Along those lines, as of two months ago there was no downloadable ready-to-use USB image ready for dd'ing to your handy flash drive. I wrote up the steps I took to make one on OS X using VirtualBox. I've spoken to James Hall about making the resulting image file available for download directly from freedos.org, but it looks like he hasn't taken me up on it yet.
With the prevalence of cameras, why does the seller not record said item being packed, and end with it having the shipping label affixed where you can see the label tracking numbers time stamp etc clearly.
Film it up through the point where you hand it to the shipper. At least with the post office, it's my understanding that once they come to possess the item you're shipping, it is literally impossible for you to legally get it back before delivery.
To be pedantic they are actually wanting to collect fines on n^2 copyright violations. n^n would give numbers so large that that wouldn't fit on an A4 sheet of paper for 10 000 people.
Congratulations on figuring out the RIAA's business plan for the 2010's.
Even easier: many mailservers (including Gmail) support using the plus sign as a "tag marker" on your normal email address. I register for sites with "username+sitename@example.com". As a bonus, spammers' web scrapers are typically stupid enough to only harvest everything after the "+", so my maillogs show a lot of bounced email sent to "slashdot@strauser.com".
Woman in row in front of mine was on cell phone four times during movie. Got out of my seat, fetched manager during the fifth time.
It's perfectly legal (and completely socially acceptable) to tell someone to "turn that f'in thing off, dumbass". If you say it right, it's almost certain that everyone around you will start laughing at the person which will either 1) shame them into turning the f'in thing off, or 2) demonstrate that they'll get a mass beat-down if they try to physically escalate it with you. Either way, you're pretty much perfectly safe and everyone will applaud you.
Because we're evolved to enjoy hanging out with other people. We're social animals. I love my home theater, but it can't compare to feeling like you belong with a group of your sad, laughing, scared, or cheering neighbors as you share the experience with them.
A majority of their customers certainly pay their bills online, but they do it automatically and are hence exempt from this fee.
I can't quite get the attraction for automatic payment of metered services. If I suddenly get a bill for $5,000 because my telco screwed up and billed me for hundreds of calls to Berzerkistan, I want the negotiating leverage of being able to say "you're wrong and I'm not paying my bill until you fix it". With automatic payment, you don't really have a bargaining position. The telco's already charged you and about the best you can do is take it up with your credit card company (who will likely point out that you were the one who set up the payment arrangements).
I do have recurring payments set up for lots of bills that are either fixed or very unlikely to change dramatically, but there's no way I'd to that for something with such chaos potential.
Slashdot Mirror
I'd handwave that away by saying I'm not sure why poor AES got dragged into this mess in the first place. Despite what the OP claims, I've not heard of many people using ciphers as hash algorithms.
We said the same things about DES/3DES, Moores law, the groth of bot nets, and all that has some interesting side effects
A common misunderstanding of Moore's Law is that computers double in speed every 18 months. Were that true and it held true forever, then a 256-bit hash would fall about 100 years after it's 128-bit counterpart. (To those double-checking the math at home: the birthday paradox implies that you only effectively get the strength of half those bits.)
Horizontally scaling has a much, much worse payoff. Suppose you make a billion (2^30) node botnet running 24/7/365 dedicated to cracking hashes. That would make the project finish "just" 55 years after the 128-bit hash fell.
And if your target bumps that to 512-bit hash - SHA512 is in a lot of standard libraries today - then the Moore's law payoff comes after about 300 years and the billion-node payoff is still two and a half centuries out.
It's like the difference in upgrading from 8-bit to 16-bit CPUs, and then to 32-bit CPUs. Those went relatively quickly. It'll take a while for Mr. Moore to chew through the extra 32-bits we've given him in the last few years, though.
DES was cracked in 1998 on $250,000 or so of custom hardware, using an average of 4.5 days (so half the key space).
He was asking about 3DES, not DES. It's a whole world of pain harder to attack. According to the wiki, "NIST considers keying option 1 to be appropriate through 2030."
I'm not a doctor but my family practice guy explained it to me like this: That viral infection can make you much more susceptible to opportunistic bacterial infections. Depending on your health history, it might be reasonable and appropriate to start preventative antibiotics to ward off a likely, harder-to-fight illness.
I'd hire you and 9 more just like you in a heartbeat. That's exactly the kind of attitude I want in the people I'll be working alongside.
Trust me: you'd already been using the product in question for years before they asked me how I'd have designed it.
When I ask the question, I don't expect perfection.
But I expect it from myself. I hate the feeling of walking out of the room and realizing that I made some dumb, should-be-obvious typo. I usually react to mistakes by laughing it off: "oops! Yep, I missed that. It should have been..." and moving on, but I still hate that I made them in the first place when I likely wouldn't if I'd been in a different setting.
There's a lot more going on in the interviewer's mind than playing 'cc'...
I've had it both ways. I don't write C often, but I've written some C that I'm proud of. I've been through some interviews (not for a position programming C!) where the whiteboard programming was basically "write some pseudocode to do a binary search", and then had a fun time playing "did you remember not to make an off-by-one error" and exploring other failure modes as you described in your other post. I've been through others where the interview was obsessing on whether I'd gotten the syntax right for type-punning a value stored in a char[4] to an int32_t.
I suspect you and I would have a good interview experience - regardless of who was asking the questions - but I promise that plenty of interviewers do things differently than you.
"After all, everybody in this room is taller than this pencil, but it doesn't tell me anything useful about them if that's my the only metric."
...says the guy who's metric is whether I prefer to use one specific communications device. Interesting!
And then you go on to list quite a few desirable skills that don't require a whiteboard at all. I don't mind writing sample programs at all. I do this stuff for a living and I should (and am) certainly able to explain why I've made the design choices that I have, and what the pros and cons of each of those decisions are. Can't I just tell you what happens if someone passes in NULL, or do you really require that I literally be on my feet with a marker in hand while I do it?
I don't mind if you challenge me and ask hard questions. To the contrary: I thrive on proving that I'm as good as I claim to be. I just wish I didn't have to be so artificially uncomfortable while I'm doing it.
How can I expect you to socialize ideas that you have to other engineers if you can't whiteboard them?
Why do you assume that I suck at explaining things verbally?
Tell me, why should someone have to program outside the office to show they're interested or good?
You don't have to. But without exception, every programmer I've ever respected - either in person or from a distance - has written at least some code because something inside them made them do it, not only because a boss made them. Those are the kind of people I want to surround myself with.
No worries, I can absolutely guarentee you I won't be interested in working for someone who wants people who live and breath code.
Neither would I, and that's not what I said. I just wouldn't trust a programmer who never codes for the pleasure of it, any more than I'd hire an artist who only paints for money. I'm not saying you're entire life should revolve around programming, but I'd be highly suspicious if you've never encountered a problem or puzzle and thought, "you know, I bet I could write a program to solve this for me".
I've walked away from quite a few offers, especially when I run in to people like you.
That's probably a good idea. If in 15 years you've not written anything just for the fun of it, you probably wouldn't be happy in the work environment here. The pay, benefits, and working conditions are excellent, but we like people who are passionate about what they do.
Wow, you really hate whiteboarding don't you?
I hate having to write out-of-context, complicated, error-free programs on them when I can't rely on muscle memory to do some of the syntax that my fingers would automatically handle for me if I was typing, and where my normal brain-to-output pathways are unavailable.
Whiteboarding conveys a few things, a high level of spatial intelligence required for diagramming and modeling complex problems visually.
But none of what you're saying relates to whiteboarding specifically, and you're asserting that one specific means of communication is inherently necessary for conveying ideas. I've written articles, given talks, and presented without picking up a marker.
You may be extremely productive writing software or some such engineering activity, but you seem like an extremely low-level task oriented person
[...] because, in your opinion, I'm not using your pet tool in the same way you would. Look, I don't mind if you want to communicate that way. Seriously! If you're most comfortable thinking through problems with a board and marker, that's cool and I'm glad you found a way that works well for you. I don't hold that against you in any sense. However, neither do I give you extra credit for choosing that one specific method over the other options.
I'm a team player and not a lone wolf or cowboy coder by any stretch. I wish you wouldn't assume that I am just because I prefer other tools than you do.
Sure I have the stuff I did back at the University, but thats 5 years ago - I never program outside the job, which means anything I've done belongs to someone else; in fact, I don't even own a computer these days.
You wouldn't get past me in the interview process. The kinds of interviewees I like to see are ones that program because they like to program, because they're compelled to program, and they've chosen that as a career because they love doing it. And honestly, I don't even care what you've written on your own just as long as there's something. I happily approved a candidate who wrote a duck-hunting logging application to track his own results. I couldn't care less about duck hunting, but greatly appreciated that he took the initiative to write something that made his life easier in some way that was important to him.
If you want to get over that hurdle, get a dirt cheap used PC and explore GitHub until you find a project that personally interests you. Fork it and make some modifications, then submit a pull request. That tells me that you're actually into programming as a personal skill and not just as something to put on a resume, that you can adapt to others' coding styles and standards, and that you can communicate with coworkers and teammates. All of those instantly make you a more attractive candidate than someone who can't be bothered to do the same. And again, the kind of project doesn't particularly matter to me. In fact, you get bonus points for impressing me with how niche and unlikely your programming interests are. Make an Ethernet driver more efficient? Sweet! Embed subtitles in anime after downloading them from a web service? Cool! Added a new feature to a closet organizer because your clothes hanger ordering was suboptimal? I may not "get" it, but I'll respect your motivation to solve problems that interest you.
Don't use a "puzzle", use a problem you're encountered in your own code base (possibly changing the details but keeping the core problem).
Exactly this. During an interview with a certain large Internet company, one of my interview sessions started with "how would you design a system that supports [application we provide]?" It started with high-level stuff like proxy servers, database backends, etc. From there it drilled down to such details as HDD access latencies and IOPS, switch backplane bandwidth, etc. It was incredibly hard but also a lot of fun! By the end of that session, I had a pretty good idea of the kinds of capacity management issues they deal with and they had a good idea of the kind of thought processes I'd apply to new problems.
Of course, I didn't get the job so it could be that it demonstrated that my thought processes suck. Still, it was fun. :-)
If you get asked to do a puzzle or whiteboard test, do it, get it over with - yes you might not have access to your favorite cheat sheet, but thats life.
That's not even remotely close to why I despise whiteboard tests. They indicate poor interviewing skills on the company's part because they have no relation whatsoever to my future job duties.
The last time I wrote on a whiteboard in a real-life setting, I was standing in front of my elementary school classmates to work through long division problems. I never wrote on a whiteboard in college. I have never, not once written on a whiteboard at work. I do not anticipate that I'll ever be shoved into a room full of clients and asked to explain an outage by writing it out on a whiteboard. If I were, I'd throw the marker out the window, turn to the clients, and explain it to them verbally. As it turns out, I'm actually pretty good at that kind of stuff.
And for God's sake, don't ask me to write a program on a whiteboard. If you want to see me struggle through an unfamiliar, idiotic coding environment, give me a banjo and a Morse code cheatsheet and ask me to play a binary search with my toes. If you actually want to judge my applicable job skills, sit me down with a text editor - any text editor! - and let me use my standard hand-eye coordinated method of sending code into a computer.
So again, my problem with whiteboard coding isn't that I have trouble remember algorithms or experience difficulty explaining my thought processes. I don't. My problem with them is that they force me into an artificially bizarre environment that fails to demonstrate my actual job skills. If you want to really evaluate my performance under stress, bring in several interviewers at once and harshly grill me about my problem solving approach until I can either satisfactorily defend it or I run out screaming. That's a much better simulator for the "roomful of clients" situation.
I'm sure you've heard similar from others, but: you made my life better. I was a programming geek on my little C=64 before the Amiga ever came along, but it was the machine that opened my eyes to the possibilities. Your work shaped my attitudes, education, and career. Thanks for what you did for me - what you did for a lot of us.
You then [re]read the blocks whos CRCs match to determine if the CRC found a matching block or simply had a collision.
I know you already know this, but for the benefit of other readers: ZFS gives you the option of using no deduplication, using SHA256 as the checksum and trusting its results, or using SHA256 but verifying all collisions. I can't really see the point of not verifying collisions in "strong" hashing algorithms, though - it's not like you're going to get SHA256 collisions so frequently that you can't afford to explicitly verify them.
besides you assume that it needs to keep track of every block, when you only need to hash every file
In the context of ZFS, you're working with block-level deduplication.
if you've got 5 tb of files, 25gb doesn't seem so huge
Absolutely true! ZFS will happily store its dedupe block lists in any cache device you've added to a pool, so add a $100 SSD to that pool and get a huge performance boost at the same time.
but yes, that is a massive burden on resources
Depends what you're using it fore. Suppose you're running ZFS with dedupe on your virtualization farm's backend storage. Each of those VMs will start off with the same base image. Create a new VM by simply copying that base image and you'll only pay for the space needed to store the dedupe information. If you install a given app on 50 of those VMs, then you'll only "pay" for a little more than the size of a single installation (since the deduplication is at the block level). That can add up to a rather massive win in both storage and read bandwidth.
Anybody who flashes BIOS ought to be excited.
Along those lines, as of two months ago there was no downloadable ready-to-use USB image ready for dd'ing to your handy flash drive. I wrote up the steps I took to make one on OS X using VirtualBox. I've spoken to James Hall about making the resulting image file available for download directly from freedos.org, but it looks like he hasn't taken me up on it yet.
With the prevalence of cameras, why does the seller not record said item being packed, and end with it having the shipping label affixed where you can see the label tracking numbers time stamp etc clearly.
Film it up through the point where you hand it to the shipper. At least with the post office, it's my understanding that once they come to possess the item you're shipping, it is literally impossible for you to legally get it back before delivery.
To be pedantic they are actually wanting to collect fines on n^2 copyright violations. n^n would give numbers so large that that wouldn't fit on an A4 sheet of paper for 10 000 people.
Congratulations on figuring out the RIAA's business plan for the 2010's.
Even easier: many mailservers (including Gmail) support using the plus sign as a "tag marker" on your normal email address. I register for sites with "username+sitename@example.com". As a bonus, spammers' web scrapers are typically stupid enough to only harvest everything after the "+", so my maillogs show a lot of bounced email sent to "slashdot@strauser.com".
I dunno. I thought an hour's pay to never have to worry about this stuff again was worth it.
Woman in row in front of mine was on cell phone four times during movie. Got out of my seat, fetched manager during the fifth time.
It's perfectly legal (and completely socially acceptable) to tell someone to "turn that f'in thing off, dumbass". If you say it right, it's almost certain that everyone around you will start laughing at the person which will either 1) shame them into turning the f'in thing off, or 2) demonstrate that they'll get a mass beat-down if they try to physically escalate it with you. Either way, you're pretty much perfectly safe and everyone will applaud you.
Because we're evolved to enjoy hanging out with other people. We're social animals. I love my home theater, but it can't compare to feeling like you belong with a group of your sad, laughing, scared, or cheering neighbors as you share the experience with them.
I thought Walker relied on Chun Kuk Do for cleaning up Texas.
A majority of their customers certainly pay their bills online, but they do it automatically and are hence exempt from this fee.
I can't quite get the attraction for automatic payment of metered services. If I suddenly get a bill for $5,000 because my telco screwed up and billed me for hundreds of calls to Berzerkistan, I want the negotiating leverage of being able to say "you're wrong and I'm not paying my bill until you fix it". With automatic payment, you don't really have a bargaining position. The telco's already charged you and about the best you can do is take it up with your credit card company (who will likely point out that you were the one who set up the payment arrangements).
I do have recurring payments set up for lots of bills that are either fixed or very unlikely to change dramatically, but there's no way I'd to that for something with such chaos potential.