LinuxMCE Forums

General => Developers => Topic started by: rstuart on November 29, 2007, 05:01:33 am

Title: Appliance vs Package vs Distro
Post by: rstuart on November 29, 2007, 05:01:33 am
I came across LinuxMCE a few months ago now after reading an article about a ex-microsoft employee thinking about jumping ship because of DRM. I have been using it ever since and have been quite satisfied with it. Recently, i decided i wanted my core to also be a server for my house, handling mail, hosting websites, running java web applications, handling PPPoE and all the rest of it.

I found the distro used by LinuxMCE to be very tightly controlled and specific. Installing new software meant changing the sources list, getting pppoe working meant channing a database, all users created by LinuxMCE had their shell point to /dev/null etc. In short, it was very appliance like.

So what i am here to ask is this. Is the vision of LinuxMCE to literally be an appliance or was this something inherited from pluto? Is there any interest in the future to turn LinuxMCE into an OS Distro of its own (MCEbuntu anyone?) or perhaps even just creating a LinuxMCE package that can be installed from ubuntu server edition. I think it would be great if i could install ubuntu server and then the LinucMCE package and have it all work. For now i'm left with changing everything LinuxMCE has put in place to get it to operate like a server.

Am i the only one with these desires?



Title: Re: Appliance vs Package vs Distro
Post by: DeadPenguin on November 29, 2007, 05:42:59 am
No I don't believe you are alone.
I would like this very much also. I have to believe this is one of major reasons for the "fork". To utilize the power of the base OS and make it accessible from the LMCE package.
see here: http://wiki.linuxmce.org/index.php/History (http://wiki.linuxmce.org/index.php/History)

I think LinuxMCE is still in its infancy. In the few months I have been watching it has evolved very much. There are a lot of great people here putting a lot of time and effort to make this better. I think a lot of the focus is still on the Media side since that is the shiny part everyone comes here for. I think the true power of LinuxMCE is in the consolidation of a lot of good projects that work together in harmony.  I think once adding stuff becomes easier LMCE will blossom. I am very happy with some of the very recent annoucements -Mplayer as the media player. I have never been a fan of XINE.
Stay tuned its only going to get better.

Regards,
Blair
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on November 29, 2007, 06:16:16 am
Thanks for that, hadn't come across that page yet but it spells it all out just they way i hoped it would. So it looks like Paul has the same idea for LinuxMCE as i do, which is great. But as you say, most of the work seems to be around the media at the moment. Is anyone actively working to get it into a package (standard add-on) form? The announcement that KDE is getting on board is obviously a good one but just wondering if any progress had been made and if there was anything that needed doing?
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on November 29, 2007, 02:23:47 pm
I am very happy with some of the very recent annoucements -Mplayer as the media player. I have never been a fan of XINE.
Stay tuned its only going to get better.

Regards,
Blair

Just wanted to correct a misinterpretation above regarding mPlayer; mPlayer is only used for HD playback in 0710... Xine is still used everywhere it is currently in 0704

Andrew
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on November 29, 2007, 04:15:23 pm
I really don't know why everyone is all ga-ga over MPlayer, the code-base is terrible, and a lot of things had to be grafted back into MPlayer for it to have the functionality that the Xine_Player wraps directly around libxine...but I guess people really are sheep...

*hmm*
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on November 29, 2007, 04:51:20 pm
I really don't know why everyone is all ga-ga over MPlayer, the code-base is terrible, and a lot of things had to be grafted back into MPlayer for it to have the functionality that the Xine_Player wraps directly around libxine...but I guess people really are sheep...

*hmm*


Well... if you want to play back HD content etc then mPlayer is really the only viable route at the moment. Xine is still doing the job it does now (and very nicely too!) for SD content.
Title: Re: Appliance vs Package vs Distro
Post by: rrambo on November 29, 2007, 06:39:43 pm
I can tell you one reason I like mplayer over other players...  have you looked at cpu utilization during video playback with mplayer versus other players?? On my machine, the same video file played with mplayer versus xine results in almost twice the cpu usage with xine...

There's a reason why Geexbox uses mplayer...  low cpu utilization..  great video playback and support for basically any video file..  I've had video files on my system that xine won't play at all come up and play perfectly in mplayer..

I'm actually disappointed that xine is still going to be used in 7.10
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on November 29, 2007, 06:41:09 pm
regardless, the code-base is a MESS, and riddled with all sorts of workarounds.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: teedge77 on November 29, 2007, 06:45:27 pm
ha...so mplayer seems like it should fit right in...most linuxmce installs are a mess, riddled with workarounds.
Title: Re: Appliance vs Package vs Distro
Post by: darrenmason on November 29, 2007, 10:44:01 pm
Just a question, I thought one of the original reasons Mplayer was not used was due to lack of support for DVD Menus - which Xine supported.

I assume this must of changed, anyone know.

btw. I agree with the problems with all the code workarounds. There seems to be an excessive amount of code that looks like;
if (device == A PARTICULAR DEVICE TYPE)
{ Do something special }

This sort of code appears in devices that are meant to be oblivious to the contained devices, effectively compromising the design.

It will be interesting to see if Mplayer needs all the same workarounds that Xine_Player seemed to be subject to.

Mind you, its good to see the code base progressing.
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on November 30, 2007, 01:06:17 am
Does LinuxMCE still need to fill the appliance space? Does pluto not already fill this void?

I'm a fan of working hard after the 710 release to get LinuxMCE in a package form. I think the admin site needs to be completely re-written (it should be an optional plugin for the package version), we need to get rid of the mysql database (at least the parts that have to do with system config) and get rib of all os specific stuff like the boot scripts. The package version should care about firewalls, remote access, ssh keys or any of that stuff. Users should be based on the OS users and the list goes on.

Then if people feel there is still a need for an appliance version, we can pick an OS, and do much like we do now. Except, the website would be installed by default, we would care about firewalls, ssh etc. In fact it would be very similar to now, but the appliance stuff should be very low maintenance. The majority of work would lie in the package.

Is this the feeling amongst the community or have i taken it further then what people were expecting?
Title: Re: Appliance vs Package vs Distro
Post by: dopey on November 30, 2007, 08:35:37 am
I'm a fan of working hard after the 710 release to get LinuxMCE in a package form. I think the admin site needs to be completely re-written (it should be an optional plugin for the package version), we need to get rid of the mysql database (at least the parts that have to do with system config) and get rib of all os specific stuff like the boot scripts. The package version should care about firewalls, remote access, ssh keys or any of that stuff. Users should be based on the OS users and the list goes on.

Then if people feel there is still a need for an appliance version, we can pick an OS, and do much like we do now. Except, the website would be installed by default, we would care about firewalls, ssh etc. In fact it would be very similar to now, but the appliance stuff should be very low maintenance. The majority of work would lie in the package.

Is this the feeling amongst the community or have i taken it further then what people were expecting?

We can't get rid of the database, but I do agree that the system configuration stuff should be cut out. If LinuxMCE wants to do system configuration it shouldn't duplicate the config in a database and then modify the config files. It should just read and write the config files. In fact, I think any configuration for another application should use the that specific application's configuration files. I just gets really annoying... Of course re-writing this is a major chore...

I too am a big fan of the packages and the 0704 release was a big step in that direction. There are still some issues to work out, however.

I do think that the website should continue to be installed by default... it's currently the only way to configure many things... of course, you're right, the website could use some improvement... but I also think there are bigger issues that need to be tackled first.
Title: Re: Appliance vs Package vs Distro
Post by: bulek on November 30, 2007, 08:43:14 am
...
I do think that the website should continue to be installed by default... it's currently the only way to configure many things... of course, you're right, the website could use some improvement... but I also think there are bigger issues that need to be tackled first.

I agree. My vision is to go in direction of making web portal with also other services like blogging, Galleryv2, some light groupware etc... And web admin could be integrated in such portal... Afterall, we're making this system as home/family integrated server...

Regards,

Bulek.
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on November 30, 2007, 02:21:00 pm
if you're going to do things like that, the user interfaces have to be melded together to seem cohesive.

One thing I have not heard from ANYONE on this forum, or on the lists, or on the wiki, is an emphasis of an overall aesthetic and vision. That's okay, most of you are programmers interested in functionality....

I want something more....

The threat of breaking apart the appliance aspect of the system is that an overall consistent vision may very well be lost in the process as the entire system is cannibalised, and if that happens, I _am_ going back to Pluto.

The whole point of a smart home system is to have something transparent, and fluid...if the system architecture does not go in this direction, it will always be this nuisance to use, and configure. In the end, I want something I can install, set up, forget. and I could give a flying FUCK about what distribution is used, what programs are underneath, so long as the system is consistent, and if I have to bulldoze my way through everyone to show you all what a consistent system is, so be it.

(yes, I _am_ being instigatory, programmers are not the best people to do user interface work.)

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: teedge77 on November 30, 2007, 03:38:55 pm
instigatory?  :D
Title: Re: Appliance vs Package vs Distro
Post by: jester on November 30, 2007, 04:40:09 pm
I must agree with Thom,

