Aún en octubre de 2022, todavía faltan meses para el lanzamiento de Debian 12, la que será la próxima versión de uno de los sistemas operativos más importantes de los existentes en Linux. Como todos los lanzamientos, el 12º también tendrá un nombre de un personaje de la saga Toy Story, el del gusano Bookworm. Más tarde, sobre los dos años después, llegará Trixie, y unos 48 meses después se lanzará otra versión, en este caso un Debian 14 del que ya se ha dado a conocer su nombre en clave.

He de reconocer que, sin ser un fan de la saga, tengo que buscar en internet imágenes para saber qué personaje da nombre a una nueva versión de Debian, e incluso que el mismo motivo me impedía saber de dónde se sacaban los nombres hasta pasados varios años. Es algo que hice con Bullseye, Trixie y ahora con Forky, el puntiagudo personaje que dará nombre a Debian 14. Para los que hablen sólo español y no dominen tampoco el inglés, decirles que «Forky» vendría a ser el diminutivo de «tenedor», lo que quedaría algo así como «Tenedorcito».

Aún faltan más de cuatro años para el lanzamiento de Debian 14

Ahora mismo, la versión estable más actualizada es la de Debian 11, concretamente 11.5. La siguiente versión mayor será Debian 12.0, programada para 2023. Trixie llegará en 2025, y Forky llegará pinchando ya en 2027. En donde han anunciado el nombre de Debian 14 también han hablado del próximo Debian 12, confirmando el 12 de enero como fecha para la transición y la toolchain freeze.

En cuanto a las novedades que traerá Debian 14, pues os podréis imaginar; es virtualmente imposible avanzar nada. Lo que sí es seguro es que incluirá software más que probado, lo que hace que Debian sea más estable que otras distribuciones como su hijo favorito, Ubuntu. Con esto no quiero decir que Ubuntu no sea estable, sino que Debian lo es más por su filosofía. Por lo tanto, usará el último kernel LTS, si éste lleva meses disponible, y escritorios con varias actualizaciones de mantenimiento ya a sus espaldas.

from Linux Adictos https://ift.tt/Mhx5B3P
via IFTTT

El código de hardware BIOS para los procesadores Intel Alder Lake fue publicado en 4chan

Hace pocos días en la red se había dado a conocer la noticia sobre la filtración del código UFEI de Alder Lake de Intel en 4chan y que posteriormente se publicó una copia en GitHub.

Sobre el caso Intel, no se postuló al instante, pero ahora ya ha confirmado la autenticidad de los códigos fuente del firmware UEFI y BIOS publicados por una persona desconocida en GitHub. En total, se publicaron 5,8 GB de código, utilidades, documentación, blobs y configuraciones relacionadas con la formación de firmware para sistemas con procesadores basados ​​en la microarquitectura Alder Lake, lanzados en noviembre de 2021.

Intel menciona que los archivos relacionados están en circulación desde hace unos días y como tal la noticia está siendo confirmada directamente de Intel, que menciona que desea señalar que el asunto no implica nuevos riesgos para la seguridad de los chips y de los sistemas en los que se utilizan, por lo que hace un llamado a no alarmarse sobre el caso.

Según Intel, la filtración ocurrió por culpa de un tercero y no como resultado de un compromiso en la infraestructura de la empresa.

«Nuestro código UEFI patentado parece haber sido filtrado por un tercero. No creemos que esto exponga nuevas vulnerabilidades de seguridad, ya que no confiamos en la ofuscación de la información como medida de seguridad. Este código está cubierto por nuestro programa de recompensas por errores dentro del Project Circuit Breaker , y alentamos a cualquier investigador que pueda identificar vulnerabilidades potenciales a llamar nuestra atención a través de este programa. Nos estamos acercando tanto a los clientes como a la comunidad de investigación de seguridad para mantenerlos informados sobre esta situación». — Portavoz de Intel.

Como tal no se especifica quién se convirtió exactamente en la fuente de la fuga (ya que por ejemplo los fabricantes de equipos OEM y las empresas que desarrollan firmware personalizado tenían acceso a las herramientas para compilar el firmware).

Sobre el caso, se menciona que el análisis del contenido del archivo publicado reveló algunas pruebas y servicios específicos de los productos Lenovo («Lenovo Feature Tag Test Information», «Lenovo String Service», «Lenovo Secure Suite», «Lenovo Cloud Service»), pero la participación de Lenovo en la fuga de información también reveló utilidades y bibliotecas de Insyde Software, que desarrolla firmware para OEM, y el registro de git contiene un correo electrónico de uno de los empleados de LC Future Center, que produce computadoras portátiles para varios OEM.

