I’ve begun working on an appliance-style mini Linux distribution built about libretro and retroarch. The project is still in very early stages, so these notes are not exceedingly well organized. I’ll post some of the rationale and philosophy here, grab the first couple of replies for future use, and then we can discuss it (to death probably?) and see what comes of it.
Why do it at all?
That’s a good question—actually it’s three good questions. First, what is it I am trying to accomplish, and why is what I’m looking to accomplish different from what the LakkaTV project is already doing? And third, why amd64 and not something small/low-cost? Let’s take the first question first.
In a word, Hyperkin. Now, I’m no “anti-commercial zealot”. I understand a few around here might wear such an accusation as a badge of honor, but I’m not one of them. IFF it were true that Hyperkin were obeying all the software licenses, had integrity about what they used and where they got it, and produced an example of an unquestionably 100% legal example of hardware emulation as easy to use as commercial consoles… Sounds like the American Way to me: Find something people want and make some money giving them the convenience of having it done for them.
But Hyperkin didn’t do that… They cheated, they lied, and while they were oh-so-worried about Nintendo and Sega and anyone else they figure might actually sue them for piracy, ripping off devekopers is perfectly acceptable to them. Well, screw 'em then! We can do it ourselves, and ours can be better.
As to why a competing project to LakkaTV? Probably it won’t be, actually. I’ve got some more specific things in mind that I want a “1.0 release” to do/have that they may not have even considered yet. They may or may not like the ideas I’ve got, but it’s a lot easier for them to merge working code than good ideas. 
The only reason I’m not already building out of a clone of their git repository is that I’m working on a Mac with NV video.
Why amd64 is probably the easiest to answer: The arm-based systems, while nice and cheap and often enough now coming with pretty impressive graphics capabilities, are just too slow. My personal long-term goals include “flawless” GameCube emulation because “F***ING BLUE SHELLS!!!” (amongst other reasons), and you’re not going to get that on a Pi where even some moderate PSX games just don’t run fast enough.
So what’s the big deal about Mac with NV video?
Skip this if you don’t care.
NV’s binary drivers claim to support EFI, but I’ve had a ton of problems with that using reasonably current NV drivers. Okay, so boot OpenELEC in legacy BIOS mode—Apple’s provided that standard on every amd64-based Mac they sell, right? Sure, but … you can’t boot USB in legacy BIOS mode on a Mac! So either the NV driver works under EFI, or you have to have it installed on your internal hard drive. And my internal hard drive is an encrypted CoreStorage SSD/HD “Fusion Drive”. So um, yeah it’s not going to happen on the internal drive on my development workstation. There’s actually a couple of clever workarounds for this but screwing it up can hose your system. Ask me how I know. 
So … VMWare. I’ll put together a non-virtual system when I’ve got something to install on it. 
Some design goals
Like Lakka, I’m going for the “just enough OS” approach. Actually, I find Lakka comprises a lot more software than it maybe needs to at the moment. Part of that is perhaps that they think they might need it sooner or later, and part of it is that OpenELEC includes it and they haven’t removed it. I’ll probably remove what isn’t getting used from the OpenELEC build process, but … leave the build rules in place so that we can stick it back in there if it becomes useful.
I’m not real happy with OpenELEC’s upgrade process. An appliance really should (and nicer Linux-based appliances already do) literally provide two theoretically working systems in case one of them gets hosed. Gigabyte does this with their BIOS, TiVo does this with their OS, Android should do it (but not all implementations do), and mission-critical embedded systems do it all the time. A good Libretro Box should do it too.
It looks like a few things in LakkaTV could still result in you needing a keyboard. Some of that is Lakka’s young age. In the end, though, I expect you to never need one. That includes installation, configuration, upgrades, memory card management, you name it.
Speaking of memory cards, currently OpenELEC puts your home directory in /storage and that’s just used as a normal Linux home directory more or less with dotfiles and the like. I actually envision conceptually (it may not make sense in reality) that you might not have an internal /storage and instead use memory cards to hold everything. That means some customization for use of fat32/exfat volumes as the primary place stuff gets put is in order. I’d also like to see some effort go into handling the user yanking a memory card out of the system other than while it’s actively being written and have this be handled gracefully. There are a couple of ways to do that, the simplest of which is to mount the thing sync. It’s too bad we can’t take a page from the Amiga which would recognize that you’d popped out a floppy and just tell you to put it back. The kernel hackery required for that is beyond my sanity, though.
And while I’m not sold entirely on yet another XMB clone being the end-all system, I don’t see any particular reason not to run with it. Except that at some point I’d like to see a game database built out of whatever ROMs you have in /storage or on a memory card. If you insert a card whose database doesn’t match the files on the card, rebuild it. Then instead of giving the user a directory tree to search for ROMs and cores, give them what’s available by system, by genre, etc. I’d suggest also by franchise, but frankly no game DB I know of includes franchise info. But I also think it might be cool to be able to have scans of game manuals and whatnot available to read if you want them. Maybe the ability to include things like maps and guides and whatnot could be desirable. I dunno, at some point I might want to investigate a different front-end. Maybe one that would give you the flexibility to define how it looks and how it responds to input, and I’m going to just stop talking here before someone mentions WebKit-based GUIs. Wait, I just did. DAMMIT!
I’d also like to take a page from Hyperkin’s playbook and implement a nifty interface for patches. Obviously it’s up to you with a Libretro Box where your ROMs come from and I’m just going to assume you’ve got yourself a Retrode or a dumper and not ask questions. But storing most romhacks as patches requiring the original ROM is a more proper way to do things. Plus, I want them to have NOTHING to offer by the time “1.0 release” is done.
Also, I think there are a number of not-currently-libretro-based free games for Linux and whatnot that should be available on a 1.0 release. Not so much a Libretro Box problem as it is kind of a clash between the general philosophy of The Right Way to do things in the libretro universe and I Don’t Care I Want It To Work Even If It Isn’t Proper pragmatism. See below.
A possible dual-system implementation for OpenELEC
How this works isn’t a difficult mod to how OpenELEC works now, actually: When you install the system, you actually install it twice. You get a KERNEL1 and KERNEL2, SYSTEM1 and SYSTEM2, etc. There’s one /var and one /storage, because it’s possible to blow away the former with “reset all settings to default”, and it’s possible to blow away both with “reset everything”, “are you sure?”, “are you really, totally, absolutely sure?” possibly with some kid-proofing.
Anyway, the magic here happens in syslinux, where instead of one config you have “four” (two get used at boot time) which effectively define settings for one system to boot by default, and the other to be available as a recovery option. The first one is your standard syslinux.cfg. The second is bootpref.cfg which tells syslinux which system is which. And then you have bootpref_system1.cfg and bootpref_system2.cfg. All you’ve got to do in order to change which system gets booted is to copy one of those files over bootpref.cfg.
If you’re using system 1, when it’s time to upgrade you (or rather the upgrader running in the libretro frontend) downloads the upgrade, wipes out system2, replaces it, and sets bootpref_system2.cfg to be used at next boot. The upgrade finishes by rebooting the system into the upgrade.
Going against the libretro grain a bit
As noted above, there’s a lot of pretty cool games for Linux that should be fairly easy ports to libretro, but aren’t necessarily. If I can’t play Frozen Bubble on Libretro Box 1.0 without having to configure anything, I’m not going to be happy. The problem is that Frozen Bubble is perl of all things, which brings in perl, SDL, SDL perl bindings, and old SDL at that, and … Without porting it to C (which I think some people may have done, but they had to change enough in their ports that starting over might be wise), it’s possible but not exceedingly easy to turn FB into a monolithic “core”.
But more than that, I think we need to actually port SDL to libretro backend. Both SDL1.2 (which is frankly easier because of the notion of a “screen” and all) and 2.0 which is a little harder because SDL2 supports things like multiple windows, etc. That’s kind of amusing given that libretro could in turn be run on SDL. The software-rendererd SDL games would benefit from having awesome shader-based scaling and whatnot. GL-based games would hardly notice the difference really. And all SDL-based things would benefit from a consistent controller interface with pre-configured defaults on a Libretro Box.
Ah, but a man’s reach should exceed his grasp, Or what’s a Heaven for?
Despite this sounding like “LakkaTV, plus a few things”, it seems to me a fairly ambitious project overall. By the time it’s done, we’ll be doing things that go beyond what OpenELEC is doing with their OS, and the entire thing should be idiot-proof, failure-proof, upgrade-proof, guts invisible to the user, keyboard optional, making non-libretro games easy to port to without effort, and leap tall buildings in a single bound.
If the project becomes wildly successful, I’d LOVE to see someone revive the retrode concept and build something that looks like a console with cart slots and an optical drive using this. Because why not? Just add a compatible mini motherboard with recommended specs, bluetooth, USB, etc, and you’re good to go. I don’t intend to do it personally, but I’d probably buy one if someone else did. But we’ve gotta create the platform Hyperkin could’ve had first.