Energy consumption during rides or runs

General Thoughts

  • The body digests food better in calm situations with minimal stress.
  • High-intensity activities can impair digestion due to diverted blood flow and physical jarring.


  • Uphill: Slower, less jarring, potentially easier on the stomach.
  • Fueling Strategy: Solid food before/during climbs.
  • Downhill: Faster, more jarring, higher risk of gastrointestinal discomfort.
  • Fueling Strategy: Gels and gummies before/during downhill.


  • Climbing: Intense but steady exertion, moderate stress on the stomach.
  • Fueling Strategy: Gels and gummies before/during climbs.
  • Downhill: Less physical exertion, but potential for vibrations and jarring.
  • Fueling Strategy: Solid food before/during downhills.

fix mp3 with ffmpeg

issue: Sonos didn’t played back some mp3’s and showed an network related error message. At the same time Sonos could playback other mp3’s. So it was not a network issue.

solution: ffmpeg

  1. macOS install ffmpeg in terminal

brew install ffmpeg

  1. batch convert
for i in *.mp3; do ffmpeg -i "$i" "${i%.*}_fixed.mp3"; done


Pi-hole and unbound

Source and Details:


Faster DNS resolving, by becoming own DNS Server


sudo apt install unbound

Create confiig

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Add following content into pi-hole.conf

    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    # root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: fd00::/8
    private-address: fe80::/10

## Performance
# More cache memory, rrset=msg*2 | Default: 4m, 4m
msg-cache-size: 32m
rrset-cache-size: 64m
# Time  to  live [minimum|maximum] for RRsets and messages in the cache | Default: 0, 86400
cache-min-ttl: 3600
cache-max-ttl: 86400
# Serve old responses from cache with a TTL of 0 in the response without waiting for the actual resolution to finish | Default: no, 0
serve-expired: yes
serve-expired-ttl: 86400
# Fetch DNSKEYs earlier (DNSSEC): More cpu usage, less latency | Default: no
prefetch-key: yes
# Helps to reduce the query rate towards targets that get a very high nonexistent name lookup rate | Default: no
aggressive-nsec: yes

## Privacy | Default: no, no
hide-identity: yes
hide-version: yes

EDNS config creation

sudo nano /etc/dnsmasq.d/99-edns.conf

99-ends.conf content


PI-hole adjustment

  • remove on left all hooks
  • add Custom 1 (IPv4):
  • remove Custom 3 (IPv6)
  • active Use DNSSEC in the bottom
  • save

default view


Debian Fix

sudo systemctl disable --now unbound-resolvconf.service
sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf 
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Restart and go live

sudo service unbound restart

PrestaShop Admin Panel 500 error

Issue 1 happened during an update from version to the latest stable one.

After the DB restore, the shop itself run well, but the admin backend run into an error

prestashop FileLocatorFileNotFoundException

solution: download and install the version and copy the src directory from the fresh one, renamed first and deleter afterwards the corrupt one.

Issue 2

Upgrade of modules was not possible: classes/../tools/pear/PEAR.php): failed

solution: removed blockrss module and replaced other corrupted modules which run into the same issues from modules of fresh installation

Lateral Leadership

source: What is Lateral Leadership? – Humans Matter

Dear reader! If you are managing a team or have a company, lateral leadership could be the game changer. Recommend to read the source,

Lateral Leadership in Agile Organizations

Modern network organizations, agile organizational structures and processes are more likely to rely on self-organization and distributed management tasks and/or processes. Leadership roles. In an agile context, explicit managerial employee relationships are broken up and management responsibilities are divided between cross-functional teams. Titles and hierarchies have undesirable effects on team collaboration and dynamism. So there is no longer only “the” one manager or “the” manager. Leadership is no longer a given force. So there are fewer or no leaders, but leadership roles. And according to the expertise and context, many of them may even be.

Definition Lateral Leadership

Lateral leadership means leadership without disciplinary leadership, without authority. The guide direction is not limited from top to bottom. Lateral or peer leadership has an explicit effect on the horizontal level. Everyone has leadership responsibilities towards their colleagues. It does not matter where they are located in the artificial hierarchy. This explicitly includes the direction of employee to boss.

The great challenge for employees is to recognize the importance of their own leadership and to take responsibility for it and to find ways and ways to do it.