I agree with the article, email is email. But it points out something which is fundamentally a problem for the industry. Some software is done as in doesn't need to change any more.
That is a scary place since all those Gmail engineers need to do something so if it isn't adding new things to Gmail what will they do?
Interesting parallel in open source, Linux especially, when you have a subsystem that works well and is well understood by lots of people. Nothing to fix right? Well that would be boring. So we get things like systemd replacing the init subsystem and we get the unholy love child of netware and windows 'net' command replacing networking infrastructure management. Did they need changing? No, the previous systems did just fine. But what else is there to do?
But, people can't just do nothing and get paid. So, they will create the need. And now spend months to make it, fix it, get busy again.
This is absolutely a thing at Google IMHO. Remember the last major version of Google Maps, ran silky smooth on low end hardware, searches went where you expected, in and out no problem.
Then someone decided to try for glory and improve on perfection by re-engineering the entire thing. Now it sets the fans off in my macbook within a few seconds of appearing and they run for the duration, searches zoom out and show results 5 miles away on the other side of the major city I live in when I just want to see restaurants or coffee shops near me, constant back and forth jank from result lists to items.
Went from an app that was a complete joy to use to something I dread to interact with.
Says enough about their priorities, IMHO.
I remember one of the earliest software features that was widespread and called "intelligent" was basically the fact that a search form would remember your previous queries and present them incrementally as you were typing your new search.
That a company that prides itself on its AI efforts simply refuses to do this, again, says enough about their priorities.
It's mostly about tracking and a form of "embrace, extend, extinguish". We're at the last end of the second phase now. Make no mistake, Google has followed through on the "extinguish" part enough in the past. See: Google Reader, and what they did to Usenet and the Deja archives.
90% of the industry isn't directly about software, rather other products that are helped by having some software around, and when it is done, it is done. Time to move along to other customer.
The underlying protocols (SMTP and IMAP) are decent, but the clients aren't. It still lacks usable end-to-end encryption found in many modern messaging protocols/apps. Outright spam is mostly solved, but marketing and other notification emails I accidentally or intentionally signed up for consume way too much mental bandwidth, even with supposedly intelligent email clients (at least the ones I've tried)
That said, AMP for email doesn't solve any of those problems either.
A lot of what it does definitely needed changing — although systemd implements that change suboptimally.
Take the logind concept:
In the past, Linux screensavers were simply a fullscreen window in front of everything else. They crashed? Your system unlocked.
With logind, you have one tiny separate daemon that spawns your original X session, and the screensaver. As long as the screensaver is active, that screensaver replaces the X sessions's display.
If the screensaver crashes, it gets restarted, or, if that fails, you get in a lovely TTY font "open a tty, login as your user, and type loginctl session-unlock".
And this is secure. If something fails, your session won't accidentally unlock.
Other features include an IPC protocol that allows per-message security — user A can send messsage type 1, but user B can only send message type 2 (although, did that verification language have to be JS? T_T)
Systemd is a lot of good intentions and ideas, turned into bad code.
AMP is one good idea (faster loading speeds) turned into not just bad code, but also lock-in and proprietary anticompetitive services.
There's no black, or white, only Greys on Greys.
(if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)
This is really offtopic, but you seem to confuse KDE with systemd. There is a bit of KDE that tells you to use loginctl to tell KDE's display manager to unlock the session if KDE's screensaver doesn't work properly.
Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.
In your first comment you said that screensavers were just normal windows and would crash back to an unlocked screen - that never happened. Here you're conflating KDE (started ~1997) needing logind (started in what 2010?) which it didn't. Even your comment about a 'session' makes no sense since at the X runlevel X itself is the 'session'.
In my opinion a lot of the problem has been a lack of clarity of what the actual user benefit will be, and the crazy borg-like scope expanion. I'm going to avoid commenting on the implementation of logind and brethren.
I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp
Gräßlin wrote a bit about that in his blog.
But you might be right, I’ve not worked on either of these projects, so my knowledge is mostly from hearsay.
Edit: to be clear, it’s not about the binary used to run the screensaver, it’s about the fact that it does not need to be a question of “all or nothing” and that a solution for this particular problem could have been adopted without replacing virtually every other component of the system services simultaneously.
logind is developed by systemd, but a separate binary. In fact, every systemd project is a separate binary, just developed by the same project. Systemd is as much a monolith as KDE is.
Second, this tiny little logind binary is separate from the screensaver. It does not contain the screensaver, nor the lock screen, nor does it link to them.
This tiny process spawns the session and screensaver, and simply switches between them based on a signal. It's the tiniest possible concept for handling this task.
In general, I'd prefer if you could be more specific about your criticism, e.g. how this separate tiny binary is a "kitchen sink" and the screensaver, which is entirely separate from logind and systemd, is "part of a megalith".
So, instead of wrapping my screensaver in a small program that manages respawns on crash, you’ve arranged to force me to either have the screensaver unlock itself (since you ripped out the old simple wrapper), or have remotely exploitable network holes.
[edit: source: https://www.jwz.org/xscreensaver/versus-xlock.html ]
Also, due to systemd, the some of the ioctls you need for rootless X are needlessly declared “root only”, so to call them, you have to launder the call through some authentication daemon that has its own (not Unix) security model, and runs as root.
Finnally, I run this mess on a machine that is also an NFS client, and it frequently times out mid login / resume session, so you need to login like three times on a bad day because nfs takes a few seconds to stat something.
It was even worse with systemd aware desktop environments. There, instead of timing out quickly, it would sometimes hang for minutes, with per-user copies of what appeared to he the whole systemd stack running, and no logs anywhere.