DEV Community: ricco020

GitHub says these three repos have no licence. They all do.

ricco020 — Thu, 20 Aug 2026 01:52:17 +0000

GitHub puts a licence label on every repository. It reads it from the LICENSE file and
normalises it to an SPDX identifier — MIT, BSD-3-Clause, Apache-2.0. When it cannot,
the API returns NOASSERTION and the web UI quietly says "Other".

I checked twelve popular proxy, VPN and mesh-networking repositories through the GitHub API
on 20 August 2026. Three came back NOASSERTION. Here is what each of the three actually
ships — because "Other" is not one situation, it is three very different ones.

The measurement

Repository	SPDX from the API	Stars
SagerNet/sing-box	NOASSERTION	37,141
XTLS/Xray-core	MPL-2.0	41,121
juanfont/headscale	BSD-3-Clause	43,009
tailscale/tailscale	BSD-3-Clause	35,368
v2fly/v2ray-core	MIT	34,491
wireguard/wireguard-go	MIT	4,347
apernet/hysteria	MIT	22,355
EAimTY/tuic	GPL-3.0	3,261
cloudflare/cloudflared	Apache-2.0	15,304
netbirdio/netbird	NOASSERTION	28,520
zerotier/ZeroTierOne	NOASSERTION	17,029
slackhq/nebula	MIT	17,630

Three out of twelve. Now the interesting part.

1. sing-box — GPLv3, plus a clause of its own

The LICENSE file opens with the standard GPL version 3 or later grant. Then it adds:

In addition, no derivative work may use the name or imply association with this
application without prior consent.

That sentence is why the label cannot be GPL-3.0: the text is no longer the unmodified
licence. The grant is still copyleft, with a naming restriction bolted on.

2. netbird — BSD-3-Clause, except where it is AGPLv3

Its LICENSE file says it plainly in the first two lines:

This BSD-3-Clause license applies to all parts of the repository except for the
directories [...] Those directories are licensed under the GNU Affero General Public
License version 3.0.

A permissive licence for most of the tree, and the strongest network copyleft there is for
part of it. One SPDX identifier cannot express that, and picking the friendlier of the two
is exactly the mistake the label would encourage.

3. ZeroTier — MPL, and a `nonfree/` directory

LICENSE.txt is three lines, and the second one is the one that matters:

See nonfree/LICENSE.md for all non-free ("source available") portions of this repository.

Source-available is not open source. A repository can be mostly MPL and still contain a
directory you may read but not freely reuse.

What to take from this

NOASSERTION does not mean "no licence" and it does not mean "unclear". It means GitHub
declined to summarise this one in a single word, and in all three cases it was right to
decline. An extra clause, a per-directory split, and a non-free carve-out are all things
that matter the moment you ship something built on top.

The practical rule is boring and holds up: if you are redistributing, open the LICENSE
file. The badge is a convenience, not a statement of terms. Two minutes of reading, and
the three repositories above stop being surprises.

I went down this road while comparing two of these cores in detail — the licence turned out
to be the sharpest difference between them, well ahead of the protocol lists everyone else
compares:
sing-box vs Xray: the differences that actually decide it.

All figures read from the GitHub REST API on 20 August 2026; star counts move, the licence
files are the stable part.

Your sysctl says one thing, the kernel says another

ricco020 — Wed, 19 Aug 2026 05:06:12 +0000

You set net.ipv4.ip_forward=1 in /etc/sysctl.conf. You rebooted. The value is still 0.

Nothing is broken, and you did not make a typo. On a host running UFW, there is a second sysctl file, and it wins.

Two files, one kernel

UFW ships /etc/ufw/sysctl.conf and loads it when the firewall comes up. It takes precedence over /etc/sysctl.conf. Anything you set in the familiar file that UFW also sets is quietly overwritten on the next ufw enable.

Quietly is the operative word. There is no warning, no log line, no diff. The file you edited still contains exactly what you typed — which is why this costs hours rather than minutes: you keep re-reading a correct file.

The symptom that most often brings people here: a WireGuard tunnel that comes up, a client that receives its address, and no traffic going anywhere. ip_forward fell back to 0.

Read the effective value, not the file

sysctl net.ipv4.ip_forward          # what the kernel applies
cat /proc/sys/net/ipv4/ip_forward   # same thing, one file

If that disagrees with what you wrote, look in /etc/ufw/sysctl.conf. Note the notation there uses slashes:

net/ipv4/ip_forward=1

Both net.ipv4.ip_forward and net/ipv4/ip_forward name the same knob. Grepping for only one of them is a good way to conclude the setting is absent when it is not.

A small script to stop guessing

I wrote a read-only checker that compares effective sysctl values against hardening recommendations and, more importantly, flags the ones that are declared somewhere and not applied:

 ECART  kernel.kptr_restrict            effectif=0      attendu=2
 ECART  fs.protected_hardlinks          effectif=0      attendu=1
         declare a 1 dans /etc/sysctl.conf, mais le noyau applique 0

That second line is the whole point. No dependencies, Python 3 only, changes nothing:
https://gitlab.com/ler.eric/sysctl-hardening-check

While we are here: what hardening does not cover

Tightening sysctl narrows what a compromised process reaches on that machine. It says nothing about the paths that never touch the machine — a password reused on a service that leaked, a session left open on a device you no longer carry, the one account that receives every recovery link.

That distinction is worth keeping in view: Linux hardening, what it covers and what it does not.

One line to keep: the file you edited is not necessarily the file that wins.

UFW and WireGuard: the tunnel is up and nothing goes through

ricco020 — Wed, 19 Aug 2026 03:37:35 +0000

