Portada
mis comunidades
otras secciones
#7:
La pregunta es por qué un usuario de un procesador que dejó de fabricarse hace 15 años necesitaría la próxima versión del kernel. No tiene ningún sentido. Como dice Torvalds, si alguien tiene el caso, que use una versión anterior.
Todo tiene un límite, el legacy hay que mantenerlo, y llega un momento en el que es absurdo y hay que soltar lastre.
Todo tiene un límite, el legacy hay que mantenerlo, y llega un momento en el que es absurdo y hay que soltar lastre.
#1:
Hay que poner un límite a la backward compatibility o nos quedamos atascados. En mi opinión, claro.
Comentarios
La pregunta es por qué un usuario de un procesador que dejó de fabricarse hace 15 años necesitaría la próxima versión del kernel. No tiene ningún sentido. Como dice Torvalds, si alguien tiene el caso, que use una versión anterior.
Todo tiene un límite, el legacy hay que mantenerlo, y llega un momento en el que es absurdo y hay que soltar lastre.
#7 La retrocompatibilidad es la gran losa en el avance, desde las CPU X86 a los kernels de Linux y no en tanto medida los de M$.
Los únicos que van por "faena" son los de Apple, se van pelando las retro compatibilidades cada poco y si no te funciona, pues te compras un Mac nuevo, esa es su política, con Catalina se pelaron todo lo que no fuera 64bits.
#13 Apple es el extremo opuesto. Como desarrollador me agota un poco tener que estar subiendo las versiones de todo constantemente.
#14 A ellos les da igual los usuarios y los desarrolladores, lo que quieren es seguir vendiendo y si deja de ser compatibles y se tienen que comprar equipos nuevos mejor para ellos.
Ya hicieron el salto de PowerPC a x86, luego se pelaron el x86 para dejar solo los 64bits, y están preparando el salto definitivo a ARM.
#16 no son solo los saltos entre arquitecturas. Son las librerías y todo lo demás, MacOS está constantemente obligándote a subir versiones de todo.
Pero sí, está claro que ellos miran por sus intereses no por los intereses de los desarrolladores.
#16 ¿"salto definitivo a ARM"?
nah: arm-cambia-modelo-comercial-socios-oem-deben-obtener-licencias/c01#c-1
Arm cambia el modelo comercial: los socios OEM deb...
semianalysis.comHay que poner un límite a la backward compatibility o nos quedamos atascados. En mi opinión, claro.
#1 Aupa el 8086 y su set instructions.
#8 Linux nunca ha funcionado en un 8086.
#20 Larga vida al Buffer Overflow y al Test Fuzzy.
#1 poco sentido le veo a la opinión, la verdad.
¿ Por qué nos íbamos a quedar atascados ?
Lo importante es que se aprovechen las nuevas capacidades del hardware nuevo y eso ya se está haciendo de toda la vida.
#11 Pues no estoy de acuerdo. A veces para evolucionar de verdad hay que romper con todo lo anterior, de lo contrario es parchear y parchear.
#11 mantener el legacy no es gratis. Se dedican horas a algo que ya nadie usa cuando se podría dedicar a nuevo desarrollo.
Y también hay veces como dice #15 que el hardware cambia tanto que necesitas una refactorización seria para poder sacarle realmente partido a las nuevas arquitecturas.
#17 Más claro, agua.
#17 si es por cuestiones de coste, pues ya es otro tema con el que yo podría estar o no de acuerdo una vez que lo estudiara.
Pero con lo que dice #15 no estoy de acuerdo porque la soclución la das tú mismo: hacer una refactorización correcta.
#15 Si hay una buena arquitectura de software, se incluye todo lo nuevo del nuevo hardware sin problemas, respetando lo anterior.
Si no hay una buena arquitectura de software, debe cambiarse para que sea buena.
En el caso del núcleo de línux no hay mucha controversia: la arquitectura es buena, cualquiera puede verlo. Y se hacen las refactorizaciones necesarias cuando se precisa.
#11 yo, ahi, tengo opiniones encontradas. En el siglo XIX (finales), cuando se produjo la transicion vapor electricidad, los empresarios se quejaban de que su inversion no tenia el retorno esperado. La razon es que habían electrificado las fabricas basadas en vapor, lo cual no tenia mucho sentido: la arquitectura de la fabrica estaba centrada en el hecho de tener una maquina de vapor y tener qur llevar la energia que generaba a las distintas estancias. Fue cuando se empezaron a construir fabricas pensadas incialmente en usar electricidad y no vapor, cuando se produjo realmente el cambio y se vio que la electricidad era el futuro.
Vamos, que como dice #1, el backwards compatibility debería tener un limite (y a partir de este solo recibir parches de seguridad... Como mucho). Porque la arquitectura de las maquinas viejas dicta muchos aspectos del software de hoy, y mantener dos ramas distintas implica muchas horas de trabajo.
#33 el ejemplo no está relacionado para nada. El mensaje #1 nio habla de rentabilidades y es la clave en tu ejemplo. Busca uno mejor.
#34 si de mi ejemplo te has quedado con lo de las rentabilidades, que es un mero detalle, igual en lugar de sugerir buscar ejemplos deberías reflexionar sobre lo que (obviamente no) has entendido
#38 ¿ que sugieres que no se maneja toda la potencia del nuevo hardware para mantener la compatibilidad del viejo ?
Eso no es verdad. Hay una pelea constante por que el núcleo de línux maneje el nuevo hardware en su totalidad y ahí lo determinantees la velocidad a la que sale nuevas funcionalidades en el hardware. La existencia de otro viejo no supone limitación. Como mínimo es así en los módulso de línux que conozco, pero dada la arquitectura del núcleo, supongo que será igual en todas partes.
No obstante estos temas son muy complicados para mí y creo que voy a dejar la conversación en manos de quienes controláis.
#39 Yo no he sugerido tal cosa, y coincido contigo en que eso no es verdad (por eso no lo he sugerido). Lo que sí he sugerido es: todo cambia, los conceptos de arquitectura evolucionan, nuevas herramientas hacen el trabajo del programador mas simple, y menos propenso a errores, etc., El tener que mantener una arquitectura (de kernel, pero este razonamiento aplica a cualquier software) dada porque tiene que funcionar en arquitecturas hardware extremadamente viejas (20 o mas años) limita lo que puedes hacer. Claro que hay soluciones: desarrollar modulos específicos para arquitecturas mas nuevos y listos.. pero en el momento en que podrías hacer cambios mas transversales para sacarle mas jugo al nuevo hardware te encuentras con que el viejo no lo soporta, o que tendría una perdida de rendimiento importante (debido a los cambios que tendrías que introducir) y... cagada.
En terminos generales, la retrocompatibilidad es una lacra. Yo entiendo que cierto nivel de retrocompatibilidad sea necesario porque no puedes perder soporte despues de 3 años de tener una maquina, pero de eso a 20 años... pues a mi me sobran como 10, almenos. Y a nivel de hardware lo mismo: Si se pudiera hacer algo tipo lo que hicieron los de Apple cuando se migró de PPC a Intel (Rosetta, creo que se llamaba?) y forzar a los fabricantes a ofrecerlo siempre, la evolucion en cuanto a arquitecturas (porque x86 es otra lacra)... existiria, a efectos practicos.
Según la Wikipedia, los 486 se dejaron de fabricar en el 2007, después de 15 años, me pregunto quién puede tener un equipo de este tipo y para qué lo usa, seguramente está funcionando con alguna versión de Linux que ni siquiera necesita actualizarse.
A mi me parece bastante razonable.
#6 todas las versiones de linux corrigen bugs de versiones anteriores.
#12 y meten nuevos bugs
#19 eso es falso, son features 😂 😂 😂
#19 esperemos que no lo hagan a propósito, pero quien sabe, quizá sea una forma de asegurarse el trabajo.
#6 hace tiempo se mandaban 486 en satélites por la robustez frente a radiación. Pero claro igual no hace falta la última versión del kernel
#6 Juraría se siguen fabricando procesadores, aunque no los haga Intel. Hay muchos sistemas "empotrados" que seguro siguen montando 486.
#26 Nadie fabrica 486, ni Intel ni ninguna otra empresa.
#31 Estaba mirando si se seguían fabricando los Geode, pero son 586.
#32 Me la envaino. Estaba pensando en micros para PCs, pero en sistemas embebidos sí hay alguna cosa: http://www.zfmicro.com/zfx86.html
#6: El ASFA Digital de los trenes corre sobre un 486 a 66 MHz, al menos en los trenes Sepia de CAF (serie 120.000, o sea, los "fase 1"), porque lo vi al arrancar su ordenador. Son estos trenes:
https://www.listadotren.es/motor/series.php?id=281
No sé si otros sistemas (Indra, Dimetronic ó Siemens...) corren con lo mismo.
PS: Sí, la seguridad del tráfico ferroviario está en parte en manos de #Indra. #troll
#29 Pues ya se puede decir que son tecnologia punta ... los Airbus 737Max llevan 286
Puta obsolescencia programada.
#0. Linus Torvalds, empezaste con un "Sinclair QL", un poquito de respeto y de coherencia con el cada día más escaso retro-hardware Libre y liberado que nos queda. Los 386 y 486 son historicamente relevantes.
Edit #2. Linus Torvalds, aloitit "Sinclair QL:llä", hieman kunnioitusta ja johdonmukaisuutta yhä niukemman vapaan ja julkaistun retro-laitteiston kanssa, jota olemme jättäneet. 386 ja 486 ovat historiallisesti tärkeitä.
#2 ¿Sinclair QL? Negativo por hacerme sentir viejo.
#2 Che! Que el QL lleva un Motorola 68k, poca coña que sigue siendo un bicharraco
#9. "...the QL uses a Motorola 68008. The 68008 is a member of the Motorola 68000 family with 32-bit internal data registers, but an 8-bit external data bus..."
https://en.wikipedia.org/wiki/Sinclair_QL
#2 nada impide que voluntarios hagan un fork del núcleo y sigan manteniendo la compatibilidad
Como este 2022 va a ser el año de Linux retirar este soporte influye ya poco.