Fue en los 90 cuando llegaron las tarjetas de sonido dedicadas a nuestros ordenadores. El problema era que su firmware era privativo. El controlador del sistema operativo podía ser libre, pero el software dentro de las tarjetas tenía una licencia que se puede resumir en “ni se mira ni se toca”. Por eso es una buena noticia que el proyecto Sound Open Firmware se integre dentro de The Linux Foundation y se trata de un firmware de procesamiento de señal digital (DSP) y un SDK para los desarrolladores.
Comentarios
Lo que haría falta es impulsar de manera seria el hardware libre, sobre todo de los componentes críticos, sin eso no hay forma teórica de estar seguros sobre el control de nuestro sistema y nuestra información, como hemos venido descubriendo estos meses
#1 Que un programa sea software libre no te asegura que los binarios que distribuyen se correspondan con el código fuente publicado. La solución en ese caso es compilarlo tú mismo.
En el mismo sentido el hardware libre no te asegura que el producto que distribuyen se corresponda con el diseño publicado. Buena suerte fabricandote tu propio microprocesador de 14 nanómetros.
#13 en absoluto es necesario que lo compiles tú para asegurar que lo que obtienes es lo mismo que la fuente, lo mismo se aplica para el hardware
#14 En absoluto puedes saber si el binario tiene como origen el código fuente publicado, lo mismo se aplica para el hardware.
#15 ni siquiera te molestas en preguntar a qué me refiero, ya haces la payasada de imitarme para negar lo que digo?
pues a lo que me refiero es que no es necesario que seas tú quien compile la fuente porque pueden ser sistemas centralizados de confianza los que compilen y tú simplemente verificar con hashes, este sistema es ampliamente usado hoy en día por si no lo sabías
suerte con la arrogancia
#16 Conozco los binarios determinísticos con hashes y también conozco que son la excepción a la norma, que no los utiliza ni el tato salvo en ámbitos muy específicos como las criptomonedas. Y también sé que cuando la gente se descarga el binario LibreOffice no tiene ninguna forma de saber si ese binario se corresponde con el código fuente publicado, por que la gente de LibreOffice como todo el mundo en general no hace binarios determinísticos.
Y en los binarios determinísticos o bien lo compilas tú para verificar que el código fuente coincide con el binario, con su hash, o tienes que confiar en que lo hagan otros por ti y confiar en que no te mienten.
Si hubieras indicado que te referías a esto en vez de hacer una afirmación categórica vacía de contenido mi respuesta habría sido más completa.
Y una vez aclarado que para los binarios determinísticos se pueden hacer firmas criptográficas ahora nos puedes explicar como coño se fabrica hardware de forma determinística y como coño haces un hash criptográfico de un producto fabricado.
Anda, a ver si sigues teniendo la arrogancia de ponerle magia a la realidad para que encaje con tus prejuicios.
#17 y sigue subidito el chaval, te crees superior a algunas personas por lo que veo, humildad máxima
pues no, a lo que me refería es al uso de terceras entidades de confianza que sean quienes compilen desde fuente, es lo que toda distro con repo propia hace, señor humilde, por si no lo sabía usted, aunque disculpe usted por afirmar eso ya que claramente lo sabe usted todo 👍
y como no preguntas nada sino que te dedicas a afirmar y a ensalzar tus aires de superioridad vuelves a hacer el ridículo, no me refería al uso del mismo método en el hardware sino otros métodos, puedes preguntarle a entidades militares cómo vigilan que el hardware comprado no es manipulado por entidades de espionaje enemigas
pero no preguntarás, te volverás a hacer el arrogante, para tí preguntar es una humillación, impensable que no sepas algo
#18 Ah, vale, ahora entiendo a que te refieres, ahora entiendo que te refieres a algo de lo que no tienes ni idea.
Cuando compilas desde código fuente el binario obtenido puede ser distinto, de hecho suele serlo, si se compila en maquinas distintas. No se obtiene el mismo binario ni el mismo hash aún partiendo del mismo código fuente. Esto es algo que cobró importancia como digo en las criptomonedas, donde la confianza en el software es mucho más relevante al mover valor. Y para dar solución a ese problema usaron compilaciones determinísticas, que básicamente es compilarlo en una VM Qemu o similar donde el hardware que ve el compilador es virtual y por lo tanto sí es idéntico, y el binario resultante también.
Es un proceso engorroso y lento, poco práctico, por eso se utiliza muy poco.
No es intuitivo pensar que del mismo código fuente se puedan compilar binarios que no son idénticos pero esa es la realidad, la cruda realidad.
me refería al uso del mismo método en el hardware sino otros métodos
Sí, ya te he entendido la primera vez, te referías a magia. No tienes ni idea de como se podría hacer pero tu imaginación mágica te lleva a pensar que los militares tienen tecnología secreta que lo hace de forma mágica, solo por que te gustaría que fuera así.
Quizá no sea arrogancia si no tener poco contacto con la realidad, lo desconozco.
#19 y sigues haciéndote el payaso
la comparación de hashes es solo para verificar que obtienes lo mismo que ha compilado la máquina de confianza central, no entiendo por qué le das tantas vueltas, es muy sencillo, una máquina que se declare de confianza porque ejecute un compilador monitorizable y en general no tenga ninguna circunstancia que genere desconfianza compila el paquete y se distribuye, es que no tiene más
y la magia militar a la que te refieres no es más que vigilancia personal, sorprende verdad? Estás tan metido en el mundo que le buscas mil vueltas y enrevesamiento a cosas tan sencillas y usadas
#20 Esto es lo que yo dije y a lo que tú respondiste negándolo:
Que un programa sea software libre no te asegura que los binarios que distribuyen se correspondan con el código fuente publicado. La solución en ese caso es compilarlo tú mismo.
Y ahora en este último comentario nos dices que sabes que es lo mismo por que confías en una máquina central de alguien de confianza en quien confías que habrá compilado ese código fuente y habrá obtenido un binario de su confianza en el que tú confías por que confías en la persona de confianza que ha compilado ese binario en esa máquina de confianza.
En resumen, que un programa sea software libre no te asegura que los binarios que distribuyen se correspondan con el código fuente publicado.
Y para hardware es aún más surrealista, nos dices que tenemos que confiar en que un militar esté siguiendo el proceso y vea él que todo se hace según el diseño para que luego nosotros confiemos en ese militar para "saber" que el diseño se corresponde con el harware producido.
Demencial.
Vaya troleada te has marcado campeón.
#21 no confías en esa máquina? No lo descargues de ahí, busca una máquina en la que puedas confiar, y si no la encuentras te montas tu propia máquina y compilas ahí, y para ahorrar tiempo y energía a los demás puedes compartir tus compilaciones. Si eres extremadamente escéptico te lo compilas tú mismo, pero implica un esfuerzo extra que depende de la persona le interesa o no, normalmente a la gente le conviene más la confianza estadística que el escepticismo máximo que en la práctica no lleva a ningún lado.
Estás diciendo que no confías en ninguna máquina? En la tuya sí? En una que montéis tu amigo y tú sí? Cuál es el punto en el que dejas de confiar?
nos dices que tenemos que confiar en que un militar esté siguiendo el proceso y vea él que todo se hace según el diseño para que luego nosotros confiemos en ese militar para "saber" que el diseño se corresponde con el harware producido.
Demencial.
Te parece demencial lo que se hace y se ha venido haciendo en todos los países potencias militares? Tanto en vigilancia de fabricación como en auditorías nucleares en los tratados de desmantelamiento? Vaya
Puedes llamarlo troleada si quieres, desde luego está claro que conversar con gente tan tóxica que no admiten un mínimo de conversación ni duda no conviene en absoluto
#22 y si no la encuentras te montas tu propia máquina y compilas ahí
No jodas, ¿eso se puede hacer?
Jamás lo hubiera imaginado ... Que un programa sea software libre no te asegura que los binarios que distribuyen se correspondan con el código fuente publicado. La solución en ese caso es compilarlo tú mismo.
Te parece demencial lo que se hace y se ha venido haciendo en todos los países potencias militares? Tanto en vigilancia de fabricación como en auditorías nucleares en los tratados de desmantelamiento? Vaya
Me parece demencial que propongas eso como "alternativa" a reconocer la veracidad de esta frase:
En el mismo sentido el hardware libre no te asegura que el producto que distribuyen se corresponda con el diseño publicado. Buena suerte fabricandote tu propio microprocesador de 14 nanómetros.
#23 es como decir que te parece demencial sugerir en confiar en la palabra de vigilantes en... un proceso electoral
en fin
#24 Que un programa sea software libre no te asegura que los binarios que distribuyen se correspondan con el código fuente publicado. La solución en ese caso es compilarlo tú mismo.
En el mismo sentido el hardware libre no te asegura que el producto que distribuyen se corresponda con el diseño publicado. Buena suerte fabricandote tu propio microprocesador de 14 nanómetros.
Lo que nunca he entendido es porqué los distintos subsistemas de los ordenadores no "hablan" en lenguajes normalizados (OpenGL, OpenAL, Vulkan, DirectX, ...)
#2 Bueno OpenGL ha sido el estándar durante montones de años.
DirectX de Microsoft es el que no ha sido nunca estándar. Y no, un software que funciona solo en un solo SO de una sola arquitectura no es estándar se mire por donde se mire.
OpenAL es una librería multiplataforma de audio.
#3 No he puesto DirectX como multiplataforma si no como norma de facto (durante demasiados años).
En cuanto a OpenAL, ya sé que es una librería de audio Pero igualmente hay un subsistema de audio en cada equipo, aunque vaya empotrado en la placa base.
#4 Una "Norma de facto" en un único SO en una única arquitectura no es un lenguaje normalizado, estándar o como lo quieras llamar.
Lo siguiente a OpenAL en la cadena no es el subsistema de audio empotrado en la placa base, si no el servidor de audio del SO.
En el caso de Windows el "Servicio de Audio de Microsoft Windows" o sistemas de audio profesionales como ASIO.
En el caso de Linux tienes OSS, ALSA, y por encima JackD, ARTS, ESD, Pulse audio, etc...
#5 Lo sé. Pero, por desgracia, cuando alguien tiene el 90ypico% de los equipos de escritorio (recuerda cuando Apple casi se va al carajo, por ejemplo), lo que ponga como "norma" ese alguien pasa a ser el "standard" aunque sea a la fuerza. Da igual que no siga una definición ortodoxa de lo que es una norma.
Personalmente encuentro que Direct3D nunca debió llegar a salir, teniendo en cuenta que fue una puñalada trapera a OpenGL (quien quiera, que busque información sobre el proyecto Fahrenheit entre Microsoft y Silicon Graphics)
#6 "el 90ypico% de los equipos de escritorio"
Eso lo hace una característica usada por muchos equipos, no una norma.
Las DirectX son tan norma como cola de impresión o el sistema de sonido de de Windows.
Algo que solo se usa en un único SO y en una única arquitectura no es automáticamente una norma.
Si fuese la única puñalada trapera de MS... pero hay donde escoger.
#7 Ya sé que es exclusivo de los distintos Windows, pero de cara a los fabricantes, lo lógico es que las tarjetas de vídeo tragaran también Direct3D de manera nativa. Al menos mientras siga teniendo un porcentaje alto de uso.
En cuanto a puñaladas traperas de MS, sí, se pueden escribir muchos libros sobre eso.
#8 Ya pero las tarjetas de video históricamente han soportado a nivel hardware primitivas OpenGL.
El soporte de DirectX sin embargo ha sido con wrappers de software.
El API OpenGL es mucho más simple y se puede integrar bastante bien en las GPUs, DirectX imposible por que es mucho más que primitivas y transformaciones.
#9 Bueno, tal y como yo creo que funcionan, entiendo que no sería demasiado difícil, de un tiempo a esta parte, meter en la propia tarjeta un traductor para que trague OpenGL, Direct3D, Vulkan o lo que le echen hasta una versión concreta. Entiendo que cuando empezaron las tarjetas 3D poca potencia de sobra había para que pudieran gastarla haciendo de traductoras.
En cuanto a que las TdV hayan soportado a nivel HW las primitivas de OpenGL ¿entonces cómo es que hacía/hace falta un driver entre la tarjeta y el SO para que trague OpenGL? ¿No valdría con que el SO le enviara las primitivas y se ahorra el paso intermedio?
Nota: no soy especialista en el tema, ojo. Sólo es un tema que me interesa.
Dicho de otra manera: mover el driver de vídeo dentro de la tarjeta y que la interfaz con la misma sea independiente del SO (no sé si me explico).
#10 Sí es dificil por que DirectX (Direct 3D) es prácticamente un motor 3D entero. Es decir, no meten solo la parte gráfica 3d de primitivas, texturas y transformaciones.
Las últimas versiones meten mucha funcionalidad que habitualmente vienen del lado del Juego. Son cosas que se siguen haciendo por software, pero al meterlo dentro de Direct3D los juegos que lo usan crean una dependencia que de otra forma no estaría ahí.
Que es precisamente lo que mejor se le da hacer a MS, crear mercados esclavos que una vez que estás dentro es complicado salir por que tienes que tirar la mitad del trabajo.
#11 Vale. Me estaba basando en lo que leí en su día sobre Direct3D (las primeras versiones). Después no me he interesado demasiado por las tripas de D3D (ni ganas).
Gracias por la información.
Y es verdad que suena al EEE habitual de MS.