A systemd service that won’t start is almost never mysterious. Run systemctl status <unit>, then read the last 50 journal lines for that unit with journalctl -u <unit> -n 50 --no-pager — between the two, one of five causes is usually named outright: a bad path, a missing binary, wrong permissions, an SELinux/AppArmor denial, or a unit file syntax error. The failure reason is in the log; the fixes below are just pattern matching against it.

How do I see why a systemd service failed?

Status first, journal second:

systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

status gives you the state (inactive (dead), failed (exit-code), activating (auto-restart)) and the last few log lines. The journal gives you the full story: stdout, stderr, and systemd’s own complaints about the unit.

If the unit failed before and you want the record of that run, add -b for the current boot or --since today:

journalctl -u myapp.service -b --no-pager

For the full toolkit — boots, priorities, following output live — see the journalctl cheat sheet. It’s the same muscle memory.

One more pair worth knowing:

systemctl list-units --failed
systemctl reset-failed myapp.service

The first lists every red unit on the box. The second clears the failed state after you’ve fixed it — cosmetic, but it stops status pages from crying wolf.

What are the most common causes?

After the log names the symptom, the cause is almost always one of these five:

The 203/EXEC family deserves a special mention because it’s the one that eats afternoons. Systemd does not use your shell to launch ExecStart=. That means:

# Wrong — no shell, ~ never expands, no PATH lookup
ExecStart=~/app/run.sh

# Right
ExecStart=/opt/app/run.sh

And the script itself must be executable and start with a real shebang (#!/bin/bash or #!/usr/bin/env bash). A script that runs fine from your terminal but fails with 203 under systemd is nearly always one of: not executable, CRLF endings, a shebang pointing nowhere, or a relative path.

Why does it start manually but not on boot?

The classic ordering bug. If the log shows failures right after boot but the unit starts fine when you systemctl start it by hand, your service is losing a race — it’s reaching for the network, a mounted disk, or a database before that thing exists.

The fix is to declare dependencies instead of hoping:

[Unit]
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
ExecStartPre=/usr/bin/test -f /opt/app/config.toml

After= orders the start; Wants= makes systemd actually bring the dependency up. network-online.target only works if the network-wait service is enabled on your distro, so check systemctl is-enabled NetworkManager-wait-online.service (or the systemd-networkd equivalent). The ExecStartPre= guard is a cheap, honest way to fail loudly with a readable message instead of a stack trace.

A second variant: the service starts on boot but immediately dies. Look for things your interactive environment had that boot doesn’t — PATH differences, a virtualenv, a HOME. Set what you need explicitly:

[Service]
Environment="PATH=/opt/app/venv/bin:/usr/bin"
User=appuser
WorkingDirectory=/opt/app

Why is my service not logging to the journal?

If journalctl -u shows nothing, check three things in order:

1. StandardOutput= and StandardError= in the unit — they must be journal (the default) or journal+console. Someone may have set them to null.
2. The app writes to a file instead of stdout. Systemd only captures stdout/stderr; log-file writers bypass the journal entirely. Either point the app at stdout or read the file.
3. Storage limits dropped old lines: journalctl --disk-usage, and SystemMaxUse= in /etc/systemd/journald.conf if the journal is choking.

For debugging the start itself, nothing beats dropping a shell into the boot-time context:

[Service]
ExecStart=/bin/bash -c 'exec /opt/app/bin/server 2>&1'

Or, for genuine mysteries, run the exact ExecStart= command as the unit’s user in a shell — most environment differences surface in the first ten seconds.

How do I make it restart automatically after a crash?

Default policy is Restart=no: a crashed service stays dead, and you find out from a user. Fix that per service:

[Service]
Restart=on-failure
RestartSec=5

Pair Restart=on-failure with a start-rate guard so a crashing loop doesn’t hammer the box: StartLimitIntervalSec= and StartLimitBurst= in the [Unit] section. Five failures in sixty seconds should page a human, not spin a CPU.

If you’re wiring this up as a scheduled job rather than a daemon, weigh cron vs systemd timer first — timers give you journal logging and dependency ordering for free, which is exactly what this article keeps reaching for.

The 60-second checklist

1. systemctl status <unit> — read the state and last lines.
2. journalctl -u <unit> -n 50 --no-pager — find the real error.
3. 203/EXEC? Fix path, shebang, permissions. Permission denied? Fix user and file ownership.
4. Fails only at boot? Add After=/Wants=network-online.target and an ExecStartPre= guard.
5. Change a unit file? systemctl daemon-reload && systemctl restart <unit>.
6. Add Restart=on-failure so the next crash announces itself instead of hiding.

Most “systemd is complicated” moments reduce to the error was in the journal the whole time. Read it before you edit the unit file, not after.

Pick Q4_K_M by default; go Q6_K or Q8_0 when you have VRAM to spare and need the last few percent of quality. GGUF quantization shrinks a model’s weights from 16 bits to fewer — Q4_K_M stores roughly 4.85 bits per weight, so a 7B model drops from ~14 GB to ~4.1 GB with perplexity typically less than 1% worse than the original. The question “which gguf quantization to use” has a boringly stable answer that most of the drama online obscures. Below: what quantization actually does to weights, how much quality each level costs, how to do the size math yourself, and one command to measure the damage on your own hardware instead of trusting a stranger’s benchmark.

What does GGUF quantization actually do?

A model is trained in 16-bit floating point (FP16 or BF16): every one of its billions of weights is a 2-byte number. Quantization compresses each weight into fewer bits. The naive way — round every weight to a 4-bit integer — destroys small-but-important values, so GGUF uses two tricks:

1. Block scaling. Weights are grouped into blocks (usually 32), and each block gets its own scale factor. The 4-bit values are offsets within that block, so a wide range of magnitudes survives.
2. Importance-aware k-quants. The “K” in Q4_K_M means super-blocks of scales, plus treating attention and feed-forward layers differently from each other, because they tolerate compression unequally.

The “I” family (IQ4_XS and friends) goes further with information-theoretic codebooks borrowed from image compression. Same idea, fancier encoding: fewer bits per weight at similar quality, at the cost of slightly slower inference on some backends.

One clarification that prevents most confusion: quantization changes only the stored weights. Architecture, tokenizer, and context handling are untouched. A Q4 file and a Q8 file of the same model are the same model, wearing different coats.

Q4 vs Q8: is higher quantization better?

Yes, technically; no, perceptually. Using llama.cpp’s own perplexity runs on Llama models as the reference: Q8_0 lands within ~0.02% of FP16 — for any practical purpose, lossless. Q6_K is near-indistinguishable. Q4_K_M gains roughly 1–2% perplexity, Q4_0 a bit more, and Q2_K is where coherent answers start falling apart on small models.

Two rules the numbers imply:

• Model size buys quantization headroom. A 70B model survives Q2/Q3 far better than a 7B model does, because larger models are more redundant. Quantizing a 7B to Q2 is amputation; quantizing a 70B to Q3 is tailoring.
• The quality floor moves with the task. Chat tolerates Q4. Exact code generation, math, and RAG over precise documents expose quantization noise sooner. If a Q4 model keeps writing subtly wrong code, test the same model at Q6_K before you blame the model.

How much VRAM does each level need?

Do the size math yourself instead of memorizing tables — it is one line:

size_GB ≈ (bits_per_weight × params) / 8
# 8B model @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B model @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Then add the parts the formula leaves out: the KV cache (grows with context length — a few hundred MB to multiple GB), activations, and compute buffers. Practical margin: a “4.9 GB” model wants a 6 GB card at 4k context, and flash-attention plus KV-cache quantization to stay there at 16k. Weights are the headline, not the whole bill.

Which GGUF quantization should you use?

Decision order, no exceptions worth memorizing:

1. Compute your context + KV budget first, then weights. Context you can’t fit is worse than quality you can’t measure.
2. Default to Q4_K_M. It is the community’s default for a reason — roughly 1% perplexity for 70% of the size. Every registry, including Ollama’s, ships it as the baseline.
3. Step up to Q6_K when the task punishes noise: code, math, extraction, anything you feed to a pipeline unattended.
4. Use Q8_0 only for reference — A/B tests, quantization-damage measurement, or a fine-tune base. As a daily driver it mostly buys warmth in your VRAM sensors.
5. Go below Q4 only under duress, and only on large models. Test with a known-hard prompt before trusting it.

If you are choosing which file to download on Hugging Face, prefer a single Q4_K_M.gguf over sharded splits unless the uploader only ships the latter — fewer moving parts. And if you are choosing where to run it, the engine choice is separate: see llama.cpp vs Ollama for that axis.

How do you measure quantization damage yourself?

Benchmarks differ; your prompt is constant. Build llama.cpp once, download two levels of the same model, and measure both perplexity (lower is better) and tokens/second:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity on a wiki-text chunk (lower = closer to the original model)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# and speed on the same hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

The Q4_K_M number will be a few hundredths of a point worse than Q8_0 and the file will be ~40% smaller. If your downstream task can’t tell the difference — and for most, it can’t — you have your answer without reading anyone’s leaderboard.

Does quantization hurt privacy or local-only claims?

No — it is arithmetic on weights, entirely offline, and the quantized file is just a smaller container of the same parameters. Running a Q4_K_M locally leaks exactly as much (or little) as running the full-precision model locally: nothing leaves the machine. The privacy-relevant variable is where inference runs, not the bit width. The usual caveats about model provenance apply equally to every quant level: a stolen-base “uncensored” fine-tune in Q8 is not safer than the same weights in Q4. For the file-format side of this, see how to run GGUF models locally.

Which level should you pick?

Q4_K_M, and stop reading forums about it. Upgrade to Q6_K for precision-hungry work if VRAM allows, keep one Q8_0 around for A/B comparisons, and treat anything under Q4 as an emergency ration for large models only. The one mistake worth avoiding is symmetric: worrying about Q4-vs-Q5 while ignoring context length, which wrecks more local setups than any quant ever did.

TL;DR: git cherry-pick <sha> copies one commit from any branch onto your current branch — same patch, new SHA, no history moved. For several commits, list SHAs or use a range (git cherry-pick A..B); note that range excludes A, so write A^..B to include it. If it stops on a conflict, resolve, git add, then git cherry-pick --continue. Cherry-picking is for moving a specific fix — when you want everything from the other branch, merge or rebase instead.

What does git cherry-pick actually do?

Cherry-pick takes an existing commit and applies its diff as a new commit on your current branch. The original commit stays where it is; the copy gets a fresh SHA. Git does not “move” anything — people who later wonder why the commit still shows on the old branch are seeing exactly this.

That copy-not-move model decides when cherry-pick is the right tool:

• You need one fix from a feature branch on main now, without merging the rest.
• A hotfix committed on the wrong branch needs to land on the right one.
• A patch must be replayed onto a release branch that never merges from main.

The complementary skill is knowing how to back out a commit that turned out to be wrong — the mechanics of that are covered in git undo last commit: keep the changes.

How do I cherry-pick a commit from another branch?

Find the SHA, switch to the target branch, pick:

# 1. Locate the commit on the source branch
git log feature/payment-fix --oneline -5

# 2. Switch to the branch that should receive it
git switch main

# 3. Copy it over
git cherry-pick 1a2b3c4

Two conveniences worth knowing:

• git cherry-pick <branch> picks that branch’s tip commit — handy, but easy to do by accident with a stale mental model of what “the tip” is.
• After the pick, git log -1 --stat confirms what landed. One second of reading, saves a revert.

The commits stay on feature/payment-fix; delete that branch whenever you like — the picked copy on main has its own SHA and no dependency on the old one.

How do I cherry-pick multiple commits?

Three shapes, in order of how often you want them:

# 1. Explicit list — picked in the order you list them
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Range — everything after A up to and including B
git cherry-pick A..B

# 3. Range including A
git cherry-pick A^..B

The A..B vs A^..B distinction is the classic surprise: A..B excludes A. If you visualize the range from git log and pick oldest..newest, you silently skip the oldest commit. When “the oldest few commits, in order” is the goal, write oldest^..newest and the off-by-one disappears.

To fold several picks into one commit instead of three, stage without committing using -n / --no-commit, then commit once:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

Why is git cherry-pick not working?

Four real causes, in order of frequency:

1. A conflict stopped the pick. Git applies the patch, hits a line that changed on both branches, and pauses mid-sequence:

# resolve the files, then:
git add <resolved-files>
git cherry-pick --continue   # or --abort to return to the pre-pick state

--continue is not optional and not implied — until you run it, you are inside a paused cherry-pick sequence and git status will keep saying so.

2. The pick is empty (“The previous cherry-pick is now empty”). The change already exists on this branch, often from an earlier pick or a squashed merge. Skip it with git cherry-pick --skip, or force an empty commit with --allow-empty if you genuinely need the marker.

3. The commit is a merge commit. A merge has two parents, so “apply this diff” is ambiguous — git refuses rather than guess. Say which parent you are diffing against:

git cherry-pick -m 1 <merge-sha>   # parent 1 = the branch you merged *into*

4. Wrong working tree or detached HEAD. The pick lands wherever HEAD points. git branch --show-current before picking; if it prints nothing, you are in detached HEAD and the commit will be orphaned when you switch away.

Cherry-pick vs merge vs rebase: which one when?

The one-line rule: cherry-pick moves a selection; merge and rebase move everything. Reaching for cherry-pick to “sync” with a branch is a sign you actually want a merge — and if the branch is your fork’s main versus upstream, the full routine is in sync a fork with upstream, step by step.

One habit to skip: cherry-picking the same commit into several branches long-term. Every future fix on the source branch needs another pick, and eventually the branches drift. Backports to release branches are a normal pattern; a permanent parallel universe is not.

The cherry-pick workflow, condensed

git log <source-branch> --oneline -5   # find the SHA(s)
git switch <target-branch>             # land in the right place
git cherry-pick A^..B                  # range, list, or single SHA
# on conflict: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # confirm what landed

Find, switch, pick, verify. The command has a reputation for danger it does not deserve — the diff either applies or it stops and tells you why. The only genuinely destructive mistake is picking into the wrong branch, and git log -1 before you push makes that one hard to miss.

On a modern distro, use a systemd timer for anything you own and keep cron for one-line user jobs and servers you did not set up yourself. Timers log every run to the journal, can catch up on schedules missed while the machine was off, and depend on the same unit files as everything else on the system. Cron wins on brevity — one crontab -e line beats two unit files — and it is still the only scheduler guaranteed to exist on minimal containers and exotic Unix boxes. The catch: cron fails silently. If your job errors at 3 a.m., cron mails a local mailbox nobody reads, while a timer gives you journalctl -u mytimer.service with the full output. Below: the real differences, how to test each one, why a timer might not trigger, and a decision table.

What is the difference between cron and a systemd timer?

Cron is a daemon that reads a table of lines — five time fields and a command — and runs each command when the wall clock matches. That is the whole model. It has no concept of a job as an object: no unit, no status, no dependencies, no log entry of its own.

A systemd timer is a unit file (foo.timer) that fires another unit file (foo.service) when its schedule matches. The job is a first-class object with start, status, logs, and failure tracking like any other service. Scheduling is either calendar-based (cron-like) or monotonic (OnBootSec=15min, which wall-clock changes cannot confuse).

The practical consequences:

• Logging: timers log stdout/stderr to the journal per unit; cron at best mails the local user.
• Missed runs: a timer with Persistent=true runs once on boot if its schedule was missed; cron just skips.
• Dependencies: timers can wait for network-online.target or mount points; cron needs you to hand-roll retry logic in the script.
• Syntax: cron is one line; a timer is two files. That is the entire cost of switching.

Which schedule syntax is easier — crontab or OnCalendar?

Cron’s five fields are the compact incumbent: */15 * * * * is every 15 minutes, and most admins can read them in their sleep. Systemd’s OnCalendar= is more verbose but strictly more expressive, and systemd-analyze calendar will tell you the next runs before you commit — cron has no equivalent dry-run.

# Cron: every day at 03:30
30 3 * * * /usr/local/bin/backup.sh

# systemd: the same schedule, verifiable before you save it
systemd-analyze calendar "*-*-* 03:30:00"
# -> Next elapse: Fri 2026-09-11 03:30:00 ...

OnCalendar handles things cron genuinely cannot express cleanly: Mon..Fri *-*-* 09..17:00:00 (weekdays, business hours), or *:0/15 with RandomizedDelaySec=10m to stop a thousand machines from hammering a server at the same instant.

How do I test a systemd timer without waiting?

Three commands answer everything. List what is scheduled and when it next fires, run the job by hand exactly as the timer would, then read its logs:

systemctl list-timers --all                 # every timer, next + last run
sudo systemctl start backup.service         # fire the job now, same unit as the timer
journalctl -u backup.service -f             # watch its output live

Note the split: systemctl start backup.timer arms the schedule; the service is the job. If list-timers shows your timer, systemctl status backup.service is green, and the journal shows your output, the whole chain works.

How do I run a cron job manually?

Cron jobs run with a stripped environment, which is why “works in my shell, fails in cron” is a genre of bug. To reproduce cron faithfully, run the command through sh with the same environment cron would use:

crontab -l                                  # confirm the exact line
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # did cron even fire it? (Debian/Ubuntu)
journalctl -u cron -n 20                    # same, on systemd distros

That env -i line is the honest manual test: a bare environment with cron’s default PATH. Most silent cron failures are a bare PATH or an unquoted % in the command (cron treats % as a newline), and both show up immediately this way.

Why is my systemd timer not triggering?

Four causes cover almost every case, in the order to check them:

1. Service and timer names do not match. foo.timer fires foo.service — a typo’d OnFailure or a renamed unit means the timer “runs” into nothing. systemctl cat foo.timer shows exactly what it targets.
2. The timer was edited but not reloaded. After changing a unit file: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Without this your new schedule is not live.
3. Persistent=true without OnCalendar semantics you expect — or you are checking systemctl status foo.timer (always shows active even when idle) instead of list-timers.
4. The service it fires is failing instantly, so the timer looks dead. journalctl -u foo.service --since -1h will show the crash that list-timers hides.

And when you do look at the logs, the journalctl cheat sheet covers the filters (-u, --since, -f) that make this fast.

Cron vs systemd timers: the decision table

Rules of thumb: shipping a job on your own systemd machine → timer. Quick personal reminder or a box you did not build → cron. Anything with dependencies, retries, or a need to know whether it actually ran → timer, always. A common pattern is a timer running a maintenance job — say a nightly rsync backup — where Persistent=true guarantees the backup happens even if the machine was asleep at the scheduled minute, which cron simply cannot offer.

Raw llama.cpp if you want maximum tokens/second and full control; Ollama if you want a one-command install and an API server that works out of the box. Ollama is not a competing engine — it is a Go service that bundles llama.cpp as its inference backend, adds model management (ollama pull llama3.1), and serves a REST API on port 11434. So the real question is not “which engine is faster” but “how much control do you want over that engine’s knobs”. Because Ollama ships conservative defaults (Q4_K_M quantization, modest context, no flash attention until recently), identical hardware can produce noticeably different numbers. Below: what actually differs, where the speed gap comes from, the same model running in both, and a decision table.

What is the difference between llama.cpp and Ollama?

llama.cpp is the inference engine: a single C/C++ project from GGUF creator Georgi Gerganov that runs quantized models on CPU, GPU, or a mix of both. It gives you llama-cli for one-shot prompts and llama-server — an OpenAI-compatible HTTP server — plus every tuning flag the engine supports: GPU layer offload, KV-cache quantization, speculative decoding, custom samplers.

Ollama is a product layered on top of that engine. It forks and vendors llama.cpp, then wraps it in:

• a model registry (ollama pull, ollama list) with automatic GGUF weight splitting,
• a Modelfile system (a Dockerfile-like spec for prompt templates and parameters),
• a background daemon that keeps models warm in VRAM and exposes its own REST API,
• automatic hardware detection with safe defaults.

The practical consequence: with Ollama you manage models; with llama.cpp you manage inference. If you have ever wanted to change the quantization format, quantize the KV cache, raise context past the default, or pin specific layers to the GPU, that is llama.cpp territory. Ollama hides most of those dials — deliberately.

Is llama.cpp faster than Ollama?

On the same GGUF file, same quantization, same context, and the same llama.cpp version — no, they are within noise of each other, because Ollama is llama.cpp doing the math. Every “Ollama is 30% slower” benchmark you see is really a comparison of defaults. The gap comes from three places:

1. Quantization choice. Ollama’s registry defaults to Q4_K_M. Run the same model as Q5_K_M or Q6_K from llama.cpp and you get better quality per token at a similar speed — or choose Q4_0/IQ4 for raw speed.
2. Flash attention and KV-cache quantization. --flash-attn plus -ctk q8_0 -ctv q8_0 shrinks the KV cache dramatically, which raises tokens/second at long context and lets you fit bigger contexts in the same VRAM. Ollama only exposes some of this.
3. Version lag. llama.cpp lands kernel optimizations weekly; Ollama merges upstream on its own schedule. A fresh llama.cpp build can be measurably faster than a months-old Ollama binary on the same box — until Ollama catches up.

Quick benchmark command, engine-agnostic — it reports prompt evaluation and generation speed:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Run it against Ollama’s own model file (~/.ollama/models/blobs/..., renamed to .gguf) and you will usually match Ollama’s numbers exactly — then beat them by adding -ctk q8_0 at 16k context.

How do you run the same model in both?

Both consume GGUF. Minimal end-to-end for each:

# --- Ollama path: install, pull, serve ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # downloads Q4_K_M, loads into VRAM, opens a chat

# its API, OpenAI-compatible style:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cpp path: build, download GGUF, serve ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # or -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server exposes the OpenAI Chat Completions schema, so the same curl against http://localhost:8080/v1/chat/completions works unchanged. Any tool built for the OpenAI API — scripts, editors, RAG pipelines — can point at either. The flags do the real work: -ngl 99 offloads every layer to the GPU, --flash-attn plus the -ctk/-ctv pair keeps a 16k context inside an 8 GB card that Ollama’s defaults would refuse.

For picking the GGUF file itself and what the quant labels mean, see how to run GGUF models locally.

When does Ollama make more sense?

Most people should start with Ollama, and that is not a consolation prize:

• You want it working tonight. One command, model pulled, API up. llama.cpp means choosing a backend (CUDA/Vulkan/HIP/Metal), building, and fetching weights by hand.
• You juggle many models. The registry, automatic unloading, and Modelfiles beat hand-managing directories of GGUF files.
• Your machine is modest. Ollama’s defaults are conservative for a reason — they almost always fit and run.
• You want a stable API surface. Ollama’s daemon manages model lifecycles so a long-running service does not have to.

Choose raw llama.cpp when you are benchmarking, serving at any scale, running on a phone or a Raspberry Pi, need long context on small VRAM, or want a feature the day it merges upstream. Power users often run both: Ollama for daily driver models, a pinned llama.cpp build for the one workload that needs the last 20%.

If your comparison is really between desktop GUI apps, that is a different axis — see Ollama vs LM Studio — and for engine choice per task, the best local LLMs for coding covers the model side.

Which should you use?

Decide by control, not speed. The engines are the same; the defaults are not. Install Ollama if “it runs and serves an API” is the goal — you lose a few knobs you were not going to turn anyway. Build llama.cpp if tokens/second, context length, or quantization control is the goal — you get every knob, at the cost of managing models yourself. Either way you are running the same GGUF files, and switching later costs an afternoon, not a rewrite.

TL;DR: to remove untracked files in git, run git clean -fd — but always preview with git clean -nd first, because clean deletes permanently and they never hit the trash. Use -f for files, -fd for files and directories, and -fdx if gitignored build output should go too. The single most common complaint — “git clean is not removing my untracked files” — almost always means the files live inside an untracked directory (add -d) or they are ignored files (add -x). Untracked clutter is the normal byproduct of experiments, builds and clone-adjacent scripts; this guide shows how to preview every deletion, remove files from one directory only, and which combinations to never run in a repo you care about.

What does “untracked files” mean in git status?

Untracked means git sees the file on disk but has never been told to track it — it is not in the index and has no commit history. git status groups everything into three buckets:

$ git status --short
 M src/app.ts        # modified: tracked, changed
?? notes.txt         # untracked: new file git doesn't know
?? build/            # untracked directory: entirely new to git

That distinction matters because each bucket needs a different removal tool. Tracked-but-changed files are reverted with git restore or committed away — git clean will not touch them. Only the ?? lines are git clean territory. Ignored files (anything matched by .gitignore) are a hidden fourth bucket: they do not even show as ??, and git clean skips them unless you explicitly opt in with -x.

If your real problem is a tracked file that should never have been committed, cleaning is the wrong tool — that is a git rm --cached job, or a reset of the last commit as covered in git undo last commit: keep the changes.

How do I remove untracked files in git?

The core command is git clean -f. Without -f git refuses to delete anything and just prints a warning — a deliberate safety rail. The full routine looks like this:

# 1. See exactly what will be deleted (dry run — deletes nothing)
git clean -nd

# Would remove:
# notes.txt
# build/
# scratch/

# 2. Confirm nothing precious is in the list, then delete for real
git clean -fd

Flag by flag:

• -f / --force — required. Actually deletes untracked files.
• -d — recurse into untracked directories. Plain -f only removes untracked files at the top level and reports the directories it refused to touch.
• -n / --dry-run — show what would be removed. Always run this first.
• -x — also delete ignored files (node_modules, build output, .env).
• -X — delete only ignored files, keeping untracked-but-not-ignored ones.
• -i — interactive mode; useful when the dry-run list is long.

A habit worth copying: treat git clean -nd like git diff — you look before you commit, you look before you clean.

Why is git clean not removing my untracked files?

Three real causes, in order of how often they bite:

1. The files are inside an untracked directory. With only -f, git removes loose untracked files but stops at directories, even reporting Would remove build/ without deleting it in a real run. Add -d:

git clean -fd

2. The files are gitignored. node_modules/, dist/, .venv/ — ignored paths are invisible to a plain clean. The dry run will not list them, and neither will the clean remove them. Opt in explicitly:

git clean -fdx   # untracked + ignored files and directories

3. A nested git repository or submodule is in the way. Git never deletes another repo’s contents from the outside. Remove the submodule properly or pass --force twice (git clean -ffd), and prefer the first option.

If the dry run lists nothing but git status still shows ?? entries, you are probably in the wrong working tree — run git rev-parse --show-toplevel and check you are inside the repo you meant to clean.

How do I remove untracked files from a specific directory only?

Scope the clean by passing a path — everything else is left alone:

git clean -fd build/          # only inside build/
git clean -fd src/generated   # one specific tree

This is the answer to “I want to remove untracked files and folders in build/ but keep my scratch notes in the repo root”. The path is relative to your current directory, so running from the repo root scopes to the whole repo; running from a subdirectory scopes to that subtree.

How do I remove untracked files without deleting them?

When the dry run shows files you might want later, do not gamble — preserve first, clean second:

# Stash untracked files (including ignored ones with -a) without deleting
git stash push --include-untracked
git clean -fd                      # tree is clean
git stash pop                      # bring them back when needed

git stash -u moves untracked files out of the tree but keeps them recoverable — that is the “remove without deleting” semantics people are actually looking for. For a preview you can keep, git clean -nd > clean-plan.txt gives you the exact list before committing to anything. There is no undo after git clean -f: deleted means gone.

git clean vs git rm vs git restore: which one when?

The one-line rule: clean manages what git doesn’t know about; rm and restore manage what it does. Mixing them up is how people lose work — running git clean -fdx while believing it behaves like git restore.

What should you never run git clean on?

Two habits to avoid outright:

1. Never run git clean -fdx blindly in a monorepo or workspace. It deletes every ignored directory — that is every node_modules, every virtualenv, every local .env in the tree. Regaining them can mean an hour of reinstallation, and a deleted .env may not be recoverable at all.
2. Never alias clean with force baked in. git config alias.wipe "clean -fd" feels efficient until you typo the path. Keep the dry run one keystroke away (git clean -nd) and make it a two-command ritual, preview then delete.

Also worth knowing: cleaning untracked files right before a [sync a fork with upstream] pull keeps the merge surface small — a tidy tree is the cheapest conflict insurance there is: sync a fork with upstream, step by step.

The safe git clean workflow, condensed

git status --short        # what's in the tree?
git clean -nd             # preview: what WOULD go?
git clean -fd             # delete untracked files + directories
git clean -fdX            # (optional) clear only ignored build output
git status --short        # confirm: working tree clean

Preview, delete, verify — thirty seconds, zero regret, and git status finally reads clean again.

Use rsync for anything bigger than a quick one-off copy, and scp when you just want a file on another box right now. The core difference: scp streams the whole file again every time and has no memory of a dropped connection, while rsync compares source and destination, transfers only the changed blocks, and resumes an interrupted copy where it stopped. On a large backup over a flaky link that is the gap between two minutes and starting over. Both ship with OpenSSH on virtually every Linux distribution, so this is a habit choice, not an install choice — and the habit should default to rsync. Below: a straight comparison table, real speed differences, the resume trick scp cannot do, and the cases where scp is still the right answer.

What is the difference between rsync and scp?

scp does one thing: open an SSH channel, stream the bytes, close. It has no state between runs, so if the transfer dies at 90% you restart from zero.

rsync is a synchronisation tool that happens to use SSH as its transport. Before sending, it builds a checksum list of the destination file (the rolling-checksum delta algorithm) and transmits only the blocks that differ. Run the same command twice and the second pass moves almost nothing. That also makes rsync the natural tool for keeping two directories in sync — schedule it and each run copies just the deltas.

The practical consequences:

• Interruptions: rsync resumes; scp restarts the file.
• Second copies: rsync sends only changes; scp re-sends everything.
• Deletions: rsync can mirror deletions with --delete; scp cannot.
• Filtering: rsync has --exclude patterns; scp copies everything you point at.
• Dry runs: rsync shows what it would do with --dry-run; scp offers nothing.

Is rsync faster than scp?

For a first-time copy of one large file over a fast link, they are close — both are saturating SSH, and the checksum pass adds only a small overhead. The gap opens in three places:

1. Small files in bulk. rsync pipelines directory walks and can reuse one connection; older scp setups spawned work per file. Thousands of little files (a node_modules, a WordPress install) finish noticeably faster with rsync.
2. Re-runs. Copy a 4 GB file where 50 MB changed and rsync moves roughly 50 MB; scp moves 4 GB again.
3. Compression. -z compresses in flight, which helps on slow WAN links.

You can time both yourself — the command is identical in shape:

# same file, same server, both over SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# re-run both: scp re-copies, rsync verifies and sends ~nothing
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

If you spend your day in servers, transfer speed is one of those things worth measuring once — the same way ss beats netstat on busy hosts (see ss vs netstat: which Linux port command to use).

Can scp resume an interrupted transfer?

No. scp has no resume; if the connection drops at 900 MB of 1 GB, you start again. This is the single most quoted reason in every rsync-vs-scp debate, and it is real.

rsync’s whole design assumes the transfer will be interrupted sometimes. The canonical resume incantation:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial keeps the half-written file instead of deleting it.
• --append-verify resumes by appending, then checksum-verifies the appended region — safe against a corrupt partial file, unlike the old plain --append.
• --progress shows you where it picked up.

Wrapped in a retry loop, this is a set-and-forget backup over even a hostile connection:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

When should you use scp instead of rsync?

scp is still the right tool in a handful of cases:

• One small file, once. Typing scp app.conf user@host:/etc/myapp/ is shorter than any rsync invocation, and there is nothing to resume.
• rsync is missing on the far end. rsync needs its binary on both sides. Many minimal containers and appliances ship scp’s SFTP server but not rsync.
• You don’t want an rsync server exposed. Rare, but some environments lock down the rsync daemon specifically.

One subtlety worth knowing: the OpenSSH project deprecated scp’s original protocol years ago, and modern scp actually speaks SFTP underneath. That fixed a path-escaping quirk, but it changed nothing about the two limitations that matter here — no resume, no delta transfer. The protocol change does not make scp rsync.

Also related: if your question is really “rsync vs cp”, the answer mirrors this one — cp is the local-only equivalent of scp (no resume, no delta, no attributes unless you add flags), and rsync works for both local and remote. For local one-shots, cp is fine.

Which rsync flags matter most?

Most people only ever need one line:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Two habits worth adopting. First, dry-run anything with --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # review
rsync -avh --delete src/ user@server:/srv/dest/             # then commit

Second, mind the trailing slash — /srv/src copies the directory itself into the destination, while /srv/src/ copies its contents. This trips up everyone once; rsync even warns “no bytes transferred” when you meant the other form.

For a daily or weekly sync, drop rsync into a systemd timer and let it copy only the deltas — the journalctl side of scheduling is covered in the journalctl cheat sheet.

Rsync vs scp: the verdict

Default to rsync for backups, big trees, anything over a link that can drop, and anything you will run more than once. Use scp when the command is shorter than the thought. If you take one flag away, take --partial — it converts every future dropped connection from a restart into a pause.

Downloaded a .gguf file and wondering how to actually run it? Fastest path: ollama run hf.co/<repo>:Q4_K_M — Ollama pulls the GGUF straight from Hugging Face and serves it. GGUF is the single-file model format that llama.cpp introduced and every local-LLM tool now speaks, so the same file runs in Ollama, llama.cpp, LM Studio, Jan, and (with caveats) vLLM. This guide covers each runner with copy-paste commands, how to pick the right quantisation for your VRAM, and the load errors you will actually hit.

What is a GGUF file?

GGUF (GGML Universal File) is a container format for quantised language models. One file holds the weights, the tokenizer, and the model metadata — nothing else to download, no config soup. The weights inside are quantised: compressed from 16-bit floats down to 4-bit (or lower) integers, which is why a 9B model that needs ~18 GB in full precision fits in ~5.5 GB as a Q4 file and runs on a gaming GPU or even a CPU.

Two things matter about a GGUF file’s name:

1. The base model — gemma-3-4b-it-GGUF is a fine-tuned Gemma 3 4B exported to GGUF.
2. The quant tag — Q4_K_M, Q8_0, IQ4_XS, and friends say how aggressively the weights were compressed. More on picking one below.

Can Ollama run GGUF models?

Yes — GGUF is Ollama’s native format, and since 2024 it can pull one straight off Hugging Face without you ever touching a file:

# Pull a GGUF quant directly from Hugging Face and chat with it
ollama run hf.co/bartowski/gemma-2-9b-it-GGUF:Q4_K_M

# The quant tag after the colon picks the file inside the repo
ollama run hf.co/ggml-org/gemma-3-4b-it-GGUF:Q8_0

Already downloaded a .gguf file yourself? Point a Modelfile at it:

# Modelfile — one line is enough
FROM ./gemma-2-9b-it-Q4_K_M.gguf

ollama create gemma9b -f Modelfile
ollama run gemma9b

Ollama decides GPU offload automatically and exposes an OpenAI-compatible API on port 11434, so anything that speaks that API can use the model. The trade-off is control: you do not choose how many layers go to the GPU.

How do you run a GGUF file in llama.cpp?

llama.cpp is where GGUF comes from — the format exists for it — so support is deepest and freshest. The llama-server binary gives you both a chat UI and an OpenAI-compatible endpoint:

# Download straight from Hugging Face (picks a matching GGUF for your machine)
llama-server -hf ggml-org/gemma-3-4b-it-GGUF --port 8080

# Or run a file you already have, with full GPU offload
llama-server -m ./gemma-2-9b-it-Q4_K_M.gguf -ngl 99 --port 8080

-ngl 99 pushes 99 layers onto the GPU; set it lower than your VRAM allows and the rest stays on CPU. That partial-offload dial is llama.cpp’s superpower — a 9B model runs fine on a 6 GB card with 20 of 48 layers offloaded, just slower. For one-shot prompting instead of a server, swap llama-server for llama-cli with the same -m flag.

LM Studio is the same engine behind a desktop GUI: drop a .gguf file into its models folder (or search Hugging Face in-app) and click load. For the tooling choice itself, the Ollama vs LM Studio comparison covers which one to put underneath your models.

Which GGUF quantisation should you download?

Default answer: Q4_K_M. It is the community sweet spot — within a percent or two of full-precision quality at roughly a quarter of the size. The ladder, largest to smallest:

• Q8_0 — near-lossless; use it if your VRAM eats 8.5 bits per weight without noticing.
• Q6_K / Q5_K_M — a step down in size, still excellent for 30B+ models.
• Q4_K_M — the default. For 7–14B models this is where quality-per-GB peaks.
• IQ4_XS / Q3_K_M — for squeezing a big model onto a small card; quality loss becomes noticeable.
• Q2_K and below — last resort; the model starts degrading into nonsense mid-sentence.

The rule of thumb for fitting: file size in GB plus ~1–2 GB of context overhead should fit in your VRAM. A 4.7 GB Q4_K_M of a 9B model is comfortable on an 8 GB card. Prefer a smaller model at a higher quant over a bigger model at a terrible quant — a Q8 4B usually beats a Q2 9B.

GGUF vs Safetensors: which format do you need?

Safetensors is the unquantised archive format — full-precision weights for training, fine-tuning, and tools like transformers and ComfyUI. GGUF is the quantised, runnable format for inference on your own hardware. You cannot fine-tune a GGUF, and you cannot run a safetensors file in Ollama or llama.cpp without converting it first (that is what the convert_hf_to_gguf.py script in llama.cpp is for). Rule: training or image pipelines → safetensors; local chat and serving → GGUF. If your search started as “gguf vs safetensors”, that split is the whole answer.

Which GGUF runner should you use?

Pick Ollama if you want it running at boot and out of sight — it is what I use on my homelab to serve models to everything on the network. Pick llama.cpp when you need a feature the day it ships (new architectures land there first) or want layer-level memory control. Pick LM Studio for a GUI. Pick vLLM only when one model must serve many concurrent users — its GGUF support works but is second-class next to its native formats.

Why won’t my GGUF model load?

The four errors that cover most cases:

1. unknown model architecture — the GGUF uses an architecture your runtime predates (new MoE and vision models land constantly). Update Ollama or rebuild llama.cpp; no other fix exists.
2. Out of memory at load — the quant is too big for your VRAM plus context. Drop one rung (Q4_K_M → Q3_K_M), lower -ngl, or shrink context with -c 4096.
3. Download truncated / corrupt — GGUF load fails with a magic-number or metadata error. Re-download and compare the SHA256 shown on the Hugging Face page.
4. ollama run ./model.gguf refuses — expected: Ollama’s run takes model names, not file paths. Use the Modelfile route shown above.

One last angle worth knowing: a local GGUF endpoint pairs well with agentic coding tools — point an OpenAI-compatible client at it and completions cost only electricity. The best local LLMs for coding tested which models deserve the slot once the plumbing in this guide works.

TL;DR: run git fetch upstream && git merge upstream/main && git push origin main and your fork is caught up. That is the whole “git sync fork with upstream” workflow in one line — pull changes from the project you forked, then push them to your copy. If you prefer linear history, swap merge for git rebase upstream/main and force-push. And if you have never wired up the upstream remote at all, start with step 1 below, because that missing remote is the number-one reason a fork “won’t sync”. Everything else — rebasing, the GitHub sync button, unpushable diverged branches — is detail on top of those three commands.

What does it mean to sync a fork with upstream?

A fork is your copy of someone else’s repository on GitHub. The original is the upstream; your copy is the origin. GitHub forks do not update themselves — when the maintainers merge a pull request, your copy keeps yesterday’s code. Syncing a fork means pulling the upstream’s new commits into your fork so your branch matches, or at least contains, the current state of the project.

This matters for two reasons. First, contributions: every pull request you open from a stale fork carries extra noise, and maintainers will ask you to update before merging. Second, self-hosting or studying: if you run a fork in production or just read the code, a month-old fork is a month of bug fixes you do not have.

How do I sync a fork with upstream from the command line?

Three steps: declare the upstream once, fetch from it, then merge and push. The wiring is permanent — steps 2 and 3 are all you type next time.

Step 1 — add the upstream remote (one time per clone).

# inside your local clone of the fork
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # confirm: origin -> your fork, upstream -> the original

Find the correct URL on the original repo’s page: the green Code button. A common mistake is pointing both remotes at your fork — then a “sync” quietly does nothing, because you fetched from a copy that was just as stale as the one you have.

Step 2 — fetch and merge the upstream branch.

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

That is the standard answer to “git sync fork with upstream command line”. A fast-forward is the normal outcome — main on your fork had nothing new, so it simply slides forward to upstream/main and no merge commit is created.

Step 3 — repeat on demand. There is nothing to remember beyond git fetch upstream && git merge upstream/main && git push origin main. To see how far behind you are before merging, run git rev-list --count main..upstream/main after the fetch.

Should I rebase or merge when syncing a fork?

Both land the same code in your fork; they differ in the history they leave behind. Pick one policy per repo and stick to it:

The rebase variant of the sync:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

The force push is required because rebasing rewrites commit IDs — your fork’s remote branch no longer descends from your local one. Always prefer --force-with-lease over --force: it refuses to overwrite the remote if someone (or another machine of yours) pushed in the meantime, which makes the dangerous command safe by default.

One rule worth tattooing on your wrist: never rebase a branch that has an open pull request unless you know what you are doing — rebasing changes commit IDs, which can detach an open PR from its commits. Sync main with merge (or rebase it before starting new work), and keep PR branches out of it.

Why is my fork not syncing with upstream?

The four usual suspects, in the order they appear in real terminals:

1. No upstream remote — git remote -v shows only origin. Symptom: git fetch upstream fails with 'upstream' does not appear to be a git repository. Fix: step 1 above.
2. You fetched but never merged — fetching updates upstream/main in your local repo but touches no working branch. Symptom: git log looks old after a successful fetch. Fix: git merge upstream/main.
3. Diverged history — you committed to your fork’s main, and upstream moved too. git pull then complains about unrelated histories or forces a merge. Fix, if you want upstream to win: git reset --hard upstream/main (throws away your local main-only commits — check git stash list or back up with a branch first; if a bad reset already happened, the recovery path is the same as in git undo last commit: git reflog still knows the old tip).
4. Push rejected as non-fast-forward after a rebase — you rebased but pushed normally. Fix: git push --force-with-lease origin main.

A fifth, rare case: the upstream repo was renamed or deleted, so even step 1’s URL 404s. GitHub redirects renamed repos, so a hard failure usually means deleted or made private — nothing to sync to.

Can you sync a fork from the GitHub website?

Yes. On your fork’s page, the branch dropdown shows a Sync fork button whenever your branch is behind; one click pulls upstream in. Below the fold, the same thing works as a pull request: open a PR from upstream/main into your fork’s main and merge it.

The button’s limits explain when to fall back to the CLI: it only does a fast-forward or merge — it will not rebase, and it refuses outright when the branches have diverged, telling you to discard commits or use the command line. It also syncs only the default branch. For everything past a simple catch-up, the three commands above are the tool.

How often should you sync your fork?

Before every new piece of work is the honest answer: branch off a fresh main, and no PR you open starts with “this is based on a version from three weeks ago”. For forks you actively contribute to, a daily or per-session sync of main costs seconds. For a fork you only read or deploy, sync when upstream ships something you want — subscribe to the original repo’s releases feed and sync on release. Syncing is cheap precisely because it is routine; a fork six months behind often needs surgery instead of a merge, which is how “sync my fork” turns into an afternoon.

Cheat sheet

# one-time setup
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# routine sync (merge policy)
git fetch upstream && git merge upstream/main && git push origin main

# routine sync (rebase policy, linear history)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# how far behind am I?
git fetch upstream && git rev-list --count main..upstream/main

# diverged beyond repair — make main identical to upstream (destructive)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Keep the routine two-liner in your muscle memory and the diverged fork stays a curiosity you read about, not a problem you fix. If your git housekeeping extends to servers, the journalctl cheat sheet covers the other half of keeping a machine’s history readable.

Use ss — it is the current standard on every modern Linux distro, and netstat is legacy there. On Ubuntu, Fedora, and Debian the netstat binary now ships in an optional net-tools package, while ss is built into iproute2 and installed everywhere. ss is also faster on busy servers because it reads socket statistics directly from the kernel instead of walking _/proc_ file by file. The catch is syntax: -tulpn does not mean the same thing everywhere, so this guide gives you the exact flag mapping, the commands worth memorising, and answers to the questions that come up when you are mid-incident at 2 a.m.

Is netstat deprecated?

On Linux, effectively yes. The net-tools package — which contains netstat, ifconfig, and route — has not tracked modern kernel features for years and is no longer installed by default on any major distribution. It still exists, still runs, and there is nothing to uninstall, but new features land only in iproute2 (the package behind ss and ip).

Three practical consequences:

1. Missing on fresh installs. A default Ubuntu 24.04 or Fedora server has no netstat until you install net-tools by hand. This is why so many people search for the netstat equivalent — the binary is simply gone.
2. No modern socket info. netstat predates features like TCP fast open, subflow-level socket stats, and cgroup socket attribution. ss reports them natively.
3. The Windows exception. On Windows, netstat is alive and well — netstat -ano is still the standard way to map a PID to a listening port there. Only the Linux story is deprecation.

What is the ss command in Linux?

ss means “socket statistics”. It dumps the kernel’s view of every TCP, UDP, and Unix socket: state, addresses, ports, processes, timers, and queue depths. The workhorse form is:

# Everything listening, with the owning process
sudo ss -tulpn

Flag by flag, that reads: TCP (-t), UDP (-u), listening sockets only (-l), show processes (-p), numeric output — no DNS lookups (-n). The sudo matters for -p: without root you see ports but get no process names for sockets you do not own.

Two more one-liners that cover most of the job:

# All established connections to/from port 443, with processes
sudo ss -tnp 'sport = :443 or dport = :443'

# Summary table: how many sockets in each state
ss -s

That filter syntax is a genuine upgrade over netstat’s grep-and-pray approach — it runs inside the kernel, so it is exact rather than text-matched.

How do you check which process is using a port?

This is the single most common reason to reach for either tool. With ss:

sudo ss -ltnp 'sport = :8080'

Example output on a machine running a dev server:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

The users:(...) field gives you the process name and PID directly — no second command needed. If the port is busy but no process shows, you are usually looking at a socket held by another network namespace (a container). From the host, run sudo ss -ltnp and look for the port with an empty process column, then match it with docker ps or nsenter into the container’s namespace.

Prefer a dedicated tool? sudo lsof -i :8080 -sTCP:LISTEN does the same job and works identically on macOS and most BSDs, which is why it survives in runbooks. On Linux, though, ss is already there.

What are the differences between ss and netstat?

Same job, different plumbing: netstat scrapes _proc/net/tcp_ in userspace, while ss uses netlink to ask the kernel directly — which is why ss returns in milliseconds on a server with 50k open sockets and netstat does not. Day to day, the difference is the flags. Here is the mapping worth taping to your monitor:

Notice the first two rows are identical: by luck, ss’s short flags line up with netstat’s for the common cases, so muscle memory mostly survives the move. The bottom rows are where netstat has no answer — the routing and interface jobs moved to the ip command, and the summary/filter rows only exist in ss.

When should you still use netstat?

Two honest cases. First, portability: on a mixed fleet of Linux, AIX, or older BSD boxes, netstat is the one syntax present everywhere. Second, muscle-memory continuity in old runbooks — if a runbook says netstat -tlpn and the box has net-tools installed, it still works fine.

Otherwise, default to ss and update the runbook. A useful companion when you are rewriting those runbooks on a server is the journalctl cheat sheet, which pairs naturally with port checks when you are diagnosing a service that will not start: /en/blog/2026-09-02/journalctl-cheat-sheet.

Why is the ss command not found?

Because you are either on a very old distro (pre-2007-era, before iproute2 was standard) or — far more likely — you are not on Linux at all. ss is not a macOS command; macOS ships lsof and netstat but no ss. Same for the BSDs, mostly. On Windows, use netstat -ano or PowerShell’s Get-NetTCPConnection.

If you genuinely are on Linux and ss is missing, install iproute2:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

The 30-second answer

ss over netstat on Linux, every time: it is preinstalled, faster, and can filter in-kernel. netstat -tlpn becomes ss -tlpn, process hunting becomes sudo ss -ltnp 'sport = :PORT', and routing tables belong to ip route now. Keep netstat for cross-platform scripts and old muscle memory; keep this page for the flag mapping.

The best local LLM for coding right now is Qwen3 Coder 30B A3B on a 24 GB card, Qwen2.5 Coder 14B at Q4 on 12–16 GB, and Qwen2.5 Coder 7B at Q4 on 8 GB. Every one of these runs fully offline, autocompletes and refactors real code, and costs nothing per token. If your GPU has less VRAM than the model needs, drop the quant one notch before you drop the model size. This guide matches models to VRAM brackets, compares the two coding families people actually argue about, and ends with runnable commands so you can be generating code locally in about five minutes.

Which local LLM should you use for coding on your GPU?

Pick by VRAM first, model second — the model only fits if the weights plus context fit in memory. This is the shortlist that keeps coming out on top in 2026 community benchmarks and day-to-day use:

Two rules make this table work in practice:

1. Leave 1–2 GB of VRAM headroom for the KV cache. A 14B model at Q4 plus an 8K-token context will not fit in a 10 GB budget — context counts toward the total.
2. Go one quant down before you go a model size down. Q5/Q4 quants cost a few percent of quality; a 7B model instead of a 14B costs far more than that.

How much VRAM do you need for a local coding LLM?

The honest rule of thumb: VRAM needed ≈ quantised weights + 0.125 GB per 1K tokens of context at 8-bit KV cache. In plain numbers:

• 8 GB runs 7B–8B models at Q4 comfortably. Expect autocomplete-length answers, 4K–8K context.
• 12 GB is the sweet spot for 14B at Q4 — enough room for the model plus a realistic 8K–16K coding context.
• 16 GB opens 20B-class dense models and Qwen3 14B with longer context.
• 24 GB runs the Qwen3 Coder 30B A3B MoE at Q4, which is the closest thing to a cloud-quality coding model you can host yourself.

CPU-only? It works — llama.cpp will happily run a 7B Q4 on a laptop CPU at 5–10 tok/s — but treat it as a patience exercise, not a daily driver. For the tooling side of getting a runtime installed, the Ollama vs LM Studio comparison covers which local LLM tool to put underneath your models.

Qwen3 Coder vs DeepSeek: which is better for coding?

This is the matchup the autocomplete bars actually ask about, and the answer splits cleanly:

• Qwen3 Coder (30B A3B) is built for the edit loop: it follows instruction-format conventions for tool calling, produces consistent diffs, and — the decisive part — the MoE design means only ~3B parameters activate per token, so a single 24 GB card gets 40–60 tok/s. For IDE-style use, responsiveness is quality.
• DeepSeek V3/R1 line argues at a higher level: architecture decisions, tricky algorithms, multi-step reasoning. But the flagship is 600B+ parameters; locally you only run it heavily quantised on multi-GPU or Mac unified-memory rigs, and it writes prose about code faster than it writes code.

Local choice: Qwen3 Coder for the daily driver, DeepSeek only if you have the hardware to host it near-full-precision. At 8–16 GB the debate is moot — Qwen2.5/3 Coder models are the strongest thing that fits.

How do you run the best local LLM for coding with Ollama?

Five commands, from nothing to an OpenAI-compatible API your editor can use:

# 1. Install Ollama (Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Pull the model that fits your VRAM bracket (8 GB card shown)
ollama pull qwen2.5-coder:7b

# 3. Chat with it interactively
ollama run qwen2.5-coder:7b

# 4. Use it as an OpenAI-compatible API from any tool
curl http://localhost:11434/v1/chat/completions 
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [{"role": "user", "content": "Refactor this fn to be async: add(a,b){return a+b}"}]
  }'

