This workflow is tied to KDE Plasma's tagging feature. Moving away from KDE Plasma would likely mean abandoning parts of this workflow altogether.

~~It looks like these tags are stored in filesystem xattrs themself, not in dolphin or kde metadata. That is, even if you load up gnome's file browser, or another file browser, it should still be able to read them.~~

Nope, it looks like the tags used are KDE specific, even though any software could theoretically implement support for reading and writing them.

https://wiki.archlinux.org/title/Extended_attributes

https://www.freedesktop.org/wiki/CommonExtendedAttributes/

I don't like the less serious licenses because they often don't explicitly declare that your software is distributed with no warranty.

This makes you liable to be sued in certain jurisdictions, where simply distributing software is assumed to also provide support, or you could be held responsible for damage it causes or misuse.

Of course, the chance of someone suing you is extremely slim. And courts are ran by humans, who can interpret the spirit of the law, rather than the letter, so I would hope they would be gracious and understanding of the open source model. But it's better to just not take chances.

No, it would actually be quite easy to spot.

Nixpkgs templates the source code url fro the url, and then it injects a variable

Here is an example from bash:

pname = "bash${lib.optionalString interactive "-interactive"}";
    version = "5.3${fa.patch_suffix}";
    patch_suffix = "p${toString (builtins.length upstreamPatches)}";

    src = fetchurl {
      url = "mirror://gnu/bash/bash-$%7Blib.removeSuffix fa.patch_suffix fa.version}.tar.gz";
      hash = "sha256-DVzYaWX4aaJs9k9Lcb57lvkKO6iz104n6OnZ1VUPMbo=";
    };

If the url were to be changed, it would show up as a change in git when someone is reviewing before merging.

Rust

Rust is doing pretty poorly right now.

among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

https://kerkour.com/rust-supply-chain-nightmare

Rust programs that are compiled with cargo, when compiled as dependencies of another program or when compiling a binary itself, can execute arbitrary code via build time scripts, and they are executed unsandboxed. This is a security nightmare.

push whatever you want to an NPM package if you have the author’s login

This is how all language package managers work, unfortunately. The login's security can be improved, via things like 2fa, but it's currently very bad. Having multiple parties use keys to sign packages after reviewing all changes, is a thing unique to distro package managers, and it is why Linux distros are extremely resilient against supply chain attacks.

For maintenance I would recommend a ticketing system instead of forgejo:

https://selfh.st/apps/?search=ticket

There are a few options and they probably all work better than a git issue tracker.

Another thing I would recommend is to have centralized accounts via an identity provider. People have one username and password they can use to log into all the services, and you can reset/signup them to all connected services by managing the identity provider app.

There are a few options for this as well but I'm on my phone some imma just list the three that I find most promising for your usecase: kanidm, voidauth, authentik.

Depends on the program and the professors. I'm doing computer scuence at CSUN, and I've gotten lucky, none of the online exams have required any proctoring software (rootkit monitoring software). They just do them in the browser.

Because you can run a "rootfull xwayland" session which is essentially an X11 session but rewritten to be more maintanable.

After this, it's a lot harder to be opposed to the loss of X11, because you don't really lose it.

Because one of the features of Linux that Microsoft is most interested in is docker/oci containers, but that is a feature specific to the Linux kernel (and thus requires a virtual machine).

This feature used to be in KDE 5 as well though, but with a size cap. I suspect the removal of the size cap is intentional rather than a bug.

How to improve Python packaging, or why fourteen tools are at least twelve too many

Still relevant.

As a someone who has used both Arch, and Debian, neither has less or more bugs.

Debian has the same bugs, over the period of their stable release, and Arch has changing bugs (like a new set every update lol).

Yes, Arch is going to get a lot more features. But it comes at the cost of "instability". Which is not so much a lack of reliability but instead, how much the software changes. I remember a firefox bug that caused a crash when I attempt to drag bookmarks in my bookmarks bar around, which lasted for like a week — then it went away.

The idea behind projects like Debian, is that for an entity that needs stability, you can simply work around the bugs, since you always know what and where they are. (Well, the actual intent is that entities write patches and submit them to Debian to fix the bugs but no one does that).

Another thing: Debian Stable has more up to date packages than Ubuntu 20.04, and Ubuntu 22.04. This happens because Ubuntu "freezes" a Sid version, and those packages don't get major updates for a while. So often, the latest Debian stable has newer packages than the older Ubuntu releases.

No one complained when s6, another init system, also offered a sudo alternative (before systemd did, too). But when Poettering does it, it's bad and wrong and ununixlike!

Maybe setuid has been extremely problematic, and more than one entity has sought alternatives?