Just a basic programmer living in California
Seems like a matter of preference, and I see the logic in it. I’ll mention that Nushell makes it easy to create custom shell functions that are invoked as sub-commands in this manner. https://www.nushell.sh/book/custom_commands.html#command-names
As someone who is not onboard with dismantling the existing political system without a better system ready to go, I think that dual power sounds like a great idea!
This happens to be the plot of the book series, The Accidental Minecraft Family
My favorite is Time Surfer. The core mechanic is basically the same as Tiny Wings, but the theme, artwork, levels, etc are all very different. I especially enjoy the chiptunes!
Are there other relevant standards? The XDG base directory specification has been around for a long time, and is well established.
Maybe your comment wooshed over my head; if so I apologize.
Are you saying that you don’t want to write your software according to the XDG spec, or that you don’t want to set the XDG env vars on your system? If it’s the second that’s fine - apps using XDG work just fine if you ignore it. If it’s the first I’d suggest reconsidering because XDG can make things much easier for users of your software who have system setups or preferences that are different from yours; and using XDG doesn’t cause problems for users who ignore it.
OP’s recommendation is aimed mostly at software authors.
So yes, “XDG” stands for “Cross-Desktop Group” - but I don’t agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don’t set the relevant env vars).
OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn’t on a system that doesn’t have a typical home directory layout or permissions.
I also have a slimfold micro that I’ve been using so long I don’t remember how old it is.
There was a post earlier today complaining about questions that aren’t open-ended, and therefore don’t adhere to the community rules. So here we are with a question with many possible answers (which makes it properly open-ended).
Probably not directly helpful, but Nix packages for Chromium and Electron apps are set up so that you can switch to native Wayland mode globally by setting an environment variable, NIXOS_OZONE_WL=1
I don’t know of any global setting that isn’t distro-specific.
The artificial sounds are legally required at low speeds, at least in the US and Europe. In the US electronic sounds are required at speeds below 30 kph. In the EU I think it’s 20 kph. At faster speeds the sounds of wheels on the road and such make electric and hybrid cars basically as loud as ICE cars.
There are very specific rules about the noises. It looks like there was some effort in the US to allow user-selectable sounds, but it didn’t work out. I found some info here, https://www.federalregister.gov/documents/2022/07/13/2022-14733/federal-motor-vehicle-safety-standards-minimum-sound-requirements-for-hybrid-and-electric-vehicles
FYI I’ve been running Steam and Wine games in Gamescope because I’m using a window manager that doesn’t implement XWayland. I don’t know if that would help with Nvidia, but might be worth a try. It works ok; Gamescope has a Steam integration switch that helps.
I think Electron apps mostly switch to native Wayland mode if you set an environment variable, ELECTRON_OZONE_PLATFORM_HINT=wayland. The one I don’t have working in Wayland mode is Discord. See https://wiki.archlinux.org/title/wayland#Electron
I’m a fan of Pitch Meeting. I feel like Honest Trailers is too mean.
It would make sense for the terminal to handle syntax highlighting since that would match how editors work. But the convention is that the shell handles highlighting, not the terminal. You can check which shell you are running with the command,
$ echo $SHELLIt’s done that way because the shell is a running program that is capable of telling the terminal which colors to show (by mixing color escape sequences into text). Compare that to code in an editor which is text, not a running program so the only option is for the editor to handle highlighting[1]. Editors need syntax files to configure highlighting for all the different programming languages, while terminals don’t need this because the shell tells them what colors to show.
[1] setting aside the “semantic highlighting” LSP capability - that was invented long after syntax highlighting conventions were established