Jarkko Sakkinen
Posts
4818Following
319Followers
488OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 1 year ago
I have accountant for my company now. Had a meeting yesterday. I decided to go to a traditional accountant office and pay for personal accountant. I think this spending will come back!
I.e. not using one of those fancy Internet platforms. IMHO, great accountant is the same for a company as a great doctor is for a person.
I.e. not using one of those fancy Internet platforms. IMHO, great accountant is the same for a company as a great doctor is for a person.
0
0
2
@ljs is that a weight lifting term :D https://thegainzbox.com/
1
0
1
Jarkko Sakkinen
jarkko
it is crazy how acid you can get with u-he bazille without even getting even into using filters yet. phase distortion and fractalize rock
0
0
0
@anotherwalther The expectations on timeline might also be too optimistic. Rust support has been in the mainline like couple of years or something. It's not a long time and not much progress is expected on overall acceptance during that period. Some patience can go a long way.
Even outside Rust circles some people give up on kernel development because a major feature patch set can take about the same time to upstream going to through various forms and sizes, as Rust has been available.
Even outside Rust circles some people give up on kernel development because a major feature patch set can take about the same time to upstream going to through various forms and sizes, as Rust has been available.
0
0
0
@anotherwalther In addition to documentation, for Linux it is not sustainable to have defconfig's, which don't compile with GCC. So other way to make Rust more feasible for Linux is to contribute to GCC-Rust backend. Up until it is as usable tool for Rust based kernel development, the whole language is cool demo but cannot be scaled handling any of the kernel internals. It is a huge capping element here and I don't think all Rust folks necessarily understand the importance of GCC compilation.
1
0
0
Jarkko Sakkinen
jarkko
@anotherwalther It could be also that checking the details would require reverse engineering huge chunks of Rust code base, which is simply not possible to commit into. Some people might use Rust if the barrier is not too high, but not all people are particularly excited about it, which is a fair position.
It could be also just my own beliefs but I got impression from some Rust posts sometimes that some people think that there would be some kind of large-scale plan to reimplement Linux with Rust. It might be something that Microsoft and Google would like to happen but otherwise such plan does not exist.
There is neither a plan to not do it. The point is that we look at best for Linux maybe few weeks ahead and the overall result is distributed consensus.
That leads to the conclusion that only way to increase Rust adaptation is to make it lower hanging fruit than it is today. Documentation is a great starting point.
It could be also just my own beliefs but I got impression from some Rust posts sometimes that some people think that there would be some kind of large-scale plan to reimplement Linux with Rust. It might be something that Microsoft and Google would like to happen but otherwise such plan does not exist.
There is neither a plan to not do it. The point is that we look at best for Linux maybe few weeks ahead and the overall result is distributed consensus.
That leads to the conclusion that only way to increase Rust adaptation is to make it lower hanging fruit than it is today. Documentation is a great starting point.
1
0
0
@anotherwalther NCC Group actually blog articles only few days ago still available with really good architecture insight on the use of Rust in Linux. It had comparisons to C constructs too, which made the reasoning sound.
I have no idea why they removed this great series but it was with the topic "Rustproofing Linux". I only recently bumped into them. It was kind of material that would be nice if NCC would contribute it to the kernel documentation. At least for me cleared up bunch of things that I did not get before.
I have no idea why they removed this great series but it was with the topic "Rustproofing Linux". I only recently bumped into them. It was kind of material that would be nice if NCC would contribute it to the kernel documentation. At least for me cleared up bunch of things that I did not get before.
1
0
1
Jarkko Sakkinen
jarkko
Good to know enjoyed this article, https://it-notes.dragas.net/2024/08/29/make-your-own-cdn-openbsd/
0
0
0
@anotherwalther Sorry for going over the top with this :-) I think this is still one of the best and easiest ways to improve the situation.
[and even if documentation sucks that does not give right to be asshole]
[and even if documentation sucks that does not give right to be asshole]
1
0
1
Jarkko Sakkinen
jarkko
Yet another audio post. this is my basic "per-channel" use case for tape emulation. I care about the eq curve here mainly. for most sounds you want to soften the top and bottom.
It is like perfect placeholder EQ + saturation for a channel. Then by adjusting mixer gain I can go a long way before doing anything more sophisticated :-)
It is like perfect placeholder EQ + saturation for a channel. Then by adjusting mixer gain I can go a long way before doing anything more sophisticated :-)
1
0
2
@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