daily

2026-08-27
1

New passport rules for sea travel via Rosslare

Wexford Local · original → · 9/10 · Local Wexford: new passport rules for Rosslare ferry travel
[image →]New passport rules will be introduced on the Rosslare ferry routes to Britain from September 28th. (File Pic; WexfordLocal.com) By Dan Walsh Ferry companies Stena Line and Irish Ferries…
[image →]
New passport rules will be introduced on the Rosslare ferry routes to Britain from September 28th. (File Pic; WexfordLocal.com)

By Dan Walsh

Ferry companies Stena Line and Irish Ferries informed customers today (Wednesday) that new passport rules will soon affect ferry travel between Rosslare Europort, Pembroke and Fishguard.

Ferry passengers between Ireland and Britain will need a valid passport from the end of next month, according to requirements of the UK Border Force.

Currently, passengers are not always asked to show a passport but have sometimes been required to have another form of photo ID.

Stena Line said all passengers travelling between Holyhead and Dublin or Fishguard and Rosslare will now need to show a passport on departure and no other forms of ID will be accepted.

It said the rule applies to all passengers regardless of age or nationality.

There is no change to the ID requirements for business or leisure passengers travelling with Stena Line from Belfast, Liverpool, Cairnryan or Heysham.

In a similar statement, Irish Ferries said; “All passengers, including Irish and British citizens, travelling between the Republic of Ireland and Britain (both directions) will be required to carry a valid passport.”

The operator encouraged all passengers to check they have an in-date passport or passport card before arriving at the port.

Under the century-old Common Travel Area agreement, Irish and British citizens do not legally require a passport to travel between Ireland and Britain.

However, certain airlines have required a passport for boarding and the measure for ferries comes into effect from Monday, September 28th.

2

Yellow warning issued for nine counties as heavy rain and thunderstorms forecast

Breaking News Ireland · original → · 8/10 · Local Wexford weather warning: yellow alert for rain/flooding
Six counties are bracing for possible thunderstorms as Met Éireann issued a rain warning for the south-east. There is a risk of localised flooding and difficult travelling conditions in Carlow,…

Six counties are bracing for possible thunderstorms as Met Éireann issued a rain warning for the south-east. There is a risk of localised flooding and difficult travelling conditions in Carlow, Cork, Kilkenny, Waterford, Wexford and Wicklow from midday on Thursday. The status yellow warning expires at 3am on Friday. A separate thunderstorm warning has also been issued for Kerry, Clare and Limerick. The warning came into effect at 4:18pm, and will last until 7pm. Met Éireann said there would be “spells of heavy rain with a possibility of thunderstorms” throughout that period. More generally, it forecast: “Thursday will start off dry in many areas. “Rain across southern fringes will slowly extend to eastern and southern counties, heavy at times with the chance of thunderstorms and the potential for surface flooding. “Drier and warmer across west and north-west counties with some sunny spells, but the odd thundery shower may occur too. Highest temperatures of 18 to 24C.” It added: “Scattered outbreaks of rain will affect the country, locally heavy and thundery, with the potential for some thunderstorms. “However, it will likely become drier across the western half of the country. “Patches of mist or fog may form in light variable, mainly westerly breezes. Lowest temperatures of 13 to 16C.” Scattered showers – some heavy and thundery – appear to be on the cards into the weekend, with the weather agency also advising that current indications suggest “the early days of next week will continue unsettled with rain or showers at times”.

3

CAO process has worked 'reasonably well' for last 25 years

Breaking News Ireland · original → · 7/10 · Irish education policy: CAO university admissions system affecting teenagers
The Minister for Higher Education has praised the Central Applications Office (CAO) process as “fair” and “independent”, but said that pressure points are instead caused by “what it is used for…

