Algo más: ¿paquetes de aplicaciones Haiku?

TL; DR: ¿Puede Haiku obtener soporte adecuado para paquetes de aplicaciones, como directorios de aplicaciones (como .app en Mac) y/o imágenes de aplicaciones (Linux AppImage)? Creo que esta sería una adición valiosa que es más fácil de implementar correctamente que otros sistemas, ya que la mayor parte de la infraestructura ya está implementada.

Hace una semana Descubrí Haiku, un sistema inesperadamente bueno. Bueno, como hace tiempo que me interesan los directorios y las imágenes de aplicaciones (inspiradas en la sencillez del Macintosh), no es de extrañar que se me ocurriera una idea...

Para una comprensión completa, soy el creador y autor de AppImage, un formato de distribución de aplicaciones de Linux que apunta a la simplicidad de Mac y brinda control total a los autores de aplicaciones y usuarios finales (si desea saber más, consulte wiki и documentación).

¿Qué pasa si hacemos una AppImage para Haiku?

Pensemos un poco, puramente teóricamente: ¿qué hay que hacer para conseguir AppImage, o algo similar, en Haiku? No es necesario crear algo ahora mismo, porque el sistema que ya existe en Haiku funciona de maravilla, pero un experimento imaginario estaría bien. También demuestra la sofisticación de Haiku, en comparación con los entornos de escritorio Linux, donde esas cosas son terriblemente difíciles (tengo derecho a decirlo: he estado luchando con la depuración durante 10 años).

En Macintosh System 1, cada aplicación era un archivo independiente "administrado" en el Finder. Usando AppImage, intento recrear la misma experiencia de usuario en Linux.

En primer lugar, ¿qué es una AppImage? Este es un sistema para lanzar aplicaciones de terceros (por ejemplo, Cuidado de Ultimaker), permitiendo que las aplicaciones se publiquen cuando y como quieran: no hay necesidad de conocer los detalles de varias distribuciones, crear políticas o construir infraestructura, no se necesita soporte de mantenimiento y no les dicen a los usuarios qué (no) pueden instalar. en sus computadoras. AppImage debe entenderse como algo similar a un paquete de Mac en el formato .app dentro de la imagen del disco .dmg. La principal diferencia es que las aplicaciones no se copian, sino que permanecen dentro de AppImage para siempre, al igual que los paquetes Haiku. .hpkg montado, y nunca instalado en el sentido habitual.

A lo largo de más de 10 años de existencia, AppImage ha ganado cierto atractivo y popularidad: el propio Linus Torvalds la apoyó públicamente y proyectos comunes (por ejemplo, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) la adoptaron como el método principal. para distribuir compilaciones continuas o nocturnas, sin interferir con las aplicaciones de usuario instaladas o desinstaladas. Sin embargo, los entornos de escritorio y las distribuciones de Linux con mayor frecuencia todavía se aferran al modelo de distribución tradicional, centralizado y basado en mantenedores y/o promueven sus propios negocios empresariales y/o programas de ingeniería basados ​​en Flatpak (RedHat, Fedora, GNOME) y Rápido (Canónico, Ubuntu). Viene ridículamente.

Como funciona

• Cada AppImage contiene 2 partes: un pequeño ELF de doble clic (llamado. runtime.c), seguido de una imagen del sistema de archivos CalabazaFS.

• El sistema de archivos SquashFS contiene la carga útil de la aplicación y todo lo necesario para ejecutarla, lo que en su sano juicio no puede considerarse parte de la instalación predeterminada para todos los sistemas de destino relativamente recientes (distribución de Linux). También contiene metadatos, como el nombre de la aplicación, iconos, tipos MIME, etc., etc.

• Cuando lo ejecuta el usuario, el tiempo de ejecución usa FUSE y squashfuse para montar el sistema de archivos, y luego maneja la ejecución de algún punto de entrada (también conocido como AppRun) dentro de la AppImage montada.
  El sistema de archivos se desmonta una vez que se completa el proceso.

Parece que todo es simple.

Y estas cosas lo complican todo:

• Con tal variedad de distribuciones de Linux, nada que esté "en su sano juicio" puede considerarse "parte de la instalación predeterminada para cada nuevo sistema de destino". Solucionamos este problema construyendo lista de exclusión, lo que le permite determinar qué se empaquetará en AppImage y qué se deberá llevar a otro lugar. Al mismo tiempo, a veces fallamos, a pesar de que, en general, todo funciona muy bien. Por este motivo, recomendamos que los creadores de paquetes prueben AppImages en todos los sistemas de destino (distribuciones).
• Las cargas útiles de las aplicaciones deben poder reubicarse en todo el sistema de archivos. Desafortunadamente, muchas aplicaciones tienen rutas absolutas codificadas, por ejemplo, a recursos en /usr/share. Esto debe solucionarse de alguna manera. Además, debe exportar LD_LIBRARY_PATH, o arreglar rpath para que el cargador pueda encontrar bibliotecas relacionadas. El primer método tiene sus inconvenientes (que se superan de formas complejas) y el segundo es sencillamente engorroso.
• El mayor problema de UX para los usuarios es que establecer bit ejecutable Archivo AppImage después de la descarga. Lo creas o no, esto es una verdadera barrera para algunos. La necesidad de establecer el bit de ejecutabilidad es engorrosa incluso para usuarios experimentados. Como solución alternativa, sugerimos instalar un pequeño servicio que monitorea los archivos de AppImage y establece su bit de ejecutabilidad. En su forma pura, no es la mejor solución, ya que no funcionará de inmediato. Las distribuciones de Linux no brindan este servicio, por lo tanto, los usuarios tienen una mala experiencia desde el primer momento.
• Los usuarios de Linux esperan que una nueva aplicación tenga un ícono en el menú de inicio. No puedes decirle al sistema: “Mira, hay una nueva aplicación, trabajemos”. En cambio, de acuerdo con la especificación XDG, debe copiar el archivo .desktop al lugar correcto en /usr para una instalación de todo el sistema, o en $HOME para individuo. Los iconos de ciertos tamaños, según la especificación XDG, deben colocarse en ciertos lugares en usr o $HOMEy luego ejecute comandos en el entorno de trabajo para actualizar el caché de iconos, o espere que el administrador del entorno de trabajo lo resuelva y detecte todo automáticamente. Lo mismo con los tipos MIME. Como solución alternativa, se propone utilizar el mismo servicio que, además de configurar el indicador de ejecutabilidad, lo hará, si hay iconos, etc. en AppImage, cópielos desde AppImage a los lugares correctos según XDG. Cuando se elimina o se mueve, se espera que el servicio borre todo. Por supuesto, existen diferencias en el comportamiento de cada entorno de trabajo, en los formatos de archivos gráficos, sus tamaños, ubicaciones de almacenamiento y métodos de actualización de cachés, lo que crea un problema. En resumen, este método es una muleta.
• Si lo anterior no es suficiente, todavía no aparece el icono de AppImage en el administrador de archivos. El mundo Linux aún no se ha decidido a implementar elficon (a pesar de discusión и implementación), por lo que es imposible incrustar el icono directamente en la aplicación. Entonces resulta que las aplicaciones en el administrador de archivos no tienen sus propios íconos (no hay diferencia, AppImage u otra cosa), solo están en el menú de inicio. Como solución alternativa, utilizamos miniaturas, un mecanismo que fue diseñado originalmente para permitir a los administradores de escritorio mostrar imágenes de vista previa en miniatura de archivos gráficos como sus íconos. En consecuencia, el servicio para configurar el bit de ejecutabilidad también funciona como un "miniaturizador", creando y escribiendo miniaturas de iconos en las ubicaciones apropiadas. /usr и $HOME. Este servicio también realiza una limpieza si la AppImage se elimina o se mueve. Debido al hecho de que cada administrador de escritorio se comporta de manera ligeramente diferente, por ejemplo, en qué formatos acepta íconos, en qué tamaños o lugares, todo esto es realmente doloroso.
• La aplicación simplemente falla durante la ejecución si ocurren errores (por ejemplo, hay una biblioteca que no es parte del sistema base y no se proporciona en AppImage), y no hay nadie que le diga al usuario en la GUI qué está sucediendo exactamente. Empezamos a solucionar esto usando notificaciones en el escritorio, lo que significa que debemos detectar errores desde la línea de comando y convertirlos en mensajes comprensibles para el usuario, que luego deben mostrarse en el escritorio. Y, por supuesto, cada entorno de escritorio los maneja de manera un poco diferente.
• Por el momento (septiembre de 2019 - nota del traductor) no he encontrado una manera sencilla de decirle al sistema que el archivo 1.png debe abrirse usando Krita, y 2.png - usando GIMP.

