Subpage under development, new version coming soon!
Subject: Experimentar Linux
Bueno, fueron 25 minutos en total, pero ahí se logueó!
gracias!
gracias!
Bueno, me alegro. Pero igual 25 minutos es muchísimo!
Igual la cagada me la mandé yo porque cuando lo instalaste te tendría que haber dicho que uses Reiserfs en lugar de ext3 como sistema de archivos. Todo esto se hubiera evitado. :-S
Igual la cagada me la mandé yo porque cuando lo instalaste te tendría que haber dicho que uses Reiserfs en lugar de ext3 como sistema de archivos. Todo esto se hubiera evitado. :-S
El tipo de sistema de archivos no lo podés modificar porque tendrías que formatear la partición (y reinstalar Ubuntu). Lo que podés hacer es deshabilitar los chequeos al inicio. Para eso ejecutá el comando "mount" y te va a aparecer algo así:
/dev/sda5 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
De ahí, la que te interesa es la primera línea (la que dice "on /" y "ext3"). Lo que te interesa es el valor de la primer columna (en este caso /dev/sda5).
Después ejecutá lo siguiente:
sudo tune2fs -c 0 -i 0 /dev/sda5 <--- reemplazá esto último por lo que te haya dado el comando mount.
Ahí lo que hiciste es decirle al sistema que no haga más chequeos del filesystem en el inicio.
Cualquier duda avisá! ;-)
/dev/sda5 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
De ahí, la que te interesa es la primera línea (la que dice "on /" y "ext3"). Lo que te interesa es el valor de la primer columna (en este caso /dev/sda5).
Después ejecutá lo siguiente:
sudo tune2fs -c 0 -i 0 /dev/sda5 <--- reemplazá esto último por lo que te haya dado el comando mount.
Ahí lo que hiciste es decirle al sistema que no haga más chequeos del filesystem en el inicio.
Cualquier duda avisá! ;-)
Jejeje, lo que pasa es que yo soy de la vieja escuela y aprendí todo con comandos. Ahora es mucho más fácil y seguro que hay que abrir una ventanita y destildar la opción que dice "no chequear al principio", pero no se explicar paso a paso como llegar hasta ahí, entonces lo explico de la forma difícil. :-S
Yo se que de esa forma no voy a ganar muchos adeptos a Linux, pero es lo que hay. :-(
(edited)
Yo se que de esa forma no voy a ganar muchos adeptos a Linux, pero es lo que hay. :-(
(edited)
Yogurtu, uds. que es el más capo jipi...
Yo instalé el virtualbox (una masa loko) y tengo una máquina virtual con XP funcionando joya dónde hago los proyectos .NET de la facultad.
También instalé otra máquina virtual con un RTOS con el cual estuve probando como controlar dispositivos de tiempo real. Joya...
Ahora necesito instalar una máquina virtual con el Leopard, el último SO de Mac para poder ver cuanto me complicaría la vida aprender a programar aplicaciones para el maldito IPHONE y poder entregar un presupuesto.
Tenés idea de lo que te estoy preguntando?
Yo instalé el virtualbox (una masa loko) y tengo una máquina virtual con XP funcionando joya dónde hago los proyectos .NET de la facultad.
También instalé otra máquina virtual con un RTOS con el cual estuve probando como controlar dispositivos de tiempo real. Joya...
Ahora necesito instalar una máquina virtual con el Leopard, el último SO de Mac para poder ver cuanto me complicaría la vida aprender a programar aplicaciones para el maldito IPHONE y poder entregar un presupuesto.
Tenés idea de lo que te estoy preguntando?
Las máquinas virtuales no son lo mío, pero se de que me hablás. Según tengo entendido, el Leopard no funciona en Virtualbox, pero si lo hace en VMWare. No se cuales son los motivos, pero yo al menos probaría de instalarlo en Virtualbox y ver con que problemas me encuentro.
Ahora te pregunto yo a vos. Cómo corno hace un sistema RTOS para manejar tiempo real en una máquina virtual instalada sobre un sistema de tiempo compartido? Ya escuché a varias personas que lo han usado así, pero nadie me supo explicar como funciona (para mi es imposible).
Ahora te pregunto yo a vos. Cómo corno hace un sistema RTOS para manejar tiempo real en una máquina virtual instalada sobre un sistema de tiempo compartido? Ya escuché a varias personas que lo han usado así, pero nadie me supo explicar como funciona (para mi es imposible).
Yogurtu, yo pensaba exactamente lo mismo, pero el profesor, capo di tutti di capo, me dijo que haga la prueba y luego me explicaba....
A ver si es que le entendí bien: Los RTOS se manejan en muchos casos casi igual al resto de los SO. O sea, tienen partición de memoria, manejo muy particular del RounRobin (ya no me acuerdo si se escrcibe así) y manejo exclusivo de todos los dispositivos I/O por asignación de punteros directos a memoria.
La fragmentación o partición dinámica de la memoria es con paginación pero sin usar disco rígido.
Es ahí que no me cerraba, por que se supone que los sistemas virtualizados usan disco con lo cual las interrupciones para llamar a la controladora del disco ya lo harían imposible de ser un RTOS.
Pero vaya mi sorpresa al ver que carga el RTOS en memoria y ya no accede a disco si no hasta que el mismo RTOS hace la llamada.
Lo que sí me explicó el profesor es que para hacer una máquina virtual de un RTOS es necesario tener un micro multi core, como el que tiene mi Notebook que con un giga de ram se la re-banco.
De ahí que el profesor nos felicitó (la materia ya la tenía aprobada hace un año, simplemente me acerque con la inquietud y nos propuso hacer un trabajo de investigación) escribimos el paper para la facultad y el mismo fue cajoneado ya que la puta facultad está casada con Mircrosoft y esto no lo lograron hacer funcionar con el Virtual PC y Winkk
A ver si es que le entendí bien: Los RTOS se manejan en muchos casos casi igual al resto de los SO. O sea, tienen partición de memoria, manejo muy particular del RounRobin (ya no me acuerdo si se escrcibe así) y manejo exclusivo de todos los dispositivos I/O por asignación de punteros directos a memoria.
La fragmentación o partición dinámica de la memoria es con paginación pero sin usar disco rígido.
Es ahí que no me cerraba, por que se supone que los sistemas virtualizados usan disco con lo cual las interrupciones para llamar a la controladora del disco ya lo harían imposible de ser un RTOS.
Pero vaya mi sorpresa al ver que carga el RTOS en memoria y ya no accede a disco si no hasta que el mismo RTOS hace la llamada.
Lo que sí me explicó el profesor es que para hacer una máquina virtual de un RTOS es necesario tener un micro multi core, como el que tiene mi Notebook que con un giga de ram se la re-banco.
De ahí que el profesor nos felicitó (la materia ya la tenía aprobada hace un año, simplemente me acerque con la inquietud y nos propuso hacer un trabajo de investigación) escribimos el paper para la facultad y el mismo fue cajoneado ya que la puta facultad está casada con Mircrosoft y esto no lo lograron hacer funcionar con el Virtual PC y Winkk
Pero sigue siendo una maquina virtual, y sigue siendo un programa interrumpible como cualquier otro programa que este corriendo en linux, sinceramente no me cierra :P. Me quedo del lado del ipi en este caso.
Por definicion el RTOS debe dar una respuesta en un tiempo limite acotado, en el momento que lo pones en una maquina virtual, deja de ser RTOS. Por ahi sirve para alguna que otra prueba de juguete.
Salute
Por definicion el RTOS debe dar una respuesta en un tiempo limite acotado, en el momento que lo pones en una maquina virtual, deja de ser RTOS. Por ahi sirve para alguna que otra prueba de juguete.
Salute
A ver, al tener la PC doble núcleo, lo que hace que tenga dos procesadores, deja uno de los procesos en modo prioritario. Al instalar el RTOS uno al virtual box, le señala que es un RTOS con lo cual ya le asigna procesamiento prioritario, lo cual lo logramos chequear ya que al ver los procesos que estaban corriendo en linux, el virtual box corriendo el RTOS quedaba siempre en primer plano sin aceptar interrupciones desde linux.
O sea, el principio de toda máquina virtual es la de mapear un área de memoria como si fuera una PC propia que no acepta o si, dependiendo de la configuración, interrupciones desde el SO que corre la máquina virtual.
O sea, el principio de toda máquina virtual es la de mapear un área de memoria como si fuera una PC propia que no acepta o si, dependiendo de la configuración, interrupciones desde el SO que corre la máquina virtual.
Si no entendí mal, vos tenés un Ubuntu y sobre él una Virtualbox con varios S.O., entre ellos un RTOS.
No se si tenés la posibilidad de repetir el experimento, pero en caso de que sea posible, hacé lo siguiente (o preguntale a tu profe que pasaría). Poné a correr el Virtualbox con el RTOS y dentro de ese RTOS ponete a controlar los procesos de tiempo real. Después en el Ubuntu ejecutá algún proceso que use muchos recursos (por ejemplo renderizar varios ejemplos de Blender) y fijate si el RTOS sigue ejecutándose de la misma forma o si anda más lento.
(edited)
No se si tenés la posibilidad de repetir el experimento, pero en caso de que sea posible, hacé lo siguiente (o preguntale a tu profe que pasaría). Poné a correr el Virtualbox con el RTOS y dentro de ese RTOS ponete a controlar los procesos de tiempo real. Después en el Ubuntu ejecutá algún proceso que use muchos recursos (por ejemplo renderizar varios ejemplos de Blender) y fijate si el RTOS sigue ejecutándose de la misma forma o si anda más lento.
(edited)
La prueba que hicimos fue, corriendo el RTOS y controlando 4 dispositivos que eran del tipo puerta de ascensor, sensores de paso o no de algo. En el UBUNTU nos pusimos a correr varios procesos, un video y música.
El problema era que se ralentizaba el UBUNTU y no el RTOS.
O el video se veía entrecortado.... Pero el control de apertura y cierre de puertas según la interrupción del haz de luz seguía funcionando correctamente.
Cómo puede ser? Pues el RTOS tomaba control absoluto de uno de los cores y dejaba el otro core para el UBUNTU.
Recuerden que QNX no tiene tanta pretensiones gráficas. En sí ni levantamos la interfaz gráfica ya que ejecutamos el monitor de las I/O y el controlador de los dispositivos.
El problema era que se ralentizaba el UBUNTU y no el RTOS.
O el video se veía entrecortado.... Pero el control de apertura y cierre de puertas según la interrupción del haz de luz seguía funcionando correctamente.
Cómo puede ser? Pues el RTOS tomaba control absoluto de uno de los cores y dejaba el otro core para el UBUNTU.
Recuerden que QNX no tiene tanta pretensiones gráficas. En sí ni levantamos la interfaz gráfica ya que ejecutamos el monitor de las I/O y el controlador de los dispositivos.
Si perfecto, pero lo que no me cierra (es muy posible que este equivocado porque estoy hablando desde el punto teorico mas que practico) que el virtual box sigue siendo un proceso cualquiera del linux, con pid y un nice level y un aging y toda la bola de linux. Y hasta donde yo se, va a seguir compartiendo CPU, y el esquema va a seguir siendo Round Robin (creo que se manejaba con Round Robin + Aging, pero hace mucho que hice la materia :P). Y eso implica que la virtual machine corre riesgo de ser despachada tarde o temprano. Y si es despachada, ya existe la posibilidad que el RTOS deje de responder a cualquier interrupcion en un tiempo finito y acotado, y si pasa eso, ya no es RTOS.
Por ahi hay alguna forma de asegurar que un proceso no sea despachado, pero dudo ya que eso abriria demasiadas puertas de seguridad.
Pero bueno, como dije, nunca hice nada practico en un RTOS, solo hice alguna que otra cosa que responde en tiempo real, pero era todo circuiterio e integrados.
Salute
Por ahi hay alguna forma de asegurar que un proceso no sea despachado, pero dudo ya que eso abriria demasiadas puertas de seguridad.
Pero bueno, como dije, nunca hice nada practico en un RTOS, solo hice alguna que otra cosa que responde en tiempo real, pero era todo circuiterio e integrados.
Salute
Si lo que vos decis es cierto, estas asegurando que hay una forma en linux (o en un sistema unix) de poder apropiarse de un CPU y no devolverlo nunca mas.
No linux, el RTOS y me lo acaba de explicar mejor el especialista acá en AySA que es el que administra los servidores que la mayoría son virtuales.
El tema se divide en:
1) Los micros y mother actuales manejan la memoria en forma directa entre el micro y RAM
2) Los RTOS "capturan" los recursos y cuando puede se los devuelve al SO que está por debajo
3) QNX está preparado para blindar o asegurar sus recursos de procesamiento de Round Robin por prioridades en cascada sin acceso a disco. (de hecho nuestro programa no lo necesitaba)
4) Las máquinas virtuales actules, VMWARE nuevos y Virtual Box nuevo, trabajan sobre memoria dinámica y asignación por protección de la máquina virtual. De ahí que no es afectada por el SO que está por debajo. Trabajan por anillos de RAM.
Todo esto, sumado a la robustes de los RTOS para manejo de dispositivos I/O con acceso directo a RAM hacen que un RTOS funcione mejor en una máquina virtual que sobre el hardware directo.
El tema se divide en:
1) Los micros y mother actuales manejan la memoria en forma directa entre el micro y RAM
2) Los RTOS "capturan" los recursos y cuando puede se los devuelve al SO que está por debajo
3) QNX está preparado para blindar o asegurar sus recursos de procesamiento de Round Robin por prioridades en cascada sin acceso a disco. (de hecho nuestro programa no lo necesitaba)
4) Las máquinas virtuales actules, VMWARE nuevos y Virtual Box nuevo, trabajan sobre memoria dinámica y asignación por protección de la máquina virtual. De ahí que no es afectada por el SO que está por debajo. Trabajan por anillos de RAM.
Todo esto, sumado a la robustes de los RTOS para manejo de dispositivos I/O con acceso directo a RAM hacen que un RTOS funcione mejor en una máquina virtual que sobre el hardware directo.