Desde la página Linux.com siguen con su serie de entrevistas a los principales desarrolladores que trabajan en el desarrollo del kernel de Linux. Por ellas han pasado hasta ahora:
- Linus Torvalds, abriendo la serie
- Thomas Gleixner
- Sara Sharp
- Jean Delvare
- Greg K-H
- Dave Jones
- Paul Mundt
- Alan Cox
- Arnd Bergmann
- John Linville
- Johannes Berg
- Martin K. Petersen
- Julia Lawall
- Ben Hutchings
- Mauro Carvalho Chehab
- Jiri Slaby
- Laurent Pinchart
- Jiří Kosina
- Chuck Lever
- H. Peter Anvin
- … y hoy le toca el turno a Steven Rostedt un desarrollador que trabaja ahora para Red Hat y que a veces piensa en montar un Starbucks !
Aqui en este blog (http://victorhckinthefreeworld.wordpress.com/) he traducido todas estas entrevistas, desde que empezaron hace ya varias semanas. Principalmente para mí, porque me interesaban sus historias, y después pensé que estaría bien compartirlas con más gente. No es fácil traducirlas, y trato de hacerlo lo mejor que sé. Si os gustan y créis que son interesantes me alegro, hacédmelo saber para ver si es un tiempo bien empleado…
Esta en especial ha tenido algúna respuesta difícil de traducir por lo técnico de los términos, etc. No dudéis en ofrecer mejoras a la traducción o comentarios.
Estas son una serie de entrevistas que realizan a los desarrolladores del kernel de Linux. Me gusta conocer las historias, y cómo llegaron a desarrollar el kernel y compartirlo con todos. Puedes ver todas las entrevistas traducidas pinchando aqui.
Quizás te sirvan de inspiración para involucrarte, ver cómo ellos antes de ser los “gurús” que ahora son fueron simples usuarios como tu con ganas de aportar algo. Ten en cuenta sus consejos y da el primer paso para implicarte en el desarrollo del kernel.
Si quieres ver el original en inglés visita la página original pinchando aqui. Escrito por Jennifer Cloer a ella y la página original pertenecen los derechos de autor, gracias por permitir la traducción y difusión. Si quieres usar esta traducción lo puedes hacer pero por favor atiende a la licencia CC-by-sa del blog, citando expresamente la fuente original del artículo en inglés, y este blog como creador de la traducción. Empezamos…
Nombre:
Steven Rostedt (me llaman Steven o Steve, no me llames Stephen, ese no soy yo y creeré que estás hablando de uno de los muchos otros desarrolladores del kernel que se llaman Stephen)
¿Qué papel desempeñas dentro de la comunidad y en que subsistemas trabajas?
El trabajo que supongo que hago es trabajar el los parches de tiempo real del kernel de Linux. Mantengo los lanzamientos estables de los parches de tiempo real, y debo seguir la línea principal de los lanzamientos estables.
Hace tiempo, estuve trabajando en conseguir incorporar una infraestructura de la latencia de rastreo del parche -rt dentro del kernel, también combinado con una herramienta de rastreo que escribí hace años y que a acabado siendo lo que ahora se conoce como ftrace. Ftrace ha terminado siendo un pionero en la rama principal del kernel como infraestructura de rastreo. Otras herramientas trataron de convencer de la utilidad del rastreo a los desarrolladores del kernel, pero no fue hasta que llegó ftrace que los desarrolladores del kernel se dieron cuenta. Entonces todos empezaron a usarlo y en la actualidad hay alrededor de 700 eventos en todo el kernel.
Mantenerse actualizado con la demanda me ha apartado de trabajar más en -rt (aunque todavía doy prioridad al mantenimiento de -rt estable) Lo que me ha llevado a crear otras herramientas como trace-cmd y kernelshark. Lo que ha implicado otros eventos perf de software.
¿De dónde recibes tu nómina?
Red Hat me paga por mi afición 
¿En qué parte del mundo vives, y porque allí?
Vivo en Endwell, Nueva York, que comparte el mismo código de correos que Endicott, Nueva York, que es donde me crie. Una pequeña curiosidad. Hace 100 años IBM empezó su andadura en Endicott, así que nací en la misma ciudad (si quierees llamarlo así) que Big blue.
Mi padre fue director de IBM, y le trasladaron a Endicott a finales de los 60. Aunque IBM ya no está aquí hace tiempo, ya que era muy grande a principios de los 90. Lo que me lleva a preguntarme porque sigo aquí.
Me gradue en Ciencias de la Informática (N.del T: No sé si eso será un término correcto) en 1991, durante el periodo de recesión lo que fue un problema para encontrar trabajo. Incluso estuve trabajando de introductor de datos para la oficina del servicio de impuestos de Nueva York. Finalmente mis deudas eran mayores que mis ingresos y en vez de terminar viviendo por las calles, lo dejé todo y volví a la casa de mis padres.
Allí encontre un trabajo en GE (N.del T: ¿General Electric?) y mi primera toma de contacto con sistemas en tiempo real. Me permitió poder dejar la casa de mis padres. Hice pruebas para el control del motor C17. Despues GE fue comprada por Martin Marietta y después por Lockheed por lo que se convirtió en Lockheed Martin. Al mismo tiempo fui a trabajar a IBM Federal systems en Owego, Nueva York, que más tarde fue comprado por Loral, que más tarde fue también comprado por Lockheed Martin (parece que no puedo escapar de ellos). Trabajé para 5 empresas diferentes y sólo tuve 2 despachos. Estaba tan confundido de para quien trabajaba que al final empecé a contestar al teléfono diciendo únicamente “La Compañía”
Volviendo a tu pregunta, la razón por la que sigo aquí es porque me casé, compr’una casa y tuvimos unos hijos. Red Hat me permitió trabajar de manera remota y no he encontrado una razón para irme de aquí. Los terrenos y las casas aquí son realmente muy baratas y no encontraría nada comparable que pudiera pagar si me mudara a la zona de California a Boston.
¿Cual es tu herramienta favorita para el desarrollo de software?¿Y que tienes instalado en tu PC?
Trabajo con dos monitores y dos teclados en mi equipo de escritorio, que estan conectados a dos sistemas diferentes. Mi PC de trabajo tiene instalado Fedora 13 (no he necesitado actualizarlo) y mi otro PC (personal) tiene Debiang testing. Para Fedora utilizo Gnome 2, y en Debian utilizo Xfce 4. No estoy dentro de los paradigmas del usuario clásico.
Mi herramienta favorita de desarrollo podría ser Emacs, mi sistema operativo por encima de los otros. Eso y por supuesto mi propio script ktest.pl. Mi trabajo lo desarrollo básicamente:
- Actualizar código con emacs y guardarlo
- en la línea de comando escribo ./ktest.pl <box> .conf
Y mientras espero a que ktest realice su trabajo leo lwn.net o heise.de, o instalo y arranco el kernel con mis modificaciones actuales. También puedo ejecutar pruebas, pero principalmente lo tengo para arrancar el kernel donde por medio de ssh arranco y pruebo cómo funcionan las cosas. Ya hace mucho que no escribo el típico “make” o “make install”.
Antes de subir el código a la rama principal, siempre hago varias pruebas usando ktest, para asegurame de que mis parches funcionan y no causan ninguna regresión conocida.
Así como las herramientas mencionadas como son: git, perf, trace-cmd y kernelshark. Son herramientas que también utilizo de manera habitual.
¿Cómo te involucraste en el desarrollo del kernel de Linux?
Mientras trabajé en las compañías que he mencionado antes, trabajaba principalmente con Sun (Solaris) y AIX, un sistema Unix. Trabajando principalmente en un entorno militar sentía que mi carrera se estaba encasillando. Parecía que todo lo divertido y excitante estaba sucediendo entorno a los ordenadores, y ese sistema operativo nuevo de Microsoft. En 1996, por fin fui capaz de seguir mi camino en un proyecto basado en Windows NT. Fue utilizando C++ usando Windows Visual C++.
Fue un desastre. Honestamente me sentí como si tuviera que programar con una mano atada a la espalda. Después de pasar varios días fiabilizando una variable corrupta, encontré que el problema no sucedía donde creía, si no que el depurador de Visual C++ decidió decirme que la variable cambió cuando en realidad no lo hizo. Añadiendo dos printf estratégicamente, solucione este caso. Harto de tanta frustración exclame bien alto: “Por que no pueden inventar un sistema Unix para el PC!!”. Un compañero que estaba sentado cerca de mí se giró y me preguntó si había oido hablar de Linux?.
Hice lo típico, descargar los 13 disquetes que contenían la imagen de Slackware, y mi viaje comenzó. Pensé que era increíble que pudieras ver el código fuente y el kernel. Había un error en el kernel para uno de mis dispositivos, y despues de ua búsqueda rápida en internet encontré el parche que lo solucionaba. Bien no era un parche, eran instrucciones para cambiar el kernel. Pensé que eso era fantástico: “Estoy cambiando el kernel en mi PC!” Pero no es así como me hice desarrollador del kernel.
En 1998 mientras estudiaba un Master en la Universidad de Binghamton, uno de los profesores daba una clase sobre redes. El proyecto principal era convertir Linux 2.0 TCP stack en un protocolo credit/NAK. Durante esta clase encontré mi llamada. Me enamoré del todo de la programación del kernel. Me obsesioné con ello. Por desgracia lo más que podía hacer en mi trabajo era utilizar VxWorks kernel, que no era tan divertido.
En 2001 una compañía que empezaba llamada TimeSys abrió una oficina cerca de donde vivía. Tuve que luchar duro para conseguir un trabajo allí. Mi experiencia laboral era más que nada como usuario, y mi trabajo con el kernel era sólo como afición. Gracias a mis amigos que ya trabajaban allí fueron capaces de convencer a los directores de que tenía experiencia con el desarrollo del kernel ya que lo hacía en mi tiempo libre.
¿Qué es lo que hace que sigas interesada en esto?
La comunidad. Somos como una gran familia disfuncional, y me gusta eso. Hay mucha rivalidad en la lista de correo, pero despues cuando te encuentras en una conferencia, puedes tomarte con ellos una cerveza y reirnos juntos. Tienes que ser un tipo de persona peculiar para vivir en este entorno, y eso no es fácil. El truco es no llevar las cosas al terreno personal. Tienes que sopesar que es lo mejor para ti y que es lo mejor para la comunidad. Estamos intentando conseguir lo mejor de eso, pero al mismo tiempo, estamos intentando ayudar a otros. A veces la gente se olvida de este detalle y se dañan sentimientos.
Programar es un arte, y me gusta todo el arte, es un reflejo de lo que eres. Cuando alguien te dice que tu código apesta, puedes sentirte como si te lo dijeran a ti personalmente. Pero recuerda, si tu arte mejora tu también mejorarás. Si puedes sacudirte todas esas críticas, y mejorar tu trabajo, también mejorarás tu.
Me he sentido a veces tan hundido que he estado a punto de dejarlo. He pensado seriamente abrir una tienda de Starbucks en la carretera y dedicarme a eso. Pero no lo he hecho, y siento que soy mejor persona debido a ello. Además, tener mi propio Starbucks suena interesante.
¿Qué es lo más gracioso o curioso que te ha sucedido durante el proceso de desarrollo colaborativo (discusión encarnizada, petición de un código ridículo, un logro increíble)?
Lo que más me ha sorprendido fue mi “#define if()” (ver include/linux/compiler.h) Estaba asombrado de cómo funcionaba. Estaba incluso tan asombrado que lo incluí en el kernel. Cuando no se configuraba, no producía ningún daño en el kernel, así que no era un riesgo.
Todavía lo utilizo para encontrar heurística en varios códigos. Alguien me sugirió una forma de modificarlo para que fuera actualmente más útil para otros sin riesgos de rendimiento cuando este era habilitado. Todavía hoy está en mi extensa lista de cosas por hacer.
¿Cual sería tu consejo para los desarrolladores que quieran implicarse?
Encuentra algo en lo que quieras trabajar y hazlo. Una cosa que he aprendido trabajando en los parches -rt es que no puedes añadir cosas en el kernel. Esas cosas son las que necesitan que sean añadidas. No vengas diciendo que eres el mejor en una nueva característica y que todo el mundo debería tirar pétalos de flores a tus pies. Necesitas convencer a los mantenedores actuales que lo que tienes les beneficiará. Si puedes conseguir eso, tendrás a gente que se interese por tu código.
Necesitas empezar a ayudar a otros y a la comunidad, y esto no significa arreglar espacios en blanco o errores tipográficos. Si puedes contribuir con un beneficio de rendimiento, o simplemente limpiar código para hacerlo más sencillo de mantener y entender, sin sacrificar el rendimiento, estarás haciendo a la comunidad un gran servicio.
¿Qué escuchas mientras programas?
Los ventiladores de mi PC. No escucho música. Además mientras espero a que ktest termine su tarea, suelo leer algún podcast en Alemán para recordarlo y practicarlo. Ultimamente también he hecho un curso rápido de español para estar preparado para mi viaje a Barcelona
¿En qué lista de correo o en qué canal IRC puede encontrarte la gente?¿En que conferencias?
Estoy en LKML, y linux-rt-users@vger.kernel.org. También me suelo pasar por el canal de OFTC #linux-rt (N.del T: “where we like to throw around large fish with thermo-deficiencies.” esta frase supongo que sea un tipo de frase hecha que no he sabido encontrar un parecido en español, si alguien tiene alguna idea…)
Normalmente suelo asistir a cinco conferencias al año. Me puedes encontrar en Linux Collaboration Summit y en Plumber. A veces también asisto a Embedded Linux, LinuxCon y Linux Users . También a OSADL’s Realtime Linux Workshop de la que he regresado hace poco y me gustó. Pero aquí de nuevo es la conferencia que más me gusta.
Enlaces de interés
Página personal en G+ | https://plus.google.com/116317370665849559569/posts
Página en GitHub | https://github.com/rostedt
—
Puedes ver las entrevistas que he traducido aqui: victorhckinthefreeworld.wordpress.com/30-entrevistas-a-desarrolladores-kernel-linux/
—————————————————-
