Liquid-Cooled NVIDIA Servers at the ASRock Rack OCP 2026 Booth

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/liquid-cooled-nvidia-servers-at-the-asrock-rack-ocp-2026-booth/

We checked out the ASRock Rack booth at OCP 2026 and saw servers ranging from fully integrated NVIDIA NVL72 racks to liquid-cooled switches

The post Liquid-Cooled NVIDIA Servers at the ASRock Rack OCP 2026 Booth appeared first on ServeTheHome.

Inside a successful AWS European Sovereign Cloud exercise to demonstrate independent operation

Post Syndicated from Stéphane Israël original https://aws.amazon.com/blogs/security/inside-a-successful-aws-european-sovereign-cloud-exercise-to-demonstrate-independent-operation/

On Saturday, October 24, 2026 we conducted a successful exercise demonstrating that the AWS European Sovereign Cloud can operate without depending on any infrastructure outside the European Union (EU). This was the first public technical exercise demonstrating the independence of a sovereign cloud Region.

The AWS European Sovereign Cloud is a new, independent cloud partition for Europe that became generally available in January 2026, with its first AWS Region in Brandenburg, Germany. It is physically and logically separate from other AWS Regions, with no critical dependencies on non-EU infrastructure, and all customer content and customer-created metadata remains in the EU.

The AWS European Sovereign Cloud is managed through dedicated European legal entities established under German law and operated entirely within Europe. My fellow Managing Director, Stefan Hoechbauer, and I called for the exercise. We are EU citizens residing in the EU, responsible for its management and operations, including its infrastructure, technology, and services. Only EU residents located in the EU control its operations and support, and AWS is gradually transitioning the AWS European Sovereign Cloud to be operated exclusively by EU citizens located in the EU.

What we did

In standard operations, the AWS European Sovereign Cloud uses two global systems: the AWS Global Network backbone, and a dedicated system operated by the local EU team to manage limited, controlled transfers of operational AWS data. As we explained ahead of the exercise, neither is critical to running the AWS European Sovereign Cloud. During the exercise, the team switched off both systems, and traffic that normally travels across the AWS Global Network backbone rerouted securely over the public internet.

The AWS European Sovereign Cloud can operate independently at any time, and for several hours on October 24 the team showed exactly that, running it on only its own software and hardware resources, operated by EU-resident staff within the EU.

Workloads continued running, and customers could still access their data. The exercise did not affect service availability within the AWS European Sovereign Cloud, other AWS Regions, or private connectivity through AWS Direct Connect. When the exercise finished, traffic returned to its normal path.

Why we ran it

Transparency is at the core of our digital sovereignty commitment, so we ran the AWS European Sovereign Cloud exercise openly and reported back on the outcome.

The exercise produced verifiable technical and operational evidence that the AWS European Sovereign Cloud can continue to operate independently within the EU. It turns a design claim into a verified result. Organizations in regulated industries and the public sector can take this result to regulators and their boards as evidence for their compliance and assurance documents.

What customers and partners are saying

“Digital sovereignty is ultimately about trust and safeguarding business continuity. The successful demonstration of the AWS European Sovereign Cloud’s operational independence is an important proof point for European organizations with the most stringent sovereignty requirements. Combined with Capgemini’s European heritage, presence and AWS capabilities, we can deliver a sovereign proposition in Europe, for Europe, by Europeans, enabling clients to accelerate secure and resilient cloud and AI transformation at scale whilst assuring business continuity.” – Fernando Alvarez, Chief Strategy and Development Officer and Group Executive Board Member, Capgemini

“Autonomy, resilience and operational control are foundations driving digital sovereignty concerns across the public sector and regulated industries. Achieving sovereignty requires more than a sound and consistent architecture; it demands operational evidence to build trust. The AWS European Sovereign Cloud team has provided evidence, supporting organizations on the transformation of their critical data and digital assets toward greater sovereign control. Having engaged with this team since the inception of the project, and as a Launch Partner of the AWS Digital Sovereignty Competency, Atos helps customers define their sovereignty roadmaps, adopt the appropriate graduated solutions, and confidently operate and govern their target sovereignty posture.” – Michael Kollar, Digital Sovereignty Leader and Head of Cloud & Modern Infrastructure and Digital Workplace, Atos Group

“For organizations in regulated industries, meeting strict data and operational requirements cannot come at the cost of a great customer experience. Running on the AWS European Sovereign Cloud, Genesys can help European organizations deliver exactly that, with their data and operations kept in the EU. Seeing the AWS European Sovereign Cloud operate independently under real conditions helps give our shared customers added confidence to move their most sensitive workloads to the cloud.” – Daniel Karadza, Senior Director, Partners and Alliances, EMEA Central and Benelux, Genesys

