Traductor

sábado, 27 de agosto de 2016

MAQUINA VIRUTAL

¿QUÉ ES UNA MAQUINA VIRTUAL?
 
Una máquina virtual es un software (programa) que
emula a un ordenador real y por lo tanto dispone
de disco duro, memoria ram, tarjeta gráfica, etc.
y puede ejecutar programas como lo hace una
computadora. En cierta medida, podríamos verlo como
una partición de nuestro ordenador: la máquina
real y la máquina virtual. La diferencia está en
que mientras una partición tiene componentes físicos
(hardware) la otra no los tiene físicamente sino como emulación. La partición suele ser en dos, pero
podríamos tener más de una máquina virtual dentro de un ordenador o servidor.
Entre el software más difundido que permite crea
r máquinas virtuales tenemos VMWare, VirtualPC y
Sandbox.
Las máquinas virtuales pueden instalarse sobre cualquier ordenador. Conviene consultar los
requerimientos de equipo que indique el suministrador del software, es decir, hay máquinas virtuales
que pueden requerir un mínimo de 8 Gb de memoria ram y que no convendrá instalarlas en
ordenadores con menos ram que esta. 
 

CARACTERÍSTICAS DE UNA MÁQUINA VIRTUAL
 
•Las máquinas virtuales están aisladas entre sí, igual que las máquinas físicas. Por ejemplo, si hay 3 máquinas virtuales en una máquina real y falla una de ellas, las otras dos siguen estando disponibles.

•Una máquina virtual ni siquiera sabe que es virtual; se comporta como una máquina física real.

•Una máquina virtual es compatible con sistemas
operativos estándar como Windows o Linux, es
decir, cualquier programa desarrollado para dichos
sistemas operativos puede ejecutarse en una
máquina virtual.

•Una máquina virtual es completamente independiente
del hardware físico. La máquina virtual tiene
todos los componentes físicos pero éstos son virtuales (placa base virtual, tarjeta VGA virtual,
controlador de tarjeta de red virtual,..., etc.),
esto quiere decir que una máquina virtual puede
ejecutarse en una máquina real con tarjeta de red de marca x, pero siempre verá una tarjeta de red virtual. Esto es útil porque permite que una máquina virtual se pueda mover de una maquina real a otra, sin realizar cambios en los controladores del dispositivo aunque las 2 máquinas reales sean de
2 fabricantes distintos. La independencia del ha
rdware proporciona más portabilidad y flexibilidad
para la gestión de servidores por ejemplo. 

•Las aplicaciones están protegidas de los problemas de estabilidad y rendimiento de otras aplicaciones existentes en la máquina real, es decir; si una persona tiene todas sus aplicaciones en una máquina virtual, la estabilidad y rendimiento es
independiente de lo que suceda en la máquina
real. El comportamiento es como sise tratara de otro ordenador.

•Una máquina virtual se encapsula en una colección de archivos, y al igual que los archivos, las máquinas virtuales se pueden copiar, mover, distribuir (enviar por correo, grabar en DVD, etc.) 


¿POR QUÉ ES ÚTIL UNA MAQUINA VIRTUAL?
 
Una máquina virtual puede ser útil en muchas situaciones. Veamos algunos ejemplos:

• Supón que te envían o descargas un archivo de un
programa a tu disco duro, y no te fías por si
puede ser un virus o programa malicioso. Entonces,
si no quieres ejecutar dicho programa en tu
máquina real, puedes hacerlo en tu máquina virtual, y así evitar todo tipo de riesgos. Una vez que te asegures que es un programa útil para tí y libre de riesgos, entonces si deseas puedes instalarlo
en tu máquina real para tu uso frecuente. Si lo prefieres puedes mantenerlo en tu máquina virtual
para no sobrecargar de programas tu máquina real.

•Otro ejemplo, supongamos eres usuario de Wind
ows XP y que has decidido instalar el nuevo
sistema operativo de Microsoft, Windows 8.1 Ultimate, en tu máquina real, pensando que todos los programas con que trabajas funcionarán correct
amente en el nuevo sistema operativo. Sin embargo, te das con la sorpresa de que un programa que funcionaba bien en Windows XP ya no te
funciona con el Windows 8.1 Ultimate y necesita
s trabajar con él urgentemente. En este caso,
bastaría con que instalaras en tu máquina virtual el Windows XP y problema resuelto. Cada vez que desees trabajar con dicho programa te pasas a
tu máquina virtual con un solo click del mouse y cuando lo deseas, pasas a tu máquina real y sigues trabajando con tus otros programas.