Según Intel, el código que entró en acceso abierto no contiene datos confidenciales ni componentes que puedan contribuir a la revelación de nuevas vulnerabilidades. Al mismo tiempo, Mark Yermolov, que se especializa en investigar la seguridad de las plataformas Intel, reveló en el archivo publicado información sobre registros MSR no documentados (registros específicos del modelo, utilizados para la gestión, rastreo y depuración de microcódigos), información sobre la cual cae bajo un no -acuerdo de confidencialidad.

Además, se encontró una clave privada en el archivo, que se usa para firmar digitalmente el firmware, que potencialmente se puede usar para eludir la protección Intel Boot Guard (no se ha confirmado el funcionamiento de la clave, es posible que se trate de una clave de prueba).

También se menciona que el código que entró en acceso abierto cubre el programa Project Circuit Breaker, lo que implica el pago de recompensas que van desde $500 hasta $100,000 por identificar problemas de seguridad en firmware y productos Intel (se entiende que los investigadores pueden recibir recompensas para informar sobre vulnerabilidades descubiertas mediante el uso de los contenidos de la fuga).

“Este código está cubierto por nuestro programa de recompensas por errores dentro de la campaña Project Circuit Breaker, y alentamos a cualquier investigador que pueda identificar vulnerabilidades potenciales a que nos las comunique a través de este programa”, agregó Intel.

Finalmente cabe mencionar que sobre la filtración de los datos el cambio más reciente en el código publicado tiene fecha del 30 de septiembre de 2022, por lo que la información dada a conocer es actualizada.

from Linux Adictos https://ift.tt/1MQCNTw
via IFTTT

Vectis IP anuncia convocatoria de patentes para el códec Opus

Hace poco se dio a conocer mediante una publicación de blog, que la empresa de gestión de propiedad intelectual Vectis IP ha anunciado el inicio de un grupo de patentes para licenciar tecnologías utilizadas en el códec de audio Opus.

Se menciona que la próxima licencia del conjunto de patentes cubrirá el códec de voz y audio interactivo Opus, según lo definido por el Grupo de Trabajo de Ingeniería de Internet. Los participantes iniciales en el posible grupo de Vectis IP incluyen a Fraunhofer y Dolby.

Sobre Opus

Para quienes desconocen de este codec, deben saber que hace 10 años, Opus fue estandarizado (RFC 6716) por el IETF (Internet Engineering Task Force) como un códec de audio libre de regalías para aplicaciones de Internet y no interfiere con tecnologías propietarias.

Sobre el caso, Vectis IP tiene la intención de cambiar el estado de licencia de patente de este códec y ha comenzado a aceptar solicitudes de empresas que poseen patentes que se superponen con las tecnologías Opus.

“Nos complace actuar como administradores en el desarrollo de este importante grupo de patentes que tiene como objetivo respaldar el acceso eficiente, justo y transparente a cientos de patentes que cubren tecnologías utilizadas en el códec Opus”, dijo Giustino de Sanctis, director ejecutivo de Vectis IP. “Las tasas de regalías razonables de este grupo equilibrarán los intereses tanto de los innovadores del programa como de los fabricantes de dispositivos de usuarios finales cuyos productos se benefician del uso de estas tecnologías patentadas”.

Después de la formación del grupo de patentes, se prevé que la recaudación de regalías se centre en los fabricantes de dispositivos de hardware compatibles con Opus.

Cabe mencionar que la concesión de licencias no afectará las implementaciones de códec abierto, las aplicaciones, los servicios y la distribución de contenido.

Los primeros titulares de patentes en sumarse a la iniciativa fueron Fraunhofer y Dolby. Se espera que en los próximos meses se forme un grupo de más de cien patentes y se solicite a los fabricantes licenciar el uso del códec Opus en sus dispositivos. El importe de las deducciones será de 15-12 céntimos de euro por cada dispositivo.

Cabe señalar que, además del formato Opus, Vectis IP está trabajando simultáneamente en la formación de consorcios de patentes que cubren otras tecnologías relacionadas con la codificación de imágenes y videos, las comunicaciones, el comercio electrónico y las redes informáticas.

El códec Opus se crea combinando las mejores tecnologías del códec CELT de Xiph.org y el códec SILK de código abierto de Skype. Además de Skype y Xiph.Org, empresas como Mozilla, Octasic, Broadcom y Google también participaron en el desarrollo de Opus.

Opus presenta una alta calidad de codificación y una latencia mínima tanto para la compresión de transmisión de audio de alta tasa de bits como para la compresión de voz para aplicaciones de telefonía VoIP con restricciones de ancho de banda.

