5/6
Castellano | English
Entrevista: Al Equipo Arch Linux 5/6
publicado por Jordan Spencer Cunningham el Lunes 11 de enero del 2010 a las 15:57 hs UTCArch Linux Team, 5/6
¿Qué parte del desarrollo del Arch Linux es la más activa?
Thomas Bächler: Definitivamente, los monos paquetes de actualización.
Allan McRae: El empaquetado.
Aaron Griffin: El empaquetado es, bien de lejos, la parte más activa, seguida de cerca por el desarrollo de Pacman.
Ionut Biru: Hmmm. Empaquetado, empaquetado y empaquetado.
Ronald van Haren: Supongo que es la parte del empaquetado. Además, el desarrollo de pacman que es bastante activo en estos días.
Pierre Schmitz: Definitivamente los paquetes. Nuestra lista de confirmación es muy útil en este para comparar su servidor de correo. ;-)
Pero no nos olvidemos de nuestro equipo de desarrollo de pacman. Creo que es nuestra "real" codificación de los proyectos, esta es la más activa.
Dan McGee: ¿Qué parte de Arch Linux es la más activa?: los paquetes.
¿Qué parte del desarrollo de Arch Linux es la más activa?: No estoy realmente seguro.
Esta es una cuestión que me molesta un poco. Tiendo a pensar que tenemos un montón de gente que se ocupa de empaquetar, que hacen un buen trabajo en lo que hacen, pero que no hacemos lo suficiente, porque el desarrollo insume un montón de nuestro tiempo. Podríamos utilizar mucho más esfuerzos en la automatización de algunos de los procesos de empaquetado, e incluso hacer reconstrucciones automáticas de [core] o [extra] cada cierto tiempo (algo así como el tinderbox de Gentoo).
Hugo Doria: ¿Alguien habló de "empaquetado" ya?
¿Qué es lo que menos le gusta de Arch Linux?
Thomas Bächler: ¿Sugiere Usted que hay algo que me disgusta?
Dieter Plaetinck: Las cosas que se rompen. Especialmente roturas de paquetes que son de uso poco frecuente en Arch, y que son un dolor de cabeza, porque estás por tu cuenta. Pero cada distribución tiene roturas, y en el Arch, es más fácil de entender.
Allan McRae: Los usuarios. Al menos los exigentes ...
Aaron Griffin: Hmm, una pregunta dificil esa. Lo que menos me gusta, no es algo que sea realmente específico de Arch. No me gusta en lo que se esta convirtiendo el entrelazados de los componentes del sistema en Linux. Tomemos, por ejemplo, la dependencia de Xorg de hal. Xorg necesita a hal para detectar los nuevos teclados y ratones (mouses) que están conectados. Lo que parece ideal, pero esto siempre ha funcionado en el pasado y bien hal. Parece ser que HAL es imprescindible para cubrir esos casos extremos. Lo que tiene una contrapartida, hacerlos, comúnmente, mas dificil de manejar. Lo que contradice a los fundamentos de Arch por el cual un caso común debe ser sencillo.
Ionut Biru: Nada. Las cosas que me gustan son las decisiones que toman los desarrolladores de software y/o mantenedores del mismo.
Tobias Kieslich: Arch Linux trata de mantenerse focalizado, pero de vez en cuando las cosas fracasan. En cuanto a Linux en general, todo HAL -> (lo que sea)-kit -> cadena de permisos de manejo es una pesadilla. No sólo falla en la funcionalidad específica, sino que cambia constantemente. Y como evidencia tenemos lo que trató de hacer Fedora (permitiendo a los usuarios instalar paquetes), lo que se convierte en una pesadilla en términos de seguridad también. En aras de buscar un confort (algo discutible) siguiendo el camino de Windows. ¡Lo que me inquieta y mucho!
Ronald van Haren: Nada.
Pierre Schmitz: Es que todavía no ha llegado a una posición óptima para ser promovido en los países de habla germana.
En serio, hay un montón de cosas para mejorar, pero no puedo nombrar a algo que realmente me moleste.
Hugo Doria: Yo creo que necesitamos más usuarios que prueben el sistema y que reporten errores. Por ejemplo, hay algunos paquetes que permanecen en [testing] durante algún tiempo, pero los usuarios no lo ponen a prueba, lo que hace que encontremos los problemas cuando el paquete se mueve al repositorio principal (core / extra).
¿Ha considerado la construcción de un sistema de paquetes rígido y el uso de un kernel patcheado con grsecurity?
Thomas Bächler, Giovanni Scafora, Ionut Biru, Ronald van Haren: No.
Allan McRae: No. La necesidad esta, evidentemente, pero no hay ningún proyecto determinado de la comunidad que haya comenzado realmente el trabajo.
Aaron Griffin: Como se dijo antes, el Arch trata de proporcionar un sistema de base para que otros puedan añadir lo que necesite. Si fuera necesario un equipo de rigidez/grsecurity, es un asunto trivial, pues bastará con proveer a pacman de repositorios que lo hagan. Si Arch se hace popular, siempre se podrá integrar en el sistema de central de Arch.
Pierre Schmitz: No, todavía estoy bien con un kernel vainilla, y creo que ofrece una configuración sana y segura y, por supuesto, las actualizaciones periódicas.
Dan McGee: Preguntas como esta provienen de un lote. Los proyectos comunitarios son anunciados en el BBS y después ... nada. Todo comienza con la comunidad que recibe y hace correr la bola, y durante los 3 últimos años no he visto esta bola en ninguna parte.
¿Dónde se centra principalmente en el desarrollo para el equipo de Arch Linux (la instalación, Pacman, etc)?
Todos: Empaquetado.
Aaron Griffin: Sí, más trabajo y tiempo se dedica a los empaquetados. Es un trabajo ingrato. Yo mismo, sin embargo, tiendo a (tratar de) trabajar en algunas de las herramientas internas que en realidad nadie ve, como los scripts que gestionan nuestros repositorios, las herramientas que construyen nuestras ISOs de instalación, y cosas así.
~Interview: Arch Linux Team 5/6
posted by Jordan Spencer Cunningham on Mon 11th Jan 2010 15:57 UTCArch Linux Team, 5/6
What part of the Arch Linux development is the most active?
Thomas Bächler: Definitely the package update monkeys.
Allan McRae: Packaging.
Aaron Griffin: Packaging is by far the most active part, followed closely by Pacman development.
Ionut Biru: Hmmm. Packaging, packaging and packaging.
Ronald van Haren: I suppose that is the packaging part. Also, pacman development if fairly active these days.
Pierre Schmitz: Definitely packaging. Our commit list is a great use case to benchmark your mail server. ;-)
But let's not forget about our pacman development team. I guess of our "real" coding projects, this is the most active one.
Dan McGee: What part of Arch Linux is most active: packaging.
What part of Arch Linux development is most active: I'm actually not sure.
This is one issue I am a bit sore on. I tend to think we have a lot of packagers that do a good job at what they do, but we don't do enough development because that is taking up a lot of our time. We could use a lot more effort in automating some of the mundane packaging process and even doing automatic rebuilds of [core] or [extra] every so often (something like Gentoo's tinderbox).
Hugo Doria: Someone mentioned "packaging" already?
What do you like least about Arch Linux?
Thomas Bächler: Are you implying that there is anything I dislike?
Dieter Plaetinck: Things that break. Especially breakages for packages that are infrequently used on Arch are a pain because you're on your own. But every distro has breakages, and in Arch it's just easier to figure out.
Allan McRae: Users. At least the demanding ones...
Aaron Griffin: Hmm, tough one. What I like the least isn't really Arch specific. I dislike how intertwined all the system components of a basic Linux system are becoming. Take, for instance, the Xorg dependence on hal. Xorg needs hal to auto-detect new keyboards and mice that are plugged in. Sounds ideal, but this has always worked for me in the past without hal. It seems like hal is necessary to cover the edge cases, but this also makes the common cases more unwieldy. This is contrary to the basics of Arch - the common case should be simple.
Ionut Biru: Nothing. Things that I dislike are about upstream decisions.
Tobias Kieslich: Arch Linux tries to stay focused, but every once in a while things fail. As for Linux in general, the entire hal -> (whatever)-kit -> permission handling chain becomes a nightmare. Not only does it fail to deliver that targeted functionality, but it keeps changing. And as by evidence of what Fedora had tried (allowing users to install packages), it becomes a security nightmare, too. For the sake of (questionable) comfort headin' down the Windows road. Leaves me uneasy about it, very!
Ronald van Haren: Nothing.
Pierre Schmitz: It's name is suboptimal for promotion in German speaking countries.
Seriously, there a lot of things to improve, but I cannot name one that really annoys me.
Hugo Doria: I think that we need more users testing the system and reporting bugs. There are some packages, for example, that stay on [testing] for some time, but the users do not test it and we just find the problems when the package is moved to the main repos (core/extra).
Have you ever considered building hardened system/packages and/or using grsecurity patched kernel?
Thomas Bächler, Giovanni Scafora, Ionut Biru, Ronald van Haren: No.
Allan McRae: No. The need is obviously not there given no community projects have really started the job.
Aaron Griffin: As stated before, Arch tries to provide a base system for others to add on to. If hardened/grsecurity stuff is needed, it's trivial for someone else to provide a pacman repo with packages that do this. If it becomes popular enough, it could always get integrated into the core Arch system.
Pierre Schmitz: No, I am still fine with a vanilla kernel, and I believe in sane and secure configuration and, of course, regular updates.
Dan McGee:
Questions like this come up a lot. Community projects get announced on the BBS and then...nothing. Everything starts with the community getting the ball rolling, and for the last 3 years I've seen this ball go nowhere.
Where is development primarily focused for the Arch Linux team (the installation, pacman, etc)?
All: Packaging.
Aaron Griffin: Aye, most work and time is spent packaging. It's a thankless job. Myself, though, I tend to (try to) work on some of the internal tools no one really sees, such as the scripts which manage our repos, the tools that build our installation ISO, and things like that.