• M5 chip: October 2025


• M5 Pro and M5 Max chips: March 2026


• M5 Ultra chip: Late 2026


• M6 chip: Late 2026


• M7 chip: First half of 2027


• M7 Pro and M7 Max chips: Second half of 2027


• M7 Ultra chip: 2028

Introduction

Recently, I've got a chance to try building Mozc (Most famous Japanese input method editor) with Bazel.

As you know, recently newer Bazel related packages were landed into debian/unstable. Then now I'm planning to update Mozc from 2.29.5160.102 to 3.33.6133.

Background story about Mozc and Debian

The upstream of Mozc had released 3.34.6239, but on Debian, we stick to Mozc 2.29.5160.102.

Mozc requires newer Bazel but we only had Bazel 4.2.3 at that time on Debian, so even though the upstream of Mozc switched from GYP to Bazel, we had patched Mozc with GYP based package.

We even did make an effort to restore build options that had been already removed. :-( And needed to migrate from GTK2 renderer to GTK3 renderer.

That is why the version of Mozc is diverged from upstream on Debian.

• 2.29.5160.102 (Now on Debian)
• 2.29.5268.102
• 2.29.5374.102
• 2.29.5544.102
• 2.30.5544.102
• 2.31.5712.102
• 2.31.5851.102
• 2.32.5994.102
• 3.33.6089
• 3.33.6133 (Target to upgrade for)
• 3.34.6239

How to switch from GYP to Bazel?

At first, we needed to decide what Mozc version to work with it.

Now latest version of Mozc is 3.34.x, but it requires Bazel 9.x. Please recall that Bazel 7.7.1 was introduced Debian/unstable. And more, newer dependency libraries are required.

You might feel that target version (3.33.6133) is too high from 2.29.5160.102, but if we upgrade to more older Mozc, it means that it requires to backport Mozc to older libabsl compatible codes and so on.

That is why Mozc 3.33.6133 was chosen.

Even once the target version has been decided, you can't let your guard down.

There are many technical tasks to solve.

• Revisit patch sets to apply
• Porting uim mozc patch and fix FTBFS
• Porting fcitx5 mozc patch and fix FTBFS
• Fix src/third_party vendoring
• Switch from GYP to Bazel build systems
• ...

At least, it will likely require several rounds of testing in the Debian experimental.

Conclusion

Currently, gbp buildpackge has succeeded finally on local machine, but need to tidy and cleanup stuffs.

I didn't know packaging with Bazel best practice yet, to remove many third party vendor/ bundles, I've found that it requires pile of patch to eliminate them.

In the current version of Debian, as a one of build system, further work — such as support from debhelper - will be needed.

I'll file working progress on #1085173

Following up on my previous post, I am releasing debvulns-exporter, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.

Testing and Dashboarding

To validate the exporter, I spun up older Debian 11 and Debian 12 cloud images sourced from the Debian Cloud team. The older image was intentionally selected to guarantee a standard baseline of unpatched vulnerabilities for testing. The local evaluation topology is structured as shown below:

Rather than constructing the Grafana dashboard from scratch, I used Claude 4.6 Sonnet via Antigravity to generate the layout configuration. The generated dashboard for the local testbed functions effectively:

The complete, ready-to-import Grafana dashboard configuration is included directly in the debvulns source code.

At May First, we recently received (all within a single week) three different complaints about domain names that previously worked fine suddenly not resolving to our servers.

While that isn’t terribly uncommon, we discovered that in each case, the domain name’s authoritative name servers were pointing to our mail servers (a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org) instead of our name servers (a.ns.mayfirst.org, b.ns.mayfirst.org and c.ns.mayfirst.org). The weird part: this mistaken configuration was happening at the registrar level, protected by each member’s own credentials that we don’t have access to.

Each affected member fixed their records to resolve the problem but also made very clear that they had not logged into their registrar in years, sugggesting that the DNS authoritative records in their registrar accounts spontaneously changed on their own. The first time was weird, the second time could possibly be a coincidence? But by the third time this happened, we started to panic. How could registrar records spontaneously change? All three domain names were registered with different companies - so it couldn’t be a single registrar problem? Are we going to get a flood of these complaints? What is going on!?!?

We did an inventory to see if this was happening with other domain names in use by our membership and that’s when we discovered just how hard it is for our mostly non-technical users to set a domain’s authoritative name servers. The error rate was less than 1% but still that was a lot of domain names with typos:

• raise your fist in the air with a.ns.mayfist.org!
• or just plain give up and hit the floor with a.ns.matfirst.org
• Or more commonly people added our name servers, but also left the default name servers in place.
• Also, one person added as their authoritative name servers: a.ns.mayfirst.org, b.ns.mayfirst.org, c.ns.mayfirst.org, a.mx.mayfirst.org, b.mx.mayfirst.org, c.mx.mayfirst.org, and even a.webproxy.mayfirst.org - in other words, all the domain names we tell you do to anything with.
• And lastly, I did find two more domains just pointing to a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org.

That’s when it occurred to me: for years we have maintained an offsite server that provides both c.ns.mayfirst.org and c.mx.mayfirst.org. It hangs out in case something terrible happens to our main colo. The week before we started receiving these complaints, I separated these services, moving c.mx.mayfirst.org to a dedicated MX server. As a result, these two domain names stopped pointing to the same IP address. And that’s when the complaints started rolling in. In other words: the affected members set the incorrect name servers years ago, but because just one of the name servers resolved to an IP that happened to provide the correct authoritative lookup services, it went undeteced all this time.

So… mystery solved. Nobody’s authoritative registrar records “suddenly” changed. They were mis-configured for years but thanks to the amazing resilience of the DNS system, nobody noticed because just one working DNS server is all you need.

Welcome to the June 2026 report from the Reproducible Builds project!

In these reports, we outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit our Contribute page on our website.

In this month’s report, we cover:

1. Only installing reproducible packages with repro-threshold
2. Distribution work
3. diffoscope development
4. From our mailing list…
5. Documentation updates
6. Patches
7. Four new scholarly papers

Only installing reproducible packages with repro-threshold

A very interesting demonstration is now available showing how you might configure your Debian system to only install packages that have been reproduced by m/n rebuilders.

This is implemented via a reproduced+https:// APT transport ( a mechanism for communicating between the APT client and its repository source — commonly HTTP):

Every package download is intercepted by repro-threshold, which queries two independent rebuilders for a signed attestation before allowing installation to proceed. [It] is important to note that [an] install will only succeed if all package dependencies are also reproducible.

The demo gives examples of how to quickly experiment with this using a Docker container.

Distribution work

In Debian this month:

• The debian-installer package in Debian was uploaded with a substantial reproducibility-related changelog. This means, for the first time, the uploaded version could finally be reproduced.

• Various OpenJDK packages were also uploaded to Debian, including the fix for JDK-8385738 (“Javadoc does not produce reproducible output…”) (for example). […][…][…]

• The “reason” pages on reproduce.debian.net, such as the one for ppc64el, now feature links labeled with the bug emoji (i.e. 🐛) which links to the categorized issues packages have been tagged with in the reproducible-notes.git repo.

• Indeed, 25 reviews of Debian packages were added, 31 were updated and 33 were removed this month adding to our extensive knowledge about identified issues. Two issue types were updated as well. […][…]

The IzzyOnDroid Android APK repository reached its next milestone this month, now covering 2 out of every 3 apps (66.7%) with reproducible builds. Their documentation for debugging and fixing failed builds has steadily grown as well. More clients have picked up showing reproducibility results (e.g. Droid-ify), and Neo Store now can be configured to stick to only reproducible applications. Further, an independent builder has been added to the build farm, increasing the trust level even more as APK builds can have multiple confirmations now.

At the same time, IzzyOnDroid’s rbtlog got several new features. The most outstanding is caching for frequently used resources such as reproducible-apk-tools, command-line tools and NodeJS in order to counter ongoing issues with GitHub availability, while at the same time saving bandwidth and build time. This change also enables some other some smaller enhancements such as being able to configure build timeouts per recipe for those builds running longer than the average, release pattern filtering for update checks or having a field for maintainer notes to shortly summing up e.g. why a reproducible build failed.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.

diffoscope development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 319, 320, 321, 322 and 323 to Debian:

• Debian adds an extra Flags: line in the output of ocamlobjinfo, so adjust the test for cross-distribution compatibility. […]
• Bump debhelper compatibility level to 14. […]
• Fix compatibility with Ocaml 5.4.1. […]
• Use --long-form-style arguments when calling apktool in order to support apktool version 3. […]
• Support Androguard version 4 and previous versions at the same time. […]
• Update copyright years. […]

In addition, Jochen Sprickerhof added better header detection for the Sphinx documentation system […], Michael Daniels fixed the tests when run with zipdetails version 4.006 […] and Zbigniew Jędrzejewski-Szmek added a version of the deprecated os.path.commonprefix method […].

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 321 and 323.

Chris Lamb also made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:

• Skip symlinks when manually called via /usr/bin/strip-nondeterminism. (#1139000)
• Update debian/watch format. […]
• Drop Rules-Requires-Root: no and Priority: optional fields. […]
• Bump Standards-Version to version 4.7.4. […]

From our mailing list…

On our mailing list this month:

• kpcyrd posted to our mailing list regarding the “waves of malware uploads to aur.archlinux.org”. Curiously, “every incident I looked at used npmjs.com for malware delivery”, specifically where the npm package includes an (automatically executed) preinstall script that is an ELF binary.

• kpcyrd also announced the release of debian-repro-status version 0.4.0, a tool written “to give you an approximate idea of how viable it would be to enforce a ‘reproducible packages only’ update policy for the computer system you’ve built”:

  The change updates dependencies to the latest versions, and adds support for multiple -H options, to query results from multiple rebuilderd instances. The results are also now fetched concurrently.

• kpcyrd also reported that, whilst taking a screenshot for the above release, they noticed that the debian:sid container now is 100% reproducible.

• Finally, kpcyrd also created a pull request against the add-determinism package to update the itertools and zip Python dependencies.

Documentation updates

Yet again, there were a number of improvements made to our website this month including:

• Chris Lamb added a reminder re. using the UTC variants of the Javascript Date methods. […]

• Mattia Rizzolo moved OTF to the ‘old’ sponsors list. Thank you for your support!. […]

• kpcyrd updated the Rust documentation to recommend using the --release argument for consistency. […]

Patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:

  • cvise
  • efl
  • gettext-runtime/bash
  • hadrian
  • plasma6-keyboard
  • syntax-highlighting

• Chris Lamb:

  • #1139654 filed against node-fuse.js.
  • #1139655 filed against node-egjs-hammerjs.
  • #1139656 filed against node-chartjs-adapter-date-fns.
  • #1139662 filed against mkdocs-include-markdown-plugin.
  • #1139704 filed against lmarbles.
  • #1140240 filed against rocm-docs-core.
  • #1140567 filed against libecoli.
  • #1140688 filed against golang-github-tobischo-gokeepasslib.

• Jochen Sprickerhof:

  • #1139457 filed against c-munipack.
  • #1140365 filed against latex-coffee-stains.
  • #1140366 filed against cxxtest.
  • #1140367 filed against slime.
  • #1140368 filed against spooles.
  • #1140369 filed against sdpb.
  • #1140645 filed against procmail.
  • #1140676 filed against proftpd-dfsg.
  • #1141059 filed against mah-jong.
  • #1141133 filed against dxf2gcode.
  • #1141194 filed against afterstep.
  • #1141195 filed against ledger2beancount.
  • #1141196 filed against ocamlviz.

• Kris Van Hee and Vagrant Cascadian:

  • #1140167 filed against dtrace.

Four new scholarly papers

Kenichiro Muto and Kuniyasu Suzaki of the Institute of Information Security in Yokohama, Japan published an interesting paper this month titled Attestable Build Chain: Enabling Trust in Reproducible Builds (PDF). Their abstract is as follows:

Ensuring trust in software supply chains requires verifying not only artifacts but also the processes that produce them. Although Reproducible Builds (R-B) require rebuilding to validate artifacts, they cannot verify whether the build was executed with the intended toolchain and inputs and may reproduce unintended or compromised builds without detection. We present Attestable Build Chain, a framework for externally verifying build-time execution without rebuilding. Rather than preventing compromise, it provides verifiable, tamper-evident evidence of actual build-time execution, enabling verification of build process integrity from observed file accesses during the build. […]

Julien Malka, Stefano Zacchiroli and Théo Zimmermann published a 50-page report detailing A Decade of Software Reproducibility in the Nix Package Ecosystem:

We find that functional package management enables extremely high rebuildability over time (near-universal ability to reconstitute historical build environments and rebuild software packages), while bitwise reproducibility has steadily improved and reaches a high point in recent years (up to 93% in 2024). Early years show substantially lower bitwise reproducibility, indicating that functional package management alone does not guarantee bitwise-identical outputs, and that the observed high level of bitwise reproducibility is not solely due to the package management approach. Common causes of unreproducibility, both in the rebuildability and bitwise reproducibility dimensions, include management of dates in build and test processes; we quantify their prevalence and other common causes using manual analysis of logs of rebuild failures and automated analysis of diffoscope.

A PDF of their report is available online

Tim Bastin of L3montree GmbH and Jacek Galowicz of Applicative Systems GmbH from DevGuard published a paper detailing How We Built a Sovereign, Reproducible Container Supply Chain for DevGuard:

This paper presents how the DevGuard project rebuilt its OCI container pipeline around reproducible Nix builds and independent dual-platform digest verification. DevGuard images are built hermetically from pinned source revisions, signed with Sigstore/Cosign, and verified through digest comparison across GitHub Actions and sovereign GitLab infrastructure hosted on container.gov.de. We describe the practical integration of reproducible OCI image builds into existing CI/CD workflows and argue that independently reproducible container digests provide a stronger integrity guarantee against build tampering than provenance alone. The paper further discusses remaining trust assumptions and the relevance of sovereign build infrastructure for government and regulated environments.

Finally, Yiseul Choi, Junga Kim, Jun-Ho Hong and Seongmin Kim of the Department of Convergence Security Engineering at the Sungshin Women’s University in Seoul, Korea titled Attestation-based verification of SBOM integrity via consumer-side reproducibility:

Software bills of materials (SBOMs) support supply chain transparency, but they do not prove that a delivered SBOM reproducibly corresponds to its software artifact. Existing signing and provenance mechanisms protect integrity and traceability, yet lack consumer-side reproducible verification. We propose an SBOM integrity verification framework combining procedure disclosure, consumer-side reproduction, authority-generated reference evidence, and digest comparison. A trusted authority records a reference digest, and consumers compare it with locally reproduced and delivered SBOM digests. Experiments on 100 real-world container images show detection of artifact tampering, SBOM substitution, distribution modification, and adaptive tampering beyond signature-based approaches

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.

• Mastodon: @reproducible_builds@fosstodon.org

• Mailing list: rb-general@lists.reproducible-builds.org

Wall Chargers

• Anker Nano USB-C Wall Charger with Smart Display - $25.99, down from $39.99


• Anker 140W 4-Port GaN USB-C Charger - $79.99, down from $99.99


• Anker 3-Port Prime Charger - $99.99, down from $149.99

Wireless Chargers

• Anker MagGo 3-in-1 Charging Station - $71.99, down from $89.99


• Anker 3-in-1 MagSafe-Compatible UFO Charger - $71.99, down from $89.99


• Anker 3-in-1 MagSafe-Compatible Foldable Charging Station - $85.99, down from $109.99


• Anker 3-in-1 MagSafe-Compatible Charging Cube - $89.99, down from $129.99


• Anker 3-in-1 Prime Wireless Charging Station - $99.74, down from $149.99


• Anker Prime MagSafe-Compatible 3-in-1 Charging Station - $139.99, down from $229.99

Portable Chargers

• Anker MagGo Power Bank 10,000 mAh - $65.99, down from $79.99


• Anker Prime Power Bank 20,100 mAh - $129.99, down from $179.99


• Anker Prime Power Bank 26,250 mAh - $179.99, down from $229.99

Portable Power Stations

• Anker SOLIX C300 Power Station with Lantern - $189.99, down from $249.00


• Anker SOLIX C300 - $249.99, down from $299.99


• Anker SOLIX S2000 - $599.00, down from $1,199.00


• Anker SOLIX C2000 Gen 2 - $899.99, down from $1,499.00

Top Stories

'iPhone Ultra' Likely to 'Repeat the iPhone X Story' With Delayed Launch

Everything Coming in the 2026 Apple TV 4K

Everything New in iOS 27 Beta 3

Apple Intelligence Home Features Require 2TB iCloud+ Plan in iOS 27

iPhone 18 Pro Battery Capacities Revealed by Regulatory Filings

When is Apple's 2026 Back to School Offer?

MacRumors Newsletter

A new minor release 0.4.28 of RQuantLib arrived on CRAN this evening, has been uploaded to Debian, and is being built for r2u as well.

QuantLib is a rather comprehensice free/open-source library for quantitative finance. RQuantLib connects (some parts of) it to the R environment and language, and has been part of CRAN for nearly twenty-three years (!!) as it was one of the first packages I uploaded to CRAN.

This release of RQuantLib brings a minor update to the calendars for Israel which in QuantLib 1.43 can now use one of three different exchange choices. However, using ‘settlement’ is now deprecated so we adjusted our code. This came up as we had packaged the 1.43-rc version of the (upcoming) 1.43 release a few days ago, and it is now in testing requiring RQuantLib to catch up. Full details from the NEWS file follow as usual.

Changes in RQuantLib version 0.4.28 (2026-07-10)

• Adjust to Israel calendar constructor change in QuantLib 1.43

• Continuous integration uses ccache-with-R action

Courtesy of my CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

Team Rcpp is excited to share that an brandnew new version 1.1.2 of Rcpp is now on CRAN, has also been uploaded to Debian, and has already built for r2u and r-universe; Windows etc builds at CRAN should follow in due course.

Rcpp has long established itself as the most popular way of enhancing R with C or C++ code. Right now, 3236 packages on CRAN depend on Rcpp for making analytical code go faster and further. On CRAN, 13.4% of all packages depend (directly) on Rcpp, and 61.4% of all compiled packages do. From the cloud mirror of CRAN (which is but a subset of all CRAN downloads), Rcpp has been downloaded 121.6 million times. The two published papers (also included in the package as preprint vignettes) have, respectively, 2263 (JSS, 2011) and 471 (TAS, 2018) citations, while the the book (Springer useR!, 2013) has another 742.

The is the second update in the 1.1.* series which had, among other changes, switched to C++11 as the minimum standard. This release continues as usual with the six-months January-July cycle started with release 1.0.5 in July 2020. Interim snapshots are always available via the r-universe page and repo. We continue to strongly encourage the use of these development released and their testing—we tend to run our systems with them too.

Having said that, we would like to reiterate that we strongly object to the upstream R release and change management which in this 4.6.* cycle made several abrupt changes forcing packages which consume header files to make very abrupt change. Rcpp, just like numerous other CRAN packages demonstrates that API changes can be undertaken responsibly in a managed manner which allows for transition periods followed by possible warning periods, deprecations periods and finally (but only at long last) errors. What happened here is a speed run to the final stage of forced errors. Uncool and irritating for something as widely used as R. This forced us to make an interim release 1.1.1-1.1 even though we have of course had a policy of always keeping properly tested, installable, and error-free releases candidate version in the main repository branch and hence available via R-universe tested packages for all relevant platforms, and even via binaries for most (including Ubuntu LTS). It would be nice if R Core found a way to take advantage of this. Maybe development cycles, running apart for a year as they do for R, should also include selected packages.

Once again I am not attempting to summarize the different changes. The full list follows below and details all these changes, their respective PRs and, if applicable, issue tickets. Big thanks from all of us to all contributors!

Changes in Rcpp release version 1.1.2 (2026-07-01)

• Changes in Rcpp API:

  • Use of execinfo.h is again conditional to avoid build complexity (Dirk in #1445 addressing #1442)

  • An internal state component for Datetime is now int (Dirk in #1448 and #1449 fixing #1447)

  • Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in #1450 closing #1432)

  • An UBSAN error in the Sugar-based NA comparison has been corrected (Iñaki in #1453 fixing #1452)

  • Treatment of Inf outside of integer range in Sugar function has been corrected (Iñaki in #1458 fixing #1455)

  • Integer overflow protection has been added for sugar functions (Iñaki in #1457 fixing #1454)

  • The parent environment is now accessed via R_ParentEnv (Dirk in #1460 fixing #1459)

  • Change to returning dataptr again for better handling of empty vectors (Iñaki in #1462 fixing #1461)

  • Undefined behavior errors in use of ListOf proxies have been addressed (Iñaki in #1464 fixing #1463)

  • Under newer R version, R_UnboundValue is no longer used (Iñaki in #1466 fixing #1465)

  • New R API access point R_getRegisteredNamespace() is used with current R versions (Dirk in #1469 fixing #1468)

  • The Nullable::as() exporter now uses an explicit cast to the templated type (Dirk in #1471 fixing #1470)

  • A memory leak in the variadic Rcpp::warning() template has been fixed (Kevin in #1475 fixing #1474)

  • The Nullable::operatorT() has been added as a 'opt-out' (Dirk in #1477 with coordination in #1472)

  • Add templated integer-index overload for operator[] on small systems such as WASM (Jeroen Ooms in #1482)

  • The attribute accessors in AttributeProxyPolicy no longer rely on get__() (Kevin in #1484 fixing #1483)

• Changes in Rcpp Documentation:

  • Reference in the bibliography used by the package vignettes have been updated.

• Changes in Rcpp Deployment:

  • Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in #1467)

  • R 4.5.* has been added to the CI matrix (Dirk in #1476)

  • Three nag messages issued when obsolete build flag accessors are used now show Rcpp::: (Dirk in #1480 fixing #1456)

  • Reference GitHub Actions have been updated to their current versions (Dirk in #1481)

• Non-release Changes:

  • A non-release hotfix 1.1.1-1 used by CRAN accommodates breaking changes to the API in R 4.6.0. It would be nice to have the same level of release management in R itself that CRAN expects from us.

Thanks to my CRANberries, you can also look at a diff to the previous interim release along with pre-releases 1.1.1-1 and 1.1.1-1.1 that were needed because R-devel once again sudden decided to move fast and break things. Not our doing. And there also should not have been a need to two such uploads but it was amateur hour all around.

Questions, comments etc should go to the GitHub discussion or issue section, or the Rcpp list. Bugs reports are welcome at the GitHub issue tracker as well. GitHub offers decent search for issue, pull requests and discussions; as many topics have been covered it is worth checking as well.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Search

Siri AI

Writing Tools

Smart Reply

Contextual Suggestions

Call Context

Performance Improvements

Requirements

I used to ice skate as a teenager but I stopped at University. I tried to pick it back up in 2024 but had to stop when I got ill. I restarted in 2025, initially with a weekly skate session but last month I started group hockey skate lessons.

There's not a lot of pics of me skating… this one from an IR camera

I've been skating in a pair of Bauer¹ Nexus N77s that I bought 7 years ago on a work trip to Toronto. These did a great job of getting me back into the hobby for 6 years but recently I felt it was time to step up to a better quality pair. Despite being a size down from my shoe size, the Nexuses are too large: I had been compensating with thick socks but still struggling to get the boots tight enough. I'd have to wear gloves to lace up because I'd cut my hands pulling the laces otherwise.

After too long researching/deliberating/kvetching (very much on trend for me) I upgraded to Bauer Vapor Fly30s another half-size down (and nearly ten times as much). The fit is much better, in almost every respect. They actually go on easier and I don't have to tear my hands tightening the laces. They feel like a natural extension of my feet. I seem to be using a different set of muscles to skate, so the first few sessions were very fatiguing, but that settled. The Vapor line is speed-oriented, which I thought would fit my skate style best.

new and old skates

I have unfortunately gained a common problem: arch pain. More precisely, my navicular bone seems to be quite prominent², and that part is pressing uncomfortably into the boot. Boots typically take a few sessions to break in, but after 7-8 sessions the pain was getting to the stage that I couldn't skate for a full session without being in agony.

The last time I skated I tried to throw everything at the problem: I'd had the skates baked³; bought some orthotic insoles; then some "Bunga" pads over the sore bit and an attempt to more loosely tie the laces over the affected area. I tried a ten minute skate, and it seemed a bit better.

I then tried experimentally to swap back to my old skates, and I felt like Bambi: I just couldn't do it! They didn't press on the navicular, and they're softer so you can compensate for the size with tight lacing, but I had no confidence in them, I couldn't lean into the turns. They just felt weird. I realised there's no way back.

I switched back to the fly30s, adjusted the bunga pad positioning, tweaked the lacing and went back on for about 40 minutes. It went well: the rink was quiet, it was cool whilst we had a heat wave outside, so I worked up a sweat. By the end there was some discomfort, but not too much, and I think partly the area is currently sensitive so just about anything will cause discomfort. Fingers (or toes) crossed that I've mitigated the problem! If not, it might be time to try a punch out.

At Apple, our teams are constantly developing breakthrough technologies to create the best products and services in the world, and protecting their work and intellectual property is something we take very seriously. Recently, significant evidence has emerged suggesting individuals employed by OpenAI wrongfully took Apple's secret and confidential information regarding our unreleased technologies, processes, and products. We will always defend our teams' hard work and innovations, and we are taking all appropriate steps to do so.

OpenAI also instructs new hires on how to avoid scrutiny when they leave Apple. For example, Mr. Tan warns them not to tell Apple that they have taken jobs at OpenAI, so they can stay at Apple as long as they can. After his own departure, Mr. Tan improperly retained or obtained an internal Apple managers' document marked "Need to Know" that describes security procedures for employee departures. Messages left on Apple-issued work devices show that Mr. Tan and his OpenAI colleagues have been sharing this document with new hires before they give notice to Apple of their departures, previewing Apple's security protocols. Unsurprisingly, Apple's investigation has found a pattern by employees who depart for OpenAI of taking steps to evade the security processes intended to protect Apple's confidential information.

This is the tip of the iceberg. Apple lacks visibility into what's been happening behind closed doors at OpenAI, where such misconduct is normalized and exemplified by leadership. This much is clear, however: at every level, from members of its Technical Staff to its Chief Hardware Officer, and in coordination with business partners, OpenAI has been stealing Apple's trade secrets and confidential information. As a natural result, OpenAI's nascent hardware business now rests on the shakiest of foundations, rotten to its core by its illegal reliance on misappropriated trade secrets.

Brands have been continuously upgrading their smartwatch hardware to make devices more AI-capable. Edge AI integration enables real-time health insights and faster responses while helping ensure data privacy. Currently, Edge AI penetration remains limited to leading brands, with Apple solely accounting for ~90% of Edge AI smartwatch shipments in Q1 2026.

“You are what you eat” – but perhaps this is even more true of our information diet. It is hard to strike a balance between remaining a well-informed citizen versus spending hours ingesting unnecessary news about issues and events we can’t affect. But I’m increasingly convinced that my hours lost to doomscrolling are down to design choices by web publishers rather than a failure of individual willpower.

We have created an “obesogenic” information environment

I don’t think it is just me – I think our information environment has been progressively altered over time as news sites look to maximize engagement. Even outside of social media, the invisible hand of the market for eyeballs forces sites to optimize for browse time or risk irrelevance.

Even as newspapers find it increasingly difficult to fund good journalism through advertising in an online world, especially local journalism, they need to keep readers on their sites, clicking through as many articles as possible. Clickbait headlines, “urgent” flashing live icons to draw the attention, and many opportunities to leap from one article to another, and another.

But this design approach even extends to news organisations with a different funding model, like BBC News, which is a public service (state-owned but arms-length) organisation funded through a mandatory television licence – a matter of controversy in some quarters. And it extends even to sites where I pay a subscription fee; I might get adverts removed, but I am still bombarded with the same design philosophy; too many opportunities to be pulled away from what I’m reading towards some other unrelated article.

Even if I try and limit my exposure to algorithmic “discovery” of new news, via RSS feeds or similar, if I’m reading the full article in a browser then I am prompted to read more stuff that I didn’t intend. This defeats the benefit of curating a set of feeds, because you still get dragged away to random articles.

Only 44% of BBC News is news

To show you what I mean, I’m going to pick on the BBC, although I love them dearly and the same issue very much applies elsewhere.

I’ve taken a screenshot of a random BBC News article in mobile view (my preferred doomscrolling user access device), and measured approximately what proportion of the full length of the page is taken up by each section. This is a fairly in-depth news article, so I reckon if anything the figures would be worse than this on shorter articles.

(These numbers will not sum to 100% for reasons which are obvious if you look at the crossbars. Also they’re approximations.)

Less than half of the page (44% if you exclude the inline related links) is actual news text/images; the rest are links trying to help you find the next thing to read/watch. I do not want this.

I’m sure this A/B tests well in terms of reader figures, but it sometimes leaves me exhausted – it must take subconscious mental energy to ignore, or I spend too much time trying to keep on top of things.

And remember, this is a publicly-funded site that does not rely on advertising!

Blocking out the noise

If you are technically-minded, you can use an ad-blocker such as uBlock Origin to take back some control. Applying the following lines as a custom filter (Settings > My filters) brutally cuts out almost all of these links:

bbc.co.uk##aside
bbc.co.uk##footer>div:has(h2)
bbc.co.uk##[data-block="uploaderEmbed"]
bbc.co.uk##[data-block="links"]

Caveat emptor: I have not road-tested this for more than half an hour, so who knows what consequences this could have on your web browsing. In particular, international readers outside the UK will likely be redirected to bbc.com, the commercial arm of the BBC, where these rules will need adapting.

Is it unethical to use an ad-blocker to remove these links? I would argue not. I am not depriving the BBC of any revenue, because I pay my licence fee. I might reduce the amount of time I spend on their website, but if anything the subjectively better experience might encourage me to consume more news from them, not less. In other circumstances (outside the UK for instance, where the BBC relies on advertising), the balance might be different.

Product managers, please find better metrics

I lament the state of the internet in 2026. I now can’t unsee these innocuous “related stories” links as a mechanism to grab my attention, and it’s gone too far.

If you are a normal person just browsing the news and looking to discover the latest important stories relatively quickly, I can see that these types of links might actually be useful for discovery; but I’m actually reasonably sure that I’m not going to miss out on anything major. You still have the option of the news home page if you want to be presented with more news for example, and it feels natural to go back to there when you’ve run out of stories to consume.

But it shouldn’t be down to individual responsibility to ignore or geekily block these types of link; news sites with alternative funding models should find better metrics for engagement than “hours spent on site” – how about optimizing for customer mental wellbeing, or minimizing time required to catch up with the news? There’s no need to maximize clicks and eyeballs. This is a societal level issue, because we are all going mad with news over-engagement.

Product managers, over to you.

The diffoscope maintainers are pleased to announce the release of diffoscope version 324. This version includes the following changes:

[ Paul Spooren ]
* Allow trailing garbage in Gzip files.

[ Chris Lamb ]
* Bump debhelper compatibility level to 14.

You find out more by visiting the project homepage.

Apple Watch Ultra 3

• What's the deal? Take $99 off Apple Watch Ultra 3


• Where can I get it? Amazon


• Where can I find the original deal? Right here

MacBook Pro

• What's the deal? Take $450 off M5 Pro MacBook Pro


• Where can I get it? Best Buy


• Where can I find the original deal? Right here

MacBook Air

• What's the deal? Take $150 off M5 MacBook Air


• Where can I get it? Amazon


• Where can I find the original deal? Right here

Anker

• What's the deal? Save on Anker accessories


• Where can I get it? Amazon


• Where can I find the original deal? Right here

These features fuel the user's urge to keep scrolling and shift the brain into 'autopilot mode,' contributing to unhealthy habits and compulsive use.

Moreover, Meta disregarded available information about the time minors spend on Instagram or Facebook at night and how the optimization of its different formats – such as reels and stories – could lead to excessive or compulsive use of the services.