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/06/opensuse-tumbleweed-review-of-the-week-2020-24/

Otra semana que se pasa. Y en esta semana ha habido algunos problemas técnicos a la hora de publicar snapshots”. Dos fueron marcadas para ser publicadas, pero no llegaron a los servidores. En otra kiwi renombró las imágenes “live” de -i686- to -ix86-.  Así que debido a esto solo se han publicado 3 snapshots (0604, 0609 y 0610; 0609 contiene los cambios de 0605 y 0607 las snapshots que no llegaron a los servidores)

Los cambios más significativos en estas snapshots fueron:

• GNOME 3.36.3
• Mozilla Firefox 77.0.1
• Libvirt 6.4.0
• Transmission 3.00
• KDE Plasma 5.19.0

Y algunas cosas que se incluirán en próximas snapshots:

• KDE Applications 20.04.2
• SQLite 3.32.2
• Linux kernel 5.7.1
• Mesa 20.1.0
• RPM change
• openSSL 3.0

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

——————————–

Como sabréis, este año se Akademy 2020 se celebrará en línea del 4 al 11 de Septiembre. La entrada de hoy es para recordaros que el Call for Papers, es decir, la recepción de charlas está abierto, con lo que Akademy 2020 sigue esperando tu charla, si es que todavía no te has atrevido a presentarla.

Akademy 2020 sigue esperando tu charla ¡A qué esperas!

A pesar de todas las restricciones para vernos que tenemos debido a la pandemia, los eventos comunitarios parece que no se detienen.

El pasado 15 de abril compartí con vosotros que este año Akademy 2020 se realizaría en línea del 4 al 11 de septiembre, en una edición muy especial.

Siguiendo el esquema habitual, las charlas se realizarán en línea el sábado 5 y el domingo 6, dejando el resto de días para el trabajo en pequeños grupos en sala más reservadas pero no privadas, es decir, que no están cerradas sino que todo el que quiera aportar algo está invitdado.

Como se ha comentado en anteriores ocasiones, uno de los objetivos de Akademy es aprender y enseñar nuevos conocimientos y compartir entre nosotros la pasión de lo que se hace en KDE.

Para compartir ideas, experiencias o momentos, se reservan talleres específicos en la sede (o se aprovechan los corrillos en los pasillos, las cenas o los momentos de barra), pero para enseñar y compartir detalles técnicos se utilizan las charlas.

Si crees que tienes algo importante que presentar, por favor házselo saber a la organización. Y si crees que alguien debería presentar su ponencia, no dejes de animarlo para que lo haga. Todas las contribuciones son útiles.

Para más detalles, mira las líneas generales del Call for Papers. Tienes de plazo para enviar tu propuesta hasta el domingo 14 de Junio 23:59:59 CEST.

Vía: KDE News

¿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, ideólogos, etc. 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 que se mantendran gracias a las listas de correo, canales irc o Sprints.

Hay que recordar que en España tenemos gran tradición en la celebración de Akademy ya que en 2005 se celebró en Málaga , en 2011 en Gran Canaria, en 2013 en Bilbao, en 2015 en A Coruña y en 2017 en Almería, todos esos años junto con Akademy-es (como este año), y que fue un gran éxito tanto de asistentes, como de ponencias o de resultados. Así que no tienes excusa para asistir ya que por el «precio» de uno este año tienes dos grandísimos eventos a tu alcance.

Dear Tumbleweed users and hackers,

Another week has passed. There have been a few technical issues around the publishing of our snapshots. Two were flagged for release, but actually never made it to the mirrors. Turned out, kiwi renamed some of the live-images from *-i686-* to *-ix86-*. But nothing else knew about it. As we even have links on the web pointing to those image names, we opted to revert to the original name. So, due to this, we only release 3 snapshots (0604, 0609, and 0610; 0609 contained the changes of 0605 and 0607 – the ones that got not synced out).

The changes in these snapshots were:

• GNOME 3.36.3 (sadly, upstream did not release a gnome-desktop update; this package would be responsible for the version number shown in the control center)
• Mozilla Firefox 77.0.1
• Libvirt 6.4.0
• Transmission 3.00
• KDE Plasma 5.19.0

Thins being worked on include:

• KDE Applications 20.04.2
• SQLite 3.32.2
• Linux kernel 5.7.1
• Mesa 20.1.0
• RPM change: %{_libexecdir} is being changed to /usr/libexec. This exposes quite a lot of packages that abuse %{_libexecdir} and fail to build
• openSSL 3.0