Ubicación de almacenamiento para especificaciones entre escritorios utilizadas en GNOME, KDE и Xfce es freedesktop.org

Alcanzar el nivel de sofisticación profundamente arraigado en el ambiente de trabajo del Haiku es difícil, si no imposible, debido a las especificaciones. XDG de freedesktop.org para escritorio cruzado, así como implementaciones de administradores de escritorio basados ​​en estas especificaciones. Como ejemplo, podemos citar un icono de Firefox que se encuentra en todo el sistema: aparentemente, los autores de XDG ni siquiera pensaron que un usuario podría tener instaladas varias versiones de la misma aplicación.

Íconos para diferentes versiones de Firefox

Me preguntaba qué podría aprender el mundo Linux de Mac OS X para evitar arruinar la integración del sistema. Si tienes tiempo y te gusta esto, asegúrate de leer lo que dijo Arnaud Gurdol, uno de los primeros ingenieros de Mac OS X:

Queríamos que la instalación de la aplicación fuera tan fácil como arrastrar el ícono de la aplicación desde algún lugar (servidor, disco externo) al disco de su computadora. Para hacer esto, el paquete de la aplicación almacena toda la información, incluidos los íconos, la versión, el tipo de archivo que se está procesando y el tipo de esquemas de URL que el sistema necesita conocer para procesar la aplicación. Esto también incluye información para el 'almacenamiento central' en la base de datos de Icon Services y Launch Services. Para respaldar el rendimiento, las aplicaciones se "descubren" en varios lugares "conocidos": los directorios de aplicaciones del sistema y del usuario, y algunos otros automáticamente si el usuario navega hasta el Finder en el directorio que contiene la aplicación. En la práctica esto funcionó muy bien.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesión 144 - Mac OS X: empaquetado de aplicaciones e impresión de documentos.

No existe nada parecido a esta infraestructura en los escritorios Linux, por lo que estamos buscando soluciones alternativas a las limitaciones estructurales del proyecto AppImage.

¿Haiku viene al rescate?

Y una cosa más: las plataformas Linux como base de los entornos de escritorio tienden a estar tan poco especificadas que muchas cosas que son bastante simples en un sistema full-stack consistente resultan frustrantemente fragmentadas y complejas en Linux. Dediqué un informe completo a cuestiones relacionadas con la plataforma Linux para entornos de escritorio (desarrolladores expertos confirmaron que todo seguirá así durante mucho tiempo).

Mi informe sobre los problemas de los entornos de escritorio Linux en 2018

Incluso Linus Torvalds admitió que la fragmentación fue la razón por la que fracasó la idea del espacio de trabajo.

¡Qué bueno ver Haikus!

Haiku hace que todo sea increíblemente simple

Si bien el enfoque ingenuo para "portar" AppImage a Haiku es simplemente intentar construir (principalmente runtime.cy service) sus componentes (¡lo cual incluso puede ser posible!), esto no proporcionará muchos beneficios a Haiku. Porque, de hecho, la mayoría de estos problemas se resuelven en Haiku y son conceptualmente sólidos. Haiku proporciona exactamente los componentes básicos de la infraestructura del sistema que he estado buscando en los entornos de escritorio Linux durante tanto tiempo y no podía creer que no estuvieran ahí. A saber:

Lo creas o no, esto es algo que muchos usuarios de Linux no pueden superar. ¡En Haiku todo se hace automáticamente!

