alsactl: sysfs_init:48: sysfs path '/sys' is invalid Found hardware: "HDA-Intel" "Analog Devices AD1989B" "HDA:11d4989b,10438311,00100300" "0x1043" "0x8311" Hardware is initialized using a generic method
This is what I could read on boot after a recent kernel upgrade (4.4.1-2 ->
4.4.3-1, to be exact), as a result of running
alsactl restore Now, the good
thing is my audio didn't stop working, but that's still not right (and my
settings (e.g. volume levels) weren't restored as they should have been).
"Release often" they say, right? Yet another release of kalu, since a stupid mistake on my part led to notifications being empty in 4.0.1, making them much less useful indeed.
This is now fixed; Thanks to adam777 for the report. Hopefully this is the last release for this week :p
2016 will be different, and there's already a new release of kalu! Nothing to be pleased about though, as I let slip a bad bug with the templates reworking, and kalu would segfault when running and no configuration has been loaded.
In other words, news users - or anyone without an existing
kalu.conf - would
see a segfault as soon as the first checks were ran. Not good.
As I don't doubt you're aware, pacman 5.0 is out. I managed to take some time and here we go with new releases for kalu & PkgClip -- though, really, only the former has a link to the new pacman, since as said before PkgClip wasn't actually affected by the API changes.
(For pacdep: API changes aren't relevant, so a simple rebuild will do the trick. No new version coming as of yet.)
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."