Anteriormente, Opus fue reconocido como el mejor códec cuando usaba una tasa de bits de 64 Kbit (Opus superó a competidores como Apple HE-AAC, Nero HE-AAC, Vorbis y AAC LC). Las implementaciones de referencia del codificador y decodificador Opus se distribuyen bajo la licencia BSD.

Todas las patentes utilizadas en Opus son otorgadas por las empresas contribuyentes para uso ilimitado sin pago de regalías; las patentes se delegan automáticamente para aplicaciones y productos que utilizan Opus, sin necesidad de aprobación adicional.

No hay restricciones sobre el alcance y la creación de implementaciones alternativas de terceros. Sin embargo, todos los derechos otorgados se revocan en caso de procedimientos de patente que afecten a las tecnologías de Opus contra cualquier usuario de Opus. La actividad de Vectis IP está dirigida a encontrar patentes que se superpongan con Opus, pero que no pertenezcan a las empresas que originalmente estuvieron involucradas en su desarrollo, estandarización y promoción.

Finalmente sobre el caso, puedo mencionar que este movimiento se me hace muy familiar a lo que realizo en su momento QT, pero falta ver el cómo se desarrollara este cambio planeado a futuro, ya que muchos ven este movimiento como algo desperado por rescatar al codec.

Fuente: https://www.vectis.com

from Linux Adictos https://ift.tt/dqWjCN9
via IFTTT

Hace unas horas, KDE ha lanzado Plasma 5.26, y entre sus novedades ha cabido una mención a Plasma Bigscreen. De hecho, han sido dos, si contamos por separado cada una de las nuevas aplicaciones en llegar a nuestras pantallas. Por una parte, han lanzado Plank Player, un reproductor; por otra, Aura, un navegador web. Ambos están diseñados para que sea más fácil usarlos con un mando, y esa es una de las razones de ser de esta imagen o «piel» para Plasma.

Hace un tiempo que yo he hecho de mi viejo Lenovo mi «TV Box». En él tengo Ubuntu 22.04 y Windows 11. Yo preferiría usar Ubuntu para jugar y para ver contenido multimedia, pero Kodi ha decidido no funcionar como debe desde su subida a Matrix, y ahí es donde entra en juego la partición de Windows 11; la uso para lo que Ubuntu no me permite. Recientemente me ha dado por mirar al trabajo de KonstaKANG, y desarrollador que trae a la Raspberry Pi (entre otros) Android, y en su últimos lanzamientos, además, en versión AOSP.

Plasma Bigscreen recuerda a Plasma Mobile

Pero, ¿y qué tiene que ver lo anterior con Plasma Bigscreen? El momento. Justo ahora, cuando soy un mar de dudas sobre qué es mejor para mi uso, KDE nos ha recordado que existe su Bigscreen, por lo que me he decidido a volver a probarlo. La primera sorpresa, y no muy buena, ha sido ver que ya no está disponible la imagen basada en KDE neon. La mala impresión me la ha dado una idea, o más bien una pregunta: ¿tan poco confía KDE en su propuesta para pantallas grandes que ya no lanza la versión basada en el sistema operativo que más controlan? Pero también es cierto que KDE está en todos los rincones, el último en meterse la Steam Deck de Valve.

Superada la primera sorpresa, me ha tocado elegir entre postmarketOS y Manjaro. Esos son los dos proyectos que aparecen al entrar al apartado «Instalar» en la página oficial de «Pantalla Grande». Teniendo en cuenta que ya he usado Manjaro en la Raspberry Pi, y que las imágenes se parecen más a lo que conozco, mi elección ha sido clara. Así que meto una SD en el adaptador, todo en la ranura para tarjetas de mi portátil y la «flasheo» con Imager para asegurarme de que todo sale lo mejor posible (y evitar así echarle la culpa a alguien que no le tiene si algo sale mal).

Inicio mi Raspberry Pi 4 de 4GB y lo que veo está realmente bien. Recuerda mucho a lo que vemos en una tablet y en otros sistemas operativos para televisores, pero a la vez es diferente. Sí se parece mucho a Plasma Mobile, por ejemplo, al abrir una aplicación, que sale como una pantalla de bienvenida con el icono y un color de fondo, que depende de la app. También me ha recordado a la versión móvil de Plasma que no he encontrado la manera de cambiarle el idioma.

Entonces, ¿merece la pena?

Plasma Bigscreen tiene un buen diseño, y yo no he podido usar la opción de interactuar por medio de la voz porque no dispongo de hardware compatible. Pero uno tiene que saber qué necesita y qué uso va a hacer de un dispositivo como la Raspberry Pi. Que no esté en español no ayuda a decantarse por Bigscreen, pero ese sería un problema menor si no fuera por las opciones disponibles.

