Hacker News new | comments | show | ask | jobs | submit login

Because they didn't internalize the feedback from Wave well enough I guess. /s

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?

That's exactly what I thought about new Youtube web interface. It's slow to load and consumes more CPU. Previous design worked great everywhere. There was no need for the UI change.

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.

Yes! This "over-engineering" is happening all over Google products. Chrome is another example. It is not all bad, however, some Google Apps really needed attention, like the new Calendar is a step up (IMO).

> This "over-engineering" is happening all over Google products

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.

The Google Maps app isn't even "capable" of remembering your recent search queries if you don't allow Google to track your Location History.

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.

The interface might be perfect but if it doesn't change users will eventually think it's "too old", some users like you and me will happily use the "too old" interface because it's fast and works well, but the normal people want something "fresh". Design is like fashion, some design patters stay, but the look is constantly changing.

While you're not wrong about trends in design / UI design, if you think about it for a moment, your argument is no more than a mere footnote (if any) in Google's reasons for pushing AMP to email.

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.

Which is why, in a way, consultancy is a better place to be.

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.

I don't consider email to be "done". It's pretty much my least favorite tool.

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.

IMAP without NOTIFY which no major provider implements is terrible.

I have to disagree on the topic of systemd.

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)

This thread here is obviously the wrong place to roll out the systemd discussion again.

That's a good point, it's just sad to see people directly dismiss it.

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.

Real happy with the "fold subthread" buttons on HN :)

(if only they would auto-fold after a fixed number of children, like Reddit, I might script that for myself one day)

> 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".

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.

Sure, KDE implements that bit, but the important part is that logind makes it possible to implement that bit in the first place.

Before logind, the alternative was custom handling and detection of screensavers in your session, or simply it crashing back to the session.

I find both your comments confusing.

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'm not conflating anything — lockscreens on X11 were always just normal windows. If they crash, they unlock.

I suggest you read JWZ's On Toolkits page: (archive link due to referer shenanigans): http://archive.is/BjMfp

Yes you are. The trick that KDE uses is that the screen locking is done by the KDE session manager, and because that is the main process in the X session if it crashes the session terminates so it's not possible to bypass the screen locker that way. None of that requires systemd; it makes use of something that's been true under X11 pretty much forever. The only thing that changed with logind is that instead of trying to restart the password prompt if it crashes, KDE now pops up a message asking you to drop to a console and use logind to disable the screen locker. (Annoyingly, it does this even on systems that don't use logind, in which case the instructions don't actually work.)

I was aware that KDE handled it that way, but as far as I know to handle it properly like this across X11, Wayland, and other sessions, logind is pretty much required.

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.

That’s just bad design to begin with, replaced by a ln inefficient kitchen sink of a solution. Why should the screensaver be part of this megalith?

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.

As I wrote in the comment you replied to, the screensaver is NOT part of the init system, nor is logind part of the init system.

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".

Presumably, it is part of a “megalith” because now my screensaver depends on some crazy login manager, which depends on a crazy authenticated ipc scheme that loginctl uses, and probably none of this works if I replace systemd with something else, so it all depends on running some busted dns client with a recent history of remote exploits.

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.

To what DevOps platform is this a reference to? "and we get the unholy love child of netware and windows 'net' command replacing networking infrastructure management"

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact