Even submarines powered by diesel engines use, to my very limited knowledge, generators to convert to electricity and then use that electricity for the actual engines. Unlike most cars which do not convert to electricity first. And if the way the electricity was generated is what defines it, then other EVs would need to be allowed as well because the electricity could have been generated from burning fossils.
Fish is a surprisingly good shell.
It’s not POSIX compatible, but I don’t really care, it only executes its own scripts / functions. It’s not as innovative as elvish or nu, but it kind of does everything very conveniently and shell-y for lack of a better word – and it always seems so simple. It seems conservative in design, but the old concepts have been evolved in a very usable way. Something I can’t say for all the other shells I’ve tried – at some point, it always gets awkward where fish is just elegant.
I suspect that is something specific to Ecosia, that they changed parameters from time to time which changes the entry, making your selected one no longer available, and then this happens: https://support.mozilla.org/en-US/kb/search-engine-removal
The fact that they announce Ecosia now after it’s been available for a bit, makes me think this is what happened. I’ll see
Using Linux here
The Ukrainian strategy from 1991 to 2014? I’m not sure this is something I’d attempt nowadays.
Cool stuff, now of Firefox didn’t switch back to Google every major update or so, that would be great… because I actually do have Ecosia selected and need to switch back to it every once in a while because hey why not
I think military applications should focus on what’s best for the job, there are cases where EV is better and there are others where you want ICEs.
Banning EVs for the military sounds really serious because technically, these include electrically powered trains, and as far as I know most nautical vehicles also use electric engines.
I like how the headline’s structure makes it sound as if “in France” was part of the punishment. Reminds me of “Fistful of Yen”.
Take him to Detroit France!
The term midlife crisis doesn’t refer to just any crisis, it’s a very specific thing about your identity and achievements and can be financial, but doesn’t have to be. It’s more of a “what have I achieved in life / how do I compare to others” thing after about half of your work life (or actual life sometimes) is over. If you measure success financially then yeah it might play into the equation but being strapped for cash in your early twenties doesn’t make a midlife crisis.
No, Cargo.lock is the only relevant optional one for Rust packages and that is already there, so we should be good. I’ll request it tomorrow if someone else doesn’t beat me to it ;)
No, but I will try to incorporate the nixpkgs update script into it now that the metadata is fixed for the release. I’m not a nixpkgs maintainer (yet) though but usually this is close to automatic.
If you want, you can also submit and maintain the package, or I can put us both as maintainers
It’s rather simple in good cases, here’s my version:
{
lib,
fetchFromGitHub,
rustPlatform,
perl,
}:
let
pname = "managarr";
version = "0.4.1";
in
rustPlatform.buildRustPackage {
inherit pname version;
src = fetchFromGitHub {
owner = "Dark-Alex-17";
repo = pname;
rev = "df9bba32cb1628fe0bdf33c71089d7ae085066d4";
hash = "sha256-2KWuqv0nxMc+H+lmuNQ0lbEm5yE2akuZTa7PT5JcvBs=";
};
cargoHash = "sha256-hB4uRgVUp6YngMoXqd03U/n+HdlcYdL5bwvTxI4xCLE=";
nativeBuildInputs = [ perl ];
meta = {
description = "A TUI and CLI to manage your Servarrs";
homepage = "https://github.com/Dark-Alex-17/managarr";
license = lib.licenses.mit;
maintainers = [ ];
};
}
No worries, I look forward to using this in the future :) (though probably rarely, I don’t use my *arr stack often)
Once you have pushed your next release, I’ll submit the package definition I wrote to nixpkgs, currently worked around the ordering by checking out two commits after the tag, but since there’s no rush to push this, I’ll wait for the next release.
It’s kind of in line with their plan to get rid of OCSP: short certificate lifetimes keep CRLs short, so I get where they’re coming from (I think).
90 days of validity, which was once a short lifetime. Currently, Google is planning to enforce this as the maximum validity duration in their browser, and I’m sure Mozilla will follow, but it wouldn’t matter if they didn’t because no provider can afford to not support chromium based browsers.
I was expecting that they reduce the maximum situation to e.g. 30 days, but I guess they want to make the stricter rules optional first to make sure there are no issues.
So I’m currently building the package, and there’s one thing that irks me a bit about it, which is that you first tagged your release as 0.4.1 and then changed your Cargo.toml… which means that if you check out that tag on GitHub, the information is always one release behind. This also seemed to be the case with other releases (0.4.0 shows as 0.3.7, 0.3.7 as 0.3.6…). From the commit history, this also seems to affect Cargo.lock, so we’re always getting the lock file for the previous release when checking out the tag. Not ideal
An issue with the program itself: it will always show servers for both radarr and sonarr, regardless if you have them configured or not. Switching to an unconfigured one will yield an error for missing configuration. The program itself looks nice, though I’d prefer if there was the option to respect my shell’s color theme.
This makes me so angry, Russia is deploying huge amounts of foreign troops in Europe and leaders are just like “we must not escalate” bruh are you paying attention right now
Cool stuff, thanks.
Now if Sonarr didn’t depend on a .NET version that is EOL… recently deactivated it for that reason
Lol no
I have opened a pull request at https://github.com/NixOS/nixpkgs/pull/367042, there might be more changes needed as I had an error in the meta section of the package which I rectified according to the reviewers proposed changes. Not sure this is the end of it, but the request is open