HACK THE SYSTEM: 1/2/22

RSS

 Seguime por RSS

13 feb 2022

El clickbait de Wayland en muylinux y la pelotudez de la comunidad millenial

 Espero que como en otros tiempos, no digan que hago una entrada sobre ellos para ganar tráfico, ya que mis lectores, o eso pretendo, son muy diferentes a los suyos.

Por empezar, no diría nunca que es más válida una encuesta de la mejor distro, hecha en mi blog (con 3000 votos) que en distrowatch, solo porque "la de distrowatch, se basa en los click en las páginas", como si eso fuera poco indicativo.

Armaron un artículo que es una pataleta, sobre que ellos (los tarados) aún no tienen Wayland.

No consultaron fuentes, programadores ni gente calificada, y todo para generar visitas.

Luego sale Eduardo Medina en Youtube diciendo lo contrario a lo que publicó su colega en muylinux, donde trabaja, bajando los ánimos, total, ya habían conseguido las visitas para ese entonces.

A diferencia de los palurdos de muylinux, me puse a charlar con un programador sobre la cuestión de Wayland, para entender el tema, ya que no soy programador y no conozco los detalles del asunto. Estés o no metido en el desarrollo de wayland, si sos programador de entornos Linux, sabés de qué va la cosa.

Primeras desinformaciones de Muylinux: Afirman que hace 14 años Wayland está en desarrollo.

Falso, no hace 14 años que está sin estar listo, desde 2013 Tizen lo usa de forma estable: https://www.phoronix.com/scan.php?page=news_item&px=MTUxMTE

Incluso ya antes estaba listo, se empezó en 2008, así que aunque hubiera sido en 2013, no me parece tanto 5 años para una pila gráfica.

Wayland se pensó para seguridad y entornos productivos, jamás para que fuera como Xorg, no es que (como dicen en muylinux), se pensó mal o no existía screencasting (wtf!) en 2008 (lo repite Medina en youtube).

No se puede tener todo, y me refiero a seguridad + flexibilidad. No leo usuarios de OpenBSD quejándose de Xenocara, porque saben y admiten que todo no es posible. Es como tener 123 de password root, porque sos de olvidarte, y a la vez exigir seguridad en tu PC.

Deberían agradecer que Red Hat y otros, están hace años, sí 14, añadiendo cosas alrededor de Wayland para que tenga algunas de las que posee Xorg, y probablemente nunca las tenga todas, porque usar pipewire para reemplazar funcionalidades perdidas, es un arreglo sucio, como capa sobre capa como xwayland.

Entonces, no es cierto que hace 14 años esperan nada, está listo desde al menos 2013 y antes también. No es cierto que "se diseñó mal", sino que se diseñó con otros objetivos y fué justo con el que salió en su versión estable.

Tampoco existe una conspiración entre Canonical y los "usuarios conservadores" para detener Wayland y aunque la hubiera, cómo es que los usuarios esos dentendrían el desarrollo de software en manos de una empresa? no pudieron (pudimos) con systemd, menos con esto. Es ridículo.

Las pelotucedes que dicen en ese blog no tienen límite, pero lo peor es que desinforman y generan discordia sin explicar, tirando su nivel aún más al de una comunidad de Taringa. Un /r de reddit tiene más nivel.

¿Quieren grabar el porno que ven o hacer streaming de su pene a su amigo/a? usen Xorg, ¿quieren seguridad? usen Wayland. Los pedidos de los nenes caprichosos jugones (ay los FPS) son los que demoran wayland, no los "usuarios conservadores".

¿Qué más querría un conservador de Linux (Slackware? Gentoo?) que un servidor gráfico y compositor seguro? no conozco ningún conservador old school contra eso, y si fué y es aún en contra de systemd, es porque de seguro no tiene nada y de KISS menos.

El error de Red Hat posiblemente fué no aclarar de entrada las limitaciones y decir "quieren todo? usen Xorg, quieren una sesión segura para usar su banca móvil? usen Wayland" y fin del asunto.

La demora es porque están metiendo funciones de Xorg en Weston, cosa que ni estaba pensada, y todo eso sin volverlo una cagada, que podría pasar.

Lo que deberían es dejar de joder con pedirle a Wayland HDR, VR, etc, etc, es Linux no Windows. Realmente la comunidad está cada día más pelotuda. Linux no compite con Apple o con Windows como dicen en algunos lados, es como decir que yo compito con el blog dedoimedo, una imbecilidad absoluta.

Empezaron usando Linux por libre, seguro y estable y terminan pidiendo HDR, realidad virtual, grabar la pantalla y stremear en twitch. Mejor se replantean qué OS es para ustedes.

Saludos.

9 feb 2022

Stremio libmpv.so.2: cannot open shared object file: No such file or directory Arch Linux / Manjaro

Si bien en la web oficial de Stremio hay una descarga para Arch / Manjaro, esta nos envía a AUR, para instalarlo usando paru o yay.


Pero existe un problema y es que originalmente, este software fué hecho para Debian / Ubuntu, y como se sabe, a Debian y sus hijos les encanta renombrar los paquetes y sus librerías.

En algunos casos esto no se presenta porque el paquete instalado de mpv de AUR o bien de repo, tiene ya el enlace simbólico, ejempllo de mpv-amd-full-git:

lrwxrwxrwx 1 root root 15 feb  9 20:52 libmpv.so.2 -> libmpv.so.2.0.0

La librería real es: 2,7M -rwxr-xr-x 1 root root 2,7M feb  9 20:52 /usr/lib/libmpv.so.2.0.0

Entonces, la solución a esto es tan simple como:


1) su - root

2) cd /usr/lib/

3) ln -s /usr/lib/libmpv.so.1.109.0 libmpv.so.2

 

Sino, instalen mpv de AUR, en version git.

Solucionado.

3 feb 2022

LibreOffice 7.3.0.3 Developer branch langpack ES PKGBUILD ArchLinux / Manjaro

 Si usan Arch o derivados, Manjaro como es mi caso, habrán notado que en AUR se encuentra la rama desarrollo de libreoffice, que mejora la compatibilidad con MS-Office.

El -dev-bin que se instala, mediante yay, es el paquete clásico, el otro, el de idioma si notan el PKGBUILD contiene todos los idiomas y a la hora de descargar y armarlo, no solo demora mas de 1 hora porque los repos de libreoffice son lentos (500kb promedio) sino que además llena muchísimo el disco para armar algo que no vamos a usar.

Bajé y modifiqué el PKGBUILD de libreoffice para que cree e instale el langpack (no el helppack) de -es. Son apenas 3.7MB.


Resultado del paquete instalado: 

 

pacman -Qi libreoffice-dev-bin-langpack-es
Nombre                    : libreoffice-dev-bin-langpack-es
Versión                   : 7.3.0.3-1
Descripción               : LibreOffice development branch
Arquitectura              : x86_64
URL                       : https://www.libreoffice.org/
Licencias                 : LGPL3
Grupos                    : Nada
Provee                    : libreoffice  libreoffice-es-ES
Depende de                : gtk3  lpsolve  neon  curl
Dependencias opcionales   : java-runtime: adds java support [instalado]
                            java-environment: required by extension-wiki-publisher and extension-nlpsolver
                            coin-or-mp: required by the Calc solver
                            kio: for Qt5 integration
Exigido por               : Nada
Opcional para             : Nada
En conflicto con          : Nada
Remplaza a                : Nada
Tamaño de la instalación  : 26,81 MiB
Encargado                 : Unknown Packager
Fecha de creación         : jue 03 feb 2022 04:31:55
Fecha de instalación      : jue 03 feb 2022 04:34:06
Motivo de la instalación  : Instalado explícitamente
Guion de instalación      : No
Validado por              : Nada

El PKGBUILD es el siguiente:

_pkgnamefmt=LibreOffice
_pkgname=libreoffice
pkgname=${_pkgname}-dev-bin-langpack-es
_LOver=7.3.0.3
pkgver=7.3.0.3
#_basever=$( cut -f1-2 -d'.' <<< ${_LOver} )
pkgrel=1
arch=('x86_64')
license=('LGPL3')
url="https://www.libreoffice.org/"
pkgdesc="LibreOffice langpack-es development branch"
depends=('gtk3' 'lpsolve' 'neon' 'curl')
optdepends=('java-runtime:          adds java support'
            'java-environment:      required by extension-wiki-publisher and extension-nlpsolver'
            'coin-or-mp:            required by the Calc solver'
            'kio:                   for Qt5 integration')
provides=('libreoffice-dev-bin-langpack-es')

source=("https://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/${_pkgnamefmt}_${_LOver}_Linux_x86-64_rpm_langpack_es.tar.gz")
sha256sums=('SKIP')

package() {
	find "${srcdir}/${_pkgnamefmt}_${_LOver}"*/RPMS/*rpm -exec bsdtar -x -f '{}' -C "${pkgdir}" \;
}

Crean un archivo PKGBUILD con el contenido, hacen makepkg -s y eso va a crear un paquete local pkg.tar.zst, el cual instalan con sudo pacman -U.


Espero que les sirva.