I lied when I said I intended to release a blog post along my releases. Let me make it right.

I have a lot of PSP UMD games. When I back them up on my computer, I back them up as CSO images which are registered as "application/x-compressed-iso" in XDG's MIME database. They don't compress as much as CHDs but they run on real hardware so I decided to use them.

Most Linux desktop environments (except KDE which has its own thing) use GNOME's thumbnailer standard. I decided I wanted some flair to my disc backups so I ended up writing a CSO thumbnailer. According to the timestamps in the release of cso-thumbnailer, I wrote it in May of 2022 and released it in February of 2024. It took about two years to release it simply because I code dirty so it took me a lot to get around to clean the source code of it up. This blog post was written in April of 2025. That's a lot of procrastination. I need to do better.

Let's start by running some sanity checks on the input file. We'll check whether the file is not too small, whether it starts with the format's magic bytes and whether its header is corrupt.

#define CISO_MAGIC 0x4F534943 // "CISO"
#define ZISO_MAGIC 0x4F53495A // "ZISO"
unsigned char header_pvd[6] = {0x01, 0x43, 0x44, 0x30, 0x30, 0x31}; // 0x01 + "CD001"

ptr_input = fopen(argv[1], "r");
if (ptr_input == NULL) error_and_exit("Error opening input file\n");
fseek(ptr_input, 0L, SEEK_END);
uint64_t size_file = ftell(ptr_input);
rewind(ptr_input);
if(size_file < 32) error_and_exit("Input file too small to be valid\n");

unsigned char header_cso[0x18];
fread(header_cso, 1, sizeof(header_cso), ptr_input);	
magic = header_cso[0x0] + (header_cso[0x1] << 8) + (header_cso[0x2] << 16) + (header_cso[0x3] << 24); 
if(magic != CISO_MAGIC && magic != ZISO_MAGIC) error_and_exit("File couldn't be identified as CISO or ZISO\n");

uint64_t size_uncompressed = 0; 
for(int i = 7; i >= 0; --i) { 
	size_uncompressed <<= 8; 
	size_uncompressed |= (uint64_t)header_cso[0x8 + i]; 
}
size_block = header_cso[0x10] + (header_cso[0x11] << 8) + (header_cso[0x12] << 16) + (header_cso[0x13] << 24);
int version = header_cso[0x14];
alignment_index = header_cso[0x15];
if((magic == ZISO_MAGIC && version != 1) || !size_uncompressed || !size_block) error_and_exit("Corrupt header in specified ZISO file\n");

The file we want to extract is named "ICON0.PNG". While every official release I backed up have the image file at the exact same location on the disc, I also have some games I applied translation patches to which have the image file at different locations. To avoid decompressing the entire disc image to extract a single image file, we can locate the image file's location from the disc image's table of contents section.

#define MB64_IN_BYTES 64 * 1024 * 1024
unsigned char record_icon0[10] = {0x09, 0x49, 0x43, 0x4F, 0x4E, 0x30, 0x2E, 0x50, 0x4E, 0x47}; // 0x09 + "ICON0.PNG"

int total_block = floor(size_uncompressed / size_block);
int limit64mb_block = floor(MB64_IN_BYTES / size_block);
if(total_block > limit64mb_block) total_block = limit64mb_block; // First 64MB should be enough to get the location of the file, we can decrypt more if needed later
int size_index = (total_block + 1) * sizeof(uint32_t);

buffer_index = calloc(1, size_index);
buffer_output = calloc(1, size_block);
buffer_input = calloc(1, size_block * 2);
file_iso = (int*) calloc(1, size_uncompressed * sizeof(int));
if(!buffer_index || !buffer_output || !buffer_input || !file_iso) error_and_exit("Couldn't allocate enough memory\n");
fread(buffer_index, 1, size_index, ptr_input);
decompress(total_block);
	
uint64_t *location_pvd = memmem(file_iso, size_uncompressed * sizeof(int), header_pvd, sizeof(header_pvd));
unsigned char pvd[2048] = {0};
unsigned char magic_iso[8] = {0};
unsigned char first18bytes[18] = {0};
memcpy(&pvd, location_pvd, 2048);
		
