Historically, we have been good at choosing right tool for the job:
homestead
| vs | commercial |
| fishing
| |
| grass cutting
| |
| shape adjustment
| |
In the examples above at least three factors stand out: cost of acquisition, cost of maintenance and operational complexity. While choosing tools for home, I prefer those with maximum ease of use, and in many cases I save for months or even years to get the desired one.
However this approach does not hold in computer engineering - the prevalent trend seems to be:
the bigger, costlier, complexier - the better
We can use LOC (lines of code) as a measurement of complexity and see how everyday software fare:
| lines of code
| reference
|
Windows | 50 000 000 | [4]
|
Linux kernel
| 27 800 000
| [2]
|
Firefox | 21 000 000
| [7] |
Docker | 10 000 000
| [8]
|
Libre Office
| 9 500 000
| [3]
|
Kubernetes | 1 510 000
| [9]
|
Gnome | 945 000
| [6] |
OpenShot | 715 000
| [5]
|
VLC | 685 000
| [10] |
Kafka | 470 000
| [13]
|
Krusader | 57 000
| [11] |
But why should we complain if software works, and works well? After-all, not many people can work on their cars. Selected few can change oil or brake pads, and everything else is so computerized and specialized that requires a certified mechanic.
This is exactly the problem I believe we should avoid in computer engineering. Creative part of our community was founded on four essential freedoms: (0) to run the program, (1) to study and change the program in source code form, (2) to redistribute exact copies, and (3) to distribute modified versions [12].
However the sheer size of modern software strikethru this philosophy, as only standing teams could master anything above 500K LOC. That effectively aligns most large projects with corporate interest. The larger the source code base, the more important is the corporate support, the less it is tinker-friendly.
The Linux community:
A corporate controlled committee of people
who don't use Linux and dislike ideas
Bryan Lunduke [19]
Don't get me wrong - it is great that Kafka or Linux are open source software. However I have serious doubts whether homed or self-balancing brokers aid personal use.
Should we perhaps triage existing open source software projects and label them accordingly to their complexity and intended use: corp-only, home-friendly and tinker-friendly? And if in the process we classify existing Linux Kernel as corp-only, should we then look to develop home-friendly open source operating system?
Let's take this thought a step further - given current hardware trends, we can expect two 16 core servers per homestead at the turn of the decade. Do we really expect people to learn Kubernetes to utilize all this hardware? Let's just enumerate required concepts to use the latter: deployment, replica-set, pod, label, rolling update, health check, environmental variables, secrets, resource management, horizontal pod autoscaler, namespace, service, ingress, annotations, persistent volumes, jobs, config map, etc. Security is extra.
That is on top of: computer science data structures & algorithms, file system, memory tables, CPU interrupts, network & protocols & routing, programming languages, compilers, GUI.
De-facto we require an engineer to master two types of operating systems: single-node and multi-node before even conceiving something fun!
Note - business skills, such as data processing, statistics or deep learning, is packaged and sold separately.
No one knows the whole kernel
Linus Torvalds [1]
It is overwhelming for the current generation of engineers, many of whom have learned basics tinkering Comodores, Ataris or ZX Spectrums (whose Basic had 88 keywords [18], of which I probably used 40). But how surmountable is it for the next generation, born to touchscreen and "cloud"? Good approximation could be that Google with 2 billion lines of code [15] has arguably not innovated in the past decade [14], while constantly producing ever-more scalable and performant infrastructure.
I think if we want next generations of enthusiast and innovators to push boundaries of innovations and discoveries, to explore computational universe and cross the isle to genetics, jurisprudence and other disciplines, we need to scale down the software projects complexity.
We don't need combined 38 million lines of code between Linux Kernel & Docker & Kubernetes if we can use Plan9 at 2 million mark [16]. Yes, it has no corporate appeal for now, but when it does, we need to protect it from growing into Linux-2.
It is quite possible that a non-profit foundation like FSF [17] needs to setup a cyber-preserve where projects are maintained from overgrowing certain complexity threshold, and mandate forking & name change when it happens. We also probably need foundation-driven distros, providing software &/| hardware for home use that could replace majority of cloud services with a local ones. For instance:
os -> plan9 + gnu tools
system programming language -> go
database -> pgsql, rocksdb
google search -> computational knowledge engine
photo, audio, video -> kodi
video editing -> openshot
image editing -> krita, gimp
office -> libre office
browser -> ?
And for that to happen, we likely need to come up with a FSF funding plan.
Cheers!
[1]
https://www.zdnet.com/article/even-linus-torvalds-doesnt-completely-understand-the-linux-kernel/
[2] https://www.linux.com/news/linux-in-2020-27-8-million-lines-of-code-in-the-kernel-1-3-million-in-systemd/
[3] https://www.openhub.net/p/libreoffice
[4] https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/
[5] https://www.openhub.net/p/openshot-video-editor
[6] https://www.openhub.net/p/gnome
[7] https://hacks.mozilla.org/2020/04/code-quality-tools-at-mozilla/
[8] https://www.openhub.net/p/docker
[9] https://www.openhub.net/p/kubernetes
[10] https://www.openhub.net/p/vlc
[11] https://www.openhub.net/p/krusader
[12] https://www.gnu.org/philosophy/philosophy.html
[13] https://www.openhub.net/p/apache-kafka
[14] https://secondbreakfast.co/google-blew-a-ten-year-lead
[15] https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/
[16] https://www.openhub.net/p/plan9
[17] https://www.fsf.org
[18] https://en.wikipedia.org/wiki/Sinclair_BASIC
[19] https://www.youtube.com/watch?v=cZN5n6C9gM4