Ya se ha anunciado (por diferentes canales)la versión 3.0 del kernel Linux.
Aparte de un nuevo sistema de numerar versiones, este kernel tiene unas cuantas novedades: defragmentación automática y 'scrubbing' de datos en Btrfs, envío de mensajes ICMP_ECHO sin privilegios, wake on WLAN, filtrado de paquetes BFP acelerado mediante JIT, soporte de XEN dom0, un sistema a lo memcached para el caché tde páginas, la llamada al sistema sendmmsg() que envía múltiples instancias de sendmsg(), la llamada al sistema setns() para gestionar mejor los sistemas de virtualización ligera, como los contenedores, soporte de nuevo hardware como por ejemplo Microsoft Kinect y APUs AMD Llano Fusion, y muchos otros drivers y pequeños cambios. La lista completa de
cambios, en inglés, puede encontrarse aquí, como siempre.
· Btrfs: defragmentación automática, scrubbing, mejoras de rendimiento
· Defragmentación automática: Los sistemas de archivos COW (copy-on-write, copiar-al-escribir) tienen muchas ventajas, pero también algunas desventajas, como por ejemplo la fragmentación. Cuando Btrfs escribe un archivo al disco por primera vez lo hace secuencialmente, pero el diseño COW implica que cualquier modificación posterior no debe reescribir los datos antiguos, sino escribirlos en un bloque libre del disco, lo cual causa fragmentación (las bases de datos RPM son un caso común de este problema). Además, están los problemas de fragmentación comunes a todos los sistemas de archivos. Btrfs ya ofrecía algunas alternativas para luchar contra este problema. En primer lugar, soporta defragmentación en vivo utilizando el comando "btrfs filesystem defragment". En segundo lugar, tiene una opción de montaje, -o nodatacow, que desactiva el COW para los datos. Ahora se añade una tercera opción, la opción de montaje -o autodefrag. Este mecanismo detecta pequeñas escrituras aleatorias en los archivos y los defragmenta automática y transparentemente, sin intervención del usuario. Aun no funciona bien con imágenes de virtualización o grandes bases de datos, pero funciona bien para los archivos pequeños como bases de datos rpm, sqlite o bdb.
· Scrubbing
"Scrubbing", que podría traducirse como "fregar", o "restregar", consiste en comprobar la integridad de todos los datos del sistema de archivos: Se van comprobando los checksums de todos los datos, y si hay alguno erróneo, o el disco está dañado, se restaura una copia en buen estado, de haberla.
· Mayor velocidad de creación/eliminación de archivos: Btrfs tiene bajo rendimiento en la creación/eliminación de archivos, la razón es que cada creación/eliminación necesita hacer modificaciones en el b+tree, como insertar o eliminar un item de inodo, de nombre de directorio, índice de directorio, etc. Ahora btrfs puede retrasar la inserción/eliminación de items en el b+tree, lo que permite acumular modificaciones y hacerlas todas de una vez. Los microbenchmarks de creación de archivos se han acelerado un ~15%, los de eliminación un 20%.
· No escribir al disco items de checksum de datos que no han cambiado: Mejora el rendimiento de fsync. Un benchmark sysbench haciendo "escritura aleatoria + fsync" ha aumentado de 112.75 peticiones/segundo a 1216 requests/seg.
· Asignador de espacio en configuraciones con múltiples discos: El asignador de "chunks" (el que busca espacio para usar en el disco) siempre asigna el espacio en las configuraciones multidisco en el mismo orden. Esto causa una distribución de los datos subóptima, especialmente usando RAID1/10 y un número impar de dispositivos. Ahora btrfs intenta buscar espacio en primer lugar en los discos con más espacio.
· sendmmsg(): acumulación de llamadas a sendmsg():
recvmsg() y sendmsg() son las llamadas al sistema que se utilizan para recibir/enviar datos a la red. En Linux 2.6.33 se añadió recvmmsg(), una llamada al sistema que permite recibir en una sola llamada al sistema los datos de varias llamadas recvmsg(), lo cual mejora el rendimiento y la latencia en muchos casos. Ahora, se ha añadido su equivalente sendmmsg(). Los microbenchmarks muestran una mejora de ancho de banda en el envío de tráfico UDP del 20% y un 30% en sockets raw.
· Soporte de Xem Dom0: Por fin, Linux tiene soporte del modo Dom0 de Xen, requisito para poder funcionar como host Xen sin parches.
· Cleancache: Cleancache es algo opcional que permite aumentar el rendimiento del caché de páginas del kernel. Podría describirse como algo análogo a memcached, pero para páginas de cache. Proporciona un almacenamiento no directamente direccionable por el kernel, que no garantiza que los datos que se escriban en él no desaparecerán. Puede ser usado por sistemas de virtualización para mejorar la gestión de memoria de las VMs, pero también puede usarse para implementar un caché comprimido.
· Filtrado de paquetes BPF mediante JIT: El filtrado de Berkeley Packet Filter, que es lo que utilizan herramientas como libpcap/tcpdump, normalmente se hace con un intérprete. En esta versión se ha añadido un JIT que genera código nativo para los filtros, y hace que el filtrado sea mucho más rápido. Aunque pueda parecer una exageración tener un JIT en el kernel, lo cierto es que se trata de un JIT muy, muy simple, y es algo que otros sistemas operativos, como FreeBSD, tienen desde hace años.
· Wake on WLAN: Wake-on-LAN es la capacidad de que un sistema dormido pueda ser "despertado" por un paquete de red especial. En esta versión se añade en la implementación 802.11 la misma capacidad, pero para tarjetas de red inalámbricas.
· Mensajes ICMP_ECHO sin privilegios: Esta versión permite enviar mensajes ICMP_ECHO (es decir, un ping) sin necesidad de privilegios de root, lo cual permite que la herramienta ping no requiera setuid.
· Llamada al sistema netns(): Linux soporta diferentes espacios de nombre para los diferentes recursos que gestiona; por ejemplo, las formas ligeras de virtualización, como los contenedores o systemd-nspaw, muestran a los procesos virtualizados un PID virtual en lugar del PID real. Lo mismo puede hacerse con la estructura de directorios del sistema de archivos, los recursos de red, IPC, etc. La única manera de configurar diferentes espacios de nombre es usar diferentes flags en la llamada al sistema clone(), pero ese método no permite hacer cierto tipo de cosas, como permitir que un proceso acceda al espacio de nombres de otro proceso. La llamada al sistema setns() resuelve ese problema.
· Temporizadores-alarma: Los temporizadores-alarma son temporizadores híbridos, similares a los temporizadores de alta resolución, sólo que cuando se suspende el sistema, se activa el RTC para que se dispare y despierte el sistema.Este concepto está inspirado en los temporizadores-alarma de Android, y la API usa la interfaz de relojería POSIX.
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
22 de julio de 2011
15 de julio de 2011
Cómo instalar Fedora 15, u otra distro, sobre Btrfs como mandan los cánones
Hace ya meses que la cuenta de sectores relocalizados de mi disco duro (sectores dañados cuya referencia se modifica para que apunten a otros en buen estado) era demasiado preocupante, una especie de señal divina advirtiendo de que era hora de cambiar de disco, así que he aprovechado para conseguirle no un reemplazo, sino dos (con sus correspondientes ventiladores), y de ese modo dar a btrfs un hogar más apropiado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
Con esto se han creado los subvolúmenes requeridos.
Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
Pero al comenzar una instalación nueva de Fedora 15, con ese inexplicable deseo de convertirla en espejo y honra de todos los administradores, me encontré con un problema que no había resuelto en la anterior instalación, y que ahora podía aprovechar resolver. Se trata de hacer, desde el principio, una instalación acondicionada para convivir con los subvolúmenes de btrfs.
En btrfs, los subvolumenes (que podrían describirse confusamente como pseudosistemas de archivos vacíos creados a partir del espacio disponible) son añadidos a la raíz del sistema de archivos como directorios. Una buena instalación sobre btrfs debería dejar ese directorio raíz exclusivamente para subvolúmenes, e instalar cosas dentro de estos. Por ejemplo, tendríamos un subvolumen "/raiz-fedora/" con la instalación de Fedora, otro "/raiz-debian/" con la de Debian, y un cursi "/casita/" para los datos personales. El problema está en que los instaladores de las distros no tienen nociones de subvolúmenes (Fedora los tendrá en la próxima versión), no permiten crearlos; y, lo que es más puntilloso, tampoco permiten montar unos que se hayan creado a mano fuera de la instalación, así que te instalan todo en la raíz principal. Se puede solucionar posteriormente a base copiar archivos y modificar el fstab, no digo que no, pero hay una alternativa, que cuento aquí porque no he logrado encontrarla en Google.
Resulta que btrfs permite configurar un subvolumen determinado como directorio raíz, es decir, podemos hacer que al montar el sistema de archivos, en lugar del directorio raíz contenedor de todos los subvolúmenes, monte /raiz-fedora o /raiz-debian. Así que, metidos en la tarea...
# mkfs.btrfs -d raid0 -m raid1 -L btrfspool /dev/disco1particion /dev/disco2particion Con esto se crea un "pool" de almacenamiento consistente de esos dos discos, con la configuración de RAID0 (distribución) para datos y RAID1 (replicación) para metadatos (en un futuro se podrán tener diferentes políticas para cada subvolumen, pero de momento...)
# mount /dev/sdb /mnt; cd /mnt # btrfs subvolume create raiz-fedora Create subvolume './raiz-fedora'# btrfs subvolume create casita Create subvolume './casita'
Con esto se han creado los subvolúmenes requeridos.
# btrfs subvolume list /mnt
ID 256 top level 5 path raiz-fedora
ID 257 top level 5 path casita# btrfs subvolume set-default 256 /mnt Con esto se consigue que cada vez que se monte el sistema de archivos se monte directamente el subvolumen raiz-fedora, y no la verdadera raiz, que quedará oculta a primera vista (se puede volver a montar pasando a mount la opción -o subvolid=0). Ahora se puede instalar Fedora -con el DVD de instalación, no el Live, y pasando "btrfs" como opción del kernel-, y bastará indicar al instalador que se utilize /dev/disco1particion como raíz /: sin que el instalador se percate, estará instalando sus cosas en el subvolumen raiz-fedora.
Queda lo de poner al subvolumen casita como "/home". Una vez terminada la instalación, y antes de entrar por primera vez en la sesión, se puede entrar a una consola y modificar el /etc/fstab, añadiendo la línea correspondiente y, si apetece, adornar la de la raiz:
UUID=numero-raro / btrfs defaults,subvol=raiz-fedora 1 1UUID=mismo-numero-raro /home btrfs defaults,subvol=casita 1 1 Tras esto, un reinicio, un mount -a o un montaje manual montará el subvolumen casita donde corresponde, aunque hay que acordarse de dar permisos adecuados al nuevo directorio /home (chmod o+rx /home). Ya puestos en la tarea, parecería apropiado crear el directorio del usuario que ya se había creado en los diálogos de inicio: mkdir /home/usuario; chown usuario:usuario /home/usuario - bonus para quien sea lo suficientemente diligente para, antes de montar el subvolumen en /home/, mover el directorio de usuario que la instalación había creado a, por ejemplo, /tmp, y devolverlo luego a su sitio natural.
Pero no se fíen, que siempre está SELinux para hacer la puñeta. Además de dar permisos a todos los usuarios en el nuevo montaje /home, es necesario darle el contexto SELinux adecuado, y también a /home/usuario, especialmente si quieren mover todos sus archivos personales de una instalación anterior. Así que queda un último comando: restorecon -R /home. Y, ahora si, todo completado.
14 de julio de 2011
10 de julio de 2011
Google++
Hay que reconocer que la estrategia de las invitaciones es un gran idea: se controla el número de usuarios durante el periodo de pruebas, y al mismo tiempo la gente hace ruido para entrar. De todos modos Google parece haber abierto en los últimos días el caudal de invitaciones, así que no tardarán en llegar a todo el mundo.
Pueden estar tranquilos, no voy a hablar sobre teoría de simetrías en las relaciones de redes sociales y en qué lado cae Google+, en parte porque no sé nada sobre el tema, y también porque otros ya lo han hecho. En general, los Círculos me parecen una buena idea. Se dice que esa manera de gestionar los contactos es más difícil de manejar que otras, pero esa afirmación sólo es cierta tomada como argumento técnico, desde el punto de vista de las relaciones sociales del mundo real los círculos son, en mi opinión, más intuitivos y comprensibles porque se corresponden con mayor fidelidad con la vida cotidiana.
Facebook desprecia ese punto de vista, y por eso nunca terminó de gustarme. Aunque allí se pueden gestionar los contactos en grupos, su filosofía es la de intentar apartar al usuario de ellos. Al fin y al cabo, Mark Zuckerberg cree que a la sociedad actual no le importa la privacidad, que las costumbres sociales han cambiado radicalmente (para coincidir asombrosamente con las reglas de privacidad de su web). Naturalmente, no deja de haber verdad en que hoy en día la gente quiere compartir muchas cosas con todo el mundo, pero la lista de excepciones es como para parar un tren.
El simple hecho de que las meteduras de pata en Facebook con padres, jefes o parejas se hayan convertido en fuente de humor en Internet debería ser tomado como una prueba obvia -un reporte de bug- de que hay problemas en la concepción de Facebook, de que deberían intentar evitarse esos casos para que sólo puedan ocurrir por meteduras de pata gigantescas, y no por no haberte parado a preveer la opinión de cada uno de tus cientos de contactos, pero eso a Zuckerger no parece importarle. En cambio, la idea de Google+ parece aspirar a que uno pueda tener en sus contactos a sus familiares cercanos, a compañeros de trabajo, a gente aficionada a pornografía judía y a gente del partido nazi local, y gestionarlos todos en un perfil común con la confianza de que uno no meterá la pata tan fácilmente. Google+ está pensado para la doble vida.
Google+ tiene, además, funciones como Hangout y Huddle, magníficas ideas para gestionar relaciones sociales y que encajan perfectamente con el concepto de círculos. La respuesta de Facebook a esto ha sido añadir un soporte de Skype que sólo permite videoconferencia entre dos, mientas que los Hangouts de Google+ permiten videoconferencia entre 10 personas, muy cómodo para pequeños grupos de trabajo en una empresa o reuniones familiares virtuales.
Pero dejando de un lado el tema de la gestión de contactos, que al fin y al cabo probablemente sufrirá modificaciones en el futuro, detrás de Google+ hay una finalidad que es tan ambiciosa como la de rivalizar con Facebook, la de convertirse en el punto de integración de todos los servicios de Google. Hace mucho tiempo que llevan intentándolo sin éxito y parece que esta vez será la buena, la información interna que se conoce apunta en esa dirección, casi todos los servicios de Google podrían añadir funcionalidad para compartir datos o notificar de acciones a otros usuarios, por ejemplo, las actualizaciones de este blog podrían ser notificadas automáticamente en Google+ a los círculos que yo prefiera, o, mejor aun, a cualquier persona que decida seguirme en un círculo, sin preocuparme yo de añadirlo a mis círculos, estilo twitter, también podrían permitir crear círculos en los que los usuarios incluidos sólo envíen notificaciones de los servicios que yo escoja, como una especie de lector primitivo de RSS, o no tan primitivo si lo mejoran con el tiempo, todo se andará.
(PD: El abuso de comas de la última frase se debe a que ayer terminé un libro de Saramago, quien lo conozca seguro que me comprende...)
Pueden estar tranquilos, no voy a hablar sobre teoría de simetrías en las relaciones de redes sociales y en qué lado cae Google+, en parte porque no sé nada sobre el tema, y también porque otros ya lo han hecho. En general, los Círculos me parecen una buena idea. Se dice que esa manera de gestionar los contactos es más difícil de manejar que otras, pero esa afirmación sólo es cierta tomada como argumento técnico, desde el punto de vista de las relaciones sociales del mundo real los círculos son, en mi opinión, más intuitivos y comprensibles porque se corresponden con mayor fidelidad con la vida cotidiana.
Facebook desprecia ese punto de vista, y por eso nunca terminó de gustarme. Aunque allí se pueden gestionar los contactos en grupos, su filosofía es la de intentar apartar al usuario de ellos. Al fin y al cabo, Mark Zuckerberg cree que a la sociedad actual no le importa la privacidad, que las costumbres sociales han cambiado radicalmente (para coincidir asombrosamente con las reglas de privacidad de su web). Naturalmente, no deja de haber verdad en que hoy en día la gente quiere compartir muchas cosas con todo el mundo, pero la lista de excepciones es como para parar un tren.
El simple hecho de que las meteduras de pata en Facebook con padres, jefes o parejas se hayan convertido en fuente de humor en Internet debería ser tomado como una prueba obvia -un reporte de bug- de que hay problemas en la concepción de Facebook, de que deberían intentar evitarse esos casos para que sólo puedan ocurrir por meteduras de pata gigantescas, y no por no haberte parado a preveer la opinión de cada uno de tus cientos de contactos, pero eso a Zuckerger no parece importarle. En cambio, la idea de Google+ parece aspirar a que uno pueda tener en sus contactos a sus familiares cercanos, a compañeros de trabajo, a gente aficionada a pornografía judía y a gente del partido nazi local, y gestionarlos todos en un perfil común con la confianza de que uno no meterá la pata tan fácilmente. Google+ está pensado para la doble vida.
Google+ tiene, además, funciones como Hangout y Huddle, magníficas ideas para gestionar relaciones sociales y que encajan perfectamente con el concepto de círculos. La respuesta de Facebook a esto ha sido añadir un soporte de Skype que sólo permite videoconferencia entre dos, mientas que los Hangouts de Google+ permiten videoconferencia entre 10 personas, muy cómodo para pequeños grupos de trabajo en una empresa o reuniones familiares virtuales.
Pero dejando de un lado el tema de la gestión de contactos, que al fin y al cabo probablemente sufrirá modificaciones en el futuro, detrás de Google+ hay una finalidad que es tan ambiciosa como la de rivalizar con Facebook, la de convertirse en el punto de integración de todos los servicios de Google. Hace mucho tiempo que llevan intentándolo sin éxito y parece que esta vez será la buena, la información interna que se conoce apunta en esa dirección, casi todos los servicios de Google podrían añadir funcionalidad para compartir datos o notificar de acciones a otros usuarios, por ejemplo, las actualizaciones de este blog podrían ser notificadas automáticamente en Google+ a los círculos que yo prefiera, o, mejor aun, a cualquier persona que decida seguirme en un círculo, sin preocuparme yo de añadirlo a mis círculos, estilo twitter, también podrían permitir crear círculos en los que los usuarios incluidos sólo envíen notificaciones de los servicios que yo escoja, como una especie de lector primitivo de RSS, o no tan primitivo si lo mejoran con el tiempo, todo se andará.
(PD: El abuso de comas de la última frase se debe a que ayer terminé un libro de Saramago, quien lo conozca seguro que me comprende...)
4 de julio de 2011
OS X 10.7
Hace ya unas semanas que Apple dio rienda suelta al bombo y platillo sobre OS X 10.7, y hay un par de cosas interesantes que merece la pena comentar.
La primera de ellas, el Autosave, autoguardar. La idea en si -guardar automáticamente los cambios de los documentos mientras se editan- no es novedosa. Se ha importado de iOS, pero en el escritorio tampoco lo es: Office tiene autoguardar, vim hace mmap() de un archivo temporal cuando edita algo, lo cual garantiza que se sincroniza al disco periódicamente, Firefox guarda el contenido de los formularios a medio escribir, hay muchos juegos que también lo usan, el propio editor web de Blogger lo usa...no, no es una una idea que no conozcamos. Los más críticos de Apple señalarán que esto es puro marketing, venta de humo.
Esta manera de ver las cosas desdeña, sin embargo, el punto de vista del "framework". Como tantas cosas en Apple, la novedad no está en lo que hace, sino en cómo lo hace. Puede que la idea no sea nueva, pero sí lo es proporcionar en el SO APIs de primer nivel que permitan a los programadores añadir autoguardar con facilidad sin tener que reimplementarlo en cada aplicación, también lo es el hecho de ir guardando varias versiones antiguas del documento y tener una interfaz de usuario unificada para ver los cambios entre ellas o para "bloquear" futuras ediciones a un documento. Y el tan criticado marketing, combinado con el hecho de que las aplicaciones de Apple son las primeras en utilizar (y de ese modo publicitar) las nuevas APIs, hace que quienes programan para Mac se interesen por incorporar estas cosas a sus programas, con el resultado final de que el usuario se encuentra con una nueva característica muy bien integrada en todos los rincones del SO.
Otro tanto se puede decir de "Resume", que consiste en restaurar el estado del escritorio tras un reinicio tal como estaba antes de producirse. Creo recordar que Windows 9x hacía algo de esto, y como usuario de KDE puedo certificar que tengo la sesión por defecto pre-configurada para que, en cada inicio de sesión, me restaure en su escritorio virtual correspondiente, el conjunto de aplicaciones básico que suelo utilizar. Y en Fedora al menos, la configuración por defecto es que en cada inicio de sesión se restaure la anterior. Sin embargo, individualmente cada aplicación no restaura su estado: kmail no abre la carpeta en la que estaba, kaffeine no recuerda el vídeo que estaba viendo, akregator no recuerda la fuente que estaba leyendo...no deja de ser una restauración imperfecta.
En OS X 10.7, se ha refinado este aspecto hasta el punto de que se ha eliminado, al igual que en iOS, la barrera entre aplicación cerrada y aplicación minimizada - de hecho, el Dock ya no indicará (por defecto) si una aplicación está minimizada. Cuando la aplicación es capaz de guardar en todo momento su estado (incluso la posición del cursor y el texto seleccionado), es posible que al minimizar un editor de texto, el SO en realidad le cierre. Si el usuario intenta "desminimizar" el editor, basta con iniciarlo de cero y cargar al estado anterior (tener APIs que ayuden facilita mucho la adopción de estas cosas), y no hace falta mencionar que es posible reiniciar el equipo y recuperarlo tal como se había dejado hasta el último detalle.
Quien sabe, en un futuro podrían arriesgarse a ser más extremos y cerrar incluso aplicaciones abiertas que estén visibles, que no hayan sido utilizadas en un buen rato y no estén haciendo nada por si mismas: se podría mantener una copia de la imagen de la ventana, cerrar el programa, y si el usuario la vuelve a tocar reiniciar la aplicación...esta manera de gestionar las aplicaciones abiertas puede ser confusa al principio, pero es bastante más natural que tener que acordarte de guardar un determinado documento antes de apagar el ordenador. Y cerrar los programas que no se usan para liberar RAM para los que si se usan es una buena idea.
No hay muchas más cosas interesantes en esta versión, con la excepción de que esta versión se distribuirá online, a través de la App Store, y de los snapshots locales (apostaría a que no tienen nada que ver con ZFS ni con snapshots de volúmenes tradicionales, y que algo deben tener que ver con el mismo mecanismo que las versiones de Autosave - pero este post ya es demasiado largo)
La primera de ellas, el Autosave, autoguardar. La idea en si -guardar automáticamente los cambios de los documentos mientras se editan- no es novedosa. Se ha importado de iOS, pero en el escritorio tampoco lo es: Office tiene autoguardar, vim hace mmap() de un archivo temporal cuando edita algo, lo cual garantiza que se sincroniza al disco periódicamente, Firefox guarda el contenido de los formularios a medio escribir, hay muchos juegos que también lo usan, el propio editor web de Blogger lo usa...no, no es una una idea que no conozcamos. Los más críticos de Apple señalarán que esto es puro marketing, venta de humo.
Esta manera de ver las cosas desdeña, sin embargo, el punto de vista del "framework". Como tantas cosas en Apple, la novedad no está en lo que hace, sino en cómo lo hace. Puede que la idea no sea nueva, pero sí lo es proporcionar en el SO APIs de primer nivel que permitan a los programadores añadir autoguardar con facilidad sin tener que reimplementarlo en cada aplicación, también lo es el hecho de ir guardando varias versiones antiguas del documento y tener una interfaz de usuario unificada para ver los cambios entre ellas o para "bloquear" futuras ediciones a un documento. Y el tan criticado marketing, combinado con el hecho de que las aplicaciones de Apple son las primeras en utilizar (y de ese modo publicitar) las nuevas APIs, hace que quienes programan para Mac se interesen por incorporar estas cosas a sus programas, con el resultado final de que el usuario se encuentra con una nueva característica muy bien integrada en todos los rincones del SO.
Otro tanto se puede decir de "Resume", que consiste en restaurar el estado del escritorio tras un reinicio tal como estaba antes de producirse. Creo recordar que Windows 9x hacía algo de esto, y como usuario de KDE puedo certificar que tengo la sesión por defecto pre-configurada para que, en cada inicio de sesión, me restaure en su escritorio virtual correspondiente, el conjunto de aplicaciones básico que suelo utilizar. Y en Fedora al menos, la configuración por defecto es que en cada inicio de sesión se restaure la anterior. Sin embargo, individualmente cada aplicación no restaura su estado: kmail no abre la carpeta en la que estaba, kaffeine no recuerda el vídeo que estaba viendo, akregator no recuerda la fuente que estaba leyendo...no deja de ser una restauración imperfecta.
En OS X 10.7, se ha refinado este aspecto hasta el punto de que se ha eliminado, al igual que en iOS, la barrera entre aplicación cerrada y aplicación minimizada - de hecho, el Dock ya no indicará (por defecto) si una aplicación está minimizada. Cuando la aplicación es capaz de guardar en todo momento su estado (incluso la posición del cursor y el texto seleccionado), es posible que al minimizar un editor de texto, el SO en realidad le cierre. Si el usuario intenta "desminimizar" el editor, basta con iniciarlo de cero y cargar al estado anterior (tener APIs que ayuden facilita mucho la adopción de estas cosas), y no hace falta mencionar que es posible reiniciar el equipo y recuperarlo tal como se había dejado hasta el último detalle.
Quien sabe, en un futuro podrían arriesgarse a ser más extremos y cerrar incluso aplicaciones abiertas que estén visibles, que no hayan sido utilizadas en un buen rato y no estén haciendo nada por si mismas: se podría mantener una copia de la imagen de la ventana, cerrar el programa, y si el usuario la vuelve a tocar reiniciar la aplicación...esta manera de gestionar las aplicaciones abiertas puede ser confusa al principio, pero es bastante más natural que tener que acordarte de guardar un determinado documento antes de apagar el ordenador. Y cerrar los programas que no se usan para liberar RAM para los que si se usan es una buena idea.
No hay muchas más cosas interesantes en esta versión, con la excepción de que esta versión se distribuirá online, a través de la App Store, y de los snapshots locales (apostaría a que no tienen nada que ver con ZFS ni con snapshots de volúmenes tradicionales, y que algo deben tener que ver con el mismo mecanismo que las versiones de Autosave - pero este post ya es demasiado largo)
Suscribirse a:
Entradas (Atom)