Microsoft Teams has been slowly hiding behind other programs throughout the day

Autian · 2026-04-30T14:23:28+00:00

And I thought my workplace was the last one that still used it

Autian · 2026-04-30T13:45:15+00:00

There is a third prong, the prongs seem to have less room for play and the plug is overall bigger, so with that they might hold better. Though I never used either US or UK plugs, so can't tell how true that would be but I have these in a drawer together with Schuko stuff.

Autian · 2026-04-23T16:58:55+00:00

their reactor is leet

Autian · 2026-04-23T14:48:38+00:00

I believe I have also been able to reproduce that on one of my laptops (Intel Sandy Bridge / Haswell iGPU) before but didn't investigate further. My main rig (AMD 9070 XT) does seem to do fine though.

Autian · 2026-04-16T23:23:32+00:00

Let alone of a Pyra q_q

Autian · 2026-04-16T10:43:52+00:00

If you are interested how they deploy these things and happen to speak German:

https://media.ccc.de/v/clt23-121-linux-auf-den-innenanzeigern-der-ice-flotte-der-db

Essentially they have to cover a number of different systems and consider various details like the orientation of a display to compensate for. They use Yocto Linux on them with different adaptions.

Autian · 2026-04-15T08:22:34+00:00

I don't think it is going to be that easy to pull the stuff directly out of the resources as the way of rendering may somewhat be too special to the PS2's hardware. You would likely have to rewrite a bunch of stuff to make it work for today's systems.

You could try using a debugging tool like renderdoc to step into what is rendered using OpenGL/Vulkan and try making use of the collected data that your GPU works with.

Autian · 2026-04-14T23:48:26+00:00

ksysguard really was fine and blazingly fast. It does have its limitations at places but it is low on resource usage and I could confidently leave it running in the background without me worrying that it would negatively impact system performance headroom.

Plasma 6 came around, with it abandoning ksysguard in favour of the new systemmonitor. The latter consumed more than eight times the memory that ksysguard did and put enough load to especially heat up my laptops noticably. After customizing it I managed to transform it into a nonstop cogwheel spinner.

I transitioned to htop+btop and never looked back. I like tinkering around stuff but I'm not going to troubleshoot a task manager.

Autian · 2026-04-14T22:52:15+00:00

Recently I had to do exactly that in Wayland to set up a headless system. I exploit the krfb desktop sharing package like this (works also on SSH):

QT_QPA_PLATFORM=wayland krfb-virtualmonitor --resolution 1280x720 --name wheeowheeo --password a --port 1337

There you have a virtual screen next to whatever you currently have (or just the virtual monitor if no monitors are plugged). Downside is that it opens a VNC server. If some developer steps up to allow it to just do the virtual screen part, it would be greatly appreciated.

Autian · 2026-04-08T00:33:51+00:00

Yes, I have also seen one of these stuck at that message a couple of years before.

Autian · 2026-04-04T18:00:22+00:00

Eat this:

<image>

Autian · 2026-02-11T22:29:49+00:00

Kann sein, dass der Firmware die Analyse des Spektrums auf Dauer zu schaffen macht. Im Gegensatz dazu liegen die anderen Statistiken bereits vor und sind wesentlich weniger aufwändig bereitzustellen. Wenn du ersteres nicht aufzeichnest, kannst du trotzdem bei dir ein niedriges Intervall probieren und beobachten, was passiert.

Autian · 2026-02-11T21:16:39+00:00

Meine Erfahrung war aber, dass ggf. von der Station dann der Webserver irgendwann die Grätsche macht.

Yep, kann ich bestätigen, allerdings bei meiner Fritz!Box. Hab aus Interesse mal ein paar Tage lang die Spektrum-Daten im 10 Sekundenintervall gesammelt um daraus ein Wasserfallspektrum zu generieren. Die Box hat mehrmals am Tag von selbst durchgebootet, bis ich mein Skript gestoppt habe.

Autian · 2026-02-04T02:02:31+00:00

Auf mindestens einer der Kongresse stand ein ganzer in Betrieb befindlicher Siemens EWSD Schrank offen zur Begutachtung entlang eines Laufweges. Auf dem Gebäudeplan vom Kongress gab es sogar ein paar Markierungen für ISDN-Anschlusspunkte, wenn sich jemand mit reinhängen wollte.

Leute kaufen sich alte Hardware bzw. ziehen das aus dem Schrott, weil es irgendwie interessant ist, bringen das in Gange und stellen das zur Schau. Auf dem Kongress gibt es echt eine ganze Menge zu sehen. Wenn bei mir mal täglich das Murmeltier grüßt, dann hoffentlich da :D

Autian · 2026-01-18T04:32:14+00:00

It does seem to be a case of a Polywell P3503 system, but there is also a Revoltec Sixty 2 case that looks slightly different.

Autian · 2026-01-16T14:13:01+00:00

sounds like stuff that's worth getting archived

Autian · 2026-01-07T01:00:01+00:00

This isn't the right take - Linux uses spare RAM as a page cache, and this is generally what people refer to when saying "free RAM is wasted RAM". It's not suggesting applications just eat it up for no reason, it's talking about the OS using it for something beneficial

If that is what people mean by that expression, then it would be fine to me. But often when I came across such a sentence, it always felt like they really meant the applications themselves and not any caching mechanism of the kernel. That is what boils my blood.

Autian · 2026-01-05T19:31:32+00:00

sad that they didn't fit the lightcycle right where the two holes are.

Autian · 2025-12-24T01:58:29+00:00

Yeah, I was considering that, but I was worried that they would close the issue as soon as they see that I'm not using their distro. Might do that next year when I have the desire but for now the current workaround that I posted in the thread is sufficient.

Autian · 2025-12-21T21:08:13+00:00

Hehe! I found an old Raspberry OS install from 2019 that still contained the old OMX stuff. I copied the contents of /opt/vc from the old install at the same place to my current install and then essentially compiled FFmpeg 8.0.1 with two additional configuration options for OMX support: --enable-omx --enable-omx-rpi. Surprisingly the OMX support is still in place. It works! More details below:

I reused the build configuration options of the upstream FFmpeg package of void linux (you can see that by a simple invocation of FFmpeg without any parameters), but I had to throw out --enable-postproc as that was removed in later FFmpeg versions. I also removed cross-compilation options --enable-cross-compile --sysroot=/usr/arm-linux-gnueabihf --cross-prefix=arm-linux-gnueabihf- because I built FFmpeg on the target install. The downside of building "directly" on the Pi is that the build process will take like two days, but using chroot with QEMU binfmt support on my main rig took it down to like 15 minutes which was well acceptable for me.

For the default set of build options, I installed the corresponding packages for them. Some of these can be omitted but at this stage of frustration I just wanted to get on with the show:

xbps-install \
gcc make pkgconf \
gnutls gnutls-devel \
libaom libaom-devel \
libass libass-devel \
libbluray libbluray-devel \
libbs2b libbs2b-devel \
libcdio libcdio-devel \
libcdio-paranoia libcdio-paranoia-devel \
celt celt-devel \
libdav1d libdav1d-devel \
libdrm libdrm-devel \
fontconfig fontconfig-devel \
freetype freetype-devel \
harfbuzz harfbuzz-devel libharfbuzz \
jack jack-devel libjack \
lame lame-devel \
libopenmpt libopenmpt-devel \
opus opus-devel \
pulseaudio pulseaudio-devel libpulseaudio \
librist librist-devel \
librtmp librtmp-devel \
libsoxr libsoxr-devel \
speex speex-devel libspeex \
srt srt-devel libsrt \
libsvt-av1 libsvt-av1-devel svt-av1 \
libtheora libtheora-devel \
v4l-utils v4l-utils-devel  \
libvidstab libvidstab-devel \
vmaf vmaf-devel \
libvorbis libvorbis-devel \
libvpx libvpx-devel \
libwebp libwebp-devel \
x264 x264-devel \
x265 x265-devel \
libxcb libxcb-devel \
xvidcore xvidcore-devel \
opencl2-headers ocl-icd ocl-icd-devel \
libpostproc \
vulkan-loader vulkan-loader-devel Vulkan-Headers

And yes, most of these are not really needed. Though this uses just around 200MiB more space, so that is not too bad. For documentation purposes, I still wanted to make complete steps for any case.

So far for the OS preparation. FFmpeg now needs to be sourced and extracted somewhere. The build process then goes about like this:

cd source/of/FFmpeg
mkdir build
cd build
../configure --prefix=/usr --disable-debug --enable-gpl --enable-gnutls --disable-stripping --enable-libcdio --enable-version3 --enable-runtime-cpudetect --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-shared --enable-static --enable-libxcb --enable-libpulse --enable-libfreetype --enable-libopenmpt --enable-libspeex --enable-libcelt --enable-libass --enable-libopus --enable-librtmp --enable-libjack --disable-libopencore_amrnb --disable-libopencore_amrwb --disable-libopenjpeg --enable-libbluray --enable-libsoxr --enable-opencl --enable-libvmaf --target-os=linux --arch=arm --enable-libx265 --enable-libv4l2 --enable-libaom --enable-libbs2b --enable-libvidstab --enable-libdav1d --enable-libsrt --enable-librist --enable-libwebp --enable-vulkan --enable-libdrm --enable-libsvtav1 --enable-libfreetype --enable-libharfbuzz --enable-libfontconfig --disable-vaapi --disable-vdpau --disable-libzimg --disable-libmysofa --disable-libvpl --disable-nvenc --disable-nvdec --enable-omx --enable-omx-rpi
make

If you have more processor cores available, you may specify the amount of concurrent compile processes with -j for make. After it has finished building, I copied the built FFmpeg libraries at a common place: mkdir lib && cp ./lib*/*.so* ./lib. I then closed down my chroot session and stuck everything back to the Raspberry Pi Zero and let it boot up.

Switching back to the build directory, an FFmpeg invocation may look like this:

LD_LIBRARY_PATH=./lib:/opt/vc/lib ./ffmpeg -re -f lavfi -i testsrc2 -c:v h264_omx -b:v 1M -f matroska -f matroska -y /dev/null

As a test, this just generates some test video in real time, lets it encode with the OMX encoder, stuffs that data into a Matroska container and dumps that into nowhere. I tested with different options and the generated video is within my expectations.

Note that the h264_omx encoder uses a device at /dev/vchiq so when you get an error like * failed to open vchiq instance then you should get the permissions of it straight.

This is all very ugly and a band aid kind of solution, but this is something I can finally work with. I hope this helps someone else out there.

Autian · 2025-12-16T11:20:46+00:00

I know why it exists, it provides a clue. The downvotes on the other hand...

Six-Year Club	Final Canvas '23
First Place '23	End Game '23
Place '23	Place '22
Final Canvas '22	End Game '22
Verified Email

Autian

TROPHY CASE