For backups, I was considering setting up borgmatic with its home-manager integration, so that it would also work on my Linux desktops.

But I later found that you can use macOS’s native backups mechanism “Time Machine” with remote Samba shares, so I looked further into that, to have a better and more nicely integrated experience. By setting up Samba on my home server, I could make a share for my time machine backups and another share for miscelleanous files, integrated within Finder.

So here’s how I did it.

Setting up the server

Following the NixOS wiki page, here’s a basic setup for the Samba server:

services = {
  samba = {
    enable = true;

    settings = {
      global = {
        "workgroup" = "WORKGROUP";
        "server string" = "smbnix";
        "netbios name" = "smbnix";
        "security" = "user";
      };

      "my_share" = {
        "path" = "/home/john"
        "valid users" = "john";
        "force user" = "john";
        "public" = "no";
        "writeable" = "yes";
      };
    };
  };

  samba-wsdd = {
    enable = true;
    discovery = true;
  };

  avahi = {
    enable = true;

    publish.enable = true;
    publish.userServices = true;
    nssmdns4 = true;
  };
};

With this, you should now be able to access the on Samba clients at smb://<ip_address>/my_share. And the nice part is that Gnome Files, macOS Finder, and other applications can use this directly.

And here’s my own setup, where I also add some options for better macOS compatibility, and declaratively set ownership of the shares’ directories on the server system:

let
  user = "samba";
  privatePath = "/mnt/samba/private";
  tmPath = "/mnt/samba/tm_share";
in
{
  # https://wiki.nixos.org/wiki/Samba#Server_setup
  services = {
    samba = {
      enable = true;

      settings = {
        global = {
          "workgroup" = "WORKGROUP";
          "server string" = "smbnix";
          "netbios name" = "smbnix";
          "security" = "user";

          # Only available on localhost and Tailscale
          # note: localhost is the ipv6 localhost ::1
          "hosts allow" = "100.64.0.0/10 127.0.0.1 localhost";
          "hosts deny" = "0.0.0.0/0";
          "guest account" = "nobody";
          "map to guest" = "bad user";
        };

        "private" = {
          "path" = privatePath;
          "valid users" = user;
          "public" = "no";
          "writeable" = "yes";
          "force user" = user;
          "fruit:aapl" = "yes";
          "vfs objects" = "catia fruit streams_xattr";
        };

        "tm_share" = {
          "path" = tmPath;
          "valid users" = user;
          "public" = "no";
          "writeable" = "yes";
          "force user" = user;
          # Below are the most imporant for macOS compatibility
          # Change the above to suit your needs
          "fruit:aapl" = "yes";
          "fruit:time machine" = "yes";
          "vfs objects" = "catia fruit streams_xattr";
        };
      };
    };

    samba-wsdd = {
      enable = true;
      discovery = true;
    };

    avahi = {
      enable = true;

      publish.enable = true;
      publish.userServices = true;
      nssmdns4 = true;

      # https://wiki.nixos.org/wiki/Samba#Apple_Time_Machine
      extraServiceFiles = {
        timemachine = ''
          <?xml version="1.0" standalone='no'?>
          <!DOCTYPE service-group SYSTEM "avahi-service.dtd">
          <service-group>
            <name replace-wildcards="yes">%h</name>
            <service>
              <type>_smb._tcp</type>
              <port>445</port>
            </service>
              <service>
              <type>_device-info._tcp</type>
              <port>0</port>
              <txt-record>model=TimeCapsule8,119</txt-record>
            </service>
            <service>
              <type>_adisk._tcp</type>
              <!--
                change tm_share to share name, if you changed it.
              -->
              <txt-record>dk0=adVN=tm_share,adVF=0x82</txt-record>
              <txt-record>sys=waMa=0,adVF=0x100</txt-record>
            </service>
          </service-group>
        '';
      };
    };
  };

  fileSystems."${privatePath}" = {
    device = "zsafe/samba";
    fsType = "zfs";
    options = [ "zfsutil" ];
  };

  fileSystems."${tmPath}" = {
    device = "zsafe/timemachine";
    fsType = "zfs";
    options = [ "zfsutil" ];
  };

  # Set up password: https://wiki.nixos.org/wiki/Samba#User_Authentication
  users.users.${user}.isNormalUser = true;

  # Share path must be owned by the respective unix user. (e.g. ❯ chown -R samba: /samba)
  systemd.tmpfiles.rules = [
    "d ${privatePath} 0755 ${user} users"
    "d ${tmPath} 0755 ${user} users"
  ];
}

