I am using disqus because it allows me to push all the comment management stuff offsite. Hooray!

When I began using Arch, we had the philosophy that we were "as vanilla as possible". This means that we trusted the upstream developers. If an Arch user wanted featureX, they contact the upstream developers, asked for featureX. Whatever upstream's decision, yes or no, we went along with it. We did NOT add the feature to our package anyway.

When I began using Arch, we had the philosophy in mind to "Keep It Simple, Stupid". This means that if things were too complex, we did it another way, or didn't do it ourselves. Someone wanted custom hardware modules? They could build them themselves.

When I began this all, we kept things as simple as we could, and allowed (and actually encouraged) people to change things they wanted to. This was the core of Arch - if you don't like it, do it yourself. We told people "If you don't like how the maintainer did that, use ABS and rebuild it". We told people, "If you want a package for that, make it yourself". We had users that knew this, and worked in tandem with us. Some users provided custom repos, different PKGBUILDs, alternatives.

This has all changed. For the worse. And it shows in the mentality of our patching. One user requests a feature, we apply a patch - we don't worry about upstream. One user has a brand-spanking new sound card, kernel gets patched. One user doesn't like a configure flag in a package, it gets changed.

We can't continue like this. Arch wasn't made to sustain itself in this way. Arch was made to work in tandem with the users - users that can help themselves AND us. Arch was made to work with you, not for you.

I've been out of the hardware world for some time, so this is a call to anyone who is good at this sort of thing. I need help finding new hardware. Disks, RAM, that sort of crap - not a big issue, but I don't know what the status-quo is, nor do I know what top-of-the-line is.

So what should I be buying? Quad core? AMD? Intel? What are the current trends in motherboard chipsets? Any hardware recommendations?

Feel free to send me your recommendations over jabber, or email.

Thanks in advance

I had an interview in Boston recently, but I don't know if the area was really for me - when explaining it to dan, I used the term "monocultural". Currently I'm taking a peek at Seattle and maybe places in California (ugh, expensive).

So we'll see where this goes. I may or may not be moving across the country in the near future. Where to, however, is fuzzy at the moment

Yeah, the power supply went kaput. So I pulled it out, and left the box sitting there. This just happened to be my "always on" machine which managed my torrents, had my music shares, ran phrik (the lovable #archlinux bot), and kept a running irc connection.

Well, it's been a few days without perma-idling in IRC, and I've learned something. It makes me feel better to keep it off.

Being ever-present in IRC makes me think "man, I should check my IRC window, maybe something important happened / was said". This is simply not the case. Important things don't happen in IRC. Idle chatter does. Wasted time happens.

So, when all is said and done, I've decided not to idle in IRC anymore. I will miss some of the #archers banter, but all-in-all this is for the best.

Now, I just need to go buy a new power supply. Oh, and a bigger disk. Oh, and some of those. Oh, and that too. No, no, I'll take three.

Sadly, Arch wasn't an install option 8(

Update: Since this writing, Slicehost has added Arch slices. Awesomely enough, they are running Arch64! This means I will need to back up my slice, and get all the data off here, and then reimage. Luckily, my blog and everything is a bunch of static files. Yay!

Here is my take on that document. My version of what we provide the user.

In short, the Arch Way is about simplicity and giving control to the user. Keeping things simple, and agile.

Arch is lightweight and simple, like clay - able to be molded by the user as they choose.

Arch is not a distribution made for "user friendliness". It is a distribution designed to be a platform - a "base" for the user to do what they want. This means that we don't try to force a user's hand into our way of doing things, with our configuration tools, and our ideas. It should be about their ideas.

It is important who controls the system here: the user. Developers suggest things, and push in certain directions, but let the user do as they wish.

Arch is a base for anyone to make into whatever they see fit. Arch is a tool.

Use it well

Furthermore, the driving philosophy behind Arch is provided in this document. Here, again, is my take on this (really just reworded).

• Keep It Simple, Stupid: A simple design is usually the most elegant (See also Occam's Razor)

• 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap.

• Relying on complex tools to manage and build your system is going to hurt the end users. Maintenance and upgrading should be an active process, not a passive one.

• "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding.

• We can't help you. Yes this is a philosophical point. Every Arch user is expected to be able to help themselves - to be able to look up information, configuration files, bugs, etc. You're expected to be able to do a little research when you have a problem. Teach a man to fish, and all that.

• We are, above all, a community oriented distro. Contributions and effort from the end users should never be discouraged.

• Unlike other distros, Arch is not primarily concerned about the user. The user is important, sure, but most important are simplicity and elegance. The user is important as long as it does not interfere with these doctrines.

• "It is what you make it" -- Judd Vinet

Hooray!

See, I have one defining principle that is covered pretty well in the Python Philosophy.

Now is better than never.

Really, this is a simplification of Pareto's principle - also known as the 80/20 rule.

See, I am a strong supporter that completing 80% of the work that is "easy" as soon as possible and in a functional manner, is far better than waiting for 100% completion.

To make this an analogy: If I were building a house and it's the only shelter I had, I would rush to at least get the roof up. That's just a small portion of the work, but it is functional - I could sleep under it and all that fun stuff.

When I try to explain this to people, I describe it like molding clay. If you are sculpting a 1:1 scale human being, out of clay, you don't start on just the ear, make it perfect, move to the cheek, make it perfect, etc. No. You take a lump and make it look kinda like a human, maybe add some small details, go over it with another pass, add some muscle definition, another pass to clean up some things and fix inaccuracies, and another pass for fine details.

This is how I attack these things.

You don't need a perfect fool-proof plan. It's impossible to make something fool-proof, because fools are so ingenious. Someone will always piss in your proverbial cereal. Accept it. Accept that 80% is just as good. Accept that the ear doesn't need to be perfectly defined right away.

For those of you who don't monitor my every move (and why haven't you started?), there was some recent news involving my life:

Read this first

Yes. That means I'm now the "big hat" in the ArchLinux world. It's a mixed blessing - as a whole I think we both need and fear this sort of thing.

But, that's how life works. When life gives you lemons, and all that. I'm here right now to give a sort of informal roadmap to anyone who may be watching. I figure this will percolate out to the community at some point, but this way I can keep the vision small and open for discussion.

I plan on making some changes soon to the way ArchLinux is run as a whole, and I guess I'll kinda give a preview here.

See, something like this is easy when you have 3 or 4 people, with similar goals and ideals. But when you hit 30 or so developers, that's when you run ashore. What you need, at that point, is something to keep everyone in line, something to keep everyone from going off on different tangents.

You need Process.

I know. It's a frightening word for anyone who has ever worked in a heavy corporate environment. But we need it. The more hands we have doing different things, the more opportunity we have to introduce human error.

This process begins with the new [testing] repo policy. That is, if a package is in the core repository, it must always go to the testing repo and be "signed off" by another developer. It is more important to ensure the stability of the core repo than to have updates minutes after they are released.

In the coming weeks, I am also planning on defining a set of "roles" or "teams" for our developers. Right now, everyone is just a generic "I do everything" guy. Again, this works when you are small, but doesn't work anymore. Everyone can't and shouldn't do everything.

So what we gain is a set of specialists instead of a group of generalists. Instead of "I work on ArchLinux", it's "I work on for ArchLinux".

More to come, don't worry.