@ljs Yeah, it is also my leisure time computer. Switching between Linux and macOS is my daily work trip in my home office :-) For making music it is really nicely packaged system. I use Bitwig and FL on it and they run perfectly.

I wonder if they've already fixed the security issue with signed kernel extension loader, which could be bypassed in the past because it was not fully implemented in kernel space (i.e. unlike how we handle things in Linux).

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

@ljs @jani @vbabka I’m trying to convince David (Howells) that we should seed Rust support to keyutils because it is exactly the context where Rust would work out pretty well. It would also provide governance from forks. I’m already putting together patches for this, even tho have not checked yet what David responded in IRC to this idea.

Other benefit is to be able to deprecate old rusty bash based test suite. With that change we could start using something like rstest to build up more comprehensive test suite. Also Rust test suite is easier to deploy to a BuildRoot image to run kernel tests.

These bash/autotools test suites are terrible for any SoC type of stuff tbh. They should be IMHO deprecated in almost any possible project… They also add up to the security risks because less test suite is run, more likely bugs will leak in. The only nicely aged test suite I know is kselftest which packages easily to anywhere :-) It’s not perfect but we should be happy that we have it…

@ljs @jani @vbabka That said I don't think this oreboot is useless. It could be used as basis to glue Rust into mainline coreboot (if that makes sense in a way or another). I just don't believe that it will live on like this... I mean it is a working of proof of concept that coreboot can utilize Rust if they ever want to, and if that ever happens, it would probably make sense to re-use some of this codebase.

@ljs @jani I'd look for places where de-facto stuff is crap or unuseful for modern use. This is why I work on side with my zmodem crate and serial terminal to accompany it (MS-DOS had better terminal apps than anything for Linux). And while ago @vbabka told me about this SUSE employee who does a software TPM in Rust. That makes also a lot of sense because IBM and Microsoft implementations are not up to today's standards (trying to state this politely as I can :-)).

There's really a lot of this type of stuff that would really deserve a rewrite so I just don't get why to focus on stuff that works and is of quality (like coreboot IMHO is). Especially in boot loader you would anyway do tons of unsafe stuff, and the actual malware facing thing is only after that, e.g. SBI implementation in the case of RISC-V (for OpenSBI it really would make sense to enable Rust on side based on experience of tailoring it recently).

I do like Rust but I do not like this "Let's reinvent the wheel... in Rust!"-culture ;-)

@jani @liw even tho i work in low-level i do mostly think what users care of. as a user i don't care if there was boreboot written in BASIC, if it improved my life somehow :-) less compatible fork of coreboot does not really improve my life quality...

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

I use Bitwig myself too but still envy ReaScript, which would really bring alot to table (and pool clips, which are equivalent to FL/Tracker style patterns).

@polarity Yeah, I mean point was not to say that it is bad. It is of course great if it works for you :-) I just merely see it as a different UI for already existing modulation system, in terms of expressive power, so I would not necessarily take EQ/Sampler as analogy here (actually all you need is sampler and all-pass filters if you really want to go that archaic :-)).

@polarity Might a be bit controversial opinion but I've never really got into situation where I would *need* to use grid. It is because the modulation system already for the most part allows to connect stuff freely.

All "must use grid" use cases that I'm aware of are related just to a device that is only available in the grid, which is sort of artificial.

I'd be happier with Bitwig if it had instead of Grid something like ReaScript, which unquestionably adds to Reaper, or at least I would have tons more use for something like that.

@timojyrinki @oherrala Mulle itseasiassa Nokian fall-down opetti tuon kantapään kautta, vaikka omaan nilkkaan se ei taloudellisesti osunut, kun sain nopeasti työpaikan Inteliltä. Opin siitä ainakin sen, että jos kokee patsastelevansa tosi hyväpalkkaisessa duunissa, niin silloin voi lopulta käydä huonosti. Tekemistä kannnattaa jalostaa jopa palkan kustannuksella aika-ajoin...

@timojyrinki @oherrala Taidot on varmin sijoitus mitä tiedän. Ja siinä huomaa hyvin nopeasti, jos sijoittaa väärään kohteeseen, eli tekeminen ei kiinnostakaan :-) Omaisuuden voi menettää aina, vaikka todennäköisyydet olis pieniä, ja osaaminen taas governoi sitä riskiä... Silloin voi aina aloittaa alusta.

@oherrala tyttärellä on itseasiassa pieni rahastopesämuna, mutta eläminenkin maksaa :--)

@wamserma in linux i stick with pipx but i could give it a shot in macOS thanks :-)