We had an amazing day on May 15, as we organized SCS Fay Day Experience #4! We welcomed fans of our games from all around the world to our office in Prague, where they had the opportunity to meet our team, tour the studio, and get a behind-the-scenes look at how our games are made.
After receiving a huge number of applications for this fourth edition of our SCS Fan Day, we had to narrow the list down to a smaller group of some of our most dedicated fans, including visitors who traveled all the way to Prague from countries such as Brazil.
As always, it turned into an unforgettable experience meeting and chatting with members of our #BestCommunityEver. Once everyone arrived, they took on the challenge of driving on our 4D motion simulator before heading out on a tour of the office. Along the way, we stopped by several departments where our colleagues gave them a behind-the-scenes look at what they are currently working on and how the development process looks at SCS Software.
Later in the afternoon, we hosted a special Q&A session with our developers and CEO Pavel Ε ebor, where we discussed the community's thoughts on our games and answered plenty of questions from our guests. The session was accompanied by delicious snacks and coffee before we gathered for a group photo, handed out bags filled with SCS merchandise, and unfortunately had to say goodbye - at least until we hopefully meet again someday!
We would like to thank everyone who took part in this year's Fan Day. We hope it was a memorable experience for you, because it was certainly unforgettable for us as well. Your passion, support, and willingness to travel such long distances just to meet us truly means the world to everyone here at SCS Software, and it continues to motivate us every day. We also hope to meet again with everyone who applied but was not selected or was unable to attend this time around.
We hope we will be able to host another Fan Day in the future and meet even more of our amazing fans. Don't forget to give ourΒ X/Twitter,Β Instagram,Β Facebook,Β Bluesky, andΒ TikTokΒ a follow, as you'll receive news from any upcoming events straight to your feed, orΒ subscribe to our newsletterΒ to stay informed.
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.
Fixed a crash experienced by users with Intel Raptor Lake CPUs. (Bug 1950764)
Fixed an issue on Windows where some websites using WebSerial to flash device firmware could fail unexpectedly. (Bug 2040754)
Reference link to 151.0 release notes.
This is a security release to address a brute-force based vulnerability related to multi-factor authentication, and to update project libraries to help avoid potential vulnerabilities that have been reported in those.
Upgrade is generally advised, but strongly so where multi-factor authentication is used & considered as a critical layer of defense.
Thanks to Stephen O. / Sakusen (Codeberg, Website) for responsibly reporting these issues.
VIENNA, Austria β May 21, 2026 β Proxmox Server Solutions GmbH today announced the immediate availability of Proxmox Virtual Environment 9.2, the latest version of its integrated open-source platform for enterprise virtualization. This major update introduces a dynamic load balancer, expanded software-defined networking (SDN) capabilities, and granular management of custom CPU models. By improving resource utilization through dynamic workload balancing and simplifying complex cluster maintenance workflows, Proxmox VE 9.2 enables organizations to scale their infrastructure with higher efficiency and significantly reduced operational complexity.
Dynamic Load Balancer
A highlight of version 9.2 is the introduction of the Dynamic Load Balancer, which utilizes an intelligent decision-making framework to optimize guest placement for maximum cluster balance and reliability. Operating in a new dynamic mode, the cluster resource scheduler (CRS) incorporates real-time node and guest resource utilization into every placement decision. The integrated load balancer can automatically migrate guests managed by the High Availability (HA) stack to reduce the imbalance across the cluster nodes while strictly respecting all user-defined HA rules. Administrators maintain granular control through configurable options that define the behavior and sensitivity of the load Balancer through various parameters, providing organizations with superior oversight of resource utilization in highly available environments.
Expanded software-defined networking (SDN)
This release significantly improves its SDN stack to support modern network architectures.
Further additions include route redistribution for OSPF fabrics, additional options for configuring EVPN controllers, and IPv6 underlay support for EVPN.
Custom CPU model management
To provide greater flexibility for specialized workloads, Proxmox VE 9.2 introduces a dedicated management interface for custom CPU models. Administrators can now create, edit, and remove custom CPU profiles directly in the web interface under the βDatacenterβ section. This makes it easier to tailor the virtual CPU features exposed to VMs, ensuring optimal workload performance. Additionally, the integrated CPU flags selector provides instant visibility into supported flags across all cluster nodes, helping administrators identify potential cluster-wide compatibility issues during the configuration phase.
Confident maintenance with HA Arm/Disarm
Addressing common administrative challenges during maintenance windows, Proxmox VE 9.2 introduces the ability to "disarm" and "arm" the HA Manager cluster-wide. Administrators can temporarily suspend the HA stack during planned cluster maintenance to prevent unwanted actions, such as fencing nodes. HA resource states are preserved during these disarm and arm cycles, ensuring HA resources return to their previous state and node placement automatically once maintenance is completed.
Updated technology stack
Proxmox Virtual Environment 9.2 is based on Debian 13.5 "Trixie" and features Linux kernel 7.0 as the new stable default. Along with the latest versions of QEMU 11.0, LXC 7.0, and ZFS 2.4, this release offers a high-performance open-source architecture for modern infrastructure.
As a complete data center ecosystem engineered for high-density virtualization and disaster recovery, version 9.2 provides businesses with a seamless management environment for compute, storage, and backup. This includes updated support for the storage layer, with Ceph Tentacle 20.2. now available as a stable option alongside Ceph Squid 19.2.
Proxmox Virtual Environment 9.2 is open-source software and immediately available for download at the official website. Users can obtain a complete installation image via ISO download, which contains the full feature set of the solution and can be installed quickly on bare-metal systems using an intuitive installation wizard.
Seamless distribution upgrades from older versions of Proxmox Virtual Environment are possible using the standard APT package management system. Furthermore, it is also possible to install Proxmox Virtual Environment on top of an existing Debian installation.
For enterprise environments, Proxmox offers comprehensive support plans that provide direct access to expert support services and stable and secure updates. These support contracts offer a cost-effective way to secure enterprise-grade stability, with pricing starting at EUR 120 per year and CPU.Β
Resources:
About Proxmox Virtual Environment
Powering over 2 million hosts globally, Proxmox Virtual Environment is a complete open-source platform for enterprise virtualization and hyper-converged infrastructure. It natively unifies KVM virtualization, LXC containers, software-defined storage, and networking on a single platform. Alongside its dedicated Backup Server and Datacenter Manager, the Proxmox ecosystem eliminates multi-site complexity as well as dependency on proprietary stacks. Backed by a global community of over 225,000 members, the platform serves as a scalable, cost-effective foundation for modern data centers.
About Proxmox Server Solutions
Proxmox Server Solutions provides powerful, intuitive open-source server software that guarantees vendor independence and minimizes total cost of ownership. Enterprises of all sizes rely on the companyβs reliable vendor support, certified training services, and a global network of 3,000 integration partners to ensure business continuity. Established in 2005 and headquartered in Vienna, Austria, tens of thousands of corporate customers worldwide trust Proxmox solutions to secure their mission-critical IT environments. To learn more visit https://www.proxmox.com or follow us on LinkedIn and YouTube.
Contact:Β Daniela HΓ€sler, Proxmox Server Solutions GmbH,Β marketing@proxmox.com
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)
We are pleased to announce the latest stable release of Jellyfin, version 10.11.9! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!
You can find more details about and discuss this release on our forums.
We are pleased to announce the latest stable release of Jellyfin, version 10.11.9! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!
You can find more details about and discuss this release on our forums.
The Stable channel has been updated to 149.0.7827.22/.23 for Windows and Mac (149.0.7827.29/.30) ,as part of our early stable release to a small percentage of users. A full list of changes in this build is available in the log.
You can find more details about early Stable releases here.
Interested in switching release channels? Β Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Srinivas Sista
Google Chrome
Full Changelog: v4.3.2...v4.3.3
