Por el blog te traigo una traducción que he realizado a una entrevista realizada a Bram Moolenaar el desarrollador que creó y mantiene el editor Vim

Hace un par de días encontré una entrevista a Bram Moolenar el desarrollador holandés que creó Vim (Vi mejorado) y que todavía mantiene y se encarga de gestionar las nuevas actualizaciones de este gran editor.

La entrevista está en inglés y publicada en la web evrone.com el pasado 14 de enero de 2022. Puedes leer la entrevista original escrita en inglés en este enlace:

• https://evrone.com/bram-moolenaar-interview

Les pedí permiso para traducir la entrevista y publicarla en mi blog y amablemente me dieron permiso. Así que aquí la tenéis para que la disfrutéis.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Y para aprender Vim (de la manera más inteligente) aquí tienes esta útil guía:

• https://victorhck.gitbook.io/aprende-vim/

Evrone: Mirando atrás en el tiempo, ¿qué significó para ti personalmente trabajar en Vim?

Bram: Un montón. Siempre me ha gustado crear cosas, pero muy a menudo, cuando algo ya está terminado, me pregunto qué hacer con él. Con Vim no solo puedo usarlo yo mismo, sino que al ponerlo a disposición del público muchas personas pueden disfrutarlo. Ha dado a conocer mi nombre en el mundo e indirectamente me consiguió un trabajo. En estos días, ahora que estoy jubilado, me da algo interesante, alegre y útil que hacer. Vim es una parte muy importante de mi vida.

Evrone: En tu opinión, ¿el desarrollo de software está más cerca del arte o de la ciencia? ¿Permite desviaciones de las técnicas tradicionales o hay que seguir estrictamente la dirección principal?

Bram: No veo mucha ciencia en el desarrollo de software. La ciencia implica que hay pruebas de que algo es cierto. En software hay muchas opiniones y hay experiencia, pero ¿hay alguna prueba de que un lenguaje de programación sea mejor que otro? ¿Hay pruebas de que la programación orientada a objetos resulte en una mejor productividad?

La mayoría de las pruebas son sobre medidas de rendimiento, y hay estadísticas, pero casi ninguna relación con el lenguaje en el que se escribió un programa o las herramientas que se usaron. Tampoco es arte, ya que el objetivo principal es que el software funcione bien, no que se vea bien.

Es mucho más una artesanía. Y un artesano usa las herramientas que cree que obtendrán el mejor resultado, sin importar si son las que usan los demás o algo diferente. Y un buen artesano fabrica sus propias herramientas cuando es necesario.

Evrone: Al abrir Vim, no podemos dejar de tener presente tu llamada para ayudar a los niños que viven en Uganda. ¿Cómo se le ocurrió esta idea de licenciar Vim usando los modelos de licencia Careware/Charityware y cuántas personas pueden hacer donaciones de esta manera?

Bram: Nunca he querido ganar dinero con Vim. Comenzó como un pasatiempo y la mayor parte del tiempo tenía un trabajo que pagaba bastante bien. Excepto por algunos años durante los cuales pedí donaciones.

Aún así, bastantes personas dijeron que pensaban que Vim valía algo y que se vendían otros editores. Así que decidí combinar mi deseo de ayudar a los niños pobres con eso y nació Charityware.

Funciona bien, se recaudan unos 30.000 euros al año de esta manera, lo que está ayudando a unos 50 niños a terminar su educación, desde la escuela primaria hasta la universidad. Las donaciones provienen de algunos grandes patrocinadores y muchas donaciones pequeñas.

Evrone: A pesar de toda su flexibilidad y funcionalidad, Vim no es un editor intuitivo, la curva de aprendizaje es bastante alta. Si alguien quiere usar Vim de manera efectiva, debe dedicar bastante tiempo a aprender los comandos de control. ¿Cuál fue el motivo por el que optó por este camino en lugar de introducir un modo «apto para principiantes» con un aumento gradual de la complejidad?