• Los archivos ELF que no tienen un bit de ejecutabilidad obtienen uno automáticamente cuando se hace doble clic en el administrador de archivos.
• Las aplicaciones pueden tener recursos integrados, como iconos, que se muestran en el administrador de archivos. No es necesario copiar un montón de imágenes en directorios especiales con íconos y, por lo tanto, no es necesario limpiarlas después de eliminar o mover la aplicación.
• Existe una base de datos para vincular aplicaciones con documentos, no es necesario copiar ningún archivo para ello.
• En el directorio lib/ junto al archivo ejecutable, se buscan bibliotecas de forma predeterminada.
• No existen numerosas distribuciones y entornos de escritorio; lo que funciona, funciona en todas partes.
• No hay ningún módulo separado para ejecutar que sea diferente del directorio de Aplicaciones.
• Las aplicaciones no tienen rutas absolutas integradas a sus recursos; tienen funciones especiales para determinar la ubicación en tiempo de ejecución.
• Se ha introducido la idea de imágenes comprimidas del sistema de archivos: este es cualquier paquete hpkg. Todos ellos están montados por el kernel.
• Cada archivo lo abre la aplicación que lo creó, a menos que especifique explícitamente lo contrario. ¡Qué genial es esto!

Dos archivos png. Tenga en cuenta los diferentes iconos que indican que serán abiertos por diferentes aplicaciones al hacer doble clic. También tenga en cuenta el menú desplegable "Abrir con:" donde el usuario puede seleccionar una aplicación individual. ¡Qué sencillo!

Parece que muchas de las muletas y soluciones alternativas requeridas por AppImage en Linux se vuelven innecesarias en Haiku, que tiene la simplicidad y la sofisticación en su núcleo que le permite manejar la mayoría de nuestras necesidades.

¿Haiku necesita paquetes de aplicaciones después de todo?

Esto lleva a una gran pregunta. Si fuera mucho más fácil crear un sistema como AppImage en Haiku que en Linux, ¿valdría la pena hacerlo? ¿O Haiku, con su sistema de paquete hpkg, ha eliminado efectivamente la necesidad de desarrollar tal idea? Bueno, para responder debemos analizar la motivación detrás de la existencia de AppImages.

La perspectiva del usuario

Miremos a nuestro usuario final:

• Quiero instalar una aplicación sin pedir una contraseña de administrador (root). No existe el concepto de administrador en Haiku, ¡el usuario tiene control total ya que es un sistema personal! (En principio, puedes imaginar esto en modo multijugador, espero que los desarrolladores lo mantengan simple)
• Quiero obtener las últimas y mejores versiones de las aplicaciones, sin esperar a que aparezcan en mi distribución (la mayoría de las veces esto significa "nunca", al menos a menos que actualice todo el sistema operativo). En Haiku esto se "resuelve" con lanzamientos flotantes. Esto significa que es posible obtener las últimas y mejores versiones de las aplicaciones, pero para ello es necesario actualizar constantemente el resto del sistema, convirtiéndolo efectivamente en un "objetivo en movimiento"..
• Quiero varias versiones de la misma aplicación una al lado de la otra, ya que no hay forma de saber qué se rompió en la última versión o, digamos, yo, como desarrollador web, necesito probar mi trabajo en diferentes versiones del navegador. Haiku resuelve el primer problema, pero no el segundo. Las actualizaciones se revierten, pero solo para todo el sistema, es imposible (hasta donde yo sé) ejecutar, por ejemplo, varias versiones de WebPositive o LibreOffice al mismo tiempo.

Uno de los desarrolladores escribe:

Básicamente, el razonamiento es el siguiente: el caso de uso es tan raro que optimizarlo no tiene sentido; tratarlo como un caso especial en HaikuPorts parece más que aceptable.

• Necesito mantener las aplicaciones donde me gustan, no en mi disco de inicio. A menudo me quedo sin espacio en disco, por lo que necesito conectar una unidad externa o un directorio de red para almacenar aplicaciones (todas las versiones que he descargado). Si conecto una unidad de este tipo, necesito que las aplicaciones se inicien haciendo doble clic. Haiku guarda versiones antiguas de paquetes, pero no sé cómo moverlas a una unidad externa ni cómo iniciar aplicaciones desde allí más adelante.

Comentario del desarrollador:

Técnicamente, esto ya es posible con el comando mount. Por supuesto, crearemos una GUI para esto tan pronto como tengamos suficientes usuarios interesados.

• No necesito millones de archivos dispersos por el sistema de archivos que no puedo administrar manualmente. Quiero un archivo por aplicación que pueda descargar, mover y eliminar fácilmente. En Haiku este problema se resuelve usando paquetes. .hpkg, que transfieren, por ejemplo, Python, de miles de archivos a uno solo. Pero si, por ejemplo, Scribus usa Python, entonces tengo que manejar al menos dos archivos. Y tengo que tener cuidado de mantener versiones de ellos que funcionen entre sí.

