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