Por ejemplo, en el hardware que podemos usar Plasma Bigscreen también podemos usar Manjaro ARM, verlo en español e instalar de todo, sólo saliendo perdiendo si lo que queremos es usar sólo un mando. También tenemos Twister OS, con el que podemos tener todo tipo de «temas» y overclockear fácilmente a la placa para mejorar su rendimiento. Y no debemos olvidarnos de Android, el que está desarrollando KonstaKANG y que nos permite tener un Android tipo tablet al que en la actualidad sólo le falta el soporte para aceleración por hardware.

Por lo tanto, respondiendo a la pregunta, creo que ahora mismo hay mejores opciones, pero la cosa puede cambiar en el futuro, sobre todo si usamos un mando o tiramos de KDE Connect para controlarlo todo sin hacer uso de todo un teclado, que aunque sea inalámbrico es menos cómodo. Aún así, si no se olvidan de lo más importante, que es la versión para ordenadores, desde aquí les animo a seguir. Las opciones casi nunca sobran.

from Linux Adictos https://ift.tt/ke2avRc
via IFTTT

Hoy es un día importante para los usuarios de KDE. Si no importante, por lo menos interesante, ya que el proyecto ha lanzado Plasma 5.26, y no es una actualización más. Esta versión ha llegado con novedades, pero Nate Graham, pieza clave en el equipo y quien publica artículos semanales sobre las novedades en las que están trabajando, también dijo que iban a frenar un poco para centrarse en la estabilidad y fiabilidad. Por lo tanto, lo importante o interesante de hoy es, primero, que hay nuevo Plasma, y, segundo, que con él todo funcionará mejor.

Durante las últimas semanas no se frenó del todo el avance, pero sí han estado por lo menos desde el lanzamiento de la beta de Plasma 5.26 tratando de corregir el máximo número de bugs posibles. Estas correcciones no motivan titulares, pero sí que hacen que usar el escritorio al completo sea mejor. Tienen tres listas de bugs: la de 15 minutos (fallos que aparecen pronto y dan mala fama al proyecto), los de importancia y la lista general, y en los tres casos se han eliminado más de lo habitual.

Novedades más destacadas de Plasma 5.26

• Fondos de pantalla animados.
• Mejoras en Plasma Bigscreen, entre lo que se incluye un nuevo navegador web, Aura, y un reproductor, Plank Player.
• Posibilidad de redimensionar los widgets del panel inferior.
• Nuevo widget de cuenta atrás que aparecerá sobre la pantalla.
• Nuevo centro de control, un widget que se puede añadir a la bandeja del sistema.
• Posibilidad de cambiar el tamaño de la fuente del reloj digital, y configurar el paso de volumen en el controlador de volumen.
• Posibilidad de eliminar el icono del lanzador de aplicaciones/menú principal/widget de inicio y hacer que use un texto en su lugar… O hacer que use ambos.
• En Kickoff, ahora se puede navegar fácilmente por la sección de Todas las Aplicaciones usando un índice alfabetizado.
• Lista completa de cambios, aquí.

Plasma 5.26 ha sido anunciado hace unos instantes, y eso significa que su código ya está disponible para que los desarrolladores trabajen con él. En las próximas horas aparecerá, o debería hacerlo, en KDE neon, y probablemente también en el repositorio Backports de KDE. Posteriormente lo hará para las distribuciones cuyo modelo de desarrollo sera Rolling Release. Al resto de sistemas operativos irá llegando en unos plazos que dependerá de su filosofía.

from Linux Adictos https://ift.tt/vzo21Ja
via IFTTT

Oracle ha lanzado durante la noche de hoy VirtualBox 7.0, la última versión estable de su software para instalar y usar máquinas virtuales de los sistemas operativos compatibles. En este sentido, esta actualización es la primera estable en soportar oficialmente Windows 11, ya que dicho soporte llegó por primera vez en agosto, pero lo hizo a la versión beta. Es algo que no se menciona en la nota de su lanzamiento, pero no es necesario, ya que sí lo dijeron el pasado verano.

A pesar de subir el número del 6 al 7, Oracle dice que se trata de una actualización de mantenimiento. El cambio de número podría deberse a que soporta Windows 11 de manera oficial, o a cualquier otro detalle como algunos retoques en la interfaz, pero no es una nueva versión que incluya novedades destacadas, o por lo menos no para la compañía que lo desarrolla.

Novedades más destacadas de VirtualBox 7.0

