HACK THE SYSTEM: 2022

RSS

 Seguime por RSS

19 mar 2022

Lenovo L340 teclado inglés convertido a español, símbolo < > less greater | Lenovo L340-15API us to la-latin1 fix less greater symbol

Con el teclado US standard keyboard viene:


 

Al pasarlo a latam mediante stickers (los detalles en amarillo) queda así:


Si poseen una Lenovo L340-15API con teclado US convertido a español (latam) habrán notado que si bien en X11 con altgr (el alt derecho) + shift + X o Z obtienen < >, en una consola tty no y deben usar "loadkeys us" alternado con "loadkeys la-latin1".

Se puede mapear dichos símbolos modificando el teclado la-latin1 que es el adecuado en consola para este teclado, modificando las siguientes líneas.

En /usr/share/kbd/keymaps/i386/qwerty/ vamos a encontrar la-latin1.map.gz

Creamos mkdir -p /usr/local/share/kbd/keymaps y ahí copiamos la-latin1.map.gz, hacemos gunzip la-latin1.map.gz y editamos el la-latin1.map con vim.

En la línea que tiene "keycode  86 = less             greater" (línea 61 que no funciona), borramos la misma y colocamos:

 

    altgr   keycode  51 = less
    altgr   keycode  52 = greater
 

Grabamos y salimos. Renombramos el archivo a personal.map con el comando mv y luego lo pasamos a .gz con gzip personal.map que lo comprime y pasa a llamar personal.map.gz


Ahora lo copiamos a /usr/share/kbd/keymaps/i386/qwerty/


Usamos localectl para setearlo de esta manera:


localectl set-keymap personal personal


Ya tenemos el alt derecho (altgr) para usar la ubicación original del símbolo <> en la posición que posee el teclado que es < sobre la , y el > sobre el . en consola tty sin tener que pasar a us.



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.

30 ene 2022

De nuevo Fedora, o mejor dicho, Red Hat

Ya hace muchos años, cuando era usuario de Fedora, tuve que pasar por varias situaciones, para darme cuenta que no era una comunidad, sino una aparente comunidad manejada y controlada por Red Hat, porque al fín y al cabo, Fedora no es algo más que la segunda etapa en el control de calidad y creación de RHEL.

Comienza con Fedora rawhide, sigue con Fedora en sus alfa, beta, etc, Fedora final, luego CentOS Stream (antes no lo tenían y es un paso más que añaden a mejorar la distro) y finalmente RHEL.

Más allá de las cuestiones técnicas de si es buena o no, que veo se debate demasiado seguido en muylinux, la cuestión es política y es algo que no se da muy bien en los ambientes de IT. Política no es solamente a quién votan para presidente o son de izquierda, centro o derecha.

Red Hat aprovecha esta cuestión para hacer algo similar a lo que hacen las empresas, llamado "engagement empresarial". De esta manera logran que mucha gente colabore de forma gratuita con Red Hat y Fedora, a cambio de ser reconocidos, formar parte de algo, y claro, poder sumar eso eventualmente a un curriculum.

Por tanto, tenemos una falsa comunidad, ya que si mañana absolutamente todos los colaboradores de Fedora, se van a Debian o Ubuntu, Red Hat en pocos días crea otra Fedora, porque es parte de su workflow y porque realmente Fedora no existe sin Red Hat ni Red Hat sin Fedora. No olvidemos que el equivalente en SLES de SUSE es OpenSUSE y está bien que así sea, la cuestión es cuando no se es claro y se dice cosas como que vos sos igual a cualquier otro porque es una comunidad, y se habla de horizontalidad, cuando no es tal.

Debian por ejemplo, tiene una comunidad, y sus controles de calidad pasan por su debian experimental (fedora rawhide), unstable (Fedora testing), testing (Fedora) y finalmente la stable (RHEL). Más allá de la burocracia y el esquema verticalista de Debian, más que menos es una comunidad.

Hace algunos años, me pasó que Red Hat me robó y borró un bug report /aporte sin reconocimiento alguno y sinceramente no le di mayor importancia porque era gastar tiempo para no obtener resultados, además, debo admitir que lo dejé pasar también un poco por idiota.

Hace poco, el colega sincorchetes, antes Netsys, del blogroll, tuvo un incidente similar con un PR en Fedora.

A Lyude le pagan, su @ es redhat, a Álvaro no le paga nadie y su única ganancia en esto es tener algún reconocimiento y eventualmente ponerlo en su curriculum o donde mejor le guste.

Se ve que Lyude estaba muy apurada (risas) y le resultó más rápido (risas) cerrar un PR, abrir otro, copiar el código, que simplemente añadirlo como estaba y no colocarse en el changelog. Sucede que cuando sos empleado, tenés que cuidar el trabajo y parte de eso es hacer lo que tenés que hacer, porque si lo hace otro, no estás haciendo tu trabajo. No creo que Lyude no sepa o no quiera poner ese parche, sino que alguien de la comunidad, hizo lo que debería haber hecho eso, y en medio de la adquisición de Red Hat por parte de IBM, no es menor "hacer buena letra". Lo podemos ver en su cuenta de twitter:


Sin mucho más que decir, les dejo el enlace a quien cuenta en primer persona lo que le sucedió: https://echemosunbitstazo.es/posts/es-realmente-comunitaria-fedora-project/