Programming

TL;DR: The big tech AI company LLMs have gobbled up all of our data, but the damage they have done to open source and free culture communities are particularly insidious. By taking advantage of those who share freely, they destroy the bargain that made free software spread like wildfire.

Following publication of our original article, GitHub reversed its decision. The Microsoft-owned developer site has taken to X to admit it might have made a mistake by unilaterally announcing plans to charge people for using their own hardware to host runners.

“We’ve read your posts and heard your feedback,” GitHub said. “We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.”

The company said that it still intends to do something to help offset the “real costs” in running GitHub Actions via self-hosted runners, but “we missed the mark with this change by not including more of you in our planning.”

I'm looking for free resources to learn backend development. I prefer video-based content with a complete, step-by-step learning path. I want lots of hands-on practice, exercises, and real projects to work on.

Here, my summary of key features and decisions of Guix:

1. Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or Conan. In difference to the pip and cargo package managers, it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
2. Guix allows to define a fully reproducible system. This works by using a declarative language for immutable version-controlled package descriptions, and by deriving any software from package definitions and a fixed version (commit hash) of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code and build recipes - and all inputs to the system are open source and can be reviewed.
3. Important for programming, this can also define isolated build and development environments, like Python's venv, but also Docker containers. This means that Guix can be used to develop, build, package, and deploy software, very much like Snap packages. And that's independent from the distribution you work in, very much like pip or cargo are independent from the system you work in. (And yes, it supports Rust!).
4. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free forks of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can't happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions as a complement to GNU Guix. Non-free packages for Guix do exist, in the same way as you can buy and run Steam Games software for Linux. Such non-free software just can't become part of the official Guix distribution, just like Amazon or Apple can't sell their non-free software via Debian or the Linux kernel project (or, for that matter, Apple has no obligation to market and distribute, say, Oracle products).
5. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson's "Trusting Trust" problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online -- certain companies don't seem to like it).
6. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
7. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software, but more importantly, whole user configuration, is written in Emacs Lisp.
8. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
9. Also worth noting is that the Guix project has superb online documentation. This is a practical advantage compared to Nix.

As example: you are on Debian stable and quickly want to try a recent version of the kakoune editor (as kakoune is in ongoing development): They are available under the Guix package manager. Just

guix install kakoune

and bang you have it!

How it works:

https://codeberg.org/guix/guix#headline-4

Manual:

https://guix.gnu.org/manual/en/html_node/Installation.html

Also informative for using Guix just as a package manager:

https://wiki.archlinux.org/title/Guix

Sebastian Aaltonen’s super in-depth analysis of all current graphics APIs, GPU history, and a proposal for a much simpler API that better fits today’s GPUs

Hello everyone,

I've just published the second post in my Linux Inside Out series.

In the first post we demystified the Linux kernel a bit: where it lives, how to boot it in a VM, and we even wrote a tiny init program.

In this second post we go one layer deeper and look at how programs actually talk to the kernel. We'll do a few small experiments to see:

• how our init program (that we wrote in the first post) communicates with the kernel via system calls
• how something like echo "hello" ends up printing text on your screen
• how to trace system calls to understand what a program is doing

I’m mainly targeting developers and self-hosters who use Linux daily and are curious about the internals of a Linux-based operating system.

This is part 2 of a longer series, going layer by layer through a Linux system while trying to keep things practical and approachable.

Link (part 2): https://serversfor.dev/linux-inside-out/system-calls-how-programs-talk-to-the-linux-kernel/

Link (part 1): https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/

As always, any feedback is appreciated.

On January 1, 2026, GitHub will reduce the price of GitHub-hosted runners by up to 39% depending on the machine type used. The free usage minute quotas will remain the same.

On March 1, 2026, GitHub will introduce a new $0.002 per minute GitHub Actions cloud platform charge that will apply to self-hosted runner usage. Any usage subject to this charge will count toward the minutes included in your plan, as explained in our GitHub Actions billing documentation.

Runner usage in public repositories will remain free. There will be no changes in price structure for GitHub Enterprise Server customers.

We are increasing our investment into our self-hosted experience to ensure that we can provide autoscaling for scenarios beyond just Linux containers.

Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost.

I have always had a great deal of respect for C, and I would like to start writing in it. However, while I am skilled in other languages, I basically don't know any C off the top of my head.

I find that I learn better and faster by attempting projects, rather than working through a book ir taking a class. For example, to learn Perl, I am working on a basic disk image writer that's coming along nicely.

So, what do you think might be a good idea for my first C project?

EDIT: Zig is also something I'm interested in learning. Same question, different language.

Issue and PR threads are invaluable documentation for a project, it's difficult to migrate to another code host when years of knowledge are locked into your old hosting service. So I built a couple of scripts to archive issues, pull requests, comments, and source code from github repositories, and to turn them into static sites! With the accelerating exodus away from github, I've heard from a lot of people that there aren't any good tools for archiving that knowledge in a human-readable format, so I thought this would be a useful tool to make. The initial release is ready, and just in time for github to start charging for self-hosted runners!

If you try it out, let me know what you think. There's definitely areas that can be improved on :)

This is a lightweight code editor which implements a concise yet powerful subset of vim commands, and adds support for multiple selections, by adding selection-based editing commands from plan 9's sam editor. The latter is nice for refactoring larger codebases. For example, one can define a selection for a variable name, add all its occurences, then visit each match to make sure a change does not shadow another name, and then change it all at once. That's great because I am a fan of good names, and since programs evolve and change, names should be changed, too!

What makes vis nice is that - in difference to vim descendants like kakoune - it remains still largely vim-compatible, so that one can easily continue to use vim (or even learn vim better, due to vis' magnificient concise man page ;-)).

Of course, kakoune is also powerful, light-weight, vim-like, and really nice, thanks to its visual support for multiple selections. But kakoune is (because of its "selection-command" 'editing language' syntax, different from vim's "command-selection" syntax) a big step away from vim - and my own experience is that it is hard to learn several of these "large" editors well, because they contain so many details one has to memorize, and which the human brain is gleefully happy to throw out after not using them for a few weeks. And for me, vim is already a (or more precisely the) secondary editor - I use it for quick tasks, git and jujutsu commit messages, embedded system and admin stuff, but not for writing large programs. And vim is an excellent match for these use cases, since it is basically installed everywhere.

Recommend me any good finance related projects that may try to solve an actual problem being faced in the industry now.

What os? What ide? What plug-ins?

Hi all, much of what I have read recommends Android Studio to create Android apps, but I'm a bit wary since it's developed by Google. Are there any other good alternatives that are ideally open-source?

I am currently running Fedora 43 KDE, and I use VSCodium as my main code editor, mostly Python at the moment. Are there any plugins I could use to enable Kotlin support/specific Android dev stuff in VSCodium?

There are some times that I make something and the terminal isn't enough. I want to make it user-friendly and add buttons and dropdowns and stuff. I mainly write C, so I want a well-known and good GUI library for C. I have tried learning Qt but the documentation was awful and all the examples were for C++ or Python. I also am aware about libraries like imgui but it's more for debugging UIs I think and not for normal applications that end users use.

I also would like the library to be platform-agnostic, or at least just work with Linux because that's what I am using.

If you also code in C, what do you use to make GUIs? What do you suggest me to use?

Thanks in advance.

Also, if anyone suggests Electron or anything involving a browser, I will find them and remove one electron from each atom of theirs, turning them into smoke.