There comes a point in a startup's life where more controls are needed. Red tape. The stuff that slows down the big boys. Problem is, the red tape is scar tissue from previous informal process failures.
I think these control rooms were superior in some respects to modern software system observability.
- modelling the system rather than implementation (system status rather than many individual service statuses)
- supporting causal reasoning: the control flow on top means you can trace failure modes back, visually; software systems typically only model their own ontology, and you need to look somewhere else for the next abstraction down
- surface state first rather than time series; a pretty graph is nice to look at, but for actionability sometimes what you need is the flashing red light
- prioritize first-out indicator. In a complex system with lots of alerts, the most important diagnostic alert is often the first one - the rest are downstream and contribute to alert fatigue, despite them probably being more important business metrics
It's not actually. Think about it for a moment and you'll see life is full of tensions between preventing crimes and freedom / utility.
It's most obvious on the roads. Few non-commercial vehicles will limit your speed to the national maximum. Wouldn't a strict interpretation of your opinion imply speed governors?
People are stochastic. You build reliable processes out of unreliable parts with feedback and self-correcting mechanisms. AI is not actually magically special in this regard. It has higher variance and we're still figuring out how to get all the tradeoffs right.
You see a lot of hobby shops in ultra-wealthy areas of major metropolises. Tiny art studios, interior decorators with a handful of items in stock, boutique fashion shops.
Can you try and tune your Claude or whatever LLM you're using for your text to phrase things in plain English. Way less use of antithesis, at least. You can probably find a skill for it, if not get an LLM to write your own.
The second mode is another way of doing the first, actually.
Either way, working people's output today needs to support the non-working people today (unless you let them starve). Whether that is done via taxation or via wealth accumulation, one way or another, more and more young people will be supporting old people.
And it's not even clear the wealth accumulation angle is good. It requires young people to own a lower amount of wealth so that old people can dangle it in from of them to keep them supported.
I found it interesting that vLLM was dismissed as slower than llama.cpp.
IME vLLM is quite a bit faster than llama.cpp but where it really wipes the floor with it is in batching concurrent load. The downside is that it is dramatically less flexible in terms of tweaking. It gives you very few options for running quantized weights. It takes a lot longer to start up because it optimizes the compute graph. So for single user experimentation on a model that's a bit too big for your box, vLLM is just going to be frustrating.
You don't need to work, but you need to have value in your tribe. You need the respect of peers. You need to feel part of a team. You need to feel like you contribute something to the lives of those you love.
Working to keep a roof over the head of yourself and those you love is an identity. It's social proof that you have value, that you can do something for someone else.
It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows.
Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
Data, compilers, software architecture
[email protected]