I have observed a change in behaviour in vim and tiny vim, in Debian 11 (Bullseye). When the window loses focus, vi automatically enters command mode.
To revert to the previous behaviour, where vi will retain the most recent mode, add the following to ~/.vimrc:
set esckeys
Sometimes it is necessary to speed up videos and/or reduce the resolution. This will typically result in a much small file size. ffmpeg and avconv allow video file manipulation on the command line.
These commands work on Debian 10, and will likely work on Ubuntu and other Linux distributions.
Speed up video, 2× speed: ffmpeg -i input.mp4 -filter:v "setpts=0.5*PTS" output.mp4
Reduce resolution down to 1280×720: ffmpeg -i input.mp4 -s 1280x720 output-small.mp4
Note that the metadata of the video, such as the resolution, can be read with the utility:
mediainfo
Often for testing purposes it is necessary to restrict the speed of a network connection.
This can be achieved using the netem module to tc.
For example, to restrict the bandwidth on eth0 to classic dial-up speeds use the command:
tc qdisc add dev eth0 root netem rate 56kbit
This can be cleared with:
tc qdisc del dev eth0 root netem rate 56kbit
Alternatively, this rule can be executed on an Ethernet Bridge so that it is independent of the device being tested.
The isc-dhcp-server included in Debian 9 will attempt to start a DHCPv6 instance on servers which have a dual-stack (IPv4 & IPv6) config.
If DHCPv6 is unconfigured because for example, Router Advertisements are used for configuring IPv6 hosts, then the service will fail to start. The DHCP(v4) is running but Systemd reports the service as failed.
One work-around is to force isc-dhcp-server to only start the v4 instance, add the following line to /etc/default/isc-dhcp-server:
INTERFACESv4=eth0
where eth0 is the interface on which DHCP requests should be serviced.
After restarting the service, the DHCP server shall now only run on v4 and as long as the v4 config is correct, Systemd will report the service as successfully started.
When developing on platforms with a different architecture and cross-compiling, it is often necessary to print the stack trace on a coredump.
TOOLCHAIN=/path/to/toolchain
DEBUGER=$TOOLCHAIN/gdb
EXECUTABLE=myprogram
CORE=coredumpfile
$DEBUGER -ex “set sysroot $TOOLCHAIN” -ex “set auto-load safe-path $TOOLCHAIN” -ex "file $EXECUTABLE" -ex "core-file CORE" -ex "thread apply all bt full" -ex "quit" > trace.log