No puedes comprar una Raspberry Pi en este momento, no al menos a sobre precio 

raspberry pi sobre costo

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

Desarrolladores de LLVM proponen un manejo seguro de búfer en C++

LLVM Logo

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

Identificaron un error en Linux 5.19.12 que podría dañar las pantallas de portátiles con GPU Intel

controlador intel daña pantalla en Linux 5.19.12

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

Report: Big U.S. Banks Are Stiffing Account Takeover Victims

When U.S. consumers have their online bank accounts hijacked and plundered by hackers, U.S. financial institutions are legally obligated to reverse any unauthorized transactions as long as the victim reports the fraud in a timely manner. But new data released this week suggests that for some of the nation’s largest banks, reimbursing account takeover victims has become more the exception than the rule.

The findings came in a report released by Sen. Elizabeth Warren (D-Mass.), who in April 2022 opened an investigation into fraud tied to Zelle, the “peer-to-peer” digital payment service used by many financial institutions that allows customers to quickly send cash to friends and family.

Zelle is run by Early Warning Services LLC (EWS), a private financial services company which is jointly owned by Bank of America, Capital One, JPMorgan Chase, PNC Bank, Truist, U.S. Bank, and Wells Fargo. Zelle is enabled by default for customers at over 1,000 different financial institutions, even if a great many customers still don’t know it’s there.

Sen. Warren said several of the EWS owner banks — including Capital One, JPMorgan and Wells Fargo — failed to provide all of the requested data. But Warren did get the requested information from PNC, Truist and U.S. Bank.

“Overall, the three banks that provided complete data sets reported 35,848 cases of scams, involving over $25.9 million of payments in 2021 and the first half of 2022,” the report summarized. “In the vast majority of these cases, the banks did not repay the customers that reported being scammed. Overall these three banks reported repaying customers in only 3,473 cases (representing nearly 10% of scam claims) and repaid only $2.9 million.”

Importantly, the report distinguishes between cases that involve straight up bank account takeovers and unauthorized transfers (fraud), and those losses that stem from “fraudulently induced payments,” where the victim is tricked into authorizing the transfer of funds to scammers (scams).

A common example of the latter is the Zelle Fraud Scam, which uses an ever-shifting set of come-ons to trick people into transferring money to fraudsters. The Zelle Fraud Scam often employs text messages and phone calls spoofed to look like they came from your bank, and the scam usually relates to fooling the customer into thinking they’re sending money to themselves when they’re really sending it to the crooks.

Here’s the rub: When a customer issues a payment order to their bank, the bank is obligated to honor that order so long as it passes a two-stage test. The first question asks, Did the request actually come from an authorized owner or signer on the account? In the case of Zelle scams, the answer is yes.

Trace Fooshee, a strategic advisor in the anti money laundering practice at Aite-Novarica, said the second stage requires banks to give the customer’s transfer order a kind of “sniff test” using “commercially reasonable” fraud controls that generally are not designed to detect patterns involving social engineering.

Fooshee said the legal phrase “commercially reasonable” is the primary reason why no bank has much — if anything — in the way of controlling for scam detection.

“In order for them to deploy something that would detect a good chunk of fraud on something so hard to detect they would generate egregiously high rates of false positives which would also make consumers (and, then, regulators) very unhappy,” Fooshee said. “This would tank the business case for the service as a whole rendering it something that the bank can claim to NOT be commercially reasonable.”

Sen. Warren’s report makes clear that banks generally do not pay consumers back if they are fraudulently induced into making Zelle payments.

“In simple terms, Zelle indicated that it would provide redress for users in cases of unauthorized transfers in which a user’s account is accessed by a bad actor and used to transfer a payment,” the report continued. “However, EWS’ response also indicated that neither Zelle nor its parent bank owners would reimburse users fraudulently induced by a bad actor into making a payment on the platform.”

Still, the data suggest banks did repay at least some of the funds stolen from scam victims about 10 percent of the time. Fooshee said he’s surprised that number is so high.

“That banks are paying victims of authorized payment fraud scams anything at all is noteworthy,” he said. “That’s money that they’re paying for out of pocket almost entirely for goodwill. You could argue that repaying all victims is a sound strategy especially in the climate we’re in but to say that it should be what all banks do remains an opinion until Congress changes the law.”

