Posted
by
timothyon Monday July 11, 2011 @09:45PM
from the give-in-to-hegemony dept.

Evil Al writes "From the ubiquitous Verifone card terminals to the fancy Apple Store terminals, point-of-sale devices are everywhere. But does anyone know of an open terminal (with printer + Wi-Fi), preferably running Linux, that we can use to run a custom application for retail, made by a reputable manufacturer?"

Cold fusion in cells like the one used by Pons and Fleishman has been observed many times now over the last 20 years. But never (AFAIK) in a way that was predictable or controllable. Almost as though there is some unknown variable. But until we are able to predict when it will happen and how much, it isn't of much use to anybody.

Specifically cold fusion. Google Rossi and the e-cat. He says there will be a test installation done in October. It's hard to say for sure, but the guy has over $500,000 of his own money sunk into it and isn't interested in investors, so there's no obvious financial gain to be had from lying to us. His patent application was denied from the Italian patent system because he can't explain how it works.

But does anyone know of an open terminal (with printer + Wi-Fi), preferably running Linux, that we can use to run a custom application for retail, made by a reputable manufacturer?

Just curious but why does the operating system underneath it all matter? It seems the application is key and you can open source that regardless of the platform it is running on. Why not an iPod touch + card reading sled + open source app, an app that you distribute internally as an enterprise app so it doesn't need the Apple approval process that a regular app would need?

Good evening sir, if you would just swipe your card I'll have you out of here in a jiffy: The mobile POS device being a conglomeration of ipod, linksys router (dd-wrt, for extended range to reach that one corner in the back), card reader, 6 volt lantern batteries, paper clips, assorted wires in various colors, exposed circuit boards and electronics to convert serial to USB or whatever, all of this strapped together on a piece of chip-board with duct tape and thick rubber bands - Although it would look prett

Just curious but why does the operating system underneath it all matter?

Because iOS will rob you of your freedoms in ways that Bill Gates never imagined. I assume you mean "free software", as in freedom, when you say "open source". Unless of course, you don't care about freedom. There's no such thing as free software on iOS. It's incompatible with Job's EULA. I recommend getting a real OS. Free software, something less likely to screw you: in this case, Android.

Perhaps you should have read just a little bit further and learned: "an app that you distribute internally as an enterprise app doesn't need the Apple approval process that a regular app would need".

Also iOS can support open source, even for a regular app. The developer is free to give their source code to users. Users may need to register in order to load their build onto their device but that was their choice when the selected iOS as their platform. And if they prefer Android they can port the app to A

Enterprise app: "an app that you distribute internally as an enterprise app doesn't need the Apple approval process that a regular app would need"
Regular app: "Users may need to register in order to load their build onto their device but that was their choice when the selected iOS as their platform"

Note iPod touch not iPhone, phone's are a needless expense given that all that is needed is wifi. So Android phones seem to be overkill too. Pads may be too large. So what other proven comparable devices/solutions are there? I think proven device/solution is the most important point.

That is a straw man. Also misinformed, I can build and run software on a first generation iPhone and iPod touch.

And free software... ooh man do they last forever.

That is a red herring. Free software runs just fine on iOS devices. Developers are fee to give away their source code to users. However the most relevant point is that an enterprise app like the one being discussed does not have to go through the approval process required by regular apps that are distributed via Apple App Store. An enterprise app can be distributed by the company to its internal u

Bullshit. In 1993 they sold 386 and 486. You can't install any modern GNU/Linux on a 486. My 486DX had a maximum memory of 32 megs. RHEL requires 1GB per CPU core. Ubuntu requires a 1GHz P4 and 512MB. Both require 5GB of disk space. My old 486 DX had 250megs... Eventually I upgraded it to 800 megs.

Yes, you can run an older OS, but that is true with anything.

Apple hardware is well-known to last forever. They still have running useful G3 iMacs, (13 years old machines,) in my kids' elementary school.

Stuff that actually matters rarely comes out first or is even remotely available in 'open source' circles

