New tiny project: lddsafe

Some days ago we could all read that “ldd”, a tool which prints shared library dependencies, should not be run on untrusted binaries. I read it first on Hacker News and later it hit Slashdot’s frontpage. In some operating systems, this is stated clearly in the man page for the program, while in others it’s not mentioned at all. I belonged to the camp that didn’t know about it and I was a bit surprised. I supposed ldd was doing its job by examining the binary file and not by running it setting some special environment variables.

A Hacker News user, anyway, pointed out something interesting. You can easily get information about the needed shared library dependencies for a program or library using “objdump”, so I spent a few hours writing and tweaking a small script called lddsafe that prints almost the same information as “ldd” using “objdump” and avoiding the security problems, as it doesn’t have to run the program. Two major caveats at this point in time:

• It requires bash and, more specifically, bash version 4 or later. I needed to use associative arrays to make the program reasonably fast and they are only available in bash 4.
• It’s only been tested under Slackware Linux. However, bug reports and patches are welcome if it doesn’t run properly in other distributions.

Future improvements may include rewriting it in Perl so as not to require bash 4, knowing that Perl is present in most Unix systems.

A picture is worth a thousand words:

$ lddsafe /usr/bin/xcalc
        libXaw.so.7 => /usr/lib/libXaw.so.7
        libXmu.so.6 => /usr/lib/libXmu.so.6
        libXt.so.6 => /usr/lib/libXt.so.6
        libSM.so.6 => /usr/lib/libSM.so.6
        libICE.so.6 => /usr/lib/libICE.so.6
        libc.so.6 => /lib/libc.so.6
        ld-linux.so.2 => /lib/ld-linux.so.2
        libuuid.so.1 => /lib/libuuid.so.1
        libX11.so.6 => /usr/lib/libX11.so.6
        libxcb.so.1 => /usr/lib/libxcb.so.1
        libXau.so.6 => /usr/lib/libXau.so.6
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
        libdl.so.2 => /lib/libdl.so.2
        libXext.so.6 => /usr/lib/libXext.so.6
        libXpm.so.4 => /usr/lib/libXpm.so.4
        libm.so.6 => /lib/libm.so.6

GDB now supports stopping on system calls

One of the best moments in my professional career, from a pure personal perspective, came about 6 weeks ago when I was able to find out the cause of a memory leak one of our programs was suffering, and it turned out to be a problem in a standard library function completely unrelated to memory management. I am very proud of that moment because it took me a lot of time to find the problem and I had to apply a good amount of knowledge I did not expect to apply as a professional. When I could finally prove the memory leak was in the library function, using a short (20 lines) demonstration program, I felt simply happy. The drama was over.

Our program has soft real-time requirements and is written mostly in Ada, with a few calls to C library functions via pragmas. Due to the nature of the program, it avoids memory allocation as frequently as possible and uses static-sized arrays for its data structures, and O(1) algorithms whenever possible to behave properly in the context it is being used.

I will completely skip the part of the story dealing with analysis of the source code in vain to find where the program was leaking memory, but I can tell you it took a lot of time and did not give any positive results, making us quite angry and desperate. We would have been unable to find the problem this way. As I said before, the leak was in a standard library function from an expensive software development kit for Ada, and had nothing to do with memory allocation functions. To be more precise, the memory leak was in Text_IO.Reset, a procedure that resets the state of a text file, very similar to rewind in C. I will head to the final steps, what I considered interesting.

The program runs on Solaris, so we monitored the process using pmap. This gave us precise information and told us clearly that the memory region that was growing was the heap, where memory allocation happens. I thought that, if our program was barely doing any memory allocation operations, and normally it should be doing none, according to the code, we had a good chance of catching it leaking memory. When a program in Unix needs more memory, it calls either mmap, brk or sbrk. I could not come up with more system calls that allocated memory. Normally, when you program in C or C++ you use malloc, free, new and delete. These language operators or library functions in turn manage memory blocks but request more memory to the operating system with the previous system calls I mentioned. It is explained in many books and tutorials over the Internet but I would say, and maybe I am wrong, that it is not exactly common knowledge.

My first approach, which did not work, involved creating a shared library that I would load using LD_PRELOAD, which intercepted calls to sbrk, brk and mmap. When intercepted, it would call pstack on the current process (a program that prints the call stack of any process given its pid), save the call stack to a text file and proceed with the normal system call. Hackish and clever, I thought while laughing like a maniac when I was coding that. Well, that did not work, I repeat. While the program was indeed calling sbrk as confirmed by truss (for Linux users, truss is very similar to strace), it was not calling, apparently, any function called sbrk that I could intercept. I created a test program to see if my library worked and it did, but it did not create any stack trace for the program in question.

Still, I had already started using truss to verify the program was allocating memory with sbrk, so I dived into the truss manual to see if I could use it for something else. This way I discovered that truss was able to stop the program execution when it made any system call I specified. My new approach was, then, tracing the program with truss, stopping in sbrk, then calling pstack on the PID and then telling the program to continue running. This almost worked. The printed stack did not have any symbols, probably due to the Ada compiler not populating the executable file with the debugging information as the C compiler did. So close yet so far. Our programs were indeed compiled with debugging information, and a minor change to the strategy was enough. Instead of printing the stack with pstack, I would attach the Ada debugger to the program and print the call stack. This way, I finally witnessed the program leaking memory in what seemed to be a call to Text_IO.Reset.

I thought this could be wrong, so I created a test program that read a file over and over again, calling Text_IO.Reset when reaching EOF. The test program, indeed, leaked memory at an alarming rate. Case closed, smile and surprise in my face. Well, to be honest, we replaced the calls to Text_IO.Reset with something else and tested again, to confirm the program had stopped leaking memory. But I already knew the problem had been found after running the test program.

When I came home I wondered if I could have done something similar in my Linux system. I read the man page for strace to see if it could stop programs when a specific system call was made, but I found no way of doing so. Apparently, the solution and the strategy I had employed was Solaris (or maybe UNIX) specific. Several Google searches did not give me any clue about doing the same in Linux.

Yesterday, however, GDB 7.0 was released. I took a look at the new features and I found this little sentence at the end of it:

* New command to stop execution when a system call is made

According to the documentation, you only need to set a cathpoint for the program like catch syscall sbrk to achieve the same. Two months ago, I would have read the features and forgotten them five minutes later. But, yesterday, I again smiled, then laughed like a maniac and shouted “BEGONE, MEMORY LEAKS!!!”.

GNU grep is slow on UTF-8

Thanks to someone on the ##slackware FreeNode IRC channel that mentioned the problem some weeks ago, I discovered that GNU grep is very slow when working on UTF-8 filenames, and possibly other Unicode encodings. This, apparently, is a long-standing bug that hasn’t been officially fixed yet. The problem manifests itself when you run grep using locale settings that involve using UTF-8. Let’s see the following example:

$ echo $LANG
en_US.UTF-8
$ time grep '^....' /usr/share/dict/words >/dev/null 

real    2m16.795s
user    2m10.536s
sys     0m0.087s
$ export LANG=C
$ time grep '^....' /usr/share/dict/words >/dev/null 

real    0m0.031s
user    0m0.028s
sys     0m0.003s

In the previous text, /usr/share/dict/words is a file part of the bsd-games package in my Slackware system. It contains a list of English words and it’s not too long. It has below 40000 lines, each line having a word, and weights about 345 KB. Still, as you can see in the previous example, it takes more than 2 minutes in my computer to search for words having at least 4 characters. When I change my locale settings to “C” (ASCII), it only takes 31 milliseconds. The difference is amazing. Does grep behave differently in both cases? The answer is yes.

When grep runs in UTF-8 mode, the dot character, for example, represents any multi-byte character, while in ASCII mode the dot represents a single byte. See for example the following, using an accented Spanish character to form a 5-letter word.

$ echo ámbar | LANG=C grep '^.....$'
$ echo ámbar | LANG=en_US.UTF-8 grep '^.....$'
ámbar

The á character is represented using two bytes in UTF-8. Using the UTF-8 locale, grep correctly identifies it as a single character. Hence, my search for a 5-character word inside the file correctly returns 1 result. With LANG=C, no results are found. This feature is not, however, worth making grep so slow.

If you try to reproduce the problem above, probably you will not succeed, at least in your Linux system. This is because most Linux distributions are well aware of the problem and ship a patched GNU grep, and have been doing so for years. Debian does it (and with it, Ubuntu), Archlinux does it, Fedora does it, etc. Other distributions like Slackware traditionally ship software as vanilla as possible, and the problem shows, as seen above. Slackware’s GNU grep is completely vanilla. Most distributions use slightly different versions of the same patch, which replaces the MBS (Multi-Byte Sequence) treatment almost completely.

