Imagen tomada del sitio: https://upload.wikimedia.org/wikipedia/en/thumb/5/5c/NetBSD.svg/300px-NetBSD.svg.png
Buenos días/tardes/noches estimados blurtters que les gusta el Open-Source!
A continuación posteamos una traducción de un posts de interes.
Mayo 04, 2024 posteado por Nia Alarie en el sitio (https://blog.netbsd.org/tnf/entry/x_org_on_netbsd_the)
Hace algunos años, Escribí un post en mi blog del "estado de las cosas " con respecto a Wayland en NetBSD. Es natural que debía hacer un post sobre X11, el cual es usado por mucha más gente como ambiente gráfico en NetBSD.
Hay una gran cantidad de diferencias desde cómo NetBSD y el distribuidor público vienen con X.Org. Para uno, nosotros lo incluimos como un paquete opcional monolítico en vez de paquetes separados e individuales. Esto significa que cada controlador está incluido en cada sistema, en vez de estar como un módulo opcional. Algunas veces, esto significa que necesitamos una selección de controlador ajustado de forma granular para asegurar que el controlador correcto es cargado en el hardware correcto, desde que múltiples controladores en conflicto pueden reclamar una salida de video. También se busca tener una recuperación en caso de fallos que sea sensible, dado que se está usando un GPU del futuro con una versión antigua del sistema operativos, probablemente querrá que X silenciosamente caiga en framebuffer regular conocido.
En Segundo lugar, la manera en que nuestro repositorio "xsrc" está configurado, está funcionando efectivamente como un fork o trabajo derivado de X.Org que regularmente jala del sitio principal freedesktop.org (pero no sube de regreso). Esto permite a desarrolladores X existan como parte de NetBSD.
En tercer lugar nosotros usamos nuestro propio Sistema de compilación basado únicamente en archivos makefiles BSD, no en X.org basado en autotools de GNU. Esto se ajusta bien a nuestro sistema de compilación cruzada build.sh.
Tenemos un buen número de controladores que no han podido ser subidos a la fuente principal de X.org. Quizas el más ubicuo de estos sea xf86-input-ws, un controlador que viene desde OpenBSD, apunta a una API desde NetBSD, y continua siendo desarrollador en ambos. Este es un controlador genérico de entrada que puede soportar cualquier dispositivo apuntador que soporte el kernel. A diferencia del xf86-input-mouse, éste no assume que el dipositivo es un mouse, y puede soportar características avanzadas de touchpad y touchscreen. Otras exclusivas de NetBSD incluyen xf86-video-pnozz, xf86-video-mgx, y xf86-video-crime. Mientras que todas éstas comparten el nombre "xf86" heredado de la histórica distribución XFree86 ninguna de ellas son exclusivas para la arquitectura x86.
Hay un número de controladores que son acelerados cuando se usan en NetBSD, pero el soporte de aceleración se puerde en la fuente principal de código. Esto es debido principalmente al trabajo de macallan@, quien ha trabajado diligentemente en controladores para aceleradores gráficos encontrados en hardware SPARC y PowerPC.
X.Org ha soportado históricamente dos aceleradores 2D modos, XAA y EXA. XAA se ve complicado – de acuerdo a la fundación X.Org éste soporta "relleno de patrones y líneas Bresenham" (eh?). XAA fue eño,omadp desde el servidor X.Org en 2012, y muchos controladores antiguos no fueron actualizados para soportar el módelo más simple y nuevo EXA, excepto en NetBSD, durante un periodo de tiempo de varios años.
Sabías que Nvidia solía tener un controlador de código abierto? Ese controlador soportaba aceleración 2D para un rango de tarjetas. En NetBSD, está retenido para plataformas que incluyen chips embebidos de Nvidia y que no son capaces de (o son de fecha anterior, o no quieren) el controlador moderno novuea. Hace seis años, fue actualizado en NetBSD para soportar aceleración EXA.
Hay algunas maneras en las que nuestra integración X puede ser mejorada. Mientras que mucha atención se ha dirigido a los servidores, se ha dejado de prestart atenció a clientes (programas). Sabías que X incluye un editor de texto, y que ese editor soporta resaltado de sintáxis y verificación de ortografía?
NetBSD incluye su propio verificador de ortografía de línea de comando y diccionarios asociados, spell(1), heredado desde el UNIX BSD de antaño. Es muy básico, y solo soporta variaciones de Inglés. Para lograr que la verificación de ortografía function en xedit, usted necesita instalar ispell (otro verificador de ortografía de línea de comando) desde pkgsrc, instale un diccionario, entonces asigne algunos Xresources (o cree ligas simbólicas (symlinks)) para asegurarse que xedit encuentre a ispell. Esto podría ser colocado en la corriente principal por medio de enseñar a xedit sobre ispell.
También empacamos cada programa que ha sido incluido históricamente en las distribuciones X.Org. Esto incluye cosas bien conocidas como xterm, o cosas ligeramente menos conocidas como xbiff(1), y cosas algo oscuras como bitmap(1) (aparentemente una alternativa de 1-bit-por-pixel al MS Paint). Hace un tiempo, se eliminaron algunas bibliotecas que no eran usadas ya por servidores X modernos, y tal vez deberíamos evaluar si estos programas también se necesitan. xmh(1) es un frontend para un Sistema de correo que no está incluido en la base. Juntos tanto, bitmap y xmh pesan unos 300 kilobytes.
Nosotros incluimos, fuentes, bitmaps y letras escalables, para un amplio rango de dispositivos de cómputo. En la última version de NetBSD, el tamaño de fuente escalará automáticamente con el tamaño de panalla para soportar displays HiDPI así como también dispositivos móviles pequeños. Sin embargo, nosotros no incluimos un tema de cursor escalable hasta el momento. También carecemos de los tipos de letra de alta resolución para Japones, una vergüenza considerando la popularidad de NetBSD en Japón. Koruri se ve interesante y es convenientemente pequeño, tal vez deberíamos importarlo.
Mientras que tenemos muchos programa útiles y simples por defecto (un reloj, una calculadora, un editor, un gestor de ventanas, un compositor, un emulador de terminal...), aún tenemos un problema al no tener un programa de bloqueo de pantalla para X en la instalación por defecto, a pesar de que tenemos lock(1) para la consola tty.
La gran pregunta – todo esto tiene algun futuro? La buena noticia es que todo hardware nuevo tiene soporte genérico en X. Alguno escribió un controlador modesetting de kernel o un controlador de kernel wsdisplay clásico y ellos serán automáticamente soportados por los controladores asociados en X. Las malas noticias es que para tener aplicaciones corriendo requerimos acceso a un ecosistema de código abierto más grande,y en ese ecosistema tiene muchas cosas revueltas y es fácil distraerse por nuevas ardillas brillantes. El proceso de subir código o cambios a a la corriente principa de X.Org es un proceso en marcha, pero es muy probable que terminemos viendo cosas que nunca serán convenientes para la corriente principal de desarrollo.
Desde luego, en NetBSD, puedes tener la opción de intentar el X.org modular vainilla desde pkgsrc, o usando algo completamente diferente.
Imágen tomada del sitio https://www.phoronix.net/image.php?id=bsd-linux-eo2021&image=bsd_eo2021_2_med
Bueno, les deseo éxito en todo lo que hagan en relación al software opensource.
Estamos a la espera de sus comentarios, hasta la próxima publicación donde continuaremos con más sobre NetBSD .
@cosmicboy123 fuera!
Si lo deseas puedes votar por mi como witness para poder aumentar las capacidades de un servidor.
https://blurtwallet.com/~witnesses?highlight=cosmicboy123
Integrate al grupo de Telegram de @team-mexico 😀 donde yo y otros usuarios de México y de otros países de habla hispana compartimos experiencias y opiniones así como nuestros propios posts. Una gran iniciativa de @cristo
| 👉Entra a https://t.me/TeamMexico 👈|