BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel

It’s been a tense few months for users of the BCacheFS filesystem, as amidst the occasional terse arguments and flowery self-praise on the Linux Kernel mailing list the future of this filesystem within the Linux kernel hung very much in the balance. After some initial confusion about what ‘externally maintained’ means in Linux parlance, it’s now clear that this means that BCacheFS has effectively been kicked out of the kernel as [Linus] promised and will ship as a DKMS module instead. The gory details of this change are discussed in a recent video by [Brodie Robertson].

We covered the BCacheFS controversy in the Linux world a few months ago, amidst reports of data loss and filesystem corruption among its users. Its lead developer, [Kent Overstreet], came to blows with [Linus Torvalds] on the LKML after [Kent] insisted on repeatedly pushing new features into kernel release candidate branches along with rather haughty statements on why he should be able to do this.

To make a long story short, [Linus] didn’t like this and froze BCacheFS support in the current kernel release with all future in-kernel development ceased. Distributions like SuSE have initially said that will disable BCacheFS starting in kernel version 6.17, meaning that users of BCacheFS may now have to install the DKMS module themselves. Some distributions like Arch are likely to include this DKMS module by default, which is something you want to check if you use this filesystem.

Continue reading “BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel”

Everything In A Linux Terminal

Here at Hackaday Central, we fancy that we know a little something about Linux. But if you’d tasked us to run any GUI program inside a Linux terminal, we’d have said that wasn’t possible. But, it turns out, you should have asked [mmulet] who put together term.everything.

You might be thinking that of course, you can launch a GUI program from a terminal. Sure. That’s not what this is. Instead, it hijacks the Wayland protocol and renders the graphics as text. Or, if your terminal supports it, as an image. Performance is probably not your goal if you want to do this. As the old saying goes, “It’s not that the dog can sing well; it’s that the dog can sing at all.”

If, like us, you are more interested in how it works, there’s a write up explaining the nuances of the Wayland protocol. The article points out that Wayland doesn’t actually care what you do with the graphical output. In particular, “… you could print out the graphics and give them to a league of crochet grandmas to individually tie together every single pixel into the afghan of legend!” We expect to see this tested at an upcoming hacker conference. Maybe even Supercon.

We generally don’t like Wayland very much. We use a lot of hacks like xdotool and autokey that Wayland doesn’t like. We also think people didn’t understand X11’s network abilities until it was too late. If you think of it as only a video card driver, then you get what you deserve. But we have to admit, we are humbled by term.everything.

A Look At Not An Android Emulator

Recently, Linux has been rising in desktop popularity in no small part to the work on WINE and Proton. But for some, the year of the Linux desktop is not enough, and the goal is now for the year of the Linux phone. To that end, an Android Linux translation layer called Android Translation Layer (we never said developers were good at naming) has emerged for those running Linux on their phones.

Android Translation Layer (ATL) is still in very early days, and likely as not, remains unpackaged on your distro of choice. Fortunately, a workaround is running an Alpine Linux container with graphics pass through via a tool like Distrobox or Toolbox. Because of the Alpine derived mobile distribution postmarketOS, ATL is packaged in the Alpine repos.

In many ways, running Android apps on Linux is much easier then Windows apps. Because Android apps are architecture independent, hardware emulation is unnecessary. With such similar kernels, on paper at least, Android software should run with minimal effort on Linux. Most of what ATL provides is a Linux/Android hardware abstraction layer glue to ensure Android system calls make their way to the Linux kernel.

Of course, there is a lot more to running Android apps, and the team is working to implement the countless Android system APIs in ATL. For now, older Android apps such as Angry Birds have the best support. Much like WINE, ATL will likely devolve into a game of wack-a-mole where developers implement fresh translation code as new APIs emerge and app updates break. Still, WINE is a wildly successful project, and we hope to see ATL grow likewise!

If you want to get your Android phone to talk to Linux, make sure to check out this hack next! 

The Android Linux Commander

Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.

I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:

  • All messages to the ordinary Linux start with >
  • All messages to the Android device start with <
  • All messages end with a carriage return

Security

You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.

There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.

If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.

Continue reading “The Android Linux Commander”

The Android Bluetooth Connection

Suppose someone came to talk to you and said, “I need your help. I have a Raspberry Pi-based robot and I want to develop a custom Android app to control it.” If you are like me, you’ll think about having to get the Android developer tools updated, and you’ll wonder if you remember exactly how to sign a manifest. Not an appealing thought. Sure, you can buy things off the shelf that make it easier, but then it isn’t custom, and you have to accept how it works. But it turns out that for simple things, you can use an old Google Labs project that is, surprisingly, still active and works well: MIT’s App Inventor — which, unfortunately, should have the acronym AI, but I’ll just call it Inventor to avoid confusion.

What’s Inventor? It lives in your browser. You lay out a fake phone screen using drag and drop, much like you’d use QT Designer or Visual Basic. You can switch views and attach actions using a block language sort of like Scratch. You can debug in an emulator or on your live phone wirelessly. Then, when you are ready, you can drop an APK file ready for people to download. Do you prefer an iPhone? There’s some support for it, although that’s not as mature. In particular, it appears that you can’t easily share an iPhone app with others.

Is it perfect? No, there are some quirks. But it works well and, with a little patience, can make amazingly good apps. Are they as efficient as some handcrafted masterpiece? Probably not. Does it matter? Probably not. I think it gets a bad rep because of the colorful blocks. Surely it’s made for kids. Well, honestly, it is. But it does a fine job, and just like TinkerCad or Lego, it is simple enough for kids, but you can use it to do some pretty amazing things.

Continue reading “The Android Bluetooth Connection”

Video Clips With Emacs

Sometimes it seems like there’s nothing Emacs can’t do. Which, of course, is why some people love it, and some people hate it. Apparently, [mbork] loves it and devised a scheme to show a video (with a little help), accept cut-in and out marks, and then use ffmpeg to output the video clip, ready for posting, emailing, or whatever.

This was made easier by work already done to allow Emacs to create subtitles (subed). Of course, Emacs by itself can’t play videos, but it can take control of mpv, which can. Interestingly, subed doesn’t insist on mpv since it won’t work on Windows, but without it, your editing experience won’t be as pleasant.

Continue reading “Video Clips With Emacs”

Linux Fu: Windows Virtualization The Hard(ware) Way

As much as I love Linux, there are always one or two apps that I simply have to run under Windows for whatever reason. Sure, you can use wine, Crossover Office, or run Windows in a virtual machine, but it’s clunky, and I’m always fiddling with it to get it working right. But I recently came across something that — when used improperly — makes life pretty easy. Instead of virtualizing Windows or emulating it, I threw hardware at it, and it works surprisingly well.

Once Upon a Time

First, a story. Someone gave me a Surface Laptop 2 that was apparently dead. It wouldn’t charge, and you can’t remove the keyboard without power. Actually, you can with a paper clip, and I suggested pulling it to see if the screen would charge by itself. They said they had already bought a new computer, so they didn’t care.

Unsurprisingly, once I popped the keyboard off, the computer charged and was fine. You just have to replace the keyboard or use another one. Or use it as a tablet, which it is set up for anyway. But I have plenty of laptops and computers of every description. What was I going to do with this nice but keyboardless computer? Continue reading “Linux Fu: Windows Virtualization The Hard(ware) Way”