Yeah, nobody would ever think to use one of those stupid web browser thingies since Mosaic gave their source code out to whoever wanted it. Not that there's anything important to look at on those toy webservers like CERN httpd, and if any of it was important, it certainly wasn't written in perl or php.

But hey, you've got a point, sendmail was opensource and pretty much all my email is spam.

If you intend to process credit card payments through your custom application on the point-of-sale device, you'll likely fall under the purview of the Payment Card Industry's Payment Application Data Security Standard (PCI PA-DSS) [pcisecuritystandards.org], which may require a source code audit and limit what you can have the software do. That may be no problem for you depending on your resources and intended use of your software, but it's worth keeping in mind.

For all but the largest operations though, you need no code audits or anything of the sort: Even a chain with a couple dozen stores won't even be asked to do more than fill a questionnaire claiming to follow PCI standards, which as far as software go, aren't all that difficult to follow, especially if you leave most of the credit card handling to a third party, so you aren't stuck having to deal with securing encryption keys.

In particular the vx810 Duet is a pin-pad that has it's own printer and ethernet (sadly not wireless), and can talk via an rs-232 in "semi-integrated" mode whereby only the transaction amounts and transaction numbers etc flow to the POS, everything secret (pin, debit card number, etc) is handled by the terminal.

Beyond PCI compliance, you'll have to certify with processors. They typically certify a specific combination of hardware and software for terminals, and software for POS solutions. If you do this all in an open-source environment, anyone who commits changes will break certification for those who use it, and there you go.

Where I work, you can certify in a day if you know what you are doing. We know what we are doing. YMMV with other processors, and some may exhibit a lot less urgency than you would like,

Just because you're PCI compliant, doesn't mean you are until there is a breach and it is shown that you were indeed compliant...i.e., Visa wins. The best bet is to offload that risk to a processor as much as humanly possible.

Also, wifi + credit cards = lame. Really, really lame. Please don't do that...also, ipsec is nice when you can get it. SSL is not the greatest thing since sliced bread.

But does anyone know of an open terminal (with printer + Wi-Fi), preferably running Linux, that we can use to run a custom application for retail, made by a reputable manufacturer?

But no mention of it needing to be handheld. Sure, a handheld POS is nifty and all, but it does make it that much more complicated. Really if someone is just establishing a retail setup a POS in a static location would be more reliable and less expensive, which are both positive traits in the chaos of a start-up.

I saw that, but I'm wondering why it is in the title and not the summary. The text from the submitter is short enough that he easily could have said "handheld" if that is what he wanted, but he never did. Which leaves me wondering why it is in the subject line but not in the text.

Of course, we all know that slashdot editors are perfect and never make a mistake, ever, anywhere...

Seriously, when you business relies on a machine that must work or you are losing money, everyone wants someone to turn to when it doesn't work. That someone isn't a man page or IRC channel or mailing list or whatever support for $foo GPL program here. It's a computer, not a holy war. You press buttons and it does things. When you want a computer you control, you run linux, when you want a computer that grandma can use, you give her a Mac and when you want retail system that checks people out, you run whatever OS that your POS maker asks you to.

:-) Close but no... this will not be for processing cards at all, but rather for issuing access codes for Wi-Fi. I didn't want to go into too much detail in the summary so as not to bore people; I can see why it sounds like it would be for card processing.

:-) Close but no... this will not be for processing cards at all, but rather for issuing access codes for Wi-Fi. I didn't want to go into too much detail in the summary so as not to bore people; I can see why it sounds like it would be for card processing.

Erm... Can we clarify exactly what it is you do want? Do you already have the application? Does your handheld terminal need to process cards? Read barcodes? Print things out with an inbuilt printer?

As it stands, the most obvious reading of the summary is card processing - which, as others have said, is going to give you so much trouble meeting PCI-DSS requirements that you'd be insane to even try.

Well such a POS terminal would be very handy for tax avoidance purposes, a few small changes and recompile so you can skim a percentage of sales off the top keeping them out of the tax records. Places like restaurants and cafes can get away with this sort of thing easily since it is very hard to audit waste vs sales, biggest risk is that the POS logs act as evidence of your false tax reporting.New POS terminals log every transaction which goes through them, often with no way for the owner to clear the histo

