viernes, 28 de noviembre de 2014

Sistemas Operativos de Redes

Sistemas operativos de red instalables/incorporados

Dependiendo del fabricante del sistema operativo de red, tenemos que el software de red para un equipo personal se puede añadir al propio sistema operativo del equipo o venir integrado con él.
NetWare de Novell fue un ejemplo, de amplia difusión, de sistema operativo de red donde el software que le permitía trabajar en red se debía instalar en el cliente sobre el sistema operativo del equipo. El equipo personal necesitaba ambos sistema operativos para gestionar conjuntamente las funciones de red y las individuales.
El software del sistema operativo de red se integra en un número importante de sistemas operativos, incluyendo: casi todas las distribuciones de Linux; los sistemas operativos de Microsoft y Apple para portátiles, servidores y equipos de sobremesa;, sistemas operativos de dispositivos móviles, como Android, IOS, Windows Phone, etc.

Características

Las características genéricas de un sistema operativo de red son:
  • Conecta todos los equipos y recursos de la red.
  • Gestión de usuarios centralizada.
  • Proporciona seguridad, controlando el acceso a los datos y recursos. Debe validar los accesos (claves, certificados, sistemas biométricos, etc.) y ver aplicar las políticas de seguridad.
  • Coordina las funciones de red, incluso con las propias del equipo.
  • Comparte recursos (lleva a cabo la coordinación y los privilegios a la hora de compartir). Por tanto, mejora notablemente la utilización de los recursos.
  • Permite monitorizar y gestionar la red y sus componentes.

Entorno de los sistemas operativos en red

  • Servidores: Son equipos con sistemas operativos en red que proporcionan recursos a los clientes, haciéndolos accesibles a los equipos de la red, sea a otros servidores o, habitualmente, a clientes.
  • Clientes: Son equipos con un sistema operativo monopuesto conectados para empezar a trabajar en red. A diferencia de los servidores, no comparten sus recursos.
  • Dominios: Es una agrupación lógica de equipos, que permite realizar una gestión centralizada, es decir, desde una ubicación se controla los servicios administrativos del dominio. Los recursos los gestiona el servidor principal. Uno de los protocolos habituales para la formación de dominios es LDAP.
Dependiendo del sistema operativo, se puede dar el caso que en un determinado dominio un equipo sea servidor de ciertos recursos y cliente de otros.

Software Libre

Historia

Richard Matthew Stallman, creador del concepto de software libre y fundador de la Free Software Foundation.
 
Entre los años 1960 y 1970, el software no era considerado un producto sino un añadido que los vendedores de las grandes computadoras de la época (las mainframes) aportaban a sus clientes para que éstos pudieran usarlos. En dicha cultura, era común que los programadores y desarrolladores de software compartieran libremente sus programas unos con otros. Este comportamiento era particularmente habitual en algunos de los mayores grupos de usuarios de la época, como DECUS (grupo de usuarios de computadoras DEC). A finales de la década de 1970, las compañías iniciaron el hábito de imponer restricciones a los usuarios, con el uso de acuerdos de licencia.
En 1971, cuando la informática todavía no había sufrido su gran boom, las personas que hacían uso de ella, en ámbitos universitarios y empresariales, creaban y compartían el software sin ningún tipo de restricciones.
Con la llegada de los años 1980 la situación empezó a cambiar. Las computadoras más modernas comenzaban a utilizar sistemas operativos privativos, forzando a los usuarios a aceptar condiciones restrictivas que impedían realizar modificaciones a dicho software.
En caso de que algún usuario o programador encontrase algún error en la aplicación, lo único que podía hacer era darlo a conocer a la empresa desarrolladora para que ésta lo solucionara. Aunque el programador estuviese capacitado para solucionar el problema y lo desease hacer sin pedir nada a cambio, el contrato le impedía que modificase el software.
El mismo Richard Matthew Stallman cuenta que por aquellos años, en el laboratorio donde trabajaba, habían recibido una impresora donada por una empresa externa. El dispositivo, que era utilizado en red por todos los trabajadores, parecía no funcionar a la perfección, dado que cada cierto tiempo el papel se atascaba. Como agravante, no se generaba ningún aviso que se enviase por red e informase a los usuarios de la situación.
La pérdida de tiempo era constante, ya que en ocasiones, los trabajadores enviaban por red sus trabajos a imprimir y al ir a buscarlos se encontraban la impresora atascada y una cola enorme de trabajos pendientes. Richard Stallman decidió arreglar el problema, e implementar el envío de un aviso por red cuando la impresora se bloqueara. Para ello necesitaba tener acceso al código fuente de los controladores de la impresora. Pidió a la empresa propietaria de la impresora lo que necesitaba, comentando, sin pedir nada a cambio, qué era lo que pretendía realizar. La empresa se negó a entregarle el código fuente. En ese preciso instante, Stallman se vio en una encrucijada: debía elegir entre aceptar el nuevo software propietario firmando acuerdos de no revelación y acabar desarrollando más software propietario con licencias restrictivas, que a su vez deberían ser más adelante aceptadas por sus propios colegas.
Con este antecedente, en 1984, Richard Stallman comenzó a trabajar en el proyecto GNU, y un año más tarde fundó la Free Software Foundation (FSF). Stallman introdujo la definición de software libre y el concepto de "copyleft", que desarrolló para otorgar libertad a los usuarios y para restringir las posibilidades de apropiación del software.

Libertades del software libre

De acuerdo con tal definición, un software es "libre" cuando garantiza las siguientes libertades:[3]
LibertadDescripción
0la libertad de usar el programa, con cualquier propósito.
1la libertad de estudiar cómo funciona el programa y modificarlo, adaptándolo a tus necesidades.
2la libertad de distribuir copias del programa, con lo cual puedes ayudar a tu prójimo.
3la libertad de mejorar el programa y hacer públicas esas mejoras a los demás, de modo que toda la comunidad se beneficie.
Las libertades 1 y 3 requieren acceso al código fuente porque estudiar y modificar software sin su código fuente es muy poco viable.
Ciertos teóricos usan este cuarto punto (libertad 3) para justificar parcialmente las limitaciones impuestas por la licencia GNU GPL frente a otras licencias de software libre (ver Licencias GPL). Sin embargo el sentido original es más libre, abierto y menos restrictivo que el que le otorga la propia situación de incompatibilidad, que podría ser resuelta en la próxima versión 3.0 de la licencia GNU GPL, que causa en estos momentos graves perjuicios a la comunidad de programadores de software libre, ya que muchas veces no se puede reutilizar o mezclar códigos de dos licencias distintas, pese a que las libertades teóricamente lo deberían permitir.
Tanto la Open Source Initiative[4] como la Free Software Foundation,[5] mantienen en sus webs oficiales, listados de las licencias de software libre que aprueban.
El término software no libre se emplea para referirse al software distribuido bajo una licencia de software más restrictiva que no garantiza estas cuatro libertades. Las leyes de la propiedad intelectual reservan la mayoría de los derechos de modificación, duplicación, y redistribución, para el dueño del copyright; el software dispuesto bajo una licencia de software libre rescinde específicamente la mayoría de estos derechos reservados.
La definición de software libre no contempla la cuestión del precio; un eslogan frecuentemente usado es "libre como en libertad, no como en cerveza gratis" o en inglés "Free as in freedom, not as in free beer" (aludiendo a la ambigüedad del término inglés "free"), y es habitual ver a la venta CD de software libre como distribuciones Linux. Sin embargo, en esta situación, el comprador del CD tiene el derecho de copiarlo y redistribuirlo. El software gratis puede incluir restricciones que no se adaptan a la definición de software libre —por ejemplo, puede no incluir el código fuente, puede prohibir explícitamente a los distribuidores recibir una compensación a cambio, etc—.
Para evitar la confusión, algunas personas utilizan los términos "libre" (software libre) y "gratis" (software gratis) para evitar la ambigüedad de la palabra inglesa "free". Sin embargo, estos términos alternativos son usados únicamente dentro del movimiento del software libre, aunque están extendiéndose lentamente hacia el resto del mundo. Otros defienden el uso del término open source software (software de código abierto). La principal diferencia entre los términos "open source" y "free software" es que éste último tiene en cuenta los aspectos éticos y filosóficos de la libertad, mientras que el "open source" se basa únicamente en los aspectos técnicos.
En un intento por unir los mencionados términos que se refieren a conceptos semejantes, se está extendiendo el uso de la palabra "FLOSS" con el significado de free/libre and open source software e, indirectamente, también a la comunidad que lo produce y apoya.

Formatos abiertos

Los formatos abiertos permiten al software libre mantener sus cuatro libertades y la libre difusión de todo el código y formatos utilizados, su distribución y estudio, debido a esto, los creadores de software libre desarrollan a la vez de programas libres, formatos libres para estos programas o utilizan formatos libres ya creados anteriormente.
Los formatos libres permiten a los usuarios poder trabajar con programas libres aunque al ser libres pueden ser implementados y utilizados cualquier programa sea cerrado o no. Algunas compañías, como Microsoft, suelen no utilizar formatos libres en sus programas, no por impedimento si no por falta de voluntad de implementar formatos abiertos en sus programas, aún así los usuarios pueden instalar software libre en sus sistemas para trabajar con estos formatos.

Tipos de licencia

Una licencia es aquella autorización formal con carácter contractual que un autor de un software da a un interesado para ejercer "actos de explotación legales". Pueden existir tantas licencias como acuerdos concretos se den entre el autor y el licenciatario. Desde el punto de vista del software libre, existen distintas variantes del concepto o grupos de licencias:

Licencias GPL

Una de las más utilizadas es la Licencia Pública General de GNU (GNU GPL). El autor conserva los derechos de autor (copyright), y permite la redistribución y modificación bajo términos diseñados para asegurarse de que todas las versiones modificadas del software permanecen bajo los términos más restrictivos de la propia GNU GPL. Esto hace que sea imposible crear un producto con partes no licenciadas GPL: el conjunto tiene que ser GPL.
Es decir, la licencia GNU GPL posibilita la modificación y redistribución del software, pero únicamente bajo esa misma licencia. Y añade que si se reutiliza en un mismo programa código "A" licenciado bajo licencia GNU GPL y código "B" licenciado bajo otro tipo de licencia libre, el código final "C", independientemente de la cantidad y calidad de cada uno de los códigos "A" y "B", debe estar bajo la licencia GNU GPL.
En la práctica esto hace que las licencias de software libre se dividan en dos grandes grupos, aquellas que pueden ser mezcladas con código licenciado bajo GNU GPL (y que inevitablemente desaparecerán en el proceso, al ser el código resultante licenciado bajo GNU GPL) y las que no lo permiten al incluir mayores u otros requisitos que no contemplan ni admiten la GNU GPL y que por lo tanto no pueden ser enlazadas ni mezcladas con código gobernado por la licencia GNU GPL.
En el sitio web oficial de GNU hay una lista de licencias que cumplen las condiciones impuestas por la GNU GPL y otras que no.
Aproximadamente el 60% del software licenciado como software libre emplea una licencia GPL o de manejo.

Licencias AGPL