And if LinuxMCE wants to be appreciated by a wider audience, next to consistency there would be sense, ease of use and good looks. This is why Apple is selling so damn good (your being cornered with DRM and other tricks, but you must love the previously state points ;) )
Title: Re: Appliance vs Package vs Distro
Post by: teedge77 on November 30, 2007, 05:22:11 pm
there has been talk on other forums about linuxmces terrible interface. people were not impressed at all by how it looked. i guess being new to the htpc stuff i was jsut impressed that it did so much and didnt think much about the ui. it is a big fugly though.
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on November 30, 2007, 05:33:52 pm
it's not so much about the skin, the skin does play a big part, but it isn't the only thing...

one example of where we need to concentrate efforts:
there needs to be a clear flow of how to use the system when it is first set up. The set-up wizard is a very good start, but the issues start when you need to go to the web admin interface

far too often, i see in the web admin interface so much architecture from down below exposed, lots of things like PK_Device, EK_CapturePort etc.. I understand what these are, they directly map to various keys inside the database, but is someone going to know that in order to make a live TV button, you need to use media type 11, use the device # for your cable box so that the system knows how to map things? granted, it's amazing that I can give a device # and a media type and the system knows what to do, but we need to wrap things into something a bit more easily understood, especially when you want to do things like turn on lights AND the TV for an alarm clock. The Advanced Wizard I feel was merely meant as a stop-gap until better stuff was created.

There are loads of other issues, the Media tagging aspects of the system expose too much of the underlying architecture, and can be vastly simplified, and there is the disconnects of going into MythWeb and AMP to configure other aspects of the system....

the user interface needs to be designed, and the software should map what the user sees on the UI to the back-end. I am working on some designs for this now (I had to put my game plugin on hold temporarily while a build environment can be built) and I am experimenting with building a totally new web admin to try out some ideas....

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: teedge77 on November 30, 2007, 05:43:48 pm
wait...game plugin....on hold?....well....son of a bitch.....like i wasnt impatient enough already with the 0710 release..now i have to wait for the games too? im gonna call this the black winter of 07.

anyway...i definitely get what youre saying thom. itd be nice to not have to know as much as the rest of you and still be able to set things set up a little more easily and in a much more "granular" (buzzword) way.
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on November 30, 2007, 06:31:57 pm
...
I do think that the website should continue to be installed by default... it's currently the only way to configure many things... of course, you're right, the website could use some improvement... but I also think there are bigger issues that need to be tackled first.

I agree. My vision is to go in direction of making web portal with also other services like blogging, Galleryv2, some light groupware etc... And web admin could be integrated in such portal... Afterall, we're making this system as home/family integrated server...

Regards,

Bulek.

Hmmmm... I tend to agree with your ideas above. Its certainly the way we see things moving in that we see the Home/Family aspect as increasingly important.
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on December 02, 2007, 10:48:47 am
Quote
The threat of breaking apart the appliance aspect of the system is that an overall consistent vision may very well be lost in the process as the entire system is cannibalised, and if that happens, I _am_ going back to Pluto.

Does pluto not already fill the application space? The point i am trying to make is, if we get it into package form, we can make the appliance aspect work a lot better. Why? Becuase we can do it our selves. We don't have to rely on all of the pluto scripts and ugly hacks. Its been said once, and i'll say it again, the code base is a MESS. From what i understand the pluto people readily admit this. Taking something that is a mess and making it brillant is difficult. Especially when its not your mess to start with.

What we have here is a reference implementation. We know what works, what doesn't and hence we are in a position to make it better. I'm not saying start from scratch. What i am saying is don't be afraid to chop and change. When you get it in package form, as a standard add-in to KDE across many distros, then you are in a position to make a fantastic appliance. But people aren't going to be interested in doing this with a mess of a code base and a community thats reluctant to change it.

My point of view is, eventually, someone somewhere will take linuxmce in its current form and turn it into a distro unspecific package. From what i have read on the history page, this sounds like what linuxmce was born for. If not, unfortunately it will take another project fork. After all, what was the point in forking form pluto if the goal was to make just another appliance?

Create the package, the appliance will follow and and so will developers.
Title: Re: Appliance vs Package vs Distro
Post by: hari on December 02, 2007, 01:00:00 pm
After all, what was the point in forking form pluto if the goal was to make just another appliance?

a year ago i thought it would be fine if it were no appliance but i could take the pieces out i want from it. But now i think the appliance is the better way. There is nothing in pluto what you can't get from other combinations of software/hardware. All the point around pluto/LMCE is to deliver a complete solution. So what do you want to run on another distribution? Is it the Asterisk AGI scripts? Or the scripts to set up nfs roots for diskless clients? Myth? VLC? The ugly web interface? The "script-glue" and DCE all around this? The installer?

The point in the fork was to get more control over the code base. And thanks to the work of daniel we are able to compile it ourself now. So we can introduce more options for "experts" and make lmce fit the user needs better. So yes, i think the goal is to make another appliance that fits our needs better.

