I should try Nix on Mac again; I took against it a while ago for … reasons? … and I do love it on the Linux machine in the basement. I fear it would be fighting the platform too much on Darwin, but it can’t hurt to try.
I have used it quite successfully on MacOS. I do only use it for per project shells though, I still install all “system level” applications with Brew.
I am in a kinda inbetween phase: I use home-manager, and use nix as a “primary” package manager. Meaning, I first try to install stuff via nix; but when something is not available in nixpkgs, I resort to brew. Which seems to be much more often than I’d like, unfortunately… :(
Didn’t try nix-darwin yet; I feel not brave enough yet…?
Curious, any recent examples come to mind where you had to resort to brew instead of nixpkgs?
Did you open a package request on the nixpkgs repo?
Hm, haven’t installed anything over last 3+ months so don’t remember now; but I’m starting a new job just now, so I can try and collect a list for you if something shows up - and if I remember :/ (will try to put up a todo for that).
Didn’t request, I don’t feel like bothering people, esp. as I seem to believe the Nixpkgs maintainers tend to be overburdened anyway - or has that changed since a few years ago?
edit: Also, sometimes I’m trying stuff and not yet sure if I won’t uninstall, so if it’s not on nixpkgs, should I ask someone to maintain it just for the sake of trying and uninstalling?
There’s thousands of contributors and package maintainers. I wouldn’t say you should open a package request for something you’re just trying out on a whim, but if it’s something you actually care about and would be willing to commit some time helping through testing and such then sure.
One example I had recently was Karabiner-Elements. I wasn’t sure how to handle the use of Darwin kernel extensions.
I’m a fan of Nix and use it across both NixOS and macOS.
I find nix-darwin is useful for configuring the macOS desktop experience, and between nixpkgs and home-manager you can get quite far towards a declarative macOS setup. I only reach for Homebrew to install some macOS UI applications (so casks, really) that I can’t easily Nix-ify, and I still manage the Brewfile using Nix (and a special casks list type that allows me to declare the cask near the respective Linux pkgs statement).
I recently updated my dotfiles to build both platforms using CI on push to ensure I haven’t broken either with a change. I also store the resultant binaries in Cachix which often saves me needing to locally build.
Fantastic article. Computers are indeed really fast and if you structure the system for the problem while minimizing assumptions then as the article says you could be doing innovative things.
Now I’m inspired to write about the autoscaling CI system we built at Zenefits running on AWS spot instances that would grind through 20k+ tests for every pull request.
As someone who is currently working through reworking a CI system, I would love to read something like that!
I’ll look into moving it up the post queue but not making any promises.
What are the constraints and requirements for the work you’re doing?
Nothing nearly as complicated. It’s a Node.js monorepo with an old Jenkins instance that is very slow/crash prone. Mostly just want to make it reliable (and maybe a bit faster) and add pull request building.
The bit about the AWS spot instances is what caught my eye. I have been looking into them to allow us to have beefier build agents without spending way too much money.
Makes sense. I think Jenkins has a plugin or two for controlling spot instances. Something to look into if you’re considering spot instances for cost and performance reasons (assuming you haven’t yet).
One thing we did at Zenefits that was good from a performance perspective was pre-baking the build agents with snapshots of the code and all the other required bits and pieces. So as soon as the agent was online it could do a git pull and be off to the races.
The other thing was using LXC containers for isolation to pack more build agents per VM. The controller for the build agents was Buildkite. Not saying use Buildkite but I can’t recommend those folks enough. They saved us the hassle of building our own agent/workflow controller.
As someone else who works in CI/CD, I too would love to hear some more detailed info about this.
Damn…I trounced the current high score (32704, I got 61768), but was expecting it to announce “game over” or something and exited the session without recording it. Oh well.
Shit, sorry. I skipped implementing a game over check because it’s not entirely trivial.
I did the same thing the first try, you could just leave a message at the bottom with instructions.
Awesome. I really appreciate how simple the code is too.
How about something like solitaire? Or sudoku (not sure how the scoreboard with work with that though).
Most of the others I can think require multiple players which would add a lot more complexity.
I really wish something like this or Little Snitch exist for Linux. I would use it in a heartbeat. Unfortunately nothing seems as easy to use.
I wonder if this is up to snuff https://github.com/evilsocket/opensnitch
Thanks for the tip. I will have to try it out.
Typically if want these kinds of requests to gain traction you’re going to need to provide a list of Nim articles proving the need for a new tag.
Good point. I just edited my post.
A quick search shows quite a few links.
I’m not for or against the tag; frankly I don’t care. I’m just stating how these kinds of requests typically work.
See here or even here.
Makes sense. Sorry if that came off bad, I’m new around here and don’t really know how things are done.
Thanks for the info.
It always bugs me why we need a shell like syntax? For all those shell clones in lisp, we already have an REPL. What those shell clones do is some kind of parsing the shell syntax and calling lisp functions anyway. You are not going to get a posix compatible shell anyway, then why do it?
Is it because unix shell has a superior syntax geared toward CLI? Is it mostly because we can save a few keystrokes?
It is an interesting point. The pipe and redirect syntax is very succinct and powerful though.
I really like the idea that of something like this that is mostly the same for simple cases (which probably make up 90%+ of my shell usage), but allows you to dip down to the more powerful syntax very easily when the need arises.
The reason I write a lot of shell scripts is the simplicity of invoking commands, reading and writing files, stdio, pipes, branching on exit codes, command substitution, etc.
Doing this with things like Python’s subprocess module is a pain, and often requires highly non-obvious things like spawning extra threads to avoid deadlocks, etc. Helper libraries make life much easier, although I agree that altering the syntax to match sh is usually unneccessary.
This is definitely a quality-of-life thing that you only notice when it’s gone. I typically use it as a function, but since it’s the shell, there’s ten thousand ways to do it. Here’s (my) fish shell version for copy-paste:
function man -d "Pretty manpages"
LESS_TERMCAP_mb=(printf "\e[1;31m") \
LESS_TERMCAP_md=(printf "\e[1;31m") \
LESS_TERMCAP_me=(printf "\e[0m") \
LESS_TERMCAP_se=(printf "\e[0m") \
LESS_TERMCAP_so=(printf "\e[1;44;33m") \
LESS_TERMCAP_ue=(printf "\e[0m") \
LESS_TERMCAP_us=(printf "\e[1;32m") \
That’s nice. Going to use that for sure.
FYI fish has a set_color builtin that might make that a bit more readable.