Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Matthew

Pages: [1] 2 3
Developers / Adding DB Access to Orbiter
« on: February 04, 2008, 10:08:01 am »
I'm trying to add database access to the Orbiter. Specifically, I'm trying to add it to the ScreenHandler class, where it sends the Bulk Rip message to the Powerfile_C200 in ScreenHandler::JukeboxManager_ObjectSelected() , to get the rip target format defaults. So I'm trying to add a database connection to the ScreenHandler constructor, which can be queried later in the code right before composing the message to be sent. But I'm having problems just adding a database object to the ScreenHandler class.

I'm modeling the code on the WizardLogic.cpp code that does the same thing. I'd reuse the WizardLogic code and its DB querying functions, but AFAICT the WizardLogic has an Orbiter, but there's no backward reference to the WizardLogic in the Orbiter, that the ScreenHandler could get from the ScreenHandler::Orbiter . So I just try to add a Database_pluto_main * member to the ScreenHandler , as a protected member Database_pluto_main *m_pDatabase_pluto_main; in ScreenHandler.h , and m_pDatabase_pluto_main = new Database_pluto_main(LoggerWrapper::GetInstance()); in ScreenHandler.cpp . I add #include "pluto_main/Database_pluto_main.h" to each of ScreenHandler.{cpp,h} .

But when I (cd src; make all) , I get

Code: [Select]
../Orbiter/ScreenHandler.o: In function `ScreenHandler':
/opt/lmce/src/Bluetooth_Dongle/../Orbiter/ScreenHandler.cpp:69: undefined reference to `Database_pluto_main::Database_pluto_main(DCE::Logger*)'
/opt/lmce/src/Bluetooth_Dongle/../Orbiter/ScreenHandler.cpp:69: undefined reference to `Database_pluto_main::Database_pluto_main(DCE::Logger*)'
collect2: ld returned 1 exit status
make[1]: *** [Bluetooth_Dongle] Error 1
make[1]: Leaving directory `/opt/lmce/src/Bluetooth_Dongle'
(FWIW, the Makefiles requiring rebuilding dozens of object files when only ScreenHandler.cpp changes is a real hassle. And what's Bluetooth_Dongle doing rebuilding the ScreenHandler when only the ScreenHandler has changed?)
As a test, I change the ScreenHandler.h declaration to int m_pDatabase_pluto_main; and then in ScreenHandler.cpp I replace the creation of the new Database_pluto_main with just m_pDatabase_pluto_main = 32; . When I (cd src; make all) , it compiles and links without complaint.

I don't know why the linker isn't finding the definition of  Database_pluto_main in pluto_main/Database_pluto_main.h as #included in ScreenHandler.h .

Any ideas?

Users / New 0710 Release Date Target?
« on: January 30, 2008, 09:35:01 pm »
I'm not trying to make the 0710 release come any faster (though I'd like to :)). But we don't have any indication of a target release date for 0710. We started in October with an "endo f November" release date. We went through December thinking "maybe by Christmas" but sometime in January if not. Now January is over.

Can we get a new target date? It'll be easier to keep on going if someone credible can make an estimate.

Also, by the end of February we'll be only a month away from the next release of Kubuntu, which would be numbered 0804. So maybe "0710" will never come out, if we add "upgrade to Kubuntu 0804" to the requirements for the next version.

Developers / to SVN?
« on: January 27, 2008, 02:46:06 am »
I see that Ender fixed  Mantis bug#3839: Cisco 7970 does not come up after configure with a new . Any reason it's not in SVN, where we could get it with the rest of 0710b3?

