Como era de esperar, el gran evento comunitario de KDE no se va a celebrar físicamente tampoco este año. De esta forma, la Comunidad KDE acaba de anunciar que Akademy 2021 se celebrará en línea en junio, evitando así los actuales inconvenientes de la pandemia que está marcando nuestras vidas.

Akademy 2021 en línea se celebrará en junio

Como ya anticiparon muchos científicos y muchas comunidades libres este nuevo virus ha venido para quedarse mucho más que unos meses.

De esta forma, y viendo los problemas de movilidad, la Comunidad KDE ha decidido continuar con la modalidad en línea de evento de Akademy 2020 y empezar a organizar Akademy 2021 que también será en línea y cuyas fechas se han fijado para final de junio.

Como es habitual, las charlas se realizarán en línea el sábado 19 y el domingo 20, dejando el resto de días para el trabajo en pequeños grupos.

Como es habitual, en breve se lanzará el «Call for Papers» y pronto tendremos más detalles, sobre todo los técnicos.

Es cierto que se sigue perdiendo el factor humano pero se mantiene ese espíritu comunitario y seguro que se evoluciona en este tipo de eventos para que sean más emocionales.

Más información: KDE

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2018 de Viena.

openqa-mon is a little command-line utility to monitor one or multiple openQA jobs for their status. This tool is useful if you want to live monitor a handful of jobs closely e.g. for verification runs.

Almost five years ago librsvg introduced Rust into its source code. Around the same time, Linux distributions started shipping the first versions of Firefox that also required Rust. I unashamedly wanted to ride that wave: distros would have to integrate a new language in their build infrastructure, or they would be left without Firefox. I was hoping that having a working Rust toolchain would make it easier for the rustified librsvg to get into distros.

Two years after that, someone from Debian complained that this made it hard or impossible to build librsvg (and all the software that depends on it, which is A Lot) on all the architectures that Debian builds on — specifically, on things like HP PA-RISC or Alpha, which even Debian marks as "discontinued" now.

Recently there was a similar kerfuffle, this time from someone from Gentoo, specifically about how Python's cryptography package now requires Rust. So, it doesn't build for platforms that Rust/LLVM don't support, like hppa, alpha, and Itanium. It also doesn't build for platforms for which there are no Rust packages from Gentoo yet (mips, s390x, riscv among them).

Memories of discontinued architectures

Let me reminisce about a couple of discontinued architectures. If I'm reading Wikipedia correctly, the DEC Alpha ceased to be developed in 2001, and HP, who purchased Compaq, who purchased DEC, stopped selling Alpha systems in 2007. Notably, Compaq phased out the Alpha in favor of the Itanium, which stopped being developed in 2017.

I used an Alpha machine in 1997-1998, back at the University. Miguel kindly let me program and learn from him at the Institute where he worked, and the computer lab there got an Alpha box to let the scientists run mathematical models on a machine with really fast floating-point. This was a time when people actually regularly ssh'ed into machines to run X11 applications remotely — in their case, I think it was Matlab and Mathematica. Good times.

The Alpha had fast floating point, much faster than Intel x86 CPUs, and I was delighted to do graphics work on it. That was the first 64-bit machine I used, and it let me learn how to fix code that only assumed 32 bits. It had a really picky floating-point unit. Whereas x86 would happily throw you a NaN if you used uninitialized memory as floats, the Alpha would properly fault and crash the program. I fixed so many bugs thanks to that!

I also have fond memories of the 32-bit SPARC boxes at the University and their flat-screen fixed-frequency CRT displays, but you know, I haven't seen one of those machines since 1998. Because I was doing graphics work, I used the single SPARC machine in the computer lab at the Institute that had 24-bit graphics, with a humongous 21" CRT display. PCs at the time still had 8-bit video cards and shitty little monitors.

At about the same time that the Institute got its Alpha, it also got one of the first 64-bit UltraSPARCs from Sun — a very expensive machine definitely not targeted to hobbyists. I think it had two CPUs! Multicore did not exist!

I think I saw a single Itanium machine in my life, probably around 2002-2005. The Ximian/Novell office in Mexico City got one, for QA purposes — an incredibly loud and unstable machine. I don't think we ever did any actual development on that box; it was a "can you reproduce this bug there" kind of thing. I think Ximian/Novell had a contract with HP to test the distro there, I don't remember.

Unsupported architectures at the LLVM level

Platforms like the Alpha and Itanium that Rust/LLVM don't support — those platforms are dead in the water. The compiler cannot target them, as Rust generates machine code via LLVM, and LLVM doesn't support them.

I don't know why distributions maintained by volunteers give themselves the responsibility to keep their software running on platforms that have not been manufactured for years, and that were never even hobbyist machines.

I read the other day, and now I regret not keeping the link, something like this: don't assume that your hobby computing entitles you to free labor on the part of compiler writers, software maintainers, and distro volunteers. (If someone helps me find the source, I'll happily link to it and quote it properly.)

Non-tier-1 platforms and "$distro does not build Rust there yet"

I think people are discovering these once again:

• Writing and supporting a compiler for a certain architecture takes Real Work.

• Supporting a distro for a certain architecture takes Real Work.

• Fixing software to work on a certain architecture takes Real Work.

Rust divides its support for different platforms into tiers, going from tier 1, the most supported, to tier 3, the least supported. Or, I should say, taken care of, which is a combination of people who actually have the hardware in question, and whether the general CI and build tooling is prepared to deal with them as effectively as it does for tier 1 platforms.

In other words: there are more people capable of paying attention to, and testing things on, x86_64 PCs than there are for sparc-unknown-linux-gnu.

Some anecdotes from Suse

At Suse we actually support IBM's s390x big iron; those mainframes run Suse Linux Enterprise Server. You have to pay a lot of money to get a machine like that and support for it. It's a room-sized beast that requires professional babysitting.

