By Eugenia Loli - Posted on 2005-03-29 19:32:51 UTC at http://OSNews.com
Today we are very happy to feature a huge interview with most of the developer team of Arch Linux [http://www.archlinux.org/], including its founder, Judd Vinet [http://www.zeroflux.org/blog.php]. If you are curious about this young and promising Linux distribution, dig in for more!
Passion, Page 1/9
Judd Vinet: The thrill of creating something that other people use and like. I think that's the main motivation for me now. Arch has already reached a point of "best-suited distribution for me" so it's already fulfilled the goals set out when I started it. Now I find myself looking forward to adding features that other users will find helpful, and looking forward to working with other Archers. I'm truly proud of the calibre of our community and the way we've carved ourselves a little niche in the over-crowded distro contention.
Jan de Groot: Arch suits my needs, though it has its limitations sometimes. I switched to LFS and later gentoo for a while, but didn't like them. After I switched back, I became an archlinux maintainer. Before becoming an official maintainer, I've done most of the work for new gnome releases to get into archlinux using unofficial beta repositories. I am still attracted to archlinux because it's very up to date with new software releases.
Tobias Kieslich: In 2003, when I was tired of over customized distros, I found Archlinux. It had the latest software and did not look so exaggerated complex. As a bonus I got a fast and easy package manager and a distro which makes it easy to look behind the surface and learn the basics of Linux in general.
I like to keep it this way. Make it easy for the user to understand how things work and, by the same time, provide well working packages that don't need much hassle to get in touch with the software. When I come across a new software it'll take me time to get it known by studying the docs and testing some configurations. I like to give on that experiences to the users by transparent packages.
Damir Perisa: I run ArchLinux since 0.4 and since then i never had to reinstall the OS on this laptop. Besides no need to reinstall it, i have always the latest versions of software i need.
The reason that keeps me working on Arch is easy to explain: There are some packages that i use almost daily. Maintaining them needs almost no additional effort and other people who want to use this packages have the advantage that they do not need to care to build / update them themselves. So the only effort i really have is the uploading of the packages. My connection is not the fastest and therefore while uploading my internet is unusable for other things. This is a small price to pay to offer thousands of people hundereds of pkgs ready to be used for productivity and creativity. Opensource software depend on people who are willing to offer some of their time to all the others. In the end, it's a big virtual team of thousands of people helping each other to have working software they can use as tools for their work.
Dale Blount: I love Arch's simplicity and ability to scale if I need it to.
Jason Chu: I've always liked the potential that Archlinux has. Not only is it a good base to start from, but it's still small enough to change quickly.
Tobias Powalowski: I started with 0.6 one year ago and was impressed by the simplicity. An other
point i really liked was that the community was really friendly and it was
really easy to contribute things to Arch. I can use latest features and software and most of the packages i use myself,
so it's not a big deal to upload them to the net. I was searching for a community where i can share my experience with Linux and
i found it in Arch. Quote from Damir ( it's a great explanation):
Opensource software depend on people who are willing to offer some of their time to all the others. In the end, it's a big virtual team of thousands of people helping each other to have working software they can use as tools for their work.
I fully agree to that.
Aurelien Foret: First of all, thanks to OSNews. Indeed, I came to Arch Linux because of an article posted more than two years ago here [http://osnews.com/story.php?news_id=2264]. I immediately got interested by the author's description and the new package manager he mentionned.
All in all, before discovering Arch, I was a passive F/OSS user. I never cared for contributing to the Open Source community, or even subscribing to forums or mailing lists.
Arch changed turned me upside-down. After the first install, I immediately loved it, and it gave me the will to do something. I started to answer posts on the forums, and to report bugs. Several days after I was contributing new packages, and I started to write patches for pacman (Arch Linux package manager). Only a few months later, I got hired in the development team.
To say it all, working on Arch is my way to give back to the community what it brings to me everyday: fun and one of the best OS ever.
Arjan Timmerman: I came to archlinux two years ago, after looking for a new distro on distrowatch.
The KISS part it mentions was exactly what i was looking for. I had ran slackware/debian/gentoo pre1.0 and openbsd before.
None of them suited my needs. I still think archlinux is my distro of choice. i never looked back after this. I was asked by Sarah31 too become gnome maintainer after the gnome maintainer left. The reason that they asked me, was that i builded the gnome1.4 libs so i could run gaim.
Challenges, Page 2/9
Judd Vinet: Time is a huge one. Arch doesn't pay any bills for myself or other developers, so we typically can't work on it during the "make some real money" hours of the day. Lately I've been doing contract work, so I shift my schedule to try to be available during the days, but it's still tough to keep up.
The growth of the community and userbase means more bugs, more feature requests, more lines of communication, and more PR work. Somewhat surprisingly, the development team has met this growth head on and we've handled it quite well. We've always been wary of growing too fast and I think that's been a good thing.
Jan de Groot: Time and motivation. We're not getting payed for our work and lately I've been very busy with other things.
Tobias Kieslich: Speaking of general things, time is a limiting factor. Beside some real life and pay the bills kind of work that needs to be done, I wish I could spent more time on ArchLinux. And sometimes it's hard to make a decision to do some package improvement or to take the guitar and play some tunes.
On a more technical sides, API changes are always a challenge. Was it the freetype2 header change some times ago, that required to touch many packages to include the headers correctly, or most recently the db package with the transaction support. One always run into the risk to break packages. Meanwhile we have the testing repository, to catch much of this trouble before it goes online. But the work needs to be done nevertheless.
Damir Perisa: One of the challenges to me is to provide many good scientific software to the community. One of the points to solve was, that we lacked the GNU fortran compiler and some packages like octave and R do not really like to be compiled with f2c. Since we have gcc-g77 now in the repositories, this challenge is now easier to face.
A not yet solved challenge is to find a standardised way to handle additional java software. Also i plan to write on the documentation, but besides university and other activities i hardly can find some time to spend on it.
Dale Blount: Time. Since we're all volunteers our "real jobs" come first and sometimes we're found lacking the needed time to update packages and to improve Arch.
Jason Chu: Keeping interest. Previously I maintained way too many packages that I didn't use. Each person has a set of packages that are their need-to-have set. If you maintain too many need-to-have packages, you find you're always rushing to get things done. Very tiring.
Tobias Powalowski: Time is the most important factor. We are not full Arch workers and all have their own jobs, studies and so on. We give our best to make Arch as up to date and stable as possible.
The most problems are when a package will not compile anymore and you will have to search for patches or write the patch on your own. Or you have to look for ways that people can have a clean update of their systems, without getting too much trouble while updating.
Aurelien Foret: Time! I'm not working on Arch for a living, and as consequence I have to find a balance between the time I devote to Arch and my social life.
Arjan Timmerman: The biggest challenge is finding the time to do school/archlinux and World of Warcraft.
Popularity, Page 3/9
Judd Vinet: Actually, I'm continually surprised that so many people find Arch to their liking. I thought that the absence of GUI helper utilities would have scared most people off, but it seems that there are many more linux users like myself, more than I thought.
But I can't say I feel any added stress due to the increased popularity. It's just an indication that we're doing something right.
Jan de Groot: It doesn't really matter if 1000 people use a distro or 100.000 users use a distro, when there is a bug, you will get bugs from both groups. With the 2nd group, there are even more people out there that do the actual bughunting for you, so when you're limited on time, it's easy to c&p stuff from the bugreport and make a fixed package right away. I don't put extra effort in archlinux because suddenly more people use it. I work on arch whenever I like and do whatever I want to do.
Tobias Kieslich: There are more requests about features, some of them simply conflict with each other. The more people use the distro, the more diverse needs come together. Since we have some good guidelines to patch software for security and reasons of packaging(Makefile fixes etc.) only it is quite clear which way to go. It doesn't really put more stress to work but you have to consider your decisions better.
In general, the bigger popularity is nice since I have more input and more feedback. The only thing that will never change is: If you make a real good hack to get things working flawlessly, you'll never get feedback on it because the people don't see it. It just works. If you break things the rants will come in faster than you can read them. Well, that's part of the game and it's ok.
Damir Perisa: The actual challenge i face nowadays is to keep being informed about all the activities in the community. Growing means more people and more people means more activities. The bigger the community the more difficult to stay informed. From experience from my other projects i'm involved in (e.g. the Calcutta Project Basel) i learned that to be really productive, you need to know and understand most of the activities that are going on. In ArchLinux, about a year ago, if i was offline some days and came back, i needed some minutes reading posts in the forums/ML to be "back on track". Now, if i'm offline for some days, i need more than half an hour to catch up with the activities. This costs time and time costs productivity.
Dale Blount: Not really, everybody wants the same thing, their Perfect Distro. I try to do this for myself, so added requests don't stress me any.
Jason Chu: As it stands, the main message path between developers and users is through the bug tracker and "flag out of date" button. There have been more bug reports since popularity increased.
Tobias Powalowski: Well not really, the difference is that you get more feedback on your work, negative or positive.
Aurelien Foret: I'm getting frustrated because of this increased popularity, because I just can't read anymore all forum posts or mails from Archers ;) Seriously, it's giving me extra motivation to see more people interested in Arch, and to feel the work done on Arch is useful and appreciated by more and more people.
If you had asked me this question two years ago, I would have answered I'm afraid to see Arch popularity increase. Anyway, Arch is still a healthy distribution today, and there's no reason for things to not keep that way.
Arjan Timmerman: I has decreased, because Jan helps out a lot nowadays.
Maintainance, Page 4/9
Judd Vinet: Lately the kernel package has been particularly annoying. There are many different patchsets one can use, and now that the kernel developers have moved to an often-updated 2.6.X.Y versioning scheme, it makes it more difficult for me to distribute up-to-date, stable kernels. Users don't want to download a new kernel each week, reboot, compile custom modules, etc. so I have to try and space these upgrades out as much as I can.
Jan de Groot: I don't have many packages, but from my own packages, the limitation of arch with 1 PKGBUILD -> 1 package really kills gst-plugins because of the splitup (lucky me I know how sed works, updating 45 PKGBUILDs is a breeze then).
Usually I update gnome packages for Arjan and some mozilla-* packages for Dale. The gnome packages are not that bad, but the mozilla-* packages are horrible when it comes to their build system. If I would be openoffice.org maintainer, that package would go straight to number 1 on the most irritating package to create.
Tobias Kieslich: Ask me this now and I will give you a completely different answer than I would in 4 weeks. Currently the mono software is under heavy development. So it is tricky to provide latest software without breaking too many dependencies.
But I also remember blender some times ago when they dropped autotools shortly after they introduced it. scons building support had still some rough edges and the only way to build it were the old NaN shellscripts which are a bit proprietary. On the other hand, blender is a complex piece of software and it builds on many different platforms. So there is need for more complex build systems. It just takes time to get used to it and it's not really documented apart from some comments in the scripts itself.
Damir Perisa: There are no packages that i "must" keep supporting/updating. Almost all the packages i maintain i also use at least weekly. Some of them are essential tools i use daily. There is always one or two packages that are in a state that is not easy to solve (e.g. when the authors change the URL and you need to search for it or when the authors change the building process or the API without announcing it) but this is often solved by the next release of this software. The actual pkg that is in this state is libextractor that wants a static -lgobject-2.0.
Dale Blount: I bet each of us have our own lists for this question, but I'd say that the packages that need patches to build with the latest toolchain are the ones that annoy me personally the most.
Jason Chu: Lots of packages are annoying in their own way, but if I had to pick the worst one it would be gnomemeeting. The intricacies of gconf fail me.
Tobias Powalowski: Well most time consuming is KDE because it's some kind of monster ;) searching new depends, figuring out bug reports, patch security issues, building/testing and give some support in the forum and irc. but i guess it's not different to others DEVS that maintain the big Linux DEs.
Aurelien Foret: I'm not a good candidate to answer this question: I almost only maintain packages for Xfce, and the ones relating to it. No problem here, Xfce folks are doing a great job :)
Arjan Timmerman: The most painfull packages was openoffice for me it doesn't build with the latest gcc, and before that i needed a lot of patching.
Development, Page 5/9
Judd Vinet: Pacman needs some love. It works well, but we have had plans to turn it into a proper library for a couple years now. Aurelien Foret has been doing most of the work on the library project and we're finally seeing the finish line somewhere off in the distance. In an ideal world, Arch would be my fulltime job and I would have ample time to work on pacman and the distro itself.
Jan de Groot: Pacman would need some work. Porting existing tools like gnome-system-tools to work on archlinux perfectly would also be on my todo list then.
Tobias Kieslich: I think there are some urgent needs take action on a good i18n concept for ArchLinux. From a good base in glibc and the initscripts, over a well considered font support to some good and usable input methods. This also affects the installer and some applications. I18n is pretty much useless if things doesn't really act in concert. AFAIK, none of the developer speaks or can write multibyte based languages ... and my Russian really sucks. But there is some activity in the community going on which needs to be brought to some usable results.
To write documentation is another issues and most developer feel that something needs to be done on this point. If it is documentation for ArchLinux itself or to write some stuff about projects that could be realized with ArchLinux. I'd like to write a guide for an ArchLinux Server without the big and well known software because there is a lot of good and specialized software which fits the need of many people way better than the "incumbents". But no one knows about and how to use it.
Damir Perisa: Having more resources, i would start spending them on my other activities first. Helping other people, doing "cool" research projects, traveling, learning languages, taking pictures ... the list is really long. ArchLinux is not very high in this list, but there are for sure a lot of things i would want to do for it.
One of the things related to Arch is: i would be able to spend time writing on the document i started about a year ago, the "Survival Guide to (Arch)Linux", the introduction to computers, opensource software, linux and the virtual team of people helping each other to reach goals. This document i started to write mainly for people in the 3rd world to help them understand computers and the usage of IT to speed up administrative tasks without forcing them to pay for licences for software where there are "free" and often even better alternatives around. It has now about 30 pages but is a long way from being finished. The reason is the lack of time to work on it.
Dale Blount: I would increase the reach from i686 to x86-64, PPC, and sparc.
Jason Chu: I would put way more time into pacbuild (the automated package building system), devtools (a set of tools to help Arch developers), namcap (the package analyzer), pacman, and other such projects to help Arch. I'm more of a programmer and less of a package maintainer.
Tobias Powalowski: Probably i would write more wikis and docs on stuff that's interesting.
Aurelien Foret: I would like to see our current repositories ported to more architectures, namely i586, PPC, and x86-64. Another cool thing would be to have a "stable" repository with only security issues and critical bugfixes backported to it from our "current" repository.
Pacman, Page 6/9
Judd Vinet: Well, it's less of a problem for those of us with more memory and less reboots, as most of the db will be cached after the first pacman run. But there is a big slowdown for large pacman databases during the first run (since a reboot). This is because pacman has to read many small files, and some filesystems do not optimize for this type of behaviour.
The filesystem-based database has some great advantages, ones that reflect Arch's values more than a dbm backend would, but there are some performance issues that we can't ignore. I'd like to try using a db (or sqlite) backend in the future and see how much of a performance improvement we can get.
The big plus to having a plain filesystem base is that anyone can peek and poke at it, including custom scripts and whatnot. Using a more complicated backend makes it tough to code up a bash script that scans the database.
So I guess only time will tell -- the jury is still out. ;)
Jan de Groot: It is because the many small files. Pacman looks through all of them. In the beginning pacman was fast, but when we did some good work to get tons of packages in the repositories, it became slow. Personally I'm thinking of putting the package database in a BDB format, which is also the easiest.
I haven't worked on this because I want to wait for the modularized version of pacman other people are working on at this moment. It would be a waste of time to convert pacman 2.9 to a BDB format and see pacman 3.0 appear as a complete rewrite after that.
Tobias Kieslich: Pacman's scaling goes well, but it has some serious trouble with file operations on certain file systems, most prominently on xfs and reiserfs if I remember correctly. This could be solved by using a single file for it, incorporating a known database backend such as db or sqlite or maybe some very small free database engine since db or sqlite might be a bit overkill. I think this is related to the unlimited resources question since Judd could make some experiments here to find the "best" solution if he had the time.
I think Judd can answer this better since pacman is his baby.
Damir Perisa: Pacman is the core of ArchLinux and it's concept and features support a really great concept. I myself have around 1200 packages installed on the laptop and when it comes to -Suy multiple packages it takes long to handle the single files where pacman keeps the information-database on the packages. On bad days (kde update) it takes pacman up to an hour to prepare a -Suy (without downloading and updating). This behaviour is not ideal and i wish that pacman would use a more effective way to handle the information-database. My opinion is to use a DB or at least a single file instead of flat single files to speed up this bottleneck. However, the usual installation of ArchLinux does not contain that many packages and therefore times are much shorter. On my old computer (266MHz) where only around 340 packages are installed, pacman reacts almost immediately doing -Suy.
Dale Blount: Luckily this doesn't bother me much.
Jason Chu: While pacman can use work, I also think that it's really great how far it's come. I try not to criticize pacman's failing, instead I submit patches.
Tobias Powalowski: well let judd and the pacman crew find an answer to that.
Aurelien Foret: In my opinion, pacman assumes quite well its job.
Currently, there is a trend to consider pacman would behave better with another database backend, but I don't really share this point of view. Having a flat file based database of packages makes it so convenient and easy to manage that it is virtually almost unbreakable. A different backend, such as gdbm or bdb, would introduce an overall complexity to pacman, which I wouldn't welcome.
There are still some areas that can be reworked to improve pacman scalability, and I think it is better to focus on improving the current implementation than switching to a new backend.
Anyway, let Judd have the final say on this topic.
For the record, I've already tried to implement a gdbm backend for pacman several months ago, but I was disappointed by the results: it didn't make pacman significantly faster.
But at that time, packages repositories were smaller than nowadays, so it may worth spending some time to perform more tests...
To date, I'm quite involved in the process of creating a library for pacman. Althougt it will allow people to develop new frontends for pacman package management functions, my aim is also to help rationalizing pacman structure and cleaning it. Based on that, it will be easier in the future to extend and enhance pacman.
CVS, Commercialism, Page 7/9
Judd Vinet: Nope, nobody's convinced me of a Subversion-only feature that would make the move worth it. None of CVS's shortcomings really faze us, so it's tough to think of a reason to change.
Jan de Groot: No, the only reason I would use SVN is because the stupid server interaction CVS does on every action. This is solved using SSH keys on my side, so this is not really a problem to me.
Tobias Kieslich: ArchLinux uses binary packages that are provided via pacman from ftp/ http servers. CVS is not the only application that is involved in the package changing/building/uploading process. It is part of our build system and the way we provide our package instructions to the users (via cvsup in the abs script). CVS is just controlling the PKGBUILDs and absolutely sufficient for this job. If there are plans to change that I think Judd will have his reasons and tell us about it.
Damir Perisa: It's not up to me to decide this, as i don't run the archlinux.org server but i see no advantage in svn compared to cvs worth the change.
Dale Blount: Let's let Judd answer this one.
Jason Chu: I've wanted to since I started using Subversion, but I don't expect that the other developers share my feelings. I can't find a compelling reason to change because things like cvsup won't work with subversion. The abs command would have to find a different backend.
Tobias Powalowski: let judd decide that, i have no problem with CVS or subversion.
Aurelien Foret: CVS just works and addresses our needs quite well. I don't see a good reason to change it. Hum... maybe this one: moving to Arch system could be nice because it has such a cool name ;)
8. If the popularity trend of Arch continues, do you have plans to go fully commercial and maybe form a company around it?
Judd Vinet: I've been encouraged to do so by a few people, but I'm not sure. To be honest, I'm not much of a business person, so I have trouble thinking of ways that Arch could generate revenue while still being a free product.
Jan de Groot: Linux doesn't sell that good in my country, so if it was only for my country, I wouldn't. I don't think there's really a big market for Arch, because commercial users are looking for more secure and stable distros like Redhat, SuSE or Debian. That leaves us with users like myself that don't need support. These users won't pay for archlinux, at least, I wouldn't.
Tobias Kieslich: There are no plans of which I know. Personally I'm against a direct commercialization of ArchLinux like AL-Home version 6, AL-Server version 3 1/4 etc. This also doesn't work with our rolling release system. Providing service for ArchLinux installations or products based on it is another thing, but also there are no plans.
Damir Perisa: If the growth of the community of ArchLinux speeds up, i plan to create my own distro with a very similar concept but with less people and compatibility to ArchLinux repositories. Maybe with a rewrite of pacman to support mysql. This are however plans i can face not before my studies are finished. Again: Time is the limiting factor.
My comment about commercialisation: Don't!
Dale Blount: Let's let Judd answer this one too.
Jason Chu: I've been saying since I started that I'd do this all day if someone paid me. I fear a company would be driven by pressures from the market though. It's a double edged sword.
Tobias Powalowski: I think on commercialization the problem is that people will get more demanding and expect perfect support, documentation etc. it's judd's baby and he decides in which direction Arch will go. Personally i'm against commercialization.
Aurelien Foret: I don't think Arch Linux was born to achieve this possibility. Anyway, I definitely wouldn't mind getting paid to work on it, although I'm afraid it would probably kill the fun I'm having with Arch...
Installer, Page 8/9
Judd Vinet: Not really. A lot of people like our current installation script. One thing I'd like to have is a "kickstart" style setup for sysadmins who install linux in labs or other settings where each install is more-or-less identical.
Jan de Groot: I don't use the installer at all because I don't really like it, I use a modified quickinst script I use too to set up my build chroots. If we would improve the installer with configuration support, we should also go the same way as debian went with their debconf database. Since we don't want to hack around in people's configuration files, the installer won't get improved in this way.
Tobias Kieslich: The positive effect of the "limited" means of the installer is that people are forced to read the basic documentation. This prevents from asking needles questions and indeed I don't see so many questions regarding how the installer works. Although I personally don't need it, adding support for more file systems and a better i18n would be nice since users request it from time to time.
I don't see the need of configuration front-ends - this would be a totally different and partially contrary approach of the system administration than we have it now with rc.conf and friends. I don't even think it would be useful for newbies. A configuration front-end for admins to get the daily work done is another thing, which shouldn't be provided out of the box and included in the installer. But there are no plans of which I know. Also I don't like to see IRC quotes from users to newbies: "Install easyadmin and you are done..." These people come back and ask other simple things they could get easily from the docs.
For administration of bigger installations I think the support of easier system cloning would be nice, although much could be done via simple shellscripts, thanks to pacman's capabilities. Or a rapid install tool that takes a list of settings like hostname, IP, users etc. and installs a bunch of boxes without confirmation for every point. Oh, unlimited resources ...
Damir Perisa: I'm not involved in the Arch Installer but here my opinion on it: The only feature enhancements in the installer i would find usefull is the handling of more filesystems and exotic devices and a better internationalisation handling. I see no reason to create users via the installer, use a frontend for the configs or mess with other things that are good to left being simple. Everybody who is willing to learn how to do it, will be able to edit a file and use the correct command to create users and groups. What i see that should be done is to work on the documentation to make it even more evident for newcommers that their learning is simpler and faster with less effort. That's also why i said that i plan to work on the docs. I convinced a lot of non-linux users to use linux and i got very positive input from them about how simple archlinux is when you get used to it. The only negative input i got is that the docs of archlinux are a little bit chaotic and you need some time to find the informations you need. By my opinion Arch is a great distro for newbies that are willing to learn. The quote that comes to my mind is: "Give a person a fish and you fed her/him for a day, teach this person fishing and she/he will have a more confortable life."
Dale Blount: I'd hope not. Arch isn't for the beginner and if we make it easier to install, the average user will be confused after install time.
Jason Chu: That depends, if the automation is created to cover up parts of the process that are "too complicated" or "too much to learn", then no. Everyone should want to learn and understand. Then again, if it's to help a lazy (in the positive sense of the word) admin keep their sanity, then yes.
Tobias Powalowski: Arch should support more filesystems, more hardware while installing and ntfs resizing support would also be a great feature. I think we have an automation script on the installer cd, haven't we?
Aurelien Foret: To date, no... but contributions are welcome ;)
Arch Vs The World, Page 9/9
Judd Vinet: Tough to compare really, they're all great distros. I find it flattering to have Arch compared to the likes of Slackware and Debian, as I've always revered them as the time-tested, rock-solid distributions on which other distros are based.
Arch has been largely successful in adopting positive traits of other distributions, and you're quite accurate in picking those four. I think Arch has borrowed some good qualities from each of those systems, especially Slackware and FreeBSD.
Most users who like FreeBSD or Slack would probably like Arch Linux.
As for prerequisite knowledge, you don't need that much to start using Arch, as long as you're prepared to ask questions and read documentation. It's not as involved as we often make it out to be, but having a rudimentary knowledge of the commandline, kernels, modules and hardware config will be a big asset when climbing our learning curve.
Arch assumes you know what you're doing. I like that a lot, because it tends to stay out of your way if you start to wander off the beaten path. For this reason, I think Arch may prove to be a good base for other, more specialized distributions.
Jan de Groot: Debian users should be able to find their way into arch, at least I did. Only thing I had to learn was that apt-get was renamed to pacman, and that a thing like debconf didn't exist.
Arch does not contain upstream documentation in the packages and does not configure things for you. This is something to get used to when switching from debian, since the first thing I did after installing a package was reading /usr/share/doc/$pkgname/README.Debian. Archlinux is more bleeding edge, even more than Gentoo. Things could be broken once in a while, so I wouldn't use archlinux on production systems. I don't keep Debian as server OS for nothing.
Tobias Kieslich: Each of the named systems has been developed with a certain idea to make things better and easier. I think arch brings much of the good things of these systems as it is fast, simple, solid and easy to maintain. Arch doesn't fit every need out of the box. But it can fit them with only little customization by the user.
Thanks for the interview and your patience with my mono-packages :)
Damir Perisa: I would not compare them. All have good ideas behind and everybody should decide idependendly what idea suits her/his needs best. As a student in biology, i know to respect the value of diversity. You cannot argue that e.g. a zebra is "better" than an elephant. Both perform important actions in the ecosystem of the sahel zone in Africa and without one of them, the ecosystem would lack important elements in the chains and processes called life. I think that diversity is also the key to linux. You should not try to convince say a Debian user to use something else because you like it. It has to do with ideas. The possibilities today give the people the freedom of choice. This is a strenght opensource software has compared to commercial products. You often have 2 or 3 kind of software to choose to do be productive.
What i would tell a user who asks me about Arch is easy: I would tell her/him my experieces and the reason why i myself use it. If she/he agrees with my arguentation of the idea of ArchLinux how i see it, she/he decides her/himself to try it or not. The only tip i would make is: If you are a newbie and do not care about learning some basics of linux, forget it! Arch is, as i see it, for the lazy user who is still willing to learn things and is not afraid if this involves the command line. You don't need to be a guru or expert in IT, the only thing you should bring with you is the joy to learn how to use a computer efficiently.
Thank you for the interview and the interest in ArchLinux.
Dale Blount: Arch combines the best from all of these distros. It's simple like Slackware, easy to update like Debian, optimized (although not to the same extent) like Gentoo, and rock solid like FreeBSD.
Jason Chu: I only have experience with Slackware, Debian, and Gentoo. Even then, I don't see what the point in comparing them is. They may all be linux distros but they're all managed differently and have different goals.
To answer the second question, it's not what a power user needs to know, it's what a power user wants to learn. There are many users of many different skill levels who all get along in the Archlinux community. Depending on how you want to use your machine, your knowledge may already be enough. If you're willing to learn, your knowledge *is* already enough.
Tobias Powalowski: Well i don't know the others, i installed once Slackware and i tried Knoppix hd-install but i have no experience with them for running them in long time. I did run SuSE 7.0-9.0 i wouldn't say that it's bad but if you start changing things in SuSE beside the installer you will get trouble and updating was always a little bit cross your fingers and hope it will work. ( i mean from one release to an other.)
Archs-Installer is like Slackware, pacman/makepkg is a great package system it's optimized for i686 and you can tweak Arch to boot really fast, what else a power linux user does want :)
What you need for Arch:
Read the install doc,wikis manpages, learn how to use your favourite editor and some basics of how the files in /etc work together that's all you need. Since Arch delivers the things normally as they are you can read the manual of each package you need and adjust it to your needs.
Don't expect crazy hardware to be running in Arch, but you could be suprised that it may work. If hardware runs in other distros it should also run in Arch.
Aurelien Foret: I've never used BSD, and I prefer to stay away from source based distributions. This being said, I was a Slackware user before coming to Arch, and I found in Arch a perfect extent to my Slackware experience.
I don't consider there's a peculiar knowledge required for an average Linux user before trying Arch. On the opposite, you'll find yourself far more knowledgeable by using it!
Arjan Timmerman: I do not compare them, Arch suits my needs. I never really used. What a power user needs to know before enter Arch's domain? I think know your system and have a basic knowledge of the console.
Original story page here.
Copyright OSNews.com 1997-2006. All Rights Reserved. OSNews and the OSNews logo are trademarks of OSNews.
All trademarks, icons, and logos, shown or mentioned in this web site, are the property of their respective owners.
Reproduction of OSNews stories is granted only by explicitly receiving authorization from OSNews and if credit is given to OSNews.
Privacy statement - Notice to Bulk Emailers