Jarkko Sakkinen
Posts
4936Following
327Followers
492OpenPGP: 3AB05486C7752FE1
@anotherwalther And even some of the existing documentation looks like README for a Github project. Consider e.g.
https://docs.kernel.org/rust/coding-guidelines.html
For a regular kernel developer or maintainer the first question is obviously how do I apply kernel doc comments here? The page neither explicitly state whether RST or MD is used for the function header comments. With the current information I'd be already lost before writing a single line of code because the documentation is not explicit in conventions.
https://docs.kernel.org/rust/coding-guidelines.html
For a regular kernel developer or maintainer the first question is obviously how do I apply kernel doc comments here? The page neither explicitly state whether RST or MD is used for the function header comments. With the current information I'd be already lost before writing a single line of code because the documentation is not explicit in conventions.
1
0
0
@anotherwalther I most blame #Microsoft and #Google for this if any entity because they are key sponsors in Rust specifics. They are handling their kernel teams internally badly. I.e. not blaming the developers themselves.
1
0
0
@anotherwalther OK I get that, BUT my comment is totally orthogonal and almost universal truth. It works everywhere else in the kernel.
Integrate documentation updates as part of the patch review process. Not a big deal.
Obviously toxic behavior is bad but also reach and approachability of Rust-for-Linux is not in a great state, and this only because documentation has not been a priority so far. People tend to evade things that they don't know what they are.
It would not be very educated to think that the problem is only on kernel developers who are not contributing to Rust-for-Linux (which is not same that saying that any bully behavior would be acceptable in any possible situation).
Integrate documentation updates as part of the patch review process. Not a big deal.
Obviously toxic behavior is bad but also reach and approachability of Rust-for-Linux is not in a great state, and this only because documentation has not been a priority so far. People tend to evade things that they don't know what they are.
It would not be very educated to think that the problem is only on kernel developers who are not contributing to Rust-for-Linux (which is not same that saying that any bully behavior would be acceptable in any possible situation).
1
0
0
Jarkko Sakkinen
jarkko
@anotherwalther I really don't know, and I'm not part of that, but I think better integration between documenting and implementing features would help a lot to clear up misconceptions.
Take almost any subsystem, like PCI documentation for instance, and it should be clear that this blocks bi-directional communication: https://docs.kernel.org/rust/
Take almost any subsystem, like PCI documentation for instance, and it should be clear that this blocks bi-directional communication: https://docs.kernel.org/rust/
1
0
0
Jarkko Sakkinen
jarkko
Essential tool with #Storj: https://cyberduck.io/
I guess everyone knows this who has used AWS but I experienced S3 storage first time ever last March :-)
#cyberduck
I guess everyone knows this who has used AWS but I experienced S3 storage first time ever last March :-)
#cyberduck
0
0
0
@jjdavis a classic in this arena is https://github.com/philipl/pifs
0
0
1
Jarkko Sakkinen
jarkkoTo save some time upgrading all U-he plugins I did:
#!/usr/bin/env bash
set -e
wget -q --show-progress -r -np -nd -l1 -A Mac.zip https://uhe-dl.b-cdn.net/releases/ -P dl/
for file in dl/*.zip; do unzip -j -o "$file" -d staging "*.pkg"; done
for file in staging/*.pkg; do sudo installer -pkg "$file" -target /; done
1
0
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
Not a new one but interesting read (also part 2):
https://research.nccgroup.com/2023/02/06/rustproofing-linux-part-1-4-leaking-addresses/
https://research.nccgroup.com/2023/02/06/rustproofing-linux-part-1-4-leaking-addresses/
0
0
0
Jarkko Sakkinen
jarkko
This is great because MPE-parameters can be misused as automation parameters :-) Less automation curves better...
https://u-he.com/news/#mpe-update
https://u-he.com/news/#mpe-update
0
0
0
Jarkko Sakkinen
repeated
repeated
daniel:// stenberg://
bagder@mastodon.social
Edited 1 year ago
Beware, there is an ongoing spambot attack in #GitHub issues in several projects were random people suggest "the fix" is to download a random file from mediafire.com. Like this:
8
9
0
I appreciate people who do all sorts of complex things with Grid etc. but it's not my thing. Still there's lot of simple workflow upgrades that do not require complex engineering.
Another feature I like a lot are these selector devices. One dead simple use case is an effect that needs to be sometimes on and usually off. Then I just have two chains: one empty and another with the effect on. It is quite reliable way to guarantee dry when off and not cause e.g. clicks when turning effects off (which does happen sometimes).
Another feature I like a lot are these selector devices. One dead simple use case is an effect that needs to be sometimes on and usually off. Then I just have two chains: one empty and another with the effect on. It is quite reliable way to guarantee dry when off and not cause e.g. clicks when turning effects off (which does happen sometimes).
0
0
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
IMHO, the most useful thing in its simplicity at least I've had for MSEG in Bitwig: drop-in replacement for LFO Tool.
I actually still use LFO Tool to "design" the side-chain curve and then just match it with Curves modulator and Tool device.
Actually this is what I do a lot: use VST first given e.g. nicer visual feedback and then replicate with stock devices. Best of both worlds as far as I'm concerned :-)
#Bitwig #BitwigStudio
I actually still use LFO Tool to "design" the side-chain curve and then just match it with Curves modulator and Tool device.
Actually this is what I do a lot: use VST first given e.g. nicer visual feedback and then replicate with stock devices. Best of both worlds as far as I'm concerned :-)
#Bitwig #BitwigStudio
1
0
4
@gregkh @kernellogger @pinganini Right! I've tried that with Tianocore and QEMU but never with actual hardware.
To be totally honest, for machines located at my own premises I don't have secure boot enabled at all :-) I've started to use TPM2 tho for those because it gives a lot of convenience for headless machine booting up with hard drive encryption enabled. Secure boot gives me really, umh, not much anything at all.
To be totally honest, for machines located at my own premises I don't have secure boot enabled at all :-) I've started to use TPM2 tho for those because it gives a lot of convenience for headless machine booting up with hard drive encryption enabled. Secure boot gives me really, umh, not much anything at all.
0
0
0