Hírolvasó

The fourth 5.13 kernel prepatch is out for testing. "So after two small rc releases, the other shoe finally dropped, and rc4 is fairly sizable."

AlmaLinux 8.4, a clone of RHEL filling the role that CentOS used to play, has been released. Changes include full support for secure boot, a developer repository with packages not found in RHEL, and more; see the release notes for details.

Modern computing systems can feature multiple types of memory that differ in their performance characteristics. The most common example is NUMA architectures, where memory attached to the local node is faster to access than memory on other nodes. Recently, persistent memory has started appearing in deployed systems as well; this type of memory is byte-addressable like DRAM, but it is available in larger sizes and is slower to access, especially for writes. This new memory type makes memory allocation even more complicated for the kernel, driving the need for a method to better manage multiple types of memory in one system.

The 5.12.8, 5.10.41, and 5.4.123 stable kernels have been released. These contain only a small handful of changes, including fixes to the BPF verifier to address a privilege escalation vulnerability. Users of those series should upgrade.

Security updates have been issued by Debian (nginx), Fedora (chromium, curl, kernel, php-symfony3, php-symfony4, python-lxml, python-pip, and runc), Mageia (ceph and wireshark), openSUSE (mpv), Oracle (bind, idm:DL1, redis:6, slapi-nis, squid:4, and xorg-x11-server), SUSE (curl, nginx, postgresql10, postgresql12, postgresql13, slurm, slurm_18_08, and slurm_20_11), and Ubuntu (nginx).

I've moved from the San Francisco Bay Area to Sydney, Australia, where I will continue the best job so far of my career: Performance engineering at Netflix. I'm grateful for the support of Netflix engineering management, Netflix HRBPs, and others for helping to make this happen. While my move is among the first from the Linux cloud teams, Netflix has had staff in Australia for years (for content, marketing, and the FreeBSD OCA). It's been a privilege and an adventure to work in Silicon Valley with so many amazing people. But I'm now excited about my new adventure: Doing an advanced tech role remotely from Australia. I know others who have also left the Bay Area or are planning to. Back in 2015 we'd have BPF (iovisor) meetups in Santa Clara and most contributors would be there in person, with some having travelled. Now we're more scattered, either to other US cities or worldwide. As another indicator of tech moving elsewhere, last year brought the [headline]: "Bay Area's share of VC deals predicted to fall below 20% for first time in 2021." Day to day things won't be much different. I'm still online, doing the same work, answering the same emails. And many of us expect (when travel is possible) to make regular visits to the US for company-wide meetings and events. I think some coworkers will still see me occasionally in the US office and won't even realize I've moved. Why Australia? When I told people I was moving to Australia they'd guess why: "Is it because of X? Or Y? ... or Z?" Well, the answer is yes, all of the above. I began discussing Australian tech roles with different companies in Jan 2020. The pandemic then added another reason to move. Both the US and Australia have their pros and cons, and I have many favorite places and people in both (sorry I didn't come say goodbye: We'll meet again). But in the end I'm a proud Australian and I do prefer Australia for various reasons, many of which Deirdré wrote about in [Why move to Australia?]. Additional reasons for me included visa uncertainty (and the abuse it leads to), voting rights, and complex international taxation. (Disclaimer: Netflix is an exception, as they have been great with visa workers including myself.) Another reason is that the tech market became stronger in Australia. I moved to the US in 2006 as there were many more opportunities there, especially in kernel engineering and performance. Now, in 2021, Australia has a thriving tech market. Sydney has AWS and Google offices and even a small Netflix office, just to name a few. There is also a wider variety of roles available. If you want to do kernel engineering work you no longer need to move to California to work for Sun Microsystems in the MPK17 building. You can work on Linux anywhere. Linux is Already Remote Linux has been described as the world's most successful open source project, and it's all engineers working remotely. There's no Linux kernel headquarters where all the engineers sit in an open office layout, typing furiously then dashing for the break room coffee during kernel builds, and where maintainers can yell across the room at someone for their bad patch (when it's Linus yelling, everyone takes off their headphones to listen). That doesn't happen. Engineers are remote, and may only meet once or twice a year at Linux kernel conferences. And it's worked very well for years. Another example of remote work I've already done is book writing. Last year I published [Systems Performance 2nd Edition], which I wrote from my home office with help from remote contributors. The entire project was run via emails, a Google drive, and Google docs, and was delivered to the publisher on time. Making it Work While tech workers are well suited for remote work (savvy with communications technologies) there are benefits with office work, and I don't think remote work is for everyone. (One benefit I'll miss is playing in the Netflix cricket team.) In the future I'd expect hybrid teams, where the remote workers visit the office on a regular cadence (e.g., once a quarter) for meetings. This is a model that's already been successfully used by some teams, including at Netflix. As for work hours, I set my own schedule where I start around 7am, giving between 3 and 5 hours overlap with California time (depending on daylight savings). About once a month I'll have an early morning meeting (e.g., 4am). Back when I did [SRE oncall] for Netflix I'd have more wakeups at unpredictable times, so this feels easier to manage. (I also had prior jobs in the Bay Area where I'd be in the office most days past midnight, so compared to that this is like a health retreat!) As more people move to other timezones I think this will improve further. Some meetings may move to an asynchronous format, and others may be run twice for world coverage, at 9am and 4pm California time.

.@Brendangregg in his new office. pic.twitter.com/ylTGxEdrcC

