Linux Containers The Hard Way

If you want to make containers under Linux, plenty of high-level options exist. [Lucavallin] wanted to learn more about how containers really work, so he decided to tackle the problem using the low-level kernel functions, and he shared the code with us on GitHub.

Containers are more isolated than processes but not quite full virtual machines. While a virtual machine creates a fake computer, a container is more like a fake operating system. Applications can run with their own idea of libraries, devices, and other resources, but it doesn’t try to abstract the underlying hardware.

Continue reading “Linux Containers The Hard Way”

Debian Officially Adds RISC-V Support

As time goes on, more and more computer manufacturers are moving towards the ARM architecture and away from the bloated and outdated x86 instruction set. Apple is the most prominent producer to take this step, but plenty others are using ARM for its flexibility and efficiency. The only problem with ARM is that it’s licensed, so if you want to go even further down the open-source path the RISC-V instruction set is the next logical step. Now at least one mainline Linux distribution will officially support this architecture.

While Debian did have some support for RISC-V before this as a Debian port, which was not officially part of Debian. However, the official support will begin with the release of Debian 13, which is currently in the testing phase and hasn’t seen a stable release yet. To that end, the current state of this official version is extremely limited, being described as “almost empty” but with planned support for an initial 90 packages in the coming days. Most users working on a RISC-V platform will most likely to continue to use their Debian ports version.

It might be a little while before the RISC-V version is as full-featured as the ARM or x86 versions of this Linux distribution, but we are happy to see it move in this direction at all. And don’t think that RISC-V is limited to embedded systems or otherwise limited computing platforms, either. We’ve seen full Linux desktops with RISC-V processors since at least 2019.

Ask Hackaday: What’s Linux Anyway?

Any time we mention Linux, it is a fair bet we will get a few comments from people unhappy that we didn’t refer to it as GNU/Linux or with some other appellation. To be fair, they aren’t wrong. Linux is a kernel. Much of what we think of as a Linux desktop OS is really from other sources, including, but not limited to, GNU. We thought about this after reading a report from [The Register] that Linux has nearly half of the desktop OS Linux market. Wait, what?

If you are like us, you probably think that’s a typo. It isn’t. But the more you think about it, the less sense it makes. You know that half of the world’s desktops don’t run Linux. But maybe they mean Unix? Nope. So how can Linux have almost half of the Linux market? That’s like saying nearly half of Hackaday readers read Hackaday, right?

Continue reading “Ask Hackaday: What’s Linux Anyway?”

SSH Can Handle Spaces In Command-line Arguments Strangely

One of the things ssh can do is execute a command on a remote server. Most of us expect it to work transparently when doing so, simply passing the command and its arguments on without any surprises in the process. But after 23 years of using OpenSSH on a nearly daily basis, [Martin Kjellstrand] got surprised.

It turns out that the usual rules around how things are parsed can have some troublesome edge cases when spaces are involved. [Martin] kicks off an example in the following way:

One would reasonably expect the commands figlet foobar bar\ baz and ssh localhost figlet foobar bar\ baz to be functionally equivalent, right? The former ultimately runs the command “figlet” with arguments “foobar” and “bar baz” on the local machine. The second does the same, except with ssh being involved in the middle. As mentioned, one would expect both commands to be functionally identical, but that’s not what happens. What happens is that ssh turns bar\ baz into two distinctly separate command-line arguments in the process of sending it for remote execution: “bar” and “baz”. The result is mystification as the command fails to run the way the user expects, if it runs at all.

What exactly is going on, here? [Martin] goes into considerable detail tracking down this odd behavior and how it happens, but he’s unable to ultimately explain why ssh does things this way. He suspects that it is the result of some design decision taken long ago. Or perhaps a bug that has, over time, been promoted to entrenched quirk.

Do you have any insights or knowledge about this behavior? If so, [Martin] wants to hear about it and so do we, so don’t keep it to yourself! Let us know in the comments, below.

SuSE Take On Red Hat, Forking RHEL

One of the Linux stories of the moment has come from Red Hat, with their ongoing efforts to make accessing the source of their Red Hat Enterprise Linux product a paid-for only process. This has caused consternation and annoyance alike, from the open source community angry at any liberties taken with the GPL, and from the community of RHEL users and customers concerned as to what it might mean for them.

Now a new player has entered the fray in the form of SuSe, who have announced the creation of an RHEL fork with the intention of maintaining a freely-available Red Hat compatible operating system distribution.

This is good news for all who use Red Hat derived software and we expect the likes of Rocky Linux will be taking a close look at it, but it’s also a canny move from the European company as they no doubt hope to tempt away some of those commercial Red Hat customers with a promise of stability and their existing experience supporting Red Hat users through their mixed Linux support packages. We hope they’ll continue to maintain their relationship with the open source world, and that the prospect of their actions unleashing a new commercial challenge causes Red Hat to move away from the brink a little.

Need some of the backstory? We’ve got you covered.

The perfect header for this story comes via atzerok, CC BY-SA 2.0.

Linux Device Drivers In Only A Few Years

[Johannes 4GNU_Linux] has been filming a video series on how to write Linux device drivers for a couple of years now, but luckily, you won’t need that long to watch them or to create your own driver. He’s added some recent videos to the series, like the one below, but might want to rewind a few years and start at the beginning.

If you build your own hardware for Linux, you’ll probably eventually want to write a driver which runs as a privileged program. While there are many things you can do in user space, for the ultimate control and performance, you can’t beat a driver.

One problem, though, is that drivers can really crash your system in a big way. In the old days, it was common to have a dedicated system for driver development. Today, for many drivers, you can get away with running a virtual machine that you can crash and reload without much trouble.

The videos cover diverse topics like interrupts, completions, polling, and threads. He even uses a Raspberry Pi, which will be very useful for many embedded projects. Of course, the trend these days is to have one driver — like the USB driver — and have it provide user-space access so that everyone doesn’t have to write their own drivers. But, as usual, that only goes so far.

We aren’t sure how many more videos there will be, but if you make it through the first 31, maybe more will be waiting for you. It has been a while since we looked at SPI drivers in Linux. As an example of why you might want to roll your own, consider a custom FPGA driver.

Continue reading “Linux Device Drivers In Only A Few Years”

Rocky Strikes Back At Red Hat

The world of Linux has seen some disquiet over recent weeks following the decision of Red Hat to restrict source code distribution for Red Hat Enterprise Linux (RHEL) to only their paying customers. We’re sure that there will be plenty of fall-out to come from this news, but what can be done if your project relies upon access to those Red Hat sources?

The Red-Hat-derived Rocky Linux distro relies on access to RHEL source, so the news could have been something of a disaster. Fortunately for Rocky users though, they appear to have found a reliable way to bypass the restriction and retain access to those RHEL sources. Red Hat would like anyone wanting source access to pay them handsomely for the privilege, but the Rocky folks have spotted a way to bypass this. Using readily available cloud images they can spin up a RHEL system and use it to download their sources, and they can do this as an automated process.

We covered this story as it unfolded last week, and it seemed inevitable then that something of this nature would be found, as for all Red Hat’s wishes a GPL-licensed piece of code can’t be prevented from being shared. So Rocky users and the wider community will for now retain access to the code, but will Red Hat strike back? It’s inevitable that there will be a further backlash from the community against any such moves, but will Red Hat be foolhardy enough to further damage their standing in this regard? They’re certainly not the only large distro losing touch with their users.