The tunnel comes up. wg show prints a recent handshake. The client has its address inside the tunnel. And not a single byte reaches the internet.

Almost every guide answers this with "open UDP 51820 in the firewall". You already did that — it is why the handshake works at all. The problem is somewhere else, and UFW makes the distinction easy to miss:

Entering a machine and traversing it are two different permissions.

ufw allow 51820/udp lets packets arrive at the server. Your clients' traffic does not stop there — it goes through the box and out the public interface. That path lives in the FORWARD chain, which UFW denies by default and which no allow rule touches.

The four things to check, in order

1. IP forwarding — and the file that overwrites the other file

This is the one that costs hours, because the setting looks done.

UFW loads its own sysctl file at startup, and it takes precedence over the system one. A value you carefully set in /etc/sysctl.conf can be silently overwritten on the next ufw enable.

The right place is /etc/ufw/sysctl.conf:

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Then check the effective value, not the file you just edited:

sysctl net.ipv4.ip_forward

2. Forwarding, which is not the same as ingress

Targeted, and the one to prefer:

sudo ufw route allow in on wg0 out on eth0

Or globally, in /etc/default/ufw:

DEFAULT_FORWARD_POLICY="ACCEPT"

The second opens forwarding for every interface. It is a good ten-second diagnostic and a poor permanent configuration.

3. NAT, which UFW never adds on its own

Without it, packets leave carrying their tunnel address, which nothing on the internet knows how to answer. In /etc/ufw/before.rules, at the very top, before the *filter line:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Two classic mistakes here: putting this block after *filter (it is then ignored), and copying eth0 without checking.

4. The real name of the egress interface

eth0 is an article convention, not a fact. Depending on the host it will be ens3, enp1s0, something else. The command that answers without guessing:

ip route get 1.1.1.1

The test that separates the two families of causes

From a connected client, try to reach the server's address inside the tunnel (often 10.8.0.1):

What you observe	What it means
tunnel address answers, nothing external does	tunnel is fine — forwarding or NAT missing
tunnel address does not answer either	upstream: keys, `AllowedIPs`, client routing
everything answers but names do not resolve	not UFW at all — it is the DNS pushed to the client

That third row is worth knowing. "I have no internet" very often means "no name resolves". Pinging an IP directly tells you in one command.

After applying

before.rules is only re-read on reload:

sudo ufw disable && sudo ufw enable
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

One last thing that produces duplicate configurations: if your PostUp/PostDown rules in the WireGuard config already add MASQUERADE, you do not need the *nat block above. Both together rarely break anything, but they make the next outage much harder to read — and there will be a next one.

If you are still choosing a port or wondering whether 443/UDP is worth it, I wrote a longer piece on WireGuard ports, changing them and opening them properly.

One line to keep: an open port means packets can enter, not that they can traverse.

Your drive says SMART PASSED and is already failing: the 5 attributes that actually predict it

ricco020 — Sat, 15 Aug 2026 15:52:24 +0000

A drive that SMART calls PASSED can already be losing your data. The overall
self-assessment is a manufacturer threshold, not a statement about your files — and it stays
green well past the point where sectors have started going unreadable.

Here is the case that matters, from a real report:

SMART overall verdict : PASSED

Reallocated_Sector_Ct  = 24   sectors already remapped
Current_Pending_Sector = 8    sectors unreadable RIGHT NOW

That drive passes. It is also actively failing.

The five attributes worth reading

Forget the table of forty values. Five of them describe the two families that precede
unreadable data — reallocation and pending sectors:

ID	attribute	meaning
5	`Reallocated_Sector_Ct`	sectors already remapped
197	`Current_Pending_Sector`	unreadable now, waiting to be remapped
198	`Offline_Uncorrectable`	the drive could not read them offline
187	`Reported_Uncorrect`	errors it could not correct
188	`Command_Timeout`	commands that timed out

A non-zero 197 on a drive reporting PASSED is the exact situation to act on.

Read it in one command

smartctl -a -j /dev/sda | python3 smart_triage.py

The script is MIT, has no dependencies and no network access — it reads stdin and prints a
verdict, with exit codes 0 healthy, 1 monitor, 2 back up now, 3 stop and image:
https://gitlab.com/ler.eric/smart-triage

The order of operations, which decides whether you keep the data

If the verdict is stop and image, the sequence is not negotiable:

Stop using the drive. Every hour of use turns more pending sectors into lost ones.
Image the whole device to a file with ddrescue — not a file copy, a block-level image.
Work on the copy. Never on the original.

The mistake that destroys recoverable data is running a filesystem repair tool first. fsck
and chkdsk write to the disk. Writing to a drive with pending sectors is how a
recoverable image becomes an unrecoverable one — and it is irreversible.

What SMART does not tell you

SMART predicts a meaningful share of failures, not all of them. Controller failures, firmware
faults and head crashes can arrive with every attribute still green. A clean report is a reason
to keep monitoring, never a reason to skip backups.

If you want the detail of what is realistically recoverable per failure mode — mechanical,
electronic, logical, firmware — this breakdown covers it:
https://www.save-my-disk.com/en/blog/hard-drive-failure

A failed deployment is invisible from the web

ricco020 — Fri, 14 Aug 2026 06:27:43 +0000

Last night a deployment of mine failed for 21 hours and every monitoring check stayed green. The site answered 200 the whole time. Here is why that happens, and the two-line check that catches it.

The failure mode

When a build fails on Vercel (and on Railway, and on most platforms with atomic deploys), the platform does the sensible thing: it keeps serving the previous successful build. Your users see a working site. Your uptime monitor sees 200 OK. Your health check passes.

