That's fine - you're definitely not the 'target audience' though - we mainly cater for emacs users and konsole

Seriously though Mer is for people who look at the capability of cheap embedded systems and want a much shinier UI or just more in the way of middleware that they don't want to manage themselves.

Most of our devs use vi/emacs and consoles.



Right - we still do that. We actually define an set of CONFIG_* that you need to have in your kernel (and why). You then build your hardware adaptation layer (using Android BSP if you like) and put Mer on top. Your UI layer sits on there. So yes, we're a small and increasingly blurry step up in device class from a kernel/framebuffer.

I see you didn't write a kernel from scratch? Why not? Because if you can answer that then. in a way, Mer takes that rationale and pushes it up the stack to the UI layer (but no higher).

You selected Debian (me too on my desktop) - but if you knew Mer Core has just ~350 packages which are selected and optimised for mobile (RAM and storage space still matter) to form a rational mobile base OS that is pre-built for multiple ARM, MIPS and x86 architectures. If it helped with the "OMG what bits of Debian do I need?" question. If it also used latest stuff like systemd, Wayland and similar (I don't care what people say about them for the desktop/server - they are *superb* for mobile). Then maybe you'd use Mer - after all it's the same source that Debian uses - just less to wade through.

Then yes, there's an 'SDK' which operates at 3 levels - there's a pure command-line SDK which is basically a chroot for us platform-level guys. All vi/emacs and raw gcc, nasm, cmake, $whatever (also we support a really nice opensource cross-compile solution called scratchbox2). Nicely this thing also runs as-is on our build farm stuff - so if you want to scale up to do QA with a team or 2 or more ... that's fine we can go there (and that's another key point - this is not just for 1-man outfits - it scales from hobbyist to Nokia's size)

That *same* SDK is then quietly wrapped in virtualisation tech and shipped with a GUI as an application SDK. Same toolchains, same code releases as your platform or build systems - but with the C++/Qt graphics stuff available. That's nice for QA


So moving on 10 years to 2010

You still need to do that but now does it have ... bluetooth? web browser? wifi? maybe even a remote control with a touchscreen display that needs fancy graphical transitions? Sure you *could* write them - but Mer would let you assemble and prototype that setup in a matter of days. (We know - there's a Chinese consortium making set top boxes using Mer).

I am not kidding - days. Maybe a month if you've never used Mer before and need to brush up on Qt/C++

Sure it'll look like crap until you hire some graphics people to pick nice colours and do fancy layouts - but that won't take long either - Qt/QML is good there.

And this isn't for end-users to hack it onto a phone - it's for a company to 'easily' make a device for their market.

oh, and it just happens that we're making a phone too


Again, I have no idea what this means in reality.

Dont worry too much that I dont get it - it is not aimied at me I suspect, my phone is a mono Nokia, my TV does not surf the web nor would I want it to :-)
[quote]
(I think I covered the Debian/busybox (yes, we'll have a busybox option) points above.)

Fair enough. I'm not radically different. I have smartphones but barely use them. My TV is MythTV but I just watch boring old TV (though Denise does occasionally browse epguides.com to see what order the shows are in)

But I do want my next car stereo to tether to my phone to sync on the move or browse the web or use OSM - but I suspect I'll enjoy building it more than actually using it

The 'services' part is about the systems that you need to run all the infra - automation, QA, build. All opensource of course.



Yes, that's pretty close - but properly open with more linux and no java(*)


(*) ask if you *really* care about running Android apps on it 'cos you can.