# 5. Point tools that expect OPENAI_BASE_URL at it
export OPENAI_BASE_URL=http://localhost:11434/v1

No API key, no rate limit, no per-token bill. On Linux the installer registers a systemd unit, so if the server ever misbehaves, journalctl tells you why — the journalctl cheat sheet has the exact filters for service debugging.

Is a local LLM good enough for real coding work?

Yes for the edit loop, no for the hard problems — and that split is exactly how you should use it. A 14B–30B local model handles refactors, boilerplate, test scaffolding, regex, and “explain this legacy function” faster than most cloud APIs round-trip. Where it loses to the big hosted models is long multi-file reasoning and obscure framework trivia — a 30B model simply knows less than a frontier model.

The workflow that works: keep a local model running for 90% of your keystrokes, and reach for a hosted frontier model only for the gnarly design questions. Your code never leaves the machine for routine work, which matters for client code, and the VRAM you already own quietly replaces a subscription.

TL;DR: to undo the last commit but keep the changes, run git reset --soft HEAD~1 (changes stay staged) or git reset HEAD~1 (changes stay in your working tree). If the commit is already pushed, run git revert HEAD instead — it creates a new commit that undoes it without rewriting history. Those three commands cover almost every “I committed too early” moment. The rest of this guide walks through each case with copy-paste commands, explains the difference between --soft, --mixed and --hard, and shows how to recover if something goes wrong. Every command below works on any recent Git install on Linux, macOS or Windows.