“Operational independence is a defining pillar of digital sovereignty, and the AWS European Sovereign Cloud has shown what that means in practice. It runs without reliance on any infrastructure outside the EU and is operated entirely by EU residents, which makes it a strong fit for Europe’s regulated industries and public sector. As an early collaborator with the AWS European Sovereign Cloud team before its launch, Accenture is uniquely positioned to help clients navigate sovereignty requirements and scale with greater confidence and control.” – Emanuele Baldassarre, Managing Director, Accenture

Learn more

To learn more about the design and digital sovereignty controls of the AWS European Sovereign Cloud, visit aws.eu. If you have questions about this exercise or want to discuss your workloads, reach out to AWS Support or contact your AWS Account team.

Stephane Israel

Stéphane Israël

Stéphane is the leader and Managing Director of the AWS European Sovereign Cloud. He is responsible for the management and operations of the AWS European Sovereign Cloud, including infrastructure, technology, and services, in addition to broader digital sovereignty efforts at AWS. Prior to AWS, he was the CEO of Arianespace, where he oversaw numerous successful space missions, including the launch of the James Webb Space Telescope.

Kernel prepatch 7.4-rc1

Post Syndicated from corbet original https://lwn.net/Articles/1104654/

The 7.4-rc1 kernel prepatch is out, and
the merge window is closed for this development cycle.

This is a *BIG* merge window. I think the reason is the by now
obvious one, but I’m actually taking it as a good sign: I’m *much*
happier with the flood of AI triggered work going into the merge
window than it showing up mainly as extra fixes during the -rc
period. So I’m hoping that this merge window being larger than
usual is a sign that the AI fixes are becoming more part of the
“normal development” than a flood of fixes that go into the whole
stabilization phase. I think that’s a much healthier model.

There were 18,591 non-merge changesets brought in during this merge window
— this is not just a record, but it nearly matches the patch volume during
the entire (record-setting) 7.3 development cycle. So far, 2,678
developers have contributed to 7.4; 625 of them are first-time kernel
contributors. Subscribers can find more details in the KSDB 7.4 page.

Final release for the 7.2 stable series

Post Syndicated from jzb original https://lwn.net/Articles/1104629/

Greg Kroah-Hartman has announced the release of the
7.2.15 kernel, with a handful of updates.

Note, this is the LAST 7.2.y kernel release. After this one the 7.2.y kernel
tree is end-of-life. Please move to 7.3.y at this time.

And yes, you aren’t imagining things, this one went “end-of-life” a bit sooner
than normal. But based on the release cycle at the moment, and the number of
pending cc: stable patches in the queue, I figured it was better this way so we
can focus on the latest 7.3.y release as it would require us to keep 8
different branches alive at the same moment, a taxing task under the best of
times.

A massive pile of security updates for Saturday

Post Syndicated from corbet original https://lwn.net/Articles/1104612/

