No more Chrome Apps for Google Chrome users

The progress of modern browsers puts the Web in a good position to answer the vast majority of use cases - evident in the success of companies like Figma and our own products like Google Earth. We are confident that the Web can deliver first class experiences on an open platform. With this continued progress, we are expanding upon our earlier announcement and will begin phasing out support for Chrome Apps across all operating systems

Google will phase out the support for Chrome Apps in several steps and finally stop their support for good in 2022. However Chrome Extension will remain a valid way to provide always accessible cross-site capabilities to desktop users. Overall this a good step as it reduces the probability of pseudo web apps that might depend on specific Chrome APIs. This would break one of the basic web principles, i.e. platform independence and portability. With the advent of PWAs the need for low-level integration of non-trivial functionality has just been reduced.

Chrome, Web

NoOps is DevOps brought to its final conclusion

NoOps (no operations) is the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house. Traditionally in the enterprise, an application development team is in charge of gathering business requirements for a software program and writing code. The development team tests their program in an isolated development environment for quality assurance (QA) and -- if requirements are met -- releases the code to an operations team who deploys and maintains the program from that point on. In a NoOps scenario, maintenance and other tasks performed by the operations team would be automated.

NoOps is probably one of those attention-drawing buzzwords without any new concept behind. Still it is one of those buzzwords that help to re-focus attention on the automation aspect of the already well-known DevOps role. I would not be surprised if Pivotal Inc. have coined this buzzword as NoOps assumes a self-service platform that takes care of everything DevOps used to take care of.

DevOps, Cloud, Software Development

Mozilla struggles to find a sustainable business model

Mozilla laid off about 70 employees today, TechCrunch has learned. In an internal memo, Mozilla chairwoman and interim CEO Mitchell Baker specifically mentions the slow rollout of the organization’s new revenue-generating products as the reason for why it needed to take this action. The overall number may still be higher, though, as Mozilla is still looking into how this decision will affect workers in the U.K. and France. In 2018, Mozilla Corporation (as opposed to the much smaller Mozilla Foundation) said it had about 1,000 employees worldwide.

The implications for Firefox development might be not necessary dramatic. A layoff usually affects the bloated process machinery which emerges in every organization and serves no purpose but make everything slower an more complicated. A browser vendor starts to become political and wants to "fight fake news". This layoff might help Mozilla to focus on things that actually matter - providing an alternative to Google's Chrome browser that cements Google's web dominance.

Mozilla, Firefox, Google

HTTP/3 the successor of HTTP/2 that makes the web even QUICer

HTTP/3 promises to make Internet connections faster, more reliable, and more secure. Born as "HTTP over QUIC", an effort to adapt the HTTP protocol to run on top of Google's own transport layer protocol, QUIC, it was later proposed as an IETF standard and it is currently an Internet Draft. [...] QUIC is a key element of HTTP/3, since it provides the foundations for its main features. Built on top of UDP, QUIC attempts to solve the major issues experienced when using the TCP protocol, i.e., connection-establishment latency and multi-stream handling in the presence of packet loss. TCP latency issue stems from the requirements of its congestion control algorithm, which mandates for a slow start to assess how much traffic can be sent before congestion occurs. This compounds, in HTTP/1.0, with the fact each TCP request/response exchange is assigned a new connection, thus incurring the slow-start penalty.

Unlike HTTP/2 which runs on top of TCP, HTTP/3 will leverage the UDP protocol which does not provide any delivery guarantees. However as reliability is a major challenge, the corresponding delivery guarantee logic will be moved up the protocol stack, right into HTTP/3 itself. HTTP/3 will transfer the payload not using text - like HTTP/1 is doing - but just as HTTP/2, also HTTP/3 will keep using a binary encoding for its payload. As HTTP/3 is built upon QUIC, which leverages UDP... HTTP/3 protocol updates will be delivered over the userland space without touching the OS kernel space because the only underlying required primitive is UDP!

Web, IETF, Internet

The microservice framework Quarkus 1.2 integrates well with the polyglot runtime GraalVM 19.3

