Besides starting at $599 (the Air has mostly been a $999 product; occasionally selling at $799 at Costco), coming in 4 bright colors with matching keyboards, using an A series chip for the first time in a Mac, containing 90% recycled aluminum (the most of any Apple product) and breaking all Mac laptop sales records, there's nothing new about it. /s
> Personally, I would want that R&D spend and innovation to go to more sustainable materials, longer lasting devices, and easily repairable parts to extend the devices useful life.
Apple probably leads the industry in sustainability–the MacBook is 60% recycled material.
They’ve been working for years to be carbon neutral by 2030.
> 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.
Yes, I meant pf. Indeed, it was there in the source tree in 10.6 but they only flipped it on it in release builds in 10.7. My bad. Either way, it has hardly changed since then, while the OpenBSD upstream continued to progress.
> I doubt multiple routing tables are a problem.
The lack of them is a limitation for me (complex VM + VPN setup), which requires me to do pretty unholy static routing and address rewriting with pf.
I think even Apple has come across this; they added "scoped routing" (which IMO is a hacky workaround providing some of the functionality you'd get with multiple routing tables) just before iOS shipped with MMS support. Android, for comparison, uses Linux's routing policies and tables to send and receive MMS.
> 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.
> 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:
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].
> > 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.
That's not what that means. font-size specifies the size of the font's em box, but the correlation between the em box and the visual size of the font is not consistent across fonts. font-size-adjust can adjust how a font-face responds to the font-size so that the sizing is consistent with other fonts of that size. For example, capsize is easier to implement that way.
This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.
If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.
Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.
Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.
old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.
This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?
Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming
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:
Absolutely!
reply