En la conferencia Build 2016 de Microsoft, inaugurada el miércoles, la compañía de Redmond anunció algo que rompe bastante con la tradición de los sistemas operativos de escritorio. Bash, la consola de comandos de Ubuntu –una de las distribuciones de Linux más usuales– podrá ser ejecutada de forma nativa en Windows 10 a partir de una próxima actualización.
Bash es una combinación de consola de comandos y lenguaje de programación que permite ejecutar y crear programas por medio de líneas de comando, y es una de las herramientas más poderosas de la distribución de Linux. Con esta nueva funcionalidad será posible instalar y correr aplicaciones de Linux en entornos Windows sin hacer nada más. Lo logra, básicamente, ‘traduciendo’ los comandos de Linux a órdenes que Windows puede entender. No es un emulador, ni un servicio creado por terceros. Es un soporte nativo.
En el nivel de la tecnología de consumo quizás esto no parece muy interesante, pues la mayoría de servicios populares están disponibles en Windows y solo muy pocos de ellos están en el sistema operativo del pingüino. Pero esto sí les va a hacer la vida más fácil a los creadores de software, pues –como dice Scott Hansleman, un desarrollador empleado de Microsoft, en una publicación en su blog– «elimina una barrera significativa para los desarrolladores que quieren o necesitan usar herramientas de Linux como parte de su flujo de trabajo«.
Desde siempre, Linux y Windows eran vistos como antagonistas, pues eran estandartes de filosofías opuestas: los sistemas cerrados, por una parte, y el código abierto, por otra. «Este no es un momento que hubiéramos podido predecir«, le dijo a The Wall Street Journal Mark Shuttleworth, el fundador de Canonical, la empresa que desarrolla Ubuntu.
La idea es facilitarles la vida a los desarrolladores
Por eso, este es uno de los movimientos de apertura más radicales que el Microsoft de Nadella ha hecho. La compañía ahora está enfocada en prestar servicios en cualquier entorno, sin importar si es Windows o no. La estrategia, dice Wired, es «hacer que Windows sea el principal lugar en el que los programadores puedan desarrollar aplicaciones para una amplia variedad de plataformas, desde Linux hasta Android o iOS«.
Por ahora, la herramienta no es de código abierto. Será lanzada a mediados de año, junto con la actualización de aniversario de Windows 10.
Imagen: ENTER.CO.
ahh? me perdí.
«Con esta nueva funcionalidad será posible instalar y correr aplicaciones de Linux en entornos Windows sin hacer nada más»
el sistema operativo tiene varias partes, una es el núcleo del sistema, otra es el shell o intérprete de comandos, otra son los drivers etc. lo que corre los programas es una combinación del núcleo,q ue administra los procesos, el mismo procesador, el bios que vienen con procesos comunes que los programas pueden llamar etc. el shell carga los programas, pero no los ejecuta, sino se los pone en la entrada al núcleo para que el núcleo los despache, e inicia el despacho por parte del núcleo.
‘bash’ es uns hell, lo mismo que unity o gnome, sólo que unity o gnome funcionan con ventanas, y bash con líneas de texto, equivalente al ‘command.com’ de windows o dos. ni unity ni gnome corren los programas en linux, bash tampoco; sólo se entiende con el usuario para pasarle mensajes als istema, y poner en fila los programas que deben ser despachado y demás. poner bash en windows sería lo mismo que decir que ahora hay un intérptete de comnados equivalente al command .com en linux, y que ahora en vez de rm nombre_archivo, se le dice del nombre_archivo. lo súnicos ‘programas’ que corre el bash son listas de comandos dentro de un archivo textomarcado como ejecutable, igual que los .bat de dos
que si más adelante o ahora puede correr programas nativos de linux, tal vez, pero no tiene nada qué ver con poner un intérprete equivalente al bash*
editado: y por cierto, si no quedó claro, el shell NO es el corazón del sistema, así que el título ‘El corazón de Ubuntu llega a Windows’ no corresponde; de hecho los shells se pueden reemplazar a gusto del usuario, por cualquier otro (así como la gente discute sobre unity vs gnome y unos ponen uno y ottros otro)
*editado 2: en realidad es al revés; linux corre algunos programas escritos para dos y otras cosas, windows no corre nada de linux (hasta ahora, y no estamos hablando de virtualización)
Por lo que vi en un video es como tener una imagen de Ubuntu (sin interfaz grafica) montada en Windows y desde dicha imagen poder ejecutar todos los comandos como ls, pwd, emacs, vi, vim ssh etc etc etc. Dentro de eso imagino que estara disponible apt para poder bajar mas aplicaciones claro esta que no se podria bajar todas las aplicaciones sino solo aquellas que esten compiladas para Windows.
Haria la misma funcionaldiad de proyectos ya existentes coo Cygwin que permiten ejecutar aplicaciones/comandos de Linux en Windows.
en todo caso no es lo que dicen acá; no es coger un programa delinux y correrlo en windows; es simplemente una cosa que interpreta comandos de texto y si existe un equivalente en windows, correr ese comando sobre windows (que esmuy diferente). sobre cygwin tampoco se trata de eso. cygwin es coger fuentes de linux (o unix), que nativamente no se pueden compilar sobre windows porque no existen las librerías en windows, y suplir unos sustitutos, para poder armar el ejecutable, como nativo de windows, pero llamando librer´ñias que actúan como sustitutos delas librerías de linux (para aclarar si alguien lee esto y no sabe qué es cygwin). tampoco sería coger un programa delinux y correrlo para windows, sino coger fuentes delinux y crear un programa para windows a partir de esas fuentes, como ejecutable
Pero es que Cygwin no es solo para compilar cosas, es un conjunto de herramientas y dentro de esas herramientas estan muchos de los programas/utilidades/comandos de Linux. Osea usted instala Cygwin y podra instalar herramientas como tar, busybox, emacs, vim, grep, awk etc etc ademas de tener una shell, existe un repositorio de muchas herraminetas que se puede bajar. Varias eran nativas de Linux y las portaron para poder ser usadas en Windows y la idea de todo eso es poder usar esas aplicaciones combinadas con otras para hacer programas mas potentes. Por ejemplo en el video donde mostraron eso nuevo un man habria Emacs para poder editar una pagina web, igual con Cygwin puede instalar Emacs y editar paginas.
El problema del articulo es que dice que se puede coger cualquier programa de Linux instalarlo y correrlo cosa que no es verdad, lo que harian es igual que con Cgywin tener un repositiorio de aplicaciones precompiladas para Windows y solo esas aplicaciones son las que se podran usar pero teniendo todo el conjunto de aplicaciones mas el shell seria como usar una distribucion linux sin interfaz grafica
mi punto era lo que ud menciona en el segundo párrafo. de acuerdo con eso, no es coger un programa d elinux y correrlo en windows, que eslo que dan a entender acá
re-editado: y en el caso de bash, a diferencia de cygwin, tampoco es utilizar funcionalidad de linux; es ejecutar listas de comnados que de otra forma se meterían en la línea de comandos (que está lejos de ser el corazón del sistema)
Como no me gusta hablar de lo que no tengo conocimiento, esta es la explicación que encontré en un blog de Windows:
Finalmente uno de los rumores que surgieron horas antes de la primera presentación de la Build 2016 es real: Linux estará integrado en Windows 10, más en concreto una consola Linux. En la presentación se ha mostrado cómo exploraban el directorio de Windows desde la consola, acceder a servidores remotos vía SSH o lanzar editores emacs para trabajar sobre el código de las aplicaciones universales.
Para lograr esto Microsoft se ha aliado con Canonical, empresa encargada de desarrollar Ubuntu, con el fin de traer a los desarrolladores de Linux a Windows 10. Este bash no corre en una máquina virtual, es una versión de Ubuntu que corre sobre Windows con todas las herramientas propias de Linux como awk, sed, grep, etc.
si no tiene conocimiento (así al parecer se la pase criticando lo que no conoce), se lo pongo de esta forma, recuerda el dos? el dos no era realmente un s.o, sino más bien un sistema de manejo de archivos y una colección de programas sueltos, pero realmente no hacía nada de gestión de procesos. cada programa se apropiaba del computador y hacía lo que quería, sin que el sistema interviniera en lo que podía hacer o no hacer. sin embargo tenía ‘comandos’. como acabo de decir, esos comandos en gran parte eran programas sueltos. había un programa para comparar archivos, otro para hacer debug y otras cosas. eso fue lo que hicieron acá. cogieron un poco de programas sueltos que ejecutan funciones específicas en entornos unix y los pasaron a windows. grep es un programa que usa cadenas de texto como filtro para hacer búsquedas de texto sobre la entrada, emacs es un editor de texto, al igual que cada una de las cosas que ud puso arriba. son programas sueltos que ahora tiene traducción a windows (en realidad la han tenido desde hace buen tiempo, incluso como menciona tuxerito vienen para correr dentro de cygwin). aparte de eso, hay otro programa, que en dos era conocido como command. com. el command .com no ejecutaba los programas, pero era el que se encargaba de ponerlos a ejecutar, y también podía correr varios programas en secuencia leyendo una lista que estuviera en un archivo de texto terminado en .bat. acá es lo mismo, ud hace un archivo de texto llamando diferentes programas sueltos a manera delista, y esos son los ‘programas’ que corre el shell. en realidad no son ejecutables, es simplemente una lista de comandos. eso fue lo que ‘tradujeron’ a windows. siq uiere correr cosas delinux, y no es con virtualización, una posibilidad es compilarlos para windows con los archivos fuente, y corriéndolos dentro de cygwin. eso sería lo más parecido, pero un ejecutable de linux no le va a correr en windows
No , eso no fue lo que se hizo. Se re-habilito el subsistema Posix que otrora permitía a executable ELF de unix correr en Windows, este subsistema luego se volvio opcional y luego quedo relegado a opcional solo en algunas gamas de Windows Server. Ahora se ha vuelto a habilitar este subsistema y se ha actualizado al conjunto de llamados Posix modernos (al menos a la mayoria pero aun falta trabajo por hacer). Windows siempre ha soportado subsistemas by-design. Los binarios ELF corren en Windows, las llamadas al kernel Linux funcionan en Windows siendo traducidas por el subsistema a llamadas al kernel de Windows. No es solo un bash, eso no seria noticia bash para windows existen varios y hace rato. Microsoft no gana nada haciendo un bash inútil. Este movimiento permite que todo el ecosistema de development tools, especialmente web development, el cual se desarrollo mucho en OSX en los últimos años pueda correr en Windows sin necesidad de portar proyectos, ni de crear nuevas versiones. Redis, Ruby y sus gemas, Node & packages , Git scripts y muchas mas tools correrán en Windows sin problema y permitirán a los desarrolladores utilizar en Windows todas las herramientas disponibles. En el corto plazo de seguro toda la estrategia de portabilidad que esta ejecutando Microsoft se verá fuertemente beneficiada…
jejeje lo dejaste calladito al android lover
Al contrario no he criticado nada, como se poco y nada de Linux por eso no opine y me limite a copiar un articulo que me dio mas claridad del tema, y mas claridad me dio su explicación con la comparación con DOS y me trajo esos recuerdos de tener ese listado de comandos impresos para abrir una carpeta, ver el directorio, formatear un disquete, cambiar de unidad, defragmentar
Los comentarios de @VooDooChicken:disqus respecto a DOS tambien son bastante desafortunados… si que es/era un OS corriendo en modo real, si tenia gestión de procesos , memoria etc… tenía todo. Lo que no tenía era diferenciación entre modo kernel y modo usuario y todo el sw se ejecutaba bajo un mismo conjunto de privilegios, privilegios completos, pero tambien en las versiones finales era un OS multitarea y multiprocesos… m uy regularcito pero suficiente para sus fines… ud critica a @carlosmolina_co:disqus porque no tiene idea de lo que habla, pero usted tampoco tiene mucha idea más allá de lo superficial.
hmm.. otro comentario de este personaje donde escupe términos que en la mayoría de los casos ni siquiera tienen qué ver con el tema, entonces debe ser cierto
de wikipedia, entrada ‘dos’, párrafo ‘design’:
«DOS is a single-user, single-tasking operating system with basic kernel functions that are non-reentrant:
only one program at a time can use them and DOS itself has no
functionality to allow more than one program to execute at a time. The
DOS kernel provides various functions for programs (an application program interface), like character I/O, file management, memory management, program loading and termination.
DOS by default provides a primitive ability for shell scripting, via batch files (with the filename extension .BAT).
These are text files that can be created in any text editor. They are
executed in the same fashion as compiled programs, and run each line of
the batch file as a command. Batch files can also make use of several
internal commands, such as GOTO and conditional statements.[27] GOSUB and simple arithmetic is supported with the DR DOS COMMAND.COM as well as some with third-party shells like 4DOS; however, no real form of programming is usually enabled.»
puede mostrar una sóla reseña donde pruebe que el dos soportaba multitarea o multiprocesos? y que la ‘gestión de memoria’ no consistía en algo más allá de soportár más de 640k?
ud dijo que no era un OS.. en su último quote dice claramente que si lo es… su pregunta de multitarea tiene una respuesta: Multitasking cooperativo. Y gestionar 640k tambien se llama gestionar memoria o me va a decir que no? DOS 4.0 soporto multitasking en un par de escenarios adicionales y por su fuera poco versiones posteriores de DOS (hasta la 8) aumentadas con todas las gamas de Windows over DOS si que hicieron multitasking. Ademas preogramas corriendo on-Top of DOS como por ejemplo Windows 3.1 podian usar multitasking cooperativo para ejecutar multiples tareas a la vez. DOS quedo como parte del loader y otras tareas incluyendo drivers y de ahí mismo atado a muchisimos videojuegos en todos los Win 95,98,ME y XP hasta SP1. Windows posteriores dejaron el kernel DOS para pasar al Kernel WinNT. NO dejemos de lado el hecho de que usted quiere desviar el tema, UD dijo > no maneja memoria ni procesos tan falso que usted mismo copio donde dice que si lo es , claro que los manejaba y tenia rutinas para hacerlo así fueran en su forma más básica. Hay que aprender la definición de Multitasking… que no tiene nada que ver co el hecho de que las versiones non-win de DOS solo ejecutaban un proceso a la vez…
Finalmente no estoy escupiendo, no tengo la culpa que usted **se ponga grosero** cada vez que alguien lo pone en su sitio. Por no mencionar todo lo que ha dicho del «simple interprete de texto windows» que como lo veo se ha quedado calladito…
dos tenía soporte para multitasking cooperativo? esa no me la sabía,pero bueno aprendí algo ya que no es sólo escupir términos que ni tienen qué ver cone l tema. y también las aplicaciones le pedían emmoria al sistema y le asignaba memoria que no fuera usada por otro programa, ya que podía correr varios programas al tiempo.. bueno, debo reconocer que no me las sé todas.. es aparte también es nueva para mí.. incluyendo lo dl dos 4.. aunque tal vez se refiere a un dos 4 que no era la versión 4 del dos, y que no tuvo qué ver siquiera con m$.. pero bueno, no era simplemente enumerar babosadas no relacionadas, por suerte
No relacionadas? si usted no puede ver la relación entre las cosas que ha afirmado y mis comentarios al respecto entonces definitivamente no tiene ni idea, ni la más mínima idea, de lo que habla. El DOS 4 real multitasking si fue el de ms.
Muy equivocados todos, las syscalls de Linux estarán soportadas en Windows (de nuevo pues hace años POSIX 1.X era un subsistema soportado por Windows) así que lo que se vino es más grande de lo que creen, ustedes pueden correr un apt-get si lo desean y por ejemplo ejecutar la versión re Redis para Linux sin problema desde Windows… no se como pueden interpretar la información como si simplemente fuera una consola bash, eso no tendría ninguna gracia. 1. Son binarios ELF reales 2. Las llamadas al sistema de Linux son manejadas por el kernel de Windows 3. Se puede instalar lo que uno quiera , adicionar sus propias fuentes y hacer apt-get desde allí 4. Si un proceso linux abre un puerto ningún proceso Windows puede usarlo
@VooDooChicken:disqus : Que ud no sepa como redirigir la salida en Windows a otros dispositivos o programas no quiere decir que no lo soporte… ejemplo:
dir c: /s /b | find «LOG» | more
o un ejemplo con powershell
Get-ChildItem -Path C:WINDOWSSystem32 | Out-Host -Paging
ahh? me perdí.
«Con esta nueva funcionalidad será posible instalar y correr aplicaciones de Linux en entornos Windows sin hacer nada más»
el sistema operativo tiene varias partes, una es el núcleo del sistema, otra es el shell o intérprete de comandos, otra son los drivers etc. lo que corre los programas es una combinación del núcleo,q ue administra los procesos, el mismo procesador, el bios que vienen con procesos comunes que los programas pueden llamar etc. el shell carga los programas, pero no los ejecuta, sino se los pone en la entrada al núcleo para que el núcleo los despache, e inicia el despacho por parte del núcleo.
‘bash’ es uns hell, lo mismo que unity o gnome, sólo que unity o gnome funcionan con ventanas, y bash con líneas de texto, equivalente al ‘command.com’ de windows o dos. ni unity ni gnome corren los programas en linux, bash tampoco; sólo se entiende con el usuario para pasarle mensajes als istema, y poner en fila los programas que deben ser despachado y demás. poner bash en windows sería lo mismo que decir que ahora hay un intérptete de comnados equivalente al command .com en linux, y que ahora en vez de rm nombre_archivo, se le dice del nombre_archivo. lo súnicos ‘programas’ que corre el bash son listas de comandos dentro de un archivo textomarcado como ejecutable, igual que los .bat de dos
que si más adelante o ahora puede correr programas nativos de linux, tal vez, pero no tiene nada qué ver con poner un intérprete equivalente al bash*
editado: y por cierto, si no quedó claro, el shell NO es el corazón del sistema, así que el título ‘El corazón de Ubuntu llega a Windows’ no corresponde; de hecho los shells se pueden reemplazar a gusto del usuario, por cualquier otro (así como la gente discute sobre unity vs gnome y unos ponen uno y ottros otro)
*editado 2: en realidad es al revés; linux corre algunos programas escritos para dos y otras cosas, windows no corre nada de linux (hasta ahora, y no estamos hablando de virtualización)
editado 3: por cierto, lección rápida de programación y de unix. cuando se hace un programa en ‘c’ a veces (o generalmente) se usan cosas como stdio. (o entrada y salida estándard), o en c++ cosas como cout. resulta que a diferencia de lo que uno hace cuando está aprendiendo, cout no necesariamente significa ‘la pantalla’, sino ‘la salida del programa’. resulta que els istema puede redirigir esa salida por ejemplo, para otro dispositivo, o como entrada para otro programa. eso se llama ‘piping’, o extender tubería entre procesos. si el windows no soporta eso, pues no sirve de mucho que haya un comnado que le diga que haga eso no?
Por lo que vi en un video es como tener una imagen de Ubuntu (sin interfaz grafica) montada en Windows y desde dicha imagen poder ejecutar todos los comandos como ls, pwd, emacs, vi, vim ssh etc etc etc. Dentro de eso imagino que estara disponible apt para poder bajar mas aplicaciones claro esta que no se podria bajar todas las aplicaciones sino solo aquellas que esten compiladas para Windows.
Haria la misma funcionaldiad de proyectos ya existentes coo Cygwin que permiten ejecutar aplicaciones/comandos de Linux en Windows.
en todo caso no es lo que dicen acá; no es coger un programa delinux y correrlo en windows; es simplemente una cosa que interpreta comandos de texto y si existe un equivalente en windows, correr ese comando sobre windows (que esmuy diferente). sobre cygwin tampoco se trata de eso. cygwin es coger fuentes de linux (o unix), que nativamente no se pueden compilar sobre windows porque no existen las librerías en windows, y suplir unos sustitutos, para poder armar el ejecutable, como nativo de windows, pero llamando librer´ñias que actúan como sustitutos delas librerías de linux (para aclarar si alguien lee esto y no sabe qué es cygwin). tampoco sería coger un programa delinux y correrlo para windows, sino coger fuentes delinux y crear un programa para windows a partir de esas fuentes, como ejecutable
Pero es que Cygwin no es solo para compilar cosas, es un conjunto de herramientas y dentro de esas herramientas estan muchos de los programas/utilidades/comandos de Linux. Osea usted instala Cygwin y podra instalar herramientas como tar, busybox, emacs, vim, grep, awk etc etc ademas de tener una shell, existe un repositorio de muchas herraminetas que se puede bajar. Varias eran nativas de Linux y las portaron para poder ser usadas en Windows y la idea de todo eso es poder usar esas aplicaciones combinadas con otras para hacer programas mas potentes. Por ejemplo en el video donde mostraron eso nuevo un man habria Emacs para poder editar una pagina web, igual con Cygwin puede instalar Emacs y editar paginas.
El problema del articulo es que dice que se puede coger cualquier programa de Linux instalarlo y correrlo cosa que no es verdad, lo que harian es igual que con Cgywin tener un repositiorio de aplicaciones precompiladas para Windows y solo esas aplicaciones son las que se podran usar pero teniendo todo el conjunto de aplicaciones mas el shell seria como usar una distribucion linux sin interfaz grafica
mi punto era lo que ud menciona en el segundo párrafo. de acuerdo con eso, no es coger un programa d elinux y correrlo en windows, que eslo que dan a entender acá
re-editado: y en el caso de bash, a diferencia de cygwin, tampoco es utilizar funcionalidad de linux; es ejecutar listas de comnados que de otra forma se meterían en la línea de comandos (que está lejos de ser el corazón del sistema)
Como no me gusta hablar de lo que no tengo conocimiento, esta es la explicación que encontré en un blog de Windows:
Finalmente uno de los rumores que surgieron horas antes de la primera presentación de la Build 2016 es real: Linux estará integrado en Windows 10, más en concreto una consola Linux. En la presentación se ha mostrado cómo exploraban el directorio de Windows desde la consola, acceder a servidores remotos vía SSH o lanzar editores emacs para trabajar sobre el código de las aplicaciones universales.
Para lograr esto Microsoft se ha aliado con Canonical, empresa encargada de desarrollar Ubuntu, con el fin de traer a los desarrolladores de Linux a Windows 10. Este bash no corre en una máquina virtual, es una versión de Ubuntu que corre sobre Windows con todas las herramientas propias de Linux como awk, sed, grep, etc.
si no tiene conocimiento (así al parecer se la pase criticando lo que no conoce), se lo pongo de esta forma, recuerda el dos? el dos no era realmente un s.o, sino más bien un sistema de manejo de archivos y una colección de programas sueltos, pero realmente no hacía nada de gestión de procesos. cada programa se apropiaba del computador y hacía lo que quería, sin que el sistema interviniera en lo que podía hacer o no hacer. sin embargo tenía ‘comandos’. como acabo de decir, esos comandos en gran parte eran programas sueltos. había un programa para comparar archivos, otro para hacer debug y otras cosas. eso fue lo que hicieron acá. cogieron un poco de programas sueltos que ejecutan funciones específicas en entornos unix y los pasaron a windows. grep es un programa que usa cadenas de texto como filtro para hacer búsquedas de texto sobre la entrada, emacs es un editor de texto, al igual que cada una de las cosas que ud puso arriba. son programas sueltos que ahora tiene traducción a windows (en realidad la han tenido desde hace buen tiempo, incluso como menciona tuxerito vienen para correr dentro de cygwin). aparte de eso, hay otro programa, que en dos era conocido como command. com. el command .com no ejecutaba los programas, pero era el que se encargaba de ponerlos a ejecutar, y también podía correr varios programas en secuencia leyendo una lista que estuviera en un archivo de texto terminado en .bat. acá es lo mismo, ud hace un archivo de texto llamando diferentes programas sueltos a manera delista, y esos son los ‘programas’ que corre el shell. en realidad no son ejecutables, es simplemente una lista de comandos. eso fue lo que ‘tradujeron’ a windows. siq uiere correr cosas delinux, y no es con virtualización, una posibilidad es compilarlos para windows con los archivos fuente, y corriéndolos dentro de cygwin. eso sería lo más parecido, pero un ejecutable de linux no le va a correr en windows
@VooDooChicken No , eso no fue lo que se hizo. Se re-habilito el subsistema Posix que otrora permitía a executable ELF de unix correr en Windows, este subsistema luego se volvio opcional y luego quedo relegado a opcional solo en algunas gamas de Windows Server. Ahora se ha vuelto a habilitar este subsistema y se ha actualizado al conjunto de llamados Posix modernos (al menos a la mayoria pero aun falta trabajo por hacer). Windows siempre ha soportado subsistemas by-design. Los binarios ELF corren en Windows, las llamadas al kernel Linux funcionan en Windows siendo traducidas por el subsistema a llamadas al kernel de Windows. No es solo un bash, eso no seria noticia bash para windows existen varios y hace rato. Microsoft no gana nada haciendo un bash inútil. Este movimiento permite que todo el ecosistema de development tools, especialmente web development, el cual se desarrollo mucho en OSX en los últimos años pueda correr en Windows sin necesidad de portar proyectos, ni de crear nuevas versiones. Redis, Ruby y sus gemas, Node & packages , Git scripts y muchas mas tools correrán en Windows sin problema y permitirán a los desarrolladores utilizar en Windows todas las herramientas disponibles. En el corto plazo de seguro toda la estrategia de portabilidad que esta ejecutando Microsoft se verá fuertemente beneficiada…
jejeje lo dejaste calladito al android lover
Al contrario no he criticado nada, como se poco y nada de Linux por eso no opine y me limite a copiar un articulo que me dio mas claridad del tema, y mas claridad me dio su explicación con la comparación con DOS y me trajo esos recuerdos de tener ese listado de comandos impresos para abrir una carpeta, ver el directorio, formatear un disquete, cambiar de unidad, defragmentar
Los comentarios de @VooDooChicken:disqus respecto a DOS tambien son bastante desafortunados… si que es/era un OS corriendo en modo real, si tenia gestión de procesos , memoria etc… tenía todo. Lo que no tenía era diferenciación entre modo kernel y modo usuario y todo el sw se ejecutaba bajo un mismo conjunto de privilegios, privilegios completos, pero tambien en las versiones finales era un OS multitarea … muy regularcito pero suficiente para sus fines… ud critica a @carlosmolina_co:disqus porque no tiene idea de lo que habla, pero usted tampoco tiene mucha idea más allá de lo superficial.
hmm.. otro comentario de este personaje donde escupe términos que en la mayoría de los casos ni siquiera tienen qué ver con el tema, entonces debe ser cierto
de wikipedia, entrada ‘dos’, párrafo ‘design’:
«DOS is a single-user, single-tasking operating system with basic kernel functions that are non-reentrant:
only one program at a time can use them and DOS itself has no
functionality to allow more than one program to execute at a time. The
DOS kernel provides various functions for programs (an application program interface), like character I/O, file management, memory management, program loading and termination.
DOS by default provides a primitive ability for shell scripting, via batch files (with the filename extension .BAT).
These are text files that can be created in any text editor. They are
executed in the same fashion as compiled programs, and run each line of
the batch file as a command. Batch files can also make use of several
internal commands, such as GOTO and conditional statements.[27] GOSUB and simple arithmetic is supported with the DR DOS COMMAND.COM as well as some with third-party shells like 4DOS; however, no real form of programming is usually enabled.»
puede mostrar una sóla reseña donde pruebe que el dos soportaba multitarea o multiprocesos? y que la ‘gestión de memoria’ no consistía en algo más allá de soportár más de 640k?
ud dijo que no era un OS.. en su último quote dice claramente que si lo es… su pregunta de multitarea tiene una respuesta: Multitasking cooperativo. Y gestionar 640k tambien se llama gestionar memoria o me va a decir que no? DOS 4.0 soporto multitasking en un par de escenarios adicionales y por si fuera poco versiones posteriores de DOS (hasta la 8) aumentadas con todas las gamas de Windows over DOS si que hicieron multitasking. Además programas corriendo on-Top of DOS como por ejemplo Windows 3.1 podían usar multitasking cooperativo para ejecutar múltiples tareas a la vez. También estaba el tema de TSR que permitia en DOS tener los famosos procesos residentes en memoria, el equivalente moderno a un servicio en segundo plano, estos tenían tiempo de procesamiento disparado por una interrupción que era soportada en DOS y que permitía cambios de contexto para que estos procesos se pudieran ejecutar en segundo plano sin que los usuario lo notaran… en Win >9x DOS quedo como parte del loader y otras tareas incluyendo drivers y de ahí mismo atado a muchisimos videojuegos en todos los Win 95,98,ME y XP hasta SP1. Windows posteriores dejaron del kernel DOS para pasar al Kernel WinNT. NO dejemos de lado el hecho de que usted quiere desviar el tema, UD dijo > no maneja memoria ni procesos tan falso que usted mismo copio donde dice que si lo es , claro que los manejaba y tenia rutinas para hacerlo así fueran en su forma más básica. Hay que aprender la definición de Multitasking… que no tiene nada que ver con el hecho de que las versiones non-win de DOS solo ejecutaban un proceso a la vez…
Finalmente no estoy escupiendo, no tengo la culpa que usted **se ponga grosero** cada vez que alguien lo pone en su sitio.
dos tenía soporte para multitasking cooperativo? esa no me la sabía,pero bueno aprendí algo ya que no es sólo escupir términos que ni tienen qué ver cone l tema. y también las aplicaciones le pedían emmoria al sistema y le asignaba memoria que no fuera usada por otro programa, ya que podía correr varios programas al tiempo.. bueno, debo reconocer que no me las sé todas.. es aparte también es nueva para mí.. incluyendo lo dl dos 4.. aunque tal vez se refiere a un dos 4 que no era la versión 4 del dos, y que no tuvo qué ver siquiera con m$.. pero bueno, no era simplemente enumerar babosadas no relacionadas, por suerte
No relacionadas? si usted no puede ver la relación entre las cosas que ha afirmado y mis comentarios al respecto entonces definitivamente no tiene ni idea, ni la más mínima idea, de lo que habla. El DOS 4 real multitasking si fue el de ms.
. @VooDooChicken Muy equivocados todos, las syscalls de Linux estarán soportadas en Windows (de nuevo pues hace años POSIX 1.X era un subsistema soportado por Windows) así que lo que se vino es más grande de lo que creen, ustedes pueden correr un apt-get si lo desean y por ejemplo ejecutar la versión re Redis para Linux sin problema desde Windows… no se como pueden interpretar la información como si simplemente fuera una consola bash, eso no tendría ninguna gracia. 1. Son binarios ELF reales 2. Las llamadas al sistema de Linux son manejadas por el kernel de Windows 3. Se puede instalar lo que uno quiera , adicionar sus propias fuentes y hacer apt-get desde allí 4. Si un proceso linux abre un puerto ningún proceso Windows puede usarlo
@VooDooChicken:disqus : Que ud no sepa como redirigir la salida en Windows a otros dispositivos o programas no quiere decir que no lo soporte… ejemplo:
dir c: /s /b | find «LOG» | more
o un ejemplo con powershell
Get-ChildItem -Path C:WINDOWSSystem32 | Out-Host -Paging