In the day job we use Microsoft Teams. The good news is that it is running on the Linux Desktop, and specifically KDE. So far, so good, however, there was a problem with screensharing for me.

Whenever I tried to share my KDE screen, the screen became black, surrounded with a red rectangle as indicator for the shared area. The people who I shared with also just saw the black area, and also the mouse pointer as me.

The problem is described in a bugreport and there are two ways of solving it:

1. Enable compositing: The red indicator rectangle requires that the window manager supports compositing. KWin can of course do that, and with that enabled, sharing works fine including the red rectangle.
2. If compositing can or should not be used there is another workaround: As the bug report shows, renaming the file /usr/share/teams/resources/app.asar.unpacked/node_modules/slimcore/bin/rect-overlay so that it is not used by teams fixes it as well. Obviously you wont have the red rectangle with this solution.

That said, it is of course preferable to use an open source alternative to Teams to help these evolve.

I have been running some workloads on Raspberry Pi’s / Leap for some time. I manage them using salt-ssh along with a Pine64 running OpenBSD. You can read more about using Salt this way in my Using Salt like Ansible post.

The workloads ran on containers, which were managed with systemd and podman. Salt managed the systemd service files on /etc/systemd, which start, monitor and stops the containers. For example, the homeassistant.sls state, managed the service file for mosquitto:

homeassistant.mosquito.deploy:
  file.managed:
    - name: /root/config/eclipse-mosquitto/mosquitto.conf
    - source: salt://homeassistant/files/mosquitto/mosquitto.conf

homeassistant.eclipse-mosquitto.container.service:
  file.managed:
    - name: /etc/systemd/system/eclipse-mosquitto.service
    - contents: |
	[Unit]
	Description=%N Podman Container
	After=network.target

	[Service]
	Type=simple
	TimeoutStartSec=5m
	ExecStartPre=-/usr/bin/podman rm -f "%N"
	ExecStart=/usr/bin/podman run -ti --rm --name="%N" -p 1883:1883 -p 9001:9001 -v /root/config/eclipse-mosquitto:/mosquitto/config -v /etc/localtime:/etc/localtime:ro --net=host docker.io/library/eclipse-mosquitto
	ExecReload=-/usr/bin/podman stop "%N"
	ExecReload=-/usr/bin/podman rm "%N"
	ExecStop=-/usr/bin/podman stop "%N"
	Restart=on-failure
	RestartSec=30

	[Install]
	WantedBy=multi-user.target
  service.running:
    - name: eclipse-mosquitto
    - enable: True
    - require:
      - pkg: homeassistant.podman.pkgs
      - file: /etc/systemd/system/eclipse-mosquitto.service
      - file: /root/config/eclipse-mosquitto/mosquitto.conf
    - watch:
      - file: /root/config/eclipse-mosquitto/mosquitto.conf

The Salt state also made sure the right packages and other details where ready before the service was started.

This was very simple and worked well so far. One disadvantage is that the workloads are tied to a particular Pi. I was not going to make the setup more complex by building my own orchestrator.

Another disadvantage is that I was pulling the containers into the SD card. I was not hoping for a long life of these. After it died, I took it as a good opportunity to re-do this setup.

My long term goal would be to netboot the Pi’s, and have the storage mounted. I am not very familiar with all the procedure, so I will go step by step.

I decided for the the initial iteration:

• k3s (Lightweight Kubernetes) on the Pi’s
• The k3s server to use a USB disks/SSDs with btrfs as storage
• The worker nodes to /var/lib/rancher/k3s from USB storage
• Applying the states over almost stock Leap 15.2 images should result in a working cluster

All the above managed with salt-ssh tree on a git repository just like I was used to

k3s:
  token: xxxxxxxxx
  server: rpi03

k3s.boot.cmdline:
  file.managed:
    - name: /boot/cmdline.txt
    - contents: |
	cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory

k3s.disable.swap:
  cmd.run:
    - name: swapoff -a
    - onlyif:  swapon --noheadings --show=name,type | grep .