But the whole discussion is kind of pointless. Pluto is in package form and has always been. Nothing stopped you in the past from taking the pluto debs and run it on your own debian. There even has been some script to help you achieve that goal. So what stops you from porting the stuff you need to another distribution/os/whatever?

So i recommend to all "package" fans to try to compile the core components from svn (like DCE_Router) on your preferred target platform (and make little ZIP packages *grin*). The new target should be integrated to use MakePrep and MakeBuild correctly. So we would have both ways: a target for an appliance and targets for single packages.

best regards,
Hari
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 03, 2007, 05:29:55 pm
All of the choices in this discussion could become equally available options if the LMCE architecture were properly 3-tiered.

All of the data, including system config, should be in the database, even if there's a lower level for interfacing the database to the OS config files. Databases bring a lot more to the architecture than just data storage, including clustering for reliability, easier data conversion (like upgrading), statistics, config scenarios, and most important a consistent data API for all data, even as middleware. A proper data tier would be a LMCE API to the data, independent of the RDBMS used (ie. MySQL, Postgres, Oracle). Especially for installing in environments that already have an RDBMS running, this is the best data architecture.

LMCE is mostly independent apps glued together to deliver combined features to a unified user experience. The DCErouter does a great job of abstracting all the messaging and kinds of apps. What it could use would be abstraction of its interface to the data and UI APIs, to go with their own modularity.

The UI of course will "sell" LMCE to the mass audience against other competition like WMCE, and Apple's and Sony's inevitable products. Even if the other systems have much less function, even with crippling DRM and other closed (even arbitrary) constraints, people will prefer them if they looks like what they want. LMCE should have a single GUI definition that is rendered differently for dedicated devices (like the Orbiter) and for Web access (eg. remote access or as webservices). Orbiter should read an XML file that defines the skin, links to other fields, and to executables. LMCE's webserver should render that XML file as HTML and glue it to the executables, preferably as AJAX. Functions should not be segregated between Orbiter and webpages, requiring both users to use both GUIs for a use case requiring both segregated functions (like configuring disc ripping storage format, then starting the ripping), and also developers to work redundantly in both segregated presentation code files - with different appearance in each.

Organizing LMCE into that architecture lets its components operate and get developed independently, with core and optional features. That architecture lends itself to deployment as .deb packages, which can just require all the standard external packages of Kubuntu and other apps (ie. MythTV, MySQL, etc). The LMCE project can use those packages to offer a custom distro ISO with all those packages for convenience, preferably a net installer against the existing external repos and an LMCE repo for just the LMCE-specific meta/packages. Especially as Ubuntu upgrades every 6 months, LMCE can just use its APT system to eliminate problems managing dependencies and the bulk of the bundled apps. While making it much easier to compose variants that use alternative components, such as different databases, custom theme GUIs, and omitting unneeded functions from either/both the GUI or/and the apps and data.

We don't have to make choices as a project that exclude some alternative LMCE configurations that would work, just to keep our work on it simple enough not to drive us crazy. The current upgrade to 0710 is a turning point that makes LMCE able to upgrade along with OS upgrades (another is just about 4 months away), as well as present a development platform that can be scaled to a larger, more open developer community. It's already modular enough as DCErouter and device templates that we're not stuck. Let's keep the architecture as open (to alternatives) as possible, wherever that openness lets making choices not actually core to LMCE be someone else's problem, in their own component project or configuration bundling.
Title: Re: Appliance vs Package vs Distro
Post by: darrenmason on December 04, 2007, 12:06:23 am
A few comments....

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.

As far as the software is concerned I would like to see Orbiter seperated from the Media Director device a bit better so that a Media Director  can just be responsible for delivering the media and the orbiter is just responsible for user interaction. Where people want to use both together then they should work together fine as well (the current model). For this to happen, the xxx_player devices need to be owned directly by the Media Director device rather than the onScreen Orbiter.

I believe the code already has a database abstration layer that seems to do the job. There may be additional coupling to mysql in the scripts, and maybe the web admin though. MythTV has a coupling to it as well so breaking that might be hard. I don't see much benefit in doing a lot of work here as  I don't see a lot of peoples homes having a major RDMS setup that requires huge amounts of maintenance.

I think the configuration aspect of the system is done reasonably well already. It is served by the DCERouter so how it is persisted doesn't matter too much as that is effectively the interface to it from devices. We are starting to see some requirements for getting changes as they happen for some devices but the restarting mechanism of reloading from the DB works well enough at the moment. I think web admin should remain basically the device editor that it is and that commonly used configuration should be redone as use case implementations (often wizards) in the Orbiters - like is being done now.