• Soporte inicial para máquinas virtuales con cifrado completo por línea de comandos.
• Soporte 3D basado en DXVK.
• Soporte para Secure Boot en EFI.
• Soporte para dispositivos IOMMU.
• Se ha incluido soporte para TPM 1.2 y TPM 2.0.
• Mejoras en la interfaz de usuario (otro motivo que podría dar sentido al salto de número).
• Nuevo centro de notificaciones en donde podremos consultar información sobre errores y otros avisos.
• Nuevo widget para ver la ayuda.
• Nuevo asistente para instalaciones desatendidas.
• Mejorada la gestión del ratón en configuraciones multi-pantalla en X11.
• Se ha mejorado la función de grabar audio, y ahora se usa OGG Vorbis como el audio por defecto para contenedores WebM.
• Soporte inicial para la auto-actualización de las Guest Additions en Linux.
• Otras novedades disponibles en las notas del lanzamiento.

VirtualBox 7.0 está disponible desde hace unas horas en la página web oficial del proyecto, y en los próximos días empezará a aparecer en los repositorios oficiales de la mayoría de distribuciones Linux.

from Linux Adictos https://ift.tt/YACJo2x
via IFTTT

Con el pasado de este escritorio en nuestros recuerdos, uno no sabe si alegrarse o salir corriendo asustado. Personalmente no recuerdo si el «campo de minas» que me hizo huir del escritorio de KDE hace años era la v5 de Plasma o la anterior (creo que la anterior), pero lo cierto es que ahora mismo la experiencia es buena. En unos días llegará la próxima versión de Plasma, y ya para el verano que viene lanzarán Plasma 5.27, lo que, en teoría, será la última de la serie 5.

La siguiente ya será Plasma 6.0, y es ese punto-cero, junto a otras versiones tempranas, lo que da un poco de miedo. Durante la Akademy 2023, que ha tenido lugar en Barcelona, se habló mucho de Qt 6 y KDE Frameworks 6, y lo único que falta por subir al seis sería el escritorio, Plasma. Actualmente, Frameworks está en 5.99 (justo ayer se lanzó), y la siguiente versión será 5.100. Todo invita al lanzamiento de Plasma 6.0, pero vendría en el verano de 2023, o más tarde si deciden que no está lo suficientemente maduro.

Plasma 5.27 llegará a principios de 2023

En la actualidad, KDE está trabajando para hacer que KWin funcione bien en Qt 6, y todos esperamos que lo consigan y no se precipiten en un lanzamiento tan importante como será el de Plasma 6.0. Los seises de Plasma y Frameworks se ponen porque están construidos sobre el de Qt, y ese es el trabajo más delicado.

En las últimas versiones de Plasma y Frameworks, KDE se ha centrado en mejorar muchas cosas, y entre ellas hemos tenido el soporte para Wayland. En Plasma 5.25.5, el compositor trabaja bastante bien en el software de KDE, no llegando a la perfección, pero sí se puede usar. Es casi seguro que en Plasma 6.0 se siga esta tendencia, aunque no se descarta que aparezcan fallos feos.

Sobre si merecerá la pena subir o no, sólo el tiempo lo dirá. Los que lo recibirán sí o sí por su filosofía serán los usuarios de Arch Linux, pero otras distribuciones, aunque estén basadas en el mismo Arch, podrían retrasar su llegada para asegurarse de que no llega con problemas serios. Es algo que Manjaro ya hizo con Plasma 5.25 o GNOME 40 (más con GNOME 40), por lo que seguramente lo harán con Plasma 6.0. Y, aunque la impaciencia empuja, se agradece.

También podemos ser optimistas y pensar que tendremos software más avanzado y que todo irá bien, pero el pasado nos hace ser escépticos. Crucemos los dedos.

from Linux Adictos https://ift.tt/73BrREN
via IFTTT

La Raspberry Pi está enfrentando grandes problemas de sobre costo

En una publicación de blog, el desarrollador Jeff Geerling explica por qué cree que aún pasará un tiempo hasta que Raspberry Pi vuelva a estar disponible para el público en general en el precio establecido o al menos a un costo considerable dentro del mercado.

Para quienes desconocen de la «Raspberry Pi», deben saber que esta es una computadora de placa única basada en ARM del tamaño de una tarjeta de crédito. La Raspberry Pi permite la ejecución de varias variantes del sistema operativo libre GNU/Linux, en particular Debian, y también funciona con Windows.

Sobre el tema, de manera personal debo mencionar que encontrar el articulo que redacto Jeff Geerling me hace comprender que la situación no es solo en mi país, ya que no hace mucho me había percatado (hasta cierta parte), que los costos de la Raspberry Pi 4 desde su lanzamiento hasta ese momento, al menos aquí en mi país (México), han estado a un sobre precio exagerado.

Y dando un ejemplo, el costo de una RPi 4 básica, está no debajo de los $2000.00 MXN (pesos mexicanos) que es un aproximado de unos 100 dólares/euros (ya que están casi a la par, unos centavos mas/menos), mientras que la versión de 8GB rebasa los 150 dólares (unos $3000.00 MXN). Mientras que por el lado de la RPi 400 ni hablar.

Se podría entender hasta cierto punto que este lado del charco (Latinoamérica) sea un punto olvidado y por ende los revendedores tengan que aumentar el costo y personalmente es algo que odio, ya que proyectos como este o dígase el Librem, PinePhone, entre otros, me los he perdido porque resulta imposible poder hacerse con uno de estos.

Tomando en cuenta los costos de las RPi aquí en México, (en estos momentos de redactar el articulo), la verdad te orillan a optar por otras alternativas, que por un costo promedio de $3500.00 MXN (unos 175 dolares), con ello te haces de un combo ryzen 3 2400g e incluso con suerte de un ryzen 5 5600g, claro hay que tomar en cuenta que te faltaría la fuente de poder, pero pues si uno piensa en comparación de potencia, simplemente no hay punto de partida.

En este punto, sé que muchos pensaran y me dirán que «una RPi como tal no está pensada para estar a la par de componentes de escritorio y que en términos de utilidad, la RPi tiene una amplia gama proyectos. El punto es hacer solo una comparativa de costo y que en muchos casos, la mayoría optaría por un equipo de escritorio, que tal vez si, «desnudo» (hablando de no usar un gabinete) pero pues es funcional y realmente no afecta su funcionamiento.

Ahora, pasando al tema de la publicación de Jeff Geerling, este menciona que:

«Para ser claros, me refiero a los SBC de Raspberry Pi convencionales, como el Pi 4 Model B, Compute Module 4, Pi Zero 2W y, en muchos casos, incluso el Pi 400. Pico y Pico W están disponibles, en menos en la mayoría de los mercados que he examinado (todavía existe escasez local, pero por lo general no durante meses o años )”, dice Geerling.

Y es que hay que recordar que en su momento «Eben Upton», fundador de Raspberry Pi, anuncio un aumento «temporal» en el precio de Raspberry Pi 4. Upton dijo que el precio de la Raspberry Pi 4 de 2 GB bajaría de $ 35 a $ 45 y una versión previamente descontinuada de la Raspberry Pi 4 con 1 GB de RAM se reintroduciría a $ 35.

“En febrero de 2020, anunciamos que descontinuaríamos la variante de 1GB de Raspberry Pi 4 y cambiaríamos el producto de 2GB a nuestro precio de lista de $35. Desafortunadamente, el aumento del costo causado por la escasez actual significa que este producto actualmente no es económicamente viable a este precio reducido. Por lo tanto, lo estamos reduciendo temporalmente a 45 dólares”, dijo Eben Upton.

Para Geerling, Raspberry Pi es uno de los pocos proveedores de SBC (quizás el único) que aborda la característica más importante para la adopción y la felicidad continua del usuario final, «el soporte».

“En lugar de arrojar hardware a la pared, ver qué falla y depender de las comunidades de desarrolladores para respaldar su hardware con distribuciones como Armbian, Raspberry Pi respalda activamente sus placas, directamente desde el Pi Model B original. Mejoran continuamente su documentación y se enfocan en una excelente experiencia de usuario final para usuarios principiantes y avanzados.

Hay un factor importante que tambien entra en juego, y es que la Raspberry Pi solo puede producir una cantidad limitada de modelos Pi basados ​​en el SoC Broadcom BCM2711. Es el mismo problema que afecta a los fabricantes de automóviles. Incluso gigantes como Nvidia, Intel, AMD y Apple se ven afectados.

Debido a la escasez, Raspberry Pi no ha podido aumentar la producción para satisfacer la demanda, por lo que tienen que priorizar hacia dónde van los Pis que fabrican… y en la actualidad todavía están dando prioridad a los socios OEM sobre los minoristas de usuarios finales que venden unidades individuales.

Según Geerling, esto está lejos de ser ideal, y muchos en la comunidad/fabricante se sienten traicionados por una organización que ha crecido rápidamente gracias a la adopción popular de Raspberry Pi desde 2012.

«¿Cuántos usuarios comerciales e industriales de Pi lo incorporarían en su productos (y, por lo tanto, dependen de las acciones de Pi para su propia supervivencia) ¿no fue por la enorme comunidad de desarrolladores, fabricantes, manipuladores y educadores individuales que han hecho que Raspberry Pi sea tan popular como lo es hoy? él se pregunta.

