That's from the good old days where truth mattered. Like how many action movies are about "getting the truth out" where that act in itself brings consequences, cut, happy ending?

Compare with now: revolution may be televised, but its spread not amplified and its authenticity denied. And if you have sufficient tribalism, it will not make a dent.

From what I know, politologists are analyzing the situation in US from a perspective of "mid intensity civil war".

So what you're writing is aligned with tactics you'd expect...?

So what are the sources for people driven insane by it?

(I have no opinion, but find it mildly suspicious given that I happen to sometimes drive through Germany, and the country seems to be currently less insane than, say, US)

> Gradle files (worst abomination of a build system ever)

Ant? Maven?

Ugh. Why can't we just make javac [STAR].java work? Tarball the resulting .class files, make sure to have one called Main.class that is the entrypoint, GPG sign the tarball and you should be ready to distribute.

Yeah I know it doesn't work like this now, but the designers of the entire Java/Android ecosystem should have designed it to be that simple.

The moment you get any of these build systems involved you instantly lose all hopes of DRY coding. Excerpts from an Ant build.xml file:

    <target name="jar" depends="compile">
        <mkdir dir="jar" />
        <jar destfile="jar/HelloWorld.jar" basedir="classes">
            <manifest>
                <attribute name="Main-Class" 
                  value="antExample.HelloWorld" />
            </manifest>
        </jar>
    </target>
 
    <target name="run" depends="jar">
        <java jar="jar/HelloWorld.jar" fork="true" />
    </target>

I see "HelloWorld" repeated 3 times. MASSIVE fail. I'd rather no build system than deal with this level of repetitiveness. It's bad enough that Java requires the file name == class name which is already a case of repetition (that design decision is fine with me but then files should start with "class {" and not "class Foo {")

Maven is wonderful. It's all the best parts of npm or cargo, years before them. Just don't try to fight it - accept that there is a maven way of doing things that you will have to follow. If you need something to build before something else, put it in a separate module. If you absolutely need a custom build step, write a proper maven plugin for it. But 99% of the time your build definition can and should be just a list of dependencies and a couple of basic settings values.

Internet starts to have 1y memory retention.

Unless refreshed by active learning, aka someone doing the refresh job.

Or unless delegating the work to large players—either the memory or the hosting.

EDIT: This feels wrong, even when done for right reasons. And I wonder whether this would fly without LE and whether this means we are officially making LE THE critical part of Internet infrastructure.

Websites marked "insecure" are still fully accessible.

Not always. You may also end up with having incompatible set of ciphers (happened to me).

"Get off my Internet lawn if you can't be up to date" is what we're saying and I just do wonder whether we haven't exchanged too much of accessibility for too little of security.

Not always. Sometimes the browser presents a full-page response to the effect that the site is dangerous at which point, even if it's a harmless site, the non-savvy user will leave. Blanket HTTPS/SSL + Letsencrypt is a disaster.

This only happens if the site used to be HTTPS and no longer has a certificate or the site has long-lasting HSTS.

On the contrary… LE is unaffected by this, since from the beginning it has enforced a much shorter certificate expiry time: 90 days. Which effectively forces you to set up automated renewals. Doing that does not require the help of "large players"; you stick certbot or another tool in your crontab, or use something like Caddy or Apache mod_md to have your web server do it by itself.

Fun fact: you can use Caddy to manage certificates independently of its web server, with just a few lines of config: https://caddy.community/t/using-caddy-to-keep-certificates-r...

This approach is more reliable than cron in case of failures/errors. Not only are there fewer moving parts, Caddy's error handling logic and retries are smarter than just "try again in <interval>".

I'd say quite the opposite. What you say is one of the myriad of considerations that should go into prioritization by the team, yet is super hard to capture by any hard attribute as I believe the "positive/negative mental health effect" is way more complicated than "bug/feature", yet known by the team.

One of the reasons I am delaying design is getting deeper into accessibility and readability research. And I have decided to write some content first ;)

If you mean how to prevent them, well, no bugs so no way to create them.

If you mean how they handle them, there is an incident procedure for that. If it's not really an incident but, well, I need this next week for Gartner Magic Quadrant...I have phone numbers of managers in my reporting chain.

True. I think one of the issues is slapping an issue tracking system on a bunch of different problems.

As mentioned, this is true for versioned software, not for continuously deployed SaaS.