The purpose is similar, i.e. configuring a system, but I’d say Ansible works best, if you need to make a few small changes from an existing distro, whereas NixOS rather takes the approach of controlling everything about the operating system.
And in many ways, controlling everything is actually simpler.
As the other person said, the bit about Arch is just the preamble.
But you can use Nix Home-Manager on Arch (or other distros), if you’re so inclined, which will give you that reproducibility for the stuff in your home-directory.
In some ways, this is like backing up and restoring your dotfiles, but it allows you to template those dotfiles and depending on the program, it offers simple ways to populate the dotfile templates. For example, KDE applications don’t generally offer very legible dotfiles and so configuring e.g. a panel via dotfiles is kind of a pain. To help with this, there’s Nix Plasma-Manager.
Copy Link to Highlight is my favorite addition.
The thing I never understood about PowerShell is that it’s partially more verbose than C#, which is one of the most verbose programming languages in existence. It just feels like you might as well go for a full-fledged programming language at that point.
The appeal of Bash et al is that the scripting is almost the same as the interactive usage, which you already know. But because PowerShell is so verbose, I’m really not sure people do use it interactively.
I guess, that code snippet in the article makes somewhat of a difference, in that PowerShell offers better features for interop between processes. But man, that still feels like it could’ve been a library instead…
Yeah, I also recommend this. Particularly with laptops, it’s good to have a full-fledged desktop environment, since you’re more likely to need WiFi, power management, easy display configuration etc…
Oh yeah, I do think setTimeout executes in parallel, so only the largest element determines the execution time. It was difficult enough to make that sentence make sense, so I didn’t want to cram that detail in as well. 🙃
I mean, it does scale with the size of the input. Just not with the count of inputs, but rather the size of each input element.
I agree in general, that a crash is much better than silently failing, but well, to give you some of the nuance I’ve already mostly figured out:
Currently implementing error handling for a library I’m building and the process is basically to just throw all of the information I can find into there. It makes the error handling code quite verbose, but there’s no easy way for me to know whether the underlying errors expose that information already, so this is actually easier to deal with. 🫠
That is a good tip. Unfortunately, I am too fish to understand it. 🙃
I just type ps and in 9 out of 10 cases, my shell suggests ps -ef | grep <process-name>. So, it’s actually less for me to type than “pgrep”…
Ah, that was a brainfart. I do use pkill primarily. I just use the other command, when I’m not sure what the process is called…
Yeah, I especially don’t understand it here, because it’s a graphical tool. You don’t have to keep backwards compatibility.
Even if you’re worried about people depending on the format that’s being piped, you could keep only the piped format stable. We have the technology.
Yeah, I would often just grab htop because I had no idea how to read the CPU usage out of top.
For example, for me it says:
%Cpu(s): 0,4 us, 0,4 sy, 0,0 ni, 98,8 id, 0,0 wa, 0,3 hi, 0,0 si, 0,0 st
Now that I look at it, I can guess that us and sy are supposed to be user and system time. And I guess id is supposed to be idle.
I have no guess what the other numbers might be, though. And well, I would often like to see the CPU usage per core.
Now I know that I can just press 1t and get effectively the same view as in htop.
I might learn top’s filtering workflow, too. But so far, I always killed processes with ps -ef | grep <process-name> and then kill <pid>, which isn’t particularly more cumbersome, so will see…
What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?
I know that the terminal emulator built into the JetBrains IDEs works that way…
Last year, money was running out in our project and the guy who had trained me decided he’d take the L and move to another project, so we could continue in the project. And yeah, suddenly I was in the role of the lead developer.
Like, don’t get me wrong, I would’ve been the one to be moved to another project, if I wasn’t up for the task. It’s not like I was a complete dumbass.
But it did still feel more like “I guess, we doin’ lead development now” rather than something I had intentionally worked towards.
I mean, depends on the country. Labor laws here in Germany mean that it’s worth investing into workers and when you have invested, it costs you significantly more when they quit than if you just paid them reasonably.
I can’t really sell this as a solution, as it requires quite a lot more involvement than a simple configuration file should, but I use Nix Home Manager with Plasma Manager for this.
This is part of the tooling you’d use on NixOS, but you can use it on other distros, too, and it generally works fine (although I’m not sure, if the current version of Plasma Manager still supports Plasma 5, in case you’re still on a distro with that).
Basically, it allows you to define e.g. keyboard shortcuts like this:
shortcuts = {
ksmserver = {
"Lock Session" = [
"Screensaver"
"Meta+Ctrl+Alt+L"
];
};
kwin = {
"Expose" = "Meta+,";
"Switch Window Down" = "Meta+J";
"Switch Window Left" = "Meta+H";
"Switch Window Right" = "Meta+L";
"Switch Window Up" = "Meta+K";
};
};
It then fucks up the formatting, so that it looks like KDE expects, and throws it into ~/.config/kglobalshortcutsrc.
(KDE does actually have a text-based config, it’s just borderline unusable.)
Well, and you can do this with lots of other Plasma options, too. Here’s their official example: https://github.com/nix-community/plasma-manager/blob/trunk/examples/home.nix
Been hacking away at a library and definitely feeling this one. Some APIs, I’m not yet terribly happy with, and there’s always this urge to introduce a macro to hide away the ugly API.
So far, I’m still staying away from it, because I’m just thinking that users will not have an easier time either way. The code they write may look prettier, but if they have to learn custom syntax rules for it, then it isn’t easier to understand in the end.
Also, while a macro can clean up some rough edges, it won’t fix up an API that’s illogical to begin with. Well, unless you make it a turing-complete macro (i.e. proc_macro rather than macro_rules), but that makes it infinitely harder to understand once more.
I find that if your command is complex enough that editing it on the terminal becomes annoying, then there’s a very high chance you want it in a file anyways, just to document what you did and to allow easily re-running it.
Having said that, you can also have your shell open the command in your editor of choice: https://www.stefanjudis.com/today-i-learned/edit-long-shell-commands-in-your-usdeditor/
Well, good news, it actually is fun to dick around in the Nix configuration and see those changes manifest on your system.