The majority of retail systems I've seen over the years run some kind of Unix or Linux. Occasionally, you see one that runs windows with a pretty touch screen, but those are few and far between. First place I would look for this kind of thing would be Alibaba. If you can think of it, you can probably find it there. Even though the ads look like shit, most of the Gold Certified wholesalers are pretty good. And you can usually get a deal when ordering multiple units. If you can't find what you want in terms o

Retail Management has been wanting a handheld register since I can't remember when. Their idea is that they can use this as a "line-buster." Well, most retailers use check lanes now, so they should just open a damned register. Self-checkout is handling a lot of the line busting. Handhelds has a certain "cool" factor that just isn't there today.

I worked for a retailer that tried to develop this on their own. It started out simple, ring a transaction. Then we had to figure out how to print a receipt.

Apple Stores will email your receipt, but I think they will also print it for you if you prefer. All their POS terminals are modified iPod Touches. The printer sits behind the Genius Bar (aka the service desk).

It seems my sarcasm is lost around here. The US is way behind the times with this credit card signature business. I can't believe it's still common. I haven't been asked to sign for years, except when visiting the US, due to chip and pin being the standard elsewhere. Even more bizarre is that it seems nobody even bothers checking the signature in the US when it is given.

Very well put. I used to work in support for a Restaurant POS company back in the mid 90's and the POS systems were sold as a complete package from the touchscreen terminals to the MS Windows workstation that was used to manage the app to change menus, set prices, update sales tax. The credit card black box ran DR-DOS and you connected via modem using PC-Anywhere to clear the credit card batches and sort out the other problems with credit cards. By and large the people who own and run a business for profit

Easy answer. WinCE and administering devices through the finicky unholy abortion that is ActiveSync.

WinCE is almost as fragmented as linux is, not as fragmented as linux's arm tree, which is a total mess, but still. Then there's ActiveSync. What I wouldn't do to avoid that. Will it see the handheld today? Will it see any handheld today? Will it remember this handheld? Will it think this handheld is some other handheld and totally confuse their settings? It really is

If done properly its still far more secure than having your credit card in your wallet and typing in your pin in a remotely public environment.

I don’t know much but I don't think intercepting the packets is hard part for hacking a banking system to get money. Its not impossible to intercept data from copper wires and they have mobile efpos machines.

I'm guess I'm pretty close to being an expert, on this--like much of Slashdot, I get paid to do this stuff.

If your payment system runs over WiFi, and if that WiFi link and your payment server/client apps also do not implement any extra security measures, then your security is screwed. Anybody with a laptop and some free software can sniff your traffic, insert extra packets, etc. God help you.

Luckily, most modern WiFi equipment supports the WPA2 standard for link-layer encryption and authentication. If you j

AML makes Linux-powered portable handheld computers with Wi-Fi and barcode scanning capability, and they'll give you their source disk with your hardware if you ask, so you can modify it as much as you like if their standard suite of applications don't suit you. You would also need to add a printer like the Epson TM-T88 and an RS232 magstripe-reader like the Unitech MS-240. For the actual card clearing, you'd probably either tie this system into your existing POS mainframe (if you have one) or you'd tie it into an Internet-based POS solution like Authorize.net, or if you are feeling ambitious, you can integrate over SSL directly with a clearing network like TSYS (formerly VisaNet / VITAL). Of course, your biggest expenditure is probably going to be paying someone to write the software to tie all this together for you (unless you can pull it all off yourself, in which case hats off to you!)

P.S.I have worked on the AML portable computers before. I have not specifically worked with the Epson printer or the Unitech magstripe reader, but both should work in conjunction with the AML unit's WiFi and serial capabilities respectively. You would probably need to custom-make a cable for the magstripe reader since the AML unit uses a non-standard RS232 connector (RJ45 if I recall correctly).

But, if you want open, SquareUp mentioned elsewhere looks to be the easiest approach- just plug it into the audio jack of any phone/tablet/whatever. Using a camera for barcode recognition is ok for very low volume transactions only though.

