Unpopular opinions
Unpopular opinions
I hold unpopular opinions about a lot of things. Given the worldwide phenomenon of political polarization, it is dangerous these days to disclose, let alone discuss certain points of view. Here, I will restrict myself to a couple unpopular views related to computing.
Since 2010, I am convinced Linux should adopt Android UI as the "next" UI. Why?
First, because it's there. The AOSP part is free software. It is a mature implementation. It is used and therefore tested in billions of devices. It offers a standard API for UI, background services, audio, video, camera, etc. There are hardware drivers. There are tons of apps that serve the average user.
Nothing precludes an AOSP graphical environment running in a vanilla Linux distribution. An AOSP does not (need to) stay in the way of the bare metal. Just open a Terminal and be happy.
People look down on AOSP because it hinges on Java... is that worse than depend on GObject? Meanwhile, nobody managed to write a decent e-mail client for Linux. We are still stuck with Thunderbird, which is ages old, and multiplatform. Android has no shortage of good e-mail apps.
I still can't use a Mac keyboard on Linux just by configuring it using the UI configuration tool. I need to issue an additional setxkbmap or change an X11 keymap file to make it work perfectly. If the Linux GUI still can't do something so simple, how can we expect to succeed developing an X11 replacement from scratch?
As happens with window managers, the community promply fragmented the efforts in many X11 replacement candidates: Mir, Wayland, and a couple others I can't remember the name. The endeavor of replacing X11 is huge and fragmenting is a sure way to get nowhere.
On top of that, there is the Joel's Curse: why rewrite something we already have? The Linux/free software/pure/whatever way to go would be improve Xorg incrementally. For all its flaws, Xorg delivers our current GUI and it has been improved throughout the years. It runs Counter-Strike, window managers do the Exposé trick, and connecting external monitors does work well nowadays (that was a maaaaajor blunder for Linux laptop users back in the day). Major GPU manufacturers supply drivers for Xorg. What else do we need?
Maybe I am wrong and Wayland makes it, but I am skeptical.
I don't understand why C couldn't have a String type — just like Pascal, or at least Object Pascal. This is an older gripe of mine; since 2005 or so.
Imagine how many billions of bugs and exploits would be averted. Imagine being able to use strings as generic memory buffers, since they have defined lengths and \0 chars have no special meaning. Imagine not having to free() string buffers thanks to the RAII convention.
Einstein said: things should be as simple as possible, but not simpler. IMHO this is the case for C vs. strings: people go too far in protecting C's perceived simplicity.
"But the C standard would become more complicated!" The C standard is already too complicated for its own good. Lots of undefined behavior. C is a bad language. It is bearable because compilers issue lots of warnings, most platforms follow VAX and POSIX conventions, and most undefined behavior cases are fulfilled by reasonable behavior.
A reference-counted, copy-on-write, length-checked string type needs just a handful of support functions: allocate, deallocate, ref, unref, copy. It is a thing to be implemented in an afternoon — and it has been implemented again and again thousands of times because the core language lacks it.
"But the implementation might not be the most efficient!" Just replace the support functions with your own implementation, or by preloading a library, just like we do today when we are not content with the standard malloc().
"But strings have no place in kernel/embedded/bla/ble!" Then just don't use strings in there! Make the support functions equal to NULL and/or add a compiler flag to disable the String type. The Linux kernel cannot use floating-point types (e.g. float, double) which are native C types; and yet, the kernel is written on C, not in BCPL.