I tried Arch Linux first for some time when looking at to what switch from Ubuntu (which I used since 2004 to last year) and I think it is really good! I still use it for more complex test VM's (when needing something more like a distribution than BuildRoot). The reason for ending up with OpenSUSE was the binary packaging part that I mentioned.

I.e. how features are engineered feels very "German" in the good sense of the word. Sometimes ugly but always useful and made to last :-)

I've been pretty satisfied with #OpenSUSE since I started to use it somewhere in the latter part of last year :-) Some UI workflows are not as off-the-shelf polished as in #Ubuntu but payback comes from mostly relying in the common sense standard compliant solutions and not trying to hack features "not yet possible". And when comparing to other rolling release distributions I find it nice that you get the latest shit but mostly as binary packages so update times are always fast.

Comparing now how SDIO boot works with the official SDK. I don’t know where “SDIO” comes from but it should boot all from SD and it is the term used in the quick start guide.

The same guide does not give whole a lot of promised as it just states that:

StarFive recommends that you use 1-bit QSPI Nor Flash mode since there is a low possibility that the VisionFive 2 may fail to boot in eMMC or SDIO3.0 boot mode. Try restarting the VisionFive 2 if fails to boot in eMMC or SDIO3.0 boot mode

Probably something like BeagleV would more convenient but it was not yet even publicly announced when I ordered this. And even if I probably eventually get it having multiple pieces for hardware is nice for comparison.

Six months before my contract at the university ends so better start looking for vacancy preferably a safe corporate job. Not too many requirements expect needs to support being a kernel maintainer...

Hmm.. With DIP switches set to “SDIO” mode, VisionFive2 SBC gives the most informative error message ever:

BOOT fail,Error is 0xffffffff

I’d guess the last value is -1 in 1’s complement format but other than that 🤷

I used #BuildRoot and visionfive2_defconfig. Not sure how feature complete so maybe I will try the official SDK for comparison.

execmem allocator for #tracing and RISC-V support for applying it for #kprobes v6:

https://lore.kernel.org/linux-riscv/20240326012102.27438-1-jarkko@kernel.org/T/#t

#riscv #linux #kernel

@arj OK, cool, just giving evidence that there's no bottleneck to add more support, only four relatively simple steps :-)

@arj ARM support can be added but not in the scope of my patch set. The priority is to implement it so that arch support can be gradually added.

Post this work ARM support could be added by:

1. Implement alloc_execmem().
2. Implement free_execmem().
3. Edit appropriate arch Makefile.
4. Set HAVE_ALLOC_EXECMEM in appropriate Kconfig.

Kprobes w/o modules for RISC-V v5

https://lore.kernel.org/linux-riscv/D036FYBQUMIX.L5TL0SUCAO49@kernel.org/T/#t

s/textmem/execmem/ (a typo)

#linux #kernel #kprobes #riscv

@ncopa Hey thanks a bunch!

@merri must be true if you say so but i have zero interest in politics.

Does anyone provide static and pre-compiled #busybox binaries for #riscv? For #x86 busybox.org provides this but other than that I have no idea.

I guess the software version of Moore's law is that software gets exponentially worse as hardware gets exponentially better. For instance, word processors do mostly the same tasks as in 1993 but do not run with 386 and 4 megabytes of RAM :-)

#amiga #sampler https://www.potenzadsp.com/amigo/

#audio

@viznut @neauoire it is also style adopted by various plugin systems like audio plugins (VST, AU etc.) where you need immediate mode GUI that is driven by the plugin callbacks (most of operating system UI framework are incompatible how plugins behave).

Not my expertise area at all but I was just thinking how would you measure relative round-trip time of syscalls on let's say between x86 and RISC-V. i.e. when you have your measurements how would you normalize the results for meaningful comparison.

I tried to switch back to mutt couple of times but aerc some tricks under its sleeve that have kept me using it.

After about two'ish years of use I've reached the point with #aerc #email client that I do not pro-actively hate it :-)

The withdrawal symptons of #mutt are over...

@jon_giraffe or if you want to go crazy:

$ alias rustup-init="curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s --"
$ rustup-init --help
rustup-init 1.27.0 (b02c9c2b4 2024-03-08)

The installer for rustup

Usage: rustup-init[EXE] [OPTIONS]

Options:
  -v, --verbose
          Enable verbose output
  -q, --quiet
          Disable progress output
  -y
          Disable confirmation prompt.
      --default-host <default-host>
          Choose a default host triple
      --default-toolchain <default-toolchain>
          Choose a default toolchain to install. Use 'none' to not install any toolchains at all
      --profile <profile>
          [default: default] [possible values: minimal, default, complete]
  -c, --component <components>...
          Component name to also install
  -t, --target <targets>...
          Target name to also install
      --no-update-default-toolchain
          Don't update any existing default toolchain after install
      --no-modify-path
          Don't configure the PATH environment variable
  -h, --help
          Print help
  -V, --version
          Print version

Execution of a remote payload but should be fairly secure as it is verified with rust-lang.org CA (thanks to TLS 1.2).