Language Selection

English French German Italian Portuguese Spanish

Latest of LWN (Paywall Expired)

Filed under
  • Python 3, ASCII, and UTF-8

    The dreaded UnicodeDecodeError exception is one of the signature "features" of Python 3. It is raised when the language encounters a byte sequence that it cannot decode into a string; strictly treating strings differently from arrays of byte values was something that came with Python 3. Two Python Enhancement Proposals (PEPs) bound for Python 3.7 look toward reducing those errors (and the related UnicodeEncodeError) for environments where they are prevalent—and often unexpected.

    Two related problems are being addressed by PEP 538 ("Coercing the legacy C locale to a UTF-8 based locale") and PEP 540 ("Add a new UTF-8 Mode"). The problems stem from the fact that locales are often incorrectly specified and that the default locale (the "POSIX" or "C" locale) specifies an ASCII encoding, which is often not what users actually want. Over time, more and more programs and developers are using UTF-8 and are expecting things to "just work".

  • Shrinking the kernel with link-time garbage collection

    One of the keys to fitting the Linux kernel into a small system is to remove any code that is not needed. The kernel's configuration system allows that to be done on a large scale, but it still results in the building of a kernel containing many smaller chunks of unused code and data. With a bit of work, though, the compiler and linker can be made to work together to garbage-collect much of that unused code and recover the wasted space for more important uses.
    This is the first article of a series discussing various methods of reducing the si

  • The current state of kernel page-table isolation

    At the end of October, the KAISER patch set was unveiled; this work separates the page tables used by the kernel from those belonging to user space in an attempt to address x86 processor bugs that can disclose the layout of the kernel to an attacker. Those patches have seen significant work in the weeks since their debut, but they appear to be approaching a final state. It seems like an appropriate time for another look.
    This work has since been renamed to "kernel page-table isolation" or KPTI, but the objective remains the same: split the page tables, which are currently shared between user and kernel space, into two sets of tables, one for each side. This is a fundamental change to how the kernel's memory management works and is the sort of thing that one would ordinarily expect to see debated for years, especially given its associated performance impact. KPTI remains on the fast track, though. A set of preparatory patches was merged into the mainline after the 4.15-rc4 release — when only important fixes would ordinarily be allowed — and the rest seems destined for the 4.16 merge window. Many of the core kernel developers have clearly put a lot of time into this work, and Linus Torvalds is expecting it to be backported to the long-term stable kernels.

    KPTI, in other words, has all the markings of a security patch being readied under pressure from a deadline. Just in case there are any smug ARM-based readers out there, it's worth noting that there is an equivalent patch set for arm64 in the works.

  • Containers without Docker at Red Hat

    The Docker (now Moby) project has done a lot to popularize containers in recent years. Along the way, though, it has generated concerns about its concentration of functionality into a single, monolithic system under the control of a single daemon running with root privileges: dockerd. Those concerns were reflected in a talk by Dan Walsh, head of the container team at Red Hat, at KubeCon + CloudNativeCon. Walsh spoke about the work the container team is doing to replace Docker with a set of smaller, interoperable components. His rallying cry is "no big fat daemons" as he finds them to be contrary to the venerated Unix philosophy.

  • Demystifying container runtimes

    As we briefly mentioned in our overview article about KubeCon + CloudNativeCon, there are multiple container "runtimes", which are programs that can create and execute containers that are typically fetched from online images. That space is slowly reaching maturity both in terms of standards and implementation: Docker's containerd 1.0 was released during KubeCon, CRI-O 1.0 was released a few months ago, and rkt is also still in the game. With all of those runtimes, it may be a confusing time for those looking at deploying their own container-based system or Kubernetes cluster from scratch. This article will try to explain what container runtimes are, what they do, how they compare with each other, and how to choose the right one. It also provides a primer on container specifications and standards.

  • HarfBuzz brings professional typography to the desktop

    By their nature, low-level libraries go mostly unnoticed by users and even some programmers. Usually, they are only noticed when something goes wrong. However, HarfBuzz deserves to be an exception. Not only does the adoption of HarfBuzz mean that free software's ability to convert Unicode characters to a font's specific glyphs is as advanced as any proprietary equivalent, but its increasing use means that professional typography can now be done from the Linux desktop as easily as at a print shop.

    "HarfBuzz" is a transliteration of the Persian for "open type." Partly, the name reflects that it is designed for use with OpenType, the dominant format for font files. Equally, though, it reflects the fact that the library's beginnings lie in the wish of Behdad Esfahbod, HarfBuzz's lead developer, to render Persian texts correctly on a computer.

    "I grew up in a print shop," Esfahbod explained during a telephone interview. "My father was a printer, and his father was a printer. When I was nine, they got a PC, so my brother and I started learning programming on it." In university, Esfahbod tried to add support for Unicode, the industry standard for encoding text, to Microsoft Explorer 5. "We wanted to support Persian on the web," he said. "But the rendering was so bad, and we couldn't fix that, so we started hacking on Mozilla, which back then was Netscape."

    Esfahbod's early interest in rendering Persian was the start of a fifteen-year effort to bring professional typography to every Unicode-supported script (writing system). It was an effort that led through working on the GNOME desktop for Red Hat to working on Firefox development at Mozilla and Chrome development at Google, with Esfahbod always moving on amiably to wherever he could devote the most time to perfecting HarfBuzz. The first general release was reached in 2015, and Esfahbod continues to work on related font technologies to this day.

More in Tux Machines

Node.js 10.9 and npm milestone

  • Open Source Node.js Hits v10, with Better Security, Performance, More
    Speaking of which, the brand-new Node.js 10.0 is expected to soon support npm version 6 (currently Node.js ships with npm 5.7.x). The company npm Inc., which maintains the npm software package management application, today announced that major update, called npm@6. The npm company said its JavaScript software installer tool includes new security features for developers working with open source code.
  • Announcing npm@6
    In coordination with today’s announcement of Node.js v10, we’re excited to announce npm@6. This major update to npm includes powerful new security features for every developer who works with open source code. Read on to understand why this matters.

Openwashing: Sony, Scality and Ericsson

Voyage/Open Autonomous Safety (OAS) Now on GitHub

  • Voyage open-sources autonomous driving safety practices
    Dubbed Open Autonomous Safety, the initiative aims to help autonomous driving startups implement better safety-testing practices. Companies looking to access the documents, safety procedures and test code can do so via a GitHub repository.
  • Open-Sourcing Our Approach to Autonomous Safety
    Without a driver to help identify and mitigate failures, autonomous vehicle systems need incredibly robust safety requirements and an equally comprehensive and well-defined process for analyzing risks and assessing capabilities. Voyage models its safety approach after the ISO 26262 standard for automotive safety, taking the best practices from the automotive industry and applying them to autonomous technology. The automotive industry continues to reach for new levels of safety in manufacturing vehicles, and we are inspired by that approach.
  • Startup Voyage Wants to Open Source Self-Driving Car Safety
    Under what the company calls its Open Autonomous Safety initiative, Voyage is publishing information on its safety procedures, materials, and test code in a series of releases. The goal is to create an open-source library of safety procedures that multiple companies can use as a standard, a Voyage blog post said.
  • This startup’s CEO wants to open-source self-driving car safety testing
    The initial release, which Voyage calls Open Autonomous Safety (OAS), will take the form of a GitHub repository containing documents and code. The functional safety requirements are Voyage's interpretation of the ISO 26262 standard for automotive safety, updated for autonomous vehicles. "This is our internal driving test for any particular software build," says Cameron. "It lets us evaluate our designs and look for the different ways they can fail in the real world."

Programming: Qt 5.9.5 and Jakarta EE