•Puede que desees visitar páginas de las cuales no tienes idea de si son seguras. En este caso puedes usar tú máquina virtual y visitarlas sin ningún problema que implique poner en riesgo tu máquina real, ya que cualquier daño sólo afectaría a tu máquina virtual. 

•Otra gran utilidad es poder conectar tu máquina virtual en una red con tu máquina real como si tuvieras dos máquinas físicamente cuando en realid
ad tienes una real y la otra virtual. De esa manera hacer pruebas de red sin necesidad de gastar en una segunda máquina real con el costo
que eso implicaría. 

•Puede ocurrir que siendo usuario de Windows acostumbres a trabajar con Linux para algunas cosas,
o quieras ir aprendiendo o probando Linux. En este caso puede ser tedioso estar reiniciando la máquina real, para pasarte a la partición de tu disco duro donde está el sistema operativo Linux
cada vez que quieras utilizarlo. La solución sería
tener en la máquina virtual instalado el Linux y
cada vez que desees usarlo, con
un solo con click del mouse cambiar de sistema operativo. Cuando
termines con Linux, puedes pasar rápidamente a
Windows sin la pérdida de tiempo que implica
reiniciar el ordenador. De igual manera puedes te
ner muchos otros sistemas operativos al mismo
tiempo en distintas máquinas virtuales. 

•Los sistemas operativos actuales pueden ejecutar
múltiples aplicaciones de software que sean
compatibles con el sistema operativo, pero
los distintos programas pueden no funcionar
correctamente cuando se ejecutan a la vez que
otros, lo que provoca a menudo resultados
inesperados y no deseables. Si se trata de servidores, la ejecución de múlt
iples aplicaciones en el  mismo servidor, supone riesgos adicionales. Si se
parara un servidor con múltiples aplicaciones, se
verían afectadas todas las aplicaciones del servidor
Para gestionar estos riesgos, los centros de
procesamiento de datos ejecutan normalmente una
sola aplicación por servidor con el gasto que
eso implica en cuanto a comprar un servidor por aplicación. La solución a esta situación estaría en  un servidor virtual para cada aplicación ahorrándono
s una importante suma de dinero en la compra
de nuevos servidores.
INCONVENIENTES DE LAS MÁQUINAS VIRTUALES
Hasta ahora puede parecer que una máquina virtual es la panacea para resolver muchos problemas, pero también podemos indicar que tienen algunos inconvenientes. Entre ellos podemos destacar: 

•La máquina virtual ocupará espacio de nuestro disco duro. La máquina virtual en sí puede ocupar en torno a 1 GB, pero a este espacio hay que añadirle
el sistema operativo quetendremos que instalar.
Además, el espacio ocupado irá creciendo a medida que instalemos más programas en ella. 

•Cuando tenemos una máquina virtual y la arrancamos
parte de los recursos de nuestro sistema real
(memoria ram, memoria de tarjeta gráfica, capacidad del procesador, etc.) se derivan a la máquina virtual. Esto puede suponer que nuestro ordenador vaya más lento, ya que los mismos recursos tienen que sostener a dos máquinas. 

•Aunque máquina real y virtual son sistemas independientes, realmente la máquina virtual está corriendo con “el fondo” del sistema operativo real. Por tanto el sistema operativo real puede hacer que el rendimiento de nuestra máquina virtual no sea bueno y que vaya más lenta que con otros sistemas operativos. Por ejemplo, una máquina virtual puede correr mejor con Windows 8 Ultimate que con Windows 8 Home.

Lista de máquinas virtuales

Máquinas virtuales de proceso

Máquinas virtuales de sistema
Máquinas virtuales a nivel de sistema operativo
 



Publicadas por a la/s No hay comentarios.:

martes, 9 de agosto de 2016

SYMBIAN OS

Symbian fue un sistema operativo propiedad de Nokia, y que en el pasado fue producto de la alianza de varias empresas de telefonía móvil, entre las que se encontraban Nokia, Sony Mobile Communications, Psion, Samsung, Siemens, Arima, Benq,Fujitsu, Lenovo, LG, Motorola, Mitsubishi Electric, Panasonic, Sharp, etc. Sus orígenes provenían de su antepasado EPOC32, utilizado en PDA's y Handhelds de PSION.
El objetivo del Symbian era crear un sistema operativo para terminales móviles que pudiera competir con el de Palm o el Windows Mobile de Microsoft y
posteriormente Android de Google , iOS de Apple, Windows Phone de Microsoft y BlackBerry 
LA HISTORIA DE SYMBIAN OS