In my most recent scripts, I avoid GNU grep altogether, and use the fantastic and very efficient PCRE library (Perl Compatible Regular Expressions), used by many open source software projects (e.g. the Apache web server). The pcre package is present in most Linux distributions and BSD ports systems. It will probably ship the pcregrep tool inside. This is an alternative grep which features compatibility option-wise with the most common POSIX and GNU options, like -n, -l, -r, -w, etc. It expects, however, a Perl regular expression. They are, in the most common cases, like every other regular expression syntax out there, but closer to egrep than grep. By default, pcregrep behaves like grep with the LANG=C locale, even if your locale specifies that you are using UTF-8. It’s this fast:

$ time pcregrep '^....' /usr/share/dict/words >/dev/null 

real    0m0.061s
user    0m0.042s
sys     0m0.003s

A bit slower than grep with C locale, yes, but not a problem. In addition, you can activate UTF-8 mode to enable compatibility with multi-byte characters by using the -u option, explicitly. In this mode, pcregrep is not much slower:

$ time pcregrep -u '^....' /usr/share/dict/words >/dev/null

real    0m0.068s
user    0m0.049s
sys     0m0.002s

Of course, it’s able to behave correctly in the previous UTF-8 test with the -u flag:

$ echo ámbar | pcregrep -u '^.....$'
ámbar

Moving away from GNU grep to pcregrep is not a bad option. You get consistently fast behavior, regular expression syntax compatible with Perl, and get to choose if you want UTF-8 compatibility or not by providing an explicit option. So long, GNU grep! Welcome, pcregrep!

Final note: GNU awk suffers from this problem too, but its behavior with a UTF-8 locale is more or less equivalent to a patched grep. Still a bit slow, though.

$ time awk '/^..../' /usr/share/dict/words >/dev/null

real    0m0.373s
user    0m0.342s
sys     0m0.003s
$ export LANG=C
$ time awk '/^..../' /usr/share/dict/words >/dev/null

real    0m0.075s
user    0m0.055s
sys     0m0.002s

Reclamación a Jazztel

Note: the following post narrates a complaint I filed against a Spanish telco. To maximize the usefulness of this post for people in Spain having a similar problem, it’s written entirely in Spanish.

Este verano tuvimos un problema con la empresa Jazztel cuando intentamos contratar el servicio de ADSL con ellos. Por si alguien tuviera el mismo problema, a continuación describiré los hechos desde mi punto de vista y los pasos que seguimos para que la reclamación se resolviese a nuestro favor.

Los antecedentes son sencillos. Contábamos con una línea de teléfono contratada con Telefónica. El servicio ADSL nunca ha estado disponible en esta línea, por motivos técnicos que no tengo totalmente claros. Hace unos años intentamos contratar ADSL con dicha empresa, pero no funcionó y tuvimos que devolver el router, costeando nosotros los gastos de la devolución del mismo. Desde entonces, siempre hemos tenido cuidado de rechazar todas las ofertas de ADSL que recibíamos por teléfono de otras operadoras, conscientes de que no funcionaba en nuestra línea. Como prueba, siempre comprobaba la disponibilidad del servicio ADSL en el sitio web www.telefonicaonline.com, que indicaba que el servicio ADSL no se encontraba disponible para nuestra línea.

En el mes de abril, debido supuestamente a unas mejoras técnicas en la zona, comenzamos a recibir una nueva oleada de llamadas teléfonicas de varias operadoras ofreciéndonos ADSL, entre ellas Jazztel, aunque eso carece de importancia. Rechazamos todas las ofertas pero, sorprendidos por la nueva oleada de llamadas, comprobamos una vez más la disponibilidad de ADSL para nuestra línea. En esta ocasión, por primera vez desde hace años, se indicaba que nuestra línea soportaba un servicio básico de 1 Mb y no más. Animados por la impresión de que quizás la mejora técnica fuese real y pudiéramos, en 2009, contratar ADSL y prescindir por fin de otras alternativas más caras y peores como conexión 56k y, recientemente, conexión con módem 3G, comparamos precios y ofertas.