What nobody sees is that the commit you pushed is not the code being served. Every article, fix and config change since the last green build is sitting in git, live nowhere.

That is a good default — far better than serving a broken build. But it means "the site is up" and "my work is deployed" are two different questions, and most monitoring only answers the first.

The check that actually answers it

Compare the timestamp of your last commit with the timestamp of the last successful deployment. If the commit is newer by more than a build's duration, something is wrong:

git log -1 --format=%ct                 # last commit, unix time
npx vercel ls --prod                    # last deployments + their state

If the age of the newest Ready deployment is older than your last commit, you are serving stale code. In my case the newest Ready was 21 hours old, and two Error deployments sat above it.

The trap that cost me an hour

Here is the part worth the read. Outside a TTY, vercel ls splits its output across two streams:

stdout gets the deployment URLs, one per line — no status
stderr gets the formatted table, including the ● Ready / ● Error column

So this looks correct and silently returns nothing:

r = subprocess.run(["npx","vercel","ls","--prod"], capture_output=True, text=True)
errors = [l for l in r.stdout.splitlines() if "Error" in l]   # always empty

Your script reports zero errors on a project that is entirely broken. The fix is to read both streams:

out = (r.stdout or "") + (r.stderr or "")

The general lesson is worth more than the specific fix: an empty result and a clean result are not the same thing. If a check can return "nothing found" both when everything is fine and when the parsing broke, it will eventually lie to you — and it will lie in the reassuring direction. Make the two cases distinguishable:

if not lines:
    return "NOT VERIFIED"     # not "0 errors"

What actually broke the build

For the curious: a TypeScript error on a component prop. One call site out of 21 was missing a required id. Nothing exotic — but because the previous build kept serving, nothing surfaced it either.

I found the second occurrence only after the first fix failed, because I had listed the call sites with grep ... | head -8 on a file with 21 of them. A head on a search meant to be exhaustive turns "I saw nothing" into "there is nothing".

Three things to take away

Uptime monitoring does not detect failed deployments. Compare commit time to last successful deploy time.
Check the state of recent deployments, not just the age of the last good one.
When a check returns nothing, make sure it can tell you why — no data and no problem must not look identical.

If you are wiring up this kind of monitoring, the same reasoning applies to the telemetry you collect about it — what OpenTelemetry actually is, and what it deliberately does not give you covers the difference between producing telemetry and having observability, which is the trap one layer up.

You don't need to restart WireGuard to add a peer

ricco020 — Thu, 13 Aug 2026 15:09:57 +0000

Most guides answer "how do I add a WireGuard peer" with this:

wg-quick down wg0 && wg-quick up wg0

That works. It also tears down every active tunnel on the box to add one line to a file. On a server anyone actually depends on, that is the reason people batch peer additions for weeks instead of doing them when asked.

There is a command that does it live.

wg set

wg set wg0 peer <CLIENT_PUBLIC_KEY> allowed-ips 10.0.0.5/32

The peer exists from that instant. Existing sessions are untouched — wg set edits the running interface through the kernel module rather than rebuilding it.

Nothing is printed on success, which throws people. wg show wg0 is what confirms it.

The catch nobody mentions

wg set changes the running state, not /etc/wireguard/wg0.conf. Reboot and your peer is gone.

You can write the live state back:

wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 600 /etc/wireguard/wg0.conf

But note what showconf actually prints: the interface's private key, along with everything else. If your umask leaves that file world-readable, you have just published it to every account on the machine. The chmod is not optional politeness.

Reloading an edited file without dropping anyone

wg syncconf wg0 <(wg-quick strip wg0)

syncconf applies the difference. wg-quick down/up rebuilds from scratch — the thing you were trying to avoid in the first place.

The failure that looks like magic

Two peers sharing an AllowedIPs address is the bug that wastes an afternoon, because the symptom is backwards: you add a new client, and the older one stops working. AllowedIPs is what decides which peer a packet belongs to, so a duplicate makes that decision ambiguous.

One /32 per client, never overlapping.

I wrote a small tool that reads a folder of client configs and flags exactly that — duplicate addresses, reused private keys, and AllowedIPs ranges wide enough to swallow the local network: wg-clients-audit. Deliberately silent on 0.0.0.0/0, since full-tunnel is a choice, not a mistake.

The longer version, with the client-side config and the three reasons a new peer fails to connect, is here: WireGuard add peer without restarting the tunnel.

What is an API? A clear, practical explainer

ricco020 — Wed, 24 Jun 2026 12:25:36 +0000

An API (Application Programming Interface) is a contract that lets one piece of software ask another for data or actions, without knowing how it works inside. What an API is, how a request and response work, the common styles like REST and GraphQL, and why developers build on them.

An API — short for Application Programming Interface — is a set of rules that lets one program talk to another. It defines how you ask for data or an action, what you have to send, and what you get back, so two pieces of software can work together without either one knowing how the other is built inside. It is the contract between them.

A common analogy is a restaurant menu. The menu lists what you can order and what each dish costs, you place an order, and the kitchen prepares it — but you never need to see the kitchen or know how the cooking is done. An API is that menu for software: it tells you what you can request and how, and hides everything behind it.

More precisely, an API exposes a set of operations a service is willing to perform. A weather service might offer an operation that returns the forecast for a city; a payment service might offer one that charges a card. You call the operation with the inputs it expects, and the service does the work and hands back a result. The internals stay private and can change freely, as long as the contract holds.

On the web, most APIs work over the same protocol as web pages: HTTP. Your program sends a request to a URL called an endpoint, usually with a method that signals intent — GET to read data, POST to create it, PUT or PATCH to update, DELETE to remove. The request can carry parameters and a body; the server processes it and sends back a response.

That response has two important parts: a status code and a payload. The status code is a short number that says how it went — 200 means success, 404 means the thing was not found, 500 means the server hit an error. The payload is the data itself, today almost always formatted as JSON, a lightweight text format that is easy for programs to read and write.

APIs come in a few common styles. REST is the most widespread: it organises everything around resources addressed by URLs and leans on the standard HTTP methods. GraphQL takes a different approach, letting the client ask for exactly the fields it needs in a single query, which avoids over-fetching. Older systems may use SOAP, and real-time apps often add WebSockets for a continuous two-way connection.

Many APIs are protected, because they expose real data and actions. Authentication proves who is calling — often with an API key or a token such as OAuth — and rate limiting caps how many requests a caller can make in a window, so one client cannot overwhelm the service. Public APIs publish documentation describing every endpoint, its inputs, and its responses.

Developers rely on APIs because they let you build on top of existing services instead of reinventing them. You can add maps, payments, email, login, or AI to an app by calling someone else’s API. They also let large systems split into smaller services that talk to each other, and they are how a mobile app or single-page front end fetches data from a backend.

Finally, an API has to run somewhere. The service behind it — the backend that receives requests and returns responses — needs a reliable, always-on server. For your own APIs, that means a host you control: a VPS or cloud server where the backend stays up and reachable. A solid host is the foundation the whole interface sits on.

Self-hosting needs a reliable home with full runtime and network control. Infomaniak — a Swiss, privacy-respecting provider — offers VPS and cloud servers to host your CMS or app.

Originally published on versiondude.net.

What Is a Higher-Order Function? Functions as Values, Explained (2026)

ricco020 — Wed, 24 Jun 2026 08:37:13 +0000

In most languages a function is something you call. In functional programming a function is also a value — you can store it in a variable, pass it into another function, and get one back as a result. A higher-order function is exactly the function that does one of those last two things. This guide explains what a higher-order function is, why map, filter and fold are the classic examples, how they replace loops, and how they look in Haskell.

The short definition

A higher-order function is a function that takes one or more functions as arguments, returns a function as its result, or both. A function that does neither — it only takes and returns plain values like numbers or strings — is called a first-order function. The "higher-order" name simply means it operates on functions the way an ordinary function operates on data.

This only works in a language where functions are first-class values: things you can name, pass around and return, just like an integer. Haskell, JavaScript, Python, Swift and many others treat functions this way, which is what makes higher-order functions possible.

The three classics: map, filter and fold

Almost every functional codebase leans on three higher-order functions. Each one takes a function as an argument and applies it across a collection:

- **map** applies a function to every element of a list and gives back a new list of the results. `map (+1) [1,2,3]` gives `[2,3,4]` — the function `(+1)` is the argument.

- **filter** keeps only the elements for which a function returns true. `filter even [1,2,3,4]` gives `[2,4]` — here `even` is the function you pass in.

- **fold** (also called reduce) collapses a list down to a single value by combining elements two at a time. `foldr (+) 0 [1,2,3]` adds them up to `6` — the combining step `(+)` is the function argument.

In each case you supply the small piece of logic — increment, "is even", add — and the higher-order function handles the walking-over-the-list part. You describe what to do to each element, not the bookkeeping of how to step through them.

How they replace loops

In an imperative language you might write a loop with a counter, an accumulator, and an explicit index. The same intent expressed with a higher-order function disappears into a single line, because the iteration is already baked into map or fold. That is why purely functional code, which avoids mutable loop counters, leans so heavily on these functions and on recursion — the two cover the work that loops do elsewhere. List comprehensions are often a readable shorthand for the same map-and-filter combination.

Returning a function: where it gets powerful

The other half of the definition — functions that return functions — is just as common. A function can build and hand back a new, specialised function. A classic example is a "multiplier maker": you give it a number and it returns a function that multiplies its input by that number. Call it with 3 and you get back a "times three" function you can then use like any other. The maker is higher-order because its result is itself a function.

In Haskell this is woven into the language through currying: every function of several arguments is really a chain of one-argument functions, each returning the next. That is why map (+1) works — (+1) is the addition function with one argument already supplied, returning a function that still expects the other. Partial application like this is higher-order functions at work, often without you noticing.

Higher-order functions in Haskell

Haskell makes the idea explicit in its type signatures. The type of map is written map :: (a -> b) -> [a] -> [b]. Read it left to right: the first argument (a -> b) is itself a function — that is the higher-order part — followed by a list of a, producing a list of b. The arrows make it visible on the page that a function is being passed in. The same pattern appears in filter :: (a -> Bool) -> [a] -> [a] and across the standard library.

You often pass these functions inline as lambdas — small anonymous functions written with a backslash, like map (\x -> x * x) [1,2,3] to square each element. Whether you pass a named function, an operator section like (*2), or a lambda, it is the same mechanism: a function travelling as a value into a higher-order function.

Why they matter

Higher-order functions let you factor out the common shape of a computation — "do something to every element", "keep the ones that match", "combine them all" — and reuse it with different logic plugged in. That means less repeated boilerplate, code that reads closer to its intent, and small, testable pieces of logic you can compose. They are the building block on top of which much of functional programming is expressed, and combined with Haskell's lazy evaluation they even let you map and filter over lists that are conceptually infinite.

The honest trade-offs

Higher-order functions take some getting used to: reading foldr or a chain of map . filter is a skill, and deeply nested lambdas can become hard to follow. Passing functions around can also make a stack trace less obvious when something goes wrong. The payoff — far less repetitive iteration code and logic you can recombine — is why they have spread well beyond functional languages into everyday JavaScript, Python and Swift. Used with restraint, they make code shorter and clearer; overused, they can obscure it like any other tool.