When librsvg and Firefox started getting rustified, there was of course concern about getting Rust to work properly on the s390x. I worked sporadically with the people who made the distro work there, and who had to deal with building Rust and Firefox on it (librsvg was a non-issue after getting Rust and Firefox to work).

I think all the LLVM work for the s390x was done at IBM. There were probably a couple of miscompilations that affected Firefox; they got fixed.

One would expect bugs in software for IBM mainframes to be fixed by IBM or its contractors, not by volunteers maintaining a distro in their spare time.

Giving computing time on mainframes to volunteers in distros could seem like a good samaritan move, or a trap to extract free labor from unsuspecting people.

Endianness bugs

Firefox's problems on the s390x were more around big-endian bugs than anything. You see, all the common architectures these days (x86_64 and arm64) are little-endian. However, s390x is big-endian, which means that all multi-byte numbers in memory are stored backwards from what most software expects.

It is not a problem to write software that assumes little-endian or big-endian all the time, but it takes a little care to write software that works on either.

Most of the software that volunteers and paid people write assumes little-endian CPUs, because that is likely what they are targeting. It is a pain in the ass to encounter code that works incorrectly on big-endian — a pain because knowing where to look for evidence of bugs is tricky, and fixing existing code to work with either endianness can be either very simple, or a major adventure in refactoring and testing.

Two cases in point:

Firefox. When Suse started dealing with Rust and Firefox in the s390x, there were endianness bugs in the graphics code in Firefox that deals with pixel formats. Whether pixels get stored in memory as ARGB/ABGR/RGBA/etc. is a platform-specific thing, and is generally a combination of the graphics hardware for that platform, plus the actual CPU architecture. At that time, it looked like the C++ code in Firefox that deals with pixels had been rewritten/refactored, and had lost big-endian support along the way. I don't know the current status (not a single big-endian CPU in my vincinity), but I haven't seen related bugs come in the Suse bug tracker? Maybe it's fixed now?

Librsvg had two root causes of bugs for big-endian. One was in the old code for SVG filter effects that was written in C; it never supported big-endian. The initial port to Rust inherited the same bug (think of a line-by-line port, althought it wasn't exactly like that), but it got fixed when my Summer of Code intern Ivan Molodetskikh refactored the code to have a Pixel abstraction that works for little-endian and big-endian, and wraps Cairo's funky requirements.

The other endian-related bug in librsvg was when computing masks. Again, a little refactoring with that Pixel abstraction fixed it.

I knew that the original C code for SVG filter effects didn't work on big-endian. But even back then, at Suse we never got reports of it producing incorrect results on the s390x... maybe people don't use their mainframes to run rsvg-convert? I was hoping that the port to Rust of that code would automatically fix that bug, and it kind of happened that way through Ivan's careful work.

And the code for masks? There were two bugs reported with that same root cause: one from Debian as a failure in librsvg's test suite (yay, it caught that bug!), and one from someone running an Apple PowerBook G4 with a MATE desktop and seeing incorrectly-rendered SVG icons.

And you know what? I am delighted to see people trying to keep those lovely machines alive. A laptop that doesn't get warm enough to burn your thighs, what a concept. A perfectly serviceable 32-bit laptop with a maximum of about 1 GB of RAM and a 40 GB hard drive (it didn't have HDMI!)... But you know, it's the same kind of delight I feel when people talk about doing film photography on a Rollei 35. A lot of nostalgia for hardware of days past, and a lot of mixed feelings about not throwing out working things and creating more trash.

As a graphics programmer I feel the responsibility to write code that works on little-endian and big-endian, but you know, it's not exactly an everyday concern anymore. The last big-endian machine I used on an everyday basis was the SPARCs in the university, more than 20 years ago.

Who gets paid to fix this?

That's the question. Suse got paid to support Firefox on the s390x; I suppose IBM has an interest in fixing LLVM there; both actually have people and hardware and money to that effect.

Within Suse, I am by default responsible for keeping librsvg working for the s390x as well — it gets built as part of the distro, after all. I have never gotten an endianness bug report from the Suse side of things.

Which leads me to suspect that, probably similar to Debian and Gentoo, we build a lot of software because it's in the build chain, but we don't run it to its fullest extent. Do people run GNOME desktops on s390x virtual machines? Maybe? Did they not notice endianness bugs because they were not in the code path that most GNOME icons actually use? Who knows!

I'm thankful to Simon from the Debian bug for pointing out the failure in librsvg's test case for masks, and to Mingcong for actually showing a screenshot of a MATE desktop running on a PPC PowerBook. Those were useful things for them to do.

Also — they were kind about it. It was a pleasure to interact with them.

One of the things that came up during user testing GNOME 40 was that people went through the Tour and all the abstract(ish) UI illustrations didn't really help people orient themselves on screen. We did get positive feedback on the feel of the tour though. For the new Tour we iterated on some illustrations that help solidify the style and give a nice welcoming vibe to the experience.

Because you can soon experience GNOME 40 yourself, here's a few sketches of the exploratory phase. Be sure to check out some background on how the animations were done.

Bienvenidos al Podcast 07×05 Software libre y KDE en entornos profesionales: Arqueología donde seguimos estudiando si es posible el uso de proyectos libre en la profesión que se encarga de desenterrar nuestro pasado para conocernos mejor.

Podcast 07×05 Software libre y KDE en entornos profesionales: Arqueología

Quinto podcast de la temporada en el que tenemos como invitado a Fernando Muñoz, arqueólogo con más de 20 años de experiencia y que lleva desde 2008 utilizando Linux como entorno de trabajo y cuyos conocimientos sobre el mundo GNU/Linux es bastante extenso.

