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

help-circle


  • Man, it really is like an extremely dense but dedicated intern. Does not question for a moment why it’s supposed to make fun of an interval, but delivers a complete essay.

    Just make sure to never say “let’s eat Grandpa” around an AI or it’ll have half the leg chomped down before you can clarify that a comma is missing.



  • 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…


    1. Cargo is truly great, but it’s a mystery to me right now how I’m going to get it to work with certain packaging systems.

    Yeah, Cargo itself doesn’t deal with any of the bundling after the executable is built.

    For that stuff, the efforts are certainly still ongoing. There’s no grand unified tool yet.

    If you just want e.g. a DEB file, then you probably want this: https://crates.io/crates/cargo-deb

    But if you want to do more in CI, then there’s kind of three popular options that I’m aware of.

    • just: More or less a shell script runner, and kind of like make.
    • cargo-make: A lot of effort has been put into this, it’s certainly got a good amount of features, but personally not a fan, since it makes you write a custom TOML format and then ideally you should be writing a custom script language, DuckScript. You can also use Rust scripts with it, which we tried, but there was just no way of passing parameters between tasks.
    • cargo-xtask: This is not a tool, it’s a pattern, basically just build your own build tool. It does have its downfalls, you’re not going to build good caching into your own build tool, for example. But in principle I find this quite workable, as you get to write your CI code in Rust. There’s also more and more community-made libraries to aid with that.

  • 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.





  • Ah yeah, I guess, my interpretation of that quote wasn’t quite right.

    You can build a shared library in Rust, but it will need to be called via the C ABI or the WebAssembly ABI.
    It is also possible to call a C ABI library in Rust (and virtually any other language), as well as a WebAssembly ABI library.
    So, technically you can do shared libraries that way, but because the C ABI and WebAssembly ABI are significantly more limited compared to what you want to be passing around internally in Rust, you’ll only really want to use these in special cases.

    Rust doesn’t particularly like dynamic libs. It compiles libraries you use on your dev machine, so it knows how you’ll use the libraries, which allows it to make various assumptions and optimizations.
    For example, Rust can do generics via monomorphization (as opposed to vtables), which means it will generate the generic library code for each type that’s passed into the generic type argument. This is useful, because it can fully optimize that code, but also because it retains type information, despite the use of generics.


  • To my knowledge, they generally don’t. Shared libraries are a massive pain from a programming perspective, so it’s largely been avoided (even though there are some advantages for Linux distro maintainers and sysadmins).

    Modern languages usually bring along their own package manager, which downloads the libraries you want to use from a central repository and then bundles them into your build artifact that you hand to users.
    In ‘semi-modern’ languages, like the JVM languages and I think also Python, you get the dependencies in a folder as part of a larger archive.
    With Go and Rust, they decided to include those libraries directly into the executable, so that many programs can just ship a single executable.




  • As others have already said, Kate should work as text editor. I think, the only thing that’s not built-in is base64 en-/decoding, but you can set that up like this:

    That’s for decoding. For encoding, just change the name to “base64 encode” (exact name doesn’t matter) and remove the “–decode” from the Arguments-field.
    This relies on a CLI utility called base64, which is going to be pre-installed on most distros.
    It’s not entirely perfect, because it’ll always insert a newline, as that’s part of the base64 output. If you do want to get rid of that, you could write a tiny script and then call that script instead, but obviously, you don’t have to.

    You can also install Kate on Windows, if you want to give it a test-ride: https://kate-editor.org/
    (The base64 CLI won’t be available on Windows, though.)



  • My workplace preinstalls Ubuntu, personally I’m using openSUSE. I don’t even think that Ubuntu is particularly bad, I’m mainly frustrated with it, because it’s just slightly worse than openSUSE (and other distros) in pretty much every way.
    It’s less stable, less up-to-date, less resilient to breakages. And it’s got more quirky behaviour and more things that are broken out-of-the-box. And it doesn’t even have a unique selling point. It’s just extremely mid, and bad at it.


  • Oh, I don’t think, it really needs the plug. It’s been around since forever, a proper GNU project and all that.
    Sure enough, it’s kind of niche, but there’s even music archival projects that have been typesetting all the works of Mozart et al in Lilypond, so there’s enough of a community to keep this ball rolling for the foreseeable future.

    And well, that’s also kind of where it’s strongest: Transcribing existing music.
    It’s actually less well suited for composing, because you basically can only listen to things by generating a MIDI, and also you can’t move measures around as easily.
    But yeah, I still like it for composing, because I can use a text editor and Git and such, and personally, I also find it helpful to refer to notes with their names for figuring out intervals, rather than them just being random dots between lines…