I don't know if the community actually has/had the opportunity to do all the required changes to the N900 even if they wanted to. For example, until PR1.2 which came out in Spring 2010, I couldn't even reload the credit on my phone's SIM because the N900's phone application (or modem stack) didn't bother to implement the required USSD support. The only thing the community *could* do was what it did: release a crappy homescreen applet that might or might not work. (I just swapped my SIM card into my old 20€ cellphone for which the N900 was a replacement...) Couldn't actually change the phone/modem software, because there's no source for it to edit. At least that's how I understood it, and which I found to be quite pathetic. (Which I think is such a shame, it could've been such a nice platform, and it mostly, but not quite, is too)
Implementing AES directly in the chip makes implementing AES in userspace also less vulnerable to cache-based side-channel attacks against AES. Also note that there has been work to use these AES instructions in implementing (some of the) candidates of SHA-3 (http://crypto.rd.francetelecom.com/sha3/AES/)
Actually, you can apparently use larger Mersenne Primes to improve results in totally different but very useful fields, like privacy-related schemes. For example, this paper http://eccc.hpi-web.de/eccc-reports/2006/TR06-127/index.html uses large Mersenne primes to get interesting results on Locally Decodable Codes and Private Information Retrieval Schemes...
Actually, the problem lies not with KDE. The core KDE Libraries are actually LGPL (parts even use some BSD license), which should be pretty compatible with the GPLv3. Just like many KDE programs are actually GPLv2+. The 'problem' is that as of yet, Qt has been licensed under GPLv2 only (and slightly more, they allow linking with a selection of other free software licenses as well, as far as I know). Which in turn makes all KDE applications linking with Qt GPLv2 at run-time. The obvious reason would be that Trolltech just does not really like giving the FSF full controll over their Qt software through their ability to modify future versions of the GPL at will.
Won't this create some undesired mess? I'd rather like to have at least some visual diversity between them. After all, concurrent development inspires progress.
Visual diversity may indeed inspire progress because there would be more competition, but it's not very desirable. Developpers may like it, but if you want to show a desktop with 2 different themes, people who are used to see a consistent interface will be scared (or at least not be impressed) by it.
Not only will most people think it's ugly, but also requires extra configuration: with two independant themes, changing the KDE theme doesn't change the theme for GTK applications, resulting in confusion. And confusion isn't good when trying to impress people with Linux.
This doesn't make the UI look inconsistent at all: the 'plastik theme' is not a GUI for OOo, but rather an example of how OOo looks like when themed like KDE can be themed. This makes your desktop look nice and integrated, whereas with a 'united' OOo theme, your perfectly skinned desktop would look inconsistent and out of balance while running OOo: every application you run looks the same, except OOo.
Also, it's not like OOo has different UIs. There is just one UI, but it can be themed differently (as shown).
IANAL, but I think, that when they want to use their 'trade secrets' to win this battle, it is a wise choice not to reveal the code. Because (if I understand it correctly) if they would reveal this code publicly to show they are right, they would lose their trade secrets (as they're not a secret anymore)
Slashdot Mirror
I don't know if the community actually has/had the opportunity to do all the required changes to the N900 even if they wanted to. For example, until PR1.2 which came out in Spring 2010, I couldn't even reload the credit on my phone's SIM because the N900's phone application (or modem stack) didn't bother to implement the required USSD support. The only thing the community *could* do was what it did: release a crappy homescreen applet that might or might not work. (I just swapped my SIM card into my old 20€ cellphone for which the N900 was a replacement...) Couldn't actually change the phone/modem software, because there's no source for it to edit. At least that's how I understood it, and which I found to be quite pathetic. (Which I think is such a shame, it could've been such a nice platform, and it mostly, but not quite, is too)
Implementing AES directly in the chip makes implementing AES in userspace also less vulnerable to cache-based side-channel attacks against AES. Also note that there has been work to use these AES instructions in implementing (some of the) candidates of SHA-3 (http://crypto.rd.francetelecom.com/sha3/AES/)
Actually, you can apparently use larger Mersenne Primes to improve results in totally different but very useful fields, like privacy-related schemes. For example, this paper http://eccc.hpi-web.de/eccc-reports/2006/TR06-127/index.html uses large Mersenne primes to get interesting results on Locally Decodable Codes and Private Information Retrieval Schemes...
Actually, the problem lies not with KDE. The core KDE Libraries are actually LGPL (parts even use some BSD license), which should be pretty compatible with the GPLv3. Just like many KDE programs are actually GPLv2+. The 'problem' is that as of yet, Qt has been licensed under GPLv2 only (and slightly more, they allow linking with a selection of other free software licenses as well, as far as I know). Which in turn makes all KDE applications linking with Qt GPLv2 at run-time. The obvious reason would be that Trolltech just does not really like giving the FSF full controll over their Qt software through their ability to modify future versions of the GPL at will.
Won't this create some undesired mess? I'd rather like to have at least some visual diversity between them. After all, concurrent development inspires progress.
Visual diversity may indeed inspire progress because there would be more competition, but it's not very desirable. Developpers may like it, but if you want to show a desktop with 2 different themes, people who are used to see a consistent interface will be scared (or at least not be impressed) by it.
Not only will most people think it's ugly, but also requires extra configuration: with two independant themes, changing the KDE theme doesn't change the theme for GTK applications, resulting in confusion. And confusion isn't good when trying to impress people with Linux.
This doesn't make the UI look inconsistent at all: the 'plastik theme' is not a GUI for OOo, but rather an example of how OOo looks like when themed like KDE can be themed. This makes your desktop look nice and integrated, whereas with a 'united' OOo theme, your perfectly skinned desktop would look inconsistent and out of balance while running OOo: every application you run looks the same, except OOo. Also, it's not like OOo has different UIs. There is just one UI, but it can be themed differently (as shown).
IANAL, but I think, that when they want to use their 'trade secrets' to win this battle, it is a wise choice not to reveal the code. Because (if I understand it correctly) if they would reveal this code publicly to show they are right, they would lose their trade secrets (as they're not a secret anymore)