Security updates have been issued by AlmaLinux (.NET 10.0, .NET 11.0, .NET 8.0, .NET 9.0, aspell, bind, bind9.18, container-tools:1.0, container-tools:rhel8, curl, dogtag-pki, ignition, java-21-openjdk, python-pillow, tomcat, and virt:rhel, virt-devel:rhel), Debian (antiword, cyrus-sasl2, dovecot, dpdk, nss, python-git, and thunderbird), Fedora (7zip, aegisub, aom, apptainer, arm-none-eabi-binutils-cs, assimp, avr-binutils, baresip, barman, bind9-next, btrfs-backup-ng, chezmoi, chromium, cifs-utils, clevis-pin-trustee, composer, containerd, curl, docker-buildx, dotnet10.0, evolution, evolution-data-server, evolution-ews, exim, fips-provider, firefox, flare-im, forgejo, freeipa, freerdp, gcc, gegl04, ghostscript, GitPython, glib-networking, gnome-shell-extension-gsconnect, golang-x-mobile, hcloud, helix, httpd, ImageMagick, iperf3, jfrog-cli, jupyterlab, keepassxc, kernel, knot-resolver, krb5, kryoptic, libdigidocpp, libheif, libindi, libinstpatch, libpng12, libpng15, librabbitmq, libre, libXi, libzip, linux-firmware, Lmod, log4net, markdownlint-cli2, mingw-freetype, mingw-gstreamer1, mingw-gstreamer1-plugins-bad-free, mingw-gstreamer1-plugins-base, mingw-gstreamer1-plugins-good, mingw-libpng, mingw-LibRaw, mingw-python-certifi, mingw-python3, mongo-c-driver, mstflint, mutt, nant, nebula, nix, nsd, ntpsec, openbao, openjpeg, openssl3, openvpn, perl-Badger, perl-CLI-Simple, perl-Cpanel-JSON-XS, perl-CSS-Inliner, perl-Encoding-FixLatin, perl-ExtUtils-Typemaps-Default, perl-GD-SecurityImage, perl-HTML-Query, perl-libnet, perl-Markdown-Render, perl-Net-IDN-Encode, perl-Net-Whois-Raw, perl-Plack, perl-Plack-Middleware-ReverseProxy, perl-Text-CSV_XS, pgbouncer, php-getid3, php-pecl-mongodb2, python-boto3, python-botocore, python-cairosvg, python-django5, python-django6, python-jupyter-builder, python-mkdocs-rss-plugin, python-nbdime, python-nh3, python-notebook, python-pydantic-core, python-pypdf, python-uv-build, python3.10, python3.11, python3.12, python3.13, python3.14, qdigidoc, qdl, qt5-qtbase, radicale, rclone, rt, ruff, rust-ammonia, rust-archive-trait, rust-astral-html, rust-astral-ini, rust-astral-mail-headers, rust-astral-pubgrub, rust-astral-version-ranges, rust-astral_async_http_range_reader, rust-astral_async_zip, rust-asyncband, rust-backtrace, rust-blake2b_simd, rust-blake3, rust-cargo-semver-checks, rust-chrono, rust-clap-cargo, rust-constant_time_eq, rust-dua-cli, rust-faster-hex, rust-gengo-bin, rust-gitui, rust-lzma-rust2, rust-object, rust-object0.37, rust-object0.38, rust-object0.39, rust-onefetch, rust-ppmd-rust, rust-quick-junit, rust-rbw, rust-regorus, rust-reqsign, rust-reqsign-aliyun-oss, rust-reqsign-aws-core, rust-reqsign-aws-v4, rust-reqsign-aws-v4a, rust-reqsign-azure-storage, rust-reqsign-command-execute-tokio, rust-reqsign-core, rust-reqsign-file-read-tokio, rust-reqsign-google, rust-reqsign-http-send-reqwest, rust-reqsign-huaweicloud-obs, rust-reqsign-oracle, rust-reqsign-tencent-cos, rust-reqsign-volcengine-tos, rust-routinator, rust-rustls, rust-ruzstd, rust-sccache, rust-tar-codec, rust-tar-framing, rust-tokei, rust-totp-rs, rust-trustfall-rustdoc-adapter, rust-trustfall-rustdoc-adapter57, rust-trustfall-rustdoc-adapter60, rust-typed-path, rust-zip, rust-zip0.6, rust-zip2, rustup, samba, SDL3_image, socat, stargz-snapshotter, stgit, sudo, syncthing, thunderbird, tor, trafficserver, ty, unbound, unshield, uv, webkitgtk, wordpress, xorg-x11-server, xorg-x11-server-Xwayland, zchunk, and zvbi), Mageia (libgit2), Red Hat (go-toolset:rhel8 and rhc), SUSE (ab-av1, ansible-core, aws-nitro-enclaves-cli, bouncycastle, cadvisor, chromium, cifs-utils, coredns, crun, dr_libs-devel-20260901, dssim, epiphany, expat, forgejo, freetype2-devel, fuseiso-20260614, gh, ghostscript, gosec, gvfs, hashcat, hauler, hugo, ImageMagick, kernel-devel, kubevirt1.9, libmikmod, libsoup, percona-toolkit, perl-cpanel-json-xs, perl-dancer2-plugin-auth-extensible, perl-mozilla-ca, pocketbase, putty, python-brotli, python-CairoSVG, python-cairosvg, python-django, python-pypdf, python-urllib3_1, roundcubemail, rsyslog, shadowsocks-rust, shadowsocks-libev, stgit, suseconnect-ng, tailscale, trivy, and vlc), and Ubuntu (brotli).

How We Could Have Backdoored Bash (Hacktron blog)

Post Syndicated from corbet original https://lwn.net/Articles/1104262/

The Hacktron blog documents how
the group was able to compromise the GNU Savannah forge and could have
pushed malware into any of the projects hosted there.

Using Hacktron, we found that an email address like
`touch${IFS}/tmp/savane-rce-proof`@attacker.example gave any
registered user code execution on its backend. From there, we made
our account a superuser, impersonated Bash’s maintainer, and
confirmed we could add an SSH key with push access to the upstream
Bash repository. An unpatched kernel gave us root access and access
to a GNU backup server. We reported it to the FSF on May 11, 2026.

The collective thoughts of the interwebz