In my setup, I also make it so that only devices in my Tailscale network can access the shares. Unfortunately, I couldn’t seem to connect to Samba shares using Tailscale’s MagicDNS, so I had to fallback to using the server’s Tailscale IP instead.

I also created a separate user just for this, as I would prefer not to connect directly as root. Something that wasn’t immediately obvious is that each Samba user needs to have a corresponding unix user on the host system and also that the directories must be accessible by that user. So I also added systemd-tmpfiles rules to do that automatically.

To set the samba user’s password: sudo smbpasswd -a samba

This version also has a separate share just for Time Machine backups. To set that up, first connect through Finder > Go > Connect to Server (CMD + K) > smb://<ip_address>/tm_share and connect with the Samba user and its samba password.

Finally, this should now show up as an available backup disk in Time Machine settings. Here, I set up a more or less arbitrary quota of 1TB (which you can’t seem to easily change later) and also enabled encryption. After that, Time Machine should be set up and you can now use the fancy interface to show the contents of a directory in the past and restore files (and also just fully restore on freshly set up Mac).

Some little tricks that weren’t immediately obvious were how to pin a Samba folder to Finder’s sidebar and Time Machine complaining that it lost access to the share (because I became offline and/or suspended the computer).

To pin the folder to Finder’s sidebar, open a terminal and do open /Volumes/<share_name> after mounting it through Finder as described above. Now, on Finder > View > Show Path Bar (CMD + OPT + P) and drag the icon next to the share’s name to the Sidebar.

After becoming offline, accessing (and therefore mounting) the share didnt’ seem to be enough. I still quite haven’t figured out how to recover reliably, but manually opening the share and mounting/opening its Sparse Bundle file seems to allow Time Machine to be able to see it again.

Closing remarks

I’m happy that after some configuration and troubleshooting, all appears to be working smoothly.

It seems that time machine backups are basically APFS snapshots, which themselves seem to be analagous to ZFS snapshots. So I’m happy that, in a way, my setup is similar to having automatic snapshots on my Mac and then sending them encrypted to some remote server, as I’ve been meaning to do on my remaining NixOS servers with a Sanoid/Syncoid setup.

References

• https://wiki.nixos.org/wiki/Samba

A popular approach seems to be just using Ollama or LM Studio but I’d like to avoid both. I’ve been getting a bad impresison of Ollama for multiple reasons, such as their use of misleading names and tags for the models, and seemingly leveraging llama.cpp without giving proper credit. As for LM Studio, I’m mainly avoiding it because it isn’t free software.

This post while focus on llama.cpp and Open WebUI. The instructions are tailored to Homebrew on macOS but I believe it should work mostly the same in Linux, just with different ways of installing the tools.

Setting up Docker

Because, as of March 2025, I’m unable to use the open-webui package from Nix, we’ll be using Docker for that.

Docker Desktop on macOS seems to be having some issues lately, so I took the chance to try out colima for a leaner setup. We can install it like so:

brew install colima docker

After that, we can just do:

colima start

And the docker command will work as expected.

Installing llama.cpp

To run the model, we’ll be using llama.cpp, a leading open-source project for running LLMs locally.

Again, we can install it with Homebrew:

brew install llama.cpp

Running a model

For a more minimalist setup, it is possible to run the model with llama-cli from llama.cpp and interact with it directly in the terminal.

However, I’ll show you how to run the model with llama-server so that it hosts an API to connect with Open WebUI, where we’ll have niceties like conversation history.

For example, here’s how we can run the freshly released Qwen QwQ model:

llama-server \
    -hf bartowski/Qwen_QwQ-32B-GGUF:q4_k_m \
    --host 127.0.0.1 \
    --port 10000

I haven’t found this -hf flag mentioned very often but I find it useful to have llama.cpp download the model directly from Hugging Face. If at a later point you wish to move or delete these models, on macOS they’re stored at ~/Library/Caches/llama.cpp.

