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.

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 never had problems with Debian stable, especially on headless server. But it’s not especially well-suited for brand new desktop hardware; even Ubuntu LTS and RHEL focus more on hardware enablement backports than Debian.

I’ve had a worse experience with Debian testing breaking my system with updates than Arch. Adding to that the freeze period (2012’s was the worst, lasting 11 months) makes testing feel like the worst of both worlds between rolling and standard release distros.

As someone who used to use Arch a decade ago: I still use pacman for devkitpro at least, and I do miss how fast its parallel downloads get, but the tool I use to manage packages is far from the most important difference between distros to me, even if you assume not needing AUR.

The first I tried was Ubuntu 7.04 but I didn’t stick with it and went back to XP. Until I ended up with a hardware setup that wouldn’t work on Windows XP (widescreen monitor + Intel graphics driver with no widescreen mode options) but worked perfectly on Ubuntu 9.10. I never truly went back to Windows since.

Tried a few other distros in 2011 then switched to Arch for a couple years, Xubuntu for a couple years, Ubuntu GNOME for 7-8 years, and finally switched to Fedora last year.

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.

Every single other browser is Chromium.

One exception I’m aware of: GNOME Web (aka epiphany-browser) uses WebKitGTK, which is based on Apple’s WebKit rather than Google’s Chromium/Blink. But it’s Linux desktops first and foremost. Not on mobile platforms, not exactly intended for Windows (might be usable with Cygwin/WSL) or macOS (seems to be on MacPorts) either, and even on non-GNOME desktops like KDE it might seem a bit out of place.

I daily drive Firefox but Epiphany is my first choice fallback on the rare occasion I encounter a site that’s broken on Firefox.

The main reason people use Fandom in the first place is the free hosting. Whether you use MediaWiki or any other wiki software, paying for the server resources to host your own instance and taking the time to manage it is still a tall hurdle for many communities. There already are plenty of MediaWiki instances for specific interests that aren’t affected by Fandom’s problems.

Even so, federation tends to foster a culture of more self-hosting and less centralization, encouraging more people who have the means to host to do so, though I’m not sure how applicable that effect would be to wikis.