for insightful reviews at #amazon checkout mine :-)

#AI can be useful but there is lot of useless AI where well-established algorithm does a better job. Sometimes even completely random from well-chosen distributions can deliver more interesting results than as deep learning is essentially a search engine, which substitutes links with data aggregation. AI is definitely not an #algorithm.

Especially this is true for #audio industry where AI innovation happens in the #plugin layer, which bottlenecks all the interesting applications. The only way it can ever work for audio is in the #DAW layer because deep learning algorithms are at their best for global optimization problems where as algorithms sort out localized problems.

I believe that the next thing for DAW's is scripting languages similarly as #Reaper already has but extended with ways to use 3rd party modules to integrate with e.g. AI frameworks. Before AI revolution it was archaic feature but if AI is moving forward in audio, this development is sort of inevitable...

#musicproduction

I’m not excited about oreboot. Fork is not engineering. Neither is replacing mature field-stressed implementation with immature Rust implementation.

Enabling Rust on side with C in upstream #coreboot would be engineering. This way upstream stays mature but Rust can be used to further improve the implementation.

EDIT: I gave this more thought and here’s what I spammed :-) To put story short I don’t believe this works as a “standalone product” but is still potentially useful: https://social.kernel.org/notice/AdIOdilzP66IevvbCy

#rustlang

Ihmettelen välillä näitä sijoittamisesta kiihkoilevia, joiden mielestä jo 5-vuotiaan lapsen pitäis avata osakerahasto, jotta pääsee alle 40-vuotiaana eläkkeelle.

Itse yli nelikymppisenä en kyllä mistään hinnasta lakkaisi tekemästä mitään, koska ihminen on luotu tekemään asioita. Kuulostaa aikaistetulta kuolemalta.

Parempi ajatus omasta mielestä maksaa lainat pois kokonaan, ja keskittyä sen minimoimiseen kuinka paljon rahaa on pakko tulla sisään. Itsellä kuukausittaisiset eksistentiaaliset menot on n. 300 euroa asumiseen , ja 400 euroa tyttären opiskelujen tukemiseen. Esim. autoa en tarvitse keskusta-asunnon takia. Kallis keskusta-asunto säästää yllättävän paljon kaikissa muissa kuluissa, vaikka hankintahinta ja tarvittavan lainan koko onkin suuri. Lisäksi se on helposti likvidoitavaa omaisuutta.

Ostelen kyllä krpyptoa ja osakkeita silloin tällöin, mutta tavallaan tavoitteettomasti. Se on vaan mukava harrastus siinä missä shakki tai nettipokeri... Ei sijoittamisessa oikein varmaan pärjääkään pidemmän päälle, jos siitä odottaa liikoja, ja ei tykkää itse tekemisestä.

#raha #sijoittaminen #osakkeet

looking into using relatively new #accel subsystem of the #kernel to accomplish some work tasks...

i was afraid i would have to invent something like this by reusing some of the gpu code but this is great.

CONFIG_DRM_ACCEL for the win i hope :-)

https://docs.kernel.org/accel/introduction.html

#linux

the only diagram type actually like is old school data flow diagrams (DFD) :-) sequence diagrams and state machines are IMHO redundant and made only to please managers that "we are doing something". DFD's are not sensitive to code changes and provide actually useful map how data moves within a system.

#apache #tvm is somewhat involved to install #macOS laptop. At least compared to pipx install apache-tvm in my #Linux desktop.

I followed these randomly found instructions but rolled it backed immediately because I don’t want to re-spend my time on this.

Also makes me wonder how big mess compiler toolchains are in macOS really:

1. I have Xcode command-line tools installed, which I expect to readily include llvm in some form.
2. Instructions imply that I also need to install llvm, which logically makes no sense to me.
3. Instructions also imply that I need to have GCC.

Might be just that the instructions are the broken portion but feels somewhat primitive and unorganized…I’m glad I develop iOS or Mac applications because then I would actually would have to use this as a real development machine I guess :-)

PS. The official instructions for macOS do not work in macOS at all :-)

