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

[Nicolas Mailhot]

Le jeudi 05 février 2009 à 23:57 +0100, Kevin Kofler a écrit :
> Nicolas Mailhot wrote:
> > 1. you ignore or turn a blind eye to many native package properties and
> > to what packagers do in addition to producing rpm files
> 
> What's the point of a single-file noarch package containing some piece of
> media you're dumping to a semi-arbitrary location of the filesystem

1. the location is not semi-arbitrary
2. users are not so good at managing install/uninstall
3. once it has a stable location it can be depended on, referenced and
reused by other (software or not) works. Re-use is not a software
exclusivity.

> And there are plenty of such files around even if we only count those under
> acceptable licenses, Fedora's infrastructure does not scale to that many
> files,

Having someone responsible for triaging, screening their origin,
collecting feedback, and taking care of them (ie a packager) is already
self-limiting. I don't support giant collections of resources packed in
a single srpm (à la TEX).

> also considering the size of most media files. Ship a few
> CC-licensed movies and you'll make kde-l10n look small in comparison.
> Multiply this by the number of such files you want to ship and we quickly
> reach astronomical proportions. We cannot afford wasting our mirrors'
> resources that way for content which does not need packaging in the first
> place.

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, 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, users do not use our
preferred formats and pester us for closed format support, users find
our desktop experience boring and no fun, our audio theming is in the
dark ages, our UI designers have no taste, etc etc

Digital works producers will continue to support closed ecosystems as
long as they don't feel the pressure of free/open offerings, those won't
take up if we don't help them, and our means of helping them is to
distributing them.

Otherwise, the FLOSS community will continue to be seen by others as a
bunch of egoïst hippy freeloaders that ask for all kinds of free (beer)
goodies but contribute nothing back (yes the contempt cuts both ways).

Distributing, incidentally, was the primary aim of a "distribution".
That some bits needs to be frobbed by a "compiler" before is only
accessory (lots of software files don't, and source-only distros exist).

> Most content, on the other hand, is a
> self-contained file, which just needs to be downloaded to be viewed, and
> often not even that (-> streaming).

Just like an autopackage, a java .jar, a windows .exe, etc.

The only reason our "software" bits are not self-contained is because we
*chose* to distribute them this way, and we *chose* to further their
inter-dependencies, because that made all the different bits better with
less work. Any immersion on the dark side will show you software there
is largely distributed the way you claim is "natural" for "content".

> > 3. core+extras, autopackage, direct CPAN use are all (mild) forms of
> > what you advocate and the project already decided not to go those ways
> 
> FWIW, I'm not a fan of Matthew's suggestion of a "content repo" either. In
> fact I think it wouldn't scale any more than packaging everything in Fedora
> would. We have such a repo already, it's called the World Wide Web. :-)
> Trying to put it all on a single server or even server farm is madness.
> 
> The best we can do, really, is work with search engines to get filtering on
> licenses more widely adopted.

Why would search engines want to do that? Why would users care? If you
make them do the triaging and searching and installing and file managing
by hand why should they care what you prefer as licensing model?

Any freeware or warezware will be just as good for them.

> But we can't put the result of that filter
> into a single repo, nobody has that much storage space and bandwidth.
> (Well, maybe if you can get both archive.org (for storage space) and Akamai
> (for bandwidth) on board, but even then I doubt it. ;-) )
> 
> > 4. but you don't really want to admit that, because you're only
> > rationalising prejudices, and call for Fedora censorship of its
> > community contributions to support them
> > 
> > 5. I don't have a cluestick big enough to hit you with, so I'll just
> > continue to annoy you by contributing work you don't care about to the
> > project
> 
> Can you please stop this kind of personal attacks? Insulting people is not
> going to help you prove your point at all. Please argue to the facts, not
> the person.

I apologize for having been short and brutal. However as I've already
explained to Matthew by private mail, I feel that:

1. listing all kinds of Fedora-acceptability checks, that apply just as
well to many existing software packages, to conclude other bits should
not go in, is not constructing a rational argument leading to a logical
conclusion, but rationalising post-facto a pre-decided conclusion.

2. consistently refusing to consider what those checks could apply to
software, and looking only at "content", because you know it "should"
fail, is pre-judice.

3. asking to filter some contributions, via checks that boil down to
(once you've removed all the rules that apply just as well to software
packages) "my subjective feeling is this is not terribly useful, why are
we wasting resources on it", is asking for censorship.

I admit that a very restrictive reading of what software should be may
produce "fair" (as in enforceable by robot with no possibility of human
prejudice) rules, but that would not be blocking content from Fedora,
that would be eviscerating what Fedora is today, starting with anything
not in %{_libdir}.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090206/2c680519/attachment.sig>