@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 :-)

@oherrala Näinhän se on tottakai myös :-) Ei sijoittamista silti pidä ottaa ainoana prioriteettina, vaan NATO-termein on hyvä kehittää kaikkia kyvykkyyksiä, kun elämässä voi sattua muutakin kuin henkilökohtainen konkurssi...

Esim. jos olisi pakko valita lapsen kohdalla järkevän harrastuksen ja sijoittamisen kohdalla, niin kyllä mun mielestä järkevää harrastusta kannattaa painottaa taloudellisen turvaverkon. Taitava persaukinenkin tyyppi löytää aina paikkansa.

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

I use #Lucidchart for these because UML style used by #drawio is the crappy and convoluted UML version, and with #yEd you have to go too great lengths for a trivial task: https://yed.yworks.com/support/qa/2054/is-a-data-flow-diagram-palette-available

It is sad how weak the support is for this diagram type among the tools, given that it is the most useful of them all...

Edit: actually draw.io also has old school versions in the palette so I was wrong. I might use that in the future :-)

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 :-)

@vitaut trolling fingers try to make me write something sarcastic but i bravely fight against my temptation :-)