Back in the day we used to code inventory addons to add Intermec (http://www.intermec.com) hand-held laser barcode scanners to pre-existing mainframe inventory applications. Their kit ran MS DOS 5.0 (This was back in the 90s) and could be configured to run a terminal app to a UNIX box. They also had their own custom programming language that I vaguely remember sucked donkey balls.

These days my HTC phone costs substantially less than one of those things did, has better battery life, a bar code scanner libr

It doesn't matter what they run. I helped develop an ePoS system for a public house running on LAMP, with the ePoS terminals bought on eBay running Damn Small Linux and various brand hand-held devices with wireless networking running WinMob, accessing different addresses for their respective interfaces. One of the only times I've done work in exchange for free beer!:D

Integration of payment facilities is what tends to break "my own POS" solutions. As soon as you touch a regular payment system you'll hit the circus surrounding PCI compliance, and that's a headache in itself.

There is something new on its way, but as first talks have only started this month I don't expect anything exciting to happen for at least another 3 months. It's probably going to be 2012 before this comes out proper..

It's only common sense if it wasn't pretending that the fundamentals were sound. They are not.

Card security was designed with "card present" in mind. The moment people started using card numbers over a phone the whole model went bust. The only difference now is that thieves can steal from further away. No amount of VISA 3D can bury the problem, it's merely papering over the cracks.

I don't get why you don't just get a Vx680 or Vx820 that are coming out - you can run your own application layer on top of the software on it (making it as open as you need to be). Both PCI:DSS and PA:DSS will need to be adhered to to, of course.

I have this. If anyone is interested, visit my web site (where you won't see any mention of this specific project yet but where anyone can see who I am and what I do) and find my contact information there. I have provided my POS help and source code to a few people over the years so that they can establish POS businesses in their locations. I would submit many of the details of new things going on to Slashdot but there's no guarantee it would be published so instead I'll make a whitepaper available to anyo

You see, compiling the Linux kernel was harder than I thought. Well, not harder than I thought... it just suddenly didn't want to cooperate after my hundred times compiling the kernel. For Linux in VMWare, I had to rummage around for ages until I finally figured out that I had to include Fusion MPT, whatever the hell that was. Funny how when I searched for Symbios 53c1030 it didn't show up, although when I went to Fusion MPT there it was, staring at me happily in the face, along with its brothers the 53c1020, 53c1010, and who knows what not (Hint: It's not funny at all). And get this... when I tried to mount the iso images using the loopback, and with EFS compiled as a module and loaded, the fucking VFAT driver comes up and tries to make sense of the filesystem on the iso images. That's right, the EFS module didn't even do its fucking job, which was the whole fucking point of recompiling the kernel in the first fucking place. Worse of all, why the hell was the VFAT driver coming up? What the fuck? Don't try to be a hero, you just got yourself nuked, shitface.

So I tried going into my secret hideout - the LUKS encrypted supersecret Linux partition on my hard drive (not so secret if you just fdisk it). One thing led to another, and soon I was struggling furiously with this shitty program called mkinitrd (no doubt written by a monkey who was too busy jacking off to pay any attention to coding), which insists on making a gzipped ext2 filesystem image with your modules in it, instead of making a gzipped cpio archive, which the kernel uses. WHAT THE FUCK IS THE POINT OF PACKING MY KERNEL MODULES IN A FORMAT THAT THE KERNEL DOES NOT, REPEAT, DOES NOT, RECOGNIZE? The whole debacle wasted another 3 hours of my life, and I was still nowhere closer to getting IRIX 6.5 on my Indy.

And suddenly, up comes my shitty ext3 filesystem telling it can no longer find a superblock on so and so partition.

Fuck you, Linux.

Hope it is helpful to people considering Linux in a non hobby environment. Particularly "Don't try to be a hero, you just got yourself nuked, shitface." You can probably make yourself a macro in Emacs's Xrwqpxzzkpltk blogging module (don't use the 1.0.4pre version it's got a bug that posts all the images in ~/porn/ to your blog, stay on 1.0.1) so you don't need to type it out each time you use it and just