La oferta más atractiva era la de Jazztel. A través de su web, jazztel.es, contratamos el servicio ADSL+Llamadas con conexión de 1 Mb. No recuerdo la fecha exacta en la que se hizo esta solicitud, pero fue a finales de abril. Jazztel envía a casa un router inalámbrico que llega el día 11 de mayo. Junto con el router, recibimos bastante documentación de bienvenida y una carta clara en la que se nos indica que la activación del servicio se comunicará mediante un mensaje de texto SMS al teléfono móvil indicado en el proceso de contratación. Jazztel permite consultar el estado del proceso de alta a través de su web, e inicialmente nos indica que el servicio estaría disponible a primeros de junio, aunque la fecha va variando ligeramente según avanza el proceso. Nosotros, en cualquier caso, estamos atentos a posibles mensajes de Jazztel y, además, periódicamente realizamos pruebas conectando el router para ver si se enciende el indicador marcado como “ADSL”, que indica que la conexión está disponible.

Sin embargo, pasan bastantes días y todo sigue sin funcionar. Finalmente, el día 8 de junio recibimos una factura de Jazztel, en la que se cobra por el servicio desde el día 2 de mayo al 14 de mayo, y se nos cobra una cuota de ADSL proporcional a 2 días, 13 y 14 de mayo, como si el servicio se hubiera activado el 13. Nosotros no recibimos ningún SMS y las pruebas que íbamos realizando eran todas con resultado negativo. Motivados por la llegada de la factura, realizamos una nueva prueba y comprobamos que el indicador ADSL no se activa. Llamamos ese mismo día a Jazztel.

La primera persona que nos atiende nos ayuda a realizar unas cuantas comprobaciones y pruebas durante un buen rato. Cuando nada de lo que probamos funciona nos transfiere con otra persona, que se identifica como un “técnico de nivel dos”, o una expresión similar. Seguimos haciendo pruebas con esta persona hasta que, finalmente, nos comunica que la distancia a la centralita parece excesiva y que nuestra línea no es adecuada para ofrecer el servicio ADSL, por lo que pasa a declarar la línea como no válida para ADSL, y nos asegura que se nos devolverá todo el importe del ADSL a partir de ese momento en cada factura. Le preguntamos si se nos va a devolver también el importe cobrado hasta ese momento. Este es el origen de casi todo lo que sucede a continuación. Lógicamente, desde nuestro punto de vista, habría que devolver todo lo cobrado por ADSL. Nunca se nos dio ese servicio, y el informe técnico que acredita que nuestra línea no es válida para ADSL supone una afirmación implícita de que no sólo no funciona a partir del día 8 de junio, sino que nunca lo ha hecho. Si nunca ha funcionado, no se nos debería facturar nunca, y lo facturado ha de devolverse. Sin embargo, la burocracia comienza de nuevo a partir de ese momento y el técnico dice que, para saber si se nos va a devolver todo lo cobrado hasta ese día, tendremos que consultarlo con una persona de facturación, que nos llamará a lo sumo en un plazo de una semana a partir de ese instante.

Como viene siendo costumbre y ya comenzamos a intuir, Jazztel realmente no nos llama. Nosotros esperamos y lo vamos dejando de lado hasta que, finalmente, decidimos llamar el día 27 de junio (20 días más tarde). La persona que nos atiende nos permite reclamar la devolución de cualquier factura posterior al 8 de junio, el día que la línea se declaró como no válida para ADSL, pero no antes. Esta es la primera noticia que tenemos en la que se nos niega explícitamente la devolución de lo cobrado antes del 8, por lo que mostramos nuestro desacuerdo. Como suele ser habitual en estos casos, la persona al otro lado de la línea parece incapaz de hacer nada por nosotros.

A partir de este día nuestras acciones se dividen en dos grupos. Por una parte, tenemos que seguir reclamando las facturas que nos van llegando, donde no se bonifica el importe del ADSL. Cuando recibimos una, tenemos que reclamarla y se indica que el importe se regularizará en la factura siguiente. Naturalmente, es bastante irritante que esto suceda así. Cuando nos dicen que se nos va a devolver todo lo cobrado por ADSL a partir del día 8, uno espera que eso suceda automáticamente y en la factura del mismo mes.

