LinuxParty

Por muy importantes que hayan sido sus históricamente turbios negocios para su éxito, Microsoft no tuvo que hacer trampa para ganar", argumenta un nuevo artículo en el Register.

Las empresas Unix estaban haciendo un gran trabajo para suicidarse".Verá, si bien hubo muchos intentos de crear estándares de desarrollo de software para Unix, fueron demasiado generales para servir de mucho (por ejemplo, la Interfaz de sistema operativo portátil (POSIX)) o quedaron atrapados en las peleas de consorcios comerciales entre la Open Systems Foundation y Unix International, que se conoció como las guerras Unix.

Mientras las empresas Unix estaban ocupadas destrozándose unas a otras, Microsoft estuvo sonriendo durante todo el camino hasta el banco. El problema central era que las empresas Unix no podían conformarse con estándares de software. Los proveedores de software independientes (ISV) tuvieron que escribir aplicaciones para cada plataforma Unix. Cada uno de ellos tenía sólo una pequeña participación en el mercado de computadoras de escritorio.

Las primeras versiones de la variante gratuita / abierta Unix BSD venían con archivos de contraseña que incluían contraseñas hash para luminarias de Unix como Dennis Ritchie, Stephen R. Bourne, Eric Schmidt, Brian W. Kernighan y Stuart Feldman. Leah Neukirchen recuperó un árbol fuente de BSD versión 3 y reveló que pudo descifrar muchas de las contraseñas débiles utilizadas por el algoritmo de hash igualmente débil de aquellos días pasados .

Dennis MacAlistair Ritchie fue "dmac", Bourne's fue "bourne", Schmidt's fue "wendy !!!" (el nombre de su esposa), Feldman era "axlotl" y Kernighan era "/., /.,." Arthur Krewat descifró otras cuatro contraseñas: Ozalp Babaolu era "12ucdort", Howard Katseff era "graduado", "Tom London era" ..pnn521, "Bob Fabry era" 561cml .. "y Ken Thompson era" p / q2- q4! " (notación de ajedrez para un movimiento de apertura común). BSD 3 utilizó Descrypt para el hashing de contraseñas, que limitó las contraseñas a ocho caracteres, con 12 bits de entropía.

Recibo esta pregunta con bastante frecuencia, pero me cuesta explicarlo, especialmente con unas pocas palabras simples. De todos modos, este es un tema muy interesante porque las cosas son muy complicadas cuando se trata de UNIX vs Linux. Hay cosas relacionadas con los negocios, licencias, políticas, influencia del gobierno, etc.

Debido a que Unix es un sistema operativo y que Linux es un kernel, son de naturaleza diferente y tienen propósitos diferentes, no son fácilmente comparables. No puede resumir las diferencias y lo que son en una sola oración. Pero no te preocupes. Después de esta lección de historia y sus características y propósitos, obtendrás el "panorama general" y todo será agradable y claro. Puede saltar al final de la publicación, en la conclusión, si desea una lectura rápida.

Multix

Saltemos a finales de los sesenta. Las computadoras personales en ese momento fueron diseñadas para hacer tareas específicas individuales. Por ejemplo, había una computadora para calcular un salario mensual, o una computadora para procesar las palabras en una biblioteca, etc. Cada una de ellas estaba ejecutando un programa específicamente diseñado para ese hardware en particular y la tarea que debía realizar. Los programas que se escribieron para un proveedor de computadoras (o un fabricante como IBM o Apple) no se pueden ejecutar en una computadora desarrollada por un proveedor diferente. Esos equipos no pueden manejar la ejecución de varios programas a la vez, pero solo uno. Entonces, si un usuario quería escuchar algo de música mientras escribía un documento, eso era imposible.

fuser

Muestra que procesos están usando un: archivo, directorio, sockets, etc. Ver también lsof

fuser -v /home lista todos los procesos que utilizan el directorio /home

fuser -mv /mnt/xxx lista los procesos asociados al sistema de ficheros.

fuser -amk /mnt/xxx el proceso que se encuentre en ese sistema de archivos se elimina.

