queerlilhayseed

Yup, ollama, various models. I initially downloaded it because I, along with thousands of other people, wanted to see what would happen if I made models debate with each other after RAGging them with various books (The Prince, The Art of War, The complete works of Shakespeare, etc.).

The results were uninteresting and I abandoned the project pretty quickly. I’ll sometimes use them for code analysis but they’re too slow on my rig to be really useful.

yeah it’s not a great design. It could easily be a line graph where the the vertical axis is a log scale representation of each day’s uptime . You’d still be able to tell at a glance which services are stable (top marks across the board) and which services have dips. you could even still have the line change colors when it dips below a certain range if you just really wanted colors on it. it would even zoom infinitely* since the horizontal axis can be arbitrary buckets of time, and the vertical axis is always 0%-100% uptime

• down to whatever your health check interval is, at which point the graph would just alternate between 0% and 100%, and up to the full lifetime of the service. still, it could be nice for analyzing some service failures.

The whole paper is full of bangers. I like to imagine that he nailed it to the door of the university library.

About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.

Projects promoting programming in “natural language” are intrinsically doomed to fail.

Simplicity is prerequisite for reliability.

EWD found an optimal path to my heart. He’s one of my all-time favorites.

For anyone unfamiliar with Dr. Dijkstra’s work in the field of psychotherapeutic COBOL: https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

In this fast-paced modern life, I find that I have too many complex thoughts in my head all the time. Thanks to Dr. Dijkstra’s patented COBOL regimen, my brain is free and clear of any thought complex enough to hurt it. Thanks COBOL!

They have always reminded me of bright line spectrographs. Now that you mention it I see the resemblance to DNA tests too.

I think that’s how a lot of the internet is dying right now because buying an IP then wringing every drop of value out of its dying corpse before dropping it is a good way to make money right now. This is very much a thing that happens outside of the internet too, and happened long before the internet existed. I think one of the cool things about the internet is how quickly word can spread about this kind of compromised company / product / whatever thing, though I think we need to get better at it. I’m not exactly sure how to accomplish that, it seems like an overwhelming problem, but I think about it a lot.

At one place I worked we had a service that had been part of an acquired company that, as far as I could tell, had no one responsible for maintaining it, and it either zero or almost zero users, so it would go down for weeks at a time before somebody noticed and did something about it, usually because it needed a security patch. To this day I have no idea why it wasn’t shut down but AFAIK it’s still out there causing problems for whoever works there now.

We came up with a bunch of ways to describe its uptime: a service has one fortnine of reliability if it stays up for at least one continuous fortnight of the year, for instance. An absolute nine is nine days per year. Fractional nines were invented: a “quarter nine” was 25% of 90%uptime, or 22.5% total uptime.

Yeah that’s fair. It’s part of the advertising in some sectors, but not all. A lot of the companies I’ve bought products from tend to advertise their uptime, and that’s the type of company I think about when I think about uptime stats. However, a lot of the companies I’ve sold products to tended to not talk about it, and their uptime was often in the 2 nines to 3 nines, if not a lot worse. Somehow they still managed to keep going lol. Some of them anyway.

Oh sure, there will always be museums and monuments with little slices of the internet that was, but for the most part, the urge to repurpose old resources to new endeavors means that some parts of the internet will always fade away. I don’t know if we’ll ever start preserving it perfectly but we certainly aren’t there yet.

Server / service downtime. For a well managed company, you would expect these to be almost uniformly green, meaning that all servers are responding correctly almost all of the time. This graph has a lot of yellow and red, indicating severe instability in their services.

Not being able to keep servers running is something that typically happens to smaller companies that grow too fast for them to manage. Established companies are (or, IMO, should be…) expected to have near perfect (>99.99%) uptime, and this is indicative of some expertise loss for the company broadly.

It never occurred to me before now but from here on out, there will probably always be some old part of the internet, crumbling and sparse, moldering and broken, populated by far fewer denizens than it was designed for.

I wonder if that’ll just be the ever-fading “old folks” internet.

We’re watching the old internet fall apart.

Same

Requests per second getting higher, and higher, then they level out – but the server is just barely hanging in there, frantically serving as many requests as it possibly can, and then all at once they come crashing down into warm, gentle waves of relaxing human pings.

it follows the pattern of a tree, you can only reach further up if your roots are deep enough to support it.

I like this, gonna steal it for explaining research to new coders.

I think the design of interfaces is a difficult and subtle art. You have to have a very refined understanding of both of the layers being interfaced, so you can understand where the boundary should go and what shape it should have so concepts don’t get split across layers. You also need to have a keen understanding of how the humans using the interface will behave in the future, which is really hard and often impossible. I think that’s why interfaces tend to evolve over time along with the tech, because assumptions built into them were either incorrect, or became incorrect (or just confusing) as the technical landscape shifts around them.

Speaking of shifting landscapes, I think one of the fundamental practices of engineering is prototyping: building a thing that does what you think you want, even if it’s janky or unscalable or has an insane cyclomatic complexity or w/e. Sometimes building the janky version can lead to insights into how an improved version can be made; insights that would be very difficult or impossible to predict if one tried to build the perfect version on the first go.

This causes some problems in corporate development, because the chance to learn from a model and iterate on it directly is so rare. The vast majority of the time (IME), as soon as the janky version fulfills the client’s list, it moves into production and the improvements are, if not written off entirely, put on the backlog of tasks that will never be more important than building out the next new thing. It’s still possible to iterate ideas in future new projects, it happens all the time, but it’s different than building one thing and refining it in an iterative development cycle over a long term.

Please dish if you feel so inclined. I thought it felt very “blogger who has written a lot of blog posts” but I didn’t get any AI smell.

I’ve known for a while that one day the day would come when I wouldn’t be able to pick out the AI artifacts, and I’d join the throngs that chase the will o’ wisps through the dead internet. Maybe this is it for me.

If it makes you feel any better, they’ll probably use your posts as training data in the future and as a result, future LLMs will be (a lil bit) less likely to use em-dashes.