How do I undo the last commit but keep the changes?

The most common situation: you committed, then spotted a typo, a missing file, or realised the change belongs in a different commit. Nothing is pushed yet. Undo the commit and put everything back where it was:

# Commit stays in history nowhere — changes go back to the staging area
git reset --soft HEAD~1

# Changes go back to the working tree (unstaged) instead
git reset HEAD~1

HEAD~1 means “one commit before where HEAD points now”. After either command your files are untouched on disk — only the branch pointer moved. Check it with git status: with --soft the changes are staged, ready to re-commit with fixes folded in; without a flag they are unstaged, so you can edit freely first.

A safer habit when you just want to add files to the last commit is not to undo it at all:

git add forgotten-file.txt
git commit --amend --no-edit

--amend replaces the last commit in place (no commit message change here). Note that amending a pushed commit rewrites history — more on that below.

What is the difference between —soft, —mixed and —hard?

This is the part worth memorising, because the flag decides where your changes end up — and whether they can be lost:

--hard is the only dangerous one: it discards the commit and the changes. Before any reset --hard, stash or branch what you have:

git branch backup-before-reset   # cheap insurance
git reset --hard HEAD~1          # commit + changes gone

If you already ran the dangerous version, all is not lost — git reflog remembers where HEAD has been:

git reflog                       # find the commit hash you lost
git reset --hard HEAD@{1}        # or: git reset --hard <hash>