Por otra parte, realizamos dos reclamaciones a Jazztel para intentar que se nos devuelva lo facturado antes del día 8. Una primera reclamación por teléfono, donde relatamos nuevamente los hechos e insistiendo en la declaración de la línea como no válida para ADSL. Jazztel la rechaza. Realizamos una segunda reclamación por escrito a atencion.al.cliente@jazztel.com, exponiendo en detalle la cronología de los hechos y nuestra opinión de que lo justo es devolver todo lo cobrado. También es rechazada. A partir de aquí, lógicamente, las vías directas para hablar con la empresa se consideran agotadas, así que intentamos informarnos y ver qué se puede hacer para que se devuelva todo el importe.

Acudimos a la Junta Arbitral de Consumo del Principado de Asturias. Es una opción de la que ya habíamos oído hablar, y viene a ser como un juicio pero sin abogados y sin costes. Si la empresa decide que esa vía le parece adecuada, puede acudir y comprometerse a acatar la resolución del árbitro. Sin embargo, primero hay que comprobar si la empresa está suscrita a la junta arbitral, y la persona que nos atiende en la Junta nos indica que, quizás, la vía más adecuada para nuestra reclamación es la Oficina de Atención al Usuario de Telecomunicaciones, sita en Madrid.

El mecanismo es bastante sencillo: se escribe una carta o se envía un burofax a esta oficina. Ellos evalúan nuestro caso y la documentación aportada. Si lo creen conveniente, ponen una queja ante Jazztel en nuestro nombre, y Jazztel está obligada a responder en un plazo de 6 meses. Si resuelven la reclamación de forma negativa, habría que acudir a los tribunales. Cuando se empieza a hablar de meses de plazo uno comienza a sentirse defraudado y con la sensación de estar caminando entre fango cada vez más profundo, pero igualemente decidimos probar. Enviamos una carta el día 22 de julio, redactando nuevamente los hechos y adjuntando fotocopias de las facturas y todo el material que tenemos. No nos sale muy caro todavía.

La respuesta de Jazztel es sorprendentemente rápida. Se pone en contacto con nosotros el día 12 de agosto. Indicamos que estamos de vacaciones en el extranjero, así que se pondrán en contacto con nosotros a la vuelta. Mala suerte, pero todavía no he mirado cuánto costó esa llamada. En cualquier caso, llaman nuevamente el 24, preguntan si somos nosotros los que hemos puesto la reclamación y deciden que, lógicamente, por supuesto que tenemos razón. Se nos devolverá el importe facturado y, además, para no tener que reclamar la bonificación con cada factura, se tramitará la baja del servicio de ADSL+Llamadas inmediatamente, quedando únicamente el servicio básico de voz. Todo pinta muy bien, aunque esperamos la llegada de la siguiente factura.

En cualquier caso, son destacables varios hechos. Sin nada que ver con asuntos xenófobos, la persona que nos llama el día 12 y 24 y de agosto es una persona española, con acento español de España. Todas las personas con las que habíamos hablado anteriormente tenían acento sudamericano, posiblemente argentino. Cuando ocurre así, uno tiene la sensación de estar hablando con alguien subcontratado y que, sea como sea, tiene poco poder para decidir nada. Sin embargo, en agosto uno tiene la sensación de que ha hecho el ruido suficiente como para llamar la atención de alguien con poder para solucionar el problema.

Además, el importe reclamado es desde el día 13 de mayo al 8 de junio, y no supera los 30 euros. La queja a través de la Oficina de Atención al Usuario de Telecomunicaciones es una señal clara de que estás dispuesto a llegar relativamente lejos, y el paso siguiente es potencialmente más costoso para ellos que para ti. Recomiendo a cualquier persona que tenga este tipo de problemas, que haga lo mismo que hicimos nosotros. Si la reclamación es lógica y justa, hay que tomar buena nota de las fechas y los números de reclamación e incidencia que nos van dando. Si las reclamaciones directas a la empresa fallan, la Oficina de Atención al Usuario de Telecomunicaciones es una opción que ha funcionado a la perfección en nuestro caso.

