website/content/handbook/rant.md

+++ title = "BaguetteOS, hand book"

paginate_by = 5 +++

Rant about software complexity or why reading a file now requires docker

I wanted to manipulate a YAML file on my Ubuntu, here's my story.

The only thing I needed was to read a YAML file to extract a single field in it, nothing complicated. So, I tried to install yq. I'm on Ubuntu, I use apt.

# apt install yq
No apt package "yq", but there is a snap with that name.
Try "snap install yq"

So, apt doesn't know how to install this application. Fine, this is a developer tool, maybe it is too recent for my kinda old long-term-support OS. Still, this message tells us a couple of things:

1. we know we do not provide all the available tools
   And this is perfectly fine. We may not have every tool packaged at a moment, or available for every OS version.
2. ... but we know how to provide the tool to you anyway
   That part is weird. Why don't you give me the package yourself then, since it will be installed on my machine regardless if someone tested it? Why does another package manager do the job instead of the package manager of my OS?
   Snap seems to be a good substitute to apt, says apt
   Now I have 2 package managers, one for supported applications from my OS and the other by... no matter who, but hey they tell me it's secure and stuff. Great!

OK, now I will use an alternate package manager. Fine.

# snap install yq

I do have yq on my machine now, hooray!

$ yq read shard.yml
22:54:42 main [ERRO] open shard.yml: permission denied

Wait, what? I do have the permissions, it's my own file! Let's check what's the developer has to say...

Snap notes

yq installs with strict confinement in snap, this means it doesn't have direct access to root files.

(Note: I'm not even in root files here.)

To read root files you can:
1. read from standard input
2. use Sponge

(I don't know what sponge is, and I frankly don't want to, I just want to read a stupid file)

3. write in a temporary file

Great.

# snap remove yq
yq removed

What other solution to the problem does the developer explore? Docker.

No.

I won't install an application designed to run virtual machines just to read a file.

Making it complicated to provide a simple application written in a language designed to deploy applications easily is an un-human achievement. Thanks Cthulhu, I guess.

Okay okay, let's try to answer this question: who's to blame here?

• The developer?
  He tried to provide its application for everybody, including people installing applications only through snap and docker. AFAIK, at no point he is responsible for this mess.
• Snap and Docker?
  They respond to simple requests, they have a purpose. Some things were not possible on the different OSs, so they were developed. There was a need behind those.
• The original package manager...
  If there was a way to get my application, it should have been through the OS package manager. Since it wasn't possible, I had to learn how to get the application from non trusted sources with a parasit application running over the very simple binary provided by the developer.

To get the application I downloaded a binary version, compiled statically, directly from the github page. Am I on Windows in the early 00's? Is my package manager still useful?

Another possibility would have been to download the application from the package distribution of the language used. How long has this practice been used? That's just a way of skipping packaging for an OS.

Apparently, it seems okay for developers to provide a Snap package and a Docker image for a simple, statically compiled binary that has no dependencies whatsoever, but not a single OS package.

Maybe, the complexity of OS packaging is way too high. What's sure is that this developer did not seem lazy...

Conclusion: package managers failed us

and that's the only real conclusion we can have here

Package management should be performed by the OS package manager. OSs should be that simple.

But hey, now we have Baguette and, above all, slotting. Give it a try.