I really don’t care what you use but I highly recommend picking something extensible or fully featured. No need to cut yourself off of valuable tools.

(Also I use Neovim BTW)

In theory it is safe. When a Nix package is built it isn’t “installed”. Unless root is running/installing random packages out of the Nix store there is no problem. As long as the user’s aren’t added to the trusted-users option they shouldn’t be able to cause any problems for other users.

However like any multi-user system you are sharing a Linux kernel. A kernel is a very complex piece of software with a huge attack surface. Privileged escalation vulnerabilities are commonly found. (This also applies to the nix-daemon, but it is a bit smaller attack surface but vulnerabilities are still occasionally found.) So you shouldn’t assume strong security isolation. I would say that a setup like this is acceptable for mostly-trusted people like coworkers or friends that are not expected to actively exploit vulnerabilities but definitely wouldn’t let random unknown users use the system.

So if you want strong isolation use a VM or separate hardware, but then you won’t be able to share the builds and packages defeating the point in this case.

Every team has a QA environment. The fancy ones have a separate production environment.

In most distros shutdown is a symlink to systemctl.

Apple is a lot better than Windows but slowly getting worse. They keep pushing their own services more and more aggressively while the quality of their software drops over time. Not to mention that iOS is so locked down that they don’t have to worry about things like pushing Edge because they just don’t allow any other browsers.

I’ve definitely ran into the situation where I fucked something up half-way though installing a new distro, then had to wipe it to go back to an old distro so that I could access the internet and find out what I did wrong so that I could start from scratch.

I hate doing debugging on my phone, but man sometimes is it better than the alternative.

Generally speaking it will be fine. SSH will also refuse keys with open permissions so you would notice if it was wide-open to other users of the device.

But you know if you are running random code or AI harnesses as that user it can be at risk. Or if you copy around the key all over the place it is more likely to leak. But generally speaking you are secure by default, just don’t do something dumb with the key and you’ll have no problems.

It sounds pretty reasonable. As long as you keep SSH patched and keep the key safe it should be quite locked down. Do double-check that password login isn’t allowed (or that all users have a very strong password).

One non-security note is be careful with rsync backup. Generally rsync isn’t considered a backup as any mistakes made in the source will be propagated to the “backup” on next sync. Although there are ways to use rsync to take good backups (like copying to a new directory for each backup).

I built Chibichange to have a way to conveniently deliver changelogs to Dawarich users

Have you considered just posting a changelog to your blog? That would be much more convenient than every app I run pinging me in its own way by phoning home to its server.

Yes, on one hand every commit to nixpkgs needs review (to some degree) on the other hand there are far too many committers to nixpkgs.

There are also gaps such as the bots to auto-merge packages with maintainer approval, so a simple attack looks like this:

1. Submit a package with you as a maintainer.
2. Create a new GitHub account and send a malicious update to that package.
3. Use a bot to merge with maintainer approval.

So nixpkgs is better than the AUR, but it isn’t great and unlike Arch has no separate official repos.

Because every three letter acronym means more than one thing. There are only 17 576 TLA so they are going to be heavily duplicated.

You should almost always spell out acronyms on the first use.

Oof, that is really not a good look. This should have been clearly disclosed and probably with a per-notification for the patch release.

No, the DRM wouldn’t work at higher levels so you would have the same requirements with regard to 4k.

You seem to be making this very complex. But it really isn’t. Yes, git doesn’t track renames. So you are working around it by splitting your operation into 2 commits.

1. A pure rename.
2. A file change.

This way 1 is always considered a rename and 2 is just a regular file change with the same path. You may also consider tweaking the default rename detection threshold with flags like --find-renames or options like diff.renameLimit.

Would it be nice if Git tracked renames? Probably. But that isn’t how the data model works so it is unlikely to happen soon. But maybe they could add some metadata.

I think it doesn’t really make sense. Because you can’t “squash” one commit. squash is taking multiple commits and making them one.

When you do a “squash merge” you are really saying “squash all the commits that are on this branch and not the target” then merge.

So you can’t “squash a merge commit” you need at least one additional commit to squash in.

You have obviously never tried dereferencing a null pointer.

They are legal if you follow the regulations. The problem with the “rideshare” companies is that they don’t. We should just call them “unregulated taxis” rather than pretending that they are a different service. I think just about every taxi company these days is on some app or another (often the same that call unregulated cabs in countries that actually got their shit together and banned the unregulated ones).

Nah it’s worse. Bitcoin actually has legitimate uses. (Yes, they are a minority of actual usage, but they exist.) NFTs are only useful for speculation, gambling and money laundering.

“Rideshare” is also the least accurate term used to dodge regulations. It is just a taxi/cab. You are paying someone to get you from one place to another. They aren’t sharing their ride, they were never going where you are going before you told them to.

You forgot step 2. Throw sacrificial drive into trash.