• 0 Posts
  • 156 Comments
Joined 4 years ago
cake
Cake day: May 31st, 2020

help-circle



  • I’m guessing, they did it this way, because there’s no persistent process to keep the decrypted files open. You’d need to ask the user for the password for every single command they run. With GPG, that persistent process is gpg-agent.

    Of course, encryption with a GPG key is also going to be more secure than the longest password you can come up with.

    I guess, many people will want access to GPG, too, if they want access to their passwords, so they’re not bothered by it.
    But yeah, I do also remember setting that up on Android, where you need a separate app to do the GPG, and it really stops feeling simple pretty quickly…









  • Normally, the process is:

    • install the packages for the desktop environment
    • log out (not just locking the screen)
    • find a dropdown or cogwheel where you can select the other desktop environment
    • log in

    Having said that, I don’t know what you mean with “graceful”. Desktop environments may involve lots of packages, which may create configuration files in your home directory or get auto-started in your other DEs, so it can be messy.
    Something minimal, like LXQt or the various window managers, isn’t going to cause much of a mess, though.

    I guess, creating a second user with a separate home-directory, like the other person suggested, would isolate that potential mess…


  • Presumably you’re using an IDE or smart text editor to run your code. Otherwise you’d be running e.g. cargo build and cargo test from the command-line quite often.

    The difference to Pip is that Cargo detects changes in the Cargo.toml and will automatically install all the necessary dependencies, when you run cargo build or cargo test (or other similar commands). And since your IDE / editor runs these for you, it looks to you like you’re just editing a text file.

    It should also be said that Pip has a somewhat unusual workflow in that you pip install everything, which would normally install it globally into your operating system. And then with venv, you kind intercept that to install it into the .venv/ folder in your repo instead.
    This workflow doesn’t make a ton of sense, if you always have a repo folder where the dependencies can be installed into, so Rust just doesn’t do it that way.
    (In particular, installing dependencies globally quickly causes issues when different projects have different version requirements for the same library.)

    There is a cargo install command, but it’s only for installing applications, not libraries.


  • You might generally prefer not setting zsh as the system-wide default shell, but rather just to be launched by default in Konsole or whatever terminal emulator you’re using.
    The actual default shell will still show up in TTYs, or when you use the newgrp command, or I believe when you ssh into the machine, and probably other such edge cases, but usually, you can then just run zsh to get into zsh.
    Not setting it as the system-wide default shell just avoids any potential for problems, particularly also if some script doesn’t have a proper shebang.

    Having said that, on Debian-based distros, I usually still set the system-wide default shell to Bash (even though I use Fish), because the default dash shell is pretty much unusable.
    Not unusable enough to prevent typing “zsh”+Enter (if you don’t typo), so this is definitely optional, but yeah, it comes up often enough that dash annoys me, and I haven’t yet had compatibility problems from setting it to Bash instead.


  • I feel like there’s just too many different programming workflows, to try to pre-install them.

    Here on openSUSE, there’s ‘patterns’ you can install, which are basically just groups of packages, and they’ve got some pre-defined patterns for programming:

    I feel like that kind of goes in a more useful direction, although it’s still partially questionable what those contain. For example, the Java development pattern comes with Ant as the build system, when Maven and Gradle are more popular, I believe.

    I also have to say that I often prefer installing programming tooling in distro-independent ways, and ideally automated in the project repo, to avoid works-on-my-machine situations.
    Of course, something like Git, Docker, VMs etc. tend to be stable across versions, and I might not care for having the newest versions, but even with those, I think it’s good to install them on demand, rather than having them pre-installed. If the distro simply makes it a breeze to install them, that’s ideal IMHO.