Bram: En realidad, hay un modo poco conocido en el que uno puede escribir sin conocer todos los comandos. Esto se llama «Easy Vim», o evim. Pero supongo que no se usa mucho, porque una vez que escuchas sobre Vim y todos los poderosos comandos, ¿por qué usarías un modo que lo hace funcionar como cualquier otro editor?

Obviamente, Vim es, al igual que Vi, algo que debes aprender a usar. Para mí, estaba más o menos obligado, cuando una clase práctica en la universidad tenía solo una computadora específica disponible y el único editor en él era vi.

Después de quejarnos a los profesores, su solución fue darnos una hoja de trucos de una página… Sin este aprendizaje forzado, es posible que nunca hubiera dado el salto para aprender a usar Vi, y el curso de la historia hubiera sido muy diferente.

Evrone: En los últimos años, hemos visto a los desarrolladores preguntar «¿me ayudará el código de alguien a resolver mi tarea actual?», en lugar de escribir su propio código desde cero. Como resultado, algunas aplicaciones cumplen con los estrictos plazos dictados por las empresas, pero se parecen a Frankenstein. Desde su punto de vista, ¿es aceptable tal enfoque?

Bram: Esto suele suceder cuando se ordena que el software sea creado por personas que no tienen conocimiento del software. He estado trabajando para una empresa donde bastantes gerentes, educados en física y mecánica, pensaban que el software era igual al que conocían y que podían decidir cómo hacerlo. Esa empresa fue cuesta abajo y finalmente fue absorbida.

Lo mismo sucede en lugares donde los tomadores de decisiones pueden salirse con la suya, como en el gobierno. Las personas que escriben el código probablemente solo se aseguran de que les paguen y luego huyen de la escena del crimen. En el otro extremo de la escala están las personas que quieren escribir un código hermoso, dedican mucho tiempo a él y no les importa si realmente hace lo que se pretendía que hiciera o cuál era el presupuesto. En algún punto intermedio, hay un equilibrio.

Evrone: Hace dos años, se anunció un «fork» experimental de Vim9. ¿Podrías contarnos un poco más sobre este «fork»? ¿Cuál es la etapa actual de este proyecto?

Bram: Vim9 no es un «fork», sino el siguiente paso para mejorar Vim. Primero hice un experimento para ver si compilar una función en un código de bytes funcionaría para hacer que el script de Vim fuera mucho más rápido. Resultó que funcionó bien, pero requirió hacer cambios en la sintaxis. Esa no es una elección fácil, admitir dos variantes de un lenguaje de script al mismo tiempo, pero creo que funcionará y hará felices a los escritores de complementos.

La sintaxis heredada permanecerá, por lo que no debería llamarse «fork». No espero que todos los scripts antiguos de Vim se reescriban en la nueva sintaxis, por lo que seguiremos admitiendo la sintaxis heredada. Incluso Python tardó mucho, mucho tiempo en convertir el 99% del código de Python en Python 3. Y ese 1% restante sigue ahí…

Evrone: Siempre es difícil mantener la compatibilidad con versiones anteriores porque muchas funciones no se pueden implementar sin romperse. ¿Se apegará Vim9 a sus principios de compatibilidad con versiones anteriores o abrirá una nueva página en la historia de Vim?

Bram: El script Vim9 no es compatible con versiones anteriores, pero la sintaxis del script heredado también está disponible. Uno puede decidir para cada archivo y cada función qué sintaxis usar. De esta manera tenemos la libertad de hacer que el script de Vim9 funcione mucho mejor.

Aún así, las dos variantes de secuencias de comandos de Vim están lo suficientemente cerca como para que uno pueda escribir cualquiera de ellas. He tenido cuidado de asegurarme de que cuando se comete una equivocación se proporcione un error para ayudar al usuario a solucionarlo rápidamente.

Evrone: El IRC se especifica como el canal de la comunidad en el sitio web oficial de Vim. No es tan popular hoy en día y algunos de los usuarios más jóvenes nunca han oído hablar de él. ¿Planeas cambiarte a Slack o Discord algún día para darle un mayor impacto a Vim de esta manera?

