Got one for my wife here in Canada recently, where it's on a similarly good sale.

It's a nicely put together piece of _hardware_ and firmware, way way better than the garbage Dell laptops I have to use for work, which are heavy and hot and regularly fail to manage basic things like customizing sleep/wake behavior…

… but I personally am completely unwilling to use a Mac unless I'm getting paid and forced to.

I hate MacOS. I hate the UI, I hate the fiddly little ways that it hides information about real file paths and makes it unnecessarily difficult to uncover the tall ones. I hate hate hate all the broken stuck-in-the-80s non-GNU CLI tools, and the kludged-together stupidness of the networking stack compared to Linux.

Windows 11 is arguably worse than MacOS in many of these ways, but Linux with a Gnome or Cinnamon or XFCE desktop is far far better.

I hate the lack of full-size USB ports and HDMI. I don't care if it makes the laptop 3 mm thicker. I want them, in particular to be able to plug in my Logitech wireless mouse adapter and all my 10-15-year-old USB devices which still work fine.

I hate the keyboard and trackpad. I want a pointing stick and a trackpad with physical buttons. I want page up/down buttons and separate delete/backspace.

It's fun indeed!

The theme seems to be something like "college students at house parties"… reminds me very much of my friends and the photos we took at around this age.

> He has some kind of byzantine but ideologically-pure protocol for reading his emails in batches,

This caught my eye as well.

I'm not sure what his objection to accessing email in a normal-ish way might be. Any ideas?

My best guess is that it's something surveillance-related, but really not sure.

I think OP might be confusing Stallman's website protocol with that for email:

> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly.

(he describes his arrangements in detail here: https://www.stallman.org/stallman-computing.html)

https://lwn.net/Articles/262570/ Is what I found

Great writeup.

I have done similar things on several long flights.

Very often, there is at least one large cloud provider or CDN (e.g. Microsoft/Azure or Amazon/AWS or Google/GCP) that is whitelisted by the in-flight Internet gateway so that it can serve static pages, and I can get access to all the sites hosted by that provider simply by using domain fronting (which the author of this post describes as "disguise domain": https://ramsayleung.github.io/en/post/2025/a_story_about_byp...)

> All 33 of the batteries with the [negative anode overhang] defects came from the 424 sold by low-cost brands or brands selling counterfeits. > > … > > None of the name brand OEM batteries were found to have any problems, and while there was some deviation in anode overhang for rewrap batteries, the deviations were seven times worse for the low-end cells.

Based on those stats, it sure sounds like the following is happening:

1. The reputable OEMs (Samsung, Panasonic, Murata in this study) do adequate quality control for defective batteries. The low-cost OEMs do not do adequate quality control. 2. Some portion of the defective or not-fully-tested batteries from the reputable OEMs get "diverted" to rewrappers, who essentially just relabel the batteries without doing any further testing.

Is that a correct read?

> The way they used to handle that at a FAANG I worked for was they had this app installed on each machine issued by IT, that would ask you a question daily about some aspect of your workplace.

I presume you're referring to "Amazon Connections"?

Had to be the most-hated bit of corporate enforcedware around. Every Linux laptop user had a different hack for hobbling or removing it.

It's been years, and I still remember the infamous ticket `CONNECTIONS-3303`. A pox on everyone involved with that clusterfuck.

> The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem.

Absolutely, this is important.

But I don't understand why this should have any effect on OCSP-stapling vs. CRL.

As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date.

Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment.

> As an aside it's not clear that OCSP stapling is better than short-lived certs.

This is equally applicable to CRL, though.

The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.

> I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable)

> The privacy concerns could have been solved through adoption of Must-Staple

Agreed. I haven't followed every bit of the play-by-play here, but OCSP (multi-)stapling appeared to me to be a good solution to both the end-user privacy concerns and to the performance concerns.

> A lot of engineers design by trying to think of the “ideal” system: something well-factored, near-infinitely scalable, elegantly distributed, and so on.

Was it Donald Knuth who said "premature optimization is that root of all evil"?

This article made this point very well, especially regarding the obsession with "scaling" in the SaaS world.

I've seen thousands and thousands of developer hours completely wasted, because developers were forced to massively overcomplicate greenfield code in anticipation of some entirely hypothetical future scaling requirement which either never materialized (95% of the time) or which did appear but in such a different form that the original solution only got in the way (remaining 5%).

John Ousterhout’s Philosophy of Software Design makes the case for simplicity in a book-length form. I really like how he emphasizes the importance of design simplicity for the maintainability of software; this is where I've seen it matter the most in practice.

My current company is in that 5% part right now. Tremendous effort invested into the system, everyone involved was very proud of themselves. Unfortunately the way we actually needed to scale was almost completely untouched by any of this architecture astronomy, so we have both a terrifically complicated system - very difficult to change things without potential breakage or regression - AND it doesn't scale at all.

I don't mind, I don't blame people for not predicting the future - it's a tough game. But god the hubris and attitude we put up with until the crows came home to roost.

> Unfortunately the way we actually needed to scale was almost completely untouched by any of this architecture astronomy

"Architecture astronomy" 100%, I love this phrase. Did you come up with it?

> But god the hubris and attitude we put up with until the crows came home to roost.

I feel this, I feel this.

thanks for sharing and I couldn't agree more.

I assume you mean astrology (prophecy), not astronomy (science)?

> I assume you mean astrology (prophecy), not astronomy (science)?

I took "astronomy" as an allusion to the fact that @atomicnumber3's team was metaphorically peering at their scaling needs through a telescope, an instrument with a very narrow field of view.