En UNIX y Linux por lo general, los servicios se configuran con varios archivos de texto, en el directorio /etc/. Un típico servidor podría tener docenas de archivos de configuración. Es importante que compruebe la validez del archivo de configuración. En algunos casos, es posible comprobar la cordura de los datos especiales o directorios (por ejemplo, /var/lib/cache/). Los archivos de texto son más fáciles de administrar de forma remota. Puede utilizar ssh y un editor de texto. Si hay un error en la configuración, el servidor no podrá comenzar. Esto puede resultar en un desastre. En este artículo voy a explicar como descubrir un error de sintaxis para los archivos de configuración más populares y prueba de los errores de sintaxis.

Ser un administrador de Unix o Linux tiende a ser un extraño tipo de trabajo: a menudo se pasan gran parte de su jornada de trabajo vagando (que no vagueando) por su cuenta, dedicando una gran cantidad de tiempo haciendo cosas aparentemente no específicas de sus tareas, marcadas por momentos de pánico donde tiene que hacer algo muy importante y de inmediato. Sandra Henry-Stocker, una veterana administradora de sistemas, ofrece 7 sugerencias sobre cómo estructurar su vida profesional si tiene este trabajo. Su consejo incluye el establecimiento de prioridades, a sabiendas de sus herramientas, y proporcionando explicaciones a los co-trabajadores a los que ayudan. "¿Qué hábitos has encontrado eficaces para los administración del sistema?

Para capturar la pantalla, generalmente bastará con pulsar la tecla [Impr Scr], eso está bien, cuando el servidor es local, pero ¿y si quieres imprimir en un servidor remoto? Será bueno que aprendas unos simples programas para imprimir la pantalla...

¿Por qué capturar pantallas, ventanas y cuadros de diálogo?

Odio admitirlo, una imagen vale más que mil palabras. Una documentación técnica más bien vale que incluya imágenes, conocidos genéricamente como capturas de pantalla, que muestran las ventanas y diálogos que aparecen en la aplicación que se está documentando. Incluyendo las imágenes en la documentación de los usuarios, hace más cómoda la documentación de la aplicación, ya que este tipo de imágenes muestran los menús, diálogos, y la interacción en el contexto general del programa, de modo que los usuarios pueden ver exactamente qué hacen y verán lo que una aplicación hace cuando están trabajando con él.

La captura de este tipo de imágenes no es sólo una tarea de escritura. La mayoría del material de marketing para aplicaciones gráficas incluye capturas de pantalla de una parte significativa de la interfaz de una aplicación, o de la aplicación en curso con un trabajo complejo, para resaltar la apariencia de las capacidades de una aplicación. Cualquier persona que haya presentado una denuncia contra el defecto de un software, sabe que una captura de pantalla es la que muestra realmente el problema, establece más credibilidad que una descripción escrita o verbal. Destacando un problema a través de una captura de pantalla, también aw hace más fácil para los desarrolladores centrarse en la fuente real del problema.

Muchas veces nos interesa automatizar la conexión SSH o la descarga (download) o envió (upload) de un fichero/s mediante SCP en un servidor remoto del cual no tenemos acceso directo y por tanto tenemos que indicar un login y contraseña en el momento de ejecutar la conexión.

En Unix tenemos muchas formas de automatizar estos scripts (como p.ej usando expect) pero para simplificar el uso de este proceso y que pueda ser probado también por usuarios desde Windows (que me imagino les interesara bastante), hoy voy a hablar de las utilidades PSCP y PLINK incluidas en la pagina de descarga de PUTTY.

Para ello conectate a la pagina de Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) y descargate los ficheros plink.exe y pscp.exe o en su defecto el paquete putty.zip (que ya lleva incluidas todas las utilidades).

plink.exe lo emplearemos para automatizar las conexiones ssh (ejecuciones de comandos), y pscp.exe para las conexiones scp (upload y descarga de ficheros).

Hoy hemos recibido una triste noticia, otro grande del mundo de la informática ha fallecido, Dennis Ritchie. Muchos medios de comunicación grandes y pequeños se están haciendo eco de la noticia, y es que Dennis Ritchie, era el padre de C, principal lenguaje de programación donde los haya, y con el que se hacen, si no todos, la mayoría de los Sistemas Operativos, y co-creador de Unix, el principal S.O. de cualquier Gran Sistema, allí donde la robustez sea necesaria, hay un Unix. (o un Linux).