RC 0x02: Linux Packages

Over lunch, my brain is popping up questions of back-burnered personal tasks. The peril of a software development career is continuous return to build systems, packaging, and best practices for distributing software. Over the years, I’ve seen and maintained a number of Linux packages, build systems, embedded distributions, and containers.

With the newer releases of Ubuntu, Canonical has been heavily pushing their “snap” standard – which, as a user, I find less than desirable. The big complaint is weird breakage on basic things – like clicking a link in another application opening in a new browser instance (and worse, without my privacy extensions enabled!).

In my toy distribution, I really wanted to take an approach of absolute minimalism and experiment with containerized setup of applications – up to and including the base system layer.

In the windows world, applications tend to rely on a system installed C runtime (Visual Studio Redistributable) and media library (DirectX). This system provides a strong “base layer” but the application then must ship all the other libraries or static link them to the executable. While I fault Microsoft with many things, the reality is that their approach to system backward compatibility and best practices for shipping apps has resulted in easy installation of programs from 10+ years ago. Indeed, today I have software from even earlier (early 2000s) that installs today and works on Windows. The same can not be easily said for Linux.

I believe Flatpak to be superior from my user experience point of view – but the standard is not as well supported by major players, and integration is “subpar”. Moreso, flatpak seems to have a very GNOME/desktop centric focus.

I’m hoping that the base levels of flatpak can provide a solid foundation. My main hangup at present is that the technology feels a bit limited when attempting to gather dependencies for a C/C++ application that don’t fit within the general idea of the system SDK. The “dependency soup” managed by RPM and DPKG very quickly appears and becomes difficult to manage without a nice / proper system root. From a management aspect- I really am hoping for some sort of system that provides extensive configuration and artifact management to insure complete reproducability of system configurations.

I’m hopeful that something like Yocto could provide a means around this, but I’m not sure I’m feeling it. I’m starting to consider some sort of new middle-ware layer necessary, but there’s not an amount of development effort I’d like to spend there.

Going forward, the big questions are – is flatpak suitable for building a distribution? How can we ‘cleanup’ the dependency soup requirements for building packages?

RC 0x01: Modelling Text

I’ve found my growing collection of “Note.txt” files floating around in random directories to be an unbearable way of keeping notes. I’ve debated moving those into some sort of Wiki form – but at present, I’ve decided to move documents to this blog in the hopes that others might find them useful. I’ll be labelling these posts as “Research Comments” and numbering them in publish order for my own reference. These documents are not intended to be academic or authoritative in nature – they are research notes collected with links to other documents.

As I type into the new fancy “block based” wordpress editor, I’m reminded of the complexity of HTML vs the simplicity of a simple text block control. WordPress enables fancier things in blocks, but for a long time (and multiple purposes) simple text blocks where all we had.

I’m not so sure that the box layout model of CSS is really the “best” thing when it comes to the idea of supporting simple text layout – and it definitely was not intended (originally) to compete with advanced manual typesetting that might be done by a Publisher. Still, today’s graphics artists are forced to utilize a system developed by 90s era nerds without much concern of the needs of the typesetting industry.

For forum software, this presents a unique set of challenges in that we want the ability to include a substantial number of tags and at the same time limit the feature set to preserve the overall representation of the page. Early social media giant “MySpace” provided minimal filtering allowing teenagers to customize their pages to extreme levels – at times completely replacing significant elements of the MySpace UI. Unfortunately, not much is left of the ‘old web’ to point to, but it does make for some fun discussions on current forums.

We can group approaches utilized by social networks into several major camps. Facebook and Twitter provide “text only” modelling with the addition of meta data to allow a degree of enhancement (eg: link detection, post backgrounds in FB, ‘moods’, and attached images). This model allows substantially simplified user interface (no need to deal with formatting shortcuts) – but at the cost of the user’s ability to represent more complicated text with inline Linux. The second camp utilized by major web forums allows text via some other markup language with limited functionality (eg: BBCode). The translation from this syntax into HTML removes the need for detection of error codes and extended cases that may be problematic if utilizing HTML directly. Finally, the rare case is a system that allows direct HTML / CSS with (hopefully!) filtering.

