Greetings folks!
I've figured out that when playing with Docker's Debian images, it's a good idea to pull Debian packages from a fast local repository. And what can be faster than using a local APT proxy, especially when your uplink with the Interweb is excruciatingly dial-up era slow?
I would say that apt-cacher-ng fits the bill perfectly and basically works out of the box, with one small caveat. On my configuration I've found out that, like what I've described some time ago with lighttpd1, it refuses to start if it can't find its log directory.
As with lighttpd, the suggested method to fix it is to add a file in /etc/tmpfiles.d with the files or directories to create at boot time. This is the content of my apt-cacher-ng-log.conf file:
D /var/log/apt-cacher-ng/ 0755 apt-cacher-ng adm
Yeah, I didn't spent a lot of time on this one. Splendid!
Greetings people!
Today I would like to spend some words about user interfaces or how usually some program's design decisions could make you shake your head, shake your fist, rise your voice against the monitor or in the worst cases trigger an even more energetic response1.
This time the culprit is Nautilus, the Gnome file manager, or more specifically the behavior of the new2 long file operations indicator. The Gnome developers decided to review the notification system and now for any operation that takes more than a few seconds a notification pop-up is displayed below the Nautilus title bar.
The pop-up reports the estimated time of completion with an animated progress bar, while a button with a increasing disk sector animation is displayed on the title bar, which both should disappear when the operation is completed.
Or at least that I suppose was the developers' idea.
There's an irritating detail in the new implementation: the pop-up is displayed in every currently opened Nautilus window and the frustrating part is, the thing will not go away until it's acknowledged on every opened Nautilus window. Miss a single one and it will still be displayed on newly created windows. I usually resolved opening a shell and killing the file manager.
Yup, that bad.
According to bug reports it's fixed upstream, but unfortunately it happened only after it entered in current Debian stable, so I'm stuck with it at least until Buster3 is released.
I can assure the reader it's super annoying.
I found it so really annoying that I was seriously considering to switch to Debian testing or going back to Debian unstable to get rid of it.
Before leaving the cozy Debian stable branch, I grumbling decided to invest a week-end afternoon to see if I could compile a recent Nautilus to my current Gnome installation without importing an avalanche of libraries dependencies4 or try to port the changes back on the current version.
Well, I overestimated the requirements as it didn't took an afternoon to fix it; I would guess I've already spent more time on this fine post.
The nimble patch is reported below:
--- nautilus-3.22.3.orig/src/nautilus-toolbar.c
+++ nautilus-3.22.3/src/nautilus-toolbar.c
@@ -633,7 +633,7 @@ update_operations (NautilusToolbar *self
if (gtk_widget_is_visible (GTK_WIDGET (self)))
{
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (self->operations_button),
- TRUE);
+ FALSE);
}
}
It simply flips the state for the pop-up toggle button, from enabled to disabled. I wasn't thrilled to peruse the Nautilus code-base, fortunately in this case the rabbit hole wasn't really deep and in retrospect I should have done it earlier, fortunately I didn't destroyed any hardware by rage attack.
On a tangent note with Nautilus, in the strive of minimalism, when copying/moving multi gigabytes of files, there isn't a direct way to see which file is currently processed5, but nothing that can't be revealed with lsof and updated "live" with the watch command:
$ watch lsof -a -p $(pidof nautilus) +D /destination/dir
I seldom need it, but when I do I tend to always forget the correct options, especially the plus sign. Not so long ago I found a nifty command line utility in the Debian repository called progress that can provide a progress indicator of data I/O plus an estimated time of completion for the common commands like cp, mv, dd.
throwing a PC outside of a window usually isn't a viable option but I was tempted more than once in the past ↩︎
"new" is relative, considering that Debian's Gnome is currently 2 releases behind upstream ↩︎
the codename of the next Debian stable release ↩︎
no can do, Nautilus 3.26 needs a newer Gnome tracker, libgnome-autoar and meson package ↩︎
unless monitoring the destination directory, but it's not immediate if, for example, it's already populated ↩︎
Roswell is a multi-platform Lisp installer and launcher; if the reader is familiar with Clojure it could be seen roughly as the equivalent of Leiningen. Yesterday I've decided to say goodbye and thank for all the fish to Roswell and proceeded to remove it and install SBCL the old trusted way, directly from source.
Roswell has some neat offerings, like installing with a single command a Lisp implementation like CCL or SBCL, download and configure Quicklisp or build an executable from a project.
When the installation works.
In my case, more than a single time, when I've tried to upgrade it I ended up with some errors. Nothing that I couldn't solve with some pronging, but that elided the usefulness of the tool1.
The biggest problem I've found was the installation from scratch. Quite often it ended with a somewhat strange error in a bizarre place of the system, the hostname-util.c file, or in other words, the fail pointed to the famous systemd.
Well, not exactly.
As I've said before, contrary to the loud majority I'm OK with systemd. Frankly, creating an init system better than a bunch of shell scripts isn't placing a bar really high.
Anyway, this is the error message:
$ Assertion 'uname(&u) >= 0' failed at ../src/basic/hostname-util.c:55, function gethostname_malloc(). Aborting.
I was a little puzzled because there aren't a lots of thing that could go wrong in the gethostname_malloc() function, unless the error is caused by lack of RAM. To deepen the mystery, on the same system I can build SBCL inside a tmpfs partition2, so RAM is aplenty.
I've looked at the bug reports and found at least one with the same error message and probably digging deep enough I could have isolated the problem, but sometimes the pragmatism wins. In this case, installing it from sources didn't create a lot of friction, unfortunately this means that deploying has became more complicated.
I decided to put the SBCL installation in my home directory. For the compilation it requires an ANSI compliant Common Lisp implementation, other than that I don't usually build it with --fancy features enabled as I stick with the defaults:
$ mkdir -p ~/.local/share/sbcl
$ sh ./make.sh
$ INSTALL_ROOT=~/.local/share/sbcl sh ./install.sh
I'm using Zsh so I've added the binaries path in my .zshenv file:
# add SBCL common lisp to PATH
if [[ -d "$HOME/.local/share/sbcl/bin" ]]; then
export PATH="$HOME/.local/share/sbcl/bin:$PATH"
export SBCL_HOME="$HOME/.local/share/sbcl/lib/sbcl"
fi
If it's not already installed, I then proceed to download and configure Quicklisp, that means adding my local project directory path in the ~/.sbcl.rc file:
#+quicklisp
(progn
(pushnew #P"/path/to/sources/lisp/"
ql:*local-project-directories*))
Profit?
The Stow version of the instructions above became:
$ sh ./make.sh --with-sb-core-compression
$ SBCL_HOME="" INSTALL_ROOT=/usr/local/stow/$(basename $(pwd)) sh ./install.sh
$ stow -D sbcl-currently-installed-version -S $(basename $(pwd))
where --with-sb-core-compression is applied to add zlib compression for core images and $(basename $(pwd)) usually expands to sbcl-version-number, if upstream doesn't change the naming format of their archives. Invoking Stow from the current directory should work when configured properly.3