Fedora Project, give me 20 Million Euros or Free EDA software

Nicolas Mailhot nicolas.mailhot at laposte.net
Fri Feb 6 09:08:43 UTC 2009



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




More information about the devel mailing list