Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)ZA
Posts
0
Comments
96
Joined
2 yr. ago

  • 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.

  • Compared to simplelogin (or proton pass aliases, addy, firefox relay, etc), one other downside of a catchall is in associations across accounts. Registering with a @passmail.net address implies that I use Proton; registering with random-string@mydomain.org implies I have access to that domain. If 10 data breach leaks have exactly one account matching the latter pattern then that's a strong sign the domain isn't shared. If one breached site has my mailing address, my real identity can be tied to all the others.

  • 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.

  • 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.

  • 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.

  • There is one caveat: Google Play Services and by extension Google's Play Store stopped receiving updates on Android 4.4 (released late 2013) last August, just before that OS hit 10 years old. Even so, the servers still work with that old app in the short term and there are alternatives for installing apps without relying on Google Play at all.

    That 10 year age is for the OS, not the device. Nexus 4 for example launched in 2012 with Android 4.2 and got updates up to Android 5.1.1 in 2015. So it still gets Play Store updates now. You can install apps from other sources, and you don't need to rely on internet or servers for initial setup if you don't want to, and you can even install a custom OS like Lineage's build of Android 8.1.

    Nexus 4's 2.5 years of OS updates was still abysmally low compared to how long phones should be perfectly usable for. Yet that 12 year old phone remains far more usable this year than a <5 year old Oculus Quest soon will be.

  • 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 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.

  • 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 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.

  • 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.

  • 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.

  • 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.

  • The act of tipping itself is a cultural thing it needs to be addressed culturally. If you can’t tip someone for something, complications in the law arise that may disallow giving money to people in general. For example how do you distinguish between tipping a server for a meal and giving the server a dollar as a gift?

    If you are a customer at a food or retail business and opt to give one worker there a cash gift while they are on the clock, how can that not be a tip? Current US laws like FLSA already have a very clear definition of tipped wages which would include anything matching that description.

    Even if you want to allow that sort of cash "gift", eliminating tips for credit card payments should be enough to shift the norms and expectations. Namely, prohibit payment terminals from prompting for a tip as part of the same credit card transaction and prohibit the tip lines on receipts. Majority of Americans don't pay with cash. If a business says they accept credit card, customers clearly aren't expected to give a decent tip and by extension the advertised meal prices and wage amounts should reflect what the customer is expected to pay and what the staff should expect to earn independent of customer whims.