The reflog keeps dangling commits for around 90 days by default, so “I hard-reset by mistake” is almost always recoverable if you act before garbage collection.

What if I already pushed the commit?

If the commit is on a shared branch (anything other than your own feature branch), do not rewrite history. Use git revert, which computes the opposite change and commits it:

git revert HEAD
git push

Everyone who pulls simply gets a new commit that removes the old one’s changes. No force-push, no broken colleagues. If you need to undo a run of commits, revert a range: git revert --no-commit HEAD~3..HEAD && git commit.

The alternative — git reset --hard HEAD~1 && git push --force-with-lease — is only acceptable on a branch nobody else builds on, and --force-with-lease (never plain --force) is the only safe form because it refuses if someone pushed in the meantime. Force-pushing shared branches is how teams lose commits and CI logs mysteriously stop matching anyone’s checkout.

How do I undo the last commit but keep it around for later?

Sometimes the commit is good work at the wrong address — on the wrong branch, or too early. Instead of undoing it, move it:

git branch stash-commit          # park the commit on a new branch
git reset --hard HEAD~1          # then clean your current branch

Or take just the commit to another branch without touching your current one:

git cherry-pick <hash>           # while on the target branch

Between reset --soft, cherry-pick and revert, there is no commit you cannot relocate or nullify — the trick is choosing “move” versus “undo” before reaching for a flag.

