I once built a demo-ish encrypted network boot system using similar initrd techniques. It's a fun hack working in the preboot environment.
I once built a demo-ish encrypted network boot system using similar initrd techniques. It's a fun hack working in the preboot environment.
But to quote Little Red Riding Hood in Stephen Sondheim's musical: Nice is different than good. It's hard to accept if people you really like do horrible things. It's tempting to not believe what you hear, or even what you see. And Epstein was good at getting you to really like him, if he wanted to.
That doesn't mean we should be suspicious of niceness. It just means that we should realize, again, nice is different than good.
The author is right. The magic has faded. It's sad. I'm still excited about what's possible, but it'll never create that same sense of awe, that knowledge that you can own the entire system from the power coming from the wall to the pixels on your screen.
My recent experience is the opposite. With LLMs, I'm able to delve into the deepest parts of code and systems I never had time to learn. LLMs will get you to the 80% pretty quick - compiles and sometimes even runs.
The text processing is running Qwen / Alibaba?
Awesome to see more small teams making impressive leaps.
In the end it was faster, cheaper, and more reliable to buy a fat server running our models and pay the bandwidth tax.
I asked it about a paper I was looking at (SLOG [0]) and it basically lost the context of what "slog" referred to after 3 prompts.
1. I asked for an example transaction illustrating the key advantages of the SLOG approach. It responded with some general DB transaction stuff.
2. I then said "no use slog like we were talking about" and then it gave me a golang example using the log/slog package
Even without the weird political things around Grok, it just isn't that good.
I'll say that grok is really excellent at helping my understand the codebase, but some miss-named functions or variables will trip it up..
A lock-free queue by itself isn't very useful. You need a polling strategy that doesn't involve a busy loop. If you use mutexes and condvars, you've basically turned it into a lock based queue. Eventcounts work much better.
If I run more threads than CPUs and enough work so I get time slice ends, I get about 1160 nsecs avg enq/deq for mutex version, and about 146 nsecs for eventcount version.
Timings will vary based on how man threads you use and cpu affinity that takes your hw thread/core/cache layout into consideration. I have gen 13 i5 that runs this slower than my gen 10 i5 because of the former's efficiency cores even though it is supposedly faster.
And yes, a queue is a poster child for cache contention problems, une enfant terrible. I tried a back off strategy at one point but it didn't help any.
I rewrote the entire queue with lock-free CAS to manage insertions/removals on the list and we finally got some better numbers. But not always! We found it worked best either as a single thread, or during massive contention. With a normal load it wasn't really much better.
But there's a bigger issue than just what software you're allowed to run on your own computer. What's really insidious is the combination of the corporate and government interest. If every server tracks how old you are, it's a short step to tracking more information. Eventually it's a mandatory collection of metadata on everyone that uses a computer (which is every human). Something both corporations and governments would love.
You were worried about a national ID? No need. We'll have national metadata. Just sign in with your Apple Store/Google Store credentials. Don't worry about not having it, you can't use a computer without it. Now that we have your national login, the government can track everything you do on a computer (as all that friendly "telemetry" will be sent to the corporate servers). Hope you didn't visit an anti-Republican forum, or you might get an unfortunate audit.