Bram: Soy muy anticuado, mi principal medio de comunicación es el correo electrónico. No es solo que esto es a lo que estoy acostumbrado, sino también porque no es disruptivo mientras trabajas.

Puedo leer y responder mensajes cuando quiero y posponerlos cuando no quiero que me interrumpan. Por supuesto, los usuarios son libres de elegir lo que funcione para ellos, otros pueden organizarlo. Sin embargo, la comunicación tipo chat tiende a ser muy ruidosa.

Evrone: Usando muchos manuales web, podemos descubrir excelentes complementos para ampliar la increíble funcionalidad de Vim. ¿Tiene algún complemento favorito y imprescindible que pueda recomendar a nuestra audiencia?

Bram: Debo admitir que no uso muchos complementos, aparte de los que se incluyen con la distribución (como matchit y termdebug). Cuando necesito algo, tiendo a hacer un truco rápido o agregarlo a la base de Vim. Ese es el lujo de ser el creador :-).

Evrone: Teniendo en cuenta su amplia experiencia, ¿podría compartir algún truco para los desarrolladores sobre cómo mantener la productividad a lo largo de los años? ¡Gracias!

Bram: Sin trucos, solo algunas reglas básicas y consejos. Una cosa que he visto hacer a los jóvenes es trabajar hasta muy tarde y luego terminar tarde a la mañana siguiente. La mayoría de las personas tienen su momento más productivo en la mañana, por lo tanto, es mucho mejor establecer un límite de tiempo estricto para detenerse.

Toma nota de dónde te quedaste, luego relájate un poco, duerme bien y continúa a la mañana siguiente. Muy a menudo, el problema con el que estabas atrapado ayer de repente adquiere una nueva perspectiva y sabes qué hacer. El término «dormir en él» realmente funciona, al menos lo hace para mí.

Otra cosa es que, a veces, lo que necesitas no es una solución inteligente o un ajuste interminable de su configuración, sino simplemente escribir rápido. La grabación y repetición de macros en Vim suele ser lo suficientemente buena como para hacer algo 200 veces. ¿Cuánto tiempo necesitarías para escribir un complemento para eso?

Hasta aquí la traducción que he realizado de la entrevista a Bram Moolinaar publicada en inglés en la web evrone.com. Espero que te haya resultado interesante, a mí me interesó y por eso quise publicarla en el blog. Gracias a la web evrone.com por permitirme publicar esta traducción.

Hay partes que me ha costado traducir y mantener el significado original, espero que sepas perdonar si no me ha quedado del todo correcta. Puedes aportar tus sugerencias en los comentarios.

Bienvenidos a una entrada que creo que es muy interesante, y más en estos tiempos donde cada día es más frecuente realizar trámites burocráticos de forma telemática. Se trata de compartir con vosotros un vídeo donde nos enseñan cómo firmar con Okular de forma rápida y sencilla, que aunque no sea una firma digital puede ser una opción en determinados casos.

Cómo firmar con Okular, el visor de pdf de KDE

La idea es sencilla, utilizar las herramientas gráficas que incluye Okular para poder poner nuestra firma (o garabato) en un documento pdf.

El vídeo ha sido realizado por el canal de Youtube Techview Podcast y dura apenas 5 minutos, y en él nos muestran dos formas de hacerlo: o bien directamente sobre el pdf o bien crear nuestra firma con Gimp y subirla como si fuera un sello a Okular.

Si os ha gustado el truco no olvidéis compartirlo y darle un «me gusta», estas cosas siempre ayuda en el desarrollo del Software Libre.

Listado de los trucos

Aunque en realidad este truco no está realizado por la cuenta de Youtube de KDE Commnity creo que es un buen momento para comentar que también esta cuenta ofrece trucos y que casi todos ellos han sido comentados en el blog.

De hecho ya hemos superado la decena de trucos que la Comunidad KDE y está bien tener un listado de los consejos que hemos promocionado en este espacio de notocias.

