git clone https://github.com/nixos/nixpkgs

ANTHROPIC_BASE_URL=https://openrouter.ai/api ANTHROPIC_AUTH_TOKEN= claude --model qwen/qwen3.6-plus:free

> This repository has two ways of packaging Nix packages: defining them via pkgs/top-level/all-packages.nix (the old way); or defining them via the pkgs/by-name directory (the new way). Let's port my_example_package over to the new way.

i'm not actually working in the nixpkgs repo -- i'm trying these in a private repo that has very similar structure. i'm also a n00b with these tools, so probably a bad prompt. but Qwen 3.6 actually conflates "the old way" with "the new way", attempts to do the porting in reverse, and just gets stuck. gemma-4 E4B does better. even gpt-oss-120b, an open weight model from a _year_ ago, does the full port unattended.

so either it's shit at coding, or i'm using it wrong. curious to hear other anecdotes.

if there's really nothing more to this 8.8 RCE CVE than that, this will finally be the thing that's makes me blackhole cve.org.

v.s.

> Why hasn’t there been a fork of nixos? And the folks who want to do things in a certain politically leaning way stay and those that don’t gravitate towards that.

now let's spend the next few years arguing which of these is the correct proposition.

sure, it's more complicated: there's questions about _what_ to fork (Nix is an _ecosystem_, not necessarily a single repository), there are certain things which can't trivially _be_ forked (e.g. a multi-hundred-TB S3 cache that's actually critical infrastructure; project websites, wikis, uncountable automation services). how do you coordinate all the details of forking, if forking isn't actually as trivial as pushing the "fork" button? that requires highly capable leaders, and if the ecosystem were good at finding and promoting that type of leader, then it wouldn't be in this place to begin with.

more optimistically, various parts of this ecosystem _have_ been forked, or reshaped, by various entities. things happen; sometimes that happening is just a lengthy process.

if the margins on hosted inference are 80%, then you need > 20% utilization of whatever you build for yourself for this to be less costly to you (on margin).

i self-host open weight models (please: deepseek et al aren't open _source_) on whatever $300 GPU i bought a few years ago, but if it outputs 2 tokens/sec then i'm waiting 10 minutes for most results. if i want results in 10s instead of 10m, i'll be paying $30000 instead. if i'm prompting it 100 times during the day, then it's idle 99% of the time.

coordinating a group buy for that $30000 GPU and sharing that across 100 people probably makes more sense than either arrangement in the previous paragraph. for now, that's a big component of what model providers, uh, provide.

arguing that RSS is dead because the average person doesn't understand it is like saying HTTP's dead for the same reason. neither are dead: we've just abstracted them to the point that they're no longer the front-facing part of any interaction.

well, the con is you might unknowingly break some setups. take NetworkManager: after tightening it down, did you check both IPv4 and IPv6 connectivity? did you check that both the `dns=systemd-resolved` and `dns=default` modes of operation (i.e. who manages /etc/resolv.conf) work? did you check its ModemManager integrations, that it can still manage cellular connections? did you check that the openvpn and cisco anyconnect plugins still work? what about the NetworkManager-dispatcher hooks?

> Why don't distros flip more of these switches?

besides the bit of "how many distro maintainers actually understand the thing they're maintaining well enough to know which switches can be flipped without breaking more than 0.01% of user setups", there's the bit of "should these flags be owned by the distro, or by the upstream package?" if the distro manages these, they'll get more regressions on the next upstream release. if the upstream sets these, they can't be as aggressive without breaking one or two of their downstreams.

on the legal front, there's been some notable "wins" for cryptocurrency advocates: e.g. the U.S. lifted its sanctions against Tornado Cash (the Ethereum anonymization tool) a few months ago.

on the UX front, a mixed bag. the shape of the ecosystem has stayed remarkably unchanged. it's hard to build something new without bridging it to Bitcoin or Ethereum because that's where the value is. but that means Bitcoin and Ethereum aren't under much pressure to improve _themselves_. most of the improvements actually getting deployed are to optimize the interactions between institutions, and less to improve the end-user experience directly.

on the privacy front, also a mixed bag. people seem content enough with Monero for most sensitive things. the appetite for stronger privacy at the cryptocurrency layer mostly isn't here yet i think because what news-worthy de-anonymizations we have are by now being attributed (rightly or wrongly) to components of the operation _other_ than the actual exchange of cryptocurrency.

that's a huge leap! i think most of us gloss over it, but the rest of the article is predicated on that leap.

the tv you're streaming video to probably runs Android by now. it has a stable internet connection, CPU, RAM, and probably a couple USB ports. why not install the Jellyfin server software on it, attach a USB hard drive, and let it be the machine that hosts all your media? why, actually, do you need to go out of your way to buy a completely new machine for this?

similar argument applies to Immich. you're wanting to co-edit an album among several contacts. you're probably all uploading your photos from a phone. why not just have one of your always-on phones host that album? i shouldn't expect the drain on your battery to serve an album to a few friends is that much more than it took to take those photos in the first place.

to a certain degree, you're "self-hosting" things on a physical server because that's the only platform on which we all still have the ability to run arbitrary workloads on. solve that problem and everything becomes a _lot_ simpler.

in my vicinity, the sci-fi discourse has died down the last few months. my coworkers will _show me_ how they use these tools when i ask them, and are building on/with them incrementally. the shift in tone is encouraging. there's space for actual practical discourse around this stuff now. chat about concrete things with your friends/coworkers -- if you're interested in it. ignore the media, CEO interviews and LinkedIn hype posts: they're playing a different sort of game that you're probably happier off not being a part of.

not sure why it's not linked from the README: found it in the repo at website/astro.config.mjs

say, my parents own phones but don't do much on them except navigation, photos, messaging, and web browsing. if you're not into Uber, Doordash, mobile banking, and so on, then you're not really giving up much by switching to the alternatives.

generally, it's harder to _remove_ something from your life than it is to forego _adding_ it. if you're content with the functionality of your tech as it exists today, then a feasible route to de-apple/de-google really is to just not start doing too much _new_ with it, and within some number of years you'll find the alternatives have developed to the point where you can switch to them without going backward.

IA is one of the go-to examples for that. is it good to make every book ever written freely downloadable (as they were trying with their library project a while back), or is that bad? you and i might think the answer is obvious. we might even agree on it. but we would occupy a rather different world if even a supermajority agreed on that question, in either direction.

1. host all services on the residential IP.

2. restrict all clients to a VPN.

because self-hosting for me is more about the sovereignty/autonomy: privacy concerns can weaken that, but inserting a VPN in between you and the other self-hosters weakens that _more_ (arguably). whereas not much is lost by adding a VPN between me and my Google searches.

'course the other thing you can do is to ask a friend to tunnel your traffic. i was pretty reluctant to do that at first, due to uptime concerns, but if you know other self hosters who've been at it for a while then they'll be as invested in keeping that box online as you will. your anonymity pool will be smaller than with a commercial VPN, if that's what you care about, on the other hand if your VPN "provider" gets a call asking to unmask you, you're more sure to learn about that.

why not have `foo` be a shell script which invokes the meta loader on the "real" foo? like:

``` #!/bin/sh # file: /bin/foo

# invoke the real "foo" (renamed e.g. ".foo-wrapped" or "/libexec/foo" or anything else easy for the loader to locate but unlikely to be invoked accidentally) exec meta_loader.sh .foo-wrapped "$@" ```

it's a common enough idiom that nixpkgs provides the `wrapProgram` function to generate these kinds of wrapper scripts during your build: even with an option to build a statically-linked binary wrapper instead of a shell-script wrapper (`makeBinaryWrapper`).

but it's kind of still a weird statement to make. i thought it was generally the OS's job to supply the vulkan layer, and that mesa -- which just about every linux OS will be using -- provides pretty robust software implementations of those things as fallback. what would cause them to require a "physical" anything?