k3s.volume.mount:
  mount.mounted:
    - name: /var/lib/rancher/k3s
    - device: /dev/sda1
    - mkmnt: True
    - fstype: btrfs
    - persist: False
    - opts: "subvol=/@k3s"

k3s.volume.mount:
  cmd.run:
    - name: mount -t btrfs -o subvol=/@{{ grains['id'] }}-data /dev/sda1 /data
    - unless: findmnt --mountpoint /data --noheadings | grep '/dev/sda1[/@k3s]'
    - require:
	- file: k3s.volume.mntpoint

k3s.volume.mount:
  file.managed:
    - name: /etc/systemd/system/var-lib-rancher-k3s.mount
    - contents : |
	[Unit]

	[Install]
	RequiredBy=k3s
	RequiredBy=k3s-agent

	[Mount]
	What=/dev/sda1
	Where=/var/lib/rancher/k3s
	Options=subvol=/@k3s
	Type=btrfs
  cmd.run:
    - name: systemctl daemon-reload
    - onchanges:
	- file: k3s.volume.mount
  service.running:
    - name: var-lib-rancher-k3s.mount

{%- set k3s_server = salt['pillar.get']('k3s:server') -%}
{%- if grains['id'] == k3s_server %}
{%- set k3s_role = 'server' -%}
{%- set k3s_suffix = "" -%}
{%- else %}
{%- set k3s_role = 'agent' -%}
{%- set k3s_suffix = '-agent' -%}
{%- endif %}

k3s.{{ k3s_role }}.install:
  cmd.run:
    - name: curl -sfL https://get.k3s.io | sh -s -
    - env:
	- INSTALL_K3S_TYPE: {{ k3s_role }}
{%- if k3s_role == 'agent' %}
	- K3S_URL: "https://{{ k3s_server }}:6443"
{%- endif %}
	- INSTALL_K3S_SKIP_ENABLE: "true"
	- INSTALL_K3S_SKIP_START: "true"
	- K3S_TOKEN: {{ salt['pillar.get']('k3s:token', {}) }}
    - unless:
	# Run install on these failed conditions
	# No binary
	- ls /usr/local/bin/k3s
	# Token changed/missing
	- grep '{{ salt['pillar.get']('k3s:token', {}) }}' /etc/systemd/system/k3s{{ k3s_suffix }}.service.env
	# Changed/missing server
{%- if k3s_role == 'agent' %}
	- grep 'K3S_URL=https://{{ k3s_server }}:6443' /etc/systemd/system/k3s{{ k3s_suffix }}.service.env
{%- endif %}
    - require:
	- service: k3s.volume.mount
	- service: k3s.kubelet.volume.mount

k3s.{{ k3s_role }}.running:
  service.running:
    - name: k3s{{ k3s_suffix }}
    - enable: True
    - require:
      - cmd: k3s.{{ k3s_role }}.install

homeassistant.mosquitto:
  file.managed:
    - name: /var/lib/rancher/k3s/server/manifests/mosquitto.yml
    - source: salt://homeassistant/files/mosquitto.yml
    - require:
      - k3s.volume.mount

---
apiVersion: v1
kind: Namespace
metadata:
  name: homeassistant
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mosquitto
  namespace: homeassistant
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mosquitto
  template:
    metadata:
      labels:
	app: mosquitto
    spec:
      containers:
	- name: mosquitto
	  image: docker.io/library/eclipse-mosquitto
	  resources:
	    requests:
	      memory: "64Mi"
	      cpu: "100m"
	    limits:
	      memory: "128Mi"
	      cpu: "500m"
	  ports:
	  - containerPort: 1883
	  imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: mosquitto
  namespace: homeassistant
spec:
  ports:
  - name: mqtt
    port: 1883
    targetPort: 1883
    protocol: TCP
  selector:
    app: mosquitto

---
apiVersion: v1
kind: Namespace
metadata:
  name: homeassistant
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: homeassistant-config
  namespace: homeassistant
