Enlightenment Mysteriously Drops Wayland Support

jones_supa writes: According to Enlightenment 0.19.12's release notes, it's an important release that fixes over 40 issues, which is quite something, considering that previous versions had only a few improvements, with most of them being minor. However, the big news is that 0.19.12 drops support for the Wayland display server. Unfortunately, the Enlightenment developers have omitted to mention why they decided to remove any form of support for Wayland from this release, and if it will return in upcoming releases of the software.

Comments

I guess they realised...

[Viol8]

... that Wayland is a solution for a problem thats already been solved better.

Re:I guess they realised...

[Anonymous Coward]

Windows

Re:I guess they realised...

[Junta]

I suspect the sentiment is that X11 is better because of the network transparency angle. Of course the underpinnings of how X11 does it are actually decrepit and inefficient and compare poorly to other strategies that leverage different entry points that Wayland actually preserves. Injection into the compositing and WM provides a simpler and nowadays better performing strategy than X11 primitives. It meant something when the X11 primitives were actually used in the typical X applications with some sort of relevance, but now pretty much applications running over remote X are pretty much dumping bitmap data rather than any useful shorthand for complex UI concepts. Meanwhile intejecting the payload via compositor and the context via WM avoids a lot of the complexity that X contends with and allows a compositor freedom in picking good client-server protocol/compression.

Re:I guess they realised...

[squiggleslash]

Well, it's funny how something with "the underpinnings of how X11 does it are actually decrepit and inefficient and compare poorly to other strategies that leverage different entry points that Wayland actually preserves" still manages to solve the problem, and Wayland doesn't.

X11 isn't perfect. Nobody's ever argued that. It's just nobody's really asking for a replacement, and if they were, they wouldn't be asking for Wayland. X11 is an extraordinary piece of technology, it takes some gal to claim everyone should just throw it out and replace it with a ground up rewrite that adds no new features and doesn't support the major features X11 is famous and loved for.

It's not like init/SystemD, where init really was a bug ridden piece of garbage that's needed replacing now since before Linux itself came on the scene, and SystemD implements everything init did but does it right.

Re:I guess they realised...

[Anonymous Coward]

it takes some gal

Found the problem. It's more of that horrible misogyny in the Linux community.

Re:I guess they realised...

[jon3k]

It's just nobody's really asking for a replacement

No one asked Henry Ford to make cars, either. This attitude, specifically in technology, is baffling to me.

Re:I guess they realised...

[fisted]

init really was a bug ridden piece of garbage

Care to point out a couple of those bugs?

SystemD implements everything init did

And a lot more, yes

but does it right.

Hahaha, yeah, it probably looks right from a Windows-centric POV

Re:I guess they realised...

[jareth-0205]

It's not like init/SystemD, where init really was a bug ridden piece of garbage that's needed replacing now since before Linux itself came on the scene, and SystemD implements everything init did but does it right.

Talking of statements that take some gall...

Re:I guess they realised...

[serviscope_minor]

No one asked Henry Ford to make cars, either.

And you know what? No one asked the Stanley Motor Carriage Company to make cars either.

Simply being new doesn't mean it's better. The trouble with Wayland, or rather why I'm deeply suspicious of it is that some of the claims from the devs about waykand and X11---and bear in mind they're X11 devs too---are flat out wrong at best and deeply deveptive at worst. Why the need for a FUD attack? If Wayland is better it ought to win on merit, not FUD.

Tahe for example this article: http://www.phoronix.com/scan.p...

Going through one at a time.

1. Extensions are what X11 calls API updates. Wayland will get API updates too, so this is not an advantage of wayland beyond version 1.0.

1. A, B, C: Almost all extension version updates add new API calls and keep the old ones. Sending Foo 2.0 calls to Foo 2.2 works just fine. Not to say that versioning isn't a problem, but then fixing the API is apparently bad for X but nothing else.

2. Well core X11 is super simple and a tiny setup of Xinput 2. This leaves essentially 2 input systems left of any complexity, 2.2 and 2.0, and as far as I can tell 2.0 isn't actually separate from 2.2. So, basically X has one major input system which actually looks kinda similar to the Wayland one.

3. That's a misunderstanding of "mechanism not policy"

4. So Xorg and Xfree86 got a bit crazy and then got refactored. Apparently historical cleanups are a bad thing? This happens in any project of any age.

5. Apparently it's impossible to add a new API call for synchronisation because from (1) that X11 isn't allowed api updates unlike every other system.

6. Yeah OK, fonts are not great.

7A A badly designed chunk of Xorg is apparently a problem with X11 now. Oh and it's been fixed so it's not a problem at all. But apparently every misstep in one implementation of an X server fixed 5 years ago is a reson it's bad now.

7B That was pure fud in 2013 when it was written. Xrandr and monitor hotplugging has worked flawlessly for years.

7C Huh? There's been xrandr front ends for years which remember certain layouts. Hell, Arandr, the nice GUI point and click one in all the repos remembers layouts just fine.

7D That smells like bullshit to me. Unless the second monitor is a separate screen (X11 term for something little used now) they it'd be impossible for one to have compositing and one not. I've not heard of anyone using screens in years.

8 Yeah and real toolkits are poorer for it. The window tree is a really nice thing when you have latency. Because with tree'd systems the server remembers which sub-sub-sub window a mouse click went to, and you could ignore the absolute position. With a treeless system all you have to go on is the position.

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

9 Yes this is finally a genuine, no-nuance flaw.

10 C this is not correct if you have a compositing window manager, because it can do whatever it likes with the final display.

10 D their solution is to make the compositor do all this shit in Wayland. That could be done equally well in X. Sure, the current convention has a small flaw, but X11 now supports the Wayland way too.

10 E just use the features of the compositing window manager. It intercepts all key presses and windows anyway.

So without getting into the merits or demerits of Wayland, it's disappointing to see the devs engaging in a colossal FUDstorm.

Re:I guess they realised...

[Uecker]

It is a myth that supporting old drawing primitives in X11 somehow slows down modern clients and you can essentially have the same buffer handling as Wayland with X. In fact, the design of Wayland is basically copied from X minus some old parts which are not needed by modern clients. The problem with this is: Breaking compatibility with a decades old protocol for no good reason is just moronic.

Re:I guess they realised...

[TheRaven64]

It's not that supporting the old things slows things down, it's that it doesn't speed things up. It actually does cause some problems, because various things in the X11 protocol use 8-bit fields of which a significant space is used by legacy stuff that no one uses anymore, but that's largely worked around in newer extensions.

If you're in a world where most applications are sending commands like 'draw line from x,y to x1,y1' then X11 network transparency is really fast. At the protocol layer, anyway - if you use xlib then performance will suck unless network latency is very low because it adds a synchronous API on top of an asynchronous protocol (XCB fixes this). Modern applications don't do that, they typically render pixmaps and just have the X server composite them. X11 can still do a reasonable job here, with XDAMAGE, XFIXES, and XRENDER, allowing you to keep most of a pixmap (a Picture, in fact) on the server, update image data in selected parts, and do all of the compositing in the server. The problem is that none of the X11 toolkits actually do this very well. Wayland doesn't solve this at all - it simply says 'well, grab an OpenGL context and send drawing commands'. That works okay - the OpenGL protocol allows you to copy textures to the server (and the GPU) and composite them very fast. The problem is that this approach also works fine in X11, and with X11 you get network transparency when you do it (which works reasonably).

The main criticism I'd have of X11 is that it puts too much state on the server. There is no way, at the X protocol layer (or even in the low-level X libraries) of saying 'disconnect this window from this display, reconnect it here', or 'oh, my X server has crashed, recreate my state on this newly restarted version'. The latter worked fine in BeOS almost 20 years ago and works fine in Windows today. The former worked on NeWS 30 years ago. Both are use cases that I'd love to see addressed for modern devices. The Wayland solution to this is 'write a web app'.

Re:I guess they realised...

[vadim_t]

Care to point out a couple of those bugs?

Okay, sure.

1. It does next to nothing. All the real functionality is in distribution specific scripts, which means you need to research and write a script for each distribution you want to support, each with its own particular features and idiosyncracies.
2. Each script is a bunch of boilerplate that has to reimplement the same stuff. Often badly, especially when an init script has to be improvised.
3. The functionality is inconsistent between services. Some can be restarted, some not. Some have a status command, some not.
4. To check whether a service is running, it uses pid files. Pid files are horribly unreliable and prone to failing if a pid file happens to be left around, and something else happens to use the same pid.
5. If you want start on demand, eg, something like xinetd, that's an entirely different system that's managed differently and separately.
6. If you want a service to get automatically restarted, that's also done with an entirely different system like monit.
7. It doesn't have useful logging. Processes can vanish into the ether without useful information in the logs because stderr may not be captured in some cases, and because init doesn't log service crashes.
8. Service providing services are tricky. You may know the daemon has started, but you don't know it's now accepting requests. Yay for "sleep" hacks.
9. Breaks horribly the moment something goes wrong. Network cable not plugged in? Well, if you boot like that nothing network related works, so you've got to log in and fix it by hand.

Re:I guess they realised...

[Alomex]

It's just nobody's really asking for a replacement,

Except SunOS which replaced it with SunNews,

--Ok, but apart from SunOS no one is asking for a replacement.

Well NeXTSTEP replaced it with display postscript.

--Ok, apart from SunOS and NeXTSTEP no one wants a replacement.

Android dumped it.

-- Yes, aside from SunOS and NeXTSTEP and Android, who else wanted a replacement?

OSX replaced it with Quartz as well as iOS.

-- All right, but apart from SunOS, NeXTSTEP, Android, OSX, iOS what have the Romans ever done for us, i mean who wants a replacement?

Ubuntu with Mir and the Xorg with Wayland?

--Oh, SHUT UP!

Re:I guess they realised...

[Uecker]

It doesn't slow down, but they also don't help. That's the point I was making, that the lines, text, and pattern primitives that X was able to simply describe aren't leveraged in modern UI.

Yes, this is why XRENDER was introduced 15 years ago.

Now I can't speak to the question of what Wayland fixes in exchange for getting to ignore having X11 as part of the core,

Well they don't have to deal with the old code, I can understand this. But it breaks compatibility on the protocol level, this is really stupid IMHO.

and whether it's worth it. I can say that even if it Xorg, it's time for most folks to move on to strategies like Xpra that preserve the awesome facets of seamless remote applications, perform better, and are not sensitive to things like network disconnects trashing the ability for the application to keep running.

Xpra is nice if you have a slow connection, but I use X applications just fine over the network every single day and it works just fine. Being able to disconnect would be nice though, and I do not understand why toolkits still do not support this. Well, the reason is that rewriting everything from scratch all the time is apparently more fun...

Re:I guess they realised...

[Endymion]

hey typically render pixmaps and just have the X server composite them

This is just nonsense. Your applications may be overly pixmap based (certain GTK+ engines started that mess when people prioritized "themes" over good design), but it is foolish to assume everybody else uses the same limited set of software. Remember, most of the software in the world is smaller private stuff used internally by businesses, academia, etc. Simply asserting that nobody uses various features doesn't make it true.

Wayland advocates really need to learn one of the most important lessons of software design, which was best explained by Joel Spolsky's essay "Things You Should Never Do, Part I".

[Y]ou can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for." [...]

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. [...]

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. [...]

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Yes, there are rough areas in X11 that really need to be fixed. That's true for almost any software project of sufficient size. Fortunately, the extension system in X11 allows a lot of those problems to be solved one at a time, while retaining backwards compatibility. The people that believe the very existence of backwards must somehow be a bottleneck are not creating the next version of X. Instead, they are creating something new. This is fine, but by their own definition, it is not a replacement for X11, and if Wayland tries to be such a replacement, it will inevitably grow to a similar level of "messiness" as numerous fixes, workarounds, and minor features are re-invented.

The problem with Wayland (and many other modern "replacement" projects, with systemd as the canonical example) is not technical in nature, but the hubris that so easily throws out so many man-years of effort.

Re:I guess they realised...

[Camel Pilot]

Oh look a hockey game broke out in a boxing match :)

Re:I guess they realised...

[fisted]

What about the part where you were going to mention bugs in init?

Re:I guess they realised...

[Endymion]

Each script is a bunch of boilerplate that has to reimplement the same stuff.

So shared libraries don't exist? That hasn't been a problem in a long time on BSD or OpenRC systems. Seriously, it's not hard to factor out code into a library. If you're only considering Debian, you have to remember that they are always behind (sometimes FAR behind) the update cycle.

The functionality is inconsistent between services.

Again, only if you were a moron and reinvented the wheel each script instead of using a common library.

That said, the ability to do things different is very important when you need to support something unusual.

To check whether a service is running, it uses pid files.

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

It doesn't have useful logging.

Again, this is by design, as it left logging *unspecified*. If you don't like syslog, nothing was preventing you from using something else. (also, "useful" is subjective)

because init doesn't log service crashes.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Yay for "sleep" hacks.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

on demand

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

"On demand" isn't necessary, because the kernel already provides that feature. Adding a redundant implementation simply increases complexity and adds more opportunity for bugs. Super-servers make it even worse, as they add the risk that a problem in on service could take down all the services provided by the super-server.

Breaks horribly the moment something goes wrong.

Ok, now you're just trolling.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

Also, you might want to actually read about UNIX before you make these kinds of accusations. Reading taoup is a good place to start.

Re:I guess they realised...

[Anonymous Coward]

Unless you go out of your way to configure it otherwise, on Gentoo, having the *loopback* device started is enough to consider the network up and online. Additionally, after the WiFi device is brought online, its startup is backgrounded so that the time taken by AP discovery and association and IP address acquisition doesn't stall the rest of system start. When backgrounded, WiFi network interfaces are marked as "started, but unready". When AP association and IP address acquisition is complete, that interface is marked as "started and ready".

Of course, the amusing thing about your snark is that the network connection handling software used on most non-enterprise Linux distros is NetworkManager; another Poettering special. I've dumped it and rely only on wpa_supplicant, wpa_gui, and the link detection stuff built right in to Linux. It works *really* well.

Re:I guess they realised...

[ardor]

If one of the X developers essentially calls X obsolete crap, then I think we should listen to him.

There are certain things that just don't work well in X. One of them is vsync, which requires a rather large amount of nontrivial workarounds, like Intel did.

To get something like vsync integrated properly, you need to fundamentally change how frames are updated. This is what Wayland developers refer to when they say that "every frame is perfect". The X11 model is essentially dumb drawing and updating, with no regards to complete frames. It goes further when you have for example 2 videos on screen. Even if both have the same framerate, temporal jitter will cause lots of problems. With a display server like Wayland, it is possible to inform the server that "surface X needs to be presented at timestamp Y", giving the server the chance to correctly schedule and group together updates. This possibility doesn't exist in X.

X is an anachronism, designed for graphics hardware from a bygone era. X does not in any way reflect properly how today's graphics chipset work. Sure, X can be used, but you need to use so many extension that very little is left from core X, at which point you have the display server equivalent of the Ship of Theseus.

One other big problem with X: it is single-threaded. Applications *can* cause X to block and become unresponsive. LibreOffice is good at this.

That said, I am not particularly fond of Wayland. I think it is a step in the right direction, but I slightly prefer the DisplayPDF approach of OSX. I believe certain primitives like text do have to be part of the server. Not for network transparency, but because rendering text is not easy, and especially because it makes it easier to deal with display scalability issues (physical size, PPI etc.) and multi-monitor setups (and also allows for very nice benefits like system-wide font atlas caching). However, in order for this to work properly and efficiently, you need to merge the display server interfacing libraries (= the equivalent of libX11/libxcb), the server itself, and the UI toolkit(s) to work consistenly across the board (and this is what OSX Quartz does). In particular, this requires the protocol between the interfacing libraries and the server to be opaque, implementation-defined, and not guaranteed to remain the same. This is because it makes modernizations, subsystem replacements, and extensions much easier. In X, there are still old extensions around because some old programs use the (Xinput vs Xinput2 for example). With such an encapsulated protocol as I describe, there would be only one high-level input API. The possibility of API breaking changes would not be that high, since unlike in the 80's and 90's, these days, the essentials of a 2D on-screen user interface (basic widgets, interface structures, crucial features and behaviors etc.) are well-known and stable.

Re:I guess they realised...

[vadim_t]

No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.

Of course. Keeping track of running services is out of scope for a service management system. Genius.

It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.

Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.

Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.

Also note that I'm talking about the init system, and not about individual services doing their own logging.

While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)

No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.

There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.

Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.

Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)

I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.

Also, you might want to actually read about UNIX before you make these kinds of accusations.

I speak from personal experience

Reading taoup is a good place to start.

Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.

Re:I guess they realised...

[Anonymous Coward]

There is one BIG flaw in X11 that wasn't mentioned: by design, every program that hooks into X also gets access to ALL input X gets. Meaning by design you cannot prevent any keyloggers from logging your sudo password. Wayland only allows access to all input to the compositor itself, and with a sandbox it can prevent any other program from keylogging.

Re:I guess they realised...

[serviscope_minor]

There is one BIG flaw in X11 that wasn't mentioned: by design, every program that hooks into X also gets access to ALL input X gets. Meaning by design you cannot prevent any keyloggers from logging your sudo password. Wayland only allows access to all input to the compositor itself, and with a sandbox it can prevent any other program from keylogging.

Indeed, though entertainingly this isn't part of the X protocol, but part of the Xinput extension brought to you by the folks now working on Wayland. However, I don't see any reason that the compositor model of X11 can't be updated to intercept all events: it already has to intercept all events anyway because it needs to be able to arbitrarily mangle them before feeding them into the various captured windows.

So this flaw could be fixed for compositing window managers with a small update to the API. Given the architecture of X, the 10 remaining people like me using non compositing window managers could do it with an external compositor. However, one of the main bonkers criticism of X is that the API sometimes receives updates. So make of that what you will.

Re:Yes and?

[Junta]

This is enlightment. They've never ever had a '1.0' release in decades of existing.

Re:Yes and?

[Anonymous Coward]

In general, they don't seem to be particularly good software engineers: https://what.thedailywtf.com/t...

I figured out the mystery

[Anonymous Coward]

After about 1 minute of investigation, I figured it out.

https://www.mail-archive.com/git@lists.enlightenment.org/msg05157.html

The code they had was old and unmaintained and didn't work so they removed it.

It's TEMPORARY, No Big Deal

[Anonymous Coward]

This is just a temporary change just for E19.... They have better Wayland support in E20. Explained @ http://www.phoronix.com/scan.php?page=news_item&px=Enlightenment-Wayland-Temp

Because Wayland support is moved to DR 0.20

[Jizzbug]

See here: https://phab.enlightenment.org/phame/live/3/post/e20_alpha_release/

Re:Because Wayland support is moved to DR 0.20

[Jizzbug]

Official statement on Wayland support in Enlightenment and its libraries:

"It also is in the transition from X11 to Wayland. We are fully committed to moving to Wayland eventually as this is definitely the future of the graphical display layer on Linux."

From the Enlightenment home page.

Re:Because Wayland support is moved to DR 0.20

[CajunArson]

Thank you.
I was pretty sure there was some click-baityness occurring here, and you just proved me right.

Re:Yes and?

[Anonymous Coward]

Those knowledgeable in the horrible language of C...

That's where I stopped taking the article you linked seriously.

it's all in the commit message

[Anonymous Coward]

https://git.enlightenment.org/core/enlightenment.git/commit/?h=enlightenment-0.19&id=d9501096bfaf626699dd6a61b49be2fb96ee6713

author Mike Blumenkrantz 2015-09-26 02:53:16 (GMT)
committer Mike Blumenkrantz 2015-09-26 02:53:16 (GMT)
commit d9501096bfaf626699dd6a61b49be2fb96ee6713 (patch)
tree 729fa82c90fd58c539391575ac2534101781b8c6
parent map/unmap x11 client windows when toggling iconic state (diff)
completely remove all wayland support from build system
this is unmaintained and out of date. the protocol versions are old,
and it's extremely unlikely that any client will work and be in a
usable state given the development progress since E19 was originally
released.

use E20+ for wayland support.

fix https://phab.enlightenment.org/T2746

Re:it's all in the commit message

[TeknoHog]

Ewige Blumenkrantz! Ewige Schlangenkrantz! Hail Eris! All hail Discordia!

Re:Yes and?

[myowntrueself]

Those knowledgeable in the horrible language of C...

That's where I stopped taking the article you linked seriously.

C isn't a horrible programming language!

Its a beautiful practical joke.