Sharp Japan is doing the American market a disservice by not including WiFi, and also by not selling the device in the USA AT ALL.
Sharp Japan is doing the Japanese market a big service by not including WiFi, allowing Japanese users to buy their own cellular data cards (AirH, PHS, etc, with data rates at something like $20/month for 128 kbit) which are already subscribed to a cellular service.
Sharp USA will probably make different decisions. Sharp Japan has the Japanese market to think about. Please respect them for that.
I strongly agree. In meta-moderation I have a much higher bar for 'funniness' than I do in real life only because of the problem you mentioned. I was afraid my concerns about "funny" moderation being too easy to obtain were only minority concerns, but you got +5 by voicing yours. That makes me want to step forward also.
I used to get moderator points somewhat regularly, and meta-moderated somewhat regularly. But since I started raising my personal bar for 'funny' or 'unfunny' on slashdot and meta-moderating appropriately, it's been over two years since I've had moderator points. (I look at the original post in context and see if it's currently +2 Funny or +5 Funny. If it's +5 Funny, and it isn't really that funny, then I vote thumbs-down. Only problem is, I can't tell what the score was when the moderator moderated it -- maybe they took it, appropriately, to +2, and someone else overinflated it.)
Has anyone else noticed this? Have any other multiple-year slashdot users adopted a similar meta-moderation policy and noticed the same thing? (That would make this seem like some kind of unwritten slashdot policy that we should know about.) Have other multiple-year slashdot users NOT done anything unusual with "Funny" moderation, and ALSO noticed the same thing? (That would suggest that mod points really are rare now, and I'm just imagining a problem.)
(People who share my problem will probably have to post instead of moderating, for obvious reasons.)
About that "making ATMs"... yeah, it strikes me as ironic too, but keep in mind these are two completely different classes of problem, ATMs and eVoting.
In ATM transactions, the ATM machine sitting in front of you is just a terminal -- it doesn't do a lot of work. OTHER COMPANIES than Diebold, who definitely DO understand security and have their own customers' (or their customers' customers') funds on the line when security fails, have created debit network standards. There is a specific kind of protocol that must be followed to conduct a transaction. Diebold would get a standards document, and they would design their terminal to conform to those standards.
Most details of these standards are confidental, but I can share a couple of design elements that Diebold must conform to when making ATMs, which pretty-much make security idiotproof.
First, a debit transaction is request-response. The terminal takes the card, gets all the information they need from the user through various input screens, and prepares a single transaction record. They submit that transaction record. A challenge/response happens for the pin number (more on that later). Then the ATM receives a response record, which tells it to do whatever it needs to do. They don't have access to the entire customer account -- they can only communicate with the bank using specific transactions allowed by the debit network.
Second, pin numbers are handled very carefully. There is tamper-resistant hardware in all ATMs (and even in those pin-pad-on-a-stretchy-cord things you see at some cash registers) which contains some encryption key material, and some tamper detection hardware which erases that key material if it thinks it's being tampered with. As part of the ATM transaction, the server sends a 'challenge' containing more key material, and the pin pad computes the response for that pin number and sends a response. Because the raw pin number never leaves the pin pad, and because Diebold (and other companies) have to conform to specific pin pad design guidelines or...get sued or something (I'm not a lawyer)... (hypothetical) crappy software never gets the opportunity to mishandle the raw pin number.
Third, the debit network describes what transaction data can be stored (for accounting and whatnot), and what transaction data MUST NOT be stored. They have designed the protocol in such a way that it's not possible to use stored data on an ATM to submit new transactions, without breaking the standard the ATM manufacturer agreed to comply with. (and then here come the attack lawyers after the ATM manufacturer again)
For the above reasons, a long history building ATMs doesn't mean much when it comes to eVoting. In eVoting they get to design the entire system, from data storage to communication to auditing. ATM network providers never gave them that kind of power before. In the ATM world, if the terminal blows up in the middle of the business day, existing transactions aren't lost -- they still get paid -- and debit network is smart enough to rebuild the lost information without the terminal. In eVoting, if the terminal blows up in the middle of the business day votes are lost.
And the same types of alleged eVoting problems you hear about in the news -- in the banking world, vicious bank-funded attack lawyers with sharp, pointy teeth would be unleashed as soon as they were needed if these same types of problems happened here.
(*rereads to make sure the above is safe to post non-AC*) (*flips a coin*)
I work for a major credit card processor (First National Merchant Solutions) as a tech support rep for point-of-sale hardware. I do NOT work on ATM machines themselves, but I would provide support for one of those cash registers with a pin-pad-on-a-stretchy-cord. So as part of my job I have to know just enough of how the protocol works to be able to troubleshoot problems with that kind of system -- but not so much that I'm dangerous, or have to treat the information as confidential.
We use E-Gain. http://www.egain.com (We're also a bank, so we're well funded.)
New emails get a ticket ID, and you log into a web interface to download new tickets. It keeps messages for the same ticket associated together.
It also supports autoreplies, template/scripted replies, and some non-email-related things like a knowledge base, quick-message-forwarding address book, etc.
The whole point for going with a system like this, of course, is for performance monitoring, tracking, and reporting.
The $125 PCI card from Digium just connects to your telephone line as a standard telephone does -- it can only dial the same DTMF tones a normal telephone can dial, so it has no ability to spoof caller ID.
If you don't mind paying for something completely different, though, hook up an Asterisk box with some VOIP provider like Voicepulse Connect (google for it), and you can spoof caller ID, changing the spoofed number with a simple config file edit and restart of Asterisk.
"zero fundamentals"? Is Google playing for the NBA now?:-)
Google doesn't sell physical products. That doesn't mean they have "zero fundamentals". That doesn't make them inherently inferior to firms in the Dow 30 index. Otherwise, someone will have to argue that any information commodity Google can bring to the market will eventually have no value to consumers.
Has the Internet advertising market picked up THAT MUCH since the crash that we're in danger of another crash?
--Michael Spencer
Re:We need to fix this on the pay side
on
CAN-SPAM Is A Bust
·
· Score: 2, Informative
I work for a major credit card processor (First National Merchant Solutions), and I'm at work right now. This is a highly opinionated reply I'm posting here, so let me say right out in front: this opinion is mine, and may or may not be shared by my employer, First National Merchant Solutions. (I heard from a coworker that we process about 5% by volume of all Visa/Mastercard sales nationwide. We're a big company, so the disclaimer is necessary.)
I agree with the general idea of interfering with spammers' revenue streams.
I do NOT agree with the parent's proposed method, for specific reasons I'll describe. In general your proposed change would have a positive effect, making it much more difficult for anonymous businesses to accept Visa or Mastercard. It would have a much more pronounced negative effect, increasing administrative overhead for acquirers (like us) and merchants alike. The end result of this will be more fees for merchants, which hurts small mom-and-pop businesses disproportionately. ("What's this $25.00 regulatory fee on my statement? I barely do 3 transactions a month!" "Well, the Visa and Mastercard regulatory commissions meet once every six months. Usually the changes they mandate are small, and we don't need to charge our merchants to cover significant development costs, but this year...")
First, legislation is *slow*. Keep in mind legislation requiring truncation of customer account numbers on receipts has been rolled out slowly over several years. (Truncation is our industry's term for only printing the last four digits of the card number, instead of printing the entire number.) In some states' implementations of this requirement, new installations must be compliant but existing installations don't need to be made compliant for a few more *years*.
I submit that this new proposed legislation would have a similarly long roll-out, meaning spammers would likely still be using non-compliant web sites legally well into 2010.
Second, there are already mechanisms in place for stopping money laundering. Visa and Mastercard transactions are logged and monitored at every step of the chain for this kind of activity: by the issuing bank (which issued the customer card), by the association (Visa/Mastercard, responsible for funds transfer and administration of the system), and by the acquiring bank (the credit card processor, like us, who helps the merchant collect payment). Just because the information necessary to stop money laundering isn't available on the web site to consumers with no investigative authority doesn't mean the information isn't available at all. All law enforcement has to do is get the merchant to perform a sale, and they have all the information they need to track the transaction all the way back to the merchant's bank account.
So I submit my opinion that one would be unlikely to persuade lawmakers to pass this spam-unfriendly money-laundering-prevention bill, because it doesn't actually do anything significant to prevent money-laundering. You'll have to convince lawmakers to pass this on its spam-fighting merits alone.
I don't think the parent post actually understands the industry well enough to be making that kind of advice. Just like computer experts watch "hacker" movies and groan and complain about all the inaccuracies, I view the parent post as someone with good intentions and good ideas, but not enough understanding of the business to come up with a good implementation. I'd say moderate it +3 at the highest -- to someone in the industry who is sympathetic to the parent poster's cause, it just seems silly. Well-intentioned, but silly.
----------
I'd like to do more than just shoot the parent poster down, though. I want to help. If YOU conduct business with a spammer, or a business who has (deliberately or accidentally) hired a spammer for promotion, you can leverage Visa/Mastercard regulations against them. (If you're going to do business with a criminal for the sole purpose of stopping th
I work for a major credit card processor. Don't worry, I'm already at the karma cap.
Electronic credit card processing systems have an address verification service available. My company primarily uses Vital Processing Services (vitalps.com) and that system's address verification service supports checking the leading digits of the street address, as well as the billing zip code. It does this by sending an address-verification query to systems owned by whatever bank owns that card. That bank checks that query against their billing information for that customer, and reports back if some or all of the address information matches ("ZIP MATCH", "EXACT MATCH", "NO MATCH", etc.)
This address verification service only supports numeric zip codes and street addresses. If address verification is attempted against a Canadian address, the address verification system returns SYSTEM NOT AVAILABLE. (It's not available because the bank that issues that card is in a foreign country, even if someone types in a 5-digit zip code when doing the transaction.)
It's impossible for an Internet merchant to get perfect protection against fraud while accepting payment from Visa or Mastercard, but they can eliminate many of the common sources of fraud by always using a tracking shipping carrier (and getting a signature proof of delivery every time), and only shipping to an address that the address verification system indicates a match with. (If the customer is ordering an item as a gift, sending it to a different address than they receive their credit card billing statements at, best practices state the merchant should ask the customer to call their bank and "whitelist" that shipping address.)
Since many (most?) processing systems' address verification services don't support international address verification, most merchants must choose to either ship merchandise internationally without getting an address match, or to manually find the phone number for the bank that issued the card and *call them*. (Merchants who accept credit cards are given access to a system that lets them look up the first 6 digits of a Visa card or the first 11 digits of a Mastercard and find the bank that issued that card.) For small merchants, or merchants with occasional big-ticket purchases, they can take the time to personally attend to those transactions and make phone calls. For a large discount Internet superstore of some kind, though, they just don't have time to personally handle every address-mismatch.
So for convenience, they just refuse to accept cards that return a SYSTEM NOT AVAILABLE address-verification match.
That gives me an idea for an interesting use of VoIP/Asterisk: drop one of these guys into a fake extension that plays a continuous audio loop that sounds like a phone that's been sat down on the desk, with someone looking for their credit card, without tying up your phone or phone line so you can still receive calls.
Step 1: get a VoIP account from someplace like VoicePulse or Nufone.
If you use Inter-Asterisk Exchange to connect to their service ("IAX termination"), something interesting happens: even though you have only one inbound phone number, multiple calls into that number each get their own VoIP connection. So yes, 100 people could call you at the same time and saturate your Internet connection with VoIP traffic.
This also means your provider doesn't handle call waiting or anything like that for you: you need to tell Asterisk how to handle multiple calls where your phone is already busy. You can be simple and just go straight to voicemail; you can do fancy stuff like transfer to a phone queue ("All representatives of the household are currently assisting other telemarketers. Please hold, and your call will be answered in the order it was received.") or to an IVR ("If this is an emergency, press 1 to have me paged." etc) or anything you want.
Step 2: Record an audio loop of someone sitting the phone down and looking for their credit card.
Set up your Asterisk box with a special-purpose extension for recording audio from your telephone. For example:
Put that in a context that your inside telephone can access but outside callers calling in can't access, and then pick up your phone and call x732 ("REC"). You'll hear a beep -- then immediately set the phone down and play-act like you're looking for your credit card. Remember, you're going to be playing this audio in a loop, so if you say anything longer than a word or two, your target may figure out he's listening to the same thing over again.
Phone reps will probably mute the phone so you can't hear them and then do something else while they wait. If you rattle the phone, or make noises that sound like maybe you're coming back to the phone, or maybe you just bumped the phone by accident, they'll have to pay a little more attention and can't tune you out completely while they wait.
After you've got 20 or 30 minutes of audio on there, hang the phone up. Then go find the wav file in/var/lib/asterisk/sounds/ and open it in an audio editor, and trim out the beginning and end where you picked up and/or put down the phone.
Step 3: Create a 'trap' extension to park telemarketers into.
Again in a context you can access but outside callers can't, add an extension:
Use Playback instead of Background because you don't want the system to react to button presses -- you don't want them dialing their way out of your trap and back onto your phone.
Then, when you get a telemarketer call, string them along as per the parent post, and then just transfer the caller to extension 3845 (or whatever arbitrary extension number you pick) and hang up. Then your phone line is free, and the caller hears your recording in a continuous loop until they hang up.
If it's legal in your area (one-party-consent state), you could even record the call while playing that loop. Just change that part of the dialplan to something like:
exten => 3845,1,Monitor(wav,telemarketer-trap-recording) e xten => 3845,2,Playback(telemark) exten => 3845,3,Goto(2)
and then if you're bored, load the files up in an audio editor and skip to the loudest sections, to see if you caught them saying anything interesting.:-)
(I can't believe I just sat here and wrote all that. Yes, I'm at work, and I'm bored.:) )
This thing is a VoIP BEAST. It's an open source PBX which runs on Linux. This will solve your problems by connecting all of these incompatible VoIP clients, making them all seem like virtual telephones, each with their own extensions. (This is good, if you don't mind them using your bandwidth when they bounce off of your Asterisk server to communicate with each-other.)
"PBX" seems scary -- it's the same kind of system large businesses use to manage tons of phone lines, both inside their company and connecting to the outside world.
For the needs of people like you and I, don't think of it in terms of "a solution used by people with lots of phones" -- think of it in terms of the kinds of technology it uses and can connect with.
"Physical layer" stuff: with dedicated hardware it can talk to existing phones and existing phone lines. There's even a PCI card that can communicate with four T1 lines, for nearly 100 phone lines out to the telephone company. It can also do VoIP using standard interfaces like SIP, using its own unique (but open-source, not proprietary at all) interface called IAX, with existing programs like Netmeeting or MS Messenger, or with any number of Linux programs. (There's even an IAX client for my Zaurus PDA. That's not all that practical for receiving calls, but I have successfully placed phone calls with that client, over 802.11b.)
Logical stuff: each of these connections to the outside world is given a context, and you can do things with those contexts. A connection to your outside phone line will be used by unknown callers, so its context shouldn't have access to features that cost money. A connection to an inside phone is "trusted", so it should be given access to these features.
The system has something like a "dialplan", which is a rather flexible set of scripts you use to handle calls. There's a lot of room for creativity here -- you can make your system do anything you want with any call.
This is so flexible because you form your dialplan from a bunch of references to "applications", either built-in or external. Some are very simple: play this wav file, transfer to this extension, go to this voicemail box, etc; some are more complex, such as "shell out to this executable CGI-style and do whatever that executable tells you".
Asterisk also comes with a bunch of audio samples recorded by a "professional PBX voice", and many of them are saying some rather funny things, only useful for a home user. "All representatives of the household are currently assisting other telemarketers. Please hold, and you call will be answered in the order it was received."
Asterisk can email you your voicemail messages as wav files. This is a KILLER feature. But you weren't asking about voicemail, you were asking about VoIP.
Pros: VoIP BEAST. Take all your friends with VoIP clients, give them signins and extensions and voicemail, give them conference capabilities, etc. (Then they all use your bandwidth.)
Cons: Complexity. Even if all you want is a simple call routing tool to make incompatible VoIP systems talk to each other, you have to learn the entire system to make it work. This is a typical Linux problem: you have to read tons of documentation / visit forums / discuss with others to figure it out, but because it uses "real world" concepts and is designed intelligently, once you're finished you have spent 30% of your time learning the quirks of a single software package you could care less about, and 70% of your time learning about how the subject works, gaining knowledge about that field that will follow you to any other program.
(That's definitely true here: Since playing with Asterisk I've talked with professional telecom guys, and found what few terms and concepts I've learned from Asterisk definitely overlap with their "real world" stuff.)
Weird system service requirements. Some software features rely on a very high-resolution system timer, and (allegedly) can't get t
mspencer.net is a Compaq Prolinea 575. ( http://h10025.www1.hp.com/ewfrf/wc/softwareCategor y?lc=en&cc=us&product=95703 ) Pentium (P54C) 75 mhz with 88 MB RAM (8 MB soldered on the main board). It's running Linux 2.4 with pop3/smtp, dns (authoritative for 12 domains), Apache/PHP/MySQL, shell services, ftp/scp, HylaFax, and a MUD nobody uses. (Oh yeah -- and a PaintChat java servlet.) It's got a 15 GB IDE hard disk, which works just fine, but the weird Compaq BIOS reports an IDE error and requires someone hit F1 to continue when it boots. It's basically a free community server: people in a certain Internet community know they can ask me for free nonprofit web hosting or other techie help, and mspencer.net is at their service.
Its system load sometimes goes as low as 0.6, but it's usually around 2.0 or 3.0. I've seen it over 10 before, swapping like crazy. The hardware is still very stable, and even under that tremendous load it keeps months of uptime.
A page hosted on this machine has been linked from Penny Arcade's front page. (Static HTML, of course:) ) The/etc/passwd file has over 200 users. The box routes all traffic for a 640k/640k "Pro" DSL line, and its Apache service keeps on average 400k of that full./var/log/httpd/access_log grows to between 80 and 150 MB over the span of a week, before it's rotated and gzipped.
mspencer.net has successfully fought off an attempted installation of Movable Type. I think the user's complaint said something about it taking more than 60 seconds to create a page. phpBB2, however, runs acceptably.
Users still bug me for an upgrade -- I bought the upgrade hardware months ago (512 MB RAM, AthlonXP 2400+, etc etc) but haven't gotten around to moving all the services over. I guess the old box isn't dead yet, and if it ain't broke...
I'm still going to watch his movies. It really isn't that big of a deal:
* Moore is showing us things that we didn't know before, or that our media hasn't shown us before. * Moore is also *telling* us things he wants us to know, with his editing and presentation. People who watch his movies can tell the difference between facts he shows us and the messages he's communicating with those facts. * Moore is profiting from tragedy. He's saying controversial things and then making money. I don't care about that. I don't care about Michael Moore as much as I care about the things he shows us and tells us.
I hold Michael Moore to higher standards than I hold our media, because I have to pay to see his movies. He still passes any reasonable bar I have set for him.
I'm going to watch for bias and slant. The one-sided body of facts I will see in his movie has already been balanced against the one-sided body of facts I have already seen in the media. When he shows me things on video, I will believe those are true. When he shows me an image and describes it, I will take that description with a grain of salt. When he shows me video made of multiple segments cut together, I won't assume he meant those happened right after each other.
I'll just enjoy his movie, and learn some things I haven't seen in the US media yet.
This article is already down at the bottom of the main page, so maybe nobody will see this, but I work for a major credit card processor. (We're an "acquirer" -- we provide services to merchants who want to accept payment from credit cards.)
We try VERY HARD to educate our non-face-to-face merchants (MOTO, or Mail Order / Telephone Order) on fraud protection. There's an Address Verification Service available for MOTO merchants: for more fraud protection, you check the street address and zip code of where you're mailing the order. If you get a match, and nothing else looks suspicious, it's probably safe to ship the order. If you don't get a match, call the customer. If the customer claims the item is a gift, so OF COURSE the shipping address and the billing address won't match...then make the customer call their issuing bank and "whitelist" the shipping address. Then try the sale again.
Address verification is not available for foreign cards, so you're on your own there. Call the bank.
Visa and Mastercard are interested in fraud protection. If they didn't care about protecting merchants from fraud, merchants would be less likely to accept Visa/Mastercard for payment, so less money would change hands through the Visa/Mastercard payment associations. That means less interchange fees for Visa/Mastercard, and less profit for the banks who issue cards.
They also implemented CVV2/CVC2 checks, billing zip code checks for Visa, and address verification for the express purpose of protecting cardholders and merchants from fraud.
Anyway...regarding the original question:
You can identify which bank issued any Visa card (starts with a 4 and is 16 digits long) with just the first six digits of the card number. Mastercard cards (starts with a 5 and is 16 digits long) can be identified by the first 11 digits of the card number. Sort your card number list and use those assumptions to classify broad groups of card numbers according to their issuing bank.
Then get with each individual issuing bank's fraud department and report the cards. DURING BUSINESS HOURS. Keep in mind that most large banks consider debit cards (attached to a demand deposit account) and credit cards (attached to an actual debt account, whatever it's called) to be different universes, and probably have different departments for each.
Also keep in mind you might be fighting a cause that shouldn't be fought. If those sample card numbers came from a card number generator, and if the expiration date, CVV2 number, customer billing address, or other customer or card details were just made up (to make you want to buy a card number list) then you're asking issuing banks to put referral or fraud statuses on otherwise perfectly safe cards.
Expect to be treated as suspicious, and try to anticipate things that would make them nervous. For single cards, the bank can usually confirm or deny a card's matching information. That is, you read them what you think the customer name, expiration date, billing address, etc. is, and they tell you if you're right or wrong. They will NOT release the customer name to you, and they will probably not call the customer just because you ask them to.
For entire lists of cards, they probably don't want to even confirm/deny details for you. In their eyes, you might have a list of card numbers with supporting details and are trying to verify if it's a good list, by picking a card at random and seeing if the details are good (pretending to be a fine upstanding citizen reporting a single card). They may want you to fax the entire list to them. They will do their own analysis on whether the supporting details for each card number actually match, and will put referral or fraud statuses on the cards if things match. They will probably NOT let you know what action they took.
That's a lot of annoyance inflicted upon someone who is trying to do them a favor. They can't afford to be nicer though: they're (hopefully) worried about security, and need to m
I hate to sound like I'm being contrary, but I don't really know enough about the subject:
You are forgetting a key deficiency of the P4 "netburst" architecture. Its incredibly long pipeline which makes it very susceptable to cache misses. Therefore the larger the L2 cache the less of a performance hit the processor will take if it misses an instruction or two.
I just finished a Computer Architecture class at the local university. While I'll probably forget 90% of what we learned in that class in another year, I'll ask while it's fresh on my mind:
What does a long pipeline have to do with the cache hit/miss ratio?
We learned about some hypothetical five-stage-pipeline CPU in class, which is childs' play compared to the superpipelined monsters of today. However, if the same concepts still hold, a longer pipeline just increases the stall penalty.
For those who haven't yet had their heads pumped full of Computer Architecture trivia, I'll recap what little I learned in class, so the question makes sense:
A CPU is like a big assembly line. Its job is to read a bunch of instructions and execute them in order as they come down the assembly line. In an ideal world, with a program that never loops and never branches, it works JUST LIKE an assembly line, munching on instruction after instruction.
CPUs operate at a clock speed, and receive a clock pulse at regular intervals. They are supposed to be able to complete whatever work they're working on each clock cycle, so a really simple one-stage CPU would need to have a clock speed slow enough that any instruction can be completed in that length of time.
People figured out that instructions can be split into little pieces, such that these little pieces are each simpler than the whole instruction. That lets them build faster but more complex pipelined CPUs. Each pipeline stage might have some work to work on, but all pipeline stages can work at the same time.
So this means that if the pipeline is full of instructions, and every instruction uses every stage, then the CPU is performing one instruction per clock cycle. This is better than before though: these clock cycles are tiny because they just have to be big enough for these tiny fractions of an instruction. So we get the speed benefit of quick clockcycles, but we're still performing a full instruction each cycle. That's something like a 5x speedup if you have five pipeline stages!
It doesn't always really work this way though. See, instructions can depend on each other, and that causes problems. There can be dependencies like Read-After-Write, where instruction 100 does some math and puts the result in a register, like A, and instruction 101 uses the result (in A) in its own calculation. Normally that would be fine, but a pipelined CPU tries to do things at the same time.
For CPUs as simple as we talked about in class, there are two solutions: stalling and forwarding.
In forwarding, the CPU is smart and looks ahead and figures out "this instruction needs something that the previous instruction is providing", and just short-circuits the whole formal writing and reading process, and just kinda passes the answer under the table between pipeline stages. "Psst, hey M-stage, this is E-stage. I've got the answer to A if you want it..."
In stalling, the CPU realizes it NEEDS the answer to one instruction before it can do the next, so it starts wasting work units. Stages start getting commands saying "do nothing", which wastes CPU cycles. So in the example above, where instruction 101 needs something instruction 100 is still creating...suppose instruction 100 is multiplying two 256-bit floating point numbers together. Instruction 100 is going to take TONS of time to finish, so instruction 101 just gets stuck at the decode pipeline stage, sitting there tapping its feet and executing an "are we there yet" check every clock cycle. The rest of the pipeline goes unused.
That electricity has to come from someplace... in China, that means mostly oil and coal powerplants with none of the pollution controls found in the west
Stationary power plants produce more energy and less pollution than a sea of small movable engines consuming the same amount of fuel. Chinese power plants may pollute more than American power plants, but they both pollute less than mini power plants (automobile/motorcycle engines) designed for size and weight instead of efficiency.
You can eliminate more pollution with $1,000,000 worth of pollution control equipment on one power plant, then you can with a $100 worth of pollution control equipment on each of ten thousand automobiles.
There's a difference between direct copyright infringement liability and copying copyright-protected material. Search for RTC (religious technology center, a.k.a. Scientology) v Netcom. The decision in that case sets a precedent that the owner of a service cannot be liable for automated acts of reproduction. Instead there must be some volitional act -- you have to know you're doing it.
There's still contributory and vicarious infringement liability to worry about, but at least if you join a network with honest good intentions you can explain to a judge, and copyright infringement happens without your knowledge, you can't be held liable for direct copyright infringement without the judge ignoring precedent.
(If you're profiting from looking the other way and running a node with no other legal uses, that's vicarious copyright infringement. If you're materially contributing to infringement but not actually doing it yourself, and you know (or should reasonably know) it's happening, that's contributory copyright infringement.)
The bottom line here is: the law gives legal protection from automated acts of copyright infringement to ISPs, so they can continue to operate. We need to assume that sometime in the future, lawmakers are going to try to stop that body of law from being used to benefit home users on a filesharing network.
To do that, they are going to codify in law the difference between an ISP (with paying customers), a "volunteer ISP" (with nonpaying, anonymous customers, whatever it ends up being called), and a normal home user. Then they're going to have to explain to their fellow lawmakers why they are giving freedoms and granting exclusions for one class of citizen (including Cox Communications) but not for another class of citizen (including you and I).
I don't think they can make it illegal to start an ISP. I have to be able to go out to some little hick town in the middle of nowhere and set up a microwave relay and be a small-business ISP. If I can do that, I can set up an 802.11b repeater on my roof and be a free ISP for my neighbors. If I can do that, I can set up a virtual service using only my Internet connection that gives people "real Internet access" when they only have "cable modem web access". (That last one means: I'm a VPN, I'm enabling filtered ports, etc.) If I can do that, I can participate in one of these filesharing networks.
To forbid these filesharing networks they need to be able to draw the line in there somewhere, and codify that line with precise language in law.
I am not a lawyer, but one of my emails on this subject was featured in a slashdot article long ago. (Protecting Clients: Legal Implications of Filesharing Network Design) Check my posting history.
I'm sorry but do Google text ads bother you that much? I actually find them useful and have wound up buying a few products from them. If you don't like them are they that hard to ignore? I don't recall ever seeing a Google text ad popping up with "Smack the Monkey and win $50!" in a flashing javascript banner that causes epileptic seizures.
I don't see any reason to block Google ads. They are useful and (more to the point) they provide pretty much the sole revenue stream to our favorite company. Why the hell would you block them?
I think some peoples' problem with advertisement on the Internet is that we like to see content chosen based on merit. If person A likes something person B wrote, they shouldn't care whether person B has money to pay for advertising, has a Ph.D., is the manager of a company, or otherwise is a "better person". We like to see ideas and content chosen on their own merit.
When an site plugs a commercial product (say, Penny Arcade talking about a new game they're playing), perhaps even including a referral program link to buy the product with, that still passes the "merit" bar that some people find important. The author of that content has personally reviewed the product they're linking, and feels it has enough merit to warrant introducing it to their readers.
Google's text (or new image) ads blur the line: they are based indirectly on the content of the site one is viewing, but the strength of the advertisers' voice is determined by how much money they have, not by how many people value their information.
Some people are annoyed with ads when they are distracting. Some people are annoyed with ads when they are irrelevant. Yet more people are annoyed with ads when they are bought with money instead of being earned based on merit.
Not all of those reasons apply to all people. People are different, and we should respect that, even when we don't understand why.
I know the guy (Mark A Miller) being described in this article. I use IRC mostly as a contact list, and have a channel for users of my unremarkable non-profit server. Mark has been a regular in my small (under 20 people) channel for months. I know this is the same guy as the Mark Miller in this article because the user in my channel talked incessantly about these freedom of information act requests, months ago.
[04/13 00:16] <@Mirell[Mobile]> Ah. [04/13 00:17] <@Mirell[Mobile]> District Attorney Office. Forgot to go by that. [04/13 00:17] <@dyfrgi> Why do you want/need to? [04/13 00:17] <@Mirell[Mobile]> To file a writ of mandumus against UT Austin. [04/13 00:18] <@Mirell[Mobile]> They are ignoring one of my open records request. [04/13 00:18] <@Mirell[Mobile]> To find out how much they pay for their Internet service. [04/13 00:18] <@mspencer> "one of"? [04/13 00:18] <@Mirell[Mobile]> Okay, several of. [04/13 00:18] <@Mirell[Mobile]> They initiall complied. [04/13 00:19] <@Mirell[Mobile]> Now they're ignoring me hoping I'll go away. [04/13 00:19] <@mspencer> I'm surprised you've filed even one open records request, let alone several. [04/13 00:19] <@mspencer> What are you using the data for? [04/13 00:19] <@Mirell[Mobile]> Er? [04/13 00:19] <@Mirell[Mobile]> Why are you suprised? [04/13 00:20] <@mspencer> I mean, as long as you're being adult about it, and making sure your need for the data is worth the time they need to put into filling those requests. [04/13 00:20] <@dyfrgi> Writ of Mandumus? [04/13 00:20] <@Mirell[Mobile]> mspencer, [04/13 00:20] <@mspencer> So what are you using the data for? [04/13 00:20] <@Mirell[Mobile]> To satiate my curiousity. [04/13 00:21] <@Mirell[Mobile]> I'm not sure if that's how you spell it, dyfrgi. [04/13 00:21] <@mspencer> Do you think those requests are having any kind of negative effect on the University or its staff? [04/13 00:21] <@dyfrgi> I'm just wondering what it is. [04/13 00:22] <@Mirell[Mobile]> Let's see...I requested initially any contracts or invoices detailing the cost the University entails in gaining Internet connectivity. [04/13 00:22] <@dyfrgi> Mm. I assume you want to file a petition for a writ of madamus. [04/13 00:22] <@Mirell[Mobile]> Then I filed another one for something they withheld on an invoice. [04/13 00:22] <@Mirell[Mobile]> Then another one for another thing they left out.. [04/13 00:22] <@Mirell[Mobile]> Then one about the UT Classroom Web Cams they deny knowledge of [04/13 00:23] <@Mirell[Mobile]> Then one about the UT Information Security Council briefs, since we had the Social Security Number scare. [04/13 00:24] <@Mirell[Mobile]> And I'm not at all sure what you are trying to say by "Negative Affect" when they have a position who's sole purpose is to manage Open Records Requests. [04/13 00:25] <@dyfrgi> I think he is implying that you should not ask, because it costs money for them to tell you. [04/13 00:25] <@mspencer> I was deliberately vague: any effect, emotional or financial or otherwise, that is more significant than the benefit you get from satisfying your curiosity. [04/13 00:26] <@Mirell[Mobile]> No. [04/13 00:26] <@mspencer> hopefully there isn't one, but if there is, I'd like to think you considered that. [04/13 00:26] <@bl0d> i dunno, i'd really be curious about the Webcam one...that's just fucked up... [04/13 00:26] <@mspencer> Ah, OK then. [04/13 00:26] <@Mirell[Mobile]> http://www.dailytexanonline.com/main.cfm?include=d etail&storyid=620962 [04/13 00:27] <@Mirell[Mobile]> They pull crap like this as well. [04/13 00:27] <@Mirell[Mobile]> And this: http://www.dailytexanonline.com/main.cfm?include=d etail&storyid=657367 [04/13 00:27] <@Mirell[
Also remember that for DC circuits, V = I * R. (V is voltage, I is current or amperage, and R is resistance) This is why you can connect something to a power supply capable of delivering 450 watts, but only use 150 watts: the resistance of the circuit, combined with the voltage, determines the current flowing through the circuit. If the circuit "wanted to", it could select how much current it used by dialing its resistance up and down. If the circuit's resistance is so low that V=I*R means the power supply must deliver 10000 watts, but the power supply is only capable of delivering 10 watts, then the supply's voltage will sag (as described in the parent).
The parent poster almost definitely knows all this, but I thought some readers might understand this better if it were spelled out.
If the resistance in the human body doesn't change, then you need to double the voltage in order to double the current.
People who say 'high voltage is dangerous' are correct. You can't push high current through a human body without high voltage.
People who say it's not the voltage but the current that kills you are also correct -- but that statement by itself is misleading. Different bodies have different internal resistance, and conditions for death are indicated by current, not voltage. A power source entering the body through dry fingertips needs a much higher voltage to reach 100 mA. A power source entering the body through metal rods piercing the chest cavity, just barely on either side of the heart, need a much lower voltage to reach 100 mA.
Again, all sides of this conversation are technically correct, but perhaps not everybody reading this understood why.
(I am not an EE, but my brain has been severely warped by a technical writing course last semester. I think about the average reader FAR too much now.)
(If that isn't easy to understand, keep in mind it's section 12 of a long HOWTO with lots of conceptual material. If you start reading from the beginning, and skip sections that don't involve your problem, everything should start making sense.)
For example:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
police rate 640kbit buffer 10k drop \
flowid:1
This adds a simple filter rule that limits inbound traffic to 640 kbit/sec and drops matching *outbound* traffic to slow down inbound traffic. You don't have to do the whole line at once: this is class-based and the above example assumes only one class, so you could add several classes, one for each user, and make them borrow from each other when others' classes aren't maxed out. (Just don't make them 'bounded' or 'isolated' and you get this borrowing for free.)
What would the end result of this be? If you set up seven queues (using u32 filters on each rule to match each individual user) all underneath one parent queue representing the entire downstream pipe then you get some interesting and fair behavior:
Suppose you have a max line speed of around 70 KB/sec, and seven active users. Six are well-behaved, doing one HTTP file download each, and the seventh is running as many filesharing clients as he possibly can. Each user would notice about 10 KB/sec download speed on their download. (If one user's download wasn't capable of going any faster, then maybe the other guys would borrow his spare KB/sec and go a bit faster, until he downloaded something else that used all of his allocation.) The badly-behaved filesharing user, though, might be attempting 30 downloads at once. He'd still be getting 10 KB/sec across all of the connections though. The other endpoints of his connections may be trying to send him faster than 10 KB/sec, but traffic policing will notice this is over his limit and will cut off his acks to match. So this one user may notice an 80% frame loss rate and almost useless web browsing, but everyone else will have pretty much normal service.
And the best part is: when things aren't busy any more, this "partitioning" of bandwidth just neatly gets out of your way and shares any unused classes with other users. So at 4 AM this filesharing user might get 70 KB/sec across all of his downloads. But if someone pops on to check their mail, this user's downloads will get pushed down to make room for the new user.
Another thing to keep in mind: for these filters to work well, you need to give them some overhead. If your actual linespeed is 640 kbit/sec, set the filters to a max of 620 kbit/sec. This way it can detect and act upon overlimit conditions before inbound and outbound queues start filling up. If you set the ingress filter to a max which is the same as your line speed, you won't be able to detect when people are sending packets faster than you can receive them: your ISP will be helpfully buffering your packets in an inbound queue and adding tons of latency.
So to recap: this ingress policing will work for you too. You'll have to learn the weird way these filters work -- but they're very powerful. As with most learning in Linux, half of the documentation-reading work is bringing you up to speed with the universal concepts needed to understand what you want to do, and the other half is understanding how those concepts translate into this specific bit of software.
So if the person who posed the original question is more familiar with Linux than with your OS, it sounds like they can accomplish the same thing with Linux. No need to force someone to switch just yet.:-)
OK, here's the text of my paper, for those of you who don't want to click a link.:)
Traffic Conditioning For Inexpensive Installations
Business-Class Performance From Free Software and Commodity
Hardware
By Michael Spencer
Broadband internet connections don't handle heavy server loads
very well. When many
connections are in contention for the same limited upstream
bandwidth, problems occur
that degrade overall link performance. I have found a solution
that can be implemented
with inexpensive software on existing hardware, which sustains
reasonable performance
ever under extremely heavy load. I will describe the problems
that occur when dozens of
connections all compete for bandwidth, offer some possible
theoretical solutions, and
then describe an implementation in detail that solves these
problems.
Before I talk about the problem, you might want to know if the
solution is reasonable.
My proposed solution only works well if your upstream bandwidth
is constant. If you
have a home DSL connection with a fixed upstream rate, this
solution is ideal. If you
share a university or company internet connection, and you don't
actually administer the
university or company connection, this solution won't work well
for you. Cable modem
users might or might not work, depending on whether or not their
upstream is fixed in
hardware, or simply shares whatever is left over after all other
users are done with it.
My proposed solution uses advanced networking features in the 2.4
series Linux kernel.
You will need to have a Linux machine responsible for routing all
Internet-bound traffic
to your border router (cable modem, DSL modem, etc.). The ideal
way to do this is to
put two network interfaces in a dedicated machine. One interface
is on the local network
segment, and one interface leads directly to the border router.
Not everyone has this kind of hardware just laying around, so it
may be possible to
implement this solution even if your linux machine and border
router share the same
network segment with the rest of your network, or even if you
only have one machine
connected to your border router (or your border router is a card
installed inside your
machine).
If you only have one network segment but you already have a
dedicated Linux machine
on the network, it may be possible to reconfigure your network so
all traffic must pass
through the Linux machine. That is the configuration I use at
home, and my sample
configuration detailed below assumes this.
If you only have one computer connected via ethernet to a border
router, or if your border
router is a card installed inside your computer, you may still be
able to use this technique.
VMware Incorporated sells a virtual machine monitor called VMware
($100 for a
personal or educational license, $300 for a commercial license).
You can create a limited
Linux virtual machine with VMware and bind that to the network
interface your Internet
connection is on. Then configure the VMware machine to
communicate directly with the
border gateway, and configure your desktop computer to use the
VMware machine as its
default gateway. You will need to leave VMware running at all
times when you need to
use the Internet, but VMware can be configured to use as little
as 16 MB of memory and
very little CPU time.
Once you have a Linux machine between your border router and your
network, you will
need to add support for several advanced options to your Linux
machine. You will
probably need to recompile your kernel with support for the
experimental Shaper device,
as well as several items in QoS and/or fair queuing:
the CBQ and SFQ packet
schedulers, the U32 classifier, and Traffic Policing. These
options can be found under
Networking Options in the kernel configuration
program.
It's difficult to understand, much less set up, but essentially the stuff from this site can solve your problem by tightly controlling outbound traffic (since it is possible to have perfect control over what packets you release to the network) and by loosely attempting to control inbound traffic (since it isn't really possible to perfectly control what packets other people send you).
For example, my home setup has four priority classes:
Class 0:10 is for high priority traffic: ping replies, TCP ACK packets, and online gaming.
Class 0:20 is for everything not otherwise classified.
Class 0:30 is for BitTorrent traffic -- lower than normal, but higher than all the other p2p stuff. I do this because BitTorrent traffic is very likely to be directly related to a file I'm personally interested in.
Class 0:40 is for lowprio.mspencer.net and other misc filesharing programs. If the rest of the Internet connection is busy, class 0:40 ends up with around 24 kbit/sec out of my total 640 kbit/sec upstream.
I guarantee you can adapt this as needed, so each user has a fair slice of upstream available, but if someone's not using their slice then everybody else can split it. (So at 4 AM one user can still get the whole line speed, but at peak usage everybody gets the same bandwidth.)
The other side of the coin is ingress policing. I don't have a lot of experience with this, but you'll almost definitely need it. Basically the policing module tries to slow inbound packets by throttling the outbound acknowledgements. It's not perfect but it can help.
Some filesharing programs incorrectly state they are "firewalled" when you use a setup like this. Instruct the user to just tell his client to retest so it can confirm he's not firewalled.
My final paper for my 4000/8000 level networking class was regarding my traffic shaper. Maybe it'll help.
...and then I realize, I answered a different question than you asked. Drat. All of that would be obvious if you had TCP/IP to begin with - that's the part you're missing.
OK, if anyone else wants to provide a solution: all he really needs is TCP/IP. His 400 doesn't need anything special on top of that (since the advice I gave is probably obvious to him), so any ISP solution should work.
And I apparently don't know how to read a question before answering. Yay.:)
Slashdot Mirror
Sharp Japan is doing the American market a disservice by not including WiFi, and also by not selling the device in the USA AT ALL.
Sharp Japan is doing the Japanese market a big service by not including WiFi, allowing Japanese users to buy their own cellular data cards (AirH, PHS, etc, with data rates at something like $20/month for 128 kbit) which are already subscribed to a cellular service.
Sharp USA will probably make different decisions. Sharp Japan has the Japanese market to think about. Please respect them for that.
I strongly agree. In meta-moderation I have a much higher bar for 'funniness' than I do in real life only because of the problem you mentioned. I was afraid my concerns about "funny" moderation being too easy to obtain were only minority concerns, but you got +5 by voicing yours. That makes me want to step forward also.
I used to get moderator points somewhat regularly, and meta-moderated somewhat regularly. But since I started raising my personal bar for 'funny' or 'unfunny' on slashdot and meta-moderating appropriately, it's been over two years since I've had moderator points. (I look at the original post in context and see if it's currently +2 Funny or +5 Funny. If it's +5 Funny, and it isn't really that funny, then I vote thumbs-down. Only problem is, I can't tell what the score was when the moderator moderated it -- maybe they took it, appropriately, to +2, and someone else overinflated it.)
Has anyone else noticed this? Have any other multiple-year slashdot users adopted a similar meta-moderation policy and noticed the same thing? (That would make this seem like some kind of unwritten slashdot policy that we should know about.) Have other multiple-year slashdot users NOT done anything unusual with "Funny" moderation, and ALSO noticed the same thing? (That would suggest that mod points really are rare now, and I'm just imagining a problem.)
(People who share my problem will probably have to post instead of moderating, for obvious reasons.)
--Michael Spencer
About that "making ATMs"... yeah, it strikes me as ironic too, but keep in mind these are two completely different classes of problem, ATMs and eVoting.
In ATM transactions, the ATM machine sitting in front of you is just a terminal -- it doesn't do a lot of work. OTHER COMPANIES than Diebold, who definitely DO understand security and have their own customers' (or their customers' customers') funds on the line when security fails, have created debit network standards. There is a specific kind of protocol that must be followed to conduct a transaction. Diebold would get a standards document, and they would design their terminal to conform to those standards.
Most details of these standards are confidental, but I can share a couple of design elements that Diebold must conform to when making ATMs, which pretty-much make security idiotproof.
First, a debit transaction is request-response. The terminal takes the card, gets all the information they need from the user through various input screens, and prepares a single transaction record. They submit that transaction record. A challenge/response happens for the pin number (more on that later). Then the ATM receives a response record, which tells it to do whatever it needs to do. They don't have access to the entire customer account -- they can only communicate with the bank using specific transactions allowed by the debit network.
Second, pin numbers are handled very carefully. There is tamper-resistant hardware in all ATMs (and even in those pin-pad-on-a-stretchy-cord things you see at some cash registers) which contains some encryption key material, and some tamper detection hardware which erases that key material if it thinks it's being tampered with. As part of the ATM transaction, the server sends a 'challenge' containing more key material, and the pin pad computes the response for that pin number and sends a response. Because the raw pin number never leaves the pin pad, and because Diebold (and other companies) have to conform to specific pin pad design guidelines or...get sued or something (I'm not a lawyer)... (hypothetical) crappy software never gets the opportunity to mishandle the raw pin number.
Third, the debit network describes what transaction data can be stored (for accounting and whatnot), and what transaction data MUST NOT be stored. They have designed the protocol in such a way that it's not possible to use stored data on an ATM to submit new transactions, without breaking the standard the ATM manufacturer agreed to comply with. (and then here come the attack lawyers after the ATM manufacturer again)
For the above reasons, a long history building ATMs doesn't mean much when it comes to eVoting. In eVoting they get to design the entire system, from data storage to communication to auditing. ATM network providers never gave them that kind of power before. In the ATM world, if the terminal blows up in the middle of the business day, existing transactions aren't lost -- they still get paid -- and debit network is smart enough to rebuild the lost information without the terminal. In eVoting, if the terminal blows up in the middle of the business day votes are lost.
And the same types of alleged eVoting problems you hear about in the news -- in the banking world, vicious bank-funded attack lawyers with sharp, pointy teeth would be unleashed as soon as they were needed if these same types of problems happened here.
(*rereads to make sure the above is safe to post non-AC*) (*flips a coin*)
I work for a major credit card processor (First National Merchant Solutions) as a tech support rep for point-of-sale hardware. I do NOT work on ATM machines themselves, but I would provide support for one of those cash registers with a pin-pad-on-a-stretchy-cord. So as part of my job I have to know just enough of how the protocol works to be able to troubleshoot problems with that kind of system -- but not so much that I'm dangerous, or have to treat the information as confidential.
We use E-Gain. http://www.egain.com (We're also a bank, so we're well funded.)
New emails get a ticket ID, and you log into a web interface to download new tickets. It keeps messages for the same ticket associated together.
It also supports autoreplies, template/scripted replies, and some non-email-related things like a knowledge base, quick-message-forwarding address book, etc.
The whole point for going with a system like this, of course, is for performance monitoring, tracking, and reporting.
--Michael Spencer
So laptops with integrated wifi and hostap software are OK then?
The $125 PCI card from Digium just connects to your telephone line as a standard telephone does -- it can only dial the same DTMF tones a normal telephone can dial, so it has no ability to spoof caller ID.
:)
If you don't mind paying for something completely different, though, hook up an Asterisk box with some VOIP provider like Voicepulse Connect (google for it), and you can spoof caller ID, changing the spoofed number with a simple config file edit and restart of Asterisk.
So you were mostly right.
--Michael Spencer
"zero fundamentals"? Is Google playing for the NBA now? :-)
Google doesn't sell physical products. That doesn't mean they have "zero fundamentals". That doesn't make them inherently inferior to firms in the Dow 30 index. Otherwise, someone will have to argue that any information commodity Google can bring to the market will eventually have no value to consumers.
Has the Internet advertising market picked up THAT MUCH since the crash that we're in danger of another crash?
--Michael Spencer
I work for a major credit card processor (First National Merchant Solutions), and I'm at work right now. This is a highly opinionated reply I'm posting here, so let me say right out in front: this opinion is mine, and may or may not be shared by my employer, First National Merchant Solutions. (I heard from a coworker that we process about 5% by volume of all Visa/Mastercard sales nationwide. We're a big company, so the disclaimer is necessary.)
I agree with the general idea of interfering with spammers' revenue streams.
I do NOT agree with the parent's proposed method, for specific reasons I'll describe. In general your proposed change would have a positive effect, making it much more difficult for anonymous businesses to accept Visa or Mastercard. It would have a much more pronounced negative effect, increasing administrative overhead for acquirers (like us) and merchants alike. The end result of this will be more fees for merchants, which hurts small mom-and-pop businesses disproportionately. ("What's this $25.00 regulatory fee on my statement? I barely do 3 transactions a month!" "Well, the Visa and Mastercard regulatory commissions meet once every six months. Usually the changes they mandate are small, and we don't need to charge our merchants to cover significant development costs, but this year...")
First, legislation is *slow*. Keep in mind legislation requiring truncation of customer account numbers on receipts has been rolled out slowly over several years. (Truncation is our industry's term for only printing the last four digits of the card number, instead of printing the entire number.) In some states' implementations of this requirement, new installations must be compliant but existing installations don't need to be made compliant for a few more *years*.
I submit that this new proposed legislation would have a similarly long roll-out, meaning spammers would likely still be using non-compliant web sites legally well into 2010.
Second, there are already mechanisms in place for stopping money laundering. Visa and Mastercard transactions are logged and monitored at every step of the chain for this kind of activity: by the issuing bank (which issued the customer card), by the association (Visa/Mastercard, responsible for funds transfer and administration of the system), and by the acquiring bank (the credit card processor, like us, who helps the merchant collect payment). Just because the information necessary to stop money laundering isn't available on the web site to consumers with no investigative authority doesn't mean the information isn't available at all. All law enforcement has to do is get the merchant to perform a sale, and they have all the information they need to track the transaction all the way back to the merchant's bank account.
So I submit my opinion that one would be unlikely to persuade lawmakers to pass this spam-unfriendly money-laundering-prevention bill, because it doesn't actually do anything significant to prevent money-laundering. You'll have to convince lawmakers to pass this on its spam-fighting merits alone.
I don't think the parent post actually understands the industry well enough to be making that kind of advice. Just like computer experts watch "hacker" movies and groan and complain about all the inaccuracies, I view the parent post as someone with good intentions and good ideas, but not enough understanding of the business to come up with a good implementation. I'd say moderate it +3 at the highest -- to someone in the industry who is sympathetic to the parent poster's cause, it just seems silly. Well-intentioned, but silly.
----------
I'd like to do more than just shoot the parent poster down, though. I want to help. If YOU conduct business with a spammer, or a business who has (deliberately or accidentally) hired a spammer for promotion, you can leverage Visa/Mastercard regulations against them. (If you're going to do business with a criminal for the sole purpose of stopping th
I work for a major credit card processor. Don't worry, I'm already at the karma cap.
Electronic credit card processing systems have an address verification service available. My company primarily uses Vital Processing Services (vitalps.com) and that system's address verification service supports checking the leading digits of the street address, as well as the billing zip code. It does this by sending an address-verification query to systems owned by whatever bank owns that card. That bank checks that query against their billing information for that customer, and reports back if some or all of the address information matches ("ZIP MATCH", "EXACT MATCH", "NO MATCH", etc.)
This address verification service only supports numeric zip codes and street addresses. If address verification is attempted against a Canadian address, the address verification system returns SYSTEM NOT AVAILABLE. (It's not available because the bank that issues that card is in a foreign country, even if someone types in a 5-digit zip code when doing the transaction.)
It's impossible for an Internet merchant to get perfect protection against fraud while accepting payment from Visa or Mastercard, but they can eliminate many of the common sources of fraud by always using a tracking shipping carrier (and getting a signature proof of delivery every time), and only shipping to an address that the address verification system indicates a match with. (If the customer is ordering an item as a gift, sending it to a different address than they receive their credit card billing statements at, best practices state the merchant should ask the customer to call their bank and "whitelist" that shipping address.)
Since many (most?) processing systems' address verification services don't support international address verification, most merchants must choose to either ship merchandise internationally without getting an address match, or to manually find the phone number for the bank that issued the card and *call them*. (Merchants who accept credit cards are given access to a system that lets them look up the first 6 digits of a Visa card or the first 11 digits of a Mastercard and find the bank that issued that card.) For small merchants, or merchants with occasional big-ticket purchases, they can take the time to personally attend to those transactions and make phone calls. For a large discount Internet superstore of some kind, though, they just don't have time to personally handle every address-mismatch.
So for convenience, they just refuse to accept cards that return a SYSTEM NOT AVAILABLE address-verification match.
--Michael Spencer
That gives me an idea for an interesting use of VoIP/Asterisk: drop one of these guys into a fake extension that plays a continuous audio loop that sounds like a phone that's been sat down on the desk, with someone looking for their credit card, without tying up your phone or phone line so you can still receive calls.
/var/lib/asterisk/sounds/ and open it in an audio editor, and trim out the beginning and end where you picked up and/or put down the phone.
e xten => 3845,2,Playback(telemark)
:-)
:) )
Step 1: get a VoIP account from someplace like VoicePulse or Nufone.
If you use Inter-Asterisk Exchange to connect to their service ("IAX termination"), something interesting happens: even though you have only one inbound phone number, multiple calls into that number each get their own VoIP connection. So yes, 100 people could call you at the same time and saturate your Internet connection with VoIP traffic.
This also means your provider doesn't handle call waiting or anything like that for you: you need to tell Asterisk how to handle multiple calls where your phone is already busy. You can be simple and just go straight to voicemail; you can do fancy stuff like transfer to a phone queue ("All representatives of the household are currently assisting other telemarketers. Please hold, and your call will be answered in the order it was received.") or to an IVR ("If this is an emergency, press 1 to have me paged." etc) or anything you want.
Step 2: Record an audio loop of someone sitting the phone down and looking for their credit card.
Set up your Asterisk box with a special-purpose extension for recording audio from your telephone. For example:
exten => 732,1,Wait(1)
exten => 732,2,Record(telemark:wav|0|0)
exten => 732,3,Hangup
Put that in a context that your inside telephone can access but outside callers calling in can't access, and then pick up your phone and call x732 ("REC"). You'll hear a beep -- then immediately set the phone down and play-act like you're looking for your credit card. Remember, you're going to be playing this audio in a loop, so if you say anything longer than a word or two, your target may figure out he's listening to the same thing over again.
Phone reps will probably mute the phone so you can't hear them and then do something else while they wait. If you rattle the phone, or make noises that sound like maybe you're coming back to the phone, or maybe you just bumped the phone by accident, they'll have to pay a little more attention and can't tune you out completely while they wait.
After you've got 20 or 30 minutes of audio on there, hang the phone up. Then go find the wav file in
Step 3: Create a 'trap' extension to park telemarketers into.
Again in a context you can access but outside callers can't, add an extension:
exten => 3845,1,Playback(telemark)
exten => 3845,2,Goto(1)
Use Playback instead of Background because you don't want the system to react to button presses -- you don't want them dialing their way out of your trap and back onto your phone.
Then, when you get a telemarketer call, string them along as per the parent post, and then just transfer the caller to extension 3845 (or whatever arbitrary extension number you pick) and hang up. Then your phone line is free, and the caller hears your recording in a continuous loop until they hang up.
If it's legal in your area (one-party-consent state), you could even record the call while playing that loop. Just change that part of the dialplan to something like:
exten => 3845,1,Monitor(wav,telemarketer-trap-recording)
exten => 3845,3,Goto(2)
and then if you're bored, load the files up in an audio editor and skip to the loudest sections, to see if you caught them saying anything interesting.
(I can't believe I just sat here and wrote all that. Yes, I'm at work, and I'm bored.
Have fun!
--Michael Spencer
Archive.org is blocked by the bank's web filter where I work. Can someone put up a mirror on another domain?
www.asterisk.org
This thing is a VoIP BEAST. It's an open source PBX which runs on Linux. This will solve your problems by connecting all of these incompatible VoIP clients, making them all seem like virtual telephones, each with their own extensions. (This is good, if you don't mind them using your bandwidth when they bounce off of your Asterisk server to communicate with each-other.)
"PBX" seems scary -- it's the same kind of system large businesses use to manage tons of phone lines, both inside their company and connecting to the outside world.
For the needs of people like you and I, don't think of it in terms of "a solution used by people with lots of phones" -- think of it in terms of the kinds of technology it uses and can connect with.
"Physical layer" stuff: with dedicated hardware it can talk to existing phones and existing phone lines. There's even a PCI card that can communicate with four T1 lines, for nearly 100 phone lines out to the telephone company. It can also do VoIP using standard interfaces like SIP, using its own unique (but open-source, not proprietary at all) interface called IAX, with existing programs like Netmeeting or MS Messenger, or with any number of Linux programs. (There's even an IAX client for my Zaurus PDA. That's not all that practical for receiving calls, but I have successfully placed phone calls with that client, over 802.11b.)
Logical stuff: each of these connections to the outside world is given a context, and you can do things with those contexts. A connection to your outside phone line will be used by unknown callers, so its context shouldn't have access to features that cost money. A connection to an inside phone is "trusted", so it should be given access to these features.
The system has something like a "dialplan", which is a rather flexible set of scripts you use to handle calls. There's a lot of room for creativity here -- you can make your system do anything you want with any call.
This is so flexible because you form your dialplan from a bunch of references to "applications", either built-in or external. Some are very simple: play this wav file, transfer to this extension, go to this voicemail box, etc; some are more complex, such as "shell out to this executable CGI-style and do whatever that executable tells you".
Asterisk also comes with a bunch of audio samples recorded by a "professional PBX voice", and many of them are saying some rather funny things, only useful for a home user. "All representatives of the household are currently assisting other telemarketers. Please hold, and you call will be answered in the order it was received."
Asterisk can email you your voicemail messages as wav files. This is a KILLER feature. But you weren't asking about voicemail, you were asking about VoIP.
Pros: VoIP BEAST. Take all your friends with VoIP clients, give them signins and extensions and voicemail, give them conference capabilities, etc. (Then they all use your bandwidth.)
Cons: Complexity. Even if all you want is a simple call routing tool to make incompatible VoIP systems talk to each other, you have to learn the entire system to make it work. This is a typical Linux problem: you have to read tons of documentation / visit forums / discuss with others to figure it out, but because it uses "real world" concepts and is designed intelligently, once you're finished you have spent 30% of your time learning the quirks of a single software package you could care less about, and 70% of your time learning about how the subject works, gaining knowledge about that field that will follow you to any other program.
(That's definitely true here: Since playing with Asterisk I've talked with professional telecom guys, and found what few terms and concepts I've learned from Asterisk definitely overlap with their "real world" stuff.)
Weird system service requirements. Some software features rely on a very high-resolution system timer, and (allegedly) can't get t
mspencer.net is a Compaq Prolinea 575. ( http://h10025.www1.hp.com/ewfrf/wc/softwareCategor y?lc=en&cc=us&product=95703 ) Pentium (P54C) 75 mhz with 88 MB RAM (8 MB soldered on the main board). It's running Linux 2.4 with pop3/smtp, dns (authoritative for 12 domains), Apache/PHP/MySQL, shell services, ftp/scp, HylaFax, and a MUD nobody uses. (Oh yeah -- and a PaintChat java servlet.) It's got a 15 GB IDE hard disk, which works just fine, but the weird Compaq BIOS reports an IDE error and requires someone hit F1 to continue when it boots. It's basically a free community server: people in a certain Internet community know they can ask me for free nonprofit web hosting or other techie help, and mspencer.net is at their service.
:) ) The /etc/passwd file has over 200 users. The box routes all traffic for a 640k/640k "Pro" DSL line, and its Apache service keeps on average 400k of that full. /var/log/httpd/access_log grows to between 80 and 150 MB over the span of a week, before it's rotated and gzipped.
Its system load sometimes goes as low as 0.6, but it's usually around 2.0 or 3.0. I've seen it over 10 before, swapping like crazy. The hardware is still very stable, and even under that tremendous load it keeps months of uptime.
A page hosted on this machine has been linked from Penny Arcade's front page. (Static HTML, of course
mspencer.net has successfully fought off an attempted installation of Movable Type. I think the user's complaint said something about it taking more than 60 seconds to create a page. phpBB2, however, runs acceptably.
Users still bug me for an upgrade -- I bought the upgrade hardware months ago (512 MB RAM, AthlonXP 2400+, etc etc) but haven't gotten around to moving all the services over. I guess the old box isn't dead yet, and if it ain't broke...
--Michael Spencer
Thanks for that link.
I'm still going to watch his movies. It really isn't that big of a deal:
* Moore is showing us things that we didn't know before, or that our media hasn't shown us before.
* Moore is also *telling* us things he wants us to know, with his editing and presentation. People who watch his movies can tell the difference between facts he shows us and the messages he's communicating with those facts.
* Moore is profiting from tragedy. He's saying controversial things and then making money. I don't care about that. I don't care about Michael Moore as much as I care about the things he shows us and tells us.
I hold Michael Moore to higher standards than I hold our media, because I have to pay to see his movies. He still passes any reasonable bar I have set for him.
I'm going to watch for bias and slant. The one-sided body of facts I will see in his movie has already been balanced against the one-sided body of facts I have already seen in the media. When he shows me things on video, I will believe those are true. When he shows me an image and describes it, I will take that description with a grain of salt. When he shows me video made of multiple segments cut together, I won't assume he meant those happened right after each other.
I'll just enjoy his movie, and learn some things I haven't seen in the US media yet.
--Michael Spencer
This article is already down at the bottom of the main page, so maybe nobody will see this, but I work for a major credit card processor. (We're an "acquirer" -- we provide services to merchants who want to accept payment from credit cards.)
We try VERY HARD to educate our non-face-to-face merchants (MOTO, or Mail Order / Telephone Order) on fraud protection. There's an Address Verification Service available for MOTO merchants: for more fraud protection, you check the street address and zip code of where you're mailing the order. If you get a match, and nothing else looks suspicious, it's probably safe to ship the order. If you don't get a match, call the customer. If the customer claims the item is a gift, so OF COURSE the shipping address and the billing address won't match...then make the customer call their issuing bank and "whitelist" the shipping address. Then try the sale again.
Address verification is not available for foreign cards, so you're on your own there. Call the bank.
Visa and Mastercard are interested in fraud protection. If they didn't care about protecting merchants from fraud, merchants would be less likely to accept Visa/Mastercard for payment, so less money would change hands through the Visa/Mastercard payment associations. That means less interchange fees for Visa/Mastercard, and less profit for the banks who issue cards.
They also implemented CVV2/CVC2 checks, billing zip code checks for Visa, and address verification for the express purpose of protecting cardholders and merchants from fraud.
Anyway...regarding the original question:
You can identify which bank issued any Visa card (starts with a 4 and is 16 digits long) with just the first six digits of the card number. Mastercard cards (starts with a 5 and is 16 digits long) can be identified by the first 11 digits of the card number. Sort your card number list and use those assumptions to classify broad groups of card numbers according to their issuing bank.
Then get with each individual issuing bank's fraud department and report the cards. DURING BUSINESS HOURS. Keep in mind that most large banks consider debit cards (attached to a demand deposit account) and credit cards (attached to an actual debt account, whatever it's called) to be different universes, and probably have different departments for each.
Also keep in mind you might be fighting a cause that shouldn't be fought. If those sample card numbers came from a card number generator, and if the expiration date, CVV2 number, customer billing address, or other customer or card details were just made up (to make you want to buy a card number list) then you're asking issuing banks to put referral or fraud statuses on otherwise perfectly safe cards.
Expect to be treated as suspicious, and try to anticipate things that would make them nervous. For single cards, the bank can usually confirm or deny a card's matching information. That is, you read them what you think the customer name, expiration date, billing address, etc. is, and they tell you if you're right or wrong. They will NOT release the customer name to you, and they will probably not call the customer just because you ask them to.
For entire lists of cards, they probably don't want to even confirm/deny details for you. In their eyes, you might have a list of card numbers with supporting details and are trying to verify if it's a good list, by picking a card at random and seeing if the details are good (pretending to be a fine upstanding citizen reporting a single card). They may want you to fax the entire list to them. They will do their own analysis on whether the supporting details for each card number actually match, and will put referral or fraud statuses on the cards if things match. They will probably NOT let you know what action they took.
That's a lot of annoyance inflicted upon someone who is trying to do them a favor. They can't afford to be nicer though: they're (hopefully) worried about security, and need to m
I hate to sound like I'm being contrary, but I don't really know enough about the subject:
You are forgetting a key deficiency of the P4 "netburst" architecture. Its incredibly long pipeline which makes it very susceptable to cache misses. Therefore the larger the L2 cache the less of a performance hit the processor will take if it misses an instruction or two.
I just finished a Computer Architecture class at the local university. While I'll probably forget 90% of what we learned in that class in another year, I'll ask while it's fresh on my mind:
What does a long pipeline have to do with the cache hit/miss ratio?
We learned about some hypothetical five-stage-pipeline CPU in class, which is childs' play compared to the superpipelined monsters of today. However, if the same concepts still hold, a longer pipeline just increases the stall penalty.
For those who haven't yet had their heads pumped full of Computer Architecture trivia, I'll recap what little I learned in class, so the question makes sense:
A CPU is like a big assembly line. Its job is to read a bunch of instructions and execute them in order as they come down the assembly line. In an ideal world, with a program that never loops and never branches, it works JUST LIKE an assembly line, munching on instruction after instruction.
CPUs operate at a clock speed, and receive a clock pulse at regular intervals. They are supposed to be able to complete whatever work they're working on each clock cycle, so a really simple one-stage CPU would need to have a clock speed slow enough that any instruction can be completed in that length of time.
People figured out that instructions can be split into little pieces, such that these little pieces are each simpler than the whole instruction. That lets them build faster but more complex pipelined CPUs. Each pipeline stage might have some work to work on, but all pipeline stages can work at the same time.
So this means that if the pipeline is full of instructions, and every instruction uses every stage, then the CPU is performing one instruction per clock cycle. This is better than before though: these clock cycles are tiny because they just have to be big enough for these tiny fractions of an instruction. So we get the speed benefit of quick clockcycles, but we're still performing a full instruction each cycle. That's something like a 5x speedup if you have five pipeline stages!
It doesn't always really work this way though. See, instructions can depend on each other, and that causes problems. There can be dependencies like Read-After-Write, where instruction 100 does some math and puts the result in a register, like A, and instruction 101 uses the result (in A) in its own calculation. Normally that would be fine, but a pipelined CPU tries to do things at the same time.
For CPUs as simple as we talked about in class, there are two solutions: stalling and forwarding.
In forwarding, the CPU is smart and looks ahead and figures out "this instruction needs something that the previous instruction is providing", and just short-circuits the whole formal writing and reading process, and just kinda passes the answer under the table between pipeline stages. "Psst, hey M-stage, this is E-stage. I've got the answer to A if you want it..."
In stalling, the CPU realizes it NEEDS the answer to one instruction before it can do the next, so it starts wasting work units. Stages start getting commands saying "do nothing", which wastes CPU cycles. So in the example above, where instruction 101 needs something instruction 100 is still creating...suppose instruction 100 is multiplying two 256-bit floating point numbers together. Instruction 100 is going to take TONS of time to finish, so instruction 101 just gets stuck at the decode pipeline stage, sitting there tapping its feet and executing an "are we there yet" check every clock cycle. The rest of the pipeline goes unused.
For my next trick, I'll tie
That electricity has to come from someplace... in China, that means mostly oil and coal powerplants with none of the pollution controls found in the west
Stationary power plants produce more energy and less pollution than a sea of small movable engines consuming the same amount of fuel. Chinese power plants may pollute more than American power plants, but they both pollute less than mini power plants (automobile/motorcycle engines) designed for size and weight instead of efficiency.
You can eliminate more pollution with $1,000,000 worth of pollution control equipment on one power plant, then you can with a $100 worth of pollution control equipment on each of ten thousand automobiles.
There's a difference between direct copyright infringement liability and copying copyright-protected material. Search for RTC (religious technology center, a.k.a. Scientology) v Netcom. The decision in that case sets a precedent that the owner of a service cannot be liable for automated acts of reproduction. Instead there must be some volitional act -- you have to know you're doing it.
There's still contributory and vicarious infringement liability to worry about, but at least if you join a network with honest good intentions you can explain to a judge, and copyright infringement happens without your knowledge, you can't be held liable for direct copyright infringement without the judge ignoring precedent.
(If you're profiting from looking the other way and running a node with no other legal uses, that's vicarious copyright infringement. If you're materially contributing to infringement but not actually doing it yourself, and you know (or should reasonably know) it's happening, that's contributory copyright infringement.)
The bottom line here is: the law gives legal protection from automated acts of copyright infringement to ISPs, so they can continue to operate. We need to assume that sometime in the future, lawmakers are going to try to stop that body of law from being used to benefit home users on a filesharing network.
To do that, they are going to codify in law the difference between an ISP (with paying customers), a "volunteer ISP" (with nonpaying, anonymous customers, whatever it ends up being called), and a normal home user. Then they're going to have to explain to their fellow lawmakers why they are giving freedoms and granting exclusions for one class of citizen (including Cox Communications) but not for another class of citizen (including you and I).
I don't think they can make it illegal to start an ISP. I have to be able to go out to some little hick town in the middle of nowhere and set up a microwave relay and be a small-business ISP. If I can do that, I can set up an 802.11b repeater on my roof and be a free ISP for my neighbors. If I can do that, I can set up a virtual service using only my Internet connection that gives people "real Internet access" when they only have "cable modem web access". (That last one means: I'm a VPN, I'm enabling filtered ports, etc.) If I can do that, I can participate in one of these filesharing networks.
To forbid these filesharing networks they need to be able to draw the line in there somewhere, and codify that line with precise language in law.
I am not a lawyer, but one of my emails on this subject was featured in a slashdot article long ago. (Protecting Clients: Legal Implications of Filesharing Network Design) Check my posting history.
--Michael Spencer
I'm sorry but do Google text ads bother you that much? I actually find them useful and have wound up buying a few products from them. If you don't like them are they that hard to ignore? I don't recall ever seeing a Google text ad popping up with "Smack the Monkey and win $50!" in a flashing javascript banner that causes epileptic seizures.
I don't see any reason to block Google ads. They are useful and (more to the point) they provide pretty much the sole revenue stream to our favorite company. Why the hell would you block them?
I think some peoples' problem with advertisement on the Internet is that we like to see content chosen based on merit. If person A likes something person B wrote, they shouldn't care whether person B has money to pay for advertising, has a Ph.D., is the manager of a company, or otherwise is a "better person". We like to see ideas and content chosen on their own merit.
When an site plugs a commercial product (say, Penny Arcade talking about a new game they're playing), perhaps even including a referral program link to buy the product with, that still passes the "merit" bar that some people find important. The author of that content has personally reviewed the product they're linking, and feels it has enough merit to warrant introducing it to their readers.
Google's text (or new image) ads blur the line: they are based indirectly on the content of the site one is viewing, but the strength of the advertisers' voice is determined by how much money they have, not by how many people value their information.
Some people are annoyed with ads when they are distracting. Some people are annoyed with ads when they are irrelevant. Yet more people are annoyed with ads when they are bought with money instead of being earned based on merit.
Not all of those reasons apply to all people. People are different, and we should respect that, even when we don't understand why.
I know the guy (Mark A Miller) being described in this article. I use IRC mostly as a contact list, and have a channel for users of my unremarkable non-profit server. Mark has been a regular in my small (under 20 people) channel for months. I know this is the same guy as the Mark Miller in this article because the user in my channel talked incessantly about these freedom of information act requests, months ago.
[04/13 00:16] <@Mirell[Mobile]> Ah.
[04/13 00:17] <@Mirell[Mobile]> District Attorney Office. Forgot to go by that.
[04/13 00:17] <@dyfrgi> Why do you want/need to?
[04/13 00:17] <@Mirell[Mobile]> To file a writ of mandumus against UT Austin.
[04/13 00:18] <@Mirell[Mobile]> They are ignoring one of my open records request.
[04/13 00:18] <@Mirell[Mobile]> To find out how much they pay for their Internet service.
[04/13 00:18] <@mspencer> "one of"?
[04/13 00:18] <@Mirell[Mobile]> Okay, several of.
[04/13 00:18] <@Mirell[Mobile]> They initiall complied.
[04/13 00:19] <@Mirell[Mobile]> Now they're ignoring me hoping I'll go away.
[04/13 00:19] <@mspencer> I'm surprised you've filed even one open records request, let alone several.
[04/13 00:19] <@mspencer> What are you using the data for?
[04/13 00:19] <@Mirell[Mobile]> Er?
[04/13 00:19] <@Mirell[Mobile]> Why are you suprised?
[04/13 00:20] <@mspencer> I mean, as long as you're being adult about it, and making sure your need for the data is worth the time they need to put into filling those requests.
[04/13 00:20] <@dyfrgi> Writ of Mandumus?
[04/13 00:20] <@Mirell[Mobile]> mspencer,
[04/13 00:20] <@mspencer> So what are you using the data for?
[04/13 00:20] <@Mirell[Mobile]> To satiate my curiousity.
[04/13 00:21] <@Mirell[Mobile]> I'm not sure if that's how you spell it, dyfrgi.
[04/13 00:21] <@mspencer> Do you think those requests are having any kind of negative effect on the University or its staff?
[04/13 00:21] <@dyfrgi> I'm just wondering what it is.
[04/13 00:22] <@Mirell[Mobile]> Let's see...I requested initially any contracts or invoices detailing the cost the University entails in gaining Internet connectivity.
[04/13 00:22] <@dyfrgi> Mm. I assume you want to file a petition for a writ of madamus.
[04/13 00:22] <@Mirell[Mobile]> Then I filed another one for something they withheld on an invoice.
[04/13 00:22] <@Mirell[Mobile]> Then another one for another thing they left out..
[04/13 00:22] <@Mirell[Mobile]> Then one about the UT Classroom Web Cams they deny knowledge of
[04/13 00:23] <@Mirell[Mobile]> Then one about the UT Information Security Council briefs, since we had the Social Security Number scare.
[04/13 00:24] <@Mirell[Mobile]> And I'm not at all sure what you are trying to say by "Negative Affect" when they have a position who's sole purpose is to manage Open Records Requests.
[04/13 00:25] <@dyfrgi> I think he is implying that you should not ask, because it costs money for them to tell you.
[04/13 00:25] <@mspencer> I was deliberately vague: any effect, emotional or financial or otherwise, that is more significant than the benefit you get from satisfying your curiosity.
[04/13 00:26] <@Mirell[Mobile]> No.
[04/13 00:26] <@mspencer> hopefully there isn't one, but if there is, I'd like to think you considered that.
[04/13 00:26] <@bl0d> i dunno, i'd really be curious about the Webcam one...that's just fucked up...
[04/13 00:26] <@mspencer> Ah, OK then.
[04/13 00:26] <@Mirell[Mobile]> http://www.dailytexanonline.com/main.cfm?include=d etail&storyid=620962
[04/13 00:27] <@Mirell[Mobile]> They pull crap like this as well.
[04/13 00:27] <@Mirell[Mobile]> And this: http://www.dailytexanonline.com/main.cfm?include=d etail&storyid=657367
[04/13 00:27] <@Mirell[
Also remember that for DC circuits, V = I * R. (V is voltage, I is current or amperage, and R is resistance) This is why you can connect something to a power supply capable of delivering 450 watts, but only use 150 watts: the resistance of the circuit, combined with the voltage, determines the current flowing through the circuit. If the circuit "wanted to", it could select how much current it used by dialing its resistance up and down. If the circuit's resistance is so low that V=I*R means the power supply must deliver 10000 watts, but the power supply is only capable of delivering 10 watts, then the supply's voltage will sag (as described in the parent).
The parent poster almost definitely knows all this, but I thought some readers might understand this better if it were spelled out.
If the resistance in the human body doesn't change, then you need to double the voltage in order to double the current.
People who say 'high voltage is dangerous' are correct. You can't push high current through a human body without high voltage.
People who say it's not the voltage but the current that kills you are also correct -- but that statement by itself is misleading. Different bodies have different internal resistance, and conditions for death are indicated by current, not voltage. A power source entering the body through dry fingertips needs a much higher voltage to reach 100 mA. A power source entering the body through metal rods piercing the chest cavity, just barely on either side of the heart, need a much lower voltage to reach 100 mA.
Again, all sides of this conversation are technically correct, but perhaps not everybody reading this understood why.
(I am not an EE, but my brain has been severely warped by a technical writing course last semester. I think about the average reader FAR too much now.)
--Michael Spencer
I know what you mean, but I also wanted to let everyone know with my original post that ingress policing under Linux solves this problem.
h tml
:1
:-)
http://lartc.org/howto/lartc.adv-filter.policing.
(If that isn't easy to understand, keep in mind it's section 12 of a long HOWTO with lots of conceptual material. If you start reading from the beginning, and skip sections that don't involve your problem, everything should start making sense.)
For example:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
police rate 640kbit buffer 10k drop \
flowid
This adds a simple filter rule that limits inbound traffic to 640 kbit/sec and drops matching *outbound* traffic to slow down inbound traffic. You don't have to do the whole line at once: this is class-based and the above example assumes only one class, so you could add several classes, one for each user, and make them borrow from each other when others' classes aren't maxed out. (Just don't make them 'bounded' or 'isolated' and you get this borrowing for free.)
What would the end result of this be? If you set up seven queues (using u32 filters on each rule to match each individual user) all underneath one parent queue representing the entire downstream pipe then you get some interesting and fair behavior:
Suppose you have a max line speed of around 70 KB/sec, and seven active users. Six are well-behaved, doing one HTTP file download each, and the seventh is running as many filesharing clients as he possibly can. Each user would notice about 10 KB/sec download speed on their download. (If one user's download wasn't capable of going any faster, then maybe the other guys would borrow his spare KB/sec and go a bit faster, until he downloaded something else that used all of his allocation.) The badly-behaved filesharing user, though, might be attempting 30 downloads at once. He'd still be getting 10 KB/sec across all of the connections though. The other endpoints of his connections may be trying to send him faster than 10 KB/sec, but traffic policing will notice this is over his limit and will cut off his acks to match. So this one user may notice an 80% frame loss rate and almost useless web browsing, but everyone else will have pretty much normal service.
And the best part is: when things aren't busy any more, this "partitioning" of bandwidth just neatly gets out of your way and shares any unused classes with other users. So at 4 AM this filesharing user might get 70 KB/sec across all of his downloads. But if someone pops on to check their mail, this user's downloads will get pushed down to make room for the new user.
Another thing to keep in mind: for these filters to work well, you need to give them some overhead. If your actual linespeed is 640 kbit/sec, set the filters to a max of 620 kbit/sec. This way it can detect and act upon overlimit conditions before inbound and outbound queues start filling up. If you set the ingress filter to a max which is the same as your line speed, you won't be able to detect when people are sending packets faster than you can receive them: your ISP will be helpfully buffering your packets in an inbound queue and adding tons of latency.
So to recap: this ingress policing will work for you too. You'll have to learn the weird way these filters work -- but they're very powerful. As with most learning in Linux, half of the documentation-reading work is bringing you up to speed with the universal concepts needed to understand what you want to do, and the other half is understanding how those concepts translate into this specific bit of software.
So if the person who posed the original question is more familiar with Linux than with your OS, it sounds like they can accomplish the same thing with Linux. No need to force someone to switch just yet.
--Michael Spencer
Traffic Conditioning For Inexpensive Installations
Business-Class Performance From Free Software and Commodity Hardware
By Michael Spencer
Broadband internet connections don't handle heavy server loads very well. When many
connections are in contention for the same limited upstream bandwidth, problems occur
that degrade overall link performance. I have found a solution that can be implemented
with inexpensive software on existing hardware, which sustains reasonable performance
ever under extremely heavy load. I will describe the problems that occur when dozens of
connections all compete for bandwidth, offer some possible theoretical solutions, and
then describe an implementation in detail that solves these problems.
Before I talk about the problem, you might want to know if the solution is reasonable.
My proposed solution only works well if your upstream bandwidth is constant. If you
have a home DSL connection with a fixed upstream rate, this solution is ideal. If you
share a university or company internet connection, and you don't actually administer the
university or company connection, this solution won't work well for you. Cable modem
users might or might not work, depending on whether or not their upstream is fixed in
hardware, or simply shares whatever is left over after all other users are done with it.
My proposed solution uses advanced networking features in the 2.4 series Linux kernel.
You will need to have a Linux machine responsible for routing all Internet-bound traffic
to your border router (cable modem, DSL modem, etc.). The ideal way to do this is to
put two network interfaces in a dedicated machine. One interface is on the local network
segment, and one interface leads directly to the border router.
Not everyone has this kind of hardware just laying around, so it may be possible to
implement this solution even if your linux machine and border router share the same
network segment with the rest of your network, or even if you only have one machine
connected to your border router (or your border router is a card installed inside your
machine).
If you only have one network segment but you already have a dedicated Linux machine
on the network, it may be possible to reconfigure your network so all traffic must pass
through the Linux machine. That is the configuration I use at home, and my sample
configuration detailed below assumes this.
If you only have one computer connected via ethernet to a border router, or if your border
router is a card installed inside your computer, you may still be able to use this technique.
VMware Incorporated sells a virtual machine monitor called VMware ($100 for a
personal or educational license, $300 for a commercial license). You can create a limited
Linux virtual machine with VMware and bind that to the network interface your Internet
connection is on. Then configure the VMware machine to communicate directly with the
border gateway, and configure your desktop computer to use the VMware machine as its
default gateway. You will need to leave VMware running at all times when you need to
use the Internet, but VMware can be configured to use as little as 16 MB of memory and
very little CPU time.
Once you have a Linux machine between your border router and your network, you will
need to add support for several advanced options to your Linux machine. You will
probably need to recompile your kernel with support for the experimental Shaper device,
as well as several items in QoS and/or fair queuing: the CBQ and SFQ packet
schedulers, the U32 classifier, and Traffic Policing. These options can be found under
Networking Options in the kernel configuration program.
You will also nee
http://lartc.org
It's difficult to understand, much less set up, but essentially the stuff from this site can solve your problem by tightly controlling outbound traffic (since it is possible to have perfect control over what packets you release to the network) and by loosely attempting to control inbound traffic (since it isn't really possible to perfectly control what packets other people send you).
For example, my home setup has four priority classes:
Class 0:10 is for high priority traffic: ping replies, TCP ACK packets, and online gaming.
Class 0:20 is for everything not otherwise classified.
Class 0:30 is for BitTorrent traffic -- lower than normal, but higher than all the other p2p stuff. I do this because BitTorrent traffic is very likely to be directly related to a file I'm personally interested in.
Class 0:40 is for lowprio.mspencer.net and other misc filesharing programs. If the rest of the Internet connection is busy, class 0:40 ends up with around 24 kbit/sec out of my total 640 kbit/sec upstream.
I guarantee you can adapt this as needed, so each user has a fair slice of upstream available, but if someone's not using their slice then everybody else can split it. (So at 4 AM one user can still get the whole line speed, but at peak usage everybody gets the same bandwidth.)
The other side of the coin is ingress policing. I don't have a lot of experience with this, but you'll almost definitely need it. Basically the policing module tries to slow inbound packets by throttling the outbound acknowledgements. It's not perfect but it can help.
Some filesharing programs incorrectly state they are "firewalled" when you use a setup like this. Instruct the user to just tell his client to retest so it can confirm he's not firewalled.
My final paper for my 4000/8000 level networking class was regarding my traffic shaper. Maybe it'll help.
http://mspencer.net/traffic-shaper.doc in Word 2000 format.
http://mspencer.net/traffic-shaper.txt in plain text.
--Michael Spencer
...and then I realize, I answered a different question than you asked. Drat. All of that would be obvious if you had TCP/IP to begin with - that's the part you're missing.
:)
OK, if anyone else wants to provide a solution: all he really needs is TCP/IP. His 400 doesn't need anything special on top of that (since the advice I gave is probably obvious to him), so any ISP solution should work.
And I apparently don't know how to read a question before answering. Yay.