Symbian tiene una historia bastante corta. Sus raíces están en los sistemas que se desarrollaron en la década de 1990, y su debut fue en el 2001.
Raíces de Symbian OS: Psion y EPOC
La herencia de Symbian OS empieza con algunos de los primeros dispositivos de bolsillo; éstos
evolucionaron, a finales de la década de 1980, como un medio para comprimir la utilidad de un dispositivo
de escritorio en un pequeño paquete portátil. Los primeros intentos de las computadoras de
bolsillo no fueron recibidos con mucho entusiasmo: la Apple Newton era un dispositivo bien diseñado,
pero tuvo sólo unos cuantos usuarios. A pesar de este lento inicio, las computadoras de bolsillo
desarrolladas a mediados de 1990 estaban mejor adaptadas al usuario y a la forma en que las
personas utilizaban los dispositivos móviles. Este tipo de computadoras se diseñaron en un principio
como PDAs (asistentes digitales personales que en esencia eran planificadores electrónicos), pero evolucionaron
para abarcar muchos tipos de funcionalidad. A medida que se desarrollaron, empezaron a
funcionar como las computadoras de escritorio y también tenían las mismas necesidades, como la
multitarea; incorporaron capacidades de almacenamiento en varias formas; tenían que ser flexibles

en las áreas de la entrada y salida de datos.

La programación se basaba en el lenguaje C, tenía un diseño orientado a
objetos y empleaba motores de aplicaciones, una parte distintiva del desarrollo de Symbian OS.
Esta metodología de los motores era una poderosa característica. Se basaba en el diseño del micro-
kernel para enfocar la funcionalidad en los motores (funcionaban como servidores) que administraban las funciones en respuesta a las peticiones de las aplicaciones.
En 1996, Psion empezó a diseñar un nuevo sistema operativo de 32 bits que aceptaba dispositivos
señaladores en una pantalla táctil, utilizaba multimedia y tenía capacidades más completas de comunicación.
El nuevo sistema también estaba más orientado a objetos y podía portarse a distintas
arquitecturas y diseños de dispositivos. El resultado del esfuerzo de Psion fue la introducción del sistema como EPOC Release 1. Este sistema se programó en C++ y estaba diseñado para ser orientado a objetos desde sus cimientos. 
Symbian OS versión 6
Como la última versión de EPOC fue ER5, Symbian OS hizo su debut con la versión 6 en el 2001.
Este sistema operativo aprovechaba las propiedades flexibles de EPOC y estaba orientado a varias
plataformas distintas generalizadas. Se diseñó con la suficiente flexibilidad para desarrollar una amplia
variedad de dispositivos móviles y teléfonos avanzados, y al mismo tiempo daba a los fabricantes
la oportunidad de diferenciar sus productos.

Symbian OS versión 7
La versión 7 de Symbian OS era muy parecida a sus predecesores EPOC y la versión 6 en cuanto
a diseño y función. El enfoque en el diseño era abarcar la telefonía móvil. Sin embargo, a medida
que cada vez más fabricantes diseñaban teléfonos móviles, era obvio que hasta la flexibilidad de
EPOC, un sistema operativo para dispositivos de bolsillo, no podría lidiar con la plétora de nuevos
teléfonos que necesitaban usar Symbian OS.


Symbian OS en la actualidad

La versión 7 de Symbian OS fue muy importante, debido a que en ella se incorporaron la abstracción
y la flexibilidad al sistema operativo. Sin embargo, esta abstracción tuvo sus desventajas. En
poco tiempo, el rendimiento del sistema operativo se volvió un problema que había que resolver.
Más tarde se emprendió un proyecto para reescribir por completo el sistema operativo, esta vez
con énfasis en el rendimiento. El nuevo diseño del sistema operativo debía retener la flexibilidad de
la versión 7 de Symbian OS y, al mismo tiempo, mejorar el rendimiento y aumentar la seguridad
del sistema. La versión 8 de Symbian OS, que se liberó en 2004, mejoró el rendimiento de Symbian
OS, en especial para sus funciones de tiempo real. La versión 9 de Symbian OS se liberó en
2005; esta versión agregó los conceptos de seguridad basada en la capacidad y la instalación de un
guardián.

