El proyecto Tor ha publicado la versión 13 de su navegador basado en Firefox pero con modificaciones para poder navegar por la red Tor y usarlo manteniendo la privacidad

El navegador Tor 13.0 ya está disponible en la página de descarga del Navegador Tor y en su directorio para los diferentes sistemas operativos y arquitecturas.

Esta es la primera versión estable basada en Firefox ESR 115, que incorpora los cambios de un año que se han incorporado previamente. Como parte de este proceso, también han complettado su auditoría anual de transición ESR, donde revisan el registro de cambios de Firefox para detectar problemas que puedan afectar negativamente la privacidad y seguridad de los usuarios del navegador Tor y deshabilitan cualquier parche problemático cuando sea necesario.

Los informes finales de esta auditoría ahora están disponibles en el repositorio tor-browser-spec en su instancia de Gitlab.

Son particularmente notables las mejoras de accesibilidad que han realizado como resultado de la transición a Firefox ESR 115.

Si bien los usuarios más audaces pueden notar pequeños cambios visuales en la interfaz de usuario (por ejemplo, los enlaces internos ahora están subrayados), Tor Browser 13.0 es la primera versión que hereda el motor de accesibilidad rediseñado introducido por Mozilla en Firefox 113.

Este cambio promete mejorar significativamente el rendimiento para las personas que utilizan lectores de pantalla y otras tecnologías de asistencia.

También hay un rediseño de los iconos, aunque manteniendo el aspecto actual del icono, que fue escogido en una consulta popular hace 4 años entre toda la comunidad.

También se ha rediseñado la página de inicio que se abre al iniciar el navegador Tor: Nuevos iconos, diseño simplificado y la posibilidad de utilizar el buscador DuckDuckGo desde su página .onion.

Los usuarios actuales del navegador Tor pueden alegrarse de que la “pantalla roja de la muerte», un infame estado de error en el que ocasionalmente aparecía la página de inicio anterior, ya no existe.

Como parte de la reescritura del back-end, han eliminado la verificación automática de conectividad de la red Tor que era un vestigio del iniciador de Tor heredado, donde el arranque era manejado por una extensión que se ejecutaba antes de que apareciera la interfaz del navegador y que provocaba falsos positivos.

El navegador Tor ahora se muestra en ventanas más grandes. Aunque el navegador Tor esté maximizado en nuestra pantalla, siempre se ejecutará dentro de una ventana más pequeña, que ahora tienen un tamaño mayor.

Se ejecutan dentro de esas ventanas más pequeñas, para eludir y anonimizar el uso de Tor, ya que hay muchos sitios web que rastrean a las personas que los visitan por el dato del tamaño de nuestro monitor que filtra un navegador normal, por eso el navegador Tor ofusca ese dato ejecuntándose en ventanas menores.

Las nuevas ventanas deberían ser más grandes de forma predeterminada y presentarse en una relación de aspecto horizontal más útil para la mayoría de los usuarios de escritorio en Tor Browser 13.0.

Ya puedes actualizar tu navegador Tor para disfrutar de las nuevas ventajas de esta versión 13. Y no dudes en tenerlo siempre a mano para navegar o para visitar sitios sospechosos o peligrosos de spam, rastreo, etc.

Enlaces de interés

• https://blog.torproject.org/new-release-tor-browser-130/
• https://www.torproject.org/download/

Sigo con estas pequeñas aplicaciones que se conocen como applets, widgets o plasmoides y que dotan de funcionalidades de todo tipo a nuestro entorno de trabajo KDE. Hoy toca otro que controla tu reproductor multimedia en tu escritorio llamado Minual Musica Widget, que será el plasmoide número 229 de la serie.

Controla tu reproductor multimedia con Minimal Musica Widget – Plasmoides de KDE (229)

Como he comentado en otras ocasiones, 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 llamado Minual Musica Widget, una creación de Zayronxyo con el que controlas el reproductor multimedia directamente desde tu escritorio con el contenido mínimo que te pueda interesar: canción, autor de la canción y los mínimos controles multimedia.

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 Controla tu reproductor multimedia con Minimal Musica Widget – Plasmoides de KDE (229) se publicó primero en KDE Blog.

Cycling provides interesting examples for software development. It’s possible to race individually or in teams. A group that’s an effective team will outperform the same group acting as individuals every time. Teams compete towards a goal, and also against the environment, and many other teams, all with their own tactics, all at the same time. 

Ensemble working provides an Advantage

Cycling teams working together in a paceline can travel significantly faster—via the aerodynamic advantage of drafting the slipstream of the rotating leading rider. 

Software teams can build more stuff if each person works independently, than when working together. However, they’ll reach a team goal the fastest through working together, on the same stuff, at the same time, via pair or ensemble programming. 

Having all the perspectives, experience, and expertise available at the point of meeting resistance from unknown challenges, results in a sort of aerodynamic advantage. We get stuck for less long, and overcome obstacles more easily. 

A pair may not be twice as fast at shipping stuff as two people, but shipping stuff is not important. Working together they’ll achieve a goal a bit faster. Our goals have a cost of delay. The ability to ship a capability with associated revenue significantly faster, more than makes collaborative working worthwhile. 

Individual working provides an Advantage

Cycling teams are comprised of multiple people, they can send riders back for hydration & energy food. They can send riders ahead to mark breakaways and mitigate the risk of the breakaway succeeding at remaining ahead until the end of the race. 

Software teams that are paying attention, will see side opportunities & risks that are tangential to the main focus but too big to ignore. Often it helps for one or two people to go after them. Builds getting slow; someone peels off from the group to go fix that. Competitor launched a new product; someone peels off to explore how it works and whether should this change our plans.

Competitive Market

Unlike many pitch team sports where teams compete head to head, cycling teams compete against several other teams, at the same time. Each competitive team will employ their own tactics. Some teams may be more interested in overall win, or other incentives available such as intermediate sprints. Tactics have to take into account all the competition, not just a single opposing team. There are also environmental factors on the day such as wind and rain conditions, and the terrain. 

Organisations building software are competing against many other organisations with directly or indirectly competing interests. 

Sometimes it is advantageous to collaborate with the competition to conserve resources by working together. Cycling teams can work together to increase the chance of leading the race through a breakaway. Software builders partnering with competitors can build an ecosystem to grow the opportunity available to all parties.

Other times there’s an opportunity to get ahead of the competition by creating a break that your team is uniquely positioned to take advantage of.

Adapt to the riding conditions. Lightweight for climbing or Aero for flat. Wet or Dry. Similarly, as the economic climate changes, so do the tactics that are most successful for building software. 

Dynamic Reteaming to Breakaway

Working together, a breakaway made up of individuals from multiple teams can stay ahead of the race. They must take their own share of the hard work in the wind, and communicate effectively. If they refuse to help each other, the breakaway will fail, and will be absorbed. Breakaways often fail when competing incentives and ineffective communication reduce their advantage over the main peloton. 

There’s often a need and benefit to pulling together or self organising temporary short lived software teams. They can effectively chase an immediate goal that doesn’t neatly map to the existing team structure. 

Dynamic reteaming can be far more effective than dependencies between teams, and like a breakaway it can rapidly get ahead of what an unchanged organisation structure could achieve. 

Temporary teams also often struggle to communicate as effectively as a well established team; lacking the trust that comes from experience working with each other.

Marginal Gains Add Up

A clean well-lubricated chain could save you 5 watts, adding up to several seconds advantage over a race. Small tweaks to fitness training habits every day can add up to an advantage over a season. 

Software teams often underestimate how quickly small investments in their own effectiveness cumulatively create an advantage. Time spent making your deploy pipeline a couple of minutes faster, or time automating manual onboarding steps. The wins from these add up over time to help you outpace the rest.

Specialists 

You need specialists: climbers & sprinters. The rest of the team help get them in position at the right time for the challenges that they can best help with. Get your sprinters to the front of the race with a leadout in time for the sprints. Do the hard work to protect your race-winner’s ability to take advantage of a tactical opportunity when it comes. However, everyone needs to finish the race. Sprinters must be able to get over the mountains within the time limit.

Effective software teams have a mix of generalising specialists. They can all muck-in with whatever needs to be done towards the team goal. There’s also huge value to having the person with expertise in building UIs, the person with Data Science expertise, or the person who’s scaled databases. The right specialists enable help the team to overcome challenges.

Support Staff

Teams need support staff. If riders had to stop and repair their own mechanical issues, or carry their own food they’d be far slower. 

Engineering teams benefit from internal platforms, and developer experience tooling support functions. Invest a portion of your budget in these.

Beware Incentives

Unglamourous work is essential to team success. Teams are ruined if everyone tries to go for the win. 

Cycling teams need domestiques who will protect the leaders and fetch food. Software teams need people who’ll do glue work. People who help the whole team communicate. People who remove the friction slowing the team down. 

Organisational incentives often risk this essential work and destroy the potential of teams. 

Incentivise each of your riders to go for the win and the team will fail.

Incentivise each of your developers to chase promotions and compensation increases, on the basis of their individual impact, and your team will be ineffective. 

Incentivise each of your developers to chase promotions and compensation increases, on the basis of their individual impact, and your team will be ineffective. 

Work Sustainably

Pace yourselves. Only go all out when there’s a need for it, or you’ll not have the energy when it is needed. There’s a sprint at the end of the race. There’s another stage tomorrow. Don’t drop out. 

If you are successful, there will be production incidents and customer crises to handle. These will take your energy reserves.

If you run at 100% every day you’ll have nothing left to give when there’s a real need. 

Supporting Sustainability

The post Engineering Team Lessons from Cycling appeared first on Benji's Blog.

I was startled from my reverie by a shout, as this gentleman attempted to clear dawdling tourists such as myself out of his way. 

I watched with bemusement but resisted the urge to offer to help—knowing the eye-watering value of Murano glass therein.

He eased the precious cargo over one step at a time. The cart—heavily laden with boxes of fragile glass secured with a flimsy strap—wobbled precariously over every step.

The sun baked the scene in an intense 40 degree furnace, like the one whence the glass came. Bump. Wobble. Heavy breathing. Bump, wobble. 

Deliveries here are hard and risky work. Irreplaceable unique craft pieces, one mistake and they’re lost forever. 

Too many teams suffer through building software like this: crafting a big batch of artisanal changes. Loading up a big batch to deliver to customers. 

many teams suffer through building software like this. 

We suffer through risky deployments, fearful that any mis-step may lead to disaster. 

We optimise our delivery, each engineer efficiently delivering as much as possible; piling our carts high. 

We plan our routes using detailed road maps and follow them religiously, fearful of the consequences of deviating from the route we filed.

Sadly, delivery is an accurate metaphor for many teams’ approach to building software. Software development doesn’t have to be like this. Delivery is a poor metaphor for effective software engineering.

Software is not delivered like packages of pre-made goods. Software is crafted, nurtured, and discovered. Software is grown like a garden. Software is supplied like water or energy. Software is improved through experimentation like knowledge.

Delivery logistics can be optimised for efficiency & throughput. Software needs learning and discovery. Efficient delivery prevents outsized outcomes—efforts to eliminate wasteful deviations from plans limit teams. At very best they’ll achieve only the outcomes they were able to foresee in advance. 

Efficient delivery prevents outsized outcomes.
At very best they’ll achieve only the outcomes they were able to foresee in advance. 

Deliveries can follow planned routes along road maps. Software development is more like exploring an area with a sat-nav. You have a destination in mind but can adapt your route given unforeseen traffic conditions. You can choose to explore things that pique your interest along the way without losing sight of the goal.

Delivery is risky; if you destroy or lose a package it’s gone forever, you can never get it back. Software change can be made low risk and boring if we’re willing to invest in the technical practices, architecture, and tooling to make it so.

Delivery is done when the package reaches its destination. A software change reaching customers is only the beginning of the learning loop. What was the effect of the change? Did it do what we expected? Is there anything that surprises us in the impact on the rest of our production systems? Is it being used in the way we expected? What have we learned about the needs of our users to inform what we do next? Is it valuable or should we undo the change? What was hard about the change and how do we make it easier to do the next? 

Beware the influence of the metaphors we use upon the ways we think and work. The language we use affects how we act. We can do better than delivery.

The post One does not simply deliver software appeared first on Benji's Blog.

One of the joys of rolling distributions is that every once in a while, you get a weird issue that pops up. I recognize that this is a possibility and a rare one that the fantastic openSUSE community does end up fixing. I figure, if I have to find the solution, than I may as […]

Debo reconocer una cosa: no se me queda en la memoria el nombre del canal propio de vídeos de la Comunidad KDE. Lo cierto es que Kockatoo tube, nombre elegido para su canal de Peertube de KDE no es el más simple del mundo pero eso no significa que no debamos hacer un esfuerzo por familiarizarnos con él. Por mi parte he pensado que la forma de hacerlo será escribir mucho sobre él al tiempo que promociono algo más la pasada edición de Akademy-es de Málaga. De esta forma bienvenidos a la charla grabada de «Commons el almacén multimedia de Wikimedia y otros proyectos relacionados» por  Pedro Pacheco de Wikimedia almacenada en Kockatoo tube y en la que nos contó un poco sobre este proyecto tan importante para el mundo del Conocimiento Libre..

Commons el almacén multimedia de Wikimedia y otros proyectos relacionados en Kockatoo tube #akademyes 2023

Antes de empezar alguien se puede preguntar porqué no utilizar solo Youtube para compartir contenido multimedia. La respuesta es muy simple: para evitar que esta plataforma que pertecene a a Google tenga el control de todo contenido multimedia de la Comunidad KDE.

Para evitarlos se ha creado Kocaktoo tube, simplemente una alternativa libre de youtube, donde se cuelgan por defecto los vídeos de KDE pero no de forma exclusiva ya que si se puede se suben también a la plataforma con más usuarios (hay que pescar donde hay peces).

Como la gente asidua al blog sabrá, el pasado 9 y 10 de junio de 2023 la asociación KDE España celebró en Málaga su Akademy-es 2023 integrada en el evento marco Opensouthcode. Fruto de ella se realizaron una serie de charlas, las cuales fueron grabadas en su gran mayoría y subidas al Kocaktoo tube de KDE España. Aunque ya las he presentado en el blog creo que es positivo compartis con vosotros todas las que pueda.

De esta forma empiezo esta serie con la charla de unos de las clásicas dentre de los eventos KDE:  Pedro Pacheco de Wikimedia nos hablad e «Commons, el almacén multimedia de Wikimedia y otros proyectos». Espero que la disfrutéis.

Más información: Kockatoo Tube de KDE España

Canal de Peertube de KDE: Kockatoo Tube

Para los que no conozcan este servicio, os presento (y me sirve a mi para seguir conociéndolo más a fondo) PeerTube, desarrollado por Framasoft, es la alternativa gratuita y descentralizada a las plataformas de video, que le brinda más de 400000 vídeos publicados por 60000 usuarios y vistos más de 15 millones de veces.

Hace poco, la asociación GNU/Linux València anunció que empezaba a utilizar este servicio, poco tiempo después, anuncié que KDE España también empezaba a utilizar este servicio. Lo que no dije es que esta instancia de Peertube en realidad estaba siendo alojada en una mayor de la Comunidad KDE: Kockatoo.

De esta forma, en este instancia de KDE podemos encontrar todo tipo de vídeos, desde los de KDE España que ya he comentado hasta los vídeos de Niccolò Ve pasando por anuncios de lanzamiento como el último de Plasma 5.23, edición 25 aniversario.

La entrada Commons el almacén multimedia de Wikimedia y otros proyectos relacionados en Kockatoo tube #akademyes 2023 se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux “Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2023/10/opensuse-tumbleweed-review-of-the-week-2023-41/

Esta semana se han publicado cuatro instantáneas; La número 5 está en proceso de sincronización con la infraestructura de descarga, pero parece que está tardando un poco más de lo que tardaría.

Estas cuatro snapshots (1006, 1008, 1010, y 1011) han traido los siguientes cambios:

• NetworkManager 1.44.2
• Shadow 4.14.1
• Linux kernel 6.5.6
• Qt 5.15.11
• LibreOffice 7.6.2.1
• LLVM 17.0.2
• Node.JS 20.8.0
• gpg 2.4.3
• libcue 2.3.0 (CVE-2023-43641)

LA snapshot 1012 contendrá solución a una vulnerabilidad ( CVE-2023-3854) en cURL 8.4.0.

Y para próximas snapshots habrá actualizaciones por ejemplo en:

• KDE Gear 23.08.2
• zypper 1.14.66
• Freetype 2.13.2
• binutils 2.41

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

This week, we have published four snapshots; number 5 is in the process of syncing to the download infrastructure, but it seems to be taking slightly longer than it would.

The four snapshots (1006, 1008, 1010, and 1011) brought you those changes:

• NetworkManager 1.44.2
• Shadow 4.14.1
• Linux kernel 6.5.6
• Qt 5.15.11
• LibreOffice 7.6.2.1
• LLVM 17.0.2
• Node.JS 20.8.0
• gpg 2.4.3
• libcue 2.3.0 (CVE-2023-43641)

Snapshot 1012 is currently syncing out and will contain cURL 8.4.0, which is fixing CVE-2023-3854

Other than that, you can expect these changes in the next few snapshots (depending on QA results of course):

• KDE Gear 23.08.2
• zypper 1.14.66
• Freetype 2.13.2
• binutils 2.41: all flavors of rust fail to build
• moving to dbus-broker

Upcoming Quarterly Update 1 for SLES 15 SP5 contains Bug 1215802.

This update will make its way also to Leap 15.5 users, since SLES and Leap starting by 15 SP3/15.3 share the same kernel.

Bug 1215802 says openSUSE Leap 15.5 systems with AMDGPU driver and Radeon RX 7000 series could experience a boot freeze with kernel-default 5.14.21-150500.55.28.1. Based on the discussion it seems like issue does not happen if the latest avaiable kernel-firmware-amdgpu is installed. Comment says as long as user applies all updates, this problem should not happen.

In case you’ve already installed update and your system fails to boot, you can boot your system by a passing nomodeset option to the kernel in grub and ensure you have latest kernel-firmware-amdgpu. Alternatively, you might want to consider using snapper to rollback the update.

We highly recommend Leap 15.5 users to postpone further kernel update until the situation in Bug 1215802 is further clarified and potential fix (if needed) is released. The best case scenario is that no action is needed, and everything works as long as the user installs all available updates.

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar la segunda actualización de KDE Gear 23.08 que apareció hace unos dos meses. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.

Segunda actualización de KDE Gear 23.08

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE Gear 23.08 que nos ofrece más de 120 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Aquí podéis encontrar la lista completa de cambios de KDE Gear 23.08.2, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:

• Kdeconnect: ahora evita añadir dispositivos duplicados al panel lateral de Dolphin.
• Merkuro: corregido el desplazamiento de la fecha en un día/mes.
• Kdenlive: arreglado múltiples flujos de audio rotos por la nueva propiedad astream de MLT.

Más información: KDE Gear 23.08.2

La entrada Segunda actualización de KDE Gear 23.08 se publicó primero en KDE Blog.