(I'd PM Ender, but their mailbox is full.)

Developers / Code Where Orbiter Sends DCE Event?
« on: January 25, 2008, 03:21:11 pm »
I'm working on debugging Mantis bug#3495, "0003495: DVD Changer rips CD's only with OGG". I've found in part of the codepath that the CD/DVD changer device (VGP-XL1B) works properly after getting a faulty command from DCE to rip with an empty target format string (which then defaults in the Powerfile_C200 code to OGG). But I'm having trouble finding where the format is not specified when initiating that command upstream. I don't know whether the format is specified (or should be) in the Orbiter code, or whether the DCERouter makes (or should make) another loop on receiving the Orbiter event by sending a command to some configuration device to further populate the command sent to the changer, or whether some other point in the critical path is failing to retrieve the format from the database (which seems to have the format successfully stored by the Adminsite).

Can you help me find where the Orbiter sends the event that gets logged in /var/log/pluto/DCERouter.log that seems to be missing params 20 (Format) and 157 (Disks: slot number list or "*")?
Code: [Select]
08      01/21/08 18:14:06.135           Received Message from 20 (OnScreen Orbiter / Bedroom (Master)) to 33 (VAIO DVD Changer / Bedroom (Master)), type 1 id 720 Command:Bulk Rip, retry none, parameters: <0x77804b90>
08      01/21/08 18:14:06.135             Parameter 13(Filename): /home/public/data/___audio___or___video___/ <0x77804b90>
08      01/21/08 18:14:06.135             Parameter 17(PK_Users): 1 <0x77804b90>
05      01/21/08 18:14:06.135           The target device 33 (routed to 33) has not registered. <0xb6c46b90>

Developers / Tracing Codepaths?
« on: January 21, 2008, 07:31:03 pm »
I'm trying to trace the codepath that ends up executing . I'm looking for where the target rip format that's stored in the DB by the Adminsite "Installation Settings" form is (or, since it's buggy, isn't) is retrieved from the DB and passed to the commandline in Disk_Drive_Functions/RipTask.cpp .

I'd love some insight from someone who knows that code, but I'd settle right now for some simple tool to trace codepaths in LMCE as a whole. I don't want to have to use gdb unless I must, because I don't want to spend the time building all of LMCE (or even lots of its modules) with gdb symbols. I'd rather use some lexical code analyzer. And, if possible, keep my programming tools limited to grep, find, vi and make. Any suggestions?

Developers / UI3 Discussion
« on: January 15, 2008, 06:49:29 am »
Aaron B (Pluto CEO) posted a long examination of his thoughts about the next version of the Pluto/LMCE GUI, that he calls "UI3" (not the UI2/alpha-blended that people sometimes call UI3), in the wiki article "UI3". We can discuss it in this forum topic. Here's the current version of the article:
Quote from: aaron.b

Macromedia Flash has become the defacto standard for creating user interface's for the web, with a rich development environment to create an appealing UI, and an efficient player to do the rendering with lot's of eye candy and visual effects. Media centric applications with 10' user interfaces ("MCE apps") have the same needs, but there really does not exist any software that can do this for desktop applications, like Flash does for web applications.

A few MCE apps try to use Flash for their user interfaces. But this does not work very well since this isn't Flash's intended purpose. For example, the UI in a MCE app cannot be stand alone and isolated, rather it must be a UI that floats on top of whatever media the MCE app is delivering. The Flash player is not able to blend it's rendered output on top of the media application, like Xine or MythTV. So although you could create a really attractive EPG program guide in Flash, you cannot blend that guide on top of the live TV in MythTV.

Therefore, nearly all the MCE applications, like Xine, Myth, Windows MCE, etc., typically code their own UI's. This is inefficient; it is like re-inventing the wheel each time. And, most of the time, the developers are more focused on their core application, not the UI, and cannot create a rich UI engine. For example, Xine, MythTV, Mplayer, Freevo, etc., all have their own UI's, but none are rich with eye candy and visual effects. In general, only Microsoft has been able to develop a really eye-candy rich UI with lots of visual effects, and most other media center applications have fairly boring, static UI's, even if the core media application itself is rich. For example, while MythTV developers began implementing a rich OpenGL UI engine over two years ago, this is still only used for some of the menu system and had not been extended to the video overlay or plug-ins, and because there is no UI editor the capabilities of it's graphics engine go largely unused.

The goal, therefore, is to create (1) a UI player, like the Flash player, which is efficient and can render high-res, 3d, user interfaces with lots of eye candy on a variety of platforms (x86 Linux/Windows, PDA's, cell phones, etc.), and (2) a comprehensive development environment, like the one Macromedia developed for Flash, that is well documented and not overly technical so creative designers can use it to build innovate UI's.

The intention is that this can be used to create UI's for a variety of MCE apps, like MythTV, MPlayer, etc., and that unlike Flash which is designed to run as an isolated application, this UI will be designed from the ground up to bolt on top of the core MCE app. In other words, you can create a beautiful EPG, like you could with Flash, but it can be blended on top of MythTV's live tv feed and used to control MythTV. The UI tool should be modular and flexible so graphics designers can create interesting UI's without needing the help of the coders of the core MCE app. For example, a designer could create, say, an innovate 3d TV program guide on a rotating sphere and add it to MythTV without needing the MythTV developers to write new code. Having a unified UI will also allow us to address some of the vexing issues, like text entry using remote controls of various types, with new UI widgets which only need to be learned once for the entire class of 10' applications.

It is understood that this is a big, complicated task which hasn't really been done before. However, we feel it is an important gap that needs to be filled. The first thing most end users notice is the eye candy in the UI and how pretty it is, and only Apple and Windows Vista have had the resources to create such UI's. This will allow other MCE apps to have UI's that are just as catchy and the developers can focus on the core functionality.

Target user / financial model

Naturally this tool would be an asset to the FOSS MCE apps, like MythTV. However, there are many commercial applications as well. For example, only TiVo and Moxi have created rich UI's for their PVR's. There are tens of millions of PVR's out there from Motorola and Scientific Atlantic distributed by the cable operators, but they cannot justify the huge expense of creating a rich UI, so in general they have ugly, plain, static UI's. If there were an inexpensive, easy way to add a beautiful UI to these PVR's it would be worth it. Also, most TV's have a user interface for on screen menu's that is static and boring even though the TV's themselves have graphics processing chips in them that have the power to render a rich UI. There are numerous DMA's and set top boxes as well that could benefit from a rich UI as well. Mobile phones and PDA's also have media players and mini MCE apps.

In general these UI's are powered by a few single chip solutions, such as Sigma Designs, Broadcom and Marvell, and specialty chips for TV's, like AMD's Xillion. Macromedia Flash's player has been ported to many of these platforms so you can, for example, navigate a flash UI on a mobile phone. But, again, since Flash doesn't work well with MCE apps, in general these MCE apps all have crude, basic UI's, or they look to specialized middle-ware providers like Syabase, Mediabolic, Digion, etc., to create a UI for them.

The UI player will first be developed for X86, probably Linux and Windows in parallel. The software would be developed in such a way that the UI itself was subject to the GPL license, so there is an immediate potential to license the UI player for some commercial MCE apps. There's concern, for example, that SageTV will have a hard time remaining viable since it just doesn't have the pretty UI that Windows MCE does. They would be a potential customer to license the UI player outside the GPL since they would not want to release their UI under the terms of the GPL.

Over time the UI player could be ported to other platforms, like the Sigma, Broadcom, etc. Then the makers of set top boxes could use the UI generator to build rich UI's which could be played back on those set top boxes. By being cross-platform, we would have a strong advantage because the UI developer could target any platform for which the player existed, like Flash developers do now. Also, by being open source, the barrier of entry would be quite low. Anybody could start using the tool set, build it upon it if needed to add new visual effects, and only need to license it when they wanted to deploy a commercial application. And there would not be a concern of being locked into a closed, proprietary solution like the existing middle ware providers.

This relates to Pluto's core business of licensing an interoperability platform. Once a company adopted the use of the UI, Pluto would be able to offer a variety of modules, like lighting control, telephony, etc., that could easily 'bolt on' to the UI delivering a lot of extra functionality without writing any specialized code. If SageTV, for example, used the UI as their front end, Pluto could then offer lighting control modules, some to view security cameras, make phone calls, etc. which could be added to the SageTV package without them writing any new code. Pluto will be willing to sponsor the development of this new UI in exchange for receiving a license allowing Pluto to commercially license the UI software outside the GPL.

If QT is providing the underlying graphics library and hardware abstraction, then this benefits Trolltech as well because every commercial user who didn't want to release the UI under the GPL would also need to obtain a license to QT. The hope is that QT would also have an interest in furthering the development of this software.

How this relates to LinuxMCE

The UI in LinuxMCE, Orbiter, was developed to accomplish this same task. It has succeeded in some ways. For example, LinuxMCE's UI can be played on both Linux and Windows pc's, web pads, pda's, mobile phones, desktop phones, and web browsers. All those platforms are rendering the same UI and same set of screens created with a single design tool, called Designer. The problem is that Orbiter and Designer were created nearly 5 years ago, and were not very well designed. They are still quite crude. Designer is nearly impossible to use and does not appeal to graphic designers. The limited eye candy and visual effects in LinuxMCE, like the 3d cube media browser, are hardcoded into the player, Orbiter, rather than being part of the design as they should be. So, Orbiter and Designer are not general purpose enough to be useful to other MCE apps.

Skill sets needed

Here are 4 groups we need:

  • First we need people who really understand how to design a great UI. These could be Flash designers who have created rich UI's before. They need to outline what the new UI software must do to appeal to the designers that will be building the UI's. That is the most essential thing since, if designers are creating, say beautiful, rich TV program guides with this software, it will be easy to approach the commercial PVR makers and show them why they need to use this UI in their product. So this team is more composed of graphic designers, not C++ coders.
  • Next we need to know how to develop the UI design tool. There will be a lot of overlap with #1 since the people in #1 will be the users of the code written by this group. The UI design tool will not need to be cross platform. Windows/Linux x86 is acceptable. But it will have to be logical and similar to other design tools, like Macromedia's flash development tools, so designers can start using it without a steep learning curve.
  • Next we need people who create MCE apps and know what the player must do to integrate well with those apps. For example, what are the low level C-language hooks the player must have to handle alpha blending the UI on top of MythTV. What is the socket-based control needed to allow the player and MythTV to seamlessly communicate as though the player were developed as part of MythTV, so the user is not aware that the UI is in fact a separate piece of software.
  • The player needs to be highly efficient using a lot of the tricks that the video game industry uses to create high res 3d effects with smooth animation. For this we need some people who understand the Windows Direct X architecture, as well as the OpenGL fragment programs used by Linux and OS X, and some of the single chip solutions, so the player can be designed in such a way that as much code as possible is shared across all platforms, yet the player takes advantage of the unique hardware acceleration tricks each platform offers to be lean and efficient.

Proposed next steps

Some of the people needed will be in the Bay Area anyway for the KDE/Google event on Jan 18. We propose having a mini developers conference on Jan 19th. Pluto has agreed to sponsor this and provide airfare and accomodations to some key people, as well as pay change fees for some already at the KDE/Google event who want to stay an extra day.

The goal is to get representative people from the four skill sets to brainstorm some of the general concepts and come up with an organizational structure and delegate responsibilities. Also, key developers could be chosen to be sponsored full time.

We would also like to finalize an agreement with Trolltech so that if a committment is made to use QT as the underlying library for this new UI, it can be determined how Trolltech and Pluto will work together on the commercial licensing, and what resources Trolltech is willing to commit to the project.

Users / Motion Detection Cameras for Presence Detection?
« on: January 15, 2008, 12:19:53 am »
Is LMCE's existing support for motion detection cameras, used for alarm systems, a suitable foundation for supporting presence detection? So the cameras would always watch the rooms, and detect in which rooms there were people, and activate MDs, lights etc. Maybe even watch people leave, and switch from media/automation service into alarm mode until deactivated. Can it be calibrated to ignore moving pets, and just track people's presence in different rooms?

If it were really good, it could register users and track them individually, maybe by facial recognition. Or maybe people could wear watches or other jewelry/accessories that let LMCE distinguish among them. That's pretty far out, but even just telling whether there's >0 people in a room for more than just an alarm would be valuable.

Users / LMCE as DNS Server?
« on: January 14, 2008, 05:29:42 pm »
How do I use LMCE as the nameserver for my LAN? Independent of using DynDNS so Internet hosts could find my LAN hosts by FQDNs published on the Internet, how can I just replace the /etc/hosts file on each of my LAN hosts with DNS management that's published only on my LAN?

Developers / 0710b2 Build Errors
« on: January 13, 2008, 02:54:54 pm »
I downloaded the source from the Charon Media SVN according to the wiki "Source Code" article:
Quote from: [url=]Source Code: Current Source[/url]
# Download snapshot (391MiB)

# Test checksum to ensure it was downloaded intact.
md5sum lmce-1465.tbz # should be b3d4b3f6b33ff5e6c4641390f2314095

# Update snapshot (uncompressed: 1823MiB either snapshot or updated).
tar xfj lmce-1465.tbz
cd lmce
svn update

# Build from source (optional) to 3692MiB, total source+build = 5515MiB.

 I get some build errors (in KDE, launch_manager, and SimplePhone)
Quote from: make
checking for KDE... configure: error:
in the prefix, you've chosen, are no KDE headers installed. This will fail.
So, check this please and use another prefix!
make[3]: *** No targets specified and no makefile found.  Stop.
make[3]: Entering directory `/opt/lmce/src/lmce/src/lmce_launch_manager'
make[3]: Leaving directory `/opt/lmce/src/lmce/src/lmce_launch_manager'
cp: cannot stat `src/lmce_launch_manager': No such file or directory
make -f Makefile.cvs; LDFLAGS="-L../../lib" CPPFLAGS="-I../../ -I../../DCE -I../../Gen_Devices" CXXFLAGS="-O0 -g3" ./configure; make ; cp src/lmce_launch_manager ../bin/lmce_launch_manager  ***FAILED***
Error: make -f Makefile.cvs; LDFLAGS="-L../../lib" CPPFLAGS="-I../../ -I../../DCE -I../../Gen_Devices" CXXFLAGS="-O0 -g3" ./configure; make ; cp src/lmce_launch_manager ../bin/lmce_launch_manager  failed!
Continue anyway? [N/y]
make -f Makefile.cvs; LDFLAGS="-L../../lib" CPPFLAGS="-I../../ -I../../DCE -I../../Gen_Devices" CXXFLAGS="-O0 -g3" ./configure; make ; cp src/lmce_launch_manager ../bin/lmce_launch_manager  succeeded
***ERROR*** The file: /opt/lmce/src/lmce/src/lmce_launch_manager/src/lmce_launch_manager was not created.Continue anyway? [N/y] y
/opt/lmce/src/lmce/src/lmce_launch_manager/src/lmce_launch_manager exists
Continue? [N/y] y


***WARNING B*** /opt/lmce/src/lmce/src/bin/lmce_launch_manager not found
Continue? [N/y] y


***WARNING B*** /opt/lmce/src/lmce/src/bin/SimplePhone not found
Continue? [N/y] y

I haven't installed the built LMCE, so I don't know whether that KDE error or launch_manager error actually break the final platform (SimplePhone is not a critical component for me right now, but I want to eventually have it right if it's part of the standard distro, and as a test when I get my Cisco 7970 hardphone up and running). But I'd like the install to "just work".

Also, the install takes something like 5-6 hours on a P4/2.4GHz/512MB. That seems excessive, though it's building a hell of a lot of the bundled apps that make LMCE so featureful. But since most of those are available as Debian binary .deb packages, can't an installer just use those, rather than building from source (except as a final option, after the rest is tested and tweaked)? If there's a half-dozen (and eventually hopefully hundreds) of developers building, won't the "self-hosted build environment" at the LMCE project servers supposedly coming with 0710 just get swamped at a fraction of the developer community scale if it's building every external package from source, instead of just installing its binary .deb package?

Users / Sony PS3/PlayTV PVR?
« on: January 11, 2008, 11:19:19 pm »
Like others in this community, I've been thinking that the Playstation 3 could be an excellent MD. There's an MPlayer driver that uses the SPUs for accelerated video, and generic X (2D) acceleration has been initially delivered (though with some setbacks).

Sony is about to release PlayTV, which is a TV capture PS3 accessory that will support 1080p. It's due for release March 28, 2008 in Europe for E155. Is anyone preparing to use this platform for LMCE?

Developers / Where the Source Code Lives
« on: January 10, 2008, 06:55:56 am »
The LMCE source code seems like it lives in the Charon Media SVN, but the LMCE wiki "Source Code" article points to a SourceForge SVN. Is Charon Media the actual source? If so, I will update the wiki.

Developers / Adding "State Changed" Event to Floorplan
« on: January 09, 2008, 02:02:15 pm »
Discussion of  "    
Proper support for state devices (blinds,dimmable lights,etc..)
" progressed into Mantis bug 0003456: Adding generic "state changed" event would ease support for new various devices to LMCE. Discussion there is about to implement such a change, but there's some more discussion before leaping to the coding keyboard. Let's discuss it here before returning to the Mantis discussion with a more specific plan in mind, for the much more focused discussion that is appropriate to Mantis.

The latest state of play:

Users / Economical Insteon+X10 HA?
« on: January 06, 2008, 05:24:03 pm »
Insteon looks like the best HA control system, but it's expensive. A "cheap" plug-in lamp module is a minimum $25, which at 150W probably supplies at most 2-3 lamps (a 300W module is $35). But lamps are often $10-20 themselves, so the controller adds something like 50-100% to the price at the low end (which is where most lamps fall). And that's for controlling a bank of lights as a unit - real scenarios would call for a $25 module for each lamp, or hundreds/thousands of dollars for a decent sized home (that could most benefit from automation).

X10 is a much cruder form of control, but it's much cheaper. An X10 lamp controller is as little as $4 (cheaper than that would be hard to ask for).

Insteon controllers are supposed to be completely backwards compatible with X10 modules, so X10 modules should be treatable as cheap, low-function additions to a higher quality Insteon network. Is that really true? Is there any benefit to using an Insteon module where a cheaper X10 module will be sufficient?

Users / Installing 0710b2 from DVD ISO *File*
« on: January 05, 2008, 09:32:52 pm »
0710b2 is distributed as a DVD ISO file, but it's too big (~5.5GB) to burn on a single-layer (4.7GB) DVD. So I'm trying to install from the ISO file, as some have reported in the forums doing successfully. But so far it's not working.

I'm starting from instructions for installing Gentoo from a USB Flash drive. The process is basically to create a bootable HD partition containing the DVD files, then booting into that. But the original (0704) LMCE bootable partition continues to boot, not the new 0710 partition.

Here's my steps. If someone can correct them, I'd appreciate it.

# Partition the LMCE HD (>6GB).
  # If there's a usable existing partition, use it (empty it first).
  # If a new partition is necessary, create one from unpartitioned space if there's enough. If an existing partition has enough empty space, shrink it with parted first. A safe and convenient method is to use the GParted liveCD, which is especially helpful when the existing partitions don't allow you to unmount a target to be resized while still accessing files needed on it (eg. a single Linux partition).
  # Since the bootloader used is syslinux, which requires FAT, and the partition is >4GB, the filesystem should be FAT32 (mkdosfs -F 32 /dev/<partition>) .
  # Mark the new partition "active" (bootable), and mark the old boot partition unbootable (eg with g/parted or with fdisk).
# Install an MBR.
  # LMCE's installed version of syslinux doesn't include the mbr file, but the Ubuntu 0710 (Gutsy) version does. So you have to download the syslinux package, use ar to extract its data.tar.gz file, then use tar to extract its usr/lib/syslinux/mbr.bin file.
  # Copy the mbr to the partition (dd if=/usr/lib/syslinux/mbr.bin of=/dev/<partition>) .
# Mount the DVD ISO.
  # mkdir -p /mnt/dvd
  # mount -o loop,ro -t iso9660 kubuntu-linuxmce-0710-i386-beta-2.iso /mnt/dvd
# Mount the HD partition.
  # mkdir -p /mnt/target
  # mount -t vfat /dev/<partition> /mnt/target
# Copy the DVD files to the HD partition.
  # cp -r /mnt/dvd/* /mnt/target/
  # mv /mnt/target/isolinux/* /mnt/target/
  # mv /mnt/target/isolinux.cfg /mnt/target/syslinux.cfg
  # rm -rf /mnt/target/isolinux*
# Unmount the ISO and partition.
  # umount /mnt/dvd; umount /mnt/target
# Install the bootloader.
  # syslinux /dev/<partition>

That all seems to make sense. I ran it against /dev/sda3 (a newly created 6.4GB partition). But when I do it, the system just boots into LMCE 0704 (from sda1). Which is a mystery, because fdisk shows the drive's partition table flags sda3 as bootable, but not sda1.

Also, when 0710 comes up, there's some networking problems. (ifconfig -a) shows eth0 configured as the outside LAN segment, but the old eth1 is gone, and eth2 exists but is not up. And the DHCPd fails to start, running (/etc/init.d/dhcpd3-server) fails with a "Fail" message (but no details).

What's wrong with this picture?

Users / Ubuntu Home Server
« on: January 05, 2008, 07:42:42 pm »
I'm posting a new topic, forking from a post about the Ubuntu Home Server project that was offtopic in "Re: Media Storage Idea", copying that original post. Please continue discussion of it in this topic.

This project is coming along nicely:

I hope that both of these projects do not try to do to much (focus on getting the things they can perfect) but in the future could work together to make one hell of a system.  I like the security of the UHS, the GPL, and its data storage capabilites.  I like LMCE to play media and automate the house.  I worry about security in LMCE.

That UHS project is designed to make Ubuntu 0804 include more features for the home, including simpler GUIs for administering services for a networked multimedia home. Since LMCE is supposed to be a further packaging on top of Ubuntu, there's no reason they can't work together, if designed properly modularly. They each need to be able to omit their specific chosen components in favor of workalike substitutes that meet the same API. And their installers need to be complementary.

So UHS needs to be able to use the LMCE component where the two projects present alternatives. And LMCE needs to be able to install as packages onto UHS the way it currently does on Kubuntu, but also select (and substitute) between packages where they conflict between the two. The Debian/Ubuntu APT installation system accommodates that requirement well, so if it's used properly we can do it. But the main upgrade to LMCE is just being able to upgrade an LMCE's underlying Ubuntu against the Ubuntu repository systems, including a new Ubuntu version, without trashing the rest of LMCE. LMCE 0710 is supposed to allow that. If it does, integrating the two complementary systems will be fairly straightforward.

And beneficial. Mainly because there would be a larger, unified community of developers, who could work together on the unified set of tasks. And because the "conflicts" in each project's selections for functions also offer more choices, therefore appeal to a larger group of users who might prefer one or another choice. And also because the requirements for the integration would improve the overall robustness of each project, more integrable not only with each other, but also with other possible systems, either current or to come in the future.

I recommend people participate in this discussion in each project's forums. The UHS project started in reference to LMCE back in May, so we're catching up with them in cooperation. Even if the UHS project dies, it's worth looking at for more features and robustness as a home solution. Thanks for bringing it to our attention.

Pages: [1] 2 3