So basically I think a lot of the structure is good - it just needs a bit of cleaning up. Seperating the Orbiter would allow development on that to progress independantly, which is what a lot of people wish to see.

I am looking forward to setting up a development platform an contributing a few ideas that I have been working on and I am enthused that there is a lot more developer action of late.

Regards
Darren
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 04, 2007, 01:45:44 am
I am very happy with some of the very recent annoucements -Mplayer as the media player. I have never been a fan of XINE.

Just wanted to correct a misinterpretation above regarding mPlayer; mPlayer is only used for HD playback in 0710... Xine is still used everywhere it is currently in 0704

Actually, I'd like to see just a single player app. Since 0710 has (will have) wrapped MPlayer to the same extent that Xine is wrapped, is there any reason not to drop Xine in favor of MPlayer 100%? Where in the code does LMCE select which player (based on content), so I can look into consolidation? Maybe even convert the two wrappers into a single "wrapper template" and requirements list so people (probably developers, not consumers) can substitute any satisfactory player inside the wrapper.

There's a discussion of "Xine_Player: what is it really doing?" (http://forum.linuxmce.org/index.php?topic=3327.0) which is probably a better place to discuss Xine vs MPlayer.
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 04:02:55 am
you really need to study the media plugin and relevant player code before making such sweeping descisions. There is good reason that there are multiple players in the stack, they're each used in different situations and used dynamically.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 04, 2007, 06:57:00 am
you really need to study the media plugin and relevant player code before making such sweeping descisions. There is good reason that there are multiple players in the stack, they're each used in different situations and used dynamically.

