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.
Comentarios
Normal, viendo su carácter no hay mucha gente que le aguante. Y menos las generaciones que aprenden con las nuevas escuelas de "no atacar a la persona, no decir que algo está mal..."
#2 En realidad creo que tiene más que ver con la moda de los lenguajes de andar por casa. Ahora todo el mundo aprende a "programar" en Python o Java, a ver quién se atreve con el C
#3 el problema ya no es ese, son los putos fwks...cada dos por tres a aprender a hacer lo de siempre pero consumiendo más recursos y dividiendolo en más archivos.
#8 A ver cómo engordar el currículum si no...
#8 que es un fwk?
#3 Estas muy equivocado, ese no es el motivo, de poco te sirve saber cualquier lenguaje, sin el necesario background para realizar ese trabajo, aprender C o C++ lo hace cualquiera, aprender la arquitectura de un sistema operativo moderno como Linux, muy pocos y cada vez menos.
#3 Veo a varios diciendo que hay que programar en Python porque se gana más dinero con este lenguaje. Y yo veo una confusión, hoy ganan más dinero los analistas o científicos de datos que son expertos en estadística, matemáticas y conocen el área de negocios con sus datos. Sucede que estos profesionales usan Python. Pero lo valioso no es el Python sino el análisis de datos. Es como si yo fuese a usar el mismo peinado de Brad Pitt entonces voy a ganar dinero como ese actor, algo totalmente falso. Brad Pitt gana ese dinero porque se ha labrado su carrera con buenas actuaciones en buenas películas, NO por su peinado.
#20 Pues no sé que decirte. Vivo en Nueva York y aquí cualquier junior con un poco de conocimientos de algún framework de Python como Django o Flask se levanta tranquilamente 150K
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).
#23 Hombre podrias trabajar en wall street de Nueva York como flamante programador, o si te preparas como actor tambien te levantas una buena pasta con peliculas de exito sobre Wall Street, ya que la informatica y el cine son industrias muy poderosas, pero para cuanta gente da eso ? en el mundo hay miles de millones que sueñan con trabajos asi e irse alli
#27 Hombre obviamente para conseguir un curro de 500K en Wall Street como programador tienes que ser bueno no, buenísimo.
Estamos hablando de gente con dos y tres licenciaturas: Matemáticas, finanzas y programación.
Es decir: Un mínimo de 20 años invertidos en formarte.
#23 ¿seguro? Vivo en Silicon Valley y no veo esos sueldos (salvo que incluyas stock y benefits)
#28 No es raro. Tengo una conocida que es dueña de un fondo de inversión de los gordos. Es lo que paga. De todas formas date una vuelta por Indeed. Los sueldos de Python los he sacado de allí (aunque pocas veces lo ponen).
#3 soy programador de C y aunque entiendo lo que quieres decir, hay que precisar que la complejidad y la cirugía que se necesita en el kernel excede con mucho el lenguaje.
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
#21 Por curiosidad: ¿en que curras?
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
#26 trabajo en drivers. Hombre no solo hago C, también C++.
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.
#42 depende en qué sitio de España, pues conozco programadores de C para drivers cobrando bastante menos.
#43 Barcelona.
#21 #26 #43 #45 Embebido, software crítico, entornos industriales... En general en España se paga bastante poco, me da la sensación. Sobre todo teniendo en cuenta el nivel de especialización que requiere.
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.
#61 C es un lenguaje muy sencillo, diría que el más sencillo que se usa actualmente, quitando algunos lenguajes ensambladores sencillos de micro-controladores (hablo de actualmente, no micros de 8 bit).
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 💃
#66 C y C++ no son lo mismo. Odio que los mezcléis siendo usuario de OpenBSD. No tienen nada que ver.
#88 yo no he mezclado nada. En el dominio del que estamos hablando son los dos lenguajes mayoritarios, C, y C++. Ahora se está metiendo un poco Rust pero está lejos de ser mayoritario.
No sé por qué piensas que los he mezclado. Trabajo en los dos a diario desde hace décadas, los conozco bien.
#90 Si bueno, pero son cosas aparte; el ponerlos en el mismo grupo al hablar de C hará que cuando toques C++ tengas unos dolores de cabeza inmensos y al final por desconocimiento llegarás a odiar C, cuando el primero como digo es mucho más simple.
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.
#93 simplemente he dicho que el problema de C no es el C como tal, si no el dominio en el que se aplica, que generalmente es hardware o sistemas a muy bajo nivel. Y que eso es lo que la gente no sabe.
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í.
#93 Según tengo entendido, lo que comentas se hace en g++, tú le dices el estándar a usar con "-std=", y si le pones que te de todos los avisos con "-Wall", te dice cuando hay funciones anticuadas o cuando lo que usas no está en el estándar.
Si usas otros compiladores, éstos deberan decirte qué estándar usan y de mira en cppreference.com u otra web similar qué está al día y que no.
#61 Yo no pienso que C sea fácil. La gestión de memoria y los punteros, tal y como dices, son muy complicados.
Conozco más de uno que hizo la carrera y me confesó que acabó sin tener ni idea de punteros (ya los has comentado tú también).
Y tanto que 50K son sueldazo en España.
50K en España equivalen a unos 125K en Nueva York (aquí la vida es 2.5 veces más cara).
Si yo pudiera conseguir eso en España me largaba ya mismo.
Me das envidia: Siempre me ha encantado la electrónica y los sistemas industriales embebidos, sin embargo aquí estoy: Dirigiendo proyectos webs y mierdas en la nube (Dios, como odio la puta nube y el software SaaS).
Trabajando con sistemas embebidos en donde ves como tus ideas se plasman en algo físico, en algo tangible en la vida real. Algo que puedes tocar.
Ojalá me hubiera dado por ponerme a currar en eso, pero en España no había mucha salida.
Ahora con todo el tema del IOT y el Computing Edge parece que está empezando a haber más curro de programador en C.
#42 Por cierto: Se me olvidó preguntarte: ¿Trabajas en España? 50K es un sueldazo.
#21 Y rezar por no tener un ataque da daltonismo
#21 Trabajo en uno de esos proyectos, no al nivel del kernel de linux obviamente, pero que es de despliegue en produccion masiva. Al final hay un monton de revisiones, de controles, tests, pruebas... pero siempre queda esa sensacion de sudor frio de "Buff, como la lie aqui..."
#21 Vente a OpenBSD. Es C y el código es simple de cojones. No digo que toques la E/S del kernel, el scheduler o cosas así, pero hacen falta drivers. En muchos casos solo es añadir IDs PCIe/USB, pero en otros no.
#85 programo software libre en mi tiempo libre pero hago otro tipo de cosas y ando metido por Debian. A nivel profesional en mi empresa se mantiene casi todo Linux, de Windows un poquito también.
#92 Debian molaba; cuando no tenía internet en casa (caro al més o dependiente de 56k con GSM, inviable más de media hora), los DVDs de Sarge me dió bastante conocimiento desde los manuales hasta la Linux Gazzete.
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.
#21 ¿Y como ha llegado el kernel a ser tan complejo? ¿Tiene algo que ver con ser monolítico?
#3 typescript
#3 Mecachis, le has reventado el discurso político en dos frases. Veo que no se anima a volver a por más.
#3 yo creo que los cortazos y borderías que ha soltado el paisano a otros desarrolladores no deben ayudar mucho, hay gente buenísima que programa en C por ahí, no creo que la falta de programadores sea el problema
#48 yo conozco gente que contribuye al kernel, yo mismo podría contribuir si me tocase (hablo de que la empresa te manda contribuir).
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.
#50 ¿Las empresas mandan a sus equipos colaborar en el kernel de Linux? ¿Es para añadir alguna funcionalidad que necesitan o algo así? Tiene sentido pero nunca lo había escuchado.
#74 sí, normalmente lo que ocurre es que la empresa necesita añadir una funcionalidad o corregir un problema para un cliente, pero como eso hace que tengas que mantener tu fork, intentas subir todos los parches posibles a la comunidad para que te vengan en próximas versiones mainstream.
Se hace con el kernel y se hace con cualquier otra cosa.
#91 Gracias por la aclaración!
#3 Prefiero C a C++ cuarenta mil veces lol
#3 Aquí uno que se forjó liberando punteros desde los tiempos del MS-DOS. Sólo pensar que tuviera que manejar de nuevo a mano la asignación dinámica de memoria hace que se me ponga el vello de punta.
#2 La genialidad y las excentricidades suelen ir de la mano.
Será interesante ver lo que ocurre el día que Linus Torvalds deje de estar al mando.
#4 Se morirá y el proyecto y terminará en manos de alguna corporación sin escrúpulos. El señor Linus es el Alejandro Magno de la informática. (Tal vez haya elegido una mala comparación).
#7 Lo realmente sorprendente es que con la de grandes empresas que utilizan el kernel de Linux, que dependen de él, se siga manteniendo la unidad, se sigan aceptando las decisiones que tome ese señor desde su cueva.
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.
#10 Es una opción, pero se podría ver como una versión de la muerte del proyecto. En cualquier caso Linux tal como lo conocemos cambiará para siempre.
#11 Cambió mucho desde la 2.2, 2.4 y 2.6.
#10 Los proyectos más exitosos de software libre se consideran "dictaduras benevolentes". Hay un montón de gente contribuyendo al código, pero las decisiones las toma el autor original o un pequeño núcleo a su alrededor. Esto hace que el desarrollo sea muy rápoido y ágil, pero produce otra clase de problemas de cohesión.
#10 Linus tiene el copyright de la marca, si lo echan podran seguir con el proyecto sin él, pero no podrá llamarse Linux.
#29 Lo cual dará para infinitas discusiones y correcciones en foros, donde los ultrapuristas se empeñaran en informar a los neófitos de que el nuevo sistema operativo no se llama Linux, ni GNU-Linux, sino otracosa-GNU o GNU-otracosa.
#51 En este caso GNU no tiene nada que ver, sería que el kernel no puede llevar el nombre de Linux sin permiso del que tiene el registro de la marca.
#56 Es la hora de Hurd
#29 #51 Existe Linux-Libre.
#86 Pero no es un fork, es Linux sin partes propietarias.
#10 en tu último párrafo te respondes a ti mismo le siguen reconociendo esa autoridad única y unilateral porque todos los grandes actores del escencario saben que si se la quitan, el kernel se convertiría en una amalgama de docenas de kernels que en pocos años serían incompatibles entre sí. Y hay empresas muy gordas que prefieren que eso no pase.
#41 Como los déspotas preocupados por su legado, nombrará un delfín. Luego lo que pase tendremos que verlo.
#10 Mira quién paga la Linux Foundation. Es imposible que las decisiones de desarrollo estén desconectadas de esos intereses.
#94 No, no lo es.
#7 IBM - Red Hat...
#7 hurd
#4 Las excentricidades son tales porque se consienten. Generalmente, porque desde el primer momento no se le ponen coto.
#2 Qué tontería de comentario. Como si uno fuera a coincidir con Linus al contribuir....
https://lwn.net/Articles/780271
#2 x'D
-> Linus Torvalds dice que no entiende completamente el Kernel de Linux (Entrevista)
Linus Torvalds dice que no entiende completamente ...
maslinux.es-> Linus Torvalds: «Nunca dejaré de insultar a los desarrolladores»
Linus Torvalds: «Nunca dejaré de insultar a los de...
ubunlog.com#2 De hecho, realmente es al revés. Hace falta más gente con caracter, los mantenedores del kernel son los que filtran casi todas las chapucillas antes de que le lleguen a Linus. El problema es que si le llegan (por presiones de alguna empresa, por reinicidencia supina, porque el programador de turno está armando una pataleta por el típico "son unos tiranos y no aceptan que las cosas se hagan de otro modo, no me comprenden, el sistema está corrupto, etc", éste tiene que poner los puntos sobre las ies para que no se le suban a las barbas. Si un tipo no tiene conocimientos y experiencia no puede llegar a mantenedor del kernel, pero es que si además no tiene caracter se funde en dos días.
#75 No se si es subirse a las barbas o no, ni soy de la nueva generación, pero si un tipo con el que trabajo me dice "tu código es una puta mierda" en lugar de "es mejor si lo haces de esta forma porque aquí hay X problema", le doy con la puerta en las narices y no vuelve a ver un pull request mi en la vida. La vida es demasiado corta como para aguantar a gente así, por muy genios que sean. Y estoy seguro que hasta muchos que potencialmente podrían llegar a mantenedores del kernel harán lo mismo. ¿por qué vas a aguantar a un personaje tan tóxico cuando puedes trabajar en cualquier parte sin ser insultado?
#76 Es que esos comentarios generalmente están fuera de contexto. Normalmente para que Linus llegue a ese punto tiene que ser por algún programador concreto que se crea el rey del mambo, que ignore continuadamente ciertas cosas y piense que lleve razón porque si. Y no suele ser un "esto es una mierda" o "eres un mierda" y ya está, suele ser un "este código no hay por donde cogerlo porque no sigue las reglas estándares que usamos, no ha pasado una revisión completa, me da fallos al compilar (lo más básico es enviar un código que al menos compile, leñe)... no pretendas que me parezca un código profesional y de calidad como el que exigimos" (o sea, no se queda en el insulto, indica por qué piensa de esa manera y qué actitudes le llevan a recharzarlo). Linus usa látigo pero de manera constructiva (otra cosa es que los egos heridos sólo se fijen en la parte del látigo; por otro lado, cuando usas un lenguaje coloquialmente, puedes soltar un hijoputa a tu mejor amigo en plan broma y no pasa nada, linus suele usar un lenguaje fuerte, pero lo hace con todos, más que insultos es eso, lenguaje fuerte). Pero claro, los que no están metidos en las listas lo que ven es lo que se vende en internet de manera amarillista. Igualmente, su comportamiento ha cambiado bastante, su forma de hablar es más correcta (sin dejar de ser punzante cuando quiere).
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?
#2 Yo prefiero trabajar con alguien que cuando habla se le entiende todo lo que dice antes que con alguien que tienes que mantener vigilado por si acaso.
Yo añado: cada vez será más difícil conseguir mantenedores para cualquier proyecto de software porque a pesar de que hay una gran comunidad de "consumidores" de ese software, los que en realidad se sumergen en las cientos de miles de líneas de código que tiene un proyecto mediano (o millones si es un proyecto grande) son muy pocos. Y hay razones por ello:
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.
#5 En OpenBSD no falta gente.
#12 Todavia hay alguien que usa OpenBSD? Qué será lo siguiente, EyeOS?
#38 Mucha más gente de la que crees, al menos como SO secundario/terciario tras Linux. El tener un entorno predecible, ultradocumentado y que las actulizaciones no se vayan ATPC (solo Slackware consigue algo más o menos confiable), hace bastante. Con Ubuntu o Debian sabes que tarde o temprano tendrás problemas al actualizar.
En OpenBSD cada actualización y cambio de sintaxis entre el software base anterior y el nuevo te lo documentan con avisos.
#84 respecto a lo que comentas en #83
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.
#12 y ahí está.
Siendo la muleta Unix de cualquier corporación que la quiera (hola Sony!)
#55 Ese es FreeBSD. Es diferente. Otra rama, diferentes binarios y librerias, no son compatibles. Los kernels son distintos, el userland tambien, y bastantes otras tecnologías.
OpenBSD no tiene ZFS, FreeBSD no tiene Pledge o Unveil...
#5 Cualquier proyecto con más de una década termina por convertirse en un pastiche de varios lenguajes, ñapas para comunicar unos módulos con otros, y ñapas aún mayores para que los sistemas operativos o navegadores los sigan soportando. Y si no acaban como lo que vi hace un par de años, que estuve en una pyme donde todavía trabajaban con un programa en MS-DOS que ejecutaban en Windows 98 y que imprimía la factura en papel contínuo, poniendo el importe en euros y pesetas.
El problema es que los programadores de antes tenían más experiencia con la programación de bajo nivel. Los ordenadores de los 70, y 80 eran más simples. Había más porcentaje de programadores que sabía cómo funcionaba un ordenador por dentro, que conocía el ensamblador de alguna arquitectura. Esa es la gente que en los 80 y en los 90 aprendió C y montó las bases de lo que hoy conocemos. También había menos programadores y la calidad era, por lo general, muy superior a la de hoy. Ahora tenemos muchos más programadores, pero la mayoría tienen un conocimiento superficial de cómo funcionan las cosas por debajo. Están cegados por el alto nivel y las muchas capas de abstracción que hay hasta el hardware. Ya no se valora tanto la eficiencia, el bajo consumo de memoria, estructurar de forma inteligente las cosas, etc. A medida que pasan los años, las nuevas generaciones de programadores tienen un conocimiento más mediocre, hasta el punto que sería difícil calificar a algunos programadores de "verdaderos programadores".
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%.
#32 Bueno eso de programador de pacotilla lo dirás tú.
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.
#32 «Un programador que no sepa C, es un programador de pacotilla.»
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
#44 Toda persona llamada "Ian" es un subconjunto de una persona llamada "Brian".
#32 >stán cegados por el alto nivel y las muchas capas de abstracción que hay hasta el hardware.
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.
#67 Si amplias operaciones y eliminas otras, lo que estas haciendo de facto es una nueva revisión del estándar, revisión con la que habrá elementos anteriores no compatibles. Elementos nuevos que sólo necesitarán algunos, por lo que otros no verán necesario meterlos en el estándar.
#79 Nadie ha hablado de eliminar.
#80 No eliminar funciones antiguas, así como tener que implementar algunas que están en el estándar pero no son óptimas en tu arquitectura, es una forma de lograr una API estable pero un funcionamiento lento. Por mucho que se intente estandarizar, habrá componentes donde determinadas operaciones sean mucho más rápidas, y ese componente querrá guiar a cualquiera que la use para que use dichas operaciones. Al final, a tan bajo nivel, siempre hay que decidir cuanta eficiencia quieres sacrificar a cambio de seguir el estándar.
Seguro que la culpa es de systemd
Tíos..pensemos un poquito. Dice que la mayoría de programadores del kernel rondan los 50. ¿Y donde está el problema, joder? Les quedan entre 15 y 20 años de vida laboral. Dentro de 20 años, algún niñato que hoy sale de la universidad tendrá los conocimientos y los huevos pelados para continuar.
#22 Correcto yo creo que si a uno le gusta y le dejan, puede seguir programando hasta que se muera.
#57 tiene razón, el problema es que la solución es utópica, incluso podría ser contraproducente para el progreso.
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.
#58 ni podrías haber diseñado en 1980 un estándar de almacenamiento que cubriese las necesidades de 2020.
Si es un estándar ampliable, ¿por qué no? Seguimos con un juego de instrucciones de hace 40 años, solamente se ha ampliado.
#62 un estándar ampliable es algo que mete características nuevas y a la vez mantiene la compatibilidad con lo anterior.
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.
#64 Se amplía la especificación y se inhabilitan operaciones no compatibles. Todo perfectamente definido en el estándar.
Los niñatos de la generación actual son expertos sobretodo en debatir.
Si "lo dejan morir", ya habrá alguien que cree una derivación, solo con la base que usa android tiene asegurado el apoyo de google, que es mucho apoyo.
#19 Eso probablemente no siga siendo así en el futuro próximo, Google lleva trabajando 4 años en Fuchsia, que es un SO llamado a sustituir a Android en un futuro. Aunque los planes de Google con Fuchsia no están del todo claros, todo parece que van a ir por ahí los tiros.
#33
>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.
Casi todo el código lo agregan empresas privadas, de echo Microsoft fue de los que más aportó hace años para temas de Azure.
Yo creo que aquí lo jodió es coordinar
#18 es lo que dice el artículo, sí...
El futuro es Hurd
#63 https://xkcd.com/1508/
Los pagan?, porque yo quiero trabajar de eso y no encuentro trabajo para ello.
#36 sí, los pagan, pero no encontrarás una oferta para eso en Infojobs.
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).
#36 Otro que necesita dinero para vivir... ¡desagradecido!
#36 Según tengo entendido, la Linux Foundation contrata a aquellas personas que suelen aportar cosas gordas. No sé si habrá forma de que te contraten directamente sin haber sido voluntario.
El otro día escuchaba a Casey Muratori cagándose en lo ridículo que es tener kernels de millones de líneas cuando la complejidad no ha crecido tan exponencialmente. Decía que el hardware ha mejorado exponencialmente y sin embargo el software ha mejorado de manera lineal.
#53 eliminar lineas es muy bien venido en cualquier proyecto, el código que no existe es el mejor de todos
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.
#54 Precisamente decía que una de las razones de que el software se haya hecho tan complejo es la ausencia de un estándar a la hora de comunicarse con los periféricos. Es bastante interesante, voy a ver si lo encuentro.
Encontrado:
#54 Compara el algoritmo de ordenamiento de burbuja (poquísimas líneas de código) y el algoritmo de ordenamiento por QuickSort (muchas más líneas de código incluyendo programación recursiva). ¿Cuál es más rápido? QuickSort y es el que se usa, nadie en su sano juicio usa burbuja. Las líneas de código no es una métrica válida.
#53 el kernel se está reescribiendo constantemente, pero la mayoría de las líneas de código que llegan es soporte del nuevo hardware.
#53 En general, lo que más sube el número de líneas en cada nueva versión del núcleo suelen ser nuevos drivers, o soporte de nuevas arquitecturas. Poco puedes hacer para reducir eso.
Kernel univerty... Para cuando?
Es lo bueno de la comunidad y el software libre, que cualquiera puede ver y tocar el código
#34 tocarlo todo lo que quieras! mucha suerte cuando recién tu pull request como no sea minúscula y trivial o no estés muy metido en el proyecto.
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
Ya se apropiará alguien con intereses de hacerse cargo.
#1 Es cuestión de capacidad no de intereses.
Si no hay capacidad el interés es irrelevante.
#1 Hay como 70 mantenedores, simplemente hay mucho que hacer.