Such a needlessly negative article. PCIe 5.0 is early, peripherals are scarce-to-non-existant, and existing rigs are not infinitely flexible. Otherwise, it all looks pretty good to me. Even buying one of those may prove worthwhile as new graphics cards and SSDs are released.
I'm so grateful to him, his early work was a massive influence for me as a kid. I lent one of Dewdney's books to a neighbor friend's dad, an architect, and he gave me my first paid gig as a programmer. Can't overstate the influence in my career.
Also, I distinctly remember his column showing how to generate text based on statistics learned from an existing corpus. It has come to mind more than once in this last period of LLM magic -- the essence was already there.
Nitro "virtual NVME" device are mostly (only?) for EBS -- remote network storage, transparently managed, using a separate network backbone, and presented to the host as a regular local NVME device. SSD drives in instances such as i4i, etc. are physically attached in a different way -- but physically, unlike EBS, they are ephemeral and the content becomes unavaiable as you stop the instance, and when you restart, you get a new "blank slate". Their performance is 1 order of magnitude faster than standard-level EBS, and the cost structure is completely different (and many orders of magnitude more affordable than EBS volumes configured to have comparable I/O performance).
This is the way Azure temporary volumes work as well. They are scrubbed off the hardware once the VM that accesses them is dead. Everything else is over the network.
Beautiful, I love it, congratulations! I started my programming journey with Basic on a ZX Spectrum +, then Z80 assembly language, then 8086 and the rest from there... 40 years of programming and my appreciation for my original platform is still there. Thank you for the tribute.
I've often heard about the Linear B mystery and its final decipherment, but never in so much detail. That was fun. Now, when will there be something similar for the Iberian language...
I love John Chadwick's original The Decipherment of Linear B. It's my favorite book of all time for its nostalgic value. A taut detective story about science and discovery, following the evidence with great integrity even when it challenges your own assumptions and established dogma, how intelligence and insight can transfer domains (Ventris was an architect by training), the value of open scientific collaboration - and the knowledge rewards we can earn when we aspire to these values.
Later books did a much better job shining a light on Ventris' collaborators, in particular the scientifically far more rigorous Alice Kober (e.g. The Riddle of the Labyrinth), but I will never forget reading Chadwick with 14, or thereabouts, and feeling profoundly affected. A formative read, even if the actual state of science on Linear B is quite a bit more complicated!
Probably because changing the software to use a different read pattern is doable in a few weeks/months on your existing systems, and changing anything in the flash controller is a wicked project probably only available to hardware manufacturers, and which will take months to years given the immensely slower hardware iteration cycles (even if it's "just" firmware changes).
Beautiful. Also, after 30+ years of writing C and C++, I learned one thing by casually browsing the source code: you can use a preprocessor macro in an #include statement. Thanks.
I used it to include architecture-specific source code and also a generated C file containing a table of Linux system calls defined by the Linux UAPI lone is compiled against.
The makefile defines those macros by passing flags:
Oh so it's a GCC-specific thing... that explains it. In any case, congratulations on the lisp! It's beautiful code. I wish my current codebase was that beautiful. I mean, it's a lot of us contributing to it so the beauty is a kind of "meeting of the minds" situation... but still :)
PS: My current project implements a lisp... rendered as JSON. Some other angle on beauty...
I have written and been using that same smart pointer type for years, under the pretty horrible name of holder_cloner_t<> (at least it's clear). It is indeed the right solution to a very common and important type of problem. Looking forward to something like this in the standard library one of these decades.