data:
  configuration.yaml: |
    homeassistant:
      auth_providers:
	- type: homeassistant
	- type: trusted_networks
	  trusted_networks:
	    - 192.168.178.0/24
	    - 10.0.0.0/8
	    - fd00::/8
	  allow_bypass_login: true
      name: Home
      latitude: xx.xxxx
      longitude: xx.xxxx
      elevation: xxx
      unit_system: metric
      time_zone: Europe/Berlin
    frontend:
    config:
    http:
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: homeassistant
  namespace: homeassistant
spec:
  replicas: 1
  selector:
    matchLabels:
      app: homeassistant
  template:
    metadata:
      labels:
	app: homeassistant
    spec:
      containers:
	- name: homeassistant
	  image: homeassistant/raspberrypi3-64-homeassistant:stable
	  volumeMounts:
	    - name: config-volume-configuration
	      mountPath: /config/configuration.yaml
	      subPath: configuration.yaml
	  livenessProbe:
	    httpGet:
	      scheme: HTTP
	      path: /
	      port: 8123
	    initialDelaySeconds: 30
	    timeoutSeconds: 30
	  resources:
	    requests:
	      memory: "512Mi"
	      cpu: "100m"
	    limits:
	      memory: "1024Mi"
	      cpu: "500m"
	  ports:
	    - containerPort: 8123
	      protocol: TCP
	  imagePullPolicy: Always
      volumes:
	- name: config-volume-configuration
	  configMap:
	    name: homeassistant-config
	    items:
	    - key: configuration.yaml
	      path: configuration.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: homeassistant
  namespace: homeassistant
spec:
  selector:
    app: homeassistant
  ports:
    - port: 8123
      targetPort: 8123
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: homeassistant
  namespace: homeassistant
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.frontend.rule.type: PathPrefixStrip
spec:
  rules:
  - host: homeassistant.int.mydomain.com
    http:
      paths:
      - path: /
	backend:
	  serviceName: homeassistant
	  servicePort: 8123

There are many reasons to consider hiring inexperienced software engineers into your team, beyond the commonly discussed factors of cost and social responsibility.

Hire to maximise team effectiveness; not to maximise team size. Adding more people increases the communication and synchronisation overhead in the team. Growing a team has rapidly diminishing returns.

However, adding the right people, perspectives, skills, and knowledge into a team can transform that team’s impact. Instantly unblocking problems that would have taken days of research. Resolving debates that would have paralysed. The right balance between planning and action.

It’s easy to undervalue inexperienced software engineers as part of a healthy team mix. While teams made up of entirely senior software engineers can be highly effective. There are many benefits beyond cost and social responsibility for hiring entry level and junior software engineers onto your team.

Fresh Perspectives

Experienced engineers have learned lots of so called “best practices” or dogma. Mostly these are good habits that are safer ways of working, save time, and aid learning. On the other hand sometimes the context has changed and these practices are no longer useful, but we carry on doing them anyway out of habit. Sometimes there’s a better way, now that tech has moved on, and we haven’t even stopped to consider.

There’s a lot of value in having people on the team who’ve yet to develop the same biases. People who’ll force you to think through and articulate why you do the things you’ve come to take for granted. The reflection may help you spot a better way.

To take advantage you need sufficient psychological safety that anyone can ask a question without fear of ridicule. This also benefits everyone.

Incentive for Simplicity and Safety

A team of experienced engineers may be able to tolerate a certain amount of accidental code complexity. Their expertise may enable them to work relatively safely without good test safety nets and gaps in their monitoring. I’m sure you know better ;)

Needing to make our code simple enough to understand for a new software engineer to be able to understand and change it exerts positive pressure on our code quality.

Having to make it safe to fail. Protecting everyone on the team from being able to make a change that takes down production or corrupts data helps us all. We’re all human.

Don’t have any junior engineers? What would you do differently if you knew someone new to programming was joining your team next week? Which of those things should you be doing anyway? How many would pay back their investment even with experienced engineers? How much risk and complexity are you tolerating? What’s its cost?

