Btrfs doesn’t have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.
Why involve mdadm? You can use one btrfs filesystem on a pair of luks volumes with btrfs’s “raid1” (or dup) profile. Both volumes can decrypt with the same key.
A standard called SystemReady exists. For the systems that actually follow its standards, you can have a single ARM OS installation image that you copy to a USB drive and can then boot through UEFI and run with no problems on an Ampere server, an NXP device, an Nvidia Jetson system, and more.
Unfortunately it’s a pretty new standard, only since 2020, and Qualcomm in particular is a major holdout who hasn’t been using it.
Just like x86, you still need the OS to have drivers for the particular device you’re installing on, but this standard at least lets you have a unified image, and many ARM vendors have been getting better about upstreaming open-source drivers in the Linux kernel.
To the contrary, I would expect the sample to skew more towards people who have a heavily customized X session and strong opinions about window managers while drastically underrepresenting average GNOME users who stick with the default Wayland session. Someone who likes their custom setup can still be waiting for a Wayland equivalent while casual Ubuntu users have been defaulted to Wayland on new non-nvidia installs since early 2021.
I tried to do this a while ago with a GNOME system, setting GDM to automatically log me in, but I ended up always getting prompted for my password from gnome-keyring shortly after logging in which seemed to defeat the point. If you use GNOME, you might want to look at ArchWiki’s gnome-keyring page which describes a couple solutions to this problem (under the PAM section) which should be applicable on any systemd distro.
There actually is a silent and very subtle revision they made to the dpad less than a year after Switch launched (iirc around the time of the Xenoblade 2 controller). The protrusion out the middle of the underside was made slightly longer, which makes you less able to push down all four directions at the same time. The chance of undesired diagonals is very high either way but just slightly lower for the newer one.
Even the improved version is one of Nintendo’s worst dpads ever (including handhelds) imo, with only the GameCube’s coming remotely close. A huge step back from Wii U Pro’s dpad.
A ground-up overhaul of the copyright system would make things so much worse, not better, considering the current climate of power. In the US for example, MPA, RIAA, Entertainment Software Association, Association of American Publishers, and others wouldn’t want public libraries or the used market to exist at all; they would push for making every single transfer of “ownership” on any media involve a payment to the rights holder. Lawmakers are far more likely to accommodate those groups’ desires than the public good.
The worst parts of the current copyright system are the most recent. Both the DMCA and the extension of US copyright term to 95 years took effect in 1998, and the early 2000s saw many other countries passing laws to make their copyright system closer to US’s in various ways such as the WIPO Copyright Treaty which took effect in 2002 and EU’s 2006 Copyright Directive. Just about the only positive news we’ve seen in US copyright law since then is in temporary exemptions to DMCA’s anti-circumvention rules (Section 1201) which change every year. Copyright law was far less hostile to consumers and the public before the 90s than it is now, and up until 1976 it used to be expected that most media someone consumes would enter public domain within their lifetime.
The digital era makes market relevance far more ephemeral than ever and yet the laws written for the digital era moved copyright in the opposite direction. Movie studios simultaneously judge whether a film succeeded almost exclusively based on its first week of ticket sales and also claim that depriving public domain for 95 years is necessary. Nothing should be able to justify more than 20 years of copyright. Media formats don’t even last as long as copyright; CDs and DVDs rot, game cartridges die, servers shut down, and even books printed on today’s low-quality paper will fall apart.
Some of it is absurd to me, like the way something can be online but geographically restricted.
This is a consequence of contract terms moreso than copyright. One issue in copyright law that this does connect to, though, is the fact that the question of whether the rightsholder keeps a work reasonably available on the market does not impact whether the work retains copyright protections. If copyright law did hypothetically include that limitation, providers would become far more likely to make sure that all content is available in all countries, but even then things could still vary in terms of which content is on which platform.
For years I’ve been using KeepassXC on desktop and Keepass2Android on mobile. Rather than sync the kdbx file between my devices, I have each device access it through the network. Either via sftp, smb, or nfs, but regardless I need to connect to my home’s VPN to access it when away from home since I don’t directly expose those things to the outside world.
I used to also keep a second copy of the website-tied passwords in Firefox Sync, but recently tried migrating that to Proton Pass because I thought the PIN feature might help, then ultimately decided to move away from that too and start using the KeepassXC-Browser plugin instead. I considered Bitwarden too but haven’t tried it out yet, was somewhat deterred by seeing people say its UI seems very outdated.
There’s only one case I’ve found where Wi-Fi use seems acceptable in IoT: ESPHome. It’s open-source firmware for microcontrollers that makes DIY IoT sensors and controls accessible over LAN without phoning home to whatever remote server, without trying to make anything accessible over the Internet, and without breaking in any way if the device has no route to the Internet.
I still wouldn’t call Wi-Fi use ideal even there; mesh can help in larger homes and Z-Wave/Zigbee radios tend to be more power efficient, though ESP32 isn’t exactly suited for a battery-powered device that’s expected to run 24/7 regardless.
That’s strange. As far as I can tell from any web searches, every version Windows still defaults to storing local time to the hardware clock and there are no reports of that changing with an update, nor is there any exposed setting control to configure this behavior outside of regedit. If you’re curious enough, you can check the current setting in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. Windows maintains the current time as UTC if and only if the RealTimeIsUniversal key is present and nonzero.
I expect it’s more likely some other issue would make the BIOS display an hour that’s inconsistent with your local timezone. For example, maybe a bug in the BIOS, maybe a timezone offset setting within the BIOS, or maybe a dead clock battery.
Unix time is far less universal in computing than you might hope. A few exceptions I’m aware of:
Converting between time formats is a common source of bugs and each one will overflow in different ways. A time value might overflow in the year 2036, 2038, 2070, 2100, 2156, or 9999.
Also, Unix time is often managed with a separate nanoseconds component for increased resolution. Like in C struct timespec, modern *nix filesystems like ext4/xfs/btrfs/zfs, etc.
as soon as the BIOS loaded and showed the time, it was “wrong” because it was in UTC
Because you don’t use Windows. Windows by default stores local time, not UTC, to the RTC. This behavior can be overriden with a registry tweak. Some Linux distro installer disks (at least Ubuntu and Fedora, maybe others) will try to detect if your system has an existing Windows install and mimicks this behavior if one exists (equivalent to timedatectl set-local-rtc 1) and otherwise defaults to storing UTC, which is the more sane choice.
Storing localtime on a computer that has more than one bootable OS becomes a particularly noticable problem in regions that observe DST, because each OS will try to change the RTC by one hour on its first boot after the time change.
Yes.
My home server has dropbear-initramfs installed so that after reboot I can access the LUKS decryption prompt over SSH. The one LUKS partition contains a btrfs filesystem with both rootfs and home as subvolumes. For all the other drives attached to that system, I use ZFS native encryption with a dataset that decrypts with a keyfile from that rootfs and I have backups of an encrypted copy of that keyfile.
I don’t think there’s a substantial performance impact but I’ve never bothered benchmarking.
Thanks for the recommendation. I’ll give it a try sometime.
Stylus/handwriting oriented note taking. Stuff like Samsung Notes or Goodnotes (or OneNote, though it does a lot more) in the Android space, or e-ink options like Remarkable’s stock software.
If I just want to use a keyboard for everything I have great FOSS options like Joplin and Standard Notes, but when I want to use a pen instead it feels like no other freedom-respecting option seem to even remotely approach the usability of just sticking with real ink and moleskine-like paper notebooks.
Even someone willing to pay an upfront fee for proprietary apps will struggle to find good options that allow syncing and reading (let alone editing) your notes on other devices/platforms without resorting to a monthly subscription.
Something I’ve noticed that is somewhat related but tangential to your problem: The result I’ve always gotten from using compose files is that container names and volume names get assigned names that contain a shared prefix by default. I don’t use docker and instead prefer podman but I would expect both to behave the same on this front. For example, when I have a file at nextcloud/compose.yml that looks like this:
volumes:
nextcloud:
db:
services:
db:
image: docker.io/mariadb:10.6
...
app:
image: docker.io/nextcloud
...
I end up with volumes named nextcloud_nextcloud and nextcloud_db, with containers named nextcloud_db and nextcloud_app, as long as neither of those services overrides this behavior by specifying a container_name. I believe this prefix probably comes from the file-level name: if there is one and the parent directory’s name otherwise.
The reasons I adjust my own compose files to be different from the image maintainer’s recommendation include: to accommodate the differences between podman and docker, avoiding conflicts between the exported listen ports, any host filesystem paths I want to mount in the container, and my own preferences. The only conflict I’ve had with other containers there is the exported port. zigbee2mqtt, nextcloud, and freshrss all suggest using port 8080 so I had to change at least two of them in order to run all three.
I have configured custom Android kernel builds to enable more USB drivers, enable module support, and tweak various other things. For one tangible example of the result: I could plug in a USB Wi-Fi adapter and use it to simultaneously connect to another Wi-Fi network with the internal NIC while also sharing my own AP over USB. On an Android device of all things. I have also adjusted kernel builds for SBCs (like Pi clones) to get things working at all.
I have never seen any reason to configure a custom kernel for my own desktop/laptop systems. Default builds for the distros I’ve used have been fine for me; if I’m ever dissatisfied with anything it’s the version number rather than the defconfig. The RHEL/Rocky kernel omits a few features I want (like btrfs) but I’d rather stick to other distros on personal systems than tweak a distro that isn’t even meant for tweaking.
I recommend giving dnf the -C flag to most operations, particularly those that don’t involve downloading packages. The default behavior is often similar to pacman’s -y flag and so the metadata sync ends up slowing everything down by orders of magnitude.
I’ve long known about it. I don’t seriously use it, but I would if only my Wi-Fi router was fully supported. It’s an Asus one (that I got for free from T-Mobile a decade ago) so I installed Asuswrt-Merlin on it instead.
Following the recommendation of homelab communities, I got into OpnSense (a BSD-based firewall system for x86 hardware only) last year, still keeping my Wi-Fi router as a dedicated AP. In hindsight I somewhat regret that choice and probably would’ve been better off buying a new OpenWRT-compatible router and using it to handle firewall/routing/AP all in one device instead of wasting the power draw of another separate N100 system. I like having wireguard and vnstat in my router now, which Merlin didn’t offer, but I know OpenWRT has those too and I don’t have any other needs that warrant a higher-power router.
On Switch, no game cards support writing of save data or anything else. It’s a departure from 3DS and all previous Nintendo cart formats for as long as games have supported saving at all.
That change is probably done to help tie saves to user accounts, enable cloud saves even when the card is not inserted, accommodate variable-size user data features like level creation, and mitigate the risk of game save based exploits like Twilight Hack spreading from user to user.
Unfortunately that (plus inability to put saves on SD card) means that backing up your own save data requires either being able to run homebrew on the system that has the save or having another Switch that can and relying on Nintendo servers to perform the transfer. Either way, having a Switch that runs homebrew means you don’t need this dumper.
My best guess: whatever they’re filing now was so exhaustively researched that it took months to prepare the strongest case they’re able to make, possibly delayed by the lawyers working on several other cases. Plus waiting until sales have dried up can maximize damages.
Another possibility is that Nintendo/TPC is planning to make some big Pokémon announcements soon and wants to target this shortly before their own new games to reduce competition. Palworld might seem like more of a threat to the execs now that Pokémon is nearing a major release than it was in the middle of a long drought for the series.