Linus Torvalds, creador y responsable del desarrollo del kernel de Linux, ha aprovechado la Open Source Summit (que este año se lleva a cabo de manera íntegramente online) para lanzar una advertencia sobre el futuro del proyecto. Todo surgió cuando su entrevistador (Dirk Hohndel, director de Open Source de VMWare) le planteó la incómoda pregunta sobre qué ocurrirá cuando la actual generación de mantenedores del kernel se vea obligada a dejarlo, teniendo en cuenta que la edad muchos de sus líderes se mueve entre los 50 y los 60 años.
|
etiquetas: linux , kernel , mantenedores 
C es un lenguaje muy sencillo, pero el kernel es un problema muy complejo.
Y lo peor es que está en producción masiva, como la cagues ahí la lías parda.
Cambiar una línea de C del kernel es...cortar el cable azul
Será interesante ver lo que ocurre el día que Linus Torvalds deje de estar al mando.
1. Si es un software con muchos años a cuestas, estará usando lenguajes y tecnologías antiguas que puede que espante a las nuevas generaciones de desarrolladores.
2. Es más emocionante empezar de cero un proyecto que darle mantenimiento a uno ya existente.
3. El lastre de mantener la compatibilidad hacia atrás.
4. Tu nombre queda sepultado en los miles de créditos de otros desarrolladores. Es el refrán "es mejor ser cabeza de ratón que cola de león", y en un proyecto existente con grandes veteranos que han tenido fama, uno se siente como la cola del león. En cambio, un proyecto de cero, individual, si llega a tener éxito, el nombre de uno estará en los titulares.
lwn.net/Articles/780271
Si no hay capacidad el interés es irrelevante.
Otra historia sería que fuera un liderazgo que se pasase la mayoría del tiempo de reunión en reunión con grandes empresas para recoger sus ideas y recomendaciones y las fueran implementando, pero sospecho que no es el caso.
Lo dicho, me sorprende que a nivel mundial se le siga reconociendo esa autoridad única y unilateral.
Por ello yo apuesto por que si alguna vez deja el mando, la inmortalidad no la descarto, se convierta en una maraña de mantenedores independientes cada cual con su versión ajustada a sus intereses, ya sean corporativos, defensores del espíritu de Linus, etc.
Yo creo que aquí lo jodió es coordinar
C es un lenguaje muy sencillo, pero el kernel es un problema muy complejo.
Y lo peor es que está en producción masiva, como la cagues ahí la lías parda.
Cambiar una línea de C del kernel es...cortar el cable azul
Un buen científico de datos gana unos 300K y un programador mega experto en algoritmos de C++ para wall street se puede levantar 500K. El tema es que aprender Django + Python lleva tres meses y lo otro media vida.
Ponte a echar cuentas: Yo prefiero invertir tres meses en aprender algo que me de 150.000 ya mismo que veinte años en algo que me puede dar 500.000 (sobre todo cuanto tienes ya una edad o pocos recursos para pagarte los estudios).
-> www.meneame.net/story/linus-torvalds-dice-no-entiende-completamente-ke
-> www.meneame.net/story/linus-torvalds-nunca-dejare-insultar-desarrollad
C es un lenguaje que me encanta, pero las ofertas que siempre veo son para hacer drivers o currar en sistemas embebidos. Aquí en Nueva York no se suele pagar mucho por eso (comparado con otras cosas como desarrollo web o el diseño de apps).
Es raro pasar de los 65K siendo programador de C
Un programador que no sepa C, es un programador de pacotilla.
Cuando hay que hacer cosas serias, como por ejemplo un kernel, el driver de una GPU, una base de datos, un emulador, un recompilador dinámico (JIT), el intérprete de un lenguaje script, un engine de juegos 3D, etc, se usa C o C++.
Ahora bien, cuando hay que hacer una web, o una app para Android, o un juego con Unity, evidentemente no vas a usar C o C++.
Y es que entre los programadores también hay "clases", como en la vida real, pero no clases basadas en el dinero, sino en el conocimiento. Hay muchos programadores pobres en conocimiento de medio y bajo nivel, y algunos programadores ricos.
¿Cuántos programadores de hoy en día serían capaces de hacer un videojuego de NES o de Game Boy en ensamblador del MOS 6502 y del Sharp LR35902 respectivamente, o ya puestos en C? ¿Cuántos serían capaces de escribir un compilador de C? Creo que no llegaría ni al 5%.
trabajé en una empresa de soft libre y la comunidad (grande) acababa desistiendo de mandar código. demasiado esfuerzo "alinearse" a la estructura y el estilo, demasiadas pullrequests rechazadas (con razón).
no es tan fácil
Un buen programador lo es en cualquier lenguaje, discriminar porque usa tal o cual en lugar de C es totalmente absurdo. No todo el mundo se puede dedicar al bajo nivel, no hay trabajo para todos en eso. Precisamente lo que ha permitido a la informática actual llegar a donde está es el uso de nuevas tecnologías. A ver quien dedica 1 año a hacer una app en C que puedes hacer en 2 meses con Kotlin a ver quién está dispuesto a pagar el sobrecoste.
Gano 50K más algunos complementos como gimnasio y seguro médico privado.
Eso en España es un sueldo normal tirando a bueno, juraría que aquí es al revés y un programador web no llega a 50K ni en broma.
Si eres español sabrás también que no se pueden comprar directamente sueldos con América por el tema seguros.
Yo se C, de hecho aprendí a programar con C (lo que hacía con BASIC no lo considero programar) y mis primeros pasos en el mundo laboral fueron con C++. Aun así a menudo me considero un programador de pacotilla...
Supongo que tu sentencia es un silogismo de un solo sentido
MIra qué grandes empresas hacen aportaciones periódicas, ya que cuanto más grande y más aportaciones, más posibilidades de que necesiten contratar a más gente. Con esa lista, contacta con ellas ofreciéndote para ese trabajo.
Probablemente necesites tener antes alguna credencial que demuestre que sabes de lo que se trata, aparte de tu posible experiencia laboral fuera del kernel. Quizá debas empezar por hacer aportes a otros proyectos libres, e incluso algún aporte por mínimo que sea al kernel. Supongo que una autocandidatura a esas empresas para esa posición será más tenida en cuenta si ven que tú ya has tenido pull requests aprobados en proyectos libres (demuestra que sabes moverte en el entorno).
Lo que es, es un puto coñazo, por lo que he dicho antes: al estar en producción masiva cambiar unas pocas líneas es un drama, a mí ese tipo de programación tan quirúrgica no me gusta.
No haría eso nunca como hobby, es un aburrimiento total.
No creo que al kernel le sobren tantas, seguro que un buen porcentaje, pero no la mitad por ejemplo. Cubre una casuística muy amplia, porque una cosa que tiene el hardware, además de haber mejorado exponencial, es haberse diversificado exponencialmente.
Si solo hubiese un modelo concreto de PC cerrado y bien definido el kernel sería mucho, pero que mucho más pequeño.
Siendo la muleta Unix de cualquier corporación que la quiera (hola Sony!)
Encontrado: www.youtube.com/watch?v=kZRE7HIO3vk
Para que el hardware avance, necesita incluir características que no existían. Y al hacerlo, crea nuevas complejidades y requiere de soporte del kernel. A la vez, necesitas mantener la compatibilidad con el hardware anterior durante muchos muchos años.
Por ejemplo recientemente se ha quitado del kernel el soporte a disqueteras, ahora está como módulo aparte. Pero la solución no podría haber sido seguir usando disqueteras, ni podrías haber diseñado en 1980 un estándar de almacenamiento que cubriese las necesidades de 2020.
Podemos pensar que C es fácil, pero es el típico pensamiento de los que somos programadores de C. Yo vi a gente dejar la carrera por no entender punteros. Hoy directamente se enseña C de forma tangencial en las asignaturas que no hay más remedio (como sistemas operativos) y los chavales suelen entender la mitad de lo que leen.
Además, nos cuesta muchísimo encontrar ingenieros jóvenes para contratar. Al final hacemos lo que hacen todos: contratar a becarios de industriales. Que son la leche y muy bien formados en lo suyo y saben C, pero no son programadores, claro (tampoco es que quieran, lo cual les frustra muchas veces).
La impresión que me da es que lo sueldos en este sector(que creo que es donde más se usa C) depende básicamente del estado del sector industrial del país. Hasta donde sé en Alemania se paga una pasta (que me corrijan si me equivoco, que en Menéame hay mucho expatriado). En españa, alguna grande como Airbus o Siemens y poco más. El resto un buen sueldo medio, buen sueldo para juniors (comparativamente con otros sectores) pero el sueldo de seniors se estanca rapidísimo. Incluso si das el salto a gestión. A no ser que subas muchos escalones, pasar de 60k es muuuy dificil.
Bueno, esto son un poco problemas del primer mundo eh, que cobrar 50k en España es un sueldo que te permite vivir sin problemas, vamos. Pero sí es verdad que estamos hablando de gente de altisima cualificación, lo cual da un poco de rabia que sea el techo de este país.
Si es un estándar ampliable, ¿por qué no? Seguimos con un juego de instrucciones de hace 40 años, solamente se ha ampliado.
Normalmente la ampliación consiste en reservar algunas partes que se prevén que puedan necesitarte en un futuro, por ejemplo te describo un controlador de disquetera en principio para diskettes de 40 pistas, pero el registro donde metes el número de pista para que se sitúe el cabezal, se prevé que pueda ser de 80 o 160 pistas en un futuro.
Pero es imposible cubrir con esa especificación un lápiz USB cuando ni se ha inventado el USB todavía, ni la electrónica de un lápiz USB tiene absolutamente nada que ver con una disquetera en ningún aspecto, aprovecharías 0 lineas de código.
Date cuenta que en el kernel se trabaja a ese nivel, a nivel de electrónica.
El problema es que los problemas que se solucionan con C no son triviales, es código cercano al hardware que puede consistir en varios miles o cientos de miles de lineas de código generalmente legacy mantenido durante años o décadas. Y ese es el problema, que puede ser asumible por los que somos legacy también por edad, pero dificilmente un programador recién salido de la universidad puede enterarse de un carajo en eso.
Pueden saber C, porque C es sencillo y se aprende en la universidad. Pero no saben todo el dominio donde C se aplica, que es lo complejo, no el lenguaje en si.
Aunque puede ser peor: puede ser ese mismo dominio pero con C++17. Ahí es cuando sacamos el icono de la bailarina
Por otro lado, si quieres aportar código, tienes que saber en qué condiciones se va a producir ese aporte, no puedes ir soltando código por ahí sin cumplir una serie de cosas (cada proyecto como mínimo tiene unas reglas de estilo y una forma de usar las APIs, se siguen una serie de buenas prácticas y demás que han llegado con la experiencia, etc...). Tampoco puedes ir enmendando la plana a mantenedores que llevan décadas ahí y decir públicamente que su trabajo es una mierda, por ejemplo. Tú no puedes entrar en la casa del vecino y hacer lo que te de la gana, por muy normal que sean ciertas cosas en la tuya; tú entras y pides permiso y sigues sus reglas. Y ya te digo yo que si sigues las reglas de Linus nunca te va a echar un rapapolvo (salvo que la cagues grandemente o haya un motivo muy justificado). Si lo siguieras más, verás como aconseja y orienta a gente que llega de nuevas, incluso con cosas muy tontas y cómo es con gente que ya lleva tiempo y sigue cometiendo errores básicos o que ya le han corregido muchas veces o que se pasa de lista con quien "la arma").
Por otro lado, una sóla pregunta y sin mucha malicia... ¿has trabajado alguna vez de cara al público?
En OpenBSD cada actualización y cambio de sintaxis entre el software base anterior y el nuevo te lo documentan con avisos.
OpenBSD no tiene ZFS, FreeBSD no tiene Pledge o Unveil...
Te ciega la nostalgia. Te recuerdo cosas en intel como el modo real, la segmentación de la memoria, las IRQ's que eran una puta chapuza comparados con el HW en otros sistemas, etc...
Sobre el que no sepa C... hay te has colado. Hay programadores que no han tocado C en siglos pero saben de Common Lisp o Scheme y te dan 20000 mil vueltas en algoritmos.
No sé por qué piensas que los he mezclado. Trabajo en los dos a diario desde hace décadas, los conozco bien.
Se hace con el kernel y se hace con cualquier otra cosa.
C++ tiene demasiada redundancia en funciones y encima hay subestándares cada poco. Deberían anunciar una especie de estandar LTS y dejar lo anterior como "legacy" avisando del uso de funciones anticuadas o cuando no que hagan como con C, que las funciones de ANSI C se especifican con -ansi en los compiladores para "bajar" a ese estandar en vez de C99.
Y que eso se puede agravar aun más, si encima ese dominio se soluciona con C++, que también es habitual, porque entonces la gente que sale de la universidad no sabe ni el dominio ni el lenguaje.
Nada más, no hay ninguna confusión. Al menos para mí.
Antaño me sirvió hasta para montar un proxy-cache y ahorrar datos a lo bestia.
Ahora, bueno, estoy bastante desligado de Linux excepto Slackware. SystemD me parece un mastodonte inmanejable, es un intento de volver NT un Linux. Y si me dicen Solaris, lo siento: ZFS, las zonas, etc... estaban 2000 veces mejor integradas.
OpenSUSE Tumbleweed es de las distros más estables y menos dolorosas de mantener actualizada que he podido probar.
Para montar servidores/VMs es simplemente cojonuda.
>Los planes no son claros
Quieren un Google-MacOS.
Un núcleo Unix """""libre""""" con todo su software bien cerradito de código corriendo en y sobre el núcleo """""libre""""""
Fuchsia quiere ser a Google lo que Darwin es a Apple.