Jump to content
FxForo | Tecnología, Juegos, Anime y mucho mas!

SouRCe

Avanzado
  • Content Count

    19
  • Joined

  • Last visited

  • Days Won

    15

SouRCe last won the day on June 8

SouRCe had the most liked content!

Community Reputation

981 Excellent

About SouRCe

  • Rank
    USUARIO
  • Birthday 09/26/1980

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. Impresionante. Gracias por compartir!
  4. 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/
  5. 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.
  6. 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
  7. Video instutucional de iPlan mostrando a Ringo, Su datacenter de categoria Tier III en Argentina. Saludos.
  8. 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
  9. 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 estan deacuerdo con lasdirectivas 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 alogarlo 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]
  10. 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.
  11. I386 se refiere a la edición de 32 bits y amd64 se refiere a la edición de 64 bits para procesadores Intel y AMD. Entrada i386 de Wikipedia: El Intel 80386, también conocido como el i386, o sólo 386, era un microprocesador de 32 bits introducido por Intel en 1985 ... Esto se denomina x86, IA-32 o la arquitectura i386, dependiendo del contexto. Entrada x86_64 de Wikipedia: X86-64 es una extensión del conjunto de instrucciones x86. Soporta espacios de direcciones virtuales y físicas mucho mayores que los que son posibles en x86, permitiendo así a los programadores trabajar convenientemente con conjuntos de datos mucho más grandes ... Después de lanzar la arquitectura bajo el nombre "x86-64", AMD cambió el nombre a AMD64 ... x86-64 sigue siendo utilizado por muchos en la industria como un término neutro de proveedor, mientras que otros, en particular Sun Microsystems (ahora Oracle Corporation) y Microsoft, utilizan x64. Incluso si tiene una CPU Intel, debe utilizar AMD64 para instalar 64 bits en su computadora (utiliza los mismos conjuntos de instrucciones). Se recomienda encarecidamente su uso. En su mayor parte, no notará una diferencia, pero para cargas de trabajo grandes (como la edición de vídeo, juegos, etc.), la computadora funcionará más rápido (la computadora tiene la capacidad de calcular 2 + 2 + 2 = 6 en lugar de tener que hacer 2 + 2 = 4 + 2 = 6 en un ejemplo). En el mundo Windows, un sistema operativo de 32 bits no le permitirá utilizar más de 3.5 Gigs de RAM en su computadora (incluso si tiene 8!). Tendrías que usar un sistema operativo de 64 bits para poder utilizar completamente toda la RAM. Para Linux, sin embargo, no hay tal límite. Independientemente, el mundo ha cambiado de 32 bits y es sólo esta allí para apoyar a las máquinas más antiguas que son incapaces de ejecutar 64 bits. Llegara el momento en que no existas mas software 32 bit, como ocurrió con los 8 y 16 bits respectivamente. Nota Original en Foros Ubuntu
  12. Si eres de las personas que encontraron en su ultimo recibo de tarjeta, unos cargos adicionales con descripcion bastante rara, diciendo Paypal *WESTERNBIDI - 402-935-7733, no te preocupes, no te han hackeado. Así es como aparece en su extracto bancario o transacciones con tarjeta de crédito cuando pagas por algo a través de Paypal, o algo se carga de otra forma a su cuenta de Paypal (por ejemplo, a través de una transacción automática o usando su tarjeta de débito Paypal, por ejemplo) Usted realmente no tiene suficiente en su cuenta de Paypal para cubrir el cargo. ¿Recuerdas cuándo, cuando te registraste en Paypal y tenías que proporcionar una cuenta bancaria o una tarjeta de crédito como método de facturación de reserva? Eso es lo que es ese cargo. Es Paypal usando su método de facturación de reserva para cubrir el déficit porque no tiene suficiente en su cuenta de Paypal. Estamos de acuerdo en que hacen un trabajo pobre de dejar eso claro (y para ser justos, puede estar fuera de sus manos en términos de cómo aparece en su declaración). Pero eso es lo que ese cargo con el número de teléfono 402-935-7733.
×
×
  • Create New...