I am intending on going this time, hopefully with more commitment than last year

check the permissions on /tftpboot/default/vmlinuz
i noticed on my install the other day that it was not readable by the tftp daemon. it should be set to 644 like the initrd.
if this is the case with yours as well, then i guess we have a bug.

no, it wont do anything for you without compiling the qOrbiter bits from source.

if you can pop into irc, its a great way to interact with the people that work on this thing

If it helps any, i have built on 64 bit ubuntu with no problems. i didnt do anything different than on any other machine ive setup.

editing existing templates is discouraged simply because people usually do it incorrectly and for the wrong reasons. however if an existing device can be improved without breaking its existing functionality, then by all means edit it.

there is rarely a need to download anything other than /src or /web unless setting up a full builder, so not that many people grab the whole thing anyway

LMCE attempts to "self-repair" as much as possible, and as such most config files are regenerated at boot. usually all you need to do is make sure settings are correct on the various devices in the web admin, but for more customizing you may need to modify the scripts that write the config files. these are generally in various .sh files in /usr/pluto/bin.
there is often a better way of doing whatever it is that you are trying to accomplish though, and in particular if its a bug in something, others might appreciate the contribution of proper patch.

I have been following CEC advancements with some interest, but so far support for the protocol among a/v devices seems to be sporadic and quite fragmented. Everyone uses their own "standard" and few devices support it at all. With this in mind, I have not yet purchased any hardware to interface with it, and i doubt anyone else has either. I would love to see it supported though, and its good that there are now affordable interfaces. The most likely present themselves to the system as a RS232 port too, which means someone could get started with a Generic Serial Device.
It seems that most manufacturers use it to control other a/v gear from a TV, though with LMCE we want to control the TV (and other a/v gear) from LMCE.

i use a spare router to separate my test core on the internal net of my production core, which is necessary, yeah.
you will also want to change the internal network subnet on your test core to something else too (i use 192.168.81.x)

you still need to run /usr/pluto/bin/Diskless_CreateTBZ.sh manually (once) before MDs can be created.

yeah, for someone with a decent background in javascript web developement, qml is incredibly easy to get started in. read a few tutorials and look at some example code is about all it takes.
the declarative portion is very much like an object literal in javascript, with a reusable component system similar to classes. and of course javascript itself can be used everywhere.
and flexibility is the name of the game here. you can see by the existing skins work in progress that there is a lot of room for creativity, while still being able to provide a consistent experience for the user.

mostly its just the network control protocol. if youre lucky, nothing changed and all you have to do is make the version check match.

10.04 comes with .23. you certainly could build your own, provided you pay attention to compatibility with lmce packages, in particular the mythtv plugin.

someone that is good with paint could certainly make one silver
yes the network ones are actually controllable over the network. its actually the same commands as rs232.