Uso Institucional de Redes Sociales

Normas de uso y convivencia de Redes sociales y Web

Redes Sociales

unsplash-logo William Iven

Se permite el uso de Redes Sociales en la institución teniendo en cuenta estos aspectos:

  1. Existe un comité responsable de leer los términos y condiciones de cada servicio, informando sobre cada las novedades, y acerca de de beneficios, tanto para cada usuario como para la institución.
  2. La comunicación de este comité con la institución deberá ser permanente y estar abierta a las diferentes inquitudes de la comunidad.
  3. Existe además un comité técnico y pedagógico para asistir a los usuarios.
  4. Se entiende que cada persona tiene esferas privadas y públicas.
  5. Ninguna persona podrá ser obligada a compartir más allá de los estrictamente necesario para la comunidad. Por ejemplo, un alumno no podrá guardar bajo secreto los pormenores de un tratamiento médico.
  6. La compartición de imágenes y videos deberá ser consentida expresamente por los miembros de la comunidad involucradas.
  7. No se permitirá ninguna actividad que implique un trato deshumanizante.
  8. Si tenemos que decirle algo a otro miembro de la comunidad, tenemos que estar seguros de que podríamos hacerlo también personalmente.

¿Sabías qué?

Importante Saberlo

Photo by Markus Spiske

  • Vamos dejando rastros sobre lo que hacemos en la web, muchos sitios de internet están interconectados. Al hacer una operación sobre un sitio probablemente otros sitios de otras empresas y organizaciones registren esas actividades.
  • Nuestros datos son usados por terceros
  • Nuestros dispositivos hablan sobre nosotros, por ejemplo a qué hora encedemos un celular, qué enlaces hacemos clic, qué compramos, etc.
  • ¿Pueden crear un perfil sobre nuestros datos?
  • Sitios GMail y Twitter tienen un historial sobre tus accessos
  • Muchos servicios dicen ser gratuitos porque tus datos son el producto que tienen para ofrecer

Algunas recomendaciones

  • Apagar el GPS del dispositivo cuando no es estrictamente necesario.
  • Usar contraseñas fuertes. Una contraseña fuerte generalmente contiene al menos 8 caracteres, incluyendo letras (mayúsculas y minúsculas), números y otras caracteres.
  • Usar buscadores que no rastrean a los usuarios, por ejemplo DuckDuckGo.
  • Usar conexiones cifradas. La barra de direcciones debe indicarnos que la conexión es segura y que usa un certificado válido. De este modo los datos que vemos y/o ingresemos no podrán ser vistos por otras computadoras.
  • Usar navegadores libres. Esto implica que se puede acceder a la receta con la cual se hacen. Por ejemplo, Firefox es un navegador libre. Google Chrome es un navegador gratuito pero que no es libre.
  • Extensiones para navegadores. Hay varias extensiones que nos sirven para poder navegar con mayor privacidad, algunas de ellas son:

    • CanvasBlocker: Proporciona privacidad al navegador que estamos usando.
    • DuckDuckGo Privacy Essentials: Sirve para bloquear rastreadores y nos muestra el grado de privacidad que proporciona cada sitio visitado.
    • PrivacyBadger: Bloquea rastreadores.
    • Terms os Service; Didn't Read: Califica los términos y políticas de privacidad de los sitios con servicios, desde A (muy buenos) hasta E (muy malos)
    • TrackmeNot: Utiliza técnicas de ofuscación para evitar que construyan un perfil sobre nosotros.

unsplash-logo Glen Carrie

Enlaces de interés

El Open Source Bajo la Lupa

Hay un artículo1 escrito por Don Goodman-Wilson empleado de Github y miembro de Maintainerati. Ha sido sumamente inspirador por un lado y, ¿por qué no? pone en palabras cosas que uno viene elaborando hace rato.

unsplash-logo Tim Marshall

DGW lanza una ataque demoledor sobre la OSI (Iniciativa del Open Source) al afirmar que facilita la concentración en manos poderosos a expensas de la explotación de los desarrolladores y está muy lejos de propiciar la democratización que declama.

Se propone el autor del post reemplazar ideologías centradas en el código por gente-céntricas. En síntesis: si las elecciones que tomamos respetan a los seres humanos son correctas, de lo contrario no lo son. Y que la ideología del Open Source cosifica.

La crítica más contundente que hace sobre el código abierto es que explota trabajo no remunerado. Y ese modelo dice, es insostenible.

Cita algunos casos interesantes que contraponen esta supuesta neutralidad del software:

  • La licencia de JSON
  • La licencia de 996.ICU
  • La licencia hipocrática de Coraline Ada Emke

Algunos principios para iniciar algo nuevo

  • Los responsable de un proyecto de software merecen ser tratados como personas.
  • La tecnología existe para servir a las necesidades humanas.
  • Los valores del código abierto tienen que servir a la comunidad

El código fuente es un dogma al que no le interesan las personas.

Y se termina preguntando:

¿Cómo luce un modelo colaborativo centrado en las personas, de desarrollo de software abierto?

Quiero agregar como opinión personal que mi posición está muy alejada de "software libre" bueno, "open source" malo. No hay mucha distancia de lo que proponen los caprichos del stallmanismo. Según él, lo más importante es la libertad del software. El centro no son las personas. Pero bueno, eso da para otro post.

Cómo Hacer Túneles SSH

Una de las funcionalidades extraordinarias que posee openssh es la de encapsular el tráfico inseguro a puertos TCP. A continuación vemos algunos ejemplos útiles de cuándo y cómo utilizarlos.

Túneles

unsplash-logo Aaron Burden

Algunas suposiciones:

  • openssh-server.example.com: Es el host que posee el servicio ssh y el servicio sin cifrar
  • otrohost.example.com: Es un host que posee un servidor web sin TLS pero que carece de ssh.
  • 192.0.2.1/24: Es la dirección IP del cliente ssh.
  • filtrado.example.com: Es un host que tiene el puerto del servicio al que queremos acceder pero se encuentra filtrado para el exterior.
  • casa.example.com: Es un host remoto respecto a un servidor ssh accesible desde la red de filtrado.example.com. Este host está en un lugar en el cual podemos trabajar cómodamente 😊 por fuera de la infraestructura de filtrado.example.com.

Caso 1: Redireccionado remoto (Segurizar un servicio sin cifrar)

Queremos segurizar el acceso a un servidor web sin TLS.

ssh -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • 80: Es el puerto que tiene el servicio sin cifrar
  • localhost: Es la dirección en el host servicio-remoto.example.com que escucha en el puerto 80.
  • 10001: Es el puerto local al cual tendremos que conectarnos para obtener el servicio web.
  • -N No ejecuta comandos en el lado remoto.
  • -g Permite a otros hosts conectarse a nuestro puerto 10001.
  • -f El proceso va al segundo plazo antes de la ejecución de comandos.
  • -v Imprime información detallada.
  • El url que habrá que poner en el navegador es http://localhost:80.

Caso 2: Redireccionado remoto laxo (Segurizar un servicio sin cifrar)

Queremos permitir que otros hosts de la red puedan acceder nuestro servicio encapsulado.

ssh -g -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • -g Permite acceder a otros hosts de la red 192.0.2.0/24 acceder a el url http://192.0.2.1:10001/

Caso 3: Redireccionado remoto (Segurizar un servicio sin cifrar en otro host)

Queremos acceder de manera segura a un servicio sin TLS ni ssh.

ssh -N -f -v -L 10001:otrohost.example.com:80 openssh-server.example.com

  • Aquí la url será http://otrohost.example.com/10001

Caso 4: Acceder puertos filtrados

Queremos acceder a un puerto filtrado

ssh -v -N -f -R 9000:localhost:22 casa.example.com

  • 22 es el puerto al que queremos conectarnos desde casa.example.com al puerto 9000

Caso 5: Acceder a puertos filtrados y permitir acceso a otros hosts de la red

Queremos permitir que otros hosts de la red local de casa.example.com puedan acceder al servicio encapsulado

ssh -v -N -f -R 0.0.0.0:9000:localhost:22 casa.example.com

  • Luego para acceder al puerto ssh de filtrado.example.com podremos hacer por afuera de la red:
ssh -p 9000 casa.example.com
  • En este caso debe estar habilitado GatewayPorts en el archivo sshd_config

Borrar configuraciones de red

En Linux a veces nos podemos meter en un embrollo. Los sistemas para configurar y administrar la red son varios:

  • net-tools

  • iproute2

  • Archivos "legacy"

  • NetworkManager

  • systemd-networkd, etc

Cuando colisionan y necesitamos blanquear la configuraciones podemos hacer lo siguiente:

for i in $(ip -4 -o link |  cut -f2 -d ":"  | grep -v '^lo$')
        do
           ip addr flush dev  "$i"
           ip route flush dev  "$i"
           ip rule flush dev  "$i"
        done

Listo, a hacer la configuración en limpio ahora!

Obviamente no deberíamos hacer esto con una conexión remota a un equipo no virtualizado :)

Edición de Wikipedia o Wikiversidad

  1. Sí, puedo afirmar que la comunidad wikipedista es receptiva a nuevos usuarios y aportes. Mi primer aporte es de 2005 y en general la experiencia ha sido positiva.

  2. Si un docente decide poner a sus estudiantes a editar creo que en general tendrá un efecto positivo. Desde luego existe el riesgo de colisiones o que ciertos artículos puedan quedar de manera inconsistente. O tal vez con opiniones personales, cuestiones muy secundarias o carencia de referencias.

  3. Las dificultades anteriores podrían resolverse leyendo esta página:

  4. Ayuda:Contenidos - Wikipedia, la enciclopedia libre

Por supuesto es mucha documentación para leer, pero creo que los más importantes son:

El artículo que edite para esta actividad es :

Vim - Wikipedia, la enciclopedia libre

Cómo hacer un producto

Uno de los conceptos más importante que trajo el movimiento Open Source es que el software1, más que un producto es un proceso. Las nuevas tendencias en gestión de proyectos retoman ese concepto. Sí, aun cuando hablen paradójicamente que lo importante es el producto. En el antiguo concepto de tipo catedral, un producto solo podía estar terminado tras meses, años o décadas. En este momento no voy a ahondar esa idea en particular. Pero quiero aportar el siguiente diagrama para tanto para el arranque como para la consecusión de proyectos. Puede ser una aplicación, una documentación, una implementación, creo que es bastante abarcativa la idea. Describiré bremvemente cada fase del diagrama:

El proceso para hacer un producto

Fase Descripción
Base Tiene la terminología, conceptos, herramientas fundamentales para que tenga sentido el trabajo
Formato Tiene que tener una coherencia y una legibilidad o usabilidad básica para que pueda ser aprovechada por otros
Valor Agregado Aquí es cuando le agregamos al trabajo ese talento especial que todos tenemos que hace distinto el producto. Al terminar esta fase el producto se considera entregable. Sea para ser presentado ante un jefe o vendido a un cliente
Corrección de Errores Una vez que hemos obtenido feedback del resto del mundo, podemos corregir errores
Optimización En este punto volvemos a los pasos Base, Formato, y Valor Agregado. ¿Hasta cuándo? ¿Hasta que sea perfecto? Bueno, eso no existe. La idea es iterar todas las veces que el sentido y la alegría estén presentes

Conclusión

Si bien hay un momento en que el proceso da y debe dar como resultado un producto, es bueno tener definidas algunas fases. Una nota especial a los que padecen perfeccionismo. Es importante notar que hay dos frentes aquí. El primero es que justamente aquellos que están detrás de los resultados rápidos y atajos son muchas veces los que más hablan sobre lo perfecto que tienen que estar las cosas. El segundo frente es interno. El que siempre encuentra un obstáculo para pasar de la fase del Valor Agregado. Si bien el primer frente es incontrolable y no depende de nosotros ya que no es nuestro problema, el segundo es el que nos tiene que interesar, acallar esa vocecita que nunca quiere que obtengamos el producto. Justamente esa fase se llama Valor Agregado porque es lo que convierte tu trabajo en un producto en algo distinto. Es esa pieza que falta para que el mecanismo funcione correctamente.

Licencia de Creative Commons
Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

Sistemas de construcción de paquetes (Parte 4)

De acuerdo a los resultados, podría verse que autotools sigue siendo el “Build System” predominante. Otros paquetes todavía usan un makefile plano, tal vez merezcan un análisis aparte.

Limitaciones de estas estadísticas:

  1. Se confía en que siempre que se usa CMakeList.txt se usa cmake.
  2. Se confía en que siempre que existan los archivos  configure.ac o configure.in y Makefile.am o Makefile.in y se encuentra en el archivo spec el procedimiento ./configure && make se usan las autotools
  3. Hubo 1 (un) archivos que no pudieron ser inspeccionados por dtrx porque tenía la extensión incorrecta

Actualización 2019

Las dos cosas más notables son la reducción del uso de autotools y por otro lado la aparición de sistemas alternativos de construcción (casi un 70%).

Sistema de construcción de paquetes (Parte 3)