La Licencia Pública General de Affero (en inglés Affero General Public License, también Affero GPL o AGPL) es una licencia copyleft derivada de la Licencia Pública General de GNU diseñada específicamente para asegurar la cooperación con la comunidad en el caso de software que corra en servidores de red.
La Affero GPL es íntegramente una GNU GPL con una cláusula nueva que añade la obligación de distribuir el software si éste se ejecuta para ofrecer servicios a través de una red de ordenadores.
La Free Software Foundation recomienda que el uso de la GNU AGPLv3 sea considerado para cualquier software que usualmente corra sobre una red.

Licencias estilo BSD

Llamadas así porque se utilizan en gran cantidad de software distribuido junto a los sistemas operativos BSD. El autor, bajo tales licencias, mantiene la protección de copyright únicamente para la renuncia de garantía y para requerir la adecuada atribución de la autoría en trabajos derivados, pero permite la libre redistribución y modificación, incluso si dichos trabajos tienen propietario. Son muy permisivas, tanto que son fácilmente absorbidas al ser mezcladas con la licencia GNU GPL con quienes son compatibles. Puede argumentarse que esta licencia asegura “verdadero” software libre, en el sentido que el usuario tiene libertad ilimitada con respecto al software, y que puede decidir incluso redistribuirlo como no libre. Otras opiniones están orientadas a destacar que este tipo de licencia no contribuye al desarrollo de más software libre (normalmente utilizando la siguiente analogía: "una licencia BSD es más libre que una GPL si y sólo si se opina también que un país que permita la esclavitud es más libre que otro que no la permite").

Licencias estilo MPL y derivadas

Esta licencia es de Software Libre y tiene un gran valor porque fue el instrumento que empleó Netscape Communications Corp. para liberar su Netscape Communicator 4.0 y empezar ese proyecto tan importante para el mundo del Software Libre: Mozilla. Se utilizan en gran cantidad de productos de software libre de uso cotidiano en todo tipo de sistemas operativos. La MPL es Software Libre y promueve eficazmente la colaboración evitando el efecto "viral" de la GPL (si usas código licenciado GPL, tu desarrollo final tiene que estar licenciado GPL). Desde un punto de vista del desarrollador la GPL presenta un inconveniente en este punto, y lamentablemente mucha gente se cierra en banda ante el uso de dicho código. No obstante la MPL no es tan excesivamente permisiva como las licencias tipo BSD. Estas licencias son denominadas de copyleft débil. La NPL (luego la MPL) fue la primera licencia nueva después de muchos años, que se encargaba de algunos puntos que no fueron tomados en cuenta por las licencias BSD y GNU. En el espectro de las licencias de software libre se la puede considerar adyacente a la licencia estilo BSD, pero perfeccionada.

Copyleft

Símbolo del copyleft
Hay que hacer constar que el titular de los derechos de autor (copyright) de un software bajo licencia copyleft puede también realizar una versión modificada bajo su copyright original, y venderla bajo cualquier licencia que desee, además de distribuir la versión original como software libre. Esta técnica ha sido usada como un modelo de negocio por una serie de empresas que realizan software libre (por ejemplo MySQL); esta práctica no restringe ninguno de los derechos otorgados a los usuarios de la versión copyleft.
En España, toda obra derivada está tan protegida como una original, siempre que la obra derivada parta de una autorización contractual con el autor. En el caso genérico de que el autor retire las licencias "copyleft", no afectaría de ningún modo a los productos derivados anteriores a esa retirada, ya que no tiene efecto retroactivo. En términos legales, el autor no tiene derecho a retirar el permiso de una licencia en vigencia. Si así sucediera, el conflicto entre las partes se resolvería en un pleito convencional.

Comparación con el software de código abierto

Aunque en la práctica el software de código abierto y el software libre comparten muchas de sus licencias, la Free Software Foundation opina que el movimiento del software de código abierto es filosóficamente diferente del movimiento del software libre.[8] Apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric S. Raymond y Bruce Perens, que formaron la Open Source Initiative (OSI). Ellos buscaban darle mayor relevancia a los beneficios prácticos del compartir el código fuente, e interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto. Por otro lado, la Free Software Foundation y Richard Stallman prefieren plantear el asunto en términos éticos empleando el término "software libre".
Los defensores del término "código abierto", en inglés open source, afirman que éste evita la ambigüedad del término en ese idioma que es free en free software. El término "código abierto" fue acuñado por Christine Peterson del think tank Foresight Institute, y se registró para actuar como marca registrada el término en inglés para los productos de software libre.
Mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando los desarrolladores pueden usar, modificar y redistribuir el código fuente de un programa. (Véase también La Catedral y el Bazar). El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario de su estándar ético. El movimiento de código abierto ve la excelencia técnica como el objetivo prioritario, siendo la compartición del código fuente un medio para dicho fin. Por dicho motivo, la FSF se distancia tanto del movimiento de código abierto como del término "Código Abierto" (en inglés Open Source).
Puesto que la OSI sólo aprueba las licencias que se ajustan a la Open Source Definition (definición de código abierto), la mayoría de la gente lo interpreta como un esquema de distribución, e intercambia libremente "código abierto" con "software libre". Aún cuando existen importantes diferencias filosóficas entre ambos términos, especialmente en términos de las motivaciones para el desarrollo y el uso de tal software, raramente suelen tener impacto en el proceso de colaboración.
Aunque el término "código abierto" elimina la ambigüedad de libertad frente a precio (en el caso del inglés), introduce una nueva: entre los programas que se ajustan a la definición de código abierto, que dan a los usuarios la libertad de mejorarlos, y los programas que simplemente tiene el código fuente disponible, posiblemente con fuertes restricciones sobre el uso de dicho código fuente. Mucha gente cree que cualquier software que tenga el código fuente disponible es de código abierto, puesto que lo pueden manipular (un ejemplo de este tipo de software sería el popular paquete de software gratuito Graphviz, inicialmente no libre pero que incluía el código fuente, aunque luego AT&T le cambió la licencia). Sin embargo, mucho de este software no da a sus usuarios la libertad de distribuir sus modificaciones, restringe el uso comercial, o en general restringe los derechos de los usuarios.

