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

jester

  • Regular Poster
  • **
  • Posts: 24
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #15 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 ;) )

teedge77

  • Addicted
  • *
  • Posts: 591
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #16 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.
AMD Athlon 64 X2 6000+
Asus M2V Via AM2 ATX
Lite-On LH-20A1S SATA DVD Burner
80GB  SATA-150
EVGA GeForce 7300 GT 512MB DDR2 PCI Express
Sound Blaster Audigy SE
Kingston 2 GB PC6400 DDR2 800MHz
Ultra X-Finity 800-Watt
ZCU000
Cisco 7970
TDM400P

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #17 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

teedge77

  • Addicted
  • *
  • Posts: 591
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #18 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.
AMD Athlon 64 X2 6000+
Asus M2V Via AM2 ATX
Lite-On LH-20A1S SATA DVD Burner
80GB  SATA-150
EVGA GeForce 7300 GT 512MB DDR2 PCI Express
Sound Blaster Audigy SE
Kingston 2 GB PC6400 DDR2 800MHz
Ultra X-Finity 800-Watt
ZCU000
Cisco 7970
TDM400P

totallymaxed

  • LinuxMCE God
  • ****
  • Posts: 4660
  • Smart Home Consulting
    • View Profile
    • Dianemo - at home with technology
Re: Appliance vs Package vs Distro
« Reply #19 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.
Andy Herron,
CHT Ltd

For Dianemo/LinuxMCE consulting advice;
@herron on Twitter, totallymaxed+inquiries@gmail.com via email or PM me here.

Get Dianemo-Rpi2 ARM Licenses http://forum.linuxmce.org/index.php?topic=14026.0

Get RaspSqueeze-CEC or Raspbmc-CEC for Dianemo/LinuxMCE: http://wp.me/P4KgIc-5P

Facebook: https://www.facebook.com/pages/Dianemo-Home-Automation/226019387454465

http://www.dianemo.co.uk

rstuart

  • Newbie
  • *
  • Posts: 10
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #20 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.

hari

  • Administrator
  • LinuxMCE God
  • *****
  • Posts: 2428
    • View Profile
    • ago control
Re: Appliance vs Package vs Distro
« Reply #21 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
rock your home - http://www.agocontrol.com home automation

Matthew

  • Douchebag
  • Addicted
  • *
  • Posts: 567
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #22 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.

darrenmason

  • Addicted
  • *
  • Posts: 529
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #23 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

Matthew

  • Douchebag
  • Addicted
  • *
  • Posts: 567
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #24 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?" which is probably a better place to discuss Xine vs MPlayer.
« Last Edit: December 04, 2007, 01:50:30 am by Matthew »

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #25 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

Matthew

  • Douchebag
  • Addicted
  • *
  • Posts: 567
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #26 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)?

darrenmason

  • Addicted
  • *
  • Posts: 529
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #27 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.

Hagen

  • Guru
  • ****
  • Posts: 437
  • LMCE wannabe user
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #28 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.



chrisbirkinshaw

  • Guru
  • ****
  • Posts: 431
    • View Profile
Re: Appliance vs Package vs Distro
« Reply #29 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?