16
No. This one is actually cool, useful, and innovative. And it tries to do some things differently than everyone else.
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.
Yesterday I was browsing /r/programming
:tabclose
Hate to break it to you, but you're not really learning.
You should be thankful it's not 18446744073709551615 days to go.
While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.).
:tabclose
A reminder that the Servo project has resumed active development since the start of 2023, and is making good progress every month.
If you're looking for a serious in-progress effort to create a new open, safe, performant, independent, and fully-featured web engine, that's the one you should be keeping an eye on.
It won't be easy trying to catch up to continuously evolving and changing web standards, but that's the only effort with a chance.
Examples ARE usage documentation.
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?
What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian
[closes tab]
Is everyone genuinely liking this!
This is, IMHO, not a good style.
Isn't something like this much clearer?
// Add `as_cstr()` to `NixPath` trait first
let some_or_null_cstr = |v| v.map(NixPath::as_cstr)
.unwrap_or(Ok(std::ptr::null()));
// `Option::or_null_cstr()` for `OptionᐸTᐳ`
// where `T: NixPath` would make this even better
let source_cstr = some_or_null_cstr(＆source)?;
let target_cstr = target.as_cstr()?;
let fs_type_cstr = some_or_null_cstr(＆fs_type)?;
let data_cstr = some_or_null_cstr(＆data)?;
let res = unsafe { .. };
Edit: using alternative chars to circumvent broken Lemmy sanitization.
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!
view more: next ›
BB_C
joined 2 years ago
The whole premise is wrong, since it's based on the presumption of C++ and Rust being effectively generational siblings, with the C++ "designers" (charitable) having the option to take the Rust route (in the superficial narrow aspects covered), but choosing not to do so. When the reality is that C++ was the intellectual pollution product of "next C" and OOP overhype from that era (late 80's/ early 90's), resulting in the "C with classes" moniker.
The lack of both history (and/or evolution) and paradigm talk is telling.