You are not logged in.
If the button results in an ACPI event, you could deal with it through that: a "rules file" in /etc/acpi/events to recognize it and map to a script, and that script invoking pm-suspend, habitually placed in /etc/acpi.
Thanks.
have no idea what your talking about . . . I didn't know a kernel had a color!! LOL!
yes :-) a while ago I thought to experiment with the C-A-f1 console, to have black text on white instead of the washed out gray on black (or sometimes dirty dark green). I then found out that those console colours are hardcoded into the kernel, in a palette of 8 named colours, with "white" conveniently naming the gray colour. This seems to have happened many years ago, but that doesn't place it lower on the stupid scale. In any case, I eventually worked out how to achieve black on actual white on the console, and that it's not worth fighting for.
Is there an easy way for me to have the (beta2) XFCE desktop icon labels text in black?
Just a vanilla installation with everything default.
(and I think whoever made the "white" kernel colour be gray should have a separate talking-to)
Announcing https://github.com/ralph-ronnquist/rrq
This Parental Internet Packet Filtering is a blacklist based network traffic filter to block access to certain domain names for all or some outbound and/or forwarded HTTP and SSL traffic.
The blocking principle is simply to detect and discard any IP packet that constitutes the initial handshake of an HTTP or SSL connection to a blocked domain. By discarding these initial packets, the blocked domains become inaccessible.
The project includes two alterantive daemons: "rrq_nfq" for iptables based filtering, and "rrq_vde" for use on a VDE cable chain. Includes "make deb" for building a Devuan (.deb) package.
As I restarted a vdev setup from scratch, I was reminded that the dvb adapter end points get rather restrictive file permissions, e.g:
crw------- 1 root root 212, 0 Jan 8 21:54 demux0
crw------- 1 root root 212, 1 Jan 8 21:54 dvr0
crw------- 1 root root 212, 3 Jan 8 21:54 frontend0
crw------- 1 root root 212, 2 Jan 8 21:54 net
This is something one can remedy by an action, say, "/etc/vdev/actions/dvb.act" as follows:
[vdev-action]
event=add
path=^dvb/adapter[0-9]+/[^/]+$
VAR_PERMISSIONS_GROUP=video
VAR_PERMISSIONS_MODE=0660
helper=permissions.sh
I.e., give rw permission for group video to all endpoints. I'm adding that action to the standard set in a forth-coming version.
The script in detail: the "event" category is limited to act on new path names, and the path name (following "/dev/") is restricted (through a POSIX regular expression) to the "adapterN/blah" end points. This action utilises the standard permissions setting helper, which makes good use of the given "VAR_*" variables.
btw, re (8):
8) I attached an external USB HDTV adapter (PCTV 290e) and the expected /dev/dvb devices were created.
However for to test this further on a proper multi-tuner mythtv backend (with the need for consistent and meaningful names), I would need to be able to recreate the following udev rules in vdev:# PCTV 290e single tuner USB stick
# --------------------------------
# Create symlinks /dev/dvb/adapterPCTV290e/* pointing to PCTV 290e adapter (has unique attributes, so can find wherever it is)
I think I would consider having a separate naming script, with code like
ln -sTf adapter0 /dev/dvb/adapterPCTV290e
to be run when starting the mythtv app, or manually, rather than making it vdevd magic; especially since there might be several adapters of the same brand.
E.g., for my own TV system I have 4 receivers of the same brand, so I can't use your approach off hand. (A separate comment is that it's enough to symlink to the adapterX directory rather than symlink each "control interface" [or what it's called]) As you might know, the product name for /dev/dvb/adapterX is (currently) available at e.g.
cat /sys/class/dvb/dvbX.demux0/device/product
But, I suppose there could be a helper script improvement for this in some way.
ok. I've added (A) as issue for https://git.devuan.org/ralph.ronnquist/vdev. The daemon should indeed be robust against malformed action declarations as well as helper script errors.
Re (B): yes, most of the error messages are at a severe extreme of cryptic. Mostly they are s.c. standard error codes, and -22 would be called EINVAL. In your case, I'm guessing there was some output lines before that error line, such as:
Failed to set mountpoint, config->mountpoint = ...
or similar, which sometimes could help a geek to pinpoint the problem.
Re USB, (7): the overall issue is that several packages have been coded to utilize udev, via the rules files, for automagic hotplug handling, and they (of course) don't include a corresponding configuration (action+helper) for utilizing vdev. I did start on a "udev rules"-to-"vdev conf", but stopped (apart from incorporating scanner recognition into vdev), as I rather quickly saw it leading to insanity (mine). So, this aspect is in a state of pass the bucket game, where it really should be up to those other package developers to add their hotplug configuration wrt vdev.
That leads to your pt.8, and highlights the need for more/better documentations (and tools?) of how to "program" vdev.
(sorry. right now it's too hot here to think; I'll try again in the weekend...)
I'm of course using vdev myself, and as of last week, it's with a beta2 installation on the 20 Gb SSD of my Asus laptop. I've uncovered two faults in the vdev actions (it locks down /dev/fuse and /dev/net/tun too much), and otherwise had no grief. But I can't say I'm very inventive in changing its hardware anyhow, so it's not a very impressive vdev workout.
The documentation needs a lot of work, with possibly the major thing being a change of perspective so it, more than telling what vdev does, it tells what a person needs to do to make vdev do something more/else for them. This includes how to make changes to the current (documented) actions, and more significantly how to add new actions/helpers to deal with new hardware. At the end of the day it's just the hotplugging sub system, which really is (or should be) simple for any particular set up, but made complicated in the attempt to be capable of handling any and all possible set ups.
I got three: firstly, this is well beyond my expertise; secondly I tend to prefer using the shift key or ctrl key to wake a sleeping computer; and thirdly, the beep-beep-beep behaviour might suggest BIOS level concerns, which perhaps could be a dead battery. But again, I'm not expert on this (and I use a laptop, with acpid lid action).
This is an advisory note if you happen to use pulseaudio and want to trial vdev.
The issue is that pulseaudio has a builtin dependency on udev via its module module-udev-detect.so (e.g. /usr/lib/pulse-7.1/modules/module-udev-detect.so), and the associated stanza in /etc/pulse/default.pa, perhaps at lines 53-60:
### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect
.endif
You should thus rename or remove module-udev-detect.so, or make the stanza be just:
load-module module-detect
Either way should be enough to keep sound working.
@golinux maybe it's a good idea to prohibit posts to hold direct links until the user has built up a sufficient "credentials", e.g. by having taken part in a handful of threads, or something?