8:51 a.m.
----- Original Message -----
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote:
>
> On Feb 22, 2014, at 9:39 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
>
> > On Fri, Feb 21, 2014 at 19:08:15 -0700,
> > Chris Murphy <lists(a)colorremedies.com> wrote:
> >>
> >> The idea of what Anaconda can do to create powerful storage stacks with
> >> open source software has significant merit. But it's in the wrong
> >> place. It's an anchor on the installer, and can only be leveraged
> >> during an install of RHEL, CentOS or Fedora.
> >
> > What would you have people do instead? For example run a live image to do
> > the partitioning, raid, lvm, dmcrypt, and file system setup before doing
> > the install? Even then, you need some way to tell the installer which
> > directories go on which file systems for the install.
>
> I'm mainly suggesting a decoupling of all of this effort from an
> installation only context, so that it can be used to create and modify
> storage stacks without installing an OS. I don't particularly care how it
> manifests - separate app, or a spoke within the current app. Communicating
> the layout can be done with a fstab-like metadata file. If there's no
> inclination to do this for a much broader use case, then why wedge so much
> capability and effort into a narrow installer-only use case? Bootable
> raid6 and raid4??
>
Decoupling can't happen given the hard requirement we have on supporting a
wide range of storage configurations. Linux in general has far too many
options in this area and everyone's corner case or configuration is most
important.
Well, as Fedora.next aims pretty much on productization and we'd like to
set higher bar for these products, I think we can limit these everyone's
corner case configuration and focus on what's really needed for our main
products. And I understand, this is really more politics than technical
issue and we're right in this politics time of Fedora.next - a good time
to rethink what we do now.
Of course the last but not least question is manpower of your team. There's
possibility that if we would be able to simplify blocking paths in installer,
we could get to the point there would be more time and will to touch proposed
ideas...
Jaroslav
6:50 a.m.
New subject: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
I know a little about guided and custom partitioning. Custom is a bit too complex for
the new users.
The guided/automated partioning is the best.
Harken back to F16 my friends.
We lost a lot of important progress, I think. I was in love with F16 and I was running
it "flawlessly"
until F17 came out with major major bugs. Luckily you guys rock and knocked out all the
fucking
bugs, next problem is simple: Keeping it user-friendly. The average linux dabbler is
not going to
persist if there are more bugs in F20. For example, I am a bit of an intermediate user
and even I
was unable to get F20 up and running smoothly--- I had the opening screen dump (our
favorite
logo!) followed by being thrown into a kernel thrash and having to switch back and forth
between
dracut and bash like a fkn novice.
So anyways, let's keep it simpler for our noobs. And I think a meet is a great
idea-- let's plan for
a month or so out? I know I'm not on the developer team, but I am an active user!
Thanks
-Matt
(don't be mad at the Knoppix logos) :)
------
Powered by:
On Monday, February 24, 2014 10:51 PM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
----- Original Message -----
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote:
>
> On Feb 22, 2014, at 9:39 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
>
> > On Fri, Feb 21, 2014 at 19:08:15 -0700,
> > Chris Murphy <lists(a)colorremedies.com> wrote:
> >>
> >> The idea of what Anaconda can do to create powerful storage stacks with
> >> open source software has significant merit. But it's in the wrong
> >> place. It's an anchor on the installer, and can only be leveraged
> >> during an install of RHEL, CentOS or Fedora.
> >
> > What would you have people do instead? For example run a live image to do
> > the partitioning, raid, lvm, dmcrypt, and file system setup before doing
> > the install? Even then, you need some way to tell the installer which
> > directories go on which file systems for the install.
>
> I'm mainly suggesting a decoupling of all of this effort from an
> installation only context, so that it can be used to create and modify
> storage stacks without installing an OS. I don't particularly care how it
> manifests - separate app, or a spoke within the current app. Communicating
> the layout can be done with a fstab-like metadata file. If there's no
> inclination to do this for a much broader use case, then why wedge so much
> capability and effort into a narrow installer-only use case? Bootable
> raid6 and raid4??
>
Decoupling can't happen given the hard requirement we have on supporting a
wide range of storage configurations. Linux in general has far too many
options in this area and everyone's corner case or configuration is most
important.
Well, as Fedora.next aims pretty much on productization and we'd like to
set higher bar for these products, I think we can limit these everyone's
corner case configuration and focus on what's really needed for our main
products. And I understand, this is really more politics than technical
issue and we're right in this politics time of Fedora.next - a good time
to rethink what we do now.
Of course the last but not least question is manpower of your team. There's
possibility that if we would be able to simplify blocking paths in installer,
we could get to the point there would be more time and will to touch proposed
ideas...
Jaroslav
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
3739
days inactive
3740
days old
desktop@lists.fedoraproject.org
1 comments
2 participants
participants (2)
-
Jaroslav Reznik -
matt palsson