From my (superficial) research, the Q4_K_M level of quantization seems to provide a nice balance of small size while keeping decent results. I tend to search for models in the form of GGUFs by bartowski on Hugging Face. On my MacBook Pro 14 M1 Pro with 32GB of RAM, I find models of size 32B with Q4_K_M quantization to be the sweet spot.

There’s also lots of room for exploration and tuning with llama.cpp’s other flags and parameters. However, because I currently don’t really know what those do, I prefer to keep them to their default values.

Running Open WebUI

Finally, to interact with the model, we’ll use Open WebUI.

We can launch it like this:

docker run --pull=always --rm -p 3000:8080 -e WEBUI_AUTH=False -v ~/Documents/open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main

This will launch an Open WebUI instance, without logins, accessible on localhost:3000 in a Web Browser. Stateful data is kept in the ~/Documents/open-webui directory.

Opening up localhost:3000 on your Web Browser of choice will now leave you with the Open WebUI interface. All that’s left to do is to connect it to the llama.cpp we left running:

1. Admin Settings
2. Connections > OpenAI Connections
3. Add Connection:
   • URL: http://host.docker.internal:10000/v1
   • API Key: none

And now you should be able to start a new chat with the model. I find it sometimes takes a while to “warm up” but then it starts giving faster responses.

Closing thoughts

Very exciting times ahead in the local LLM space. It seems that while state of the art commercial models are plateauing, open-source models are increasingly achieving better performance at smaller sizes. A world where everyone is able to run excellent models on their own computers is rapidly approaching.

I’m definitely instered in digging further.\ I’d like to try out mlx models instead of GGUFs on llama.cpp, to see if I can get faster speed out of my MacBook. It would also be interesting to see if it is possible to setup a local SearxNG instance for setting up Web Search on Open WebUI. Finally, I’d like to check out tools like aider and tabby for local code assistance and completion.

References

• https://docs.openwebui.com/
• https://docs.openwebui.com/tutorials/integrations/llm-providers/deepseekr1-dynamic/#step-5-connect-llamacpp-to-open-webui
• https://unsloth.ai/blog/deepseekr1-dynamic#running%20r1
• https://reddit.com/r/localllama
• https://github.com/ggml-org/llama.cpp

But having just come from NixOS, I was missing that declarative mindset in being able to manage my system from a single file. Luckily, with nix-darwin and home-manager I was able to get my system mostly declarative, at least declarative enough for my needs. This also allowed to manage the Mac with my existing NixOS flake, so I could reuse existing configurations, like my zsh home-manager configuration.

Installation

Starting from a fresh macOS installation, this is how I bootstrapped my nix-darwin configuration:

1. Install Nix:

   curl -L https://nixos.org/nix/install | sh

   For this step, you could also try to use the Determinate Systems nix-installer, which I’ve read good things about, although the official installer also worked just fine.

2. Enable flakes:

   mkdir -p ~/.config/nix
   cat <<EOF > ~/.config/nix/nix.conf
   experimental-features = nix-command flakes
   EOF

3. Use nix run to run the first rebuild:

   nix run nix-darwin -- switch --flake <path_to_nix_darwin_configuration>

4. Use darwin-rebuild normally:

   darwin-rebuild switch --flake <path_to_nix_darwin_configuration>

Declarative Homebrew package management

One of the key reasons for using nix-darwin is not only access to the nix package manager, but being able to use Homebrew declaratively.

Homebrew is the de facto package manager for macOS. Most programs you can think are available over there, especially CLI tools but also GUI apps in the form of casks.

So we would very much like to keep access to those apps, only adding declarativeness to the workflow.

Another reason for using Homebrew is simply because nixpkgs cannot yet replace it, especially when it comes to GUI apps. Some could say that this will never happen because it’s out of scope of the nixpkgs project, which I guess is reasonable.

To use Homebrew, we first have to install it manually:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After that, we can use the homebrew module from nix-darwin, like the following example:

# I'd rather not have telemetry on my package manager.
environment.variables.HOMEBREW_NO_ANALYTICS = "1";

