Will 2020 Be The Year Of Rust In The Linux Kernel?

July 15, 2020 by Sven Gregori 55 Comments

One problem with modern programming languages is the reach their overly enthusiastic early adopters have nowadays thanks to the internet. As a result, everyone else’s first encounter with them are oftentimes some crude, fanboyish endeavors to rewrite every single established software project in that shiny new language — just because — which may leave an off-putting taste behind. However, Rust certainly seems to have outgrown this state by now, and with its rising popularity within the general developer population, it’s safe to say it will stick around. Will it fully replace C one day? Probably not, but there’s a big chance for coexistence, and [Nick Desaulniers] got the ball rolling for that within the Linux kernel.

Now, before you storm off pledging your allegiance to C by finding a new operating system: nothing is happening yet. [Nick] simply tested the waters for a possible future of Rust within the Linux kernel code base, which is something he’s planning to bring up for discussion in this year’s Linux Plumbers Conference — the annual kernel developer gathering. The interesting part is [Linus Torvalds]’s respone on the LKML thread, which leaves everyone hoping for a hearty signature Rust rant akin to his C++ one disappointed. Instead, his main concern is that a soft and optional introduction of the support in the build system would leave possible bugs hidden, and therefore should be automatically enabled if a Rust compiler is present — essentially implying that he seems otherwise on board.

We’ll see what comes of it, but with Rust language team lead [Josh Triplett] stating that enhancements benefiting and advancing a kernel integration are certainly imaginable for Rust itself, we might see interesting collaborations coming up in the near future. If you don’t want to wait for that and use Rust already today in a user-land driver, check out this 35c3 talk. And if that doesn’t go far enough for you, here’s a whole (non-Linux) kernel written in Rust.

Synthesizer Gets An External Touch Screen

July 8, 2020 by Tom Nardi 3 Comments

Like other owners of the high-end Yamaha MODX, [sn00zerman] wasn’t happy with the synthesizer’s integrated touch screen. It’s a bit small, and not at a very good angle for viewing. So he made it his mission to find some way of adding a larger external touch screen without making any permanent modifications to the expensive instrument.

This might seem like a tall order, but he wasn’t starting from zero. It was already known that you could plug an external display into it if you used a USB to DVI/HDMI adapter; but without the touch overlay it wasn’t a particularly useful trick. He pondered adding an external connector for the device’s built-in touch screen overlay, but that broke his no modifications rule. Considering how much one of these things cost, we can’t blame him for not wanting to put a hole in the side.

Sometimes you just have to dig out the right parts.

So he started to look for a software solution to get him the rest of the way. Luckily the MODX runs Linux, and Yamaha has made good on their GPL responsibilities and released the source code for anyone who’s interested. While poking around, he figured out that the device uses tslib to talk to the touch screen, which [sn00zerman] had worked with on previous projects. He realized that the solution might be as simple as finding a USB touch screen controller that’s compatible with the version of tslib running on the MODX.

In the end, a trip through his parts bin uncovered a stand-alone touch screen controller that he knew from experience would work with the library. Sure enough, when plugged into the MODX, the OS accepted it as an input device. With the addition of a USB hub, he was able to combine this with an existing display and finally have a more comfortable user-interface for his synthesizer.

Now all he’s got to do is plug in a USB floppy drive, and he’ll have the ultimate Yamaha Beat Laboratory.

Continue reading “Synthesizer Gets An External Touch Screen” →

The Latest Linux – On A Floppy In A 486!

July 8, 2020 by Jenny List 97 Comments

If you have ever studied the early history of the GNU/Linux operating system in its many forms, you’ll have read that [Linus Torvalds] developed his first kernel for his Intel 386-based computer. Though the 386 architecture is now ancient, the current Linux kernel can still be compiled for it and many distributions still maintain an i386 branch to provide broad compatibility for later machines able to run i386 code. But what if you were to take a current Linux kernel and stick it on a floppy in a machine from the early 1990s, with meagre RAM? [Fozztex] did just that, with not a 386 but a 486, sporting what would have been an impressive for the time 36MB of RAM. You can watch it in action in the video below the break.

A recent Linux kernel is rarely if ever compiled for something as small as a floppy disk, so getting one to boot from such ancient media appeared to be a challenge. It was possible though with the tinyconfig make option, and after finding a small enough root filesystem courtesy of Aboriginal Linux, a bootable floppy was created. It’s not entirely useful and its sole purpose was to see whether Linux could see a large hard drive on the 486, but it’s still a version 5.6 Linux kernel booting from floppy on an ancient computer. Never complain that your Raspberry Pi Zero is slow again, we’ve come a long way!

Continue reading “The Latest Linux – On A Floppy In A 486!” →

Linux-Fu: Parallel Universe

June 29, 2020 by Al Williams 38 Comments

At some point, you simply run out of processing power. Admittedly, that point keeps getting further and further away, but you can still get there. If you run out of CPU time, the answer might be to add more CPUs. However, sometimes there are other bottlenecks like memory or disk space. However, it is also likely that you have access to multiple computers. Who doesn’t have a few Raspberry Pis sitting around their network? Or maybe a server in the basement? Or even some remote servers “in the cloud.” GNU Parallel is a tool that lets you spread work across multiple tasks either locally to remote machines. In some ways, it is simple, since it looks sort of like xargs but with parallel execution. On the other hand, it has myriad options and configurations that can make it a little daunting to use. Continue reading “Linux-Fu: Parallel Universe” →

What’s The Deal With Snap Packages?

June 24, 2020 by Tom Nardi 151 Comments

Who would have thought that software packaging software would cause such a hubbub? But such is the case with snap. Developed by Canonical as a faster and easier way to get the latest versions of software installed on Ubuntu systems, the software has ended up starting a fiery debate in the larger Linux community. For the more casual user, snap is just a way to get the software they want as quickly as possible. But for users concerned with the ideology of free and open source software, it’s seen a dangerous step towards the types of proprietary “walled gardens” that may have drove them to Linux in the first place.

Perhaps the most vocal opponent of snap, and certainly the one that’s got the most media attention, is Linux Mint. In a June 1st post on the distribution’s official blog, Mint founder Clement Lefebvre made it very clear that the Ubuntu spin-off does not approve of the new package format and wouldn’t include it on base installs. Further, he announced that Mint 20 would actively block users from installing the snap framework through the package manager. It can still be installed manually, but this move is seen as a way to prevent it from being added to the system without the user’s explicit consent.

The short version of Clement’s complaint is that the snap packager installs from a proprietary Canonical-specific source. If you want to distribute snaps, you have to set up an account with Canonical and host it there. While the underlying software is still open source, the snap packager breaks with long tradition of having the distribution of the software also being open and free. This undoubtedly makes the install simple for naive users, and easier to maintain for Canonical maintainers, but it also takes away freedom of choice and diversity of package sources.

Continue reading “What’s The Deal With Snap Packages?” →

Netbooks: The Next Generation — Chromebooks

June 24, 2020 by Jonathan Bennett 35 Comments

Netbooks are dead, long live the Chromebook. Lewin Day wrote up a proper trip down Netbook Nostalgia Lane earlier this month. That’s required reading, go check it out and come back. You’re back? Good. Today I’m making the case that the Chromebook is the rightful heir to the netbook crown, and to realize its potential I’ll show you how to wring every bit of Linuxy goodness out of your Chromebook.

I too was a netbook connoisseur, starting with an Asus Eee 901 way back in 2009. Since then, I’ve also been the proud owner of an Eee PC 1215B, which still sees occasional use. Only recently did I finally bite the bullet and replace it with an AMD based Dell laptop for work.

For the longest time, I’ve been intrigued by a good friend who went the Chromebook route. He uses a Samsung Chromebook Plus, and is constantly using it to SSH into his development machines. After reading Lewin’s article, I got the netbook bug again, and decided to see if a Chromebook would fill the niche. I ended up with the Acer Chromebook Tab 10, codename Scarlet. The price was right, and the tablet form factor is perfect for referencing PDFs.

Two Asus Netbooks and a ChromeOS tablet. — Behold, my netbook credentials.

The default ChromeOS experience isn’t terrible. You have the functionality of desktop Chrome, as well as the ability to run virtually any Android app. It’s a good start, but hardly the hacker’s playground that a Linux netbook once was. But we can still get our Linux on with this hardware. There are three separate approaches to making a Chromebook your own virtual hackspace: Crostini, Crouton, and full OS replacement.

Continue reading “Netbooks: The Next Generation — Chromebooks” →

Seeing Code: The Widescreen Rant

June 20, 2020 by Elliot Williams 114 Comments

A couple of weeks ago, Linus Torvalds laid down the law, in a particularly Linusesque sort of way. In a software community where tabs vs. spaces can start religious wars, saying that 80-character-wide code was obsolete was, to some, utter heresy. For more background on how we got here, read [Sven Gregori]’s history piece on Hackaday, and you’ll learn that sliced bread and the 80-character IBM punch card both made their debut in July, 1928. But I digress.

When I look at a codebase, I like to see its structure, and I’m not alone. That’s one of the reasons for the Linux Kernel style guide’s ridiculously wide 8-character tabs. Combined with a trend for variable names becoming more and more descriptive, which I take to be a good thing, and monitors’ aspect ratios growing seemingly without end, which I don’t, the 80-column width seems like a relic from the long-gone era of the VT-220.

In Linus’ missive, we learn that he runs terminals at 100 x 50, and frequently drags them out to a screen-filling 142 x 76. (Amateur! I write this to you now on 187 x 48.) When you’re running this wide, it doesn’t make any sense to line-wrap argument lists, even if you’re using Hungarian notation.

And yet, change is painful. I’ve had to re-format code to meet 73-column restrictions for a book, only to discover that my inline comments were too verbose. Removing even an artificial restriction like the 80-column limit will have real effects. I write longer paragraphs, for instance, on a wider screen.

I see a few good things to come out of this, though. If single thoughts can be expressed on single lines, it makes the shape of the code better reflect its function. Getting rid of pointless wrapping takes up less vertical space, which is at a premium on today’s cinematic monitors. And if it makes inline comments better (I know, another holy war!) or facilitates better variable naming, it will have been worth it.

But any way you slice it, we’re no longer typing on the old 80-character Hazeltine. It’s high time for our coding style and practice to catch up.