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/)PR
Posts
0
Comments
142
Joined
2 yr. ago

  • Alas that would be a luxury for me. I got an Asus Strix Scar 17 2022 with NVidia 3060. I game with it, use Wayland, everything is fine.

    Except suspending/hibernating. When it wakes up the Plasma panel is pink, desktop is missing and the mouse is drawing trails. I have the NVidia suspend/hibernate scripts enabled, have a swap partition bigger than RAM, but everything still looks weird on wakeup. So I shut it down in the evening and boot it fully in the morning, no biggie I guess...

  • The unique problems for me with dogs is not just that they're evolved to interact better with us, it's that in many places where they eat them it's believed that it tastes better if it was terrified and in pain when killed. So you can imagine how they're treated when getting prepared to slaughter. No easy life or death for food dogs.

    Then there's several places in Peru where it's believed cats taste better if drowned.

    Not that we treat our livestock great in the west but some cultures take it to a horrifying level due to tradition.

  • systemd does have one problem that also existed before: sometimes services come with buggy unit files (or copy/pasted from something else and modified), similar to how there were all kinds of buggy scripts before. Unit files are much simpler than scripts and it should be easier to get right but when the author sometimes doesn't consider dependencies or test fail scenarios...

  • Well yes, if you don't provide intelligible arguments it doesn't deserve better. And a lot of the arguments really are like that: "systemd bad" or "is monolithic blob" (which it isn't).

  • Just to avoid misunderstandings: it's not a monotolithic blob, it is thought so because its first project was a system daemon that manages system services. It is described as "a software suite that provides an array of system components for Linux operating systems.", it is highly modular and offer many optional components that each have their own purpose.

  • It has been fine for me but I've only used it for 6 months (Endeavour OS==Arch). I did install it on a Btrfs root with snapper/btrfs-assistant) so I can revert to an old snapshot in btrfs-assistant and reboot in a minute. It tested that it works but haven't needed it so far.

    I update whenever with Yay which takes snapshots each time. I don't read mailing lists.

  • I've used Linux in various ways since the nineties and know it intimately but I don't want to fiddle with an install. When I got my new laptop this year I appreciated being able to plug in an EndavourOS flash drive, click on a couple of things and then let it install a sane default with prop NV driver already setup while I made coffee. I was ready to play games from my old Steam lib SSD in 20 min.

    I don't know if the Arch installer is like that but EOS is slick.

  • In case it helps: At install time I created a swap partition the same size as my RAM and a Btrfs root partition. Then after install I ran
    "yay -S snapper-support btrfs-assistant btrfmaintenance"

    Then after install I enabled the maintenance scripts with defaults in the btrfs-assistant GUI and that was it. It takes snapshots when installing stuff and I can do a roolback to a snapshot in btrfs-assistant GUI or Cli (requires an immediate reboot).

    One snag: If you installed it with Grub instead of systemd-boot it will show booteable snapshots in Grub but I don't know how roll back permanently if I've booted into one as it uses some sort of overlayfs. So I don't use this feature.

    I wish EOS did all this as an install option though.

  • I've been back and forth between Android and iOS several times, I'm happy with either these days.

    I use services that work on both platforms like GMail/Cal/Contacts, Dropbox free (10GB)/oneDrive + Cryptomator, Bitwarden, 2FAS, Signal/WhatsApp, etc. There's no lock-in on either platform as far as I'm concerned and I can switch over in half an hour and keep going.

    I charge my phones with an ancient 7W Qi pad, batteries usually last 3-4 years before any degradation is mildly noticeable, at which time getting a store to replace it is trivial or I sell the old phone and buy a new one - Apple/Samsung/Google, whatever takes my fancy.

  • I mean imo everything about the windows is terrible.

    Maybe that's very subjective but I find that thought very hyperbolic. Windows generally is pretty good and for example have some nice features like complete system reset while preserving your files. Windows has some issues but so does Linux.

    I only use Linux on my gaming+work laptop because I enjoy the freedom and I feel Windows is overly intricate and more and more "commercial" but Linux has its rough edges.

  • Well, it largely removes an attack surface for memory bugs, which is a huge thing. If we're writing a big driver (see the Rust driver for the Apple GPU) then suddenly waving hands incoherently 90% or more of the driver (depending) is likely to be much more memory safe and stable. As has been demonstrated with that particular driver already.

    I was watching the streams and when it compiled Asahi Lina usually only had to deal with logical type errors, not memory issues, it was basically a great showcase for Rust and memory safely. Unsafe is perfectly fine Rust, but it's a contract where the developer says to the compiler: "I know you can't guarantee this block is safe, so I'll keep a special eye on that, peer review more, test, etc. while you keep an eye on all the other code I can't fit in my head". In the case of Linux an Unsafe blocks means "we'll trust the Linux kernel code we connect to, though review it carefully".

    So saying all safety goes out the window is wrong, see it as a vastly reduced potential for memory problems, better error handling and more stable drivers, as demonstrated by the Apple GPU driver.

  • I've been watching Asahi Lina develop a big GPU driver for Apple silicon and development was so much faster because a whole category of bugs were largely absent once the code compiled, and memory issues are notoriously difficult to fix. Also error handling is easier and much cleaner.

    She wrote about it here and here.