uint64_t *location_record_icon0_name = memmem(file_iso, size_uncompressed * sizeof(int), record_icon0, sizeof(record_icon0));
uint64_t *location_record_icon0 = location_record_icon0_name - 4;
memcpy(&first18bytes, location_record_icon0, 18);
int location = first18bytes[2] + (first18bytes[3] << 8) + (first18bytes[4] << 16) + (first18bytes[5] << 24);
location = location * size_block;
int size = first18bytes[10] + (first18bytes[11] << 8) + (first18bytes[12] << 16) + (first18bytes[13] << 24);

While we're at it, let's check whether we can confirm that the disc image is really a PSP UMD disc backup somewhere around here.

unsigned char magic_psp[8] = {0x50, 0x53, 0x50, 0x20, 0x47, 0x41, 0x4D, 0x45}; // "PSP GAME"

for(int i = 0; i < 8; i++) magic_iso[i] = pvd[8 + i];
for(int i = 0; i < 8; i++) if(magic_iso[i] != magic_psp[i]) error_and_exit("File couldn't be identified as PSP ISO\n");

Now that we know for sure that we're dealing with a PSP UMD disc backup and where its "ICON0.PNG" file is located, we can selectively decompress its location and extract it without decompressing the entire image.

if((location + size + (2048 * 8)) > MB64_IN_BYTES) {
	free(buffer_index);
	free(file_iso);
	
	total_block = floor((location + size + (2048 * 8)) / size_block);
	size_index = (total_block + 1) * sizeof(uint32_t);
	
	memset(buffer_output, 0, size_block);
	memset(buffer_input, 0, size_block * 2);
	buffer_index = calloc(1, size_index);
	file_iso = (int*) calloc(1, (location + size + (2048 * 8)) * sizeof(int));

	if(!buffer_index || !buffer_output || !buffer_input || !file_iso) error_and_exit("Couldn't allocate enough memory\n");
	fread(header_cso, 1, sizeof(header_cso), ptr_input);
	fread(buffer_index, 1, size_index, ptr_input);
	decompress(total_block);
}

memcpy(png, (file_iso + (location / sizeof(int))), size);

Congratulations to us as we have just extracted a file from another file. Write the boilerplate for the thumbnailer standard and you have a thumbnailer in your hands.

Writing a thumbnailer is easy and fun. Why don't we have a lot more of them?

Does your hardware get twice as fast every two years? It does not! I believe that Moore's Law, while historically and industrially important as a metric, is little use for everyday consumers. Hardware gets faster in periodic bursts as it is upgraded or replaced. Software inefficiency on the other hand keeps growing at a consistent rate. May's Law, a Wirth's Law variation, is therefore incorrect. Growing software inefficiency does not compensate Moore's Law; in the real world, excluding a brief post hardware upgrade period, it overshadows it! This phenomenon creates an illusion that devices get slower with time when they do not. Well, maybe. More on this later.

The phenomenon Wirth's Law describes is a necessity! To explain the reasoning behind this thought, I thought up two possible reasons software gets more inefficient by the day:

• More lenient coding practices
• Abstractions

To understand both points better, please visualize a single-axis spectrum in your head with "ease of development" on the left side and "optimized code" on the right side.

More lenient coding practices are trade-offs that trade optimization for ease of development. How far away from the right side of the spectrum varies from case to case.

Abstractions on the other hand are placed on the furthest edge of the left side in the spectrum. That is not to say they are useless! Abstractions are necessary evils that come into being by valid reasons such as maintaining backwards compatibility, easing cross platform development to the point they're now possible in feasible time frames, reducing repeated code and eliminating divided codebases. In fact, I'm actually quite fond of abstractions! Any developer that has ever worked on a cross-platform project before will sing abstractions' praises and having worked on projects like that, I too think they're invaluable. Of course, in an ideal world, I'd be singing Progresive Web Apps' praises but that ship has already sailed. One can't always get what they want as the world is built on compromises and this is the one we ended up with. The fact however remains that abstractions, no matter how necessary or useful they may be, add onto the already complex software stack that is quasi-necessary today to feasibly develop, resulting in inefficiency.