Which undo should I use? A quick decision guide

1. Not pushed, want to fix and re-commit → git reset --soft HEAD~1
2. Not pushed, want to re-stage selectively → git reset HEAD~1 (mixed)
3. Want the changes gone completely → git reset --hard HEAD~1 (reflog knows, if you regret it)
4. Already pushed to a shared branch → git revert HEAD
5. Commit belongs on another branch → cherry-pick, don’t undo

One last operational tip: if a bad commit did make it to a server — a botched deploy hook, a CI runner misbehaving after a force-push — the next place to look is the machine’s logs, not Git. On any systemd box, journalctl -u <service> -n 100 shows you exactly what ran and when; our journalctl cheat sheet has the copy-paste patterns. And if your workflow includes local LLM tooling to review diffs, we compared the two main options in Ollama vs LM Studio.

journalctl in one line: journalctl -u <service> -f follows a live service log, journalctl -u <service> -n 100 shows the last 100 lines, and journalctl --since "1 hour ago" shows everything recent. That covers 90% of the “why is this service down” moments. The rest of this cheat sheet is the copy-paste patterns that save you from re-reading the man page at 2am — filtering by unit, time, priority and boot, plus the cleanup commands that stop a journal from eating your disk. Every command below runs as-is on any systemd distro (Ubuntu, Debian, Fedora, Arch).

