Good day folks!
Having been thinking about this for quite some time (but not having the full understanding of the LMCE architecture to implement it) I think both camps could be satisfied with the concept of 'roles' for net-booted devices. My thoughts were along the lines of:
- MD
- Workstation (or laptop)
- Workstation w/MD
- Workstation w/orbiter
Imagine this: when a device is net-booted for the first time, the wizard asks what role this machine will be fulfilling (with some helpful text around it explaining what each does). Then, the applicable software packages are applied onto the base OS to full-fill the role. We're implementing a similar approach at work for server builds, using Puppet
http://puppetlabs.com/puppet/puppet-open-source/, which is a configuration and compliance management tool. It uses a component called Facter
http://www.puppetlabs.com/puppet/related-projects/facter/ to determine facts about a client system (like architecture, virtual, OS Family/release, etc.) which can be used to take actions based on the facts it discovers about the system. It can be used to configure software packages, user and service accounts, install or remove software, change system parameters (like sysctl), etc. And, there's a nice community of pre-built modules
http://forge.puppetlabs.com/modules, plus stuff on github, or you can write your own (including facts you wish to discover, then act on).
It's a powerful configuration framework which I think would be a good fit for LinuxMCE. It would be a radical change in how LMCE works under-the-hood, and I think it would make future upgrades and life-cycle management activities a lot easier, as you can specify different things based on custom facts or facts like the OS version or hardware architecture. Think Pi MD vs an x86 MD. You can have the same role applied to both, but satisfy the architecture specific dependencies and configuration using the same toolset and policy. You can also use it to manage the core and it's services. There are implementations on the web where folks are using Puppet to build the PuppetMaster server, which is then used to build client systems (allowing them to bootstrap an entire environment, lets say in a disaster scenario).
Puppet is something that can be implemented incrementally, when each change you want to make is quantified, so it represents a low risk to stability. Start with the easy and non-intrusive stuff first, and as the implementation matures, go for the more intrusive changes one-by-one. That's the approach we're taking with 3 *nix OS Families, 4 hardware architectures, 4 hypervisors, and 10 OS variants in production. I thought I'd throw this option out for discussion, since there's a lot of interest in making the MD's (and other PC's) fit-for-purpose. Feel free to browse the links above, google it, or 'apt-cache show puppet puppetmaster facter' from your core.
Hope this provides some food for thought! Thanks for your time!
/Mike