Varias versiones de AppImages ejecutándose una al lado de la otra en el mismo Linux

La perspectiva de un desarrollador de aplicaciones

Miremos desde el punto de vista de un desarrollador de aplicaciones:

• Quiero controlar toda la experiencia del usuario. No quiero depender de un sistema operativo que me diga cuándo y cómo debo lanzar aplicaciones. Haiku permite a los desarrolladores trabajar con sus propios repositorios hpkg, pero esto significa que los usuarios tendrán que configurarlos manualmente, lo que hace que la idea sea "menos atractiva".
• Tengo una página de descarga en mi sitio web donde distribuyo .exe para ventanas, .dmg para Mac y .AppImage para Linux. O tal vez quiero monetizar el acceso a esta página, ¿todo es posible? ¿Qué debo poner ahí para el Haiku? El archivo es suficiente .hpkg con dependencias solo de HaikuPorts
• Mi software requiere versiones específicas de otro software. Por ejemplo, se sabe que Krita requiere una versión parcheada de Qt, o Qt que esté ajustado a una versión específica de Krita, al menos hasta que los parches se vuelvan a introducir en Qt. Puede empaquetar su propio Qt para su aplicación en un paquete .hpkg, pero lo más probable es que esto no sea bienvenido.

Página de descarga de aplicaciones normal. ¿Qué debería publicar aquí para Haiku?

Los paquetes (que existen como directorios de aplicaciones como AppDir o .app al estilo Apple) y/o imágenes (en forma de AppImages o imágenes de aplicaciones muy modificadas). .dmg de Apple) ¿una adición útil al entorno de escritorio Haiku? ¿O diluirá todo el panorama y conducirá a la fragmentación y, por tanto, añadirá complejidad? Estoy dividido: por un lado, la belleza y sofisticación del Haiku se basa en el hecho de que normalmente hay una manera de hacer algo, en lugar de muchas. Por otro lado, la mayor parte de la infraestructura para catálogos y/o conjuntos de aplicaciones ya está implementada, por lo que el sistema pide a gritos que el porcentaje restante esté listo.

Según el desarrollador señor. chapoteo

En Linux ellos (catálogos y kits de aplicación, - aprox. traductor) son muy probablemente una solución técnica a problemas sistémicos. En Haiku preferimos resolver simplemente los problemas del sistema.

Que piensas

Antes de responder...

Espera, hagamos una rápida comprobación de la realidad: de hecho directorios de aplicaciones - ya forma parte del Haiku:

Los directorios de aplicaciones ya existen en Haiku, pero aún no son compatibles con el administrador de archivos.

Simplemente no tienen tan buen soporte como, digamos, el Macintosh Finder. ¿Qué tan genial sería si el directorio QtCreator tuviera un nombre y un ícono "QtCreator" en la esquina superior izquierda, iniciando la aplicación al hacer doble clic?

Un poquito antes ya preguntado:

¿Está seguro de que puede ejecutar sus aplicaciones de hace una década hoy, cuando todas las tiendas de aplicaciones y repositorios de distribución se han olvidado de ellas y de sus dependencias? ¿Está seguro de que aún podrá acceder a su trabajo actual en el futuro?

¿Existe ya una respuesta de Haiku o los catálogos y los paquetes de aplicaciones pueden ayudar aquí? Creo que pueden.

Según el sr. chapoteo:

Sí, tenemos la respuesta a la pregunta: simplemente daremos soporte a estas aplicaciones durante el tiempo que sea necesario hasta que alguien pueda leer sus formatos de archivo de la manera correcta o proporcionar funcionalidad personalizada. Nuestro compromiso de soportar aplicaciones BeOS R5 en Haiku es prueba de ello...

Eso es correcto!

¿Qué curso de acción debería tomar el Haiku?

Puedo imaginar la coexistencia pacífica de hpkg, directorios e imágenes de aplicaciones:

• Usos del software del sistema .hpkg
• Para el software utilizado con más frecuencia (especialmente aquellos que necesitan programar lanzamientos continuos), utilice .hpkg (aproximadamente el 80% de todos los casos)
• Algunos instalados a través de .hpkg, las aplicaciones se beneficiarán al pasar a una infraestructura de directorio de aplicaciones (por ejemplo, QtCreator): se distribuirán como .hpkg, como antes.

