1---
2title: "The abysmal state of GNU/Linux and a case against shared object libraries"
3url: the-abysmal-state-of-gnu-linux-and-a-case-against-shared-object-libraries.html
4date: 2024-03-10T21:41:52+01:00
5type: post
6draft: false
7---
8
9## Personal critique
10
11This is in part difficult to write since I have been daily driving
12GNU/Linux for 20 years now, but I think it is necessary to be honest
13about this. How come GNU/Linux is worse than it was 10 years ago? This
14may very well be a subjective opinion, GNU/Linux being better in the past,
15or maybe I am looking at the situation with rose-tinted glasses.
16
17> A full disclaimer, this weekend my system that is pretty vanilla
18just decided to die after an update. And this was not a full version
19upgrade. Just a normal update that I do many times per week.
20
21Sure, we now have [PipeWire](https://www.pipewire.org/) and
22[Wayland](https://wayland.freedesktop.org/). We enjoy many modern
23advances and yet, the practical use for me is worse than it was 10 years
24ago. Now all of a sudden, I can't rely on the system to be stable like
25it was. I don't remember the system bricking after an update, or the
26system becoming laggy after 10 days of uptime. This may be the issue with
27[Fedora](https://fedoraproject.org/), though.
28
29Over the years, I have daily driven many
30distributions. From [Gentoo](https://www.gentoo.org/),
31[Arch](https://archlinux.org/), [Fedora](https://fedoraproject.org/)
32to [Ubuntu](https://www.debian.org/). My best memories were always with
33[Debian](https://www.debian.org/). Just pure Debian always proved to be
34the most stable system. I never had issue or system breaking after an
35update. I can't say the same for Fedora.
36
37From the get-go, I had issues. I have an Nvidia card and even
38booting presented issues on occasion. This never happened on
39other distributions, though they had their problems. Updating the
40system was basically an exercise in gambling. How come an operating
41system that boasts with the stability is so unstable? And this was
42not isolated to my main machine. This also happened on my [X220
43ThinkPad](https://www.cnet.com/reviews/lenovo-thinkpad-x220-review/)
44with Fedora on.
45
46Shared dependencies were a mistake! There, I said it! I understand
47that disk space was limited back then and this was a legitimate
48constraint. But this has given me more grief than any other thing. I am
49all in for [AppImages](https://appimage.org/) or something like that. I
50don't care if these images are 10x bigger. Disk space now is plenty, and
51they solve the issue with "libFlac.8.so is missing" and I have version
5212 installed. Which comes with unnecessary symlinking, downloading of
53older versions and hoping that this will resolve the issue.
54
55Now, the biggest apologist of GNU/Linux will never admit this and
56even saying something is wrong with this is considered a mortal sin. I,
57however, am not concerned with cultist behaviors. This is bullshit! Things
58should be better than 10 years ago, not worse. And I don't care how
59much lipstick you put on this pig. After more than 20 years of using
60Linux as my main system, I think I have earned a badge that gives me
61the right to say the truth.
62
63Regardless of all this, I am still a massive fan. I still think GNU/Linux
64is probably the most unobtrusive operating system, bar none. But the
65complexity has gotten the best of it. It's bloated and too complicated
66at this point. Understandably, you can't have a modern operating system
67that competes with alternatives without sacrificing simplicity. But I
68still think that there is another way.
69
70One of the best aspects of GNU/Linux must be outstanding package manager
71support. Nevertheless, they are essentially solving a problem that should
72have been solved and done with years ago. The number of gymnastics
73that happen in the background for you to install a software is just
74mind-boggling. The dependency graphs are insane. And Snaps and Flatpaks
75tried to solve some of these things, but until a distribution comes out
76that is completely devoid of shared dependencies, we will still live in
77this purgatory.
78
79Let's compare these two distributions when it comes to packages sizes
80and shared object libraries and see how they fair.
81
82## Debian
83
84```ini
85root@debian: cat /etc/os-release
86
87PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
88NAME="Debian GNU/Linux"
89VERSION_ID="12"
90VERSION="12 (bookworm)"
91VERSION_CODENAME=bookworm
92ID=debian
93HOME_URL="https://www.debian.org/"
94SUPPORT_URL="https://www.debian.org/support"
95BUG_REPORT_URL="https://bugs.debian.org/"
96```
97
98### Top 20 packages by size
99
100```sh
101dpkg-query -W --showformat='${Installed-Size}\t${Package}\n' | sort -nr | head -n 20 | awk '{size=$1;unit="KB"; if (size >= 1024) {size=size/1024; unit="MB"}; if (size >= 1024) {size=size/1024; unit="GB"}; printf "%.2f %s\t%s\n", size, unit, $2}'
102```
103
104| Size | Package |
105|-----------|----------------------------|
106| 651.87 MB | libwine |
107| 389.26 MB | linux-image-6.1.0-18-amd64 |
108| 345.76 MB | brave-browser |
109| 323.74 MB | google-chrome-stable |
110| 265.31 MB | llvm-14-dev |
111| 225.76 MB | firefox-esr |
112| 141.77 MB | fluid-soundfont-gm |
113| 114.67 MB | libreoffice-core |
114| 113.41 MB | containerd.io |
115| 112.77 MB | libnvidia-rtcore |
116| 111.92 MB | libllvm15 |
117| 106.56 MB | ibus-data |
118| 104.92 MB | libllvm14 |
119| 99.20 MB | docker-ce |
120| 77.39 MB | docker-buildx-plugin |
121| 72.00 MB | libwebkit2gtk-4.1-0 |
122| 71.93 MB | libwebkit2gtk-4.0-37 |
123| 70.51 MB | libwebkitgtk-6.0-4 |
124| 69.25 MB | nvidia-kernel-dkms |
125| 66.64 MB | gcc-12 |
126
127This is more or less a fresh system that is being used daily for work.
128
129### Number of packages installed
130
131```sh
132dpkg -l | grep '^ii' | wc -l
133
1342217
135```
136
137### Number of shared object libraries on system (*.so)
138
139*Note: Some of them could be symlinks to each other so take this with
140a grain of salt.*
141
142```sh
143find /lib /lib64 /usr/lib /usr/lib64 -follow -type f -name "*.so.*" | wc -l
144
1455156
146```
147
148### Shared objects sorted by size
149
150```sh
151find /lib /lib64 /usr/lib /usr/lib64 -type f -name "*.so.*" -exec du -h {} + | sort -rh | head -n 20
152```
153
154| Size | Package |
155|------|----------------------------------------------------------------|
156| 113M | /usr/lib/x86_64-linux-gnu/libnvidia-rtcore.so.525.147.05 |
157| 112M | /usr/lib/x86_64-linux-gnu/libLLVM-15.so.1 |
158| 105M | /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1 |
159| 70M | /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0.12.8 |
160| 70M | /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.67.8 |
161| 69M | /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4.4.8 |
162| 57M | /usr/lib/llvm-14/lib/libclang-cpp.so.14 |
163| 45M | /usr/lib/x86_64-linux-gnu/libnode.so.108 |
164| 43M | /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.525.147.05 |
165| 41M | /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.525.147.05 |
166| 31M | /usr/lib/x86_64-linux-gnu/libmozjs-102.so.102.15.1 |
167| 30M | /usr/lib/x86_64-linux-gnu/libicudata.so.72.1 |
168| 30M | /usr/lib/x86_64-linux-gnu/libclang-14.so.14.0.6 |
169| 29M | /usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.525.147.05 |
170| 28M | /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1.1.14 |
171| 28M | /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.1.so.0.4.14 |
172| 28M | /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18.23.14 |
173| 24M | /usr/lib/x86_64-linux-gnu/libnvidia-glvkspirv.so.525.147.05 |
174| 23M | /usr/lib/x86_64-linux-gnu/libz3.so.4 |
175| 22M | /usr/lib/x86_64-linux-gnu/libgs.so.10.00 |
176
177## Fedora
178
179```ini
180root@fedora: cat /etc/os-release
181
182NAME="Fedora Linux"
183VERSION="36 (Workstation Edition)"
184ID=fedora
185VERSION_ID=36
186VERSION_CODENAME=""
187PLATFORM_ID="platform:f36"
188PRETTY_NAME="Fedora Linux 36 (Workstation Edition)"
189ANSI_COLOR="0;38;2;60;110;180"
190LOGO=fedora-logo-icon
191CPE_NAME="cpe:/o:fedoraproject:fedora:36"
192HOME_URL="https://fedoraproject.org/"
193DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/"
194SUPPORT_URL="https://ask.fedoraproject.org/"
195BUG_REPORT_URL="https://bugzilla.redhat.com/"
196REDHAT_BUGZILLA_PRODUCT="Fedora"
197REDHAT_BUGZILLA_PRODUCT_VERSION=36
198REDHAT_SUPPORT_PRODUCT="Fedora"
199REDHAT_SUPPORT_PRODUCT_VERSION=36
200PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
201SUPPORT_END=2023-05-16
202VARIANT="Workstation Edition"
203VARIANT_ID=workstation
204```
205
206### Top 20 packages by size
207
208```sh
209rpm -qa --queryformat '%{SIZE}\t%{NAME}\n' | sort -rn | head -n 20 | awk '{size=$1;unit="B"; if (size >= 1024) {size=size/1024; unit="KB"}; if (size >= 1024) {size=size/1024; unit="MB"}; if (size >= 1024) {size=size/1024; unit="GB"}; printf "%.2f %s\t%s\n", size, unit, $2}'
210```
211
212| Size | Package |
213|-----------|------------------------------|
214| 572.91 MB | google-cloud-sdk |
215| 559.76 MB | wine-core |
216| 530.12 MB | wine-core |
217| 383.76 MB | code |
218| 350.98 MB | golang-bin |
219| 318.04 MB | brave-browser |
220| 302.78 MB | google-chrome-stable |
221| 282.24 MB | libreoffice-core |
222| 273.43 MB | firefox |
223| 253.00 MB | ocaml |
224| 223.60 MB | proj-data-us |
225| 219.46 MB | zoom |
226| 217.81 MB | glibc-all-langpacks |
227| 199.31 MB | qemu-user |
228| 196.79 MB | edk2-aarch64 |
229| 194.77 MB | fluid-soundfont-lite-patches |
230| 194.25 MB | java-17-openjdk-headless |
231| 176.75 MB | java-11-openjdk-headless |
232| 156.80 MB | pandoc |
233| 154.82 MB | qt5-qtwebengine |
234
235What is interesting that the most of these packages are from a a system
236that are daily in use.
237
238### Number of packages installed
239
240```sh
241dnf list installed | tail -n +3 | wc -l
242
2433484
244```
245
246### Number of shared object libraries on system (*.so)
247
248*Note: Some of them could be symlinks to each other so take this with
249a grain of salt.*
250
251```sh
252find /lib /lib64 /usr/lib /usr/lib64 -follow -type f -name "*.so.*" | wc -l
253
2548894
255```
256
257### Shared objects sorted by size
258
259```sh
260find /lib /lib64 /usr/lib /usr/lib64 -type f -name "*.so.*" -exec du -h {} + | sort -rh | head -n 20
261```
262
263| Size | Package |
264|------|--------------------------------------------------------------------------------|
265| 128M | /usr/lib64/libQt5WebEngineCore.so.5.15.10 |
266| 55M | /usr/lib64/llvm13/lib/libclang-cpp.so.13 |
267| 53M | /usr/lib64/libclang-cpp.so.14 |
268| 50M | /usr/lib64/libwebkit2gtk-4.0.so.37.57.6 |
269| 49M | /usr/lib64/libnode.so.93 |
270| 45M | /usr/lib64/libOpenImageDenoise.so.1.4.3 |
271| 33M | /usr/lib64/llvm13/lib/libclang.so.13.0.1 |
272| 30M | /usr/lib64/libclang.so.14.0.5 |
273| 29M | /usr/lib64/libopenvdb.so.9.0.0 |
274| 28M | /usr/lib/libicudata.so.69.1 |
275| 28M | /usr/lib64/libmozjs-78.so.0.0.0 |
276| 28M | /usr/lib64/libicudata.so.69.1 |
277| 26M | /usr/lib64/libusd_usd_ms.so.0 |
278| 26M | /usr/lib64/libgdal.so.30.0.3 |
279| 22M | /usr/lib64/libjavascriptcoregtk-4.0.so.18.21.6 |
280| 22M | /usr/lib64/libgs.so.9.56 |
281| 22M | /usr/lib64/google-cloud-sdk/platform/bundledpythonunix/lib/libpython3.9.so.1.0 |
282| 17M | /usr/lib64/libgtkd-3.so.0.9.0 |
283| 17M | /usr/lib64/libgeocoding.so.8.12 |
284| 14M | /usr/lib64/libmfxhw64.so.1.35 |
285
286## Quick observation
287
288```
289/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1.1.14
290/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.1.so.0.4.14
291/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18.23.14
292```
293
294These three packages are probably used by three different applications,
295and nothing else needs them. I could be mistaken, but in any case they
296should just be packaged alongside the application that requires them
297and be done with it.
298
299## So, now what?
300
301The main point is that, yes these packages can be big, but if we are
302honest, what would a couple of additional megabytes that would include
303shared object libraries actually do? Probably nothing! And it would make
304maintenance an entirely different game.
305
306There is also this big elephant in the room, the users. They aren't
307concerned about package dependencies. They don't care if an application
308is 20 megabytes bigger. Nobody cares! But they certainly do care about
309borked systems and non-working dependencies and hunting for solutions
310for why `libFlac` was not found even though they have it installed
311(allthough slightly different version).
312
313Operating systems should abstract these complexities away from the
314user. And I am not saying that the Linux kernel is at fault. I mean the
315operating system as a whole.
316
317This is why I am a massive proponent of
318[AppImages](https://appimage.org/). Flatpaks and Snaps are OK, but they
319still have their own package management and the whole dependency problem
320because they try to optimize for space, and they sacrifice the simplicity.
321
322It would be an interesting exercise to make a prototype distribution
323that does not rely on shared objects, but has everything packed in
324AppImages. Probably a foolish endeavor, but maybe worth looking into. I
325sense this kind of distribution would be highly unusable. Interesting
326how far we have gotten that this kind of distribution is almost not
327possible anymore.
328
329The year of the GNU/Linux desktop? I have strong doubts. We are in a
330worse state than we were. Not only that, but the sheer amount of choice
331is paralyzing at this point. This is very relatable to [The Paradox of
332Choice](https://en.wikipedia.org/wiki/The_Paradox_of_Choice). The
333more options we have, the worse it
334gets. [Wayland](https://wayland.freedesktop.org/) competing with
335[X](https://www.x.org/wiki/). So many window managers, you just get
336lost. So many choices. I have no idea if this is even salvageable,
337or something new must be made.
338
339A quick shoutout to [AppImageHub](https://www.appimagehub.com/). If
340possible, I continually try to find applications there and take care of
341updating them myself. I don't need hand holding or a constant up-to date
342system. I just want my system to be stable and when some application has
343gotten some significant new features I can download that myself. It's
344about the choice and not being forced into this churn that requires
345constant updating and keeping up with things. At this point, using
346GNU/Linux is more like a second job, and I was so stoked when this was
347not a case anymore in the past. This is why I feel like the last 10
348years were a regression disguised as progress.
349
350Some interesting talks and videos
351
352- [Jonathan Blow on how an operating system should work](https://www.youtube.com/watch?v=k0uE_chSnV8)
353- [The Thirty Million Line Problem by Casey Muratori](https://www.youtube.com/watch?v=kZRE7HIO3vk)
354- [GNU is Bloated! by Luke Smith](https://www.youtube.com/watch?v=nTCHapo8QFM)