SouRCe

Durante Muchos años te vendieron que TODAS las conversaciones de WhatsAPP eran encriptadas y que NADIE podía leer el contenido de tus chats con otra persona. Te mintieron, ok. Facebook si puede hacerlo, y ahora con la nueva Política que te obligan a aceptar, FACEBOOK puede usar tu información y las de tus contactos para administrar publicidad, ofrecerte productos y ganar mas dinero, Y si te niegas, bueno, te piden amablemente que borres tu cuenta!

El tiempo pasa incluso para nuestros Linux en versiones LTS. Así como ocurrió con los 12.04 que de solo mencionarlos parece que hablamos de historia de la informática y dinosaurios quienes lo teníamos instalado, hoy los 16.04 LTS llegaron a su EOL y todas las distribuciones que derivan de Ubuntu lo saben, como es el caso de Ubuntu Studio. Aqui esta el mensaje original desde Ubuntu Studio, donde piden actualizar a 18.04 a todos sus usuarios: Ubuntu Studio 16.04 LTS reaches End Of Life (EOL) As of today, April 25, 2019, Ubuntu Studio 16.04 LTS has reached the end of its support cycle. We strongly urge all users of 16.04 to upgrade to Ubuntu Studio 18.04 and add the Ubuntu Studio Backports PPA for support through April 2021. Our next LTS release, 20.04, is expected in April 2020. Ubuntu Studio 16.04 LTS will no longer receive community support from this point forward. Packages will continue to receive only security updates from Ubuntu until 2021. April 25, 2019 Ubuntu Studio 16.04 EOL

Un equipo de segunda mano usado puede estar en excelentes condiciones como tener un perro dentro y la tercera vez que se te cae el sistema no sabes a quien insultar primero. Un equipo refurbished te da la garantía de poder acceder a la tecnología que necesitas a un precio mas económico. Es una buena opción si encontramos lo que necesitamos a el precio correcto.

Impresionante. Gracias por compartir!

