Mail Archives: cygwin/2002/05/08/05:01:37
> -----Original Message-----
> From: Mellman Thomas [mailto:Thomas DOT Mellman AT icn DOT siemens DOT de]
> Sent: Wednesday, May 08, 2002 6:27 PM
> >>Look at it this way: The code is there, you can change it to
> >>be whatever
> >>you want. So no, we're not gatesian.
>
>
> You introduce another important definition of gatesian which
> I accept.
:]
> However, you did not recognize mine, which is to
> have the hubris to assume that users have no business knowing
> about (i.e. accessing) what they're not supposed to know
> about. It's the general gatesian premise that one doesn't
> build on what's already there - instead, if you don't like
> what's offered, you go out and buy from the competition.
I think that this really depends on your definition of user. As a user
of (say) Gnome, I really don't want to know about the mechanics of
CORBA. As a gnome developer (note: not an application on Gnome
developer, but a gnome-core hacker) I should know about the mechanics of
CORBA. I acknowledge that most projects have many levels of user, but I
think it is generally accepted that the most important distinction is
developer vs user. In this case, I think your thesis is digressing from
the original point, as the mount table has little to do with building or
not building on the existing base - because it underpins cygwin, and
it's Cygwin itself that allows building on the unix codebase on windows.
..
> no, we won't
> >>be notifying the general end user base of changes to the registry -
> >>because it's not a published API.
>
> Okay, I accept that as a practical limitation based on resources. But
> my rejection of Black Boxes above still holds.
I think perhaps you are not articulating the thing you are objecting to
clearly enough. The mount point structure is not a Black Box. It's not
part of any API, it's closest equivalent in the unix world is the
*in-kernel-memory* mount table structure. (Note: not the /etc/mtab
file). AFAIK there are no user-land calls or even documentation for that
structure. (Other than the same ones that cygwin exports - ie mount and
umount).
> Note that I'm *not* trying to turn the clock back on
> modularization and structured programming. I also think it's
> okay to sometimes hack some ugly code to solve an immediate
> problem, as long as the interfaces are clean.
Agreed.
> I simply recommended that we try not to drift away from easy
> textual processing just because Bill doesn't see any need for
> easy textual processing, and then as a consequence to your
> point, I further recommended that we not shy users away from
> "privileged" areas.
On the textual side, I think that we could have a long discussion on the
merits of different serialization and storage methodologies, but it's
off-topic here. I also don't think that it adds to what I percieve as
your key point.
As for privileged vs non-privileged areas, we are not (IMO) pushing
Cygwin users away from those. We are being clear about what dials exist
to tweak the environment vs what dials you should become a
developer/hacker of the environment before tweaking.
> Yeah, I had no problem with your point until the capital letters.
>
> Certainly, the developers of WINE hear you loud and clear. :)
Lol.
> If the Undocumented Entry Point you refer to uses concepts
> that are antithetical to unix and open programming, then I
> see no reason why users shouldn't get their two cents in as
> early as possible.
I agree with you that users should get their two cents in, should that
be the case. However as I've articulated above, the registry mount
points have no textual equivalent in the unix world, and I see no reason
to create a textual version here. The source and data are both open and
documented (via code), and processable via standard unix API calls. So,
no problem :].
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -