Skip Navigation

Posts
16
Comments
396
Joined
3 yr. ago

  • I don't know what exactly you want to know actually. It's a generic wording / term. I'm not talking about a specific user group or something like that. I'm just saying, "people" do not HAVE to use a commandline package manager, if the system is configured to use a GUI manager for the packages.

    In example SteamOS on the Steam Deck is configured in a way the user never need to use the terminal. There is the gaming mode, without a desktop and a click updates the system. And in desktop mode there is Discover pre-configured with Flathub for Flatpaks. Users don't have to use the terminal to install new applications or update them. Just as an example. I think openSUSE also has some GUI for that and doesn't Linux Mint have such a GUI too? Manjaro comes with their Pamac graphical tool.

  • I don't understand what you mean. What's not understandable about "most users"?

  • But Discover on an Arch based system (EndeavourOS) isn't that great. It only supports Flatpak, not the system packages.

  • Deleted

    Permanently Deleted

    Jump
  • No offense, but the name Mobian sounds like when you make a casual joke about Debian + Mobile = Mobian. No judging about the actual project, just found the name amusing.

  • Deleted

    Permanently Deleted

    Jump
  • Any idea on what caused the spike?

    End of Windows and lot of YouTubers recommend it as something that looks a bit like Windows (on the surface). Maybe?

  • Also most users don't even have to use a package manager directly, as there are GUI frontends that manages all of this with mouse clicks. In that case, the underlying package manager doesn't even matter, only the repositories you access to, do. I use easy to remember aliases and when I need some more features, i just look them up quickly. That does all the job I need for the most part.

  • I’ve been trying to understand one of the latest AI coding buzzword: Spec-driven development (SDD).

    writing a “spec” before writing code with AI

    The spec becomes the source of truth for the human and the AI.

    In other words, the specs are vibe coded and then this vibe coded spec is used to vibe code a program. How exciting.

  • Rust, is that you?

  • Thank you for checking! As for the private thing, they have the source code provided on a different place: https://docs.rs/crate/fnmatch-regex2/0.4.0/source/ Maybe it makes sense now, because they want people to focus on the other source, and do not want to work on Gitlab itself.

  • Because I never encountered signing into Gitlab before. And the repository of fnmatch-regex itself does not require me to sign in. So i was a bit suspicious. I mean who knows if it would be possible to provide fake sign in. Guess I'm just paranoid.

  • You can even talk about Gaming community, even if its a much wider audience and diverse than everything about Rust. What a "community" is, is defined at the moment of "talking about it", and depends on the context. If the person thanks to the Rust community in a "random community", then it does not automatically mean thanking to this sub community only. What I mean is, I think, the person here thanks to everyone involved by Rust.

  • The intent was on better TPM security after a prior security demonstration showed TPM key recovery from Microsoft Windows BitLocker as well as TPM sniffing attacks.

    I am not sure if this is a good change. Isn't this "dangerous"?

    The hope is that now it's disabled by default, the Linux kernel developers can spend more time evaluating the security benefits and performance optimizations to make it worthwhile to re-enabled by default in a future Linux kernel version.

    I'm confused. They disable security feature and then want spend time on the benefits and performance optimizations, to possible enable it again?

  • I explicitly only use it with features --derive. It let's you write the cli option setup as a struct, which feels super natural to me. That's why I know for a fact it works well. Look in your Cargo.toml under the section [dependencies] there should be an entry for clap: clap = { version = "4.5.41", features = ["derive"] } is mine. Right now version 4.5.48 is the newest I think.

    Also from your previous reply, what do you mean "unless i do the implied version, but then it can’t derive features"? I don't know why you shouldn't be able to use derive. I'm no expert either BTW, just wondering what went wrong.

    Edit: typo

  • Right now I am working on a Rust cli tool with clap and have no issues with the LSP in Neovim. It might be a configuration error. Clap is used by many and is the defacto standard cli parser in Rust. As a fan of argparse in Python, I think clap is even better. argparse being implemented as standard library is the biggest pro over clap. I wouldn't even use getops anymore, unless it is a Bash script. And even so, Bash has its own builtin argument parser that I use for scripts.

    If you really wanted to try Rust, you should sort of that issue. Clap works great and lot of users use it. Who knows, you may even end up liking it and Rust.

    Edit: BTW which example do you refer to exactly? I looked at the official ones and couldn't find: https://doc.rust-lang.org/stable/rust-by-example/

  • I think these incidents like a calculator leaking 32GB are not the problem in the industry. These are isolated issues, and fixable as you say. The bigger problem are many "smol" programs are written without performance in mind at all, with crazy languages like JavaScript, its bloated environment and runtimes and frameworks like React and a huge browser to run it. While they do not leak memory like crazy, they hog a lot and people accept it. If all programs are like this, then you end up doing 16GB for simple tasks (random number chosen for likes), while the 32 GB leaked app is corrected and now just uses 200 MB at max (just random number again, to illustrate my point).

  • It's written in Objective-C. Rewrite it in Rust.

    Modern problems require modern solution.

  • About Immutable Data:

    The most obvious benefit of this is that it is easier to reason about code when you don't have to worry about the "current" state of any internal data.

    My own phrasing about this subject: With mutable data, the state is no longer encoded in programming code itself, rather a temporary state you have to calculate in your head. That's why people need debuggers, to help pausing at a time and see the current state and analyze each step in between all immutable states; which can be endless, depending on the input.

  • The drop of third party hdds nothing to do with the new LED driver written in Rust. Do you suggest that Rust is enshitificating too??

  • Ahh, I see. Well okay, you don't have to like it. But that is not the problem of the default configuration, but the problem of those who accept it as the formatting in the project. You don't like what the KDE code formatting project does, and that's the issue. Working in teams it will obviously happen at some point that you don't like what the team accepted as formatting. This is not a specific issue with KDE or rustfmt.

    BTW, wouldn't it work to have your personal rustfmt configuration that you like and work with and when you are done and want to git push, it would automatically reformat with rustfmt using the teams formatting? I personally don't work in teams, so no idea if this is a viable option to do if you really dislike what they use.

  • Is this a typo? What do you mean by KDE formatting?