Ondsel un proyecto promover FreeCAD entre profesionales 

Ondsel

Ondsel es una empresa open-core creada en torno al increíble Proyecto FreeCAD.

Hace pocos días Brad Collette, un desarrollador activo de FreeCAD, que desarrolla la interfaz Path para organizar la producción de modelos diseñados por FreeCAD en máquinas CNC, fundó Ondsel el cual es un proyecto que desarrollará soluciones que harán que FreeCAD sea más atractivo para usuarios comerciales, ingenieros y diseñadores profesionales.

Para desconocen de proyecto FreeCAD, deben saber que este ofrece un sistema abierto de modelado 3D paramétrico, que se caracteriza por una personalización flexible y mejora de la funcionalidad a través de la conexión de complementos.

El sistema permite, cambiando los parámetros del modelo, jugar con varias opciones de diseño y evaluar el trabajo en varios puntos del desarrollo del modelo. FreeCAD puede ser un reemplazo gratuito para los sistemas CAD comerciales como CATIA, Solid Edge y SolidWorks.

Sobre el nuevo proyecto se menciona que las soluciones se desarrollarán en el marco del modelo de negocio Open Core, en el que los componentes básicos del sistema se distribuyen libremente y las funciones avanzadas se entregan como parte de un producto comercial.

“Pones todo este esfuerzo en hacer que tus diseños sean paramétricos y flexibles, pero siguen siendo inútiles para otras personas a menos que tengan FreeCAD y sepan cómo usarlo”, dijo Brad Collette, colaborador de FreeCAD desde hace mucho tiempo y CTO de Ondsel. “Quiero permitir que los diseñadores publiquen diseños en un sitio web donde los usuarios finales puedan personalizar aspectos de ellos y luego descargar exactamente lo que necesitan para imprimirlos en 3D, cortarlos en un CNC o usarlos en alguna otra aplicación”.

Mediante una publicación de blog, dio a conocer parte de los detalles del proyecto y en ella se menciona que la empresa está registrada como una corporación de beneficio público (Corporación de Beneficios Públicos), sin fines de lucro, trabajando por el bien público y contribuyendo al desarrollo del proyecto de código abierto FreeCAD.

Todos los cambios relacionados con el código base principal de FreeCAD, así como la mayor parte del código de sus servicios, Ondsel se compromete a suministrar bajo licencias abiertas y volver al proyecto principal.

“Si quería pagar por CAM, era tremendamente caro, y sin CAM, los modelos no son muy útiles para CNC”, dijo Brad. “Empecé contribuyendo a un pequeño proyecto de código abierto y haciendo algunos amigos, y luego, eventualmente, me conecté al proyecto FreeCAD. Tampoco había capacidad CAM allí. Así que empezamos desde cero y seguimos adelante”.

También está previsto contratar a varios desarrolladores que trabajarán en el desarrollo de FreeCAD para resolver problemas complejos de ingeniería. La empresa también se compromete a no vincular a los usuarios a sus servicios (vendor lock), a garantizar la portabilidad con otros productos y a no complicar la migración de los datos de los usuarios.

De los planes de desarrollo, se destaca la creación de una edición en la nube de FreeCAD, así como el desarrollo de herramientas para colaborar en proyectos complejos y construir una plataforma para publicar proyectos creados.

Se supone que los usuarios podrán vender proyectos preparados en FreeCAD a aquellos que no quieren diseñar desde cero, pero están listos para adaptar una solución típica preparada a sus necesidades. Así, las pequeñas empresas podrán utilizar una única plataforma para crear sus productos y llevarlos a los clientes.

Históricamente, la mayor parte de la base de usuarios de FreeCAD ha sido creadores y aficionados. Ondsel quiere hacer que FreeCAD sea más atractivo para diseñadores profesionales, ingenieros y usuarios comerciales.

“Nuestro conjunto inicial de clientes son las pequeñas empresas con un producto personalizable para el usuario final. Quieren usar sus diseños 3D en su sitio web para que sus clientes puedan interactuar, personalizar y explorar el producto”, dijo Brad.

Si bien el objetivo principal de FreeCAD es la ingeniería mecánica y el diseño de nuevos productos, se puede utilizar en otras áreas, como el diseño arquitectónico.

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/BMk4AIR
via IFTTT

openSUSE simplifica la instalación de H.264 en el sistema

opensuse

Es un sistema operativo orientado a los usuarios de software libre y abierto al desarrollo de nuevas funciones por su comunidad

Hace poco se dio a conocer la noticia de qué desarrolladores de openSUSE han implementado un esquema para simplificar la instalación del códec de video H.264 en la distribución.

Esto se debe a que hace unos meses, el paquete de distribución también incluía paquetes con el códec de audio AAC (usando la biblioteca FDK AAC), que está aprobado como estándar ISO, definido en las especificaciones MPEG-2 y MPEG-4 y utilizado en muchos servicios de video.

El proyecto openSUSE se inspiró en los esfuerzos de Fedora para poner a disposición de sus usuarios los códecs OpenH264 y FDK AAC de Cisco. Los miembros se comunicaron con el equipo de código abierto de Cisco para hacer lo mismo con su base de usuarios.

Un obstáculo a superar es que la limitación actual para la redistribución gratuita de los códecs es de 100 000 usuarios, por lo que el miembro de la junta directiva Neal Gompa y el gerente de versiones Leap de openSUSE, Lubos Kocman, propusieron una forma de simplificar la instalación del códec en openSUSE .

