alwillis

> OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.

"Exploring Darwin and PureDarwin: The Open-Source Foundation of Apple's Operating Systems" - https://machaddr.substack.com/p/exploring-darwin-and-puredar...

> Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard

Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch.

Whatever a firewall can do, PF can do it.

You can also get a nice GUI for PF [2].

[1]: https://www.openbsd.org/faq/pf/index.html

[2]: https://www.murusfirewall.com/murus/

In 2026, you can avoid the bad parts.

> Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.

All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.

By default, 16px = 1rem. You don't need to declare it; it just is.

Also by default, 16px = 100% if using percentage for font-size.

See "The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet" - https://adrianroselli.com/2024/03/the-ultimate-ideal-bestest...

> Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.

If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.

> Setting `font-size` in your CSS disables that second approach.

Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.

If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:

    | CSS absolute-size values | xx-small | x-small | small | medium | large | x-large | xx-large | xxx-large |
    | ------------------------ | -------- | ------- | ----- | ------ | ----- | ------- | -------- | --------- |
    | scaling factor           | 3/5      | 3/4     | 8/9   | 1      | 6/5   | 3/2     | 2/1      | 3/1       |
    | HTML headings            | h6       |         | h5    | h4     | h3    | h2      | h1       |           |

By default, medium is 16px which is 1rem.

You can write `p { font-size: medium }`.

BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].

[1]: https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop

From the docs:

CLAUDE_CODE_NEW_INIT

Set to 1 to make /init run an interactive setup flow. The flow asks which files to generate, including CLAUDE.md, skills, and hooks, before exploring the codebase and writing them. Without this variable, /init generates a CLAUDE.md automatically without prompting.

> Jokes aside I find it hard to trust in the amount of things Anthropic throws out. It can’t be a well thought out and stable product this way.

I've never seen any company iterate on a product as quickly as Anthropic has with Claude. When you drill down into the details, it is well thought out and stable and well documented.

It seems the feedback loop is so fast, they address issues before they can fester into major problems. The entire company uses Claude; there's not better dogfooding than that.

It reminds me of how, back in the day, when continuous integration and continuous deployment were new; it seemed nuts to push code to production every day. And now, it's the norm.

> But aren't they able to do incremental builds and separated x64/arm64?

During the PowerPC to Intel transition, they did stuff like that; perhaps at their current scale, there's reasons why they don't.

Supporting both architectures enables a macOS install to boot an Intel Mac or an Apple Silicon Mac, which is useful in a dual-architecture environment.

It's easy to check for dual architecture support; just use the file command:

    $ file /bin/ls
    /bin/ls: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
    /bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
    /bin/ls (for architecture arm64e): Mach-O 64-bit executable arm64e

> Yeah I’m honestly not sure why macOS updates seem to be so huge.

An update to macOS 26.5 contains all the necessary code to update a Mac from 26.0 to 26.5 for both x86_64 and arm64 architectures.

BBEdit has had support for Claude, OpenAI and Ollama (or any OpenAI-compatible LLM) in their AI Chat Sheets feature [1].

[1]: https://www.barebones.com/products/bbedit/bbedit15.html#:~:t...

I've been using BBEdit since the System 7 days or thereabouts. Then I discovered Vim and I was hooked. And then came Neovim, which is still my daily driver.

BBEdit has been my never-fail backup editor, especially for Mac-specific tasks. It's been a little awkward because of my Vim muscle memory. Glad to see they're adding Vi/Vim keybindings, which I've wanted for a long time.

> No, we should not praise software companies for hobbyist practices like selling $1 app on the App Store, which say, 30% goes to a digital distribution store, and then of your after distribution fees, about 20%+ percent goes to the federal and local government.

For hobbyists with revenue less than $1 million per year, the App Store commission is 15%.

You can use Language Server Protocol (LSP) in Claude Code; no more regexes [1].

[1]: https://code.claude.com/docs/en/discover-plugins

> I strongly suspect that the "coming soon" part of this means "after we integrate Google Gemini models into the system…"

I don’t think the Google's tech has anything to do with these features.

This would had to have been in the works long before the Google announcement. Also, these are enhancements of existing iOS and macOS features. They don’t require an LLM anyway; these features use Apple’s Machine Learning models.