Frequently asked questions

What is a higher-order function in simple terms?
A higher-order function is a function that takes another function as an argument, returns a function as its result, or both. Instead of working only on plain data like numbers and strings, it works on functions. Classic examples are map, filter and fold, which each take a small function and apply it across a list.

Is map a higher-order function?
Yes. map takes a function as its first argument and applies it to every element of a list, returning a new list of the results. Because one of its arguments is itself a function, map is a textbook higher-order function — and so are filter and fold for the same reason.

What is the difference between a higher-order and a first-order function?
A first-order function only takes and returns ordinary values, such as numbers or strings. A higher-order function takes one or more functions as arguments, or returns a function, or both. The difference is whether the function operates on data alone or also on other functions.

Do higher-order functions only exist in Haskell?
No. They exist in any language that treats functions as first-class values — values you can store, pass and return. Haskell, JavaScript, Python, Swift and many others all support them. Haskell makes the idea especially visible through its type signatures and currying, but the concept is widespread.

Recommended

A Linux box to build and run your Haskell code

Trying these higher-order functions for real — loading them into GHCi, building a project with map and fold, then running it — is smoother on a proper Linux machine than a laptop. A cloud server gives you full control to install GHC and a Haskell toolchain in a clean environment and reach it over SSH. Infomaniak — a Swiss, privacy-respecting provider — offers cloud servers for exactly that.