A lo largo de la distendida (y de nuevo) larga charla tuvimos la ocasión de ir repasar un buen número de aplicaciones de todo tipo, conocimos una distribución específica para arqueología, descubrimos un blog de Software Libre y Arqueología, vimos eventos online libres para arqueólogos, etc.

Otros integrantes del podcast fueron

• Rubén Gómez: miembro de KDE España, de HackLab Almería y de Document Foundation en la labor de presentador.
• Mari Carmen (aka Maika, miembro de KDE España) que también desempeñó su papel de presentadora.
• Baltasar Ortega (un servidor): editor de KDE Blog, secretario de KDE España, miembro de GNU/Linux València y de KDE e.V, que hizo las funciones de presentador de noticias y de presentar información adicional visual. No os perdáis el vídeo que creo que vale la pena, aunque seguro que hay cosa a mejorar.
• Jorge Lama: Diseñador sonoro/productor de podcasting: Coruña Dixital https://spoti.fi/34vr6Ve Bricolabs Podcast http://bit.ly/2KhYBnW NOlegaltech Radio http://goo.gl/GZ2gT3 y, ahora,  productor del podcast de KDE España.

Con este podcast seguimos esta temporada la serie sobre el uso de software libre en los entornos profesionales, en los oficios y profesiones. Os pedimos colaboración para localizar a profesionales no relacionados con la informática que conozcáis que estén usando software libre y Gnu/Linux como su entorno principal de trabajo: desde electricistas hasta carpinteros pasando por ingenieros, gestorías, veterinarios…

Y no os entretengo más, os dejo con el vídeo que dura su dos horas y 30 minutos, uno podcast largo pero muy denso tanto en la presentación de aplicaciones, proyectos y futuro.

Espero que os haya gustado, si es así ya sabéis: “Manita arriba“, compartid y no olvidéis visitar y suscribiros al canal de Youtube de KDE España.

Como siempre, esperamos vuestros comentarios que os aseguro que son muy valiosos para los desarrolladores, aunque sean críticas constructivas (las otras nunca son buenas para nadie). Así mismo, también nos gustaría saber los temas sobre los que gustaría que hablásemos en los próximos podcast.

My FOSDEM presentation in the BSD devroom showcased what is new in sudo and syslog-ng and explained how to install or compile these software yourself on FreeBSD. Not only am I a long time FreeBSD user (started with version 1.0 in 1994) I also work on keeping the syslog-ng port in FreeBSD up to date. But soon after my presentation I was asked what I knew about other BSDs. And – while I knew that all BSDs have syslog-ng in their ports system – I realized I had no idea about the shape of those ports.

For this article I installed OpenBSD, DragonFlyBSD and NetBSD to check syslog-ng on them. Admittedly, they are not in the best shape: they contain old versions, some do not even start or are unable to collect local log messages.

OpenBSD

OpenBSD ports have version 3.12 of syslog-ng. Some Linux distributions have an even earlier version of syslog-ng and they work just fine. Unfortunately, it is not the case here: logging in OpenBSD changed and it means that local log messages cannot be collected by syslog-ng 3.12. Support for collecting local log messages was added in a later syslog-ng version: https://github.com/syslog-ng/syslog-ng/pull/1875

Installation of this ancient syslog-ng version is really easy, just use pkg_add:

openbsd68# pkg_add syslog-ng
quirks-3.441 signed on 2021-02-13T20:25:37Z
syslog-ng-3.12.1p7: ok
The following new rcscripts were installed: /etc/rc.d/syslog_ng
See rcctl(8) for details.

Collecting log messages over the network works perfectly, so as a workaround, you might want to keep using syslogd from the base system as well while forwarding log messages to syslog-ng using the network.

DragonFlyBSD

Once upon a time DragonFlyBSD was forked from FreeBSD. While they took a different route from FreeBSD they also stayed close to the original. DragonFlyBSD ports build on FreeBSD ports even though there are some additional applications and other smaller differences. This means that syslog-ng is up to date in DragonFlyBSD ports, - which in this case means version 3.29. Installation is easy, using the same command as on FreeBSD:

pkg install syslog-ng

Problems start when you actually try to start syslog-ng:

dragon# /usr/local/etc/rc.d/syslog-ng forcestart
Starting syslog_ng.
[2021-02-17T08:59:13.598727] system(): Error detecting platform, unable to define the system() source. Please send your system information to the developers!; sysname='DragonFly', release='5.8-RELEASE'
Error parsing config, syntax error, unexpected LL_ERROR, expecting '}' in /usr/local/etc/syslog-ng.conf:19:14-19:20:
14      options { chain_hostnames(off); flush_lines(0); threaded(yes); };
15      
16      #
17      # sources
18      #
19----> source src { system();
19---->              ^^^^^^
20      	     udp(); internal(); };
21      
22      #
23      # destinations
24      #


syslog-ng documentation: https://www.syslog-ng.com/technical-documents/list/syslog-ng-open-source-edition
contact: https://lists.balabit.hu/mailman/listinfo/syslog-ng

While system() source works on FreeBSD, where this configuration was prepared, it does not work on DragonFlyBSD. You need to edit /usr/local/etc/syslog-ng.conf and replace system() source with the following lines:

     unix-dgram("/var/run/log");
     unix-dgram("/var/run/logpriv" perm(0600));
     file("/dev/klog" follow-freq(0) program-override("kernel"));

This is based on the earlier FreeBSD configuration and seems to work. I have filed an issue at the syslog-ng GitHub repo, so in a future release it might work automatically.

I also tried to build syslog-ng from ports myself, but right now it is broken. The sysutils/syslog-ng port is still a metaport referring to another port, but that version has already been deleted. The syslog-ng port was reorganized recently, and it seems like not everything was followed up on the DragonFlyBSD side perfectly.

NetBSD