For example, creating subtitles for videos? iOS 16 introduced Live Captions for FaceTime calls in 2022 [1].

[1]: https://www.apple.com/newsroom/2022/05/apple-previews-innova...

The "coming later this year" language is disappointing to some people, but that's just Apple propriety. Allow me to explain.

"Coming later this year" means it's part of a publicly committed release — iOS 27, macOS 27, etc. — not vaporware.

The annual pre-WWDC accessibility announcement is a tradition, and with the conference less than a month away, expect more detail then. New a11y features have a good chance of appearing in the 10am PT keynote or the Platforms State of the Union, the developer-focused follow-up at 1pm PT.

That said, things are still fluid with three weeks to go — features can be added or pulled at any time. If something gets bumped from the main presentations, there will almost certainly be a dedicated video session covering it.

As for availability: some of these features will land in the iOS 27 and macOS 27 betas, which drop during WWDC for Apple Developer Program members. The public beta follows in July, and there's a free tier of the developer program if you want early access.

Don't expect everything at once, though. Some features won't arrive until the September release candidates — and even then, a few may ship labeled "beta" or "experimental," or hold for a future dot release.

In hindsight, ITCSS is so obvious. Makes you wonder why so many people think CSS is difficult.

This is an excellent resource for using CSS as it was designed to work. It'll give you a different perspective on using CSS [1].

[1]: https://every-layout.dev

> With CSS names are global.

You can limit selectors (not custom properties) to a subtree by using @scope.

On the horizon is @function [1] where custom properties can be local to the function.

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

> Aren't Cascade Layers [1] a more reliable, native solution

Like many new-ish CSS features, adoption is low; around 4-5% from a crawl of 17 million sites [1]. It's been available in all major browsers since 2022.

I'm generally addressing developers who are never going to use any (or very little) modern CSS [2]. There was a thread on HN where some participants complained about "all these newfangled CSS features". Several didn't see the need to learn CSS Grid, even though it's been available for nearly 10 years. (Aside: I really disliked the floats/tables-for-layouts era, with the requisite IE hacks.)

There are lots of developers who don't see a need to use features they weren't using in the late '90s or early 2000s. For a lot of them, they'd rather use the devil they know.

There’s a huge gap between web developers who speak at web conferences, appear on CSS-themed podcasts, and who are members of standards bodies vs the 9-5 developer that works for some insurance company or school, who's not a CSS enthusiast or hobbyist. Using ITCSS would be awesome them.

Finally, there's nothing unreliable or non-native about ITCSS; it's just CSS where the layers are in specificity order. It doesn't get any more native than that.

[1]: https://almanac.httparchive.org/en/2022/css

[2]: https://modern-css.com

> This has to be somewhat anti-competitive.

I don’t think so. They were available to anyone with the money and Anthropic acted first.

I doubt attempting to hurt OpenAI was the primary reason for the acquisition.

Maybe it’s different now; Bill Gates “wanting to cutoff Netscape’s air supply” and threatening to cancel the Windows license of PC manufacturers who shipped Netscape’s browser on their PCs… now that’s anticompetitive. They had 95% market share.

Bill was like “That's a nice PC business you have there; would be a shame if something were to happen to it.”

Most other note taking apps haven’t worked for me… but Tolaria fits like a glove.

> Obsidian has a number of full time employees who all want to eat and afford rent

They have lots of sponsors [1]; you can pay $4/month for sync service or $50 a year, per person for a commercial license.

[1]: https://obsidian.md/enterprise/

> Tiddlywiki

Love Tiddlywiki. It's amazing the amount of functionality it has, even if you use it in "one html file" mode. Great for making a web garden [1].

[1]: https://nesslabs.com/digital-garden-tiddlywiki

> waffling about moving from Notion to something local/markdown based for a while.

Check out Tolaria [1]. Open source, works locally, uses markdown, no-databases. Git client built-in. Even has Notion-style input.

[1]: https://tolaria.md

If I wanted to vibe code something like Photoshop, I would start with the source code for version 1.0 [1].

It’s written mostly in very readable Pascal with some 68000 assembly.

