On Wed, Feb 18, 2015 at 12:16 AM, Axel Wagner <m...@merovius.de> wrote:
> Luke Kenneth Casson Leighton <l...@lkcl.net> writes:
>> what *does* concern me is that it takes such incredible (and amazing)
>> efforts by people like adam for the average end-user or sysadmin to
>> contemplate replacing {insert nameless package}.
>
> insert libc6.
libc6 has alternatives, and, itself is maintained by a diverse group
(the FSF) with a reputation for respecting software freedom and
sufficient experience to know the ropes surrounding UNIX/POSIX. even
google when developing android decided that the GPL was a horrible
virus, they didn't like libc6 and very kindly funded the creation of
an alternative. also as a well-defined standard it would be
unbelievably stupid to attempt to deviate from it ("get creative").
conclusion: we can trust the libc6 maintainers.
> Or insert perl.
perl is maintained by an extremely experienced and diverse group of
developers. they understand the responsibilities behind maintaining
and developing such a critical programming language.
conclusion: we can trust the perl developers.
> Or insert linux-image.
linux is developed by a hodge-podge bag of cat-like developers who
all, amazingly, pull together and get the job done. they're also
headed by a team of incredibly responsible people who have had decades
of experience.
conclusion: we can trust the linux kernel developers.
a previous example given was SE/Linux. i outlined a case where,
paradoxically, it can be demonstrated that we can trust the developers
behind SE/Linux.
another example i was gives was grub. grub has alternatives (lilo
and others): by inference this keeps them honest by way of
competition. conclusion: we can trust the grub developers.
> And suddenly no on cares (not even you).
the cases you give are ones where a rational analysis shows that the
people behind them can be trusted. we can go at this for as long as
you feel it useful for you to do so, but i think you will find that,
in every case, the team behind the package engender our trust (trust
is *not* earned, btw: respect is earned. trust is given. always.
past performance != guarantee of future behaviour)
but systemd is very, very different. far from being able to find
reasons why the systemd team may be trusted, analysis by several
people shows that, sadly, the complete opposite is the case.
unfortunately, the team behind the systemd project have demonstrated
time and time again that their focus is extremely narrow: Redhat
Desktop.
one example (and there are many, many more):
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
just one good analysis of which is here:
http://lists.busybox.net/pipermail/busybox/2011-September/076713.html
> You have to do better than this, sorry. Just that
> a package has reverse dependencies and that you have to recompile a big
> part of the debian archive to install a debian without them does *not*
> mean, that this package is in any way problematic
> [continued below]
you are correct about that [i.e. you are correct in the assertion
that the recompilation for removal has nothing to do with removal].
i am still trying to track down concrete reasons why i feel so
alarmed. i believe it's because everything i've seen that team do -
all their "blogs" and reports has been... it feels so "rational", and
so "logical", yet nowhere do i see any kind of debate, inclusion of
other people, other teams. do these people join mailing lists other
than those directly related to fedora desktop?
the whole situation feels desperately, desperately wrong, and i
cannot unfortunately give you a single concrete specific example or
reason why, and that is part of the problem: nobody else really can,
either.
and i think that's really why everyone has been getting so fed up,
getting into such severe arguments that they end up leaving projects
that they've worked well for decades with everyone for such a long
time.
that *in and of itself* should tell you that there's something
seriously wrong, here. how many prominent, committed, dedicated and
experienced people have resigned from roles in debian so far - people
without whom debian is clearly worse off.
> [continued here]
> or takes away choice.
on this you are wrong: by definition and by the immediate evidence
shown, it does exactly and precisely that. [more specifically, the
choices that people are forced into making are so extreme that many
cannot even make them, they are so disruptive, or require such extreme
knowledge, or require extreme risks, or require violations of company
policy - use of unofficial archives which would violate support
contracts - and so on].
l.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAPweEDzfzUx=+hzezcgpomp7ufrogfbv4k9aa-oqao+ev1g...@mail.gmail.com