GENERALIDADES SOBRE SYMBIAN OS
Symbian OS es único entre los sistemas operativos, ya que se diseñó con los teléfonos inteligentes
como plataforma de destino. No es un sistema operativo genérico que se adaptó a un teléfono
inteligente a la fuerza, ni una adaptación de un sistema operativo más grande para una
plataforma más pequeña. Sin embargo, tiene muchas de las características de los otros sistemas
operativos más grandes, desde la multitarea y la administración de la memoria hasta las cuestiones
de seguridad.

Orientación a objetos
El diseño de Symbian OS está orientado a objetos. Las implementaciones de las herramientas
del sistema están ocultas; los datos del sistema se utilizan a través de interfaces definidas en los
objetos del sistema. Mientras que un sistema operativo como Linux podría crear un descriptor de
archivos y utilizarlo como un parámetro en una llamada a open, Symbian OS crearía un objeto
de archivo y llamaría al método open conectado al objeto. Por ejemplo, es sabido que, en Linux,
los descriptores de archivos son enteros que indexan una tabla en la memoria del sistema operativo;
en Symbian OS se desconoce la implementación de las tablas del sistema de archivos, y toda
la manipulación del sistema de archivos se realiza mediante objetos de una clase de archivo específica.

Diseño del microkernel
Symbian OS se diseñó como un sistema operativo basado en microkernel. Para acceder a los
recursos del sistema, se abren conexiones a los servidores de recursos que a su vez coordinan el acceso
a los mismos recursos. Symbian OS luce una arquitectura conectable para las nuevas implementaciones.
Estas nuevas implementaciones para las funciones del sistema se pueden diseñar
como objetos del sistema y se pueden insertar en el kernel de manera dinámica. Por ejemplo, se pueden
implementar nuevos sistemas de archivos y agregarlos al kernel cuando el sistema operativo esté
en ejecución.

El nanokernel de Symbian OS
Para lidiar con las cuestiones del microkernel, los diseñadores de Symbian OS implementaron una
estructura de nanokernel en el núcleo del diseño del sistema operativo. Así como en las microkernels
se meten ciertas funciones del sistema en los servidores en espacio de usuario, el diseño de
Symbian OS separa las funciones que requieren una implementación complicada en el kernel
de Symbian OS y mantiene sólo las funciones más básicas en el nanokernel, el núcleo del sistema
operativo.

Acceso a los recursos de cliente/servidor
Como dijimos antes, Symbian OS explota el diseño de su microkernel e incluye un modelo cliente/
servidor para acceder a los recursos del sistema. Las aplicaciones que necesitan acceder a los recursos
del sistema son los clientes; los servidores son programas que el sistema operativo ejecuta
para coordinar el acceso a estos recursos. Mientras que en Linux podríamos llamar a open para abrir
un archivo, o en Windows usar una API de Microsoft para crear una ventana, en Symbian OS ambas
secuencias son iguales: primero se debe hacer una conexión a un servidor, éste debe reconocer
la conexión y hay que hacerle peticiones para realizar ciertas funciones. Por lo tanto, abrir un
archivo significa que hay que buscar el servidor de archivos, llamar a connect para establecer una
conexión con el servidor y después enviarle una petición open con el nombre de un archivo específico.

PROCESOS E HILOS EN SYMBIAN OS

Hilos y nanohilos

El soporte de hilos en Symbian OS se basa en el nanokernel con nanohilos. El nanokernel proporciona
sólo soporte simple para los hilos; cada hilo se sostiene mediante un nanohilo basado en
nanokernel. El nanokernel proporciona la programación de los nanohilos, su sincronización (comunicación
entre hilos) y los servicios de temporización. Los nanohilos se ejecutan en modo privilegiado
y necesitan una pila para almacenar sus datos del entorno en tiempo de ejecución. Los
nanohilos no se pueden ejecutar en modo de usuario.