También he de manifestar mi decepción con Jazztel. La empresa, a través de su sitio web cuando contratas uno de sus productos, manifiesta su compromiso de antender al cliente adecuadamente y dar una buena atención al usuario. Esta era sin duda una oportunidad para Jazztel de demostrar que, efectivamente, esto es así. Sin embargo, Jazztel, sea como fuere y debido a las razones que sean (mala organización interna de su servicio de atención al cliente, imposibilidad de los operadores de tomar la decisión adecuada, etc), nos rechazó una reclamación que tenía toda la lógica del mundo, negando tres veces como San Pedro[1]. A día de hoy podríamos estar contentos con Jazztel pensando en lo bien que nos han atendido y cómo han dejado que la razón caiga por su propio peso aunque perdieran algo de dinero. Sin embargo, la imagen que nos han dejado es la de una empresa que se comporta igual que las demás empresas grandes cuando surgen problemas: mirar para su propio bolsillo y negarse a actuar de forma lógica y justa hasta que una fuerza mayor se lo reclame.

[1] A pesar de ser agnóstico, creo que he conseguido adornar el texto con una referencia exitosa a un pasaje bíblico.

Article mentioning slackroll in distrowatch.com

Update: the article this post refers to has been updated and the slackroll part has been removed, citing this post as the cause of its removal. I have not been contacted by anyone yet (“Contact me”, on the right column), but I saw people were coming from the article page in the blog statistics and simply checked it out.

On May 18, 2009, as part of a feature called “DistroWatch Weekly”, distrowatch.com published an article on slackware-current. The author of the article recommended using slackroll to upgrade to slackware-current and suggested how to do so with a few commands. As the author of slackroll, I am forced to comment on it. I already did when the article popped up at linuxquestions.org a few days later, but this is the official statement apart from my initial comments. As most official responses and press releases, this one comes too late.

First, I wanted to comment on my reply to the thread at linuxquestions.org. As you can see, it is not a very polite response. I was not aware that the article existed until I opened the thread, and I did some minutes before going to sleep. I was supposed to be sleeping at that time, because the next day I had to get up early and go to work. I was not happy at all with the article contents, it was too late to write something elaborate, but I had to write something because the article was probably spreading. My initial intentions were to reply to the article directly in distrowatch.com. Unfortunately, it’s not a web site I follow at all. The page containing the article has several more, and I was not sure comments were allowed. As I didn’t see a way to post a comment below the article end, I supposed it was not possible, not realizing comments were at the bottom of the page. Still, apparently you need to be a registered user to post comments, as I am unable to find a way to do it as of today.

I have no personal opinion about the article author. If you read my post at linuxquestions.org and feel some of my words are personal attacks, take into account they are not. He or she is probably a nice person who thought it was a good idea to write that article. I always thought if someone was to write an article about my program for a popular web site or magazine, they would contact me first to inform me and maybe even ask me to review the article and point out mistakes. Experience, on the other hand, has shown this does not happen. This is a lesson to be learned. I will always contact the program author if I ever write an article about it in an important web site or publication, but this is not what people do, apparently. If he or she had contacted me previously, I would have pointed out that the article was completely wrong in many points and that people should not try to do what the article suggests. A popular program I made is youtube-dl. It gained a lot of popularity with an article Joe Barr (RIP) published about it in linux.com. He did not contact me, and it even reached the front page of digg.com before I found out about it. A couple more articles about youtube-dl have been published in printed press and nobody has contacted me before publishing them. Now, this article about slackroll confirms the tendency.

Repeating my words at linuxquestions.org, I completely discourage installing slackroll and proceeding as the article suggests. Furthermore, for good in a sense, the method the article describes doesn’t work. This can prevent a lot of people from making a mess with their Slackware 12.2 installation. Still, it hurts slackroll’s reputation. It barely has any reputation at all, given the fact that it’s used by a handful of people in the world (I estimate less than 50 users worldwide). In that situation, any publicity it gets is going to deeply mark the opinion people have on the tool, so it’s important that it’s good publicity, as I don’t want slackroll associated with “not working” and “breaking people’s systems”. Some people say “there’s no such thing as bad publicity”, but I do not share that view.

About the article contents their selves, the simplest statement I can make is “it is all wrong”. As I already did in my comment at linuxquestions.org, I am going to point out all the mistakes and misconceptions so people have a clear view of the program and in an attempt to wash its public image a little bit. Before it even starts talking about slackroll, the article says that the proper way of upgrading to slackware-current is to “download each individual software package from the current tree and install it with pkgtools. Given that this tree gets on average 2 – 3 updates per week, some of which could contain dozens of packages, this would be very time consuming indeed!”. The reality is that, even if you use a tool to upgrade, you are still going to download all those packages probably, and installing them with pkgtools only takes writing a simple shell loop, so it is not very different. I won’t comment on anything about slackpkg, because I only used it briefly before starting to work on slackroll and I don’t remember the details well enough.

