Re: movilizar un portatil de pequeñas dimensiones y peso (pensamientos o reflexiones) cienciaficción?
- Inicie sesión ou rexístrese para enviar comentarios
O 2022-08-13 06:11, escribiu:
> Bueno, mas que movilizar un portatil sería whatzappearlo porque
> imagino que llamadas y sms nunca podrian ser enviados ni recibidos,
...bueno, lo cierto es que hay ordenadores que incorporan una
tarjeta WAN que permite conectarse a las redes telefónicas siempre que
haya cobertura. Pero desgraciadamente, no conozco ni un solo
controlador de programación libre que soporte estas tartjetas
> La pieza mas clave que veo que necesitariamos para tal fin, el
> logicamente una version libre de un cliente que nos conecte a la red
> de whatsapp.
Recuerdo los buenos tiempos en que Pidgin se conectaba a los servicios
de mensajería de Microsoft Messenger, Facebook y Yahoo! Eso era posible
porque usaban el protocolo XMPP; pero eso se acabó, porque Microsoft,
Facebook y Yahoo! decidieron imponer sus clientes y desarrollaron sus
propios protocolos. Y no hay remedio, aunque mediante ingeniería
inversa se lograse crear un cliente compatible ellos modificarían su
protocolo para volverlo incompatible. Pierdes tu tiempo, no se logrará
un cliente WhatsApp de programación libre. Sigue mi consejo, pásate a
Telegram FOSSS, disponible en F-Droid. Todo el mundo recomienta Signal,
pero el hecho es que en F-droid no está disponible.
Saludos cordiales,
Ignacio Agulló.
El telegram FOSS ¿Se le puede hacer correr bajo Trisquel? ¿O se necesita android sí o sí?
El cliente libre de Telegram el que está hecho del código fuente liberado por Telegram actualmente no funciona, ni el del distribuido por F-droid ni el distribuido por Trisquel. Ni ningún otro, excepto modificaciones más grandes y con menos funciones, por ejemplo tdlib-purple para Pidgin. O el cliente CLI para Telegram, claramente estos como cualquier cliente libre de Telegram basado en el código fuente liberado no cumplen las funciones actuales de Telegram y tampoco suelen estar actualizados. Telegram es un pésimo servicio de comunicación, a demás de ser centralizado lo que es un grave problema tenemos la deficiencia de software realmente libre para utilizarlo.
La única forma de dejar de ser una víctima del software privativo es dejar de usarlo, un paso sencillo es instalar software libre que lo reemplace. XMPP en mensajería instantánea es el reemplazo para todos los programas que usted usa para comunicarse con software privativo.
los clientes de telegram de los repos de trisquel y el de Fdroid son
libres y funcionan bien a fecha de escribir este mensaje.
Despues hay uno para emacs que funciona genial tambien llamado telega, y
puede hacer hasta llamadas de voz.
Todos ellos libres
Han de entender muchachos que es imposible que ustedes logren alcanzar la libertad informática utilizando teléfonos. Si ustedes merecen tener el control de su informática han de hacer caminos hacía el software libre, pero no caminos ofuscados, ni caminos negligentes que los lleven a una mixtura de software privativo unido al software libre creando un monstruo atractivo que termina siendo software privativo, ya que toda suma de software privativo con software libre es siempre software privativo.
Por lo que veo el cliente oficial de telegram es software libre, de hecho está en la sección principal de los repositorios de debian, https://packages.debian.org/bullseye/telegram-desktop. Otra cosa ya es el servidor de telegram, y que uno se fíe o no de él.
Ese es el mismo que está disponible en Trisquel, ambos inútiles. Por medio de DRM de parte del servidor, impidiendo conectar a los servidores de Telegram.
Un saludo.
Puede ser porque en nabia backports van por la versión 3.11, mientras que en la web oficial van por la versión 4 y pico. Con estos programas suelen impedirte acceder si la versión que usas es muy vieja. Sería cosa de instalar el paquete de la web oficial o el de debian inestable que parece que si que está al día.
He tenido que instalar telegram en el movil y darles un montón de permisos (menos mal que casi nunca tengo conectado el movil a internet así que de poco les sirve), pero he podido hacer la prueba y el cliente ese para linux funciona, siempre y cuando tengas la última versión instalada y cuando pases por el aro de instalar el cliente oficial (no el de fdroid) en el móvil.
Cordial saludo
El cliente de telegram de F-droid si funciona, lo he venido usando hace
rato.
Atentamente,
--
Mancho
Creo que avrtm se refiere al cliente de linux y no a la apk que encontramos a f-droid.
Linux no es un sistema operativo, por favor no escondas el nombre del sistema operativo GNU, te invito a leer el siguiente artículo: https://www.gnu.org/gnu/gnu-linux-faq.html#why
No era mi intención. Es la economía del lenguaje que se impone inconscientemente cunado uno escribe rápido. De todas formas ni con gnu ni con linux por sí solos ni con la combinación exclusiva de lo que desarrolla cada uno de esos proyectos puedes conformar un entorno de trabajo completo de acuerdo con los estándares modernos.
claro iShareFreedom, yo diría para ser justos con gnu y con los linux que llevan blobs: GNU/LinuxLibre para especificar que el linux usado no es el de los binarios privativos sino que se le ha aputado esa parte no libre.
iShareFreedom: Ese es el mismo que está disponible en Trisquel, ambos inútiles. Por medio de DRM de parte del servidor, impidiendo conectar a los servidores de Telegram.
el servidor casi siempre es incontrolable, use php o lo que sea, no tenemos acceso a las fuentes en tiempo real, puedes esnifar el trafico entre tu cliente y el servidor, pero si hay cifrado de poco serviría imagino, aunque pudiera sugerir ideas de como funciona el protocolo, pero poco mas. Los programas o webs aun que digan que sus fuente en el servidor son libres, podrían mentir, creo que eso no es auditable, pero también decir que si estamos conectados a un servidor privativo con nuestro cliente libre, en principio nuestro ordenador seguiría libre, porque el programa privativo del servidor no lo ejecutaríamos en nuestro ordenador, pero si consideramos un programa en red como una unidad (que es lo que en definitiva ocurre (programa cliente, red que los conecta, y programa servidor)), es decir las tramas de datos que corren por la red entre el cliente y el servidor fusionan a ambos (cliente y servidor) en un solo programa. pero si usaríamos programas privativos en el servidor o ordenador ajeno, eso seía que éticamente reprobable, nos vuelve algo corruptos o vendidos software privativo de alguna manera supongo.
----
Discrepo con ambos:
O 2022-08-29 04:46, escribiu:
> iShareFreedom: Ese es el mismo que está disponible en Trisquel, ambos
> inútiles. Por medio de DRM de parte del servidor, impidiendo conectar
> a los servidores de Telegram.
Telegram FOSS me va bien sobre Replicant y Android.
Telegram Desktop me va bien sobre GNU/Linux Trisquel (licencia GNU v3
con excepción SSL).
https://github.com/telegramdesktop/tdesktop
> el servidor casi siempre es incontrolable
El cliente es casi lo mismo. ¿Te instalas únicamente compilaciones
realizadas por ti mismo a partir del código fuente? ¿O auditas toda la
programación que te instalas, recreando los binarios a partir del código
fuente para verificar que coinciden con los que te ofrecen? Entiendo tu
forma de pensar: la desconfianza es la base de la seguridad, la
programación en servidor es inauditable; pero casi nadie audita todo lo
que se instala. Mi postura es: cliente de programación libre +
comunicación cifrada de extremo a extremo = suficientemente bueno.
Saludos cordiales, Ignacio Agulló.
Ignacio Agulló: ...bueno, lo cierto es que hay ordenadores que incorporan una
tarjeta WAN que permite conectarse a las redes telefónicas siempre que
haya cobertura. Pero desgraciadamente, no conozco ni un solo
controlador de programación libre que soporte estas tartjetas
Imagino que es por el secreto de como funcionan los chips de las redes movilés, 4g, 5g, igual si analizaran los chips que leen las sims con microscopio los que entienden de electrónica, podrían los que entienden de programación de drivers sacar un controlador libre, aunque igual ni así podrían porque por ejemplo y desde mi ignorancia, podría haber alguna eprom con software cifrado que lo impediese...
----
Ignacio Agulló: Recuerdo los buenos tiempos en que Pidgin se conectaba a los servicios
de mensajería de Microsoft Messenger, Facebook y Yahoo! Eso era posible
porque usaban el protocolo XMPP; pero eso se acabó, porque Microsoft,
Facebook y Yahoo! decidieron imponer sus clientes y desarrollaron sus
propios protocolos. Y no hay remedio, aunque mediante ingeniería
inversa se lograse crear un cliente compatible ellos modificarían su
protocolo para volverlo incompatible. Pierdes tu tiempo, no se logrará
un cliente WhatsApp de programación libre. Sigue mi consejo, pásate a
Telegram FOSSS, disponible en F-Droid. Todo el mundo recomienta Signal,
pero el hecho es que en F-droid no está disponible.
claro, para que no escape nadie de su control, si una alternativa libre aparece, a ellos les esta chupado modificar alguna parte de el protocolo para volver a impedir que funcione el cliente libre.
Lo malo es que mis grupos y contactos en su mayoría solo usan whatsapp, pero claro esta que mi estomago libre digiere mejor telegram que whatsapp por la existencia de su cliente libre en f-droid por parte de telegram.
----
La solución no está en utilizar Telegram para mensajería instantánea, la solución está en adoptar cuanto antes XMPP dejando de utilizar WhatsApp y Telegram, de modo que tus contactos se vean forzados a usar software libre para comunicarse contigo. De otra forma no hacemos más que legitimar el uso de software privativo y su dependencia. De otra manera tus contactos, familiares y amigos nunca verán necesario utilizar software libre, por cuanto nunca dejaste de usar el software privativo por medio del cuál permanecen comunicándose.
Desde un punto de vista de autonomía, privacidad y diseño jami sería la última solución que se necesita, mientras el dispositivo que uses no se muera, en algún momento lo intenté usar, pero en ese momento no era precisamente funcional, hoy día tengo entendido que las mejoras necesarias fueron integradas en las últimas versiones (F-Droid), tal vez quieran ver si les funciona.
Lamentablemente no todo es miel sobre hojuelas, su desarrollo está "segmentado" por lo que construir paquetes binarios para su contraparte en escritorios GNU/Linux no es nada sencillo, al grado que Ubuntu no lo incluyó en la LTS Jammy 22.04 y Debian tiene bloqueada su integración desde hace más de 1 año por varios temas de compatibilidad, para aramo la historia no es muy diferente ya que temporalmente se removió del arreglo de paquetes iniciales hasta que se resuelvan dichos problemas de compatibilidad.
Con respecto de telegram, hasta donde recuerdo en nabia-backports, hay una versión con soporte a dicho servicio, así como en versiones posteriores.
Considero necesario entender que todas las soluciones que requieran de un servicio ajeno, siempre se podría especular que hay sombras detrás de la puerta, pero siendo estrictos, el uso de servicios de correos externos que se venden como "ultra-seguros/respetuosos de la seguridad" como hushmail, proton mail, mailfense, no están muy lejos de lo que telegram ofrece, en ocasiones como esta se podría complicar el entender que la seguridad, la privacidad y autonomía el día de hoy, muy poco tiene que ver con la conveniencia, facilidad y popularidad del servicio.
Pero si creo que estas pláticas nos ayudan a ver un paso más allá de lo que hoy podemos ver.
Saludos y comunicaciones seguras.
Ark, podrías explicar cual es la diferencia entre los repositorios disponibles en Trisquel?
Ark, podrías explicar cual es la diferencia entre los repositorios disponibles en Trisquel?
Pues cada versión tiene sus propios repositorios,
Etiona, Nabia, Aramo, etc.
Tomando como ejemplo nabia, estos se componen por,
- nabia - repositorio de paquetes base
- nabia-updates - el canal de actualizaciones de paquetes convencionales.
- nabia-security - el canal que recibe actualizaciones de seguridad heredadas de upstream (Debian/Ubuntu), normalmente paquetes que se rigen por estándares de seguridad, ssh, openssl, java, glibc, postfix, dovecot, linux, etc.
Todos los anteriores si o si deberías tenerlos activados.
- nabia-backports es para actualizaciones "no convencionales", estas normalmente salen del esquema de point release, donde los paquetes se congelan en un momento en el tiempo, y tienes acceso a actualizaciones que aunque no tienen un alto rigor en su revisión de seguridad, en ocasiones llevan al límite la compatibilidad para poder acceder a versiones más recientes.
Tomemos como ejemplo kdenlive en nabia,
kdenlive | 4:19.12.3-0ubuntu1 | http://archive.trisquel.org/trisquel nabia/main Sources
kdenlive | 4:19.12.3-0ubuntu1+10.0trisquel1 | http://archive.trisquel.org/trisquel nabia-updates/main Sources
kdenlive | 4:22.04.3-1~ubuntu20.04.1+10.0trisquel2 | http://archive.trisquel.org/trisquel nabia-backports/main Sources
La versión base (4:19.12.3-0ubuntu1) viene directamente de ubuntu, cuando se realiza alguna modificación en trisquel (misma versión) entra en updates (4:19.12.3-0ubuntu1+10.0trisquel1) y si posteriormente** (como es este caso) se decide rastrear la última versión, esto se hace vía nabia-backports (4:22.04.3-1~ubuntu20.04.1+10.0trisquel2).
La versión mas reciente de kdenlive 22.08 (publicada hace un par de semanas) ya no es compatible con las bibliotecas base de nabia, por lo que no hay manera de tenerla como un .deb compilado desde código fuente, querer usar 22.08 requiere moverse a aramo (con backports activado), o instalarlo vía guix, flatpack, appimage, etc., ya que esos paquetes no usan las bibliotecas del sistema, sino que re-empaquetan todo de nuevo en la versión que requieran (algo similar a lo que hace con instaladores en MS Windows).
Esto resume como llegan las cosas a backports en trisquel, dado que alteran paquetes fuera del esquema de soporte de la distro predeterminado no viene activo de manera predeterminada y se sobre entiende que activarlo es bajo responsabilidad del usuario, ¡ojo!, no se vaya a mal interpretar, backports no significa que tendrás actualizaciones de todos los paquetes de la distribución a su última versión posible, si buscas eso entonces estás pensando en una distro rolling release, no en Trisquel.
En backports normalmente encontrarás solo los paquetes que estratégicamente sirven a la distribución para extender algún tipo de soporte fuera de las versiones base o que algún desarrollador se disponga a mantener.
Lamento extenderme tanto, además que terminé robándome el hilo fuera de su tema original, una disculpa.
Espero haber respondido la pregunta, saludos.
** actualmente solo se realiza un set de cambios por paquete, indiferente del repositorio en donde se quiera mandar.
¡Hola Ark!
Por mi no te disculpes. >iShareFreedom te ha tirado de la lengua.... >:¬D
pero es muy interesante todo lo que explicas.
Igual esta información se podría añadir a la documentación de Trisquel tal cual, pregunta y respuesta.
Aclara bastantes cosas sobre los respositorios...
Muy interesante ark74, este post tuyo ha abierto luz en en mis sombras.
He estado en https://jami.net y tiene muy buena pinta, el problema que veo es si lo usarán los usuarios que no saben que es un código fuente y un compilador, y por lo tanto se sienten libres sin serlo.
Eso de comunicación entre iguales, lo veo algo raro, no es que lo ponga en duda, sino que no encaja muy bien con mi saber actual de redes, clientes y servidores, ¿que hay? ¿algún tipo de nodo o nodos descentralizados (parte servidor) tipo el tracker de un cliente de torrent que se encarga de abrir las conexiones entre los clientes con cifrado de cliente a cliente?
- Inicie sesión ou rexístrese para enviar comentarios