I hope theft deters people from wearing these perv glasses. They're easier to nick than phones since owner isn't gripping them at all. I'd tolerate a fair amount of crime and public disorder as part of this tradeoff, like how we keep predators around to control pests.
>It's a medium to pack the idea into "something" that represents the idea. It was never about a finished and polished product. It's the sign language for deaf people - a way to show your thoughts.
Sign language is a fully fledged language, as capable of expressing deep and complex thoughts as spoken English. Likening it to some kind of prosthetic for second-rate thinkers is insulting.
We still speak today of Charlemagne, Muhammed, Caesar, Alexander.
Napoleon and Columbus have secured for themselves their seats in the pantheon of history and it will take longer than a thousand years for mankind to forget about them.
That "weapon" quip from TFA really pisses me off. It implies actual malice on the part of the person copypasting GPT. But people aren't being malicious, they're mostly just clueless. "Weapon", "weaponized" etc sound punchy so they're a safe choice in the AI's slopertoire.
And on the subject of weapons, consider the example of a delayed-action fuze. They're designed to penetrate through the outer defenses of a target, before the warhead detonates deep inside. What might this look like in written form?
Well, you'd start by getting on the reader's side, with shared loathing against some outgroup. Get them to let their guard down. And then at the end:
>Use AI to make things clearer, not longer. Let it sharpen your thinking, not replace it.
You, yes you, the very clever and sophisticated person reading this who is exasperated by slop-grenades, should use AI more. You should use AI to "sharpen your thinking". You use AI, but in a good way. Not like those rubes, who use AI in a bad way.
States got strong and organized enough that they could consistently defeat the raiders. Castles, feudalism, better lines of communication, bigger and more professional armies.
This is cool don't get me wrong, but surely overcomplicated? Why not just record audio to disk the whole night then eyeball the waveform for loudness spikes? If you just don't connect it to any network at all, there's no data breach risk (or am I misunderstanding the justification for the noise-detection toggle thing?).
As you add more code between the "open" and the "close", you introduce more opportunities for control flow to accidentally skip the "close" (leak), or call it more than once (double-free). It forces you to use single-return style, which can make some things very awkward to express.
You're basically doing "defer"-style cleanup manually; you may as well just use the real "defer" if your compiler supports it. It's supposed to be official in a future standard, too.
>The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise- and-pound-foolish programmers, who can’t debug or maintain their “optimized” programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn’t bother making such optimizations on a one-shot job, but when it’s a question of preparing quality programs, I don’t want to restrict myself to tools that deny me such efficiencies.
Knuth thought an easy 12% was worth it, but most people who quote him would scoff at such efforts.
Moreover:
>Knuth’s Optimization Principle captures a fundamental trade-off in software engineering: performance improvements often increase complexity. Applying that trade-off before understanding where performance actually matters leads to unreadable systems.
I suppose there is a fundamental tradeoff somewhere, but that doesn't mean you're actually at the Pareto frontier, or anywhere close to it. In many cases, simpler code is faster, and fast code makes for simpler systems.
For example, you might write a slow program, so you buy a bunch more machines and scale horizontally. Now you have distributed systems problems, cache problems, lots more orchestration complexity. If you'd written it to be fast to begin with, you could have done it all on one box and had a much simpler architecture.
Most times I hear people say the "premature optimization" quote, it's just a thought-terminating cliche.
Yes, this is (more or less) how we regenerate the system state, when necessary. But keep in mind that the fuzzing target is a network of containers, plus a whole Linux userland, plus the kernel. And these workloads often run for many minutes in each timeline. Regenerating the entire state from t=0 would be far too computationally intensive on the "read path", when all you want are the logs leading up to some event. We only do it on the "write path", when there's a need to interact with the system by creating new branching timelines. And even then, we have some smart snapshotting so that you're not always paying the full time cost from t=0; we trade off more memory usage for lower latency.
Oh one other thing: the "fuzzer" component itself is not fully deterministic. It can't be, because it also has to forward arbitrary user input into the simulation component (which is deterministic). If you decide to rewind to some moment and run a shell command, that's an input which can't be recovered from a fixed random seed. So in practice we explicitly store all the inputs that were fed in.
>The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers.
Add to that: unicode handling, support for bigger displays, mixed-DPI, networking and device discovery is much less of a faff, sound mixing is better, power management and sleep modes much improved. And some other things I'm forgetting.
>Effective immediately, no contractor, supplier, or partner that does business with the United States military may conduct any commercial activity with Anthropic.
Nevermind Claude, does that mean Anthropic's offices can't use a power company if that same company happens to supply electricity to a US military base? What about the water, garbage disposal, janitorial services? Fedex? Credit card payments? Insurance companies? Law firms? All the normal boring stuff Anthropic needs that any other business needs.
This is a corporate death penalty. Or corporate internal exile or something, I don't know of a good analogy.