Starting the first comment about slackroll, it says “This tool was specifically designed for those who prefer to run Slackware “current” and want to keep it up-to-date with minimum of fuss.”. This is not true. In the beginning, as I was using slackware-current and the method to upgrade a slackware-current system differs a bit from upgrading slackware-stable, the program only worked with slackware-current, but this was long ago. slackroll has, as of today, 33 releases. Support for slackware-stable was added before making the first official one, so this comment is completely false. It was not specifically designed to “run slackware-current and keep it up-to-date with a minimum of fuss”.

It says “Slackroll works by parsing the Slackware ChangeLog, which is provided in a standard format that hasn’t changed in years, and it comes with tons of options and good documentation on its web site”. The latter part is an opinion that I share. I think slackroll has good documentation. It could be much better but it does have a lot of operations. The first part is completely bogus, though. slackroll does not work by parsing the change log. It parses the slackware change log, that is true, but it does not work by parsing it. Parsing the change log is an additional minor feature that is intended to help users read new change log entries easily, but the real work is done by downloading and parsing a file called FILELIST.TXT, which is present in every Slackware mirror. This is the file slackroll uses to see the which packages are present in the mirror and compare that to the previous situation, noticing if there is a new upgrade, package addition or removal.

The next sentence reads “Personally, I have never had any trouble using slackroll, but as always, this is an unsupported utility, so if something breaks, you are on your own”. The first part is a bit surprising, like I said at linuxquestions.org. If he or she did follow his own method to upgrade to slackware-current in the past, his or her system could be broken by now. The second part is also not true. I can answer questions about slackroll using its bug-tracker, by email, on IRC (I visit the ##slackware channel at Freenode from time to time) and also in the forums at linuxquesions.org. You are not on your own if you have a problem using slackroll.

Finally, it proceeds to list the steps to upgrade to slackware-current with slackroll. Those steps were already not working in the moment the article was published, but this is good in the sense that you will not be able to break your system by performing those steps. The first thing I should say is that, in order to use slackroll, you should always start by reading its tutorial. The program needs to be configured a little bit before attempting to do anything like upgrading packages, and it is recommended that you do this without upgrades pending. It is very important, crucial I’d say, yet the article fails to mention it at all. If you want to upgrade to slackware-current from -stable, you should first set a -stable mirror matching your Slackware version and be sure no upgrades are pending. Only after going through the initial set up process, you should change to a slackware-current mirror to attempt to upgrade. Upgrading involves doing several steps that are very particular to the specific release and they change slightly from version to version. Once you know slackroll, you may realize you can use it to perform the upgrade steps more easily, but the upgrade steps have to be followed carefully. This is important but not mentioned in the article either.

The document you would be looking for is called CHANGES_AND_HINTS.TXT, and hasn’t been updated yet with the correct procedure as of the time I’m writing this. During the last weeks, there have been many important changes in slackware-current like the change to a new package compression format or the release of slackware64-current. If you want to upgrade to slackware-current, I think you need to install the new xz package first, then upgrade pkgtools and finally you can proceed to upgrade the rest of key packages, install new packages, upgrade, and remove old packages as the tutorial mentions. Without those special steps, you will not be able to upgrade. For example, one of the first upgrades you will probably want to make is glibc-solibs, and it is compressed as txz, so you need xz and the new pkgtools to begin with.

That pretty much covers it all. Every program I have published so far is a simple or even trivial tool with few lines of source code. slackroll is not very complex, but it is by far the most complex of the ones I have published and I’m very proud of how well it works. I use slackroll and putmail.py a lot. youtube-dl, while being much more popular, is not something I use frequently. However, slackroll and putmail.py are my personal pets and I try to care about them as much as I can. I hope this helps understanding why I took the decision of writing such a long article about it. Much longer than the article it refers to, but I think it has been worth the effort. I don’t want bad publicity about slackroll and, while I’d like it to have more users (more users means more bug reports and constructive criticism), I would also like every new user to use the tool appropriately without breaking their systems.

I completely discourage people from following the steps in the article and would like to ask people to simply ignore it. Thanks a lot for your time and for reading this.

-Ricardo Garcia