NetBSD also has a quite ancient version of syslog-ng: 3.17.2. Installation of the package is easy, just:

pkgin install syslog-ng

Syslog-ng works and can collect local log messages out of box as well, with a catch. NetBSD seems to have switched to RFC5424 syslog format, just as FreeBSD 12.0, so local log messages collected by syslog-ng’s system() source look a kind of funny:

Feb 17 12:43:07 localhost 1 2021-02-17T12:43:07.935565+01:00 localhost sshd 2160 - - Server listening on :: port 22.
Feb 17 12:43:07 localhost 1 2021-02-17T12:43:07.936064+01:00 localhost sshd 2160 - - Server listening on 0.0.0.0 port 22.

Also, the system() source seems to have missed kernel logging. To fix this, open syslog-ng.conf in your favorite text editor, remove the system() source and add these two lines instead:

        unix-dgram("/var/run/log" flags(syslog-protocol));
        file("/dev/klog" flags(kernel) program_override("kernel"));

This makes sure that local logs are parsed correctly and that kernel messages are collected by syslog-ng as well.

What is next

In this blog I identified many problems related to syslog-ng in various BSD port systems. I also provided some workarounds, but of course these are not real solutions. I cannot promise anything, as I am not an active user or developer of any of these BSD systems and I am also short on time. However, I’m planning to fix as many of these problems at the best effort level, as time allows.

 

If you have any questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @Pczanik.

¿Cómo usa Vim un desarrollador que lo utiliza de manera intensiva desde hace años? En esta interesante entrevista en exclusiva podrás descubrirlo.

Desde que empecé a utilizar Vim, por el blog han aparecido muchos tutoriales sobre mi experiencia y aquello que poco a poco voy aprendiendo sobre este editor de texto. Puedes encontrar cómo hacer tal cosa, qué hace tal o cual complemento, incluso una entrevista a un periodista que utiliza Vim en su trabajo.

Pero desde hace tiempo, tenía en mente hacer una entrevista a una persona que utilizara el editor Vim como herramienta en su trabajo como desarrollador de software. Alguien que utilice Vim (o algunas de las opciones del planeta Vim, léase: Vi, neovim, etc) de una forma intensa y que después de muchos años de uso haya conseguido sacarle todo el jugo de las posibilidades que ofrece Vim.

Mi primera opción fue un desarrollador que trabaja actualmente para SUSE en el equipo que desarrolla YaST, llamado Ancor, pero declinó la invitación porque bajo su criterio no era un buen candidato.

Sin embargo ha tenido la amabilidad (muuuchas gracias por eso) de pasarme el contacto de un desarrollador que conoce, llamado Ignacio, con el trabajó en el pasado y que en palabras del propio Ancor es “el mayor hechicero de Vim con el que he trabajado”.

Así que agradecer a Ancor el haberme pasado ese contacto y a Ignacio el haber accedido a esta “proposición” totalmente decente, en la que nos desvelará algunos de los trucos que usa en Vim y algún proyecto personal muy interesante relacionado con Vim.

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

Pero mejor que sea el propio Ignacio quien nos lo explique en esta entrevista en exclusiva para el blog. Todo un placer y un privilegio:

Vhck: Lo primero, háblanos un poco sobre ti (lo que quieras contar).

Ignacio: Bueno, que difícil es esa pregunta, pero lo intentaré :). Soy el típico informático de vocación y, la verdad, parece que estaba predestinado a serlo, pues comencé con un Sinclair ZX Spectrum de 16Kb con teclas de goma que me compré con una quiniela de 12 resultados que gané a los 12 años, y luego seguí con un IBM PC de los originales con dos disqueteras de 5,25″ que se ganó mi padre en el sorteo final de un curso de informática en el diario de Tarragona (la suerte ya no siguió después ;-).

Posteriormente descubrí Linux con Slackware, luego vino Redhat y la mayoría del tiempo usé Debian. Principalmente me gustaba KDE como entorno de escritorio, aunque estuve mucho tiempo usando gestores de ventanas ligeros, pues era lo más personalizable y potente.

Luego llegó el 2011 en el que el gusanillo/manía de probar cosas nuevas me hizo comprarme un Macbook Pro de Apple (lo único de la marca con lo que sigo contento, aunque el teclado de mi modelo actual del 2017 lo odio profundamente, y uso un teclado externo que me regalaron, también de apple).

Parte de la culpa de haber acabado como he acabado, es por cómo funciona mi cerebro, la cual es una de las cosas que me gustaría saber porqué.

No soy el típico “empollón” que se aprende las lecciones de memoria (nunca conseguí sacarme así una asignatura sin entenderla, lo que por desgracia se prima y mucho), pero soy capaz de aprenderme casi cada día nuevos atajos de teclado (incluidos los de Vim XD) con usarlos un par de veces, así como matrículas, números de teléfono, contraseñas, ese tipo de cosas.

Además, a pesar de mi limitación para memorizar “rollo”, tengo la suerte de contar con un pensamiento lógico para deducir a partir de datos iniciales, lo cual me ha venido muy bien para solucionar situaciones “misteriosas” como las que nos encontramos día a día en el mundo de los ordenadores.

¿Y todo este rollo a qué viene? Pues creo que dará a entender mi gusto por el Vim, ya que la memoria extraña para cosas puntuales me permite ver lógicas algo raras que me facilita de alguna manera el “entender” el uso de un editor tan particular.