El motivo de hacer un cambio en el proceso de la instalación del codec en el sistema, se debe a que la distribución de la tecnología de compresión de video H.264 requiere el pago de regalías a la organización MPEG-LA, pero si se utilizan librerías abiertas OpenH264, el códec puede usarse en productos de terceros sin pagar regalías, ya que Cisco, que desarrolla el proyecto OpenH26, es licenciatario de MPEG LA.

Cisco, cuyo proyecto openSUSE está muy agradecido por sus esfuerzos, acordó un enfoque sobre la redistribución de OpenH264 a través de una infraestructura propiedad de Cisco para los usuarios de openSUSE.

El matiz es que el derecho a usar tecnologías de compresión de video propietarias se transfiere solo para las compilaciones distribuidas por Cisco, por ejemplo, descargados del sitio web de Cisco, que no permite colocar paquetes con OpenH264 en el repositorio de openSUSE.

Para resolver este problema, se ha agregado un repositorio separado al kit de distribución, en el que se descarga la compilación binaria del códec del sitio web de Cisco (ciscobinary.openh264.org).

Al mismo tiempo, la compilación del códec está formado por los desarrolladores de openSUSE, certificado por la firma digital oficial de openSUSE y transferido a Cisco para su distribución, es decir la formación de todo el relleno del paquete sigue siendo responsabilidad de openSUSE y Cisco no puede realizar cambios ni reemplazar el paquete.

Se imaginó un flujo de trabajo de lanzamiento para OpenH264 y se manejó un enfoque de tres pasos a través de un conjunto de scripts en OpenSUSE Release Tools.

Un script de flujo de trabajo activa y envía a Cisco un correo electrónico con un archivo que contiene paquetes rpm OpenH264 a Cisco; crea una instantánea de los datos que luego se envían o «PUBLICAN» para la extracción manual de un binario de Cisco . El proceso garantiza que el proyecto siempre tenga un conjunto de archivos binarios relacionados en Open Build Service .

Uno de los mantenedores del proyecto multimedia:libs:cisco-openh264 crea y envía un archivo . El paquete se firma en OBS con la clave openSUSE, por lo que se puede verificar el origen del paquete. OBS publica los metadatos del repositorio en codecs.opensuse.org/openh264 .

El archivo debe contener solo paquetes con Cisco OpenH264 y complementos OpenH264 GStreamer relacionados. La adición de cualquier otro contenido fuera del acuerdo, especialmente otros códecs, bajo el acuerdo de Cisco daría lugar a una infracción.

Ya se han discutido las posibles mejoras para mejorar el flujo de trabajo existente, pero los esfuerzos iniciales están destinados a proporcionar openSUSE una experiencia más simplificada después de la instalación.

El repositorio openh264 estará habilitado de forma predeterminada para las nuevas instalaciones de openSUSE Tumbleweed en la próxima actualización iso, y también se agregará a la versión beta inicial de la rama openSUSE Leap 15.5.

Antes de activar el repositorio predeterminado, para instalar componentes habilitados para H.264, el usuario simplemente necesita ejecutar:

sudo zypper ar http://codecs.opensuse.org/openh264/openSUSE_Leap repo-openh264
sudo zypper en gstreamer-1.20-plugin-openh264

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

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

DXVK 2.1 llega con correcciones y mas

DXVK

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine

Se dio a conocer el lanzamiento de la nueva versión de DXVK 2.1 la cual llega solucionando problemas en algunos títulos de juego, asi como tambien la posibilidad de habilitar HDR, entre otras cosas más.

La nueva versión de DXVK requiere controladores compatibles con API Vulkan 1.3, como Mesa RADV 22.0, NVIDIA 510.47.03, Intel ANV 22.0 y AMDVLK. DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, lo que sirve como una alternativa de mayor rendimiento a las implementaciones Direct3D 9/10/11 integradas de Wine que se ejecutan sobre OpenGL.

Principales novedades en DXVK 2.1

En la nueva versión que se presenta de DXVK 2.1 los sistemas compatibles con el espacio de color HDR10, es posible habilitar HDR configurando la variable de entorno DXVK_HDR=1 o especificando el parámetro dxgi.enableHDR=True en el archivo de configuración. Una vez que HDR está habilitado, los juegos pueden detectar y usar el espacio de color HDR10 si está instalado vkd3d-proton 2.8 o más reciente.

Cabe mencionar que de momento los principales entornos de usuario en Linux aún no son compatibles con HDR, pero la compatibilidad con HDR está disponible en el servidor compuesto de Gamescope y para habilitarlo, debe usar la opción «–hdr-enabled» (solo funciona en sistemas con GPU AMD cuando se usa Linux) kernel con josh-hdr parches -colorimetría).

Otro de los cambios que se destaca de la nueva versión es que la compilación de shaders fue mejorada. Para reducir el tartamudeo, el uso de bibliotecas de tuberías (pipeline) se ha extendido a tuberías con sombreadores de geometría y teselación, y cuando se usa MSAA, se usan características adicionales de la extensión Vulkan VK_EXT_extended_dynamic_state3.

Para los juegos más antiguos que admiten el suavizado de múltiples muestras (MSAA, Multi-Sample Anti-Aliasing), se agregaron las configuraciones d3d9.forceSampleRateShading y d3d11.forceSampleRateShading para habilitar el modo de sombreado de frecuencia de muestreo para todos los sombreadores, lo que le permite mejorar la calidad de las imágenes en los juegos.

El backend GLFW se ha agregado a las compilaciones de Linux, que se puede usar como una alternativa al backend SDL2.

Se mejoró la lógica de paso de comandos D3D11 para aproximar el comportamiento DXVK a los controladores nativos D3D11 y lograr un rendimiento más predecible

Problemas resueltos que aparecían en los juegos:

  • Ashes of the Singularity : regresión de rendimiento fija causada por una asignación de conjunto de descriptores subóptima.
  • Battlefield: Bad Company 2 : Parpadeo fijo
    Cardfight!! Vanguard : renderizado fijo
  • Gujian 3 : se corrigieron problemas de renderizado en algunas GPU.
  • Resident Evil 4 HD : se corrigió el uso no válido de Vulkan que causaba un bloqueo de GPU en RADV.
  • Saints Row: The Third : se solucionó un problema grave de rendimiento con la lluvia al usar el renderizador D3D9.
  • Sekiro: Shadows Die Twice : se corrigieron problemas de tartamudeo en las GPU de Nvidia.
  • Sonic Frontiers : se solucionó un error del juego que causaba que las sombras parpadearan cuando se conectaba a la GPU.
  • Supreme Commander: Forged Alliance : se corrigió un bloqueo después de cargar

Finalmente si estás interesado en conocer más al respecto sobre este nuevo lanzamiento, puedes consular los detalles en el siguiente enlace.

¿Cómo añadir el soporte de DXVK a Linux?

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, actuando como una alternativa de mayor rendimiento a la implementación de Direct3D 11 integrada en Wine que se ejecuta sobre OpenGL.

DXVK requiere de la última versión estable de Wine para ejecutarse. Por lo que, si no cuentas con este instalado. Ahora solo tendremos que descargar el último paquete estable de DXVK, este lo encontramos en el siguiente enlace.

wget https://github.com/doitsujin/dxvk/releases/download/v2.1/dxvk-2.1.tar.gz

Después de haber realizado la descarga ahora vamos a descomprimir el paquete recién obtenido, esto lo pueden hacer con desde su entorno de escritorio o desde la misma terminal ejecutando en el siguiente comando:

tar -xzvf dxvk-2.1.tar.gz

Después accedemos a la carpeta con:

cd dxvk-2.1

Y ejecutamos el comando sh para ejecutar el script de instalación:

sudo sh setup-dxvk.sh install
setup-dxvk.sh install --without-dxgi

Cuando se instale DXVK en un prefijo de Wine. La ventaja es que se puede usar Wine vkd3d para juegos D3D12 y DXVK para juegos D3D11.

Además, la nueva secuencia de comandos permite instalar la dll como enlaces simbólicos, lo que facilita la actualización de DXVK para obtener más prefijos de Wine (puede hacerlo a través del comando –symlink).

Como verán la carpeta de DXVK contiene otras dos dll para 32 y 64 bits estas las vamos a colocar de acuerdo a las siguientes rutas.
En donde “usuario” lo remplazas por el nombre de usuario que utilizas en tu distribución de Linux.

Para 64 bits las colocamos en:

~/.wine/drive_c/windows/system32/

O

/home/”usuario”/.wine/drive_c/windows/system32/

Y para 32 bits en:

~/.wine/drive_c/windows/syswow64

O

/home/”usuario”/.wine/drive_c/windows/system32/

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

He vuelto a usar Ubuntu tras cuatro años y estas han sido mis impresiones

Mirando a Ubuntu desde KDE

Mi historia con Ubuntu siempre ha sido la de una relación de amor/odio. Cuando lo probé por primera vez, su diseño y sus problemas para gestionar el audio eran los problemas, pero el rendimiento, velocidad y fiabilidad eran otro mundo comparado con Windows. Años más tarde se pasaron a Unity y es cuando empecé a hacer un «distro hopping» que me hizo mudarme a KDE (Kubuntu y Manjaro). Ahora, tras cuatro años, he estado trabajando con Ubuntu otra vez.

Este artículo es uno de esos de opinión, aunque esta vez son más impresiones. Todo lo que incluye es lo que el autor siente al usar Ubuntu tras haber pasado mucho tiempo en KDE, y ya os adelanto que me siento un poco como en la imagen de cabecera. También tengo que decir que lo tratado aquí es la versión principal, la que usa GNOME como entorno gráfico.

Ubuntu tiene un diseño que (casi) siempre me ha gustado

El diseño de Ubuntu me gusta. No siempre lo ha hecho, ya que a mí no me gusta que el panel de las aplicaciones esté a la izquierda ni llegue de parte a parte, pero eso se puede modificar desde hace unas cuantas versiones, con lo que podemos tener un dock muy estético a la parte de abajo. Por otra parte, tiene en la parte de arriba otro panel, uno al que me acostumbré cuando usaba macOS y está muy bien.

Sé perfectamente que en KDE puedo poner un dock y un panel superior de manera rápida y sencilla, pero ya estaría modificando por mi cuenta bastante de cómo es por defecto, y os lo creáis o no, no me gusta retocar demasiado las cosas. Puedo ser el único usuario de Linux que piense algo así, pero no retoco nada por defecto a no ser que sea necesario. Las manías no las curan los médicos.

Gestos del panel táctil que funcionan…

… sin sacrificar nada. Ya hace mucho tiempo que Ubuntu usa Wayland por defecto, y ya ha avanzado mucho en este apartado. KDE también tiene gestos, pero no funciona demasiado bien en Wayland, por lo que termino usando X11 y no puedo usar los gestos del panel táctil (sin instalar nada extra).

Y los gestos son algo que yo catalogaría como necesario ya en 2023. Si deslizando tres dedos a izquierda o derecha nos permite cambiar a otro escritorio, casi casi podríamos decir que tenemos dos monitores. Por ejemplo, me permiten ver una clase/tutorial/información en un escritorio virtual y tener Visual Studio Code en otro. Lo que con dos monitores haría moviendo el cuello, con esta función lo consigo deslizando de un lado a otro.

Y como digo, sin sacrificar nada. Viene de serie y Wayland se comporta bien en Ubuntu y en GNOME en general.

Mucho mejor en autonomía

Cuando uso Windows en mi portátil desde un SSD externo, he comprobado que la batería aguanta más. Como es algo que hago poco, al volver a KDE sencillamente lo uso y cargo el portátil cuando me lo pide, pero eso es algo que me pasa menos usando Ubuntu. En KDE, mi batería aguantará no mucho más de 2 horas, pero usando Ubuntu se acerca a las 5 horas, más o menos lo que se prometía cuando lo compré. Sorprendente, pero es más o menos lo que aguanta en Windows, por lo que parece que es KDE el que tiene un problema de autonomía, por lo menos en mi hardware.

Hay gente que recomienda hacer algunos retoques para mejorar el rendimiento de KDE, entre los que está desactivar Baloo, y me imagino que este tipo de cambios harán que también mejore la autonomía, pero ya son cambios que hay que hacer a la instalación por defecto.

Instalación de software en Ubuntu

Este punto es válido para Ubuntu y todos los X-buntu. Prácticamente cualquier software que está para Linux está en los repositorios oficiales de Ubuntu o como paquete .deb desde la página del desarrollador. Por ejemplo, VSCode, Chrome o Vivaldi están como paquetes .deb, y además añaden el repositorio oficial tras la primera instalación. Pero no todo es tan fácil de instalar.

Un ejemplo es BIMP, un complemento para GIMP que permite convertir imágenes en lote. Se puede compilar, pero es más fácil instalarlo en Manjaro, que se puede hacer desde su tienda de software (Pamac) y AUR. Como no he querido instalar todo lo que se me pide desde la página oficial, he solventado ese problema tirando de Converseen… hasta que actualicé mi propio «ConverMedia» escrito en Python para que también me permitiera redimensionar imágenes.

Información y soporte

Esto es de lo mejor cuando se usa Ubuntu o cualquier derivado en general. Cuando hay algún problema, casi todas las soluciones que hay por la red hablan de Ubuntu. Así, hacer funcionar algo como MySQL o usar una versión concreta de Python para que funcione en Kodi está a una búsqueda de distancia. Cuando usamos otras distribuciones, bueno, si no sabemos hacer algo tenemos que buscar algo más.

Aplicaciones (ay, WebP…)

Sin intención de hacer un spoiler, esto es lo que probablemente me hará seguir en KDE, aunque pase más tiempo en Ubuntu del que he pasado en los últimos 4 años. Gwenview permite hacer algunas ediciones de imágenes, e incluso anotaciones, y el visor de Ubuntu sirve… pues para visualizar imágenes. Lo mismo podríamos decir de programas como Okular, Ark o Kate: lo de KDE ofrece más posibilidades en general. Claro está, puedo instalar todo eso en Ubuntu, pero también librerías y dependencias que estarán de más si no se usa mucho más software de KDE.

Algo que duele más, por defecto, ya bien entrados en la tercera década de los 2000, Ubuntu no se lleva bien con el formato WebP. Ni siquiera lo reconoce como «imagen» el visor de imágenes, por lo que al hacer doble clic sobre este tipo de archivos nos abrirá el navegador. Hay maneras de hacer que el visor soporte este tipo de imágenes, pero estamos en lo de siempre: hay que añadir un repositorio de terceros…

¿Me vuelvo a Ubuntu o me quedo en KDE?

Pues me quedo en Manjaro KDE. Y vuelvo a Ubuntu. Voy a usar las dos cosas. Sigo prefiriendo KDE porque me parece que sus aplicaciones y fluidez son mejores, y Manjaro porque siento que me va mejor, pero Ubuntu me ha dejado un buen sabor de boca que no sentía desde no sé ni cuando. También es cierto que en las últimas versiones han mejorado mucho el rendimiento y que el equipo en el que lo uso tiene 32GB de RAM y un procesador i7, pero va realmente bien. Quién sabe si al final dejaré a la chica con cara de Manjaro-Kubuntu-KDE y terminaré pidiéndole una cita a la de cara Ubuntu-GNOME.

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

La primera edad de oro. Breve historia de la Inteligencia Artificial 4

Las décadas del 50 y 60 fueron extraordinarias para el desarrollo de la inteligencia artificial.
Aunque la idea de crear seres artificiales que hicieran cosas solo reservadas para los humanos siempre estuvo entre nosotros, solo en el siglo XX pudo comenzar a hacerse realidad. Una serie de acontecimientos ocurridos en los siglos XIX y XX confluyeron para que entre fines de la década del cuarenta y principios de la del 70 se diera lo que podríamos denominar la primera edad de oro de la Inteligencia Artificial.

Claro que lo de primera es un atrevimiento por mi parte.  Si bien los historiadores coinciden que fue una edad de oro, todavía no está claro de si lo que estamos viviendo ahora es la segunda.

La primera edad de oro

Para que se diera el espectacular auge de las investigaciones sobre Inteligencia Artificial a partir de la finalización de la guerra, se dieron una serie de condiciones. Como vimos en el artículo anterior desde el siglo pasado había una metodología que permitía expresar el razonamiento humano en forma de símbolos y realizar operaciones con ellos.

