Re: on forming a new Linux Distribution
bruce@pixar.com (Bruce Perens) writes:
> 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.
You are searching developers who will put significiant time into
making parts of Debian (or the distribution-to-be) more
user-friendly. Whenever you found them: Why don't they put their time
into Debian and work on the relevant parts of Debian? This would save
them a lot of duplicate work. I think even Debian developers for who
user-friendliness isn't a top priority will be glad to see someone
else do it.
> 2. Maintaining a non-commercial alternative to the commercial Linux
> distributions.
> I think Debian's drifted too far from the mainstream of Linux
> to continue to fulfill this purpose.
Heavily depends on the defintion of "mainstream". As I got it you
believe that RedHat is to define what mainstream is, and mainstream
has to use rpm. (You are invited to correct this.) As you know I don't
share this definition.
> 3. Provding shared maintainance on the base system for all Linux
> distributions.
That's what Dominik Kubla wanted to do. He pointed out that this has
nothing to do with creating a new distribution, since such a base
system approach will not be accepted by other distribution people when
you start building your own distribution on top of your own base
system. Thats the one point where I agree with Dominik ;-)
BTW: What is the current state of Dominik's project (FreeLinux (?)).
A base system has to be small, a distribution has to be big.
> This is another early goal of Debian that we've not ever fulfilled.
There weren't that many people who pursued this goal, hence I don't
consider this to be Debian's goal.
> 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.
We probably don't need it. As long as people volunteer to maintain the
packages we can distribute these packages with nearly no extra
effort. Remember: Per Definition non-free and contrib aren't part of
Debian. We might want to express this more clearly by moving
directories around, but that isn't urgent.
> 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.
Why is this necessary? IMHO the biggest problem is the (mis)use of the
mailing lists. There are to many people chatting about to many things
on too many mailing lists. People who know enough to package software
for Debian don't necessarily have enough inside knowledge to discuss
larger design issues. (And I'd like to see a split between technical
and non-technical issues for -devel).
> 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.
I don't know which of these ways is better. I know how things worked,
and this leaves enough space for both improvement and worsening. I
didn't understand which problems the constitution is expected to
solve, so I have no idea what it will cause.
> 6. Direct Commercial Participation.
That's only important for the base system. (IMHO)
> 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.
"Real developers" tend to disklike marketing. You didn't tell us what
this marketing team is going to do. (E.g., in case they will start
promising impossible things they will become a pain for honest
developers.) Marketing may have positive effects, but you have to name
them.
>
> 9. A Random List of Other Goals.
> RPM as the package system
We've been through this before. dpkg's is design is good. Someone has
to fix the bugs.
> COAS as a system management framework.
Why not? Who is going to do this?
> Non-interactive install.
Goal accepted. I haven't seen relevant proposals lately.
> Limited set of interpreters for system tasks and pre-install and
> post-install scripts. How about ANSI shell (_not_ necessarily Bourne
> shell),
Do you mean POSIX shell? I have never seen an ANSI shell specification.
> 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.
There is no point in asking for holy wars.
> No obscentity. Avoids legal problems and makes _me_ feel better.
> There is lots of room for free-speech distribution sites on the net.
We might want to handle this in an
internationalization/localization-like approach. Have local teams
create localized distributions for the people who don't want to see
something. As we discussed before the obscenity definition is
sufficiently unclear and depends on a lot of local factors.
Sven
--
Sven Rudolph <sr1@inf.tu-dresden.de>
http://www.sax.de/~sr1/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: