HKS's acquisition by Red Hat is probably a good thing. It gives them a bigger company behind them, allowing them to push more money into development. Hopefully they'll be competing with some of the big processing software like ICVerify.
However, it's really important that they get some more functionality in the base of the software first. Major technical limitations make CCVS a poor choice in hardcore processing environments.
I was setting this up for a client who was processing CC's pretty seriously - thousands of authentications per day. The biggest problem we ran into with CCVS was that it kept separate files for each transaction being processed. Each file would contain the transaction ID that you assign. To find any information out about a transaction, it opened every transaction file to find out the information you requested.
Meaning, simply, that the machine was coming to it's knees after a few days simply because of a poor way to store transactions. This could have been cut down to a few hits to the filesystem, had a schema as simple as naming the file after the transaction ID been implemented.
Plus we had assorted modem problems. HKS was always very helpful with us. Unfortunately, I had to replace the Linux box running CCVS with a SCO box running ICVerify before my client could really go into production mode. Yuck.
In any case, it would be very difficult to write an open source credit card processing program. Technically, all the protocols (at least most of the major ones) are pretty simple, and could be implemented quickly. The problem is that with the clearinghouses.
The clearinghouses are glad to hear that you want to develop processing software. To them, third-party processing software means money. If you want to talk to them, you pay them. Before your software is allowed to communicate with a credit card processor, it has to pass their tests to ensure that it does the right things. To get your software tested, you have to pay. Plus you typically have to license the protocols, you pay again.
Of course, it would be possible to start a company with some funding to create an open source credit card processor. But you're signing NDA's before you can see the protocol specs. They don't want that out there in the public, and they won't let you open source the code to speak their protocols.
It would still be possible to write an open source processor, by watching the serial I/O of an established processor and reverse engineering it. But then you're putting out software that the clearinghouse doesn't approve of. Which means that they can refuse to deal with a merchant until they get the appropriate software.
Which means a merchant might be denied money. Given the choice, most people will shell out the $x for a commercial, proprietary processor rather than risk losing their merchant account.
Of course, when I say "the clearinghouses", I'm only referring to the ones I've talked to. Hopefully, if they got enough mail about it, they might consider allowing open source software to talk to them. So if you want to see an open source CC processor, or care about the open source movement, you should mail the clearinghouses about this. I'd start with First Data Corp.
I thought the movie Hackers was a bit interesting. In particular, the responses of the viewing public. Most of the usage of computers and phones was contrived and Hollywood-invented glamour. Like The Net, it was much BS in an attempt to be eye candy without content. OK.
But the best part was them redboxing. They played a recording of tones and called. Simple. Effective. Best of all - realistic.
What shocked me most was the response of my friends. I went with a large group, none of them geeky. They all could relate to, and believe everything in the movie. When I asked them specifically about the redboxing scene, they all laughed at how fake it was.
Perhaps the problem is greater than just Hollywood...
Warden said Microsoft decided to include its browser in Windows and give it away for free before Netscape was formed in 1995. He called the government's contention "a chronological impossibility."
Why is it that Microoft's closing arguments sound like a bad Jon Lovitz skit from Saturday Night Live?
"Competing with Netscape? No...they're...they're competing with us! Yeah! We...uh...we had the idea weeks...no months...no...years! before Netscape even existed! Yeah, that's the ticket. We were going to ship Internet Explorer with Windows 3.1...no 3.0...no DOS. Yeah, with DOS. We even licensed Internet Explorer to Altair back then! Yeah, that's the ticket...
According to this portscan, the dreamcast supports BGP! For those of you who aren't familar with BGP, it's a policy-based routing protocol used (for instance) at the NAPs.
So does this mean that Sega is going to start selling routing cards for the dreamcast? It's good to see that someone's finally working on an internet device that isn't just a client, but an affordable router! It's high-time I got rid of that crappy Cisco we have over here and replaced it with a fine piece of networking machinery, like a Sega. I'm so happy to see a router that's not just cheap - but you can also play games on!!!
Seriously, though, it does indeed appear that your ISP is doing something silly redirecting ports. This is particularly probably since nobody else can recreate this test. Either that or Sega chose a really bad port number to bind on.
Slashdot Mirror
HKS's acquisition by Red Hat is probably a good thing. It gives them a bigger company behind them, allowing them to push more money into development. Hopefully they'll be competing with some of the big processing software like ICVerify.
However, it's really important that they get some more functionality in the base of the software first. Major technical limitations make CCVS a poor choice in hardcore processing environments.
I was setting this up for a client who was processing CC's pretty seriously - thousands of authentications per day. The biggest problem we ran into with CCVS was that it kept separate files for each transaction being processed. Each file would contain the transaction ID that you assign. To find any information out about a transaction, it opened every transaction file to find out the information you requested.
Meaning, simply, that the machine was coming to it's knees after a few days simply because of a poor way to store transactions. This could have been cut down to a few hits to the filesystem, had a schema as simple as naming the file after the transaction ID been implemented.
Plus we had assorted modem problems. HKS was always very helpful with us. Unfortunately, I had to replace the Linux box running CCVS with a SCO box running ICVerify before my client could really go into production mode. Yuck.
In any case, it would be very difficult to write an open source credit card processing program. Technically, all the protocols (at least most of the major ones) are pretty simple, and could be implemented quickly. The problem is that with the clearinghouses.
The clearinghouses are glad to hear that you want to develop processing software. To them, third-party processing software means money. If you want to talk to them, you pay them. Before your software is allowed to communicate with a credit card processor, it has to pass their tests to ensure that it does the right things. To get your software tested, you have to pay. Plus you typically have to license the protocols, you pay again.
Of course, it would be possible to start a company with some funding to create an open source credit card processor. But you're signing NDA's before you can see the protocol specs. They don't want that out there in the public, and they won't let you open source the code to speak their protocols.
It would still be possible to write an open source processor, by watching the serial I/O of an established processor and reverse engineering it. But then you're putting out software that the clearinghouse doesn't approve of. Which means that they can refuse to deal with a merchant until they get the appropriate software.
Which means a merchant might be denied money. Given the choice, most people will shell out the $x for a commercial, proprietary processor rather than risk losing their merchant account.
Of course, when I say "the clearinghouses", I'm only referring to the ones I've talked to. Hopefully, if they got enough mail about it, they might consider allowing open source software to talk to them. So if you want to see an open source CC processor, or care about the open source movement, you should mail the clearinghouses about this. I'd start with First Data Corp.
I thought the movie Hackers was a bit interesting. In particular, the responses of the viewing public. Most of the usage of computers and phones was contrived and Hollywood-invented glamour. Like The Net, it was much BS in an attempt to be eye candy without content. OK.
But the best part was them redboxing. They played a recording of tones and called. Simple. Effective. Best of all - realistic.
What shocked me most was the response of my friends. I went with a large group, none of them geeky. They all could relate to, and believe everything in the movie. When I asked them specifically about the redboxing scene, they all laughed at how fake it was.
Perhaps the problem is greater than just Hollywood...
Why is it that Microoft's closing arguments sound like a bad Jon Lovitz skit from Saturday Night Live?
"Competing with Netscape? No...they're...they're competing with us! Yeah! We...uh...we had the idea weeks...no months...no...years! before Netscape even existed! Yeah, that's the ticket. We were going to ship Internet Explorer with Windows 3.1...no 3.0...no DOS. Yeah, with DOS. We even licensed Internet Explorer to Altair back then! Yeah, that's the ticket...
According to this portscan, the dreamcast supports BGP! For those of you who aren't familar with BGP, it's a policy-based routing protocol used (for instance) at the NAPs.
So does this mean that Sega is going to start selling routing cards for the dreamcast? It's good to see that someone's finally working on an internet device that isn't just a client, but an affordable router! It's high-time I got rid of that crappy Cisco we have over here and replaced it with a fine piece of networking machinery, like a Sega. I'm so happy to see a router that's not just cheap - but you can also play games on!!!
Seriously, though, it does indeed appear that your ISP is doing something silly redirecting ports. This is particularly probably since nobody else can recreate this test. Either that or Sega chose a really bad port number to bind on.