Fushsia es una reconstrucción del sistema operativo Windows.
La organización de Object ha sido profundamente grabada en la médula ósea de Windows, y Fushsia, que también diseñó para el microkernel, ha heredado este diseño sin dudarlo.
El proceso de desarrollo del sistema operativo es que Windows y Linux encuentran constantemente sus limitaciones desde diferentes ángulos, y tratan de resolver estas limitaciones desde sus respectivas perspectivas. En este proceso de desarrollo, se han inventado innumerables remedios y nuevos mecanismos, pero tanto Windows como Linux son compatibles con las cosas viejas. La experiencia más importante acumulada en el proceso de evolución de Windows es cómo diseñar el microkernel. El proceso de evolución de Linux acumuló los requisitos principales para la contenedorización, como las líneas de estabilidad y aislamiento. Android ha diseñado un gran componente del sistema operativo fuera del núcleo, y la cooperación entre Android y Linux es muy fea, porque Android es equivalente a querer hacer algo que un núcleo no debería hacer en la capa de aplicación.
Cada sistema operativo está experimentando iteraciones dolorosas, cada uno enfrenta su propio punto de dolor. El mundo de Linux otorga gran importancia a los permisos y al aislamiento, pero los mecanismos que se agregaron gradualmente más tarde, como apparmor, selinux y cgroup, no son tan consistentes con el diseño original. Dado que la seguridad ha descubierto las ventajas de ACL, ¿por qué todavía necesitamos el concepto de derechos de usuario? Los recursos de aislamiento con memoria diferente se pueden agrupar y aislar ¿Por qué necesitamos una herencia de horquilla uniforme? Windows es conocido por sus gráficos, y Windows y el juego son ventajas reconocidas de Windows. ¿Cómo se forma su ventaja? ¿Cómo crear uno similar? Simplemente hablando, es porque maneja la fuente cerrada, pero la razón más profunda es aún más complicada.
Android es como un sistema experimental: espera lograr las ventajas de Windows en términos de gráficos (en términos generales, soporte de hardware) y, al mismo tiempo, envidiar el rico conjunto de características de Linux. Sabía desde el principio que no confiaría en Linux durante mucho tiempo, de lo contrario no se adoptaría la arquitectura Java. Si quiero evaluar Android, es que Android tiene más de un nivel arquitectónico de DEMO, verificando las ideas de diseño arquitectónico del sistema operativo. En cuanto a la implementación, es casi suficiente para apoyar este diseño arquitectónico. Para verificar este proceso, su núcleo solo puede usar Linux, no hay mejor opción. Sin embargo, Google siempre ha creído que Linux ha hecho demasiadas cosas que no debería hacer (mucha gente piensa que sí). De hecho, la causa raíz es que los acuerdos excesivos de código abierto impiden que otros ganen dinero.
Fushsia es un reemplazo de bajo nivel para Android. Pero este reemplazo no está en el código, sino en el nivel arquitectónico. Google rara vez juega al ajedrez en la dirección estratégica. Espera avanzar en varios campos mientras todos avanzan hacia el mismo gran objetivo tanto como sea posible. Este objetivo es un monopolio de código abierto de Windows. En todo el mundo de código abierto, Google espera comerse todo lo que esté río arriba y río abajo. Este enfoque requiere que los productos de código abierto de Google en todos los subsectores, dependan unos de otros, aprendan unos de otros, se ayuden y avancen juntos.
La primera opción es el microkernel o macrokernel. Básicamente no hay disputa. Como juguete entre empresas, el desacoplamiento es el primero. Para industrializarse rápidamente y permitir a los participantes realizar cambios independientes, el microkernel es casi la única opción. Antes de que el núcleo macro fuera Linus, nadie se atrevía a pensar en el éxito. Hasta el día de hoy, nadie puede comprender hasta dónde puede llegar este macro núcleo. El macro núcleo necesita un dictador, describe el liderazgo y dicta. Cuando te desvías, puedes sellar directamente tu camino. Todo el mundo Linux, dejando a Linus en sí, nadie tiene este prestigio (imagine cómo los tres hijos del emperador gobernaron el país).
Entre departamentos y empresas, los microkernels son más razonables. El microkernel es un kernel social, y el macrokernel es un kernel técnico. En términos de rendimiento, el microkernel no puede vencer al macrokernel de todos modos, porque el macrokernel es equivalente a cualquier cambio subdividido que requiera pruebas de integración. Cualquier subdivisión cambia dentro del marco general, incluido el estilo arquitectónico e incluso el estilo de codificación.
Por lo tanto, es fácil pensar en el sistema operativo ideal que se parece a la arquitectura de diseño de Android + microkernel. Este microkernel es solo una referencia directa a la experiencia exitosa de Windows. El diseño de Windows representa el nivel más alto de los sistemas operativos comerciales actuales. Cualquier equipo que no tenga éxito a nivel de producto no se atreverá a abandonar Windows en el diseño del microkernel. El diseño de la mayoría es aprender primero, y luego encontrar una manera de superar. Incluyendo Hongmeng ahora, la arquitectura de su microkernel también debe ser similar.
La arquitectura típica de microkernel de Windows es el diseño de objetos. Los recursos administrados por el núcleo son todos los objetos uno por uno, y cada objeto abierto tiene un identificador correspondiente. También es necesario organizar unidades de programación como subprocesos de proceso en el microkernel. Este tipo de arquitectura que se ha desarrollado hasta el sistema operativo no puede ser abandonado directamente por un nuevo sistema a menos que quiera terminar como IBM 360. La seguridad está unida al objeto. Se debe garantizar que el microkernel se incluya y solo se puede incluir, generalmente el código privilegiado del anillo 3. Para lograr el objetivo de ejecutar todo el código ring3 en el microkernel, muchas arquitecturas periféricas deben diseñarse en el kernel. Por ejemplo, el subproceso del proceso es una unidad de uso directo de recursos de la CPU. ¿La programación del espacio del usuario o el espacio del kernel? Esto no necesariamente tiene una respuesta definitiva, pero Fushsia decidió ponerlo en el núcleo, lo que significa que el mecanismo de comunicación entre procesos también debe estar en el núcleo. Windows ha agregado una interfaz de programación de espacio de usuario, pero eso no significa que el microkernel lo deje ir. El sistema operativo es un proceso que cambia dinámicamente juntos en el proceso de desarrollo de seguridad, facilidad de uso y conformidad con la organización social.
Un diseño muy maravilloso en Windows es Event, y un diseño similar en Linux es señal. Se puede decir que los dos son completamente diferentes, pero hay muchas similitudes desde el nivel filosófico. Después de pensar y practicar en profundidad, Google cree que los dos se pueden combinar. Las tres cosas de estado, evento y señal pueden resumirse en tres modelos: Objeto, Señal y Evento. Cada Objeto tiene 32 conjuntos de señales. El evento también es un Objeto. Se puede decir que es el Objeto más simple. Solo tiene 32 conjuntos de señales. Por lo tanto, el cambio del conjunto de señales del objeto representa el cambio de su estado. En otras palabras, las señales y los estados se coordinan en un concepto, que es un conjunto de señales en poder de un Objeto. La aparición de señales puede ser la ocurrencia de eventos. Google ha simplificado y vinculado varios diseños diferentes para extraer su esencia central. Conservando sus respectivas ventajas, se formaron los modelos de Objeto y Señal de Fushsia.
La seguridad bajo Windows también es un atributo de Object. Fushsia abandonó por completo el concepto de permisos de usuario de Linux a nivel de microkernel y cambió a permisos de Object para Windows. Aún más radicalmente, toda la virtualización se basa en permisos de objetos (más precisamente, HANDLE correspondiente al objeto). La mayor abstracción bajo Linux es que todo es un archivo, y la experiencia del microkernel es que todo es un objeto, incluida la unidad de proceso. Muchas llamadas al sistema Fushsia tienen que pasar a un MANGO de proceso, y este MANGO determina si la llamada al sistema tiene permiso para continuar. El último logro de Windows es la gran iteración de la tecnología de virtualización y sandbox, y Fushsia lo hizo directamente desde el nivel de diseño. Por lo tanto, Fushsia es más como una reconstrucción de un sistema Windows sin carga, conservando la mayoría de las ventajas de Windows.
Fushsia tiene ideas diferentes en muchos lugares. Por ejemplo, Windows ha sido criticado por escribir núcleos entre procesos como la cuna de muchos problemas de seguridad. Sin embargo, transferir HANDLE entre procesos es una función de transferencia de recursos muy útil en Windows. En Linux, un recurso abierto quiere ser transferido a otro proceso. En los primeros días, no había otra forma que no fuera la bifurcación. La tecnología SCM apareció más tarde, que era transferir directamente fd a través de Unix Domain Socket. Debido a que no puede predeterminar, el entorno que necesita pasar recursos son todas las relaciones de proceso padre-hijo. Un gran problema de diseño con Linux es que depende demasiado de la relación padre-hijo. El problema con Windows es que no depende demasiado de la relación padre-hijo, lo que resulta en una falta de organización efectiva entre los procesos. Las versiones recientes de Windows han prestado mucha atención a la organización de las relaciones entre procesos, y más o menos introdujeron el modelo de árbol de relaciones de proceso en Linux. En el proceso de acercamiento, ambas partes han violado gradualmente el diseño original. Hace que todo el sistema operativo se vea poco armonioso. Este problema es amplificado deliberadamente por Google en el sistema Android. Debido a que el sistema Android depende en gran medida de Binder, Binder es un diseño que intenta permitir que varios procesos se comuniquen e intercambien recursos fácilmente. Este diseño es difícil para Linux. Los requisitos para Linux son demasiado intensos. Linux siempre ha sido una dirección de desarrollo muy importante para el aislamiento del proceso de recursos, y Android hace lo contrario, lo que requiere que se abra la puerta entre los procesos. Leer el código de Binder facilita saber qué tan difícil es este sistema. Por el contrario, Binder es muy fácil de implementar en Windows, LPC es tan eficiente que puede escribir fácilmente su propio MANGO en la memoria de otro proceso entre procesos, y la transferencia de recursos es casi gratuita. Pero escribir directamente en el núcleo del proceso opuesto agrega complejidad a los permisos y la concurrencia. Por lo tanto, dado que Fushsia es el aterrizaje de la arquitectura de Android, naturalmente depende en gran medida de esta característica. Así que Fushsia puso directamente la idea del Canal implementado con éxito en Golang en Fushsia. Para pasar HANDLE, solo necesita poner HANDLE en el Canal. El proceso original pierde automáticamente el recurso, y el proceso opuesto al Canal obtiene automáticamente el recurso.
Aquí hay un problema, es decir, el bloque del núcleo en sí mismo también es un recurso, y HANDLE también es posible. Esta filosofía casi no se refleja en Linux. Android ha diseñado el ashmem muy duro para implementar su arquitectura. Utiliza el sistema de archivos de memoria para diseñar el bloque del kernel con asa. La gestión de memoria subyacente de Windows es con HANDLE, llamada Sección, una Sección es un bloque de 64 KB. Sin embargo, cuando Windows estuvo expuesto a la capa superior, aún no eligió usar directamente la sección para los usuarios, sino que la encapsuló. Pero en el microkernel está el camino de sección y su MANGO correspondiente. Se ha demostrado que este método puede administrar bloques de memoria y mapeo de archivos al mismo tiempo, y también puede proporcionar un mecanismo de asignación de memoria de nivel superior. Para el deseo de Android de HANDLE transfer de recursos, no hay razón para no aprender el mecanismo de la Sección de Windows. Fushsia está más lejos que Windows, y no usa directamente la sección de Windows, sino que diseñó creativamente el localizador, VMO y VMAR. También basados en objetos, la memoria continua y las páginas son más flexibles para los objetos abstractos, superando el problema de granularidad solucionado en Windows (predeterminado 64KB). Precisamente debido a una objetivación más sistemática, no se agregan atributos de estrategia a todo el diseño, por lo que la estrategia puede elevarse más allá del microkernel. En otras palabras, la parte de servicio del sistema operativo debería ser responsable de toda la administración de la memoria, pero la granularidad de la memoria corresponde al Objeto de hardware en el núcleo. Esta es otra gran mejora para los problemas de memoria en Windows.
La organización de tareas en Windows adopta cuatro dimensiones: trabajo, proceso, hilo y fibra. Este también es un conjunto completo de grupos de sesiones, grupos de procesos, subprocesos correspondientes a los procesos del núcleo, etc. que parecen ser muy incómodos. Fushsia también se mejora sobre la base de Windows. El proceso está organizado en trabajos, y hay hilos bajo el proceso.
Otro diseño impresionante en Windows es el puerto de finalización. Cuando se produce un gran número de eventos, el Puerto de finalización lo abstrae y envía un mensaje de paquete a un MANGO. En comparación con Linux, cosas similares usan epoll, ppoll y otros mecanismos de recopilación de eventos, Completion Port tiene un diseño muy limpio. La misma idea fue adoptada directamente por Fushsia, y se implementó "localizada".
En cuanto al bloqueo, cambiar de Windows a Linux después de trabajar durante mucho tiempo en el entorno Linux obviamente sentirá que el diseño de Windows es muy pobre. Como sistema operativo con la mayor participación de mercado en el lado del servidor, Linux maneja muy bien los problemas de concurrencia. Esto se refiere al nivel técnico, no al nivel arquitectónico. Una de las mayores ventajas es que Linux abstrae todas las implementaciones de bloqueo en una dependencia de las llamadas al sistema futex. El significado real de Futex no tiene nada que ver con el bloqueo, solo un mecanismo para esperar la condición y activar el hilo correspondiente, que es un mecanismo de sincronización de hilo simple. Linux logró hacer que todo tipo de bloqueos dependiera de un mecanismo de sincronización simple para lograr sus objetivos. Una buena Fushsia formal abstracta para aprender y aprender. En Windows, el proceso de usar Mutex, CriticalSection, RWLOCK, etc., es un proceso cruzado o en proceso. Las diferentes actuaciones son todas cajas negras e independientes. Obviamente, esto no es lo que debería ser un microkernel. Pero si el microkernel de Windows proporciona un mecanismo similar al futex para admitir la implementación de bloqueos de capa superior, esto no está claro para mí, no lo he mirado a la inversa. De todos modos, no me gusta mucho el diseño de bloqueo en Windows.
En términos de algoritmos de programación, la industria del sistema operativo está haciendo una transición gradual a la programación justa, especialmente Linux. Fushsia no puede referirse a Windows, porque nadie conoce los detalles, y la práctica de ingeniería a largo plazo de Linux ha resultado factible. Ya sabes, la programación inicial de Linux fue regañada a cada paso. No es fácil obtener la experiencia acumulada ahora.
El aislamiento es un problema al que se enfrentan Windows y Linux. El servidor inicia primero una fuerte demanda de aislamiento. El grado de demanda puede describirse como revolucionario. Durante un tiempo, la tecnología de virtualización de Linux surgió y floreció. Porque Linux soportó esto unos años antes que Windows. Todo se redujo a una idea productiva de Linux, una tecnología de virtualización LXC que alguna vez se consideró sin sentido por casualidad. Puede decir muchas ventajas de la virtualización del desarrollo de Linux, pero sin el LXC como tecnología olvidada, es probable que el primer Docker no haya tenido el coraje de lanzar, y no habrá primavera después. Windows se ha puesto al día en los últimos años, tratando de ponerse al día y superar las ventajas de Linux en la virtualización. Al mismo tiempo, con su fuerte demanda de aislamiento en la tecnología UWP, Windows ha creado su propio aislamiento y ha tratado de erosionar Linux. No se han escatimado esfuerzos en el desarrollo de la tecnología WSL. Fushsia ve el poder de la virtualización, y la experiencia de Android le ha dicho a Google que no solo el servidor sino también el cliente tienen requisitos más estrictos para el aislamiento, porque el aislamiento de Fushsia es un diseño profundo que refleja todo La refactorización del aislamiento de la arquitectura. Por lo general, no existe un sistema de archivos en el nivel del sistema operativo con el que estamos familiarizados. No hay un directorio raíz, y cada proceso solo puede ver su propio directorio privado. Fork se ha eliminado por completo, incluso Windows tiene que estar asombrado de ello. Windows todavía permite que Object herede entre creaciones de procesos, por lo que Windows es un soporte selectivo para el concepto de fork, pero es mucho menos que la herencia completa de Linux. El proceso secundario en Linux tiene que restar el proceso primario. Algunos cambios harán que la resta no se reduzca a menudo y habrá muchos problemas de seguridad. El diseño de Fork no está diseñado para el aislamiento, por el contrario, comparte completamente datos e incluso canales lógicos. Es un diseño antiaislamiento completo. Fushsia ha rediseñado completamente esto, y el nuevo proceso es un contenedor seco y silencioso. La nueva tecnología como Windows UWP, sandbox completo, elimina la posibilidad de escapar desde la parte inferior. Windows también estaría muy envidioso de la capacidad de Fushsia de llevar a cabo directamente un diseño de caja de arena pura muy radical sin equipaje histórico.
Otros campos similares incluyen TLS, DMA, registro, interrupciones, etc. Ambos se están rediseñando para encontrar un equilibrio óptimo de uso y arquitectura con una serie de necesidades en el proceso de uso de Linux, Windows, Android y sus horribles formas de satisfacción. Se puede decir que el microkernel Zircon de Fushsia es un diseño arquitectónico que se adapta mejor a todas las aplicaciones de escenarios actuales. El número de llamadas al sistema es muy pequeño, Linux se ha simplificado, pero la carga histórica es grave, y el microkernel de Windows hace que sea imposible distinguir el nivel de las llamadas al sistema, lo que resulta en una API muy caótica. Zircon tuvo un buen comienzo, proporcionando un conjunto de llamadas al sistema, pero entregó mucho trabajo al servicio. El servicio también es un muy buen concepto en Windows, y es un componente esencial de coincidencia del microkernel. La arquitectura de Android ha diseñado una gran cantidad de servicios, como SurfaceFlinger, Zygo, etc., y hay una falta de expresión efectiva de los servicios en Linux. Porque muchas de las unidades lógicas del núcleo de macros que deberían ser servicios se convierten en subprocesos del núcleo, pero no están completas. El macro kernel de Linux hace muchos servicios por sí solo, pero no es lo suficientemente completo y es imposible de completar. Todavía necesita servicios de espacio de usuario para completarlo. Por ejemplo, systemd intenta organizar los servicios de Linux de manera unificada, pero varios objetivos y procesos de inicio, administración de servicios y dependencias hacen que todo el sistema sea extremadamente complicado. Mi diseño personal para el lado del servicio de Linux siempre ha sido despectivo, porque siempre ha habido una comparación de Windows. Sin embargo, no se puede decir que el servicio de Windows no sea un problema. Muchos software maliciosos utilizan el servicio para hacer muchas cosas que afectan la experiencia, Apple lo controla muy bien. Se puede decir que Windows es un sistema con excelente diseño e implementación a nivel arquitectónico, pero la velocidad de respuesta es demasiado lenta, lo que es mucho menos adaptable que Linux. Y el propio control de Microsoft de este sistema no es fuerte, lo que resulta en que los usuarios a veces sean controlados por software malicioso. Y Apple es demasiado fuerte, todos se sienten controlados por Apple. El diseño de Android es un equilibrio, el aislamiento y el control son perfectos. Puede ser fuertemente controlado por un OEM, o puede estar completamente descontrolado. Es un diseño social muy flexible. Por el contrario, la versión empresarial de conceptos similares de Windows, la organización puede controlar cosas muy limitadas y, básicamente, la aplicación solo es interna de la empresa. Capacidades similares de entrega de la organización, Microsoft es reacio a dar a nadie, por lo que es demasiado abierto. Sin embargo, se ha endurecido recientemente. Apple también es reacio a dárselo a nadie, así que
Lo que Google imagina es una gran arquitectura social que puede extenderse, ser de código abierto, ganar dinero, ganar dinero para sí misma y ganar dinero para otros. Google conoce muy bien el poder del modelo de código abierto y la poderosa influencia del mundo de código cerrado. Más atributos sociales son los factores más importantes que hacen que Google se destaque. Porque él "castigado".
En el nivel del controlador, Zircon incluso ha abierto llamadas del sistema para el manejo de interrupciones del programa del usuario. El nivel del núcleo es equivalente a la delegación directa de la capa de aplicación al controlador, pero no a la aplicación, sino al DDK. Marco. Uno de los mayores beneficios que Android brinda a Google es una comprensión profunda del mundo de la conducción. DDK es un diseño que extrae la sublimación y luego vuelve a aterrizar. Siempre pienso que Windows es el objeto del aprendizaje de la arquitectura de Zircon, y Linux es un buen objeto para verificar la lógica del algoritmo, y también es un buen libro de texto. Android es un intento, una verificación del diseño arquitectónico y la acumulación de aprendizaje social. El objetivo es el diseño final unificado. La interfaz principal de llamadas IPC de todo Fushsia es FIDL (o "Lenguaje de definición de interfaz fucsia" ), Esta expresión descriptiva de IPC es exactamente la misma que la carpeta. Los conceptos de Componente, capacidad de captación y manifestación también son el modo de desarrollo de la verificación de Android (la capacidad de captación no está clara si hay alguna referencia a Linux). Con la promoción gradual de Flutter, Android y Windows verifican paso a paso la eficacia del modelo de Fushsia. El punto del sistema de archivos es que Linux y Windows no son buenos. Fushsia tiene su propio diseño, pero no puedo comentar si es lo suficientemente bueno. Me temo que tenemos que esperar al aterrizaje real para saberlo. En este punto, Windows tiene innumerables fallas, el elevador de Linux y el diseño de caché no es bueno, Fushsia ciertamente puede hacerlo mejor, después de todo, rediseño, referencia completa. Pero creo que será mejor verlo más tarde. Por ejemplo, el ashmem utilizado por Android tiene la misma función para simular vergüenza en Windows, y también depende del sistema de archivos tmp existente en Linux. Fushsia apareció directamente MemFS este sistema de archivos a medida. Volumen Manager es muy bueno en Linux, pero es terrible en Windows. Fushsia también ha sido rediseñado. El concepto de montaje de Mount es una función básica en Linux. Este diseño es tan excelente. Ahora Windows también está aprendiendo. Cuando Windows ingresa al campo de la virtualización, considera necesario montar un sistema de archivos en un directorio en otro disco. La sexualidad también produce la tecnología correspondiente. Este tipo de diseño, que fue inventado por un sistema (y no se puede decir que fue inventado por Linux) y adoptado por Windows, naturalmente no se lo perderá Fushsia. La implementación del sistema de archivos de red en Linux y Windows no es buena, pero cada uno tiene sus propias ventajas. Google ha notado la aplicación del protocolo 9P en WSL, pero el aterrizaje de 9P se ha convertido en una charla en papel de alta latencia. La ruta de desarrollo similar de Fushsia usa la interfaz descriptiva y el concepto de establecer conexiones que tanto Windows como Android ahora usan para el diseño de IO, y el efecto aún no se ha evaluado. Estoy muy preocupado por el error de 9P. Hay muchos ingenieros idealistas en Windows y Google que prestan demasiada atención a la integridad de la arquitectura y ya han realizado muchos trabajos "mágicos". El alto nivel de su arquitectura a menudo puede ocultar la fealdad de la implementación. Pero a nivel de rendimiento, no puede ser cubierto. El proceso de rendimiento, en la mayoría de los casos, es un proceso destructivo que destruye constantemente la bella arquitectura. Hago performance, realmente entiendo esta oración.
La pantalla es una de las fallas más grandes en el campo de Linux. Afortunadamente, hay algo de recuperación de Android, pero también es un gran esfuerzo. La presentación orgullosa de Windows es el resultado de una profunda colaboración de personalización de Directx a los controladores y del software al hardware. Esto generalmente tiene una gran motivación empresarial. Linux en sí mismo no tiene este tipo de motivación, y los teléfonos móviles sí. Fushsia, naturalmente, concede gran importancia a este campo de la vida y la muerte. La gran cantidad de experiencia de renderizado acumulada en Android hace que Fushsia sea plenamente consciente de la independencia de la parte de renderizado. El aislamiento de Android del diseño de SurfaceFlinger y la representación de la ontología del juego hace que la representación tradicional de un solo subproceso sea muy engorrosa. Esta arquitectura es, naturalmente, un producto del período de transición, y Vulkan y Directx12 están abandonando esta arquitectura. El subsistema de representación en sí es responsable de la programación de tareas y la gestión de la memoria, un problema que ha sido reconocido por las arquitecturas de representación modernas. Desde el nivel arquitectónico o el sistema operativo demasiada intervención en el proceso de renderizado, el daño es mucho mayor que el beneficio, porque el renderizado es un área de primer desempeño, no importa cuán bella sea su arquitectura, existe una fuerte motivación para rendirse frente al desempeño. Con el desarrollo altamente estratégico del almacenamiento en caché de la cola de comandos, la programación de tareas y la gestión de la memoria, como Vulkan y Directx12, Fushsia, como un sistema operativo de la nueva era, hizo concesiones conscientes al renderizado. Deje que el subsistema de representación pueda emprender un trabajo cada vez más autónomo. No solo eso, las tecnologías de computación gráfica como Direct Compute han hecho que el nivel de programación de la CPU sea consciente de las deficiencias en la computación, y la computación también será prevista en el futuro por la tubería de renderizado. La batalla entre la propia CPU y la GPU vio la primera concesión de control a nivel de software.
Fushsia es un sistema operativo de nueva era, su nacimiento se basa casi en la dolorosa base de Windows y Linux. Lo que está cambiando es la necesidad: si la arquitectura puede adaptarse mejor a las necesidades que cambian rápidamente es una garantía importante para el desarrollo a largo plazo del sistema operativo. Ahora que Linux y Windows son anticuados, todavía insisten en actualizar, innovar constantemente y atravesar el tiempo para satisfacer las necesidades de la sociedad. Windows y Linux son como dos hermanos. Cuando la sociedad necesita el sistema operativo, cuando Linux no puede soportarlo, Linux es la parte superior. Donde Linux no puede sostenerse, la parte superior es Windows. En el proceso de iteración, ambas partes finalmente dividieron la capa de dominio gradualmente. Linux es más adecuado para el lado del servidor, y Windows es más adecuado para el lado del cliente. Es mejor decir que Linux ha elegido dar prioridad a la satisfacción del lado del servidor en el proceso de satisfacer la demanda, e incluso el embebido está casi perdido. En el proceso de elegir satisfacer la demanda, Windows eligió dar prioridad para satisfacer al cliente. Ambos miraron el territorio del otro y se negaron a perder la esperanza.
Fushsia se basó en el desarrollo y posicionamiento de dos sistemas operativos, y los dos directores de Bocai llevaron a cabo un rediseño sobre los hombros de los gigantes. Esta vez, no es DEMO, ni Java. Esta vez, el objetivo de Google es lo máximo. Quería terminar el debate sobre el sistema operativo aquí. Creo que el diseño de Hongmeng no puede ir más allá de Fushsia. Si todos los días salen de la era, obviamente no es la persona de esta era. Nadie puede sobrevivir más allá de los tiempos. La evolución de la tecnología debe basarse en las tecnologías existentes a nivel filosófico, de diseño y de innovación. Si Fushsia es una innovación para Windows y Linux, creo que Hongmeng debería innovar sobre la base de la filosofía de Fushsia. Debido a que no hay ninguna razón para que Google resuma, la propiedad de alta calidad obtenida a través de experimentos y descubrimientos no se puede heredar. Es una opción razonable modificar sobre esta base. Las diferentes arquitecturas que surgieron de la nada fueron reescritas por completo. Yo personalmente no lo apruebo o no lo creo. Espera a que abra el código fuente.
