Episode 286
Old Machine Revival
February 21st, 2019
1 hr 18 mins 56 secs
Tags
About this Episode
Adding glue to a desktop environment, flashing the BIOS on a PC Engine, revive a Cisco IDS into a capable OpenBSD computer, An OpenBSD WindowMaker desktop, RealTime data compression, the love for pipes, and more.
##Headlines
###Adding Glue To a Desktop Environment
In this article we will put some light on a lot of tools used in the world of Unix desktop environment customization, particularly regarding wmctrl, wmutils, xev, xtruss, xwininfo, xprop, xdotools, xdo, sxhkd, xbindkeys, speckeysd, xchainkeys, alttab, triggerhappy, gTile, gidmgr, keynav, and more. If those don’t make sense then this article will help. Let’s hope this can open your mind to new possibilities.
With that in mind we can wonder if what’s actually needed from a window manager, presentation and operation, can be split up and complemented with other tools. We can also start thinking laterally, the communication and interaction between the different components of the environment. We have the freedom to do so because the X protocol is transparent and components usually implement many standards for interfacing between windows. It’s like gluing parts together to create a desktop environment.
- The tools we’ll talk about fall into one of those categories:
- Debugging
- Window manipulation
- Simulation of interaction
- Extended manipulation
- Hotkey daemon
- Layout manager
###Flashing the BIOS on the PC Engines APU4c4
I absolutely love the PC Engines APU devices. I use them for testing HardenedBSD experimental features in more constrained 64-bit environments and firewalls. Their USB and mSATA ports have a few quirks, and I bumped up against a major quirk that required flashing a different BIOS as a workaround. This article details the hacky way in which I went about doing that.
What prompted this article is that something in either the CAM or GEOM layer in FreeBSD 11.2 caused the mSATA to hang, preventing file writes. OPNsense 18.7 uses FreeBSD 11.1 whereas the recently-released OPNsense 19.1 uses HardenedBSD 11.2 (based on FreeBSD 11.2). I reached out to PC Engines directly, and they let me know that the issue is a known BIOS issue. Flashing the “legacy” BIOS series would provide me with a working system.
It also just so happens that a new “legacy” BIOS version was just released which turns on ECC mode for the RAM. So, I get a working OPNsense install AND ECC RAM! I’ll have one bird for dinner, the other for dessert.
Though I’m using an APU4, these instructions should work for the other APU devices. The BIOS ROM download URLs should be changed to reflect the device you’re targeting along with the BIOS version you wish to deploy.
SPECIAL NOTE: There be dragons! I’m primarily writing this article to document the procedure for my own purposes. My memory tends to be pretty faulty these days. So, if something goes wrong, please do not hold me responsible. You’re the one at the keyboard. ;)
VERY SPECIAL NOTE: We’ll use the mSATA drive for swap space, just in case. Should the swap space be used, it will destroy whatever is on the disk.
##News Roundup
###Revive a Cisco IDS into a capable OpenBSD computer!
Even though Cisco equipment is very capable, it tends to become End-of-Life before you can say “planned obsolescence”. Websites become bigger, bandwidths increase, and as a side effect of those “improvements”, routers, firewalls, and in this case, intrusion prevention systems get old quicker and quicker.
Apparently, this was also the case for the Cisco IDS-4215 Intrusion Detection Sensor that I was given a few months ago.
I’m not too proud to admit that at first, I didn’t care about the machine itself, but rather about the add-on PCI network card with 4 Fast Ethernet interfaces. The sensor has obviously seen better days, as it had a broken front panel and needed some cleaning, but upon a closer inspection under the hood (which is held closed by the 4 screws on top), this IDS consists of an embedded Celeron PC with two onboard Ethernet cards, a 2.5″ IDE hard disk, a CF card, and 2 PCI expansion slots (more on them later). Oh, and don’t forget the nasty server-grade fan, which pushed very little air for the noise it was making.
###An OpenBSD desktop using WindowMaker
Since I started using *N?X, I’ve regularly used WindowMaker. I’ve always liked the look and feel, the dock system and the dockapps. It may look a bit oldish nowadays. And that’s enough to try to change this. So here it is, a 2019 flavored WindowMaker Desktop, running on OpenBSD 6.4/amd64.
This configuration uses the Nord color-scheme, the Adapta-Nokto-Eta GTK theme and the Moblin Unofficial Icons icon set. I did remove applications icons. I just don’t need them on the bottom of the screen as I heavily use “F11” to pop-up the windows list. To be able to do that and keep the dockapps, I tweaked my ~/GNUstep/Defaults/WMWindowAttributes and created a ~/GNUstep/Library/WindowMaker/Themes/Nord.themed/style.
And here it is, the NeXT OpenBSD Desktop!
In a previous episode, we’ve seen that it is possible to create opaque types. However, creation and destruction of such type must be delegated to some dedicated functions, which themselves rely on dynamic allocation mechanisms.
Sometimes, it can be convenient to bypass the heap, and all its malloc() / free() shenanigans. Pushing a structure onto the stack, or within thread-local storage, are natural capabilities offered by a normal struct. It can be desirable at times.
The previously described opaque type is so secret that it has no size, hence is not suitable for such scenario.
Fortunately, static opaque types are possible.
The main idea is to create a “shell type”, with a known size and an alignment, able to host the target (private) structure.
For safer maintenance, the shell type and the target structure must be kept in sync, by using typically a static assert. It will ensure that the shell type is always large enough to host the target structure. This check is important to automatically detect future evolution of the target structure.
My top used shell command is |. This is called a pipe.
In brief, the | allows for the output of one program (on the left) to become the input of another program (on the right). It is a way of connecting two commands together.
According to doc.cat-v.org/unix/pipes/, the origin of pipes came long before Unix. Pipes can be traced back to this note from Doug McIlroy in 1964
##Beastie Bits
- Installation Notes for NetBSD/i386 0.9
- Porting Zig to NetBSD - a fun, speedy port
- NNN - Tiny, lightning fast, feature-packed file manager Release v2.3
- eta - A tool for monitoring progress and ETA of an arbitrary process
- A FreeBSD User Tries Out…NetBSD 8.0
- Faster vlan(4) forwarding?
- FuguIta - OpenBSD 6.4 Live System
- Adding Name-based hosting To Nginx on OpenBSD with Acme-Client
- HOWTO set up QEMU with HAXM acceleration on NetBSD
- README: gcc 7 switch coming to a port near you!
##BUG Calendar
- ChiBUG, Chicago, USA: Tuesday, February 26th 18:00 at the Oak Park Library
- CharmBUG, Baltimore, USA: Wednesday, February 27, 2019
19:30 at Columbia Ale House - NYC*BUG, New York, USA: Wednesday, March 6, 2019 18:45 at Suspenders
- KnoxBUG, Knoxville, USA: Monday, February 25, 2019 - 18:00 at iX Systems offices
- BSDPL, Warsaw, Poland: February 28, 2019 18:15 - 21:00 at Wheel Systems Office
##Feedback/Questions
- Sam - Customizing OpenBSD ports source code
- Frank - Rivalry Linux & BSD
- Zach - mysql/mariadb tuning
- Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv