looks like they brought back the glowing apple logo on the lid for the first time in a decade!
the older macbooks used the display's backlight to illuminate the logo, but since these new OLED displays light up individual pixels I wonder how they're lighting it up now...
One annoying trend in frontier models which contributes to the brainrot is:
- agent loops for a long time (minutes to hours), writing a lot of code
- agent gives high level summary of the outcome of the work, not the work itself, i.e. "Implemented and pushed feature XX. Focused tests and checks passed."
- requires detailed review of the large changes which can be exhausting, so just accepting it becomes easier
I really wish the models would explain more of the "how" and "why" of the implementation decisions. To combat this, I usually to bug the agent to discuss more including what assumptions it made and alternatives it considered.
Sure, this can be added to AGENTS.md but I view overengineered AGENTS.md as an antipattern and can work against us especially given the rapid advancements of the models.
What does seem to work is planning first via a very synchronous back and forth with an expensive model before tasking 1+ cheaper models to implement in parallel, then getting an expensive model to review while I look over things manually.
That seems to work best (plan with the expensive model, cheap ones implement). The "Implemented feature XX, tests pass" summary drove me nuts too, so I make the planner record the decision and the why in my second brain app before anything gets built, and implementers report back against it.
Seems like this URL has only been live (at least first archived [0]) around May 2026, originally with only 13 products. Great to see them add more since then, now close to 90.
Just keep a high bar for quality at whatever abstraction level you're working at - whether that's machine code, assembly, low or high level languages, or even wrangling agents.
I've been coding for 25 years and I've never been more excited and less sad to build projects I've been dreaming of but haven't had enough time to do.
Ahhh, I think the author mixed up two values here. That value seems to actually be the average over the past 3 months.
const incidents = e.detail.incidents;
// ...snip...
const now = new Date();
const threeMonthsAgo = new Date(now);
threeMonthsAgo.setMonth(threeMonthsAgo.getMonth() - 3);
// ...snip...
var currentFreq = recentIncidents.length / 3; // <- We out here, smoking these guns with our homeboy Claude
// ...snip...
var earliest = null;
for (var j = 0; j < incidents.length; j++) {
var dd = new Date(incidents[j].started_at); // <- eventually incidents[j].started_at is "2016-03-01T07:07:37.000Z"
if (!earliest || dd < earliest) earliest = dd;
}
// ...snip...
document.getElementById('n-since').textContent = earliest
? earliest.toLocaleDateString('en-US', { month: 'long', year: 'numeric' })
: '?';
document.getElementById('n-rate').textContent = Math.round(currentFreq * 10) / 10;
#n-since is going to be either march or feburary. It'll change depending on your timezone because JS's Date object always shifts the date around to match the same instant but in the system's timezone.
#n-rate has nothing to do with the #n-since month, it's just the last trailing 3 months. And even then, it's sort of underbaked? It's moving the date back by 3 calendar months not taking into account differing numbers of days, so it'll under-report short months.
I wouldn't trust the stats here.
Edit: whoops, author updated the template while I was writing this! It now says "Over the last 3 months", though that's still calendar months.
Not sure whether it has been updated since your comment, but the sentence now reads:
GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month
edit: although they also have 1.2 days of downtime (in a day) for their 'worst days' of downtime table, which suggests some auto number crunching is not working as expected.
Yes I tweaked it! The number and copy were mismatched and are no longer!
That worst day is likely an overlapping incidents accounting issue; I tried to account for overlapping incidents in another view but probably failed to port it over there.
having worked at the intersection of CAD/CAM automation & actual factories, I'm disappointed with the lack of real information on what their product actually does.
Going from bits to atoms is _hard_ for a ton of reasons, and their example prompt "Prepare this for manufacturing" is a huge red flag IMO. That said, I wish them luck, we need fresh blood in this slow moving industry.
Hey jeremyherman at xfgr.ai we don't pretend about anything, WYSIWYG, and no LLM, only math.
You asked me 10 months ago when we would have something to look at, give our MVP a shot!
Working on seed round now, to train a POC of the actual foundation model I really intend to scale.
I was about to write this. So refreshing, after having looked at hundreds of semi or completely AI-written articles. Even the news look like sterile Claude now. This is so human.
> This machine specs reminds me of how awful '90s laptop screens, based on a passive matrix, were. Definitely something I don't miss from that era.
While the 1991 Apple PowerBook 100 did have a passive matrix display, the machine it was based on, the Macintosh Portable from 1989, had a crisp active matrix running at 640×400 (even higher resolution than the compact Macintosh desktops with 512×342).
Interestingly Apple tasked Sony with designing the PowerBook 100 by taking the Macintosh Portable and slimming it down as much as possible. They shaved over 10lbs by moving away from the lead acid battery, dropping the floppy drive, and moving to a passive matrix display.
the older macbooks used the display's backlight to illuminate the logo, but since these new OLED displays light up individual pixels I wonder how they're lighting it up now...
reply