@qlob: Great idea, great proposal! And the greatest of all is that you're actually going forward and creating something
- so, you've got all the Karma that I can give.
I had thought about something similar before, but dropped the idea because many things (=information about debricking) were still changing a lot at the time. But I do think that we're currently at a point where it seriously makes sense.
At this time, we do have "fool-proof" procedures for getting at least the original K4 (silver) and K5 (Touch) back to life (I'm not entirely sure about the K3, or the K4 black; and the Paperwhite is in another universe). And we have working tools (imx_usb, fastboot) to actually apply these procedures.
So I say: YES, let's do this! I'm very willing to participate in this project.
A few observations / notes from my side:
- I don't really care which Linux distribution this would be based on. As long as it works, it's probably fine with me . But see the following remarks.
- It should fit on a 700 MB CD. And it should also be installable on (and bootable from) a USB drive.
- It should support older computers. That probably simply means creating a 32-bit distribution
- Ideally, it would also (somehow) run on Macs. I'm currently writing from a Linux on an x64 Macbook Pro, so this is in principle possible. But I remember that getting it to install was a real PITA at the time... Newer Ubuntu CDs seem to support EFI/UEFI boots, so ideally the "debrick" distro would also boot on x64 Macs.
- I would personally stick to a really simple user interface. In fact, I wouldn't even use a GUI at all, but simply use a "text-mode installer", similar to what Ubuntu has for their alternative/expert installations. (i.e., a simple dialog-driven, (n)curses-based UI). In my opinion, there are many benefits to that sort of UI:
- It's not multitasked. Yes, I think that this is an advantage for this purpose, because the user should be following a strict "you are here - what do you want to do now" scheme, instead of being able to write mails at the same time.
- It's universal. We don't have to care about supporting graphic card X with resolution Y, or mouse Z. Every computer can display an 80x25 screen.
- From a developer's point of view: it's at the same "system" level as the underlying tools. All the tools that work "under the hood" are command-line executables, and there is no reason to hide that away. Simply invoking an executable, and displaying its results, is as easy as it can get (and is also the best way of displaying errors, if something went wrong).
- In the same vein, if the smallest common denominator is "execute something", individual modules can be written in whatever language is most suitable or preferred. A "task" could be implemented as a bash script, or in python, perl, etc.
- We'll either need some sort of "online update mechanism", or someone who takes care of periodically updating the contained binaries. (also counting on Amazon's current consumer-friendly behavior, i.e. accepting that we distribute images for debricking, as they did so far)