The inefficiency caused by these two reasons are expected to be negated by Moore's Law.

My friends complain about my blog posts being walls of text so I made the following graph as a visual aid to explain my thinking better:

The very simplified graph above assumes the following:

• Performance effects caused by silicon/transistor aging are within the margin of error and therefore negligible.
• Software inefficiency and computing power grow at similar speeds within the margin of error. (They do not!)
• There are no power throttling measures in place. Some battery-powered devices nowadays use power throttling measures based on battery statistics such as remaining battery capacity in order to maintain a stable battery time throughout the devices' lifetime. There is also temperature related power throttling to consider as many chips nowadays throttle themselves when they measure above ideal temperatures in order to protect their own integrity.

I have spent a month asking around and browsing to find a name for this phenomenon but my efforts were unfortunately in vain. If there is a name for it that I am unaware of, feel free to contact me using the e-mail address in this site's footer. Until then, I am taking this opportunity to not so humbly call it "Sateallia's Law".

It goes something like this: Hardware relies on periodic updates to catch up with the growing needs of ever more inefficient software, resulting in an unstable performance timeline graph.

The mere thought of the amount of energy waste caused by computers running precompiled binaries not optimized for processors they run on keeps me up at night. There needs to be a better solution than just compiling on-site.

Potential Solutions

I see two problems each with two potential solutions here:

How many build choices will we supply?

1. For every optimization level combination possible.
2. Only for Processor Suppliment ABIs.

In an ideal world we would have choices for each optimization level combination possible but in the real world it's just not practically viable. Arch Linux merged a RFC to provide x86-64-v3 feature level builds that also talks about problems that will be encountered while working on it in April 2021. The efforts to make the RFC a reality are still ongoing.

How will the optimized code be loaded?

1. Every build will be compiled per optimization level and be provided as a different download.
2. The main application will be compiled normally but the processor intensive part will be compiled optimized per optimization level and stored in different shared objects.

Let's do an experiment to see how hard the second option would be.

The Experiment

I'll create a basic function to export later. Let's call this file libshared.c for future referring.

#include <stdio.h>
#include <math.h>
 
int fun_had(int in1) {
    int ret = in1;
    ret = ret * ret - 1;
    ret = pow(ret, 2);
    return ret;
}

In the build script I'll build libshared.c in both unoptimized and optimized forms, then convert both builds into shared objects. Let's call this file build.sh for future referring.

rm -r libsharednormal.o libsharedoptimized.o a.out binary libsharednormal.so libsharedoptimized.so 2>/dev/null

gcc -c -Wall -Werror -fpic libshared.c -o libsharednormal.o
gcc -c -Wall -Werror -fpic -march=native -mtune=native -O3 libshared.c -o libsharedoptimized.o

echo $(md5sum libsharednormal.o)
echo $(md5sum libsharedoptimized.o)

gcc -shared -o libsharednormal.so libsharednormal.o -lm
gcc -shared -o libsharedoptimized.so libsharedoptimized.o -lm

rm -r libsharednormal.o
rm -r libsharedoptimized.o

gcc -Wall -O0 -o binary main.c # build the binary normally, no optimizations

I'll start building our main program to call the shared objects from. Let's call this file main.c for future referring.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dlfcn.h>
#include <sys/time.h>

int (*fun_had)(int); // declaring a prototype before the actual function is loaded
struct timeval start, stop;

