Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)B
Posts
10
Comments
375
Joined
2 yr. ago

  • Not knowing about opt-in telemetry doesn't convey lack of experience, or lack of (relevant) knowledgeability. Especially considering the fact that Arch purposefully keeps the existence of it low-key to avoid the possibility of pissing off anyone.

    I was already an Arch user when that opt-in telemetry was introduced. And only heard about it because I was relatively active in Arch communities back then (relatively young, relatively new to Arch). If pkgstats were introduced two years later, I would have never heard of them. Because believe it or not, Arch is just a reliable OS, where you don't have to interact with anything other than reading the odd announcement every other year. It's not a "community", or a "way of life", or anything in that bracket.

  • The premise of the question is wrong, since it assumes a general preference.

    If you're asking 👉 this 👈 Arch user, the answer is "NONE".

    EDIT: The majority of users, especially experienced ones, don't enable pkgstats. So such stats always end up in some form of self-selection (biased towards users who would use a DE in this case).

  • They know you can just do if ((age < 18)) in bash, right?

    Or rather if ((10#$age < 18)) because age=021 would not be adult 😉 Hopefully, they protect against that at least.

    (I had to double-check this stupid default is still a thing, since I moved to zsh many years ago.)

  • With GPU rendering, you should learn about GPU processing and memory usage too, not that it would matter much for such a use-case.

    nvtop is nice for displaying all that info (it's not nvidia-specific).

    Also % CPU usage is not a good metric, especially when most people forget to set CPU frequencies to fixed values before measuring. And heterogenous architectures (e.g. big.LITTLE) make such numbers meaningless anyway (without additional context). But again, none of this really matters in this use-case.

  • A quick shallow look.

    • Avoid single hard paths. Provide fall-backs. Make them all configurable. Use xdg (properly)...etc.
    • Avoid .unwrap() or any source of panic!() for non-fatal things that can actually fail.
    • Make non strictly necessary fields optional in you model, if that helps.
    • Use .filter_map() and .collect() in your parsing code, instead of all the matches and continues in a for loop. You can use .ok()? to early-return with None on errors.
    • And finally, since you're micro-benchmarking, try speedy or borsh instead of bincode, unless you need the serde compat for some reason.
  • I gave this a quick look at 2X speed with a lot fast seeking, and my brain still hurts.

    First of all, and concerning Rust, please familiarize yourself with the mem module and its functions at least. You didn't even get near a situation where using unsafe{} was actually required.

    Second of all, and concerning the task at hand itself, for someone who knew to make the distinction between bytes and chars, you should have known about grapheme clusters too. There are a lot of multi-char (not just multi-byte) graphemes out there. You can make a "Fun With Flags" 😉 segment to show that off (no attribution required). Just don't do anything silly, and make sure to just utilize the unicode-segmentation crate.

  • UB didn’t matter.

    There is no such a thing.

    If you really must pretend this matters performance wise, look up MaybeUninit. It still requires unsafe{}, but it's a lot less trouble.

  • What made you reach out to a static mut in the first place?

  • sudo is NOT a part of coreutils. Anyone with basic *nix knowledge would have known this.

    sudo-rs, as expected, is also NOT a part of uutils. And the projects happen to be very different in many aspects. uutils started from scratch as a hobby side-project, and it was developed from the start in idiomatic Rust. It can't directly take anything from the GNU implementation anyway, as explained in their README. sudo-rs however is a funded effort to translate some C projects into Rust with as little unsafe{} as possible. Some of the code was directly translated from the original implementation. And if you look at the code in general, you will see that it's rather low-level and looks more like C than Rust in many parts. Some of this is arguably necessary given the nature of sudo functionality, but not all of it.

    Both projects do share the fact that they probably didn't push for distros, Ubuntu or anyone else, to switch to either of them by default already, and both were probably surprised it happened this soon.

    And yes, this exposure, negative as it may seem for now, is an unavoidable "teething" period, and it's going to be of great benefit to both projects on the long run. Hopefully, Ubuntu users living on the edge wouldn't face too much trouble meanwhile.

    (I don't use Ubuntu, but have been using sudo-rs by default for months.)

  • I have been using it by default with cargo since just before 0.4, I think, and had zero problems.

    The situation may have been different If I tried to use it with some non-Rust projects that need special support for some feature(s).

  • Like you, I'm not well versed in the web**** world (self-censored), but from my observations, Leptos appears to be the most popular (community) web rust/wasm framework currently. Why? I wouldn't know.

  • You see, rust platform support can't be bad when even meme platforms can get to tier 1.

  • I get it – abstractions are cool. They’re supposed to hide complexity so we can focus on cooler stuff. And Rust loves that idea. Traits, generics, lifetimes – layer upon layer of "don’t worry about it honey."

    That's such a fundamental misunderstanding of something so basic, that I almost had to stop reading.

  • A word of appreciation.

    Typst developers are among the best Rust citizens around. Not only do they have a cool project, but they also contribute a lot to the Rust ecosystem at large.

  • The push-based ActivityPub (apub) federation itself is bad design anyway. Something pull-based with aggregation and well-defined synchronisation would have been much better.

    There are ideas beyond that. For example, complete separation between content and moderation. But that would diverge from the decentralized family of protocols apub belongs to, and may not attract a lot of users and traffic. And those who care and don't mind smaller networks prefer fully distributed solutions anyway.

  • At least use a SIMD load, and maybe someone would find it cool-adjacent.

  • rationale behind the design principle is the only organizing entity here it seems.

    It is worth pointing out however (for "non-techies") that Rust projects have been written by people who love Rust and use it as their main language, love it but can't use it a lot in their employment, like it or are lukewarm about it and used it once or write in it on occasion, don't like it but wanted to experiment with it, hate it but learned it because it could be beneficial to them in some way, hate it but had to use it (usually as a part of their employment).

    The success of the language means that not everyone who uses it necessarily even likes it. So not even a "belief" in the design principle can be assumed by all involved.

  • Good comment.

  • Programming @programming.dev

    koto v0.16.0 released (koto is a scripting programming language)

    github.com /koto-lang/koto/releases/tag/v0.16.0
  • Programming Circlejerk @programming.dev

    When I found out even Rust needed the clib, it was like seeing an iron-clad fortress only to look closer and see it was being held up by sticks, ducktape, and prayers.

    github.com /rust-lang/rfcs/issues/2610
  • Programming @programming.dev

    Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead!

  • Rust @programming.dev

    Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead!

  • Rust @programming.dev

    Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language

    koto.dev
  • Programming @programming.dev

    Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language

    koto.dev
  • Rust @programming.dev

    kdl 6.0.0-alpha.1 (first version with a KDL v2 implementation)

    github.com /kdl-org/kdl-rs/blob/f67e3d2998dcf0d198b4d03be7b23062cab21723/CHANGELOG.md
  • Rust @programming.dev

    COSMIC ALPHA 1 Released (Desktop Environment Written In Rust From System76)

    system76.com /cosmic
  • Rust @programming.dev

    cushy v0.3.0 Released

    github.com /khonsulabs/cushy/releases/tag/v0.3.0
  • Rust @programming.dev

    slint 1.6.0 Released

    github.com /slint-ui/slint/releases/tag/v1.6.0