One of the highly anticipated features of Quarkus 1.1.0.CR1 was the GraalVM 19.3 support. GraalVM 19.3 changes quite a lot of things (JDK 11 preview etc) and due to the deep integration between Quarkus and GraalVM, it was an all-or-nothing update for us as we couldn’t support both GraalVM 19.2 and 19.3 at the same time. While porting Quarkus to GraalVM 19.3, we hit several regressions, some due to Quarkus not doing the right thing (we fixed them), some due to GraalVM regressions (we are working hand in hand with the GraalVM team to fix them). The next micro bugfix release of GraalVM is planned for mid-January, so any workaround had to come from Quarkus and by writing substitutions.

GraalVM is a Java based polyglot runtime in the sense that it can serve as a common execution runtime not only for bytecode based languages like Java, Kotlin, and Scala but also for Python, JavaScript, Rust, C, and C++. Quarkus is a microservice framework with a focus on GraalVM integration. However you do not need to use Quarkus instead of e.g. Spring Boot to leverage GraalVM.

Java, GraalVM, Software Development

Apple wants to reduce its dependency on external suppliers, incl. China

Apple is trying to change the way electronics are recycled with a robot that disassembles its iPhone so that minerals can be recovered and reused, while acknowledging rising global demand for electronics means new mines will still be needed. The Cupertino, California-based company says the robot Daisy is part of its plan to become a “closed-loop” manufacturer that does not rely on the mining industry, an aggressive goal that some industry analysts have said is impossible.

After obtaining the capability & facilities to recycle major parts of their hardware output, Apple might also lobby for tougher environment standards and use their recycling capabilities as a competitive advantage. Still this strategy is everything but altruism as Apple will market itself as a brave fighter against climate change which hits the zeitgeist quite well. Just a few people will question whether their habit to buy a new iPhone every year is what actually burdens the environment.

Apple, iPhone, Hardware

F2FS, a file system, tuned for Android scenarios, lands as rootfs option in Debian

For these like me who want to change their root filesystem to F2FS, I have enabled support for adding the F2FS module in the EFI signed image of grub in Debian. So the grub EFI image can load configuration, kernel images and initrd from a /boot that is formatted in F2FS (the upstream grub supports the filesystem since 2.04).

F2FS is a flash-friendly file system that is used by some Android flavors like Huawei's EMUI. So we see a further ongoing convergence between the mobile Linux, Android and the desktop & server Linux, Debian.

Android, Debian, Linux

Technology matters but social dynamics matter even more

The problem is their organization’s unhelpful processes, behavior, and culture. You can think of these as “thought technologies,” but I like to call them “meatware.” Much of what it takes — to transform IT organizations into centers for innovation — is about changing the IT culture from a command and control, big planning up-front, organized by function (or “silo’d”) mind-set.

"Meatware" is probably one of the slang-ishly summarized aspects of Conway's law. Specifically meatware refers to people of an organization who are the ultimate executors and implementers of a company's culture and its processes.

Organization, Corporate Culture

Sun's Oracle's ZFS file system on Linux

Note that "we don't break users" is literally about user-space applications, and about the kernel I maintain. If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it, and I can not be bound by other peoples kernel changes. And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd. Other people think it can be ok to merge ZFS code into the kernel and that the module interface makes it ok, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so. And I'm not at all interested in some "ZFS shim layer" thing either that some people seem to think would isolate the two projects. That adds no value to our side, and given Oracle's interface copyright suits (see Java), I don't think it's any real licensing win either. Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me. The benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?

Despite Linus being everything but an empathetic individual, he makes a valid point: people who integrate ZFS with Linux, risk a law suit with Oracle. And with Android & Java Oracle has already shown that its willing to sue anything with a heartbeat.

Linux, ZFS

Java 14 brings the Linux-only ZGC garbage collector to Windows & macOS

Most of the ZGC code base is platform independent and requires no Windows-specific changes. The existing load barrier support for x64 is operating-system agnostic and can also be used on Windows. The platform specific code that needs to be ported relates to how address space is reserved and how physical memory is mapped into a reserved address space. The Windows API for memory management differs from the POSIX API and is less flexible in some ways.

ZGC enables the Java platform to manage very large heaps more efficiently. Usually large heap sizes result in longer pause times required by the GC to free up memory. Actually large heap memory might have a very negative impact on application responsiveness. Hence just increasing the heap memory in order to improve performance, might actually make it worse. The ZGC implementation is particularly useful for server scenarios.

Java, Windows, macOS