UNAUTHORIZED FRAUD

However, when it comes to reimbursing victims of fraud and account takeovers, the report suggests banks are stiffing their customers whenever they can get away with it. “Overall, the four banks that provided complete data sets indicated that they reimbursed only 47% of the dollar amount of fraud claims they received,” the report notes.

How did the banks behave individually? From the report:

-In 2021 and the first six months of 2022, PNC Bank indicated that its customers reported 10,683 cases of unauthorized payments totaling over $10.6 million, of which only 1,495 cases totaling $1.46 were refunded to consumers. PNC Bank left 86% of its customers that reported cases of fraud without recourse for fraudulent activity that occurred on Zelle.

-Over this same time period, U.S. Bank customers reported a total of 28,642 cases of unauthorized transactions totaling over $16.2 million, while only refunding 8,242 cases totaling less than $4.7 million.

-In the period between January 2021 and September 2022, Bank of America customers reported 81,797 cases of unauthorized transactions, totaling $125 million. Bank of America refunded only $56.1 million in fraud claims – less than 45% of the overall dollar value of claims made in that time.

Truist indicated that the bank had a much better record of reimbursing defrauded customers over this same time period. During 2021 and the first half of 2022, Truist customers filed 24,752 unauthorized transaction claims amounting to $24.4 million. Truist reimbursed 20,349 of those claims, totaling $20.8 million – 82% of Truist claims were reimbursed over this period. Overall, however, the four banks that provided complete data sets indicated that they reimbursed only 47% of the dollar amount of fraud claims they received.

Fooshee said there has long been a great deal of inconsistency in how banks reimburse unauthorized fraud claims — even after the Consumer Financial Protection Bureau (CPFB) came out with guidance on what qualifies as an unauthorized fraud claim.

“Many banks reported that they were still not living up to those standards,” he said. “As a result, I imagine that the CFPB will come down hard on those with fines and we’ll see a correction.”

Fooshee said many banks have recently adjusted their reimbursement policies to bring them more into line with the CFPB’s guidance from last year.

“So this is heading in the right direction but not with sufficient vigor and speed to satisfy critics,” he said.

Seth Ruden is a payments fraud expert who serves as director of global advisory for digital identity company BioCatch. Ruden said Zelle has recently made “significant changes to its fraud program oversight because of consumer influence.”

“It is clear to me that despite sensational headlines, progress has been made to improve outcomes,” Ruden said. “Presently, losses in the network on a volume-adjusted basis are lower than those typical of credit cards.”

But he said any failure to reimburse victims of fraud and account takeovers only adds to pressure on Congress to do more to help victims of those scammed into authorizing Zelle payments.

“The bottom line is that regulations have not kept up with the speed of payment technology in the United States, and we’re not alone,” Ruden said. “For the first time in the UK, authorized payment scam losses have outpaced credit card losses and a regulatory response is now on the table. Banks have the choice right now to take action and increase controls or await regulators to impose a new regulatory environment.”

Sen. Warren’s report is available here (PDF).

There are, of course, some versions of the Zelle fraud scam that may be confusing financial institutions as to what constitutes “authorized” payment instructions. For example, the variant I wrote about earlier this year began with a text message that spoofed the target’s bank and warned of a pending suspicious transfer.

Those who responded at all received a call from a number spoofed to make it look like the victim’s bank calling, and were asked to validate their identities by reading back a one-time password sent via SMS. In reality, the thieves had simply asked the bank’s website to reset the victim’s password, and that one-time code sent via text by the bank’s site was the only thing the crooks needed to reset the target’s password and drain the account using Zelle.

None of the above discussion involves the risks affecting businesses that bank online. Businesses in the United States do not enjoy the same fraud liability protection afforded to consumers, and if a banking trojan or clever phishing site results in a business account getting drained, most banks will not reimburse that loss.

This is why I have always and will continue to urge small business owners to conduct their online banking affairs only from a dedicated, access restricted and security-hardened device — and preferably a non-Windows machine.

For consumers, the same old advice remains the best: Watch your bank statements like a hawk, and immediately report and contest any charges that appear fraudulent or unauthorized.

from Krebs on Security https://ift.tt/0QXsgRO
via IFTTT