Apache y Nginx son los dos servidores web de código abierto más comunes en el mundo. Juntos, son los responsables de servir sobre el 50% del tráfico en internet. Ambas soluciones son capaces de manejas diversas cargas de trabajo y ser compatibles con otros softwares para dar lugar a una web stack completa. Nginx y Apache comparten muchas cualidades pero no deberías pensar en ellos como completamente intercambiables. Cada uno de ellos destaca en un área concreta y es importante que comprendas cuál es el que mejor se adapta a tus necesidades. En este artículo te mostraremos cuáles son esas áreas en las que cada uno de ellos destaca. Manejo de las conexiones y del tráfico Una de las mayores diferencias entre Apache y Nginx es la forma en la que ambos manejan las conexiones y el tráfico. Apache proporciona una variedad de módulos de multi-proceso (Apache los llama MPMs) que determinan cómo se manejan las peticiones de los clientes. Básicamente, esto permite a los administradores intercambiar su conexión con un manejo fácil de la arquitectura. Estos módulos son mpm_prefork, mpm_worker y mpm_event. Apache provee de una arquitectura flexible al dar la posibilidad de elegir diferentes conexiones y algoritmos que proporcionan respuestas. Las opciones que ofrece son principalmente una consecuencia de la evolución del servidor y la necesidad creciente de competitividad, ya que el panorama de internet ha cambiado. Nginx llegó a escena después que Apache, con más consciencia de los problemas de competitividad a los que tendrían que enfrentarse los sites a escala. Con esto en mente, Nginx fue diseñado desde la base para usar un algoritmo de manejo de conexiones que fuese asíncrónico, sin bloqueo y gestionado por eventos. Nginx genera trabajadores de procesos, cada uno de los cuales puede manejar miles de conexiones. Esto se consigue a través de la implementación de un mecanismo de bucle rápido que, de forma continua, comprueba y procesa eventos. La disociación entre lo que es trabajo real y las conexiones permite a cada trabajador involucrarse con una conexión sólo cuando se ha desencadenado un nuevo evento. Cada una de las conexiones manejadas por el trabajador se colocan en el bucle de eventos, donde existen junto a otras conexiones. Dentro del bucle los eventos se procesan asincrónicamente, permitiendo que el trabajo sea gestionado a través de un modo de no bloqueo. Cuando la conexión se cierra, se quita del bucle. Esta clase de proceso de conexiones permite a Nginx escalar de una forma increíble con recursos muy limitados. Como el servidor no es multi-proceso y los procesos no son generados para manejar cada nueva conexión, el uso de la memoria y el CPU tienden a mantenerse constantes. Contenido Estático vs Dinámico En términos de casos de uso real, una de las comparaciones más comunes entre Apache y Nginx es el modo en que cada servidor maneja peticiones para contenido estático y dinámico. Los servidores Apache pueden manejar contenido estático usando sus métodos convencionales basados en archivos. La ejecución de estas operaciones es principalmente una función de los métodos MPM arriba descritos. Nginx no interpreta archivos .htaccess ni provee de ningún mecanismo para la evaluar la configuración por directorio fuera del archivo de la configuración principal. Esto quizá sea menos flexible que el modelo Apache, pero también tiene sus propias ventajas. Una de esas ventajas es su relación con la seguridad. La distribución del acceso a la configuración a un nivel de directorio también distribuye la responsabilidad de la seguridad a los usuarios individuales, en los que quizá no se debería confiar para realizar esta tarea bien. Asegurándose de que el administrador mantiene el control sobre todo el servidor web, puede prevenir algunos fallos de seguridad que pueden ocurrir cuando se da acceso a terceras partes. Configuración Centralizada vs Distribuida Para los administradores, una de las diferencias más palpables entre ambos es si la configuración de los directorios se permite dentro de los propios directorios. Apache incluye una opción para permitir la configuración adicional sobre una base de directorio a través de inspeccionar e interpretar directivas en expedientes escondidos dentro del propio contenido de los directorios. Estos archivos son conocidos como .htaccess. Nginx no interpreta archivos .htaccess ni proporciona mecanismo alguno para la evaluación de la configuración por directorios fuera de la configuración principal de archivos. Puede que esto sea menos flexible que el modelo de Apache, pero también tiene sus ventajas. La mejoría más notable respecto al sistema .htaccess de la configuración a nivel de directorio es la actuación mejorada. Con un setup típico de Apache que pueda permitir .htaccess en cualquier directorio, el servidor comprobará estos archivos en cada uno de los archivos padre llegando hasta el archivo solicitado para cada petición. Si se encuentran uno o más archivos durante esta búsqueda, éstos deben ser leídos e interpretados. Como no permite la invalidación de ficheros, Nginx puede responder a las peticiones más rápido mediante una simple búsqueda y lectura de archivos para cada petición (asumiendo que el archivo se encuentre en la estructura convencional de directorio). Módulos Nginx y Apache son extensibles a través de sistemas de módulos, pero el modo en que trabajan difiere de forma significante. El sistema de módulos de Apache te permite cargar y descargar de forma dinámica módulos para satisfacer tus necesidades durante el tiempo en el que el servidor esté corriendo. El core de Apache siempre está activo, mientras que los módulos pueden estar encendidos o apagados, añadiendo o eliminando funcionalidad adicional y conectándose con el servidor principal. Nginx también implementa un sistema de módulos pero es bastante diferente del sistema de Apache. En Nginx los módulos no son dinámicamente descargables, por lo que deben ser seleccionados y compilados en el núcleo del software. Soporte, Compatibilidad, Ecosistema y Documentación Apache ha adquirido popularidad por un largo tiempo ya, por lo que su soporte se ha vuelto bastante ubicuo. Hay una larga biblioteca de documentación de sus creadores así como de terceros disponible para el servidor y para escenarios de tareas que impliquen conectar Apache con otros softwares. Nginx está experimentando un incremento en su soporte, ya que muchos usuarios lo acogen como su servidor base, pero aún tiene que actualizarse en algunas áreas importantes. Usando Apache y Nginx juntos Después de tratar los beneficios y limitaciones de Apache y Nginx, puede que tengas una mejor idea de qué servidor es el que más se adecua a tus necesidades. Sin embargo, muchos usuarios consideran que es posible medir los puntos fuertes de cada servidor a través de un uso conjunto de ambos. La configuración convencional para esta colaboración es situar Nginx enfrente de Apache como un proxy invertido. Esto permitirá a Nginx manejar todas las peticiones de los clientes. Esto se beneficia de la velocidad de procesamiento de Nginx y su habilidad para manejar un elevado número de conexiones de forma concurrente. Para el contenido estático, en lo que Nginx es excelente, los archivos se le proporcionarán al cliente de forma rápida y directa. En lo que respecta al contenido dinámico, por ejemplo archivos PHP, Nginx le pasará la petición a Apache, que podrá procesar los resultados y volver a la página solicitada. Entonces Nginx puede pasarle el contenido al cliente. Este setup funciona bien para mucha gente porque permite a Nginx funcionar como una máquina de clasificación. Se encargará de todas las peticiones que pueda y pasará aquéllas para las que no tiene la capacidad innata de resolver. Mediante la reducción de las peticiones que se le solicitan al servidor Apache, puedes aliviar algunos de los bloqueos que ocurren cuando un proceso de Apache está ocupado. Esta configuración también te permitirá prever mediante la adición de servidores de backend cuando sea necesario. Nginx puede ser configurado para pasar a un pool de servidores de forma fácil, incrementando la actuación y la resiliencia al fallo de la configuración. Conclusión Como puedes ver, tanto Apache como Nginx son poderosos, flexibles y capaces. Decidir qué servidor es el mejor para ti consiste en evaluar lo que necesitas y hacer pruebas para ver qué es lo que mejor se ajusta a tus necesidades. Fuente: https://clouding.io/blog/apache-nginx/

Tengo la version gratuita y me sirvio. Si eres un usuario final puedes pasarlo sin problemas. Si eres un usuario en una maquina corporativa llena de políticas y restricciones de la empresa, tienes que tener cuidado que ciertas políticas podrían ser eliminadas por error en el escaneo ya que la marca como potenciales problemas.

El sitio LiveCDList ha creado una compilacion de distribuciones linux Live que puedes descargar, y probar sin necesidad de ser instaladas. Si bien originalmente estaban creadas para ser grabadas en un CD o DVD, hoy son perfectamente utiles para cargarlas en una maquina virtual o porque no un Pendrive ya que mucho no se usan los CD´s. Aqui les dejo la lista de las primeras 10 opciones, si visitan el sitio encontraran mas de 100 opciones! Tails 1153 1153 [Secure Desktop] 2017-07 Kali Linux 1093 2934 [OS Installation] [Security] 2016-08 Arch Linux 742 742 [OS Installation] [Rescue] 2016-08 SystemRescueCD 83 466 [Rescue] [System Administration] 2016-07 Debian 417 1463 [Desktop] [OS Installation] [Rescue] 2016-04 Kubuntu 1450 1469 [Desktop] [OS Installation] 2016-04 Lubuntu 840 908 [Desktop] [OS Installation] 2016-04 OpenIndiana 1369 1643 [Desktop] [OS Installation] [Server] 2016-04 Ubuntu 1417 1434 [Desktop] [OS Installation] 2016-04 Ubuntu GNOME 1208 1240 [Desktop] 2016-04

Microsoft, servidores Bajo el mar!

Video instutucional de iPlan mostrando a Ringo, Su datacenter de categoria Tier III en Argentina. Saludos.

REPOSITORIOS PARA DEBIAN 9 | stretch Siendo root, y usando editor nano: #nano /etc/apt/sources.list # Debian9 deb http://ftp.us.debian.org/debian/ stretch main contrib non-free deb-src http://ftp.us.debian.org/debian/ stretch main contrib non-free # Debian9 - Seguridad deb http://security.debian.org/debian-security stretch/updates main contrib non-free deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free # Debian9 - Multimedia deb http://www.deb-multimedia.org stretch main non-free

Debian clasifica sus paquetes dependiendo del grado de libertad y que tan compatible son con la licencia GPL y sus directiva Debian , aquí va la explicación de cada directorio. main En este directorio se encuentran los paquetes 100% libres, esto quiere decir que cumplen o están de acuerdo con las directivas de Debian, en donde marcan cuando un paquete se le puede considerar que es 100% software libre. Non-free Aquí se encuentran paquetes que no pueden considerarse software libre según las directivas de Debian, por dar un ejemplo, hay software que puede ser distribuido e instalado, pero no se tiene acceso a su código fuente (No todos de esta sección son así hay software que si se proporciona su código fuente), simplemente por la licencia que trae el software de este paquete no cuadra con las directivas de Debian, debido a eso se decide alojarlo en esta sección. Contrib En este directorio se pueden encontrar software libre, pero depende de alguna forma de un paquete que no es 100% libre [https://www.debian.org/doc/manuals/debian-reference/ch02.es.html#s-ftparchives]

Maybe your client if not fully original and any small change in 1 file can do an inimaginable error. Here in mobzone, a bad file in the client, make disapear al GK in the server.