Doesn't fedora use zram by default nowadays?
It could be an old service on that same ip. Zoomeye/shodan don't rescan on the spot, they keep records of old scans.
Yeah, but idk if phones can use joycons in the double joycon mode. My understanding is that it requires either root or a physical adapter of some kind.
I'm using eternity, which hasn't received any updates, on my phone, and the default lemmy web interface on my computer.
Maybe I need to try some other options.
This is just straight wrong. iMessage on android has worked by connecting to a remote Mac, which then connects to imessage. The protocol is locked to their hardware.
And, even if there was a true open source reimplimplementation of iMessage, that would say nothing about the security of Apple's proprietary implementation of the iMessage end to end encryption.
There is a reason for this: https://yast.opensuse.org/
https://en.opensuse.org/Portal:YaST
Yast is opensuse's configuration/setup tool, and it's used in the installer.
You can also use it from the installed distro itself, even configuring things like grub.
Have you tried running a vpn to your phone while tethering?
https://moonpiedumplings.github.io/guides/unrestricted-tethering/
I experimented with it a little bit, but it didn't go anywhere when I discovered my phone already proxies/NATs all my traffic.
No, Android Go still supports ADB.
On an XDA review of an android go phone, they managed to connect to it via ADB
https://github.com/Katana-Official/SPatch-Update
Might not work, but at least it's updated.
You could also look into https://www.luckypatchers.com/. There might be patches for what you want to do.
Sounds like cope to me. You don't get to tell an attacker which component they can attack when you have misconfigured your security guards.
There is only a single thing on my system unencrypted: the grubx64.efi binary. This binary is verified via secure boot. Unless an attacker can break luks2 encryption, they cannot get to anything else.
I keep the LTS kernel around for that
Did you read your own post? The lts kernel was affected too. That's why I used it as an example.
anyway, a simple chroot should allow me to fix any problems.
You could also just nab the older kernel from the archive or something, if your system still boots. But I don't want to have to do that. I have better things to spend my time on then going through the pain of disabling all my security features so I can chroot into an encrypted system.
moonpiedumplings
joined 2 years ago
Give us your fstab and lsblk.
Or, the specific piece of information I want is where the kernels are located. When /boot is part of the root subvolume (not the default setup, sadly), then the kernels will be snapshpotted along with the rest of the filesystem. /boot/efi would be where the efi system partition is, and where the bootloader is installed.
If /boot is instead the efi parition (default setup lmao), then this means that when you restored a snapshot of your root subvolume, your kernels were not downgraded. I suspect that older kernels attempting to read/view newer kernel modules would cause this boot failure.