Jarkko Sakkinen
Posts
4417Following
315Followers
471OpenPGP: 3AB05486C7752FE1
@ljs Good to hear!
I got a job too from London actually.
I was also considering offer from this huge GPU/GPGPU/AI company dominating the market that you've probably never heard of but I thought that maybe that is not my passion in the end... Just did not feel it.
I had four interviews to Parity Technologies and I liked everyone I talked to, passed their tests so since it felt good I agreed to make a contract 🙂 Can work remotely of course but I'd predict that there is good chance to be able to visit London sooner or later. Can't wait to get Starbucks country mug to my ever growing collection!
I got a job too from London actually.
I was also considering offer from this huge GPU/GPGPU/AI company dominating the market that you've probably never heard of but I thought that maybe that is not my passion in the end... Just did not feel it.
I had four interviews to Parity Technologies and I liked everyone I talked to, passed their tests so since it felt good I agreed to make a contract 🙂 Can work remotely of course but I'd predict that there is good chance to be able to visit London sooner or later. Can't wait to get Starbucks country mug to my ever growing collection!
1
0
2
@raggi Thanks for the comment!
I'm a bit concerned about code generation but obviously my concerns might not have as much as weight as I think they do now :-) [never mind to get things wrong, that's why I say a lot of stupid things on Internet so that I continue learning]
C or and Rust without async is for me like that if I look at a patch, i.e. just the diff I can get idea the structure of generated assembly code, as long as I know also the CPU architecture and calling convention reasonably well. For me code with async is not as predictable because vast amount of code generation but maybe with more practice and disassembling such changes that radar would improve over time 🙂
I have to say that best learning exercise using Rust was to write an executor. Took like couple of afternoons to get it working and learned how Future, Pin and other traits play in that game. If I had not done the exercise, I would be still hitting my head against the wall on that topic. That and grasping std::marker::PhantomData can get one far with Rust 🙂
I'm a bit concerned about code generation but obviously my concerns might not have as much as weight as I think they do now :-) [never mind to get things wrong, that's why I say a lot of stupid things on Internet so that I continue learning]
C or and Rust without async is for me like that if I look at a patch, i.e. just the diff I can get idea the structure of generated assembly code, as long as I know also the CPU architecture and calling convention reasonably well. For me code with async is not as predictable because vast amount of code generation but maybe with more practice and disassembling such changes that radar would improve over time 🙂
I have to say that best learning exercise using Rust was to write an executor. Took like couple of afternoons to get it working and learned how Future, Pin and other traits play in that game. If I had not done the exercise, I would be still hitting my head against the wall on that topic. That and grasping std::marker::PhantomData can get one far with Rust 🙂
0
0
0
Jarkko Sakkinen
repeated
repeated
Greg K-H
gregkh
Here's a link to the slides for my "Why are there so many kernel CVEs?" talk I gave at OSS China yesterday:
https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be
Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security
It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.)
https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be
Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security
It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.)
4
24
36
Jarkko Sakkinen
jarkko
At Profian I did Rust with managed wasm bytecode payloads.
At Tampere University I hacked RISC-V SoC's.
At Parity Technologies, I'll do Rust with managed RISC-V *bytecode* payloads.
My work career seems to move forward by combining patterns.
At Tampere University I hacked RISC-V SoC's.
At Parity Technologies, I'll do Rust with managed RISC-V *bytecode* payloads.
My work career seems to move forward by combining patterns.
0
0
1
Previous response was a disclaimer to point out that I use this feature and even like it. Some people have tendency to think that context dependent evaluation of a language features equals to "disliking" Rust somehow overall ;-) Kernel creates the surroundings for async to be awesome in *user space*.
0
0
1
For learning and using async in user space (as I hear people saying how difficult it is, which I don't think it is).
Write your own damn executor :-) Use it with your async code until you get it because you probably end up fixing it a lot. It can be bad and should probably be switched eventually to a production quality executor but this is fastest learning curve I know and this is how I learned its internals because I don't like reading about programming languages :-)
Write your own damn executor :-) Use it with your async code until you get it because you probably end up fixing it a lot. It can be bad and should probably be switched eventually to a production quality executor but this is fastest learning curve I know and this is how I learned its internals because I don't like reading about programming languages :-)
1
0
1
Jarkko Sakkinen
jarkko
Edited 10 months ago
I think Linux would be better off not supporting async feature of Rust.
It's not that it cannot be done but it will result long-term maintained code that is hard to reverse to opcodes at the CPU core just by looking at the snippet code.
This is exactly the gist of any possible kernel patch review..
I'm not disregard its usefulness in user space code but it could be even counter-productive tool in kernel code.
It's the added cost of time for kernel maintainers that weights here. Most (all) could cope with non async Rust from the perspective of what CPU does when it executes a specific peace of Rust code. Developer productivity is the most insignificant portion of kernel development cycle. I'm 100% sure that async is not existential feature, meaning that any possible feature could not be implemented without it.
#rust #linux #kernel
It's not that it cannot be done but it will result long-term maintained code that is hard to reverse to opcodes at the CPU core just by looking at the snippet code.
This is exactly the gist of any possible kernel patch review..
I'm not disregard its usefulness in user space code but it could be even counter-productive tool in kernel code.
It's the added cost of time for kernel maintainers that weights here. Most (all) could cope with non async Rust from the perspective of what CPU does when it executes a specific peace of Rust code. Developer productivity is the most insignificant portion of kernel development cycle. I'm 100% sure that async is not existential feature, meaning that any possible feature could not be implemented without it.
#rust #linux #kernel
1
5
4
Jarkko Sakkinen
jarkko
Edited 10 months ago
TDR Molotok is IMHO the best thing ever in software and/or hardware when you want the most hyper reactive compressor in existence with reasonably clean sound at extremes.
In my books, when ducking with kick some other channel, it beats ShaperBox3, LFOTool and similar plugins. You get both surgical and musical off-the-bad. The sound just feels right :-)
Molotok is also great alternative to give a shot when having either 1176 or dbx160 would be, or is already used. Worth of trying out.
#tokyodawn #molotok #plugins
In my books, when ducking with kick some other channel, it beats ShaperBox3, LFOTool and similar plugins. You get both surgical and musical off-the-bad. The sound just feels right :-)
Molotok is also great alternative to give a shot when having either 1176 or dbx160 would be, or is already used. Worth of trying out.
#tokyodawn #molotok #plugins
0
0
0
Jarkko Sakkinen
repeated
repeated
Storj is a resource (or memory) manager. All software I've worked in the past from drivers up to applications ends up converging into a resource manger. Once you can nail the resource manager use case, the world will be eventually yours. It's simple as that.
Wolt, Ueber and Spotify are also resource managers and not much else. For "Spotify" in particular the latency is not there yet but Storj gives the metric that reaching that scale is only few years away.
Wolt, Ueber and Spotify are also resource managers and not much else. For "Spotify" in particular the latency is not there yet but Storj gives the metric that reaching that scale is only few years away.
0
0
0
Jarkko Sakkinen
jarkko
Storj made me consider a blockchain company. Before that, honestly I did not understand the application. I used it for four months without knowing it is token based and ended my Dropbox subscription. Token is like IP address, totally useless without service that makes it tick. In Storj tokens work as B2B in storage sharing. I just pay with my credit card and enjoy the awesome benefits like pay for use and ultra-cheap S3 object storage, never ever thinking crypto 😀 This is how to do it right.
1
0
0
Jarkko Sakkinen
jarkko
Edited 10 months ago
#systemd sucks for #embedded because it is not a design that downscales effectively. Tried systemd few times for smaller devices but it just a bad solution for anything not at least a mobile phone.
An init system that could both upscale and downscale and based on statically linked tight core would be awesome.
It could even be (partially) compatible with the same unit-file format.
In particular for this project it would make a lot of sense to implement such support because this is a need at scale:
https://github.com/uutils/coreutils
Could even gain sponsorships from embedded companies.
An init system that could both upscale and downscale and based on statically linked tight core would be awesome.
It could even be (partially) compatible with the same unit-file format.
In particular for this project it would make a lot of sense to implement such support because this is a need at scale:
https://github.com/uutils/coreutils
Could even gain sponsorships from embedded companies.
1
0
4
Jarkko Sakkinen
jarkko
I have now a registered private company for the sake of being a contractor starting from October: Siltakatu Solutions Oy (aka Ltd).
Siltakatu is my home street [1] in #Tampere and I try to find solutions for various issues in software engineering, so by combining these two facts I got a company name 🤷
Sometimes my solutions suck tho but I do not imply anything about quality in my "company brand" ;-)
[1] The #Finnish word silta translates to bridge and katu translates to street.
Siltakatu is my home street [1] in #Tampere and I try to find solutions for various issues in software engineering, so by combining these two facts I got a company name 🤷
Sometimes my solutions suck tho but I do not imply anything about quality in my "company brand" ;-)
[1] The #Finnish word silta translates to bridge and katu translates to street.
1
0
1
Jarkko Sakkinen
jarkko
Edited 10 months ago
One wisdom that applies both understanding math and programming in deeper level and navigating through that jungle: be stupid and try not to understand 🤷 Stupid is the new smart.
0
0
0