As I’ve said in the past, I have a M2 Mac Mini at home. It is useful for ARM64 kernel testing and (non-cross) compilation of kernel in home environment but it is also interesting to compare same tests with my Linux machines and macOS.

How the operating system and CPU cores play together makes me honestly feel that Apple is lost what they should do with macOS. If it is used for anything but real-time multimedia, e.g. raw CPU workloads, it does not really deliver. Apple is shipping general purpose computer of which software internals are optimised as it was a tablet.

i have beefiest M2 with full 32 GB of memory and trying to do a largish build with all CPU cores completely freezes the system or like make the interaction laggy to the unusable level. It is quite ridiculous tbhl. Operating system kernel is expected to do time sharing properly and evenly as possible in 2023.

This is not open source vs closed source issue. It is just bad engineering plain and simple. I mean Windows and NT kernel do deliver well in scalability (and Azure provides strong evidence of this).

For the remaining part up until end of 09/2024 at the university I’m working on enabling stuff in https://sochub.fi/, which is IMHO remarkable being academia driven project.

#SoCHub produces yearly a new bigger RISC-V chip with IP blocks from the partner companies for the purpose different topics where you need a #SoC. If I got it right, they are also beefiest SoC’s designed by #academia anywhere in the world.

#Tampere #University drives the project and integrates the IP blocks to the chip design with their own in-house developed 500 kSLOC tool, partners provide the IP blocks around RISC-V core and eventually they can be used for applied research.

For 10/2024 I’m probably looking for a stable corporate job after windy 2022 in a startup, and this period at the university but plans are then pretty much wide and open.

Is there a a config flag to trigger scripts/clang-tools/gen_compile_commands.py for every build?

For instance, #cmake has CMAKE_EXPORT_COMPILE_COMMANDS for this.

Manually calling it for every build is a glitch if the build is scripted, and tedious if the build is done manually.

#linux #kernel

not going to cover this, i just used it as a reference to create a nu-discoish’s bass sound. also quite happy with the guitar made with @uheplugins #zebra2. i’m going to use these sounds to make a track for a compilation coming from a new israel based freeform #psytrance (or #suomisaundi as it is called) record label. ps. neither autotune nor any pitch correction in the vocal, recorded from laptop mic :-) #audio #musicproduction

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.