[arch-dev-public] Goals / Mission Statement

[Jason Chu]

> I would like all of you to read through these (feel free to add your
> own) and try and list 3-5 of these that you feel are important.  On
> Thursday, I'd like to compile a list of the responses, and we can go
> through and cherrypick our goals from this subset from everyone - yes
> this includes those of you without write access to this list.  Email
> me directly, if you want to remain anonymous.
> 
> Please look these over, and reply with anything you feel is important.
> 
> Thanks,
> Aaron
> 
> ----------------- Dev Wiki Entries -----------------
> 
> * Provide the latest software as is practical, while aiming to achieve
> a reasonable level of stability
> 
> * Not be dependent on any graphical interface for any system function
> 
> * Remain a lightweight, general purpose distribution that is simple in
> it's implementation
> 
> * Continue to be a strongly community oriented distribution
> 
> * Provide a good set of reliable and modern Linux technologies for
> desktop, server and portable PCs
> 
> * Be equally suitable for home, educational, small business and corporate use
> 
> * Provide a solid base for creating custom Arch (ISOs and repos)
> variants for users specific purposes
> 
> * Remain a "install once, run forever" distribution
> 
> * Provide good i18n and l10n support
> 
> * Simple design. Reasoning: "Debugging is twice as hard as writing the
> code in the first place. Therefore, if you write the code as cleverly
> as possible, you are, by definition, not smart enough to debug it." –
> Brian W. Kernighan
> 
> * Vanilla. As few patches as is reasonable to make things play
> together in the ways necessary, and then primarily as stopgap
> solutions until things get fixed upstream. This creates predictability
> and allows smart people with general GNU/Linux knowledge to pick up
> Arch instantly. It also keeps us from maintaining more and more custom
> patches over time.
> 
> * Easy packaging with pacman. The SINGLE thing that will probably keep
> me from ever leaving Arch is how simple it is to create packages with
> Pacman. The thought of ever having to write another RPM spec file or
> something else as obtuse or complicated or ill-conceived as that makes
> me want to toss my lunch. When I find new software on the Web to help
> me do my work, I can have it packaged and integrated into my bag of
> tricks usually in less than an hour. As a result of this simplicity,
> we have a Community who understands what's going on and can be
> productively helpful and supportive of each other.
> 
> * Binary distribution. Unlike Gentoo, we can download and install
> Firefox on a reasonably fast machine with a reasonably fast link in
> less than a minute. Also, we test and certify binaries, so quirks of
> people's machines don't bugger up their compile processes. The result
> is that after a pacman -Syu, on any machine, most things just work.
> 
> * This might not be exactly where or what we are, but someone once
> called Arch a "meta distribution". That is, it gives you tools and a
> very nice base with which you can do whatever you want. I think this
> also coincides with 2 of the "goals" I would like to see - that is,
> (a) like Andy said, we provide a very nice base system and not much
> more, and (b) "Slackware with pacman" - we get likened to Slackware
> enough, and I think the simplicity that slackware strives for is ideal
> for us as well.
> 
> * I say focus more on the core packages.. the underlying fundamentals.
> Push the addons higher into the stack. I liken Arch to one of the
> BSD's, oddly enough. The BSD team focuses on handling the core. They
> deal with things that come about when the system goes from poweroff to
> running a base network os. Then ports managers handle the packages
> that lay on top of this core system.
> Just a thought.

Some of these goals are so vague that they could be interpreted to mean
anything...

Either way, here's my list, some copied some made up:

- Binary distribution.  Things can just be installed and (possibly with
  some configing) work.

- Vanilla packages.  As few changes to the original package as possible.
  If someone wants to know how to configure a package, the original
  documentation should be as good as anything we put out.

- Not get in the way of the user (of the distro).  Don't force them to jump
  through hoops to get common tasks done.  Don't force them to learn the Arch
  Way of doing things.  This goes along with the vanilla packages goal.

- Help as much as possible.  This goal is secondary to the not getting in
  the way goal.  If you have to make a choice between being helpful and not
  getting in the way of the user, choose to not get in the way.

- Include the community in as much of this as we can.  We're
  making/distributing this distro so that people can use it.  If they don't
  like using it they'll leave.  If they can offer help, then we should accept
  it.

I don't like any goals that try to define what sorts of packages we include
in the distro, especially ones that limit the total number of packages and
push responsibility for everything else to someone else.  Arch Linux
includes more than just a core.  Without the other packages, it's just a
fancy way to see a bash prompt.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20070529/6ed9f2a7/attachment.pgp>