The conditions that processors run under in situations like military equipment are drastically different from those of consumer devices. Consistency and stability are more important than performance in those contexts. So much so that RTOS systems like VxWorks are popular in that space. They'd probably already have features like clock boost disabled (or use processors completely lacking it) in favor of a lower fixed clock speed, probably avoiding these issues entirely.
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.
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.
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.
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.
if the featureset is not clear enough at first glance
My experience as someone who has barely dabbled in Matrix, tried comparing clients, and knows a lot of people who stick to Discord: a lot of Discord users heavily use custom emotes, voice chat, and screen sharing. It's not even easy to figure out which Matrix clients support each of those features without installing everything and trying it out. There's a clients comparison on matrix.org that mentions Voip but not stickers or video.
For stickers alone:
- Element is widely considered the go-to Matrix client but uses a strange integration system for predefined sticker packs instead of the MSC2545 stickers that more closely resemble what users coming from Discord would want.
- Cinny seems to have the best support for stickers/emotes but its site doesn't mention them at all. It supports uploading and managing sticker packs at either a channel or user level, provides a nice picker UI to send any picture from those packs as either a large "sticker" or a small inline "emoji", and allows using them for reactions.
- FluffyChat mentions stickers on its site and has the second best sticker support, with all of those except reactions and a graphical sticker picker for inline emoji (need to type them as shortcode).
- SchildiChat, Nheko, and NeoChat have some sort of limited support for custom stickers/emoji. NeoChat is the only one of those that advertises stickers on its main site. Nheko mentions them in a GitHub readme.
Being able to freely use custom emotes without paying for a Discord Nitro subscription nor server boosts would be a great selling point but it's not something most users would be able to figure out before signing up. The limited client support isn't great; e.g. Fluffy is the only Android client that supports sending custom stickers but some people may dislike the chat bubbles style UI.
Not every work environment is the same.
When I first started with my current employer I was given a system with RHEL preinstalled and I replaced it with Fedora on my first day. I was told to use LUKS and given a normal OpenVPN profile but otherwise they don't control or monitor anything about my workstation. No matter how many years or decades I stay at this company, it's extremely unlikely I'll ever touch an OS that isn't Linux-based during work time.
Every previous job I've been at also had me use Linux for my primary workstation, because my field of work more or less requires it, but some have needed me to access a separate Windows system/server/VM on rare occasions.
I've been using it since it felt usable enough in GNOME to me. Around 2015-ish, give or take a year. GNOME leading on Wayland support is a big part of why I switched to it from Xfce back then. Nowadays KDE and others have plenty good Wayland support too (better in some ways like allowing server-side decorations and global shortcuts) but I just haven't felt like trying to properly experiment to see what I like.
I've always avoided Nvidia on my desktops. Stuck with either radeon or intel and never had any exceptionally big issues with them on Wayland. Though other things like hardware accelerated video decoding have had a history of being spotty on some drivers/GPUs.
If you're assuming "as long as the hardware will function" in the first place: even digital copies, DLC, and updates installed on the system before the servers shutdown will continue working even without hacks. There's no check-in requirement except for the subscription-locked things like SNES games.
However, the result of a nonrepairable hardware failure when you have no hacks nor official servers is rather bad no matter how your games are obtained: OFW does not allow you to transfer save data from one system to another without going through Nintendo servers and a vast majority of cartridge games are incomplete without updates or DLC.
I use it for just two features: video screenshots and increasing playback speed higher than 2x. Both seem like small features but I very quickly notice their absence when I try to use a browser that I haven't yet installed it in.
Anbernic devices in particular are known to ship with an SD card that's preloaded with a fairly large game library. I own a RG351M which did indeed include a cheap card loaded with both the OS and a collection of games by Nintendo, Sega, and many others, plus some strange rom hacks. I immediately swapped that card out for a better one with a better CFW and my own files.
Most other notable names in the emulation handhelds space like Retroid, Ayn, and Ayaneo expect users to be able to provide their own files instead, which I'd say makes more sense.