Los trabajos de Turing, Shannon y von Neuman por su parte, permitieron la aparición de equipos capaz de ejecutar instrucciones complejas. Solo faltaba el software.

Las redes neuronales

En un primer momento los investigadores intentaron construir hardware que simulara la estructura del cerebro con componentes eléctricos que cumplían la función de las neuronas. Para entender el comportamiento de estas se utilizaba el análisis matemático.

Dos investigadores, McCulloch y Pitts, publicaron un artículo en 1943 en el que explicaban cómo podían construirse mecanismos que emularan el comportamiento del cerebro.  Hoy se sabe que parte de su enfoque estaba equivocado ya que ellos creían que eran las neuronas individuales las que tomaban decisiones a partir de la información obtenida por los sentidos y generaban respuestas (En realidad se necesitan millones de ellas interactuando) si presentaron un análisis matemático bastante acertado sobre cómo se produce la transmisión de información entre neuronas.

El siguiente gran aporte llegó en 1949 de la mano de un fisiólogo de una universidad canadiense. Donald O. Hebb propuso la idea de que las conexiones neuronales no son inmutables. Cada vez que aprendemos algo nuevo la estructura neuronal cambia para fijar ese conocimiento. La explicación es que cuando una neurona provoca de manera seguida la activación de otra aumenta su conductividad lo que hace que sea más probable que se produzcan más activaciones estableciendo nuevas rutas de conexiones neuronales.

El cambio al segundo enfoque (En lugar de imitar la configuración del cerebro simular el mecanismo que le permite llegar a un resultado) vino de la mano de un señor llamado Marvin Minsky.

Minsky era un verdadero hombre del Renacimiento que se interesaba en disciplinas tan diversas como la Zoología y la Física pasando por la Psicología y la Matemática. Con otros dos investigadores construyó una red neuronal que simulaba la forma en que una rata aprendía cómo salir de un laberinto.

Pronto se dio cuenta que si bien «la rata» aprendía de sus errores era incapaz de utilizar su conocimiento para evitar cometer otros nuevos. De ahí que la tesis para su doctorado en matemáticas fuera sobre cómo construir redes neuronales más complejas capaces de planificar por anticipado.

El cambio de paradigma se produce en 1955 cuando Minsky conoce a Ray Solomonoff que estaba trabajando en una teoría sobre la inferencia deductiva.  A partir de su conversación comenzó a pensar que estaba siguiendo e camino equivocado. Que en lugar de crear hardware que imitara la composición del cerebro, lo mejor era tratar de deducir la forma en que el cerebro actúa y traducirlo a símbolos y relaciones que puedan ser procesados por cualquier computadora.

En 1956 se reunieron diez de los investigadores (Casi todos los que había sobre el tema) en un taller de dos meses. Además de Minsky estuvo presente el arriba citado Ray Solomonoff.

Solomonoff, en contra de la opinión mayoritaria de sus colegas sostenía que el estudio sobre la capacidad de los ordenadores para resolver problemas debería hacerse con los menos complicados ya que esto simplificaría el análisis de los procesos mentales intervinientes.

Con el tiempo se demostró que era un buen consejo por otro motivo. Las tareas que nuestro cerebro hace en forma automática como reconocer un rostro o conducir un vehículo son muy difíciles de reproducir en orma de pograma informático.

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

Ubuntu 23.04 añadirá otro snap a su colección: Telegram

Ubuntu 23.04 con Telegram como Snap

Hay usuarios de Linux que aseguran que les encanta, otros no los quieren tocar ni con un palo y es uno de los motivos por los que se decantan por distribuciones como Linux Mint… Si los paquetes snap dejan indiferente a alguien, será a pocos. Canonical los lanzó hace ya casi siete años como una de las novedades de 16.04 Xenial Xerus, tiempo después se «cargó» la versión DEB de Chromium, luego hizo lo propio con Firefox y en Ubuntu 23.04 habrá más movimientos en este sentido.

Vaya por delante que, según se comenta, ha sido el equipo de Pavel Durov quien le ha pedido a Canonical que haga el cambio, tal y como se supone que hizo Mozilla con su Firefox. El problema que se pretende resolver es que la versión de Telegram que incluye Ubuntu llega directamente de los repositorios de Debian, un proyecto que entre sus características tiene que refrena un poco los paquetes para ir sobre seguro. Lo malo es que esto también puede traducirse en versiones desactualizadas, e incluso con bugs que ya están solucionados en las versiones más recientes.

Ubuntu 23.04 llegará en abril

Telegram pone a disposición de cualquier usuario una versión de su cliente de mensajería desde su página web. Aunque también está presente en la mayoría de tiendas de software, allí ofrece una APK para Android, un DMG para Mac, el instalable para Windows o los binarios autoactualizables para los usuarios de Linux. Por opciones no será, pero lo que no quieren es que nadie tenga software desactualizado, y por ese motivo se habrían puesto en contacto con Canonical.

Sabiendo que la compañía que dirige Mark Shuttleworth quiere impulsar el uso de los paquetes snap, estaba claro que aceptarían la (supuesta) propuesta. Lo que pasará en Ubuntu 23.04, y ya está pasando en las Daily Build, es que al introducir el comando sudo apt install telegram-desktop, se verá en el terminal que empieza el trabajo para instalar la versión snap, tal y como ya ocurre con Chromium o Firefox.