— Deirdré Straughan (@DeirdreS) February 11, 2021 To work remote I think you have to really want it and be willing to put in extra effort, including doing the occasional early meeting. Personally, I use a stopwatch to help me stay productive: I pause it whenever I have an interruption, and measure how many hours of uninterrupted work I get done each day, log it, and then plot it on graphs to see the trends. Yes, I'm performance analyzing myself. It's been a slow process, but I've been figuring out how to become more productive each day. It's really satisfying to finish a full day's work and then realize I'm no longer in the Bay Area, but instead have a two minute walk to the beach. It's just one of many reasons to put in that extra effort. [Why move to Australia?]: http://www.beginningwithi.com/2020/12/01/why-move-to-australia/ [headline]: https://www.bizjournals.com/sanjose/news/2020/12/14/bay-area-vc-deal-share-predicted-to-fall-below-20.html [Systems Performance 2nd Edition]: /systems-performance-2nd-edition-book.html [SRE oncall]: /blog/2016-05-04/srecon2016-perf-checklists-for-sres.html

Over on the Python Software Foundation blog, the reports from day 1 of the Python Language Summit are available. At the time of this writing, a few from day 2 are ready as well. There are lots of interesting topics discussed at the summit, including a talk on making CPython faster from Python creator Guido van Rossum. "Seven months ago, Guido van Rossum left a brief retirement to work at Microsoft. He was given the freedom to pick a project and decided to work on making CPython faster. Microsoft will be funding a small team consisting of Guido van Rossum, Mark Shannon, Eric Snow, and possibly others. [...] The team is optimistic about doubling CPython's speed for 3.11. They plan to try an adaptive, specializing byte code interpreter, which is a bit like the existing inline cache and a bit like the shadow byte code covered in Dino Viehland's talk." Some of the ideas go back to Shannon's thoughts on speeding up the interpreter that we looked at back in December.

When kernel developers want to communicate something about the state of a running kernel, they tend to use printk(); that results in a log entry that is intended — with varying success — to be human-readable. As it happens, though, the consumers of that information are often not human; the kernel's log output is also read by automated monitoring systems that are looking for problems. The result is an impedance mismatch that often ends with the monitoring system missing important messages. The printk() format indexing patch set is the latest of many attempts to improve this situation.

Security updates have been issued by Debian (djvulibre), Fedora (slapi-nis and upx), Gentoo (ceph and nginx), openSUSE (python-httplib2 and rubygem-actionpack-5_1), Slackware (curl), SUSE (curl, libX11, and python-httplib2), and Ubuntu (isc-dhcp, lz4, and nginx).

Sven G is back with another tale of using a Raspberry Pi in his garage:

OpenBSD lets one control the GPIO pins on a Raspberry Pi. Controlling a garage door is simple: connect the GPIO output pin to one side of a relay's coil, connect the 5 volt output of the Pi to the other side of the relay's coil, and connect wires from your garage's wall console to the relay's common and "normally closed" ports. Running the program below opens or closes the door. Since the Pi will be connected to the garage wall console, you'll want to enable sshd. I've named my Pi "garage" and my program "og," so I can open the door remotely with

ssh garage /home/sven/bin/og

Read more…

The LWN.net Weekly Edition for May 27, 2021 is available.

Internet Relay Chat (IRC) is a longstanding protocol—or series of protocols—for creating online, text-based chat rooms. While many of the "channels" (as chat rooms are usually called) are highly useful to a wide variety of projects and organizations, including much of the free-software world, IRC seems to have a community that suffers from more than its fair share of disagreements, hostile forks, vitriol, and other types of divisiveness. It is perhaps no huge surprise, then, that the IRC world is currently undergoing another of its periodic upheavals. The largest IRC network, freenode, is embroiled in a messy dispute that has led to the mass resignation of many of its volunteer staff, the founding of a competitor network (run by the former staff), and its abandonment by multiple high-profile projects.

Stable kernels 5.12.7, 5.10.40, 5.4.122, 4.19.192, 4.14.234, 4.9.270, and 4.4.270 have been released. As usual, they contain important fixes and users should upgrade.

Security updates have been issued by Arch Linux (djvulibre, dotnet-runtime, dotnet-runtime-3.1, dotnet-sdk, dotnet-sdk-3.1, gupnp, hivex, lz4, matrix-synapse, prometheus, python-pydantic, runc, thunderbird, and websvn), Fedora (composer, moodle, and wordpress), Gentoo (bash, boost, busybox, containerd, curl, dnsmasq, ffmpeg, firejail, gnome-autoar, gptfdisk, icu, lcms, libX11, mariadb, mumble, mupdf, mutt, mysql, nettle, nextcloud-client, opensmtpd, openssh, openvpn, php, postgresql, prosody, rxvt-unicode, samba, screen, smarty, spamassassin, squid, stunnel, tar, tcpreplay, and telegram-desktop), openSUSE (Botan), Red Hat (kernel), Slackware (gnutls), SUSE (hivex, libu2f-host, and rubygem-actionpack-5_1), and Ubuntu (apport, exiv2, and libx11).

Version 3.0 of Magit, a Git interface that runs inside emacs, has been released. "The big change are the completely reworked menus used to select arguments and invoke suffix commands. Magit now uses the Transient package to implement these menus." See the release notes for more details.

On March 24, version 1.6.0 of the Julia programming language was released. This is the first feature release since 1.0 came out in 2018. The new release significantly reduces the "time to first plot", which is a common source of dissatisfaction for newcomers to the language, by parallelizing pre-compilation, downloading packages more efficiently, and reducing the frequency of just-in-time re-compilations at run time.

Security updates have been issued by Fedora (python-eventlet), openSUSE (grub2 and mpv), and Red Hat (kpatch-patch and rh-ruby25-ruby).

Version 1.1 of the Inkscape vector image editor has been released. "Among the highlights in Inkscape 1.1 are a Welcome dialog, a Command Palette, a revamped Dialog Docking System, and searchable preference options, along with new formats for exporting your work."