Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modernizing the OpenBSD Console

cambus.net

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Modernizing the OpenBSD Console

#31

Post by JdeBP »

mjg59 wrote: post #25
JdeBP wrote: post #24

Earlier quoted context omitted.

It's the sort of optimization that one can read about in games and DirectX programming books. A better optimization comes with the realization, as MacOS people had many years ago, that copying from system memory to video memory is slow. So one instead pre-loads the glyphs into off-screen video memory, possibly on-demand, and then uses the display hardware to blit them into the on-screen part. Of course, this requires…

GOP functions aren't available after ExitBootServices() has been called, so the kernel doesn't get to take advantage of Blit() - the assumption is that the kernel will have a native driver for the hardware. Additionally, you can't really use off-screen graphics RAM in the EFI environment because GOP doesn't tell you how much video RAM is actually available, only the size of the framebuffer. You can guess which PCI de…

Hah! I've been doing too much load-time stuff, obviously. (-:

But if one is looking at PCI device IDs, then one is already at the level of the code having detailed knowledge of the specific hardware (even if only via some "miniport"-like system) and the point stands.

Re: Modernizing the OpenBSD Console

#32

Post by JdeBP »

Aloha wrote: post #14

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

Almost certainly not, but on the other hand there are people who conversely enjoy proper boldface and italics, as Unix text processing tools encompassed pretty much from the get-go; or more than 256 different glyphs in use at once, with none of that faffing about with loadable Unicode-to-8-bit character maps; or MouseText. (-:

Re: Modernizing the OpenBSD Console

#33

Post by mjg59 »

JdeBP wrote: post #31
mjg59 wrote: post #25

Earlier quoted context omitted.

GOP functions aren't available after ExitBootServices() has been called, so the kernel doesn't get to take advantage of Blit() - the assumption is that the kernel will have a native driver for the hardware. Additionally, you can't really use off-screen graphics RAM in the EFI environment because GOP doesn't tell you how much video RAM is actually available, only the size of the framebuffer. You can guess which PCI de…

Hah! I've been doing too much load-time stuff, obviously. (-: But if one is looking at PCI device IDs, then one is already at the level of the code having detailed knowledge of the specific hardware (even if only via some "miniport"-like system) and the point stands.

Oh, you can look at the device that the GOP instance is bound to and get the PCI device from there. At that point you just walk the BARs looking for one that's mapped in a region that covers the framebuffer address that GOP gives you. This doesn't require you to know anything about the device in question, and most of the time you'd probably get lucky by throwing glyphs in space that exists outside the framebuffer and blitting them onto the screen - up until you find a driver that implements blt() by using the 3D engine and mapping some buffer objects on top of the space you're trying to use.

Re: Modernizing the OpenBSD Console

#34

Post by formerly_proven »

saagarjha wrote: post #8

Interestingly, some of the newer commits seem to have come from John Carmack. While it's not quite related to consoles, I've noticed that the non-GUI interface to a lot of operating systems often don't get a lot of love. Linux has had a fairly nice boot scroll, but I think part of that is because it's become an icon and as such is part of the public face of the OS; but on macOS for example it's an tiny awful experien…

At least on pictures HP 9000 / HP-UX "boot scroll" looks the nicest: https://blog.pizzabox.computer/img/hp712/hpux-init.png https://upload.wikimedia.org/wikipedia/commons/thumb/8/87/HP...

Re: Modernizing the OpenBSD Console

#35

Post by formerly_proven »

JdeBP wrote: post #26
watersb wrote: post #3

Earlier quoted context omitted.

The article uses 32 bits per pixel to illustrate the growth in performance requirements: > In framebuffer however, to fill a 4K UHD-1 (3840x2160) screen in 32bpp mode we need to send 3840 * 2160 * 4 bytes of data, which is 33177600 bytes (approximately 33 MB). but I don't know if that is in fact the definition a "framebuffer console" versus a terminal that uses character addressing. That's a different issue that actu…

The "I" in "ITU" does not stand for "ANSI". (-: * https://itu.int/rec/T-REC-T.416 As M. Kochkov will attest, supporting 24-bit RGB (or even 32-bit ARGB) colour involves (a) recognizing and processing the new (sic!) control sequences from the 1990s, and (b) actually supporting having the display hardware in a non-palettized true colour mode (as opposed to using a 256-colour palettized mode and pretending). The definit…

I expect none of this (text mode, indexed colors, 16 bpp, hardware GDI/2D etc.) actually exists in hardware any more. I expect GPUs emulate all of this through shaders baked into the VBIOS/driver.

Re: Modernizing the OpenBSD Console

#36

Post by protomyth »

brobdingnagians wrote: post #30
mgreenleaf wrote: post #27

Earlier quoted context omitted.

Not sure if this counts, but I use it in production in yakdocs.com and yak-mu.com. I love how easy it is to maintain and I love the pf firewall. Hetzner has images for OpenBSD on their cloud service and you can use a custom image on the dedicated servers.

Vultr also has support for OpenBSD

Works well too. We've moved a lot of boxes from local to them. I do wish their console supported cut and paste on a Mac.

Re: Modernizing the OpenBSD Console

#37

Post by hnlmorg »

abrookewood wrote: post #12
saagarjha wrote: post #8

Interestingly, some of the newer commits seem to have come from John Carmack. While it's not quite related to consoles, I've noticed that the non-GUI interface to a lot of operating systems often don't get a lot of love. Linux has had a fairly nice boot scroll, but I think part of that is because it's become an icon and as such is part of the public face of the OS; but on macOS for example it's an tiny awful experien…

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.

Re: Modernizing the OpenBSD Console

#38

Post by rbanffy »

saagarjha wrote: post #8

Interestingly, some of the newer commits seem to have come from John Carmack. While it's not quite related to consoles, I've noticed that the non-GUI interface to a lot of operating systems often don't get a lot of love. Linux has had a fairly nice boot scroll, but I think part of that is because it's become an icon and as such is part of the public face of the OS; but on macOS for example it's an tiny awful experien…

> you'd think Apple would be the first one to fix this…

To be fair, they have one of the very few terminal apps that support double-width/height characters and that passes the VT torture test with flying colors.

Re: Modernizing the OpenBSD Console

#40

Post by jlgaddis »

TimSchumann wrote: post #4

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

I used OpenBSD in production at my previous job (an ISP), in a few different roles. Lots of ISPs use OpenBSD for various purposes.

HSMs from nCipher used to run on top of (a slightly modified, IIRC) OpenBSD. Just as JunOS (the OS on (some) Juniper network devices) runs on FreeBSD, I'm sure there are many other commercial products built on OpenBSD as well -- we just don't hear about them very much.

---

Related (from the same author as this submission): "Why OpenBSD?" [0].

---

[0]: https://www.cambus.net/why-openbsd/

Post reply on HN