Re: [backstage] Using filters to manage mailing-lists (Was: Move to Mailman)
On Thu, 2010-03-04 at 15:41 +, Stephen Jolly wrote: if $h_Sender: matches owner-([a-zA-Z-.]*)@ and not delivered then save $home/mail/lists/$1 endif Exim filter files are great. I similarly filter all mailing lists into different folders using a meta-mailing-list filter; mine's a little more complicated: if not delivered and ( $h_List-Id: matches ([^]+) # Mailman or $h_X-Mailing-List: matches ([...@]+)@ # Majordomo -- handles Kernel.org or $sender_address: matches owner-([...@]+)@ # Listserv or $sender_address: matches (.*)-request@# (Old majordomo listservs?) ) thensave mail/lists/$1 if $1:$tod_log matches ([^:]+):(\d+-\d+) thensave mail/archive/lists/$1/$2 # Save a second copy in # mail/archive/lists/list-name/year-month endif endif This means that when I get added to new mailing-lists, the new emails get filed away automatically rather than cluttering up my in-tray.. (Sadly, we're being migrated to a central Exchange service which isn't nearly so powerful. So far I've resisted by having a mail spool that's bigger than Exchange can handle...) Cheers, David -- David McBride d...@doc.ic.ac.uk Department of Computing, Imperial College, London signature.asc Description: This is a digitally signed message part
Re: [backstage] [ORG-discuss] DRM Free BBC Content on GNU/Linux (Ubuntu)
Rob Myers wrote: On Thu, Oct 30, 2008 at 6:53 AM, Vladimir Harman [EMAIL PROTECTED] wrote: hmmm...nice and positive news for the ubuntu friends, and me of course :) thanks to canonical for spreading the word :) the plugin works with totem only, or it works with other gnu/linux video applications? My next action was going to be to ask backstage if anyone can provide more information on this project. :-) Apparently, this is based on URIPlay (http://uriplay.org/), which was presented at the OpenTech 2008 conference last summer. Totem appears to be getting its (RDF) metadata from the BBC directly via the URL: http://open.bbc.co.uk/rad/uriplay/availablecontent ... so anything that can process that or do anything sensible with it should also be able to partake. (As the URL suggests, it looks like its under Rapid Application Development so I'd expect it could change at any point in the future. But this looks like wonderful progress from the BBC.) Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] iPlayer in Wii
Dave Crossland wrote: The BBC-vs-ISP bandwidth issue could be resolved by the BBC dropping DRM so that the ISPs can cache the data. The ISPs who are anticipating financial hardship are more concerned with the cost of bandwidth between their network and home ADSL users, and _not_ between their network and the outside world. This is because they are charged a metered rate by BT for all the traffic they relay over BT's ADSL network. Thus adding data caches to their network wouldn't solve their immediate problem. Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
[backstage] What would you do? (Was: BBC tech chief: You Freetards don't matter)
vijay chopra wrote: Of course, this raises the question, is he misleading deliberately, or just misinformed? Considering his recent faux pas it's not much of a stretch to believe he's not only misinformed, terminally so (I ascribe nothing to malice that can be explained by eveyday incompetence). To paraphrase a famous saying, Any sufficiently advanced incompetence is indistinguishable from malice. (With apologies to Arthur C. Clarke.) But, seriously, I do have a great deal of sympathy for Ashley's current predicament. If you had: * Negotiated distribution rights with large numbers of programme-makers, * Developed and deployed a large-scale, proprietary peer-to-peer distribution system for providing access to said programmes, * Developed the client-side programs and web- and server-side tooling to support such access, ... and then later realised that: * That the arguments for DRM that you'd previously accepted do not make sound technological sense, * The regulatory agency that you report to is indicating that the current platform support is insufficient, * That the proprietary technology choices that you'd made for the distribution and DRM components of your infrastructure are not portable to all of the necessary and ideal target platforms (Mac, Linux, smartphones, iPods, etc.), * You're being forced to publically defend the decisions that you'd previously made using the rationale you used at the time, and finding that the arguments you're making are unconvincing (at least to this audience), ... what would you do? So far as I see it, Ashley has only a couple of options: 1. Try to continue down the present course - procuring or developing DRM and/or distribution technology as necessary in order to satisfy both the BBC regulators' and the rights-holders' requirements. (See also: the recent Adobe Air streaming announcement.) Or: 2. Develop and advocate a major shift in strategy, that involves: - Dropping the design requirement for DRM on all distributed content, - Retooling the existing production infrastructure as necessary to support open distribution and content standards, - Either convincing the BBC legal team that they have the rights to distribute the programme-makers content sans-DRM under their existing broadcast / streaming agreements, -or- - Re-opening negotiations with the programme makers to secure internet distribution rights sans-DRM, -or- - Restricting the programmes that may be downloaded by the iPlayer service to in-house content that they clearly can offer for access by UK residents. Though option 2 seems, to me at least, to clearly be in the license-payer's (and our) interest - and a technically superior option - it's certainly a much higher-risk strategy from Ashley's perspective, and, politically, would most likely be a very hard sell to BBC management. At what point does option 1 become untenable? Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] Ashley Highfield on iPlayer - 26min Interview
Hi, A very interesting interview - many thanks to Backstage and Ashley. A few thoughts: * It seems clear that all of the portability issues currently affecting the iPlayer beta are a direct result of the requirement for DRM specified at the design stage. If the DRM constraint _were_ relaxed, then it would be possible to exploit all of the existing standardized and open-source media encoding and distribution technologies and completely avoid the current cross-platform incompatibility problems. * One question I have is: why Kontiki? Given that the files being distributed are DRM-wrapped anyway, why not use something more mainstream such as Bittorrent? (Even with a DRM-wrapped payload, RSS feeds carrying BBC series as a set of .torrent files would be very cool!) * From the interview, it is clear that the reason that the current DRM requirements exist is because rights-holders did not want the end-user the to be able to redistribute content to others - because they fear would reduce the value of their other distribution channels. This appears to be faulty reasoning. First, the BBC are _already_ broadcasting all of their content, digitally and in the clear, in the form of RealPlayer streams, terrestrial radio and (HD) television broadcasts and also via internet multicast. Why is it useful to apply DRM to this one distribution channel, when anyone can ignore it and instead obtain a 20Mbit/sec HD digital copy encoded in a standard, well-defined encoding by pointing an antenna at Crystal Palace? Secondly, all evidence to date shows that DRM does not in fact prevent the redistribution of content by end-users -- indeed, the WMPv9 DRM scheme currently used by the iPlayer distribution service had already been broken before the Beta had even launched! * Rights buy-outs: it's not necessary to buy out the rights to putting on live shows, publishing books and many of the other functions mentioned by Ashley in the podcast in order to set up a functional, DRM-free iPlayer service. Moreover, his assertion that all of the downstream rights - for books and so forth - would become worthless if the shows themselves could be readily downloaded seems dubious. Indeed, the value of many related works - books, live shows, etc. - may well _increase_ significantly if the original shows themselves were more readily available. This is because making the content more readily available to the public would help the rights-holders to build a bigger audience for their other works. Indeed, it is partly for this reason that many book authors are now publishing the entire content of their works online under Creative Commons licenses. (This is basically the same argument the BBC made in the case of the Beethoven MP3 downloads which so worried other Classical music distributors.) * One of the things Ashley talks about is a potential new future distribution model which he hopes that technology will enable the publication of content with no DRM -- but distributed in an intelligent wrapper that is able to enforce a set of rules for how it should behave. I think someone needs to tell Ashley that the mythical future technology he's describing _is_ what the rest of us would call DRM! Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] Ashley Highfield on iPlayer - 26min Interview
Tom Loosemore wrote: First, the BBC are _already_ broadcasting all of their content, digitally and in the clear, in the form of RealPlayer streams, terrestrial radio and (HD) television broadcasts and also via internet multicast. all above are geographically bounded. So is access to the iPlayer service. general users can't yet *easily* grab a broadcast stream and copy/share a file internationally Of course, that doesn't matter - someone else will have uploaded a copy somewhere public that the general user can grab already. Even UK pirate sites rely on very few expert cappers who do this by hand, hence the relative scarcity of UK TV programmes on the darknets compared to music. It is trivially easy, with current tooling, to automatically catalog, isolate from one another and transcode music tracks from CD. Anyone can basically belt-feed CDs into a PC and get iTunes to do everything for them. Recorded TV, unlike DVDs, would however require manual editing to edit out the commercial breaks, to set accurate start and end times, and selecting optimal transcoding settings. The tooling to do this isn't as usable and isn't as widely deployed among end-users. However, bandwidth capacity, storage and tooling will only improve. right holders would argue that it's enough rather than absolute deterrent which matters. They've already got copyright law with its current scope for enormous penalties to wield as a deterrent. DRM isn't a deterrent, its just obfuscation. And once one person's figured it out, it's not even that. * Rights buy-outs: it's not necessary to buy out the rights to putting on live shows, publishing books and many of the other functions mentioned by Ashley in the podcast in order to set up a functional, DRM-free iPlayer service. how so? You don't need to buy the rights to make and distribute e.g. Top Gear books if all you're trying to do is to distribute the TV show via the Internet. It's just not a legal requirement. Moreover, his assertion that all of the downstream rights - for books and so forth - would become worthless if the shows themselves could be readily downloaded seems dubious. agreed that worthless is an overstatement - but it's hard to argue that they'll not be reduced, which is enough for most rights holders to resist. The market for spin-off books, live shows, and many other related works will most likely go _up_ as a result of the wider distribution of the original programme. The right-holder's main concern is, I suspect, not that people will freely redistribute their TV-shows amongst one-another -- they do this already! -- but that people will stop buying their content on DVD and will instead build up their own large library of shows as they're broadcast, removing the need to fork out for the same content again. Which would then mean that DRM's ability to limit redistribution is only a secondary effect; the primary function here is to stop end-user from storage any downloaded content for longer than the 30 day window the BBC negotiated with the rights-holders. This is also why the announced Adobe streaming-only solution is also perfectly fine with the rights-holders - it'll include DRM that prevents users from saving streamed downloads permanently to disk. I think someone needs to tell Ashley that the mythical future technology he's describing _is_ what the rest of us would call DRM! i *think* he mean't to express a desire for standard machine-readable means of attaching (if not enforcing) rigfhts to media. Kinda CC+ without creative reuse? He clearly used the term enforce during the interview. To effectively enforce such constraints, it is necessary to prevent end-users from being able to copy and/or edit the original bitstream, and would thus - by definition - would be classified as DRM. (Otherwise, if the inability to add meta-data to distributed video content is the only thing preventing the BBC from dropping the current DRM requirement, then I can point them at a number of standard ways that they could do it..) Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] An interview with Mark Taylor, Pres. of UK Open Source Consortium
Quick aside: you appear to have a very interesting UTF-8-encoded From name string: From: =?UTF-8?B?In46Jycg44GC44KK44GM44Go44GG44GU44GW44GE44G+44GX44Gf?= =?UTF-8?B?44CCIg==?= [EMAIL PROTECTED] ... which actually expands to (what appear to be) a number of interesting chinese glyphs! This may not be what you intended.. ~:'' ありがとうございました。 wrote: the unfortunate fact is that open source is not above or beyond this type of controversy. ie who funds the developers? who are they developing for? Actually, at least in major open-source projects such as the Linux kernel, nobody cares. In such projects, you will often have many developers paid and working for the interests of various companies. Not only is this not a bad thing, however, it's actually very good as it results in a larger number of (presumably effective) developers working on developing the code-base full-time. The open-source development process is, at its core, evolutionary. Each developer works to build new revisions of a given project. If the new version is 'fitter' than the original, then those changes will be adopted. If the new version is inferior, it won't. In such a system, the more competent developers you have, the better. It doesn't matter that they're all trying to apply evolution pressures in different directions; the project as a whole will still benefit. in many cases developers: have little or no understanding of a 'public' audience. actively refrain from user testing. These two points can be summarised as open-source developers don't care about usability. And this demonstrably isn't true. Different tools are designed for different audiences; emacs, for example, is intended to be usable by developers - and it is. Similarly, Ubuntu, GNOME and other systems that _are_ intended for regular end-users have clearly seen a great deal of usability testing. encourage feature creep Do you have any evidence that you can port to to demonstrate this? design to impress their peers You say this as if this is a bad thing! in some sense consumerism at least gives the end user some authority. To a degree, but it heavily depends on there being a free market with a number of competing alternatives. I'm not an economist, but it appears that, in computing, free markets generally cannot form if the interfaces used for data interchange are closed and/or proprietary; in such markets, one provider will eventually tend to dominate all of the others. For example: Operating systems: MS Windows tends to dominate (because nothing else can run Windows applications, as the ABIs/APIs are myriad and not fully documented); Office productivity suites: MS Office tends to dominate (because nothing else can read/write the proprietary file formats that Office uses.) To contrast: Web browsers: There are many web-browsers: Seamonkey, Firefox, Internet Explorer, Safari, Konqueror, Galeon, Lynx etc. (because the interfaces that such applications must support are well-documented.) Web servers: lighttpd, Apache, Nginx, IIS etc. (because the interfaces that such servers must support are well-documented.) .. and so forth. If there is a free market, then the consumer has influence. Note that in the case of the BBC iPlayer and other similar services from other broadcasters, the interfaces are not fully documented - and this is considered a feature! as you may know, the web specifications created by W3C are far more potent than the mere iplayer. I don't think I understand - how (and why?) are you comparing the W3C interface specifications and guidelines, which exist to ensure interoperability between different implementations, and the BBC's iPlayer, which is just one application? The issues are similar though there are more companies and corporations engaged in the project Than which project? The W3C? There have certainly been many more companies and corporations involved in the W3C specification development process than that of the iPlayer! Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
Greetings, Interesting discussion - primarily useful for the we don't have the rights arguments that haven't been effectively aired until now. The reason for using DRM has often been stated thus: * We need to prevent our users from re-distributing content that we feed them. However, it now appears clear that the real reason is thus: * We have to be seen to be trying to do something to prevent our users re-distributing content. Given that no DRM scheme has _ever_ met the goal of preventing users re-distributing content, would it not be better for the BBC, consumers and pretty much everyone (except perhaps MS) in the long-run if the BBC simply denounced DRM as the snake-oil it is and refuse to deploy it? Indeed, this seems particularly pointless when I can simply point my desk antenna at the Crystal Palace transmitter and record the 20Mbaud H.264 1080p stream being broadcast in clear. Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
vijay chopra wrote: (even if it's only one podcastl; what makes a downloadable audio file into a podcast anyway??) If this is going to be a (semi-)regular occurrence, could we get a real RSS feed for it? Cheers, David -- David McBride [EMAIL PROTECTED] Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
