• 2 Posts
  • 794 Comments
Joined 2 years ago
cake
Cake day: June 6th, 2023

help-circle
  • So,

    1. OP is asking why month before day rather than day before month
    2. In your example, it’s not clear whether you are doing Y-M-D or Y-D-M, but I assume you are putting month before day, so we agree on that part. But
    3. I think we’re all in favor of: Most significant on the left -> Least significant on the right. I’m just arguing that, most if the time, for the most common uses, Month is most significant. It’s just more common that you’re looking at a list of dates that all span the next few months than a list of dates that are all within this month, or beyond a year.

  • regardless of the month, I think what matters first is to know what day of the month you are in

    You’re telling me that if you have a list of scheduled dates in the near future to meet with clients/patients/whatever, you first want them sorted by day, and then month?

    So this list is the order you want to see these in?

    • 4/5/25
    • 8/7/25
    • 15/6/25
    • 16/5/25
    • 23/6/25

    Doesn’t it make way more sense to see them sorted by month first, then day, so that they’re actually in chronological order.

    • 5/4/25
    • 5/16/25
    • 6/15/25
    • 6/23/25
    • 7/8/25

    The only way you could defend the former listing is if you’re also arguing that it makes sense to sort the list by the middle column, and hopefully we all agree that is just absurd. We don’t alphabetize people by their middle names. You don’t look up a word in the dictionary starting with the letter in the middle.

    I jest, but I think this illustrates a real-life, commonplace example of when it makes sense. I agree that MM/DD/YYYY is not in order of magnitude, but I do believe it’s in order of most significance to least significance given the timescales we are typically dealing with.






  • And IMO if one of those students can get Roblox working on Linux, they have solved a harder problem than any homework they would be given 😆.

    I’m curious how ootb mint works out for this usecase. Any chance we could get a 6mo update later? I’m particularly curious how well it holds up against non-admin users who may constantly be trying to get root-level access. There’s almost certainly going to be one student who figures out a local privilege escalation.



  • IMO bazzite is too focused on gaming for people to be daily driving it for everything, but hey whatever works. Just hope they’re not upset when something breaks and the response from bazzite is “well yeah, that’s not something we bother testing for”.

    (I have bazzite on a HTPC in my living room, and I think it’s perfectly suited for that usecase)

    IMO Mint, Fedora, or OpenSUSE is going to offer the more stable, user-friendly experience long term. Install Lutris through the distro’s package manager, launch it, install bnet through lutris, launch it, install wow through bnet, launch it, Thrall’s your uncle 😉.

    Edit: to answer your other question, yes Lutris runs as an app similar to how battle.net or steam works on windows. It’s just that instead of having a storefront and downloading data directly from a central “lutris” server, it’s basically a bunch of community-written scripts to automate the installation and configuration of games from all sorts of places. So when you tell lutris to install bnet, it’s running a script that goes and downloads it from blizzard, then locally creates a wine environment, launches the installer in that environment, you install it like on windows, and then it creates a lutris launcher entry for the bnet executable so that when you click play on it in lutris, it will automatically launch it in a wine environment each time.

    And it should all work in KDE plasma, gnome, cinnamon, or whatever window manager you’re using (the window manager on msft windows is called dwm and it’s responsible for the same job).



  • Package managers tend to assume they are the only ones touching files in /usr/share. You will find if you try to change any files there, the next update may delete or download a new version of the file, stomping your changes. Instead your local changes should go in /usr/local (if you want something system-wide) or ~/.local (if it only applies to a specific user).

    Ex. If you made a custom .desktop file to show up in your app launcher, or a custom .xsession file to show up in a login manager.