[indiana-discuss] Technical constitution

[Geoffrey Teale]

On 09/06/07, John Sonnenschein <johnsonnenschein at gmail.com> wrote:
>
> I'd just like to say this right now,
>
> I think it's of the utmost importance that if this project is going to
> go forward, a technical constitution is written and approved ( as in,
> "under no circumstances... no matter how many people want it, will we
> integrate unstable software just because it's flashy and trendy" ).
>
> Democracy is a fine thing but it's not without it's perils, and
> there's a reason western democracies all have constitutions. Sometimes
> the majority is wrong and needs some time to cool off and really think
> about it.
>
> Since one of this project's goal is to attract linux users for some
> reason, it's important to not allow voices of reason to be drowned out
> by recent migrants that may or may not be trustworthy from a technical
> design perspective.
>
> Just putting it out there...
>
>
This is the first thing I've said on this list, so "hi".  Apologies for
starting with a small essay :-)

I would classify myself as a recent migrant - though I've been using Sun
OS/Solaris in one way or another since the mid 1990's, my primary OS has
been Linux for pretty much the same period and my day job is Linux
programming.

I totally take the point that whilst there is a lot to learn from Linux
there are things that should not be abandoned.  Heres my insight (for what
little is may be worth), I talk a lot about Debian and Ubuntu here, but
they're just examples (and hopefully ones everyone will be familiar with) -
in the day to day I run Arch Linux and Solaris Express.

Constitution
---------------
Sure, good plan, so long as it's simple and it doesn't act as a tool to
undermine leadership.  No matter want the license (and licenses are
important and an area where OpenSolaris could do with a serious review)
leadership is what makes things work and, if used properly, can cut through
a lot of the bureaucracy and pointless debate.

Stability vs. new software
--------------------------------
Stability is an important goal - particularly in an OS that is likely to do
a lot of it's work in the server room.  However a lesson from Debian -
stagnate and die.  Debian has fanatical supporters who would never would
abandon the OS - but most of them run unstable.   We used to use debian as
the basis of our product, but we dropped it because it's best feature was
it's stability, but it's stable releases were so far apart that we could
never get it to work on our laptops without recompiling the kernel and
repackaging so much stuff that it was becoming unworkable.  Interestingly it
was far more politically acceptable to "roll our own" than use a variant
marked "unstable", though the effect was similar.   Instead we now use
Ubuntu.

So the answer here, I strongly believe is this:  cherish stability, work
towards delivering well developed, tested, reliable software, but work to a
release cycle that allows you to integrate new pieces and release them in a
timely manner.   That doesn't have to mean integrating that latest openGL
hack that makes your taskbar drip with sweat when CPU temperature goes above
40 degrees, but it does mean delivering the new Intel wifi driver in a
timely fashion.

It's also important to have that unstable option.  Why?  Well the key to
stability is testing, not running scared from new things.  Also how can you
be a reference distro if you're not leading the way?


A few final things:
----------------------
One thing that Solaris does need to retain is a differentiation from Linux.
I've said some nice things about Ubuntu's short(ish) release cycle and the
fairly common idea of a rolling, unstable release.  There are things that I
*really* hate about Ubuntu though and a lot of them are about legacy from
Debian.  They are, in no particular order:

* A community often so wed to the existing way of doing things that they
even comprehend a better system.

* A package management system that works well, but is complex to develop
against and is only made easier by wading through a myriad of organically
occurring tools with inconsistent interfaces and naming conventions (really,
making .debs still sucks).   If you want the community to support your
packaging system a simpler way is  better.  RPM is easy, the Arch Build
System is even easier and equally as capable as deb/apt-get.  See
http://aur.archlinux.org for an example of what the community will do around
a relatively small distro given a nice simple toolset.

* A tendency to bend applications to fit the distro rather than leave them
as their maker intended.  Sometimes this works well (Debian's Common LISP
support integrates nicely with ASDF), but sometimes it's terrible.  More
importantly when it happens to an application you care about it's
frustrating ("this should work like this, but something else is happening,
WTF?")  and gives the overriding impression that the packagers are arrogant.

I'll shut up now :-)

--
Geoff
<tealeg at member.fsf.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/indiana-discuss/attachments/20070609/42361e63/attachment.html>