When I have had to use Windows I've WSL2 totally inconvenient environment to work in with a number of things breaking up badly. A regular VM works much better and shell access goes by SSH.

That said I think as a technology it is a great piece still. I'd see for it more use if there was way to make Windows applications that would embed Linux kernel as a run-time.

It could e.g. be used to deliver accurate software versions of hardware consumer products, which tend to run Linux quite often...

Personally, I think that these new bc replacements make me feel more like Cobol vibes with "1 kilometer - 1 meter" type of expression support than modern vibes...

Commercial Linux distribution vendors could bring a lot of confidential computing benefits by providing rate-limited attestation service (i.e. accountless like AMD SEV-SNP CA works) I.e. CA would provide cryptographic proof of the core software stack.

With TPM2 backed hard drive encryption and HMAC encrypted chip communication you get a piece of confidential computing promise, i.e. the software adversary part and you can maintain that promise with pure software bug fixes, which obviously adds in to the value.

The main threat scenario of confidential computing is an adversary with a physical access to the hardware but it is also debatable scenario, and as we all know, there is a lot of data to backup the "debatable" part.

TCG, being a consortium and not a private company, states its specifications that TPM provides resistance against physical attacks. I think this is how Intel, AMD, ARM and other commercial CPU vendors should also describe their corresponding white papers, and make any improvements on top of clear and obvious to the customer.

PS. "confidential computing" is bad terminology but unfortunately it is also defacto terminology of the industry by now. It is actually "trusted computing" because the goal is try to address both confidentiality and integrity problems.

#linux #kernel #tpm #intel #amd #arm #sev #snp #sgx

Otin kuukaudeksi Ruutu plussan ja tyttöystävän kanssa käyty läpi hieman suomirealitya:

1. Lejonan luola. Hyvä ohjelma, ja ulkomainen vastine on lempiohjelmia. On tosin moraalisesti kyseenalaista, että yksi leijonista on istuva kansanedustaja Toiset pistävät omaisuutensa pantiksi kampanjoinnin takia, joten risuja tuotantoyhtiölle.
2. Rikkaat ja rutiköyhät. En sano tätä edes vitsillä, kun totean, että on monesti vaikea arvioida, kumpi jakson perheistä on rikas, ja kumpi rutiköyhä. Tämä siksi, koska en tiedä ihmisten henkilökohtaista tasetta. Kaikkea hienoa saa velkarahalla.

#suomi #reality #tv

#Linux #kernel 6.7-rc7 is out: https://lore.kernel.org/lkml/CAHk-%3DwjDbR1oNZtqTNE4n8MHbzi028JFKSCvyW88hw%2B0GO%3DP%2BA@mail.gmail.com/

"'"[…] since tomorrow is Xmas Eve,[…] I'm doing rc7 on a Saturday instead.

[…] we *could* release a final 6.7 next weekend as per the usual schedule, I'm not going to do that. It's the holidays,[…]

So next weekend is going to be rc8, and I expect that it will be small as nobody should be around.

And then we might get back to a more normal schedule the week after. Maybe.

Please do give it a whirl if you have the time and the energy[…]"'"

Not only #rustlang problem with Rust bindings but also an issue with e.g. #Python bindings: you cannot really use them to do any QA for upstream project, unless they are maintained by that project.

The reason being that they are not guaranteed to be in-sync with upstream changes.

The most of #autotools based open source software is sort of anti-pattern for QA/CI because the test suite is hard-bound to the source project. This is the reason why I rarely (or almost never) run TPM2 TSS test suite.

I wonder if #rustlang continues to follow this anti-pattern or is there cargo install for the test?

It is sort of thing that has been always bad for anything with disjoint host and target system but is part of “craftmanship” because things has been done that way long enough :-)

I think I will aim at building OS image per CI cycle for keyutils. This guarantees a kernel with configuration options to provide maximum coverage.

For .gitlab-ci.yml I guess it makes sense to then just limit to the branch master i.e. review is manual but red flags will rise up if the reviewer was sloppy :-)

