Rockbox Ports are now being developed for various digital audio players!
Read before:I am already aware of the Rockbox No-Do philosophy and why it is there, it's to keep Rockbox as simple as possible (in terms of code) and to maximize ram usage to Rockbox alone. Without further ado, put those closed, negative thoughts aside and listen to why I think support for these things is essential.
GPT:There's no reason not to use GPT in favor of the MS-Dos partition table. Even Microsoft will be switching to GPT support with Windows 8 and UEFI. And the GUID system makes sense (at least in GNU/Linux) for organization. I'm not saying that GPT support is necessary for Rockbox, but the benefits still outweigh the losses. Not much more resources are used for GPT vs MS-Dos PT, and you can make more than 4 primary partitions, depending if Rockbox supports them all.
Extfs:With FAT32 you can't even make lowercase labels or include some symbols in them. Most of my labels are lowercase. And FAT32 doesn't support file sizes over 4GB. Sometimes people put movies on their PMP which may be above this size, and they don't want to compress it even further by re-encoding it. I wish the amount of support for FAT32 was dropped in favor of extfs (such as ext2, ext3 and ext4...) on most devices, but it sad that I'm still required to use it. I think ext4 with the journal turned off will still be much faster and support more GNU/Linux friendly file attributes. Extfs should be a big improvement, and I don't fully see why RB isn't inclined to doing it. I really don't like FAT32 anymore at all, and I would find out any means to get rid of its existence.
Encryption:Finally, one of the big reasons I won't use RockBox more often is because of the lack of encryption support. I want to have dm-crypt + LUKS on everything I own. hNow, that being said, is this appropriate for Rockbox? Yes, it definitely can be. But is it going to work out? No, I don't think so. Here's why: There's no standard input mechanism for all players.Typing in a potentially large password with the input mechanisms on a PMP, and still having it secure while saving time to input the password would be a real challenge. And there's entropy (strength) lost when a full keyboard is not used... God forbid if the entropy goes below 6-bits per character. And probably an extra keyfile would have to be there, but it would have to be on a decrypted partition. Maybe, on the Clip Zip, it would be on the SD Card, but not all PMP devices have support for an SD Card. That is troublesome to say the least. Now a virtual prompt with a virtual keyboard below may be a good solution to the problem.So the password would need be stored on the device with bcrypt+SHA512 and the filesystem would be encrypted with AES 256+Blowfish or whatever is best supported and standardized.One last thing is a hit on speed. Once it's decrypted, it would function like normal, but if people choose to use encryption, then they choose to degrade the life on their device even further (more R/W processing) among other minor things. But they can still listen to music on their device without the worry of someone stealing the unencrypted content on your device.
Anyway, thanks for reading. Sorry I cannot contribute any code because of the policy that requires having your real full name on commits. I prefer to be, at most, pseudo-anonymous. Plus, I have limited knowledge with this kind of stuff. I hope the Rockbox team will reconsider these goals. Maybe GPT support is okay to be left out, but please at least reconsider support for extfs and encryption. I hope others can agree with me.
Page created in 0.093 seconds with 20 queries.