Can you summarize the good reasons for using Xine for playback of non-HD video, when MPlayer could do it instead (or maybe it can't)?
Title: Re: Appliance vs Package vs Distro
Post by: darrenmason on December 04, 2007, 07:06:17 am

Actually, I'd like to see just a single player app. Since 0710 has (will have) wrapped MPlayer to the same extent that Xine is wrapped, is there any reason not to drop Xine in favor of MPlayer 100%? Where in the code does LMCE select which player (based on content), so I can look into consolidation? Maybe even convert the two wrappers into a single "wrapper template" and requirements list so people (probably developers, not consumers) can substitute any satisfactory player inside the wrapper.

The whole point of the architecture of the system is to allow support for best of breed devices. This includes hardware based solutions. If something plays a certain type of media better, than invariably someone is going to want to use that. We have just seen that happen now with HD DVDs, hence the MPlayer implementation.
IMHO, we should not be looking to close this down and limit to  the lowest common denominator.
I also think that the end user shouldn't be aware (or care) what software based media player is in use. They need to be able to add media - play it - and get a consistent interface to do it.

If MPlayer proves to be best of breed for all Media Types then now that a wrapper is built it should be quite trivial to switch usage - but lets not try and restrict to single apps unnecessarily.
Title: Re: Appliance vs Package vs Distro
Post by: Hagen on December 04, 2007, 09:37:56 am
As a consumer I would prefer an appliance that I can 'set up in xxx easy clicks'.
That should not prevent a package I would think, but I really don't care what's underneath the LMCE UI as long as it's fairly understandable if I have to venture out onto the desktop. So I am perfectly happy with the choices that has been made for me (Kubuntu) as long as it works.


Title: Re: Appliance vs Package vs Distro
Post by: chrisbirkinshaw on December 04, 2007, 02:01:29 pm
Can you summarize the good reasons for using Xine for playback of non-HD video, when MPlayer could do it instead (or maybe it can't)?

Because Xine is doing it already? Why fix it if it's not broken?

My thoughts on the whole appliance/package separation effort is that right now I'd be happier to see development effort going into fixing all the annoying bugs and terrible GUI problems which make even simple operations almost impossible - e.g. girlfriend wants to find episode of Heroes called "5 years ago", or wants to watch an in progress recording - both of these things are actually quite difficult. The fact that under the hood a peice of code has been changed to be distro agnostic is at this stage in time wholly unimportant to me. I appreciate that is the goal, but surely that is the FINAL goal. In between we actually need to get the think to play TV/movies and do HA reliably and intuiively, which right now it doesn't really do.

Anyone agree?

Title: Re: Appliance vs Package vs Distro
Post by: Hagen on December 04, 2007, 02:09:09 pm
Anyone agree?
I do
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on December 04, 2007, 02:29:26 pm
Can you summarize the good reasons for using Xine for playback of non-HD video, when MPlayer could do it instead (or maybe it can't)?

Because Xine is doing it already? Why fix it if it's not broken?

My thoughts on the whole appliance/package separation effort is that right now I'd be happier to see development effort going into fixing all the annoying bugs and terrible GUI problems which make even simple operations almost impossible - e.g. girlfriend wants to find episode of Heroes called "5 years ago", or wants to watch an in progress recording - both of these things are actually quite difficult. The fact that under the hood a peice of code has been changed to be distro agnostic is at this stage in time wholly unimportant to me. I appreciate that is the goal, but surely that is the FINAL goal. In between we actually need to get the think to play TV/movies and do HA reliably and intuiively, which right now it doesn't really do.

Anyone agree?

I agree totally. The problem is that we have a community made up of people with a wide range of expectations for LinuxMCE. They range from the people who just want to code 'cool new' things... for the sake of well... 'coolness' (if there is such a word ;-) ) and dont use the system really that muxh to those at the other end of the spectrum who just want to use the system and want reliability and cleanup of what they expected LinuxMCE to be when they got started with it!

We need to keep both of these diverse groups happy and engaged with LinuxMCE... we need people at both ends of this spectrum. If we don't serve all these diverse needs we will become similar to a group of Master Woodworkers discussing the best way to 'sharpen' our tools or make a better join between two pieces of wood!

We probably need to organise things around releases so that the 'engineering' crowd here have a set of goals to aim for and a defined feature-set and path to travel along. Then there is a path which is focussed on delivering fixes etc and making sure the system delivers usable capability. Someone needs to become the 'product manager' for each of these and take charge of whats in and whats out. In the end you need someone to make the decision.

Anyway I will stop rumbling on now!

Andrew
Title: Re: Appliance vs Package vs Distro
Post by: rrambo on December 04, 2007, 03:21:29 pm
I've got a question on a related note with regards to xine/mplayer...  why not make it an option like in mythtv..  where you can say files with extension .*** use mplayer and files with .*** use xine...  give the end user the choice....  would that involve a great amount on coding?
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 03:30:20 pm
because it's not that simple, different media players need to be used depending on both the type of media and the destination. In a properly designed system, the media players expose their capabilities, and the system makes the appropriate choice. This should not be deviated from, and would only cause reliability issues long term should such a feature be exposed.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: rrambo on December 04, 2007, 03:33:21 pm
because it's not that simple, different media players need to be used depending on both the type of media and the destination. In a properly designed system, the media players expose their capabilities, and the system makes the appropriate choice. This should not be deviated from, and would only cause reliability issues long term should such a feature be exposed.

-Thom


that would be fine with me...  if the system determines the best player and automatically chooses it..  but my understanding is that in 7.10 mplayer is only used for HD playback...  that's not going to help with video files that are SD but won't play in xine..  but would in mplayer..
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 03:36:56 pm
these issues will be resolved, even if we have to refactor the external media identifier system to do it.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: rrambo on December 04, 2007, 03:40:25 pm
these issues will be resolved, even if we have to refactor the external media identifier system to do it.

-Thom


now that's what I needed to hear....  sounds great Thom
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 03:42:14 pm
the thing is, LMCE is being shifted into community process.. We need people to help take this thing apart and understand it.

we need more developers.. I'm hoping to be one of the guys down in the mud... (I'm still trying to get my dev environment to build correctly)...

but it will get done. :-)

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: MarcoZan on December 04, 2007, 05:07:04 pm
Hi all

here I put my 0,2 c.

I've nothing against Xine or Mplayer (and nothing special in favour of one of them)
My concern as a user and as a semi-tech is pretty performance oriented.

To me it is not that important if my videos are played by Xine or Mplayer, but it is very important to get decent performance even without having to buy a core duo box for each MD.

From what I've seen many of us are oriented to use small factor MD (the majority of which are VIA based, like Fiire Station), and this sounds as a very reasonable choice to keep cost not too high and to keep the whole system appealing to general audience.

So the choice between Xine or Mplayer (and in general all choices, regardless of "appliance" vs "package" vs "distro" perspective) should be driven by this consideration first, i.e. performances against "normal" hw.

In the specific case of video playback, Xine_Player already gave proof to be a bit unefficient (if I launch Xine itself outside LMCE it consumes way less CPU compared as when launched from LMCE ).

