3 ms·

As a note... you could dabble in OpenBSD and have what is in my opinion a much more stable experience

by geggam 8y ago

exikyut 8y ago
I've seen this sentiment repeated a lot. I recently learned that OpenBSD has a kernel-level debugger. That's really nice, and something that I've wished Linux would have had for a long time. I mean it makes so much sense - "the system's panicked, here, poke the hardware registers!" versus "and here we have a module that borrows 114 bytes from your real-time clock to write a hash of where the boot process is up to (and here's the accompanying tool that bruteforces what the hash even means), and over here we have some code that tries to print a QR code to the screen, oh and this module configures a TTY over the EHCI debug port, and over here we can set up early consoles over Ethernet, and...", and in the end you just give up and order/find legacy-compliant machines with RS232 headers hiding on the motherboard. On that note, that reminds me, OpenBSD is probably going to keep X hanging around for a long time. But that doesn't say much about driver support going forward. Hmm, I just poked around looking for licensing info for the Intel "Linux" drivers. They appear to be MIT (!), reading random files from https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/Makefile.genxml.am https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/Makefi... https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/blob/master/src/intel_device.c https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/... https://cgit.freedesktop.org/mesa/drm/tree/intel/intel_debug.h https://cgit.freedesktop.org/mesa/drm/tree/intel/intel_debug... And, conversely, I was very fascinated to see that this liberal license has already lead to exactly the kind of thing I'd have hoped for - perusing the history of a randomly picked file, https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/drm_crtc_helper.c https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/dr..., I see: > Update inteldrm(4) to code based on Linux 4.4.70. ... > Update inteldrm to the code from Linux 3.14.52 ... ... > Make use of recent drm_linux.h additions to further reduce the diff to linux. ... > use linux style memory allocations in shared drm code ... > Switch generic drm modesetting code over to Linux-style negative errno return values. That's very very cool. GPL was never that productive. :P With OpenBSD's Xenocara fork, X'll still be around for a while. (Uh, as an aside, shortening "X will" is weird, lol.)
- bitwize 8y ago
  In Linux, video drivers are moving to the kernel and there's been a push for this in the BSDs as well. Wayland was part of the impetus for this but it benefits X as well: with the modesetting driver and GLAMOR accelerator, Xorg will Just Work and be accelerated with whatever graphics hardware, old or new, the kernel supports.
  - exikyut 8y ago
    FWIW, GLAMOR doesn't work with the AMD R300 in my ThinkPad T43 (2006). :( Apparently it can work with the R3xx series chipsets, but mine doesn't like it for some reason.

As a note... you could dabble in OpenBSD and have what is in my opinion a much more stable experience

by geggam 8y ago

As a note... you could dabble in OpenBSD and have what is in my opinion a much more stable experience

I've seen this sentiment repeated a lot. I recently learned that OpenBSD has a kernel-level debugger. That's really nice, and something that I've wished Linux would have had for a long time. I mean it makes so much sense - "the system's panicked, here, poke the hardware registers!" versus "and here we have a module that borrows 114 bytes from your real-time clock to write a hash of where the boot process is up to (and here's the accompanying tool that bruteforces what the hash even means), and over here we have some code that tries to print a QR code to the screen, oh and this module configures a TTY over the EHCI debug port, and over here we can set up early consoles over Ethernet, and...", and in the end you just give up and order/find legacy-compliant machines with RS232 headers hiding on the motherboard. On that note, that reminds me, OpenBSD is probably going to keep X hanging around for a long time. But that doesn't say much about driver support going forward. Hmm, I just poked around looking for licensing info for the Intel "Linux" drivers. They appear to be MIT (!), reading random files from https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/Makefile.genxml.am https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/Makefi... https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/blob/master/src/intel_device.c https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/... https://cgit.freedesktop.org/mesa/drm/tree/intel/intel_debug.h https://cgit.freedesktop.org/mesa/drm/tree/intel/intel_debug... And, conversely, I was very fascinated to see that this liberal license has already lead to exactly the kind of thing I'd have hoped for - perusing the history of a randomly picked file, https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/drm/drm_crtc_helper.c https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/dr..., I see: > Update inteldrm(4) to code based on Linux 4.4.70. ... > Update inteldrm to the code from Linux 3.14.52 ... ... > Make use of recent drm_linux.h additions to further reduce the diff to linux. ... > use linux style memory allocations in shared drm code ... > Switch generic drm modesetting code over to Linux-style negative errno return values. That's very very cool. GPL was never that productive. :P With OpenBSD's Xenocara fork, X'll still be around for a while. (Uh, as an aside, shortening "X will" is weird, lol.)

bitwize 8y ago
In Linux, video drivers are moving to the kernel and there's been a push for this in the BSDs as well. Wayland was part of the impetus for this but it benefits X as well: with the modesetting driver and GLAMOR accelerator, Xorg will Just Work and be accelerated with whatever graphics hardware, old or new, the kernel supports.
- exikyut 8y ago
  FWIW, GLAMOR doesn't work with the AMD R300 in my ThinkPad T43 (2006). :( Apparently it can work with the R3xx series chipsets, but mine doesn't like it for some reason.