Yo me refería a esto.
Las funciones en tiempo real pudieron mantenerse durante mucho tiempo como un proyecto separado del kernel, y quien las necesitara podía tomarlas, aplicarlas al kernel y usarlas.
No he desarrollado del lado de Linux.
Parece que el wrapper en Rust para los controladores de dispositivo tiene una estructura que no puede separarse del kernel...
Yo también soy usuario de Rust, pero si se mezcla código Rust con código C en un proyecto open source, a menos que exista una política estricta sobre hasta dónde se permite el uso de Rust, me parece que se volvería imposible de controlar o, como mínimo, subirían muchísimo los costos de revisión y mantenimiento; por eso creo que la decisión más sensata es hacer un fork en lugar de agregarlo.
Creo que quiere decir que, entre varios métodos de marketing, un blog no necesariamente es la mejor opción; pero las alternativas que propone son pararse con un cartel frente a la oficina del cliente o ponerse a discutir en X, así que no me convence mucho.
No sé mucho del kernel, pero creo que estaría bien si se pudiera traducir automáticamente el código en C a Rust. Claro, además del problema de traducir el código, también estaría el factor humano.
Recuerdo que, cuando era necesario hacer backport a la versión estable o por algo así y me ponía en contacto, incluso en medio de todo ese trabajo respondía muy bien.
Me cuesta estar totalmente de acuerdo con esa idea, aunque entiendo el punto cuando veo empresas que invierten en SEO a largo plazo para aumentar el tráfico orgánico y, con eso, generar ingresos estables.
No sé bien qué debería decirle porque no sé si usted tiene experiencia en desarrollo del kernel.
Antes que nada, aplicar el lenguaje Rust no significa cambiar el kernel a Rust. Se podría decir que entonces bastaría con separarlo y crear otro kernel, pero
la idea no es hacer el kernel en Rust, sino crear wrappers en Rust solo para las interfaces del kernel destinadas a los controladores de dispositivos, de modo que únicamente los controladores de dispositivos
puedan desarrollarse en Rust. Por eso, irse a un proyecto nuevo no tiene sentido.
Hay que dejar atrás la ilusión de la ingeniería global..
Se necesita una optimización extrema de procesos, pero el desarrollo en tres turnos con una sola base local es común en el sector de los videojuegos.
Por ejemplo, los grandes estudios de juegos chinos desarrollan 24 horas al día en 3 turnos.
Compañías de videojuegos como EA y Ubisoft, donde la ingeniería global lleva mucho tiempo establecida, trabajan según sus respectivas zonas horarias, así que los retrasos en la velocidad de ejecución son inevitables, pero operan con la idea de que un costo de vida bajo + costos laborales más bajos compensan eso. (Ahora, con los despidos masivos, no sé en qué situación estarán)
Resulta bastante irónico que la comunidad de Linux, que venía justificando un tono tóxico en nombre de la estabilidad del kernel, ahora considere razonable responder con "si no te gusta, haz un fork".
No entiendo en absoluto la afirmación de que debería hacer un fork e irse. ¿Por qué demonios Linus tendría que hacer un fork y salir de Linux?
Yo me refería a esto.
Las funciones en tiempo real pudieron mantenerse durante mucho tiempo como un proyecto separado del kernel, y quien las necesitara podía tomarlas, aplicarlas al kernel y usarlas.
No soy parte de la comunidad de Linux, pero...
No he desarrollado del lado de Linux.
Parece que el wrapper en Rust para los controladores de dispositivo tiene una estructura que no puede separarse del kernel...
No creo que se deba considerar a esas personas y a quien escribió este comentario como parte de la misma comunidad.
Yo también soy usuario de Rust, pero si se mezcla código Rust con código C en un proyecto open source, a menos que exista una política estricta sobre hasta dónde se permite el uso de Rust, me parece que se volvería imposible de controlar o, como mínimo, subirían muchísimo los costos de revisión y mantenimiento; por eso creo que la decisión más sensata es hacer un fork en lugar de agregarlo.
Creo que quiere decir que, entre varios métodos de marketing, un blog no necesariamente es la mejor opción; pero las alternativas que propone son pararse con un cartel frente a la oficina del cliente o ponerse a discutir en X, así que no me convence mucho.
No sé mucho del kernel, pero creo que estaría bien si se pudiera traducir automáticamente el código en C a Rust. Claro, además del problema de traducir el código, también estaría el factor humano.
Había querido usar Obsidian personalmente en el trabajo, pero lo había dejado por el tema de la licencia; creo que tendré que volver a probarlo.
Qué bien...
Pensé que era una traducción libre.
Ah, yo estaba suscrito con licencia comercial, qué bueno.
Recuerdo que, cuando era necesario hacer backport a la versión estable o por algo así y me ponía en contacto, incluso en medio de todo ese trabajo respondía muy bien.
Me cuesta estar totalmente de acuerdo con esa idea, aunque entiendo el punto cuando veo empresas que invierten en SEO a largo plazo para aumentar el tráfico orgánico y, con eso, generar ingresos estables.
No sé bien qué debería decirle porque no sé si usted tiene experiencia en desarrollo del kernel.
Antes que nada, aplicar el lenguaje Rust no significa cambiar el kernel a Rust. Se podría decir que entonces bastaría con separarlo y crear otro kernel, pero
la idea no es hacer el kernel en Rust, sino crear wrappers en Rust solo para las interfaces del kernel destinadas a los controladores de dispositivos, de modo que únicamente los controladores de dispositivos
puedan desarrollarse en Rust. Por eso, irse a un proyecto nuevo no tiene sentido.
Definitivamente hay muchísimos videos de GOTO..
Hay que dejar atrás la ilusión de la ingeniería global..
Se necesita una optimización extrema de procesos, pero el desarrollo en tres turnos con una sola base local es común en el sector de los videojuegos.
Por ejemplo, los grandes estudios de juegos chinos desarrollan 24 horas al día en 3 turnos.
Compañías de videojuegos como EA y Ubisoft, donde la ingeniería global lleva mucho tiempo establecida, trabajan según sus respectivas zonas horarias, así que los retrasos en la velocidad de ejecución son inevitables, pero operan con la idea de que un costo de vida bajo + costos laborales más bajos compensan eso. (Ahora, con los despidos masivos, no sé en qué situación estarán)
Resulta bastante irónico que la comunidad de Linux, que venía justificando un tono tóxico en nombre de la estabilidad del kernel, ahora considere razonable responder con "si no te gusta, haz un fork".
222
Oh, es una buena decisión..