1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind #ifdef COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

The release of NetBSD 11.0, the 19th major version of the operating system, has been announced. There are many changes and enhancements since the 10.1 release, including a new port to RISC-V, better support for Linux system calls in compat_linux(), as well as improvements to the NPF firewall.

As you are probably aware, the number of security issues found or suspected everywhere has massively increased with the advent of AI tools. As a consequence, we can't publish a release without open issues. Instead of delaying the release further to fix them (new ones are being reported all the time), we've instead chosen to be transparent about this.

See the full release notes for links to the binary distributions and links to the full change logs.

Project LANA interim report on IUT theory, “As of July 2026, the LANA Project has not made a final judgment on the correctness or incorrectness of IUT theory. However, through the multiple bootcamps held since February 2025 and lively discussions during numerous online meetings, it has progressed to the point of transforming the core of the controversy, which for many years had been discussed in vague terms, into the form of diagrams, types, code, black boxes, and explicit questions”, and later: “we are reserving our final judgment on whether a proof exists for Corollary 3.12 in Mochizuki’s third paper on IUT theory.”

Silk, a cooperative fiber scheduler for Linux with per-CPU scheduler threads, io_uring integration, and topology-aware work-stealing. By ClickHouse.

The git history command deserves more attention, useful additions in Git 2.55.

Justif is a JavaScript library that applies TeX-style paragraph layout to existing HTML.

Fast Synthesis of Basic Oscillators, by Artemis Everfree.

E73, a rendering of the ECMA-42 standard bitmap printer font from 1973.

Why did early ASCII have ← and ↑ but not ↓ or →?

BSD Make extravaganza computes the Mandelbrot set in bmake.

Bad Apple, animated in the browser, without JS and CSS.

Frankfurt Schoodle, guess the author of a quote.

Killing Processes

One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too. In recent Debian releases the default configuration of systemd-logind (the login manager for systemd) is to allow processes to keep running, the configuration file /etc/systemd/logind.conf has an option KillUserProcesses that can be enabled to have user processes killed. If you do that then there are options to only kill processes for certain users and to exclude some users (default to excluding root). If using that option you can apparently use a systemd unit to start screen which prevents it being killed on logout.

This is a very handy feature for some particular user cases. One situation was that I was supporting some people who weren’t very good at computers on a system running KDE and some KDE processes would linger. So the option of logout and login again to deal with an issue of akonadi or some other KDE service misbehaving didn’t work. On that system I enabled the option to kill user processes which reduced the number of problems they had while not requiring rebooting.

It is widely believed that the “linger” feature is required to allow screen/tmux/nohup to work, in Debian (and probably most distributions) that is not the case. It might be that some combinations of configuration requires “linger” to allow screen/tmux to work but I am not interested in trying to discover them. Of all the people I have directly supported for Linux desktop use (which numbers in the hundreds) none of them have had the ability to use screen/tmux and also the cluelessnes that makes me want to automatically kill their processes when the logout.

Controlling Linger

You can enable and disable “linger” for your own account with the following commands if polkit is installed and in a typical configuration:

loginctl enable-linger
loginctl disable-linger

If running as root you can enable and disable it for another user with the following commands:

loginctl enable-linger $ACCOUNT
loginctl disable-linger $ACCOUNT

There doesn’t seem to be any documented way of discovering if an account has linger enabled or for listing accounts that have it, it seems that “ls /var/lib/systemd/linger” is the only option.

Linger on Debian

On a Debian system with close to default settings the processes won’t be killed on logout and the only difference “linger” makes is to start programs in the user’s context BEFORE they login. A friend was recently testing out a bunch of LLM programs on one of my servers and the account he used for that ended up with “linger” enabled, presumably one of the install scripts he ran was written on the assumption that enabling linger was necessary for nohup to work and it did so automatically without being asked.

One benefit I’ve found from this behaviour is on my laptop. I’m currently testing out new SE Linux policy on my laptop and rebooting it a lot. When I enabled linger on my account it caused the laptop to connect to wifi on boot without needing to login which is convenient. I can then ssh to it even when the X11/Wayland login configuration is broken.

I will leave it enabled after finishing these tests. Having background processes like Pipewire and Bluetooth start before I login will presumably make things slightly faster when I do login.

We launched GitHub Sponsors in 2019 with a simple belief: the people who build and maintain open source software deserve to be supported for their work. Since then, tens of thousands of sponsors—individuals and organizations alike—have turned that belief into action.

We’re proud to announce that more than $100 million has been invested in open source maintainers and projects through GitHub Sponsors. This milestone belongs to the developers, organizations, and maintainers who have invested in a more sustainable open source ecosystem, and it signals that the way we value open source is changing.

How we got here

GitHub Sponsors started with individuals. We wanted to make it possible for any developer to directly support the maintainers they depend on. In 2023, we made organization-funded sponsorships generally available and saw organizations like Shopify step up to fund their dependencies at scale. The program expanded to 103 regions, partnered with Patreon, and introduced tools like bulk sponsorships and invoice payments to make it easy to participate.

The result: a global funding network that supports over 70,000 maintainers and organizations, and includes more than 280,000 sponsors spanning individual developers to Fortune 500 companies.

