It's so cool to see more terminal(-adjacent) experiments! We're overdue in evolving this space.<p>Self-plug: last month I demoed [0] my own terminal. The goal is to dispense with traditional shells and see what happens. It generated quite a bit of hooplah, with a 50-50 split on how people felt about it.<p>I'll keep an eye on Fui; might come in handy for future Linux builds.<p>[0] <a href="https://terminal.click/posts/2025/04/the-wizard-and-his-shell/" rel="nofollow">https://terminal.click/posts/2025/04/the-wizard-and-his-shel...</a>
Can someone explain what “the framebuffer” is? I’m familiar with OpenGL programming where the OS can provide a framebuffer for an application but I’m confused about whether there is a global framebuffer for the entire desktop. Is this a Linux specific concept?
Awesome! Reminds me of the good old days of QuickBasic and SCREEN 13, when you could write very small programs with fullscreen graphics.<p>I still have not figured out how to do fullscreen graphics on my Mac.
Don't type commands from the Internet, especially as root, especially when dd is involved. That being said,<p>If you're ever bored, from a TTY, type<p>sudo dd if=/dev/urandom of=/dev/fb0<p>This provides a nifty demonstration of how both the framebuffer and urandom works.<p>you can also take a sort of "screenshot" in a tty by typing dd if=/dev/fb0 of=./shot.fb<p>and then you can view it by flipping those filenames around, so that the shot.fb is now the input and /dev/fb0 is now the output.
This kind of thing begs to be run bare metal (no Linux fbdev using modern 3D GPU with a complex driver stack under the hood). Or some small RTOS at most.