Portada
mis comunidades
otras secciones
#1:
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!
Sorpreson!
#4:
#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.
#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.
#15:
#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 
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
Surrealista.
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
Surrealista.
Comentarios
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:
https://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.
https://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 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."
#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 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.
#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 respuesta que buscas? ¿no te parece más cómodo simplemente hacer scroll hacia debajo o desplegar las respuestas con un simple click y sin tener que recargar toda la página? ¿por qué son malos para gestionar cientos de hilos si están todos bien organizados, etiquetados y tienen herramientas de búsqueda integrada? o igual es que yo no estoy gestionando los mismos correos de la misma forma que tú y tú no estás gestionando las conversaciones del mismo modo que yo...
¿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.
#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?
https://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!):
https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&content=kernel&no_redirect=1&order=Importance&query_format=specific
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): https://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 you take into account systemd’s larger scope. Most security bugs do not apply if you restrict systemd to the features already found in other init systems. More functionality means a larger attack surface, which is a drawback we usually accept when we need the features.
Using systemd helps mitigating or eliminating other security issues, by bringing new security features to all daemons running on the system. Switching to systemd is a security improvement for the whole system.
Y en especial:
The OpenRC statement has removed its systemd criticism, only keeping the vague “problems with Systemd have been debated a lot” statement. Since there is a lot of this criticism being spread by OpenRC or sysvinit advocates, it is still worth commenting on some incorrect, although widespread, beliefs.
There have been many comments on supposed lack of documentation on systemd’s internals or interfaces.
10% of the source code (14 kLoC) are comments.
Each component has its detailed manual page.
Many discussions are centered on systemd-logind as in being the only problem to address by other proposals, wildly proposing seemingly easy-to-develop replacements.
Logind is only a small fraction of systemd’s added value. It is important for desktop environments, but systemd is for all systems.
Reimplementing logind is not hard because of supposedly missing documentation. It is hard because without systemd, you are missing the necessary features to implement this service.
Systemd is often said to be too big for the functionality of an init system.
However it is much more than init, and if you take into account all the functionality it can provide or replace, you’ll soon find out that it takes less lines of code than the alternatives, in a language (C) that takes less memory to execute.
Linux is mostly a monolithic kernel and runs an enormous amount of code in ring 0. Having ~2% of this amount in the init system, most of which is run outside PID 1, does not sound like gigantism.
There is a lot of criticism about systemd’s upstreams and potential lack of quality in our relationship with them. However, this collaboration already exists and is of excellent quality.
Many are complaining about the absence of shell scripts, quoting ease of administration or embedded systems.
Shell scripts are not easy to maintain or debug; systemd unit files are. For the handful of services that still need scripts, it is possible to execute them before or in place of the daemon’s startup.
Systemd makes it easy to debug services, without the need to resort to a debugger or to hack on shell scripts.
Shell scripts should be entirely banned from embedded platforms, where they use memory and CPU for an interpreter irrelevant to the system’s purpose.
Overall, many of the arguments of those who don’t want to migrate away from sysvinit (with or without OpenRC) boil down to rumors or irrelevant political stances, while the decision to choose a default init system should be based on technical facts and the shape of the community.
#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 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).
* https://es.wikipedia.org/wiki/Apache_Software_Foundation
** https://es.wikipedia.org/wiki/Anexo:Proyectos_de_Apache_Software_Foundation
#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
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
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!!
* 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).
#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 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)".
#37 Si quieres un lenguaje con una sintaxis simple y un IDE totalmente gráfico, Smalltalk. Pharo es la mejor implementación.
https://pharo.org/download
https://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).
https://github.com/soimort/translate-shell
#c-40" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3247387/order/40">#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
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 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 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.
Mira que desconfiar de Facebook...
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 https://ia802309.us.archive.org/25/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf
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 "
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.
#37 Y se me olvidaba, dos libros para aprender:
Básico http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf
Intermedio http://files.pharo.org/books-pdfs/deep-into-pharo/2013-DeepIntoPharo-EN.pdf
habría sido recomendación de inglaterra...