Y ya de forma más personal, trabajo desde hace más de 20 años como programador (actualmente desarrollo aplicaciones web en Ruby On Rails, aunque he dado “tumbos” por otros lenguajes y disciplinas informáticas y también me gusta hacer algunas tareas de sistemas y sobre todo “tunear” cosas para facilitarme la vida, (soy un poco lo que se llama un McGiver) a pesar de haber estudiado una carrera de ingeniería industrial eléctrica.

Por lo que he visto en tu blog, comparto contigo bastante, y me ha gustado especialmente y me describe perfectamente la imagen de “Por que amo el software libre”, y aunque me gusta “ayudar” en lo que puedo, reconozco que lo hago muy poco y en píldoras muy puntuales. Y además de la informática, me encanta la ciencia ficción y soy también adicto al simracing, con el que llevo muchos años aunque de forma amateur.

Vhck: Cuándo y cómo fue tu primer acercamiento a Vim y cómo fue ese primer contacto.

Ignacio: Pues la recuerdo perfectamente, y todo el que se acerca a este editor supongo que lo hará igual, pues es muy fuerte el impacto que provoca. Fue delante de una estación de trabajo en la universidad viendo a un amigo (el que posteriormente fue mi primer “Jefe” en el mundo laboral) y pensé “qué demonios está haciendo éste con esas combinaciones de teclas tan extrañas, algún tipo de sortilegio?” XD.

Ese fue mi primer contacto, e inmediatamente tuve mi primer acercamiento, pues la asignatura de informática en ingeniería industrial venía acompañada de esas estaciones Digital de trabajo prehistóricas con sistema VAX-VMS, y ellas con el omnipresente Vi.

¿Y cómo fue ese acercamiento? pues también lo recuerdo perfectamente y seguro que a mucha gente también le pasaría lo mismo (de hecho he visto que tu primera entrada de Vim en el blog va de ello :).

Entro a editar un fichero con toda la ilusión del mundo, y cuando intento salir del editor guardando los cambios sin haber mirado ningún manual de uso (quién lo hace a priori? XD), no tengo más que poner el proceso en background y matarlo (menos mal que ya conocía el ctrl-z y el kill :).

Sí, es un momento de impotencia/rabia/vergüenza que ahora recuerdo con diversión, pero luego se convirtió en muchos años disfrutando de tan potente herramienta.

Vhck: ¿Qué te hizo seguir utilizando Vim en tu trabajo como desarrollador hasta el día de hoy? ¿Cual fue tu momento “eureka”?

Ignacio: Pues no recuerdo ningún momento “eureka” en particular, más que nada es mi “manía” por evitar cualquier actuación “manual” y mi adicción a automatizar cosas la que me hizo comenzar con “qedit” y descubrir el maravilloso mundo de las macros (no estoy 100% seguro de que no hubiera algún otro editor antes que qedit, pero estamos hablando de hace muchos años y vivencias en el mundo informático como para acordarme de todo).

Después de eso fue cuando tuve mi primer lector de CDROM, que venía acompañado de un disco repleto de software, donde descubrí Linux y ahí retomé en serio mi contacto con Vi, y ya para toda la vida.

Vhck: Me has comentado que utilizas no únicamente Vim, si no toda la familia. ¿Cuando usas Vi, cuando Vim y qué utilizas en el día a día para tu trabajo?

Ignacio: Básicamente uso Vim en mi día a día desde hace años, más o menos tuneado y en diferentes versiones (actualmente NeoVim), pero tengo claro que sólo con la base de Vi ya soy feliz, y si entro en algún servidor/router/loquesea que tenga vi, no suelo encontrarme desamparado y tunearlo de entrada, sino que me arreglo con lo básico y si ya lo tengo que usar de forma más repetida le meto lo que haga falta. Por supuesto, en el windows que uso para simracing también lo tengo instalado

Vhck: ¿Qué tareas realizas con Vim?

Ignacio: Principalmente lo uso para escribir código, aunque la gente que me conoce sabe de mi “alergia” a los interfaces gráficos, no por ningún “esnobismo” sino porque muchas veces me “molesta” quitar las manos del teclado y usar ratón y tengo claro que soy más productivo con el teclado, por lo que de forma natural uso Vim para editar casi cualquier texto.

Estarán pensando que tendré el navegador con alguna extensión para usarlo en modo Vi, y en algún momento lo he probado, pero no llego a ser un fanático enfermizo, sé cuándo algo me resulta útil/cómodo y cuando no.

Aún así, el otro día me sorprendí pensando en cómo podría editar una hoja de cálculo en la que tenía que hacer edición repetitiva, no sólo de números, pues eso ya se puede hacer como csv, sino fórmulas y todo, pero no pudo ser XD.

Vhck: ¿Por qué seguir utilizando el editor Vim, frente a otras opciones quizás más modernas?

Ignacio: En un principio no sabía qué responder a esa pregunta, pero trabajando con Ancor y su hermano hace años me llegó la respuesta. Varios de nosotros comenzamos un mini curso de Emacs para probar y nos gustaba, pero sólo su hermano siguió con él, ya que otro compañero y yo pensamos que no había una razón técnica preponderante, y el tiempo hasta llegar al nivel que teníamos en Vim no iba a compensarnos.

¿Porqué Emacs y no otros? lo principal en mi es que no soy nada fanático (arriba hablo de que uso un Macbook Pro, pero he tenido iPhone y iPad y me he quedado con Android de teléfono, a cada cosa lo suyo, no por ser de una marca lo tengo que usar), reconozco que Emacs es igualmente potente y flexible, por lo que era natural en mi probarlo, de hecho había usado un poco el lenguage Lisp en autocad (sí, también descubrí que era automatizable y en una calculadora HP48 RPN (lógica polaca inversa) y me gustó la experiencia, por lo que tenía curiosidad de poder usarlo como mi editor de confianza ;-).

Sí, sé que esas dos alternativas no son lo que te referías con modernas, pero mi predilección por ese tipo es por lo que comentaba antes de mi “alergia” por los interfaces gráficos, aunque como veremos posteriormente, al final estoy usando vscode… con Vim, naturalmente

Vhck: Llevas usando Vim de manera intensa en tu trabajo muchos años ¿hay en tu caso espacio para el asombro y para el aprendizaje de nuevas funcionalidades de Vim o ya nada te puede sorprender?

Ignacio: La verdad es que una de las cosas que más me gusta de Vim es que no deja de sorprenderme, y el mundo de sus extensiones es inmenso, por lo que sí, sigo dejándome sorprender.

Vhck: Vi/Vim/Neovim “vitaminado” o prefieres un sabor “vainilla”. Es decir, prefieres tenerlo adaptado a tus gustos con tus personalizaciones o utilizar en la medida de lo posible lo que “viene de serie”.

Ignacio: Pues depende de las circunstancias, pues trabajo en mi equipo principalmente, pero también bastante en servidores remotos y alguna vez en routers o equipos “limitados”. Evidentemente me siento más cómodo en mi versión “tuneada”, aunque no tengo ningún problema en usarlo “a pelo”.

Vhck: ¿Qué configuración o característica propia de Vim te resulta imprescindible? ¿Qué última mejora en Vim te resultó más útil y necesaria?

Ignacio: A riesgo de ser demasiado “purista” diría que la base “modal” del editor es lo que se usa más, los 3 comandos principales de c(hange), d(elete) y y(ank) con los parámetros de movimiento y sobre todo el comando ‘.’ para repetir.

Ah, y por supuesto las expresiones regulares (sí, también soy medio adicto a ellas y cuadraron en mi cerebro de forma casi nativa :).

Respecto a mejoras de los últimos tiempos, pues diría que los popups de NeoVim, pues es de las pocas cosas de interfaces gráficos que veo útiles para mostrar información de forma más clara :). Seguro que ahora mismo no me acuerdo de otras cosas incluso más importantes, pero es un mundo tan extenso en si mismo y lo tengo tan interiorizado que me cuesta acordarme de algo en particular.

Vhck: ¿Cual echas en falta?

Ignacio: No sé si te refieres a algo que todavía no se haya inventado o a algo que tengan otros editores y no Vim, pero ahora mismo no me viene nada a la mente. No es que Vim lo haga todo, pero en el momento en que encuentro alguna necesidad suelo encontrar algo que la soluciona, si no totalmente sí en parte, o me hago algún pequeño parche para no tener que sufrirla demasiado

Vhck: ¿Qué complemento o plugin de Vim te resulta imprescindible y lo usas cada día en tu trabajo?

Ignacio: Siempre que empiezo alguna nueva fase de personalización desde cero suelo echar de menos ciertas de ellas, como son aquellas para trabajar con “pares” (paréntesis, corchetes, comillas, etc…) o con mis ficheros de wiki en texto, u otras para gestionar repositorios de git. Seguro que ahora mismo se me olvidan muchas, pero eso es lo que suelo añadir de entrada.

Vhck: Por cierto ¿Qué tema de colores utilizas?

Ignacio: Pues es de las cosas que “más rabia” me da, pues no he encontrado ninguno que me guste totalmente y no tengo paciencia ni creatividad para hacerme uno yo mismo.

Lo que tengo claro es que tiene que ser con fondo oscuro y ahora mismo estoy usando “hybrid” con alguna personalizacion de colores de cosas que me molestan más de la cuenta.

Vhck: Me has comentado que tienes un proyecto entre manos que auna Vim y Vscode. ¿qué tiene de especial el proyecto y qué nos puedes contar de el?

Ignacio: Bueno, realmente no es un proyecto mío sino algo que descubrí hace poco, por lo que hablaré un poco de mi último cambio en el ecosistema de Vim. Hasta hace poco he usado durante bastante tiempo el proyecto vim-config de Rafael Bodill (de hecho sigo usándolo con el Vim en terminal), y lo comentaré aquí para las personas que no quieran usar Vscode (está muy bien comentado en la página de github, por lo que recomiendo su visita).

Me gustó mucho la forma de integrar un montón de extensiones pero no cargar demasiado el entorno, usando una aproximación “lazy” que permite tener diferentes entornos de trabajo (p.ej. para lenguajes de programación variados) y sólo cargar la mayoría de ellas en el momento necesario.

Una de las cosas que descubrí con él fue la posibilidad de usar extensiones de vscode (proyecto https://github.com/neoclide/coc.nvim) y la existencia del Language Server Protocol (LSP), lo que permite (junto a la posibilidad de Vim de ejecutar operaciones de forma asíncrona) usar compiladores, linters, embellecedores de código, etc… de forma integrada y tener un IDE en toda regla.

Como comentaba, estuve bastante tiempo “jugando” y disfrutando de esa configuración, pero hay algo que me molesta mucho, y es usar algo en modo texto y que sea pesado (no es que sea lento, pero yo soy demasiado exigente y mi uso de teclado a veces me hace llegar al límite de lo soportable y además, veía a mis compañeros usar un IDE gráfico como Vscode con total rapidez (también había jugado con interfaces gráficos de vim, pero o usaban node con electron y no me acababan de ir bien, o no eran completamente lo que quería).

Además los astros se alinearon y en mi lector de feeds apareció una noticia sobre una extensión de Vscode para usar NeoVim de forma perfectamente integrada (no la ya existente que permitía un modo emulado), y lo probé y pensé “tengo lo que amo y además de forma rápida!!??”.

De esta forma uso muchas de las extensiones de Vscode que ya usaba anteriormente y las de Vim que necesito porque no están en Vscode o prefiero usarlas por otros detalles.

Así que ésta es mi situación actual, conociéndome no aseguro que no vaya a cambiar, más que nada porque he empezado hace muy poco con ella y apenas he rascado la superficie, pero ahora mismo estoy contento de esta forma y estoy en la fase de enamoramiento inicial XD.

Vhck: Supongo que utilizas Vim en diferentes máquinas ¿de qué manera “sincronizas” Vim y las configuraciones entre distintos equipos que utilizas?

Ignacio: La verdad es que es una de mis asignaturas pendientes, aunque es así por lo que comentaba más arriba, aparte de mi equipo principal, sólo suelo usar Vim en servidores remotos, y tampoco me gusta la idea de dejarlos llenos de “cosas”, y como me siento cómodo con lo mínimo, lo más que suelo hacer es añadir la opción “nocompatible” al vimrc para poder usar Vim en todo su potencial, y poco más, alguna que otra opción.

Aún así, reconozco que debiera tener una versión ligera con lo necesario de mi extenso vimrc (más que nada de los ficheros accesorios, pues el vimrc poco tiene y sincronizarla de alguna forma, pero si no lo he hecho es porque no me ha molestado mucho ;-).

Vhck: ¿Cual crees que es el “secreto” para dominar Vim? ¿Algún recurso que utilizaste en su día y que quieras recomendar?

Ignacio: No recuerdo cómo comencé a aprenderlo, creo que el comando h(elp) XD, sobre todo por lo que expliqué al comienzo sobre como funciona mi cerebro y la facilidad para aprender “cosas raras” sobre la marcha, pero cuando explico Vim a alguien suelo recalcar la importancia de entender perfectamente los 3 comandos básicos (evidentemente comenzando por tener clara la filosofía modal de funcionamiento), los modificadores de movimiento y las operaciones relativas para poder usar el ‘.’ y repetir operaciones (con eso se tiene mucha potencia).

Luego ya hacer búsquedas y reemplazos, quizá por curiosidad la grabación de macros o el comando ‘g’, y así seguir ya con el maravilloso mundo de las extensiones :). Y si a alguien le gusta aprender jugando, que visite https://vim-adventures.com/ ;-).

Vhck: ¿Alguna vez te has planteado utilizar otros editores de texto para tu trabajo? ¿Por qué seguiste usando Vim frente a otras opciones?

Ignacio: Creo que esto ya está contestado más arriba, por ahora creo que seguramente no cambiaré, teniendo en cuenta que no considero un cambio la forma en que me he pasado a Vscode. Básicamente la memoria muscular adquirida hace muy complicado que encuentre algo que sin el vim por detrás me haga mejorar mi productividad.

Vhck: ¿Te importaría compartir una captura de pantalla de tu Vim?

Ignacio: Por supuesto, te adjunto una de mi NeoVim en terminal (pues lo sigo usando bastante en paralelo con Vscode, por lo de usar el teclado y eso :), aunque no se ve mucho, me gusta tener pocas distracciones a la vista.

Vhck: Muchas gracias por tu tiempo y por responder a estas preguntas. La última palabra es tuya para decir lo que quieras:

Ignacio: Pues nada, agradecerte a ti también el haberme dado la posibilidad de hablar de algo que me gusta mucho y forma parte importante de mi día a día, y ya sabes, sigue con tu “evangelización”… es broma ;-), con tu curso “improVIMsado”.

La verdad es que se me quedan en el tintero muchísimas cosas, aunque bastantes de ellas las has comentado en tu blog, pero igual le doy una segunda lectura más profunda y te paso un día de estos una lista con lo que me venga a la mente y crea que te pueda servir a ti y a otros usuarios.

Espero no haberme enrollado mucho, aunque viendo lo que se me va ocurriendo cada vez que reviso el texto, podría haber sido mucho peor y siento que me quedé muy corto ;-).

Espero que la entrevista os haya parecido tan interesante e inspiradora como me ha parecido a mí. Un placer leer las respuestas de un usuario de Vim con tanta experiencia y tanto uso de este editor de texto.

Quizás al leer sus respuestas veas un paralelismo con tu experiencia personal, o quizás no, pero espero que en ambos casos te haya resultado interesante la lectura.

Y ahora que tan de moda se ha puesto la palabra y los podcasts, reivindico la palabra escrita (por la que Ignacio también tiene preferencia) porque a la hora de buscar algo, podemos encontrarlo sin necesidad de tener que escuchar todo.

Como decía un compañero de trabajo: “Lo escrito, se puede leer”. Una perogrullada que guarda verdad. Ahí queda para disfrutarlo a la dosis que quieras.

Tienes los comentarios del blog para compartir tu opinión al respecto de la entrevista, me gustaría leerlas.

I am happy to say that I now have published my openSUSE Breeze Dark Plasma Style for the world to use. If the color scheme I have previously release is any indicator of interest, there will be a few dozen that download it and that is good enough for me. I will be quite content … Continue reading openSUSE Breeze Dark Plasma Style →

Η ασχολία μου με το ελεύθερο λογισμικό περιορίζεται κυρίως σε θέματα engagement (προώθηση, άρθρα, ομιλίες σε συνέδρια, παρουσίες σε συνέδρια κλπ) και σε μεταφράσεις. Η αλήθεια είναι ότι όλα αυτά τα χρόνια, εάν είχα ξεκινήσει την εκμάθηση μιας γλώσσας προγραμματισμού, τώρα θα ήμουν ειδικός.

Από τα χρόνια που ασχολούμαι με το ελεύθερο λογισμικό, έχω έρθει σε επαφή με πολλά άτομα, η πλειοψηφία των οποίων μου έχει πει ότι όλες τις γνώσεις περί μιας γλώσσας προγραμματισμού, δεν τις έμαθε στο πανεπιστήμιο. Όλοι διάβασαν και ασχολήθηκαν μόνοι τους.

Ακόμη μια αλήθεια είναι ότι εάν γνωρίζεις μια γλώσσα προγραμματισμού, είναι εύκολο να μάθεις την επόμενη. Προφανώς γνωρίζεις τον τρόπο εκμάθησης και επίσης πολλές τεχνικές μπορεί να είναι ίδιες.

