Should graphics be a topic of rigor in FreeBSD?

Should graphics be a topic of rigor in FreeBSD?

  • Sure!

    Votes: 24 68.6%
  • No..

    Votes: 7 20.0%
  • Meh, I don't care.

    Votes: 4 11.4%

  • Total voters
    35
IBM did not make GPU's.
Sorry, mistake. Should read Intel.

With FreeBSD, compiling graphics/drm-kmod will eventually give you the option to install the sources into /usr/src/ and work exactly the same. Too lazy to dig up the thread where I showed that.
FreeBSD does indeed boot up to a text terminal, and you can see crash messages along the way - all you have to do is NOT start X windows.
Yes, because it is the same device that is used as the primary console as well as the graphics screen. I still believe that the most simple and robust approach is to have two entirely different devices for these two things. But then only a few workstation owners would probably like that, while the vast majority of PC users, and even more the laptop and tablet users, have only one screen.
But even if you do, you can still type # dmesg to see the bootup messages and crashes. Everything you like is still there, and accessible.
They are accessible only as long as the system is still healthy enough to send kernel messages into userland. The fault behaviour that I have often seen is that the graphics screen becomes frozen, then for a while nothing happens, and then reboot. This will happen when e.g. the disk (swap space!) fails to read, and for a bunch of other reasons (mostly related to hardware failures). In these cases usually some printf() from the kernel would still appear on the console, and reading that could be helpful.

Oh, and Macs are descended from FreeBSD 4.4, BTW... Duh. :p
Yes. They are mostly Berkeley, and so I can find my way in the console if there is need to (there rarely is). And for anybody who does not want to (or does not have the skill to) do serious maintenance I still don't know anything better to suggest. Obviousely, when you do not or can not DIY, you have to find somebody whom you can pay for it. Is there a better option?
 
They are accessible only as long as the system is still healthy enough to send kernel messages into userland. The fault behaviour that I have often seen is that the graphics screen becomes frozen, then for a while nothing happens, and then reboot. This will happen when e.g. the disk (swap space!) fails to read, and for a bunch of other reasons (mostly related to hardware failures). In these cases usually some printf() from the kernel would still appear on the console, and reading that could be helpful.
/var/crash is where you go read error messages from boot failures. Of course, to make that possible, remove the hard drive that failed to boot, and use a healthy, working computer to mount that drive as read-only.

I still believe that the most simple and robust approach is to have two entirely different devices for these two things. But then only a few workstation owners would probably like that, while the vast majority of PC users, and even more the laptop and tablet users, have only one screen.
An educated guess on my part is that it's not impossible to pull off with Xorg or even Wayland - if you see your dmesg on Screen0, tell xorg.conf to launch everything on Screen1 (once it gets detected). 😩
 
Back
Top