CentOS 8 Rebased on RHEL 8.2

We are pleased to announce the general availability of CentOS Linux 8. Effectively immediately, this is the current release for CentOS Linux 8 and is tagged as 2004, derived from Red Hat Enterprise Linux 8.2 Source Code. As always, read through the Release Notes at : http://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.2004 - these notes contain important information about the release and details about some of the content inside the release from the CentOS QA team. These notes are updated constantly to include issues and incorporate feedback from the users.

Actually I am elaborating and test driving Fedora as an alternative to both Ubuntu on my Desktop and Debian on my server.

Ubuntu, Debian, Fedora, OpenStack, RedHat

Java 16 moves from Mercurial to Git and to GitHub as collaboration platform

An external source-code hosting provider is a source-code repository service that is not implemented and managed by contributors in the OpenJDK Community. Examples of external providers are BitBucket, GitLab, Phacility, SourceForge and GitHub. There are three primary reasons for the OpenJDK Community to use an external source-code hosting provider: Performance. Many, if not all, providers have excellent performance, not only with regard to network performance but also when it comes to availability, i.e., uptime. For the OpenJDK Community this would result in significantly faster clone and pull times, and more highly-available source-code repositories. API. A technical reason to host OpenJDK repositories on a source-code hosting platform is to gain access to web APIs that enable programs to interact with developers on the platform. Although not impossible to achieve today by interacting with developers over email, it is considerably harder to implement programs that interpret free-form text in emails compared to using a structured API. Allowing programs to participate in the review process enables powerful automation; see the Description section for several examples. Expanded community. The largest providers would also offer the OpenJDK Community the opportunity to tap into large existing communities of developers and potential contributors. If a developer already has an account on a provider then few additional steps are required in order to contribute to OpenJDK. Almost all open-source projects in the larger Java community are hosted on an external providers, including several OpenJDK distributions. This can foster an even closer collaboration if OpenJDK repositories are also hosted on the same provider.

With GitHub, Microsoft acquired yet another platform that is going to be choked slowly, just like any other product a major corporation acquired. Just look into the history of any business and corporation acquisition. The is not a single product that thrived long-term after a major corporation bought it.

Google, Microsoft, OpenJDK, Hg

Linux is faster than Windows - for non-server workloads too

If taking the geometric mean of those 101 tests, Ubuntu 20.04 LTS on the Core i9 10900K was faster than Windows 10 May 2020 by just about 2%... Much closer results than we have seen out of past Intel comparisons with largely similar tests being run or even the recent Threadripper tests with largely overlapping tests being run where it was a 20% difference. As for why the Core i9 10900K is running so competitive between Windows 10 May 2020 and Ubuntu 20.04 LTS is a good question. Whether it's due to recent Intel optimizations to Windows 10 and/or (Ubuntu) Linux performing subpar for the latest generation Comet Lake processors remains to be determined. Given the aggressive Turbo Boost handling with the Core i9 10900K for being able to hit up to 5.3GHz, it wouldn't surprise me the least if Windows at the moment is offering better handling for Turbo Boost Max / Thermal Velocity Boost handling than Linux. There has also been a lot of recent Intel power management Linux work in flux at the moment as well around migrating P-State to the Schedutil frequency governor and other changes. As time allows and depending upon interest from premium readers, I may dig deeper into exploring the current Windows/Linux behavior of the i9-10900K and seeing in comparison how the Windows 10 May 2020 vs. Ubuntu 20.04 LTS performance stacks up for older Intel CPUs to see if the more competitive Intel Windows performance is a new phenomenon or indeed just limited to newer Comet Lake processors.

Performance really does not matter as far as the difference remains withing single digits. What I miss is a UX benchmark that measures how productive somebody is with an OS. When was the last time when you said: oh, when only Windows would be 5, 10 yes even 20% faster than Linux I would switch? So marginal performance differences are absolutely nothing when the UX has major flaws. I mean Windows hat cmd.exe as the only built-in terminal for decades. This was a major flaw indeed!

macOS

Fuchsia OS is about to replace Android OS

Fuchsia is designed for security and privacy Security and privacy are woven deeply into the architecture of Fuchsia. The basic building blocks of Fuchsia, the kernel primitives, are exposed to applications as object-capabilities, which means that applications running on Fuchsia have no ambient authority: applications can interact only with the objects to which they have been granted access explicitly. Software is delivered in hermetic packages and everything is sandboxed, which means all software that runs on the system, including applications and system components, receives the least privilege it needs to perform its job and gains access only to the information it needs to know. Fuchsia is designed to be updatable Fuchsia works by combining components delivered in packages. Fuchsia packages are designed to be updated independently or even delivered ephemerally, which means packages are designed to come and go from the device as needed and the software is always up-to-date, like a Web page. Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers.

Just like Go, Fuchsia seems to pursue a pragmatic philosophy, not trying to built upon a microkernel but a sweetspot kernel concept that solves actual problems, instead of following a microkernel dogma.

Sailfish, iOS, iPadOS

Nashorn JavaScript Engine leaves Java with JDK 15

Summary Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release. Motivation The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard. With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.

A good approach to streamline the Java standard runtime and focus on what matters.

OpenJDK, Java 15, JVM

Quarkus, an alternative to Spring Boot, backed by Red Hat

Quarkus is more than just a runtime. It is a Kubernetes-native Java stack for building fast, lightweight microservices and serverless applications. It is purpose-built to capitalize on the benefits of cloud-native applications. Quarkus delivers significant runtime efficiencies for applications deployed on Kubernetes with fast startup times, low memory utilization, and small image footprints. Everything you need to grow your career. With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development. SIGN UPEverything you need to grow your career. A modern Java stack One of the founding principles of the Quarkus project was to bring developer joy to enterprise Java developers. What does that mean, and how does Quarkus bring joy? Kubernetes-native Java Quarkus is a Kubernetes-native Java framework targeted for containers and serverless due to its fast startup, low memory, and small application size.

For me Quarkus not worth not rewrite any Ktor or Spring Boot app that does not have any major issues. Quarkus is still on the level of being yet another service framework than a fundamentally new way of developing services.

Spring Boot, Quarkus, Kotlin, Java, Ktor

GraalVM shows promising performance and outperforms OpenJDK in many cases

GraalVM offers a comprehensive ecosystem supporting a large set of languages (Java and other JVM-based languages, JavaScript, Ruby, Python, R, WebAssembly, C/C++ and other LLVM-based languages) and running them in different deployment scenarios (OpenJDK, Node.js, Oracle Database, or standalone). This page provides an overview of different scenarios in which GraalVM can make a difference for your applications. Some of versatile GraalVM capabilities, that might be missing on this page are thoroughly summarized and disclosed in Top 10 Things To Do With GraalVM blog post. For Java Programs For existing Java applications, GraalVM can provide benefits by running them faster, providing extensibility via scripting languages, or creating ahead-of-time compiled native images. Run Java Faster GraalVM can run in the context of OpenJDK to make Java applications run faster with a new just-in-time compilation technology. GraalVM takes over the compilation of Java bytecode to machine code. In particular for other JVM-based languages such as Scala, this configuration can achieve benefits, as for example experienced by Twitter running GraalVM in production.

A common runtime for all popular and industry-relevant languages, the GraalVM is not only backed by Oracle but also Red Hat.

OpenJDK, Rust, Kotlin, Java

Due to memory safety issues, Chromium considers evaluating safe programming languages

The problem Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Pie chart of uses-after-free, other memory safety, other security bug, security asserts (Analysis based on 912 high or critical severity security bugs since 2015, affecting the Stable channel.) These bugs are spread evenly across our codebase, and a high proportion of our non-security stability bugs share the same types of root cause. As well as risking our users’ security, these bugs have real costs in how we fix and ship Chrome. The limits of sandboxing Chromium’s security architecture has always been designed to assume that these bugs exist, and code is sandboxed to stop them taking over the host machine. Over the past years that architecture has been enhanced to ensure that websites are isolated from one another. That huge effort has allowed us — just — to stay ahead of the attackers. But we are reaching the limits of sandboxing and site isolation. A key limitation is that the process is the smallest unit of isolation, but processes are not cheap. Especially on Android, using more processes impacts device health overall: background activities (other applications and browser tabs) get killed with far greater frequency. We still have processes sharing information about multiple sites. For example, the network service is a large component written in C++ whose job is parsing very complex inputs from any maniac on the network. This is what we call “the doom zone” in our Rule Of 2 policy: the network service is a large, soft target and vulnerabilities there are of Critical severity. Just as Site Isolation improved safety by tying renderers to specific sites, we can imagine doing the same with the network service: we could have many network service processes, each tied to a site or (preferably) an origin. That would be beautiful, and would hugely reduce the severity of network service compromise. However, it would also explode the number of processes Chromium needs, with all the efficiency concerns that raises. Meanwhile, our insistence on the Rule Of 2 is preventing Chrome developers from shipping features, as it’s already sometimes just too expensive to start a new process to handle untrustworthy data.

