Mx. Aria Stewart

The four horsemen of the apocalypse: War, the leaf blower Plague, the unvaccinated Death, the pickup truck with the high hood Famine, the car alarm

@b0rk@social.jvns.ca The first friction is https://www.w3.org/Provider/Style/URI "Cool URIs don't change" MIME types to identify what kind of thing you're sending on the web have to come from somewhere. What we decided on first was to map filename extensions to them. This means that the filename, usually, became embedded in the URL. And because good URLs shouldn't change, the specific technologies are imprinted with a trace there. At the same time, we moved from frames as a navigational paradigm to includes, because frames are actually kind of a state-keeping nightmare. URLs should also only refer to one thing, and be specific. Framing broke that. Then we moved to dynamic generation and hid filenames because it was mostly includes anyway, and we lost the 1:1 mapping of file to URL entirely, and hosting got an order of magnitude more complicated. In there is the threshold we crossed that influenced design decisions ongoing in ways that keep this hard. That's when we stopped having web pages be _data_ and started having _applications_, running code. Frames, iframes and SSI includes still expressed relationships between information. But online, dynamic generation as the norm crossed into something we can no longer inspect and manipulate as information, only as representations of abstract things hidden inside a machine. That's the second friction: no longer is a "web server" a single pretty comprehensible construct, where they're all pretty similar — a few features here or there for things like content negotiation or include engines, but still roughly the job was "serve data from disk to network" Apache gave way to apache+mod_php gave way to nginx+php-fpm. Now it's TWO services. CGI scripts stopped being dynamic parts of sites, and instead became entire sites. Then the third friction: the abstraction of "the cloud". Excellent for simplifying large applications and scalable resource needs, because now sites exceeded the capacity of single servers regularly, instead of only at the peak scales. The cost though, is that now you have to rent infrastructure for even something simple. There is no 'throw it on the university file server'. The free options are mostly limited to the era of includes and frames. We now call those static site generators. But that means editing the site still requires something, or expertise in code and build systems. We no longer just edit the information. There's always code that comes with it. There's always been things pulling against these currents: CSS yanks us back in a good direction every time it becomes capable of expressing something without needing Turing-complete language. S3 having a way to set the mime type for an arbitrary URL is great. We lost Accept-Language along the way. We lost browser-managed authentication too, since HTTP Basic and HTTP Digest are old and janky now, hard to manage and integrate and secure well, and still lacking a way to "log out" in all current browsers. Inside the new web the old web is still struggling to get out, but it's buried deep. I keep intending to excavate. Haven't managed to yet. But in the end, what we want is to throw a site up and have it stay working. All our choices to this point have made that harder not easier.

Seriously though imagine this kind of creature artistry but with Star Trek writing #monsterdon

If anyone in Ireland is looking for a C++ position, I might know one #getfedihired

This is a tool to COMMUNICATE impact of pain. It's not just expressive, the goal is not just to assign a number, it is to communicate the impact of pain or discomfort to a clinician or caregiver so they can know it needs treatment, and to understand if treatment is working. Accuracy helps that, but remember the point is not to have the NUMBER, but to COMMUNICATE.

It's a great place for a mirror if you know Feng Shui #monsterdon

@b0rk@social.jvns.ca Yes! God the early web was SO WEIRD this way. Servers were at once cheap and expensive: running your own was a matter of stable internet and a spare computer, but stable internet was hard to come by (this is the era of dial-up); universities were reliably fast internet, thanks to efforts like Internet2 and other connectivity programs. Students set up servers in dorms. Grad students and professors often had a box under a desk somewhere, serving pages. IP addresses were real IPs, too, 18.57.23.45 for example, just open to the internet. No NAT, no 192.168.x.y addresses. You just ran Apache and a Linux server and you were off to the races. If you were diligent you turned off sendmail so people wouldn't relay spam through your server. (this is the beginning of email server blacklists!) A friend of mine has been excising the last of these things at MIT the last couple years. Like, in 2025, this was still a thing. (A demand for all university web resources to be properly accessible, and have good certificates has driven this. End of an era.) Many web servers were configured so that http://domain.name/~username/ was mapped to ~/public_html on the server. All you needed was an FTP client and a text editor to write some HTML. No git, no cloud, just a username and password. (And on some badly configured servers, of which there were many, anonymous FTP and writing to some public web directory... or abusing photo-upload CGI scripts to write to the directory they were in) It was very common for someone's ~ directory to outlive them, finally being removed when a server was de-provisioned or migrated to new hardware or in an OS upgrade gone wrong. You can still see this ethos in old unix nerds: https://www.chiark.greenend.org.uk/~sgtatham/ for example (author of Putty, and many puzzle games). Still running on a server running apache and mod_perl in this case. Mine's using newer tech, but I have a server that I started in 1998 (though it's migrated hosts like 11 times and is now a cloud instance instead of being served on a 300kbps DSL circuit in my apartment in Oregon) that still has this: there's a reason my website is https://dinhe.net/~aredridel/ I'm thinking about going back to Apache. Caddy leaves a lot to be desired for this multi-user serving. And the thing about all of this is it was a fundamentally _shared_ experience, before everyone moved to commercial web hosts where the users didn't trust each other at all. I still have friends who share files by "throw it in /pub on the server."

@b0rk@social.jvns.ca Yeah we've managed to make it exhausting, and I've kinda got a trace of technical patterns and decisions that drove us here. It goes back surprisingly far.

RE: https://mastodon.social/@eff/116971060659423351 I have said this is a good idea. Recommendation algorithms are editorializing.

@jcoglan@mastodon.social Yeah, you've fundamentally misunderstood how 'running for hours on end' works. Compaction and other reductions of the context window happen. Things are delegated to sub-agents with their own context windows. This is not unbounded context growth at O^2, this is pretty tightly managed context windows where window^2 is an acceptable number and GPU does go BRR. Nobody is doing billions squared. They're doing, at most, 1M, and usually more like 100k. All of this is made more efficient by attention architectures, too, which reduce that.

@mildpeach@mstdn.social @bich@apobangpo.space Wait least successful per dollar? Citation?

@b0rk@social.jvns.ca I wish there were a step between 'permacomputing and error-correcting-coded-replication-of-data-forever' and 'yolo, if you delete everything from your postgresql database, it's gone'. I think we could make it but we'd have to enumerate the responsibilities and trade-offs.

They shot on location here! #monsterdon

@b0rk@social.jvns.ca I also have been thinking for a while that a constrained "you get 64MB of compute" is actually a really good unit. It packs densely. It's plenty to do some immense tasks. It requires you to not waste resources. It might just be an enabling constraint if providers managed to make it a utility that you could depend on. WASM has a lot of shades of this too. It could, in theory, enable dense dynamic computing for mostly-static sites. The problem is that someone has to take responsibility for the data, or make it _possible_ for users to take responsibility for it usefully.

@b0rk@social.jvns.ca Yeah, though I don't think you need to go that aggressive in many cases. Containerization is pretty solid if not perfect. Non-root containerization like podman is a step again. Having a narrower interface like CGI or FastCGI is again a help. But some of it is that what we want in a platform _just barely_ crosses into what's hard to provide cheaply. Static hosting is _so easy_ in comparison, because it's just data. A trick that might be viable to revive is a relatively common if not standard set of available dynamic tools provided by the host. Users don't get to supply dynamic things but they do get to use the host's. Now that code generation is pretty trivial, the actual economics of that might have changed favorably. (I am always surprised how much LLMs change the economics in ways that enable some old-school things to work now. I'm unsure the net benefits and the whole calculus of it, but there's avenues worth understanding.) The big one however is backups. Modern cloud systems make this the user's problem. Old school hosting made it the admin's problem. Servers as 'cattle not pets' works great when you have a durable data store you back up and snapshot. When you're talking about a bunch of tiny data but that is valuable and should be backed up, things get weird. There's something to be said for the 'servers as pets' mentality there. The fundamental contract there is that Someone Has Your Back With The Data. That's something we've lost, and I think that's bad.

@b0rk@social.jvns.ca Yeah, it wasn't. But also for a hot minute, everyone who had internet access was also like 2 hops from those people at most. They were not hard to find. A couple years later internet access was more pervasive, and things started changing. We see a bit of that ethos poking out here on Mastodon, the community-minded but kinda hard-headed admin of smaller instances brings a lot of the same mindset. And in things like IPFS, too, trying to keep the good aspects without the bad, to mixed effect. I think one of the under-appreciated aspects is that it was FAR FAR cheaper to serve users who vaguely trusted each other and had a person who'd arbitrate abuse, vs the controls you needed to actually have people's accounts be separate and unable to touch each other. Some of that is for stupid technical reasons: FTP servers didn't have controls to confine someone to a root. Shell access was shared, unix permissions not containers as the security primitive. Giving real shell and FTP access was a risk! People broke into parts of systems they shouldn't all the time. Commercial hosts often did complicated chroot things to protect their systems, but that mostly made things slow and janky. So you got much better service if you made friends with someone than if you paid for it. That changed over time, as web servers and FTP servers grew features for mutually-untrusting users. But for a good few years, it was SUCH a better option. (the shared host as slow and janky continues to this day in the form of cpanel servers, which are a direct descendant of this. And the cheap ones oversubscribe their services heavily. The core disk and bandwidth are cheap enough, but the security design is still awful heavy-weight and causes issues. And it's held together by a zillion awful perl scripts. Just like the old days.)

@b0rk@social.jvns.ca Oh whoa I didn't realize 11ty had rebranded. That 'build in browser' is actually really interesting and I think they might be tilting at something good there. I've long thought that S3-flavored storage (only with authentication that doesn't suck with access keys) might be a sufficient foundation for a web builder tool. It could store index data in the bucket too for its operations, and build HTML pages and store them there, ready to directly serve. Something like that could live on top of that pretty easily. The only thing missing from the old ethos is the 'sysadmin mindset' of shared hosting where some curmudgeonly nerd maintained a community host, ruled the technical aspects with an iron fist, but by gum there was no way to stop them if the server went down. The difference was that they were a person, not a platform, and mediating a shared resource. https://m.xkcd.com/705/

RE: https://infosec.exchange/@ifin/116834521039597035 Hot take but TLD-blocking is mostly just enforcing US hegemony. It was that when it was .biz and .xyz that everyone was blocking. Maybe if you're gonna do that get the registrar and block domains based on that.

Here's a couple thought experiments: Would you allow an AI company to make a model trained off your open source licensed work, if the model was guaranteed to be open weights under an MIT-like license, and the training dataset was public? And Do you think that the existing licenses of open source work allow this already? (answers may vary by license)

@moss@kind.social @Texan_Reverend@kind.social Welcome to the start of taking your pain seriously. Time to take it to your doctor, say “I discovered I may have been under-reporting my pain” and go from there.

@b0rk@social.jvns.ca YES! THAT is the space we need to be building toward. There's stabs at it. Turso is making infrastructure kinda that shape for databases. We just need to get more explicit about backups, and expose it to users. Like, that should be a thing that people think about _early_ in choosing who to go with. "I like how their backups work" is a criteria more people should use.

@timbray@cosocial.ca I've been thinking about stuff like this for a while — it's so hard partly because of how the debate has been framed. We're so focused on "is this AI?" that we've lost the relationality we really need to care about. Of course that thinking has a long tradition: we're used to asking "is social media bad?" instead of “what relationships is Instagram turning parasocial?” or “what relationships is Facebook breaking?” When we ask questions of origin about things that should be relational, a surprising amount of trauma is caused, because it blocks the ways we heal and connect. The framing literally keeps us from it.

@fluffy@plush.city Albums OMG. I am so tired of having this gigantic queue of great music but that, when played, is a giant heap of seams. I want to love these artists, but they need to either collaborate or release albums not just tracks. Sometimes you want a single and an amazing video. That's a different art form! Since I listen to more folk, albums make more sense.

@glyph@mastodon.social @be@floss.social @jalefkowit@vmst.io I can tell you a bunch of ways it's different! The economics and attention and reason people participate is much different — there's people who approach both similarly, but by and by large they operate very differently. And ultimately you can, mostly automatically, check if code works. The cost is low. For knitting someone has to MAKE it, and discover it late. The cost in human time is much higher And the vendors around knitting and the vendors around programming are very very different and have different incentives.

@geoffl@mastodon.me.uk That's the thing. That's not really a thing one needs to communicate: if you're at or past 10, there's not really more intervention to do, there's not more seriously to take it. The point is not to give numbers to all possible pain, it's to communicate for intervention.

@swachter@toot.boston Not cheap but if you search for 'union made tees' you'll find a heap of high quality stuff made in the US. Can vouch for "oh that's _different_" (though that's not the same as soft)

@b0rk@social.jvns.ca As much as I love WAL-shipping, I think most people want / need intelligible snapshots and are willing to take the "lost a few hours" hit. Maybe we can do both, but we keep optimizing for five-nines style service, rather than simple-and-low-MTTR.

@b0rk@social.jvns.ca Yeah it's really mixed. I loved the unix culture (I was that nerd and I'm friendly!) and in many cases it was automatically provisioned when you got a university account. In many cases you just asked a friend who had a server under their desk. But it definitely scales funny, it's a very clumpy experience, people are gonna have such different experiences.

@hannah@posts.rat.pictures Guy fighting a lion, like you do. But sure, it's the sea-goat that's the problem

@cR0w@infosec.exchange Thank you for this! I keep meaning to look this up since I knew something like it existed but I have let it slip my mind for years.

Would any of y'all be interested in an archival curation tool that can handle merging large collections of files? I'm in the middle of designing something — git is inspiration but the wrong tool for this job — but that allows reintegrating diverged collections of materials, and propagating enough information that if you were to merge two folders, you'd get a relevant set of questions about the contents to successfully and meaningfully merge them. It's aware of the fact that embedded metadata changes. My goal is to make a library simple enough that one could embed it in an operating system's file browser to surface intelligent behavior, and that it could form the basis of media servers too, taking the scanning-and-recording-files duties.

@adorfer@chaos.social YES IT IS

@misty@digipres.club THIS. There's a reason I'm using a French inference provider.

@Tattooed_Mummy@beige.party Just noticing that things like stubbing a toe are _acutely_ painful — blindingly immediate but don't last — and suspecting that someone who would think of a stubbed toe "as a 10" even though the impact is relatively short lived would also experience noise similarly. The acute nature of the sensation itself is in fact a big part of the disruptive nature of it for you, I suspect.

@me@jaehanley.social Heh. They do this about cars to me. Anything with inarguable upsides, large externalized downsides, and big economic consequences follows this pattern.

@sekomi free himb

@anthra@todon.nl Time to go poke your doctor and say “Hey, today I learned" and show them.

@aphyr@woof.group As a cautious user of LLMs, me too. I'm thinking of making a code review tool that kinda works on the assumption that until you've reread it in the interface, it's generated

@fractalolivia@infosec.exchange Most definitely.

@Cronopio@nrw.social Sure, but there's a bunch of things that could be and pain is not at the top of the list. It is sufficient that someone competent should be asking what's going on though. (that said, it's legit tough: there's a fair bit of psych stuff that looks like that, and emergency is where you see it.)

#monsterdon I miss the days when you could get broken media working by futzing with it instead of "welp, SD card is dead"

@Offbeatmammal@mastodon.social @fishter_uk@mastodon.scot @misty@digipres.club Mistral is such an also-ran. But whose model vs whose inference is actually an important distinction.

@Tattooed_Mummy@beige.party Hazarding a guess: loud, sudden noises are also absolutely awful for you?

Can I build Ladybird under Darling on Linux and then run it on my mac? Let's find out.

@jdlh@mstdn.ca Fixity is at the core: tracking whole-file hashes as primary identifiers, and optionally merkle trees for detecting partial-file changes, and also optionally metadata-excluding hashing for recognizing "same" objects with changed metadata. "Verify this file against known hash history" is a primary operation. Not in scope to add durability like erasure coding, but would potentially support such tools.

@jcoglan@mastodon.social Uhhh... they did. It's called "KV Caching" All of this is both a subject of active research _and_ the constant factor on that O^2 is basically acceptable, and bounded.