The Minister for Higher Education has praised the Central Applications Office (CAO) process as “fair” and “independent”, but said that pressure points are instead caused by “what it is used for afterwards”. It comes as the CAO issued 90,866 round one offers to 62,166 applicants. These offers consist of 56,618 level eight course offers and 34,248 Level 7/6 course offers. Some 48% of level eight offers are for the applicant’s first preference course, and 76% of level eight offers are for one of their top three preferences. Applicants are allocated places in courses ranked in order of their performance in the Leaving Certificate. Earlier on Wednesday, students, parents and teacher groups called for a reform of the CAO points system, with some describing it as creating a “pressure cooker effect”. Minister for Higher Education James Lawless said it is a system that has worked “reasonably well” for more than 25 years. The Government made a commitment in the Programme of Government to reform the CAO system. Mr Lawless said he has reform plans in place but would not disclose them during a press conference on Wednesday about the CAO offers. “It’s no secret that I have begun an examination of the broad education, the idea of creating more avenues into education, more foundational modules in first year and moving on to more specialist options in second year and beyond,” he said. “I think that there’s work we can do, but we’re already doing that, the likes of the tertiary degree, so there are 68 programmes still accepting applicants outside the CAO completely. “So any student who might be disappointed today can still get a tertiary degree, even today, tomorrow they can go and apply for those. “There are many pathways through the system. That is a significant reform already.” “The benefits of the CAO process is it is completely independent. It’s divorced from any influence or persuasion. We see in some jurisdictions where word of mouth or people you know can influence the process. The CAO is a mathematical computer-based process. It is not perfect, but it is extremely fair. “In terms of students applying, they are based on examination results. They come through the system; they are done on points and come through the automated system. It’s a fair and transparent mechanism. “It’s a system we’ve had for 25-plus years. It’s worked reasonably well. “These days there are so much more than the Leaving Cert being the avenue to go forward. “It should never be seen as a second or third best; it is equally valid and rewarding.” He added: “It’s not so much the CAO process, it’s what it’s used for afterwards that creates the pressure point. “The actual system of examination, of adjudication, continued assessments, and the transparency and independence of it all we should value, something that is strong and proven the test of time. “The Leaving Cert is respected internationally for decades and that is a good thing that we should preserve and respect. But what we do with those results afterwards and if they are the only ticket into a course, then that can be problematic and that is one of the reasons we have expanded pathways repeatedly. “One of the issues I will look is that students could benefit from being exposed to a wider range of disciplines in their early years.” Mr Lawless said he is aware of the organisations who have made the call to reform the system, and invited them to write to him, saying he will meet with them. Among the groups was Children’s Rights Alliance, which said the Leaving Cert and the CAO process were times of “stomach-curdling dread”. Tanya Ward, chief executive of Children’s Rights Alliance said: “Mounting stress, anxiety and sleepless nights result in a ‘pressure cooker effect’ that boils over every year. “Maintaining an archaic and anxiety-inducing system to preserve the prestige of university league tables and a hierarchy of professions flies in the face of what our education system should be about. “The Government promised this review when entering office, and now as we approach halfway of that term and a new school year, we want to see some follow through.” Harrison Rossiter McGuire, Uachtarán of the Irish Second Level Students’ Union (Issu) said the CAO system represents “one of the biggest needs for change in Irish education”. “On a global scale, the CAO is a unique system of college application. “It makes no account for extracurricular activities and purely focuses on academia with more subjects than other countries, which drive stress and burnout,” “While there is a large number of courses that require a specific grade in certain subjects, many courses don’t have this and simply require a certain number of points, which can lead to students picking subjects not out of passion but out of perceived ease or ‘gameability’.” Their views were supported by the National Parents’ Council, the Teachers’ Union of Ireland and the National Association for Principals and Deputy Principals.

4

Pnpm 12.0

Hacker News · original → · 7/10 · Work/tech: pnpm 12.0 Rust rewrite, networking/platforms relevant
pnpm 12.0 pnpm 12 is stable. It is a rewrite of pnpm in Rust, and it is deliberately not a migration: the commands, flags, settings, and lockfile format of pnpm 11 all carry over, and the…

pnpm 12.0 pnpm 12 is stable. It is a rewrite of pnpm in Rust, and it is deliberately not a migration: the commands, flags, settings, and lockfile format of pnpm 11 all carry over, and the documentation describes both versions. The short list of things that genuinely behave differently is in What's different in pnpm 12. This post covers what pnpm 12 adds that pnpm 11 never shipped. latest on npm still points at the pnpm 11 line, so pnpm 12 is installed from the next-12 tag: pnpm self-update next-12 See Installing pnpm 12 for the other ways, including without Node.js. Homebrew, winget, Scoop, and Chocolatey don't offer it yet. Breaking changes Git dependencies are identities For repositories on GitHub, GitLab, and Bitbucket, a specifier now names a repository rather than choosing a transport. github:owner/repo , owner/repo , git+https://… , and git+ssh://git@… all resolve through the host's canonical HTTPS URL, and the lockfile never records an SSH URL for those hosts. To reach a private hosted repository over SSH, configure the machine with git's own URL rewriting: git config --global url."git@github.com:".insteadOf https://github.com/ pnpm shells out to git , so the rewrite applies to all of its git operations. Unknown hosts keep their exact URL, SSH included, and a URL with embedded credentials is kept verbatim and never resolves to a host archive. Details in How git dependencies are resolved. An unrecognized setting in pnpm-workspace.yaml is reported A setting pnpm does not recognize used to be ignored in silence — a misspelled minimumReleaseAge dropped the policy it was meant to set, and nothing said so. It is now reported, with the closest real setting name suggested when the key looks like a typo. It fails the command with ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS when the project pins a pnpm version the running pnpm satisfies: with the pin honored, the setting cannot have been meant for a different pnpm version, so it is a mistake to fix rather than a key to ignore. Everywhere else it is a warning, so a project that has yet to be cleaned up keeps working. The pnpm config subcommands never fail on it, so a broken file can still be inspected and repaired. Lockfiles of cyclic dependency graphs Dependency cycles are now broken canonically during peer resolution: the members of each cycle are ordered by package id, and the edges that close a cycle are always cut at the same place, wherever the installation walks into the cycle from. The lockfile therefore becomes a pure function of the dependency graph — reordered importers, reordered dependencies, and repeated installs all produce byte-identical lockfiles, which they could not before (#13846, #13865). On large cycle-heavy workspaces peer resolution is 2–3× faster, uses about 25% less memory, and produces a substantially smaller lockfile. Existing lockfiles keep working: --frozen-lockfile consumes them unchanged, and an install that skips resolution leaves them untouched. The first install that actually re-resolves re-keys the walk-order-dependent peer variants of cyclic packages once. See How peers are resolved. packageImportMethod: auto hardlinks first on Linux A reflink materializes a new inode and copies extent bookkeeping inside the filesystem's metadata trees, where a hardlink is one directory entry — on btrfs that roughly halves the time an install spends materializing node_modules from a warm store. So on Linux, auto now tries the hardlink first. ext4 is unchanged (cloning was never supported there, so auto already hardlinked), and macOS keeps clone-first, where APFS clonefile is the platform's cheap primitive. On Linux, cloning becomes the second rung rather than the first, so a store that refuses a hardlink still gets a clone; packageImportMethod: clone still asks for one outright. engineStrict follows the edge, not the subtree Under engineStrict , an install now fails when an incompatible package is reached through a regular dependencies edge of an installable package, even when that whole subtree hangs off an optionalDependencies entry. pnpm 11 installs the package and emits an install-check warning instead. Packages reachable only through optional edges, or through a package that was itself skipped, are still skipped in both versions (#13286). New features Not all of these are exclusive to pnpm 12. Registry revisions, the remote side-effects cache, audit.ignorePrune , batch staged approval, and the pnpm init latest-tag pin ship in pnpm 11.25 as well; the rest are v12 only, because they belong to the Rust rewrite. Project-aware global bins A globally installed node , deno , or bun follows the version the current project pins, instead of always running the globally installed one — no shell hooks, no use -style command. The new globalShims setting picks which globally installed packages get such a shim; it defaults to { node: true, deno: true, bun: true } and merges key-wise, so globalShims: { typescript: true } adds one without restating the rest. A stable Node.js release is authenticated against the Node.js release team's signatures and switches without asking. Everything else — Deno, Bun, Node.js prereleases, ordinary package bins you enable — asks Do you trust this project? once per project and per candidate, and remembers the answer machine-locally. PNPM_SHIM_BYPASS=1 bypasses the feature for one invocation. See Project-aware global bins. pnpm installs the other package managers pnpm now provisions npm, Yarn Classic, Yarn Berry, Yarn 6 (yarnpkg/zpm ), and Bun, each fetched through the trusted package-manager registries, and each npm-published one verified against npm's signature for its exact version before it runs. Three things use it. A git-hosted dependency is prepared with the package manager it asks for, so a repository built with Yarn installs on a machine that only has pnpm. pnx runs one for a single command — pnx yarn@4 install , pnx npm@11 ci , pnx node@22 . And pnpm shim add yarn links a yarn that runs whatever the current project pins. Naming a package manager therefore means the tool rather than the npm package that shares its name: pnpm add -g yarn@4 installs Yarn Berry, and in a project pnpm add yarn@4 records "packageManager": "yarn@4.18.0" — what Corepack reads — while every other package manager is recorded in devEngines.packageManager . A specifier that locates a package still installs what it names (pnpm add yarn@npm:yarn@1.22.22 ). See Other package managers. Registry revisions A registry can serve a replacement artifact for an already-published version — a rebuild with a vulnerability patched out — without changing the version number and without rewriting the bytes the canonical name@version URL has always served. pnpm calls each such artifact a revision, addresses it by its complete SHA-512 digest, and records it in the lockfile as one extra line: packages: lodash@4.17.21: resolution: integrity: sha512-<replacement-digest> revision: 1 An entry with no revision is revision 0, the original — which is what every entry pnpm has ever written means, so a lockfile that has adopted no replacements is byte-identical to today's. A dependency or override may pin a revision explicitly as <version>+rN , and pnpm update --patches refreshes the locked artifacts without changing a single version. pnpr serves revisions for the packages it hosts and proxies them for an upstream registry that advertises them. See Registry revisions. pnpm init pins the latest pnpm pnpm init pins the latest released pnpm rather than the version that ran the command, so a project scaffolded by an outdated pnpm no longer inherits that staleness through its own pin (#7490). If the latest lookup cannot answer — no network, a slow registry, offline , or a latest that minimumReleaseAge or trustPolicy rejects — the running version is pinned as before. The lookup never fails or hangs the command. Batch approval for staged publishing pnpm stage approve approves several staged packages at once. Run it with no stage id to pick from the staged versions interactively, or pass a list. The whole batch is approved with a single one-time password, and pnpm asks for a new one only once the registry stops accepting it. Inside a workspace the packages are approved in dependency order, and one whose workspace dependency could not be approved is skipped rather than published against a dependency that never reached the registry. audit.ignorePrune Set audit.ignorePrune: true and pnpm audit --fix removes the ignored GHSA entries that no longer appear in the audit report, so a list of tolerated advisories stops accumulating entries for dependencies that are long gone. Global commands refuse to run under sudo pnpm setup , pnpm self-update , and any command that modifies the global installation now fail with ERR_PNPM_SUDO_NOT_SUPPORTED under sudo , instead of silently operating on the root user's home directory. pnpm keeps global packages and configuration in the invoking user's home, so these commands never need root. Read-only global commands such as pnpm bin --global still work. A remote side-effects cache (proof of concept) An opt-in proof of concept lets installs reuse a dependency's build output across machines, by publishing and restoring signed, organization-scoped artifacts through pnpr instead of running the lifecycle scripts locally. A repository names only the eligible remoteSideEffectsCache.organization and packages ; everything describing the act of signing is refused in pnpm-workspace.yaml and read from the global config file or the environment instead, so a cloned repository cannot turn the machine's key into a signing oracle. Every cache failure falls back to the ordinary local build. It restores on Linux/glibc x64 and arm64 only for now — see Shared side-effects cache. Fixes worth knowing about The compatibility database drops its static-analysis entries The built-in compatibility database no longer adds dependencies that were detected by static analysis of published packages. Those entries named packages a dependent only imports for its types, so installing them was at best unnecessary and at worst broke the dependent: @typescript-eslint/types gained a typescript dependency resolved to the newest release, which put TypeScript 7 under older @typescript-eslint versions and made ESLint fail with Cannot read properties of undefined (reading 'Intrinsic') . The @yarnpkg/extensions entries and pnpm's own curated ones stay. A store inside the project when nothing above it is linkable When no directory above the project accepts a hard link — an AI agent sandbox that grants write access only to the project, or a container with just the project mounted writable — the default store is created at <project>/node_modules/.pnpm-store instead of in the pnpm home directory. In those environments the home store is either read-only or on another volume, which forces every package to be copied instead of hard linked (#13525). The filterLog pnpmfile hook is deprecated pnpm 12 ignores hooks.filterLog and warns when a pnpmfile defines it. Use loglevel to choose how much pnpm reports. Feedback Please report any issues you run into.

5

Tailcat – Like netcat, but over Tailscale’s data plane

Hacker News · original → · 7/10 · Work/tech: Tailcat networking tool over Tailscale data plane
"Tailscale without Tailscale, by Tailscale" Tailcat is a remix of Tailscale open source pieces to act like netcat, but over Tailscale's data plane, without Tailscale's control plane. Tailscale's…

"Tailscale without Tailscale, by Tailscale" Tailcat is a remix of Tailscale open source pieces to act like netcat, but over Tailscale's data plane, without Tailscale's control plane. Tailscale's data plane (magicsock , internally) gives you point-to-point WireGuard®-encrypted tunnels between two machines with DERP as the NAT-hole-punching communication side channel and the ultimate relay-of-last-resort if NAT traversal fails. Instead of using the Tailscale control plane, all tailcat connection metadata is exchanged out of band, however you want. The tailcat CLI (in cmd/tailcat ) is built on the tailcat Go library (importable as github.com/tailscale/tailcat ). Whether you use tailcat as a CLI tool or library, one side runs a tailcat server (listener) and gets back a short connection token. The other side passes that token to tailcat 's client side to connect. All traffic between the two is encrypted end-to-end with WireGuard. The initial connection bootstraps through a DERP server (see below), and then magicsock performs NAT traversal to upgrade to a direct peer-to-peer UDP connection when possible (usually!). You don't need a Tailscale account, root/admin access on the machine (it doesn't alter your machine's routing tables, DNS, etc.). It's just a userspace library and CLI tool. And it's all open source. You can use our free rate-limited DERP relays (the default DERP map is https://tailcat.dev/derpmap.json) or you can run your own. There's also an experimental in-browser web demo (tailcat compiled to WebAssembly) at https://tailscale.github.io/tailcat/ that can send and receive files or text, interoperating with the CLI. Browser traffic is relayed over DERP only, with no direct connections until WebRTC support (#4). $ go install github.com/tailscale/tailcat/cmd/tailcat@latest Or with Nix flakes, run it directly or install it: $ nix run github:tailscale/tailcat $ nix profile install github:tailscale/tailcat Server starts, printing out its ephemeral address: $ tailcat # Selected bootstrap relay region 302, San Francisco # 🐈 Server listening with new address: tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu (hangs, waiting...) And then the client can: $ echo hello | tailcat tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu $ Then the server unblocks: $ tailcat # Selected bootstrap relay region 302, San Francisco # 🐈 Server listening with new address: tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu hello $ Or you can serve a local TCP port, forwarded to localhost: $ tailcat --serve=8080,8443 # or --serve=all # 🐈 Server listening with new address: tcXXXXXXXXX And then the client: $ tailcat tcXXXXXXXXX 8080 GET / HTTP/1.1 Host: foo HTTP/1.1 200 OK .... On Linux and macOS, you can run an SSH server too with no auth. (If you want auth, you can just tailcat --serve=22 and proxy to your system SSH server) $ tailcat --serve=no-auth-ssh # 🐈 Server listening with new address: tcXXXXXXXXX And on the client side: $ tailcat ssh tcXXXXXXXXX $ tailcat ssh tcXXXXXXXXX ls -la Ping to test connectivity; each pong reports whether it arrived via a DERP relay or a direct path. --until-direct keeps pinging (up to --timeout , default 10s) until a direct path works, exiting non-zero if one doesn't: $ tailcat ping --until-direct <token> pong in 42.1ms via DERP(sfo) pong in 1.2ms via 203.0.113.7:41641 Run a command through a SOCKS5 proxy routed over the tunnel: $ tailcat socks <token> curl http://server.tailcat:8081/ Tokens also work directly as URL hostnames: the SOCKS proxy recognizes and dials them, so the token argument is optional. (Tokens are case-sensitive; this works with curl and most CLI tools, but not with browsers, which lowercase hostnames.) $ tailcat socks curl http://<token>:8081/ Act as an exit node so the client can reach the server's network: $ tailcat --serve=exit-node Parse a connection token and print its contents (the server's WireGuard public key and DERP info) as JSON, without connecting to anything: $ tailcat parse tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu { "ServerPublic": "nodekey:9c8d2e6728da80a1dd37e275a82595b42d9a838610bc53f74a7670d1610f2e34", "RegionID": 302 } Resolve a short token (which references a DERP region by ID, requiring clients to fetch the DERP map) into a longer self-contained one with the DERP server info embedded, letting clients connect more quickly: $ tailcat resolve tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFygaFhToGjYWhudGMzMDJhLmlwbi5kZXZhNG0yMDguMTExLjM5LjM4YTZzMjYwNzpmNzQwOjA6M2Y6OjcyMA Parsing that resolved token shows the embedded DERP info: $ tailcat parse tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFygaFhToGjYWhudGMzMDJhLmlwbi5kZXZhNG0yMDguMTExLjM5LjM4YTZzMjYwNzpmNzQwOjA6M2Y6OjcyMA { "ServerPublic": "nodekey:9c8d2e6728da80a1dd37e275a82595b42d9a838610bc53f74a7670d1610f2e34", "Region": [ { "Nodes": [ { "HostName": "tc302a.ipn.dev", "IPv4": "208.111.39.38", "IPv6": "2607:f740:0:3f::720" } ] } ] } A server can print the long self-contained form directly with the --full-address flag. A server's address (connection token) is derived from its WireGuard key, so the key you use determines who can reach you: - Ephemeral keys (the default): each server run generates a fresh key in memory and prints an address nobody has ever seen. When the process exits, the key is discarded and the address is dead forever. This is the safe default: sharing that address only ever refers to that one run. - Saved keys: tailcat genkey generates a key saved to disk so the address stays stable across restarts. The flip side: anyone you've ever shared that address with can connect to any future server using that key, unless you restrict clients with--allow (seetailcat genkey --client ). The CLI says at startup which kind it's using, so you know whether you're starting a fresh single-use server or re-listening on an address you may have shared in the past. $ tailcat genkey --region=nyc # prints the token; key saved to ~/.config/tailcat/keys/default.private.json # later; the key named "default" is used automatically once it exists: $ tailcat --serve=8080 # 🐈 Server listening with saved key "default": tcXXXXXXXXX # ... unless you force a one-off ephemeral key: $ tailcat --serve=8080 --key=new # 🐈 Server listening with new address: tcXXXXXXXXX That is, default is a magic key name: once it exists, plain tailcat silently uses it instead of generating an ephemeral key, and the startup line above is what tells you which happened. Use --key=new to get an ephemeral key anyway, --key=<name> to use a different saved key, or tailcat genkey --delete --key=default to remove the saved default key. tailcat genkey --list lists your saved keys. Tokens can also be published as DNS TXT records and looked up by name; a DNS name works anywhere the CLI takes a token: # If example.com has a TXT record "tailcat=tc..." $ tailcat example.com 8080 $ tailcat ssh example.com $ tailcat ping example.com Who needs port forwarding or port knocking? This runs an SSH server reachable from anywhere by name, with no open inbound ports on the server, where WireGuard authenticates the client before the SSH server ever sees a packet. On the client machine, generate a client identity keypair. It prints the public key, which is all the server needs to know: client$ tailcat genkey --client # wrote file to ~/.config/tailcat/keys/client-default.private.json nodekey:cfb6bfa77a0654d7450947fd6acef17d2cd848da1d30b2540b13dac272ddfd16 On the server, generate a server keypair pinned to its nearest DERP region (see why below), then serve SSH to only that client: server$ tailcat genkey --fixed-region # wrote file to ~/.config/tailcat/keys/default.private.json tcXXXXXXXXX server$ tailcat --serve=22 --allow=nodekey:cfb6bf...ddfd16 # 🐈 Server listening with saved key "default": tcXXXXXXXXX Publish the token in DNS as a TXT record: my-server.example.com. 300 IN TXT "tailcat=tcXXXXXXXXX" And then the client side is just: client$ tailcat ssh my-server.example.com Client modes automatically use the saved client-default key when it exists, so no extra flags are needed to present the allowed identity. Anyone else's handshake is silently ignored: they can't reach the SSH server, or even learn that one is running. Why --fixed-region : it discovers the nearest DERP region once, at genkey time, and bakes its ID into both the printed token and the saved key file, so server restarts bind to the same region (keeping the published token valid) without re-probing. Plain tailcat genkey defaults to --region=auto , which instead bakes in "pick at startup": fine for one-off use, but a token published in DNS should name a fixed region so clients and future server restarts all rendezvous in the same place. (--region=<name> pins an explicit one instead; --region=list shows the choices.) TODO: make the client more robust here if the DERP map changes over time: #7 Nothing requires Tailscale's relays: run your own DERP server (it needs a hostname with a TLS certificate, which derper can get itself via Let's Encrypt), then generate a server key that uses it by passing its hostname (or several, comma-separated) as the region: server$ tailcat genkey --region=derp.example.com tcomFwWCCAIsKOqPUux6ClG2RM4A_vOq4VBzGgHGGjq9OsJuFKSWFygaFhToGhYWhwZGVycC5leGFtcGxlLmNvbQ server$ tailcat --serve=22 The token embeds your relay's hostname: $ tailcat parse tcomFwWCCAIsKOqPUux6ClG2RM4A_vOq4VBzGgHGGjq9OsJuFKSWFygaFhToGhYWhwZGVycC5leGFtcGxlLmNvbQ { "ServerPublic": "nodekey:8022c28ea8f52ec7a0a51b644ce00fef3aae150731a01c61a3abd3ac26e14a49", "Region": [ { "Nodes": [ { "HostName": "derp.example.com" } ] } ] } so clients need no extra flags and never contact Tailscale's DERP map server or relays, and the only rate limits are yours. Alternatively, if you run a whole fleet of relays, serve your own DERP map JSON and point both sides at it with --derpmap-url . A minimal server that answers any TCP port through the tunnel and prints its token. The zero value Server picks defaults for anything unset: a fresh ephemeral key, the nearest region of the default DERP map, and log.Printf logging (set Logf to logger.Discard for quiet): package main import ( "fmt" "log" "net" "github.com/tailscale/tailcat" ) func main() { s := &tailcat.Server{ OnTCP: func(port uint16) func(net.Conn) { return func(c net.Conn) { fmt.Fprintf(c, "hello from port %v\n", port) c.Close() } }, } if err := s.Start(); err != nil { log.Fatal(err) } fmt.Println(s.ConnBlob()) select {} } And a minimal client that dials it, given that token as its argument. Like Server, the Client zero value works with just its Server token field set (tailcat.NewClient is shorthand for exactly that), and the tunnel is established lazily by the first dial: package main import ( "context" "io" "log" "os" "github.com/tailscale/tailcat" ) func main() { cl := tailcat.NewClient(tailcat.ConnBlob(os.Args[1])) defer cl.Close() c, err := cl.DialTCPPort(context.Background(), 80) if err != nil { log.Fatal(err) } io.Copy(os.Stdout, c) } $ ./client tcomFwWCAWf933BLELdzd3RkHiOufJ... hello from port 80 A Tailcat server is identified by a connection token (called a ConnBlob internally). It looks like tcXYZ... and is a "tc" prefix followed by base64-encoded CBOR containing: - The server's WireGuard public key (Curve25519, 32 bytes) - DERP info. Either: - a small integer referencing one of the default Tailscale-run tailcat servers), or - full DERP server metadata, to either use a custom DERP server, or to avoid the client needing a potential round-trip to fetch the latest DERP map (the server's --full-address flag and thetailcat resolve subcommand produce this form) A typical token with just an integer region ID is around 50 bytes. With embedded DERP node details it's longer but self-contained. Tailcat reuses Tailscale's client networking components but without the control plane. - WireGuard -- a userspace WireGuard implementation for encrypting all tunnel traffic. It doesn't use a kernel TUN/TAP device (nor does it configure any networking routes or DNS settings), so root isn't required. - magicsock -- Tailscale's transport layer that multiplexes traffic over direct UDP and DERP relays. It handles STUN-based endpoint discovery and UDP hole-punching for NAT traversal. - Netstack (gVisor) -- a userspace TCP/IP stack that terminates TCP connections inside the process. This is what lets Tailcat accept inbound connections and dial outbound ones without any OS network configuration. - DERP relay -- Tailscale's encrypted relay protocol, used as a rendezvous channel and as a fallback data path when direct connectivity isn't possible. - Server starts. It generates (or loads) a WireGuard keypair, connects to a DERP relay, and prints its connection token to stderr. It then waits for clients. - Client parses the token to learn the server's public key and DERP region. It generates its own ephemeral keypair and connects to the same DERP relay. - Discovery handshake. The client sends a "Meow" ping message to the server through the DERP relay. This message carries the client's node public key. The server receives it, adds the client to its WireGuard peer list and network map, reconfigures the WireGuard engine, and replies with a "Meowed" acknowledgment. - WireGuard tunnel. With both sides configured as WireGuard peers, the standard WireGuard handshake proceeds (routed through DERP initially). Once complete, the tunnel is up and encrypted traffic can flow. - NAT traversal. In parallel, each side advertises its UDP endpoints (public IP:port learned via STUN, plus local interface addresses) to the other in disco call-me-maybe messages over DERP, re-advertising whenever they change. Both sides then run Tailscale's disco protocol and attempt UDP hole-punching. If successful, traffic upgrades from the DERP relay to a direct peer-to-peer path. If hole-punching fails, DERP continues as a fallback and the connection still works, just with rate-limited throughput if you're using our public hosted DERP relays. - Data transfer. The client dials a TCP port on the server through the tunnel. gVisor's TCP/IP stack on both sides handles connection setup. On the server, the incoming connection is dispatched to a handler based on the port: forwarding to localhost, piping to stdout, running an SSH session, etc. Each peer currently derives a deterministic IPv6 address from its WireGuard public key, but that's an implementation detail not exposed to end users and might change. (e.g. we might remove those bytes from the IP headers entirely and recover that redundant MTU) Tailcat is free to use, but it comes with no API or CLI stability promises: the Go API, the CLI flags and output, and the wire format may all change. The public rate-limited Tailcat DERP relays have no uptime SLAs or throughput targets, and we may revoke access to them at any time, for any reason. Everything is provided best effort, without a contractual relationship (e.g. dedicated DERP relays and/or support) saying otherwise. If you don't want to run and support things on your own, or want any help, contact sales and we can exchange money for goods and services. Tailcat began life in September 2023 as "derpcat", written on a long flight while catching up on bad movies: the first sketch was commit 9e4d925cc ("cmd/dc: start of derpcat tool"), and it first worked in commit 911915fbb ("derpcat: it's alive!", whose commit message notes "UA 605 PDX-ORD en route to Ireland. yay not buying the wifi."). Back then it lived inside a fork of the tailscale.com repo and it bitrot several times as the Tailscale internals moved on without it. We've since brought it back to life and refactored it to be a regular Go module client of the tailscale.com repo instead of a fork of it. It was open sourced August 2026 at the TailscaleUp conference.

