Unas palabras de nuestra agencia de traducción: por lo general, todos buscan traducir los materiales y publicaciones más recientes, y nosotros no somos la excepción. Pero los terminales no son algo que se actualice cada semana. Por eso, hemos traducido para ustedes el artículo de Antoine Bopré, publicado en la primavera de 2018: a pesar de su "edad" considerable de acuerdo con los estándares actuales, en nuestra opinión, el material no ha perdido su relevancia. Además, en el original se trata de una serie de dos artículos, pero decidimos combinarlos en una gran publicación.
Los terminales ocupan un lugar especial en la historia de la computación, pero en las últimas décadas han tenido que "sobrevivir" junto a la línea de comandos en medio de la proliferación de interfaces gráficas. han reemplazado a sus , que a su vez eran una modificación de sistemas basados en tarjetas perforadas y conmutadores. Las distribuciones modernas vienen con una gran variedad de emuladores de terminal de diferentes formas y colores. Y mientras que muchos se conforman con el terminal estándar proporcionado por su entorno de trabajo, algunos utilizan con orgullo software claramente exótico para operar su shell o editor de texto favorito. Pero, como veremos en este artículo, no todos los terminales fueron creados de la misma manera: varían significativamente en funcionalidad, tamaño y rendimiento.
Algunos terminales tienen vulnerabilidades de seguridad sorprendentemente graves, además, la mayoría posee un conjunto de funciones completamente diferente, que va desde soporte para interfaces con pestañas hasta scripts. Aunque ya , este artículo es una actualización del material anterior que ayudará a los lectores a decidir qué terminal usar en 2018. En la primera mitad del artículo se comparan funciones, y en la segunda se evalúa el rendimiento.
Los terminales que he considerado son:
Quizás estas no sean las versiones más recientes, ya que me limité a las compilaciones estables en el momento de redactar el material, que pude implementar en Debian 9 o Fedora 27. La única excepción es Alacritty. Este es un descendiente de terminales con aceleración GPU y está escrito en un lenguaje inusual y nuevo para esta tarea: Rust. Excluí de mi revisión los terminales web (incluyendo, y en ), porque las pruebas preliminares mostraron su extremadamente bajo rendimiento.
Soporte de unicode
Comencé mis pruebas con el soporte de unicode. La primera prueba de los terminales fue mostrar una línea sobre unicode de : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 y 말». Esta prueba simple muestra si el terminal puede funcionar correctamente en todo el mundo. La terminal xterm no muestra el carácter árabe en la configuración por defecto:
Por defecto, xterm utiliza una clásica fuente «monoespaciada», que, según , tiene «una cobertura significativa de unicode desde 1997». En esta fuente, ocurre algo que provoca que el carácter se muestre como un marco vacío y solo al aumentar el tamaño de la fuente a 20+ puntos, el carácter finalmente comienza a mostrarse correctamente. Sin embargo, este «arreglo» rompe la visualización de otros caracteres unicode:
Estas capturas de pantalla se realizaron en Fedora 27, ya que esta brindó los mejores resultados en comparación con Debian 9, donde algunas versiones antiguas de terminales (específicamente - mlterm) no podían funcionar adecuadamente con las fuentes. Afortunadamente, esto se corrigió en versiones posteriores.
Ahora, observe la visualización de la línea en xterm. Resulta que el carácter Mem y el siguiente Semitic pertenecen a guiones de escritura RTL (), por lo que técnicamente deberían mostrarse de derecha a izquierda. Los navegadores web, como Firefox 57, manejan correctamente la línea anterior. Una variante más simple de texto RTL es la palabra «» en hebreo (). dice lo siguiente:
«Muchos programas informáticos no pueden representar correctamente el texto bidireccional. Por ejemplo, el nombre hebreo «Sara» está compuesto por los caracteres sin (ש) (que aparece a la derecha), luego resh (ר) y, finalmente, he (ה) (que debe aparecer a la izquierda)».
Muchos terminales no pasan esta prueba: Alacritty, los terminales derivados de VTE de Gnome y XFCE, urxvt, st y xterm muestran "Sara" al revés, como si escribiéramos este nombre como "Aras".
Otro problema de los textos bidireccionales es que deben alinearse de alguna manera, especialmente si se trata de la mezcla de textos RTL y LTR. Los scripts RTL deben comenzar desde el lado derecho de la ventana del terminal, pero ¿qué debe ocurrir con los terminales que, por defecto, funcionan con inglés LTR? La mayoría de ellos no tienen mecanismos especiales y alinean todo el texto a la izquierda (incluido Konsole). Las excepciones son pterm y mlterm, que cumplen con los estándares y alinean tales líneas a la derecha.
Protección contra pegado
La siguiente característica crítica que he identificado para mí es la protección contra pegado. Aunque es ampliamente conocido que hechizos como:
$ curl http://example.com/ | shson comandos push para ejecutar código, pocos saben que comandos ocultos pueden infiltrarse en la consola al copiar y pegar desde el navegador web, incluso después de una inspección minuciosa. muestra brillantemente cómo un comando que parece inofensivo:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitse convierte al pegarlo desde el sitio de Horn en el terminal en este desagradable resultado:
git clone /dev/null;
clear;
echo -n "Hola ";
whoami|tr -d 'n';
echo -e '!n¡Esa fue una mala idea! No copies código de sitios web en los que no confías!
Aquí está la primera línea de tu /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.git¿Cómo funciona esto? El código malicioso se ha extraído en un bloque , que se mueve fuera de la vista del usuario mediante CSS.
está diseñado precisamente para neutralizar tales ataques. En este modo, los terminales envuelven el texto que se está pegando en un par de secuencias de escape especiales para informar al shell sobre el origen de este texto. Así, el shell recibe la señal de que puede ignorar los caracteres especiales que puede contener el texto pegado. Todos los terminales, incluso el venerable xterm, admiten esta función, pero la inserción en modo bracketed necesita apoyo del shell o de la aplicación que se ejecuta en el terminal. Por ejemplo, el software que utiliza (el mismo Bash), necesita un archivo ~ /.inputrc:
set enable-bracketed-paste onDesafortunadamente, el sitio de prueba de Horn también muestra cómo eludir esta protección a través del formato de texto y finalizar prematuramente la aplicación del modo enmarcado. Esto funciona porque algunas terminales filtran incorrectamente las secuencias de escape antes de agregar las propias. Por ejemplo, en mis pruebas, no logré completar exitosamente las pruebas de Konsole, incluso considerando una configuración correcta. .inputrc del archivo. Esto significa que puedes dañar fácilmente la configuración del sistema debido a una aplicación no soportada o una shell mal configurada. Esto es especialmente peligroso al acceder a servidores remotos, donde el trabajo cuidadoso de configuración es menos común, especialmente si tienes muchas de estas máquinas remotas.
Una buena solución a este problema es un plugin de confirmación de inserción para terminales urxvt, que simplemente solicita permiso para insertar cualquier texto que contenga nuevas líneas. No encontré una opción más segura frente al ataque textual descrito por Horn.
Pestañas y perfiles
Una función popular en la actualidad es el soporte para interfaces de pestañas, que definiremos como una ventana de terminal que contiene múltiples terminales. Para diferentes terminales, esta función varía, y aunque los terminales tradicionales como xterm no soportan pestañas, las encarnaciones más modernas del terminal, como Xfce Terminal, GNOME Terminal y Konsole, sí la tienen. Urxvt también soporta pestañas, pero solo si se utiliza un plugin. Sin embargo, en términos de soporte de pestañas como tal, el líder indiscutible es Terminator: no solo soporta pestañas, sino que también puede organizar terminales en un orden arbitrario (ver imagen a continuación).
Otra característica de Terminator es la posibilidad de "agrupar" estas pestañas y enviar las mismas pulsaciones de teclas a múltiples terminales simultáneamente, lo que proporciona una herramienta básica para realizar operaciones masivas en varios servidores al mismo tiempo. Una función similar también está implementada en Konsole. Para usar esta función en otros terminales, es necesario utilizar software de terceros, como , o .
Las pestañas funcionan especialmente bien en conjunto con los perfiles: por ejemplo, puedes tener una pestaña para el correo electrónico, otra para el chat, y así sucesivamente. Esto está bien soportado por el terminal Konsole y el GNOME Terminal. Ambos permiten que cada pestaña ejecute automáticamente su propio perfil. Terminator también soporta perfiles, pero no pude encontrar una manera de iniciar automáticamente programas específicos al abrir una pestaña determinada. Otros terminales no tienen el concepto de "perfil" en absoluto.
Volantes
Lo último que consideraré en la primera parte de este artículo es el aspecto de los terminales. Por ejemplo, GNOME, Xfce y urxvt soportan transparencia, pero recientemente eliminaron el soporte para imágenes de fondo, lo que llevó a algunos usuarios a cambiar a otro terminal. . A mí personalmente me parece suficiente y simple. Xresources, que establece un conjunto básico de colores de fondo para urxvt. Sin embargo, los temas de color personalizados pueden crear problemas. Por ejemplo, con aplicaciones y , ya que ya utilizan sus propios colores.
no soportaba colores, y los nuevos a menudo estaban limitados a una paleta de 256 colores. Para los usuarios avanzados que estilizan sus terminales, las solicitudes de shell o las barras de estado de maneras complejas pueden ser una limitación molesta. rastrea qué terminales tienen soporte para "True Color". Mis pruebas confirman que st, Alacritty y los terminales basados en VTE soportan perfectamente True Color. Otros terminales se sienten bastante mal en este aspecto y de hecho no muestran ni siquiera 256 colores. A continuación puedes ver la diferencia entre el soporte de True Color en los terminales GNOME, st y xterm, que manejan bien esta tarea con su paleta de 256 colores, y urxvt, que no solo no pasa la prueba, sino que incluso muestra algunos caracteres parpadeantes en su lugar.
Algunos terminales también analizan el texto en busca de patrones de URL para hacer los enlaces clicables. Esto se aplica a todos los terminales derivados de VTE, mientras que urxvt requiere un módulo complementario específico que transforme las direcciones URL al hacer clic o mediante un atajo de teclado. Otros terminales que he probado muestran las URL de maneras diferentes.
Finalmente, la nueva tendencia en los terminales es la opcionalidad del búfer de desplazamiento. Por ejemplo, en st no hay búfer de desplazamiento; se supone que el usuario utilizará un multiplexor de terminal, como tmux y .
En Alacritty también faltan los búferes de desplazamiento inverso, pero su soporte debido a "amplios comentarios" al respecto por parte de los usuarios. Aparte de estas excepciones, cada terminal que he comprobado y que pude encontrar soporta el desplazamiento inverso.
Resultados intermedios
En la segunda parte del material (en el original eran dos artículos diferentes, — nota del traductor.) compararemos el rendimiento, el uso de memoria y la latencia. Pero ya vemos que algunos de los terminales analizados tienen serias desventajas. Por ejemplo, los usuarios que trabajan regularmente con guiones en RTL pueden prestar atención a mlterm y pterm, ya que se desenvuelven mejor que otros en estas tareas. Konsole también se ha desempeñado bien. Los usuarios que no trabajan con guiones en RTL pueden elegir otra opción.
Desde el punto de vista de la protección contra la inyección de código malicioso, urxvt se destaca por su implementación única de protección contra este tipo de ataques, que me parece ciertamente conveniente. Aquellos que buscan algunas características avanzadas deberían considerar Konsole. Por último, vale la pena mencionar que VTE es una excelente base para terminales, que garantiza soporte para colores, reconocimiento de URL, y más. A primera vista, el terminal predeterminado que viene con tu entorno favorito puede cumplir con todos los requisitos, pero dejaremos esa cuestión abierta hasta que aclaremos el rendimiento.
Continuamos la conversación
En general, la performance de los terminales puede parecer un problema exagerado, sin embargo, como se ha demostrado, algunos de ellos muestran retrasos sorprendentemente altos para un software de tan fundamental naturaleza. También más adelante examinaremos lo que tradicionalmente se llama "velocidad" (en realidad, se refiere a la velocidad de desplazamiento) y el consumo de memoria del terminal (teniendo en cuenta que hoy en día esto no es tan crítico como hace décadas).
Retraso
Después de una cuidadosa investigación sobre el rendimiento de los terminales, he llegado a la conclusión de que el parámetro más importante en este aspecto es el tamaño de la latencia (ping). En mi artículo Pavel Fatin examinó la latencia de diversos editores de texto y sugirió que en este aspecto, las terminales pueden funcionar más lentas que los editores de texto más rápidos. Esta sugerencia fue lo que, en última instancia, me llevó a realizar mis propias pruebas y a redactar este artículo.
Pero, ¿qué es la latencia y por qué es tan importante? En su artículo, Fatin la definió como «la latencia entre presionar una tecla y la correspondiente actualización de la pantalla» y citó , que dice: «La latencia en la retroalimentación visual en la pantalla del ordenador tiene un gran impacto en el comportamiento del mecanógrafo y su satisfacción».
Fatin explica que tal ping tiene consecuencias más profundas que simplemente la satisfacción: «escribir se vuelve más lento, se cometen más errores, aumenta la tensión en los ojos y los músculos». En otras palabras, una mayor latencia puede llevar a errores tipográficos y a una disminución en la calidad del código, ya que genera una carga cognitiva adicional en el cerebro. Pero lo que es aún peor, el ping «aumenta la tensión en los ojos y los músculos», lo que, aparentemente, implica en el futuro (aparentemente, el autor se refiere a problemas con los músculos oculares, la espalda, las manos y, por supuesto, la visión, — nota del traductor.) debido a la tensión repetitiva.
Algunos de estos efectos se conocen desde hace tiempo, y los resultados , publicados en 1976 en la revista Ergonomics, indican que una latencia de 100 milisegundos «empeora significativamente la velocidad de escritura». Muy recientemente, se ha añadido en la guía de usuario de GNOME de 10 milisegundos, y si se va más allá, demuestra que el ideal es 1 milisegundo.
Fatin llevó a cabo sus pruebas en editores de texto; creó una herramienta portátil llamada , que utilicé para verificar el ping en emuladores de terminal. Tenga en cuenta que la prueba se realizó en modo de simulación: en realidad, debemos considerar el retraso de entrada (teclado, controlador USB, etc.) y de salida (buffer de la tarjeta gráfica, monitor). Según Fatín, en configuraciones típicas es de alrededor de 20 ms. Con hardware para gamers, se puede alcanzar un valor de solo 3 milisegundos. Dado que ya tenemos ese hardware rápido, la aplicación no debe introducir su propio retraso. El objetivo de Fatín es reducir el retraso de la aplicación a 1 milisegundo, o incluso lograr una entrada sin , como en .
Aquí están los resultados de mis mediciones, así como algunos resultados de Fatín para mostrar que mi experimento coincide con sus pruebas:
Lo primero que me sorprendió fue el mejor tiempo de respuesta en programas antiguos como xterm y mlterm. Con el peor retraso de registro (2,4 ms), mostraron un resultado mejor que el terminal moderno más rápido (10,6 ms para st). Ningún terminal moderno baja del umbral de 10 milisegundos. En particular, Alacritty no cumple con los requisitos para ser "el más rápido de los emuladores de terminal existentes", aunque sus resultados mejoraron desde la primera verificación en 2017. De hecho, los autores del proyecto y están trabajando en mejorar la visualización. También es importante señalar que Vim, que utiliza GTK3, es considerablemente más lento que su contraparte de GTK2. De esto se puede concluir que GTK3 introduce un retraso adicional, y esto se refleja en todos los demás terminales que lo utilizan (Terminator, Xfce4 Terminal y GNOME Terminal).
Sin embargo, para el ojo, las diferencias pueden ser imperceptibles. Como explica Fatín: "no es necesario ser consciente del retraso para que tenga un efecto sobre usted". Fatín también advierte sobre la desviación estándar: "cualquier variación en la duración del retraso (temblor) crea una carga adicional debido a su impredecibilidad".
El gráfico anterior se obtuvo en Debian 9 puro (stretch) con . Este entorno proporciona los mejores resultados en pruebas de latencia. Como resultó, GNOME genera un ping adicional de 20 ms para todas las mediciones. Una posible explicación para esto es la presencia de programas con procesamiento síncrono de eventos de entrada. Fatin menciona como ejemplo para tal caso , que añade latencia al procesar todos los eventos de entrada de manera síncrona. Por defecto, GNOME también cuenta con un gestor de ventanas , que crea un nivel adicional de buffering, lo que influye en el ping y añade un mínimo de 8 milisegundos de latencia.
Velocidad de desplazamiento
La siguiente prueba es una verificación tradicional de «velocidad» o «ancho de banda», que mide qué tan rápido puede el terminal desplazarse por una página mostrando una gran cantidad de texto en la pantalla. La mecánica de la prueba varía; la prueba original consistía en generar simplemente la misma línea de texto utilizando el comando seq. Otras pruebas incluyen la verificación de Thomas E. Dick (acompañando a xterm), en la que se descarga repetidamente . En otra revisión del rendimiento de los terminales utiliza una cadena de bytes aleatorios en codificación base32, que se muestra en el terminal utilizando cat. Luu considera que esta prueba es «un banco de pruebas tan inútil como se puede imaginar» y sugiere utilizar en su lugar la respuesta del terminal como principal indicador. Dick también califica su prueba como engañosa. Sin embargo, ambos autores reconocen que el ancho de banda de la ventana del terminal puede ser un problema. Luu encontró un bloqueo de Emacs Eshell al mostrar archivos grandes, y Dick optimizó el terminal para eliminar la lentitud visual de xterm. Por lo tanto, todavía hay algo de razón en esta prueba, pero dado que el proceso de renderización varía mucho de un terminal a otro, también puede usarse como un componente de prueba para verificar otros parámetros.
Aquí vemos que rxvt y st se destacan frente a la competencia, seguido de Alacritty, que es mucho más nuevo y se desarrolla con un enfoque en el rendimiento. Luego vienen Xfce (familia VTE) y Konsole, que funcionan casi el doble de rápido. Por último, xterm tiene un rendimiento cinco veces más lento que rxvt. Durante la prueba, xterm también presentó mucho parpadeo, siendo difícil ver el texto que pasaba, incluso si era la misma línea. Konsole fue rápido, pero a veces "engañaba": la pantalla se congelaba intermitentemente, mostrando texto parcialmente o sin mostrarlo en absoluto. Otros terminales mostraron las líneas claramente, incluyendo st, Alacritty y rxvt.
Diki explica que las diferencias en rendimiento están relacionadas con el diseño de los búferes de desplazamiento en diferentes terminales. En particular, acusa a rxvt y otros terminales de "no seguir las reglas comunes":
"A diferencia de xterm, rxvt no intentaba mostrar todas las actualizaciones. Si se retrasa, omitirá algunas actualizaciones para ponerse al día. Esto tuvo un mayor impacto en la percepción de la velocidad de desplazamiento que en la organización de la memoria interna. Una desventaja fue que la animación ASCII era algo imprecisa."
Para corregir esta aparente lentitud de xterm, Diki sugiere utilizar el recurso , que permite a xterm descartar algunas actualizaciones de la pantalla para no quedarse atrás del flujo. Mis pruebas confirman que fastScroll mejora el rendimiento y lleva a xterm al mismo nivel que rxvt. Sin embargo, es un parche algo tosco, como explica Diki: "a veces xterm —al igual que konsole— parece detenerse, ya que espera un nuevo conjunto de actualizaciones de pantalla después de que se han eliminado algunas de ellas". En este sentido, parece que otros terminales han encontrado el mejor compromiso entre velocidad e integridad de la pantalla.
Consumo de recursos
Independientemente de la viabilidad de considerar la velocidad de desplazamiento como una medida de rendimiento, esta prueba permite simular la carga en los terminales, lo que a su vez nos permite medir otros parámetros, como el uso de memoria o disco. Las métricas se obtuvieron ejecutando la prueba mencionada seq bajo la supervisión de un proceso de Python. Recopiló datos de los contadores para ru_maxrss, la suma de ru_oublock y ru_inblock y un temporizador simple de tiempo.
En esta prueba, ST ocupa el primer lugar con el menor consumo promedio de memoria de 8 MB, lo cual no es sorprendente, ya que la idea principal del proyecto es la simplicidad. Un poco más consumen mlterm, xterm y rxvt, alrededor de 12 MB. Otro resultado notable es Alacritty, que requiere 30 MB para funcionar. Luego están los terminales de la familia VTE con un consumo de entre 40 y 60 MB, lo cual es bastante. Este tipo de consumo se puede explicar porque esos terminales utilizan bibliotecas de más alto nivel, como GTK. Konsole ocupa el último lugar con un consumo colosal de 65 MB de memoria durante las pruebas, aunque esto se puede justificar por su amplia gama de funciones.
En comparación con los resultados anteriores, obtenidos hace diez años, todos los programas han comenzado a consumir notablemente más memoria. Antes, Xterm requería 4 MB, y ahora 15 MB simplemente para iniciar. Un aumento similar en el consumo se observa en rxvt, que ahora requiere 16 MB por defecto. El terminal de Xfce ocupa 34 MB, lo que es tres veces más que antes, mientras que GNOME Terminal necesita solo 20 MB. Por supuesto, todas las pruebas anteriores se realizaron en una arquitectura de 32 bits. En LCA 2012, Rusty Russell , hay muchas razones más sutiles que pueden explicar el aumento del consumo de memoria. Dicho esto, ahora vivimos en una época en la que tenemos varios gigabytes de memoria, así que nos las arreglaremos de alguna manera.
Sin embargo, no puedo deshacerme de la sensación de que asignar más memoria a un software tan fundamental como un terminal es un desperdicio de recursos. Estos programas deberían ser los más ligeros de todos, deberían ser capaces de funcionar en cualquier "caja", incluso en una de zapatos, si alguna vez llegamos al punto de equiparlos con sistemas Linux (y saben que así será). Pero con estas cifras, el uso de memoria se convertirá en un problema en cualquier entorno al ejecutar varias terminales, excepto en situaciones con las más ligeras y limitadas en funciones. Para compensar esto, GNOME Terminal, Konsole, urxvt, Terminator y Xfce Terminal tienen un modo Daemon, que permite gestionar múltiples terminales a través de un solo proceso, lo que limita su consumo de memoria.
Durante mis pruebas, llegué a otro resultado inesperado respecto a la lectura y escritura en disco: esperaba no ver nada aquí, pero resultó que algunas terminales escriben los datos más pesados en el disco. Así, la biblioteca VTE de hecho mantiene un búfer de desplazamiento en el disco (esta característica , y esto sigue ocurriendo hasta hoy). Pero a diferencia de las viejas implementaciones, ahora, al menos, estos datos están cifrados con AES256 GCM (). Pero surge una pregunta razonable, ¿qué tiene de especial la biblioteca VTE que requiere un enfoque tan poco convencional para su implementación…?
Conclusión
En la primera parte del artículo descubrimos que las terminales basadas en VTE tienen un buen conjunto de características, pero ahora vemos que esto conlleva ciertos costos para garantizar su rendimiento. Ahora la memoria no es un problema, ya que todas las terminales VTE pueden ser gestionadas a través de un proceso Daemon, que limita su apetito. Sin embargo, los sistemas antiguos, que tienen limitaciones físicas en la cantidad de memoria RAM y búfer del núcleo, pueden todavía necesitar versiones anteriores de las terminales, ya que consumen significativamente menos recursos. Aunque las terminales VTE se han comportado bien en las pruebas de ancho de banda (desplazamiento), su latencia para mostrar datos en la pantalla supera el umbral establecido en la guía del usuario de GNOME. Probablemente, los desarrolladores de VTE deberían tener esto en cuenta. Dado que incluso para los nuevos usuarios de Linux el encuentro con la terminal es inevitable, podrían hacerla más amigable para el usuario. Para los geeks experimentados, cambiar de la terminal predeterminada puede incluso significar una reducción de la carga visual y la posibilidad de evitar lesiones y enfermedades profesionales en el futuro debido a largas sesiones de trabajo. Desafortunadamente, solo los viejos xterm y mlterm nos llevan al mágico umbral de ping de 10 milisegundos, lo cual es inaceptable para muchos.
Las mediciones de control también mostraron que, debido al desarrollo de entornos gráficos en Linux, los desarrolladores se vieron obligados a hacer varios compromisos. Algunos usuarios deberían considerar los gestores de ventanas tradicionales, ya que proporcionan una reducción significativa de la latencia. Desafortunadamente, no pude medir la latencia en Wayland: el programa Typometer que utilicé fue creado para lo que Wayland pretende prevenir: la vigilancia de otras ventanas. Espero que el rendimiento del compositador de Wayland sea mejor que el de X.org, y también espero que en el futuro alguien encuentre una manera de evaluar el nivel de latencia en este entorno.
Fuente: habr.com