int main(int argc, char *argv[]) {
    if(argc < 2) return -1;
    int num = strtol(argv[1], NULL, 10); // argv[1] is now stored in num
    
    char toLoad[256] = "";
    __builtin_cpu_init();
    if(__builtin_cpu_supports("avx2")) strcat(toLoad, "./libsharedoptimized.so");
    else strcat(toLoad, "./libsharednormal.so");
    printf("\nlib to load: %s\n", toLoad);
    
    void *handler_dl = dlopen(toLoad, RTLD_NOW);
    if(!handler_dl) { 
        printf("dlopen error: %s\n", dlerror()); 
        return -1; 
    }
    fun_had = dlsym(handler_dl, "fun_had"); // the actual function is now loaded
	
    gettimeofday(&start, NULL);
    int final = 0;
    for(int i = 0; i < 100000; i++) final = fun_had(num);
    printf("%i\n", final);
    gettimeofday(&stop, NULL);
    printf("function took %lu us\n", (stop.tv_sec - start.tv_sec) * 1000000 + stop.tv_usec - start.tv_usec);
    dlclose(handler_dl);
    
    printf("\n");
    printf("loading unoptimized function for testing purposes\n");
    handler_dl = dlopen("./libsharednormal.so", RTLD_NOW); // let's load the unoptimized function for testing
    if(!handler_dl) { 
        printf("dlopen error: %s\n", dlerror()); 
        return -1; 
    }
    fun_had = dlsym(handler_dl, "fun_had");
	
    gettimeofday(&start, NULL);
    int final2 = 0;
    for(int i = 0; i < 100000; i++) final2 = fun_had(num);
    printf("%i\n", final2);
    gettimeofday(&stop, NULL);
    printf("function took %lu us\n", (stop.tv_sec - start.tv_sec) * 1000000 + stop.tv_usec - start.tv_usec);
    dlclose(handler_dl);
    
    return 0;
}

Most of this code is testing boilerplate so some explanation might be necessary here.

I'll go over the shared object loading first:

#include <dlfcn.h>
int (*fun_had)(int);

void *handler_dl = dlopen("./libshared.so", RTLD_NOW);
if(!handler_dl) { 
    printf("dlopen error: %s\n", dlerror()); 
    return -1; 
}
fun_had = dlsym(handler_dl, "fun_had");

This snippet here will create a prototype, open the shared object file and then finally point our prototype to the function exported from the shared library.

To feed to the above snippet, I also need to pick which shared library we need to load:

char toLoad[256] = "";
__builtin_cpu_init();
if(__builtin_cpu_supports("avx2")) strcat(toLoad, "./libsharedoptimized.so");
else strcat(toLoad, "./libsharednormal.so");

For testing purposes I used __builtin_cpu_supports to pick between them and used supporting AVX2 as a distinction. There are many other ways to do this including probing /proc/cpuinfo but for simplicity's sake I'll go with this.

Finally, I need to call the function. For testing purposes, I'll also measure the time it takes to call the function.

#include <sys/time.h>
struct timeval start, stop;

gettimeofday(&start, NULL);
int final = 0;
for(int i = 0; i < 100000; i++) final = fun_had(num);
printf("%i\n", final);
gettimeofday(&stop, NULL);
printf("function took %lu us\n", (stop.tv_sec - start.tv_sec) * 1000000 + stop.tv_usec - start.tv_usec);

Now I'll try running it.

$ ./build.sh && ./binary 59
84f6ada061366dc244fb474c5ba50347 libsharednormal.o
83851c036b3a04d53ff016e2cca48cad libsharedoptimized.o

lib to load: ./libsharedoptimized.so
12110400
function took 182 us

loading unoptimized function for testing purposes
12110400
function took 1901 us

This is not practical, at all! The runtime feature level detection code would evolve into spaghetti if we were to use it for real.

For more practical purposes I envision a library that takes care of all of this including mechanisms for building objects for every CPU feature level combination desired and picking between them at runtime.

Steps Already Taken

GNU C Library has something very similar! They call it glibc-hwcaps and it's very cool! Unfortunately I'm of the opinion that C libraries should be POSIX only and stuff like this should be handled at compilation or at runtime via libraries. In fact, GNU C Library uses tunables to do something similar internally already. Take a look at its ifunc-impl-list.c for some examples.
You may also be interested in reading about ARM64 ELF hwcaps and POWERPC ELF hwcaps.

On the compiler side of things, GCC has had x86-64-vX feature level support since October 2020. I do not use or follow other compilers so I will not be able to comment on them.

Likewise, there may be other efforts on the distribution side of things but I will not be able to comment on them as I don't use or follow them.

Future looks bright!

I think it's safe to say that the internet has become a "quasi-necessity" today. That is to say while it is not necessarily a "necessity", it is definitely not a "luxury" either. Banking, instant messaging, geo-locating and routing, governmental applications... While the question whether internet access is going to be a human right or not is a good debate topic, that's not what I'm going to rant about today.

Middlemen

Imagine a world where it is impossible to be a functioning member of the society without an internet connection. Not like today where it's practically improbable, think actually impossible. You can't buy a house that doesn't come connected to a remote smart housing server. You can't pay your taxes without internet access. You can't do your banking, you can't even open a savings account without internet. It's all digital.

Let's look at a few examples of how it would go:

Mobile Applications

There are a few features that I currently have to use my bank's mobile application for:

• Depositing/withdrawal using QR codes
• Contactless payments using the phone
• Applying for offers and promotions
• Opening a branch-free banking account

While I don't mind them being application exclusive features, there is one thing I do mind: the method I have to obtain the app. I have to obtain it through my operating system vendor's application store, meaning that to do banking with my bank, I also need to enter a contract with my OS vendor.

Since I can't just rant about drawbacks without also suggesting, let's also take a look at a few potential solutions:

F-Droid/Linux style distribution

In an ideal world, I would be able to have a store client that retrieves application packages from decentralized servers that all talk the same protocol. While this is already the reality within the open source community (e.g. F-Droid, Linux package managers as per the topic header); this is simply, practically infeasible for real world applications. Why?

• Lack of security within such package manager systems, especially considering the high security needs of applications that deal with things such as banking or governmental processes, would be inexcusable. Consider that even today when they're relatively niche, there have been malicious/bad PPAs or AUR scripts (doesn't necessarily have to be intentional). If you have enough users, some of them are guaranteed to make typos or find malicious links!
• Technical skills needed to operate such package managers. Probably the biggest reason this approach wouldn't work.

Making each repository its own application wouldn't work either since then you either have to:

• Register with that repository's owner, shifting the problem
• If you're maintaining your own repository, get users to sideload your app.

Sideloading

While the term "sideload" implies a danger of intrusion that is not merited, that is the least of our worries here. Most instant messaging apps I use (even the proprietary ones) do provide direct package downloads for my mobile OS. I do appreciate that. While the same arguments of the previous model applies here but there is also one another thing to consider with this method: server connections.

There are currently two methods to achieve push notifications to a mobile applications:

• Always on server connection that is handled by the application. Requires your app to always run in the background. Certainly not the most battery efficient (considering the lack of optimization brought with "sprints" nowadays) so very much discouraged, even at OS level nowadays.
• Centralized vendor provided connections. The norm nowadays. The device only needs to maintain one connection to a main server and all notifications are routed through that path.

Do you see the issue here?

Internet of Things / Smart Homes

There are many, many, many examples of a vendor going out of business or deprecating an IoT device making them essentially paper weight. Locally hosted IoT is not a solution either considering then you either lose the ability to contact the device from outside of the local network or essentially expect your users to be system administrators.

Dependency on Transportation

As human population grew and expanded throughout the planet, an industry for transportation of goods emerged. That is fine. That is acceptable. What isn't is the dependency on these things. A society needs to be able to self-sufficient. Transported goods should only be pleasant bonuses. Fortunately for me, I don't need to theorize examples for this topic as it has already happened in history more than enough times (e.g. 2021 Suez Canal obstruction).

History of Middlemen

Historically, lumber and coal companies used to pay their employees with "company scrips", issued by them and only accepted in company stores owned by them. While this was historically solved in United Kingdom with the "Truck Acts", it took until 1938 for the United States to solve this problem with the "Fair Labor Standards Act of 1938". The problem of middlemen isn't anything new, it just keeps reappearing with every new unregulated industry.

The Problem of Middlemen

Vendors do go out of business. Devices do become obsolete. It is simply foolish to depend on a vendor to provide you lifelong service. Look at Internet of Shit when you're bored. Why are we as a society progressing towards solely relying on vendors to distribute our software? There needs to be a better way that doesn't compromise security or require developers to register with distributors. I'll think about it.

UPDATE (5 Oct 2022): I did at first consider default pre-trusted repositories as F-Droid comes with a few of its own and the model seems to work fine for operating systems for providing root certificates (even though it historically was abused a few times by both manufacturers and trusted developers on the pre-trusted repositories). This solution, however, does not scale. At all.

Have you ever seen one of those "Install This App at X Store" kind of banners? In fact, F-Droid has something very similar! I think this could work! This however does not solve the security aspect of this model as now you have to make sure your users are finding your site to discover your repository links and not anything malicious instead.

After releasing resistormaid, all the friends I showed it had the exact same question: "No one made this before? Surely someone made this before." That is the logical answer. It's just a commandline resistor calculator, there is exactly zero percent of chance no one made it before. And I had the same answer every time as well: "Well, let's look for one together." Every time, we find nothing. Which begs the question... Why can't I find one? There exist websites or apps that do this sure, but surely someone made this before the internet era.

Then one of my friends jokingly said, "I feel like there is no way someone didn't do some resistor CLI app though... It's probably called something that doesn't make sense or some obscure dated joke".

"That's what READMEs are for!" I hear you say. Unfortunately, it's not that simple. Even if the solution to this in the software industry is that simple, this problem isn't only relevant there.

It applies to all media

The time a content is consumed and the time it's produced don't necessarily have to be close.

How many times have you read a classic book that didn't require you to pull out your phone or read a wall of text by the translator/editor to understand what obscure fact they were referencing in a one-liner? Many of them are practically unreadable because of this problem. How many times have you seen a new meme in a brand new video game? Big production media go through months if not years of approvals, producing, revisals, polish so by the time you get to play it, the meme's long dead. How many times have you watched an old movie and laughed at the decades old political joke?

One should not rely on the audience to have the same experiences as the author. It is important to appeal to the lowest denominator that is the human nature if you want the content to survive. In-jokes, political commentary, knowledge on a subject, humoral memes, pop culture references; these will only narrow the audience. Not in the sense of the immediate audience, no. Think human history. Think descendants. Think broader.

Let's look at Moby Dick for example. At its surface, it's an adventure thriller making it enjoyable by the common man. At its core, it's a complex take and commentary on human nature and ego. Herman Melville (shamefully) died penniless! Only years after his death did it gained the attention it deserved as people started delayering the onion and saw it for what it is. Even if no one hunts whales nowadays, it's still enjoyable.

Immortality through Writing

Like how a chain is as strong as its weakest link, a content is as relevant as its most dated part. Relying on a passing reference to pull a content together is sabotaging its lifespan. It is, in a sense, trading immortality to viral marketing. Such content will be forgotten to time, not being able to get its points across. The experiences the artist's trying to share will be forgotten to time and events that would be avoided by their wisdom will be repeated. Therefore, the artist should avoid relying on passing things to elaborate on their points if they wish to make their writings last.

Mortality through Writing

Mind you, I'm not refusing the worth of passing elements. There is need for short-term lifespanned or specifically targeted content. That's fine as long the content is supposed to be short-term lifespanned or specifically targeted.

Remember how I said "It is important to appeal to the lowest denominator that is the human nature if you want the content to survive." before? That's the big if.

Conclusion

Writing balanced for both the current and the upcoming eras is hard. I don't exactly have a solution to this. I'm sorry. I also apologize for the whimsical writing. I realize my sentences keep swinging from subject to subject.

How many of you would recognize the last paragraph as a theatre play reference? I will doubt any percentage that's higher than 5%. That's exactly the point I'm trying to get across.

Also, don't take this post too seriously. I'm just emptying my mind here.