Ya se ha anunciado la versión 3.19 de Linux. Esta versión añade soporte en Btrfs para sustitución rápida de dispositivos y scrubbing en RAID 5 y 6, soporte para las extensiones de protección de memoria de Intel, que ayudan a parar la explotación de desbordamientos de búfer, soporte para la arquitectura AMD HSA, soporte para el sistema de depuración ARM Coresight, soporte para la arquitectura Altera Nios II, soporte para la descarga de las funciones de switchs y routers en chips de hardware, soporte para la preasignación y el borrado de […].
|
etiquetas: novedades , linux , linux 3.19 , software libre 
Aún así, tiene mi meneo
En serio, maravilloso el desarrollo. Lo ubicuo que es Linux hoy en día es genial. Y la madurez de BTRFS es muy importante para el desarrollo de soluciones de contenedores.
Aún así, tiene mi meneo
Sin comentar que Windows saca version buena, version mala.
Gracias!
/Modo día de los enamorados: off
open-zfs.org
Y en teoria la próxima versión en vez de 3.20 pasará a ser 4.0 por el mismo motivo; porque no hay ningún motivo.
Casi todas las novedades van enfocadas a dispositivos de uso industrial, y cuatro formalismos sobre donde debe estar cierto código de android.
plus.google.com/app/basic/stream/z13tw1t5hkqiv1rjz04cj1yx1py4xrsb1ps0k
PD: Para los curiosos y perezosos, va ganando la versión 4.0. Habemos next mayor version
No obstante, la opción de OpenZFS no estaría de más.
/cc #20
La rama 2.4 solo recibía parches de mantenimiento procedentes de la rama 2.6 desde hace muchos años, y el kernel de Android lo desarrolla Google por su cuenta y solo algunos de los parches han llegado a la rama principal.
El único motivo de pasar a la versión 3.x fue porque no había ningún motivo y porque que ya habia muchas versiones 2.6.x
~$ uname -r
3.2.0-76-generic-pae && raid
3.3.2-fedora
uname -r
3.13.0-45-generic
furlz proletariat
Que el planificador de procesos sea más eficiente o que el sistema de archivos tenga un mejor sistema de journaling para recuperar errores no van a cambiar el panoráma del escritorio. Lo que necesita es conseguir un ecosistema de aplicaciones rentable.
$ uname -r
3.19.0
Plebs.
OpenZFS de momento, Tux3 en el futuro, Btrfs nunca.
En cualquier caso, paso de btrfs. Feature checklist, sin diseño.
No se puede permitir que para instalar cualquier programa en un usuario corriente tenga que usar la consola de comandos que no es nada intuitivo, hay "documentarse" para saber los parámetros (indicarle la acción a llevar a cabo dentro de todas las que tiene) creando asi frustración e impotencia cuando no sabe. Ver la consola para un usuario es "chocante" ya que no hay por donde cogerlo, a nivel de interfaz es horrible no hay nada parecido que alla usado y pueda usarlo como guia, el primer pensamiento es "cualquier cosa que introduzca metere la pata" y como resultado que el usuario no quiera saber nada de Linux.
En lo que no tienes razón es en lo de Android. Desde la versión 3.3 (mayo 2012), android hizo un merge con linux (fuente: kernelnewbies.org/Linux_3.3#head-b733d694037e0b34ad47e1b5d38ebc4d1bd1d ). Desde el año 2013, Google es el desarrollador que más código aporta al kernel de Linux.
Nuevamente, el conflicto entre android y linux allá por el año 2010 impidió pegar formalmente el salto a la nueva nomenclatura (android hizo branch en la 2.6.33, antepenúltima versión de la rama 2.6 [fuente: www.kroah.com/log/linux/android-kernel-problems.html ] ).
Quizá no podemos decir que Android fue el motivo, porque nadie oficialmente puso grito en el cielo, pero si que había un monton de trabas para conseguir dar el salto a 3.0.
Hay que recordar que fue un simple cambio nominal y organizativo, más que una mejora que sustentara el salto a 3.0, pero dentro de la comunidad de desarrolladores, se tiene el sentimiento que desde que el kernel ha sido enfocado principalmente a dispositivos móviles/embebidos, allá por la 2.6.32, tercera longterm stable, que fue cuando Google empezó a inyectar código de forma constante. Ahí debería haberse pasado a 3.0. Llegó tarde el salto, pero era ya absolutamente necesario por ese motivo final.
Y si que se han incluido algunos parches de Android en la rama principal, pero aun faltan muchos y a día de hoy el kernel de Android sigue siendo una rama separada. Prueba de ello es que en esta misma noticia se dice que se ha hecho un merge de un parche de Android de hace varios años. Otra prueba, esta vez de tu enlace:
"Various Android subsystems and features have already been merged, and more will follow in the future."
Se han incluido varios, que no todos. Y eso fue con la 3.3, pero es que el desarrollo de Android no se ha parado, por ejemplo con la ultima version, 5.0 Lollipop, hay muchos cambios en el kernel, que por supuesto no están en la rama principal de Linux ni se les espera pronto. Y para cuando se incluyan ya habrán salido nuevas versiones de Android con mas cambios y así hasta el infinito.
Linus lo dijo en su momento, Android y Linux algún día se unirán, pero no esperéis que sea pronto..
Por que tú lo digas
" hasta que la instalación de programas sea tan facil como en Windows, "
www.microstiffed.com/wp-content/uploads/2013/12/bing-bar.png
", apariencia (el gran punto débil de los programadores que estan a favor del software libre)."
Perdona, la mayoría de programas para Windows tienen una interfaz horrorosa. ¿O no te acuerdas de los 90?
"
No se puede permitir que para instalar cualquier programa en un usuario corriente tenga que usar la consola de comandos "
No tiene por qué.
"" ya que no hay por donde cogerlo, a nivel de interfaz es horrible no hay nada parecido que alla usado y pueda usarlo como guia,"
La gente nace aprendida, claro. Y en OSX, al salir de Windows, lo aprenden por arte de magia. ¿Qué coño es eso del Dock
Tarde o pronto se dara la ocasión.
-"ya que no hay por donde cogerlo, a nivel de interfaz es horrible no hay nada parecido que alla usado y pueda usarlo como guia,"
No estoy criticando el nivel de aprendizaje de los usuarios, critico la falta de interfaz en los programas.
Si respondes que sea para debatir con argumentos, el resto de tus respuestas las omito responderlas al no partir de una base.