Jarkko Sakkinen
Posts
4981Following
329Followers
494OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
@oranki This is a valid point!
And simple batched sync's with rclone have been much nicer 99% of the time nice behavior as far as I'm concerned.
Sometimes tho would be nice to have quick real-time sync'd access. So what I do instead is that I simply run it at localhost 🤷 Then I know at least when I spending my quota, right? :-)
Thanks for the comment! Was a money saver...
And simple batched sync's with rclone have been much nicer 99% of the time nice behavior as far as I'm concerned.
Sometimes tho would be nice to have quick real-time sync'd access. So what I do instead is that I simply run it at localhost 🤷 Then I know at least when I spending my quota, right? :-)
Thanks for the comment! Was a money saver...
0
0
1
@codrusofathens ... and counter arguments are 90% of time qualitative arguments, e.g. "we have this contract/abstraction/invariant so you're wrong".
I only believe in quantitative arguments for the most part. E.g. spec growth is one of such, e.g. you can compare that to a spec that does not grow. Would be foolish to think that spec growth does not have a negative impact to static analysis.
But for any quantitative arguments it is hard to say anything conclusive. Can't beat Gödel's theory of incompleteness, right? ;-)
I only believe in quantitative arguments for the most part. E.g. spec growth is one of such, e.g. you can compare that to a spec that does not grow. Would be foolish to think that spec growth does not have a negative impact to static analysis.
But for any quantitative arguments it is hard to say anything conclusive. Can't beat Gödel's theory of incompleteness, right? ;-)
0
0
1
@codrusofathens and the whole narrative that Rust almost invented memory safety is like totally untrue.
E.g. in the backend Java has delivered the whole gist of memory safety literally decades and JVM's JIT is a monster dealing with server payloads... It is optimized by the best breed of Intel, ARM etc. companies for each micro-architecture.
When looking at beyond the hype I feel that there's exactly one area where I find Rust best tool so far: cli-interfaces. For tpm2-cli I chose Rust because input validation was easier with it than in my previous python experiments (I've done a small Python based stack for kselftest previously).
Not a revolution really ;-)
E.g. in the backend Java has delivered the whole gist of memory safety literally decades and JVM's JIT is a monster dealing with server payloads... It is optimized by the best breed of Intel, ARM etc. companies for each micro-architecture.
When looking at beyond the hype I feel that there's exactly one area where I find Rust best tool so far: cli-interfaces. For tpm2-cli I chose Rust because input validation was easier with it than in my previous python experiments (I've done a small Python based stack for kselftest previously).
Not a revolution really ;-)
2
0
1
Jarkko Sakkinen
jarkko
@codrusofathens yeah, it is f*****g horror story how this plays :-) absolutely hate rusty forking culture.
1
0
0
@hunger I do like Rust, I'm using it too, and have contributed to some upstream projects features and also have some things of my own going on too (still unreleased ASN.1 to bytecode compiler, and alternative super light-weight TPM2 stack).
I just generally learn best by applying "learn by hate"-methodology ;-)
Like when doing kernel dev, I look Linux more like how bad it is, and from that angle I find ways to improve it. And even look into how great NT kernel or Darwin are doing some things, whereas Linux is under-performing.
I just generally learn best by applying "learn by hate"-methodology ;-)
Like when doing kernel dev, I look Linux more like how bad it is, and from that angle I find ways to improve it. And even look into how great NT kernel or Darwin are doing some things, whereas Linux is under-performing.
1
0
0
@hunger Except the one that I already mentioned:
1. Rust static analysis can get only worse over time, given the steady complexity growth in the spec.
2. C static analysis can get only better over time, given a stable and compact spec. And it does. Tooling for analyzing C is a whole multi-million industry of its own.
1. Rust static analysis can get only worse over time, given the steady complexity growth in the spec.
2. C static analysis can get only better over time, given a stable and compact spec. And it does. Tooling for analyzing C is a whole multi-million industry of its own.
1
0
0
@hunger it is well anchored comparison also given the build artifact: ELF binary (or COFF/PE).
Also in binary analysis C wind by a large margin given its trivial binary structure, which is result of compact language spec with only constructs that are great fits for any possible microarchitecture ABI.
Also in binary analysis C wind by a large margin given its trivial binary structure, which is result of compact language spec with only constructs that are great fits for any possible microarchitecture ABI.
1
0
0
I find it somewhat easy because the application category is well defined in my post:
- I based amount of C dependencies based on what I’m typically seeing in the project file. GNOME is a project umbrella, not a dependency.
- Dependencies might be larger but there are much less forks, larger user bases, which adds up to the QA and generally well-defined processes.
- For many Rust libraries I find sometimes hard to trust, given that they have not been exposed that much in the “warzone”. And this is sort of feature of the ecosystem too because you pile up your app stack from these nuts and bolts (also known as “crates”). You end up constructing yourself the “big dep”.
2
0
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
A typical #TUI #Rust application has usually about ~600 dependencies or similar figure.
A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.
And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷
What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.
Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.
Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...
#rustlang #gcc #llvm #toolchain
A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.
And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷
What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.
Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.
Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...
#rustlang #gcc #llvm #toolchain
3
2
6
Do want to slander our neighbor nation but I’m bit skeptical towards claim that Estonia had its first blockchain in 2007.
Bitcoin paper came out in 31st of October, 2008, so possible conclusions:
- Bitcoin was not the first blockchain like within the metrics for such data structure that the paper defines.
- KSI has some of the characteristics of those defined in the original Bitcoin paper but is not an “actual” blockchain.
Without better knowledge, bullet 2 is pretty good base assumption. Or who knows, perhaps Satoshi Nakamoto is an Estonian citizen or a group of citizens.
1
0
1