HN user
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.
After the OOM handler had halted everything the 10:th time, I finally decided to do something (at least the kernel and the TCP/IP stack seem to be very stable, because it still did not crash!)
I set the maximum amount of sockets to 32, the maximum amount of file handles of the DOS kernel to 40, and the maximum amount of file descriptors per one VPU process to 40. Now it should (maybe) be able to do its work without randomly running out of memory.
A hello world for an IBM PC compatible does not require much. Sadly UEFI has made everything exponentially more complex. If you want to be more minimalistic, this also works with if the BIOS is newer than 1/10/86 (written in NASM syntax):
[org 0x7c00] ; code offset
xor dx, dx ; row 0, col 0
mov ds, dx ; set data segment to 0
mov ax, 0x1300 ; ah = 0x13 (write string), al = 0x00 (write mode)
mov bx, 0x0007 ; bh = video page number (0), bl = attribute byte
mov cx, 11 ; string len: 11 bytes
mov es, dx ; ES:BP = pointer to string
mov bp, message
int 0x10 ; interrupt 0x10
end: ; do nothing to prevent crashing
jmp end ; (cli & hlt also works)
message: db "Hello world"
times 0x01FE-($-$$) db 0 ; padding
dw 0xAA55 ; boot sector signature
I recorded that video from a computer that is connected to the same ethernet hub as the 486 server.
Yes. I wrote a special mouse driver that hooks to the keyboard interrupt and makes it possible to use the numpad keys as a "mouse". Sadly most DOS programs seem to replace the BIOS's keyboard interrupt handler with their own, so my driver does not work with them.
It consumes about 30 watts.
Considering that it has to be able to handle about 100 new sockets per second, one socket requires about 1 kB ... 2048 kB (?) of memory depending of the size of the buffers and how the congestion window is implemented[1], I'd say that it would need at least dozens of megabytes of memory and fast I/O. Maybe more depending of the size of the content in the server.
Also not all TCP/IP stacks close the socket properly, so the socket cannot just be removed from the memory immediately after sending the page. There will always be sockets that are just waiting for a timeout.
[1]my 486 server does not have any TCP congestion control at all - it just sends one TCP frame and waits for ACK before sending the next frame.
This video answers to your question: https://www.youtube.com/watch?v=0CeK1TnGhIs
Everything in my "operating system" is 16-bit x86 code. It uses regular DOS packet drivers. I have also started writing my own DOS kernel, but it is not ready yet. The server uses FreeDOS kernel. That's why I write the "operating system" in quotation marks.
And because my TCP/IP stack is 16-bit code, it probably won't work for your system. It's just a DOS program that has an interrupt service routine that the other programs can call.
Yeah, a 486 is not a slow CPU - not even the 25 MHz SX version that the server has. But Windows 95 is a 32-bit protected mode OS. My OS also works on a 8088, but I don't have a 8088 computer that I could use as a server.
I think the user will most probably keep pressing the F5/Refresh button anyway if the site is not working at the first try, so responding with a RST packet would just use more bandwidth and resources.
iptraf on another computer, connected to the same hub: https://www.youtube.com/watch?v=0CeK1TnGhIs
Assuming that one "TCP entry" means one socket, that's a lot of SYN packets...
Video from what it looks like on the server: https://www.youtube.com/watch?v=BVKjVyM53sg
My OOM handler killed the HTTP server process. Now I restarted it - the HTTPD process, not the computer.
The TCP/IP stack is compiled for 64 sockets. If the socket table is full, it just drops all new SYN packets and does not answer to them.
My system is 100% 16-bit code and cannot access more than 640 kB of memory, and that's why it is so limited. I could probably increase the maximum amount of sockets and file handles to give it more capacity, but it still has its limits.
For those who are interested in retrocomputing, you can download the actual software from there: http://sininenankka.dy.fi/~sami/fdshell/
I recommend downloading the bootable floppy image, unless you want to see the source code.
Right now I cannot even access it locally from my lan, but it does answer to some of my pings. The HDD led is also blinking, which means that it is in fact answering to some HTTP requests. The TCP/IP stack is compiled for 64 simultaneous sockets.
Video: https://www.youtube.com/watch?v=erM0K0oXk4M
In the end I minimized the HTTPSERV.APP window so that scrolling down the text would not consume too much CPU time.
Me too, and that's why the BBS service is still on a floppy.
Actually I upgraded the storage and the website is now served from a hard disk. I'm uploading a video to Youtube atm.