Finalmente si quieres conocer más al respecto, te invito a que visites el articulo original de Jeff Geerling sobre el tema en su sitio web. El enlace es este.

from Linux Adictos https://ift.tt/KpM6DTN
via IFTTT

LLVM es una marco para el desarrollo de compiladores ademas de que ayuda a construir nuevos lenguajes de programación y mejorar los lenguajes existentes

Los desarrolladores del proyecto LLVM propusieron una serie de cambios destinados a fortalecer la seguridad de los proyectos C++ de misión crítica y proporcionar un medio para eliminar los errores causados ​​por las saturaciones de búfer.

Como tal la propuesta que dieron a conocer se centra en el trabajo de dos áreas en especial: proporcionar un modelo de desarrollo que permita trabajar de forma segura con búferes y trabajar para reforzar la seguridad de la biblioteca de funciones estándar libc++.

Se menciona que el modelo de programación seguro propuesto para C++ «es utilizar las clases proporcionadas por la biblioteca estándar cuando se trabaja con búferes en lugar de manipular punteros sin procesar». Por ejemplo, se propone utilizar las clases std::array, std::vector y std::span, que se agregarán con una verificación en tiempo de ejecución para la memoria asignada fuera de los límites.

Nuestro objetivo es mejorar la seguridad de las bases de código críticas de C++. Para ello tenemos previsto trabajar en dos ideas.

Biblioteca estándar reforzada de C++
Modelo de programación de búferes seguros de C++ y herramientas de adopción
La libc++ endurecida tiene como objetivo hacer que las interfaces de la biblioteca estándar de C++ sean más seguras en general.

El modelo de programación de búferes seguros de C++ junto con libc++ fortalecida brindan mitigación en tiempo de ejecución del acceso a la memoria fuera de los límites. Las herramientas de adopción automatizarán la migración de código a este nuevo modelo de programación.

Ademas de ello, tambien menciona que para combatir las prácticas de programación «peligrosas» en clang, se propone emitir advertencias del compilador para todas las operaciones aritméticas de punteros, similares a las advertencias de linter de clang-tidy cuando se usa el indicador «cppcoreguidelines-pro-bounds-pointer-arithmetic», cuyo soporte aparecerá en la versión LLVM 16. Para habilitar tales advertencias, se agregará una bandera separada a clang, inactiva por defecto.

Está previsto implementar un modo de protección opcional en libc++, que, cuando está habilitado, detectará algunas situaciones que conducen a un comportamiento indefinido en tiempo de ejecución. Por ejemplo, en las clases std::span y std::vector, se monitoreará un acceso fuera de los límites, en cuyo caso el programa fallará.

Estas comprobaciones de tiempo de ejecución adicionales se agruparán en varias categorías que se pueden controlar por separado. La intención es que un proveedor que envíe libc++ en su plataforma pueda decidir elegir qué comprobaciones habilitar en la biblioteca que envía (si es que las envía), según el nivel de seguridad deseado.

Los desarrolladores creen que agregar dichos cambios mantendrá a libc++ en conformidad con los estándares de C++, ya que la elección de cómo manejar los casos de comportamiento indefinido recae en los desarrolladores de la biblioteca, que pueden, entre otras cosas, tratar el comportamiento indefinido como un bloqueo que requiere la programa para salir.

Las comprobaciones de tiempo de ejecución en libc++ están planificadas para dividirse en categorías que se pueden incluir individualmente. Algunas de las comprobaciones sugeridas que no resultan en operaciones más complejas o cambios de ABI ya están implementadas en el modo seguro de libc++ (modo seguro).

Para reiterar, el objetivo final es que la biblioteca enviada habilite estas comprobaciones en producción; esta no es una característica de «solo depuración», aunque eventualmente reemplazará el «modo de depuración» roto hace mucho tiempo.