Hace un par de días que apareció la nueva versión del escritorio de la Comunidad KDE y ya es hora de empezar a hablar unde algunas novedades de Plasma 5.19, ahora que ya está disponible en algunas distribuciones, como KDE Neon, y he podido probarlo un poco.

Algunas novedades de Plasma 5.19

El pasado 9 de junio de 2020 fue lanzado Plasma 5.19, otro paso más en la evolución constante de este entorno de trabajo, y cuyo lanzamiento destacaba por la optimización de código, con lo cual se limaban las asperezas de las anteriores versiones.

No obstante, los desarrolladores de KDE no pueden ofrecer una nueva versión sin ofrecer novedades. El martes compartí una pincelada de ellas pero hoy es el momento de hacer una revisión un poco más pormenorizada.

Empezaré con las novedades del Escritorio, la uniformidad de aspecto y comportamiento de la bandeja del sistema y los plasmoides.

Escritorio y bandeja de sistema

Las primera de las novedades que encontramos es un cambio en el fondo de escritorio por defecto. Ahora es Flow, diseñado por Sandra Smukaste, que nos ofrece mucho color y contraste, en contraste con el tono pastel del anterior. Personalmente me gustaría que cada versión tuviera su fondo por defecto, para así poder diferenciar rápidamente cada lanzamiento.

También se han mejorado detalles que no se notan demasiado hasta que se trabaja mucho con el entorno. De esta forma el espaciador del panel, el elemento invisible que ayuda a situar componentes en el panel, puede ahora centrar automáticamente los plasmoides.

Por otra parte se ha completado la colección avatares por defecto para escoger cuando esté configurando su usuario, un pequeño detalle que siempre da un toque de profesionalidad a cualquier entorno.

Además, Plasma 5.19 incorpora un diseño consistente y un área de cabecera uniforme para las miniaplicaciones de la bandeja del sistema y para las notificaciones.

Para finalizar comentar que se ha mejorado la integración de aplicaciones No-KDE, como es el caso de las creadas con librerías GTK. De esta forma:

• Las aplicaciones GTK3 aplican inmediatamente los esquemas de color recién seleccionados.
• Las aplicaciones GTK2 ya no tienen colores estropeados y se ha aumentado el tamaño del tipo de letra de anchura fija de 9 a 10 puntos, mejorando la lectura de las mismas.

Los plasmoides también mejoran

Esos maravillosas miniaplicaciones que dan el extra de configuración a nuestro escritorio han sufrido pequeñas per significativas mejora.

De esta forma:

• Se ha refrescado el aspecto de la miniaplicación de reproducción multimedia de la bandeja del sistema
• Ampliado el control sobre la visibilidad de los controles de volumen, al tiempo que se ha limpiado y mejorado su aspecto, algo cada vez más importante ahora que todos vamos con auriculares y micrófonos variados.
• El plasmoide «Monitor del sistema» se han reescrito desde cero, ofreciendo un aspecto mucho más elegante y acorde con el escritorio.

• Se han resideñado las ayudas emergentes del gestor de tareas.
• Las notas adhesivas contienen varias mejoras de usabilidad.

Y no me canso de ver y compartir el vídeo promocional de este lanzamiento de Plasma 5.19.

Mañana más novedades, aunque si queréis verlas ya todas, os remito al anuncio oficial en al web oficial de KDE.

When Go 1.12 was released, I was very excited to test out the new opt-in support for TLS 1.3. TLS 1.3 is a major improvement to the main security protocol of the web.

I was eager to try it out in a tool I had written for work which allowed me to scan what TLS parameters were supported by a server. In TLS, the client presents a set of cipher suites to the server that it supports, and the server chooses the best one to use, where “best” is typically a reasonable trade-off of security and performance.

In order to enumerate what cipher suites a server supports, a client must make individual connections, each offering a single cipher suite at a time. If the server rejects the handshake, you know the cipher suite is not supported.

For TLS 1.2 and below, this is pretty straightforward:

func supportedTLS12Ciphers(hostname string) []uint16 {
	// Taken from https://golang.org/pkg/crypto/tls/#pkg-constants
	var allCiphers = []uint16{
		tls.TLS_RSA_WITH_RC4_128_SHA,
		tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA,
		tls.TLS_RSA_WITH_AES_128_CBC_SHA,
		tls.TLS_RSA_WITH_AES_256_CBC_SHA,
		tls.TLS_RSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_RSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_RSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA,
		tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
		tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
		tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
		tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
		tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
	}

    var supportedCiphers []uint16
    
	for _, c := range allCiphers {
		cfg := &tls.Config{
			ServerName:   hostname,
			CipherSuites: []uint16{c},
			MinVersion:   tls.VersionTLS12,
			MaxVersion:   tls.VersionTLS12,
		}

		conn, err := net.Dial("tcp", hostname+":443")
		if err != nil {
			panic(err)
		}

		client := tls.Client(conn, cfg)
		client.Handshake()
		client.Close()

		if client.ConnectionState().CipherSuite == c {
			supportedCiphers = append(supportedCiphers, c)
		}
	}

	return supportedCiphers
}

After writing the barebones code to support TLS 1.3 in the tool, I discovered something unfortunate: Go does not allow you to select what TLS 1.3 cipher suites are sent to the server. The rationale makes sense: TLS 1.3 greatly simplified both what is contained within a cipher suite and how many are supported. Unless and until there is a weakness in a TLS 1.3 cipher suite, there’s nothing to be gained in allowing them to be customized.

Still, this tool was one of the rare situations where it makes sense, and I wanted to see if I could hack it in. Enter go:linkname. Buried deep in Go’s compiler documentation:

//go:linkname localname importpath.name

The //go:linkname directive instructs the compiler to use “importpath.name” as the object file symbol name for the variable or function declared as “localname” in the source code. Because this directive can subvert the type system and package modularity, it is only enabled in files that have imported “unsafe”.

Well hello! This looks promising. If there is a function or variable in Go’s standard library that specifies what the list of TLS 1.3 ciphers are, we can override that in our tool by instructing the Go complier to use our local implementation instead of the one in the standard library.

Let’s dig into the standard library’s TLS 1.3 implementation. In crypto/tls/handshake_client.go [link], we have:

if hello.supportedVersions[0] == VersionTLS13 {
		hello.cipherSuites = append(hello.cipherSuites, defaultCipherSuitesTLS13()...)
        // ...
}

Great! Let’s just override this defaultCipherSuitesTLS13() function. In crypto/tls/common.go [link]:

func defaultCipherSuitesTLS13() []uint16 {
	once.Do(initDefaultCipherSuites)
	return varDefaultCipherSuitesTLS13
}

This complicates things a bit. This calls an initialization function lazily on first use, and that function manipulates a bunch of internal default lists beyond just the TLS 1.3 cipher suites list. We don’t want to mess with any of that. But in that initDefaultCipherSuites function, we have this [link]:

varDefaultCipherSuitesTLS13 = []uint16{
    TLS_AES_128_GCM_SHA256,
    TLS_CHACHA20_POLY1305_SHA256,
    TLS_AES_256_GCM_SHA384,
}

Ah ha! A package global variable is assigned the cipher suite values. And because this initialization function is only ever called once, we can initialize the list and then take control of it in our code.

// Using go:linkname requires us to import unsafe
import (
    "crypto/tls"
    _ "unsafe" 
)

// We bring the real defaultCipherSuitesTLS13 function from the
// crypto/tls package into our own package.  This lets us perform
// that lazy initialization of the cipher list when we want.

//go:linkname defaultCipherSuitesTLS13 crypto/tls.defaultCipherSuitesTLS13
func defaultCipherSuitesTLS13() []uint16

// Next we bring the `varDefaultCipherSuitesTLS13` slice into our
// package.  This is what we manipulate to get the cipher suites.

//go:linkname varDefaultCipherSuitesTLS13 crypto/tls.varDefaultCipherSuitesTLS13
var varDefaultCipherSuitesTLS13 []uint16

// Also keep a variable around for the real default set, so we
// can reset it once we're finished.
var realDefaultCipherSuitesTLS13 []uint16

func init() {
    // Initialize the TLS 1.3 ciphersuite set; this populates
    // varDefaultCipherSuitesTLS13 under the covers
    realDefaultCipherSuitesTLS13 = defaultCipherSuitesTLS13()
}

