YAML is actually very complex, to the point that basically nobody implements the full YAML 1.2 spec from 2009 (https://matrix.yaml.info/), while 1.1 contains footguns like `country: fr` and `country: no` parsing issues.
Though I agree simple usage is good enough in practice, there are a lot of edge cases that can cause subtle bugs.
I use mailbox for the past few years and I think it's the best option out there. But they have one major issue, which is that anyone can impersonate your domain:
Lack of records isn't the issue. You authorize mailbox's servers to send on behalf of your domain. Then they let anyone with a mailbox account set the from to your domain.
I see, so their SMTP authentication is woefully broken and they let anybody who can send an e-mail from their SMTP server to put anything in From: ? That's rather hard to believe. The defaults of most SMTP servers like Postfix prevent that. Since I don't want to get banned I don't really want to test that option with their SMTP server.
I took the https://emailspooftest.com/ and while the "spoof" mail gets delivered to mailbox.org's Inbox, my Thunderbird client is all red and it warns me about DKIM and SPF fails.
For incoming mail, your client should check regardless of the server provider. On Thunderbird I have this extension: https://github.com/mcortt/EagleEye . It checks for any SPF, DKIM and DMARC fails and shows a banner. SPF/DKIM/DMARC is minimum and pretty useless against spam though. All phishing e-mails in my GMail account have impeccable SPF/DKIM records.
Things like that existed in the category of accelerator cards. Xeon Phi (Knights) is one example, focused on core count. Some from HP have soldered on SSDs too. You also had blade servers which is more focused on that use case, though that's going out of style.
I don't think PCIe is really a good fit for general CPU tasks. You need big heatsinks and power and can't fit that much RAM on board.
Sure, but Joel isn't saying that's impossible or that people who do that are crackpots. In fact, he was an advocate of writing specs ahead of time [1] - for people.
At the time "generating a program from a spec" was an idea floating around that you could come up with a "spec language" that was easier than regular programming languages but somehow still had the same power and could be compiled directly into a program. That's the crackpot idea that Joel is referencing - but that's not what a spec language used with an LLM is doing.
This is an excellent observation and puts into words something I have barely scratched the surface of. Along with specifications, formal verification is another domain that received the "just automate it" treatment in the before times.
And because formal verification with LLMs is an active area of open research, I have some hope that the old idea of automated formal verification is starting to take shape. There is a lot to talk about here, but I'll leave a link to the 1968 NATO Software Engineering Conference [1] for those who are interested in where these thoughts originated. It goes deeply into the subject of "specification languages" and other related concepts. My understanding is that the historical split between computing science and software engineering has its roots in this 1968 conference.
I don't know why you say that. I've measured Linux sleep power consumption for Lenovo and ASUS laptops over the past 10 years and S3 and si0x come pretty close.
Basically every high end laptop comes with TB4 or 5 ports.