Remeber that 100 base TX over cat 5 ethernet is rated only for a max of 150 meters per segment. If you've got to run further than that (and going up into ceilings, around ducts, etc., makes for a long run quickly) you need some kind of hardware to act as a repeater, be it a router, switch, hub, or booster. Those cost big money, since not only do you have to buy them, you have to install them, you have to power them from their own electrical outlet which also costs lots of money to install. You also have to pay to maintain them with service contracts, monitoring software, payroll costs, etc., which means that even a simple repeater ends up costing roughly the same as a full blown 24-port switch, while giving you only 1/24th the value.
The cheapest solution is to put a router and fiber switch at your building's service entrance. Run the fiber to a closet in each corner of the building, and in each closet put a switch. Then you can run the final wires from the closets to your devices over cat 5.
This eliminates "random repeaters" hanging unmaintainably in the ceilings. Fiber is high capacity, and unaffected by EM interference generated by other devices in the building, such as HVAC systems or lighting ballasts, and is well suited to the long portions of the runs.
10 years ago, if you were in a Walm*rt or other big retailer, chances are the wiring was completely different. IBM POS systems at the time used a "store loop" system, running over shielded two-twisted-pairs. Those runs were rated for 2000 feet, but I know of some installations that pushed them as high as 4000 feet. While it was a loop topology designed to run from register to register, for maintenance reasons many retailers found it simpler to run individual lines from a central switch panel (typically an Autoshunt device.) With 2000 foot cable lengths, this is possible, where the 300-375 foot cat 5 is not. NCR used a "Starlan" network topology, again all wires were brought back to a central closet. And Siemens Nixdorf ran yet another proprietary serial network in a hub-and-spoke topology through boxes called "star boxes".
It wasn't until the adoption of ordinary PCs as cash registers that ethernet caught on in the retail world. And since ethernet cards were way cheaper than token ring cards (no IBM tax) and far, far cheaper than store loop cards (for the proprietary register networking), ethernet was adopted on price alone even though other networking alternatives had their attractions.
While it may seem more complicated today, you should have tried to troubleshoot problems with any of those other "networking" technologies. The IBMs, in particular, acted a lot like a really slow token ring loop, and could talk only in one direction. Confuse just one computer, and the whole loop failed. Break two computers, and now none of the computers can even tell you where the break occurred anymore. Also, you have to train technicians on all the magic diagnostic commands, the electrians on the funny wiring requirements, and you have to have special software running on special hardware with a special OS; whereas ethernet is just ethernet. And everybody knows ethernet, which means service contracts and support staff just got way cheaper, too.
A similar scam was perpetrated many, many years ago in banks. If you're old like me, you might remember that banks used to have blank deposit tickets piled up for their customers to fill out while waiting for the next available cashier.
The bad guys simply placed a few non-blank deposit tickets on the top of the stack. They looked blank, but had a MICR line at the bottom for an account. Some were even so bold as to place their own actual deposit tickets in the stack. If the cashier was careless and ran the deposit ticket through her machine, it would deposit the money to the perpetrator's account.
At least that was the theory. I don't know just how often the bad guys got away with it.
You're kidding yourself to think they don't have that information already.
What they probably don't have is an on-line alarm center that compares gift card issuance or redemption in the time and geographical fashion needed to catch this guy. Yet.
It would have been the first approach I'd have taken to solving this problem, at least if I worked for Walm*rt's authorizing systems area.
In a related note, have you ever been called by a Visa representative and asked something like "did you just purchase some computer equipment in Florida?" Visa already has a system like this in place today. They do track your shopping habits geographically, and if they get an authorization request for a large purchase outside of your "normal" range, it sets off alarm bells in their Fraud Detection unit.
It's a deliberate typo on my part. I do it mostly because I work for a company that doesn't think highly of Walm*rt, nor do I. I know there's a star in the name somewhere, but I deliberately choose to replace the 'A' with the asterisk in the same manner that I might spell f*ck. I think of it in roughly the same manner that the military types deliberately mispronounce the names of their enemies. It's just a little slam against them. (I thought your regexp jokes were pretty funny, btw.)
That said, I feel really bad for them taking a hit from thieves. As much as I don't like W*llyWorld, I really, really don't like thieves; and nobody should ever have to put up with them. Very few things are sweeter than watching videotape of a scumbag thief get nailed because of a system I wrote or helped implement. I'd personally go a long way out of my way to help Walm*rt bust these assclowns. Funny how a shared enemy can get you to set aside your differences like that.
Does this include their technical staff? I mean George the Greeter probably isn't likely to be the hacker in this case, nor is virtually anyone working in the stores. Only their tech staff would be the ones who know the protocols for the gift card authorizations. And they're probably the more loyal employees.
Unless it's as simple as a previous poster mentioned: pay off Nate the Night Shelf Stock Boy to get a few minutes access into a wiring closet and plant an access point. They could probably sniff the protocols easy enough, at least to see a gift card authorization and recognize the number. Then, it's a SMOH (Small Matter of Hacking) to find POS servers and/or registers elsewhere in the network. Sniff, sniff, hack, hack, and the gift card scam is underway.
I'm pretty sure the case wasn't publicised by Walm*rt. I can't think of a single benefit they'd get by announcing to the world "our gift card customers are getting screwed." This was made public by an annoyed customer who went to her local TV station, and the reporter did a bit more digging (just like they're supposed to!)
Yeah, I know replying to yourself is bad karma, but I just thought of another possibility: system error.
Walm*rt may have an error in their central authorizing servers that's "confusing" redemption replies. Imagine a server that accepts requests from tens of thousands of different registers (probably a mainframe.) All those responses have to go back to the place they came from. What if a response was corrupted and an approval went back to a wrong register?
Or what if a request was corrupted? What if some stack corruption in their register changed a 12345 into a 22345, and they just happened to match a card issued elsewhere?
Or, what if the manufacturers screwed up and printed duplicate serial numbers on the backs of a batch of cards? Jane Doe goes to buy a card, but that serial number was already purchased by John Smith in a different state. If Jane's purchase request was made "offline", the card would be given to her immediately, but the card activation would have to be made after she left. Now, if Jane redeems her card, she uses John's value. Walm*rt would have no way to go back to Jane to say "Sorry, we gave you a bad card."
For these scenarios to work with a card being cashed within hours of being issued seems highly unlikely until you remember one thing: Walm*rt operates over 8000 stores, with probably over 200,000 POS registers, each of which is cranking through perhaps two or three hundred transactions a day. When you start factoring in just how many transactions might be corrupted, having a couple of "unlikely" coincidences seems more like a statistical certainty than a random chance.
This has to be someone hacking from the inside of Walm*rt. Maybe not an employee, but it sure looks like someone is inside their network.
First, look at how gift cards work. Many retailers use the model where their gift card records in their database created upon activation. This means they don't even ask the manufacturers for a list of "cards printed"; they simply direct the manufacturer to produce "a million cards in this number sequence, label them $20," that sort of thing. The value is added when the record is created at issuance. I'm assuming Walm*rt is operating in a similar fashion.
It's theoretically safe, because a shoplifted card isn't redeemable. The cards never actually "store" their value, all the value is located only in the database (more correctly, the value is in the ability to redeem from the database.)
So, if someone is redeeming the cards in a distant state just hours after issuance, they're doing it by sniffing the data real-time, somewhere on the inside of Walm*rt's systems. The article implies that the thief knows when the card is issued, and cashes it in within hours. Cashing the cards in distant states implies network access to at least run the scam (although that may be an email to a conspirator.) The fact that the victims were located in different states implies the perpetrators either have central access to the database involved, or have access to the POS systems that are selling and activating the cards.
The points of access are numerous. This could be happening in the POS registers, the store POS servers, the networking gear, the central authorizing servers, the central sales logging servers, or the database. It could be someone in their security group looking at electronic journals on-line. It could be a hacker in the parking lot with 802.11 gear telnetting to any of the above equipment, emailing card info to his buddies. The redemption is probably being done via "forged" cards, which might be as simple as printing a barcode on a sticker, covering the existing barcode, and then keeping the cards after redeeming them to hide the evidence. A smart thief would redeem $149 on a $150 card to keep the card with the $1 balance on it in his pocket.
That's a lot of ground to cover for their investigators. Given their M.O. I can think of a few traps they can set to catch these guys, but they're probably going to take time to implement. And with the high probability of an inside job, who do you trust in their systems end to help you catch the bad guys?
Re:Nope, wrong, invalid.. nothing to see here.
on
The End of Encryption?
·
· Score: 2, Insightful
Perhaps the author expressed the idea poorly by stating it in terms of solving P?=NP, but the ultimate point he was trying to get across is: will the currently difficult* problems that are the basis of modern cryptography remain difficult into the future? And for how long?
* I'm deliberately leaving 'difficult' undefined to dodge abuse from the language lawyers.
I've always wondered what would happen if some 15-year-old math wiz who is playing around in Mathematica comes up with a novel approach to factoring; and then what effect that would have on modern cryptography and communications. This article simply inflates that idea into a paranoia for the masses. Which, as you said, is nothing to see here, move along...
rifled air-pressure-powered pellet guns are considered firearms in Michigan
Most people who hear the words "air rifle" remember the lever action Daisy B-B guns, and they remember B-B gun battles with their friends. The worst anyone ever went home with was a stinging bruise, (no, Mom, nobody put their eye out) and everyone had a great time.
Modern air rifles are nothing like those B-B guns. Compare the Daisy to my rifled RWS Diana 350 which fires a pellet at 1250 fps. You can even buy actual rimfire.22 caliber ammo that isn't that fast. Believe me when I say that I would NOT want to get shot by this springer. It's a great varmint gun -- very quiet and powerful enough to kill small game. But don't confuse it with the toys of your childhood.
I can certainly understand why Michigan would consider it to be in the same class as a firearm. It performs substantially the same tasks.
Hmm. I had only seen Crestron used for room lighting solutions before, so I just went to their web site. It looks to me like they invented their own solution for whole house automation, and it does look really cool.
But as a mid-level consumer, I can't afford to refit my house with Crestron everything, from light switches to thermostats. At least not today. And, I don't want to carry a Crestron remote any more than I want to carry a Sony remote. I already carry a phone, I want to use that. And if my phone says Bluetooth, and this TV set says Bluetooth, I'll buy it.
And if you're right, and the manufacturers never adopt standards for control, it would still be possible to build a bridge between Bluetooth and whatever is required for my cheapo components. The bridge could be almost as "smart" as the Harmony remote, and head to the web to download configuration data for an IR-controlled Toshiba television and an RF-controlled RCA satellite dish receiver.
I do believe market forces may yet drive consumer electronics makers to adopt standards. If nothing else, some of the more "snobbish" brands will pick up on one of these standards sooner or later. I know I'd spend substantially more for a device that used Bluetooth (hell, I just spent $x00 outfitting my family with new BT phones just so I could have it on mine, where x is a number greater than that to which I will admit.) So, like anything else, it'll happen at the top of the line first, trickle down to the high-middle range of CE gear, and a few years after that Sony will pick up on it and sell the hell out of the bottom end to everyone, implying loudly that "if your gear doesn't have X standard support, it's obsolete." We've seen that happen with all sorts of technology before, from VHS to DVDs, from cassettes to CDs, and from color TV to HDTV (this last one is still cooking, but it's coming quickly.)
An Anonymous Coward wrote: Thats a great idea.. but bluetooth has too short a range for that to work. Isn't it around 10 feet? Thats nothin
Good point, although Bluetooth actually has three range classes -- one, ten, and one hundred meters. (I've never seen more than about 8 meters with my phone, though.) The more I read about Zigbee the more I see why the remote control technologies would be using it to perform the functionality I'm hoping for. However, it should be a simple matter of hardware to provide bridging between the two technologies. I also think that the rapid adoption of Bluetooth cell phones would drive a Zigbee-based home installation to have to accomodate all those potential users. Why would anyone want to use a remote control (or five) when they already have a cell phone that could do the job?
The Bluetooth phone from Verizon (a friend has one) isn't so much "crippled" as it is "unfinished." The rest of us in our little lunch group have had Bluetooth phones, PDAs, laptops, and even cars for quite some time now. Even I finally got a Bluetooth phone when AT&T finally expanded their GSM coverage to more than a one-mile circle around downtown. The "Verizon guy" has been waiting and waiting for the Motorola Bluetooth CDMA phone, which was finally released to Verizon customers just last month.
Boy, was he disappointed when we all sat down and discovered his phone and found that it offered only networking service, and could not use any other services except a headset.
However, it turns out Verizon has simply disabled the rest of the functionality (OBEX and others) because of bugs in the phone's implementation, not because of any vast conspiracy. As they fix the bugs, they've promised to make new versions of the phone's firmware available for free at any Verizon store.
It's getting adopted, although slower than most of us wish. Personally, I think the killer app for Bluetooth will be as the replacement for IR remote controls. Yes, IR is probably about a dollar cheaper per unit, but it's a one-way protocol with no feedback. Imagine a remote that if you pushed the button for channel change, the channel would actually change. Every single time.
And being two-way, a remote would automatically download its configuration right from the device you're controlling. Harmony remotes sort of do this today, but they require USB cables and that you download a configuration from their web site. The Philips Pronto remotes are somewhat cumbersome as their GUI is usually tied to the device, and you still have to find a configuration you like on the net.
Imagine a home where your PC, your phone, your TV, your PDA and your remote control can all interact and play nice. The phone rings? Your Tivo pauses the show, and displays the caller ID on screen allowing you to decide whether to answer it or not. Push the "do not disturb" button on the remote, and your answering machine will take over while you step into the bathroom. Your burglar alarm disarms itself because you walked up to the door, and arms itself as the last cell-phone equipped person leaves. And it's self configuring -- the only requirement is that you pair your devices to indicate "trust". Adding a surround-sound amplifier? Well, your TV, Tivo and cable box would all know about it automatically. Changing channels? Talk to the cable box. Your Tivo will know it's been changed. Raising volume? Your surround sound will handle that if it's on, your TV will handle it if it's off. And turning your system on won't involve four buttons or flaky macros that toggle one thing on but another off, either -- the power switch will turn on everything needed, reliably.
Yeah, it's a ways away yet, but a smart low-power wireless protocol makes it all possible. Being present already in phones, PDAs and PCs, Bluetooth seems like it's the first technology with a real shot at making this happen.
Windows XP Service Pack 2 supports Bluetooth natively. It discovered my Bluetooth dongle (Belkin F8T001) and put a new toolbar thing next to the system tray. I didn't even notice it until it added a menu-up arrow that included my phone that it must have spotted.
That said, it's still really buggy. Every time I've tried clicking on it, Windows Explorer crashes utterly. That led me to notice something else with Service Pack 2: Explorer now properly refreshes all the system tray icons when it comes back up. No more orphaned tasks because the icons have disappeared. Anyway, I'm still using the Belkin system tray icon for accessing the Bluetooth features.
How about a wireless speakerphone in your car? With a Bluetooth handsfree kit, you can just hop in your car and go. Your car and your phone recognize each other as you turn on the ignition, and your car says "I'm going to be your headset now."
It's been discussed having Bluetooth "silencers" installed at movie theatres, concert venues, and restaurants. They'd be a simple Bluetooth device that would request your phone switch to a silent profile for the next hour or two. If you were an anti-social jerk, you could turn such a thing off. But as we know from lots of experience, most people won't be bothered to change their default settings. It's not a complete solution to the problem of cell phone ringers in auditoriums, but every phone call silenced makes for a more pleasant experience for all.
The nice thing is that all of the features you mention with respect to PC usage can quite peacably coexist with the cell phone usage. Both ends can drive the market simultaneously, and as more crossover functionality becomes possible, consumer demand will drive more adoption. We're already seeing this with digital camera phones exchanging pictures with PCs. And laptops are able to use the Bluetooth equipped phones for network access.
Bluetooth was the sole reason I purchased a T637 phone earlier this summer. I really didn't care about the camera (crappy quality pictures) nor about the Java in the phone. I wanted my Palm Tungsten to be able get to the internet occasionally, and I now have that. But I also have the option to have a speaker kit in my car (I suppose this will wait 'til Christmas), to exchange address and phone data with my desktop, and opens up all sorts of possibilities.
Well, according to both of the articles it's the research team that created Bluetooth, and the technologies around it. They are not the group that is responsible for incorporating Bluetooth into the other products.
It could be as simple as "the standard has been set, the goals have been accomplished, move on to new things." Since Ericsson is no longer the sole creative force behind Bluetooth, it makes financial sense to not keep 125 people employed to argue one seat on the Bluetooth Special Interest Group.
It's too bad for Bluetooth in that I think Ericsson had some brilliant visionaries doing this work, and that those people are no longer focused on Bluetooth. However, they're being incorporated into other units which can only help them overall.
It's not good news, it's not bad news. It's just news. The timing is interesting as I see Bluetooth now on the cusp of adoption by every cell phone maker for their mid- and possibly even low-end phones.
( And Michael, wi-fi is not necessarily a good replacement for Bluetooth. The higher power requirements for wi-fi mean shorter battery life, which is death for cell phones. And Bluetooth incorporates discovery protocols which are all geared toward personal networking, not internet networking. I think wi-fi would be a really chatty way to accomplish those goals, again at the expense of battery life. )
This is very insightful, and I see that all over here. I imagine it takes place everywhere.
The problem in a business shop is that everyone has a day job -- crank out this code. Like most people, we'll continue to do things the same old way until someone shows us different. For example, in the early '90s when we began the migration of our business product to a Windows based platform, most of us had only briefly encountered object orientation in books and magazine articles (those of us who bothered to keep up with the trade publications, that is.) At that early time (for us), it was difficult to distinguish object oriented programming from any of the other programming "fads" of the day. For example, at that time management still thought code generators would be the magic bullet, and placed little emphasis on learning the new object oriented languages. They did not provide any encouragement to any of us to move forward professionally (although some of us did on our own, anyway.)
Recently, we brought in a consultant to help us with a large refactoring effort. I learned so much about agile programming (and not so much about refactoring) that I'm trying to figure out how to take a six-month sabbatical to go code on an agile team somewhere else just for the experience. It was really an eye-opener for me, and I think if I knew more about it, or experienced it first hand, I'd love to get it in house. More than anything, the consultant reopened my eyes to seeing what else is going on out there, over and above the daily grind.
But that's not the common viewpoint of many of the developers -- they just want to come in, write their code, and then go home to play softball or drink beer. It's not that they're opposed to learning a new methodology or technology, they simply aren't interested in personally learning that subject and then bringing those ideas in house. They see no payoff in learning assembler, or what an IP stack is, or why it's written that way, and so they don't put the effort into it. Even though they can look to the people who have that knowledge and see how successful they are, they don't often take that initiative upon themselves.
But what's ultimately most frustrating to me is our primary software vendor partner is just as old school as anyone else I can think of. We're talking "let's write our own string library because we're ignorant of the std::string library" kind of old school. (I mean, the old saw that writing your own string class is one of the stages every newbie passes through is now 10 years old.) The reason I'm so frustrated is that they're "outside" of our daily grind, so theoretically they should be exposed to methodologies from dozens of other clients. I originally expected us to get "modern" thinking out of them, but we've ended up driving more change in their organization than they've given us.
Perhaps because when our large company had everyone taking the Meyers Briggs Personality Inventory back in the late '90s, we saw a hugely disproportionate share of introverts among the programming staff? Or perhaps it's simply because introverts tend to avoid management positions, since interacting with people is not high on their list of "things they enjoy doing"?
You fall back on anectodal "evidence" that suggests your experience of hanging around with extroverted people is somehow related to their profession, when it's much more likely you hang around extroverts because you're an extrovert yourself, and you hang around programmers because you're a programmer. Those are two separate affinities -- don't get them confused just because you share both of them.
Finally, I never called programmers "schizoid" -- you made that up from whole cloth. I also never said introverts don't have "bags of common sense", nor did I say they weren't intellectual. Common sense and introversion are unrelated. You apparently are having very a hard time distinguishing introversion from a mental disorder, and seem to either be afraid of introverts, have a distate for them, or simply make no effort to understand them.
My suggestion to you is to quit whining "stereotype, stereotype" just because someone recognized a cause and effect relationship that happens to involve people. In the field of biology, recognizing cause and effect among life forms is often called "research." That, and get out there and encourage a few shy people in some way. You seem outgoing enough, you'll probably do both of yourselves some good.
Oh, absolutely there's a distinction. But keep in mind that leading isn't nearly as hard as managing. If you're an expert in your field, you'll already have the respect of the people on your team. Then it's a simple matter of speaking up at the right time, and you're a leader. A leader can inspire the workers by example -- just by doing what they've always done, only more visibly.
As you undoubtedly know, managing is all the drudge work. For those who don't think about it much, a manager has to schedule vacations, write reviews, hand out status reports to jittery managers of other projects, demand status reports of recalcitrant coders, praise the good guys and spank the bad ones who spend their mornings on Slashdot. They make up the on-call lists and have to listen to 50% of the people whine that they were on call last Christmas, so why did they get this Labor Day? Then, they have to memorize the handbooks that list the official columns of carrots and sticks. Somewhere in there they have to learn the technical lingo their employees toss around trying to explain their latest problems, they have to send flowers to the guy whose dad just died, and meet with half a dozen salesmen who promise to double staff productivity and end global warming if they'd just place their order. They have to keep their sense of humor, put up with crap from the arrogant technical staff, calm the neurotic director, and attend daily project meetings.
Oh, and they have to buy their senior technical staff new PCs. I mean really. 1500MHz is a crap box these days for compiles of that many lines of code. Dual Xeons at the desktops would improve productivity by a lot, position your staff for the 64-bit OS to come, and don't skimp on the RAM, SATA RAID, or the graphics cards. Besides, those junky old PCs are depreciated already, just give them to the guys in accounting, they don't need anything more than that.
Managing means keeping two dozen balls in the air simultaneously. It's not a glamour job. It's a sucky job. If you think your manager is overpaid, just think about that list above, realize that's only the visible portion of what your manager has to do, and then be really really glad it's not you.
[ I can hear Aldous Huxley's Brave New Words echoing in my ears: "I'm glad I'm a Beta. Alphas have too many responsibilities..." ]
Except most programmers I know that are worth their weight in salt would completely and totally suck to have as managers.
Some are poorly organized in everything but their code (*ahem*.) A few grew up believing that an employee / employer relationship should be antagonistic; that a manager must rule their team with an iron fist. That may come from looking around at a bunch of us slacker programmers thinking "hey, why aren't they working as hard as I? If I were their manager, I'd be busting their asses 24 by 7." Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it.
In most of these cases it seems that the programmers have spent their time learning machine management skills. Those skills are completely unhelpful when it comes to working with people. The lessons you learn (for example, "the machine only does exactly what I tell it") don't work with human employees, no matter how hard you try to apply them.
Yes, management is a skill that can be learned, but I don't know any geeks that would want to spend the time, let alone actually manage. Not even for the money. Almost all the people I know who have become successful managers have never been real programmers. They were business analysts or came from completely outside the IT field.
Nahh, you don't need a special screwdriver. There are lots of alternatives.
For one, you can take a moto-tool and cut a straight slot in the head of the screw, then use a flat screwdriver in your new slot to remove it. This is a lot of work but on a frozen screw it's effective.
For another, you can usually grab the sides of the screw head in a pair of needlenose pliers and rotate it out. This is especially true of the hard drive lids, and is my preferred method (since I carry a needlenose on my belt.)
For another, you can sometimes wedge a flat bladed screwdriver right in between the points of the star shaped head (tipped at the appropriate angle). If the screw isn't extremely tight, this is fastest, but you run the risk of damaging the screwdriver if it is tight.
I typically loosen all the screws with the pliers first, then spin them out with a flat blade.
Finally, remember that it's just a broken old IBM DeathStar drive. You don't have to be kind to all the pieces. Use a screwdriver as a pry bar and separate the sheet-metal lid from the aluminum drive housing. Make a hole big enough for a pair of pliers to grab it and the lid will tear out of the way fairly easily. But don't be too rough or you'll shatter the disc platters and then have lots of nasty glass shards to deal with.
Slashdot Mirror
Exactly. I'm being petty and juvenile (and I post to Slashdot, go figure.) I answered this question above, if you'd care to read why.
Yes, the bad guys tried this long, long ago.
Remeber that 100 base TX over cat 5 ethernet is rated only for a max of 150 meters per segment. If you've got to run further than that (and going up into ceilings, around ducts, etc., makes for a long run quickly) you need some kind of hardware to act as a repeater, be it a router, switch, hub, or booster. Those cost big money, since not only do you have to buy them, you have to install them, you have to power them from their own electrical outlet which also costs lots of money to install. You also have to pay to maintain them with service contracts, monitoring software, payroll costs, etc., which means that even a simple repeater ends up costing roughly the same as a full blown 24-port switch, while giving you only 1/24th the value.
The cheapest solution is to put a router and fiber switch at your building's service entrance. Run the fiber to a closet in each corner of the building, and in each closet put a switch. Then you can run the final wires from the closets to your devices over cat 5.
This eliminates "random repeaters" hanging unmaintainably in the ceilings. Fiber is high capacity, and unaffected by EM interference generated by other devices in the building, such as HVAC systems or lighting ballasts, and is well suited to the long portions of the runs.
10 years ago, if you were in a Walm*rt or other big retailer, chances are the wiring was completely different. IBM POS systems at the time used a "store loop" system, running over shielded two-twisted-pairs. Those runs were rated for 2000 feet, but I know of some installations that pushed them as high as 4000 feet. While it was a loop topology designed to run from register to register, for maintenance reasons many retailers found it simpler to run individual lines from a central switch panel (typically an Autoshunt device.) With 2000 foot cable lengths, this is possible, where the 300-375 foot cat 5 is not. NCR used a "Starlan" network topology, again all wires were brought back to a central closet. And Siemens Nixdorf ran yet another proprietary serial network in a hub-and-spoke topology through boxes called "star boxes".
It wasn't until the adoption of ordinary PCs as cash registers that ethernet caught on in the retail world. And since ethernet cards were way cheaper than token ring cards (no IBM tax) and far, far cheaper than store loop cards (for the proprietary register networking), ethernet was adopted on price alone even though other networking alternatives had their attractions.
While it may seem more complicated today, you should have tried to troubleshoot problems with any of those other "networking" technologies. The IBMs, in particular, acted a lot like a really slow token ring loop, and could talk only in one direction. Confuse just one computer, and the whole loop failed. Break two computers, and now none of the computers can even tell you where the break occurred anymore. Also, you have to train technicians on all the magic diagnostic commands, the electrians on the funny wiring requirements, and you have to have special software running on special hardware with a special OS; whereas ethernet is just ethernet. And everybody knows ethernet, which means service contracts and support staff just got way cheaper, too.
A similar scam was perpetrated many, many years ago in banks. If you're old like me, you might remember that banks used to have blank deposit tickets piled up for their customers to fill out while waiting for the next available cashier.
The bad guys simply placed a few non-blank deposit tickets on the top of the stack. They looked blank, but had a MICR line at the bottom for an account. Some were even so bold as to place their own actual deposit tickets in the stack. If the cashier was careless and ran the deposit ticket through her machine, it would deposit the money to the perpetrator's account.
At least that was the theory. I don't know just how often the bad guys got away with it.
What they probably don't have is an on-line alarm center that compares gift card issuance or redemption in the time and geographical fashion needed to catch this guy. Yet.
It would have been the first approach I'd have taken to solving this problem, at least if I worked for Walm*rt's authorizing systems area.
In a related note, have you ever been called by a Visa representative and asked something like "did you just purchase some computer equipment in Florida?" Visa already has a system like this in place today. They do track your shopping habits geographically, and if they get an authorization request for a large purchase outside of your "normal" range, it sets off alarm bells in their Fraud Detection unit.
That said, I feel really bad for them taking a hit from thieves. As much as I don't like W*llyWorld, I really, really don't like thieves; and nobody should ever have to put up with them. Very few things are sweeter than watching videotape of a scumbag thief get nailed because of a system I wrote or helped implement. I'd personally go a long way out of my way to help Walm*rt bust these assclowns. Funny how a shared enemy can get you to set aside your differences like that.
Unless it's as simple as a previous poster mentioned: pay off Nate the Night Shelf Stock Boy to get a few minutes access into a wiring closet and plant an access point. They could probably sniff the protocols easy enough, at least to see a gift card authorization and recognize the number. Then, it's a SMOH (Small Matter of Hacking) to find POS servers and/or registers elsewhere in the network. Sniff, sniff, hack, hack, and the gift card scam is underway.
I'm pretty sure the case wasn't publicised by Walm*rt. I can't think of a single benefit they'd get by announcing to the world "our gift card customers are getting screwed." This was made public by an annoyed customer who went to her local TV station, and the reporter did a bit more digging (just like they're supposed to!)
Walm*rt may have an error in their central authorizing servers that's "confusing" redemption replies. Imagine a server that accepts requests from tens of thousands of different registers (probably a mainframe.) All those responses have to go back to the place they came from. What if a response was corrupted and an approval went back to a wrong register?
Or what if a request was corrupted? What if some stack corruption in their register changed a 12345 into a 22345, and they just happened to match a card issued elsewhere?
Or, what if the manufacturers screwed up and printed duplicate serial numbers on the backs of a batch of cards? Jane Doe goes to buy a card, but that serial number was already purchased by John Smith in a different state. If Jane's purchase request was made "offline", the card would be given to her immediately, but the card activation would have to be made after she left. Now, if Jane redeems her card, she uses John's value. Walm*rt would have no way to go back to Jane to say "Sorry, we gave you a bad card."
For these scenarios to work with a card being cashed within hours of being issued seems highly unlikely until you remember one thing: Walm*rt operates over 8000 stores, with probably over 200,000 POS registers, each of which is cranking through perhaps two or three hundred transactions a day. When you start factoring in just how many transactions might be corrupted, having a couple of "unlikely" coincidences seems more like a statistical certainty than a random chance.
First, look at how gift cards work. Many retailers use the model where their gift card records in their database created upon activation. This means they don't even ask the manufacturers for a list of "cards printed"; they simply direct the manufacturer to produce "a million cards in this number sequence, label them $20," that sort of thing. The value is added when the record is created at issuance. I'm assuming Walm*rt is operating in a similar fashion.
It's theoretically safe, because a shoplifted card isn't redeemable. The cards never actually "store" their value, all the value is located only in the database (more correctly, the value is in the ability to redeem from the database.)
So, if someone is redeeming the cards in a distant state just hours after issuance, they're doing it by sniffing the data real-time, somewhere on the inside of Walm*rt's systems. The article implies that the thief knows when the card is issued, and cashes it in within hours. Cashing the cards in distant states implies network access to at least run the scam (although that may be an email to a conspirator.) The fact that the victims were located in different states implies the perpetrators either have central access to the database involved, or have access to the POS systems that are selling and activating the cards.
The points of access are numerous. This could be happening in the POS registers, the store POS servers, the networking gear, the central authorizing servers, the central sales logging servers, or the database. It could be someone in their security group looking at electronic journals on-line. It could be a hacker in the parking lot with 802.11 gear telnetting to any of the above equipment, emailing card info to his buddies. The redemption is probably being done via "forged" cards, which might be as simple as printing a barcode on a sticker, covering the existing barcode, and then keeping the cards after redeeming them to hide the evidence. A smart thief would redeem $149 on a $150 card to keep the card with the $1 balance on it in his pocket.
That's a lot of ground to cover for their investigators. Given their M.O. I can think of a few traps they can set to catch these guys, but they're probably going to take time to implement. And with the high probability of an inside job, who do you trust in their systems end to help you catch the bad guys?
* I'm deliberately leaving 'difficult' undefined to dodge abuse from the language lawyers.
I've always wondered what would happen if some 15-year-old math wiz who is playing around in Mathematica comes up with a novel approach to factoring; and then what effect that would have on modern cryptography and communications. This article simply inflates that idea into a paranoia for the masses. Which, as you said, is nothing to see here, move along...
Most people who hear the words "air rifle" remember the lever action Daisy B-B guns, and they remember B-B gun battles with their friends. The worst anyone ever went home with was a stinging bruise, (no, Mom, nobody put their eye out) and everyone had a great time.
Modern air rifles are nothing like those B-B guns. Compare the Daisy to my rifled RWS Diana 350 which fires a pellet at 1250 fps. You can even buy actual rimfire .22 caliber ammo that isn't that fast. Believe me when I say that I would NOT want to get shot by this springer. It's a great varmint gun -- very quiet and powerful enough to kill small game. But don't confuse it with the toys of your childhood.
I can certainly understand why Michigan would consider it to be in the same class as a firearm. It performs substantially the same tasks.
But as a mid-level consumer, I can't afford to refit my house with Crestron everything, from light switches to thermostats. At least not today. And, I don't want to carry a Crestron remote any more than I want to carry a Sony remote. I already carry a phone, I want to use that. And if my phone says Bluetooth, and this TV set says Bluetooth, I'll buy it.
And if you're right, and the manufacturers never adopt standards for control, it would still be possible to build a bridge between Bluetooth and whatever is required for my cheapo components. The bridge could be almost as "smart" as the Harmony remote, and head to the web to download configuration data for an IR-controlled Toshiba television and an RF-controlled RCA satellite dish receiver.
I do believe market forces may yet drive consumer electronics makers to adopt standards. If nothing else, some of the more "snobbish" brands will pick up on one of these standards sooner or later. I know I'd spend substantially more for a device that used Bluetooth (hell, I just spent $x00 outfitting my family with new BT phones just so I could have it on mine, where x is a number greater than that to which I will admit.) So, like anything else, it'll happen at the top of the line first, trickle down to the high-middle range of CE gear, and a few years after that Sony will pick up on it and sell the hell out of the bottom end to everyone, implying loudly that "if your gear doesn't have X standard support, it's obsolete." We've seen that happen with all sorts of technology before, from VHS to DVDs, from cassettes to CDs, and from color TV to HDTV (this last one is still cooking, but it's coming quickly.)
Good point, although Bluetooth actually has three range classes -- one, ten, and one hundred meters. (I've never seen more than about 8 meters with my phone, though.) The more I read about Zigbee the more I see why the remote control technologies would be using it to perform the functionality I'm hoping for. However, it should be a simple matter of hardware to provide bridging between the two technologies. I also think that the rapid adoption of Bluetooth cell phones would drive a Zigbee-based home installation to have to accomodate all those potential users. Why would anyone want to use a remote control (or five) when they already have a cell phone that could do the job?
Boy, was he disappointed when we all sat down and discovered his phone and found that it offered only networking service, and could not use any other services except a headset.
However, it turns out Verizon has simply disabled the rest of the functionality (OBEX and others) because of bugs in the phone's implementation, not because of any vast conspiracy. As they fix the bugs, they've promised to make new versions of the phone's firmware available for free at any Verizon store.
And being two-way, a remote would automatically download its configuration right from the device you're controlling. Harmony remotes sort of do this today, but they require USB cables and that you download a configuration from their web site. The Philips Pronto remotes are somewhat cumbersome as their GUI is usually tied to the device, and you still have to find a configuration you like on the net.
Imagine a home where your PC, your phone, your TV, your PDA and your remote control can all interact and play nice. The phone rings? Your Tivo pauses the show, and displays the caller ID on screen allowing you to decide whether to answer it or not. Push the "do not disturb" button on the remote, and your answering machine will take over while you step into the bathroom. Your burglar alarm disarms itself because you walked up to the door, and arms itself as the last cell-phone equipped person leaves. And it's self configuring -- the only requirement is that you pair your devices to indicate "trust". Adding a surround-sound amplifier? Well, your TV, Tivo and cable box would all know about it automatically. Changing channels? Talk to the cable box. Your Tivo will know it's been changed. Raising volume? Your surround sound will handle that if it's on, your TV will handle it if it's off. And turning your system on won't involve four buttons or flaky macros that toggle one thing on but another off, either -- the power switch will turn on everything needed, reliably.
Yeah, it's a ways away yet, but a smart low-power wireless protocol makes it all possible. Being present already in phones, PDAs and PCs, Bluetooth seems like it's the first technology with a real shot at making this happen.
That said, it's still really buggy. Every time I've tried clicking on it, Windows Explorer crashes utterly. That led me to notice something else with Service Pack 2: Explorer now properly refreshes all the system tray icons when it comes back up. No more orphaned tasks because the icons have disappeared. Anyway, I'm still using the Belkin system tray icon for accessing the Bluetooth features.
It's been discussed having Bluetooth "silencers" installed at movie theatres, concert venues, and restaurants. They'd be a simple Bluetooth device that would request your phone switch to a silent profile for the next hour or two. If you were an anti-social jerk, you could turn such a thing off. But as we know from lots of experience, most people won't be bothered to change their default settings. It's not a complete solution to the problem of cell phone ringers in auditoriums, but every phone call silenced makes for a more pleasant experience for all.
The nice thing is that all of the features you mention with respect to PC usage can quite peacably coexist with the cell phone usage. Both ends can drive the market simultaneously, and as more crossover functionality becomes possible, consumer demand will drive more adoption. We're already seeing this with digital camera phones exchanging pictures with PCs. And laptops are able to use the Bluetooth equipped phones for network access.
Bluetooth was the sole reason I purchased a T637 phone earlier this summer. I really didn't care about the camera (crappy quality pictures) nor about the Java in the phone. I wanted my Palm Tungsten to be able get to the internet occasionally, and I now have that. But I also have the option to have a speaker kit in my car (I suppose this will wait 'til Christmas), to exchange address and phone data with my desktop, and opens up all sorts of possibilities.
It could be as simple as "the standard has been set, the goals have been accomplished, move on to new things." Since Ericsson is no longer the sole creative force behind Bluetooth, it makes financial sense to not keep 125 people employed to argue one seat on the Bluetooth Special Interest Group.
It's too bad for Bluetooth in that I think Ericsson had some brilliant visionaries doing this work, and that those people are no longer focused on Bluetooth. However, they're being incorporated into other units which can only help them overall.
It's not good news, it's not bad news. It's just news. The timing is interesting as I see Bluetooth now on the cusp of adoption by every cell phone maker for their mid- and possibly even low-end phones.
( And Michael, wi-fi is not necessarily a good replacement for Bluetooth. The higher power requirements for wi-fi mean shorter battery life, which is death for cell phones. And Bluetooth incorporates discovery protocols which are all geared toward personal networking, not internet networking. I think wi-fi would be a really chatty way to accomplish those goals, again at the expense of battery life. )
The problem in a business shop is that everyone has a day job -- crank out this code. Like most people, we'll continue to do things the same old way until someone shows us different. For example, in the early '90s when we began the migration of our business product to a Windows based platform, most of us had only briefly encountered object orientation in books and magazine articles (those of us who bothered to keep up with the trade publications, that is.) At that early time (for us), it was difficult to distinguish object oriented programming from any of the other programming "fads" of the day. For example, at that time management still thought code generators would be the magic bullet, and placed little emphasis on learning the new object oriented languages. They did not provide any encouragement to any of us to move forward professionally (although some of us did on our own, anyway.)
Recently, we brought in a consultant to help us with a large refactoring effort. I learned so much about agile programming (and not so much about refactoring) that I'm trying to figure out how to take a six-month sabbatical to go code on an agile team somewhere else just for the experience. It was really an eye-opener for me, and I think if I knew more about it, or experienced it first hand, I'd love to get it in house. More than anything, the consultant reopened my eyes to seeing what else is going on out there, over and above the daily grind.
But that's not the common viewpoint of many of the developers -- they just want to come in, write their code, and then go home to play softball or drink beer. It's not that they're opposed to learning a new methodology or technology, they simply aren't interested in personally learning that subject and then bringing those ideas in house. They see no payoff in learning assembler, or what an IP stack is, or why it's written that way, and so they don't put the effort into it. Even though they can look to the people who have that knowledge and see how successful they are, they don't often take that initiative upon themselves.
But what's ultimately most frustrating to me is our primary software vendor partner is just as old school as anyone else I can think of. We're talking "let's write our own string library because we're ignorant of the std::string library" kind of old school. (I mean, the old saw that writing your own string class is one of the stages every newbie passes through is now 10 years old.) The reason I'm so frustrated is that they're "outside" of our daily grind, so theoretically they should be exposed to methodologies from dozens of other clients. I originally expected us to get "modern" thinking out of them, but we've ended up driving more change in their organization than they've given us.
Perhaps because when our large company had everyone taking the Meyers Briggs Personality Inventory back in the late '90s, we saw a hugely disproportionate share of introverts among the programming staff? Or perhaps it's simply because introverts tend to avoid management positions, since interacting with people is not high on their list of "things they enjoy doing"?
You fall back on anectodal "evidence" that suggests your experience of hanging around with extroverted people is somehow related to their profession, when it's much more likely you hang around extroverts because you're an extrovert yourself, and you hang around programmers because you're a programmer. Those are two separate affinities -- don't get them confused just because you share both of them.
Finally, I never called programmers "schizoid" -- you made that up from whole cloth. I also never said introverts don't have "bags of common sense", nor did I say they weren't intellectual. Common sense and introversion are unrelated. You apparently are having very a hard time distinguishing introversion from a mental disorder, and seem to either be afraid of introverts, have a distate for them, or simply make no effort to understand them.
My suggestion to you is to quit whining "stereotype, stereotype" just because someone recognized a cause and effect relationship that happens to involve people. In the field of biology, recognizing cause and effect among life forms is often called "research." That, and get out there and encourage a few shy people in some way. You seem outgoing enough, you'll probably do both of yourselves some good.
As you undoubtedly know, managing is all the drudge work. For those who don't think about it much, a manager has to schedule vacations, write reviews, hand out status reports to jittery managers of other projects, demand status reports of recalcitrant coders, praise the good guys and spank the bad ones who spend their mornings on Slashdot. They make up the on-call lists and have to listen to 50% of the people whine that they were on call last Christmas, so why did they get this Labor Day? Then, they have to memorize the handbooks that list the official columns of carrots and sticks. Somewhere in there they have to learn the technical lingo their employees toss around trying to explain their latest problems, they have to send flowers to the guy whose dad just died, and meet with half a dozen salesmen who promise to double staff productivity and end global warming if they'd just place their order. They have to keep their sense of humor, put up with crap from the arrogant technical staff, calm the neurotic director, and attend daily project meetings.
Oh, and they have to buy their senior technical staff new PCs. I mean really. 1500MHz is a crap box these days for compiles of that many lines of code. Dual Xeons at the desktops would improve productivity by a lot, position your staff for the 64-bit OS to come, and don't skimp on the RAM, SATA RAID, or the graphics cards. Besides, those junky old PCs are depreciated already, just give them to the guys in accounting, they don't need anything more than that.
Managing means keeping two dozen balls in the air simultaneously. It's not a glamour job. It's a sucky job. If you think your manager is overpaid, just think about that list above, realize that's only the visible portion of what your manager has to do, and then be really really glad it's not you.
[ I can hear Aldous Huxley's Brave New Words echoing in my ears: "I'm glad I'm a Beta. Alphas have too many responsibilities..." ]
Some are poorly organized in everything but their code (*ahem*.) A few grew up believing that an employee / employer relationship should be antagonistic; that a manager must rule their team with an iron fist. That may come from looking around at a bunch of us slacker programmers thinking "hey, why aren't they working as hard as I? If I were their manager, I'd be busting their asses 24 by 7." Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it.
In most of these cases it seems that the programmers have spent their time learning machine management skills. Those skills are completely unhelpful when it comes to working with people. The lessons you learn (for example, "the machine only does exactly what I tell it") don't work with human employees, no matter how hard you try to apply them.
Yes, management is a skill that can be learned, but I don't know any geeks that would want to spend the time, let alone actually manage. Not even for the money. Almost all the people I know who have become successful managers have never been real programmers. They were business analysts or came from completely outside the IT field.
Usually this is something I do when I'm tinkering away from my toolbox. A leatherman is a nifty thing.
For one, you can take a moto-tool and cut a straight slot in the head of the screw, then use a flat screwdriver in your new slot to remove it. This is a lot of work but on a frozen screw it's effective.
For another, you can usually grab the sides of the screw head in a pair of needlenose pliers and rotate it out. This is especially true of the hard drive lids, and is my preferred method (since I carry a needlenose on my belt.)
For another, you can sometimes wedge a flat bladed screwdriver right in between the points of the star shaped head (tipped at the appropriate angle). If the screw isn't extremely tight, this is fastest, but you run the risk of damaging the screwdriver if it is tight.
I typically loosen all the screws with the pliers first, then spin them out with a flat blade.
Finally, remember that it's just a broken old IBM DeathStar drive. You don't have to be kind to all the pieces. Use a screwdriver as a pry bar and separate the sheet-metal lid from the aluminum drive housing. Make a hole big enough for a pair of pliers to grab it and the lid will tear out of the way fairly easily. But don't be too rough or you'll shatter the disc platters and then have lots of nasty glass shards to deal with.