183 meneos
867 clics
El CERN cambia el uso de Facebook Workplace por Mattermost y Discourse
El Centro Europeo de Investigación Nuclear (mejor conocido como CERN) realizó hace poco un anuncio en el que explica el cese del uso de la plataforma “Facebook Workplace” que era utilizado para la comunicación interna entre los empleados. En su lugar y de ahora en adelante el CERN utilizará paquetes abiertos de Mattermost para mensajes rápidos y chat, y Discourse para largas discusiones e intercambio de información a la que se puede hacer referencia en el futuro.
|
comentarios cerrados
Sorpreson!
#2 A mí me deja perplejo que cualquier institución pública use software privativo, porque no es sólo Facebook el que genera preocupaciones sobre la privacidad de los datos, es cualquier software que no sabes qué hace por debajo.
#3 Lo que quieran (hay mucho software muy bueno para la comunicación más allá de las listas de correo) siempre que sea software libre.
Es trivial configurar un cliente de correo como Sylpheed y organizarlo según cc:to de listas de correo en subcarpetas, y nunca pierdes un hilo.
Quizá porque se combina (a la vez, depende del proyecto y cliente) con MS Teams, Slack, Signal. Un verdadero dolor de cabeza.
El asunto del coste me parece hasta secundario: prefiero pagar 100 millones en sueldos a un cuerpo de ingenieros de software que trabajen en la administración manteniendo y desarrollando aplicaciones que 50 millones a una empresa extranjera que tiene que permitir que su gobierno meta puertas traseras en el código. Al menos ese dinero se quedaría en el país, pagando sueldos y generando conocimiento.
Por supuesto, luego enchufabas Antena 3 Noticias y todos los vecindarios de Tarragona diciendo que las Autoridades no habían dado señales de vida, que nadie les había informado de nada, que las alarmas no habían sonado, que no habían recibido ninguna instrucción de cómo actuar por parte de los servicios de emergencias... eso sí: Twitter echando más humo que el incendio
Surrealista.
A mí por ejemplo Slack me gusta mucho para el curro. Se hablan las cosas por ahí con respuestas instantáneas de los implicados y ya cuando se decide algo pues se envía un correo para guardar registro de las decisiones tomadas.
El problema es precisamente el mismo que el de Facebook: la privacidad de Slack es nula y encima todos los datos que metas ahí desde ficheros con información sensible hasta código, contraseñas... se van directos a un servidor en Estados Unidos del cual ya no vuelven a salir jamás, Slack se los queda pa él pa siempre, igual como hace Suckerberg.
Vamos, que igual para una empresilla pequeña de ámbito local con un producto poco innovador Slack te puede hacer un apaño pero desde luego yo me mantendría alejado de ahí si creyera que mi empresa tiene algo revolucionario que a nadie más se le ha ocurrido, o si manejase documentación sensible.
Pues vaya MIERDA de grupos de seguridad, IT, etc que tiene el CERN!!!
blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
El volumen de datos manejado es bastante superior y el indexado es impepinable.
Además, hace trivial el participar desde donde sea.
marc.info/
"Over the years, use of email for communication has declined, and the overhead of maintaining the infrastructure has increased; sending email to hundreds or thousands of people has become increasingly indistinguishable from spam, in the eyes of service providers, and GNOME had to try and ask for exceptions—which are not easy to get, and are quite easy to be revoked. "
No estás solucionando estos problemas, si acaso este otro:
"On top of that, the infrastructure in use for managing mailing lists is quite old and crumbly, and it’s unnecessarily split into various sub-categories that make following discussions harder than necessary."
Son unos putos hipsters y en vez de meter las manos, solo son capaces de reemplazar tecnologías por sus santos cojones.
En las otras comunidades como los BSD, Linux (el kernel), Slackware/Slackbuilds, compiladores... lo gestionan de maravilla.
Me recuerdan a los de la Linux Foundation usando casi todos Macbooks con OSX. La risión.
Una pequeña aclaración, si no te parece mal.
En lo de que las instituciones no deberían usar software privativo, si exite software libre que proporcione el mismo servicio, estoy de acuerdo.
Pero que tu y yo estemos de acuerdo en esto, no significa que todo el software "privativo" (y/o propietario), sea software cerrado. Yo uso "programas" y código "privativo" que es, abierto y gratuito, y software abierto que no están bajo licencia GPL; pero no uso software cerrado en mis computadoras (en el móvil uso Android y hay partes que son propiedad de Google y más allá de AOSP, no es fácil acceder al código fuente).
El software del ecosistema BSD, con la que se licencia el software desarrollado en la Universidad de California en Berkeley, que uso, es lo más próximo al "dominio público" (una licencia de software libre permisiva), es abierto y gratuito; pero muchas licencias BSD no se reconocen como software libre por la FSF.
Los OS FreeBSD y NetBSD utilizan una licencia BSD simplificada (de sólo 2 clausulas!!).
Las licencias MIT, depende... por ejemplo, la licencia X11 (con la que el MIT licenció X Window System, que es el sistema gráfico que usan casi todos los OS del tipo UNIX, con la excepción de MacOS) se le permite formar parte de GPL; pero no se permite a ningún software que tenga licencia GPL, formar parte de la licencia MIT (quizá porque es una licencia de software libre permisiva).
Así como la ASF (Apache Software Foundation; de la que forman parte Facebook, entre otras corporaciones*), que ahora mismo, además del muy conocido y muy usado servidor HTTP Apache, ahora mantiene y desarrolla un montón de sofware abierto** entre el que está Apache OpenOffice.
CUPS (Common Unix Printing System), el código fuente de CUPS fue escrito en 1997 por Michael Sweet, sobre el protocolo IPP, aunque también admitía comandos de SMB (ahora CIFS) de Microsoft. En 1999 Apple compró el código fuente y contrató a Michael Sweet; pero mantiene CUPS con licencia GPL2.
Es decír, es software abierto, gratuito y libre. Aunque el código fuente de 1999 lo comprase Apple...
Samba; un software que comenzó siendo una "copia" libre del protocolo de archivos compartidos de Microsoft, hoy permite que computadoras que ejecutan casi cualquier OS (Windows, MacOS X Server, UNIX, Linux, BSD; se vean y actúen como servidores o clientes en redes montadas al estilo Microsoft.
Samba puede servir colas de impresión, directorios compartidos y autentificar con su propio archivo de usuarios (aunque hay diferencias dependiendo de que OS actúe como servidor, debido a las diferencias de los tipos de permisos de los OS "UNIX" y los de los OS de Microsoft.
Samba está ahora bajo licencia GPL. Por tanto, se considera software libre.
Por mencionar sólo algo de software del que se usa en casi todos los sistemas operativos (en su totalidad, dependiendo del "programa" o una parte del código).
* es.wikipedia.org/wiki/Apache_Software_Foundation
** es.wikipedia.org/wiki/Anexo:Proyectos_de_Apache_Software_Foundation
* Y en estas cláusulas de Servicio Público se escudan para justificar los fondos que reciben en forma de subvenciones y/o publicidad institucional; aunque las autoridades no las usen en toda la capacidad que podrían.
Lo de Tarragona, que menciona #15 es un ejemplo reciente de lo mal que se hacen las cosas en estos casos y de la suerte que tenemos (lo digo por los pocos fallecidos en un "accidente" que podría haber causado muchos más... otra cosa son los problemas derivados... y para medir eso hace falta un tiempo que aún no ha transcurrido).
El detonante fue un cabreo con Microsoft!!: "Microsoft retiró el apoyo a una institución académica del CERN en la cual, una vez finalizado el contrato actual, el CERN debería pagar el costo total en relación con el número de usuarios y en donde el cálculo mostró que el costo de comprar licencias en el nuevo escenario aumentará en más de 10 veces, razón por lo cual apostaron por MAlt".
MAIt: "Este movimiento por parte del CERN se deriva de una iniciativa por parte de la corporación de ahorrar gastos y apostar por el uso de software gratuito. Tal es el caso del cambio que realizaron en dejar de pagar licencias de uso a Microsoft y apostaron por MAlt (Microsoft Alternatives Project) un proyecto que está destinado a evitar el uso de productos de Microsoft a favor de soluciones alternativas basadas en software de código abierto".
Porque aunque mucha gente creía que en el CERN sólo usaban Scientific Linux, basado en RHEL o la más moderna CCentSO (CERN CentOS); y aunque es cierto que la supercomputadora que tienen allí, corre CCentSO y muchas otras comptadoras también la usan, también lo es que en sus oficinas tenían muchos escritorios Windows (y otros programas de Microsoft, como MSOffice...); demasiada confianza.
Y lo que les movió a dar el paso definitivo y ponerse a trabajar en serio, fue el coste de las licencias!! lo mismo que ahora lo que les ha movido a sustituir el Facebook Workplace ha sido el anuncio de Facebook de que en 2020 empezará a cobrar por el uso de este aplicación (entre 4 y 8 dólares por usuario y mes!!).
#18 "Mattermost se posiciona como una alternativa abierta al sistema de comunicación Slack y permite recibir y enviar mensajes, archivos e imágenes, rastrear el historial de conversaciones y recibir notificaciones en su teléfono inteligente o PC.
Los módulos de integración preparados para Slack son compatibles, y se proporciona una gran colección de módulos nativos para la integración con Jira, GitHub, IRC, XMPP, Hubot, Giphy, Jenkins, GitLab, Trac, BitBucket, Twitter, Redmine, SVN y RSS / Atom. El código del lado del servidor para el proyecto está escrito en Go y distribuido bajo la licencia MIT.
La plataforma Discourse proporciona un sistema de discusiones lineales que se ofrece para reemplazar listas de correo, foros web y chats.
Admite la separación de temas en función de las etiquetas, la actualización de la lista de mensajes en temas en tiempo real y la capacidad de suscribirse a secciones de interés y enviar respuestas por correo electrónico. El sistema está escrito en Ruby utilizando el marco de Ruby on Rails y la biblioteca Ember.js (los datos se almacenan en el DBMS PostgreSQL, el caché rápido se almacena en Redis)".
Mattermost: Los módulos de integración preparados para Slack son compatibles, y se proporciona una gran colección de módulos nativos para la integración con Jira, GitHub, IRC, XMPP, Hubot, Giphy, Jenkins, GitLab, Trac, BitBucket, Twitter, Redmine, SVN y RSS / Atom. El código del lado del servidor para el proyecto está escrito en Go y distribuido bajo la licencia MIT.
Me encanta que Discourse utilice DBMS PostgreSQL. Lástima que esté viejo para aprender Ruby on Rails... tengo un amigo que lo usa casi desde que salieron las primeras versiones. También fue un pionero en el uso de Python, allá por 1999.
Otras comunidades pueden tener (y seguro que tienen) los mismos problemas, quizá los gestionen mejor o peor y no se quejen y por eso tú no te enteras, pero pudiendo NO TENERLOS usando un software más moderno, fácil de gestionar, que dependa menos de terceros, etc...
Por lo general dichos chat avanzaus (que no son nada nuevo desde XMPP con Pidgin/Kopete, si acaso lo de guardar el historial remotamente, pero eso lo hacia el cliente de forma local) no me parecen innovadores, y son malos para gestionar cientos de hilos o ejercer una búsqueda eficiente.
Sobre "sentido", con SystemD todavía me estoy riendo. Bueno, la gente en producción no demasiado. Eso de joder NFS o machacar otros servicios es algo tan antológico y chapucero que no se había visto en la vida en 30 años de distros. Y mira que Yast era intrusivo de cojones, pero es que se reducía a SuSE y gracias.
Esa peste quiere expandirse por cojones si o sí, queriendo convertir un SO de servidores en un juguete.
Por no hablar del horroroso rendimiento de Gnome Shell vs Budgie, que también usa Mutter pero es cientos de veces más ligero, usable hasta en un Celeron.
Si eso va a ser el "referente", creo que seguiré con Slackware y Fluxbox hasta que la palme, y XFCE pal' que quiera un escritorio para personas no geeks.
AWK ia802309.us.archive.org/25/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Program
Sirve porque te enseña bastante de algoritmos de ordenado, de parseado y hasta de rendimiento.
A partir de ahí, entender otro lenguaje es coser y cantar.
En algunos scripts de shell he visto llamadas a awk.
Gracias por el enlace!! Creo que estoy un poco viejo para empezar con programación y tampoco es que tenga una base de matemáticas suficiente.
Pero le echaré un ojo, por lo menos a los ejemplos. Siempre viene bien para hacer guiones... para extraer datos y mostrarlos en aplicaciones como Conki.
pharo.org/download
mooc.pharo.org
Básico files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf
Intermedio files.pharo.org/books-pdfs/deep-into-pharo/2013-DeepIntoPharo-EN.pdf
Pero buscaré documentación de Pharo/Smalltek en español.
Muchas gracias por los enlaces
Puedes hacerte un wrapper muy guapo con xsel, trans y notify-send (o xmessage).
github.com/soimort/translate-shell
#!/bin/sh
MSG="$(xsel -o | trans -l es -e bing -b | fmt -60)"
gxmessage "$MSG" -geometry 600x400 -center -title "Traducción"
Necesitas gxmessage de los Slackbuilds.
Asocias ese script a un atajo de teclado, seleccionas el texto y pulsas ese atajo. Magia
¿Joder NFS? ¿machacar servicios? O tú no entiendes cómo funciona systemd, o no lo entendían los que causaron ese desaguisado, pero desde luego la culpa no es de systemd como tal.
Por cierto, expandirse si o si... tú compilas lo que quieres usar de systemd, nadie te impide usar otras tecnologías en según qué puntos. Luego está la parte de "es que systemd-boot, es que systemd-home, es que systemd-blablablá". Pero leches, esto permite tener un sistema donde tú puedas crear dinámicamente contenedores o incluso máquinas completas y migrar servicios y/o usuarios al vuelo de manera transparente. No suplanta nada, simplemente aporta soluciones a problemas complicados y desde luego los administradores de sistemas que no tienen la cabeza cuadrada al menos intentan entender qué cosas aporta y cómo usarlas.
Gnome vs Budgie... pues elige Budgie si te gusta más, para eso está la competencia y el poder elegir. ¿Por qué quejarse de gnome? estaría bien si fuera la única opción, si puedes elegir, en lugar de quejarte simplemente señala lo bueno que es Budgie. Te lo agradecerán mucho los creadores de Budgie y más aún los creadores de gnome, que estarán cansados de la misma cantinela una y otra vez por parte de los haters.
Hazlo. De eso se trata Linux, realmente nadie te ata a nada. Si no te gustan las distros prefabricadas, hazte la tuya (para eso existen las gentoo y compañía, y llevado al extremo, linux from scratch). Quien se queja es porque quiere.
Ah, no?
suckless.org/sucks/systemd/
bugzilla.kernel.org/buglist.cgi?bug_status=__open__&content=kernel
También podría aportar bugs bastante gordos de otros sistemas de inicio, pero no voy a entrar en esa guerra.
Por otro lado, muchos de los que apuntan en la página que enlazas, no están relacionados con systemd sino tangencialmente, pero como siempre, la culpa es de systemd.
¿Sabes también que muchos de esos bugs son causados por los mantenedores de las distros, que como cualquier persona humana a veces la pifian configurando cosas, usando funcionalidades aún verdes, etc? systemd es un conjunto de herramientas, se pueden usar bien o mal; es tentador ver una funcionalidad recién introducida que te ahorra un montón de trabajo y demás y no usarla. Por otro lado, así también se va puliendo todo el ecosistema y demás.
Por otro lado, la página enlaza esta otra que por otro lado, ignora completamente (quizá porque les rompe muchos argumentos a favor de sus tesis de que systemd es malo): wiki.debian.org/Debate/initsystem/systemd
Deberías leerla bien, porque se basa en argumentos investigados y debatidos ampliamente por mantenedores de debian, no son opiniones sino hechos comprobados:
A friend of mine mentioned to me in the pub that he had seem alarming reports of systemd security bugs.”
Most of these bugs have been found by the Red Hat Product security team conducting an audit of the code as part of its inclusion in their enterprise distribution. Therefore, systemd's security record cannot reasonably be compared with implementations that didn’t undergo similar audits.
It is unreasonable to expect any software project to be entirely bug-free. The interesting facts are that systemd’s architecture is designed in a secure way, that upstream developers know how to respond to security vulnerabilities, and that the code has actually been audited.
Less security bugs have been found in sysvinit or upstart, but this number is not necessarily correlated to the number of actual bugs, most of which might still be unknown. The comparison makes even less sense when
… » ver todo el comentario