Legitimately playing 4K blu-ray video on a PC without cracking the DRM requires an insane combination of requirements:

• Windows 10 (not 11)
• An Intel processor between gen 7-10 (nothing newer because Intel ditched SGX in 2021)
• Intel integrated graphics (no nvidia/amd)
• Monitor that supports HDCP 2.2 for DRM (some 4k ones don’t)
• An approved optical drive
• Proprietary playback software which costs about $100 USD, separate from the cost of hardware and Windows
• Miscellaneous other requirements for the motherboard features, bios settings, etc.

Meanwhile MakeMKV can rip them on basically any Windows/Linux/Mac system with a compatible BDXL drive.

Likewise, I’m far less hesitant to accept buying digital console games than video because I generally can expect that once I download a game on my one device that I’ll pull out the same device whenever I want to play it and it’ll keep working when offline and even after the servers are gone, until the hardware fails. Modern games’ physical releases rely so heavily on updates and DLC that the cart/disc you get isn’t complete anyway; buying physical effectively becomes a digital game with an extra point of failure (and partial resellability). PC gaming complicates things but at least some games are available completely DRM-free there.

With video content sold online, streaming directly from some server is always the focus. As soon as the server disconnects you become unable to watch by default. Even if some service lets you pre-download within its app and watch offline (which probably won’t work indefinitely without checkins anyway), that’ll defeat the portability expectations for watching your videos on any device interchangeably.

Blu-ray video isn’t ideal considering you cannot watch it on a phone, tablet, or linux system without cracking its DRM, but that’s still way better for lasting access than anything else major movie/TV studios are willing to let consumers access without piracy.

I bought a Milk-V Mars (4GB version) last year. Pi-like form factor and price seemed like an easy pick for dipping my toes into RISC-V development, and I paid US$49 plus shipping at the time. There’s an 8GB version too but that was out of stock when I ordered.

If I wanted to spend more I’d personally prefer to put that budget toward a higher core system (for faster compile times) before any laptop parts, as either HDMI+USB or VNC would be plenty sufficient even if I did need to work on GUI things.

Other RISC-V laptops already are cheaper and with higher performance than this would be with Framework’s shell+screen+battery, so I’m not sure what need this fills. If you intend to use the board in an alternate case without laptop parts you might as well buy an SBC instead.

This board has the StarFive JH7110 SoC. That processor has previously been in very low power single board computers like StarFive VisionFive 2 (2022) and Milk-V Mars (2023), a Raspberry Pi clone that can be bought for as low as $40. Its storage limitations (SD/eMMC rather than NVMe) show how much this isn’t meant for laptop use.

Very underpowered for a laptop too, even when considering this is intended for developers and doesn’t need to be remotely performance competitive. Consider that this has just 4 RV64GC cores, the cheapest Intel board options Framework offers are 12 cores (4P+8E), and any modern RISC-V core is far simpler with less area than even an Intel E core. These cores also lack the RISC-V vector instructions extension.

I’m not completely sure but I think they removed it at some point after the public backlash (which was 3 years ago now). For the Windows version at least, there apparently used to be an option during the installation wizard for setting whether telemetry is enabled or not. Most Linux distros never had the telemetry at all. I don’t know about Mac.

It is open source, but had some controversy. Most prominently the addition of telemetry a few years ago, which was never included in the builds managed by Debian or most other distro maintainers. They also added a Contributor License Agreement which lets the Audacity project change its own license (even to a non-foss one, though they promise they won’t) without needing to have the change approved by any individual developers.

Even their earliest “uncarrier” features weren’t without issue. Making certain services (spotify, apple music, youtube, netflix, etc.) not count against subscribers’ data caps, while continuing to enforce data caps for other uses, goes against the spirit of net neutrality. This also includes throttling video streams by default to force lower quality (with opt-out on their site).

Promos like a free pizza on Tuesdays seems like a neat optional perk on the surface but their existence fundamentally mean subscription expenses on cellular network service are partially going towards things that have not even the slightest tangential connection to the service.

