Is this a matter of slock not returning the keyboard focus back to the application it stole it from? Or it could be that that prior process doesn't deal with keyboard focus events properly? Which program is it, that should receive that typing that it seemingly doesn't receive?

@MiyoLinux: I gather esr's tax identity is Eric S. Raymond, and his CV, would he present one, would or at least could be jam packed with notes about contributions to open source software.

Of course I would agree that the style of "barging in" and presenting an authoritarian opinion is ill suited to this community. But it's certainly worth to hear him out. I think his points are more directed to end-user distribution aims, than to the core Devuan project of maintaining a systemd free platform. Even so, they can well be discussed on this thread.

I think there may well be explanation stories making ipv6 the culprit, and If you don't need it, you should disable it. E.g. put the following into a file /etc/sysctl.d/noipv6.conf and reboot:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

What do you mean by that?
Which are your "first few lines in my firewall script"?
And where do you write them?
Are you confused about how to run the redirection rule by hand?

Which is "more complicated" than what here?

Isn't it that you want your machine set up such that a certain program runs upon tcp connection to a certain port, with that socket IO being standard input/output for the program? Since that notion is almost as old as me, there are more than a few ways available for it, including those packages, as well as direct approaches using nc or socat.

I think I would do this by adding a start-up script to start the port service when I log in to the desktop management system, with the particular port service I have chosen; probably using micro-inetd, which has this as its central use case. If I would find myself wanting similar but different set ups for several ports, I would probably eventually move over to be using openbsd-inetd instead. But I know folks that certainly would make other choices.

Firstly, do these interfaces really initialize in different orders at different boots, or are they always in the same order?

The example you present suggests that "04:4b:80:08:80:03" is first, then "00:01:29:d3:0f:01", and then "00:15:e9:bd:1c:b7". If that is always the boot order, then you would do best in naming the first one "eth0", the second one "eth1" and the the third one "eth2", since that coincides with what they are initialized as.

If there is initialization randomness, then you do best in naming them on a naming scheme apart from "ethN", since that will avoid name clashes. The suggestion by @fsmithred might work if their "bus addresses" remain fixed, but it's probably better if you use a scheme of your own, say "eN".

If you also really need them to be named "ethN" in your way, then you must rename twice: first to a different scheme, then back to the "ethN scheme". In that case, you cannot really rely on udev to configure them, since the configuration has to be postponed until after the double renaming (and not on "first sight"). I think you are in scripting territory with that.

Not my language, but I guess "orden" is for the command to execute, and then that is where the full pathname to the program should be. The next field, "directario de trabajo", is probably the working directory, and I would suggest you pinpoint one of your own directories there.

Something like https://askubuntu.com/questions/558280/ … f-terminal might assist you on that quest.

It seems to be available in ascii/contrib (or jessie/contrib).

Good find.

There is also the per-AP settings in /etc/wicd/wireless-settings.conf which have a possible line of automatic = 1 or automatic = 0. That line tells wicd whether to connect to the AP automatically when in range, or not. To be sure, the wicd-curses UI offers a toggle for achieving this (without manual file editing), and I would guess the other UI's do as well.

I think the configuration file for wpa_supplicant that you refer to is created either manually (in a manual networking setting) or by the networking utility software (e.g. network-manager or wicd). E.g., for wicd, I have the configuration files in /var/lib/wicd/configurations/ with some "random" filenames.

No, you don't need to access contrib and/or non-free for this; all those packages (libopencv-core2.4, libavfilter5, libopencv-imgproc2.4, libav-tools, libavdevice55 and libtbb2) are available in jessie/main, and some of them also have upgrades in jessie-security/main.

Your OP warning probably relates to devuan-keyring, and it may help if you (re-)install that first, and then try again to install libav-tools.

Then as an aside: the current advice is that you should use deb.devuan.org instead of pkgmaster.devuan.org in your sources.list, so as to take advantage of the mirroring. But that's a different thing.

It looks like the default font path is compiled into "the actual server" binary, /usr/lib/xorg/Xorg, and even though that font path is simply a null terminated string, it's not for the faint-hearted to edit a binary. It'd be easier to avoid the warning by creating an empty directory, or maybe just have a quick sideways glance at the cat when the harmless warning scrolls past.