señor. waddlesplash escribe:

Si todo lo que necesita es ver aplicaciones en /system/apps, en su lugar deberíamos hacer que los directorios en Deskbar sean más manejables para los usuarios, ya que /system/apps no está diseñado para que los usuarios lo abran y vean periódicamente (a diferencia de MacOS). Para tales situaciones, Haiku tiene un paradigma diferente, pero esta opción es, en teoría, aceptable.

• Haiku recibe la infraestructura para ejecutar imágenes de aplicaciones, compilaciones de software nocturnas, continuas y de prueba, así como para los casos en los que el usuario quiere "congelarlo en el tiempo", para software privado e interno, y otros casos de uso especiales (alrededor del 20% de todo). Estas imágenes contienen los archivos necesarios para ejecutar la aplicación. .hpkg, montado por el sistema y, una vez completada la aplicación, desmontado. (Quizás un administrador de archivos podría poner archivos .hpkg en imágenes de aplicaciones, automáticamente o a petición del usuario, bueno, como cuando arrastra una aplicación a un directorio de red o a una unidad externa. ¡Es solo una canción! O más bien poesía: haiku). Por otro lado, es posible que el usuario desee instalar el contenido de la imagen en forma de archivos..hpkg, después de lo cual se actualizarán y procesarán de la misma manera que si se instalaran a través de HaikuDepot... Necesitamos una lluvia de ideas).

Cita del sr. chapoteo:

Ejecutar aplicaciones desde unidades externas o directorios de red puede resultar útil. Y agregar la capacidad de configurar más "zonas" para pkgman definitivamente sería una buena característica.

Un sistema de este tipo aprovecharía hpkg, directorios e imágenes de aplicaciones. Son buenos individualmente, pero juntos se volverán invencibles.

Conclusión

Haiku tiene un marco que proporciona una experiencia de usuario simple y sofisticada para la PC, y va mucho más allá de lo que normalmente se proporciona para la PC con Linux. Sistema de paquetes .hpkg es un ejemplo de ello, pero el resto del sistema también está imbuido de sofisticación. Sin embargo, Haiku se beneficiaría de un soporte adecuado para directorios e imágenes de aplicaciones. Vale la pena discutir la mejor manera de hacerlo con personas que conocen el Haiku, su filosofía y arquitectura mucho mejor que yo. Después de todo, llevo poco más de una semana usando Haiku. Sin embargo, creo que los diseñadores, desarrolladores y arquitectos de Haiku se beneficiarán de esta nueva perspectiva. Como mínimo, estaría feliz de ser su “compañero de entrenamiento”. Tengo más de 10 años de experiencia práctica con catálogos y paquetes de aplicaciones de Linux, y me gustaría encontrarles un uso en Haiku, para lo cual creo que encajan perfectamente. Las posibles soluciones que he propuesto no son de ninguna manera las únicas correctas para los problemas que he descrito, y si el equipo de Haiku decide encontrar otras más elegantes, estoy totalmente a favor. Básicamente ya estoy pensando en la idea de cómo hacer un sistema. hpkg aún más sorprendente sin cambiar la forma en que funciona. Resulta que el equipo de Haiku había estado pensando en paquetes de aplicaciones durante mucho tiempo al implementar un sistema de gestión de paquetes, pero desafortunadamente (creo) la idea quedó "obsoleta". ¿Quizás es hora de revivirlo?

¡Inténtalo tú mismo! Después de todo, el proyecto Haiku proporciona imágenes para arrancar desde DVD o USB, generadas diario.
¿Tiene usted alguna pregunta? Te invitamos a los de habla rusa. canal de telegramas.

Resumen de errores: Cómo pegarse un tiro en el pie en C y C++. Colección de recetas de Haiku OS

De автора traducción: este es el octavo y último artículo de la serie sobre Haiku.

Lista de artículos: primero El segundo Третья Cuarto quinto Sexto Séptimo

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Tiene sentido portar el sistema hpkg a Linux?

• Sí

• No

• Ya implementado, lo escribiré en los comentarios.

20 usuarios votaron. 5 usuarios se abstuvieron.

Fuente: habr.com