Últimamente, será por la senilidad, es (los títulos indi) de lo poco que me gusta.
La nota común en esos proyectos que no pasan de beta, y algunos ni siquiera de alfa, es que el autor no se plantea un entorno de trabajo realista; la mecánica es demasiado compleja para un grupo amater, cuyo entusiasmo supera a la seriedad y conocimientos necesarios para el proyecto.

Siendo piadoso, no meteré en el mismo saco a los pillabichos que pululan por páginas como Patreon, y que sólo aspiran al pelotazo económico para después desaparecer y abandonar la empresa.

Quedándose con lo realmente bueno de éstos juegos, (quitando las versiones en código abierto de juegos comerciales) es que aportan al jugador enfoques, mecánicas, y temáticas que muy dificilmente se llegan a dar en los títulos comerciales, que no creo equivocarme si digo que ya se conforman simplemente con ofrecer más efectos gráficos y más movimientos guionizados.

@cobito "y han fracasado"... ¿y los emoticonos?

Intel ME: tanta tontería de sofisticación para acabar siendo una máquina de Rube Goldberg.

La gente cree que los procesadores son dispositivos infalibles pero la realidad es bien diferente. Si echais un vistazo a la lista de bugs de Haswell vereis que es basicamente un manual de 5 paginas de fallos que ademas ni siquiera estan solucionados donde te dicen como no hacer ciertas cosas para no tener problemas. En la arquitectura Piledriver el conjunto AVX de 256 bits introduce un retraso de cerca de 20 ciclos en cada ejecucion. Y ojo al parche a todos los que tengais un Atom anterior a los Bay Trails porque por cada instruccion de coma flotante que se ejecuta, se introduce una operacion NOP que mantiene el micro sin hacer nada durante un ciclo. Eso quiere decir que el calculo de reales en los Atoms va a la mitad de velocidad de lo que deberia pero como nadie usa los Atoms para eso, no se habla mucho el tema.

Que haya bugs en procesadores es algo normal. Unas veces se ven (como esta) y otras pasan desapercibidos o son solo visibles de cara al desarrollo de software. Me parece raro que AMD no haya dicho nada sobre esto y más si supuestamente han solucionado el problema.

Y al paso que vamos, me da que llegarás a los 15 años...

Lei que ha sido la version con mas cambios de todos los tiempos. Lo del soporte para las rx vega antes de que salga el hardware es algo normal en linux. Este kernel lo llevaran algunas distros que van a tener soporte durante unos mes y puede que incluso años. No disponer de soporte para esas gpus ese tiempo seria un problema. Intel hace lo mismo metiendo los controladores para chips graficos integrados que todavia no se comercializan. De hecho a veces los rumores sobre nuevos productos y fechas de lanzamiento se basan precisamente en el soporte que se le da a linux. Una pena de nvidia siga con su postura de ferreo control sobre su software.

Este tipo de fallos estan a la orden del dia. Los windowserons no os cofieis. No es un fallo especifico de plataforma como he leido por ahi y la gente lo cree porque ha salido por primera vez en las listas de correo de debian. Se trata de un bug del hardware que afecta a todos los sistemas. Pero para reproducir el fallo hay que obtener un codigo compilado muy dificil de conseguir que es tener un bucle muy pequeño (de menos de 64 microinstrucciones). Lo que hacen los sky/kabylake es paralelizar infinitamente este codigo saturando los recursos de la cpu.

ja ja ja! hay que ser mantas. Ya me puedo imaginar al genio que llevaba el tema. Elige esas versiones y periodicamente las actualiza. Un dia deja de recibir actualizaciones del kernel y dice "bien, hoy no hay actualizaciones". Sigue sin recibirlas y piensa "no veas que buena version que no encuetran fallos". Y al cabo del tiempo deja si quiera de buscar porque llevan 5 años sin aparecer actualizaciones. Y claro si no hay actualizaciones es porque no hay fallos de seguridad.

A 300 napos por web alojada no es un mal precio para el mantenimiento tan penoso que hacian. La proxima vez invertiran ese millon en algo mas productivo.

@palotes No se me ocurre otra mejor: software maduro, una gran comunidad, mucha y buena documentación. Viene de serie con casi todo el software que necesito (quitando NodeJS que en Debian 8 venía una versión demasiado antigua). Con Debian 9 no necesitaré recurrir a ningún repositorio externo. Eso se traduce en seguridad y fácil mantenimiento.

Ubuntu LTS es otra buena candidata, pero no veo qué ventajas me trae usar una derivada de Debian sobre la original. El único inconveniente es el soporte para hardware reciente. Cuando cambié al actual servidor hace unos meses, Linux 3.16 no lo reconocía todo y a veces ha sido un poco problemático. Una vez más, con Debian 9 todos esos problemas deberían ser cosa del pasado.

@garfield Sí, de hecho en portada hay un par de entradas sobre el PSP de AMD (esta por ejemplo) relacionadas con "la seguridad de estos sistemas de seguridad".

A ver si llega pronto a Mint, seguro que el pequeño Celeron se alegra de estas mejoras.

@kynes La retrocompatibilidad es una ventaja indiscutible, pero no creo que sea un requisito para alcanzar el mercado doméstico. Tenemos el ejemplo de ARM que de vez en cuando hace incursiones en ordenadores de sobremesa (con las placas Tegra de Nvidia por ejemplo) y que ha conseguido dar un pequeño mordisco a los portátiles con los Chromebook. De hecho, hasta Microsoft sacó un Windows ARM aunque después decidiera abandonarlo.

La verdad es que no sé hasta qué punto IA-64 hubiera aportado algo interesante a la actual IA-32 + ADM64 (x86-64), pero de lo que estoy casi seguro es de que el haber mantenido un nicho como los servidores de gama alta teniendo como ensamblador sólo a HP, ha matado la arquitectura y más teniendo a un monstruo como IBM haciéndole sombra en ese segmento.

Por cierto, Intel ha dicho que el sustituto para los Itanium serán los Xeon. A ver si dan un empujón a x86 que dejando de lado las limitaciones físicas de la fabricación, parece que últimamente no están haciendo grandes logros.