This Week in Programming: eBPF Coming to a Windows Near You

The New Stack has been keeping a close eye on eBPF for a few years now, calling the technology one of the top trends of 2020. If you haven’t heard of eBPF before, chances are you are about to hear a lot more about it, as Microsoft said this week that it was bringing it to Windows.

The extended Berkeley Packet Filter (eBPF) originally served as an HTTP packet filter for the Berkeley Software Distribution (BSD) before it was extended for use in software-defined networking, where it provides a way for the Linux kernel to execute customized operations on the user’s behalf. While originally known for providing in-kernel monitoring, eBPF has gone on to give Linux users a way to run sandboxed programs within the kernel space, without changing kernel source code or loading modules.

Linux and soon Windows have eBPF (God’s own nectar), when will macOS get on the action?https://t.co/WIk5wcy2s8

— Miguel de Icaza 💉💉⏳ (@migueldeicaza) May 10, 2021

“Although support for eBPF was first implemented in the Linux kernel, there has been increasing interest in allowing eBPF to be used on other operating systems, and also to extend user-mode services and daemons in addition to just the kernel,” Microsoft noted in its announcement.

That expansion will begin with a new open source project that aims to bring eBPF to Windows 10 and Windows Server 2016. Later the expansion will glue together several existing open source eBPF projects, such as the IOVisor uBPF project and the PREVAIL verifier, to make them work on Windows. With ebpf-for-windows, developers can use existing eBPF toolchains to generate eBPF bytecode from source code in various languages, which “can then be used by any application or manually through the Windows netsh command-line tool, both of which use a shared library that exposes Libbpf APIs, though this work is still in progress.”

As for how the news is being received, “universal optimism” might not be an overly broad phrase to use in this case. Developers across Twitter have hailed the announcement, calling it a “level the playing field move.” And while Windows developers rejoice, Brendan Gregg, an expert, author, and common speaker on the topic of eBPF, says that the move goes beyond benefitting Windows developers themselves.

… this in turn will make it easy for even more kernels to adopt BPF. (And they will need to to be competitive, as production sites are already running dozens of BPF programs by default.) BSD next? (come full circle). 2/2

— Brendan Gregg (@brendangregg) May 12, 2021

From here, as Gregg points out, it’s anybody’s guess as to where eBPF is headed next, but chances are you’ll be hearing plenty more about it in the near future.

This Week in Programming

• Rust Releases Its Plan for 2021 Edition: Not a week goes by lately without a slew of Rust-related news, and this week is no exception. This time around, we start with the plan for the Rust 2021 Edition. Rust’s “editions” are a way to add features that are not backwards compatible. For example, the async keyword was added after 2018 and, even if you update Rust to a more recent version, it won’t be recognized as a keyword unless you update also to a 2018 or later edition. As for what changes will come with the Rust 2021 edition, the blog post lists a number of them: additions to the prelude, a default Cargo feature resolver, an intolerator for arrays, disjoint capture in closures, panic macro consistency, reserving syntax and the promotion of two particular warnings to hard errors. Currently, the Rust 2021 edition is slated for September to make it into Rust 1.56.0, which will be in beta until October 21. The blog post notes, however, that “Rust is a project run by volunteers” and that people are prioritized over feature releases, meaning everything is tentative. Further details will be released in July, with more details about processes and rejected proposals also slated for the Inside Rust blog in the near future.

In the class today I was telling a joke about asynchronous programming but no one stopped to listen.

— Venkat Subramaniam (@venkat_s) May 10, 2021

• AWS Launches A New Rust SDK: Next up in the Rust realm, Amazon Web Services has released to alpha a new AWS SDK for Rust that the company says will give devs familiar with Rust the language constructs they are used to, while also providing an SDK that behaves similarly to other AWS SDKs in other languages. The new Rust AWS SDK will currently work with seven AWS services, with more on the way: Amazon DynamoDB, Amazon API Gateway, Amazon Kinesis, AWS Key Management Service, Amazon Polly, AWS Secrets Manager and Amazon Quantum Ledger Database. If you’re curious about where the SDK goes from here, head on over to the roadmap, which outlines expected new features such as new functionality for AWS services and support for additional credential providers, and check out the getting started guide.
• Rust for Windows v0.9 Arrives: Last up on the Rust ticket this week, Microsoft has announced Rust for Windows v0.9, which includes full consumption support, meaning you can now call any Windows APIs (past, present, and future) using the Rust language projection. Last month, we looked at how Microsoft was getting Rusty with Rust for Windows, and now the company says it has “made great progress” since last year’s Rust/WinRT public preview announcement. The latest release includes added support for Win32 and COM APIs, unifying the Windows APIs available for consumption via the windows crate, alongside the addition of several examples to the Rust for Windows repo. And the publication of the windows crate on crates.io, which is now dual-licensed under MIT or Apache, uses generated bindings rather than hand-written bindings internally, and builds on Linux. For the full list of updates, as always, check out the changelog, and head over to the latest documentation to get started.

Docker is basically iframes for computers.

— Paul Campbell (@paulca) May 13, 2021

• GitHub Enables Security Keys for SSH Git Operations: Security keys — think “dongles” for the 21st century — are now supported for SSH Git operations on GitHub, which gives users a convenient way to perform two-factor authentication without requiring a smartphone. Security keys connect via USB, NFC, or Bluetooth and are more secure than the smartphone SMS alternative, in that the data on the key is protected from external access and modification and there’s no way to redirect, as there is with SMS. “As long as you retain access to the security key, you can be confident that it can’t be used by anyone else for any other purpose,” GitHub explains. With the new feature, you generate an SSH key and then add the keys to your account just like any other SSH key, and even if the private key file on your machine is stolen, it is useless without the physical security key. “If you’re the only person with physical access to your security key, it’s safe to leave plugged in at all times,” they further explain. For more details on how this will specifically affect your workflow, head on over to the blog post, but know that this is all part of a greater plan to move past passwords, with GitHub saying that passwords will no longer be supported for Git operations in the near future, something it already did for its API.

The CDC now says vaccinated Americans no longer have to use 2 Factor Authentication on GitHub.

— Dan Lorenc (@lorenc_dan) May 14, 2021

• Video Goes Live Across GitHub: One more tidbit in the realm of GitHub, the site has made video uploads available across GitHub. The feature was introduced in beta last year and is now generally available, allowing users to upload .mp4 and .mov files in issues, pull requests, discussions, and more. They can show bugs, provide context on pull requests, discuss how a feature may take shape, or do whatever else is easier to do in video than written form. Beyond being available across all of GitHub, the features are also available on both the Android and iOS GitHub apps, so get recording.
• VS Code Python Adds Pylance, Debug Auto-Reload: Last up, this month’s Python in Visual Studio Code release is out and it has a couple of big new features. First, Pylance is now the default language server and is bundled with the core Python extension as an optional extension starting with this release, though you can opt-out if you so choose. Pylance, they write, “provides what we believe is the most performant and user-friendly Python editing experience for Visual Studio Code ever.” But if you disagree, you can uninstall the Pylance extension and use the language server of your choice. Beyond Pylance, the Python extension now features live reload for Python scripts, which means “your changes will be applied after the debugger has already started executing and has hit a breakpoint, without the need to restart the debugger.”

anarchism functional programming
🤝
state is inherently
dangerous and should
be eliminated

— 💤🌵🤖the shorterant left (@boring_cactus) May 13, 2021