• Trucos KDE (I): KDE Connect y Konsole
• Trucos KDE (II): cambiar fondo de pantalla y subir imágenes
• Trucos KDE (III): gráficas con Krunner y encontrando ventanas
• Trucos KDE (IV): abrir archivos desde consola y mix de efectos
• Trucos KDE (V): cambiando el tamaño de las ventanas
• Trucos KDE (VI): configurando plasmoides
• Trucos KDE (VII): guardando notas en el escritorio
• Trucos KDE (VIII): filtrando en Dolphin
• Trucos KDE (IX): creando anotaciones en Okular
• Trucos KDE (10): controlando el volumen de forma alternativa
• Trucos KDE (11): optimizar ventanas con el teclado

PT. Aktiva Kreasi Investama, sebuah perusahaan layanan cloud SaaS (Software as a Services) membutuhkan beberapa kandidat dibidang teknis untuk pengembangan usaha, yang meliputi :

• Staff IT Support
• Front-End Developer
• Back-End Developer
• Intern UI/UX Designer

Kesemua posisi untuk penempatan on site di Bekasi.

Untuk detail persyaratan dan mekanisme penerimaan, silakan merujuk pada flyer berikut :

As you may know, YaST is not only a control center for (open)SUSE Linux distributions, but it is also the installer. And, in that regard, we think it is a competent installer. However, time goes by, and YaST shows its age in a few aspects.

During summer 2021, the team discussed how YaST should look in the near future. We considered many ideas, but let's focus on these:

• Shortening the installation process.
• Decoupling the user interface from YaST internals.
• Adding a web-based interface. We had WebYaST in the past, but it was not meant to work as installer.

We played around with these ideas (e.g., see $INSTALLER:80 and making openSUSE installer shorter), but we never had a concrete plan.

Fast-forward to December: before the holidays, we decided to resume our research and build a proof of concept of a web-based installer. We created something simple enough that, to be honest, does not even work at all. But after discussing the overall approach at a team meeting in January, we thought it might be a good idea to invest more time into it.

However, before jumping into coding just "something", we want to take our time to define the project in the right way, build a plan and ask for feedback.

It is not just about the user interface​

Providing an alternative web-based interface is just the tip of the iceberg. Before doing that, we need to make many internal changes, like decoupling the user interface code or adding a D-Bus interface.

Fortunately, we already have improved YaST internals in several vital areas (storage, networking, etc.). However, we are not there yet: a lot of work remains to be done.

The diagram below outlines the main components of the idea. Of course, it might change as the project evolves, but it looks good as a starting point.

Benefits​

Following this approach, we can foresee many benefits for YaST. To name a few:

• A better user interface: libYUI has served us well. However, it imposes some limitations that we would love to overcome.
• Reusability: YaST contains a lot of helpful logic that would be available to other tools.
• Better integration: It should be easier to integrate pieces of YaST in your own workflows by providing a D-Bus interface.
• Multi-language: Eventually, using D-Bus might allow us to use other programming languages.
• Contributors: We expect more people to contribute to the project by making the code more accessible and using widely-known technologies.

Q&A​

We expect you have questions, right? So let's try to anticipate some of them.

Are you deprecating the current user interface?​

No. We just want to offer an alternative and somehow simplified interface. Actually, we do not expect the web-based UI to be as powerful as the current one in the short term.

Which modules would get the new interface?​

At this point, we are limiting to the installer. We do not plan to add a web-based interface to any other module.

What about AutoYaST?​

Regarding AutoYaST, the idea is to use the same codebase as the standard installation while keeping the backward compatibility. So you could reuse your AutoYaST profiles with no significant issues.

Are you moving from Ruby to another language?​

No. We just thought that, in the future, it might be possible to reimplement parts of YaST (or write new pieces) in a different language. But we do not plan to replace Ruby in the short term.

When will it be released?​

We do not know yet.

Isn't precisely that what Anaconda developers are doing?​