Ας δούμε όμως κάποια tips για το πως μπορείτε να μάθετε μια ΝΕΑ γλώσσα προγραμματισμού:

1. ΑΠΟΦΑΣΙΣΤΕ ΤΟ ΜΕΣΟ ΕΚΜΑΘΗΣΗΣ

Μέσο εκμάθησης εννοείται εάν θα είναι βιβλίο, εάν θα είναι κάποιο ασύγχρονο μάθημα στο διαδίκτυο ή κάποιον άλλο τρόπο που θεωρείτε εσείς ότι σας ταιριάζει. Εάν μάλιστα θέλετε να μάθετε την γλώσσα προγραμματισμού με ένα φίλο σας, τότε φροντίστε να διαβάζετε από τον ίδιο τίτλο. Σε περίπτωση που κάποιος έχει πρόβλημα, μπορεί ο άλλος να τον βοηθήσει.

Μαθήματα online (δωρεάν και επί πληρωμή):
https://www.w3schools.com/
https://www.udemy.com/
https://www.coursera.org/
Πολλές σειρές στο Youtube (τόσο στα Ελληνικά, όσο και στα Αγγλικά)

2. ΝΑ ΜΑΘΑΙΝΕΤΕ ΛΙΓΟ ΚΑΘΕ ΜΕΡΑ

Αφού αποφασίσατε το μέσο εκμάθησης, σειρά έχει η συχνότητα. Προσπαθήστε να διαβάζετε από λίγο κάθε μέρα. Αυτό θα είναι πχ 10 λεπτά από τον χρόνο σας; Θα είναι η ολοκλήρωση του κεφαλαίου; Χωρίστε το ανάλογα με τις αντοχές σας.

Θυμηθείτε ότι η συχνότητα είναι πιο σημαντική της ποσότητας. Εάν αφήσετε κάτι, θα σας αφήσει και αυτό.

3. ΑΚΟΛΟΥΘΗΣΤΕ ΤΗΝ ΣΕΙΡΑ ΤΟΥ ΜΕΣΟΥ

Όταν ξεκινάτε την ανάγνωση, μην παρακάμπτετε σελίδες, θεωρώντας ότι γνωρίζετε τι λέει. Συνήθως θα παρακάμψετε πολλές σελίδες που μπορεί να έχουν μια πληροφορία που δεν την γνωρίζετε και στις παρακάτω σελίδες να την χρησιμοποιήσουν, οπότε θα ανατρέξετε στα προηγούμενα ή μπορεί και να εκνευριστείτε και να σταματήσετε.
Οι συγγραφείς του μέσου, έχουν μια λογική σειρά που θα οδηγήσουν σε κάποιο τελικό αποτέλεσμα. Πιθανό να λείπουν κάποιες πληροφορίες για προχωρημένους. Στο χέρι σας είναι να ψάξετε, έχοντας την βάση της γλώσσας προγραμματισμού.

4. ΠΩΣ ΝΑ ΜΗΝ ΞΕΧΝΑΩ;

Η απάντηση στην ερώτηση είναι ότι μαθαίνεις με την επανάληψη. Πως θα κάνεις την επανάληψη; Προχώρησε ένα βήμα παραπέρα. Προσπάθησε να λύσεις ασκήσεις που θα κάνουν χρήση των γνώσεων που έμαθες. Έτσι θα μάθεις πως χρησιμοποιείται η τεχνική ή η εντολή.

5. ΞΕΚΙΝΑ ΔΙΚΟ ΣΟΥ PROJECT

Με λίγα λόγια εξάσκηση. Όταν ξεκινάς ένα δικό σου project θα ψάχνεις πως γίνεται μια τεχνική που δεν γνωρίζεις-έμαθες. Θα κάνεις μια αναζήτηση πχ σε stack overflow.

Εσείς μαθαίνετε κάποια γλώσσα προγραμματισμού; Αν ναι, υπάρχουν κάποια tips που θέλετε να τα μοιραστείτε;

Tal y como estaba previsto en el calendario de lanzamiento de los desarrolladores, hoy martes 23 de febrero la Comunidad KDE ha comunicado que ha sido lanzada la primera actualización de Plasma 5.21. Una noticia que aunque es esperada y previsible es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran entorno de escritorio de Software Libre.

Lanzada la primera actualización de Plasma 5.21

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes 23 de febrero ha sido lanzada la primera actualización de Plasma 5.21, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones. Es por tanto, una actualización 100% recomendable.

Más información: KDE

Las novedades básicas de Plasma 5.21

Os dejo las novedades más destacada de esta nueva versión son:

• Nuevo lanzador de aplicaciones que presenta una interfaz de usuario de doble panel, mejoras en la navegación con el teclado y con el ratón, mejor accesibilidad y soporte para idiomas con escritura de derecha a izquierda.
• Mejoras visuales en el tema por defecto de Plasma que disponen ahora de una combinación de colores renovada y lucen un nuevo estilo de barra de encabezado unificado con un aspecto limpio y refrescante.
• Presentación de Breeze Crepúsculo («Twilight») nevo tema oficial disponible que combina lo mejor de los temas claros y oscuros.
• Nueva interfaz de información del sistema llamdo Plasma System Monitor para monitorizar los recursos del sistema construido sobre Kirigami y un servicio de estadísticas del sistema llamado «KSystemStats».
• Mejoras y avances importantes en Kwin con Wayland cuyo código de composición de KWin se ha refactorizado mejorando la latencia (tiempo de respuesta del escritorio) .
• Nueva página para las «Preferencias del sistema»: las preferencias del cortafuegos de Plasma. Este módulo de configuración le permite ajustar y editar el cortafuegos de su sistema y constituye una interfaz gráfica para «UFW» y «firewalld».