For both integration tests of my #ZMODEM crate and also for keyutils Gitlab #CI I’ve been looking for solution to implement transparent serial file transfer.

#QEMU allows trivially to convert serial port to UNIX domain socket but it is not natively supported by sz but with a little bit of socat magic it can be apparently converted quite easily again to PTY:

socat -d UNIX-CONNECT:output/images/serial.sock  PTY,raw,echo=0,link=output/images/ptyC0

This allows to drop SSH support completely from BuildRoot config, which makes it much more appealing for automated CI.

For using #QEMU in #CI generating ephemeral #SSH key pair is one option but after playing for a while with that option I realised that you can create named pipes:

mkfifo tty.{in,out}

And then pass -serial pipe:tty to QEMU. After this commands can be emitted to tty.in and the output can be read from tty.out.

I think this a quite good strategy when having to orchestrate headless QEMU instances without any high-level infrastructure, such as libvirt.

I packed swtpm for the #QEMU build so it does not have to be installed to the system:

https://github.com/jarkkojs/tpmdd-buildroot-external

start-qemu.sh will automatically setup shenanigans so that swtpm will work as TPM emulation host for QEMU.

After build there’s three options:

1. TPM2 TIS/FIFO: output/build/images/start-qemu.sh
2. TPM2 TIS/CRB: output/build/images/start-qemu.sh --tpm-crb
3. TPM1 TIS/FIFO: output/build/images/start-qemu.sh --tpm1

Right, and neither QEMU needs to be installed to the host. I’m trying to sort of construct this in a way that it would become as CI friendly as possible so that this could be in addition used as a CI workload for keyutils.

#BuildRoot #linux #kernel #tpm

My new (WiP) orchestrator for building test image for testing my #kernel tree is fully implemented with GNU make:

# SPDX-License-Identifier: MIT

ROOT			:= $(dir $(abspath $(firstword $(MAKEFILE_LIST))))
BUILDROOT_VERSION	:= 2023.11
OUTPUT			:= $(ROOT)output
BUILDROOT_URL		:= https://buildroot.org/downloads/buildroot-$(BUILDROOT_VERSION).tar.gz
EXTERNAL_URL		:= https://github.com/jarkkojs/tpmdd-buildroot-external/tarball/main

define make-buildroot
	make -C "$(OUTPUT)/buildroot" BR2_EXTERNAL="$(OUTPUT)/external" O="$(OUTPUT)/build" $(1)
endef

define download-package
	mkdir -p $(2)
	curl -sL "$(1)" | tar -zxv -C "$(2)" --strip-components=1
endef

all: buildroot

.PHONY: buildroot
buildroot: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,all)

.PHONY: buildroot-menuconfig
buildroot-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,menuconfig)
	$(call make-buildroot,savedefconfig)

.PHONY: linux-menuconfig
linux-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,linux-menuconfig)
	$(call make-buildroot,linux-savedefconfig)

$(OUTPUT)/download-stamp: 
	$(call download-package,"$(BUILDROOT_URL)","$(OUTPUT)/buildroot")
	$(call download-package,"$(EXTERNAL_URL)","$(OUTPUT)/external")
	touch $@

.PHONY: clean
clean:
	rm -rf "$(OUTPUT)"

It is pretty robust structure because I can e.g. easily add packages (like maybe host swtpm) in a robust manner to buildroot.

#buildroot #linux

To test latest linux-tpmdd changes:

git clone https://github.com/jarkkojs/test-tpmdd
cd test-tpmdd
make

Then:

1. TPM2 TIS/FIFO: output/images/start-qemu.sh --swtpm
2. TPM2 TIS/CRB: output/images/start-qemu.sh --swtpm --tpm-crb
3. TPM1 TIS/FIFO: output/images/start-qemu.sh --swtpm --tpm1

Tools for testing (more in future):

• keyutils for testing keyring and trusted keys
• /usr/lib/kselftests/run_selftests.sh

Requires swtpm to be installed (but not QEMU, it will build one).

#linux #kernel #buildroot