I think It was Peter Luka's install abstraction proposal...

[John Munoz <jmunoz@mho.net>]

I think the abstraction is critical to simplifying the System. Higher
Level data will also accomodate different filesystem standards and Un*x
versions.  Conceptually, /etc/rc and /etc/rc.d/rc.xxx are very similar,
but are structurally different.  This sort of higher level abstraction
could allow us to say "Right now, we will modify Red Hat's config tool
and base the 
distribution upon .rpm, and later add a high level model interpreter to
support Debian without too much trouble.  If we opted for the low level
storage (current state of affairs) we will have to rewrite debian's
package manager to support .rpm, or reverse engineer alien to convert
dpkg's to rpm's.  I am not insisting we use Red Hat, just suggesting we
support as many package types as transparently as possible.

I like Your proposal for a "High Level" (abstract) representation that
is later interpreted into the low level config (I have two HD's (high
level) create fstab with sda and sdb (low level)).  I missed the
outright rejection you mentioned Peter (Luka), and you may need to asses
whether the "Silent Majority" can be coaxed to vote or something.  The
petty nature of many of the discussions and the incredible volume of
rambling* on this group really limits my ability and desire to reply to
the cogent, well thought out, organized plans (like the Registry
proposal).  I think this may be true for many others too.

There are many positive features in the W95 registry. I like the
"Registry corrupted, restoring from old copy" feature, even though it is
a bit trigger happy and erases all the config I just did, sometimes
right, sometimes wrong. I like it's structure better than the old w3.11
registry.  I liked w3.11 ini files (relatively comprehensible), but the
registry is a different beast, much more like a database than a flat
file.  A registry inplemented with flat files will be *VERY* bad anytime
more than one process needs to access it, and don't try to tell me that
the FS handles locking or relational integrity well.  The problem with a
DB is that your OS becomes dependent on the operation of the DB( I think
this is obvious and the main reason against it), so the question is "can
we implement a bombproof DB that will be one of the mandatory OS
components like the scheduler or the root shell?" A second option might
be to design it so that in single user mode there will be no concurrency
issues, have the application handle relational integrety, and allow
certain processes text mode access, untill we switch info "full db
working, multi-user mode".  Might be tricky...

I was looking at window managers.  AfterStep, Enlightenment, and K all
caught my eye.  Olvwm was not the coolest, but not bad looking.  I used
to use it. Enlightment seemed way cool, but too narrow in it's cult
appeal, non standard shape libs, etc.  It will not seem businesslike. 
It looks like an extremely cool time waster.  The other ones, although
slick as spit, still seemed work oriented, nicer that windows, etc. 
These are impressions.  What we really need to do is list our 
requirements.  Here are mine, in descending order of importance.  Use
the best, standard, freely available libraries available (If there is a
market leader, bugs will be fixed sooner).  Very few bugs. Good
security. Interoperability/supported by many packages, Cool features,
including most of: (wallpaper, 3d widgets, drag -n- drop, CDE style
virtual desktop, color gradients), decent performance, support for many
colors 8/16/24/32 bit would be nice, both focus policies, good
xterm/color xterm, etc.     

* This is intended to provoke you.  Is. Is not. Is. Is not! gets us
nowhere.  Ask "What would be useful?" before you write.  Explain your
reasoning, Yes or No really means nothing to me.  Argue, don't just
say.  "According to "me", you are wrong" does not cut it with anyone but
"me". Prove you have some Idea of what you are talking about.  Address
the issue.  It is critical that we all work to minimize non-productive
discourse, or we risk drowning out the good ideas and turn our most
important assets (programmer/volunteers) off of the project. I realize
that this is a flame, but It my first public flame on this list, don't I
get one or two freebies a year?