Seguridad y Protección de los Sistemas Operativos

La función principal de un Sistema Operativo (SO) es la de tomar todos los recursos físicos de un sistema de computo y brindarlos de manera virtual, esto es logrado por medio de una abstracción del hardware (HW). En la actualidad no es suficiente con permitir el manejo y uso del HW si no se maneja seguridad y protección . 
 Es importante en definir claramente las diferencias entre estos dos conceptos
  • La seguridad : es la ausencia de un riesgo. Aplicando esta definición a al tema correspondiente, se hace referencia al riesgo de accesos no autorizados, de manipulación de información, manipulación de las configuraciones, entre otros
  • La protección : son los diferentes mecanismo utilizados por el SO para cuidar la información, los procesos, los usuarios, etc
Después de tener claro que quiere decir cada tema surgen numerosas ideas en nuestras mentes, ya que la seguridad es algo que manejamos en todos los aspectos de nuestras vidas, y por experiencia se sabe que no depende de un solo actor ( persona, computador , … ) si no que esta fuertemente ligada con todo lo que lo rodea, por esto la seguridad no solo es manejada por el sistema operativo si no que es necesario un refuerzo como otro software que comúnmente denominamos “antivirus”. Un SO como administrador de los recursos cumple funciones muy importantes en la instrumentación de la seguridad pero no engloba todos los aspectos de esta, la cual se fortalece según las necesidades y los usos ( es decir que según la necesidades y enfoques que dan los usuarios a los equipos estos cuentan con diferentes tipos de seguridad ). En la actualidad los conceptos e ideas tenidos sobre la seguridad han ido cambiando mucho, esto por que se entro a un era donde es posible los accesos remotos a los equipos, donde se busca que todo proceso sea mas fácil de realizar ( y sabemos que la seguridad es inversamente proporcional a la facilidad de uso ).

 


 
Un sistema de seguridad debe cumplir con unos requisitos:
  • Confidencialidad: Acceso solo a usuarios autorizados
  • Integridad: Modificación solo por usuarios autorizados
  • Disponibilidad:  Recursos solamente disponibles para usuario autorizado
 La seguridad se clasifica en:
  • Externa:  protección contra desastres y contra intrusos
  • Operacional: básicamente nos determina que acceso se permite a quien
 Una de las obligaciones de un sistema seguro es permanecer en constante vigilancia, verificando y validando las posibles amenazas, esto lo hacen con uso de contraseñas, controles de acceso
 Se plantea que es mas fácil haces un sistema seguro si esto se ha incorporado desde los inicios del diseño, por que no se puede hablar de un SO seguro si su núcleo no lo es; de igual manera es posible hacer seguridad por hardware donde se obtiene como ventaja la velocidad de operación permitiendo controles mas frecuentes y mejora el performance
 Con respecto a los SO mas seguros es difícil listarlos ya que todos tienen sus seguidores y contractares los cuales por instinto suelen defender lo que usan, pero es sin duda alguna lo que responden las encuestas hay una delas distribuciones de Linux denominada openBSD que es conocido como el SO mas seguro a parte de que no deja de ser software libre, de igual manera es situado a a los SO de Windows encima del Mac OSX donde apenas la ultima versión empieza a aplicar completamente  algoritmos de seguridad que desde antes eran utilizados por la competencia pero sin duda alguna los sistemas libres ganan la batalla con respecto a la seguridad
Para poder garantizar la seguridad es fundamental proteger nuestro sistema, por eso básicamente los mecanismo articulados para la protección son los que nos llevan a un sistema seguro; existen diferentes formas de realizar la protección tal vez la mas común y mas básica sea definir cuales son los archivos u objetos a proteger para que posteriormente se delimite que usuarios pueden acceder a que información
 Como objetivos de la protección esta:
  • Controlar el acceso a los recursos
  • Utilizabiliad por diferentes usuarios
 Generalmente surgen dudas sobre que es lo que debemos proteger o que debo cuidar mas y la respuesta es siempre variable según el tipo de necesidades de cada usuario, pero generalmente los mas afectados son la CPU, la memoria, terminales, procesos, ficheros y las bases de datos
Un sistema de protección deberá tener la flexibilidad suficiente para poder imponer una diversidad de políticas y mecanismos.
 La protección se refiere a los mecanismos para controlar el acceso de programas, procesos, o usuarios a los recursos definidos por un sistema de computación. Seguridad es la serie de problemas relativos a asegurar la integridad del sistema y sus datos.
 Pero contra que nos debemos proteger:
  • Adware
  • Backdoor
  • Badware alcalinos
  • Bomba fork
  • Bots
  • Bug
  • Toryano
  • Cookies
  • Crackers
  • Cryptovirus
 Esos entre muchos otros software que desde sus diferentes especialidades atacan nuestro sistema, pero recordamos que no solo se trata de protección de software si no que también se incluye la protección contra los usuarios
 La protección es algo que inicia desde el SO y que termina con las practicas que nosotros como usuarios realizamos, por ejemplo los correos que se revisan el antivirus que se instala
La violación más famosa de todos los tiempos ocurrió en 1988 cuando un  estudiante lanzó un gusano por la Internet que botó miles de máquinas en cosa de horas. El gusano tomaba el control de una máquina intentando diversos mecanismos. Uno de ellos era un bugo en el programa finge  Una vez obtenido el control, trataba de descubrir las claves de los usuarios de esa máquina intentando palabras comunes. Si descubría una, entonces tenía acceso a todas las máquinas en que ese usuario tuviera cuenta. El gusano no hacía ninguna acción  dañina en sí, pero usaba tantos recursos de las máquinas infectadas que las botaba.