Growth opportunity for others

Teaching, advising, mentoring, coaching less experienced people on the team can be a good development opportunity for others. Teaching helps deepen your own understanding of a topic. Practising your ability to lift others up will serve you well.

Level up fast

It can be humbling how swiftly new developers can get up to speed and become highly productive. Particularly in an environment that really values learning. Pair programming can be a tremendous accelerator for learning through doing. True pairing, i.e. solving problems together, rather than spoonfeeding or observing.

Tenure

Amount of software engineering experience is one indicator for the impact an individual can have. Amount of experience within your organisation is also relevant. If you only hire senior people and your org is not growing fast enough to provide them with further career development opportunities they are more likely to leave to find growth opportunities. It can be easier to find growth opportunities for people earlier in their career.

A mix of seniorities can help increase the average tenure of developers in your organisation—assuming you will indeed support them with their career development.

Action over Analysis

Junior engineers often bring a healthy bias towards getting on with doing things over excessive analysis. Senior engineers sometimes get stuck evaluating foreseen possibilities, finding “the best tool for the job”, or debating minutiae ad nauseam. Balancing the desires to do the right things right, with the desire to do something, anything quickly on a team can be transformational.

Hire Faster

There’s more inexperienced people. It’s quicker to find people if we relax our experience and skill requirements. Some underrepresented minorities may be less underrepresented at more junior levels.

The inexperienced engineer you hire today could be the senior engineer you need in years to come.

To ponder

What other reasons have I missed? In what contexts is the opposite true? When would you only hire senior engineers?

The post Reasons to hire inexperienced engineers appeared first on Benji's Blog.

I’m working on a couple of presentations and I wanted to share this nugget of joy with anyone who hasn’t actually read it.

Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.
ohio-state.edu!wupost!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Keywords: 386, preferences
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki
Lines: 20

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.  This has been brewing
since april, and is starting to get ready.  I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want.  Any suggestions
are welcome, but I won't promise I'll implement them :-)

Linus (torvalds@kruuna.helsinki.fi)

PS.  Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

Sigue adelante el evento más importante de la Comunidad KDE Internacional. Bienvenidos a la mañana del segundo día de Akademy 2020 en línea, un resumen de lo que ha dado de sí la jornada matinal del sábado la cual ha sido muy fructífera y variada. Como es habitual, me gusta partir estas entradas en mañana y tarde para no tener artículos excesivamente largos. Mañana la jornada vespertina.

Mañana del segundo día de Akademy 2020 en línea

Tras el gran vídeo de presentación que espero que hayáis visto antes de empezar a leer estas líneas (sale un servidor, miembros de KDE España y un crisol de personas de todo el mundo que dan muestra de la diversidad de la Comunidad) hoy toca comentar lo que dio de sí las charlas de ayer.

Tenéis toda la información en la sección de noticias de la Comunidad KDE (el dot) así que aquí, por no repetir, solo voy a dar pinceladas:

Aleix Pol, Presidente de KDE, comenzó el día puntualmente a las 8:50 UTC reproduciendo un video hecho por Bhavisha Dhruve y Skye Fentras dando la bienvenida a todos al evento, que es el que habéis visto arriba.

Después, Aleix explicó las circunstancias muy especiales de la Akademy de este año y presentó a la primera oradora principal Gina Häußge.

El resto de la mañana se puede dividir en dos grandes bloques: Objetivos KDE y charlas relámpago.

De esta forma tuvimos a Jonathan Riddell, Niccolo Venerandi y Méven Car hablando cada uno sobre los objetivos de la Comunidad de KDE: las Aplicaciones, la consistencia y Wayland.

Fueron tres charlas independientes que confluyeron a una mesa redonda donde Niccolo Venerandi, Méven Car, Jonathan Riddell, Lydia Pintscher y Adam SzopaCreo hablaron largo tendido sobre dichos objetivos.

Creo que no se podía empezar mejor una Akademy que dejando sobre mesa qué quiere conseguir la Comunidad y cómo lo está haciendo.

Tras este primer bloque llegaron las charlas relámpago con:

• Andreas Cord-Landweh hablando de SPDX.
• Shawn Rutledge nos presentó «Editing Markdown with QTextDocument»
• Carl Schwan expuso «How to Create a Good Promotional Website for your Project.»

Y hasta aquí la mañana. Si no hay nada que lo impida mañana comento la jornada vespertina.

Material audiovisual Akademy 2020 en línea

Una de las cosas positivas de esta Akademy es que todo el material debe ser emitido digitalmente, lo cual hace que ya puede estar listo para ser compartido en diferido, aunque sea sin editar.

De esta forma, en caso de que te lo hayas perdido, las charlas de hoy ya están disponibles en línea en tres bloques – uno para la mañana y dos para cada una de las habitaciones utilizadas por la tarde. También se ha grabado grabado todas las charlas por separado y pronto podrás verlas en las plataformas de vídeo disponibles de KDE.

• Pasang openSUSE Tumbleweed
• Tambahkan repo Pantheon

  sudo zypper https://download.opensuse.org/repositories/X11:/Pantheon:/Branch/openSUSE_Tumbleweed/ X11:Pantheon
  

• Segarkan

  sudo zypper ref
  

• Pasang pola Pantheon

  sudo zypper in -t pattern pantheon
  

• Have Fun!

Tumbleweed es una distribución “Rolling Release” 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 enlace:

• http://dominique.leuenberger.net/blog/2020/09/opensuse-tumbleweed-review-of-the-week-2020-36/

Durante esta semana, se ha publicado una “snapshot” muy grando, debido a que ha sido necesario hacer una recompilación completa de la distro debido a algunos cambios en los paquetes RPM y otros paquetes básicos. Por lo que todos los paquetes se han visto afectados.

Aunque todo parece que discurrió sin problemas, algunos usuarios han tenido problemas con el programa “man”. En total se ha publicado 5 nuevas snapshots: 0826, 0829, 0831, 0901 y 0902.

Que entre otros, se pueden destacar estos cambios como los más notables:

• Mesa 20.1.6
• Linux kernel 5.8.y & 5.8.4
• rpm: %{_libexecdir} ahora es /usr/libexec, y la carga de compresión cambió de xz a zstd. Esto da como resultado una descompresión más rápida de RPM’s en prácticamente el mismo espacio
• VirtualBox 6.1.3
• Mozilla Firefox 80.0
• Kubernetes 1.19

Y entre lo que podremos encontrar en próximas actualizaciones, podemos destacar:

• KDE Applications 20.08.1
• KDE Plasma 5.19.5
• systemd 246
• glibc 2.32
• binutils 2.35
• gettext 0.21
• bison 3.7.1
• SELinux 3.1

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?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

El evento más importante de la Comunidad KDE Internacional está en marcha. Bienvenidos al primer día de Akademy 2020 en línea, un resumen de lo que ha dado de sí la primera jornada del evento.

Primer día de Akademy 2020 en línea

Esta edición del encuentro de desarrolladores de la Comunidad KDE se está desarrollando de forma muy diferente a las anteriores por su carácter no-presencial.

Esto ha dado pie a que se hayan podido realizar otro tipo de actividades que, por lo visto en el panel de asistentes, han tenido un éxito abrumador.

De esta forma el primer día de Akademy 2020 en línea se ha organizado alrededor de talleres con las siguientes temáticas:

• Nuno Pinheiro, uno de los artífices del aspecto de KDE 4, impartió una clase de diseño de interfaz y de interfaz de usuario en QML para el escritorio. Este taller online contenía ejercicios prácticos sobre lo que se debe hacer, lo que no se debe hacer y la integración; y consejos sobre el diseño de la interfaz de usuario.
• Milian Wolff, nos enseñó sobre Depuración y Perfiles en Linux. Este taller fue a un nivel ligeramente superior y requirió algunos conocimientos y experiencia con Qt y C++, así como una comprensión básica de la programación multihilo.
• Michael Friedrich, un evangelista desarrollador de GitLab, nos aconsejó cómo acelerar sus flujos de trabajo de desarrollo con GitLab en su taller de buenas prácticas. Michael nos llevó a través de nuestros primeros pasos en GitLab con la gestión de proyectos (temas, tableros, etiquetas, plantillas, etc.) y lo combinó con los flujos de trabajo de desarrollo.

• Albert Astals Cid dirigió una sesión llamada Introducción al QML y nos enseñó cómo componer interfaces de usuario fluidas usando el lenguaje QML y también aprendimos a enganchar la parte QML a la lógica de C++.
• David Faure nos habló de Multithreading in Qt, que es esencial para los desarrolladores que quieren crear aplicaciones rápidas y con capacidad de respuesta en computadoras, teléfonos y dispositivos incorporados con un número cada vez mayor de núcleos.
• La Dra. Carlee Hawkins habló sobre el sesgo implícito en la sala 3. En esta sesión, se nos pidió que consideráramos nuestros propios sesgos en cuanto a raza, género, edad, etc. Exploramos cómo los investigadores entienden los sesgos y aprendimos a mitigar la influencia de nuestros propios sesgos en nuestros pensamientos.

Más información: KDE

Dear Tumbleweed users and hackers,

During the last week, we have shipped a massive snapshot, due to a full rebuild (RPM libexecdir change, rpm payload compression change, and symlink changes to /etc/alternatives). The libexecdir was not exactly as smooth as we wish it to be, on the other hand, it was also not disastrous. The biggest issue seen by users was likely the no-longer working ‘man’ program. This was a trap by update-alternatives, that does not like changing target paths, paired with a packaging bug. In total, we have shipped 5 snapshots (0826, 0829, 0831, 0901 and 0902).

The most noteworthy changes were:

• Mesa 20.1.6
• Linux kernel 5.8.2 & 5.8.4
• rpm: %{_libexecdir} is now /usr/libexec, and payload compression change from xz to zstd. This results in ‘faster decompression’ of the RPMs at roughly the same space (in average a bit smaller even)
• VirtualBox 6.1.3: working support for kernel 5.8
• Mozilla Firefox 80.0
• Kubernetes 1.19

Currently, the developers are bust bringing you these changes, that are being tested in the staging areas:

• KDE Applications 20.08.1
• KDE Plasma 5.19.5
• systemd 246
• glibc 2.32
• binutils 2.35
• gettext 0.21
• bison 3.7.1
• SELinux 3.1

Asistiré a lo que pueda pero creo que es importante recordar que hoy empieza Akademy 2020 en línea. De esta forma del 4 al 11 de septiembre los desarrolladores del Proyecto KDE se verán las caras virtualmente durante casi una semana. Si puedes no te lo pierdas.

Hoy empieza Akademy 2020 en línea

Fue anunciado en el blog en mayo, en una edición especial de Akademy 2020 ya que se realizará en línea por motivos de sobras conocidos por todo el mundo.

En este evento, en el primer día será para la realización de talleres, los dos siguientes será para las charlas y el resto de días para encuentros de desarrolladores.

De esta forma, si os podéis conectar escucharéis las novedades de Plasma para los próximos años y cómo acelerar la versión actual, el reporte de la fundación KDE e.V. en un ejercicio de transparencia, qué hace el desconocido pero vital equipo de promoción, etc.

En esta ocasión, se perderán los momentos de hermandad que se solían cristalizan en cenas y comidas grupales, visitas culturales, cervezas comunitarias y cualquier momento de encuentro que se generaba cerca de la máquina de café, por ejemplo. Una verdadera lástima que se pierdan pero debe primar la seguridad ante este problema al que nos enfrentamos.

Por cierto, puedes seguir las novedades con la etiqueta #akademy2020.

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2017 de Almería en la que tuve la suerte de participar.