Entrevista: Al Equipo Arch Linux 4/6 | Interview: Arch Linux Team 4/6

4/6

Castellano | English

Entrevista: Al Equipo Arch Linux 4/6

publicado por Jordan Spencer Cunningham el Lunes 11 de enero del 2010 a las 15:57 hs UTC

Arch Linux Team, 4/6

Una de las características más notables de Arch es su modelo de desarrollo contínuo (rolling release), que garantiza a los usuarios que siempre dispondrán de la última y más reciente versión de un programa disponible. Este modelo ha traído algunos inconvenientes notables (por ejemplo: los programas que dependen de viejas librerías que ya no están en el sistema, por ende, no reciben una actualización).

Thomas Bächler: Hay dos grandes desventajas:

1. las actualizaciones de las Biblioteca quiebran la compatiblidad ABI y API. En el primer caso, tenemos que reconstruír masívamente nuestros repositorios de pruebas (testing) para lograr que todo sea compatible de nuevo al final. En el último caso, y el mismo es necesario, tenemos, también, que encontrar o escribir parches para muchas aplicaciones. Esto no es un gran problema, pero tiene que ser bien realizado.

2. Incompatibilidad de hardware: Hay 2 «candidatos» que siguen rompiendo las computadoras de la gente: Linux y Xorg. Es un ejemplo corriente, muchas de las tarjetas ATI, que son apenas utilizables en Arch ahora - y que se espera mejorar con el lanzamiento de 2.6.32, mas, estoy seguro, que algo va a romperse.

Allan McRae: Reconstruir las bibliotecas, en lo que namebumps son el mayor problema, pero el proceso de reconstrucción de Arch es muy eficiente. Porque tratamos de tener las últimas versiones de los paquetes, que funcionan, a menudo, en cuestiones que no se han encontrado antes, lo que requiere trabajar con upstream para buscar y reparar el problema del código.

Aaron Griffin: El mayor problema con el modelo de desarrollo contínuo (rolling release) es la pereza - de los desarrolladores y los usuarios finales Arch. Intentamos estar al día, siempre que sea posible, pero algunos de los principales desarrolladores son lentos en la adopción de los nuevos cambios. Esto significa que tenemos que hacer trabajo extra para que su software sea compatible con las nuevas versiones de las bibliotecas y otras cosas de esa naturaleza. Costado usuario, la gente que no actualice periódicamente su sistema (algo que indicamos como muy importante), terminan con software más nuevo y bibliotecas viejas en el mismo sistema, provocando roturas.

Giovanni Scafora: Arch Linux es una versión móvil. Eso es bueno, y no he observado ninguna desventaja.

Ionut Biru: Vamos a aclarar algo primero. Tenemos la mas reciente y estable versión de un programa.

Visto que de vez en cuando, tenemos que reconstruir una gran cantidad de aplicaciones y, a veces tenemos que parchear y colaborar con los desarrolladores upstream. Debido a que somos los primeros adoptantes de todo, los nuevos usuarios tienen que sufrir a veces. Xorg y la reescritura de los drivers, es un ejemplo.

Tobias Kieslich: Es una espada de doble filo. Seguro que es un dolor en el cuello tener que volver a compilar la mitad de la distribución para lograr una actualización de ABI incompatible con SSL. Por otra parte, pone de manifiesto los errores y mantiene los paquetes al día. Porque así es Arch, y es por eso que la mayoría de gente lo utiliza, creo que el modelo de desarrollo contínuo (rolling release), sin duda, es beneficioso.

Ronald van Haren: Se requiere una gran cantidad de reconstrucción para algunas actualizaciones en particular, y, a veces un paquete que no es tan ampliamente utilizado se pierde, pero creo que somos, en promedio, muy rápidos en la fijación de estas cosas. Como se requiere signoffs de otros desarrolladores, antes de pasar cosas importantes a los recursos básicos, es muy poco probable que esto le sucede a uno en los paquetes básicos del sistema.

Pierre Schmitz: La desventaja más notable de ejecutar el software más reciente es ver los errores y problemas que nadie había descubierto antes. Pero, afortunadamente, las nuevas versiones de software en general corrigen más errores que los que ellos introducen.

Sin embargo, las regresiones graves son realmente raras como prueba (Testing) de paquetes importantes antes de que ellas pasen a nuestro repositori [core].

Pero como usuario de Arch, uno debe ser capaz de solucionar problemas sencillos y no tener miedo de la línea de comandos.

Dan McGee: Nos encontramos con muy pocos obstáculos que nos impidan adoptar de primera los paquetes al reconstruirlos. Esto es especialmente cierto cuando la construcción de una biblioteca básica incluye reconstrucciones de varios paquetes que a menudo requieren algunos parches para ser compatible con una nueva versión de la biblioteca.

