Live data from Hacker News

Modernizing the OpenBSD Console

cambus.net

41–50 of 62 posts

Re: Modernizing the OpenBSD Console

#41
What really disappoints me is that, with all those pixels, and bits per pixel we now have, it still can't have proper bold, italic, underline, overline, Tek graphics, sixels, and smooth scrolling like any ancient terminal made by any well regarded hardware company.

Re: Modernizing the OpenBSD Console

#42

Just curious, but does anyone know a business using OpenBSD in production other than the Pushover App?

Virtually everyone uses bits of OpenBSD. Android uses a lot of its C standard library, LLVM uses its regular expression library, and Windows 10 uses OpenSSH with LibreSSL. Armorlogic, Calyptix Security, GeNUA, RTMX, and .vantronix make network appliances based on the complete OS.

"OpenBSD Innovations": https://www.openbsd.org/innovations.html

Re: Modernizing the OpenBSD Console

#43
post #37

Earlier quoted context omitted.

If I recall correctly, there was an article on HN not so long ago about Carmack discovering BSD. Edit: found it - https://news.ycombinator.com/item?id=23224584

s/discovering/committing to/ Carmack has been aware of and actively involved in UNIX systems for a long time now. This isn't a recent discovery. However it has been recently noticed that he's committing to OpenBSD.

Contributing to OpenBSD, not committing. He is not a committer.. yet.

Re: Modernizing the OpenBSD Console

#44
post #41

What really disappoints me is that, with all those pixels, and bits per pixel we now have, it still can't have proper bold, italic, underline, overline, Tek graphics, sixels, and smooth scrolling like any ancient terminal made by any well regarded hardware company.

indeed :O

here are the VT100 ansi escape codes: https://espterm.github.io/docs/VT100%20escape%20codes.html

Bold, Underline, Double height, double width, etc... are all there. VT100, from 1978.

Re: Modernizing the OpenBSD Console

#45
post #41

What really disappoints me is that, with all those pixels, and bits per pixel we now have, it still can't have proper bold, italic, underline, overline, Tek graphics, sixels, and smooth scrolling like any ancient terminal made by any well regarded hardware company.

indeed :O here are the VT100 ansi escape codes: https://espterm.github.io/docs/VT100%20escape%20codes.html Bold, Underline, Double height, double width, etc... are all there. VT100, from 1978.

ncurses gives you all of that in a much easier-to-use fashion.

Re: Modernizing the OpenBSD Console

#46
post #37

Earlier quoted context omitted.

s/discovering/committing to/ Carmack has been aware of and actively involved in UNIX systems for a long time now. This isn't a recent discovery. However it has been recently noticed that he's committing to OpenBSD.

Contributing to OpenBSD, not committing. He is not a committer.. yet.

Apologies, I hadn't realised there were a distinction. What's the difference?

Re: Modernizing the OpenBSD Console

#47
post #46

Earlier quoted context omitted.

Contributing to OpenBSD, not committing. He is not a committer.. yet.

Apologies, I hadn't realised there were a distinction. What's the difference?

I guess it's about having a direct commit access to their CVS tree.

Re: Modernizing the OpenBSD Console

#48
post #46

Earlier quoted context omitted.

Apologies, I hadn't realised there were a distinction. What's the difference?

I guess it's about having a direct commit access to their CVS tree.

Precisely. OpenBSD developers have committed John's diffs.

Re: Modernizing the OpenBSD Console

#49
post #28
post #5

Earlier quoted context omitted.

Some of the code linked in the article seems to emulate the VGA style text console (1 value for char value, 1 value for color and attributes) and render it onto a 32bit framebuffer. The diffs that are attributed to Carmack seem to deal with this. scr->rs_bs[off].uc and scr->rs_bs[off].attr appear to represent the gylph and attributes/color respectively. So I would expect that would severely limit the amount of colors…

32 bits isn't really enough. One uses 24 bits for RGB, and the remaining 8 bits aren't really enough for the remaining graphics renditions that a modern terminal emulator should support. Factor in things like the KiTTY underlining system, invisible, the little-recognized new (sic!) ECMA-48:1991 graphic renditions (encircled, framed, and overlined), and strikethrough; and one actually needs 13 to 14 bits (depending fr…

> 32 bits isn't really enough. One uses 24 bits for RGB,

Yes, and as I mentioned you need to divide between FG and BG colors.

All a little moot because it seems to me like the code uses 3 bits for color.

> No-one doing this style of terminal emulator really does Unicode properly

Indeed, both multi-char and multi-codepoint glyphs. I also think the whole "matrix of glyphs" thing breaks down pretty severely when you want BiDi support for instance. The article mentions someone working on UTF-8 support. I wonder what that looks like.

Re: Modernizing the OpenBSD Console

#50
post #29
post #14

am I the only one who prefers a non-framebuffer console?

I hate the framebuffer console on most of the systems I have. In some cases, the font is way too small. Changing the font size is confusing, because it isn't clear what size of text you will end up with. And on some of the systems I have, the framebuffer scrolls so slow !!!!! Drives me up a wall. If it takes more than a tiny fraction of a second to display an entire screen of text, that is too slow!!!! Hate it, hate…

Sun workstation framebuffer consoles were like this. Slow scrolling! I'm thinking mainly of Sun-3's and early SparcStations...
Post reply on HN