6

Qwen3.8-Flash-Next

Simon Willison · original → · 7/10 · AI: Qwen3.8-Flash-Next multimodal MoE model
26th August 2026 - Link Blog Qwen3.8-Flash-Next (via) Another open weights model from Qwen. This one is "a multimodal MoE model that also serves as an early preview of the architecture used in…

26th August 2026 - Link Blog Qwen3.8-Flash-Next (via) Another open weights model from Qwen. This one is "a multimodal MoE model that also serves as an early preview of the architecture used in Qwen4". It's pretty big: 125B tokens, but only 6B active which means it gets a significant performance boost. I've been trying it out on a DGX Spark using these Unsloth quantized models. I'm still exploring the model - so far I've tried the 72.5GB UD-IQ1_S one (producing these pelicans) and the 78.9GB UD-Q2_K_XL (producing these). My favorite so far was this xhigh reasoning effort one from UD-Q2_K_XL: Recent articles - Conceptual integrity and counting lines of code - 19th August 2026 - Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things - 16th August 2026 - Now we have a timeline of the OpenAI accidental attack against Hugging Face - 7th August 2026

Items scoring 7/10 or above from 11 sources, scored by claude-haiku-4-5-20251001 on relevance to my interests. At most 3 per source.

Scoring categories & sources
  1. Local Wexford or South East Ireland news
  2. Irish or EU-wide affairs affecting citizens broadly: elections, new laws or policy being debated, cost of living, education — especially impacts on mid-life adults or teenagers. Never courts/crime stories.
  3. Irish news on a topic relevant to my interests
  4. Work and tech topics: networking, AI, Kubernetes, platforms, SaaS
  5. AI news including critical or anti-AI perspectives
  6. Gaming: PC gaming, indie gaming, retro gaming
  7. General interests: gardening, woodwork, cycling, fitness, travel
  8. Comics

Sources: Breaking News Ireland, Wexford Local, Hacker News, r/gaming, r/pcgaming, r/antiAI, r/indiegaming, Lenny's Newsletter, One Useful Thing, Newcomer, Simon Willison

Comics

Trade

XKCD · view →
&quot;You legs may have a comparative advantage at running, but we arms have a competitive advantage at swinging hammers, so unless you accept that we

&quot;You legs may have a comparative advantage at running, but we arms have a competitive advantage at swinging hammers, so unless you accept that we