On 13-02-05 03:36 PM, Stuart Phillipson wrote: > Damn those are some good points, your long term experience and success > rate is fairly incredible. I also agree that we shouldn't move forwards > without a do-it-yourself option for Matterhorn, it's half the fun : ) > > However the reference agent seem a bit developer focused? I don't think > I could get our AV staff to be effective happy looking after something > with this UI [1]. So shouldn't we be looking to put in a lot more > development work to keep pace with the rest of the market or remain a > solution that's unappealing to institutions who would be capable of > running it on the dev side but not the AV ops side?
To be honest, that's one of the more user-friendly interfaces in regards to the reference CA. We've had plans to make it more user friendly since the pre-1.0 days, but we just never have the cycles. This is an area where we've definitely been awaiting (hoping for?) patches from an interested adopter, especially since the barrier to entry in terms of code knowledge is fairly low. There's a ticket where a UCOSP student made some patches (https://opencast.jira.com/browse/MH-6467), but that's about it in terms of UI modernization. G > [1] > http://opencast.jira.com/wiki/download/attachments/26575033/AlsaPlaybackScreen.png?version=1&modificationDate=1331740619375 > > Stuart Phillipson | Media Technologies Coordinator > > Room 1.023 Devonshire House > University of Manchester > Manchester > M13 9PL > United Kingdom > > e-mail: stuart.phillip...@manchester.ac.uk > <mailto:stuart.phillip...@manchester.ac.uk> > Phone: 016130 60478 > > > On 5 Feb 2013, at 19:46, Christopher Brooks <cab...@mail.usask.ca > <mailto:cab...@mail.usask.ca>> wrote: > >> I'm not in favour with this proposal for a number of reasons, but I >> hesitate to vote against it because if this is where the community >> wants to go then I won't stop it. Here are some of my problems with the >> #proposal: >> >> 1. If we do not have capture agent code that works then we no longer >> have an end to end lecture capture solution to provide. Mara used to >> use the term "soup to nuts" for this, and I believe it was one of the >> strongest aspects of Matterhorn at the time -- there is no open source >> project that can claim this. Dropping the capture agent is a bad >> strategic decision to me. >> 2. If the bugs are all related to installing on new OSes we can just >> not support those OSes. This isn't a software bug, it just means more >> manual configuration, and thus we have to write documentation. The >> capture agent does not have to run on someone's favourite OS, it can run >> on an older one without compromising our overall project. We don't >> have to kill the dog because it has fleas. >> 3. If the issue is hardware we can just change the reference hardware >> page to list minimum specs. I'd prefer to see an institution contribute >> a known working hardware profile, but if no one wants to do it then >> lets just list minimum specs. Any modern hardware other than an atom >> (and maybe even that now) can run the CA. >> 4. It is inappropriate to point people to a particular vended solution >> regardless of whether it is open source or not. Why would other >> vendors participate in the Opencast project if we just tell people to >> go buy solution X? I'm all for promoting vended solutions, but I am >> not for preferring one over another in this fashion. >> >> In short, the vision of Opencast Matterhorn as a community managed >> lecture capture and media processing platform is one that, I believe, >> must involve a commitment to capturing video. There are ways we can >> reduce development time on the CA without killing it off -- reducing >> reliance on install scripts and instead providing documentation, not >> implementing features that are risky (streaming, confidence monitoring, >> etc.), providing testimonials of working hardware configurations as >> well as minimum specs instead of a reference platform. >> >> I hope these issues will be carefully considered before this proposal is >> enacted. >> >> Chris >> >> On Tue, 5 Feb 2013 10:55:57 -0600 >> Greg Logan <greg.lo...@usask.ca <mailto:greg.lo...@usask.ca>> wrote: >> >>> On 2/5/2013 9:58 AM, Christopher Brooks wrote: >>>> None of these are ecl licensed. >>>> >>>> Why can't there just be many agents? Why don't we just quit >>>> determining minimum hardware, and instead just indicate hardware >>>> that people have successfully used with the codebase? >>> >>> There's nothing saying people can't still use the reference, just that >>> there's no one on our side ensuring that it's up to date. The issue >>> with not determining minimum hardware is that then people will attempt >>> to use the CA on underpowered hardware (atom boxes, and mac minis come >>> to mind) and then yell at us when it doesn't work because we haven't >>> determined the minimum spec. And there has been lots of success with >>> other, non-spec hardware, but I have yet to see any of it put into the >>> lists we already have on the wiki... >>> >>>> I don't see a good reason to quit using the reference code and >>>> suggest a single vended solution instead. Some are still using the >>>> reference code without issue, and while it isn't evolving quickly >>>> that isn't preventing the core from evolving. .. >>> >>> The biggest reason is time. We have a limited pool of developer time >>> available, and if those two devs supporting the CA could be better >>> spent elsewhere then it doesn't make sense to keep supporting the >>> reference CA. >>> >>> Don't get me wrong, I don't like dropping the reference CA. But I >>> also don't like that Adam spends his 20% working on CA bugs related >>> to Ubuntu screwing around with package names and removing >>> dependencies when he could be working on something that affects more >>> of the project. And from talking to people at the unconference, >>> there are very very few institutions that even consider the reference >>> build when talking about rolling out CAs. >>> >>> G >>> >>>> Chris >>>> >>>> >>>> Ruediger Rolf <rr...@uni-osnabrueck.de >>>> <mailto:rr...@uni-osnabrueck.de>> wrote: >>>> >>>> We in Osnabrück have an LGPL licensed alternative too [1], but >>>> I did not mention it in this context as we use a different >>>> technology stack (Windows) and our project is not complete in >>>> features yet (no scheduling i.e.) and not as mature as the >>>> Galicaster. >>>> >>>> And maybe even other open source options may appear in the >>>> future? >>>> >>>> Rüdiger >>>> >>>> [1] http://zentrum.virtuos.uos.de/therec/# >>>> >>>> Am 05.02.2013 16:48, schrieb Stuart Phillipson: >>>>> >>>>> On 5 Feb 2013, at 15:15, Ruediger Rolf <rr...@uni-osnabrueck.de >>>>> <mailto:rr...@uni-osnabrueck.de> >>>>> <mailto:rr...@uni-osnabrueck.de>> wrote: >>>>> >>>>>> Especially Teltek's Galicaster is an valid alternative to the >>>>>> reference Capture Agent as it has an open source license too >>>>>> and works on very similar hardware. >>>>> >>>>> I'd agree with this statement. When we were looking at capture >>>>> agents we either wanted an off the self product for simplicity >>>>> or something we could customise to our environment. We ended up >>>>> going for customisation and Galicaster vs the reference agent >>>>> didn't even get off the paper stage. Galicaster was and is >>>>> evolving so much more rapidly, it's a bit more user friendly to >>>>> noobs and seems to have a much more active community. >>>>> >>>>> That said I'm wondering how Teltek would feel about being the >>>>> only future FOSS offering on the capture agent seen? >>>>> >>>>> >>>>> Stuart Phillipson |* Media Technologies Coordinator* >>>>> >>>>> Room 1.023 Devonshire House >>>>> University of Manchester >>>>> Manchester >>>>> M13 9PL >>>>> United Kingdom >>>>> >>>>> e-mail: stuart.phillip...@manchester.ac.uk >>>>> <mailto:stuart.phillip...@manchester.ac.uk> >>>>> <mailto:stuart.phillip...@manchester.ac.uk> >>>>> Phone: 016130 *60478* >>>>> * >>>>> * >>>>> >>>>> >>>>> _______________________________________________ >>>>> Matterhorn mailing list >>>>> Matterhorn@opencastproject.org >>>>> <mailto:Matterhorn@opencastproject.org> >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>> >>>>> >>>>> To unsubscribe please email >>>>> matterhorn-unsubscr...@opencastproject.org >>>>> <mailto:matterhorn-unsubscr...@opencastproject.org> >>>>> _______________________________________________ >>>> >>>> >>>> -- >>>> >>>> ________________________________________________ >>>> 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: rr...@uni-osnabrueck.de <mailto:rr...@uni-osnabrueck.de> >>>> Internet: www.virtuos.uni-osnabrueck.de >>>> <http://www.virtuos.uni-osnabrueck.de> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> Matterhorn mailing list >>>> Matterhorn@opencastproject.org >>>> <mailto:Matterhorn@opencastproject.org> >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>> >>>> >>>> To unsubscribe please email >>>> matterhorn-unsubscr...@opencastproject.org >>>> <mailto:matterhorn-unsubscr...@opencastproject.org> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Matterhorn mailing list >>>> Matterhorn@opencastproject.org <mailto:Matterhorn@opencastproject.org> >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>> >>>> >>>> To unsubscribe please email >>>> matterhorn-unsubscr...@opencastproject.org >>>> _______________________________________________ >>>> >>> >>> >> >> >> >> -- >> Christopher Brooks, PhD >> ARIES Laboratory, University of Saskatchewan >> >> Web: http://www.cs.usask.ca/~cab938 >> Phone: 1.306.966.1442 >> Mail: Advanced Research in Intelligent Educational Systems Laboratory >> Department of Computer Science >> University of Saskatchewan >> 176 Thorvaldson Building >> 110 Science Place >> Saskatoon, SK >> S7N 5C9 >> _______________________________________________ >> Matterhorn mailing list >> Matterhorn@opencastproject.org <mailto:Matterhorn@opencastproject.org> >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> matterhorn-unsubscr...@opencastproject.org >> _______________________________________________ > > > > _______________________________________________ > Matterhorn mailing list > Matterhorn@opencastproject.org > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > matterhorn-unsubscr...@opencastproject.org > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
