doing PR today...

never get involved in politics... unless there's a neo-nazi in the government 🤦

Lagging #LKML a bit, and also a bit late with my PR because I've been helping to expose a neo-nazi minister. Cannot believe this could ever happened in #Finland @torvalds

@esoterra thank you :-) i really appreciated your feedback. i have zero use for supporting feedfback for a draft like this because that never has refined anything...

@esoterra i get that but that's not really an unsolvable technical problem (sorry not back up for this claim at this point but it was great point, thanks).

@esoterra why i do such dumps here is that this type of stuff can start shift away your main focus, this way i can kind of sharpen it. and i don't mind being totally wrong on internet :-) that has been my main job for many many years anyway.... maybe i start to use #braindump hash tag for these to make it more obvious.

@esoterra we can agree to disagree at this point (for now) :-) I don't like it but if it works for most all cool. Web is not my main territory, or something I would get paid for the moment (I'm extending kernel atm to have user space vtpm drivers and wrote in-kernel RISC-V Keystone driver) but your comments motivate at least to refine the text one day!

@esoterra any feedback to this thread is welcome (and appreciated) but i don't promise to answer it but if i rework on this, then i will try to address it better. thank you...

this does not disqualify wasm but it is not a design, it is evolution of asm.js. this type of agile/evolutional self-directing model is great for most of the web but for any ABI it is not how you should do it. I could bet money that if things were done from clean slate, we would have something that would not be wasm, even if the end solution would not be riscv. subsetting extensions and layers.

If one can accept that premise, the 2nd premise would be to show that RISC-V "can do it " (even if it sucked). I think this can be made to work.

So 3rd thing to show is that it would be optimal, or more look like "good enough", and objectively better than wasm.

This is roughly how I would start to break up and structure it to a more whitepaperish form....

@esoterra at this point is just a dump with no emphasis to sell it. i just wanted it written down somewhere but i do appreciate your comment because that gives input to refine it possibly in future. frankly, i don't believe this could happen because W3C is too conservative industry body so not a focus point.

i think i already gave some thoughts on some things that you asked but obviously it is my fault (not yours) if it did not get through, i.e. my comms sucks.

so yeah, sorry for dissatisfying answer. i just hate when i loose some idea and mastodon is pretty good to put unconstructive and unfinished ideas :-) I'm sorry for not liking wasm but I stick to that unforutantely without proper study for now,...

I’ve hacked on RISCV for 3,5 months, and some thoughts have developed.

I think that #WebAssembly was a wrong design choice for #web and instead #W3C should have gone with a real micro architecture. #RISCV provides answer for this.

Benefits:

1. Wider than web industry behind it.
2. Made to last decades without breaking backwards compatibility.
3. Ultra-light state transformations (context switches and alike).
4. Well-defined layering and extensions.
5. More open and appealing to open source hackers, moving power away from industry controlled WG’s.
6. Catch up game with many CPU features would stay in sync. E.g. for VM based (i.e. not like SGX which is process based) confidential computing could just map the primitives for the underlying bare-metal CPU architecture.

WebAssembly is in the end really bad implementation of a great idea overally. Forth i interpreter was cool when JVM came out.

Here if W3C and browser vendors dared to take step back, it would result a stable innovation in the web for decades forward.

Transforming RISC-V to WebAssembly is ofc possibly but I don’t see it as an end solution, as all the crappiness of #wasm gets in the way, and e.g. benefit 6 would not even exist.

#notetomyself `curl -sS https://starship.rs/install.sh | sh -s -- -h` (tested on #linux and #macos)

#remindertomyself #git:

git submodule foreach --recursive git reset --hard
git submodule foreach --recursive git clean -f -d -x

I don’t like the policy of #buildroot in that you have to subscribe to the mailing list, in order to be able to send bug fixes. Not possible, when you try to proactively limit the incoming #email flow to the minimum.

Git should probably canocalize patch always before acting on it with realpath(). That would remove such corner cases. https://man7.org/linux/man-pages/man3/realpath.3.html

or more like a corner case:

1. PWD is inside the repository.
2. The relative path starts outside.

a cosmetic #bug in #git:

suppilovahvero in keystone on  jarkkojs/spirs via △ v3.25.1
$ git add ../keystone/patches/linux/linux.vtpm.patch
fatal: ../keystone/patches/linux/linux.vtpm.patch: '../keystone/patches/linux/linux.vtpm.patch' is outside repository at '/home/jarkko/work/nisec/spirs/keystone'

#ctags and/or #cscope are tbh better options for browsing #kernel than #clangd because two former ignore kernel config/build when scanning for new tags. perhaps get_compile_commands.py could be improved a bit. #linux

testing #asciinema and #agg https://github.com/asciinema/agg

#remindertomyself when editing #email with #aerc use CTRL-j and CTRL-k to move between header fields and the message body. I’ve got stuck to the CC list a few times and have sorted it out by killing the whole process, so this is definitely an improvement :-)

The key for finding out how to fix this was man aerc-tutorial. I was cursing for a while because man aerc was not giving me the answers, until I realized that there is another man page!

#notetomyself on #macos:

defaults write -g NSWindowShouldDragOnGesture -bool true