Los nanohilos tienen estados de hilos, así como los procesos tienen estados. El modelo utilizado
por el nanokernel de Symbian OS agrega unos cuantos estados al modelo básico. Además de los
estados básicos, los nanohilos pueden tener los siguientes estados:
Suspendido Aquí es cuando un hilo suspende a otro hilo y debe ser distinto al estado en
espera, donde un hilo se bloque mediante algún objeto de nivel superior (por ejemplo, un
hilo de Symbian OS).
Espera de semáforo rápido Un hilo en este estado espera a que se señale un semáforo rápido
(un tipo de variable centinela). Los semáforos rápidos son semáforos a nivel de nanokernel.
Espera de DFC Un hilo en este estado está esperando que se agregue una llamada a función
retrasada (DFC) a la cola de DFCs. Las DFCs se utilizan en la implementación de drivers
de dispositivos. Representan llamadas al kernel que se pueden poner en cola y
programar para ejecutarse mediante el nivel del kernel de Symbian OS.
Inactivo Los hilos inactivos esperan a que transcurra una cantidad específica de tiempo.
Otro Hay un estado genérico que se utiliza cuando los desarrolladores implementan estados
adicionales para los nanohilos. Los desarrolladores hacen esto cuando extienden la
funcionalidad del nanokernel para nuevas plataformas de teléfonos (lo cual se conoce como
niveles de personalidad). Los desarrolladores que hacen esto también deben implementar
la forma en que se cambia de un estado a otro desde sus implementaciones extendidas.




Procesos
En Symbian OS, los procesos son hilos de Symbian OS agrupados bajo una sola estructura de bloque
de control de proceso, con un solo espacio de memoria. Puede haber sólo un hilo de ejecución,
o varios hilos bajo un bloque de control de proceso. Los conceptos de estado del proceso y programación
del proceso ya se han definido mediante los hilos y nanohilos de Symbian OS. Entonces, la
programación de un proceso se implementa en realidad mediante la planificación de un hilo y la inicialización
del bloque de control de proceso correcto, de manera que el hilo lo utilice para sus necesidades
de datos.

ADMINISTRACIÓN DE LA MEMORIA
Sistemas sin memoria virtual
Muchos sistemas de cómputo no tienen las herramientas para proporcionar memoria virtual completa
con paginación bajo demanda. El único almacenamiento disponible para el sistema operativo
en estas plataformas es la memoria; no incluyen un disco duro. Debido a esto, la mayoría de los sistemas
más pequeños, desde los PDAs hasta los teléfonos inteligentes y los dispositivos de bolsillo
de mayor nivel, no proporcionan memoria virtual con paginación bajo demanda.

La administración de la memoria consiste en las siguientes tareas:
Administración del tamaño de la aplicación: El tamaño de una aplicación (código y datos)
tiene un efecto contundente en cuanto a la forma en que se utiliza la memoria. Se requiere
habilidad y disciplina para crear software pequeño.

Administración del montículo El montículo (el espacio para la asignación dinámica de
memoria) se debe administrar en forma muy estricta en una plataforma más pequeña.

Ejecución en el lugar Las plataformas sin unidades de disco por lo general admiten la ejecución
en el lugar.

Carga de DLLs La decisión de cuándo se deben cargar las DLLs puede afectar en la percepción
del rendimiento del sistema.

Transferencia de la administración de la memoria al hardware Si hay una MMU disponible,
se utiliza en toda su extensión. De hecho, entre más funcionalidad se pueda poner
en la MMU, mejor será el rendimiento del sistema.

Cómo direcciona Symbian OS la memoria
Como Symbian OS es un sistema operativo de 32 bits, las direcciones pueden variar hasta 4 GB.
Emplea las mismas abstracciones que los sistemas más grandes: los programas deben utilizar direcciones
virtuales, que el sistema operativo asigna a direcciones físicas. Al igual que con la mayoría
de los sistemas, Symbian OS divide la memoria en páginas virtuales y marcos físicos. El tamaño de
los marcos es por lo general de 4 KB, pero puede ser variable.


El modelo de movimiento. Este modelo se diseñó para las primeras arquitecturas del
ARM. El directorio de páginas en el modelo de movimiento es de 4 KB de largo, y cada
entrada contiene 4 bytes, para un tamaño del directorio de 16 KB. Las páginas de memoria
se protegen mediante bits de acceso asociados con los marcos de memoria y mediante
el etiquetado del acceso a la memoria con un dominio.

El modelo múltiple Este modelo se desarrolló para las versiones 6 y posteriores de la arquitectura
del ARM. La MMU en estas versiones difiere de la utilizada en versiones anteriores.

El modelo directo El modelo directo de memoria asume que no hay MMU. Este modelo
se utiliza muy poco y no está permitido en los teléfonos inteligentes. La falta de una MMU
ocasionaría severos problemas de rendimiento.

El modelo del emulador Este modelo se desarrolló para proveer un emulador de Symbian
OS para Windows. El emulador tiene unas cuantas restricciones en comparación con una
verdadera CPU de destino.


Publicadas por a la/s No hay comentarios.:
Suscribirse a: Entradas (Atom)