EDICIóN GENERAL
183 meneos
865 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.

| etiquetas: cern , facebook workplace , mattermost , discourse
Por la parte de la negativa de continuar utilizando Facebook Workplace en el CERN es en primer plano debido a que se trata de un producto corporativo proporcionado por Facebook para organizar la comunicación interna entre los empleados dentro de la empresa y esto genera preocupaciones y dudas sobre la confidencialidad, la falta de control sobre sus datos y el deseo de no depender de las políticas de una empresa externa.

Sorpreson!
#1 Nunca es tarde. Pero a mí me deja un poco perplejo que instituciones públicas emitan comunicados en Facebook o lo usen como una herramienta de trabajo.
#1 Por eso siempre hay que usar software libre.

#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.
#4 La ventaja de las listas de correo es la organización. Los desarrollos de software muy gordacos como los BSD y Slackware en las Slackbuilds las promueven. O la cantidad de proyectos de la FSF. Todos van por ahí.
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.
#5 Las listas de correo tampoco son la panacea, al menos desde que tu proyecto crece lo suficiente y es abierto al exterior:

blog.gtk.org/2019/03/05/testing-discourse-for-gtk/
#21 A sí, el mismo formato de foro que Haiku: Meh. Sobre "panacea", todas las listas de correo tienen un archivado MARC o similar.

El volumen de datos manejado es bastante superior y el indexado es impepinable.

Además, hace trivial el participar desde donde sea.

marc.info/
#22 En tus propias redes es una solución estupenda, nunca lo he negado. Ahora, de puertas afuera...

"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…   » ver todo el comentario
#23 Bueno, Gnome/RedHat siempre han sido unos putos chapuceros incapaces de gestionar una mierda.

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.
#24 Supongo que nunca te has parado a evaluar sus decisiones desde un punto de vista técnico. Quizá algunas tengan más sentido de lo que crees. Pero claro, es más fácil insultar si no hacen lo que tú quieres que intentar comprender por qué hacen esta o esta otra cosa.

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...
#34 >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…   » ver todo el comentario
#35 Vale, no te parecen innovadores quizá porque no lo son, quizá porque no necesitan serlo, del mismo modo que cualquier otro software de oficina. Sobre si son malos para gestionar esto o lo otro... ¿los has usado?. Por otro lado, ¿te parece usable tener que navegar por listas de correo buscando una referencia o enlace a otra conversación u otro punto de la misma? ¿tener que estar pulsando siguiente para recargar el siguiente correo o tener que saltar o buscar entre varios para encontrar la…   » ver todo el comentario
#43 >¿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.

Ah, no?

suckless.org/sucks/systemd/
#44 Vale, lees una página que te dice qué creer y tú te lo crees a pies juntillas como algo cierto e imperecedero. Tiene o ha tenido y seguirá teniendo bugs, como todo software. Deberías levantar los brazos y salir corriendo gritando como un desesperado cuando veas la lista de bugs del kernel (¡algunos sin parchear desde 2014 o antes!):

bugzilla.kernel.org/buglist.cgi?bug_status=__open__&content=kernel

También…   » ver todo el comentario
#4 Si no auditas el software libre también caes en la posibilidad de que esté haciendo cosas por debajo, por muy libre que sea. Y un par de meses de comunicaciones internas del CERN (hasta que auditas completamente el software) pueden ser bastante jugosos.
#6 Sin duda. Pero con el software libre puedes hacerlo, con el privativo no. Y un par de meses no son nada comparado con los años que llevan con Facebook Workplace sin poder auditar.
#4 Sinceramente no entiendo cómo un gobierno pueda aceptar por simple comodidad el uso de un sistema operativo y aplicaciones privativas en la administración, a cualquier nivel.
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.
#4 ...que cualquier institución pública use software privativo... es cualquier software que no sabes qué hace por debajo.

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…   » ver todo el comentario
#2 Si estás usando whatsapp de una forma oficial o extraoficial (por tu cuenta) para temas laborales estás usando caralibro.
#2 O que haya cursos para empresas y particulares sobre cómo usar las redes sociales. Ya no son cursos de Internet, ahora de redes sociales, que al final es facebook, Instagram y twitter. Haciendo cursos para empresas privadas, como antes de hacía para las herramientas ofimáticas de Microsoft.
#2 Comunicados en Facebook o en Twitter. Ahora es la moda. Como ejemplo del absurdo, cuando petó la planta química esa de Tarragona las autoridades y los servicios de emergencia y Protección Civil alertaron a la población por Twitter xD tuiteando lo que había pasado y pidiendo a la gente que se mantuvieran en sus casas, etc.

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 xD

Surrealista.
#15 Es que las redes sociales en el tema de avisos a población tienen que ser complementarias, como los famosos avisos de emergencia vía SMS que nunca se han llegado a desarrollar en este país. No puedes obviar ninguna de las vías de comunicación con el ciudadano si quieres que todo funcione como debe en una situación así.
#25 Se exige a las operadoras de telefonía móvil (y a las cadenas de radio y televisión privadas*) que dejen espacio y presten servicios de emergencia tanto en datos como en voz, y después, ante una emergencia "meteorológica", la DGT sólo utiliza a la televisión y la radio pública (que tiene que estar sintonizada, en ese momento, claro), pero no los SMS (que mencionas) o cualquier otro protocolo de mensajes que podría usarse sobre las redes de telefonía y por supuesto sobre Internet!!…   » ver todo el comentario
#17 Servidor y clientes XMPP.
#19 Son listos, a la vez que "rácanos", un poco "vaguetes" y en mi opinión, demasiado confiados.

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

…   » ver todo el comentario
#37 Si quieres un lenguaje con una sintaxis simple y un IDE totalmente gráfico, Smalltalk. Pharo es la mejor implementación.

pharo.org/download

mooc.pharo.org
Y yo que pensé que eran listos los del CERN... de verdad que usaban cualquier mierda de facebook para comunicaciones?
Pues vaya MIERDA de grupos de seguridad, IT, etc que tiene el CERN!!!
#39 Y además de viejo y con poca base matemática, mi inglés tampoco e muy fluido.

Pero buscaré documentación de Pharo/Smalltek en español.

Muchas gracias por los enlaces :-)
#40 investiga translate-shell en los Slackbuilds.

Puedes hacerte un wrapper muy guapo con xsel, trans y notify-send (o xmessage).

github.com/soimort/translate-shell
#40 Un ejemplo:

#!/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 :-D
Algo como el Cern debería usar mejor listas de correo internas.
#3 En mi empresa utilizan mattermost y, muy bien, muy bonito... pero más que nada supone un dolor de cabeza.

Quizá porque se combina (a la vez, depende del proyecto y cliente) con MS Teams, Slack, Signal. Un verdadero dolor de cabeza.
#8 Es el problema de trabajar con otras empresas. Nosotros internamente usamos Slack, pero he tenido que usar Webex Teams, MS Teams o Skype según el cliente.
#14 Skype también :ffu: se me olvidaba
#3 La verdad es que no tiene sentido tanto reinvento de la rueda cuando el correo electrónico es perfectamente capaz para el 90% de las comunicaciones (me invento el porcentaje, pero vale).
#12 El cliente de correo es incapaz de cubrir las funcionalidades de la mensajería instantánea como pueda ser Slack o Teams. El mero hecho de poder compartir escritorio mientras estás en videoconferencia me parece hoy en día esencial si es que quieres disfrutar de teletrabajo. La utilidad de Workplace puede ser más cuestionable, pero al centralizar todos los anuncios corporativos en esa red consigues que tu correo no se llene con mil respuestas felicitando a un grupo por su nuevo éxito haciendo tal cosa. Ahora, de ahí a permitir que Facebook se meta en las entrañas de tu compañía, pues como que no lo veo por ningún lado
#3 Hay cosas que se tratan mejor en un chat que en una lista de correos, además de que las respuestas son más directas.

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…   » ver todo el comentario
Mira que desconfiar de Facebook... :-D
Yo he usado mattermost y está muy bien.
#26 No lo conozco, pero parece una colección de buen software (y moderno):

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.
#31 hombre, para mi ruby on rails y python son complejos para el entorno corporativo. Mattermost me gusta porque es go. Un lenguaje increíble.
#32 Tengo que leer un poco más acerca de "go". Pero no soy programador (no manejo ni medio bien el Shell...) y hay cosas que se me escapan demasiado. De todas formas me gusta leer sobre lo que estará ahí los próximos 10 o 20 años.
#33

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.
#36 awk "BEGIN { print "Hola Mundo " }" :-)

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.
habría sido recomendación de inglaterra...
comentarios cerrados

menéame