"Cada vez es más difícil encontrar mantenedores para el kernel de Linux", advierte su creador

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.

[#3 pkreuzt]

#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

[#21 pip]

#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

[#20 CrudaVerdad]

#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.

[#15 pkreuzt]

#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.

[#17 --546793--]

#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.

[#2 --330392--]

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..."

[#28 miau]

#23 ¿seguro? Vivo en Silicon Valley y no veo esos sueldos (salvo que incluyas stock y benefits)

[#5 CrudaVerdad]

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.

[#32 --654205--]

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%.

[#10 sorrillo]

#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.

[#6 Waves]

#2 Qué tontería de comentario. Como si uno fuera a coincidir con Linus al contribuir....

lwn.net/Articles/780271

[#23 --654482--]

#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).

[#12 --625430--]

#5 En OpenBSD no falta gente.

[#42 pip]

#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.

[#4 sorrillo]

#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.

[#79 --330392--]

#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.

[#76 --330392--]

#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?

[#77 --330392--]

#56 Es la hora de Hurd

[#82 --330392--]

#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.

[#9 --6883--]

#1 Es cuestión de capacidad no de intereses.
Si no hay capacidad el interés es irrelevante.

[#50 pip]

#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.

[#61 lesbiano]

#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.

[#14 --589369--]

Seguro que la culpa es de systemd

[#47 --654205--]

#44 Toda persona llamada "Ian" es un subconjunto de una persona llamada "Brian".

[#95 pip]

#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í.

[#66 pip]

#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

[#22 cosmonauta]

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.

[#58 pip]

#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.

[#41 txeke]

#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.

[#51 --584621--]

#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.

[#7 Tronchador]

#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).

[#13 --625430--]

#11 Cambió mucho desde la 2.2, 2.4 y 2.6.

[#44 txeke]

#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

[#46 txeke]

#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).

[#78 meneandro]

#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?

[#84 --625430--]

#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...

[#106 Boleteria]

#8 que es un fwk?

[#110 PerroVerd]

#107 no, tiene que ver con que las soluciones que se usaban llegan a su limite y hay que buscar nuevas. Por ejemplo, antes se usaban hashes para guardar las paginas de memoria y tener un acceso rápido, un hash es una herramienta básica que conoce cualquier programador. Esta solución funcionaba bien hasta que la memoria de los ordenadores comenzó a crecer y se descubrió que para era más efectivo guardar las páginas de memoria en un radix tree, una herramienta que no es conocida por todos los programadores.
Newton funcionaba a pequeña escala pero Einstein es más completo y complejo

[#111 pip]

#107 cada vez hay más hardware que soportar, y cada vez el hardware es más complejo. El kernel cubre muchas casuisticas, funciona tanto en dispositivos embedded muy pequeños a super-ordenadores. Es una variedad muy muy grande de configuraciones las que tiene que cubrir.
Y además, se usa en millones de sitios. Hay que tener mucho cuidado en no romperle nada a nadie.

Eso es lo que lo hace tan complejo. Lo de ser monolítico tiene ventajas técnicas y problemas técnicos, pero a nivel de desarrollo el kernel no es monolítico, está divido en varios cientos de módulos bien definidos y bien aislados, lo que pasa que todos esos cientos de módulos se compilan todos juntos en el mismo binario (menos algunos otros que pueden ser módulos separados o ir dentro), por eso se dice que es monolítico.

[#16 menjaprunes]

#7 IBM - Red Hat...

[#60 --627591--]

Los niñatos de la generación actual son expertos sobretodo en debatir.

[#72 Gavela]

#18 es lo que dice el artículo, sí...

[#114 gambader]

#63 xkcd.com/1508/

[#26 --654482--]

#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

[#64 pip]

#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.

[#91 pip]

#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.

[#119 pip]

#113 sí, Barcelona. Los sueldos para este tipo de programación están por ahí, entre los 40K y los 50K. Aquí en España un programador de Python web cobra menos que yo sepa, o por lo menos en mi empresa cobra menos.

Ahora, cada vez más empresas internacionales aceptan trabajar en remoto y pagan más. Tendrán que ponerse las pilas en España o se quedarán sin gente, ya cuesta mucho encontrar personal y se va a agravar.

[#121 pip]

#120 la verdad es que no conozco a nadie que trabaje en temas IOT ni tengo ninguna referencia. No tengo conocimiento ni opinión sobre esto.

[#88 --625430--]

#66 C y C++ no son lo mismo. Odio que los mezcléis siendo usuario de OpenBSD. No tienen nada que ver.

[#109 walk_kindly_shout]

#106 creo que quiso decir frameworks.

[#127 zakrion]

#123 Eres bueno en C++ ? Estas empresas, para puestos de desarrollo buscan ingenieros de software "de verdad". De los que entienden bien la maquina en la que se ejecuta su codigo (diferencias entre arquitecturas Intel por ejemplo, como impactan a tu código), el compilador, buen manejo de protocolos de red (TCP, IP , UDP y ARP) y de multicast, capacidad para generar código optimizado para baja latencia (hablamos de que en algunas empresas el foco se pone en los nanosegundos), y que vayan sobrados en programación multihilo. Si ya ademas has trabajado con FPGA ya mejor que mejor, pero esto no es obligatorio.

Si crees que encajas en el perfil, mándame un privado y te puedo dar nombres de empresas donde pagan esos números para que les mandes tu CV y a ver si hay suerte.

[#129 zakrion]

#128 Bueno sabiendo eso, esta claro que tu motivación no es el dinero porque suena a que estas bastante bien montado

No sabría decirte, sin embargo, como de factible es que tu por tu cuenta mejores tu C++ y te pongas al día, para poder aplicar a ese tipo de puestos. Lo veo complicado la verdad, porque yo también estudie C++ en la carrera, pero el C++ que se toca aquí es otro mundo. Ademas, muchos de estos puestos no se meten de lleno en el trading, sino en las herramientas que posibilitan el trading, por ejemplo el parsing y difusión de market data, o los gateway para acceder a los mercados, los gestores de riesgo etc Aunque luego desde esas posiciones es posible saltar a otras.

Lo que veo mas factible es que convenzas a tus jefes para que te den una oportunidad de, poco a poco, ir metiendo el pie en la empresa de ellos. Diles que te involucren en los programas de internship que tienen por ejemplo, o algo así.

Pero bueno si por lo que sea decides tirar por la via autodidacta, busca temas de C++ con multithreading y redes. Crea un servidor que acepte conexiones TCP y que difunda una serie de datos por multicast por ejemplo y que la aplicación cliente tenga un hilo para procesar el feed que llega por multicast, otro para crear unos ficheros de datos generados en función de lo que escucha por esa feed, y otro para los logs. Cuando tengas eso, genera muchos clientes y empieza a jugar con optimizar el código del servidor para gestionar mejor multiples clientes, etc. Creo que eso podria ser un buen punto de partida, que luego podrías presentar como un proyecto personal.

Otra alternativa seria buscarte algun bootcamp, creo que hay algo de algorithmic trading en NY, pero muchos están enfocados al lado Quant, con Python y demás, y ese area realmente esta copada por gente con un dominio en matemáticas.

[#131 zakrion]

#130 No hay de que ! Espero que te sirva, y si al final acabas en la industria pues me debes unas cervezas cuando pase de nuevo por NY

[#25 zoezoe]

#2 x'D

-> www.meneame.net/story/linus-torvalds-dice-no-entiende-completamente-ke
-> www.meneame.net/story/linus-torvalds-nunca-dejare-insultar-desarrollad

[#48 zenko]

#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

[#101 --606024--]

#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.

[#122 zakrion]

#115 Por puntualizar (trabajo en el sector): No se necesitan 3 carreras para llegar a 500k en el sector del trading, de hecho tener esas 3 carreras es rarisimo, generalmente estudian CS los que acaban de ingenieros de software, que suelen arrancar (recien salidos de la uni con 21 años) en 100k + bonus (min 50%) y su tope puede andar sobre los 800k (base + bonus) si son buenos. Luego están los Quant, que suelen hacer Matematicas o Fisica + un PhD. Pero los Quant ya juegan en otra liga y pueden llevarse millones.

Por cierto finanzas ya no estudia nadie que quiera dedicarse al trading en serio. Bueno si, los que vieron el lobo de wall street y se creen que todavía funcionan así las cosas

[#29 soberao]

#10 Linus tiene el copyright de la marca, si lo echan podran seguir con el proyecto sin él, pero no podrá llamarse Linux.

[#30 xizor]

#3 typescript

[#33 mat30]

#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.

[#39 Ovlak]

#3 Mecachis, le has reventado el discurso político en dos frases. Veo que no se anima a volver a por más.

[#56 soberao]

#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.

[#69 squanchy]

#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.

[#70 squanchy]

#4 Las excentricidades son tales porque se consienten. Generalmente, porque desde el primer momento no se le ponen coto.

[#71 squanchy]

#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.

[#97 sorrillo]

#94 No, no lo es.

[#100 soberao]

#86 Pero no es un fork, es Linux sin partes propietarias.

[#102 --8899--]

#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.

[#18 asterissco]

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

[#19 janatxan]

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.

[#27 KaraKulov]

#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

[#31 SalsaDeTomate]

#8 A ver cómo engordar el currículum si no...

[#52 BiRDo]

#41 Como los déspotas preocupados por su legado, nombrará un delfín. Luego lo que pase tendremos que verlo.

[#45 pip]

#43 Barcelona.

[#54 pip]

#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.

[#55 box3d]

#12 y ahí está.
Siendo la muleta Unix de cualquier corporación que la quiera (hola Sony!)

[#63 Find]

El futuro es Hurd

[#81 zeioth]

#1 Hay como 70 mantenedores, simplemente hay mucho que hacer.

[#90 pip]

#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.

[#92 pip]

#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.

[#98 box3d]

#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.

[#99 box3d]

#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.

[#107 Boleteria]

#21 ¿Y como ha llegado el kernel a ser tan complejo? ¿Tiene algo que ver con ser monolítico?

[#117 Find]

#114 Más futuro que eso no hay...

[#118 pip]

#116 hombre, cuando son 24 millones de lineas de código como es el caso, sí es una métrica válida: te sirve para ver que es un proyecto gordito

[#35 mirav]

#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

[#36 Hil014]

Los pagan?, porque yo quiero trabajar de eso y no encuentro trabajo para ello.

[#53 --569461--]

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.

[#57 --569461--]

#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: www.youtube.com/watch?v=kZRE7HIO3vk

[#59 DangiAll]

#21 Y rezar por no tener un ataque da daltonismo

[#62 --569461--]

#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.

[#67 --569461--]

#64 Se amplía la especificación y se inhabilitan operaciones no compatibles. Todo perfectamente definido en el estándar.

[#68 yoshi_fan]

#3 Prefiero C a C++ cuarenta mil veces lol

[#80 --569461--]

#79 Nadie ha hablado de eliminar.

[#83 --625430--]

#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.

[#85 --625430--]

#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.

[#86 --625430--]

#29 #51 Existe Linux-Libre.

[#87 --625430--]

#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.