As you may know, pacman 5.0 was just released (and is available in
you might want to give it a try (and play with hooks) !
To do so, here's what you need to know wrt my tools:
There are already many cron daemons out there, and I honestly don't remember how I came about looking into such tools, but as I did I realized I wasn't too happy with the way most worked.
For instance, they all seem to operate on the same model: wake up at the top of every minute, to check if there's any job to run or not. Many also include some operations other than dropping privileges to the right user, such as setting up the environment, sometimes via definitions inside the cron tables...
I wanted something simpler. Small, simple, that does as little as possible.
As a user of a Linux system, you should have a runtime directory available for
applications. Such a thing is even defined in the XDG Base Directory
$XDG_RUNTIME_DIR -- and it is quite likely that you do have one set up.
You may have a session manager or some other component of your system handling
this directory for you, in which case the following likely won't be of much
interest to you.
If you do not have a
$XDG_RUNTIME_DIR however, let me introduce a little PAM
module to take care of it.
A new version of anopa - init system/service manager built around s6 supervision suite - has been released. Main changes since 0.3.0 are :
Change how the logging works: instead of logging into
/run/initramfs/boot.login stage 1 & 2, and using
aa-mvlogto move said file to
/var/log/bootat the end of stage 2, now stage 1 & 2 (much like stage 3) log directly into
As a special treat however, stage 1 will first check for a file
/run/initramfs/boot.logand import its content into
That way everything from stage 1 is logged into persistent storage, and the whole process is simpler.
There is something I've been meaning to do for some time now, I really should have, yet haven't found some time to: writing some sort of proper/actual introduction to anopa.
So let's try to do this now, with an actual example. A little while back, I explained why I was looking for another init system, and since I couldn't find what I was looking for, I started working on my own. That's how anopa, an init system/service manager based on the supervision suite s6, came to be.
A few years back, as I wanted to switch OS and enter the world of Linux, I needed to pick a distribution (or first, figure out what makes a distribution, what sets one apart from another).
Did some research, downloaded and tried a few ISOs, but quite honestly this wasn't a deciding factor in the end. No, what really helped me make up my mind was doing a bunch of reading, learning the "principles" of a distribution.
And the reason I eventually went with Arch Linux, was what's known to Archers as The Arch Way, which is said to "illustrate the principles and philosophy of Arch Linux."
A new version of pacman (4.2) has been released, introducing some API changes to ALPM. To go along with it, version 3.0.0 of kalu has been released, with the usual few fixes as well as some new features.
If you've been using branch
pacman-next you're already familiar with said
changes, mainly the fact, using kalu's updater, it can now keep track of any
.pacorig file created during a sysupgrade, and will made such
information available as variable
$PACFILES in the post-sysupgrade
This can be used to e.g. perform 3-way merge of .pacnew files. See man page for more, as well as this post for an example of use.
A few changes have just been pushed to branch
next of donnatella, introducing
some changes when it comes to IO operations (i.e. copy/move/delete files).
Starting at the top: donnatella doesn't perform any such IO operations itself. This isn't a not-yet-implemented feature but a design choice: there are plenty of tools which specialized in such things, no need to re-invent the wheel, let's use the existing ones instead!
A new version of donnatella, your GTK3 file manager, is available. A few fixes
as well as the addition of option
cancel_childless for terminals.
Enabled by default, it will cancel the running task on Enter/Esc if the running process (i.e. terminal emulator) has no children.
For example after running
df -h in an embedded terminal that doesn't autoclose
when the running process is done (e.g. urxvt has an option
-hold), so that you
get a chance to see the ourput, a simple Enter will close the terminal.
Ever since I switched to (Arch) Linux, I've always loved the command line. It can often be quite amazing, I find. Back in the Windows world, you're pretty much expected to forget that such a thing even exists.
Things are different over here (particularly with Arch, I guess), and that's all for the better. Many reasons for that, one being the fantastic simplicity and power that it offers you.