Mostly yes. We were glad to read their announcement because it somehow validates our point of view about the future. But, of course, Anaconda is in a better position (e.g., it already features a D-Bus interface).

Would you rely on Cockpit?​

We do not know yet, but... why not? Cockpit is a really nice project and we have already released a module for Wicked. So perhaps we could seek some collaboration.

Why is called D-Installer?​

Well, it is just a play on words. We named the repository as "yast/the-installer" and, given that it is a service-based installer, it evolved to d-installer. Of course, not even the name of the project is set in stone, so we are open to better proposals. 😉

Conclusion​

We are in the early stages of an exciting project that should take us to redefine the future of YaST. And, of course, we would love to hear from you. So, please, do not hesitate to contact us if you have any comments or questions.

Have a lot of fun!

There is a new drop-in replacement for Elasticsearch, at least if you don’t mind the limitations and the alpha status. However, it definitely lives up to the promise that it provides an Elasticsearch-compatible API for data ingestion. I tested it with the elasticsearch-http() destination of syslog-ng, and it worked perfectly after I modified the URL in the configuration example I found.

So, what is Zinc? It is a search engine written in Go that provides an Elasticsearch-compatible API for data ingestion. You cannot use Kibana with it, only its own web interface. If you are not into graphs and dashboards, and want to search text messages, then it is perfect. The application itself is a single binary and it does not have any external dependencies. It is lightweight and easy to configure, as practically there are no configuration options at all.

Note: Zinc is still in alpha state. There are no guarantees that later versions will be compatible at any level. Error messages can sometimes be cryptic and you might run into unexpected behavior.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/another-use-for-the-syslog-ng-elasticsearch-http-destination-zinc

Aunque hay gente que detesta los wallpapers (lo hace público, y no pasa nada) de la Comunidad KDE, a mi me suelen gustar (y sobre todo cuando los veo en pantallas grandes de televisores). Esa combinación abstracta de colores y forma geométricas me convence, aunque siempre hay algunos más que otros. Es por ello que me encanta anunciar que ya hay fondo de pantalla para Plasma 5.24, un fondo que además de ser bonito, en mi humilde opinión, tiene una historia creativa bastante interesante.

Fondo de pantalla para Plasma 5.24: Wavy McWallpaperface

Una de las características de los lanzamientos del escritorio Plasma, lo que alguno entienden como KDE pero que no) es que cada ciertos lanzamiento actualizan también su fondo de pantalla. De hecho, hay una entrada recurrente en el blog sobre la evolución del mismo que se ha quedado en la versión Plasma 5.20.

Para el próximo Plasma 5.24 se decidió cambiar de nuevo de fondo de pantalla por defecto y, en esta ocasión, sería trabajo de un solo creador, Ken Vermette, el cual no solo lo ha creado sino que ha compartido el proceso de creación en dos directos que han quedado registrados en Youtube:

El fondo de pantalla lleva el nombre “Wavy McWallpaperface” y nos muestra una ola (ahora que están de moda) geométrica de colores contrastados. Como es habitual, lo podéis ver a continuación y si pncháis en él lo podéis ampliar.

Creo que al igual que «Opal» de Plasma 5.11 o el fondo de pantalla de la edición 25 aniversario del proyecto KDE será un tema que se verá de forma espectacular en pantallas grandes y luminosas como comprobé cuando realicé una charla en Vilanet en el 2017 y pude ver ese fondo en un gran televisor, o en Linux Center en Noviembre.

¿Qué os parece? ¿Lo pondréis en vuestro escritorio? Yo ya lo he hecho… y se va a quedar un buen tiempo.

Más información: OMG! Ubuntu!

今回は cool-retro-term を紹介します。

cool-retro-term は、ターミナルエミュレータですが、CRT での画面イメージを模した表示を行います。たとえば、アンバー色の単色で、CRT の画面のゆがみや、走査線による輝度の変化などを再現しています。アンバー色の単色以外にも、緑色の単色、Appre II、IBM DOS(これはカラー)、IBM 3728(0のフォントが、真ん中にドットがある)などが選べます。また、エフェクト(画面のゆがみ、走査線など)も適宜設定することができます。
ちょっと雰囲気を変えたいときには良いかもしれません。

