Linux is not about choice
 

On Wed, 09 Jan 2008 15:58:45 -0500
Adam Jackson <ajackson@redhat.com> wrote:

> But the chain of logic from "Linux is about
> choice" to "ship everything and let the user chose how they want their
> sound to not work" starts with fallacy and ends with disaster.

I cannot agree more.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

On Wed, 2008-01-09 at 15:58 -0500, Adam Jackson wrote:
> > Linux is about choice.
>
> If I could only have one thing this year, it would be to eliminate that
> meme from the collective consciousness. It is a disease. It strangles
> the mind and ensures you can never change anything ever because someone
> somewhere has OCD'd their environment exactly how they like it and how
> dare you change it on them you're so mean and next time I have friends
> over for Buffy night you're not invited mom he's sitting on my side
> again.

Damn you where's my FreeBSD kernel package for Fedora?

:)

Dave.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

> Linux is about choice.

If I could only have one thing this year, it would be to eliminate that
meme from the collective consciousness. It is a disease. It strangles
the mind and ensures you can never change anything ever because someone
somewhere has OCD'd their environment exactly how they like it and how
dare you change it on them you're so mean and next time I have friends
over for Buffy night you're not invited mom he's sitting on my side
again.

As a consumer, yes, you have lots of choices in which Linux you use.
This does not mean Linux is in any sense _about_ choice, any more than
because there are so many kinds of cars you can buy that cars are about
choice.

The complaints up-thread about juju and pulse are entirely valid, but
the solution is not to try to deliver two things at once. If you try to
deliver both at once you have to also deliver a way of switching between
the two. Now you have three moving parts instead of one, which means
the failure rate has gone up by a factor of _six_ (three parts, and
three interactions). We have essentially already posited that we have
insufficient developer effort to have 100%-complete features at ship
time, so asking them to take on six times the failure rate when they're
already overburdened is just madness. Alternatively, we could say that
we're integrating features too rapidly, but you do that at the expense
of goal 1, to be the showcase for the latest and greatest in free
software.

Software is hard. The way to fix it is to fix it, not sweep it under
the rug.

There is a legitimate discussion to be had about where and how we draw
the line for feature inclusion, about how we increase and formalize our
testing efforts, and about how we develop and deploy spike solutions for
corner-case problems like the one device class that juju happens to do
worse than the old stack. But the chain of logic from "Linux is about
choice" to "ship everything and let the user chose how they want their
sound to not work" starts with fallacy and ends with disaster.

- ajax

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

On Thu, Jan 10, 2008 at 06:52:52AM +1000, Dave Airlie wrote:

> Damn you where's my FreeBSD kernel package for Fedora?

Weren't the Debian people targeting at a GNU Hurd-based version of
their distro? :-)

--
-- Jos Vos <jos@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

On 09.01.2008 21:58, Adam Jackson wrote:
>> Linux is about choice.
> [...]
> The complaints up-thread about juju and pulse are entirely valid, but
> the solution is not to try to deliver two things at once.

I agree with most of the things you said. In a ideal world there would
be no reason for some of the choices like juju or not. Juju afaics
solves a lot of problems and I agree that it's the way forward.

But we don't live in a ideal world and when we started shipping juju it
was not capable to do some things that were possible with the old stack.
Some things more then a handful of users wanted to do, so lot of users
ran into trouble and had a hard a fight fixing it -- seems some people
(including Hans afaics, who's a developer with a lot of skills) got
confused/frustrated. That's bad for Fedoras reputing -- thus we should
avoid that if we want to be a serious distribution and more than a
beta-playground for RHEL (as that's how it feels from my point of view
due to things like this).

So that leaves two choices:

- we could have delayed juju until F8 (or even F9)
- we could have included juju in F7 (as we did) and made it optional
(either enabled or disabled by default)

I think the latter is the better solution and a serious option for one
release.

CU
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

On Wed, 09 Jan 2008 22:18:25 +0100
Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> - we could have delayed juju until F8 (or even F9)
> - we could have included juju in F7 (as we did) and made it optional
> (either enabled or disabled by default)
>
> I think the latter is the better solution and a serious option for one
> release.


And if we had chosen that, it likely still wouldn't be where it is
today, because it wouldn't have had the exposure. It was functional
for the vast majority of uses and the exposure got more and more things
fixed on it. If there was an alternative then everybody would just
switch back to the old method, and no bugs would get filed and no
corner cases would get discovered.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

Best mail on this list I've ever read.

David

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

On Jan 9, 2008 9:46 PM, Jesse Keating <jkeating@redhat.com> wrote:
> On Wed, 09 Jan 2008 15:58:45 -0500
> Adam Jackson <ajackson@redhat.com> wrote:
>
> > But the chain of logic from "Linux is about
> > choice" to "ship everything and let the user chose how they want their
> > sound to not work" starts with fallacy and ends with disaster.
>
> I cannot agree more.

+1000

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

Thorsten Leemhuis (fedora@leemhuis.info) said:
> So that leaves two choices:
>
> - we could have delayed juju until F8 (or even F9)
> - we could have included juju in F7 (as we did) and made it optional
> (either enabled or disabled by default)
>
> I think the latter is the better solution and a serious option for one
> release.

That way lies madness.

Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we
ship two Intel drivers and two kernels until this is resolved?

During the Fedora 8 devel cycle, NetworkManager didn't support WPA for
a time. Should we have shipped two versions of NetworkManager and let
users choose between them?

If it doesn't work, it's a bug. Fix the bug. Not ship a version for
each set of bugs that exists.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linux is not about choice
 

David Zeuthen wrote:

Best mail on this list I've ever read.

David


Best slam against this list that I've ever read.

-dmc


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list