Introduction

Here’s my rambly list of misc tech things I am excited about, it is:

• Ordered from low-level to high-level
• Full of future developments that are “on the horizon” for some definition of “the horizon”

Hardware

Processors

There’s been a lot of news about the semiconductor industry lately:

• the CHIPS act has been enacted, allocating $52 billion to supporting semiconductor fabrication in the US.
• Tiny Corp has been putting public pressure on AMD to open source components of their drivers
• NVIDIA stock continues to rise, up 256% from one year ago

I really want silent/fanless computers that don’t get hot. While we’re waiting for lead-apetite superconductors to get validated (I never stopped superconducting in my heart), RISC processors (RISC-V, ARM) are probably our best bet. Apple has made solid progress towards this with their M-series processors, unfortunately they do not have an open standard.

RISC-V

I think the future is bright for RISC-V:

• SiFive and Intel Foundry Service (they manufacture other company’s chips now) released the P550 development board.
• In 2022, Alibaba released the first RISC-V laptop.
• Alibaba announced that it plans to release a RISC-V processor intended for servers this year.

Operating Systems

Linux

Atomic Consoles

Linux developers are pursuing one of the last major obstacles to Real Time (RT) support: atomic consoles/threaded printing. Brief summary of real time operating systems: performance is usually worse but consistent, responses are guaranteed in a set amount of time or else an “alarm” is triggered. RTOS are primarily found on embedded systems. This needs some parallelism and blocking print functions get in the way.

Bcachefs

I use ZFS quite a bit, but it is unlikely to ever be included in the Linux kernel for reasons related to licensing and IP. Bcachefs has similar functionality without legacy code from Solaris and includes several much-desired features that ZFS users have been waiting for forever. It was merged into mainline Linux (with some drama) but once it’s had some time to mature, it may become the future of CoW file systems.

Redox OS

RedoxOS (rust microkernel operating system) continues to progress quickly. Microkernels have a number of benefits (security), but one of the big unknowns is how high the overhead cost of context switching really is, and how much is varies by specific implementation. The list of Linux software that Redox can run is growing and my hope is that this will help us quantify that cost with more direct comparisons.

NixOS

Flakes Enabled by Default

I have no idea when this will happen, but it must happen at some point, right?

Service Abstraction Layer

Calling NixOS an operating system or Linux distribution feels weird, because it’s more of a tool that builds ](inux distributions according to a supplied configuration. One of the non-negotiables when building your system with NixOS is that it must use systemd. I’m not going to debate the merits of systemd here, but I will note that with its prevalence, the linux ecosystem increasingly converges towards upon a monoculture and I appreciate having options. There has been some discussion of creating a “Service Abstraction Layer” (SAL) in the NixOS community.

It’s hard to say how likely this is to actually happen. NixNG is a fork that already allows for choice of init systems. One of the primary developers chimed into a SAL discussion thread to recommend against a SAL on the grounds of the requisite complexity not being worth it. There have been many threads about this, as well as a few pull requests.

There are two other systems I’m aware of that are nix-like without systemd:

• NixBSD, a fork which runs the FreeBSD kernel and does not use systemd for init.
• GuixSD, a fork which is committed to Free Software and uses GNU/Guile (a lisp) rather than the Nix language for configuration. Init is handled by GNU Shepherd.

What Comes Next

Nix is unreasonably effective. It solves many difficult problems and I use it wherever I can (except my router, for now). I think its complexity gets to people, it was hard for me to learn some aspects of it and I’m still not comfortable with flakes.

In the future, there will likely be something similar that solves all of the same problem in a more elegant, simpler, user-friendly way. I would like to see it also be a bit more general, leaning further away from Linux distribution and towards OS-building tool. Support for different init systems fit this goal. Another thought: using a preexisting/familiar language for configuration could be nice, Guix has this going for it.

Desktop Environments

XFCE - Wayland

Wayland support on XFCE is being worked on, the roadmap makes it sound not too far away; xfwm4 is the main component still needing to be ported. I would seriously consider using XFCE once again when it works on Wayland.

COSMIC Desktop

It’s been nearly a decade since I began using Linux. During that time I’ve had nearly zero desktop environment experiences that felt stable, reliable, and not buggy. XFCE has mostly been fine. GNOME and KDE have given me tons of issues even on officially targeted/supported platforms such as KDE Neon and Fedora. This has lead me to believe that desktop environments are simply too complex to be written in non-memory-safe languages.

COSMIC desktop is being developed in rust by System76, where the lead developer of RedoxOS works. The developers at system76 clearly know what they are doing, given the success of Pop!_OS which ships a heavily customized and extended GNOME desktop. I’m excited to see if they are able to produce a desktop that feels solid and works reliably.

Desktop Applications

Helix - Plugins

Helix is my daily-driver text editor. It’s basically snappier vim (more rust software) that I don’t have to configure pretty much ever, except to add my custom color scheme which syntax highlights ONLY comments. Using Helix, I do miss some functionality that I got via extensions previously when I used neovim and emacs. Luckily, Helix is getting plugin support in the future.

It sounds like plugins will be written in some sort of Scheme. Not long after, I’m sure someone will create an org-mode plugin, which is what I want most. Who knows, with proper keybind definitions, maybe it will even become a viable alternative to emacs. Until then, markdown with the marksman language server makes Helix usable for notes.

Appflowy - Tauri

Appflowy is a note-taking app (rust again). It has two properties that set it apart from many similar apps: it’s open source (not just source-available, like anytype), and it doesn’t use electron for its UI (it uses flutter/dart). Additionally, the developers are working on a Tauri frontend.

I run into some issues using Appflowy on Linux, probably because it’s not a priority deployment target for Flutter. One example of this is that file picker dialogs don’t open. I suspect using Tauri will fix many problems including this one, but if it doesn’t, I imagine they’ll get fixed otherwise as time goes on anyways.