Si lo buscamos en la tienda de software, incluida GNOME Software si la instalamos, nada, Telegram no aparecerá como paquete DEB sencillamente porque ya no estará. El cambio podría «retro-portarse» a Ubuntu 22.04, y yo no descartaría que llegara también a 20.04. Sería parecido, pero no igual, a lo que pasa con LibreOffice: la suite de ofimática viene instalada por defecto en Ubuntu si no elegimos la instalación mínima, y lo hace en versión DEB, pero si se nos ocurre desinstalarla, lo único que encontraremos en sus repositorios oficiales serán más paquetes snap.

Telegram sería quien habría propuesto el cambio

Al final yo no sé qué hay de cierto en esta propuesta por parte de Telegram como la que hizo en su día Mozilla para su Firefox. Lo de Telegram tiene más sentido, pero Mozilla le dio más importancia a su repositorio oficial cuando se añadió la opción snap por defecto en Ubuntu. Puede ser verdad, y que la intención sea que una de las distribuciones Linux más populares no tenga una versión de un software con bugs, pero lo único que se confirma es que cada vez hay más software como snap en los sabores oficiales de Ubuntu, y no sé si para algunos usuarios se está tensando demasiado la cuerda.

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

El camino del software. Breve historia de la Inteligencia Artificial 3

Analizamos la evolución del software para inteligencia artificial
En los dos artículos anteriores vimos cómo el trabajo de Alan Turing, Claude Shannon y John von Neuman hicieron posible la creación de equipos capaces de albergar una inteligencia artificial. Sin embargo, todavía debían crearse programas capaces de hacer la tarea. Es por eso por lo que en este post contamos el camino del software desde las primeras simulaciones de conversación a los modelos de lenguaje actuales.

Alan Turing fue el primero en definir una forma de determinar el éxito de este tipo de programas.  El problema es que la prueba de Turing solo demostraba habilidad en la programación, no que estuviéramos ante lo que se pudiera denominar una inteligencia artificial.

El camino del software

Mientras que la definición de Marvin Minsky exige que para ser considerada inteligencia artificial una máquina debe realizar la misma tarea que cuando la hace un ser humano requiere la capacidad de pensar, la prueba de Turing solo pide que un ser humano no sea capaz de determinar si su interlocutor lo es o no.

Aunque ELIZA, un programa informático escrito a mediados de los 60, no fue pensado para pasar la prueba de Turing, sentó las bases de una serie de programas que sí intentarían hacerlo. El programa asumía el papel de una siquiatra que hacía una serie de preguntas a un paciente sobre temas comunes como familia, amigos o estado de ánimo. De acuerdo con las respuestas continuaba siguiendo un renglón preestablecido.

Ni ELIZA (Y de hecho ningún otro software) hubiera sido posible sin los trabajos de un profesor de matemáticas autodidacta llamado George Boole que en el siglo XIX empezó a estudiar la traducción a términos matemáticos del proceso del razonamiento humano. Para esto analizó la forma de agrupar los objetos en clases y que pasaba cuando estas clases se combinaban con otras. Luego asignó símbolos para cada una de esas relaciones.

De la formalización a la retroalimentación

Si se cambian los objetos de un conjunto por afirmaciones y establecemos tres relaciones posibles entre ellas (Y, O y NO) ya tenemos una forma de clasificarlas en uno de dos grupos (Verdadero o Falso).

Sin embargo, los trabajos de Boole no servían para todo tipo de afirmaciones. Se necesitaba una forma de describir conceptos generales. Es decir que podrían ser verdaderas o falsas dependiendo de las circunstancias.

Para que se entienda. Los trabajos de Boole permiten trabajar con la afirmación

Diego es argentino y escribe en Linux Adictos

Pero no puede hacer nada con:

X es… y escribe en Z.

Para esto hubo que esperar hasta la década del 70 del siglo XIX cuando un profesor alemán de apellido Frege introdujo el concepto de predicados. Un predicado es una afirmación que puede describirse como verdadera o falsa dependiendo de las circunstancias.

Diego, argentino y Linux Adictos son entidades que no son ni verdaderas o falsas, pero dependiendo de cómo se combinen en un predicado harán que estelo sea.

Freje agregó dos expresiones con sus correspondientes símbolos:

Para todo (Indica que todos los valores de una variable se cumple una condición)