It is a Linux machine. Runs a Debian derivative, and it’s not like Windows or anything else that isn’t Linux/BSD can run on a RISC-V laptop.

This isn’t the first RISC-V laptop, but the significance of a RISC-V laptop existing is primarily for developers who work on software targeting RISC-V systems. The ability to run RV64 programs without emulation and to natively compile RV64 software without cross-compilers is valuable to some people. Also, China in particular sees value in having computing products that aren’t affected by sanctions; the processor in this is designed and manufactured by a Chinese company without licensing any intellectual property from US or UK.

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.

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:

• Most real-time clock hardware stores datetime as separate binary-coded decimal fields representing months, days, hours, minutes, and seconds as one byte each, and often the year too (resulting in a year 2100 limit).
• Python’s datetime, WIN32’s SYSTEMTIME, Java’s LocalDateTime, and MySQL’s DATETIME similarly have separate attributes for year, month, day, etc.
• NTFS stores a 64-bit number representing time elapsed since the year 1601 in 100-nanosecond resolution for things like file creation time.
• NTP uses an epoch of midnight 1900-01-01 with unsigned seconds elapsed and an unusual base-2 fractional part
• GPS uses an epoch of midnight 1980-01-06 with a week number and time within the week as separate values.

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.

The problem with those TV apps is DRM. All the major streaming services require that you either use a locked down platform (probably checking SafetyNet and more on Android TV) or settle for their browser UI which lacks dpad support and gets quality throttled to 1080p or lower.

Circumventing that DRM is possible, but no project at the scale of a platform like those would dare the both legal risk and support headache of making those circumventions (which are very liable to break) a core part of the OS.

Kodi (and distros using it like LibreELEC) exist for people who want a FOSS platform for using non DRM encumbered media with a TV remote interface.

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.

Likely reversing a major anti-consumer decision is nice, even if it took seven years.

Knowing that consumer protections repeatedly flip back and forth every time the executive branch switches political party, and even then only if we’re lucky, is not so reassuring. What’s stopping it from being repealed again in a few years?

I’ve avoided RGB-lit stuff for everything else, except for my wireless headset. A Logitech G733. In every other respect I love it, but it has bright lights on the front that drain the battery and reflect in my glasses. They default to constantly changing random colors until host software sends a command to control the light. Thankfully there exist tools to control it on Linux (HeadsetControl) but adjustments reset on every power cycle.

The mouse in OP (M510, I’ve had a few of them myself) doesn’t have those problems. There does exist specialized software to manage device pairing for the included “unifying receiver” but it comes by default pre-paired so the software is only particularly helpful for the niche use case of having other wireless logitech devices and wanting to save USB ports by making them all share one receiver.

The readme file, gitmodules file, and other links within that repo all still reference the now-dead gitlab links. The builds don’t seem to be present at all.

That will all probably be fixed soon enough but right now that mirror which seems to have just been pushed as-is isn’t entirely usable.

That’s actually a choice you’re offered during Debian’s interactive install. When you’re offered the option to set a root password, if you leave it empty the system will disable direct root login and instead give your first normal user sudo access.

Debian. I was in a similar boat to OP and just a couple weeks ago migrated my almost 8-year-old home server setup from Ubuntu LTS to Debian Stable. Decided to finally move away from Ubuntu because I never cared for snap (had to keep removing it with every upgrade) and gradually gained a few smaller issues with Ubuntu. Seems good to me so far.

I considered RHEL/Rocky but decided against them largely because I wanted btrfs for my rootfs, which their stock kernel doesn’t have, though I use a few Red Hat developed tools like podman and cockpit. Fedora Server and the like have too fast a release lifecycle for my liking, though I use Fedora for my desktop. That left Debian as the one remaining obvious choice.

I also briefly considered throwing a Debian VM into TrueNAS Scale, since I also use this system as a ZFS NAS, but setting that up felt like I was fighting against the “appliance” nature of what TrueNAS tries to be.