No matter whether Rust or Kotlin will become the language of choice, both are backed by LLVM which will ultimately become an even more important piece of technology.

Chromium, Rust, Kotlin, Java

TUXEDO Book BA15, a Linux notebook from Germany

It's running and running and running and running and ... The almost only way to stop the TUXEDO Book BA15 is to switch it off. Sounds odd? Well, our BA15 combines AMDs incredible power-efficient Ryzen 5 3500U mobile processors with a huge 91Wh battery for groundbreaking runtimes whilst providing strong performance for all everyday tasks. Groundbreaking battery runtime thanks to its 91 Wh capacity Due to its very large 91,25 Wh battery the TUXEDO Book BA15 is even able to reach maximum runtimes of up to 25 hours in power-saving idle mode. Even in more practical every day situations the 15.6 inch laptop lasts for very long times, so that you can do your daily work, websurfing, mail-writing and such things for up to 13 hours, even 1080p videostreaming at 50% of display brightness results in up to 10 hours of battery life.

For the Linux user base to grow, it needs to become a commercially viable option that comes pre-installed alongside notebooks for professionals.

Linux

Microsoft builds a Wayland compositor as part of its Linux on Windows endeavor

In term of presentation, I need to clarify a few things. We announced today that we're also adding support for Linux GUI applications. The way this will work is roughly as follow. We're writing a Wayland compositor that will essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). We're starting from a Weston base. Weston already has an RDP Backend, but that's for a full desktop remoting scheme. Weston draws a desktop and remote it over RDP... and then you can peek at that desktop using an rdp client on the Windows side. RAIL works differently. In that case our wayland compositor no longer paint a desktop... instead it simply forward individual visual / wl_surface over the RDP RAIL channel such that these visual can be displayed on the Windows desktop. The RDP client create proxy window for each of these top level visual and their content is filled with the data coming over the RDP channel. All pixels are owned by the RDP server/WSL... so these windows looks different than native window are they are painted and themed by WSL. The proxy window on the host gather input and inject back over RDP... This is essentially how application remoting works on windows and this is all publicly documented as part of the various RDP protocol specification. As a matter of fact, for the RDP server on the Weston side we are looking at continue to leverage FreeRDP (and provide fixes/enhancement as needed to the public project). Further, we're looking at further improvement down this path to avoid having to copy the content over the RAIL channel and instead just share/swap buffer between the guest and the host. We have extension to the RDP protocol, called VAIL (Virtualized Application Integrated Locally) which does that today. Today this is only use in Windows on Windows for very specific scenario. We're looking at extending the public RDP protocol with these VAIL extension to make this an official Microsoft supported protocol which would allow us to target this in WSL. We have finished designing this part in details. Our goal would be to leverage something along the line of wl_drm, dma-buf, dma-fence, etc... This compositor and all our contribution to FreeRDP will be fully open source, including our design doc. We're not quite sure yet whether this will be offered as a separate project entirely distinct from it's Weston root... or if we'll propose an extension to Weston to operate in this mode. We would like to build it such that in theory any Wayland compositor could add support for this mode of operation if they want to remote application to a Windows host (over the network, or on the same box).

Microsoft continues to invest into the interoperability of Linux and Windows. The only question remain who will benefit more from those contributions the Linux or the Microsoft ecosystem. Last but not least there is also the question of whether Microsoft pursues the strategy of feeding something before one consumes it alive.

DirectX, Windows, macOS, GNOME, Wayland