wondering that when compiling a Git tree that is packaged like distro kernel RPM packages for OpenSUSE is it enough to just point LINUX_GIT to a kernel tree clone?

I made this conclusion from: https://github.com/openSUSE/kernel-source/blob/master/scripts/linux_git.sh

But there's bunch of scripts so possibly something else needs also to be taken into account. I just thought that this is easier path to test a few patches vs using patch sequencing which would make more sense, if contributing to the downtstream kernel itself.

Cool story about 3M floppies https://spectrum.ieee.org/3m-floppy #floppy

Is there off-the-shelf OpenSUSE RPM package of local email interface (lei)?

I also tried to seek for the source code but it is not available here: https://git.kernel.org/pub/scm/utils

After trial and error (earlier post), I’ve found out that only three steps that are required to migrate SDDM/KDE to a Wayland-only system in OpenSUSE Tumbleweed:

# systemctl disable xdm.service
# systemctl enable sddm.service
# cat > /etc/sddm.conf.d/10-display-server.conf << EOF
[General]
DisplayServer=wayland

[Wayland]
CompositorCommand=kwin_wayland --drm --no-global-shortcuts --no-lockscreen --locale1
EOF

End result:

$ pstree `pidof sddm`
sddm─┬─sddm-helper───startplasma-way───{startplasma-way}
     └─{sddm}

Also sanity-checked ps aux | grep -i xorg. Makes sense now that I know the steps but was pretty hard to find the correct steps because did not really know what I was doing :-) The default value for DisplayServer is x11 and then default value for CompositorCommand is weston. Thus both need to be updated.

#OpenSUSE #Wayland #KDE

Do not understand this:

$ pstree `pidof sddm`
sddm─┬─Xorg.bin───7*[{Xorg.bin}]
     ├─sddm-helper───startplasma-way───{startplasma-way}
     └─{sddm}

I did select wayland session, do not understand what those xorg instances are for…

it is sometimes pretty weird how almost any problem you have at, then you post about, and instead of measured arguments, you get stuff like "blame capitalism" for that.

it is a huge society issue in modern society really. blame something big instead of fixing the issue and call it a day.

i mean it never helps fixing the leak, even if it if the big bad venture capitalist or whatever is your dystopian monster made it possible.

my favorite tool for working with #polyend #tracker: #discodsp bliss 2. it is almost like instrument editor for polyend tracker because it comes also with standalone version.
i.e. it allows to do in minutes:

key-mapped multisample along the lines of https://www.youtube.com/watch?v=bn4vPrTU9js
e.g. octave interval multisample and use multiple sample slots and instrument number to pick the octave.

if polyend published PTI specification fully then tools such as bliss could easily implement direct export for it. it would be win-win for the ecosystem and the company...
without open specs for file format it is a bit fake to use terms such as "tracker scene" in the advertisements. actually it is not a bit fake, it is fake literally.

#OpenSUSE should probably have umask when mounting /boot/efi:

UUID=1A65-1563    /boot/efi               vfat   utf8,umask=077                0  2

The default 022 umask is incompatible with bootctl.

#systemd

I'm a big fan of #linux #kernel #gpu documentation :-) Would make total sense for trusted keys. Especially in crypto seeing code and documentation simultaneously would be an asset.

https://lore.kernel.org/linux-integrity/D05LXJUT7T5Z.39FGAGHVQ6HZH@kernel.org/

tried bc rust alternatives: they seem to improve life by re-inventing the idea with COBOL inspired syntax. #cobol #rustlang

I don't get administrator account type in #KDE or who would ever use that for anything. It would be nice if this option could be disabled from settings entirely.

Better stick to sudo, polkit etc.

I think that the single biggest security flaw with Intel TDX and AMD SEV-SNP is the lack of spread who can test the features.

E.g. I still test new SGX features with NUC7. It is the latest and greatest in the area for open source community use.

Features like TDX and SNP are by practical means proprietary and closed features with an open source license. They do not drive any major open source projects because they are completely out of reach for the most.

I think this a real shame. E.g. I could find a lot of use for running local daemons sealed with such extra layer of protection.

I think worst possible question for a job interview I could imagine would be "explain configfs, debugfs, securityfs, procfs, tracefs and sysfs categorizing their roles and differences".

I would not pass.

#linux #kernel

In Linux kernel maintainer PGP guide I don’t understand the section “Back up your whole GnuPG directory”, and it is also asymmetric with the section discussing paperkey.

AFAIK, this should be sufficient:

gpg --output "priv_0.pgp" --armor --export-secret-key

I do 16 of these and then copy those to an USB stick (i.e. one for each hex digit).

#linux #kernel #pgp

Now that I understand how Ubuntu TPM2 boots looking into OpenSUSE systemd boot version:

- https://news.opensuse.org/2023/12/20/systemd-fde/
- https://www.youtube.com/watch?v=drgo6pvn5hI

I'll check also Fedora albeit I'd guess it is like OpenSUSE (follow cross-distribution standard ways) and unlike Ubuntu (ignoring the common good).

#amigo is a bliss (and also has a linux version) https://www.youtube.com/watch?v=DB6mkL6x1DE #audio #plugins #commodore #amiga

these have been best #headphone's ive had so far both for #music (listening and producing) and #teams etc meetings. and fully repairable and from recyclable plastic: https://aiaiai.audio/headphones/tma-2-studio-wireless-plus

two copies of me, i like to use different color smiley for each, and name them in web services as "yellow key" etc. :-) #yubikey #openpgp #fido2

When I backup #OpenPGP private master key to USB stick I tend to do priv_0.gpg, priv_1.gpg up to priv_f.gpg. They are identical but little bit of redundancy should bit more durability. I.e. hex amount of spare copies.

execmem patches v7 providing initial pieces of framework for allocating trampoline executable memory for tracing tools, and kprobes implementation for RISC-V: https://lore.kernel.org/linux-riscv/20240326134616.7691-1-jarkko@kernel.org/T/#t

#tracing #kprobes #linux #kernel