This is not an universal problem. It only occurs for those kernels with a specific function compiled in that most installations won't need
The upstream kernel includes this function on every build and it is not possible to exclude it. There is no such config option.
The only way that it won't be present in a standard install of any kernel v2.6.17 and newer is if the admin/packager explicitly jumped in to the source or build system and excluded it.
ThinkFinger does not support Authentec AES2501 hardware. Thinkfinger supports an entirely separate type of fingerprint reader, the UPEK TouchStrip. The same applies for the UPEK driver and the bioAPI stuff you link to (supports UPEK TS, does not support any authentec devices).
You can find some code online to retrieve images from the AES2501. However, as this is a swipe-type reader, the images are presented as several small chunks with varying amounts of overlap, which must be pieced together by software. I'm not aware of any code that actually performs that piecing together yet.
Assuming that you can piece the chunks together into a single smooth image, you then need code to process the fingerprint image and later on decide whether a new image matches the original or not -- this is required for fingerprint-based login and whatnot. This is not a simple problem to solve, and currently, no open source projects (that work) offer such functionality. At this point, we're way out of scope of writing kernel drivers, as you'd never do such kinds of image processing inside the kernel.
The reason that thinkfinger (an open source project for the UPEK stuff) works is because that hardware does image processing and matching in hardware, meaning that not much driver code is required, and you never get to see an image.
Just to add to this: as well as switching to dispatch-conf, remember to check out its config file (/etc/dispatch-conf.conf)
There are several options which most users will want to turn on for less hassle updating configuration files: replace-cvs, replace-wscomments, replace-unmodified
No idea where this was quoted from, although it was likely concopted from nowhere.
Either way, its (obviously) not true. The installer CD preview boots directly into a (precompiled!) graphical environment and then offers installation options at that point.
No, thats the trustees archive which has not been updated to show the latest advancements.
Try some "live" archives of the not-for-profit list and you'll find threads such as this one:
http://thread.gmane.org/gmane.linux.gentoo.nfp/265
The transfer is complete.
- You are using a recent kernel (2.6.11 includes a fix for the command filter, please upgrade...) - You have write access to/dev/cdrom - You are using cdrecord -dev=/dev/cdrom (using dev=ATAPI will *not* work) - You are using a recent cdrecord - You have an MMC-compliant cd writer. (Some of the less common ones which follow non-standard command sets will inevitably have problems at this point in time) - cdrecord must not setuid root (I think this problem may be fixed in the latest version, but make sure it is not setuid just to be sure)
If you are really getting problems after confirming that you are running a sane setup, then you should check the "dmesg" output. For any command that Linux rejects, it will print out a message the first time it rejects it. This will be in the form of something like: Unknown opcode 4d
Once you have that opcode, maybe someone will be kind enough to look it up in the SCSI specs for you and see if it can safely be permitted in the kernel command filter.
Having previously worked for a company who are one of the main distributors of Sitecom products in the UK, I can vouch that their service is very poor..
I'm suprised they even responded to the cease-and-desist request...
Under 2.6.0-test9-mm2 this driver works good for me. I am managing to download from the net at full speeds (120kb/sec), and transfer large files over my lan at 11mb/sec (which is as good as I got with the nvidia binary driver).
For an alpha driver, I think thats pretty impressive. I wasn't even expecting it to work.
However, I did read someone saying that under heavy network load, the driver did not perform as well as the nvidia binary one (he was running a FTP server or something).
Slashdot Mirror
2.6.24-r1 only solves 1 of the 2 vmsplice security issues
you need 2.6.24-r2 to solve the 2nd one
if you're still running 2.6.23 then you want 2.6.23-r8 which also solves both
ThinkFinger does not support Authentec AES2501 hardware. Thinkfinger supports an entirely separate type of fingerprint reader, the UPEK TouchStrip.
The same applies for the UPEK driver and the bioAPI stuff you link to (supports UPEK TS, does not support any authentec devices).
You can find some code online to retrieve images from the AES2501. However, as this is a swipe-type reader, the images are presented as several small chunks with varying amounts of overlap, which must be pieced together by software. I'm not aware of any code that actually performs that piecing together yet.
Assuming that you can piece the chunks together into a single smooth image, you then need code to process the fingerprint image and later on decide whether a new image matches the original or not -- this is required for fingerprint-based login and whatnot. This is not a simple problem to solve, and currently, no open source projects (that work) offer such functionality. At this point, we're way out of scope of writing kernel drivers, as you'd never do such kinds of image processing inside the kernel.
The reason that thinkfinger (an open source project for the UPEK stuff) works is because that hardware does image processing and matching in hardware, meaning that not much driver code is required, and you never get to see an image.
Just to add to this: as well as switching to dispatch-conf, remember to check out its config file (/etc/dispatch-conf.conf)
There are several options which most users will want to turn on for less hassle updating configuration files: replace-cvs, replace-wscomments, replace-unmodified
No idea where this was quoted from, although it was likely concopted from nowhere. Either way, its (obviously) not true. The installer CD preview boots directly into a (precompiled!) graphical environment and then offers installation options at that point.
The article text is confusing. There are 2 "releases" at hand.
1. Gentoo 2005.1 - a normal official release, updated packages and installation media but nothing mind-blowingly new.
2. An experimental LiveCD which boots into a graphical environment and includes an early version of the upcoming Gentoo Linux Installer.
The Installer "preview" is not included on the standard 2005.1 media.
No, thats the trustees archive which has not been updated to show the latest advancements. Try some "live" archives of the not-for-profit list and you'll find threads such as this one: http://thread.gmane.org/gmane.linux.gentoo.nfp/265
The transfer is complete.
Which two sites are these? Planet Gentoo is powered by http://www.planetplanet.org/
It should work fine, provided that:
/dev/cdrom
- You are using a recent kernel (2.6.11 includes a fix for the command filter, please upgrade...)
- You have write access to
- You are using cdrecord -dev=/dev/cdrom (using dev=ATAPI will *not* work)
- You are using a recent cdrecord
- You have an MMC-compliant cd writer. (Some of the less common ones which follow non-standard command sets will inevitably have problems at this point in time)
- cdrecord must not setuid root (I think this problem may be fixed in the latest version, but make sure it is not setuid just to be sure)
If you are really getting problems after confirming that you are running a sane setup, then you should check the "dmesg" output. For any command that Linux rejects, it will print out a message the first time it rejects it. This will be in the form of something like: Unknown opcode 4d
Once you have that opcode, maybe someone will be kind enough to look it up in the SCSI specs for you and see if it can safely be permitted in the kernel command filter.
Having previously worked for a company who are one of the main distributors of Sitecom products in the UK, I can vouch that their service is very poor..
I'm suprised they even responded to the cease-and-desist request...
Under 2.6.0-test9-mm2 this driver works good for me. I am managing to download from the net at full speeds (120kb/sec), and transfer large files over my lan at 11mb/sec (which is as good as I got with the nvidia binary driver).
For an alpha driver, I think thats pretty impressive. I wasn't even expecting it to work.
However, I did read someone saying that under heavy network load, the driver did not perform as well as the nvidia binary one (he was running a FTP server or something).