The pace is accelerating, too. The first $10 million took nearly two years. The most recent $10 million took just five months.

The people behind the number

While $100 million is a meaningful number, the real measure of impact is what it’s made possible for real people.

GitHub Sponsors changed how I think about open source. It gave me a direct, sustainable way to fund the time it takes to build and maintain projects, instead of treating it like side work. That has let me invest more consistently in the projects and build with a much longer-term view. Thanks to GitHub Sponsors, I am able to give back to our community, build a business, and actually make a difference in OSS.

Kelvin Tegelaar, Maintainer, Lime Networks

Shopify invests in open source because our platform, our merchants, and our engineering culture all depend on a healthy open source ecosystem. GitHub Sponsors gives us a direct way to support the maintainers and projects that move the industry forward, from foundational technologies to smaller tools that make developers’ daily work better. For us, sponsorship is both practical and values-driven: it helps sustain the software we rely on while strengthening our connection to the people building it.

Shopify

As strong advocates of open source software, Mercedes-Benz recognizes the incredible contributions made by developers and maintainers worldwide. Through GitHub Sponsors, we aim to support and empower these dedicated individuals and projects that drive innovation, collaboration, and the advancement of open source. By providing financial assistance to these projects, we hope to enable them to dedicate more time and resources to their impactful work, thereby making open source more sustainable and contributing to the overall health and longevity of the projects. We extend our deep gratitude to all the participants and celebrate their dedication. Together, we can continue to foster a vibrant and sustainable open source ecosystem that benefits our teams, developers and users alike.

Dr. Wolfgang Gehring, OSPO Lead & FOSS Ambassador, Mercedes-Benz Tech Innovation GmbH

GitHub Sponsors has meant many things for me and my open source. First, it showed me people’s appreciation and motivated me. Then it showed me I could and should figure out how to do more open source. And then, for the past years, it has also allowed me to sub-sponsor many of the open source tools that power mine, to share that appreciation and support.

Sebastián Ramírez, tiangolo

My projects wouldn’t be what they are today without GitHub Sponsors. Sponsorships allowed me to quit my job and work on them full time. GitHub Sponsors opened my eyes to the opportunities available for passionate people working on projects that people care about.

Caleb Porzio, Livewire & Alpine.js

Open source careers shouldn’t depend on geography or circumstance. They should depend on the value of the work. Increasingly, the community is making that possible.

What we’ve learned

Building GitHub Sponsors over the past seven years has taught us a few things:

Organizations move the needle. In 2022, nearly 40% of sponsorship funding came from organizations, with each organization-funded sponsorship worth an average of nearly 15x more than the average individual sponsorship. As more companies recognize their dependence on open source, this share continues to grow.

Reducing friction matters. Every time we’ve made it easier to sponsor (e.g. adding invoice payments, expanding regions, enabling bulk sponsorships) we’ve seen a corresponding increase in funding. The demand to support open source is there. We aim to make that easy to do.

What’s next

This milestone proves that when the community shows up for open source, the impact is real. But the work isn’t done. The open source funding gap is still enormous, many critical projects remain underfunded, and maintainer burnout continues to be one of the biggest risks to the software supply chain. This $100 million is proof that the community can change how open source is sustained, one sponsorship at a time.

The best way to keep this momentum going? Start sponsoring the projects you depend on or encourage your organization to do the same.

How you can get involved

Behind the scenes, maintainers are working daily to make open source better for all of us. If you or your organization depend on open source — and you almost certainly do — there’s no better time to invest in the people who make it possible.

Visit the Sponsors Explore page to discover which maintainers you depend on and start supporting them today. If you’re a maintainer and haven’t set up your Sponsors profile yet, visit github.com/sponsors to get started.

Thank you to every sponsor and every maintainer who has been part of this $100 million journey. This is what happens when a community decides that open source is worth investing in. We can’t wait to see where it goes from here.

The post $100 million for open source: A milestone built by the community appeared first on The GitHub Blog.

With Nintendo’s 3DS experiencing a bit of a renaissance lately, prices for functioning systems have shot through the roof. Getting a busted one with a broken screen is a lot cheaper, but then you run into the eye-watering price difference between a replacement top screen for the regular version and the larger XL variant. The latter costs about the same as a whole new used 3DS, while the former goes for peanuts. Here the solution is obvious, with [Skawo] demonstrating how they hacked the cheaper, smaller top screen into a New 3DS XL.

The price difference on AliExpress as shown in the video is on the order of $120, with the smaller screen going for less than $10. Since they both use the same connector pin-out and display technology, you can plug either display into the New 3DS XL mainboard.

Where you’ll run into issues, other than the replacement display being obviously not XL, is the physically shorter flat flex cable for the controls that forces the display to be installed in an offset manner. You need jailbroken firmware like Luma3DS here to adjust for the screen offset. Filling in the missing screen real-estate is the other issue you have to patch over somehow, which was done here in barbaric fashion with some cardboard.

Beyond that it does work, and as a fix to at least get a broken New 3DS XL back into the game it’s worth considering. Do note that there’s a difference between regular 3DS and New 3DS (second generation) screens with neither being compatible, so be careful before you try such a fix.