Le Ven 6 février 2009 01:30, Matthew Woehlke a écrit : > > Nicolas Mailhot wrote: >> Either you admit those files are a useful part of the ecosystem, and >> mirroring is a small cost, or you don't, and there's no legitimacy >> to >> complain there are few good or complete themes, our games artwork is >> primitive, > > I object to that. kdegames-4.1.x has *beautiful* artwork :-). I didn't write *I* was the one complaining. > We also have KHNS that makes it very easy to download and install > themes > and other such material *in a distro-agnostic manner*. This benefits > everyone, not just Fedora. +1 for not being self-centered. And in return is application (or in this case DE)-centric. Look, this model is not the "content repository" model. It's the "application-specific extension store" model. It works exactly the same way for Mozilla or OpenOffice.org (and they *do* include software bits in theirs). The usual drawbacks of this model are: 1. not resilient WRT updates, unless you reinvent native package version tracking (nothing is never updated) 2. does not permit controlled automated file pre-processing, unless you reinvent %build 3. does not permit notifying apps of deployment, unless you effectively hardcode a form of %post/%postun 4. does not permit system-wide deployment, resulting in duplication of the same files between user accounts, unless you delegate to a priviledged process (and multiplying those is insane 5. not resilient WRT a change of mind of the host of the service (cddb), unless the metadata is put in the distributed payload, in which case you've finished reinvented a package container 6. not resilient WRT interactions with the rest of the system (CPAN updates breaking other stuff) 7. not promoting re-use or sharing, unless you reinvent native package dependencies tracking (and don't tell me no theme is ever updated or use material from other themes). Since people often don't bother, files are usually massively duplicated. 8. exclusive of other applications (example: OO.o dictionnaries distributed via OO.o extensions, TEX not sharing its fonts with other apps, etc) 9. centralising model. Since you're locking distribution in an app-specific channel any third-party material needs to be copied inside your master repository to be deployed. rpm/yum and modern packaging systems allow setting up third-party repositories easily 10. as corollary not resilient WRT forking or fragmentation of the targeted app(s) (who gets to keep the kids) 11. as corollary hostile to producers that do not target your app. rpm is happily used to package stuff people didn't even though would ever be used under Linux 12. unless your organisation is very careful to track the upstream sources and licensing clauses of the stuff used inside its bundles, will quickly degenerate in a pile of files with unclear authorship and licensing (TEX). Contributory copyright infringement. 13. not resilient WRT direct or indirect used of proprietary closed infrastructure, unless your organisation commits to the same goals as Fedora 14. hostile to mirroring inside networks with controlled internet access 15. exploding management complexity, as all the updaters override each other or try to redirect apps to their own files And I'm sure I forgot some bits. So basically, the technical deployment tech is primitive, the digital works screening is usually less thorough than ours, its even more centralising and exclusive than packages, and it gets to share the system with other similar updaters anyway resulting in a huge mess. But I will admit loudly I was wrong, you're not prejudiced, you propose screwing up everything equally. I was fooled by the way you used the "content" angle initially. >> our office suites do not have any templates or cliparts worth >> mention, no one creates any professional font and you have to pay >> someone like Ascender every time you need one, > > Maybe we should work on tools to easily integrate with Free clipart > databases? And Free font databases? The web is not nicely organised in vertical content stores and is unlikely to ever be because of its decentralised nature. Those databases are intrinsically only covering part of what could be useful to our users. >> users do not use our >> preferred formats and pester us for closed format support, > > Just out of curiosity, how do you solve the chicken-and-egg problem > here? Namely, users already have media in closed formats (or, as in my > case, are stuck with devices that only grok closed formats). How do you solve the chicken-and-egg problem of users having windows software on their PCs? You don't, you offer a satisfying alternative. > Themes that are tightly coupled with existing software are one thing > (and also tend not to be ridiculously large) And also tend to re-use pictures, images, fonts, sound files that can be repurposed to other uses when not locked into app-specific theme bundles. And in fact this locking is one major waster of bandwidth and disk space. > Tossing gigabytes (or terabytes!) > worth of all sorts of multimedia over the fence "because we can" is > another. It's not "because we can" it's "because we want to". -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