homebrew = {
  enable = true;

  onActivation = {
    autoUpdate = true;
    cleanup = "zap";
    upgrade = true;
  };

  brews = [
    "coreutils"
    "direnv"
    "fd"
    "gcc"
    "git"
    "grep"
    "ripgrep"
    "trash"
  ];

  # Update these applicatons manually.
  # As brew would update them by unninstalling and installing the newest
  # version, it could lead to data loss.
  casks = [
    "docker"
    "emacs-mac" # Emacs fork with better macOS support
    "firefox"
    "iterm2"
    "monitorcontrol" # Brightness and volume controls for external monitors.
    "ukelele"
    "unnaturalscrollwheels" # Enable natural scrolling in the trackpad but regular scroll on an external mouse
    "utm" # Virtual Machine Manager
    "visual-studio-code"
  ];

  taps = [
    "railwaycat/emacsmacport" # emacs-mac
  ];

  masApps = {
    Tailscale = 1475387142; # App Store URL id
  };
};

One of the most important features in managing packages this way is that removing packages from the configuration above also uninstalls them, which is one of the big features I was missing from NixOS. This avoids the traditional buildup of unused and forgotten packages in the system.

You supposedly can also use this to manage App Store apps but I found that I always needed to manually install them first (so they could be registered to my account?), so it wasn’t as useful.

Other noteworthy options

The list of options is quite extensive, here are some that I found useful:

Nix management

# Auto upgrade nix package and the daemon service.
services.nix-daemon.enable = true;

nix = {
  package = pkgs.nix;
  gc.automatic = true;
  optimise.automatic = true;
  settings = {
    auto-optimise-store = true;
    experimental-features = [ "nix-command" "flakes" ];
  };
};

sudo with Touch ID

Just like when macOS asks for elevated privileges, this makes sudo also work with Touch ID, which I find quite ergonomic:

security.pam.enableSudoTouchIdAuth = true;

Keyboard tweaks

These are some keyboard tweaks like turning caps lock into ctrl and disabling press and hold for diacritics:

system.keyboard.enableKeyMapping = true;
system.keyboard.remapCapsLockToControl = true;

# Disable press and hold for diacritics.
# I want to be able to press and hold j and k
# in VSCode with vim keys to move around.
system.defaults.NSGlobalDomain.ApplePressAndHoldEnabled = false;

Simple nix-darwin flake

Flakes are all the rage right now but they can be daunting to new users.

Here’s a simple nix-darwin flake to get you started, which also makes it easy to use home-manager:

flake.nix:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-23.11";
    nixpkgs-darwin.url = "github:NixOS/nixpkgs/nixpkgs-23.11-darwin";

    nix-darwin.url = "github:LnL7/nix-darwin/master";
    nix-darwin.inputs.nixpkgs.follows = "nixpkgs-darwin";

    home-manager.url = "github:nix-community/home-manager/release-23.11";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = { self, ... }@inputs:
    {
      darwinConfigurations."<hostname>" = inputs.nix-darwin.lib.darwinSystem {
        system = "aarch64-darwin";
        specialArgs = { inherit inputs self; };
        modules = [
          ./hosts/mac.nix
          inputs.home-manager.darwinModules.home-manager
          {
            home-manager.useGlobalPkgs = true;
            home-manager.useUserPackages = true;
          }
        ];
      };
    };
}

Where ./hosts/mac.nix would be your nix-darwin configuration file, with the previous snippets.

home-manager

Now, we can use home-manager in our configuration.

Here are some examples:

# Import existing home-manager configuration
imports = [ "${self}/profiles/home/zsh.nix" ];

# Required by home-manager.
users.users.john.home = "/Users/john";

home-manager.users.john = {
    programs = {
      zsh = {
        enable = true;
        autocd = true;
        defaultKeymap = "emacs";

        enableCompletion = true;
        enableVteIntegration = true;
        enableAutosuggestions = true;
        syntaxHighlighting.enable = true;

        history = {
          expireDuplicatesFirst = true;
          extended = true;
          ignoreDups = true;
        };
      };

      direnv = {
        enable = true;
        nix-direnv.enable = true;
      };

      dircolors.enable = true;
      fzf.enable = true;
      starship.enable = true;
      zoxide.enable = true;

      initExtra = ''
        # Enable iTerm2 shell integration.
        test -e "~/.iterm2_shell_integration.zsh" && source "~/.iterm2_shell_integration.zsh"
      '';
    };

  home.stateVersion = "23.11";
};

This allows you to consolidate your dispersed dotfiles into a single source of truth, the nix-darwin config file. To find options for other programs home-manager supports, I found the (unofficial?) home manager options search quite useful.