Arch utiliza el sistema de PKGBUILD construir y compilar los paquetes. ¿Qué nos depara el futuro, en la tienda, para el sistema de PKGBUILD? ¿Existen nuevas características o modificaciones que se han previsto?

Dieter Plaetinck: ¿Necesitamos alguna?

Allan McRae: Si. Mejorar el soporte para el funcionamiento de las suites de prueba. Dividir los símbolos de depuración en paquetes separados. La manera en que VCS maneja los paquetes, necesita una reforma.

Aaron Griffin: Voy a aplazar a Allan aquí. Baste decir que las cosas están siempre en constante cambio y siempre mejorando. Esa es la manera en que hacemos las cosas. Respuesta corta: Si. :)

Ionut Biru: El formato general de PKGBUILD es bueno, tal como esta ahora, pero toda mejora, siempre es bienvenida.

Tobias Kieslich: Yo creo que ahora podemos desplegar paquetes separados para un armado simple, lo que es una ventaja mas. Esto deja a los paquetes más pequeños y con menos dependencias.

Arch Linux ha crecido de forma constante basándose en los usuarios, mantiéndose fiel a un diseño de bricolaje sencillo. Sin la mano de la gente, Arch está creciendo y creciendo. ¿A qué atribuye esto?

Thomas Bächler: Arch trabaja. Es así de simple. Una razón es su diseño simple, la otra es que sus usuarios están obligados a conocer y entender su sistema - y nosotros lo hacemos fácil para que todos puedan entender.

La comunidad de Arch Linux es muy fuerte, amigable y se comunica mucho. Tenemos un BBS muy activo y, probablemente, el canal de IRC más activo que jamás he visto. Esta comunidad no es una banda de tontos e idiotas, el/la miembro medio de ella es inteligente y sabe utilizar Linux y Arch.

Otra razón podría ser que nuestros usuarios desean obtener su parte en que finalmente será nuestro éxito en nuestros planes demoníacos y secretos de dominación del mundo.

Allan McRae: Los desarrolladores son impresionantes.

Aaron Griffin: Creo que la gente se está cansando de esas distribuciones Linux que buscan un estilo Microsoft Windows. La gente toda esa automatización con 100 enlaces en cadena, donde sólo basta ver un enlace y hacer fracasar todo, viendo como todo se derrumba a su alrededor. Con Arch, los alumnos ven toda la cadena, no sólo es el final de la cola lo que ven.

Ionut Biru: Yo creo que es porque tenemos un el modelo de desarrollo contínuo (rolling release), porque siempre tenemos la última versión estable de la demanda y porque es fácil de usar. La comunidad juega un rol muy importante, precisamente, porque es amable y servicial con todos los recién llegados.

Tobias Kieslich: Una linda comunidad agradable y útil. Creo que la gente se enorgullece de explicar las cosas y no lanzar a un nuevo usuario a RTFM sólo porque pueden hacerlo. En el otro extremo, tenemos personas con curiosidad sobre las capacidades de Linux y con disposición a intentar y aprender.

Pierre Schmitz: En primer lugar, estoy seguro de que es limitado el crecimiento de Arch. Existe gente a la que no le importa lo que sucede detrás de bambalinas de su sistema operativo, y existen quienes quieren controlar cada bit del misma. Y no me malinterpreten, que ambas posiciones son correctas.

Uno de nuestros puntos fuertes es el de hacer que aunque el sistema evolúe en todos los niveles, aún nos esforcemos por mantener la sencillez. Esto hace que sea fácil para los nuevos usuarios el crear sus propios paquetes y comprender la forma en cómo se hacen las cosas en Arch.

Hugo Doria: Queremos ser «sexy».

¿Qué le depara el futuro a pacman? ¿Dónde está el desarrollo en la actualidad y hacia dónde va?

Allan McRae: http://wiki.archlinux.org/index.php/Pacman_Roadmap

Dan McGee: paquetes firmados son super importantes y apuntan a la siguiente versión mayor de pacman. Además de eso, los métodos alternativos de compresión, deltas, y una mejorada interfaz de base de datos, son las características de gran peso que pueden encontrar su camino en el código en el año próximo.

~

Interview: Arch Linux Team 4/6

posted by Jordan Spencer Cunningham on Mon 11th Jan 2010 15:57 UTC

Arch Linux Team, 4/6

