2.6.14 is out, 2.6.15 has opened.
This means that I've immediately pushed three netfilter related changesets, the
biggest (307k unified diff, roughly 10k lines of code) was nf_conntrack.
Given the specific situation that David Miller is on holidays, and we have
Arnaldo Carvalho de Melo maintaining the network stack meanwhile, Linus hasn't
accepted that huge patch in the first round, since he lacked explanation why such a monster was required.
I hope my comments will convince him that nf_conntrack really is the way to
go.... let's hope we'll have nf_conntrack mainline in one or two days.
I hope Yasuyuki (the main author behind nf_conntrack) will make a big party with his USAGI friends once that happens ;)
linuxdevices reports on OpenEZX, quote from Motorola executive
linuxdevices.com reports about
OpenEZX. In that report, it quotes Motorola's chief architect of mobile devices: Motorola had no immediate plans to support native Linux applications on its phones, in part due to carrier concerns about network health, security, and interoperability..
This is just not true. In fact, the A780 as it ships in Germany comes with a
native GPS navigation and routing application called "CoPilot". Also, since
the whole GSM stack runs on a different CPU than the Linux OS, there are no
security/interoperability/network health concerns that I could think of.
Also, I have received reports that Motorola actually distributes a Linux SDK to
selected third party vendors. Parts of those SDK's (the header files for the
EZX libraries) have actually leaked, which support the position that there is a SDK.
In many ways, the EZX phones are a combination of a traditional Neptune-based
Motorola GSM phone, plus a Linux-based PDA. Therefore, if any native Linux
apps on the PDA half could influence the 'network health' in a negative way,
then any other Neptune based phone could, too.
librfid gets native CCID support
To my surprise, Werner Koch (author of gnupg) has jumped into the 'librfid'
project by contributing his USB CCID low-end driver to it. Using this driver,
it should be possible to use librfid directly on the reader, instead of going
via OpenCT. There's nothing wrong with OpenCT, as it is the only way to
support contact-based and contactless operation at the same time. However,
for development and testing, most people don't really need that feature.
Unfortunately it only works theoretically, must be some minor difference in
device initialization that causes breakage.
Adding S/M support to libmrtd
If you've now thought about something sexual, I have to disappoint you. At
least this time I'm talking about ISO/IEC 7816-4 SM (secure messaging) ;)
For those not familiar with cryptographic smart cards: SM is similar to
what SSL/TLS do for TCP.
The code for re-formatting the 7816-4 APDU's into further levels of ASN.1,
including padding rules, encrypting, authentication, ... has become quite
complex. It's also not finished yet, and I already fear testing/debugging of