Template talk:Keys

File Names

I know why we list the file names of the Root FS and ramdisks: to know which is which. Why don't we list the file names of the other (IMG3) files? I have seen some iPhone 3G (iPhone1,2/n82ap) firmwares that contain iPhone 2G (iPhone1,1/m68ap IMG3 files also under /Firmware/dfu and /Firmware/all_flash. There have also been some firmwares that contain multiple Kernelcaches.
To know which is which, you need to look up the application processor's name. If you have the keys in front of you, it would make sense to have the file name also. Listing the file names of the Root FS and ramdisks makes it so you don't have to look in BuildManifest.plist to find out which is which. So why do we make you have to look up the applicatioin processor's name?
Granted, this situation doesn't happen that often, but it would still make sense. As for how to acomplish this, we can just use the current method for IMG3 files, but modified a bit (iPhone 2G 2.0.2 (5C1)):

 | iBSS                = iBSS.m68ap.RELEASE.dfu
 | iBSSIV              = TODO
 | iBSSKey             = TODO

Any ideas? --5urd (talk) 15:58, 3 October 2013 (UTC)

Sounds like a great idea, but I would also add an option for the kernelcache (not the key) but the filename. --Phyrrus9 (talk) 02:04, 5 October 2013 (UTC)

I propose no such changes to key pages (we have many existing ones and updating them all is a pain - not to mention those of us who can actually grab keys keep having to change our templates.) --cj (talk) 16:57, 8 October 2013 (UTC)

I'm with cj on this, it's frustrating to be updating things all the time just to keep up with the latest template. Additionally, I don't think the filenames are necessary; anyone who is going to be doing this type of thing will know how to find the file they're looking for without being told the exact filename. --CompilingEntropy (talk) 20:15, 8 October 2013 (UTC)

I think we should continue to list with this new format. It is nicer now it has a smaller font and its quite nice. Filenames are not needed but it is consistent. --iAdam1n (talk) 20:16, 8 October 2013 (UTC)

It's entirely INCONSISTENT with all previous designs. --cj (talk) 19:10, 9 October 2013 (UTC)

I would love to know how you define consistent. --Neal (talk) 19:14, 9 October 2013 (UTC)

After discussions with admins, we have decided to continue over periods of time, 15 edits for this a day. --iAdam1n (talk) 08:29, 10 October 2013 (UTC)

While I like the new design, I don't think we should change these key pages all the time just for the sake of design. Remember that this wiki is intended for developers and hackers and people who want to learn something, so it doesn't matter how nice the key looks like. And the arguments of cj and Neal are very valid - there are tools that create these pages and things that have to be changed just because of this new design. I know I'm a little behind in looking through the wiki changes, but the worst thing here is that these changes have started without a discussion with a generic agreement. --http (talk) 22:06, 24 October 2013 (UTC)

If opening your code and changing "build" to "Build" and recompiling is too hard, you really shouldn't be programming. I've had to update my parsers for many sites whenever they change, but I'm not complaining. --5urd (talk) 00:38, 25 October 2013 (UTC)

I know it is a little late ideally, but what about for the S5L8900, we change LLBIV = Not Encrypted to LLBNotEncrypted = true? I think the IV part is pointless and looks stupid. It can also be confusing. I know it means editing the 8900 pages again, but I feel that this change is worth it and it would have the same rules, 15 edits a day. What do you think? I also had a few more ideas so here is an example. --iAdam1n (talk) 11:31, 27 October 2013 (UTC)

While I want this as much as you, it doesn't won't affect the output of the page. In addition, it will upset many people here. --5urd (talk) 02:17, 28 October 2013 (UTC)

I propose to not change the key pages anymore. Leave them like they are for now. If, in half a year or so, you come to a conclusion that further changes would be useful, start a new discussion and list the benefits and the number of pages affected. I would oppose minor cosmetic changes. --http (talk) 07:48, 28 October 2013 (UTC)