Los teléfonos móviles apestan!

Aquí vamos de nuevo, otra perorata acerca de los sistemas operativos móviles.

Estoy harto de Android. Pero no hay alternativa para mí en este momento. Así que tengo que gemir. Para hacer esta gimiendo más constuctive, vamos a repasar lo que odio de Android, lo que me gusta de otros sistemas operativos, y lo que yo quiero ver.

Android chupa

Multimedia no es en tiempo real. En serio, esto es estúpido. Una CPU de 1,5 GHz de doble núcleo, y todavía oigo chasquidos de vez en cuando cuando inicio el navegador
notificaciones escáner multimedia están rotos. Por lo tanto, puedo descargar una pieza de música, y lo que sucede a continuación? Cierto, las patadas del escáner medios de comunicación en y mata el reproductor de música. ¿Por qué? Ah, porque los chicos cool van locos por POO y patrones de diseño de hoy en día, pero la implementación de una actualización de la configuración apropiada en directo está más allá del alcance de las capacidades de los desarrolladores de alto nivel. Claro, quemando todo a la tierra y la creación de la nueva instancia de la clase es la única manera de ir
No, yo no voy a cambiar mi teléfono con un reproductor de mp3 porque yo m perezoso. No quiero molestar a la música copiando a él, sólo quiero que descargarlo a través de Wi-Fi desde sitios warez (d’oh)
IU se queda. Incluso en un CPU quad-core con 2 GB de RAM
accidente Aplicaciones de vez en cuando. Oh, bueno. Ni siquiera sé por qué. En java que ha estructurado el manejo de excepciones y cosas por el estilo. Incluso en Windows Mobile, donde todo estaba escrito en C plano con la administración manual de la memoria, no había que muchos accidentes. Se cuelga su destkop cada 30 segundos? No? Ok, voy a culpar Java. Android Dalvik JVM, para ser más precisos. El ciclo de vida de la aplicación se implementa en Java, el lanzador está implementado en Java, pero para algunas aplicaciones multimedia el rendimiento de Java no es suficiente, y IntBuffer de crear una sobrecarga considerable. Por otra parte, al analizar estructuras C sin JNA es sólo doloroso. Por lo tanto, los desarrolladores tienen que integrar su C y C + + de código en el entorno Java. Cada llamada en Java a C y C a Java implica un montón de manipulaciones manuales de memoria, y supongo que la mayoría de los desarrolladores no lo hacen correctamente. Aún así, me desconcierta por qué accidente aplicaciones Java puro tan a menudo
No fsck adecuada y eliminación de archivos muertos. En serio, si el sistema de archivo de datos está dañado, y la base de datos de configuración de una aplicación se vuelve modificable, y supongo que lo que sucede? Cierto, los lanzamientos de aplicación, se estrella con la IOException y el ciclo se repite indefinidamente
Android de usar un lisiado personalizada libc y es binaria incompatible con GNU / Linux. Vale, libhybris nos permite robar controladores OpenGL de Android, no estoy gimiendo más

unsucks

Android

Hay puntos positivos, por supuesto

El sistema es de código abierto, que se puede adaptar fácilmente para cualquier pieza de encargo del hardware [Estoy más interesado en el punto de vista del ingeniero de HW y no el fin de un usuario]
Se basa en el kernel de linux, lo que permite volver a utilizar muchos programas a través de chroot o factible portar [como Qt4]
Eso es todo
Oh, no. Hay una gran cantidad de dispositivos comerciales disponibles, el usuario tiene un montón de opciones

Lo siguiente

He utilizado muchas plataformas móviles y esto es lo que tengo gustaba y disgustaba sobre ellos

Windows Mobile

UI Damn lento. Sin composición o el soporte 3D en absoluto
huella de memoria baja
Muy estables
montón de aplicaciones
Native SDK C
Posibilidad de cargar los controladores en modo kernel
Buen modelo de controlador, con ABI y configuración estable a través del registro

Bloqueado fuerza. No es divertido para hackear
Demasiado caro para construir un dispositivo personalizado
Pero en el aislamiento de vista positivo, la gestión de recursos basada en la capacidad y la aplicación a través de los contenedores (security!)

iOS

simplemente funciona
Pero ningún código fuente
y SDK están vinculados a OSX

Maemo / MeeGo

Basado en Qt y X11 (Wayland en breve), un montón de código reutilizable
Usando pila GNU / Linux tradicional y
Abra-source
código nativo (a excepción de algunas partes de la interfaz de usuario escritos en QML).

buildsystem

Baja necesidades de recursos que Android

Yo estoy deseando Sailfish OS Jolla y tratando de puerto del Nemo Móvil (la pila de código abierto sin marca detrás de Pez Vela) para mis dispositivos OMAP4 .

Algunas ideas

Esto es lo que creo que un nuevo tipo de sistema operativo móvil debe ser

tiempo real la programación de [por lo menos, la prioridad adecuada manejando para multimedia y la interfaz de usuario, pero la política es una cuestión compleja]
Usando el modelo de seguridad capacidad
Capacidad para Proxify servicios y reemplazar los métodos
Construido con optimización de potencia en mente
arquitectura microkernel con IPC tamaño fijo buffer [para prevenir vulnerabilidades de desbordamiento de búfer, para facilitar la depuración]
caminos de recursos dinámicos
Soporte para-y HW-virtualización

. Quiero consultar irq como XPath. Por ejemplo, | irq = Irq_session «/ soc/gic/12» | o «/ bus/i2c/omap4-1/0x30/irq_expander/10». Tal vez una solución es una especie de controlador plataforma que acaba de asignar cadenas de IRQ en tiempo de ejecución.

reutilización existente API linux y código

Hasta ahora algunas de estas características son implementados por Fiasco.OC y Genode, pero hay algunas áreas en las que quiero un enfoque completamente diferente

Reemplace XML y LUA configuraciones con … un XML con esquema o, mejor, un DSL con la comprobación estática
Evitar la asignación de memoria en tiempo de ejecución. Quiero que las estructuras de datos como sea posible (al menos en los conductores) se asignan en tiempo de compilación. Esto reducirá destrozar la memoria, el tiempo de arranque y simplificar el fuera de tratamiento de la memoria

Utilizar un lenguaje decente. Quiero decir, algo así como Scala o Haskell.

El primero hay datos sin inicializar. Durante mi experiencia C de codificación, el 80% de los problemas de «WTF» son variables sin inicializar.
A continuación, la inmutabilidad. Funciones sin efectos secundarios pueden ser verificados. Por supuesto, la verificación de código 100% es muy caro (y bien, la verificación absoluta es imposible, porque no podemos verificar el universo), pero al menos la división del código a la «peligrosa» y «depurable» es un buen comienzo «.
estricta y la falta de tipos implícita yesos. Se ahorrará un montón de problemas con la C «todo es un int» paradigma
tipos de opciones. Como haskell de Tal vez / Justo y OCaml de algunos. Ellos eliminar los punteros «NULL», la fuente de todos los accidentes y comportamiento indefinido en C + + y Java, al obligar al programador patrón coincide con el valor

En cuanto a la reutilización de código de Linux, creo que un punto de partida podría ser microkernelizing linux. Podríamos hacer cada módulo de un proceso independiente y reemplazar todas las variables no estáticas globales y símbolos exportados con IPC pide un comienzo.

Preguntas abiertas

todavía no estoy seguro en algunos puntos, y estaría feliz de ver los comentarios en ellos

Si la implementación de soporte de CPUs heterogéneo es una tarea factible
¿Podemos hacer un mejor bytecode de JVM? ¿por qué chupan JVM? ¿por qué es lento? o no?
¿Qué sistemas de este tipo existe ya? Phantom Inferno OS OS?