Welcome and unwelcome technologies

We are not building a "Linux distribution". In fact, we are building the opposite of a "Linux distribution". We are building "it just works!" end-user appliances (initially for the desktop, later possibly also for media consumption devices and other form factors). In fact, we are not even using Linux but FreeBSD. Which is not only a kernel but a complete operating system - big difference!

Welcome

Some technologies and concepts are wanted in this project because they make life easy and elegant.

Concepts

• Desktop metaphor (think 80s to early 2000s Macs)
• Direct manipulation (as coined by Ben Shneiderman)
• Offline-first design (assuming that being online is the exception rather than the rule)
• WYSIWYG: What you see is what you get (on-screen display looks like a printed page)
• Spatial Filer: Every object in the file system has one place on screen (at defined coordinates), and one place only
• Application bundles that are relocatable in the filesystem (can run from any location) and don't require package managers to be "managed"
• Proper checkboxes https://tonsky.me/blog/checkbox/
• Repairable hardware using exchangeable standard parts (e.g., Framework Laptop)

Technologies

• Qt: May not be perfect (C++!) but as long as GNUstep is not in the mainstream for cross-platform application development (yet)?, Qt is probably the most pragmatic cross-platform GUI toolkit available right now
• mDNSResponder: https://cmcenroe.me/2017/01/08/freebsd-macos-file-sharing.html. Unfortunately many packages have dependencies on Avahi instead.
• Disk images: Can be mounted and used instantly without having to unpack the contents to disk first. Especially compressed filesystem images like uzip with Zstandard compression should be used in place of .tar.gz, .zip, and similar formats where possible
• Python Some of the GUIs are written in Python with PyQt5 so that the source code is easily editable all the time. This is designed to invite (power) users to have a look at the code, start to experiment, and possibly eventually contribute. Especially when used in conjunction with the simplified .app bundle format and with an IDE with autocompletion, this makes for a very accessible development environment with very low barriers to entry. No source code to search and download, no compilers, just open the .app bundle and start hacking away. Tiny example applications like Log.app and Calendar.app are included that anyone should be able to understand in no time
• Go (Golang) for daemons and more complex "business logic". Compiles down to static binaries without dependencies, can easily be cross-compiled. Code written by others is easy to read (once you know basic Go), allowing for long-term maintainability of code by teams with members changing over time. Sharing a lot of the same heritage, Go is how C would look if it was invented today
• ALSA: More complicated than the native FreeBSD sound system but seemingly needed to get, e.g., LMMS to work properly with MIDI keyboards (using the alsa_seq_server daemon and ALSA support compiled into applications). So we may have to use it

Unwelcome

Some technologies are not wanted in this project because they are too complex or deemed aesthetically unpleasant, and hence are not deemed to be suitable given the objectives of this project.

Keep in mind that the design intent of this project is to loosely follow the concepts from the Macintosh Human Interface Guidelines from the early 90s, and to provide an environment for people in which users of those systems can feel right at home today.

• btrfs: Has eaten my data once as my disk approached 100% fill level (as it always does)
• OSTree: Makes the filesystem unmanageable by hand because it names files in ways that make no sense to humans
• GLib: If you want to use classes, then use C++ or Python rather than C. They are built for object oriented programming, whereas C is not.
• GSettings: GSettings and schemas are just if someone thought the Windows Registry was so good we'd need to have something like it. --> Use .ini files instead.
• Gnome: While nicely designed on the surface, it is too complex technologically and seems to follow a design philosophy different from the original Macintosh desktop. KDE: Can do many things, but everything can (and needs to) be configured, while we want to keep configurability at the bare minimum. --> Use something much simpler instead, e.g., a tiny Qt-based desktop environment
• Gtk: Not really focused on cross-platform, code increasingly entangled with the Gnome ecosystem. Code-wise, very complicated to do even the simplest things (for example, instead of doing a replace() on a string you have to deal with buffers, buffer arrays, pointers, character arrays, manual memory allocation, null terminators; this is not how my brain works) --> Use Qt instead
• Gtk newer than Gtk2: If you must use Gtk, stay at least away from versions newer than 2. More information: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ ("GTK3 isn’t a reliable API. Maybe it should be called libgnome instead") --> Use Qt instead; if you cannot, use Gtk 2
• Gio is a high-level file I/O library in Gtk/Gnome used to handle file and application I/O operations, such as reading and writing files, monitoring file changes, and managing file metadata. --> Use QIODevice instead
• Wayland: Under development since a long time, it offers no clear advantage over Xorg while it makes things more complicated (e.g, breaks screen recording) --> Use Xorg instead, or (maybe even better) no X server at all but pure framebuffer (like *ELEC does for media centers). Also see https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
• Pipewire: Solution in search of a problem you don't have without Wayland? (Disputed. If it is really "like Jack if it could configure itself" and has "the ease of use of CoreAudio" then it might well be worth it?)
• XDG Desktop spec: Does not take into account the dynamic nature of applications being able to come and go on removable media, is clearly inferior to LaunchServices on the Mac --> Develop AppImage/appimaged into something that can match Mac System 1 and/or Mac LaunchServices functionality
• Fonts that are metrically compatible to, but make no attempt at being visually similar to, original typefaces. Especially: Fonts designed by Ascender Corporation, particularly Liberation which is a surrogate for Microsoft fonts which are a surrogate for Adobe fonts. We have had to look at those subjectively unaesthetic surrogates for way to long. --> Use fonts visually similar to the original 35 PostScript fonts (such as urw-base35), and/or new original typeface designs not metrically compatible to anything
• Package managers for end-user applications: Those are aimed at "managing the system", whereas everything that is to be managed on our system can be managed in the file manager and/or other GUI elements. --> Use package managers to produce a system image, which is considered immutable for the end user (like on almost every embedded system/software appliance)
• Configuration files, IP addresses: The user should not have to configure anything. --> Use Zeroconf to find devices and services on the network throughout the whole system
• D-Bus: IPC, but complicated. Why do we need XML schema files, why is there sometimes / notation and sometimes ., and so on. IPC is a good thing, but this implementation is too complicated! However, most applications use it, so we may want to provide a basic level of support for it
• Security that restricts what the user or applications can do: If you need this, this is not the system for you. Trying to build in "security" only makes the system much, much more complex, cumbersome, and less fun to use, while the benefit is questionable in many cases. --> Run as root the whole time; or, at the bare minimum, have root-equal rights for the user. Clarification: This is NOT to say that Security in general is not important. It is to say that it needs to be implemented in a way that it doesn't restrict the legitimate user (owner) of the device from truly "owning" the device
• SELinux: Can be traced back to the NSA and makes life more complicated
• polkit: Similar to sudo but much more complicated. https://security.opensuse.org/2024/04/02/kde6-dbus-polkit.html
• URIs for local files: That is what paths are for. We don't need file:/// outside of web browsers, and most applications don't understand it anyway
• Nouveau drivers: Stuttering performance even with the simplest animations, whereas the proprietary Nvidia driver runs nicely
• JACK: It never works without configuration, and only its developers know how to configure it. For example, you need to know arcane technical details like the sampling rate, buffer size, and period for each sound card to get it to work at all. It never works in a plug-and-play fashion. You always have to configure something, and most of the time it doesn't even start. No straightforward documentation. Been that way for over a decade. Not usable for "mere mortals".
• Flatpak: Not manageable by humans, only usable through app stores and package managers. Applications are not in bundles.
• Portals: Useful in the context of sandboxed desktop applications, but if you trust the authors, you don't need sandboxes. We didn't need them the last 4 decades, so we don't need them now. Unnecessary complication.
• meson: A build system in Python that is too fragile and constantly requires something newer than is available. Use CMake instead.
• ninja: A build system in Python that is too fragile and constantly requires something newer than is available. Use CMake instead.
• libadwaita: Worst practice UX in a library. Applications using libadwaita do not work properly outside of the Gnome desktop. Use Qt instead. In general we should try to stay away from stack elements that were made by Linux distributions for use in (certain) Linux distributions first and foremost. While running them on FreeBSD may work (and may even be needed for legacy compatiblity reasons), their widespead use should be avoided.
• Pango, Cairo, PangoCairo: MumboJumbo. Use Qt instead.
• "Reverse DNS" style identifiers: This scheme disadvantages projects that don't have their own domain name, which is costly. Using something like com.github.helloSystem.MyApplication gives undue reference to the service that happens to host the code at the moment.

UX