One of the more interesting ideas I’ve seen is utilization of TeX under the hood for allowing better document markup potential than HTML. While working on complex documents with extensive sourcing – the tooling TeX provides is fairly invaluable. The resultant TeX documents also tend to “look” fairly decent as well – so long as one is careful to utilize modern features and fonts when creating finished documents.

For word processor / document based formats – multiple major techniques appear to exist. Confluence utilizes a subset of HTML intended to allow better “flow” of document text. This subset includes additions for elements such as images and tables. The table model itself allows nesting, but does not allow control of text flow around the table itself (the table is treated as a breaking paragraph). Historically, Word has hidden underlying makeup of documents from users as much as possible, but WordPerfect provides detailed commentary as to the internal “codes” used for document markup. Adobe FrameMaker text bares a degree similarity to HTML, but is likely better compared to TeX in operation.

Distro Thoughts #1

So, after some consideration, I’ve decided to resurrect my previous efforts at building a Linux distribution. Mostly – because I’d like to tinker with a light-weight Linux that’s easily customizable. Something that really goes “back to basics”.

My first experiments were attempting to bootstrap a Clang/Musl build variant. Ugh!

My initial environment was Ubuntu 18.04 – with a modern C++ toolchain. I thought it’d be easy to populate a chroot environment, especially without cross compiling required. The LLVM code looks generally pretty clean – big, it does a lot, but clean. The build system though? See my previous comments on build system messes. The ‘one repo’ approach assumes a rather complete environment and does not bootstrap well to a new rootfs. I thought a hacky compile from source build would be neat – but this does not seem doable.

Too much time spent on this today, time to go outside and enjoy the sun.

Package Design Update

Wow. I’ve started getting emails/etc.. from people interested in the distro, mainly with the single question: WHERE IS IT? Just like that, the caps, bold – everything.

So here is a bit of a status update. HaX took a much needed vacation after I made him package GNOME – alone. His hair should start growing back pretty soon, and the doctors tell me the stroke did no permanent damage. While he was off, I did a foolish thing, and mangled just about all of base. Like I said before, it’s basically a completely new distro.

Some of my personal goals for this distro have changed. For one, I still want the end-user usability that would put Mandrake to shame – but unlike Mandrake, I would like to remain true to the sources that made Linux – and Unix – what they are in the first place. Some Linux distributions seem to forget about the advanced end user’s expectations. Others provide administration utilties that carelessly write over hand edited configuration files. This has greatly changed my entire approach at packaging the base system, and that is what a lot of the “base” redo reflected. That said, there is no reason why such a base, developed correctly, can not be used to build something easy to use for the end user.

Currently, beta testing is open to advanced linux users only, advanced linux users being defined as people that don’t mind hand editing config files when things go wrong. As everything is still in development things WILL go wrong.

HaX is currently working on packaging a new X, and I am putting the finishing touches on base – and trying to get the REAL installer (Beta users currently use a make-shift temporary one) ready for Prime Time. 🙂

Typity Typity Typity

Yet another day of mindless distro hacking. QT 3.0.1 was released today. Nifty. So far, LSB progressions have been pretty good, and QT 3.0.1 compiled without a hitch. Given the current status of KDE development, I’m going to start migrating all the packages to KDE-3. Now, the good news: the major portions of the base redo are done. This means that another beta is getting a lot closer.

Edit:

Sometime past 11:00

DO NOT EAT AT MCDONALD’S. They are the Satan of this world. Part of the great head of evil. Yes fokes, today I have experienced the wonders of the Big XTra, little did I know that the Extra was a wonderful bit of food poisoning. Having had all sorts of nasty stuff in the past, I think that this is the worst I have ever felt, in my life ever. There is no escaping from the pain that is the golden arches – in either end. Now, excuse me as I puke up my guts, again.