POSIX

¿Qué es?
 
POSIX es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identidad de la API(es la abreviatura de Aplication Programming Interface. Un API no es más que una serie de servicios o funciones que el Sistema Operativo ofrece al programador, como por ejemplo, imprimir un carácter en pantalla, leer el teclado, escribir en un fichero de disco, etc.).

El POSIX Se trata de un estándar que intenta asegurar la portabilidad entre diferentes sistemas operativos. Dentro del estándar se especifica el comportamiento de las expresiones regulares y de las herramientas más comunes que las usan.

Así mismo define un estándar de llamadas al sistema operativo. La librería estándar de C define unas funciones que deben estar en cualquier entorno de desarrollo de C.

El término fue sugerido por Richard Stallman en respuesta a la demanda de la IEEE, que buscaba un nombre fácil de recordar. Una traducción aproximada del acrónimo podría ser “Interfaz para Sistemas Operativos migrables basados en UNIX”.
 
Pequeña Introducción
Estos son una familia de estándares de llamadas al sistema operativo definido por el IEEE y especificado formalmente en el IEEE 1003. Persiguen generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. Estos estándares surgieron de un proyecto de normalización de las API y describen un conjunto de interfaces de aplicación adaptables a una gran variedad de implementaciones de sistemas operativos.

Especifica las interfaces de usuario y software al sistema operativo en 15 documentos diferentes. La línea de comandos estándar y las interfaces de scripting se basaron en Korn Shell. Otros programas a nivel de usuario (user-level), servicios y utilidades incluyen AWK, echo, ed y cientos de otras. Los servicios a nivel de programa requeridos incluyen definición de estándares básicos de I/O, (file, terminal, y servicios de red). También especifican una API para las bibliotecas de threading, que es muy utilizada en una gran variedad de sistemas operativos.

Una serie de pruebas acompañan al estándar POSIX. Son llamadas “PCTS” en alusión al acrónimo “Posix Conformance Test Suite”. Desde que la IEEE empezó a cobrar altos precios por la documentación de POSIX y se ha negado a publicar los estándares, ha aumentado el uso del modelo Single Unix Specification. Este modelo es abierto, acepta entradas de todo el mundo y está libremente disponible en Internet. Fue creado por The Open Group.

¿Dónde se ocupa?

Sincronización de procesos. Define funciones para permitir la sincronización de procesos a través de semáforos contadores.

Memoria compartida. Tienen espacios de direccionamiento que son independientes entre sí. Sin embargo, muchas aplicaciones de tiempo real (y también muchas que no son de tiempo real) necesitan compartir grandes cantidades de datos de una manera eficiente.

Señales de tiempo real. Permite notificar eventos que ocurren en el sistema, pero no es completamente satisfactorio para aplicaciones de tiempo real. Las señales no se almacenan en colas y, por tanto, algunos eventos se pueden perder. Las señales no están priorizadas, y esto implica tiempos de respuesta más largos para eventos urgentes.

Comunicación de procesos. Se especifica un mecanismo sencillo de colas de mensajes para la comunicación entre procesos. Las colas de mensajes están identificadas por un nombre perteneciente a un espacio de nombres dependiente de la implementación.

Entrada/Salida Asíncrona. Define funciones que permiten solapar el procesado de aplicaciones con las operaciones de entrada/salida iniciadas por la aplicación. Una operación de entrada/salida asíncrona es similar a las operaciones de entrada/salida normales, con la excepción de que una vez que la operación asíncrona ha sido iniciada por un proceso, este proceso no se suspende y puede continuar ejecutando instrucciones, en paralelo con la operación de entrada/salida

Extensión de threads. Define interfaces para soportar múltiples actividades concurrentes, denominadas threads, dentro de cada proceso POSIX. Los threads definidos en el POSIX  tienen un estado asociado más pequeño que el de un proceso. Todos los threads que pertenecen al mismo proceso comparten el mismo espacio de direccionamiento. Pueden ser implementados con tiempos de cambio de contexto y de creación y destrucción más bajos que los de los procesos. El POSIX.4a ha sido específicamente desarrollado para abordar las necesidades de los sistemas multiprocesadores de memoria compartida.

Ejemplo

El ejemplo es un sistema productor-consumidor con búfer circular utilizando hilos, semáforos POSIX binarios y semáforos POSIX genérico

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <semaphore.h>
#include <pthread.h>
#define TAMBUF 8     // Tamaño del búfer circular
#define NUMDATOS 100 // Número de datos a enviar
// El buffer circular y los correspondientes punteros
int buffer[TAMBUF];
int bufin = 0;
int bufout = 0;
// Semaforo binario
pthread_mutex_t buffer_lock = PTHREAD_MUTEX_INITIALIZER;
// Variable suma
int sum = 0;
// Semaforos generales
sem_t hay_datos;
sem_t hay_sitio;
// Funciones de escritura y lectura del buffer circular
void obten_dato(int *itemp)
{
  pthread_mutex_lock(&buffer_lock);
  *itemp = buffer[bufout];
  bufout = (bufout + 1) % TAMBUF;
  pthread_mutex_unlock(&buffer_lock);
  return;
}
void pon_dato(int item)
{
  pthread_mutex_lock(&buffer_lock);
  buffer[bufin] = item;
  bufin = (bufin + 1) % TAMBUF;
  pthread_mutex_unlock(&buffer_lock);
  return;
}
// Funciones productor-consumidor
void *productor(void *arg1)
{
  int i;
  for (i = 1; i <= NUMDATOS; i++)
  {
    sem_wait(&hay_sitio);
    pon_dato(i*i);
    sem_post(&hay_datos);
  }
  pthread_exit( NULL );
}
void *consumidor(void *arg2)
{
  int i, midato;
  for (i = 1; i<= NUMDATOS; i++)
  {
    sem_wait(&hay_datos);
    obten_dato(&midato);
    sem_post(&hay_sitio);
    sum += midato;
  }
  pthread_exit( NULL );
}
// Funcion principal
void main(void)
{
  pthread_t tidprod, tidcons;
  int i, total;
  total = 0;
  for (i = 1; i <= NUMDATOS; i++)
    total += i*i;
  printf("El resultado deberia ser %d\n", total);
// Inicializacion de semaforos
  sem_init(&hay_datos, 0, 0);
  sem_init(&hay_sitio, 0, TAMBUF);
// Se crean los hilos
  pthread_create(&tidprod, NULL, productor, NULL);
  pthread_create(&tidcons, NULL, consumidor, NULL);
// Se espera a que los hilos terminen
  pthread_join(tidprod, NULL);
  pthread_join(tidcons, NULL);
  printf("Los hilos produjeron el valor %d\n", sum);
}

