Are there any RFID readers supported by OpenBSD? Regards, Conor.
On Thu, 7 Aug 2008 10:46:40 +0100 This: http://www.openpcd.org/ claims to be an open design with GPL'd drivers, but this http://www.motorola.com/business/v/index.jsp?vgnextoid=1722e90e3ae95110VgnVCM100000840... should be fairly trivial to make work with OBSD, despite being a Windoze CE box as it has numerous open interfaces and claims to talk to SAP and IBM stuff ... The question of being "supported" is misleading as most of these devices will be designed to operate using standard industrial interfaces. Dhu
On Thu, Aug 7, 2008 at 1:05 PM, Duncan Patton a Campbell < Thanks Duncan, The OpenPCD is what I was hoping would work with OBSD, I just don't have access to the hardware yet to try it. On a FreeBSD host most of these just appear with ugen0 and thats about as far as it will go. I'll look into the Motorola but I'm not willing to committ to buying something that isn't going to work, however the same could be said for the OpenPCD. Although at least I know that OpenPCD will unfortunately work with something like Debian or Slackware as a last resort. If I can get the hardware to work with OpenBSD it'll just be a case then afterwards of getting librfid to work. At the moment I'm trying to get the Omnikey 5121 to work while I await the OpenPCD reader. It is not going well as one might imagine. ATB, Conor.
On Thu, 7 Aug 2008 15:14:24 +0100 You need to get the OpenPCD to talk on ucom/uplcom OR use the Moto which has RS232 and Ethernet interfaces (as well as USB) which can be used in a more conventional manner.
On Thu, 7 Aug 2008 15:14:24 +0100 I've been thinking about this, and what is needed is an economic model. Proprietary supply chains don't have a need to be able to cross-reference and check their "weight and measures" so they can tolerate a closed architecture. Notably, closed architectures can be "first to market" but cannot stay that way because they can't be "currently" (in RT) validated by more than one party, so they amount to private "money". However any commercial organization or association with more than one member should be interested in this because it will allow for multiparty validation of transactions. Also, quite frankly, I can't see a viable taxation system without such mechanisms, either.
|Eric Sandeen||Re: [PATCH] xfs: do not pass unused params to xfs_flush_pages|
|Daniel Hazelton||Re: x86: 4kstacks default|
|Rusty Russell||Re: 2.6.22-rc3-mm1|
|Jeffrey V. Merkey||Re: Versioning file system|
|Matt Mackall||Re: [RFD] Documentation/HOWTO translated into Japanese|
|gregkh||Patch "IPv6: keep route for tentative address" has been added to the 2.6.34-stable...|
|Patrick McHardy||Re: [rfc 02/13] [RFC 02/13] netfilter: nf_conntrack_sip: Add callid parser|
|Krzysztof Oledzki||Re: Error: an inet prefix is expected rather than "0/0".|
|Paul Gortmaker||[PATCH net-next 09/16] tipc: Relocate trivial link status functions to header file|
|Johannes Schindelin||[PATCH] fetch: refuse to fetch into the current branch in a non-bare repository|
|Junio C Hamano||Re: [PATCH] http-push: making HTTP push more robust and more user-friendly|
|Oliver Kullmann||Re: how to move with history?|
|Alex Riesen||Re: git exclude patterns for directory|
|Andreas Ericsson||Re: why not TortoiseGit|
|Damien Miller||Re: Patching a SSH 'Weakness'|
|Stuart Henderson||Re: Apache Seg Fault after upgrade to 4.6 stable|
|Úlfar M. E. Johnson||installing openbsd in xen|
|Brian||CARP multicast and ADSL bridge|
|Eric Furman||Re: Defending OpenBSD Performance|
|Linux Kernel Mailing List||New device ID for sc92031 [1088:2031]|
|Linux Kernel Mailing List||drivers/acpi: use kasprintf|
|Linux Kernel Mailing List||Staging: et131x: prune all the debug code|
|Linux Kernel Mailing List||PCI: introduce pci_pcie_cap()|
|Linux Kernel Mailing List||USB: g_multi: Multifunction Composite Gadget added|