Forgejo, a Gitea fork used by Codeberg. I chose it because it’s got the right balance of features to weight for my small use case, it has FOSS spirit, and it’s got a lovely package maintainer for FreeBSD that makes deployment and maintenance easy peasy (thanks Stefan <3).

If you’re trying to have password auth be a second layer on top of key auth (requiring a password after connecting with your ssh key), you can add the following to your server’s sshd_conf:

AuthenticationMethods "publickey,password"

/dev/sda is the whole raw disk - you typically don’t want to directly interact with /dev/sda, unless you are partitioning or overwriting it. There are a few layers between that device and the files:

• raw disk - /dev/sda
• disk partition - /dev/sda1
• luks container - when unlocked, mapped to /dev/mapper/{name}
• ext4 filesystem inside the luks container, mounted somewhere like /mnt, /media, etc

You’ll need to find where that ext4 filesystem is mounted, and run the chown command on that. You can run lsblkand see a tree of the above hierarchy, with the ext4 filesystem’s mountpount shown in the right-hand column.

Ctrl+r was a life-changer when I first learned it.

I’d recommend a full battery calibration before running the command one more time, if you haven’t already (charge the battery fully, leave it on the charger at 100% for a while, then fully discharge until it shuts itself off, leave it for a bit, then fully recharge while off). If the calibrated values line up with a full:design ratio of ~80%, especially with a 10-year-old battery with almost 700 cycles on it, my take is that’s pretty great.

That said, I think the best way to get an accurate feel for the health of an old battery is to put it through one full cycle of normal use and time how long it takes to die.

If you’re genuinely worried about this, you shouldn’t be using untrusted machines for remote access.

Apache Guacamole might be a good option. “Clientless” (browser-based), supports various mfa, uses ssh/vnc/rdp on the backend.

However, if the data on that machine is sensitive, or if that machine has access to other sensitive things on your network, I’d suggest caution in allowing remote access from untrusted machines on the wider internet.

powertop is a cool tool that can analyze your machine and provide a list of suggested power optimizations

DNS is what you’re looking for. To keep it simple and in one place (your adguard instance), you can add local dns entries under Filters > DNS Rewrites in the format below:

192.xxx.x.47 plex.yourdomain.xyz
192.xxx.x.53 snapdrop.yourdomain.xyz

Now that’s a name I’ve not heard in a loooong time.

What is your root filesystem installed on - lvm, zfs, or bare disk partitions? Are you booting with grub (legacy/bios) or systemd-boot (uefi)?

Can’t beat an X230 with an i5 for that use case, and you can still find them for around 100 bucks. Swap in an X220 keyboard, maybe a new battery, coreboot it, and in my opinion you’ve got the perfect laptop. I’ve daily driven that setup for the last 5 years and it’s been great.

This is just an attack that attempts common username/password combinations on ssh, and the article even states that the worm is dime-a-dozen. Unless you have both password auth enabled and an available account with an easily guessable password (and if you have either you should change that), this is nothing to worry about, even with sshd available to the internet.

Sensationalist title.

I’m with you there. It’s all layer upon layer of vulnerability and false security, and then at the bottom of all of it lurks the Ken Thompson hack.

Still bad advice to tell people it’s okay to use an explicitly vulnerable OS, I think.

Would you advise your enterprise clients that running Windows unpatched is ‘not a big deal as long as you have patched web browsers and AV’? Of course not. Because that’s dangerous advice and could even open you up to legal liability.

So why would you advise otherwise to home users, who are often more vulnerable in the first place?

Not having security patches on a system you do things like go to your banking website on is actually a pretty big deal, and I don’t think it should be dismissed lightly. Also AV is mostly snake oil, and is in no way an adequate substitute for a properly patched OS.

Any proclaimed prioritization of privacy or privacy improvements in stock Android serve only to bring your data more directly under the control of Google at the expense of other entities, so that those other entities must pay Google as a middleman to your data. On stock Android, there is no privacy - Google has access to everything, always.

In my opinion, one step that could reasonably be taken to improve the situation is for Google to go fuck itself, lose every anti-trust suit brought against it, and die.

If you aren’t going to fully wipe your drive in horrible events like this, at the very least use shred instead of rm. rm simply removes references to the file in the filesystem, leaving the data behind on the disk until other data happens to be written there.

Do not ever allow data like that to exist on your machines. The law doesn’t care how it got there.

Thank fucking god for the EU, for fighting for global digital rights where nobody else does.