One of the most notable characteristics of Arch is its rolling release model, which assures users that they will always have the latest and newest version of a program available. Has this model brought any noticeable disadvantages (for example: programs that depend on older libraries who aren't on the system anymore because of an update)?

Thomas Bächler: There are two huge disadvantages:

1. Library updates break ABI and API compatibility. In the former case, we have to do mass rebuilds in our testing repositories so everything is compatible again in the end. In the latter case, the same is necessary, but we also have to find or write patches for many applications. This is not a big problem, but has to be done right.

2. Hardware incompatibility: There are 2 candidates that keep breaking people's computers: Linux and Xorg. As a current example, many ATI cards are barely usable on Arch right now - that will hopefully improve with the release of 2.6.32, but I am sure something else will break.

Allan McRae: Rebuilds for library, so namebumps are the biggest issue, but the rebuild process for Arch is quite streamlined. Because we try to have the latest versions of packages, we often run into issues that have not been encountered before, which requires working with upstream to find and patch the problem code.

Aaron Griffin: The biggest problem with the rolling release model is laziness - from upstream developers and Arch users. We try to stay up to date wherever possible, but some upstream developers are slow at adopting new changes. This means we need to do extra work to make their software compatible with new library versions and things of that nature. On the user end, you get people who don't regularly update their system (something we indicate as very important), and you end up with newer software and older libraries on the same system, causing breakages.

Giovanni Scafora: Arch Linux is a rolling release. That's good, and I noticed no disadvantage.

Ionut Biru: Let's clarify something first. We have the latest and newest stable version of a program.

Having that from time to time, we have to rebuild a lot of applications and sometimes we have to patch and collaborate with upstream developers. Because we are early adopters of all, new users have to suffer sometimes. xorg and drivers rewrite is one example.

Tobias Kieslich: It's a two-side sword. It sure is a pain in the neck to recompile half of the distro for an ABI incompatible ssl update. On the other hand, it reveals bugs and keeps the packages up to date. For what Arch is and for what most people use it, I think the rolling release is surely benficial.

Ronald van Haren: It requires a lot of rebuilding for some particular updates and sometimes a not-so-widely used package is missed, but I think we are on average very quick in fixing these things. As we require signoffs from other developers before we move important stuff to core, it is highly unlikely that this happens to one of the system's core packages.

Pierre Schmitz: The most notable disadvantage of running the latest software is seeing bugs and problems no one else has discovered before. But fortunately new versions of software generally fix more bugs than they introduce.

But serious regressions are really rare as we test important packages before they are moved to our [core] repository.

But as an Arch user, one should be able to debug simple problems and shouldn't be scared of the command line.

Dan McGee: We encounter quite a few first adopter hurdles when rebuilding packages. This is especially true when building a core library that involves rebuilds of several packages that often require some patching to be compatible with a newer version of the library.

Arch uses the PKGBUILD system to make and compile packages. What does the future hold in store for the PKGBUILD system? Are there any new features or modifications that are planned?

Dieter Plaetinck: Do we need any?

Allan McRae: Yes. Improved support for running test suites. Splitting debug symbols into separate packages. The way VCS packages are handled needs an overhaul.

Aaron Griffin: I'll defer to Allan here. Suffice to say that things are always in flux and always improving. That's the way we do things. Short answer: Yes. :)

Ionut Biru: The overall format of PKGBUILD is good as it is now, but improvements are always welcomed.

Tobias Kieslich: I think that we can roll separate packages from a single build now is a big plus. It allows for smaller packages, lesser dependencies.

Arch Linux has steadily grown in user-base while still holding true to the simple DIY design. Without holding people's hands, Arch is growing and growing. What do you attribute this to?

Thomas Bächler: Arch works. It's that simple. One reason is its simple design, the other is that its users are required to know and understand their system - and we make it easy for everyone to understand it.
The Arch Linux community is very strong and friendly and communicates a lot. We have a very active BBS and probably the most active IRC channel I have ever seen. And this community isn't just a bunch of dumb idiots, but our average community member is smart and knows his/her way around Linux and Arch.

Another reason might be that our users want to get their share when we finally succeed in our evil and secret world domination plans.

Allan McRae: The developers being awesome.

Aaron Griffin: I think that people are getting tired of Linux distros trying to be more Windows-like. People see all this automation with 100 links in the chain, only to see one link fail and bring the whole thing crashing down around them. With Arch, they gain awareness of the whole chain, not just the tail end that they see.

Ionut Biru: I think because we have a rolling release model, because we have the latest stable version of application and because it is simple to use. The community has a big role because it is friendly and helpful with all new comers.

Tobias Kieslich: A nice and helpful community. I think people take pride in explaining things and not throwing a RTFM on new user just because they can. On the other end of that, stick people become more curious about the abilities of Linux and are willing to try and learn.

Pierre Schmitz: At first, I am quite sure that Arch's growth is limited. Most people don't care what goes on behind the scene of their operating system or even want to control every single bit of it. And don't get me wrong, that is perfectly fine.

One of our strengths is that, while evolving on all levels, we still try hard to keep it simple. This makes it easy for new users to build their own packages and understand the way how are things done in Arch.

Hugo Doria: We look sexy.

What does the future of pacman hold? Where is development currently going?

Allan McRae: http://wiki.archlinux.org/index.php/Pacman_Roadmap

Dan McGee: Signed packages are super important and are targeted for the next major pacman release. Besides that, alternative compression methods, deltas, and an improved database interface are large features that may find their way into the code in the next year.