I believe you can also use the home.file options to write to arbitrary files in your home directory.

Closing remarks

This experience turned the macOS experience much more tolerable.

And it really is true: Apple Silicon is game-changing. Compared to the ThinkPads I was used to, the MacBook had a great screen (brightness, color and HiDPI, although I would skip the glossy finish), great speakers, was way faster, and didn’t heat up even though it’s passively cooled, which also means that there’s no fan noise.

I managed to buy this one used for 550€, which is probably the best deal for a laptop in mid-2024 for most people. But despite all of that, there’s a dealbreaker: the keyboard was starting to give me symptoms of RSI, just like this anecdote. My experience was pretty much the same and now that I’ve stopped using it, my hands feel much better. I really can’t justify using the laptop if that has implications on my physical health.

Also, even though I really tried, I didn’t find macOS window management very ergonomic. Full-screen apps being workspaces, the workspaces shuffling around chaotically (most recently used? but only if you click the app from the dock?), having to swipe around looking for what I wanted or always having to go to Mission Control. I found it really confusing, perhaps because I’m not the kind of user to always be using a single window at once.

I’m aware that there are tiling window managers for macOS, some that even work without disable System Integrity Protection, but by that point: why even use macOS if you’re not using like it was designed?

But if you dislike macOS but tolerate the keyboard, then an Apple Silicon Macbook is probably one of the greatest Linux laptops I’ve ever used, but I’ll leave that to a future blog post.

Finally, Apple has some questionable practices, although they’re mostly hardware-related instead of software-related, which I do prefer, if I had to pick my poison from the selection of behaviours of big tech companies. What I mean by this is that, until now, Apple’s software although proprietary, (seems to) respect user privacy, doesn’t fill available screen space with ads and doesn’t force updates on its users while they’re working.

The reason for this seems to be that Apple’s business model is selling expensive hardware, so they don’t need to monetize their software as much as other companies. This also means that, if you’re buying new, you’ll have to pay 200€ for 8GB RAM upgrade increments and 200€ for a 240GB SSD storage increment, because they’re both soldered in. You can avoid falling into the scam by only buying the base models, which will make the most out of your money, or by buying used. The problem is: I also found 8GB way too restricting, I’d really recommend going for 16GB minimum. I managed to make the experience a bit better by using Auto Tab Discard in Firefox but I still seemed to be under intense memory pressure all the time.

Besides that, I felt no need to buy anything more recent than the M1 MacBook Air. Not only that, it seems that the M1 MacBook Air is better than the M2 MacBook Air in some aspects, like having greater memory bandwidth and faster storage, because it has 2 NAND chips instead of just 1.

Bottom line is that despite Apple arguably running a hardware upgrade pricing scam, trying to lock you in to the walled garden/ecosystem and muffling down right to repair (while making their hardware harder to repair, especially by soldering in SSDs that do have a very finite lifespan), I find their laptops are really good, if you can tolerate the keyboards.

References

• https://gist.github.com/jmatsushita/5c50ef14b4b96cb24ae5268dab613050
• https://github.com/LnL7/nix-darwin
• https://daiderd.com/nix-darwin/manual/index.html#sec-options

But the one thing I really missed from Linux was the US altgr-intl variant keyboard layout, which simply is the US layout where you can make dead-keys (for diacritics and other special characters) by pressing the AltGr modifier beforehand.

Apple only includes the regular US International layout by default, which I find painful to use, as it requires double tapping the keys to actually output them instead of only being dead-keys when pressed with a modifier.

Some other people have also felt this, but I was always missing something with their solutions:

osx-us-altgr-intl was working fine for the most apart, until I found out that Ctrl chords weren’t working in emacs-macport (but were otherwise working perfectly fine in regular emacs). With Ukelele, I later found that the Ctrl layer was completely missing.

I also used altgr-weur for some time but my main gripe was that it makes my layouts inconsistent between Linux and macOS, which gets quite confusing.

Finally, I found this blog post with another attempt at altgr-intl for macOS. However, this version was missing some dead-key layers.

So I took this last one as a base and added the dead key layers from osx-us-altgr-intl and it’s working quite well.

Here’s the repo with the file so others don’t have to go through this as well.