func supportedTLS13Ciphers(hostname string) []uint16 {
	var supportedCiphers []uint16

	for _, c := range realDefaultCipherSuitesTLS13 {
		cfg := &tls.Config{
			ServerName: hostname,
			MinVersion: tls.VersionTLS13,
		}

		// Override the internal slice!
		varDefaultCipherSuitesTLS13 = []uint16{c}

		conn, err := net.Dial("tcp", hostname+":443")
		if err != nil {
			panic(err)
		}

        client := tls.Client(conn, cfg)
		client.Handshake()
		client.Close()

		if client.ConnectionState().CipherSuite == c {
			supportedCiphers = append(supportedCiphers, c)
		}
	}

	// Reset the internal slice back to the full set
	varDefaultCipherSuitesTLS13 = realDefaultCipherSuitesTLS13

	return supportedCiphers
}

As you can see, we used go:linkname to subvert package modularity for both a function and a variable. We use a package init function to populate the default cipher suites list, and then we override it as we iterate and attempt connections with only a single supported cipher suite. Finally, we make sure to clean things up and set the default list back to the full set for any future uses.

Lastly, let’s glue things together:

func main() {
    hostname := os.Args[1]
	fmt.Println("Supported TLS 1.2 ciphers")
	for _, c := range supportedTLS12Ciphers(hostname) {
		fmt.Printf("  %s\n", tls.CipherSuiteName(c))
	}
	fmt.Println()
	fmt.Println("Supported TLS 1.3 ciphers")
	for _, c := range supportedTLS13Ciphers(hostname) {
		fmt.Printf("  %s\n", tls.CipherSuiteName(c))
	}
}

$ go run cipherlist.go joeshaw.org
Supported TLS 1.2 ciphers
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Supported TLS 1.3 ciphers
  TLS_AES_128_GCM_SHA256
  TLS_CHACHA20_POLY1305_SHA256
  TLS_AES_256_GCM_SHA384

There you have it.

go:linkname should be used very sparingly. Consider carefully whether you must use it, or whether you can solve your problem another way. For me, the alternative was to import all of crypto/tls to make some minor edits. It would also freeze me into a point in time of the Go TLS stack and put the burden of upgrading onto me. While I know that there are no compatibility guarantees with Go’s crypto/tls internals, using go:linkname allows me to use the TLS stack provided by current and future versions of Go as long as the particular pieces I am using don’t change. I can live with that.

The full code for this test program lives in this Github repository.

Me complace hacerme eco de una noticia que apareció hace unos días en el canal de ídem de Slimbook. Y es que en ella se constata que si quieres un portátil linux afinado una de tus opciones más claras es un Slimbook ProX. ¿Quieres saber porqué? Sigue leyendo.

KDE Blog y Slimbook, una historia de amor

Los lectores del blog lo tendrán claro a estas alturas: soy un firme defensor de las empresas que viven del Software Libre, las cuales no solo tienen todo mi apoyo sino que me tiene como consumidor habitual. Así ha sido con peluches Konqi (tengo uno que le compré especial para mi hijo), camisetas de Freewear (tengo muchas y hace poco los tuvimos en el blog) o dispositivos de Slimbook (he comprado 3 y he ayudado a vender algunos para mis conocidos).

Creo que el futuro económico del Software Libre puede estar en el merchandising y en la venta de equipos con Software de Calidad preinstalado, ya que parece que las administraciones publicas no ven, o no quieren ver, las ventajas económicas y sociales de este movimiento.

Una de estas empresas claves es Slimbook (no es la única, pero es la que conozco más a fondo). Y es que fue para mi una fortuna encontrar una empresa que ofreciera de fábrica un portátil con Linux de calidad y a un precio razonable, tras mucho tiempo de buscar por la red hace unos años.

De esta forma conocí en agosto de 2015 a la empresa Slimbook, la cual no solo me proporcionó un buen portátil, un servicio técnico humano y excelente y el inicio de una buena amistad.

Toda esta introducción es para justificar que cada cierto tiempo les dedique una entrada ya que me alegra cada vez que ofrecen al mercado un nuevo dispositivo, ayudan a la Comunidad con sus eventos en Linux Center o reciben un premio o reconocimiento, como es en esta ocasión.

SlimSlimbook ProX, el portátil Linux más potente del mercado

El pasado 7 de junio en la web de Slimbook apareció el siguiente artículo «PROX supera a System76 y Tuxedo en test independientes» que se podía resumir en los siguientes titulares, y que os recomiendo leer para entrar en los detalles.

• Jason Evangelho, redactor de la revista Forbes, ha cogido tres portátiles de 14 pulgadas y ha comparado su rendimiento.
• Los portátiles eran:
  • Slimbook ProX de 8GB de RAM y un disco duro Wester Digital.
  • Lemur Pro de System76 de 40GB de RAM y NVMe Samsung 970 EVO.
  • InfinityBook de Tuxedo con 16GB de RAM y NVMe Samsung 970 EVO.
• En la comperativa:
  • El Slimbook supera en un 2.9% y un 36.9% al Lemur Pro y no pierden en ninguna comparativa.
  • El Slimbook supera en un 13.8% y un 102% al InfinityBook, aunque pierde dos comparativas por escaso margen (menos de un 5%)

Adjunto las imágenes de las comparativas:

Esta comparativa y sus resultados, en mi opinión, son una excelente noticia por varias razones para la empresa valenciana.

La primera de ellas es que demuestra que montar ordenadores es algo más que juntar piezas: se han de balancear, ajustar, configurar, calibrar, etc. De lo contrario es como cocinar sin ponerle el tiempo, el mimo y el cuidado que una receta se merecer, o montar un coche y no ponerle aceite en las piezas móviles para reducir la fricción.

La segunda es porque la gente de Slimbook no se queda solo con la victoria, que es notable, sino que explica las razones pormenorizadas de su éxito, (o al menos parte de él) lo cual se resume en un ajuste más preciso de sus equipos y en ofrecer más libertad y transparencia a sus clientes, ya que les permite elegir cómo de agresivo o de cauteloso se comporta su equipo respecto a exprimir toda su potencia.

Así que solo me queda felicitar a la gente de Slimbook por sus resultados técnicos, desearles muchas ventas y esperar ansioso sus novedades.

PD: Quisiera recordar una cosa que he dicho ya en varias ocasiones. No penséis que hago toda esta publicidad porque reciba una compensación económica… la publicidad del margen fue iniciativa mía, y por tanto, no reibo un euro de ello. El banner está porque creo firmemente en este proyecto, igual que el de Freewear. A Google si le cobro (pero me da tan poquito que solo sirve para chuches)

Veamos cómo poder añadir un calendario a nuestro editor Vim en el que programar eventos, y anotar una lista de tareas a realizar

clic sobre la imagen para ampliar

Quizás eres de los que te gusta tener todo bien organizado y utilizas una aplicación de calendario para llevar al día tu agenda. Si además eres fan del editor Vim, veamos cómo unir ambas cosas.

Veamos cómo añadir una aplicación de calendario con la que programar eventos y tener una lista de tareas a realizar.

Este artículos forma parte del “Curso improVIMsado” sobre el editor Vim que publico en mi blog desde hace muchos meses y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Lo primero que debemos hacer es descargar el complemento para nuestro editor Vim desde el repositorio de GitHub:

• https://github.com/itchyny/calendar.vim

Podemos utilizar un gestor de complementos o copiar el contenido de las diferentes carpetas del repositorio dentro de las carpetas con el mismo nombre en nuestro equipo dentro de la carpeta .vim de nuestro /home

Una vez hecho esto, ya podemos abrir nuestro editor Vim, trabajar con nuestros archivos y si queremos abrir el calendario, simplemente ejecutar el comando :Calendar

Esto nos abrirá una nueva pestaña y de manera predeterminada nos mostrará una vista del mes en curso. Aunque si queremos podemos abrir un calendario con la fecha que queramos.

La primera vez que abramos el complemento nos pedirá en qué calendario queremos que guarde los datos, le pondremos un nombre y todos los recordatorios se guardarán en ese calendario.

No se sincroniza con otros calendarios que utilicemos, sí puede sincronizarse con Google Task, pero como no utilizo esta opción no tengo ni idea de cómo se hace (más información en el repositorio de GitHub).

Una vez abierto el calendario podemos pasar de una vista a otra mediante las teclas < y >. Vista del año completo, del mes, de la semana, de los 4 días, del día en cuestión y otra con un reloj son las distintas opciones disponibles.

Para abrir la lista de tareas, pulsaremos sobre la tecla T. Y con o añadiremos nuevas tareas, con i o con a podremos editar una en cuestión, etc.

Para darlas por finalizadas lo haremos con D. Esto nos mostrará la tarea en un color diferente, para marcarla como realizada. Si queremos borrar las tareas realizadas lo haremos con L.

También podemos ir a una fecha específica y añadir con la tecla a un evento a una hora que queramos y repetir la opción en otras fechas y horas que necesitemos.

Pero mejor verlo en acción, así que aquí os dejo un vídeo en formato .webm disponible en archive.org

Y también en YouTube para quien prefiera esta plataforma

https://www.youtube.com/watch?v=xdiSWBC3GyU