Arquitetura vantagens e limitações diante de llama cpp e vLLM

Pesquisa em 22 de outubro de 2026

O vllm.cpp procura reunir a distribuição de um motor nativo com mecanismos de atendimento concorrente inspirados no vLLM. Seu benefício mais claro é executar inferência sem um ambiente Python ou PyTorch dentro do motor. O projeto oferece recursos relevantes de escalonamento e cache, este texto é baseado no github oficial.

O que é o projeto e quem o mantém

Apresentado pela equipe do LocalAI e associado a Ettore Di Giacinto, o vllm.cpp é um motor de inferência desenvolvido em C++20. Ele carrega pesos já treinados e executa os cálculos necessários para produzir respostas. Pode funcionar como biblioteca incorporada a outra aplicação, ferramenta de terminal ou servidor HTTP. O repositório atual está em localai-org/vllm.cpp; endereços antigos sob mudler/vllm.cpp redirecionam para ele. [1]

O projeto é independente e não recebe endosso do vLLM oficial. A licença do código é Apache 2.0; os modelos mantêm suas próprias licenças. Seu objetivo inclui reproduzir comportamentos do vLLM, mas isso não equivale a compatibilidade completa com todas as suas versões, modelos, extensões ou configurações. [1, 4]

Como a arquitetura atende várias requisições

Em uma conversa com um modelo há duas etapas importantes. No prefill, o motor processa o texto de entrada. No decode, produz a continuação, normalmente um token por etapa. O escalonador decide quais requisições entram em cada rodada e como compartilhar a capacidade disponível. Separar essas etapas ajuda a entender por que um programa pode responder rapidamente a uma pessoa e ainda se comportar mal com muitas pessoas simultâneas.

O vllm.cpp implementa continuous batching, prefill em partes, preempção e reutilização de prefixos. Com continuous batching, novas requisições podem entrar à medida que outras terminam, sem esperar o lote inteiro acabar. Por exemplo, uma resposta curta pode liberar espaço para uma nova conversa enquanto outra resposta longa continua. O benefício depende da carga e dos kernels que realmente executam o modelo. [4]

O KV cache paginado armazena os estados de atenção em blocos administrados pelo motor. A técnica reduz desperdícios de alocação e permite compartilhar blocos quando há prefixos compatíveis. Ela atua sobre a memória usada pelo contexto; não comprime automaticamente os pesos do modelo. O trabalho original sobre PagedAttention explica essa relação entre fragmentação, compartilhamento e capacidade de agrupar requisições. [5]

O projeto também expõe políticas inspiradas no SGLang. A opção chamada RadixAttention é um alias para o cache automático de prefixos por hash do próprio motor; a documentação esclarece que não existe um caminho separado com uma árvore radix. A política LPM prioriza requisições com o maior prefixo já disponível no cache e depende desse cache estar habilitado. Essa escolha pode evitar trabalho repetido em aplicações com um prompt de sistema compartilhado. [6]

Biblioteca formatos e compatibilidade

A interface C pública, em include/vllm.h, permite vinculação estática ou dinâmica e integração por FFI. Na consulta realizada, a ABI estava na versão 30, consultável por vllm_abi_version(). Isso facilita incorporar o motor a programas escritos em C, C++, Go ou Rust. A ABI tem regras explícitas de evolução; internamente, os comandos e o servidor continuam mudando rapidamente. [2]

O servidor oferece /v1/chat/completions, /v1/completions, streaming, /metrics e tokenização. Endpoints para embeddings e áudio dependem da arquitetura e dos callbacks carregados. A API compatível com OpenAI facilita reutilizar clientes, mas seus recursos precisam ser confirmados. Até /health indica apenas que o processo está vivo, sem comprovar uma primeira geração concluída. [7]

Os formatos centrais são Safetensors e GGUF, com caminhos para NVFP4, FP8 e famílias GGUF. A compatibilidade depende da arquitetura, do layout dos tensores, da quantização e do backend. Aceitar um formato em uma família não garante que qualquer checkpoint com esse rótulo execute em outra. A documentação, por exemplo, ainda recusa GGUF TQ1_0 e TQ2_0, apesar da existência de kernels ternários. [8]

A decodificação especulativa inclui MTP, DFlash e caminhos com n-gramas, com diferentes níveis de validação. O documento também distingue métodos aceitos no JSON de métodos que realmente executam: draft_model tem configuração reconhecida, mas a carga é recusada por faltar o caminho de execução. Ganhos dependem do modelo, da taxa de aceitação e da carga; a existência de uma opção não demonstra aceleração em qualquer cenário. [9]

Hardware e distribuição

O motor textual usa seu próprio runtime de tensores. A compilação utiliza CMake e um compilador C++20; o servidor usa cpp-httplib. Há backends CPU, CUDA, Metal e Vulkan, com cobertura que varia por operação e modelo. No caminho CUDA, alguns kernels Triton já são distribuídos como código previamente compilado: Python e Triton são necessários para regenerá-los, não para executar esses binários. Os drivers e as dependências do backend continuam necessários. [10]

Ambiente	Situação documentada e consequência
CPU x86 e Arm	Há caminhos nativos e seleção de instruções. Velocidade deve ser medida no processador e no modelo escolhidos.
NVIDIA CUDA	A referência principal de medição é o GB10. Compilar para outra arquitetura CUDA não comprova o mesmo desempenho.
Apple Metal e Vulkan	Há implementações, mas a cobertura e a validação variam entre operações e modelos.
AMD ROCm	Há execuções nativas em caminhos específicos; permanecem lacunas de correção e de validação entre dispositivos.
Intel XPU e NPU	Não há base documental para prometer aceleração Intel NPU pronta. A matriz ainda indica lacunas nos backends XPU.

Fontes da matriz: guias de compilação e ROCm e matriz de funcionalidades. Suporte por Vulkan a uma GPU não implica suporte à NPU do mesmo fabricante. [4, 10, 11]

A release publicada mais recente encontrada foi a v0.0.2, de 11 de agosto de 2026. Seus arquivos para Linux e macOS possuem classificações distintas, incluindo stable e preview. Recursos descritos na branch principal em outubro podem não estar nesse pacote de agosto. Os arquivos também têm exigências de ABI do sistema e arquitetura do dispositivo; um executável pequeno não é automaticamente portátil para qualquer distribuição Linux ou GPU. [12, 13]

O que os números publicados demonstram

Os resultados abaixo foram publicados pelos mantenedores e constituem evidência documental, sem execução de novos benchmarks nesta análise. A principal ressalva está no próprio protocolo: várias comparações foram feitas contra uma referência anterior do vLLM e aguardam repetição após a mudança da referência em setembro. As séries identificadas como vLLM 0.25.0 são marcadas como superadas. Portanto, resultados históricos não comprovam paridade com a versão atual. [3]

O anúncio de aproximadamente 140 vezes menos para instalar compara um binário de 66 MiB com uma instalação de 9,1 GiB, medidos no ambiente usado pelo projeto. A ordem de grandeza é relevante para distribuição, mas não representa uma redução de 140 vezes na RAM, na VRAM ou na memória necessária aos pesos. Contêineres, modelos e drivers também não cabem automaticamente nesses 66 MiB. [1, 13]

Métrica publicada	vllm.cpp	vLLM	Como interpretar
Pico de PSS	24,88 GiB	28,18 GiB	Aproximadamente 11,7% menos no ensaio.
Pico de RSS	24,88 GiB	28,56 GiB	Outra medida de memória residente; não somar à PSS.
Queda de MemAvailable	68,35 GiB	80,66 GiB	Variação da memória disponível do sistema naquele ensaio.

A tabela de memória refere-se ao Qwen3.6-27B NVFP4 no GB10, durante a janela de atendimento. O GB10 usa memória unificada: números de memória do processo e do dispositivo não devem ser somados como se fossem RAM e VRAM fisicamente independentes. Os valores demonstram uma economia naquele teste, sem estabelecer uma porcentagem universal. [3, 14]

O relatório detalhado de atendimento também preserva um contraexemplo: para outro checkpoint/caminho do Qwen3.6-27B, registra pico de RSS de 21,10 GiB no vllm.cpp e 13,09 GiB no vLLM. São medições históricas de configurações distintas da tabela anterior. Elas mostram por que a retirada do Python, isoladamente, não garante menor uso de memória em todos os modelos. [15]

Na série histórica do Qwen3.6-27B NVFP4 da Unsloth, o projeto publicou 86,05 contra 82,32 tokens totais por segundo com uma requisição, e tratou as demais concorrências como empates. Esses tokens totais incluem entrada e saída; não são 86 tokens gerados por segundo. O relatório específico também contém resultados abaixo do vLLM para outros checkpoints e cargas. Como as referências mudaram, a leitura correta é que houve cenários competitivos, sem evidência de vitória geral ou atual. [3, 15]

A comparação com llama.cpp exige ainda mais cautela. O relatório de CPU informa que um denominador usado era um fork local com alterações de desempenho e pede nova medição contra o upstream fixado. Há também séries antigas em que vllm.cpp perde. A página diz expressamente que não mediu atendimento concorrente contra o servidor llama.cpp naquele ensaio. Assim, não há fundamento para transformar a antiga alegação de ganho no prefill em superioridade geral. [16]

Um levantamento exploratório em AMD Strix Halo torna a limitação mais concreta: com Qwen3.8-27B Q4_K_M, publicou 12,219 tok/s de decode para llama.cpp, 11,056 tok/s derivados para vLLM e 5,397 tok/s derivados para vllm.cpp. O próprio estudo não certifica a comparação: a verificação de tokens não passou, houve sessões distintas e parte das taxas foi inferida de tempos com dois comprimentos de saída. Ele documenta uma observação localizada desfavorável ao vllm.cpp, não um ranking reproduzido para todo hardware. [17]

Vantagens e desvantagens diante do vLLM

A principal vantagem é operacional. Distribuir e incorporar uma biblioteca nativa pode simplificar imagens de sistema, instaladores e aplicações que já são escritas em C ou C++. Também reduz a necessidade de manter um ambiente Python/PyTorch dentro do motor. Essa simplificação tem valor mesmo quando a taxa de geração empata. O ganho deve ser avaliado pelo pacote completo utilizado, inclusive bibliotecas e serviços externos. [2, 10, 13]

O carregamento direto de Safetensors e GGUF é outro atrativo para quem trabalha com os dois ecossistemas. É preciso, porém, corrigir uma comparação frequente: o vLLM também aceita GGUF. Sua documentação atual encaminha esse suporte ao vllm-gguf-plugin e o classifica como experimental e pouco otimizado. A diferença está na integração e na cobertura dos caminhos de execução, não na exclusividade do formato. [8, 18]

A desvantagem mais forte aparece na escala. O vllm.cpp descreve sua situação como single-GPU; o paralelismo de tensores possui trabalho e testes parciais, sem validação completa em duas GPUs na matriz consultada. Paralelismo de pipeline, de especialistas e execução multinó continuam incompletos. O vLLM documenta estratégias de tensor e pipeline parallelism para uma ou várias máquinas, o que o torna a escolha mais sustentada pela documentação para esses requisitos. [4, 19]

O vLLM também possui um ecossistema de implantação e uma arquitetura com servidor de API, núcleo do motor e workers. Essa organização traz componentes a operar, mas serve a necessidades de concorrência e distribuição. Descrever o vLLM apenas como Python lento seria incorreto: os cálculos pesados usam kernels especializados. A troca de linguagem da coordenação não determina, sozinha, a velocidade da GPU. O vLLM atual também documenta CPU, NVIDIA, AMD, Intel XPU e Apple Silicon, com diferentes mecanismos de suporte. [20, 21]

Vantagens e desvantagens diante do llama cpp

O atrativo do vllm.cpp é reunir Safetensors e uma arquitetura de atendimento inspirada no vLLM dentro de uma biblioteca nativa. Um serviço com muitas requisições e prefixos repetidos pode se beneficiar dessas escolhas, se o modelo e o backend necessários estiverem bem implementados. Isso é uma hipótese técnica para testar, e não uma vantagem de throughput já demonstrada contra llama.cpp em todas as situações. [2, 6, 16]

O llama.cpp já oferece execução nativa, quantizações, ampla variedade de backends e inferência híbrida CPU/GPU. Seu servidor documenta múltiplos usuários, continuous batching, cache, ferramentas, saídas estruturadas e decodificação especulativa. Portanto, a comparação não deve partir da ideia de que ele atende apenas uma pessoa ou carece de batching. O interesse está em comparar a eficiência e o comportamento dessas implementações na carga real. [22, 23]

Para máquinas pessoais, GGUF e combinações de CPU/GPU, a cobertura publicada do llama.cpp costuma oferecer um ponto de partida mais abrangente. O vllm.cpp precisa demonstrar um benefício concreto que compense a migração e as lacunas do caminho escolhido. Além disso, chamar a biblioteca nativa de diferencial exclusivo seria incorreto: ambos têm essa característica. As licenças do código são distintas, Apache 2.0 no vllm.cpp e MIT no llama.cpp. [1, 22, 24]

Limitações que influenciam a adoção

Algumas limitações ficam mais claras nos documentos específicos do que na apresentação do repositório. Elas devem orientar a escolha dos recursos:

Jump-forward. A opção existe e é validada, mas não tem chamador na execução de produção. Habilitá-la não acelera requisições no estado documentado. [6]

KV externo. O cliente C++ de LMCache possui caminho documentado de execução. O OffloadingConnector local para CPU/disco ainda não possui a parte que transfere os dados para as páginas do motor e, por isso, sua utilização é recusada. O servidor externo LMCache pode continuar exigindo seu próprio ambiente Python. [25]

Multimodalidade. No HTTP, o guia distingue Qwen3-VL e dots3-note, com testes de integração em CPU usando pesos sintéticos. Imagens exigem RGB bruto no caminho descrito; PNG, JPEG e entrada de vídeo são recusados. Registrar uma arquitetura multimodal não demonstra que todas as formas de entrada, interfaces ou aceleradores foram validados. [26]

Integrações incompletas. A matriz registra LoRA ainda sem uso completo pelo servidor. Recursos podem ter código, configuração ou testes locais sem uma execução completa acessível ao usuário. A evolução da branch principal também exige fixar uma versão ou commit e validar novamente após mudanças. [1, 4]

Como escolher e testar

Necessidade	Ponto de partida sugerido
GGUF local e combinação de CPU e GPU	llama.cpp, pela cobertura publicada; confirmar o modelo e o backend.
Múltiplas GPUs ou máquinas	vLLM, pelos caminhos documentados de paralelismo e implantação.
Biblioteca C++ com atendimento no estilo vLLM	vllm.cpp como candidato a avaliação, fixando o commit e os recursos necessários.
Maior desempenho ou menor memória	Medir os três na mesma máquina e na mesma carga; o nome do projeto não decide.

Essas sugestões são uma interpretação técnica da cobertura e dos limites descritos nas fontes, não resultados de um novo ensaio. Um teste útil mantém o mesmo checkpoint e quantização, template de conversa, modo de raciocínio, número de tokens de entrada e saída, dtype do KV cache e regras de parada. Deve testar separadamente cache frio, cache aquecido e concorrências representativas.

As métricas que permitem decidir são tempo até o primeiro token, tempo entre tokens, tokens de saída por segundo, latência completa, percentis p95/p99, falhas e consumo de memória do conjunto de processos. PSS, RSS, memória do dispositivo e memória disponível do sistema medem coisas diferentes. A utilização de CPU também precisa ser medida: a ausência de Python não comprova, por si só, menos trabalho de CPU, menor energia ou melhor throughput.

O vllm.cpp merece avaliação quando a distribuição nativa e a incorporação ao produto são prioridades. Uma adoção pode se justificar por manutenção e integração, mesmo com desempenho semelhante. Para substituir um serviço existente, o critério deve ser um resultado reproduzido no modelo, hardware e nível de concorrência da aplicação, com os recursos necessários funcionando de ponta a ponta.

Fontes primárias

Consulta em 22 de outubro de 2026. Os documentos do vllm.cpp abaixo apontam para o retrato consultado do repositório, commit 845b3c59d43d1da2583efa738b9ec9f715ba2312. As datas e referências dos benchmarks são as dos respectivos ensaios, que podem ser anteriores a esse commit. As páginas dos outros projetos refletem a documentação pública consultada na data da pesquisa.

[1] vllm.cpp — apresentação autoria licença e aviso de desenvolvimento
[2] vllm.cpp — interface C e versão da ABI
[3] vllm.cpp — protocolo referências superadas e medições pendentes
[4] vllm.cpp — funcionalidades cobertura e limitações
[5] Kwon e colaboradores — PagedAttention e gestão do KV cache
[6] vllm.cpp — políticas inspiradas no SGLang e jump-forward
[7] vllm.cpp — servidor rotas e comportamento das APIs
[8] vllm.cpp — uso formatos quantizados e tamanho do contexto
[9] vllm.cpp — métodos e limites da decodificação especulativa
[10] vllm.cpp — compilação dependências e backends
[11] vllm.cpp — guia e limites do backend ROCm
[12] vllm.cpp — releases e arquivos publicados
[13] vllm.cpp — distribuição binária e dependências externas
[14] vllm.cpp — medições de memória
[15] vllm.cpp — comparações de atendimento com vLLM
[16] vllm.cpp — comparação de CPU com llama.cpp e denominadores superados
[17] vllm.cpp — levantamento exploratório em AMD Strix Halo
[18] vLLM — documentação atual de GGUF e plugin
[19] vLLM — paralelismo e escala
[20] vLLM — arquitetura e processos
[21] vLLM — instalação e plataformas de hardware
[22] llama.cpp — apresentação e backends
[23] llama.cpp — recursos e opções do servidor
[24] llama.cpp — licença MIT
[25] vllm.cpp — conectores de KV e limitações
[26] vllm.cpp — entradas multimodais no servidor HTTP

Me alegra compartir con todos vosotros la primera actualización de Plasma 6.8, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Primera actualización de Plasma 6.8

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que ayer martes 20 de octubre de 2026, una semana después de liberar el código de Plasma 6.8 la Comunidad KDE presenta la primera actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.8

Hoy es un buen día para recordar sus principales novadades:

• Sustitución del fondo de pantalla predeterminado: El fondo de pantalla Waterfall ha sido reemplazado por la nueva imagen Hanabi en la suite de estilos Breeze.
• Soporte para el calendario nepalí: Se ha añadido compatibilidad con el calendario nepalí (Bikram Sambat) dentro de la applet de calendario alternativo (Alternatecalendar).
• Mejoras en las decoraciones de ventanas GTK4: Se corrigieron problemas como el desbordamiento de botones y la eliminación de esquinas redondeadas inapropiadas en ventanas GTK4 que no utilizan CSD (Client-Side Decorations).
• Compatibilidad con decoraciones solo de sombra: La librería de decoración de ventanas y Breeze añaden soporte nativo para decoraciones basadas únicamente en sombras (shadow-only decorations).
• Avances y rediseño en Discover: Se añadió una nueva función de vista previa de AppStream (AppStream Preview Backend), además de incluir el estado de progreso como una sección ordenable en la lista de tareas.
• Ajustes en el menú de Bluedevil (Bluetooth): Se ha reubicado el botón de configuración para sacarlo del menú tipo hamburguesa, mejorando la accesibilidad para el usuario.
• Integración del buscador en la applet de sesiones de Kate: Se ha sustituido el campo de texto estándar por un campo de búsqueda dedicado (SearchField).
• Centrado de la ubicación en el widget del tiempo: Se ha optimizado el diseño en la applet del clima para centrar la etiqueta con la ubicación dentro del panel superior.
• Rediseño del panel de permisos para Flatpak: La página del módulo de control (KCM) para gestionar los permisos de Flatpak se ha migrado al nuevo formato de formularios (Forms).
• Mejoras en la experiencia de fallos (DrKonqi): Se renovó la interfaz gráfica del visor de volcados de memoria (coredump-gui) a módulos QML y se ajustó el seguimiento para registrar y notificar múltiples bloqueos o cierres inespera

Más información: KDE

• 
  Primera actualización de Plasma 6.8
  por baltolkien
  octubre 21, 2026
  Me alegra compartir con todos vosotros la primera actualización de Plasma 6.8, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores.
• 
  Lanzado Plasma 6.8, Edición del 30.º aniversario
  por baltolkien
  octubre 15, 2026
  El tiempo pasa inexorable y la Comunidad KDE lo aprovecha para mejorar, versión tras versión, la joya de su corona: el escritorio Plasma. Hoy me complace anunciar que ha sido… Leer más: Lanzado Plasma 6.8, Edición del 30.º aniversario

La entrada Primera actualización de Plasma 6.8 se publicó primero en KDE Blog.

Me alegra compartir con todos vosotros la séptima actualización de Plasma 6.6, continuando así la serie de revisión de software que le dotan de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades. Esta serie 6.6.x está teniendo más actualizaciones debido a un acuerdo entre la Comunidad KDE y KUbuntu Focus.

Séptima actualización de Plasma 6.6

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que el pasado viernes 16 de octubre de 2026, la Comunidad KDE presenta la séptima actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.6

Aprovecho para realizar un listado de las novedades generales de Plasma 6.6:

• Nuevo Teclado Virtual: Se estrena «Plasma Keyboard», un teclado en pantalla completamente renovado y mejorado para dispositivos táctiles.
• OCR en Spectacle: La herramienta de capturas de pantalla ahora puede reconocer y extraer texto de las imágenes capturadas.
• Plasma Setup: Un nuevo asistente de configuración inicial que permite crear cuentas de usuario y configurar la red de forma independiente al proceso de instalación del sistema.
• Temas Globales Propios: Ahora puedes convertir tu configuración actual en un «Tema Global» personalizado, que además es compatible con el cambio automático entre modo día y noche.
• Intensidad de color: Posibilidad de ajustar la intensidad del color de los cuadros de las ventanas.
• Selector de emojis: Nuevo selector de tonos de piel para los emojis (Meta + .).
• Conexión por QR: Si tienes una cámara, puedes conectarte a redes Wi-Fi escaneando códigos QR.
• Control de volumen rápido: Puedes ajustar el volumen de una aplicación específica pasando el puntero sobre su icono en el gestor de tareas y usando la rueda del ratón.
• Lista de ventanas: Nueva opción para abrir la lista al pasar el ratón (Open on hover) y filtrado de ventanas por actividad o escritorio.
• Propiedades rápidas: Manteniendo Alt y haciendo doble clic en un archivo del escritorio se abren sus propiedades.
• Filtros para Daltonismo: Se añade un filtro de escala de grises, sumando un total de 4 filtros para diferentes tipos de deficiencia visual.
• Modo de seguimiento en Lupa: Nuevo modo que mantiene el puntero siempre centrado en la pantalla mientras se usa el zoom.
• Mejoras en Wayland: Soporte para «Teclas lentas» (Slow Keys) y ajuste estándar de «Movimiento reducido».
• Escritorios Virtuales: Posibilidad de tener escritorios virtuales solo en la pantalla principal.
• Gestión de Energía: Brillo de pantalla automático para dispositivos con sensores de luz ambiental.
• Gaming: Soporte opcional para usar mandos de juegos como dispositivos de entrada comunes (ratón/teclado).
• Monitor del Sistema: Ahora permite elegir la prioridad de los procesos.
• Animaciones: Mayor fluidez en pantallas con altas tasas de refresco.

Más información: KDE

La entrada Séptima actualización de Plasma 6.6 se publicó primero en KDE Blog.

Last Sunday I spent my day at the third Audio Expo in Budapest. Yet again it was fantastic. And yet again, my favorite audio experience was in the NCS Audio room, even if I listened to lot more expensive systems.

TL;DR:

Made in Hungary audio rivals the rest of the world in quality, while often being available at a much more affordable price. My favorite of the show was the NCS Audio / Qualiton / Pixel cables room, all made in Hungary. 72 Audio was also perfect, as usual. Heed Audio Helikon with Zellaton speakers could fill the largest show room with lively sound. A pair of Popori Acoustics speakers sounded beautiful with a prototype Natural Distortion DAC and amp.

NCS Audio

This year I visited the Audio Expo with someone who prefers headphones. In her experience speakers cannot give you the level of dynamics and detail that a good pair of headphones can provide. In the NCS Audio / Qualiton / Pixel cables room this suddenly changed.

We listened to almost all the systems on the seven floors of the exhibition building. This was the one where we returned for a second round of listening. No matter the type of music we listened to, it had extreme clarity, even in the bass section. We were looking for where the band is hiding, as it sounded like an actual band was there, not just a pair of speakers.

Best of all: this was one of the most affordable systems at the expo, beating many more expensive systems in listening experience.

• https://www.audioexpo.hu/kiallitok/ncs-pixel-qualiton

72 Audio

Last year 72 Audio presented my favorite music experience at the Audio Expo. This year they presented a lot more affordable system. Still, it was one of the best sounding ones. Or, if you ask my partner, it was the best.

• 72 Audio: https://www.72audio.com/

Natural Distortion

Their products are still just a prototype, but they definitely sound fantastic. A miniature DAC and amp were driving a pair of huge Popori Acoustics speakers and provided one of the most detailed sound experiences at the expo.

We listened to some church organ music. The pedals sounded a bit weak, but for the rest I felt as if I was sitting in the church and was listening to the performance live. It is very rare that organs sound natural to me from speakers.

• Natural Distortion: https://www.audioexpo.hu/kiallitok/natural-distortion
• Popori Acoustics: https://poporiacoustics.com/

Some negative experiences

While Natural Distortion sounded perfectly natural, systems with room correction sounded completely distorted. One of the demo songs was organ music, and the presenter of the demo explained how all the hard work of DSPs ensures the perfect sound. There was more than enough bass, still the whole thing sounded to me a kind of unbalanced and processed. While listening, I did not have the illusion of sitting in the church at all.

I was looking forward listening to some of most hyped new devices developed here in Hungary. The DAC and active speakers sounded OK, but as the door of the listening room was wide open and fixed in that position, there was no chance to hear the details. Much of the music was lost in the noise coming from outside.

When it comes to music, size does not matter. There were quite a few huge speakers at the event, but most of them were just loud, without providing an enjoyable listening experience. Even my good old speakers at home provide a lot more detail than some of the giants at the event.

Some positive experiences

Talking about oversize speakers. This year the Visegrád room, the largest show room of the building, had a Heed Helikon as amp, and a pair of Zellaton speakers. In earlier years I was always disappointed in this room. Loud and slightly distorted music on a pair of very expensive speakers: not something for an extended listening session. This year the room was full of perfectly sounding music, and I only left because I wanted to visit each and every room before closing time. As an added bonus, we had Lucina Yue on site, talking about her latest album: https://tidal.com/album/450279864

Another setup on my favorites list was put together by Limar Audio. They used a pair of miniature bookshelf speakers from Paradigm, but they could fill the room with beautiful music.

I prefer speakers, but as I was with someone preferring headphones, we also listened to some. We saw some odd-looking oversize headphones at a HydraSound stand in the hall. The HEDD headphones sounded fantastic, but obviously listening to an open back headphone in a busy environment is far from optimal. After a while we learned that the stand was actually about cables, the headphones were not for sale :-)

We also visited the MUZIX stand in the basement and listened to several Final Audio headphones. Navigating a Japanese tablet was a kind of a challenge. Luckily I use TIDAL enough to be able to search all different kinds of music for testing. Final Audio excelled with each of them.

Conclusion

Obviously, we did not have a chance to hear all systems with all the different types of music we listen to: everything from classical to metal, jazz, electronica, progrock and even some pop occasionally. So, all experience depended on not just the systems, but also on the music played at the time of visit. Still, I suspect that there would not have been major changes in my review if we had had a chance for more thorough listening.

See you again next year!

Welcome to our monthly report from the openSUSE Kudos recognition platform, where we take a moment to put a spotlight on the people who stepped up, helped others, and made this community a little brighter.

During the month of September 2026, 14 users received 14 kudos, and 152 badges were awarded to 136 contributors. You can see stats for this and previous months.

Spotlight

September spread its thanks evenly, with fourteen people each receiving a kudo: @adrianSuSE, Bernhard Wiedemann (@bmwiedemann), Dominique Leuenberger (@dimstar), Geetansh Goyal (@geetxnshgoyal), @hennevogel, Imobach Gonzalez Sosa (@IGonzalezSosa) and eight more.

Kudos

Here are the thank-you notes themselves: 14 peer-to-peer kudos written by contributors about contributors, grouped by the person being thanked.

@adrianSuSE received a kudo:

From @lkocman in Infrastructure Heroes

“Many thanks for always being around and always willing to help Adrian!”

---

Bernhard Wiedemann (@bmwiedemann) received a kudo:

From @jsegitz in Code & Engineering

“Thank you for your tireless work on reproducible builds!”

---

Dominique Leuenberger (@dimstar) received a kudo:

From @lkocman in Code & Engineering

“Reporting a bug is great, but submitting a fix right out of the gate is next level. Especially if it is for a spicy architecture like s390x. Thank you DimStar!”

---

Geetansh Goyal (@geetxnshgoyal) received a kudo:

From @ddemaio in Documentation and Publishing

“Many thanks for sharing your Google Summer of Code experience on news.o.o. A fantastic & article”

---

@hennevogel received a kudo:

From @akarsh in Code & Engineering

“Thanks for the quick reviews on my first OBS PR”

---

Imobach Gonzalez Sosa (@IGonzalezSosa) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for making Agama changelog shiny and actually useful Imo!”

---

Jan Baier (@jbaier_cz) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your night watch over os-autoinst-distri-opensuse PRs Jan! You just helped to make Leap 16.1 RC greener in openQA”

---

Gertjan Lettink (@knurpht) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your quick feedback about opensuse-version-diff Gertjan. Your quick eye caught an obvious issue. Many thanks!”

---

Lubos Kocman (@lkocman) received a kudo:

From @ddemaio in Code & Engineering

“Your new #diff code makes openSUSE stronger every day. Especially with people getting immediate facts about the software versions in Leap and Tumbleweed.”

---

Max Lin (@mlin7442) received a kudo:

From @lkocman in Support & User Assistance

“Many thanks for all your tireless help with getting Leap 16.1 RC out of the door Yuchen!”

---

Martin Pluskal (@pluskalm) received a kudo:

From @kskarthik in Code & Engineering

“thanks a lot for the openSUSE packaging skills! it’s a very valuable assist in packaging chores”

---

Santiago Zarate (@szarate) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your awesome help with the Leap 16.1 immutable modes in openQA Santi! I’m super happy that thanks to you we were able to release RC in the same day as it landed in openQA! Many thanks again!”

---

@wrosenauer received a kudo:

From @bbreinbauer in Code & Engineering

“Thanks for working on Firefox and Thunderbird!”

---

@Zaitor received a kudo:

From @dimstar in Code & Engineering

“Thank you very much for all your endless work to make GNOME better for openSUSE. You do tremendous work.”

Badges

Contributors earned 12 different badges in September, and here is an overview of the 8 most awarded ones. The full list of badges you can earn is on the badges page.

100 Tumbleweed Contributions
For submitting 100 Submit Requests to openSUSE:Factory.
Awarded this month to @dimstar, @fstrba, @iznogood, @mcalabkova, @ojkastl_buildservice, @pushman and @StevenK.

---

10 Tumbleweed Contributions
For submitting 10 Submit Requests to openSUSE:Factory.
34 contributors earned this badge this month, too many to list here, but every one of them counts.

---

First Tumbleweed Contribution
For submitting 1 Submit Request to openSUSE:Factory.
81 contributors earned this badge this month, too many to list here, but every one of them counts.

---

Leap 16.0 Contributor
Recognition for submitting at least one pull request to Leap 16.0 or related appliance repositories on src.opensuse.org.
Awarded this month to @abergmann, @dimstar, @jirislaby, @jsmeix, @mschreiner, @rn and @vcarvalho.

---

Leap 16.1 Contributor
Recognition for submitting at least one pull request to Leap 16.1 or related appliance repositories on src.opensuse.org.
Awarded this month to @abergmann, @alois, @jirislaby, @jsmeix and @vcarvalho.

---

linuxdays.cz 2026
For supporting LinuxDays.cz 2026.
Awarded this month to @dancermak, @jbaier_cz and @VPetras.

---

Got First Kudo
Received your first kudos.
Awarded this month to @geetxnshgoyal, @jbaier_cz, @szarate, @wrosenauer and @Zaitor.

---

First Kudos Given
Shared your first kudos.
Awarded this month to @akarsh, @bbreinbauer, @jsegitz and @kskarthik.

---

Congrats on your kudos and badges. Keep up the great work everyone, and don’t forget to have a lot of fun!

Generated by kudos-bot-news-o-o from https://kudos.opensuse.org/api/reports/monthly for the period 1-30 September 2026.

Welcome to our monthly report from the openSUSE Kudos recognition platform, where we take a moment to put a spotlight on the people who stepped up, helped others, and made this community a little brighter.

During the month of September 2026, 14 users received 14 kudos, and 152 badges were awarded to 136 contributors. You can see stats for this and previous months.

Spotlight

September spread its thanks evenly, with fourteen people each receiving a kudo: @adrianSuSE, Bernhard Wiedemann (@bmwiedemann), Dominique Leuenberger (@dimstar), Geetansh Goyal (@geetxnshgoyal), @hennevogel, Imobach Gonzalez Sosa (@IGonzalezSosa) and eight more.

Kudos

Here are the thank-you notes themselves: 14 peer-to-peer kudos written by contributors about contributors, grouped by the person being thanked.

@adrianSuSE received a kudo:

From @lkocman in Infrastructure Heroes

“Many thanks for always being around and always willing to help Adrian!”

---

Bernhard Wiedemann (@bmwiedemann) received a kudo:

From @jsegitz in Code & Engineering

“Thank you for your tireless work on reproducible builds!”

---

Dominique Leuenberger (@dimstar) received a kudo:

From @lkocman in Code & Engineering

“Reporting a bug is great, but submitting a fix right out of the gate is next level. Especially if it is for a spicy architecture like s390x. Thank you DimStar!”

---

Geetansh Goyal (@geetxnshgoyal) received a kudo:

From @ddemaio in Documentation and Publishing

“Many thanks for sharing your Google Summer of Code experience on news.o.o. A fantastic & article”

---

@hennevogel received a kudo:

From @akarsh in Code & Engineering

“Thanks for the quick reviews on my first OBS PR”

---

Imobach Gonzalez Sosa (@IGonzalezSosa) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for making Agama changelog shiny and actually useful Imo!”

---

Jan Baier (@jbaier_cz) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your night watch over os-autoinst-distri-opensuse PRs Jan! You just helped to make Leap 16.1 RC greener in openQA”

---

Gertjan Lettink (@knurpht) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your quick feedback about opensuse-version-diff Gertjan. Your quick eye caught an obvious issue. Many thanks!”

---

Lubos Kocman (@lkocman) received a kudo:

From @ddemaio in Code & Engineering

“Your new #diff code makes openSUSE stronger every day. Especially with people getting immediate facts about the software versions in Leap and Tumbleweed.”

---

Max Lin (@mlin7442) received a kudo:

From @lkocman in Support & User Assistance

“Many thanks for all your tireless help with getting Leap 16.1 RC out of the door Yuchen!”

---

Martin Pluskal (@pluskalm) received a kudo:

From @kskarthik in Code & Engineering

“thanks a lot for the openSUSE packaging skills! it’s a very valuable assist in packaging chores”

---

Santiago Zarate (@szarate) received a kudo:

From @lkocman in Code & Engineering

“Many thanks for your awesome help with the Leap 16.1 immutable modes in openQA Santi! I’m super happy that thanks to you we were able to release RC in the same day as it landed in openQA! Many thanks again!”

---

@wrosenauer received a kudo:

From @bbreinbauer in Code & Engineering

“Thanks for working on Firefox and Thunderbird!”

---

@Zaitor received a kudo:

From @dimstar in Code & Engineering

“Thank you very much for all your endless work to make GNOME better for openSUSE. You do tremendous work.”

Badges

Contributors earned 12 different badges in September, and here is an overview of the 8 most awarded ones. The full list of badges you can earn is on the badges page.

100 Tumbleweed Contributions
For submitting 100 Submit Requests to openSUSE:Factory.
Awarded this month to @dimstar, @fstrba, @iznogood, @mcalabkova, @ojkastl_buildservice, @pushman and @StevenK.

---

10 Tumbleweed Contributions
For submitting 10 Submit Requests to openSUSE:Factory.
34 contributors earned this badge this month, too many to list here, but every one of them counts.

---

First Tumbleweed Contribution
For submitting 1 Submit Request to openSUSE:Factory.
81 contributors earned this badge this month, too many to list here, but every one of them counts.

---

Leap 16.0 Contributor
Recognition for submitting at least one pull request to Leap 16.0 or related appliance repositories on src.opensuse.org.
Awarded this month to @abergmann, @dimstar, @jirislaby, @jsmeix, @mschreiner, @rn and @vcarvalho.

---

Leap 16.1 Contributor
Recognition for submitting at least one pull request to Leap 16.1 or related appliance repositories on src.opensuse.org.
Awarded this month to @abergmann, @alois, @jirislaby, @jsmeix and @vcarvalho.

---

linuxdays.cz 2026
For supporting LinuxDays.cz 2026.
Awarded this month to @dancermak, @jbaier_cz and @VPetras.

---

Got First Kudo
Received your first kudos.
Awarded this month to @geetxnshgoyal, @jbaier_cz, @szarate, @wrosenauer and @Zaitor.

---

First Kudos Given
Shared your first kudos.
Awarded this month to @akarsh, @bbreinbauer, @jsegitz and @kskarthik.

---

Congrats on your kudos and badges. Keep up the great work everyone, and don’t forget to have a lot of fun!

Generated by kudos-bot-news-o-o from https://kudos.opensuse.org/api/reports/monthly for the period 1-30 September 2026.

El incansable trabajo de promoción que está realizando Nate (ahora con ayuda de otros desarrolladores) en su blog sigue su ritmo. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y desde hace un tiempo que le voy a siguiendo semana tras semana, traduciendo sus artículos al castellano utilizando los magníficos traductores lo cual hará que la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «Nuevo widget meteorológico y teclado en pantalla» de «Esta semana en Plasma», donde empezamos a vislumbrar las novedades que obtendremos en la siguiente iteración del entorno de trabajo de la Comunidad KDE: plasma 6.9.

Nuevo widget meteorológico y teclado en pantalla – Esta semana en Plasma

Nota: Artículo original en Blogs KDE. Traducción realizada utilizando Perplexity. Esta entrada está llena de novedades de la Comunidad KDE. Mis escasos comentarios sobre las mejoras entre corchetes.

Novedades destacadas

Plasma 6.9

El widget de informe meteorológico ha recibido grandes cambios: un nuevo diseño que incluye previsiones de temperatura y precipitaciones por hora, además de compatibilidad con las previsiones meteorológicas de Open-Meteo. (Bohdan Onofriichuk y tusooa the west wind, kdeplasma-addons MR #1037, KDE Bugzilla #451767)[Lo cierto es que los últimos plasmoides de terceros le lavan la cara al que lleva por defecto Plasma, así que no está de más actualizar este veterano widget].

El teclado en pantalla de Plasma se ha rediseñado a fondo y ahora incluye varias funciones muy deseables: la opción de un teclado de tamaño completo con teclas de flecha y modificadoras; un teclado de deslizamiento para japonés; y distribuciones independientes de las configuraciones regionales del sistema. (Devin Lin, plasma-keyboard MR #109) [Ya hace algunas versiones que le están dando amor, esta versión ya parece bastante madura].

La función de luz nocturna ahora permite activarla o desactivarla temporalmente durante un periodo determinado, con independencia de su programación habitual. (Vlad Zahorodnii, kwin work item #321) [Una opción bastante interesante].

Por desgracia, los cambios de temperatura de color no se aprecian en este vídeo, pero confía en mí: ¡algo sucede de forma visible en una pantalla física!

Si prefieres que los iconos de la bandeja del sistema sean realmente pequeños, ahora puedes configurarlos así. (Jin Liu, plasma-workspace MR #6978) [A mi edad, esta novedad no será probada].

Mejoras en la interfaz

Plasma 6.8.1

Plasma ahora muestra un OSD al usar el teclado para aumentar el brillo cuando ya está en su nivel máximo, igual que ya lo hace al intentar subir el volumen cuando este está al máximo. (Pavel Radzivilovsky, KDE Bugzilla #505558) [Eso está bien ya que así tenemos información simple de qué está pasando].

Plasma 6.9

Los atajos de teclado relacionados con el portapapeles que se muestran en Preferencias del sistema ahora se agrupan en su propia sección, en lugar de aparecer en la sección genérica «Espacio de trabajo de Plasma». Además, la función que básicamente rota todo el historial del portapapeles hacia arriba o hacia abajo (de modo que un elemento nuevo pasa a ser el primero y se puede pegar fácilmente) ahora usa esa terminología para que sea más sencillo entender cómo funciona. (Taras Oleksyn y Tomáš Hnyk, plasma-workspace MR #7208, KDE Bugzilla #467252)

Plasma ya no muestra una notificación al conectar una nueva pantalla si se trata de una salida virtual. Pero si es una pantalla física real, la notificación ahora muestra más información sobre ella. (Kai Uwe Broulik, plasma-workspace MR #7233, plasma-workspace MR #7195)

Al eliminar una red en la página de Wi-Fi y redes de Preferencias del sistema, el panel derecho ya no se oculta hasta que se selecciona una nueva red en la barra lateral. (Taras Oleksyn, KDE Bugzilla #511362)

En sistemas operativos que configuran Discover para usar tanto PackageKit como las «actualizaciones sin conexión», la página con los detalles de cada paquete que se va a actualizar ahora también indica las versiones actuales de los paquetes, no solo las nuevas. (Taras Oleksyn, KDE Bugzilla #500663)

Qt 6.13.0

Qt ahora renderiza las fuentes con hinting al usar un factor de escala superior al 100%. (Infinality, Qt Bug #128874)

Corrección de errores importantes

[No comento las correcciones de errores ya que son bastante evidentes].

Plasma 6.8.1

Plasma ahora muestra un OSD al usar el teclado para aumentar el brillo cuando ya está en su nivel máximo, igual que ya lo hace al intentar subir el volumen cuando este está al máximo. (Pavel Radzivilovsky, KDE Bugzilla #505558)

Plasma 6.9

Los atajos de teclado relacionados con el portapapeles que se muestran en Preferencias del sistema ahora se agrupan en su propia sección, en lugar de aparecer en la sección genérica «Espacio de trabajo de Plasma». Además, la función que básicamente rota todo el historial del portapapeles hacia arriba o hacia abajo (de modo que un elemento nuevo pasa a ser el primero y se puede pegar fácilmente) ahora usa esa terminología para que sea más sencillo entender cómo funciona. (Taras Oleksyn y Tomáš Hnyk, plasma-workspace MR #7208, KDE Bugzilla #467252)

Plasma ya no muestra una notificación al conectar una nueva pantalla si se trata de una salida virtual. Pero si es una pantalla física real, la notificación ahora muestra más información sobre ella. (Kai Uwe Broulik, plasma-workspace MR #7233, plasma-workspace MR #7195)

Al eliminar una red en la página de Wi-Fi y redes de Preferencias del sistema, el panel derecho ya no se oculta hasta que se selecciona una nueva red en la barra lateral. (Taras Oleksyn, KDE Bugzilla #511362)

En sistemas operativos que configuran Discover para usar tanto PackageKit como las «actualizaciones sin conexión», la página con los detalles de cada paquete que se va a actualizar ahora también indica las versiones actuales de los paquetes, no solo las nuevas. (Taras Oleksyn, KDE Bugzilla #500663)

Qt 6.13.0

Qt ahora renderiza las fuentes con hinting al usar un factor de escala superior al 100%. (Infinality, Qt Bug #128874)

Cómo puedes ayudar

KDE se ha vuelto importante en el mundo, y tu tiempo y contribuciones han ayudado a llegar hasta aquí. A medida que crecemos, necesitamos tu apoyo para mantener KDE sostenible.

¿Te gustaría ayudar a preparar este informe semanal? Preséntate en la sala de Matrix y únete al equipo.

Más allá de eso, puedes ayudar a KDE involucrándote directamente en cualquier otro proyecto. Donar tiempo es realmente más impactante que donar dinero. Cada colaborador marca una gran diferencia en KDE — ¡no eres un número ni un engranaje en una máquina! No tienes que ser programador, existen muchas otras oportunidades.

También puedes ayudar haciendo una donación. Esto ayuda a cubrir costes operativos, salarios, gastos de viaje para colaboradores y, en general, a mantener KDE llevando Software Libre al mundo.

• 
  Nuevo widget meteorológico y teclado en pantalla – Esta semana en Plasmaoctubre 19, 2026
  Bienvenidos a «Nuevo widget meteorológico y teclado en pantalla» de «Esta semana en Plasma», donde empezamos a vislumbrar las novedades que obtendremos en la siguiente iteración del entorno de trabajo de la Comunidad KDE: plasma 6.9.
• 
  Los últimos retoques de 6.8 – Esta semana en Plasmaoctubre 10, 2026
  Bienvenidos pues a «Los últimos retoques de 6.8» de «Esta semana en Plasma», donde el equipo de desarrolladores de KDE nos comenta el afine de esta versión en su recta final de testeo.
• 
  Beta 2 de 6.8; ¡sigue probándolo! – Esta semana en Plasmaoctubre 3, 2026
  Bienvenidos pues a «Beta 2 de 6.8; ¡sigue probándolo!» de «Esta semana en Plasma», donde el equipo de desarrolladores de KDE nos presentan tus pequeñas evoluciones mientras nos piden que sigamos probando el nuevo escritorio que entra en su último periodo de testeo.

La entrada Nuevo widget meteorológico y teclado en pantalla – Esta semana en Plasma se publicó primero en KDE Blog.

Seguimos con las celebraciones. Una de las aplicaciones que utilizo de forma recurrente y que creo que se promociona poco es Tellico, un organizador de colecciones de KDE que en realidad es un fabuloso editor bases de datos para usuarios que no dominan este tipo de estructuras. Es por ello que estoy interesado en su desarrollo y he ido publicando sus nuevas versiones. Hoy me complace anunciar que Tellico cumple 25 años y sus desarrolladores han realizado un artículo especial para el evento.

Tellico cumple 25 años ¡larga vida a Tellico!

KDE cumple 30 años, unas cuantas celebraciones están organizándose por este evento, se ha lanzado Plasma 6.8 y estamos a las puertas de una nueva Akademy-es que llega a su 20º edición, en esta ocasión en Madrid. No se puede decir que la Comunidad KDE no tenga un mes de octubre movido, al que se le ha unido Tellico celebrando sus 25 años.

En palabras de su desarrollador principal, Robby Stephenson:

Dependiendo exactamente de cuándo marque la fecha, Tellico cumple 25 años este mes. The ChangeLog me dice que lancé Bookcase 0.1 el 4 de noviembre de 2001. La librería era el nombre original de la aplicación. Lo renové como Tellico después de que otro desarrollador de software me contactó.

Pensé que sería divertido mirar hacia atrás en algunos de los hitos.

Y así lo ha hecho, y yo simplemente os lo traduzco y lo pongo un poco más bonito.

Como dice Robby «Ha sido un viaje divertido, con ataques y brotes de desarrollo o vida personal que conducen a una pausa. Uso Tellico para mis libros, videos, álbumes de música antiguas y colección de monedas, personalmente. ¡Veremos cuánto tiempo continúa!»

¡Esperemos que muchos años!

Más información: Tellico

¿Qué es tellico?

Cuando me inicié en el mundo de KDE, uno de los programas que más me llamaron la atención fue Tellico, un excelente gestor de colecciones que te permite personalizar los campos de una forma sencilla, práctica y rápida. Empecé a utilizarlo para organizar mi colección de libros, de cómics, de películas en DVD, etc.

Lamentablemente, mi vida se fue complicando y mi tiempo para organizar cosas desapareciendo, así que perdí de vista al magnífico programa de Robby Stephenson y dejé de utilizarlos. Hace un par de años lo volví a utilizar para llevar el control de miembros de KDE España y de mis alumnos de TFG, con excelentes resultados.

En resumidas cuentas, Tellico es el organizador definitivo de cualquier tipo de colecciones. La aplicación incorpora de serie algunos tipos de colecciones como libros, películas  cómics  juegos, sellos, vinos, etc., eso si, estas colecciones son editables, es decir, tienes la posibilidad de cambiar, borrar o añadir campos.

Más información: Tellico

• 
  Tellico cumple 25 años ¡larga vida a Tellico!
  Hoy me complace anunciar que Tellico cumple 25 años y sus desarrolladores han realizado un artículo especial para el evento.
• 
  Visor meteorológico avanzado con Advanced Weather Widget – Plasmoides para Plasma 6 (41)
  Os presento un visor meteorológico avanzado llamado Advanced Weather Widget con el que llegamos al widget número 41 de la serie.
• 
  Llega KStars 3.8.5 con mejoras en el guiador por IA
  Me complace anunciar que llega KStars 3.8.5 con una renovación profunda del guiado por IA, nuevas herramientas MCP para automatizar el planificador y la captura, etc.

La entrada Tellico cumple 25 años ¡larga vida a Tellico! se publicó primero en KDE Blog.

Mike Chilson demonstrated DevsFTP and discussed backup solutions in the recent tech session. Participants shared experiences about their Linux systems, emphasizing varied engagement levels. Future sessions will cover different application topics. Community suggestions are encouraged via email or dedicated platforms. Resources and project links provided support ongoing learning and collaboration.

Eres un Knowledge Worker o trabajas en tecnología y tienes dudas sobre el futuro con todo esto de las LLM, agentes y demas?… aca dejo unos pensamientos que tengo desde hace rato, pero hoy como que les pude dar forma gracias a una pequeña encuesta en un grupo de Programadores de Venezuela en Telegram.

Pero antes de continuar, Don’t Panic!

La encuesta en cuestión tiene las siguientes opciones:

El futuro sigue estando en los humanos?

• 🔘 El futuro es humano, la IA llegará a un techo que nos dará años donde todo seguirá igual
• 🔘 Las áreas del conocimiento solo serán de top 10% humanos más inteligentes y la IA
• 🔘 Los humanos no tendrán oportunidad, vamos a una época donde las armas y la juventud son el valor
• 🔘 El futuro solo estará en los bienes y valores finitos, también el como validamos esos valores

Y llevo bastante tiempo regresando aveces a la misma analogía que escuche en un podcast de Thoughtworks¹ y quise expandir un poco mas (y se termino convirtiendo en algo bastante largo… because, well… brain):

Porque en 1970, los contadores dedicaban la mayor parte de su tiempo a recalcular manualmente hojas de cálculo en papel. Luego llegó la hoja de cálculo electrónica. Y supuso un cambio radical para ellos. Y no los convirtió en mejores contadores. Simplemente eliminó gran parte del trabajo tedioso.

Y aquí es donde yo pienso que de la misma forma que usamos un compilador, un analizador de código estático, linter, hojas de calculo, traductores (google translate), motores de búsqueda e incluso ML y otras cosas del conglomerado de AI, utilizar GPTs y otros tipos de modelos para el trabajo del día a día… 

Aquí la comparación que yo hago es a la introducción del brazo robótico en fabricas o la invención de la central telefónica automatizada… 

Los contadores siguen usando hojas de calculo y calculadora, solo que ahora todos sabemos usar una hoja de calculo en mayor o menor medida… 

En las fabricas y almacenes siguen teniendo humanos en diferentes partes de sus procesos y la automatización ayuda a ensamblado de partes, soldar componentes, etc… y hoy por hoy tenemos en muchos lugares escaleras mecánicas, puertas automáticas con sensores y hasta juguetes para lanzar un NERF al que rompió producción (si trabajas en oficina claro) o incluso cosas como impresoras 3d o CNC de sobremesa, o servicios como JLCPCB

El oficio de telefonista cambio, y ahora hay recepcionistas, operadores de servicio de atención al cliente (call centers), etc… y ahora aveces hasta hay un chatbot o operador automata antes de que puedas hablar con un humano

Todas estas eran trabajo manual que se hacia que requería una parte física para poder realizarse o era knowledge work que no se podia automatizar porque la tecnología no existía…  

Y ahora es que la automatización esta tocando al area de desarrollo de software de una forma muy dramática y a velocidad vertiginosa… 

Entonces de la misma forma que ahora tu como ingeniero de software puedes tener tu propia hoja de calculo para llevar tus impuestos y finanzas personales (i.e yo), o una impresora 3d para prototipar esas partes que necesitas para algo que se rompió o ajustar algo (i.e mejorar el flujo de aire en tu computador)… pues ahora $fulanito podría sentarse por su cuenta o con alguien mas a resolver el problema que tiene…

O como mucho ya pasa: Alguien usa un LLM para generar thumbnails de videos o imágenes desde su teléfono, en lugar de contratar a un diseñador grafico o Alguien decide que puede hacer que su idea se haga realidad y se vibecodea algo desde cero… 

Al final, citando a phenobarbital (en el 2023!):

entonces, hay un bojote de Juniors copy&paste que solo aprendieron haciendo cursos de $plataforma sin mucho ánimo de gastar 3 neuronas en análisis la informática y la creación de sistemas tiene mucho de arte y análisis y menos de monkey-coders y tira-flechas

Y nuevamente en el 2026:

foursixnine: Si no pueden sentarse en una entrevista tecnica, sin usar AI… nunca fueron seniors para empezar?…  No digo que deban saber echar codigo en $lenguaje de memoria, pero los basics deberian estar alli.

phenobarbital: _en efecto, vamos a ponernos filosóficos:

hay una escena en “Los pilares de la tierra” de Follet, dónde el arzobispo de Kingsbridge le dice a Tom Builder (el hombre que está construyendo la catedral), vieron como un obrero estaba haciendo mala mezcla pero él (tom) estaba muy ocupado poniendo bloques_

phenobarbital: que muy chévere que te guste echar ladrillo y bloques, pero ahora eres maestro constructor, o supervisas a tus empleados o tiras bloques

phenobarbital: no puedes dirigir y batir cemento

phenobarbital: y llega un punto en tu vida en que decides, batir cemento o dirigir obrero…

phenobarbital: si “usar la IA” para algunos es “pedirle que tire bloques sin saber cómo se hace el tramado o con qué densidad se bate la mezcla”

phenobarbital: no eres un senior, eres un monkey coder que reemplazó las manos para lanzar código por otro artilugio que también lanza código y que igual, tampoco entiendes

En fin, don’t panic!.

Como lectura recomendada: La pagina de Automatizacion de wikipedia y la de Inteligencia artificial (en ingles)