Just a basic programmer living in California
I use metric temperature when I talk to my kids. Now they give me a hard time when I give them a Fahrenheit value! Keeps me honest I guess. I’ve also got my oldest using a 24 hour clock.
Stardate, 2024-08-30T06:34:17.993Z
Inefficient compared to batteries? I found another article saying this company hopes that the energy dome will cost ⅔ the cost of a lithium-ion battery installation with the same energy capacity. https://www.popularmechanics.com/science/energy/a61572150/carbon-dioxide-energy-dome-plant/
It seems like only one side of the ancient rivalry is represented in the comments here. No worries, I’m right there with you.
Yeah the performance differences don’t matter in most cases. Rust makes it tempting to optimize everything because the language is explicit about runtime representations. But that doesn’t mean that optimizing is the best use of your time.
To expand on why generics are preferred, just in case you haven’t seen these points yet: the performance downsides of Box<dyn MyTrait>
are,
There is also a possible type theory objection which is that normally there is a distinction between types and traits. Traits are not types themselves, but instead define sets of types with shared behavior. (That’s why the same feature in Haskell is called a “type class”, because it defines a class of types that have something in common.) But dyn
turns a trait into a type which undermines the type/trait distinction. It’s useful enough to justify being in the language, but a little unsettling from a certain perspective.
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 $SHELL
It’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
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
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.
The picture looks like an Indian Runner duck to me
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.
From what I’ve learned revolutions are often accompanied by circumstances where people are desperate due to lack of basic necessities, especially food.
The French revolution was preceded by a serious food shortage. Remember that “let them eat cake” comment? One of the key events, the Women’s March which displaced the king and queen from Versailles, was specifically motivated by demands for food.
The European People’s Spring saw lots of revolutions across Europe in 1848-1849 including in France, Italy, Bavaria, Austria, Hungary. That was about the same time as a continent-wide grain shortage on top of an economic crisis.
The Russian revolution of 1917 came at a time when a combination of WW1, bad leadership, and an extra cold winter led to food shortages, and fuel shortages so people were starving and freezing at the same time.
This seems like the right answer to me. Whether or not you decide to dual boot, make one of these USB keys so you can recover if something goes wrong.
When I was using Debian I found I could generally get the latest version of software I wanted from Nix if it wasn’t in the main Debian repos, or was outdated. Nix works quite well on any Linux distro - it doesn’t interfere with the rest of the system.
All I can tell you is that this is done differently for each shell. So decide whether you want completions for bash, zsh, fish, all of the above, or whatever, and look at the docs for the relevant shells.
NixOS and Home Manager config both ways to get rid of the same thing