The first computer “love” is the Commodore 64 and I get real excited about new developments and uses of modern tech to allow the 40 year old computer to persist. it’s really quite amazing what is now an obscure, old, 8-bit machine has what is arguably a more flourishing existence than it ever has. I […]

Se você tem dificuldade de manter contato visual durante lives e gravações de vídeo, a Nvidia resolve este problema lançando um software de correção da direção dos olhos. O recurso específico permite que o usuário simule o contato visual, mesmo que esteja olhando para outro lugar.

A tecnologia NVIDIA Broadcast proporciona um resultado de processamento similar ao “deepfake” em que os olhos da pessoa são manipulados para parecer que estão seguindo a câmera, aumentando assim a conexão com o público. É uma ótima solução para quem tem dificuldades de se sentir à vontade durante as lives e gravações de vídeo.

Esta tecnologia da NVIDIA foi batizada como Eye Contact, que utiliza uma IA para simular seus olhos sempre olhando para a câmera e incluir efeito de transições.

É um grande passo além do aprimoramento do seu software de gravação e streaming, pois oferece aos usuários a capacidade de melhorar a sua presença na câmera, fazendo com que eles se pareçam mais presentes e envolvidos, mesmo quando estão gravando ou transmitindo a partir de casa. O Eye Contact ajusta automaticamente a direção da câmera de modo que os olhos do usuário sejam sempre direcionados para a câmera, em vez de olhar para o lado. Além disso, ele ajusta o foco da câmera para manter a imagem nítida, independentemente do movimento dos usuários. Esta nova tecnologia promete melhorar a experiência do usuário ao gravar ou transmitir, permitindo que eles tenham uma aparência mais profissional e envolvente.

Seguimos con los widgets para el escritorio de la Comunidad KDE. En esta ocasión os presento Scriptinator, el plasmoide que nos permite lanzar comandos desde el escritorio de diferentes métodos y con el que llegamos a las 217 de esta serie de miniaplicaciones que se une a la ingente cantidad de widgets de este tipo presentados en el blog.

Scriptinator, el widget para lanzar comandos desde el escritorio – Plasmoides de KDE (217)

De plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.

Así que espero que le deis la bienvenida a un plasmoide de llamado Scriptinator, creado por tubbadu , y que se trata de un widget que nos permite escribir comandos que se ejecutarán según como deseemos. Siendo más específicos:

• al inicio
• periódicamente
• al desplazarse hacia arriba
• al desplazarse hacia abajo
• -al pasar el ratón por encima

Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecer?: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

La entrada Scriptinator, el widget para lanzar comandos desde el escritorio – Plasmoides de KDE (217) se publicó primero en KDE Blog.

This is the fifth part of my syslog-ng tutorial. Last time we had an overview of the syslog-ng configuration and had our first steps working with syslog-ng. Today we learn about syslog-ng source definitions and how to check the syslog-ng version and its enabled features.

You can watch the video on YouTube:

Or you can read the rest the tutorial as a blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-5-sources

Originally I was going to make a video of applying a screen protector to the SteamDeck but… why? It’s not like it would be all that interesting and would probably be another turd of a video so just a blathering is just as well. The production time for writing something out is far, far less […]

Collaboration is the heart of the OBS project. Therefore, we have been working on the request page redesign for a while, the page where most of the collaboration happens. This time, we have focused on improving the handling of requests with multiple actions, facilitating the review process by enhancing the code changes and helping out with decision-making, among others. The request redesign is part of the beta program. We started the redesign of the request...

The openSUSE Project was inspired by Fedora’s efforts to make Cisco’s OpenH264 codecs and FDK AAC available to its users that members reached out to Cisco’s open-source team to do the same for its user base.

An obstacle to overcome is the current limitation for free redistribution of the codecs is 100,000 users, so board member Neal Gompa and openSUSE’s Leap release manager Lubos Kocman proposed a way to simplify the codec installation in openSUSE.

The codec library, which supports H.264 encoding and decoding, is suitable for real-time-application use like WebRTC. The simplification of the installation will make out-of-the-box use much easier for openSUSE users.

Cisco, which the openSUSE Project is very thankful for their efforts, agreed to an approach on OpenH264 re-distribution via a Cisco-owned infrastructure to openSUSE users. A release workflow for OpenH264 was envisioned and a three-step approach handled via a set of scripts in openSUSE Release Tools. 

A workflow script triggers and sends Cisco an email with an archive containing OpenH264 rpm packages to Cisco; it makes a snapshot of data that is then sent or “POSTed” for manual extraction of a Cisco binaries. The process ensures that the project always has a set of related binaries in the Open Build Service. 

An archive is created and sent by one of multimedia:libs:cisco-openh264 project maintainers. 

The package is signed in OBS by the openSUSE key, so the origin of the package can be verified. The repository metadata is published by OBS under codecs.opensuse.org/openh264.

The archive must contain only packages with Cisco OpenH264 and related OpenH264 GStreamer plugins. Addition of any other content outside of the agreement, especially other codecs, under the agreement from Cisco would lead to a violation.  

Potential improvements have already been discussed to improve the existing workflow, but the initial efforts are set to provide openSUSE a more simplified experience after installation. 

Or enable repo manually by running the following:

Leap

sudo zypper ar http://codecs.opensuse.org/openh264/openSUSE_Leap repo-openh264

Tumbleweed or MicroOS  

sudo zypper ar http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed repo-openh264

Installation

sudo zypper in gstreamer-1.20-plugin-openh264

The openh264 repository will be enabled by default on all new installations of openSUSE Tumbleweed starting with the next snapshot iso build. It will be also available as part of openSUSE Leap 15.5 Beta. 

Alternatively, using the openSUSE-repos for repository management will provide users an openh264 repo definition as part of the latest update. Users will need to remove old duplicate repo definitions manually as found in the project README file.

AAC has already been part of the distribution for several months.

Como ya dije hace poco, un año más se va a celebrar una nueva edición de un programa cuyo objetivo es incorporar nuevos estudiantes al gran proyecto mundial que es KDE.  Se trata de Season of KDE 2023 que a lo largo de más de una década de existencia se ha consolidado como una alternativa bastante fiable a otros programas como Google Summer of Code o Google Code In que consiguen incorporar sabia nueva al proyecto. Es por eso que me complace en anunciar que has sido publicados los proyectos y mentores de Season of KDE 202 con lo que ya puedes elegir a qué pudes dedicar tu tiempo de aprendzaje dentro de la Comundiad KDE.

Publicados los proyectos y mentores de Season of KDE 2023

Ya estamos inmersos en otro ciclo de los Season of KDE que este año cuenta con varios proyectos centrados en los objetivos de accesibilidad y sostenibilidad

Los proyectos de sostenibilidad contaron con quince candidatos excelentes para sólo tres proyectos, por lo que la selección de los alumnos fue todo un reto. Apreciamos mucho el tiempo que los solicitantes han invertido en presentar su candidatura, y animamos a los que no hayan sido seleccionados a seguir contribuyendo a KDE y al código abierto. Es posible hacer pequeñas contribuciones a los proyectos de KDE que permitan a los posibles mentores ver tu trabajo y luego asesorarte de manera informal.

Para ver todos los proyectos os remito a la página de novedades de KDE, el famoso dot, donde tenéis todos los detalles,

Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator

¿Qué es Season of KDE?

Uno de los objetivos del proyecto KDE es involucrar al mayor número de personas en él y para ello organiza todo tipo de acciones: eventos como Akademy, encuentros como los Sprints, blogs colaborativos como KDE Planet, participación en proyectos para estudiantes como el Google Code In o Google Summer of Code.

No contento con esto, una vez al año organiza Season of KDE, es decir, su programa para involucrar a nuevos estudiantes en KDE. Una especie de Google Summer of Code pero para colaborar directamente en KDE y con la posibilidad de desarrollar proyectos no vinculados necesariamente con la programación, es decir, proyectos de promoción, documentación, diseño, etc.

