Another very minor update, now at 0.3.15, for our nanotime
package is now on CRAN, and has
been built for r2u and
Debian. nanotime
relies on the RcppCCTZ
package (as well as the RcppDate
package for additional C++ operations) and offers efficient high(er)
resolution time parsing and formatting up to nanosecond resolution,
using the bit64
package for the actual integer64 arithmetic. Initially
implemented using the S3 system, it has benefitted greatly from a
rigorous refactoring by Leonardo who not only rejigged
nanotime internals in S4 but also added new S4 types for
periods, intervals and durations.
This release adjusts the package for the maybe overly hasty switch R 4.6.0 has undertaken with respect to using C++20 as a default C++ compilation standard. I am of course largely in favour of such a switch to more modern C++. But I am also cognizant of the fact that not all compilers and machines are ready. And just as I have already seen one other package fail to compile on a particular CRAN system (!!) under C++20, this package all of a sudden, and only on that same system, started to throw two (harmless) compiler warnings. We could call these erroneous as newer versions of the same compiler do not throw them but it does not matter. The decision to default to C++20 has been made, and now we live with it. But maybe some hardware platforms should be moved behind the barn. Either way, this release both adds an explicit cast to two lines that may not really need it (but this will not hurt) and also dials the compilation standard down to C++17 on one particular platform. So once again there are no user-facing changes, or behavioural changes or enhancements, in this release.
The NEWS snippet below has the fuller details.
Changes in version 0.3.15 (2026-05-21)
Add extra
const_castas one CRAN machine with more ancient setup whines otherwise and is obviously less C++20 ready than it thinks
tools/configurealso checks where this is being built and ’as needed' downgrades the compilation to C++17
Thanks to my CRANberries, there is a diffstat report for this release. More details and examples are at the nanotime page; code, issue tickets etc at the GitHub repository – and all documentation is provided at the nanotime documentation site.
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. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.
Note: MacRumors is an affiliate partner with Amazon. When you click a link and make a purchase, we may receive a small payment, which helps us keep the site running.
As the pace of change accelerates, organizations are moving quickly from AI experimentation to enterprise-scale transformation. Leaders are prioritizing measurable outcomes, faster time to value and repeatability across the business.
But many are encountering the same reality: the challenge is no longer deciding whether to invest in AI — it’s scaling adoption and delivering consistent, enterprise-wide impact.
Over the past year, one thing has become clear. Organizations aren’t asking if AI matters. They’re asking how to make it real — how to embed it into the way work gets done and ensure it drives meaningful results.
That’s where many are getting stuck.
Because the barrier is no longer experimentation. It’s execution.
At Microsoft, we believe successful AI Transformation depends on two foundational elements: intelligence and trust.
Organizations need to harness their own work intelligence — the data, workflows and expertise that make their business unique — and apply it through AI in ways that are flexible, secure and governed. That requires a platform that supports model diversity and continuous innovation, without compromising enterprise-grade security, compliance and reliability.
Just as importantly, AI must be embedded into the flow of work — how people collaborate, make decisions and operate day to day. For that to scale, systems must be transparent, secure and accountable.
This is where real enterprise value is created — and where many organizations need a clearer path forward.
Achieving impact at scale requires more than deploying new tools. It requires a trusted foundation — integrating data, security, privacy and governance — and a new model for delivering AI into the business.
That’s why Microsoft and EY are deepening our alliance — to help organizations move faster from AI ambition to measurable business outcomes.
There is no shortage of AI pilots in today’s market. But pilots don’t transform businesses. What organizations need now is the ability to scale AI across the enterprise, integrate it into core workflows and deliver sustained, repeatable impact.
EY brings that experience.
As one of the first global organizations to deploy Microsoft 365 Copilot at scale, EY began with an initial rollout to 150,000 of its people, quickly demonstrating what’s possible when AI is embedded into everyday work.
The results were significant and measurable:
The impact goes beyond individual productivity into agentic AI in core business operations:
With these results, EY is now expanding Copilot through Microsoft 365 E7 to more than 400,000 of its people worldwide, moving from early success to true enterprise scale.
This is what enterprise-scale transformation looks like — not isolated wins, but sustained impact across the organization.
It’s also why EY serves as Customer Zero — applying Microsoft AI technologies internally to prove what works before bringing those solutions to clients.
Building on this foundation, Microsoft and EY are jointly investing more than $1 billion in a new initiative designed to help organizations move from isolated AI use cases to enterprise-scale transformation.
This effort brings together Microsoft’s AI platforms, including Azure, Microsoft 365 Copilot, Foundry, Fabric and security — and EY’s deep industry capabilities and transformation leadership.
But what differentiates this initiative isn’t just what we bring. It’s how we deliver it.
At its core is a shared focus on helping organizations become Frontier Firms — where AI is embedded across the enterprise, not layered on top.
In a Frontier Firm, data, workflows and decision-making are connected end to end. AI becomes part of how work happens, and human expertise is amplified by intelligent systems.
Reaching this level requires more than investment. It requires execution.
This is where our approach is fundamentally different.
Microsoft and EY are cooperating as an integrated transformation engine — co-developing, co-engineering and co-delivering solutions aligned to real business priorities.
A key part of this model is Microsoft’s Forward Deployed Engineers (FDEs), who work side by side with EY transformation teams directly within customer environments.
Together, these teams:
This integrated model closes the gap between strategy and execution. It reduces friction across the technology stack and creates a direct path from pilot to production — at enterprise scale.
It also ensures that intelligence and trust advance together, embedding AI across data, applications and infrastructure in ways that can be governed, secured and continuously optimized.
Importantly, it establishes a repeatable blueprint — one that organizations can use to scale AI adoption across functions, industries and geographies.
Organizations are under pressure to move faster — to go beyond experimentation and deliver AI across the enterprise.
What they need is not just technology, but a clear path to execution — grounded in both intelligence and trust.
AI is not simply about doing work faster. It’s about enabling people and organizations to do more — focusing on insight, creativity and higher-value decision-making.
Our work with EY demonstrates what’s possible when AI is deployed with purpose at scale. Together, we are bringing those learnings to customers around the world — helping them accelerate transformation, unlock efficiencies and create new opportunities for growth.
Microsoft and EY are committed to helping organizations turn AI ambition into enterprise impact.
Learn more in the official announcement.
The post From AI pilots to enterprise impact: Why execution is the new differentiator appeared first on The Official Microsoft Blog.
I've heard "containers are not a security boundary" enough times that it's started to feel like received wisdom, and my honest read (after 13+ years) is that it's technically defensible but practically sloppy – and the sloppiness matters.
The part that's true: containers share a kernel, and a kernel exploit crosses the container boundary where a VM would not. That difference is real and non-trivial, and the CVE history backs it up – CVE-2019-5736, CVE-2022-0492, and CVE-2024-21626 all happened in "correctly configured" production containers.
The part I'd push back on is that the comparison point is almost never stated. "Containers aren't a security boundary" is being used as shorthand for "containers aren't a VM boundary" – but the conclusion people seem to draw from that is "therefore don't bother", which doesn't actually follow. The more honest version is that default Docker doesn't provide strong isolation between mutually untrusting parties, but a hardened configuration does.
What ships by default in Moby is actually a pretty reasonable foundation: seccomp is enabled (with a builtin profile blocking ~50 syscalls – credit where it's due: this is mostly @jessfraz's work; she even ran contained.af as a public CTF for years daring people to escape a container under her seccomp profile, and to my knowledge it was never claimed), AppArmor is enabled (the docker-default profile), and several sensitive /proc paths are masked. What's not on by default: no-new-privileges (setuid binaries inside can escalate), CAP_NET_RAW is still granted to every container (even though the kernel has supported unprivileged ICMP sockets for over a decade, meaning most modern distributions no longer need CAP_NET_RAW for ping), and user namespace remapping – though user namespaces aren't quite the silver bullet they might sound like; Debian left them disabled by default for years because the kernel attack surface they exposed hadn't been hardened against unprivileged callers.
The boundary isn't absent – it doesn't come completely pre-assembled. With VMs, the hypervisor is there whether you asked for it or not; with containers, assembling the boundary is left as an exercise for the operator. That's a much more solvable problem than "the technology is incapable", but it does mean the work falls to whoever's running the containers.
So, some things you can do today without waiting for defaults to change:
--user (or USER in your Dockerfile) is worth calling out specifically, because I think it's arguably stronger than user namespace remapping in one important way – and partly for the same reason Debian was hesitant about user namespaces in the first place. User namespace remapping protects the host from a root-in-container escape: if you do escape, you land as an unprivileged user on the host. But you were still root inside the container the whole time. Running as a non-root user means you were never root anywhere. The blast radius of a compromised process is limited whether or not it escapes, including for things like reading secrets, modifying container contents, or lateral movement within the container itself. Most application containers have no legitimate reason to be root.
Beyond that, a short list of things that are easy to enable and hard to justify leaving off:
Log in--security-opt no-new-privileges – prevents setuid binaries from escalating; can also be set daemon-wide in daemon.json with "no-new-privileges": true--read-only – a read-only root filesystem means a compromised process can't easily persist tooling or modify the container (pair with a writable tmpfs mount for /tmp etc as needed)--cap-drop NET_RAW – or --cap-drop ALL and add back only what you actually need; CAP_NET_RAW is almost never legitimately needed by application containers--privileged – if something seems to require it, the right answer is almost always a more targeted capability grant or bind mount, not the nuclear optiondocker run \
--user 1234:5678 \
--security-opt no-new-privileges \
--read-only \
--tmpfs /tmp \
--cap-drop ALL \
acme/untrusted-workload:latest
None of these require a daemon restart or infrastructure changes, and stacked together they go a long way toward actually building the boundary that the defaults leave unbuilt.
(this post was written with the assistance of "claude my eyes right out" but all thoughts and understanding are Tianon's)
