Because it's an overhyped joke successfully utilized by crypto scammers.
Neither content addressing, nor distributed hash tables (or key-value stores, or whatever) were novel ideas.
The combination of the two is not a novel idea.
For p2p, torrents, work as another user already pointed out (initial realease 2001).
For a distributed filesystem, look at Tahoe-LAFS (initial release 2007).
For a full anonymous p2p distributed filesystem, check out (real) Freenet, called Hyphanet now (initial release 2000).
And no, if you need anonymity, an anonymous transport (e.g. using libp2p) is not enough. You need to consider anonymity at each step like Freenet does.
These are three real non-overhyped products one can draw inspiration from. IPFS? not so much.
You can look around for more examples. I always found this Wikipedia page about file sharing in Japan interesting, since it mentions networks not well known to the rest of the world:
https://en.wikipedia.org/wiki/File_sharing_in_Japan
No errors from plume crates, but we get errors in a couple of locked dependencies:
error[E0422]: cannot find struct, variant or union type `LineColumn` in crate `proc_macro`
--> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/wrapper.rs:479:33
|
479 | let proc_macro::LineColumn { line, column } = s.start();
| ^^^^^^^^^^ not found in `proc_macro`
|
help: consider importing one of these items
|
1 + use crate::LineColumn;
|
1 + use crate::fallback::LineColumn;
|
help: if you import `LineColumn`, refer to it directly
|
479 - let proc_macro::LineColumn { line, column } = s.start();
479 + let LineColumn { line, column } = s.start();
|
Compiling generic-array v0.14.6
error[E0422]: cannot find struct, variant or union type `LineColumn` in crate `proc_macro`
--> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/wrapper.rs:496:33
|
496 | let proc_macro::LineColumn { line, column } = s.end();
| ^^^^^^^^^^ not found in `proc_macro`
|
help: consider importing one of these items
|
1 + use crate::LineColumn;
|
1 + use crate::fallback::LineColumn;
|
help: if you import `LineColumn`, refer to it directly
|
496 - let proc_macro::LineColumn { line, column } = s.end();
496 + let LineColumn { line, column } = s.end();
|
Checking once_cell v1.17.0
error[E0635]: unknown feature `proc_macro_span_shrink`
--> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/lib.rs:92:30
|
92 | feature(proc_macro_span, proc_macro_span_shrink)
| ^^^^^^^^^^^^^^^^^^^^^^
Let's see if a full (semver-compatible) deps update works:
% cargo update
% cargo check
This succeeds.
I will let you pick it from here.Should be a good learning experience.
I have no specific knowledge of this stuff. But the generic answer is an obvious one.However Python code does it can be replicated in Rust.For example, if python code executes the driver as a subprocess, then that too can be done in Rust.So checking how Python code does it will probably lead to an answer to this question.
Maybe ask a web dev community about this.There could be something better written in Rust.There could be something better NOT written in Rust.They should know.
Didn't read the post yet. But for future reference, posting archived links to posts from that website is probably preferable since it doesn't appear to be hosted in a way that can handle large traffic.
The problem is, if you knew anything about the subject matter, you would know that even JAVA code ends up being compiled ahead-of-time by ART to ELF binaries on Android.Even non-devs know this stuff!
I didn't understand your sentence. But:
Having concerns is valid.Having them in the context of this story/ad is misplaced.
IBM invested 1B$ in Linux all the way back in year 2000 (imagine how much that is worth with tech inflation), and they did it again years later.
That 1M$ is nothing. It's not nearly enough to control the Rust foundation for one year, let alone controlling the Rust project as a whole. Calling it a "Vote of Confidence in Rust's Future" was probably a good-spirited joke from the author, at least I hope it was.
Note that IBM still doesn't control Linux (even after acquiring RedHat), and we still have no problem calling them evil. Some of us still have no problem calling MS evil either, although many of the new crop of developers won't, because for them the chance to have the financial privilege of working there someday outweighs any moral considerations. Incidentally, there is a good intersection between this group, and the group that takes moral posturing about whatever in-group approved cause of the month to the maximum. Ironic, isn't it?
This is effective advertisement, not a donation. A real ad (with a campaign) would probably have cost much more, and wouldn't continue to be propagated for free months after the ad campaign is over, like this peace of news.
This type of ad is also much harder to filter/block, since not only it appears to be site-native, but also topic-native.
What value is this blog supposed to be adding exactly?The fact that top-level and API descriptive explanations are important?The fact that some projects don't have complete documentation?To whom exactly would this be considered new information?
The fork wouldn't be that different from whatever upstream Iced snapshot it last synced with. There are two major, if peripheral, changes still. A renderer for some Wayland special needs, and some integrated accessibility support. At least that was the case until a few weeks ago. I don't think anything significant changed since.
So the Iced API itself is largely the same. However, since this is built on top of Iced. COSMIC apps are more inclined to use abstractions and tools from libcosmic wherever applicable instead of using Iced API directly. But you still see plenty of direct Iced API use.
Because it's an overhyped joke successfully utilized by crypto scammers.
Neither content addressing, nor distributed hash tables (or key-value stores, or whatever) were novel ideas.
The combination of the two is not a novel idea.
For p2p, torrents, work as another user already pointed out (initial realease 2001).
For a distributed filesystem, look at Tahoe-LAFS (initial release 2007).
For a full anonymous p2p distributed filesystem, check out (real) Freenet, called Hyphanet now (initial release 2000).
And no, if you need anonymity, an anonymous transport (e.g. using libp2p) is not enough. You need to consider anonymity at each step like Freenet does.
These are three real non-overhyped products one can draw inspiration from. IPFS? not so much.
You can look around for more examples. I always found this Wikipedia page about file sharing in Japan interesting, since it mentions networks not well known to the rest of the world: https://en.wikipedia.org/wiki/File_sharing_in_Japan