What is journalctl and why not just read /var/log/syslog?

Old-school Linux logging wrote plain text files under /var/log — syslog, auth.log, messages. systemd replaced that with the journal: a binary, indexed log managed by systemd-journald. Plain grep cannot read it; journalctl is the only front door, and in exchange you get filtering by service, time, boot and severity without regex gymnastics.

The mental model is simple: the journal stores everything, and journalctl is the query tool. A service does not need its own log file — anything it writes to stdout/stderr while running under systemd lands in the journal automatically. That is why journalctl -u nginx works even when you have no idea where nginx configured its error log.

One caveat: on some minimal installs the journal is volatile (stored in /run, wiped on reboot) because /var/log/journal does not exist. Fix it once:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

How do I see the last 100 lines of a log?

-n limits output to the newest N lines (default is 10):

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

--no-pager matters more than it looks: without it journalctl opens less and your script, pipe or ssh one-liner hangs waiting for a keypress. Any command you pipe onward should carry it.

How do I follow logs live, like tail -f?

The -f flag is journalctl’s tail -f — it streams new entries as they happen:

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

This is the command to run in a second terminal while you restart a service in the first one: systemctl restart nginx in one pane, journalctl -u nginx -f in the other, and the cause of the crash usually announces itself within seconds. I run this exact loop on my homelab every time a container or service misbehaves.

How do I show logs for a specific service?

-u filters by systemd unit:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # the exact-match alternative

Units can spawn helper units that keep the interesting output — a failing web app sometimes logs the real error under a different unit. If -u <service> shows nothing but the service clearly runs, find the actual unit name first:

systemctl list-units --type=service | grep -i <guess>

The same -u pattern works for timers (systemctl list-timers shows names) and user services — for anything running under systemd --user add --user:

journalctl --user -u pipewire -n 50

How do I filter logs by time?

--since and --until take timestamps, but they also accept forgiving relative phrasing:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Pair a time window with a unit and you have incident triage in one line: “what did the API log between 09:00 and when it fell over?” That is faster than any log aggregator for a single box.

How do I show only errors (or warnings)?

-p filters by priority, using syslog severity names:

journalctl -p err -b              # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

Priorities in descending order: emerg, alert, crit, err, warning, notice, info, debug. When a box is “acting weird”, journalctl -p err -b --since today is the fastest sanity check — it answers “is anything actually failing?” without noise from routine info lines.

How do I see logs from the previous boot?

Services that crash at startup produce log lines before your current boot, and journalctl silently shows only the current one. -b selects boots:

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

This is the single most useful flag for “it broke and I rebooted it and now I can’t see the error” — the error is still there, one boot back.

Quick reference: the flags worth memorising

How do I stop the journal filling my disk?

Check what it costs, then cap it:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

To make a cap permanent, set SystemMaxUse=500M under the [Journal] section in /etc/systemd/journald.conf, then sudo systemctl restart systemd-journald. Between the size cap and the boot filter above, the journal stays a tool rather than a slow disk leak.

journalctl vs dmesg vs /var/log — which do I check first?

• journalctl — application and service behaviour. Anything systemd manages is here, indexed and filterable. Default first stop.
• journalctl -k / dmesg — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• /var/log/<app>/ — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

The same workflow extends to local AI services — when an ollama serve unit stalls, journalctl -u ollama -n 100 shows the model load failure immediately, as covered in the Ollama vs LM Studio comparison.

That is the whole cheat sheet: -u for unit, -f to follow, -n for lines, --since for time, -p for severity, -b for boots. Six flags cover nearly every log question a Linux box will ask you.

Ollama vs LM Studio in one line: pick LM Studio if you want a desktop GUI to browse and chat with models; pick Ollama if you want a lightweight, scriptable local API server. Both are free, both run GGUF models on your own GPU or CPU, and both can serve an OpenAI-compatible endpoint — so many developers install both and use them for different jobs. This guide compares setup, GPU handling, speed and API serving with real commands you can run today, so you can stop reading Reddit threads and start generating tokens locally.

What is the difference between Ollama and LM Studio?

The core difference is interface and intent:

• Ollama is a CLI-first runtime. You pull a model with one command and it runs as a background service on localhost:11434, exposing a REST API. There is no built-in chat window — it is built to be the “Docker for LLMs” that other tools plug into.
• LM Studio is a full desktop application (Electron) with a model search browser, chat UI, per-model settings (context length, GPU offload layers, temperature) and a local server mode you toggle with a click.

Both understand the GGUF format and both drive the same underlying engine lineage — Ollama embeds llama.cpp, and LM Studio uses llama.cpp-based runtimes it downloads and updates for you. That means raw generation quality for the same model file is effectively identical; the tools differ in everything around the model.

Is Ollama free for commercial use?

Yes. Ollama is open source (MIT) and free for commercial use — you only owe the model’s license, not Ollama’s. Llama, Mistral, Qwen and Gemma each carry their own terms, so check the model card if you ship product on top of one.

LM Studio is free for personal use but ships a closed-source license: work use requires a free “work” license flag, and companies above a revenue threshold pay for it. If your employer’s procurement team asks hard questions, that difference alone can decide the Ollama vs LM Studio debate.

Does Ollama use your GPU automatically?

Yes — Ollama detects CUDA (NVIDIA), Metal (Apple Silicon) and ROCm (AMD) at launch and offloads as many layers as fit in VRAM. Two checks worth knowing:

# What did Ollama actually load — GPU or CPU?
ollama ps

# Force the issue if it silently fell back to CPU:
OLLAMA_NUM_GPU=999 ollama run qwen2.5-coder:7b

If ollama ps shows 100% GPU, you are offloaded; a split like 48%/52% CPU/GPU means the model did not fit and you will feel it in tokens/sec. LM Studio exposes the same control as a GPU offload slider per model, which is friendlier when you want to experiment — one of its genuinely better UX touches.

Which is faster, Ollama or LM Studio?

For the same model, quantisation and hardware: effectively a tie, because both delegate to llama.cpp. Benchmark claims of “Ollama is faster” or vice versa usually compare different quants or context lengths. Measure on your own machine instead of trusting either camp:

# Ollama: --verbose prints eval rate (tokens/sec) at the end
ollama run qwen2.5-coder:7b --verbose "Summarise what a Makefile does in one sentence."

In LM Studio, load the same GGUF file with identical context length and GPU layers, then watch tokens/sec in the chat’s stats panel. Whichever shows higher numbers, rerun the test twice — first load includes warm-up noise.

Can you run LM Studio as a local API server?

Yes — head to the Developer tab, start the server, and you get an OpenAI-compatible endpoint on localhost:1234. It even has a CLI (lms) for scripting:

lms server start
lms load qwen2.5-coder-7b-instruct --gpu max
curl http://localhost:1234/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{"model":"qwen2.5-coder-7b-instruct","messages":[{"role":"user","content":"Write a jq filter for the top process by CPU"}]}'

Ollama’s equivalent API is always on once the service runs, and its native endpoint plus OpenAI-compatible routes need zero setup:

curl -fsSL https://ollama.com/install.sh | sh   # Linux install
ollama pull qwen2.5-coder:7b
curl http://localhost:11434/api/chat -d '{
  "model": "qwen2.5-coder:7b",
  "messages": [{"role": "user", "content": "Explain bash exit codes in two lines"}],
  "stream": false
}'

Both slots straight into any tool that speaks the OpenAI API — VS Code extensions, coding agents, your own scripts. This is where Ollama pulls ahead: the service starts at boot, runs headless on a server or homelab box, and nothing depends on a desktop app being open. I run exactly this setup on my own homelab, where Ollama serves models to everything on the network while the head node stays mouse-free.

Which should you pick: Ollama or LM Studio?

Rules of thumb, no regrets either way:

1. You want to use models — chat, try them out, fiddle with sliders: LM Studio.
2. You want to build on models — scripts, agents, CI, a home API service: Ollama.
3. You want both — install both; they coexist fine (just don’t let both servers claim the same port, and remember a model loaded twice eats VRAM twice).

Local models pair especially well with agentic coding tools — point an OpenAI-compatible client at your local endpoint and you get unlimited completions with zero per-token cost. That combination powers the local-first setup behind freechat, and it is the cheapest way to learn LLM plumbing: the only bill is the electricity.