Greetings random Interweb surfer.
Today I want to share my elevator pitch for a multimedia application that I've imagined a few days ago.
Imagine a book reader that, when a page where a song is mentioned, the book reader starts playing it in the background.
I haven't thought a lot about the implementation details. A strategy could be to distribute books with metadata about which song should be played and when. Another approach could be to infer directly from the content of a page if a song is mentioned.
I consciously completely avoided the "media rights" can of worms. So, if someone want to implement it, should feel free to do it with my blessing.
In my opinion it could be the best thing since the invention of the sliced bread.
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 ↩