Amigos, se están peleando en Linux, en Linux hay una batalla.
¿Qué está pasando con RAST?
¿Qué está pasando en Linux?
Pues un maintainer que está encargado, que trabaja en Microsoft
y que está encargado de añadir código de RAST en Linux,
se ha bajado de esta iniciativa porque está frustrado
con estas discusiones y debates no técnicos sin sentido.
Básicamente, porque está todo en inglés, os lo voy a comentar.
Son seis puntos clave.
Uno, renuncia del mantenedor Wetson Almeida Filo,
que era el encargado del proyecto RAST para Linux
y ha renunciado por frustraciones, por problemas no técnicos.
Segundo, motivo de la renuncia, ¿por qué se va?
Se retira del proyecto después de casi cuatro años
porque le falta energía y entusiasmo
y ha tenido que responder a un montón de problemas no técnicos
que estoy cansado, está agotado tener que lidiar con discusiones sin sentidos
y la falta de consenso en la comunidad del kernel de Linux.
Tres, los beneficios de RAST.
Porque el proyecto de RAST se supone que para mejorar Linux,
busca incorporar todas las ventajas de seguridad de memoria de RAST
y el proyecto está recibiendo resistencia interna
por parte de desarrolladores veteranos
que no quieren perder el poder.
No quieren porque no se enteran de RAST.
Ellos están diciendo, joder, si ya sabemos C o C++ o C++ o C++,
como queréis decir, si ya está, ya sabemos esto,
¿para qué? Dejad ya de añadir RAST, que no añade nada nuevo.
Y esto es lo que está pasando, que pese a las ventajas,
mucha gente dentro del proyecto está siempre tirándolo atrás.
Y eso está generando frustración en la comunidad.
Filo expresa decepción con ciertos miembros de la comunidad,
con gente en concreto,
por su comportamiento poco colaborativo y resistencia al cambio.
Ahora, y ojo, cuidado con esto,
porque hay una propuesta alternativa que puede sacudir.
Ojo, porque dice Frank Lingra, dice Linux va a morir.
Yo no creo que Linux vaya a morir.
Es imposible que Linux muera.
Y más cuando es el sistema operativo más utilizado.
Vamos, por delante, por detrás y por donde quieras.
O sea, en todos los sitios, todos los sitios.
Pero, ojo, cuidado con esto.
Hay una propuesta alternativa con todo lo que está pasando.
Y es que algunos desarrolladores dentro del proyecto de Linux,
entre ellos Filo,
están sugiriendo crear un nuevo kernel separado del actual
que esté desarrollado totalmente con RAST desde cero.
Que sea retrocompatible.
Y así, en lugar de intentar integrar RAST en el kernel actual,
crear uno totalmente separado.
Ojo, cuidado con esto.
Esto, yo sé que estamos, ah, qué tontería, no sé qué.
Ojo, cuidado con esto.
Porque esto sí que podría, a ver, es muy difícil.
O sea, antes de que la gente, ah, no, no.
A ver, muy difícil.
Es increíblemente difícil que hagan el kernel desde cero y tal.
Pero, ¿qué está pasando?
Que el código DC existente ahora mismo
está siendo muy difícil, no solo técnicamente,
sino porque mucha gente de la comunidad dentro de Linux
está en contra.
Y hay gente que dice, oye, pues, ¿sabes qué?
Pues vamos a hacer el nuestro propio ya desde cero
que sea retrocompatible y a tomar por saco, ¿vale?
Y ya está, se ha acabado.
Ahora, ¿qué pasa?
Bueno, pese a la renuncia de Filo,
el proyecto de RAST para Linux continúa, ¿vale?
O sea, todavía hay ideas como esta,
pero todavía continúa.
Y ahí tenemos enfrentando, pues,
algunos de estos problemas de la implementación.
Ya Linux, Linux Torvalds, en uno,
no sé si lo pone por aquí,
ya lo comentaba en algún momento,
decía que estaba un poco preocupado
por la rapidez
que estaba haciendo esta implementación de RAST
dentro de Linux
y que tampoco se estaban viendo tantas ventajas,
aunque reconocía que podía ser
por estos debates sin ningún tipo de sentido.
Y en estos debates sin sentido
os voy a comentar una cosa
que quizás no conocíais,
pero es un concepto muy interesante
que seguro que habéis vivido algún día
de vuestra vida.
Y es esto, el bike shedding.
Yo lo aprendí hace mucho tiempo
en una startup en la que estuve,
el bike shedding.
Y es la ley de Parkinson de la trivialidad.
Así suena muy, no sé, muy inteligente.
Ley de Parkinson de la trivialidad.
Parece como el título de una película.
Pero esto es una cosa que realmente
pasa mucho en muchas empresas
a nivel tecnológico.
Y os voy a explicar de qué trata.
Esto básicamente, para que lo entendáis,
esta ley que se llama bike shedding
o el efecto del estacionamiento de bicicletas
o el ejemplo del estacionamiento de bicicletas,
esto es una cosa que suele ocurrir
cuando tú tienes un problema técnico
bastante importante,
con bastante peso,
que tiene que tener una responsabilidad
y resulta que la gente empieza a debatir
por chorradas.
Esto viene, el origen,
es porque en su día Parkinson,
que es la persona que lo inició,
Cyril Northcote Parkinson,
estaban en un comité trabajando
sobre cómo unos planes de una central nuclear
y se dio cuenta de que la gente
estaba todo el rato hablando más
del estacionamiento de bicicletas,
de cómo tenía que ser el color del techo
del aparcamiento,
en lugar de, yo qué sé,
los diseños de la central nuclear,
cómo hacer que tenga más defensas,
que no reviente y cosas así.
Y esto se aplica mucho
en los programas informáticos.
Es bastante interesante
porque muchas veces pasa esto,
que tenemos un problema.
Hola Midu, ¿cómo estás?
Qué pena molestarte.
Quería preguntarte,
hace un tiempo he venido trabajando
en una aplicación web para una clínica,
lo estuve desarrollando
con Laravel y Inertiax.
Bueno, hasta ahí todo bien,
pero hace poco contrataron a alguien
para que me ayuden.
Y dice de emigrarlo todo a NextGS
porque él no conoce Laravel
y no le gusta PHP
y así no se puede trabajar.
¿Qué podría hacer ahí?
A ver, le podrías decir,
¿te quieres callar, payaso?
¿Te quieres callar?
Que acabas de llegar.
¿Qué NextGS ni qué hostias?
Si esta ya ha hecho todo
en Laravel e Inertiax.
Joder, aprende.
Tanta inteligencia artificial
y no vas a aprender.
No tiene sentido
que hagáis la migración a NextGS
y la verdad,
yo te lo digo de corazón.
Yo sé que me gusta más NextGS,
no conozco tanto Laravel,
pero es que tiene sentido.
Si ya has hecho el desarrollo
en Laravel e Inertiax,
otra cosa es que me digas
que llevas tres días
y digo, bueno, pues ahí vosotros entenderéis
si vais a ir más rápido o no con NextGS,
pero si ya lleva mucho tiempo,
las he estado desarrollando,
además vas bien,
no tiene sentido que ahora lo paséis.
Y yo lo que le invitaría a esta persona
es que básicamente
aprenda Laravel e Inertiax.
¿Qué mierda es esta
de que vamos a mirarlo toda NextGS
porque tú no sabes?
Esto no puede ser.
Y esa mentalidad
es no solo muy peligrosa,
sino que tiene bichos
porque esto lo que quiere decir
es que no somos buenos programadores.
Y también lo diría al revés.
Quiero decir,
hay un proyecto que está hecho con NextGS
que llevan ya desarrollándolo
un montón de tiempo,
que no sé qué, no sé cuánto.
Y te viene uno y te dice,
¿y qué lo haríamos más rápido con Laravel?
A ver, tío,
que ya llevamos meses desarrollando este,
que no lo vamos a migrar.
O sea, no, no.
Igual tienes algunas razones de peso
que puedes tener sentido,
pero a ver,
que es que un desarrollo
cuesta mucho dinero.
Prasmatismo, amigos.
Es mucho más fácil
que este chico aprenda Laravel.
Y Laravel es un framework
de sobras contrastado
que se puede hacer un desarrollo
sin ningún problema.
Y si yo fuese el número,
o sea, el que está entrando ahí,
me pondría a aprender Laravel.
Porque al final, además,
es una oportunidad para él.
Es un framework muy demandado
que tiene mucho tirón
y que puede aprender un montón.
Si ya sabe NextGS,
bien por él,
pues que aprenda ahora Laravel.
Igual que aprendió NextGS,
podrá aprender Laravel.
Y esto con todo en el mundo.
Esto es así,
con todo mi cariño.
Yo sé que nos gusta mucho a veces
hacer, utilizar las cosas
que a nosotros nos gustan.
Pero en este caso,
que qué es que te diga,
creo que te dé todo el sentido
del mundo
que utilicéis
y sigáis utilizando Laravel.
Y si no a las malas,
escalarlo
y que tome la decisión
quien lo tenga que tomar
poniendo sobre la mesa
pues lo que tú ya sabes.
Oye, ya este desarrollo
está iniciado con Laravel,
vamos bien,
no estamos tardando,
yo ya tengo un conocimiento,
él se puede adaptar,
no sé qué o cuánto.
Y que él ponga sobre la mesa
lo que él considere
que cree que es tan importante
y que si la decisión
la tiene que tomar más arriba,
pues ya está,
que la tomen,
pero que luego
apechúen con la decisión.
Luego no queremos
pues se iba más rápido con...
Hola,
perdón por interrumpirte,
quería decir
que son las 19 y 8,
gracias.
Cara sonriente.
Gracias a Max,
gracias,
es verdad,
estamos en directo.
Agamalu,
que yo lo que te diría es eso,
me da pena
porque esto es una cosa
que pasa mucho,
en el mundo de la programación
somos muy cuadriculados.
Yo, por ejemplo,
para mí tiene sentido
que yo utilice mucho
Next.js o Astro
porque es lo que me hace
ir más rápido,
pero una persona
que sea muy buena en Laravel
tiene todo el sentido
del mundo que lo haga en Laravel
y eso no significa
que sea mejor o peor
que Next.js,
significa que en programación
una misma cosa
se puede hacer
con diferentes herramientas
y así es como
hay que ver los frameworks,
en realidad,
se tiene que ver
como herramientas.
Así que nada,
mucha suerte
y espero que lo puedas convencer
y esto me recuerda
a lo que estábamos hablando,
ley de Parkinson
de la trivialidad,
el backshading,
porque seguramente
en el proyecto
en el que estás trabajando,
la web esta de la clínica,
pues tendría mucho sentido
porque dices
¿qué es lo más importante?
si es que lo más importante
en realidad
no es el framework,
es que hagáis la web
de la clínica
y la terminéis ya
y aquí lo tenéis,
un ejemplo
de backshading de manual.
Muchas veces,
cuidado con el backshading
porque
se puede perder
mucho tiempo,
es como la típica discusión
del punto y coma,
en que no sé qué,
no sé cuánto,
estos son problemas reales
que la gente está ahí,
que está todo el día
y ahora ya sabéis
cuál es el nombre
que se le da,
pues algún día
lo tenéis que poner
en una reunión,
decís,
ah,
esto es la ley
de Parkinson
de la trivialidad
y lo dejáis,
lo vais a dejar ahí
planchado.
En lugar de usar Lara
es mejor usar Java.
Hostia,
sí,
Java puede estar súper bien,
sobre todo si quieres
que alguien se corte las venas,
puede estar bien,
puedes poner,
hazlo en Java
y así tu compañero
se tirará de la ventana,
pues es que ya está,
hostia,
pues no lo había pensado,
que buena idea,
está muy bien la idea,
eh,
genial,
gracias por,
gracias por compartirlo,
me ha gustado,
me ha gustado mucho la idea,
es broma,
broma,
hombre,
a ver,
yo sinceramente
sí que con Java
una aplicación web
me daría bastante pereza,
pero bueno,
no pasa nada,
aquí cada uno
que utilice
y haga lo que le dé la gana,
pero también tendría sentido,
si alguien con Java
con Spring Boot
lo puede hacer más rápido,
tiene sentido
que también lo utilice,
es que aunque estamos en broma,
tiene todos los sentidos,
es que también con Java
se puede hacer,
que seguramente
te puedes,
puedes dejar
de querer vivir,
puede ser.
Follow al Midus
y lo ves desde el trabajo,
pero no estás trabajando,
está tu amo ahí.
Qué bueno.