Manejo de Archivos

Una de las principales funciones de un Sistema Operativo es la administración del almacenamiento de información, para lo cual es necesario contar con un “Sistema de Archivos”. Con este término se hace referencia, por un lado, a los mecanismos y estructuras que el sistema operativo utiliza para organizar la información en medios físicos tales como discos y diskettes (aspecto físico del sistema de archivos), y por otro a la visión que es ofrecida al usuario para permitir la manipulación de la información almacenada (una abstracción, o perspectiva lógica del sistema de archivos).
Se ofrece a continuación una descripción sintética de los aspectos lógicos del sistema de archivos de Linux.
 
ARCHIVOS Y DIRECTORIOS
El sistema de archivos de Linux está organizado en archivos y directorios. Un archivo es una colección de datos que se almacena en un medio físico y a la cual se le asigna un nombre. Los archivos, a su vez, están agrupados en conjuntos llamados directorios. Un directorio puede tener subdirectorios, formándose así una estructura jerárquica con la forma de un árbol invertido. El directorio inicial de esa jerarquía se denomina directorio raíz y se simboliza con una barra de división (/).
El sistema de archivos de un sistema Linux típico está formado por los siguientes directorios bajo el directorio raíz:
/bin Contiene los programas ejecutables que son parte del sistema operativo Linux. Muchos comandos de Linux como cat, cp, ls, more y tar están ubicados en este directorio.
/boot Contienen el kernel (o núcleo) de Linux y otros archivos necesarios para el administrador de inicio LILO, que realiza la carga inicial del sistema operativo cuando la computadora se enciende.
/dev Contienen todos los archivos de acceso a dispositivos. Linux trata cada dispositivo (terminales, discos, impresoras, etc.) como si fuera un archivo especial.
/etc. Contiene archivos de configuración del sistema y los programas de inicialización.
/home Contiene los directorios HOME de los usuarios. El directorio HOME el directorio inicial en el que se encuentra posicionado un usuario al ingresar al sistema, por lo que también se conoce como directorio de logín o de conexión.
/lib Contiene los archivos de biblioteca utilizados por las aplicaciones y utilidades del sistema, así también como las librerías pertenecientes a diferentes lenguajes de programación.
/lost+found Directorio para archivos recuperados por el proceso de reparación del sistema de archivos, que se ejecuta luego de una caída del sistema y asegura su integridad luego de que el equipo haya sido apagado de manera inapropiada.
/mnt Es un directorio vacío que se usa normalmente para montar dispositivos como disquetes y particiones temporales de disco.
/proc Contiene archivos con información sobre el estado de ejecución del sistema operativo y de los procesos.
/root Es el directorio HOME para el usuario root (administrador del sistema).
/sbin Contienen archivos ejecutables que son comandos que se usan normalmente para la administración del sistema.
/tmp Directorio temporal que puede usar cualquier usuario como directorio transitorio.
/usr Contiene archivos de programa, de datos y de librerías asociados con las actividades de los usuarios.
/var Contiene archivos temporales y de trabajo generados por programas del sistema. A diferencia de /tmp, los usuarios comunes no tienen permiso para utilizar los subdirectorios que contiene directamente, sino que deben hacerlo a través de aplicaciones y utilidades del sistema.
 
PERMISOS DE ARCHIVOS Y DIRECTORIOS

