Generally yes, unless it’s the original source of a story.
e-celeb content and news aggregators are never the original source of a story.

That some can and already do that on the video sites they already browse.

People like shorts too, but that doesn’t mean Lemmy should be infested with such content.

We went from spam “news sites” to spam videos. Maybe an “original source” policy should be applied by moderators!

This applies to both hare and on !rust@programming.dev

Now that others got all the technicalities out of the way, maybe ChromeOS/ChromiumOS would be something along the lines of what you’re looking for? not that anyone should choose to daily-drive it.

That’s exactly the communicated meaning I was concerned an oblivious reader might get. You can use an updated Rust compiler 10 years in the future while your crate is still on 2015/2018/2021 edition. Editions are NOT software versions.

I might expect the Rust ecosystem to adopt these new features.

This again points to you maybe not understanding how editions work, or maybe I’m just reading it wrong again. But you “upgrading” has no effect on your dependencies, and vise versa (except indirectly if MSRV is a factor as another user mentioned).

Just upgraded

Weird wording!
Maybe it’s just me, but this may give the impression that it’s something that is strictly needed, or will provide any immediate improvement, which is not the case, unless you’re still actively working on these projects and plan to use/depend on features/behaviors required by the new edition.

even if he wrote “half”, he would still be wrong, and still suffering from multiple levels of dissonance.

• Not all x86 laptops are like you describe.
• Non-Apple ARM laptops exist. They in fact predate Apple’s move to ARM. Not only that, Linux was actually the primary target platform for many of them.

Sure, there were/are still some bits and pieces of hardware support missing, but the overall experience rivaled or exceeded what you could get on most x86 laptops.

But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one).

how many levels of dissonance is that?

Pretends to rage-quit from contributing, not resigns.

Good riddance, unless they learn how to behave like well adjusted adults, instead of constantly playing to a microblogtard crowd. <= That’s what would I have wrote if something relevant actually happened, which is not the case.

And this is coming from a Rustacean.

This more belongs to a “linux drama” community (if one exists).

Is there a tiling Wayland compositor out there that supports applying custom shaders to windows (similar to picom)? This has been a known limitation for many years. And I brought it up myself with a couple of compositors’ developers, and they told me that it would break direct scan-out, and I told them that I would be fine with that, and then discussions fizzled out.

I also tried an x11vnc alternative I don’t remember the name of, and besides the generally buggy experience, it completely broke when power management kicked on the sever side (turning off the monitor IIRC). So that’s another show stopper, although maybe not as relevant as custom shader support which I need for applying my custom color inversion shaders to specific windows, otherwise, my vision would go bad quickly.

So yeah, I will be sticking with my Awesome WM (+picom +x11vnc) setup for a while too.

The highest cost for most projects comes from the CI runners.

i2p only provides anonymous transport, so not relevant at all.

ipfs is joke tech (you would be better off building something on top of good old torrents).

A fanatic microblogger* inflating some kernel drama, and inviting the microblog echo chamber and the whole internet gantry to chime in… is surely worthy of being the hottest topic of the day.

* Yes, I know who they are.

Since cargo-edit broke

Sparse indices support got added in last September. A perma-WIP pull request that added support for them existed for much longer.

The most important part of curl is the library, not the CLI tool. And the TLS backend is very much relevant due to varying features supported, different licenses involved, and varying levels of ease when it comes to building and distribution.

That’s when you’re providing binaries. Otherwise, you would have to be wary of potential compatibility issues with libcurl packages provided by different Linux distributions for example.

See CURLOPT_ECH for a recent and still evolving example of this.

What serious Linux users buy GPUs based on raw gaming performance on release week?

I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.

My current GPU is an AMD/Radeon one because of that. But I’m reconsidering my position when my next hardware upgrade comes.

I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.

If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.

Another huh from me. Or maybe I’m missing something, because this should all be obvious.

The source of the standard library is a rustup component that everyone should have installed. As for crates, you don’t have to manually download any sources. Just add the crate as a dependency, and jump around definitions as much as you like. You can remove the dependency later if you decide to not use it.

this wasn’t easy for me to find

Huh! This is the internal ExitCode, and it’s two jump-to-definition calls away. The first to get to the public type definition, and the second from the public type’s struct field to the private type.

ExitCode is a struct, therefore it behaves like a type with many fields which define the types contained in the struct.

That’s a bit too off. structs in rust are product types. A struct may define zero or more fields. And fields can be named or not. if not, such structs are called tuple structs.

In the doc page, if you clicked on source, it would have taken you to the definition.

pub struct ExitCode(imp::ExitCode);

That’s a public struct with one unnamed private field. The type of the private field also happens to be private/internal.

As for why, usually the purpose is providing type safety, a unified interface,… etc. Notice how for example a windows-only extension trait is implemented that allows converting raw u32 exit codes into ExitCode.

So now you have exit codes possibly sourced from u8 or u32 values depending on the platform. And you need a safe unified interface to represent them.

I hope that’s an enough starting point.