Además, del anuncio oficial de lanzamiento del Dot de KDE donde se dan todos los detalles en cuanto a fechas, escrito por Caio Jordão Carvalho, os dejo una especie de preguntas y respuestas sobre el proyecto, que seguro que te estás haciendo como:

• ¿Qué es Season of KDE? Bueno, eso ya lo he explicado.
• ¿Quién puede formar parte? Todo el mundo que quiera.
• ¿Qué gano con ello? Aparte de colaborar con el proyecto KDE, el proyecto más puntuado ganará un viaje a Akademy 2018 de Viena, con los gastos pagados. Además de una interesante línea en tu currículo.
• ¿Cuánto tiempo tengo? El plazo máximo para inscribirse tanto mentores como para estudiantes es del 15 de enero de 2023.
• ¿Cómo empiezo? Busca un mentor y propón tu idea.
• ¿Y si no se me ocurre nada? Pues mira en las ediciones de los años anteriores.

En fin, una buena forma de poner tu granito de arena en el proyecto KDE.

Más información: KDE

La entrada Publicados los proyectos y mentores de Season of KDE 2023 se publicó primero en KDE Blog.

I was doing some preparation for my weekly tutoring activity and when I realized I misspelled “science” on a particular file that I end up sharing with parents. Somehow, I spelled “scoence” and almost published the file spelled as such. I realized that somewhere along the line, Dolphin, the most amazing file manager wasn’t doing […]

En este artículo no encontrarás un tutorial de cómo utilizar el comando ls en tu sistema GNU/Linux. Veremos una breve historia de cómo ha evolucionado el comando

Si abrimos una terminal o un emulador de terminal en nuestro sistema GNU/Linux y queremos ver qué archivos y directorios existen en la ruta actual, para ello utilizaremos el comando ls

Cierto que hay otras alternativas, algunas modernas y con más funcionalidades como exa, pero ls será el comando en el que siempre confiar por estar presente en todos los sistemas GNU/Linux a los que accedas.

Veamos en este artículo una breve historia del comando ls

Este artículo es una traducción/adaptación del artículo escrito por Eric Fischer para la ya retirada Linux Gazette que puedes leer aquí. Me pareció curioso e interesante, por eso lo comparto traducido en el blog.

El comando ls que sirve para mostrar un listado de los archivos de una ruta, es una de las utilidades más esenciales para las personas que usen sistemas Unix y GNU/Linux y no sorprende que sea una de las utilidades más veteranas.

En los inicios fue llamado listf y estuvo disponible en el Compatible Time Sharing System (CTSS) del MIT en julio de 1961. En 1963 se añadieron algunas opciones que se podrían utilizar para modificar lo que el comando listf podía mostrar:

• listf → muestra un listado de archivo, los más nuevos primero
• listf rev → muestra un listado de archivo, los más antiguos primero
• listf extensión de archivo → ofrece información sobre el nombre nombrado
• listf mes día año → muestra n listado de los archivos más antiguos de la fecha introducida

En 1965, listf fue empliado para reconocer * como una forma de mostrar un listado de todos los archivos que coincidieran con un patrón específico, con más mejoras en la coincidencia de patrones en una versión actualizada del 3 de enero de 1966. La versión de 1966 también generalizó la sintaxis y agregó muchas opciones, que incluyen:

• listf (file) → lista solo archivo, no enlaces
• listf (auth) usuario → lista archivos creados por el nombre de usuario especificado
• listf (made) mmddyy [mmddyy] → lista archivos creados entre las fechas especificadas
• listf (srec) → listado por tamaño
• listf (smad) → listado por fecha de última modificación
• listf (rev) → listado en orden inverso
• listf (long) → listado en formato extenso

Cuando CTSS fue reemplazado por Multics, el comando listf se renombró a list, que opcionalmente podría abreviarse como ls. La primera versión de ls tenía menos opciones que las últimas versiones de listf, pero aún incluía, junto con algunas otras:

• list -all (ls -a) → lista todo (incluido archivos ocultos)
• list -date_time_modified (ls -dtm) → lista por fecha de la última modificación
• list -reverse (ls -rv) → lista en orden inverso

Cuando Bell Labs abandonó el desarrollo de Multics en 1969 y comenzó a trabajar en Unix, solo se mantuvo el nombre abreviado de list, ls. La primera edición (3 de noviembre de 1971) del manual de Unix documentó las siguientes opciones para ls, todas las cuales todavía están disponibles en la actualidad:

• ls -l → lista en formato largo
• ls -t → ordenado por fecha de modificación
• ls -a → lista todo, incluyendo archivos ocultos
• ls -s → incluye el tamaño de los archivos en el listado
• ls -d → lista el nombre de los directorios, no sus contenidos

Para la quinta edición (la página del manual es del 20 de marzo de 1974) la lista de opciones para ls se había expandido e incluía:

• ls -r → listado en orden inverso
• ls -u → usa la fecha de acceso, no la fecha de modificación
• ls -i → lista el número de inodo para cada archivo
• ls -f → no ordena en absoluto el listado

En la sexta edición en mayo de 1965, se añadió una funcionalidad más:

• ls -g → lista los identificativos de los grupos en formato largo

En mayo y agosto de 1977, Bill Joy hizo alguna modificaciones a su propio ls en la Universidad de California que después distribuiría como parte de su First Berkeley Software Distribution, 1BSD.

La mayor diferencia con esta versión de ls fue que mostraba el listado de archivos en múltiples columnas, en vez de solo listar un nombre por línea. Las opciones para controlar este nuevo formato fueron:

• ls -1 → lista un nombre por línea (sin columnas)
• ls -c → listado en columnas
• ls -x → listado en columnas, pero ordenado en cruz, no de arriba abajo
• ls -q → muestra los caracteres de control como `?’
• ls -m → todo en una línea, separado por comas

Hubo cierta controversia sobre si era apropiado incluir código para imprimir en columnas como parte integral de ls o si, en cambio, el formateo en columnas debería ser realizado por un programa separado al que la salida de ls (o cualquier otro programa) se podría redirigir su resultado.

A principios de 1979, Bell Labs lanzó la séptima edición de Unix. Su versión de ls no incorporó los cambios controvertidos y tenía una nueva opción que entraba en conflicto con una letra que Joy también había usado:

• ls -c → utiliza la fecha de cambio de inodo, no la fecha de modificación

Una nueva versión de Berkeley de ls, fechada el 26 de agosto de 1980 y lanzada con 4.0BSD, resolvió el conflicto poniendo en mayúsculas la opción de listar en columnas: ls -C. También agregó a lo que el manual llamaba en ese momento «un número increíble de opciones» los siguiente:

• ls -F → marca los directorios con / y los programas con *
• ls -R → lista de manera recursiva los subdirectorios
• ls -b → muestra los caracteres de controls como su códigos ASCII

Otra revisión en 4.2BSD (28 de julio de 1983) eliminó las opciones -m, -b y -x, pero no antes de que System V Release 2 hubiera agregado las tres a su propio repertorio de opciones. Estas opciones pervivieron temporalmente allí, pero ninguna de los tres sobrevivió a la estandarización POSIX, por lo que la versión 4.2BSD de ls es esencialmente ls como la conocemos hoy.

El comando ls actual de las distribuciones GNU/Linux deriva del comando de Unix y forma parte del paquete GNU coreutils y fue escrito por Richard Stallman y David MacKenzie. Aquí puedes ver el código de dicha herramienta y todo el conjunto coreutils

• https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree

---

¿Te ha resultado interesante conocer un poco más la historia detrás de este comando, que quizás es uno de los más utilizados? Espero que sí. Si tienes algo que aportar hazlo en los comentarios.

Por cierto, si quieres ampliar la lectura, te dejo un enlace (en inglés) donde explican, qué ocurre cuando abre una terminal y escribes el comando ls:

• https://www.warp.dev/blog/what-happens-when-you-open-a-terminal-and-enter-ls