En cualquier sistema multiusuario, es preciso que existan métodos que impidan a un usuario no autorizado copiar, borrar, modificar algún archivo sobre el cual no tiene permiso.
En Linux las medidas de protección se basan en que cada archivo tiene un propietario (usualmente, el que creó el archivo). Además, los usuarios pertenecen a uno o mas grupos, los cuales son asignados por el Administrador dependiendo de la tarea que realiza cada usuario; cuando un usuario crea un archivo, el mismo le pertenece también a alguno de los grupos del usuario que lo creó.
Así, un archivo en Linux le pertenece a un usuario y a un grupo, cada uno de los cuales tendrá ciertos privilegios de acceso al archivo. Adicionalmente, es posible especificar que derechos tendrán los otros usuarios, es decir, aquellos que no son el propietario del archivo ni pertenecen al grupo dueño del archivo.
En cada categoría de permisos (usuario, grupo y otros) se distinguen tres tipos de accesos: lectura (Read), escritura (Write) y ejecución (eXecute), cuyos significados varían según se apliquen a un archivo o a un directorio.
En el caso de los archivos, el permiso R (lectura) habilita a quién lo posea a ver el contenido del archivo, mientras que el permiso W (escritura) le permite cambiar su contenido. El permiso X (ejecución) se aplica a los programas y habilita su ejecución.
Para los directorios, el permiso R permite listar el contenido del mismo (es decir, “leer” el directorio, mientras que el W permite borrar o crear nuevos archivos en su interior (es decir, modificar o “escribir” el directorio). El permiso X da permiso de paso, es decir, la posibilidad de transformar el directorio en cuestión en el directorio actual (ver comando cd).
En los listados de directorio, los permisos se muestran como una cadena de 9 caracteres, en donde los primeros tres corresponden a los permisos del usuario, los siguientes tres a los del grupo y los últimos, a los de los demás usuarios. La presencia de una letra (r, w o x) indica que el permiso está concedido, mientras que un guión (-) indica que ese permiso está denegado.
Los permisos de un archivo o directorio pueden cambiarse desde el administrador de archivos KFM utilizando la ventana de propiedades o utilizando el comando chmod.

La memoria como mecanismo de comunicación

Tipos de comunicación

La comunicación puede ser:
  • Síncrona o asíncrona
  • Persistente (persistent) o momentánea (transient)
  • Directa o indirecta
  • Simétrica o asimétrica
  • Con uso de buffers explícito o automático
  • Envío por copia del mensaje o por referencia
  • Mensajes de tamaño fijo o variable

Síncrona

Quien envía permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otro ejercicio.

Asíncrona

Quien envía continúa con su ejecución inmediatamente después de enviar el mensaje al receptor.

Persistente

El receptor no tiene que estar operativo al mismo tiempo que se realiza la comunicación, el mensaje se almacena tanto tiempo como sea necesario para poder ser entregado (Ej.: e-Mail).

Momentánea (transient)

El mensaje se descarta si el receptor no está operativo al tiempo que se realiza la comunicación. Por lo tanto no será entregado.

Directa

Las primitivas enviar y recibir explicitan el nombre del proceso con el que se comunican. Ejemplo:
enviar (mensaje, A) envía un mensaje al proceso A
Es decir se debe especificar cual va a ser el proceso fuente y cual va a ser el proceso Destino.
Las operaciones básicas Send y Receive se definen de la siguiente manera: Send (P, mensaje); envía un mensaje al proceso P (P es el proceso destino). Receive (Q, mensaje); espera la recepción de un mensaje por parte del proceso Q (Q es el proceso fuente).
Nota: Receive puede esperar de un proceso cualquiera, un mensaje, pero el Send sí debe especificar a quién va dirigido y cuál es el mensaje.

Indirecta

La comunicación Indirecta: Es aquella donde la comunicación está basada en una herramienta o instrumento ya que el emisor y el receptor están a distancia.

Simétrica

Todos los procesos pueden enviar o recibir. También llamada bidireccional para el caso de dos procesos.

Asimétrica

Un proceso puede enviar, los demás procesos solo reciben. También llamada unidireccional. Suele usarse para hospedar servidores en Internet.

Uso de buffers automático

El transmisor se bloquea hasta que el receptor recibe el mensaje (capacidad cero).

RPC

(Remote Procedure Call / llamada a un procedimiento remoto) Permitir que los programas realicen llamadas a funciones localizadas en otras máquinas. Los programadores no se tienen que preocupar por los detalles de la programación de la red. Conceptualmente simple.
Desde el punto de vista de un programador la llamada a una función remota es y funciona de la misma manera que lo haría si la llamada fuese local. En este sentido, se logra transparencia.
Cada función pasa a tener dos partes: cliente, la máquina local donde se implementa la interface (prototipo de una función) para invocar las funciones remotas. Servidor, implementación de las funciones propiamente dichas.

Paso de parámetros

No debería de existir ningún problema si dos máquinas son homogéneas, sin embargo la realidad no suele ser ésta. Pueden surgir problemas de diferentes codificación de caracteres (ej.: mainframe IBM: EBCDIC, IBM PC: ASCII) o diferentes tipos de ordenación de bytes (ej.: Intel: little endian, Sun SPARC: big endian).
Como solución a estos problemas es importante lograr un acuerdo del protocolo usado. La parte encargada de generar los mensajes no debe de presuponer el uso de un lenguaje de programación específico.

Invocación remota de métodos (RMI)

Es un mecanismo de expansión de RPC cuyo objetivo es dar soporte a sistemas orientado a objetos.
La idea es tener objetos distribuidos. Para acceder al estado de un objeto sólo se realiza a través de métodos definidos por un objeto interface. Un objeto ofrece múltiples interfaces. Una interface puede ser implementada por múltiples objetos.

Comunicación orientada a mensajes

Las comunicaciones RPC se basan en la idea que el receptor está operativo para poder invocar una cierta función, no podemos suponer que el receptor siempre estará operativo y esperando a comunicarse. La solución es definir la comunicación en término de paso de mensajes.

Mensajes momentáneos vs. mensajes persistentes

Momentáneos: no soportan el envío de mensajes persistentes. (1) Sockets, (2) Message-passing interface (MPI).

Sockets Berkeley

Sistema fuertemente acoplado a las redes TCP/IP
Sockets API:
  1. socket: crea una nueva comunicación.
  2. bind: añade la dirección local al socket.
  3. listen: queda en espera de conexiones.
  4. accept: queda bloqueado hasta la llegada de un pedido de conexión.
  5. connect: pedido de establecimiento de conexión.
  6. send: enviar datos por la conexión.
  7. receive: recibir datos por la conexión.
  8. close: desvincula el socket la dirección local.

Message-passing interface (MPI)

Diseñado para aplicaciones paralelas crea un nivel de abstracción más alto que el provisto por sockets. Provee una interface con primitivas más avanzadas. Por el contrario cuenta con una gran cantidad de implementaciones (librería y protocolos) propietarias lo que genera la necesidad de una interface standard.
MPI API:
  1. MPI_bsend: vincula la salida de mensajes con el buffer de salida local.
  2. MPI_send: envía un mensaje y espera hasta que es copiado al buffer.
  3. MPI_ssend: envía un mensae y espera hasta que el receptor inicie.
  4. MPI_sendrecv: envía un mensaje y espera respuesta.
  5. MPI_isend: pasa la referencia de un mensaje y continúa.
  6. MPI_issend: para la referencia de un mensaje y espera hasta que el receptor inicie.
  7. MPI_recv: recibe un mensaje; se bloquea en el caso de no haberlo.
  8. MPI_irecv: verifica si hay mensajes entrantes; no se bloquea.
Persistentes: el mensaje se encola y se entrega cuando se pide. (1) Message-oriented middleware (MOM)

Implementaciones

Hay un número de APIs que pueden ser usadas por IPC. Un número de plataformas independientes de APIs incluidas las siguientes:
  • Tuberías Anónimas y con nombre
  • Common Object Request Broker Architecture (CORBA)
  • Distributed Computing Environment (DCE)
  • Message Bus (MBUS) (especificado en RFC 3259)
  • ONC RPC
  • Sockets
  • XML XML-RPC or SOAP
  • ZeroC's Internet Communications Engine (ICE)
Las siguienteas son plataformas específicas de APIs:
  • Apple Computer's Apple events (previamente conocido como Interapplication Communications (IAC)).
  • Freedesktop.org's D-Bus
  • KDE's Desktop Communications Protocol (DCOP)
  • Libt2n parar C++ solamente, manejos de objetos y excepciones complejos.
  • The Mach kernel's Mach Ports
  • Microsoft's ActiveX, Component Object Model (COM), Distributed Component Object Model (DCOM), Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), anonymous pipes, named pipes, Local Procedure Call
  • Novell's SPX
  • POSIX mmap, message queues, semaphores, and Shared memory
  • RISC OS's messages
  • Solaris's Doors
  • System V's message queues, semaphores, and Shared memory

Message-oriented middleware o Message-queuing systems

Aparece un tercer componente de la conexión que realiza tareas de almacenamiento de mensajes. Esto permite que el emisor y el receptor estén inactivos. Permite comunicaciones persistentes asíncronas. Transferencia de mensajes que duren minutos a comparación de segundos o milisegundos. La aplicación más conocida que utiliza dicho modelo es el correo electrónico (e-Mail).
La idea básica consiste en insertar (putting) o quitar (taking) mensajes en una cola. Al emisor sólo se le puede garantizar que el mensaje ha sido insertado correctamente en la cola. No existen garantías de cuándo será leído dicho mensaje.
No está ligado a ningún tipo específico de modelo de red.
Message-queuing system API:
  1. put: añadir un mensaje a una cola.
  2. get: bloquear hasta que la cola no esté vacía, luego quitar el primer elemento.
  3. poll: verificar si hay mensaje, quitar el primero. Nunca se bloquea.
  4. notify: instalar en la cola un dispositivo que avisará cuando un nuevo mensaje se inserte en la cola.

Comunicación orientada a streams

Los modelos RPC, RMI y MOM realizan comunicaciones independientes del tiempo. Existen también sistemas donde el tiempo es crucial en la comunicación, o los resultados de salida serán incorrecto; es así el caso de trasmisión de audio, video, sensor de datos, etc. (comunicación continua de datos) donde cortes de comunicación generan retardos no deseados.

Comunicación entre procesos Linux

La comunicación puede simplemente ser cuestión de dejar que otro proceso sepa que ha ocurrido algún evento, o puede implicar la transferencia de datos de un proceso a otro.

Señales
El mecanismo estándar para informar a un proceso que ha ocurrido un evento es la señal. Se pueden enviar señales de un proceso a otro pero sin enviar información. Las señales no necesitan ser generadas por otro proceso, también puede ser generada por el kernel.
Linux también implementa un mecanismo de semáforos. Un proceso puede esperar un semáforo tan fácilmente como espera una señal.

Paso de datos entre procesos
El mecanismo de tubería (pipe) estándar permite a un proceso hijo heredar un canal de comunicación con su padre; los datos que se escriben en un extremo de la tubería se leen en el otro. También define un conjunto de servicios para trabajo en red que pueden enviar flujos de datos tanto a procesos locales como remotos.
Hay otro método que es la memoria compartida que ofrece una forma extremadamente rápida de comunicar cantidades grandes o pequeñas de datos; cualquier dato escrito por un proceso en una región de memoria compartida puede ser leído por cualquier otro proceso que haya mapeado dicha region en su espacio de direcciones.

Freedesktop
Para comunicación entre aplicaciones gráficas existe D-Bus, usado por GNOME y KDE entre otros. Permite fácilmente comunicar unas aplicaciones con otras o controlar cualquier elemento de una interfaz gráfica desde consola a con un programa hecho al efecto.

Comunicación multicast

Es la abstracción de diseminación de datos. Utilizando el soporte de difusión (broadcast) en las redes locales para realizar tareas como protocolos epidémicos.

Tabla de métodos de IPC

MétodoProvisto por (sistema operativo u otro ambiente )
ArchivoTodos los sistemas operativos.
SeñalLa mayoría de los Sistemas Operativos; algunos, como Windows, solo implementan señales en las librerías de C run-time de C y actualmente no proveen soportes para su uso como técnica de IPC.
SocketLa mayoría de los sistemas operativos.
Tubería / PipesTodos los sistemas POSIX.
Named pipeTodos los sistemas POSIX.
SemáforoTodos los sistemas POSIX.
Memoria compartidaTodos los sistemas POSIX.
MensajesUsado en el paradigma MPI, Java RMI, CORBA y otros.
Mapa de MemoriaTodos los sistemas POSIX. Windows también es apto para esta técnica, las APIs usadas son específicas de esta plataforma.
Cola de MensajesLa mayoría de los Sistemas Operativos.
puertosAlgunos Sistemas Operativos.