[See Infomaniak Cloud →](https://coldwa.st/go/cloud.html)
Affiliate link — it supports these free guides.

Browse more clear explainers in our guides index.

Originally published on coldwa.st.

MCP Security: The Risks of Model Context Protocol and How to Govern It (2026)

ricco020 — Wed, 24 Jun 2026 07:31:23 +0000

The Model Context Protocol (MCP) is the open standard that lets an AI agent plug into your tools, files, and apps through one common interface — often described as "USB-C for AI." It is genuinely useful, and through 2025 and 2026 it has been adopted across AI assistants, IDEs, and agent frameworks. But the same connector that makes an agent powerful is also its biggest attack surface. Recent moves toward governing AI agents in the enterprise — security vendors shipping tools to monitor coding agents, and MCP-based governance layers landing inside Claude, ChatGPT, and Copilot — are a sign of the same thing: connecting an agent to your environment is a security decision, not a convenience setting. Here is the honest picture of MCP security in 2026 and how to govern it.

Why MCP is a security problem, not just a feature

MCP itself is just plumbing: a standard way for a model to discover tools, read their descriptions, and call them. The risk isn't the protocol — it's what flows through it.

When an agent connects to an MCP server, that server provides two things the model trusts: tool descriptions (text telling the model what each tool does and how to call it) and tool outputs (whatever the tool returns). The model reads both and acts on them. So every MCP server you attach is effectively code and instructions running with your agent's privileges. Whatever the agent can reach — your files, a repository, an API, your email — a malicious server can try to reach through the agent.

This is the same shift that makes AI agent security hard in general, applied to a specific connector: the security of your MCP setup is the security of every server you plug into it.

The MCP-specific risks in 2026

These aren't hypothetical — security researchers have documented them on real MCP clients.

Tool poisoning. A malicious server hides instructions inside a tool's description — text the model reads but the user usually doesn't. A tool that looks like a harmless add(a, b) can secretly instruct the agent to read private files and exfiltrate them. Because users tend to approve tool calls without inspecting the description, this is one of the most impactful MCP-specific attacks.
Rug pulls (silent redefinition). An MCP tool changes its own definition after you've installed and approved it. You vetted something safe; the server later swaps in malicious behaviour without telling you.
Tool shadowing and cross-server attacks. When several servers connect to the same agent, a compromised one can override or intercept calls meant for a trusted tool — a "confused deputy" problem where the agent does the attacker's bidding while thinking it's using a legitimate tool.
The exfiltration trifecta. The genuinely dangerous combination is an agent that has private data, reads untrusted content, and has an exfiltration path to the outside. MCP makes all three easy to wire together by accident.
Indirect prompt injection. Even an honest server returns outputs the agent reads — a web page, an issue, a document — that may contain hidden instructions. The agent can obey them as if they came from you.

How to govern MCP safely

You don't need to avoid MCP. You need to govern what you connect and box it in so a single bad server can't become a disaster. The principles are old security wisdom applied to a new connector.

Vet and pin trusted servers. Prefer official or well-reviewed MCP servers. Don't attach arbitrary third-party servers to an agent that holds real access, and watch for tool definitions that change after install.
Least privilege per server. Give each server only the access its job needs, using scoped, revocable credentials — never your primary accounts or production keys. If a server only needs to read, don't let it write.
Limit the blast radius. Avoid connecting many untrusted servers to the same agent, since one compromised server can intercept others. Isolate sensitive work from anything that reads the open web.
Human in the loop for high-impact actions. Require explicit confirmation before anything irreversible — sending money, deleting data, posting publicly, changing access. Let the agent draft; you approve.
Treat tool descriptions and outputs as untrusted. Both can carry injected instructions. The same caution applies when an agent uses AI code review tools or any tool that ingests external content.
Log and audit tool calls. Keep a record of which servers and tools the agent used, so you can spot anomalies and revoke fast.
Keep secrets out of prompts and tool arguments. Passwords and API keys pasted into a prompt or a tool call become text on a server. Use scoped tokens and secret managers instead.

The honest takeaway

MCP security comes down to one mindset shift: an MCP server is not a plugin you install and forget — it's a new participant with autonomy and access, and you should treat it like one you don't fully trust. The protocol is open and useful; the danger is in granting broad, standing trust to servers you haven't vetted. Connect deliberately, scope every server tightly, keep a human gate on anything irreversible, and assume every tool description and output could be trying to hijack your agent. The teams now building governance around AI agents — and the AI coding agents that lean on MCP most — are converging on exactly that: connect less, trust narrowly, and verify.

FAQ

What is MCP security?

MCP security is the practice of safely connecting AI models and agents to external tools and data through the Model Context Protocol — an open standard introduced by Anthropic in late 2024, often described as 'USB-C for AI'. MCP itself is just a connector: the security question is what you plug into it and how much you trust it. Each MCP server an agent connects to is code and instructions running with the agent's access, so a malicious or compromised server can read your data, call other tools, or take actions on your behalf. MCP security means vetting servers, scoping permissions tightly, and treating tool descriptions and outputs as untrusted input.

What is tool poisoning in MCP?

Tool poisoning is when a malicious MCP server hides instructions inside a tool's description or metadata — text the model reads but the user usually doesn't. The model treats those hidden instructions as commands, so a tool that looks like a harmless 'add two numbers' function can secretly tell the agent to read private files and send them somewhere. Security researchers have documented this as one of the most impactful MCP-specific risks, because users tend to approve tool calls without inspecting the underlying descriptions.

What is an MCP rug pull?

A rug pull, also called silent redefinition, is when an MCP tool changes its own definition after you've already installed and trusted it. You approve a tool that looks safe, and later the server quietly swaps in malicious instructions without notifying you. A related attack is tool shadowing, where a malicious server overrides or intercepts calls meant for a trusted tool. Both exploit the fact that trust granted once is rarely re-checked, which is why monitoring tool definitions for changes matters.

Is MCP safe to use?

MCP is broadly safe for everyday use if you connect only to servers you trust and scope their access tightly, but it is not safe to wire up arbitrary third-party servers with broad permissions and walk away. The protocol is an open connector, so its safety depends entirely on the servers you attach and the access you grant them. Use official or well-reviewed servers, give each one separate revocable credentials instead of your main accounts, keep a human in the loop for high-impact actions, and review what tools can do before approving them.

How do I secure MCP servers?

Apply least privilege: give each MCP server only the access its job needs, using scoped, revocable tokens rather than admin keys or your primary accounts. Vet and pin trusted servers, prefer official ones, and watch for tool definitions that change after install. Treat tool descriptions and tool outputs as untrusted content that may contain injected instructions. Avoid connecting many untrusted servers to the same agent, since one compromised server can intercept others. Log tool calls so you can audit and revoke, and keep secrets out of prompts and tool arguments.

Originally published on alexi.sh.

What Is a Vector Database? A Plain-English Guide (2026)

ricco020 — Mon, 22 Jun 2026 05:27:58 +0000

If you have read about RAG, AI search or recommendations, you have probably hit the term vector database. Here is the plain version. A vector database stores data as vectors — lists of numbers that capture meaning — and finds items by similarity, not by exact match. That one idea is what makes modern AI search feel like it understands you.

What a vector database actually is

Normal databases are great at exact questions: find the user with this ID, or every order from last week. They struggle with "find me things that mean the same thing." A vector database is built for exactly that.

It works on embeddings — the numeric fingerprints an AI model gives to text, images or audio. Items with similar meaning get vectors that sit close together. The database stores those vectors and, when you search, returns the ones nearest to your query.

How similarity search works

The flow has three steps:

Embed. An embedding model turns each document, image or sentence into a vector.
Index. The database stores those vectors in a special index (like HNSW or IVF) so it can search huge sets fast.
Query. Your search is embedded too. The database returns the vectors closest to it by distance.

So a search for "how to reset my password" can surface an article called "recover a forgotten login." The words differ, but the meaning — and the vectors — are close.

Vector database vs a normal database

They solve different problems, and most real apps use both. A relational database holds your structured records and answers exact queries. A vector database answers "what is most like this?" You keep customer rows in one and searchable meaning in the other. Tools like pgvector even let you add vector search to a normal PostgreSQL database, so both live in one place.

Why it matters for AI

A vector database is the retrieval engine behind a lot of AI. It powers semantic search, product and content recommendations, and — most importantly — the retrieval step in RAG, where an assistant fetches relevant text before answering. Without fast similarity search over embeddings, none of those features would be practical at scale.

The bottom line

A vector database stores meaning as vectors and finds items by similarity instead of exact match. It does not replace your normal database — it sits beside it and answers the questions a keyword search never could. If you are building anything with semantic search or RAG, a vector database is the piece doing the heavy lifting.

FAQ

What is a vector database in simple terms?

A vector database stores data as vectors — long lists of numbers called embeddings that capture meaning. Instead of matching exact words, it finds items whose vectors are closest to your query's vector. So a search for 'how to reset my password' can return a help article titled 'recover a forgotten login', because they mean the same thing. It is the engine behind semantic search, recommendations, and the retrieval step in most AI assistants.

How is a vector database different from a normal database?

A normal (relational) database is built for exact, structured queries: find the row where id = 42, or where country = 'France'. A vector database is built for similarity: find the items most like this one. It does not look for an exact match — it ranks results by how close their vectors are. The two are complementary. Many apps use a normal database for records and a vector database for meaning-based search.

How does similarity search actually work?

Three steps. First, an embedding model turns each item (a document, image, or sentence) into a vector. Second, the vector database stores those vectors in a special index (such as HNSW or IVF) that makes nearest-neighbour search fast, even over millions of items. Third, when a query comes in, it is embedded too, and the database returns the vectors closest to it by distance. You get the most similar items back in milliseconds.

Which vector databases are popular in 2026?

Common options include Pinecone, Weaviate, Qdrant, Milvus, and Chroma, plus pgvector, which adds vector search to PostgreSQL so you can keep everything in one database. The right choice depends on scale, whether you want a managed service or to self-host, and whether you need vectors alongside your existing relational data. For small projects, pgvector or Chroma are easy starting points.

Originally published on alexi.sh.

What Is a Home Server? A Plain-English Guide (2026)

ricco020 — Sun, 21 Jun 2026 13:38:09 +0000

There is a running joke online: someone sets out to build a "home server," and a year later they have a rack of machines, a labelled network, and a power bill to match — they accidentally built a tiny data center. It is funny because it is true, but it hides a simpler fact. A home server does not have to be any of that. At its core, a home server is just a computer that stays on to serve other devices in your home.

What a home server actually is

Think of it as a helper computer. It runs all the time, sits quietly in a corner, and waits for your other devices to ask it for something. You do not sit in front of it. Once it is set up, it has no screen or keyboard — you reach it from your phone, laptop or TV over your home Wi-Fi.

The hardware can be almost anything. An old laptop works. So does a cheap mini PC, a Raspberry Pi, or a ready-made NAS box. What makes it a "server" is the job it does, not the size of the machine.

What people run on one

A home server earns its keep by doing a few steady jobs:

File storage — one place for documents and photos that every device can reach.
Media streaming — your own films and music, streamed to any screen in the house.
Backups — automatic copies of your phones and laptops, so a lost device is not a lost life.
Smart-home control — local software that runs your lights and sensors without the cloud.
A self-hosted VPN — a private door back into your home network while you travel.

You can run just one of these, or several at once. Most people keep each job in its own container so they stay tidy and easy to update.

Home server vs a VPS

The two get confused, but they solve different problems. A home server lives in your house, holds your data, and costs only the electricity to run it. The catch is that it depends on your home internet and you look after it yourself.

A VPS is a server you rent in a data center. It is always online, has a fast connection and a public IP, and is easier to reach from anywhere — which is why people host a VPN or a website on one. If you are weighing the two, our guide on what a VPS is explains it in plain terms. Many setups use both: a home server for local files and media, a small VPS for anything the outside world needs to reach.

What you need to start

Very little. An always-on computer you already own, a wired network connection if you can manage it, and one job to begin with — say, a file share or a media library. Add a second service only once the first is steady. Start small, keep it simple, and let it grow with you.

The bottom line

A home server is not a data center. It is a spare computer doing useful work while you get on with your day — storing your files, backing up your devices, streaming your media, and, if you want, giving you a private way home over a VPN. Begin with one machine and one job. That is all it takes to have a home server.

FAQ

What is a home server in simple terms?

A home server is a computer in your home that stays on so other devices can use it. It does not need a screen or a keyboard once it is set up. You reach it from your phone, laptop or TV over your home network. People use one to store files, stream their own media, run automatic backups, host smart-home software, or run a self-hosted VPN. Any always-on computer can be a home server — an old laptop, a mini PC, a Raspberry Pi, or a NAS box.

Do I need a home server, or is a VPS better?

It depends on what you want. A home server keeps your data in your house and costs nothing to run beyond electricity, but it relies on your home internet and you maintain it yourself. A VPS (a rented server in a data center) is always online with a fast, stable connection and a public IP, which is easier for hosting a VPN or a website that you reach from anywhere. Many people use a home server for local files and media, and a small VPS for anything that needs to be reachable from outside the house.

What can you run on a home server?

Common uses are: a file share for all your devices, a media library (so you stream your own films and music), automatic backups of phones and laptops, a photo library, smart-home automation, ad-blocking for the whole network, and a self-hosted VPN to reach your home safely while travelling. You can run one of these or several at once, usually inside containers so they stay tidy and separate.

Is a home server hard to set up?

Not as hard as it used to be. A basic file or media server can be running in an afternoon with free software and a guide. The learning curve is real if you want remote access, secure logins, and automatic updates, but you can start small with one service and add more later. A Raspberry Pi or an old laptop is a cheap, low-risk way to learn before spending money on dedicated hardware.

Originally published on vpnsmith.

What Is Vibe Coding? The AI-First Way to Build Software (2026)

ricco020 — Sun, 21 Jun 2026 13:36:38 +0000

Ask an AI assistant to "build me a habit-tracker app" and watch it produce working code in seconds — then ask it to tweak the colours, add a chart, fix a crash, all in plain English, without you reading a single line. That loop has a name now: vibe coding. This guide explains what vibe coding actually is, where the term came from, how it works in practice, and the honest line between a brilliant shortcut and a trap.

What vibe coding actually is

Vibe coding is building software by describing intent to an AI and iterating on what it generates, instead of writing and reviewing the code yourself. You operate at the level of "what I want it to do" — add a feature, change a behaviour, fix an error — and let the model handle "how it's written." Your job shifts from author to director: you prompt, you run it, you react to the result, and you repeat.

The defining trait is how little you look at the code. In classic development you read and own every line. In vibe coding you often accept the AI's output without fully reading it, judging the program by whether it behaves the way you wanted rather than by how it's built.

Where the term came from

The phrase was popularised by Andrej Karpathy in early 2025. He described a mode of working where you "fully give in to the vibes" and rely on the AI so completely that you barely engage with the underlying code — fun and fast, in his framing, for weekend projects and throwaway tools. The name stuck because it captured something developers were already doing with conversational best AI coding assistants: less typing, more describing.

How it works in practice

A vibe-coding session looks like a conversation. You state a goal, the assistant writes or edits files, you run the result, and you describe what's wrong or what to add next. The model keeps the project context, so each turn builds on the last. The faster that loop — prompt, run, react — the more it feels like "coding by vibes" rather than by syntax.

This is close to, but not the same as, AI pair programming. Pair programming with an AI implies you're still reading along, reviewing and steering line by line, like a navigator beside a driver. Vibe coding leans further: you delegate the how almost entirely and judge only the outcome. The same tools support both modes — the difference is how much you choose to look.

Where it shines — and where it bites

Vibe coding genuinely excels at:

Prototypes and MVPs — get a clickable idea in front of people fast.
Throwaway scripts — one-off automation you'll run once and delete.
Learning and exploration — see one working approach, then dig in.
Non-critical personal tools — where a bug is an annoyance, not a breach.

It bites hardest when the stakes rise. Shipping code you haven't read means inheriting problems you can't see: exposed API keys, missing input validation, insecure dependencies, and subtle logic bugs. When something breaks in production, debugging code you never understood is painful, and a codebase nobody can explain becomes a maintenance liability. The accelerator that built the prototype is a poor foundation for the thing real users depend on.

The bottom line

Vibe coding is a real shift in how software gets made: describe intent, let the AI write it, iterate on the result. For prototypes, scripts and learning it's a superpower that collapses hours into minutes. For anything handling money, data or security, treat the AI's output as a fast first draft from a junior collaborator — read it, test it, and understand it before it ships. The developers who get the most from vibe coding are the ones who know exactly when to stop vibing and start reviewing.

FAQ

What is vibe coding?

Vibe coding is the practice of building software by describing what you want in natural language to an AI assistant and accepting or iterating on the code it generates, rather than writing and reviewing every line yourself. You stay at the level of intent — 'add a login form', 'make this faster', 'fix that bug' — and let the model produce the implementation. It works best with conversational AI coding tools and is excellent for prototypes and small scripts, but it shifts your role from author to reviewer-and-director.

Who coined the term 'vibe coding'?

The phrase was popularised by Andrej Karpathy in early 2025, when he described a way of working where you 'fully give in to the vibes' and lean on the AI so heavily that you barely look at the code. He framed it as fun and fast for throwaway projects. The term caught on quickly because it named something many developers had already started doing with tools like Cursor, GitHub Copilot and Claude Code.

Is vibe coding good or bad?

Neither on its own — it depends entirely on the stakes. For prototypes, personal tools, learning experiments and disposable scripts, vibe coding is a genuine accelerator: you get something working in minutes. For production software, anything handling money, personal data or security, shipping code you haven't read is risky, because you inherit bugs and vulnerabilities you can't see and will struggle to debug. The skill is knowing which mode a task calls for.

Is vibe coding safe for production apps?

Not without review. The danger of pure vibe coding is that you ship code you don't understand, which can hide security flaws (exposed secrets, missing input validation, insecure dependencies), subtle logic bugs, and maintenance debt that nobody on the team can explain later. For anything real, treat the AI's output as a draft from a fast but junior collaborator: read it, test it, and understand it before it goes live.

Originally published on alexi.sh.

DEV Community: ricco020

GitHub says these three repos have no licence. They all do.

The measurement

1. sing-box — GPLv3, plus a clause of its own

2. netbird — BSD-3-Clause, except where it is AGPLv3

3. ZeroTier — MPL, and a nonfree/ directory

What to take from this

Your sysctl says one thing, the kernel says another

Two files, one kernel

Read the effective value, not the file

A small script to stop guessing

While we are here: what hardening does not cover

UFW and WireGuard: the tunnel is up and nothing goes through

The four things to check, in order

1. IP forwarding — and the file that overwrites the other file

2. Forwarding, which is not the same as ingress

3. NAT, which UFW never adds on its own

4. The real name of the egress interface

The test that separates the two families of causes

After applying

Your drive says SMART PASSED and is already failing: the 5 attributes that actually predict it

The five attributes worth reading

Read it in one command

The order of operations, which decides whether you keep the data

What SMART does not tell you

A failed deployment is invisible from the web

The failure mode

The check that actually answers it

The trap that cost me an hour

What actually broke the build

Three things to take away

You don't need to restart WireGuard to add a peer

wg set

The catch nobody mentions

Reloading an edited file without dropping anyone

The failure that looks like magic

What is an API? A clear, practical explainer

What Is a Higher-Order Function? Functions as Values, Explained (2026)

The short definition

The three classics: map, filter and fold

How they replace loops

Returning a function: where it gets powerful

Higher-order functions in Haskell

Why they matter

The honest trade-offs

Frequently asked questions

A Linux box to build and run your Haskell code

MCP Security: The Risks of Model Context Protocol and How to Govern It (2026)

Why MCP is a security problem, not just a feature

The MCP-specific risks in 2026

How to govern MCP safely

The honest takeaway

FAQ

What Is a Vector Database? A Plain-English Guide (2026)

What a vector database actually is

How similarity search works

Vector database vs a normal database

Why it matters for AI

The bottom line

FAQ

What Is a Home Server? A Plain-English Guide (2026)

What a home server actually is

What people run on one

Home server vs a VPS

What you need to start

The bottom line

FAQ

What Is Vibe Coding? The AI-First Way to Build Software (2026)

What vibe coding actually is

Where the term came from

How it works in practice

Where it shines — and where it bites

The bottom line

FAQ

3. ZeroTier — MPL, and a `nonfree/` directory