jonathaneunice

~~have become~~ became, 30+ years ago

The office-document format wars played out _at least_ twenty years ago.

The path dependence and "everyone uses it" (installed base) inertia of Microsoft's formats continue to benefit Microsoft (and its OOXML formats), despite ODF being more open and, in many ways, superior--not least because it's easier to implement, manipulate programmatically, and reason about.

But refighting that battle seems pointless. Users and the market have moved on, not least toward cloud-based tools; file formats no longer seem the primary barrier to competition.

Astrophage

Even great words, phrases, and styles, seen too often, grate.

I personally love a lot of the Claude (or LLM) lingo. Load-bearing, gate, canonical, blast radius, and friends do a lot of tight, effective heavy-lifting in my world. I even love the em-dashes (—) and the *bold the main points* memo style, both of which I have used successfully for decades.

It's seeing them in every analysis and post—the constant repetition becoming over-repetition—that makes them the Claude voice shouting "AI wrote this!" that seems to be causing LLM allergic reactions.

Concur.

Tried on a "this test suite is weaker than I'd like, too often depending on internal state rather than outcomes" problem via Cursor, asking it to "review and suggest solutions." It gave me a quality overview of the test approaches, strengths, weaknesses, and gaps then recommended a disciplined multi-prong approach based on a common, trusted testing library (https://hypothesis.readthedocs.io/en/latest/). It broke down the things we could do this improvement pass or leave to later (staged scoping), identified some very hard/possibly-out-of-scope cases and gave me the option of focusing on them or not, and organized new tests in a logical way. After one round of feedback and plan tuning, I put it in agent mode and let it work. A few minutes later I had a much better test suite.

Have not tried Grok before and didn't have much confidence, but it did great. Exactly the sort of complex, detailed, nuanced analysis and multi-step task I would previously only trusted to GPT or Opus.

_Update_: It's now also found a substantive long-standing bug. After testing improved asked it to do overall code and packaging review. It caught a few glitches and oversights, mostly cosmetic IMO, but certainly worth cleaning up. But also some error-handling weaknesses, and one embarrassing functional bug. Which it has now also fixed and added to the tests. Color me impressed.

Not true. Macs easily pass SOC 2 audits.

You'll need MDM, installed anti-virus/anti-malware, and reasonable update policies, as with any endpoint. But have passed multiple years' audits with mostly-macOS fleet.

Deeply cynical and reductionist—but not altogether wrong.

That's the best "what is ANE, really?" investigation / explanation I've seen. Directly lays out why LLMs aren't an ideal fit, its "convolution engine" architecture, the need for feeding ANE deep operation sequence plans / graphs (and the right data sizes) to get full performance, the fanciful nature of Apple's performance claims (~2x actually achievable, natch), and the (superior!) hard power gating... just _oodles_ of insight.

Are the Apple neural engines even a practical target of LLMs?

Maybe not strictly impossible, but ANE was designed with an earlier, pre-LLM style of ML. Running LLMs on ANE (e.g. via Core ML) possible in theory, but the substantial model conversion and custom hardware tuning required makes for a high hurdle IRL. The LLM ecosystem standardized around CPU/GPU execution, and to date at least seems unwilling to devote resources to ANE. Even Apple's MLX framework has no ANE support. There are models ANE runs well, but LLMs do not seem to be among them.

Ecosystem was a huge driver. But even before that, so so easy to get going. 5 minute guided install, if you're doing it yourself. Many web hosting providers auto-installed for you. No one could touch that ease to just get going.

I once did a review of CMSs to see "is there anything better out there?" Literally scores of options. At one point seemed like everyone had tried their hand at building a CMS. Installed maybe a dozen of the most promising. It was all very meh. Some had this nice feature or that (e.g. WYSIWYG editing, back when that wasn't table stacks). But overall, none seemed substantially better that WP, Drupal and Joomla among them. Most of them seemed blighted by comparison. Drupal and Joomla included. Nothing else out there seemed worthy of investing time and energy into.

First impression is love that! Need to study it more.

We need—or at least I need—a better UI/tool to manage the sequence of edits and collaboration, drafting, rubber-ducking, and evaluation that AI tools provide. Including the prompts and edits is a nice feature, though I would also like more comparison "where we started" vs "where we are now."

Agree with the underlying point: "don't let an LLM do your thinking, or interfere with processes essential to you thinking things clearly through."

My own experience, however, is that the best models are quite good and helping you with those writing and thinking processes. Finding gaps, exposing contradictions or weaknesses in your hypotheses or specifications, and suggesting related or supporting content that you might have included if you'd thought of it, but you didn't.

While I'm a developer and engineer now, I was a professional author, editor, and publisher in a former life. Would have _killed_ for the fast, often excellent feedback and acceleration that LLMs now provide. And while sure, I often have to "no, no, no!" or delete-delete, "redraft this and do it this way," the overall process is faster and the outcomes better with AI assistance.

The most important thing is to keep overall control of the tone, flow, and arguments. Every word need not be your own, at least in most forms of commercial and practical writing. True whether your collaborators are human, mecha, or some mix.

Love this!

I've heard that desert sand is fundamentally smoother than beach or river sand. Would love to see some examples of non-beach sand side-by-side with these glorious samples.

Love this!

Have wanted to work on a "better situational awareness while traveling" app, but haven't yet had the chance. Reachability of a POI is a great place to start, and I _feel_ that "it's a lot harder than it at first looks" aspect.

It would also be cool to:

* Become aware of local attractions. Esp. good restaurants, shops, views, hotels, hiking trails, etc. A lot of rating systems seem to give every fast food venue 3 or 4+ stars. Impossible to sift out the truly good and local / unique from the chaff.

* Become aware of time-limited events. Fairs, art shows, VFD chicken BBQs or fish fries, ... all the little "I wish I knew that was happening, I would have stopped by!" I constantly search for the local, the offbeat, the not-yet-another-corporate-outpost. But again, the chaff!

* Be able to navigate on backroads and scenic roads. Mapping apps are so hyper-focused on getting you there fast. They're not good at "get me there happy"—at least not for those of us that value the path less traveled far more than the highest-speed highway.

while avoiding AI taint

Don't be shy. Tell us what you really think.

This times a thousand!

In the years before VMs, containers, and locked dependency manifests, it was essentially impossible to get repeatable builds. There are still a lot of hurdles and gotchas, but we can at least get a rough approximation. The idea that some other pre-2010 dev team was going to be able reliably build your thing from just raw source code, and have it closely resemble the thing you built—it was a delightful fantasy. Escrow was a sales and legal "don't worry we have that eventuality covered!" CYA and emotional de-risking move, not a practical expectation of ability to build from scratch.

See the embedded video Failed Vocal Attempt (Music Video). However when it is played (at 0:02 or 0:03), it shows a title card for "Neon Dreams." That's the song that seems one part ELO, one part Daft Punk.

_Neon Dreams_ is ELO × Daft Punk.

Sometimes posts like this are just value-signaling. I hear a lot of cynicism and "just you wait, the other shoe will drop" comments along those lines.

But combined with the other projects Anthropic has pursued (e.g. around understanding bias and explaining "how the model is thinking as it is") and decisions it has made, I'm happy with the course they're plotting. They seem consistently upstanding, thoughtful, and respectful. I want to commend them and earnestly say: Keep up the good work!

You might think you can, for a while. Been there, done that. But you probably can not do so sustainably in most cases. Even if you could, would you really be better off building vs. buying? Outsourcing development, operations, and maintenance is almost always the better choice, letting you focus on the things you do uniquely, differentiably, or meaningfully better.

"We have this awesome internal version of Docs that we're responsible for fixing, upgrading, and doing support for" is not the flex "AI can code anything!" aficionados think it is. Especially when you also have similar internal versions of Sheets, Jira, Slack, GitHub, Linux, Postgres, and 100 other tools.

If you believe the AI researchers–who have been spot-on accurate for literally four decades

LOLWUT?

Counter-factual much?

Switching to sovereignty-protecting, locally-hosted collaboration, compute, and storage is by no means impossible. FOSS advocates have been eagerly beating this drum and providing options for 25+ years.

The missing ingredient has always been the will to absorb the inevitable cost of change, and the friction of choosing something other than the standard, go-to, often at least apparently free (or at least bundled) tools.

The current U.S. threats against NATO and allies creates a rift in the previously-accepted international order that may finally motivate material change. Often such change is chaotic and discontinuous—it feels well nigh impossible, right up to the moment it feels necessary and inevitable.

That's Dan Frye's article, and it is um, a little Dan Frye-centric. He was a legitimately important contributor to IBM's technology management team around Linux and open source, especially as and after IBM made the turn.

But it reads as if he called the shot and piloted the turn. That is not my recollection or understanding. Other folks contributed as much or more to driving the Linux/open source pivot. Irving Wladawsky-Berger, the late Scott Handy, _et al_. It's IBM, so there were a ton of folks involved and contributing.

My source: I was an industry analyst and consultant in the server / system software space at the time, and I was in at least a few of the rooms where it happened.

Love a good rant or an artfully scathing review!

This seems very consistent with the refactoring techniques taught by Sandi Metz (https://sandimetz.com/99bottles). After taking her course, I successfully applied those techniques to good ends and outcomes.

Not sure "refactor in context" is the tool for every single last refactoring job in the universe. Some plumbing changes may be large or systematic enough that they need to be separately planned and applied, especially as explaining "oh I changed the fundamental way we do things, just in passing" can be a hard PR to present. OTOH, since adopting the "in context" approach I have had many fewer refactoring attempts abandoned, and refactoring seems much more logical and purposeful. So it works IME.

The complexity and frustration are in no way accidental. A carefully designed, obfuscated, and Byzantined process designed for exactly this effect.

You're supposed to be so beaten down, so utterly depleted of will, that you just cave. [...] You disable a bunch of parental controls you don't really understand. You let your kid play his damn game. You become the ideal customer.

Exactly so. Parental controls, privacy settings, permission to show ads and collect infinite tracking data… The machine is working exactly as intended. Maybe there are sentiments that "the parents should have some control" and maybe there are some laws about protecting children or protecting consumer privacy. But hey, what if actually using any of those mechanisms was mind-bendingly difficult and annoying? What if your control were only available downstairs, in the unlighted cellar, at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." We'd still be in compliance, right? Heh heh. Yeah. That's the ticket!

It paved the way for a lot more than that. At a time open source in general, and Linux in particular, did not have much corporate buy-in, IBM signaled "we back this" and "we're investing in this" in substantial ways that corporate IT executives could hear and act upon. That was a pre-cloud, pre-hyperscaler era when "enterprise IT" was the generally understood "high end" of the market, and IBM ruled that arena. IBM backing Linux and open source paved the way for a large swath of the industry—customers, software vendors, channel/distribution partners, yadda yadda—to do likewise.

Cosigned!

Em dash forever! Along with en dash for numerical ranges, true ellipsis not that three-period crap, true typographic quotes, and all the trimmings! Good typography whenever and wherever possible!

VAX hardware did eventually run out of steam by the early 1990s. But VMS had already failed to capture the next generation of growth. Even while DEC was still the number 2 computer company, 5–10x the size of its competitors, and growing $1B/yr in revenues.

Unix (workstations first, then servers), PCs (DOS and NetWare, later Windows), packaged enterprise apps (e.g. IBM AS/400), "data warehousing," fault tolerant apps—a lot of those were not things happening on VAX or VMS or any other DEC product. The fight was already structurally lost and VMS aficionados were already bemoaning DEC's failure to pick up new workloads and user communities even when VAX was still going strong.

VMS declined like almost all proprietary minicomputer environments. AOS, ClearPath, GCOS, MPE, NonStop, PRIMOS, VOS, and VMS...all fine products just ones no longer serving the high-growth opportunities.

Declining investment streams hamstrung proprietary CPU/system development efforts compared to higher-volume alternatives (PC or Unix), so they got successively slower and relatively more expensive each generation. Proprietary environments weren't designed to ever escape their home fields, nor were their companies set up to profit from opening up / spreading out. A few tried, very belatedly, but... by that point, dead man walking.

So from this vantage, same pattern, not a different thing. Perl and VMS were awesome in their original home fields, but were not quick to, or even able to, capitalize on the new directions and workloads customers grew to want.

Ordering, like stability in sorting, is an incredibly useful property. If it costs a little, then so be it.

This is optimizing for the common case, where memory is generally plentiful and dicts grow more than they shrink. Python has so many memory inefficiencies that occasional tombstones in the dict internal structure is unlikely to be a major effect. If you're really concerned, do `d = dict(d)` after aggressive deletion.

Debugging is a completely different and better animal when collections have a predictable ordering. Else, every dict needs ordering before printing, studying, or comparing. Needlessly onerous, even if philosophically justifiable.