My fear is that a lot of efforts have been made to write a MPlayer_Player wrapper and (I'd happy to be wrong..) no effort has made to improve Xine_Player, so in the end we have a more complicated system that can play HD content but still has some glitches playing simple stuff.

Can anyone shed some light on this?

TIA
Marco

Title: Re: Appliance vs Package vs Distro
Post by: chrisbirkinshaw on December 04, 2007, 06:21:21 pm
Exactly. Development effort is being watered out adding more features which only partly work, rather than getting the current software to work properly. Though if the community want this then there's no real sense arguing about it. I guess people are voting by deciding to code things like mplayer support!

Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 06:31:34 pm
There are immediate concerns to be dealt with in the abstract Media Plugin itself!

open the code, look at the base Media_Player.cpp ....

experienced OO coders will almost immediately see the problem:

there are tons of if statements leaking knowledge of the plugins below into the abstract code, and killing off encapsulation, thus making a tight locked dependency with the plugins below (this is especially evident with the HD-DVD code, that explicitly short circuits the entire process to force mplayer to be used.), this is very wrong, and should be rectified immediately. I would like to say this is an isolated incident, but there are bits of stuff like this all over the code, written by coders who try to bandage on functionality to suit their immediate need, without trying to understand how to do it properly! (I would also argue that stuff like this would be completely avoided in a dynamic, late-bound language, the polar opposite of C++, but still...)

We need to refactor, and we need to do it as soon as we re-sync 0710 with Pluto, or we're going to have severe migraine sized headaches later on as we start to add the very functionality that some of you are describing!

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 04, 2007, 10:26:20 pm
Design choices are valued by their results in feature performance. But I also look at the costs of delivering those features over the long term. So I'm interested in whether MPlayer can assume all Xine's functions, now that MPlayer is (seems to be) a complete superset of them, and MPlayer is a much more active independent development project than the fairly inactive Xine project. Since the "bet on MPlayer" decision has already produced a wrapper for MPlayer that seems to give it architectural interchangeability with Xine,

These are considerations about choices for developers (like me). I don't think LMCE should have choices between different media players (or similar kinds of choices) available to consumers, except maybe at installation time. And even then, it's probably better for consumers to select one completely separately packaged installer for one combo of components that are selected for one scenario rather than a few alternatives defined by other usage scenarios, rather than letting an installer give them choices that will most likely confuse them. Mostly because different packaged scenario combos is easier to develop than some AI installer :).

If MPlayer is now actually interchangeable (with some reasonable quantity of straightforward porting), I'd like to investigate unifying the players into just MPlayer to factor and simplify that functionality. Especially because there are going to be more changes to the Media_Player API as more functions are integrated over time (eg. telephony functions in a UI while video plays, even videophone, or integrating videogames with other simultaneous A/V...). It'll be better for everyone if there's just a single media player to keep delivering those functions, rather than a stable of them, if that's possible.

Which is why I'm trying to find out whether Xine still offers any functions that MPlayer doesn't (the actual apps, not any possible fixable limits of their wrappers). If it does, and MPlayer is not really simply a superset of Xine functions, then there's no point trying to merge/factor them. But if there is, I'm interested. I don't expect anyone else to follow me, but if I do deliver a version factored to just MPlayer with all the functionality of Xine+MPlayer, then that's my own time wasted for everyone's benefit, right :)? That's what drives OSS: mutual interest in each other's pet projects. Or just talk me into helping with your pet project, because it's more interesting than mine.
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 10:35:55 pm
yes, lots. proper DVD menu support for one,

but again, you're missing the point...

The customer only cares if it does what it's supposed to do, the customer is NOT going to be selecting the media player, the software is!

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 04, 2007, 10:41:30 pm
Why don't you spend some time, actually looking through the code... and seeing how the system, for example, routes messages for media.

The reasons why the architecture is like this, will surprise you, because even at this point all of the different media delivery software out there is designed for different audiences, and different needs....

it was easier, for example, to use vlc and vls for media streaming...but there are situations for example, that nbd needs to be used (for example, to expose a DVDCSS protected DVD to a media director on the other side of the house, that's in a jukebox not even connected to the system that's playing it!), the system decides...not the user...the best path through the network of devices, plugins, and players needed to accomplish a goal.... and I suggest spending a month or two, (I've spent much longer), studying the code itself...because otherwise, you're in way over your head.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 05, 2007, 12:19:21 am
Why don't you spend some time, actually looking through the code... and seeing how the system, for example, routes messages for media.
Well, that's worthwhile, though it won't really answer the question "what does Xine still do that MPlayer can't?" At least not nearly as effectively as getting some more experienced developers, like perhaps yourself, to dump to web pages how that stuff works, as any kind of guide.

The more I look at the project, the more it looks like the most productive help the community could get at this stage would be a note attached to every bug in Mantis indicating how the reported use case's critical path calls which series of code scopes, or at least which files, or at least which function is called by a GUI init. There are only a couple dozen block || crash || major bugs in Mantis, they've practically all got developers assigned to them. If each of those people just noted which files are (the most likely culprits) in the scope of the debuging task, then other people could help, and it would all be the best intro to the code.

If you want to kick it off, would you mind updating the Xine wiki page to mention the Xine_player wrapper, Media_player.cpp , whatever generates the Orbiter and Adminsite GUIs with controls that trigger Xine, the glue code from the GUIs to the Media_player.cpp ? Or at least just which code the GUIs call that eventually calls Media_player.cpp which then calls either Xine or MPlayer. This abstract discussion should be in terms of the code, and more veteran's time should be spent tipping off newcomers to which code, so we can work togther.

As another example, this Xine vs MPlayer redundancy looks like a similar redundancy/drift problem is polluting the code that rips CDs (http://mantis.linuxmce.org/view.php?id=3495). There appears to be different code for ripping from an IDE CD-ROM than the code for ripping from a jukebox, different code for ripping multiple CDs or just a single CD from the jukebox. Some of those 3 use cases are properly using the target format configs, but the "rip multiple" is not. If the redundancies were factored out, that bug would be much easier to fix, if it appeared at all. Of course the code actually needed to accommodate single ripping for either IDE and jukebox might be one program, and multiple jukebox rip another, or more likely ripping IDE should be separate from single/multiple (with modes) jukebox, or probably the best is simply a single ripper that calls different HW as specified, wrapped in a loop. To say nothing of the factoring that would mean I don't have to set the rip target format in the Adminsite, then switch to the Orbiter to actually rip. I would be fixing (perhaps totally rewriting) that code right now (I already did something just like it for my old custom system), but my bug report hasn't even been touched.

The more I think about it, the more it seems this project would benefit most from people familiar with the code just walking through the bug reports and noting which files are the likely culprits for others to investigate.

but again, you're missing the point...

The customer only cares if it does what it's supposed to do, the customer is NOT going to be selecting the media player, the software is!

FWIW, I specifically said the user shouldn't be picking the SW, so I don't think I'm missing the point at all. I'm just talking about simplifying the architecture so it doesn't support two redundant video players, just because a new one was added for its increased functionality without removing the other superfluous one. Which is a benefit to developers, who can then bring benefits to users.
Title: Re: Appliance vs Package vs Distro
Post by: tschak909 on December 05, 2007, 12:41:15 am
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.

-Thom
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on December 05, 2007, 03:24:11 am
Quote
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 (http://wiki.linuxmce.org/index.php/History)). I thought getting it into package form was already agreed upon?
Title: Re: Appliance vs Package vs Distro
Post by: dopey on December 06, 2007, 11:34:27 am
Wow, this turned into a rather heated debate...

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)...
Title: Re: Appliance vs Package vs Distro
Post by: chrisbirkinshaw on December 06, 2007, 06:57:27 pm
I agree with all the points in the post above.

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.

Thoughts?

Chris


Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 06, 2007, 09:41:37 pm
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 (http://wiki.linuxmce.org/index.php/A_new_concept_in_collaborative_development).  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.
Title: Re: Appliance vs Package vs Distro
Post by: dopey on December 07, 2007, 01:12:00 am
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 (http://wiki.linuxmce.org/index.php/A_new_concept_in_collaborative_development).  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.
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on December 07, 2007, 05:41:08 am
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.
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 07, 2007, 07:21:05 am
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?
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on December 11, 2007, 02:01:10 am
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.
Title: Re: Appliance vs Package vs Distro
Post by: darrenmason on December 11, 2007, 04:16:36 am
rstuart - Couldn't agree more.

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.
Title: Re: Appliance vs Package vs Distro
Post by: hari on December 12, 2007, 12:16:45 am
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.

best regards,
Hari
Title: Re: Appliance vs Package vs Distro
Post by: rstuart on December 12, 2007, 01:14:58 am
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.
Title: Re: Appliance vs Package vs Distro
Post by: hari on December 12, 2007, 01:23:53 am
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
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on December 15, 2007, 12:01:27 pm
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... ;-)
Title: Re: Appliance vs Package vs Distro
Post by: Matthew on December 15, 2007, 04:13:22 pm
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.

Happy holidays - peace on Earth, goodwill towards development.
Title: Re: Appliance vs Package vs Distro
Post by: hari on December 15, 2007, 04:58:07 pm
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).
Nobody said that deploying lmce is rocket science. It's the amount of code that makes things complex. Nothing in there is hard to compile..
Quote

[...]

can we now please concentrate on developing lmce further in here? I think some of you are missing a "community talk" forum.

regards,
hari
Title: Re: Appliance vs Package vs Distro
Post by: totallymaxed on December 15, 2007, 05:10:30 pm
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).
Nobody said that deploying lmce is rocket science. It's the amount of code that makes things complex. Nothing in there is hard to compile..
Quote

[...]

can we now please concentrate on developing lmce further in here? I think some of you are missing a "community talk" forum.

regards,
hari

Hari... thats exactly my point... The DCERouter on its own is no test... its the complexity of the whole of LinuxMCE that is the challenge. But if there are like minded people who are motivated to do it they will.