practica 2
jueves, 24 de noviembre de 2011
TERCER PARCIAL ACTIVIDAD 1
EJERCICIO 1
Dibuja la jerarquía de procesos que resulta de la ejecución del siguiente código. Introduce las llamadas al sistema wait para que una vez generado el árbol de procesos los hijos sean esperados por sus respectivos padres. Ademas, haz que se informe de los tiempos de ejecución de las aplicaciones xload y kcalc que se generen así como del tiempo total de ejecución. Para calcular el tiempo transcurrido, puedes utilizar la función´ time() de la librería estándar time.h. La llamada time(NULL) devuelve los segundos transcurridos desde las 00:00:00 del 1/1/1970 hasta el instante de la llamada.
int main (int argc, char ∗argv[]) {
int i, j;
pid t pid, nuevo, nuevo1;
time t ini, fin;
for (i= 0; i< 2; i++){
pid= getpid();
for (j= 0; j< i+2; j++){
nuevo= fork();
if(nuevo== 0){
break;
nuevo1= fork();
if(nuevo1== 0)
execlp ("xload", "xload", NULL);
}
}
if (pid!= getpid())
execlp ("kcalc", "kcalc", NULL);
}
return 0;
}
jueves, 3 de noviembre de 2011
PRACTICAS KDE
PRACTICAS EN KDE DE LINUX
PRACTICA 1
AQUI SE MATA UN PROCESO DENTRO DEL CONTOL GRAFICO
AQUI SE MATA UN PROCESO DENTRO DEL CONTOL GRAFICO
PRACTICA 2
SE MATA UN PROCESO DESDE EL MODO CONSOLA
SE MATA UN PROCESO DESDE EL MODO CONSOLA
PRACTICA 3
Matando procesos desde una carpeta interna y de la terminal
Matando procesos desde una carpeta interna y de la terminal
PRACTICA 4
Muestra la lista de procesos realizados al instante
Muestra la lista de procesos realizados al instante
PRACTICA 5
Lista de procesos en uso y la memoria q utiliza cada uno
Lista de procesos en uso y la memoria q utiliza cada uno
PRACTICA 6
SE USA ESTE COMANDO PARA VER PROCESOS Y EL ESTADO DE LA MEMORIA RAM
SE USA ESTE COMANDO PARA VER PROCESOS Y EL ESTADO DE LA MEMORIA RAM
PRACTICA 7
PROCESOS REALIZADOS
PROCESOS REALIZADOS
PRACTICA 8
PROCESOS EN TIEMPO REAL
PROCESOS EN TIEMPO REAL
PRACTICA 9
PARA ARRANCAR MAS PROCESOS DESDE LA CONSOLA
PARA ARRANCAR MAS PROCESOS DESDE LA CONSOLA
PRACTICA 10
CREACION DE UN FIFO
CREACION DE UN FIFO
PRACTICA 11
SE AGREGA UN PROCESO A UNA LISTA FIFO Y SE USA UNA TAREA LLAMADA CAT
SE AGREGA UN PROCESO A UNA LISTA FIFO Y SE USA UNA TAREA LLAMADA CAT
PRACTICA 12
VER LISTAS DE PROCESOS CREADOS
VER LISTAS DE PROCESOS CREADOS
PRACTICA 13
PREACTICA 14
PRACTICA 15
ARBOL DE PROCESOS NOS MUESTRA LOS PROCESOS PADRES CON SUS HIJO O HILOS
ARBOL DE PROCESOS NOS MUESTRA LOS PROCESOS PADRES CON SUS HIJO O HILOS
viernes, 21 de octubre de 2011
practica 2
codigo de practica
int cuenta= 0;
tipo_flag flag_lleno, flag_vacio;
tipo_cerrojo mutex;
productor()
{
int elemento;
while (1) {
producir_elemento(&elemento);
while (cuenta == N)
dormir(flag_lleno);
lock(mutex);
dejar_elemento(elemento);
cuenta= cuenta+1;
unlock(mutex);
if (cuenta == 1)
despertar(flag_vacio);
}
}
consumidor()
{
int elemento;
while (1) {
while (cuenta == 0)
dormir(flag_vacio);
lock(mutex);
retirar_elemento(&elemento);
cuenta= cuenta-1;
unlock(mutex);
if (cuenta == N-1)
despertar(flag_lleno);
consumir_elemento(elemento);
}
}
lock_lp (tipo_flag flag)
{
BOOL entrar= 0;
while (!entrar) {
lock(cerrojo_flags);
if (flag) {
unlock(cerrojo_flags);
dormir(flag);
}
else {
entrar= 1;
flag= 1;
unlock(cerrojo_flags);
}
}
}
unlock_lp (tipo_flag flag)
{
lock(cerrojo_flags);
flag= 0;
despertar(flag);
unlock(cerrojo_flags);
}
int cuenta= 0;
tipo_flag flag_lleno, flag_vacio;
tipo_cerrojo mutex;
productor()
{
int elemento;
while (1) {
producir_elemento(&elemento);
while (cuenta == N)
dormir(flag_lleno);
lock(mutex);
dejar_elemento(elemento);
cuenta= cuenta+1;
unlock(mutex);
if (cuenta == 1)
despertar(flag_vacio);
}
}
consumidor()
{
int elemento;
while (1) {
while (cuenta == 0)
dormir(flag_vacio);
lock(mutex);
retirar_elemento(&elemento);
cuenta= cuenta-1;
unlock(mutex);
if (cuenta == N-1)
despertar(flag_lleno);
consumir_elemento(elemento);
}
}
lock_lp (tipo_flag flag)
{
BOOL entrar= 0;
while (!entrar) {
lock(cerrojo_flags);
if (flag) {
unlock(cerrojo_flags);
dormir(flag);
}
else {
entrar= 1;
flag= 1;
unlock(cerrojo_flags);
}
}
}
unlock_lp (tipo_flag flag)
{
lock(cerrojo_flags);
flag= 0;
despertar(flag);
unlock(cerrojo_flags);
}
jueves, 13 de octubre de 2011
CARACTERISTICAS FIFO Y LIFO
TAREA # 1 SEGUNDO PARICIAL
CARACTERISTICAS FIFO Y LIFO
MEMORIAS FIFO
Son memorias serie en las que la primera información que entra es la primera que sale (First Input First Output), pueden implementarse con registros de desplazamiento estáticos y una unidad de
control. Esta última debe tener en cuenta las siguientes características de este tipo de memoria.
- La lectura es destructiva, es decir que al leer, el dato leído ya no está más en la memoria.
- Cada operación de lectura o escritura debe producir un desplazamiento del resto de la memoria.
- Cuando la memoria está llena no podrá escribirse, por lo tanto la Unidad de Control deberá ser
capaz de generar una señal de Memoria llena.
- Generar las señales de control necesarias para que el primer dato escrito esté disponible para la
primera lectura.
- Deberá aceptar al menos tres entradas exteriores: señal de lectura/escritura, señal de inicio de ciclo
y señal de sincronismo.
es normalmente empleada en los ordenadores para guardar datos cuando hay una solicitud de interrupción en el programa principal y luego volverlos a recuperar.
MEMORIAS FILO (LIFO)
En estas memorias al última información que entra es la primera que sale (Last Input First Output). Puede implementarse con un registro de desplazamiento reversible,.Un registro de desplazamiento reversible está formado por biestables síncronos y multiplexores. La salida de la memoria es la salida del primer biestable y la entrada es el segundo canal del primer multiplexor.
La inserción de una fifo resulta ideal como elemento de interconexión cuando dos sistemas que poseen información, cuyo flujo cuyo flujo presenta una cadencia o asíncrona deben inter cambiar datos. Los datos pueden introducirse o recuperarse ya sea en flujo uniforme, a ráfagas, irregular o incluso en una combinación de los citados.
martes, 4 de octubre de 2011
programa de examen
procesos con semaforos
implemente utilizando semaforos una solucion a esta variante del problema de los filosofos.hai f filosofos(f<=5);
y hay p palillos, que se pueden tomar en cualquier orden (no estan ordenados circularmente en la mesa). cuando un filosofo quiere comer, coge un par de pàlillos cuando quiera y cuando acaba de comer; los debuelve a la mesa.
sa solucion debe estar libre de interbloqueos
codigo
#include<unistd.h>
#include<semaphore.h>
#include<pthread.h>
#include<sys/times.h>
#define TRUE1
#define N5
#define LEFT(x)(((x)-1)%N)
#define RIGHT(X)(((X)+1)%N)
typedef struct
{
int value;
/* Lista de procesos. */
}
semaphore;
typedef enum
{
THINKING, HUNGRY, EATING
}
status;
/* Estado de cada filosofo. */
status estado[N];
/* Semaforo para exclusion mutua. */
semaphore mutex,
/* Semaforo para bloquear los filosofos adyacentes. */
s[N];
main ()
{
extern status estado[N];
extern semaphore mutex, s[N];
int i, sw = 1;
void Philosopher (int);
/* Inicializamos los semaforos. */
InitSemaphore (mutex, 1);
for (i = 0; i < N; i++)
InitSemaphore (s[i], 0);
/* Inicializamos los estados. */
for (i = 0; i < N; i++)
estado[i] = THINKING;
/* Inicializamos los filosofos. */
for (i = 0; (i < N) && (sw); i++)
if (!(sw = fork ()))
Philosopher (i);
}
void
Philosopher (int i)
{
void think (), eat (), TakeForks (int), PutForks (int);
while (TRUE)
{
think ();
/* Obtiene dos tenedores o se bloquea. */
TakeForks (i);
eat ();
PutForks (i);
}
}
void
TakeForks (int i)
{
void test (int);
extern semaphore mutex, s[N];
extern status estado[N];
/* Acceso a seccion critica. */
wait (mutex);
estado[i] = HUNGRY;
/* Intenta tomar los dos tenedores. */
test (i);
signal (mutex);
/* Se bloquea si no consiguio los tenedores. */
wait (s[i]);
}
void
PutForks (int i)
{
void test (int);
extern semaphore mutex;
extern status estado[N];
/* Acceso a seccion critica. */
wait (mutex);
estado[i] = THINKING;
/* Comprueba si el vecino izquierdo puede comer ahora. */
test (LEFT (i));
/* Comprueba si el vecino derecho puede comer ahora. */
test (RIGHT (i));
signal (mutex);
}
void
test (int i)
{
extern semaphore s[N];
extern status estado[N];
if (estado[i] == HUNGRY && estado[LEFT (i)] != EATING &&
estado[RIGHT (i)] != EATING)
{
estado[i] = EATING;
signal (s[i]);
}
}
#include<semaphore.h>
#include<pthread.h>
#include<sys/times.h>
#define TRUE1
#define N5
#define LEFT(x)(((x)-1)%N)
#define RIGHT(X)(((X)+1)%N)
typedef struct
{
int value;
/* Lista de procesos. */
}
semaphore;
typedef enum
{
THINKING, HUNGRY, EATING
}
status;
/* Estado de cada filosofo. */
status estado[N];
/* Semaforo para exclusion mutua. */
semaphore mutex,
/* Semaforo para bloquear los filosofos adyacentes. */
s[N];
main ()
{
extern status estado[N];
extern semaphore mutex, s[N];
int i, sw = 1;
void Philosopher (int);
/* Inicializamos los semaforos. */
InitSemaphore (mutex, 1);
for (i = 0; i < N; i++)
InitSemaphore (s[i], 0);
/* Inicializamos los estados. */
for (i = 0; i < N; i++)
estado[i] = THINKING;
/* Inicializamos los filosofos. */
for (i = 0; (i < N) && (sw); i++)
if (!(sw = fork ()))
Philosopher (i);
}
void
Philosopher (int i)
{
void think (), eat (), TakeForks (int), PutForks (int);
while (TRUE)
{
think ();
/* Obtiene dos tenedores o se bloquea. */
TakeForks (i);
eat ();
PutForks (i);
}
}
void
TakeForks (int i)
{
void test (int);
extern semaphore mutex, s[N];
extern status estado[N];
/* Acceso a seccion critica. */
wait (mutex);
estado[i] = HUNGRY;
/* Intenta tomar los dos tenedores. */
test (i);
signal (mutex);
/* Se bloquea si no consiguio los tenedores. */
wait (s[i]);
}
void
PutForks (int i)
{
void test (int);
extern semaphore mutex;
extern status estado[N];
/* Acceso a seccion critica. */
wait (mutex);
estado[i] = THINKING;
/* Comprueba si el vecino izquierdo puede comer ahora. */
test (LEFT (i));
/* Comprueba si el vecino derecho puede comer ahora. */
test (RIGHT (i));
signal (mutex);
}
void
test (int i)
{
extern semaphore s[N];
extern status estado[N];
if (estado[i] == HUNGRY && estado[LEFT (i)] != EATING &&
estado[RIGHT (i)] != EATING)
{
estado[i] = EATING;
signal (s[i]);
}
}
imprecion de pantalla
jueves, 29 de septiembre de 2011
miércoles, 28 de septiembre de 2011
posix
POSIX
(Portable Operating System Interface)
DEFINICION
Son una familia de estándares de llamadas al sistema operativo definidos por el IEEE y especificados 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.
Cuando el sistema operativo crea un proceso, el proceso en sí es un hilo de ejecución. Sin embargo se puede escribir un programa para crear muchos hilos que se ejecutan en el mismo espacio de memoria en forma paralela.
Los hilos POSIX son los más recomendables para emplear dado que son portables y tienen mejor desempeño que los procesos ligeros de UNIX.
La portabilidad de código permite que se pueda compilar y ejecutar el programa sobre otra plataforma que soporte hilos POSIX. De tal manera que el programador paraleliza su código insertando funciones de hilos POSIX, lo compila y lo ejecuta en una plataforma de un procesador o de múltiples procesadores (Por ej. en IRIX) y el mismo código lo puede compilar y ejecutar en otra plataforma (Por ej. en Solaris).
Con hilos POSIX se pueden paralelizar:
Llamadas a subrutinas o funciones.
E/S en C.
Algunas dependencias de datos usando herramientas de sincronización.
Los hilos POSIX no pueden paralelizar:
Ciclos individuales dentro de un programa (deben ser reescritos como funciones).
Pipas gráficas.
Ejemplo de uso de hilos POSIX:
/* hola.c
Programa que que genera 2 hilos POXIS para
imprimir a pantalla "hola mundo".
compilar:
cc hola.c -o hola -lpthread
*/
#include <pthread.h>
#include <stdio.h>
void* imprime_mensaje( void *ptr );
main()
{
pthread_t hilo1, hilo2;
char *mensaje1 = "hola";
char *mensaje2 = "mundo";
/* se generan 2 hilos que se ejecutaran en paralelo con el padre */
pthread_create(&hilo1, NULL, imprime_mensaje, (void*) mensaje1);
/* aquí el hilo padre puede estar haciendo otra cosa en paralelo con
los 2 hilos POSIX hijos */
/* por ejemplo: */
printf("A lo mejor esto se imprime primero... \n");
pthread_create(&hilo2, NULL, imprime_mensaje, (void*) mensaje2);
sleep(1);
exit(0);
}
void* imprime_mensaje( void *ptr )
{
char *mensaje;
mensaje = (char *) ptr;
printf("%s \n", mensaje);
pthread_exit(0);
}
Son una familia de estándares de llamadas al sistema operativo definidos por el IEEE y especificados 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.
Cuando el sistema operativo crea un proceso, el proceso en sí es un hilo de ejecución. Sin embargo se puede escribir un programa para crear muchos hilos que se ejecutan en el mismo espacio de memoria en forma paralela.
Los hilos POSIX son los más recomendables para emplear dado que son portables y tienen mejor desempeño que los procesos ligeros de UNIX.
La portabilidad de código permite que se pueda compilar y ejecutar el programa sobre otra plataforma que soporte hilos POSIX. De tal manera que el programador paraleliza su código insertando funciones de hilos POSIX, lo compila y lo ejecuta en una plataforma de un procesador o de múltiples procesadores (Por ej. en IRIX) y el mismo código lo puede compilar y ejecutar en otra plataforma (Por ej. en Solaris).
Con hilos POSIX se pueden paralelizar:
Llamadas a subrutinas o funciones.
E/S en C.
Algunas dependencias de datos usando herramientas de sincronización.
Los hilos POSIX no pueden paralelizar:
Ciclos individuales dentro de un programa (deben ser reescritos como funciones).
Pipas gráficas.
Ejemplo de uso de hilos POSIX:
/* hola.c
Programa que que genera 2 hilos POXIS para
imprimir a pantalla "hola mundo".
compilar:
cc hola.c -o hola -lpthread
*/
#include <pthread.h>
#include <stdio.h>
void* imprime_mensaje( void *ptr );
main()
{
pthread_t hilo1, hilo2;
char *mensaje1 = "hola";
char *mensaje2 = "mundo";
/* se generan 2 hilos que se ejecutaran en paralelo con el padre */
pthread_create(&hilo1, NULL, imprime_mensaje, (void*) mensaje1);
/* aquí el hilo padre puede estar haciendo otra cosa en paralelo con
los 2 hilos POSIX hijos */
/* por ejemplo: */
printf("A lo mejor esto se imprime primero... \n");
pthread_create(&hilo2, NULL, imprime_mensaje, (void*) mensaje2);
sleep(1);
exit(0);
}
void* imprime_mensaje( void *ptr )
{
char *mensaje;
mensaje = (char *) ptr;
printf("%s \n", mensaje);
pthread_exit(0);
}
jueves, 22 de septiembre de 2011
programa dos
DIBUJAR ARBOL
preguntas
¿Por que aparecen menajes repetidos?
R= aparecen por que se llama a la función FORK la cual hace procesos y los hijos son la copia exacta del primer proceso nada mas se diferencian por (PID y el espacio en memoria).
¿Que es lo que observas?
R= Observo el como trabaja las llamadas al sistema a partir de la función FORK el comportamiento del proceso padre se copia en la zona de memoria del proceso hijo.
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
¿Por que?
R= por que los procesos ejecutados desde el shell y la memoria esto es lo que genera a partir del código proporcionado. existe otra llamada al sistema que es clone es mucho más genérica y flexible que el fork, ya que nos permite definir qué van a compartir los procesos padre e hijo.
¿Por que aparecen menajes repetidos?
R= aparecen por que se llama a la función FORK la cual hace procesos y los hijos son la copia exacta del primer proceso nada mas se diferencian por (PID y el espacio en memoria).
¿Que es lo que observas?
R= Observo el como trabaja las llamadas al sistema a partir de la función FORK el comportamiento del proceso padre se copia en la zona de memoria del proceso hijo.
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
¿Por que?
R= por que los procesos ejecutados desde el shell y la memoria esto es lo que genera a partir del código proporcionado. existe otra llamada al sistema que es clone es mucho más genérica y flexible que el fork, ya que nos permite definir qué van a compartir los procesos padre e hijo.
lunes, 19 de septiembre de 2011
practica 1
programa 1
preguntas
1.-¿por que aparecen mensajes repetidos?
se llama la función fork, esta genera un duplicado del proceso actual. El duplicado comparte los valores actuales de todas las variables, ficheros y otras estructuras de datos. La llamada a fork retorna al proceso padre el identificador del proceso hijo y retorna un cero al proceso hijo.
2.-¿que observas?
que el proceso tiene un numero mayor que el padre como se muestra en la pantalla
2128
2127
2127
2126
2126
2103
3.-¿por que?
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
1. La función fork de la librería libc coloca los parámetros de la llamada
en los registros del procesador y se ejecuta la instrucción INT 0x80.
2. Se conmuta a modo núcleo y, mediante las tablas IDT y GDT, se llama
a la función sys_call.
3. La función sys_call busca en la sys_call_table la dirección de la
llamada al sistema sys_fork
SRANDOM
Funcion en c estadar llamada random(). Si quieres generar un numero aleatorio deberas utilizar srand() y rand(). Para hacer uso de ellas debes incluir stdlib.h
delay () o sleep ()
<windows.h> Sleep() // retraso en milisegundos
<dos.h> sleep() // retraso en segundos.
domingo, 11 de septiembre de 2011
google chrome y android
Google presentó Chrome OS
Como quedó clarísimo, el sistema operativo será 100% para trabajar con la nube. Nada de instalar aplicaciones en el sistema. Todo lo que haremos lo haremos a través de una pantalla que será prácticamente igual a la del actual navegador. De hecho, para que se den una idea del extremo al que lo llevaron, cuando conectemos una cámara digital se abrirá una pantalla de este “navegador” y nos mostrará qué hay dentro de ella.
Para realizar este OS la empresa se siguió basando en las típicas características que podemos ver en todos sus proyectos: simplicidad, velocidad y seguridad.
La simplicidad ya podrán imaginársela porque no habrá mucho más que la ventana de un navegador con el cual controlaremos todas las funciones del sistema operativo.
La velocidad, al manejar absolutamente todas las aplicaciones en la nube y solamente funcionar con discos SSD será extrema. De hecho, en la presentación oficial en Mountain View mostraron que desde que presionamos el botón de power hasta que nos pide que ingresemos nuestro nombre de usuario y contraseña tardó solamente 7 segundos y aseguraron que están haciendo todo lo posible para que este tiempo sea incluso menor.
Finalmente está la seguridad. Al no poder instalar sistemas binarios y aplicaciones externas no habrá nada más en el sistema que unos cuantos archivos de caché que sincronizarán con la nube. Esto quiere decir que no habrá sistemas que explotar más que el núcleo de Google Chrome y, como explicaron, el núcleo lo conocen suficientemente para poder arreglarlo en cuestión de horas.
La simplicidad ya podrán imaginársela porque no habrá mucho más que la ventana de un navegador con el cual controlaremos todas las funciones del sistema operativo.
La velocidad, al manejar absolutamente todas las aplicaciones en la nube y solamente funcionar con discos SSD será extrema. De hecho, en la presentación oficial en Mountain View mostraron que desde que presionamos el botón de power hasta que nos pide que ingresemos nuestro nombre de usuario y contraseña tardó solamente 7 segundos y aseguraron que están haciendo todo lo posible para que este tiempo sea incluso menor.
Finalmente está la seguridad. Al no poder instalar sistemas binarios y aplicaciones externas no habrá nada más en el sistema que unos cuantos archivos de caché que sincronizarán con la nube. Esto quiere decir que no habrá sistemas que explotar más que el núcleo de Google Chrome y, como explicaron, el núcleo lo conocen suficientemente para poder arreglarlo en cuestión de horas.
Otro de los temas más importantes es el hardware. Remarcaron que Chrome OS no podrá instalarse en cualquier ordenador, sino en los elegidos y desarrollados especialmente para este sistema. Si bien esto me parece una contra importantísima, la razón por la cual Google hace todo esto está clarísima: no quieren que el rendimiento sea menor al que aseguran. Si a un ordenador le ponemos un disco HDD en vez de uno SSD la velocidad se notará mucho y esto es lo que la empresa no quiere que suceda.
android
android es y seguira siendo un sistema de codigo abierto
El director de plataformas móviles de Google y responsable de Android, Andy Rubin, ha publicado un comunicado defendiendo que Android sigue siendo "una plataforma de código abierto" a la vez que ha prometido que "se liberará el código fuente cuando esté listo".
El revuelo generado por la decisión de Google de no facilitar por el momento el acceso al código fuente de la versión 3.0 de Android ha obligado a Andy Rubin a pronunciarse. Los desarrolladores privados han acusado a Google de limitar el sentido abierto de Android, pero Rubin ha explicado que "desde 2008 el Android ha crecido mucho" y asegura que desde Google "han mantenido el compromiso de fomentar el desarrollo de la plataforma".
La intención de la compañía es tener más control sobre el sistema en su fase inicial porque las prioridades de la compañía son "la calidad y la coherencia". El miedo de Google es que la adaptación del sistema a múltiples equipos haga peligrar la calidad del producto, provocando fallos de compatibilidad con aplicaciones de terceros.
Las palabras de Andy Rubin apuntan directamente a los experimentos de desarrolladores privados que habían intentado implantar la versión 3.0 de Android en 'smartphones'. En su día Google comentó que era un peligro porque por el momento el sistema no estaba optimizado para ello. Todo apunta a que para evitar este tipo de comportamientos, Google ha decidido no publicar su código.
Andy Rubin ha querido destacar que el sistema seguirá evolucionando. "Los fabricantes de dispositivos tienen libertad para modificar Android y personalizarlos a sus terminales", y ha confirmado que su equipo está "trabajando duro para llevar Honeycomb a los teléfonos", y cuando el trabajo esté hecho "publicarán el código".
El revuelo generado por la decisión de Google de no facilitar por el momento el acceso al código fuente de la versión 3.0 de Android ha obligado a Andy Rubin a pronunciarse. Los desarrolladores privados han acusado a Google de limitar el sentido abierto de Android, pero Rubin ha explicado que "desde 2008 el Android ha crecido mucho" y asegura que desde Google "han mantenido el compromiso de fomentar el desarrollo de la plataforma".
La intención de la compañía es tener más control sobre el sistema en su fase inicial porque las prioridades de la compañía son "la calidad y la coherencia". El miedo de Google es que la adaptación del sistema a múltiples equipos haga peligrar la calidad del producto, provocando fallos de compatibilidad con aplicaciones de terceros.
Las palabras de Andy Rubin apuntan directamente a los experimentos de desarrolladores privados que habían intentado implantar la versión 3.0 de Android en 'smartphones'. En su día Google comentó que era un peligro porque por el momento el sistema no estaba optimizado para ello. Todo apunta a que para evitar este tipo de comportamientos, Google ha decidido no publicar su código.
Andy Rubin ha querido destacar que el sistema seguirá evolucionando. "Los fabricantes de dispositivos tienen libertad para modificar Android y personalizarlos a sus terminales", y ha confirmado que su equipo está "trabajando duro para llevar Honeycomb a los teléfonos", y cuando el trabajo esté hecho "publicarán el código".
miércoles, 7 de septiembre de 2011
aspectos historicos del desarrollo de los Sistemas Operativos
Un sistema operativo es un conjunto de programas destinado a permitir el uso apropiado de las partes físicas del ordenador hardware, y de esta manera interactuar con el usuario. Los principales objetivos de los sistemas operativos es lograr que el sistema de computación se use de manera cómoda y que el hardware del computador se emplee de manera eficiente
Los primeros computadores eran grandes máquinas que se operaban desde una consola. El programador escribía un programa y luego lo controlaba directamente. el programa se cargaba manualmente en la memoria, desde los interruptores del tablero frontal, desde una cinta de papel o desde tarjetas perforadas. Luego se pulsaban los botones adecuados para establecer la dirección de inicio y comenzar la ejecución del
programa. Mientras este se ejecutaba, el programador-operador lo podía supervisar observando las luces en la consola.
programa. Mientras este se ejecutaba, el programador-operador lo podía supervisar observando las luces en la consola.
Con la creación de los circuitos LSI -integración a gran escala-, chips que contenían miles de transistores
en un centímetro cuadrado de silicio, empezó el auge de los ordenadores personales. En éstos se dejó un poco de lado el rendimiento y se buscó más que el sistema operativo fuera amigable, surgiendo menús, e
interfaces gráficas.
en un centímetro cuadrado de silicio, empezó el auge de los ordenadores personales. En éstos se dejó un poco de lado el rendimiento y se buscó más que el sistema operativo fuera amigable, surgiendo menús, e
interfaces gráficas.
TIPOS DE GESTION DE PROCESOS
Esto reducía la rapidez de las aplicaciones, pero se volvían más prácticos y simples para los usuarios. En esta época, siguieron utilizándose lenguajes ya existentes, como Smalltalk o C, y nacieron otros nuevos, de los cuales se podrían destacar: C++y Eiffel
dentro del paradigma de la orientación a objetos, y Haskell y Miranda en el campo de la programación declarativa.
SISTEMAS POR LOTES
El rasgo característico de un sistema por lotes es la ausencia de interacción entre el usuario y el trabajo mientras éste se ejecuta. El trabajo se prepara y se envía. Tiempo después aparece la salida.
TIEMPO COMPARTIDO
En estos sistemas los programas de los distintos usuarios residen en memoria. Al realizar una operación de E/S los programas ceden la CPU a otro programa, al igual que en la multiprogramación. Pero, a diferencia de ésta, cuando un programa lleva cierto tiempo ejecutándose el sistema operativo lo detiene para que se ejecute otra aplicación.
TIEMPO REAL
Estos sistemas se usan en entornos donde se deben aceptar y procesar en tiempos muy breves un gran número de sucesos, en su mayoría externos al ordenador. Si el sistema no respeta las restricciones de tiempo en las que las operaciones deben entregar su resultado se dice que ha fallado.
ARQUITECTURA DE UN SISTEMA OPERATIVO
Kernel monolítico:
La estructura de esta arquitectura es simplemente no tener ninguna. A nivel de núcleo no se produce ninguna abstracción, es decir, si un procedimiento necesita a otro es libre de hacerlo en cualquier momento. Fue el primer enfoque en la historia, el resto son evoluciones. Microkernel o micronúcleo:
En este caso, el S.O. se ocupa solo de unas pocas funciones, reduciendo el núcleo a su mínima expresión. El resto de funciones pasan a estar en el espacio de usuario.
Máquinas virtuales:
El primer sistema con esta esta arquitectura nació con la idea de separar completamente las dos funciones características de un S.O. de tiempo compartido: multiprogramación y un interfaz más apropiado que el del puro HW. El centro del sistema, también conocido como monitor de la máquina virtual, se ejecuta directamente sobre el propio HW, encargándose de la multiprogramación. De esta forma, ofrece al nivel superior varias máquinas virtuales, que son copias exactas del hardware, por lo que se puede dar el caso de ejecutar varios S.O. sobre cada una de ellas.
Suscribirse a:
Entradas (Atom)