Existe un… tal que (Implica que al menos hay un elemento que cumplirá una condición.

Teoría de la retroalimentación

El siguiente gran aporte para la creación de Inteligencia Artificial no fue matemático, vino de la Biología. Norbert Wiener, fundador de la Cibernética se interesaba por los puntos comunes entre la Ingeniería y la Biología.  Fue ese interés lo que lo llevó a analizar la forma en que los animales de sangre cálida mantenían su temperatura constante a pesar del cambio de la temperatura ambiente. Wiener postuló que en este y otros casos actuaban mecanismos de retroalimentación. Es decir que al recibir información se producía una respuesta para adaptarse a la misma.

Yendo más lejos, llegó a afirmar que los comportamientos inteligentes no son otra cosa que el resultado de mecanismos de retroalimentación. En otras palabras, podemos concluir que la inteligencia (natural o artificial) consiste en recopilar información, procesarla, actuar de acuerdo con el resultado y repetir el proceso.

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

WINE 8.0 llega a su versión estable introduciendo muchísimas mejoras, como Mono 7.4 o conversión de módulos a PE finalizada

WINE 8.0

Si yo hubiera apostado, habría perdido mi dinero. Se sabía que WINE 8.0 estaba cerca de llegar, ya que el año pasado se lanzaron siete Release Candidates de la v7.0 de este software para ejecutar aplicaciones de Windows en otros sistemas operativos, pero personalmente pensaba que llegaría ya en febrero. No ha sido así. Hoy 24 de enero, WineHQ ha lanzado la nueva versión estable, y llega con una larga lista de novedades.

La notificación de WineHQ está disponible en este enlace, en donde se explican cosas como que, después de 4 años de desarrollo, la conversión a PE ya ha sido completada. Tal y como explican, «Se trata de un hito importante en el camino hacia la compatibilidad con diversas funciones, como la protección anticopia, las aplicaciones de 32 bits en hosts de 64 bits, depuradores de Windows, aplicaciones x86 en ARM, etc«.

Novedades más destacadas de WINE 8.0

  • Finalización de la conversión de todos los módulos de WINE al formato PE.
  • Continuación del trabajo en WoW64 para permitir, en última instancia, que las aplicaciones Windows de 32 bits funcionen sin una biblioteca Unix de 32 bits.
  • Se ha añadido un tema gráfico «ligero» a la configuración por defecto.
  • Se ha implementado la arquitectura del procesador de impresión.
  • Mejoras continuas en torno a la funcionalidad Direct2D y Direct3D, incluyendo optimizaciones de rendimiento.
  • La biblioteca de sombreadores VKD3D ha implementado un nuevo compilador y desensamblador HLSL.
  • Se ha mejorado considerablemente la compatibilidad con la conexión en caliente de controladores.
  • Mejor soporte para la detección de dispositivos de volante, Force Feedback y otras funciones de entrada.
  • Mejoras en el manejo de fuentes.
  • Actualización del motor Mono a Mono 7.4.
  • Todas las aplicaciones integradas utilizan Common Controls v6 para el renderizado HiDPI por defecto y la tematización.
  • Varias actualizaciones de la infraestructura de compilación y de las herramientas de desarrollo.
  • Actualizaciones de muchas de las bibliotecas incluidas en WINE.

El tarball de WINE 8.0 está disponible en este enlace. A partir de ahora, las diferentes distribuciones Linux irán añadiendo la nueva versión a sus repositorios oficiales; no olvidemos que esta es la versión estable y no otra más de desarrollo. Las de desarrollo empezarán a llegar en breve para preparar el WINE 9.0 que debería llegar a principios de 2024, primero una cada dos semanas, luego una semanal en la fase de Release Candidates, luego la estable y vuelta a empezar.

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

El creador del lenguaje C++ critico un informe de la NSA sobre lenguajes de programación seguros

bjarne-stroustrup

Bjarne Stroustrup responde a la recomendación de la NSA y contradice la clasificación de C++

Bjarne Stroustrup, el creador del lenguaje C++, publicó objeciones a los hallazgos del informe de la NSA, que recomendaba que las organizaciones se alejaran del uso de lenguajes de programación como C y C++, que trasladan la gestión de la memoria al desarrollador, a favor de los lenguajes como C#, Go, Java, Ruby, Rust y Swift que brindan administración de memoria automática o realizan comprobaciones de seguridad de la memoria en tiempo de compilación.

Según Stroustrup, los lenguajes seguros mencionados en el informe de la NSA no son realmente superiores a C++ en aplicaciones importantes desde su punto de vista.

La NSA aconseja a las organizaciones que consideren hacer un cambio estratégico de los lenguajes de programación que proporcionar poca o ninguna protección de memoria inherente, como C/C++, a un lenguaje seguro para la memoria
cuando sea posible

En particular, las Directrices básicas de C++, que se han desarrollado en los últimos años, cubren métodos para una programación segura y prescriben el uso de herramientas que garantizan un trabajo seguro con tipos y recursos. Sin embargo, los desarrolladores que no requieren garantías de seguridad tan sólidas pueden continuar utilizando métodos de desarrollo más antiguos.

Stroustrup cree que un buen analizador estático que cumpla con las Directrices principales de C++ puede proporcionar las garantías de seguridad necesarias para el código C++ a un costo mucho menor que cambiar a nuevos lenguajes de programación seguros.

Por ejemplo, la mayoría de las Directrices principales ya están implementadas en el analizador estático y el perfil seguro para la memoria de Microsoft Visual Studio. Algunas de las recomendaciones también se tienen en cuenta en el analizador estático Clang tidy.

El informe de la NSA también fue criticado por centrarse solo en problemas de memoria, dejando sin abordar muchos otros problemas del lenguaje de programación que afectan la seguridad y la confiabilidad.

Desafortunadamente, gran parte del uso de C++ también está atascado en el pasado distante, ignorando las mejoras, incluidas las formas de mejorar drásticamente la seguridad. Ahora, si considerara cualquiera de esos lenguajes «seguros» superiores a C++ para la gama de usos que me interesan, no consideraría la desaparición de C/C++ como algo malo, pero ese no es el caso.

Bjarne Stroustrup no está de acuerdo con el hecho de que la publicación de la NSA limita la noción de proteger el software a la de proteger la memoria. En realidad, este aspecto es un denominador común de todas las publicaciones que aconsejan desechar C o C++ en favor del lenguaje Rust por las garantías de seguridad del software que varias grandes empresas (Microsoft, Amazon, etc.) lo reconocen.

“No existe una definición única de ‘seguridad’ y podemos lograr una variedad de tipos de seguridad a través de una combinación de estilos de programación, bibliotecas de soporte y aprovechamiento del análisis estático”, dice. Bjarne Stroustrup sugiere así que lo que se puede obtener de C++ en términos de seguridad del software depende, entre otras cosas, del desarrollador y, en particular, del conocimiento de las herramientas que ofrece el lenguaje, su dominio del compilador, etc.

Stroustrup ve la seguridad como un concepto más amplio, cuyas diversas facetas se pueden lograr mediante una combinación de estilo de codificación, bibliotecas y analizadores estáticos. Para controlar la inclusión de reglas que garanticen la seguridad de trabajar con tipos y recursos, se propone utilizar anotaciones en el código y opciones del compilador.

En aplicaciones donde el rendimiento es más importante que la seguridad, este enfoque permite el uso selectivo de herramientas que garantizan la seguridad solo donde se necesita. Las herramientas de mejora de la seguridad también se pueden aplicar parcialmente, como limitar primero las reglas de verificación e inicialización del rango y luego adaptar gradualmente el código a requisitos más estrictos.

Finalmente si estás interesado en poder conocer más al respecto sobre la publicación del creador de C++, puedes consultar los detalles en el siguiente enlace.

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

ChatGPT Professional tendrá un costo de $42 por mes

ChatGPT

ChatGPT es un prototipo de chatbot de inteligencia artificial

Se dio a conocer la noticia por parte de algunos usuarios de ChatGPT informaron que obtuvieron acceso anticipado a «ChatGPT Professional», la versión premium del chatbot de IA de OpenAI, que el costo por el uso de este será de $42 por mes.

Sin embargo, todavía no se ha hecho ningún anuncio oficial, lo que significa que todavía podría ser un experimento y este precio no es definitivo. Según las capturas de pantalla compartidas por los usuarios que obtuvieron acceso, a este precio obtienes una velocidad de respuesta más rápida, un acceso más confiable (porque ChatGPT a menudo se bloquea debido a una gran cantidad de solicitudes de red) y «acceso prioritario a nuevas funciones».

Este fin de semana, algunos usuarios informaron haber obtenido acceso a una versión pro que cuesta $42 por mes. OpenAI no ha confirmado el rumor y no ha hecho ningún anuncio sobre dicho lanzamiento, aunque hay que recordar que las funciones y los precios pueden cambiar antes del lanzamiento real de ChatGPT Professional. Como dijo OpenAI a principios de este mes:

«Tenga en cuenta que este es un programa experimental temprano que está sujeto a cambios, y no devolveremos el acceso a la versión paga generalmente disponible en este momento». Siendo así, ¿qué te aportan estos 42 dólares al mes?

Las capturas de pantalla compartidas por los primeros evaluadores de la versión ChatGPT Pro muestran que obtiene una velocidad de respuesta más rápida, un acceso más confiable y acceso prioritario a las nuevas funciones de chatbot.

Zahid Khawaja, un desarrollador que trabaja en proyectos de IA, compartió un video del nivel profesional trabajando tanto en computadoras de escritorio como en dispositivos móviles (junto con una captura de pantalla de su pago a OpenAI como prueba). Como señala Khawaja, el sistema definitivamente responde más rápido que la versión gratuita, que actualmente está plagada de una serie de problemas.

https://platform.twitter.com/widgets.js

De hecho, ChatGPT ha sido visto millones de veces desde su lanzamiento a fines de noviembre, y la gente se apresuró a aprovechar la capacidad del chatbot para responder preguntas, a veces con gran precisión. Debido al número cada vez mayor de usuarios, ChatGPT a menudo falla.

Para hacer frente a la demanda, OpenAI dice que se ha visto obligado a implementar límites de uso, introducir un sistema de colas durante los períodos pico y otros métodos para minimizar la demanda. Un mensaje en pantalla que pide a los usuarios que tengan paciencia mientras esperan que el sistema se escale.

Aun que por la parte del costo, muchos usuarios mencionar que es demasiado alto, ya que dicen que

«si estuviera ganando dinero, podría justificar los $42 al mes, pero en mi país eso es un buen porcentaje del salario mínimo”, dijo un usuario.

Otro usuario escribió:

«Realmente quería pagar por la versión pro, pero $42 es demasiado». Un tercero dijo: «$ 42 no es demasiado para las personas que son grandes usuarios y quieren convertirse en ‘superhumanos’ con la ayuda de la IA. Pero será demasiado para muchos”. Todos consideran que el precio de ChatGPT Professional es demasiado alto.

Hay que aclarar que el juicio de los usuarios sobre el precio dependerá de su necesidad del servicio, dado que las personas que usan ChatGPT para acelerar su trabajo y para esas personas, $ 42 por mes es probablemente un gasto razonable como cualquier otra suscripción de software, ademas de que las empresas que usan ChatGPT también podrían permitirse pagar esta cantidad. Sin embargo, los usuarios casuales de ChatGPT tendrán que esperar que la versión gratuita permanezca y mantenga la paridad de características (más o menos) con la versión profesional.

En última instancia, incluso un precio pequeño será un filtro efectivo para ver qué tan útil es realmente ChatGPT, y dada la falta de servicios comparables, $42 es probablemente un primer intento especulativo de fijación de precios de OpenAI.

Además, los analistas esperan que el mercado de chatbots de IA explote este año. No solo se están desarrollando sistemas rivales como Claude, una IA construida por ex miembros del equipo de OpenAI, pero que actualmente solo está disponible en versión beta cerrada, sino que Microsoft también planea hacer la integración en sus servicios.

Por otra parte, Google tambien se está preparando para lanzar su propio producto de búsqueda mejorado por chat a finales de este año. La herramienta de inteligencia artificial de Google podría basarse en el modelo de lenguaje Sparrow de su empresa hermana DeepMind.

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