Hi, I'm a bit distressed by the lack of clarity when we talk about the reference agent. There are really three pieces to it: 1. A hardware profile 2. A set of installation and configuration scripts 3. The Java code that does the work
>From my perspective, part 1 is old. Part 2 is a pain in the back to manage, >since it involves changing things for new OSes. Part 3 is, imo, rock solid. >I don't know of any failures in our 1000+ recording setup that have been from >something other than hardware, though I'm not privy to the details and only >have discussions on Adam to go with. That Ben couldn't get a reference agent running does boggle my mind. Galicaster install docs say "install x packages" and "run on an i3 or better". This should work for Matterhorn too if you're using the same hardware, we share the same underlying video processing library, so I am surprised if there is much more than just installing java as well that was needed. When adopters ask for support I say "post to the mailing list, someone there will likely be able to help". What I see you suggesting is saying "go to a different community, we don't' do that". My comments about the player/media processing were not meant as a suggestion but as a comparison; if we axed a player component from Matterhorn I would be similarly distressed. To me, Matterhorn is not just a set of scripts around ffmpeg to process video, but is a novel turn key solution for lecture capture and media distribution in higher education. I think backing away from this stance is a strategic miss-step, and that's why I don't support this proposal. I agree completely with you and Tobias that it is incumbent on institutions who see value in a component to invest in it. That's how it has been with everything. So if the proposal is: 1. Lets get rid of our install scripts, they are too much work and we can just doc things on the wiki 2. Lets get rid of the reference hardware and just list it as something that is known to work I'm all for that. If the proposal is: 1. Lets quit working on the codebase and let it get out of sync with the core I'm against that. We have lots of vendor partners and should celebrate them and make our adopters aware of them (we're looking at them too!). But indicating we're not in the business of producing an open source community-developed lecture capture system is a mistake. I'm also under the impression that others are using the reference code, UCB, UCT along with you and I. But maybe this isn't correct, I wasn't in San Diego where I assume things were discussed in more detail. Regards, Chris ________________________________________ From: [email protected] [[email protected]] on behalf of Ruediger Rolf [[email protected]] Sent: 07 February 2013 10:10 To: Opencast Matterhorn Cc: Matterhorn Users Subject: Re: [Matterhorn-users] [Opencast Matterhorn] Discontinue the Capture Agent? #proposal Hi Chris, I would say that we are even currently in nearly the state that I would expect as an outcome as an official outcome of this proposal. We currently have only very few resources to work on the CA. So it is already stuck in a status where it is nearly unusable for newcomers. And even experienced developers do not know recent hardware where it is working on. Benjamin tried to create a CA with a cheap recent computer that we bought in a computer store close to campus last week. Ubuntu 10.04 does not work on this machine anymore (like on recent Dell models). So we switched to 12.04. The we needed to find a capture card. Again our old reliable Hauppauge PVR 150 are no longer available and even BT878 cards are not easy to get these days, so he decided to use an Hauppauge HVR card that works but has some downsides. I guess that Waldemar and I would have managed to get this setup running with some manual configuration. But even Benjamin as an experience user/dev of Matterhorn failed and decided to use Galicaster instead - with some minor problems too, but at least this worked. In general the current CA works well for USASK and for UOS as we have people who know these devices very good and we have old hardware that is well know to work with the reference CA. But what do you tell adopters that ask you for some support? You suggested to get rid of other Matterhorn components, like the engage player too. I have no problem with this. If the majority of the community starts to use the paella player for example and we don't have the resources to continue the development of the reference engage player, why shouldn't we decide to switch the default player. But at the moment I am willing to put some ressources in the refactoring of the player. And it seemed to me that some other institutions would be willing to do this although. I have not noticed that enough institutions would be willing to invest their money or developers in the reference CA to continue the development. If I am wrong these institutions should speak up now! Jaime and Tobias raised some interesting questions about remote administration, configuration and updates for the CAs, if an institution would really deploy hundrets of them. If we come up with new APIs and protocolls for this. Who will implement this for the reference CA? As we at UOS are seriously investigating other options than the reference CA too, we don't see the need to invest more of our development resources into the reference CA and would focus on other parts of Matterhorn. I see the soup to nuts argument. But I am not sure is this really is that important for a possible adopter. I would expect that that a good installation an usage experience is more important. And from our support for other universities here in germany I would say that with the CentOS repo [1] we have an acceptable experience for the core. But installation, configuration, usage and monitoring of the CA are still pain points - especially for adopters. Rüdiger [1] http://opencast.jira.com/wiki/display/MHTRUNK/Binary+Installation+from+Repo Am 06.02.2013 02:28, schrieb Christopher Brooks: > Hi Olaf, > >>> Keep in mind that we're not planning on deleting the CA code. Just >>> removing the install scripts and explicit support for various >>> hardware bits. There's nothing keeping adopters from using it, the >>> hardware support will still be there. We just won't be testing >>> against any hardware. >> Also, I wonder whether you would consider Galicaster a solution that >> still allows us to claim that soup-to-nuts approach. The software is >> OS (ignoring the licence issue here for a moment), Teltek supporting >> its further development and it's not bound to HW Teltek is selling, >> at least I think I remember Stuart saying he's running it on his own >> cobbled device. > What Greg has written, "...removing the install scripts and explicit > support for various hardware bits..." is very different from what I > perceived in the #proposal from "...bit we will not really maintain the > code in the future so that it will be outdated in the near future..." > > Regardless though, I don't support the notion that Matterhorn should not > have capture agent software and should rely on other systems alone. To > me, the benefit of Matterhorn was getting rid of the home built systems > we had individually, and coming together to build an open, > community-maintained product that could scale. I think involving other > systems, like vendor products, is important to creating a viable > piece of software, but I don't think relying on a vendor for a specific > portion of the tool chain is good. > > Also, I don't know anything about the Galicaster system except what > I've read on the website and on this mailing list. Undoubtedly it is > an excellent product, but to throw away robust community-developed code > and instead tell adopters to go to this vendor for the solution is not > something I'm comfortable with. > >> Yes, that was my impression too. I think we've seen what a closer >> alignment with certain vendors can lead to when their support isn't >> there and the price policy is erratic, but I think if one could run >> Galicaster SW on your own device, wouldn't that be agnostic enough? > Why don't we just drop our player and core and instead point people > towards the Kaltura community release (it's open source)? Open source > software isn't just a set of widgets we can replace, it's about a > community that people can participate in. How many different higher > education institutions have commit access to Galicaster code? How can I > contribute back new developments we make to the broader community, and > get their contributions in return? How can I contribute patches to > bugs, and fix problems when they arise instead of buying a support > contract? The answer is you can't -- it's not a community source > project. > > This doesn't have to detract from all the wonderful things that > Galicaster is (free, open source, well supported, python, great > testimonials, etc.). But changing the docs to say "Go download > Galicaster" is cutting away a portion of our product and saying we're > not interested as a community in lecture capture, just media processing > and playback. And I don't think that's true, and I don't see why that > is necessary. > > Chris -- ________________________________________________ Rüdiger Rolf, M.A. Universität Osnabrück - Zentrum virtUOS Heger-Tor-Wall 12, 49069 Osnabrück Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 E-Mail: [email protected] Internet: www.virtuos.uni-osnabrueck.de _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