• Deceptive design patterns
• Online-first design (assuming that being online is the rule)
• "Natural" scrolling: It is the wrong way around. Made by people who don't understand scroll bars. Why would one want to turn the wheel downwards to go up?!
• Touch: The desktop system will be a workstation for productive work, and be entirely mouse-centric. Touch interfaces are for light media consumption, not for productive work
• Gestures: Not suitable for a mouse-centric desktop
• Client side window decorations: Lead to inconsistencies as to how windows look and work. Every window ought to have a title bar that is exactly the same across all windows. The title bar of the window is supposed to say the name of the application or document. Icons (other than close, minimize, maximize) belong below the window's title bar, not inside it.
• Menus hidden behind Hamburger icons: Quantitative usability testing shows that hidden menus (such as hamburger icons) hurt UX metrics: https://www.nngroup.com/articles/hamburger-menus/ --> Use a global menu bar instead.
• Flat Design: We want e.g., buttons look like three-dimensional objects so that it is obvious that they are clickable.
• Dark Mode: What a relief it was to finally have black text on white backgrounds and WYSIWYG on the Mac in 1984 after those green-on-black and amber-on-black screens of the MS-DOS times
• Single click to open: Double clicking shall open folders. Single clickig shall select them. Been that way since 1984. (Single click is an abdomination spilling over from mobile devices. We don't want to water down the desktop experience with mobile phone UX)
• Workspaces: Cryptic and not part of the desktop metaphor. Multiple workspaces are confusing, because Windows can disappear entirely out of sight, to be seen again only when pressing hardly discoverable keys or buttons. (They should be offered as an opt-in feature for advanced power users at best.)
• Caps Lock key: Has been annoying us for way too long (should be disabled by default but possible to re-enable)
• Tiling window managers: Contradicts spatial navigation and direct object manipulation principles. Use stacking window managers instead.
• On-off sliders in place of proper checkboxes

Hardware

• Unfixable hardware using soldered in proprietary parts (e.g., T2 chip, custom NAND; details)

What many of the unwelcome technologies have in common is that they originated in Linux distributions, and are not really optimized for BSD. They may run, but it is still obvious that the original authors were not embracing the Unix philosophy nor BSD. Examples:

• When you run D-Bus on BSD, there is allegedly degraded security (TODO: Find details)
• When you run ALSA on FreeBSD, it says caps.c: Normally all extra capabilities would be dropped now, but that's impossible because PulseAudio was built without capabilities support.

Business models

• Subscriptions (rather than one-off purchases)
• Software as a service (continuously changing software rather than clear versions)

Welcome and unwelcome security

What people often don't realize is that "security", when used by large corporations and vendors, often includes security from (against) the user. Have you ever wondered why it is so complicated to install another operating system image on your phone, or even get an mp3 file off an iPhone, let alone to boot a locked Apple device found in the recycle bin?

Welcome security

Basically any kind of "security" that works to the advantage of the end user (the person sitting in front of the computer)

• Anything that helps with "Datensparsamkeit" (data generation frugailty, with is actually German law); generating only as much metadata as absolutely needed
• Anything that helps against mass surveillance, e.g., the kind that Snowden unveiled
• Anything that helps against tracking users

Unwelcome "security"

Basically any kind of "security" that takes away trust from the end user (the person sitting in front of the computer) and essentially works "against", not for, the end user

• Any "security" that is closed source or based on obscurity, be it in hardware or software
• Any "security" that helps to track/identify individual users
• Any "telemetry" scheme that is not opt-in
• Any "security" that restricts what anyone sitting in front of the personal computer can do
• Any "security" that makes it harder for the end user (the person sitting in front of the personal computer) to run random operating systems, including from USB and network booting (why shouldn't I be able to run another OS on a school-configured computer in my free time?)
• Any "security" that makes it harder for the end user (the person physically possessing the personal computer) to refurbish or repair it
• Any kind of DRM (Digital Rights Management) scheme
• Any kind of "device management"/"policies" scheme that gives central system administrators power over what the end user can or cannot do with his machine
• Any "security" that makes it harder for the end user to see what data is sent and received (worst case: proprietary mobile OS apps where you can't easily inspect which data is flowing due to encryption, certificate pinning, and whatnot)
• Any "security" that requires developers to identify themselves with the vendor of the operating system
• Any "security" that requires the end user (the person sitting in front of the personal computer) to sign in with some online service
• Any "security" that requires an online connection to use, reset, format, reinstall, restore the computer (worst case: computers that require "activation" or that cannot easily be wiped if found in waste for recycling)

Also, any kind of technology that can be used to restrict the freedoms of the owner of a device or the user sitting in front of it (e.g., by allowing only signed software to run), any kind of technology that claims "security" but does so in an undocumented, proprietary way, and any kind of technology that may be used to spy upon users, and any kind of technology that limits the repairability of devices or prevents the swapping of hardware components should be considered evil and be avoided.

• Apple T2 chips (and similar proprietary "black boxes" in "Apple Silicon")
• Microsoft Secure Boot 
• Trusted Platform Module
• Intel Management Engine 
• Intel vPRO 
• Intel Active Management Technology
• AMD Platform Security Processor
• ARM TrustZone
• Intel Software Guard Extensions (Intel SGX) [now defunct but still a pain]
• Microsoft Pluton processor ("The security chip designed for the future of Windows PCs")
• HP printers with "Dynamic Security"

References

• Control != Privacy, safety, security 🤡 by Louis Rossmann