farfatched
> Scaling actions is VMs, networking, imbalances in load, memory, insuring that folks aren’t running VM training against your infrastructure.
That infra scaling is what the cloud provider can easily offer.
Meanwhile, GitHub repos/issues/PRs is all the business logic that they've written, evolved over time.
Many coupled distributed DBs, indexes, consistency concerns, etc.
That's trickier to scale.
* Sometimes I'm in flow state, and so breaking at 17:00 breaks that.
* 17:00 is rush hour, so if so leave then, my commute goes from 60m to 90m. So I leave at 16:00, and catch up later. But now I'm context switching more.
* If it's 14:30 and I know I'm leaving at 16:00, then I'm hesitant to work on something that might need more focus/debugging.
All these are workable, and many parents are testament to that, but at least for me, it's all contributing to less productivity.
My passion for tech remains, and now work is the time I spend on it, but not on my assigned priorities, sadly.
I really need to kick my engrossing tech hobbies. :(
And yes to the wider point. There are many people more capable people than me, but sometimes it's about priorities, and top achievers in fields will usually be sacrificing something else.
Not much, but some evenings will soon be available!
If I say I'm going to borrow a needle and just look at it, you should just trust me. If I use it, I make sure to sterilize it before returning it.
Try it out: `apt install dasher`. https://packages.debian.org/sid/dasher
He wrote https://www.withouthotair.org/ (creative commons) and was the Chief Scientific Advisor to the UK Department of Energy and Climate Change.
Dedicated to "to those who will not have the benefit of two billion years' accumulated energy reserves".
The author of the post uses standard terminology like entropy coding and arithmetic coding, and cited a paper "in 2023, Google DeepMind released a paper arguing that language modeling and compression are two views of the same thing" which discusses it further.
This blog post is great. Well explained, and clearly took a lot of effort.
I don't interpret it as them claiming to have to discovered it independently.
> Why unify information theory and machine learning? Because they are two sides of the same coin. In the 1960s, a single field, cybernetics, was populated by information theorists, computer scientists, and neuroscientists, all studying common problems. Information theory and machine learning still belong together. Brains are the ultimate compression and communication systems. And the state-of-the-art algorithms for both data compression and error-correcting codes use the same tools as machine learning.
Book (creative commons): https://www.inference.org.uk/mackay/itila/book.html
Lectures: https://m.youtube.com/playlist?list=PLruBu5BI5n4aFpG32iMbdWo...
Doesn't the CPU throttle if the phone gets too hot?
Or maybe some parts like the eMMC aren't spec'd for things like constant logging?
> So while I shouldn’t let myself be bullied away, I am stepping down from the Nix maintainer team.
> I am not as of now stepping down from the SC, because that would be irresponsible.
Perhaps it is no surprise the earlier adopters were people with rigid views.
This was the elected steering committee doing its job, and a sign of growing health.
The PRs keep rolling and things keep improving!
If someone wants to be a part of the community, I can see why this might dissuade people though.
That said, if there's a resurgence in microkernel, it will probably come from the Rust community.
You think what they're doing isn't covered in the intersection of OS books, OS papers, other OSs, osdev, random GitHub projects?
It's difficult for us to know what reason they might have for anonymity until we know their identity, at which point it's too late.
Also, they've written many words across many years, in a time when "the internet is serious business" was just a meme. I suppose it is now.
Perhaps it's not that OSM that needs a signal, but perhaps it's that there's an opportunity for an open map that has many signals, of which OSM and Book Corners are examples.
Opus 4.5 with a plan mode is enough for me: it asks clarifying questions to map out the design space, it covers fiddly parts, it generates good unit/integration tests.
I have seen it cheat by deleting existing tests, since it's single-mindedly focused on the problem I give it. I've not used an LLM-to-review-an-LLM, but when I've used an LLM to review my own work, it notices when there are unrelated changes in my commit/working copy.
Besides, all of your critique is how I've heard product managers speak of human developers! And a tool needn't be perfect for it to be useful.
That's the problem. Tailscale is not zero trust. Tailscale can be used to implement a zero trust architecture, with if deployed with sufficiently granular ACLs, but the most common deployment is machine-oriented, rather than service or request oriented. In which case, any process on that machine has a lot of access.
Tailscale calling itself zero trust might be what leads users to think "use Tailscale, job done".
I think Tailscale know that, which is why they barely mention locking down access ACLs.