Makes you wonder who the hell was still running kaspersky in the US…
Makes you wonder who the hell was still running kaspersky in the US…
https://grapheneos.org/faq#device-lifetime
You can buy a used Pixel 8 and it will be supported by Graphene through 2030 at the very earliest, probably the best support lifecycle you can possibly get on a phone.
Ctrl+r was a life-changer when I first learned it.
When it comes to privacy and security, I think you should treat all cloud providers equally. Use a client with client-side encryption so that the only thing that touches the provider is encrypted data.
Rclone is an example of a good client that can do this, and can even mount your cloud storage as a filesystem with its encryption layer in between.
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.
Good luck!
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.
ssh predates the specification, exists somewhat independently of even the idea of a desktop (not common to see xdg env variables like XDG_CONFIG in a headless environment, for example), and uses the homedir/.ssh directory on both the client and server side of a connection. I think it’s less to do with security and more to do with uniformity for something as important as ssh - ssh doesn’t need to change to use the xdg spec, and xdg doesn’t need to allot anything special for ssh when it’s already uniform across the unix spectrum
/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:
You’ll need to find where that ext4 filesystem is mounted, and run the chown command on that. You can run
lsblk
and see a tree of the above hierarchy, with the ext4 filesystem’s mountpount shown in the right-hand column.