Monthly Archive:: April 2022
The Sound Blaster X7 is a DAC (Digital Analog Converter) and amplifier. It allows several inputs to be mixed together toward a single output. Its configuration is maintained directly on the device and can be controlled by either a mobile device over Bluetooth or from a Windows machine over USB. When using my work laptop, I can’t change the X7 volume or output. This is an issue when you need to jump into a quick call as you can’t switch over to headset easily. Since control over Bluetooth works well from the Android application, it is possible to control all the features I need over Bluetooth. There is only one issue: the only thing I’ve ever reversed is a USB msi keyboard to implement support on Linux. I don’t know much about how Bluetooth works, nor about Android and from what I could gather, I can’t live capture the Bluetooth traffic (on my device) like I did for USB. It is nothing that can’t be fixed by a bit of reading and some work, so let’s do this. It’s amazing to me that a lot of more obscure and less popular hardware has Linux support only because some random person in Nowhere, Nebraska, had a need for it.
Known as right angle with downwards zigzag arrow, angle with down zig-zag arrow, \rangledownzigzagarrow, and ⍼, no one knows what ⍼ is meant to represent or where it originated from. Section 22.7 Technical Symbols from the Unicode Standard on the Miscellaneous Technical block doesn’t say anything about it. Who doesn’t love a good what-the-hell-is-this-glyph story?
Raspberry Pi computers require a piece of non-free software to boot — the infamous raspi-firmware package. But for almost as long as there has been a Raspberry Pi to talk of (this year it turns 10 years old!), there have been efforts to get it to boot using only free software. How is it progressing? Turns out a lot better than expected.
EndeavourOS is an Arch-based Linux distribution, and in and of itself not something I’d write about here. However, at the very end of the release notes for its latest release, there’s this: This release is also shipping with a brand-new Window Manager developed by our community editions team member Codic12 and we are more than proud to present you this WM that was developed a little bit under our wing. Codic12 decided to develop this WM to satisfy his need for a lightweight window manager that worked well with both floating and tiling modes and had window decorations with minimise, maximise and close buttons in any layout desired and that could run on a semi-embedded system like the PIZero. Worm is written in Nim and is based on X11, a Wayland version isn’t in the pipeline in the near future, according to him. There’s been a surge of interest in tiling window managers lately, with tons of articles and howtos about things like i3 and Awesome, and System76, too, made tiling a prime feature in Pop!_OS. Heck, even Windows is in on the game. Tiling isn’t for me – I’ll manage and resize my window manually, like an animal, thank you very much – but there’s no denying there seems to be a huge demand for tiling features.
Up until now, all installs of Raspberry Pi OS have had a default user called “pi”. This isn’t that much of a weakness – just knowing a valid user name doesn’t really help much if someone wants to hack into your system; they would also need to know your password, and you’d need to have enabled some form of remote access in the first place. But nonetheless, it could potentially make a brute-force attack slightly easier, and in response to this, some countries are now introducing legislation to forbid any Internet-connected device from having default login credentials. So with this latest release, the default “pi” user is being removed, and instead you will create a user the first time you boot a newly-flashed Raspberry Pi OS image. This is in line with the way most operating systems work nowadays, and, while it may cause a few issues where software (and documentation) assumes the existence of the “pi” user, it feels like a sensible change to make at this point. This is a pretty substantial change that might break some applications that assume the default “pi” user exists.
Word is out there that an individual is trying to develop Pentium III emulation as part of a fork of 86Box, regardless of how slow it is, in the name of “hardware preservation”. But why didn’t we do it in the first place? Why did we, developers of a PC emulator clearly aimed at the preservation of hardware and software, limit ourselves to the Pentium II and an underperforming competitor (the VIA Cyrix III), and why did we do these two knowing they’re already pretty slow to emulate? It’s story time. When I started reading this article I had no idea there was going to be some classic open source/forking drama at the end, but even with that, it’s a good article and definitely worth a read.
Starting on November 1, 2022, existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level. As new Android OS versions launch in the future, the requirement window will adjust accordingly. This is a very welcome move, since finding incredibly old and abandoned applications is not an uncommon occurrence in the Play Store. Clean-ups like this almost make up for Google removing the “last updated on” field in Play Store listings. Almost.
Graphics card prices remain hugely inflated compared to a few years ago, but the good news is that things finally seem to be getting consistently better and not worse. This is good news. I don’t think I’ve ever experienced something like this before in my life, and I can’t wait for prices to truly reach sane levels again, as both my fiancée and I are due for an upgrade.
I’ve been using Linux exclusively for ~15 yrs. I’ve recently started a fantastic new job – the only wrinkle was that it came with a Windows 10 laptop. This is my first time using Windows after a 15-year break. This is how it’s been going. Hint: not well.
In this post, we’ll look at implementing a simple character device driver as a kernel module in NetBSD. Once it is loaded, userspace processes will be able to write an arbitrary byte string to the device, and on every successive read expect a cryptographically-secure pseudorandom permutation of the original byte string. IF you’ve always wanted to learn how to write a NetBSD driver, here’s a great starting point.
With Fedora 36 working its way towards release later this month, more developer attention and planning is turning to Fedora 37 that will be released this autumn. One of the changes being talked about this week is for signing RPM contents for a means of trusting the files that are executed. The Fedora 37 change proposal is for adding IMA-based signatures to the individual files that are part of shipped RPM packages. This will allow for enforcing run-time policies by system administrators to ensure the execution of only trusted files or similar policies. This is a good idea, and it’s important to underline that this is entirely optional – nothing will change for regular end users who are not interested in such policies. This won’t limit your ability to install whatever rpm you want, nor does it lock down anything any further than it is today – it just gives administrators more options.
We aim for the beautiful Sailfish user experience to bring a similar elegance and simplicity to an otherwise busy and distracting world. But the beauty on the surface has to be backed up with cutting-edge technology underneath which keeps up with modern standards and developments. That’s why in the 4.4.0 Vanha Rauma release we’ve been working hard to improve compatibility across the board, keeping up with recent browser and feature developments. At the same time, we’ve been refining the user interface to allow all the new features to be exposed in a way that doesn’t impact on the simplicity of your device in daily use. I’ve been a Sailfish OS user for years and am now involved in its development, so can’t claim to be an impartial actor. But it means I also have some understanding of the effort and ideas that went into this release. Some of the big new features are the updated Gecko browser engine, all apps Sailjailed by default, NFC Bluetooth pairing, and many nice community-contributed improvements to positioning, calendar and more – and all built on a a strong Linux/glibc foundation.
I’ve extended James Friend’s in-browser Basilisk II port to create a full-featured classic 68K Mac in your browser. You can see it in action at system7.app or macos8.app. However, none of these setups replicated the true feel of using a computer in the 90s. They’re great for quickly launching a single program and playing around with it, but they don’t have any persistence, way of getting data in or out of it, or running multiple programs at once. macintosh.js comes closest to that — it packages James’s Basilisk II port with a large (~600MB) disk image and provides a way of sharing files with the host. However, it’s an Electron app, and it feels wrong to download a ~250MB binary and dedicate 1 CPU core to running something that was meant to be in a browser. I wondered what it would take to extend the Basilisk II support to have a macintosh.js-like experience in the browser, and ideally go beyond it. There’s countless of these, but this is definitely one of the nicer ones. It won’t be long before we move from running classic operating systems in local emulators, to just firing up a tab and booting up whatever we feel like playing around with today. I certainly won’t miss manually creating VMs or fiddling with purpose-built emulators.
Workstation (workstation) is an open source reference design for Fuchsia. Workstation is not a consumer-oriented product. Workstation is a tool for developers and enthusiasts to explore Fuchsia and experiment with evolving concepts and features. Workstation is one of the many “product configurations” Fuchsia can be set up with, and it targets both the Fuchsia emulator as well as an Intel NUC – so real hardware. This configuration’s goal is to be “a basis for a general purpose development environment, good for working on UI, media and many other high-level features. This is also the best environment for enthusiasts to play with and explore.” They’re emphasizing this is not some ploy to desktop dominance, but there’s no denying that with every step Fuchsia takes – from shipping it on Google Home devices to porting and running Chrome – they’re getting it ready for more than just some IoT project.
I have a proclivity to stupid and/or pointless projects. This is one of them. Conceived from a conversation that ended with “Hey, it would technically be possible to…” – sure, let’s do it. DDC, display data channel, is a protocol for reading information about what resolutions and so on a monitor supports. It was later extended to DDC/CI, that lets you set brightness and other parameters, but fundamentally, the original idea was to stick a cheap i2c eeprom on each device with some basic info on it. (Technically, the original idea was even simpler than that, but let’s not get into that.) It began in the VGA days, but has become so entrenched that even modern hardware with HDMI or DisplayPort supports it. That’s right, in an HDMI cable, nestled amongst the high-speed differential pairs, there’s an exceedingly slow i2c bus. Tiny OLED dot-matrix displays often have an i2c controller, so I had the idea to try and plug one directly into an HDMI port. Hilarious! Let’s do it. This is the kind of stuff that just puts a huge smile on my face – something we can use during these trying times.
Believe it or not, not everything is based on C. There are current, shipping, commercial OSes written before C was invented, and now others in both newer and older languages that don’t involve C at any level or layer. There’s tons of examples.