For those not familiar (or not old as me), Pascal was popular in 80s. The syntax is clean and is strongly typed, which I understand LLMs like.

LLMs are good at converting programming languages; it probably wouldn’t be that difficult to convert it to Swift, Rust, etc.

[1]: https://computerhistory.org/blog/adobe-photoshop-source-code...

What helps me a lot: if Claude makes a mistake or an incorrect assumption, press # to tell Claude to remember the correct behavior next time.

Put your coding guidelines in the ./claude/rules for additional progressive disclosure, not CLAUDE.md or AGENTS.md.

It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer.

The summary: write your CSS in specificity order [1]:

    /scss/
    ├── 1-settings.         <- global settings
    ├── 2-design-tokens     <- fonts, colors, spacing, etc.
    ├── 3-tools             <- Sass mixing, CSS functions, etc.      
    ├── 4-generic           <- reset, box sizing, normalize, etc.
    ├── 5-elements          <- basic styles: headlines, buttons, links
    ├── 6-skeleton          <- layout grids, etc.
    ├── 7-components        <- cards, carousels, etc.
    ├── 8-utilities         <- utility and helper classes
    ├── _shame.scss         <- hacks to be fixed later    
    └── main.scss

ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer.

[1]: https://matthiasott.com/notes/how-i-structure-my-css

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change.

Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex.

> placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors

In my opinion, it's the opposite. Besides the obvious violation of DRY and the separation of concerns, inline CSS can't be cached and it creates a lot of noise when using dev tools for debugging. It actually increases cognitive load because you have to account for CSS in two different locations.

Lots of people use Tailwind because they don't want to deal with the cascade, usually because they never learned it properly. Sure, back in the day, the web platform didn't provide much built-in support for addressing side effects of the cascade, but now we have @layer and @scope to control the cascade.

Tailwind uses a remnant of '90s web development (inline CSS) and built an entire framework around it. I get why it appeals to some people: it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts.

They can’t disclose the technical details yet. They did say a detailed write up is coming.

> Nicholas Carlini, for example, whose name is on many of the recent high-profile Mythos findings is not just some random dude with a Claude sub on his credit card .... he's an experienced security researcher.

I don’t think Mythos is hype for all kinds of reasons.

Anthropic is a young company but their track record is solid; they don’t seem to hype things just for the sake of hyping things. Sam Altman at OpenAI? We already know his track record…

I’m going Occam’s razor here: the simplest explanation is usually the correct one.

Anthropic had an “oh shit” moment when they realized what Mythos can do. They decided to do the responsible thing: give the industry a heads-up and an opportunity to use the preview to identify and fix the most dangerous zero-day vulnerabilities.

Since the FAANG companies have billions of users, it makes sense to start with them.

There’s still going to major issues for users of systems too old to get patches or updates. Or for IT organizations who think Mythos is a replay of Y2K, where, compared to the warnings, not lot happened.

The bottom line is someone with Mythos won’t need to be an experienced security expert to cause real problems. That’s kind of the point.

> LLM generated documentation has so low level of information density, that it’s useless. Yes, it writes nice sentences… or even writes. But it contains so much noise that currently, reading code is a better documentation than what I’ve seen from every single LLM generated documentation.

I should clarify: the documentation I’m talking about is not generated using a generic LLM prompt, which would mostly suck.

With the proper context and additions (skills, plugins, MCPs) LLMs can produce high-quality documentation. You'd also have subagents doing QA of the documentation.

But it does require effort; it’s not magic.

> I'm hearing anecdotes from all over about devs pushing LLM-generated code changes into production without retaining any knowledge of what it is they're pushing. The changes compound, their understanding of the codebase diminishes, and so the actions become riskier.

I don’t think so.

An LLM can produce higher-quality documentation than most humans. If it's not already happening, when a new developer joins a team, they're going to have an LLM produce any documentation a new developer needs, including why certain decisions were made.

It could also summarize years of email threads and code reviews that, let's face it, a new person wouldn’t be able to ingest anyway; it's not like a new developer gets to take a week off to get caught up on everything that happened before they got there. English not their first language? Well, the LLM can present the information in virtually any language required.

As the models continue to improve, they'll spot patterns in the code that a human wouldn’t be able to see.