next step in ai is obviously dynamically self-learning large language models. the current ai is google search with pre-computed aggregation heuristics, and nothing more than inspiring that.

not sure what to think about the next obvious step other than it is inevitably the next step :-)

so to scope the "problem" with the current AI is that it is not an "artist" using its own imagination, it is an "entertainer" following the patterns known to work for most.

#pelican seems to be in sweet spot for me generating a site because it has first-class #reStructuredText support, i.e. no need to add any plugins it is built-in.

The benefit in it is that if I write anything with reStructuredText it is easy to port as kernel documentation later on. #python

The first feature in #Kilohearts #PhasePlant that has made me turn into it more than #Serum is pretty cosmetic one: approachable way to modulate slope of an envelope.

E.g. with a bass patch for Serum I layer it with #Bitwig macro that has access to slopes through DAW interface but I cannot put it as part of preset. In Phase Plant I can have the macro within the preset.

#audio #musicproduction

Looking into pam_u2f.so for configuring #FIDO2 login,

Irritating thing #PayPal is that you can only add one hardware security key to your account.

After couple of hours poking around I now know how to embed #typst markup from yaml to a typst document :-)

I’m working on resume made with typst (as I’m looking to find a new job by end of September), and in that I’m using #yaml file to separate presentation from the content. Job descriptions can involve links, and thus those entries need to be evaluated.

First observation was:

#eval(job.description, mode: "markup")

If mode-parameter is not defined, typst will try to parse the string as an expression (i.e. mode: "code" is the efault, which is feasible in this case.

Another problem was the use of the hash character for tags, which is used for comments in yaml.

I sorted that out by putting every description into double quotes after trying a few different approaches:

    description:
      "I first worked on Keystone Security Monitor for RISC-V by enabling it
      for CVA6 running on FPGA. This work was part of the EU funded
      #link(\"https://www.spirs-project.eu/\")[SPIRS project].
      It involved
      tuning the
      #link(\"https://buildroot.org/\")[BuildRoot]
      based embedded stack, and
      fixing various
      #link(\"https://github.com/keystone-enclave/keystone/issues/378\")[issues].
      in the OpenSBI firmware.
      For the second half of my contract I'm enabling Linux for the new SoC's
      developed by
      #link(\"https://sochub.fi/\")[SocHub project]."

The screenshot shows the end result.

Nothing too complicated but took some time to find working patterns so putting here as a #note for myself :-)

I've only recently discovered boot-time tracing using bootconfig and moved away from huge kernel command-line strings. This is the best tutorial on topic: https://www.youtube.com/watch?v=BjiC_a13e_k

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