The call for papers for openSUSE Conference 2022 is open!

The call for papers is open until April 14. This leaves a less than 90 days to submit a proposal. The dates of the conference are scheduled for June 2 - 4. The organizing team is preparing for a hybrid conference involving both virtual talks and live talks from the Z-Bau in Nuremberg, Germany. Registration for the conference has also begun.

Presentations can be submitted for the following length of time:

• Lightning Talk (10 mins) or Lightning Virtual Talk (10 mins)
• Normal Talk (30 mins) or Normal Virtual Talk (30 mins)
• Long Talk (45 mins) or Long Virtual Talk (45 mins)
• Workshop (1 hour) or Virtual Workshop (1 hour)

The following tracks are listed for the conference:

• Cloud and Containers
• Community
• Embedded Systems and Edge Computing
• New Technologies
• Open Source
• openSUSE

The conference already has two sponsors with Fedora and SUSE. Companies interested in sponsoring the event can view sponsorship information on the project’s wiki page.

Volunteers who would like to help with the planning of the event can join our planning meetings on Tuesdays at 19:00 UTC. Check the notes for details.

Ha comenzado el inicio de una encuesta de openSUSE, tanto si eres usuario, colaborador de la comunidad de software libre o miembro de la comunidad puedes realizar la encuesta anual del pasado 2021

Al igual que en la encuesta del año pasado. La comunidad de openSUSE ha puesto en marcha una encuesta para saber más de la comunidad que usa openSUSE.

La encuesta está abierta a todas las personas que utilicen openSUSE como sistema operativo en su día a día de manera personal como afición o de manera profesional.

Sirve para hacerse una idea y recibir un «feedback» de varias cuestiones, tomar en cuenta los resultados y saber en qué se está mejorando, en qué hay que mejorar y de qué manera enfocar mejor los esfuerzos de la comunidad para llegar a más personas.

La encuesta, que debería haber empezado en diciembre de 2021, se ha pospuesto hasta este enero de 2022 y estará disponible hasta el 28 de febrero de 2022.

Las preguntas y respuestas de la encuesta están en inglés, pero son muy fáciles de entender y de responder y son anónimas.

Tienes los datos disponibles de la encuesta de 2020 en este enlace por si tienes curiosidad:

• https://en.opensuse.org/End-of-year-surveys/2020/Data

Para participar en la encuesta pincha sobre el siguiente enlace:

• https://survey.opensuse.org/

Te animo a participar si eres usuario o usuaria de openSUSE en tu día a día y quieres aportar tu experiencia y tu punto de vista a la comunidad.

Fuente: https://news.opensuse.org/2022/01/17/os-begins-annual-survey/

今回は chafa を紹介します。

chafa は、種々のグラフィカルデータを、コンソール上に表示するためのツールです。ASCII/Unicode文字やsixel 拡張を使ってコンソール上に表示します。コンソールに表示するときには、コンソールがどのような表示機能を持つかによって、表示方法を変えます。たとえば、/usr/share/cups/ipptool/color.jpg にある花の画像を変換すると、以下のようになります。

teraterm の場合

ASCII 文字列を使って表示するので、かなり荒い感じになります。
しかし、rlogin を使うと、以下のようにもっときれいに表示できます。

これだと、ほとんどイメージ表示ツールで表示したのと差がありません。rlogin は sixel 拡張などを使えるので、より良い条件で表示しているものと思われます。ちなみに、chafa を使って rlogin 上に表示するとき、文字を使って表示、と指定しても、以下のように teraterm よりかなりきれいに表示できます。

コンソールで繋いでいる状態の時、画像を確認したいときに使うと便利だと思います。
なお、上記の画像はすべて、データ量圧縮のため、256色に減色しています。