Not to minimize their work, which is actually amazing!
you wouldn't know because..
Still based on GNOME.
you don't have a single clue about what they are actually doing.
Not to minimize their work, which is actually amazing!
you wouldn't know because..
Still based on GNOME.
you don't have a single clue about what they are actually doing.
Why Aren't We Embracing IPFS?
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
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.
As a user of both libcurl (haven't followed it's development for years though) and hyper, I'd say either commit to making hyper the default at some point and make that a priority, or drop it altogether. And since there is no intention/plan to do the former, then latter does indeed follow logically.
Meh, everyone scaring you into thinking you don't own your own mind.
Assuming your boss is not the dangerous kind (beyond legal threats), and if the goal is to make it FOSS, then do it using an alias first. Do it differently. Use components/libs/algos from other people at first, even if they are not perfect. Make those parts easily pluggable/replaceable which would be good design anyway. The code then wouldn't be wholly yours, not even your alias self.
You can join the project later with your real identity as an interested domain expert (maybe a bit after not working for the same boss). Start contributing. Become a maintainer. And maybe take over after a while. You can start replacing non-optimal components/libs/algos with better ones piecemeal.
Oh, and if Rust wasn't the choice of implementation, use it this time.
What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian
[closes tab]
fn foo(&big, &chungus)
is out,
async fn foo(&BIG_GLOBAL_STATIC_REF_OR_SIMILAR_HORROR, sendable_chungus.clone())
is in.
Or maybe you know
fn foo(&big, &chungus)
is out
async fn foo(big, chungus) -> (big, chungus)
is in
Or
async fn foo(big, chungus) {
// ...
tx.send((big, chungus)).await?;
// ...
}
is in
Moving (movable/sendable) data is not limited by number or direction, you know. And that second one even makes use of them great Hoare channels! And gives us control on how long we hold on to data before sending it back (modified or not). But I digress. Let's go back to the important talking point that Hoare was right!
Languages: Just Rust!
You got my attention.
fn app(cx: Scope) -> Element { let mut count = use_state(cx, || 0); render!( rect { height: "20%", width: "100%", background: "rgb(233, 196, 106)", padding: "12", color: "rgb(20, 33, 61)", label { font_size: "20", "Number is: {count}" } } rect { height: "80%", width: "100%", background: "rgb(168, 218, 220)", color: "black", padding: "12", onclick: move |_| count += 1, label { "Click to increase!" } } ) }
Oh, it's stringly-typed Rust.
Yeah, no thanks.
Yay. My first ad-masquerading-as-a-genuine-post experience on Lemmy!
Thus, we’ve developed a cargo extension that transparently queries the Phylum API for information about a package before it’s allowed to build.
Only our* malware-like behaviour is blessed. Because it's a feature. And research-based. And security-oriented. And commercial! We told you about it beforehand and sold you the idea.
* Assuming the malware discovered is not theirs too.
I hate that I'm linking to Reddit, but I'm just reminded of this.
Some of us knew where all the obsession with dependencies' compile times will lead, and triggered the alarm sirens, if half-jerkingly, years ago.
Compile times, and more specifically, dependencies compile times, is and has always been the most overblown problem in Rust. We would have some sort of sccache public repositories or something similar by now if it was that big of a problem.
And yes, I'm aware proc-macro
crates in particular present unique challenges in that field. But that shouldn't change the general stance towards the supposed "problem". And it should certainly not trigger such an obsession that would lead to such a horrible "solution" like this serde
one.
I thought I saw this weeks ago.
yep
Anyway, neovim+rust-analyzer+ra-multiplex is all I need.