RC 0x02 (Research Comments 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?

5/17/2002 Entry

Long time, no updates. Well, lots of news for here.
First, I quit my previous job. I left amicably w/ the company, but I doubt I would ever want to work there again. I have started working again on all of my pet projects. Most notably Fluid, Sasteroids, and the Linux distribution. (Fluid is going to be really Nifty for all of those X people out there.)

Finals are over, and I now have my grades, which means: I GET TO HAVE SOME TIME OFF. It’s about time too. I though I was going to go mad. I’m chillin right now, but I’m also working on a couple new articles(living with Xinerma, and an entire new bunch of SDL tutorials.)

For those that noticed, the past week or so, I’ve had my articles page here instead of the news. Quiet simply, I accidently overwrote this page with a school assignment(topic/etc.. not chosen by myself), sorry to everyone that showed up here and got confused… 😉

2/14/02 Entry

Evil_Messiah has been kind enough to provide the distro with an uber-l1337 background. (I’ll be updating the screenshot on Saturday.) HaX and I have launched mission make Linux usable for real.

Next, I’m busy trying to move these pages over so that they are all dynamically generated. This will not change anything here though. This will allow me to update these pages a bit more regularly.

I’ve started work on an SDL tutorial that will eventually cover all of SDL. The first 3 installments are up right now. I’m currently working on the fourth(alpha blending and color keying).

More distro news. We are currently moving to RPMs and trashing our own system. We’ll be handling the move in what I feel is an interesting and easy to manage way, but we are still doing it. This does NOT mean we are basing our distro off of RedHat or any other – look at SuSe vs. Mandrake. Both use RPMs.

This series of structural changes to the distro, started with my original base-redo, has definatly been for the better, albiet they were all very time consuming, and frustrating. To respond to gcc-3 concerns: yes, gcc3 is by default the default compiler. Yes, it’s possibly to revert to gcc-2.95. This does not mean that everything is compiled with gcc-3, or even most things. Just enough for compatibility, and those items which are stable, secure, and tested with gcc-3 are being compiled. (This means the kernel/glibc aren’t getting 3’d.)

12/11/2001 Entry

Redid this page today. I’ve kept it optimized for us Lynx friends, so don’t complain to me about the lack of pretty graphics, crappy banner ads, and overuse of images. Before this page was a minimal mirror of golgotha source code, textures, music, and not much else. I’ll be posting relevant public updates to the distribution stuff I’m working on here. (Status and such) If you’d like to help – give me a line, my mail is at the bottom of this page. Any major distribution developments that I’m responsible for, and are public info will be posted here. 🙂