Author
Topic: Appliance vs Package vs Distro (Read 19705 times)

each of the major players have different architectural approaches to playing media, which make them suited not only for different media types (some media containers are designed for specific buffering schemes, etc.), but also to deliver to different systems effectively.

You can't effectively make one piece of media code that handles every possibility, without essentially duplicating each media player inside a single process... and in the end, you would not gain anything.

The Pluto designers knew this very well, and this solution was what resulted from that realisation.

I think the total solution calls for a mixture of 'appliances' and 'packages'.

There is a bunch of functionaility on the machines (CORE and MDs) that is better suited to an appliance solution. This would be the core OS, firewalls, networking etc - then there is the software components that have some dependency on these bits but that dependency is well defined and is minimised where possible. This would be the linuxMCE services. This would be packaged software that turns any compatible appliance into either a linuxMCE CORE(Master) or linuxMCE Media Director(Slave).

If people want to configure the 'appliance part' themselves or install on existing hardware and OS combinations then they just install the software. As long is the minimum requirements are met then all should be fine.Also, if people want to use the linuxMCE 'appliances' they should be able to just install that with a minimum of fuss as well. There might be different choices for OS and/or distributions that they are based on, but essentially it is an appliance - so it shouldn't matter.

This is exactly what i am talking about, LinuxMCE packages without the networking, OS etc. and then the appliance as a related project. And i think in the process of getting a package form a lot of code will get cleaned up. Being in package form is what lead to all these different MythTV distro's that you see around. Some people saw the potential in MythTV and tried to make it more appliance like for users. If someone didn't like how its done, the re did it themselves. Eventually, the best solution will win.

This is what OSS is all about. I'm not saying that the LinucMCE appliance is poor and needs re-doing or a fork. What I am saying is all good projects are in package form. This isn't a coincidence. After all, I'm really just repeating what is on the history page (http://wiki.linuxmce.org/index.php/History). I thought getting it into package form was already agreed upon?

The MPlayer/Xine discussion:The current approach of the system deciding which media player to use for a particular task is the correct one, in my opinion. Granted, that there is more work to do and some code probably needs to be cleaned up (I'll just take Thom's word on this as I haven't looked at it myself), but the general approach is sound. Lets say a brand new codec came out that only one Media Player specially designed for that codec could play, we would want LinuxMCE to just launch that player without the user having to think about it; as far as they would be concerned LinuxMCE could play their media and that's all they (including me) would care about. Of course if MPlayer does prove to have more performance (yes, this is extremely important for LinuxMCE) than Xine in certain areas then we should expand MPlayer's use for those cases, but only those cases.

The package discussion:The whole package debate is moot. LinuxMCE already has packages and the new release will expand on this. It has been LinuxMCE's goal from the beginning to be on top of another distro like that. And, no, this would not in any way make it not an appliance. LinuxMCE should always have a default install and wizards that configures everything for the user and JUST WORK. Making packages doesn't change that... The packages just help with upgradability and scalability... which also helps with the security...

The UI discussion:I couldn't agree more that the UI needs work. I have mentioned this several times in other places and even gave some thoughts as to improving it. I also couldn't agree more that developers that specialize in functionality shouldn't be creating the UI. I, myself, am an "under the hood" type of developer and as such I almost never create a UI on my own. What I usually do at work is create some focus groups from users, and create a few mock-ups for them that mimics the most important functionality (this production quality code is later re-used). The end-users usually have the best ideas on how the UI should operate. Then I work with some artists (not very many developers can do this and we desperately could use some artists in this project) to make the UI look pretty. Then I take it back to the users and get their thoughts again. After a few more tweaks we have a damn nice UI. This may seems like a lot of work, but it really isn't and is the best approach, IMHO, to get a functional, intuitive, and pretty UI. This also coincides with the Unified Process. You OOP devs should know what I mean...

The configuration discussion:This is where I think I disagree with some of what Thom said. I don't think the database should be used to store the configuration as an intermediary between the applications config and LinuxMCE. We definitely need an API that as an intermediary (we don't disagree there), however this API should directly modify the applications configuration rather than have the config stored in LinuxMCE's database and then use what is stored in that database to actually modify the configuration. If it modified the configuration directly then user changes to that configuration (if they used the applications own configuration editor, for example) would not be wiped out and LinuxMCE would just continue on using that configuration. I don't think this would break the appliance aspect of it as the wizards and install process (in the orbiter, or web, or whatever) would continue to use that API and wouldn't care how that API gets or sets the config. Granted this isn't important if all we want is an appliace, but we want more (at least I do). I want to be able to have something that JUST WORKS and be able to customize it easily without having to go through LinuxMCE's databases or specialized configurators. This is certainly a tall order; I'm definitely not disagreeing there, but lets face it, the people who are using this system now are the type of people who want to customize things... but without getting a migraine from dealing with LinuxMCE constantly changing things back and then having to poor through the database and code to see why that's happening...

Summary:LinuxMCE should always be able to be an appliance by default, but should also play nice with others. Please note that I'm not in any way putting down the devs that put this thing together. It's remarkable that they were able to get all the apps they have working together as seamless as they are now... I just want that expanded upon so it's even more seamless in the configuration standpoint. Also, the UI needs work before LinuxMCE will ever reach the average end-user. I cannot and currently do not recommend LinuxMCE to my friends and family because I know it would frustrate them to no end (though they wouldn't care about being able to configure things outside of LinuxMCE)...

What is unclear to me is which route will get the project moving fastest:

1. Work on GUI and fix basic useability issues so that people notice and get interested, then more effort can be channelled into the under-the-hood stuff later to tidy things up and separate into packages.

2. Work on under the hood stuff to get it separated into packages and then get LMCE accepted by other distros. Number of developers increases, maybe get some graphic designers interested, then voila.

I don't think this discussion is that heated - I think we mostly agree (though talk of forking LMCE does seem inflammatory). At the risk of actually being inflammatory, I want to point out that I don't think anyone in this thread (or elsewhere AFAIK) has suggested that a consumer user should ever be deciding which app handles which task, other than perhaps when installing and picking from a list of equivalent alternatives (where that's possible). Never when in actual use getting their hands dirty on the internals. Everyone agrees (AFAICT) that LMCE should operate as an appliance.

But I do think that where there are choices between equivalent functions, like "playing WMV by either MPlayer or Xine", that choice should be exposed to the user at install time, with popular defaults, with all choice options tested (by the developers) to work.

I also think that other factoring, like making the Web and Orbiter UIs share as much code as possible, would make everyone's LMCE experience easier, whether developers with a simpler codebase or consumers with fewer arbitrary (and often mutually exclusive, even within a single use case path) modes. Such a factoring would do well to target using user selectable skins/themes, especially if its possible to use existing skins/themes to capitalize on market familiarity, especially if some competing project's theme is offering that competition advantages that LMCE beats under the hood. While also opening the UI work to a much broader community of people qualified to make or convert skins, who aren't as qualified to contribute to the code the skins call.

On configuration and the DB, I absolutely prefer all configs to be mediated by the DB. It makes keeping multiple scenarios available much more straightforward. It makes config UI more accessible to different user apps, without as many permissions problems. It makes configs across the network more easily programmable than editing files, modeling dependencies between components, and to their configs, in simple relations. It enables easily deploying new installs against existing configs, whether local or from a networked community, which is one of the visionary promises of LMCE. And offers all kinds of other features that the bare filesystem doesn't (eg. scalability including factoring to a standalone but clustered network config server). The way to get what we all want is just to include a script that updates the DB when filesystem configs are changed, just like the reverse that LMCE already provides.

As for "Appliance vs Package vs Distro", the high-level topic of this thread, I don't think that's an actual choice among exclusive options, either. I think we all want LMCE to work like an appliance, to use the benefits of the package system. Eg. dead simple upgrades when Ubuntu upgrades every 6 months, easy installers that manage upgrading components like Kubuntu, MythTV, Asterisk, MySQL, etc by just wrapping their package installers, even offering LMCE kernel tweaks as packages that a LMCE metapackage depends on, that upgrades the kernel as LMCE developers specify, but which is all invisible to the consumer - except what they're not noticing is eliminated hassles.

We're waiting while 0710 takes us through a crossroads. Not just institutionalizing keeping LMCE synced to Ubuntu releases. But the product of that process will open the project to more developers, and also to more consumers. Removing these limits to scaling the project (and to scaling the installations) will help determine whether LMCE grows into a premier media environment despite competing with Microsoft, Sony and Apple, or remains a compelling hobby / cheap starting point for proprietary home automation dealers. I'd like to see it be all of those things, by being the most flexible product that doesn't confuse the consumer.

On configuration and the DB, I absolutely prefer all configs to be mediated by the DB. It makes keeping multiple scenarios available much more straightforward. It makes config UI more accessible to different user apps, without as many permissions problems. It makes configs across the network more easily programmable than editing files, modeling dependencies between components, and to their configs, in simple relations. It enables easily deploying new installs against existing configs, whether local or from a networked community, which is one of the visionary promises of LMCE. And offers all kinds of other features that the bare filesystem doesn't (eg. scalability including factoring to a standalone but clustered network config server). The way to get what we all want is just to include a script that updates the DB when filesystem configs are changed, just like the reverse that LMCE already provides.

I think we may be thinking of two different things here. The configuration for DCERouter, including the device configuration, scenarios, etc, should definitely continue to be in the database. Moving that configuration from the database to files would be a waist of time... and going in the wrong direction... What I'm talking about is the configuration for the external applications, such as MythTV and Asterisk. There is no getting around LinuxMCE having to modify the configuration through that app's specific configuration process. MythTV has its own database, so the configuration should be there and only there. Currently it's in other locations in the LinuxMCE database as well, which frustrates people like me to no end. Also, for other apps that don't have a database, such as Asterisk (yes, I know it's possible, but we aren't doing that right now) that configuration should be modified directly through that app's configuration files. Again, let me reiterate that we will still have to modify those configuration files even if we store the configuration in LinuxMCE's database or the app won't be configured.

Let me clarify what directly means: All configuration should be modified through a standard API. The orbiters and such would not know or care how the configuration is being modified, whether it be through a database or configuration files. It would just do the tasks it currently doing without the database storing duplicate data. We wouldn't run into any permissions or networking issues as a LinuxMCE service would be taking care of all the configuration stuff (which would be running with the necessary permissions); the orbiters would just be telling the service what needs to be configured and the service takes care of it. This is the point of having the standard API. None of this would be possible without it.

I'm also referring to firewall rules, network interfaces etc. All these things are in a database and have associated bash scripts that run at boot time to get the underlying OS into a nice state. If things are going to be in packages and completely distro independent, they can't remain. Things like this need to be separated out into an appliance wrapper for linuxmce. This is one of my main gripes ATM.

I'm also referring to firewall rules, network interfaces etc. All these things are in a database and have associated bash scripts that run at boot time to get the underlying OS into a nice state. If things are going to be in packages and completely distro independent, they can't remain. Things like this need to be separated out into an appliance wrapper for linuxmce. This is one of my main gripes ATM.

I'm not really clear on who's asking for LMCE to become distro independent. Just because it's distributed as packages (and dependencies on existing packages) doesn't mean it can't stay dependent on Ubuntu (or on an LMCE distro derived from Ubuntu).

Also, why can't those configs and their scripts gluing the DB to the filesystem remain, even if LMCE were to become just packages (not a complete distro or integrated standalone installer)? Even if LMCE were to become distro-independent, wouldn't that independence just mean the scripts need to behave a little differently after detecting which distro they're running in?

This is my point. I would like one day to be able to have my nice new ubuntu/debian/centos/whatever server install with networking and a firewall all setup then be able to install the linuxmce package and all its dependicies. It shouldn't touch my network settings, my firewall settings or anything. What it should do is install the DCERouter, things like MythTV, Asterix etc and the wrappers for each, the GUI stuff and thats it.

These bash scripts for firewalls and networks are all appliance specific. I acknowledge there is a need for an appliance, but as someone said earlier, thats just a case of some sensible defaults. At the moment, the simple setup come of linuxmce comes with the burden of a highly customised and tightly controlled host OS. This means our release cycles are tied to those of the host OS and it requires a lot of mucking around to actually use the box for much more then linuxmce.

I suggest we follow the mythtv model. Have it as a package, move all the stuff specific to an appliance into a different space and give the project some independence. Once thats accomplished, refactor the appliance specific code and get it working nicely with a specific distrobution (like ubuntu. MCEBuntu could be born similar to MythBuntu). This way, all functional components are in a separate project to the appliance specific stuff. Each will attract their own developers but more importantly, having linuxmce as a package that anyone can install on an existing server distro and use without too much hassle (yes, this means NOT hijacking their firewall and network settings) will server to attract a lot more developers to the functional side of linuxmce. This will, i believe, lead to a bigger and better linuxmce.

And I think the first step to getting there is well underway with the work the guys are doing in getting the source to build easily under a typical Configure -> makefile setup.This should distinguish the dependencies much better and allow a much better seperation.

i compiled the common libs (RA,DCECommon,Serialize,pluto_main) and some binaries (MakeRelease,MakeRelease_PrepFiles,sqlCVS) on debian etch to give this thread some content. OpenBSD comes next. This would be the first step on any distribution. Until somebody is willing to do the same on <insert your favorite os here>, please stop spamming the developers forum with feature requests.

It's not like there is some budget and have to discuss how to spend it. Until some of you wants to dedicate effort this won't be done. And i tell you what: you could use the binaries on an appliance, as a package or without (does tar count as a package format?), on some distros. But if you won't compile it for your target, it is senseless to discuss about packaging or distribution.

Agreed Nari. Thats why i have also been focusing efforts on Debian Etch. I hope to have something approaching functional by the end of Jan 2008.

so what are your milestones?btw, DCERouter runs fine, too

Hmmm... well the DCERouter is possibly one of the easiest components to have running on a chosen distribution. Over the time i have been involved in Pluto and now LinuxMCE... it has been built/installed on most distributions I can think of (there maybe some it hasn't).

I think what we all need to understand and recognise is that LinuxMCE has to server many different communities - the guys who like exploring deep done 'under the hood' purely for the joy of it, the guys who are interested in other platforms because... well they just are, those who want to play in specific areas but could care less what actual distro is sitting underneath, the people who really just want to install LinuxMCE and may tinker a little with scripts and stop there, those who just want it to work reliably and slickly etc etc... and then there are people like me who have strong personal involvement but also work for a company tightly involved in developing/building/installing systems for end customers who just want it to work... and probably 100 other communities too!

Accommodating all of these communities is difficult to do but I believe it is possible as long as we all respect that here has to be space here for that too happen. So the guys who want LinuxMCE to run under CentOS (or your distro du jour!) can go and do that but not get ostracised for it. But all of these communities benefit from LinuxMCE gaining critical mass in terms of the size and vibrancy of the number of people here... and to really achieve that we have to have a strong focus i believe on a stable, functional system - because that is what will attract increasing numbers of people and organisations to get involved while also allowing the engineers amongst us to do their thing in an elegant and beautiful way (thats what will impress and attract more engineers ;-) ).

So I guess what I am saying is we all have to have a less 'you all have to do my way or else' type of attitude here... ;-)

So I guess what I am saying is we all have to have a less 'you all have to do my way or else' type of attitude here... ;-)

I've been accused this past week of having that "you all do it my way or else" attitude, and I see that charge leveled in general. I haven't seen anyone demand anyone else do LMCE their own way "or else", or any other such selfish demands. I never demanded anyone else do anything, just asked whether something or another worked, or worked a certain way, or recommended a way that I thought was a good way to do something. And I haven't seen anyone else doing anything but that themselves. So I don't know where that defensiveness is coming from, except that we're all frustrated waiting for 0710 to be released, and know that the community will grow, and perhaps in later a larger group of newer people might move the developer group consensus away from where it's been.

Getting defensive like that when there's no real threat like that is another growing pain that can hurt a group as much as, or more than, actual selfish demands to yank around a project. We're each coming here for our own reasons, and finding mutual interests to work together on. Or just a personal interest to work on to contribute back. Like any other project. This LMCE project started out as a fork, of Pluto, so maybe there's fear of that happening again. But that fork was a mutual interest of both sides, and there's no evidence of it lying in store again.

Let's just take extra opportunities to give each other the benefit of the doubt, to try to avoid escalating conflicts with no real basis. We're going to have a lot of work to do, most of it lots of fun, that we can offer each other, once 0710 is the new version. The sqlCVS/GSD system will make this one of the more collaborative projects of every kind. Let's be a community that's as good at working together as we are at working on the project individually, and as good as LMCE itself is at working with all the machinery.