Re: on forming a new Linux Distribution
bruce@pixar.com (Bruce Perens) wrote on 29.04.98 in <[🔎] m0yUjfS-000Dd3C@golem.pixar.com>:
> 1. Focus on the User
>
> I'd like to have developers who program because they like to see
> their work in the hands of users, especially _naive_ users.
Well, I must say that while users are nice, naive users ... umm. Well. I
deal with enough of these in my day job to not want to deal with them in
my free time, too; they tend to be a royal pain in the ass.
Now, that doesn't mean that a system shouldn't be easy to use. Of course,
I believe that Debian *does* meet that criterion; it sure feels easier
than Win95 to me.
> Competition with Microsoft and other proprietary systems is a
> stated goal of the project. Market share for the system and its
> derivatives is a stated goal of the project.
That is essentially a question of priorities, of what you're willing to
sacrifice to meet that goal.
My priority is in technical excellence and usability for those that care
to learn about their system. To put it bluntly, I consider software not
following these primary goals to be junk. Microsoft is a prime offender.
It's nice if it's *also* easy for other people, but that is definitely a
secondary goal.
Oh, and that's always relative to the context. It sure means different
things for a general OS distribution as opposed to, say, some embedded
thing to run cash registers. I don't expect cashiers to learn about an OS;
I *do* expect them to learn, say, how to cancel entries and stuff.
> 2. Maintaining a non-commercial alternative to the commercial Linux
> distributions.
>
> This was one of the most important goals of Debian.
Still is, of course.
> I think Debian's drifted too far from the mainstream of Linux
I don't think so.
> to continue to fulfill this purpose. A non-commercial
> alternative would address the same markets as the commercial
> Linux systems, and would be compatible with them wherever
> possible. I propose for this system binary, _dependency_, and
> package compatibility with Red Hat, the most popular Linux
> distribution that has made it to LIBC 6. This would guarantee
> the availability of commercial applications for the system.
> Obviously, the easiest way to do that is to derive from Red Hat.
I am quite certain I do *not* want rpm, or a system that's a Red Hat
derivation. From all I see and hear, that would make it quite hard to
follow my primary goals above, except if I were Red Hat myself.
> 3. Provding shared maintainance on the base system for all Linux
> distributions.
>
> This is another early goal of Debian that we've not ever fulfilled.
> A system based on what commercial distributions are already deriving
> from, managed by a non-profit, with shared CVS, might be able to
> realize this goal.
This seems fairly orthogonal to Debian. We already share huge amounts of
source with most distributions out there, and better coordination of that
surely would be good, but if it's to be of use to all distributions, then
it's orthogonal to all distributions.
Of course, there will be the issue of coordinating with the upstream
maintainers, and the difficult problem of not pissing them off.
Considering XFree86 seemed offended by the Debian X maintainer offering
help, this can get ... umm ... interesting.
> 4. Maintaining the Open Source standard of Linux.
>
> We're at the point where we don't really _need_ "non-free" and
> "contrib" directories any longer - all packages in the system
> should be Open Source - let someone else distribute the rest.
Uh. You the same guy that wrote about commercial applications some
paragraphs above?
> 5. Open Development.
> I am proposing development visible to all, but not a free-for-all.
> A core group of limited size to maintain the base system and oversee
> the rest probably _is_ necessary. I am not planning to copy the Debian
> constitution - I'd rather have the Bazaar-Method management we used
> for the first few years of the project.
Hmm. The currently debated constitution seems to me to be an attempt to
get back to bazaar-style management from too much cathedral under a
previous project leader. Some guy named Bruce, IIRC.
> 6. Direct Commercial Participation.
> I would encourage direct commercial participation by other Linux
> distributions who are interested in compatibility through a standard
> base system. I know most of these people, and can probably get serious
> consideration from them.
That looks like it belongs to the common base efforts. One thing that came
up recently would be better coordination of sonames.
> 8. Marketing On An Equal Footing with Engineering
> Marketing is important for getting the user's attention and giving
> the user what they want. Lack of good marketing is the main reason
> for the failure of Unix derivitaves to achieve market domination.
> I would put the marketing team at the same level as engineering, and
> have them work together constantly.
As long as that doesn't mean marketing dictating to engineering to use
inferior solutions ... for some reason, that's what it usually means.
> 9. A Random List of Other Goals.
> RPM as the package system - possibly with an APT port later on
> (is that what it's called now?). It's necessary to get the other
> distributions in on the project. We'd have to add a few missing
> features to RPM, but this would be pretty easy to do.
For the base system CVS idea, that's not even necessary. That one is a
source-and-patches repository. No need to dictate packaging of the stuff.
It could easily hold both rpm spec files (and whatever else rpm needs),
debian subdirectories, and whatever else some other distribution wants to
use.
> COAS as a system management framework. Non-interactive install.
I think someone else asked that recently - what *is* the state of COAS
these days?
> Limited set of interpreters for system tasks and pre-install and
> post-install scripts. How about ANSI shell (_not_ necessarily Bourne
> shell), Python, and everything else is a compiled executable?
> I'm concerned that Perl is a rather messy language compared to
> Python, and both Red Hat and Caldera seem to be focusing on Python.
Python is a language I won't touch as long as I can possibly avoid it.
Indentation as syntax element is *evil*; we've known that since FORTRAN.
People who still haven't learned this basic lessons are people I don't
trust technically.
The longer I use it, the more I like Perl. Besides, it's fast becoming a
standard for Unix systems (some might argue it already is).
And compiled scripts will be in the next Perl release, AFAIK. That should
do nice things to startup times.
> No obscentity. Avoids legal problems and makes _me_ feel better.
Makes me immediately not want to join. Makes me wonder what you want to do
about the Linux kernel.
> Pursuit of the 86open goals - an Open Source binary compatibility
> standard for operating systems, provided in source code form rather
> than as a paper document (at least at the start).
Well, you ought to know more about it, being as you are in the steering
committee. Seeing as this is supposed to be open, by the way, you might
raise the issue of having some kind of pulicly-accessible archive or
something like that; the way it's now, it's kind of frustrating for non-
members.
Anyway, from what little is there to see, it seems part of the common CVS
thing, not something specific to any distribution. (Being as it's based on
glibc, and Debian is using glibc, I would expect this to be integrated
into Debian as soon as there is something available to integrate.)
MfG Kai
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: