smoppi

There is no such thing as an "AI". It's just a marketing term for so-called neural networks (that supposedly emulate a brain) running large language models. They don't have intelligence, they are merely guessing machines. They can generate sentences and fake images and videos. We shouldn't be wasting gigawatts of computing energy to run these things.

It's now been about five years since I heard about the Rust programming language for the first time. It was when I was starting to write an operating system in C and the "Rust people" (as they seem to often refer to themselves, which should already be a red flag) told me that I should write it in Rust. (Later, they have several times told me to rewrite it in Rust.) Rust is "memory safe", which in the context of Rust means that the whole language is designed in such way that it is impossible to have memory-related bugs in programs that are written in Rust.

More than a year ago I wrote a document that I named "UEFI fact sheet". The purpose was to create a more truthful counterpart to a similarly named document which the UEFI forum was spreading on various Internet sites. For a long time my document was the first search result on most search engines when searching for "UEFI fact sheet". Recently I noticed that Bing (which is owned and maintained by Microsoft) had put my document to the second page of search results, and the first result now points to a disinformation document that is published by the UEFI forum.

ST-DOS is a DOS implementation, but it is not meant to be a clone of MS-DOS. It is mostly syscall-compatible with MS-DOS, but the driver API and many other things are completely different. After all the definition of DOS is just "disk operating system".

All real mode programs that are compiled with Watcom C/C++ should work. The most recent versions of Watcom's protected mode runtime don't currently work, because they use some undocumented MS-DOS syscalls that are not implemented in ST-DOS. I intend to create a compatibility TSR that will solve most issues with those MS-DOS programs.

>I was there too. People always say this, but just because a thing changed once does not mean it will happen again.

The problem is that the web standards have now grown so much that it is impossible to write a complete new web browser from scratch. Firefox is not coming back, because Mozilla seems to prioritize other things than code quality and the actual usability of their software.

And yes, I know that the SerenityOS developers are trying to do it, but while some very advanced things work "good enough" in their browser so that Twitter and Discord's web client works to some extent, the more basic things are so broken that their browser cannot even render basic HTML 3.2 sites properly.

Google's end goal is probably to "deprecate" HTTP 1.x and force everyone into using their own replacement for the protocol. Their protocol is going to be like the thing they call "HTTP2", an insanely complex protocol that is impossible to implement by a small developer team. In the end their own protocol becomes a "rolling release" protocol that only works with Google's own app, at which point they can completely stop releasing RFCs for it.

The text was too long, so I had to put it in pastebin.

> Non-corporate-supported browsers might transition to being more friendly to this process instead of the unhelpful and scary SSL warnings provided now.

That's exactly what I would like to see happening. The current warnings make no sense and they only make security worse.

Browsers are not different from any other applications at this.

When I'm talking about "lookalike domains", I mean domain names that look exactly the same. It is simply not possible with 7-bit ASCII.

A self-signed certificate can also be used to make sure that the connection is private. Sometimes the private key may have leaked and then the certificate can be "trusted" without being private - though it's easier to just register a lookalike domain and a certificate for it than have a leaked private key.

Clearly it is not suggesting anything like that. You misunderstood it on purpose.

I am living in reality. I don't want to limit the user's freedom. Sometimes people have to learn the hard way, but the other option (giving away your freedoms) is always worse.

1: You can always use a stronger encryption. You don't have to use decades-old encryption that has already been compromised.

2: So clearly in this case the route wasn't trusted. The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed.

3: Intranets are vulnerable only if there is untrusted devices in the network.

As I wrote, encryption is a good thing and improves security when used correctly, but all software must respect the user's choices. Nothing can fix stupidity and ignorance.