Además, está previsto preparar un conjunto de herramientas de corrección de código que permitirán reemplazar variables con punteros sin procesar en contenedores y aplicar controladores alternativos en situaciones en las que el contenedor no puede reemplazar directamente el puntero (por ejemplo, la construcción «if(array_pointer)» puede ser convertido a «if(span.data ()»). Los ajustes se pueden aplicar no solo a las variables locales, sino también a los parámetros de tipo con punteros.

Tambien se hace mención de que están considerando un «comprobador de analizador estático de clang» sensible a la ruta que advierte si std::span se construye a partir de un contenedor que tiene un tamaño más pequeño que el especificado en el constructor del intervalo. Dicho verificador es autónomo y útil por sí solo, si todo va bien, estará habilitado de forma predeterminada para todos los usuarios

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/uy3jv7t
via IFTTT

Usuarios que ejecutan Linux Kernel 5.19.12 describen «parpadeo blanco» en sus pantallas.

Hace poco se dio a conocer información de que se identificó un error crítico en el conjunto de arreglos para el controlador del kernel de Linux 5.19, referente al código de los gráficos i915 incluido en esta versión.

Y es que el problema solo afecta a las computadoras portátiles con gráficos Intel que usan el controlador i915 y de las cuales ya se ha reportado el error en algunas computadoras portátiles Lenovo, Dell, Thinkpad y Framework.

Se ha informado por varios usuarios a través de un puñado de distribuciones que
parece haber una regresión en la computadora portátil Framework (que presumiblemente es
no tan especial en términos de mobo y pantalla)

Se menciona que el error se manifiesta como un intenso destello blanco brillante en la pantalla inmediatamente después de cargar el controlador i915, que los usuarios afectados comparan con los efectos de iluminación «en las fiestas rave de los 90».

El parpadeo observado se debe a retrasos incorrectos en el encendido de la pantalla LCD que, si se expone durante mucho tiempo, puede provocar daños físicos en el panel LCD.

Algunos usuarios informaron que el parpadeo no desaparecía después de reiniciar o después de cambiar a herramientas de nivel básico como BIOS o GRUB. Algunos lograron cambiar sus versiones de kernel conectándose a un monitor externo y vieron que el parpadeo se desvanecía gradualmente con el tiempo.

Pero la secuencia de alimentación del panel (es decir, la sincronización de la pantalla) que no funciona bien puede dañar las pantallas de forma permanente, especialmente las LCD integradas en las computadoras portátiles.

Adicional a ello, es importante mencionar que todas las computadoras portátiles Nvidia Optimus y posiblemente algunas computadoras portátiles combinadas con Intel-Radeon podrían enfrentar este problema porque siempre dejan que la iGPU controle la pantalla, incluso cuando la GPU dedicada está procesando los gráficos. Su computadora portátil podría estar segura si puede desactivar el modo Optimus.

«Después de mirar algunos registros, terminamos con retrasos en la secuenciación de energía del panel potencialmente falsos, lo que puede dañar el panel LCD», escribió el ingeniero de Intel Ville Syrjälä en una discusión sobre el tema . «Recomiendo la reversión inmediata de este material y una nueva versión estable lo antes posible. Además, una recomendación de que nadie que use computadoras portátiles con GPU Intel ejecute 5.19.12».

Es por ello que se hace la especial recomendación a los usuarios de estos portátiles que estén sobre esta versión del Kernel, que si es imposible seleccionar otro kernel en el gestor de arranque, lo hagan con la finalidad de poder bloquear temporalmente el problema, ademas de que se recomienda especificar el parámetro del kernel «module_blacklist=i915» durante el arranque para iniciar sesión y actualizar el paquete del kernel o retroceder al kernel anterior.

El error está relacionado con un cambio en la lógica de análisis VBT (Video BIOS Tables), que se agregó solo en la versión del kernel 5.19.12, todas las versiones anteriores o posteriores, incluidas 5.19.11, 5.19.13 y 6.0.0, son no afectado por el problema.

El Kernel 5.19.12 se formó el 28 de septiembre y el lanzamiento del parche 5.19.13 se publicó el 4 de octubre. De las principales distribuciones, el kernel 5.19.12 logró ser entregado a los usuarios en Fedora Linux, Gentoo y Arch Linux. Mientras que las versiones estables de Debian, Ubuntu, SUSE y RHEL vienen con ramas de kernel más antiguas.

Greg Kroah-Hartman, el principal mantenedor de la rama estable, lanzó la versión 5.19.13 del kernel el martes, resolviendo el problema y brindando a las distribuciones de Linux un «trampolín seguro para rebotar».

«Este lanzamiento es para resolver una regresión en algunos sistemas de gráficos Intel que tenían problemas con 5.19.12. Si no tiene este problema con 5.19.12, no hay necesidad de actualizar», se lee en el anuncio de lanzamiento.

Ademas, los desarrolladores de Manjaro, ya ha anunciado que pasarán de 5.19.7 directamente a 5.19.13, evitando introducir riesgos a los usuarios de portátiles con GPU Intel. Sin embargo, dada la demora en impulsar las actualizaciones del kernel de Linux en muchas otras distribuciones, la versión con errores podría aterrizar en algunas de ellas más adelante.

Fuente: https://lore.kernel.org

from Linux Adictos https://ift.tt/3UqTL1a
via IFTTT