Comprender los niveles de computación

Lo siento, por mi pregunta confusa. Estoy buscando algunos consejos.

Hasta ahora he estado trabajando principalmente con Java y Python en la capa de aplicación y solo tengo una vaga comprensión de los sistemas operativos y el hardware. Quiero entender mucho más sobre los niveles más bajos de computación, pero de alguna manera se vuelve realmente abrumador. En la universidad, tomé una clase sobre microprogramación, es decir, cómo los procesadores se conectan para implementar los códigos ASM. Hasta ahora siempre pensé que no podría hacer más si aprendiera más sobre el "nivel bajo".

Una pregunta que tengo es: ¿cómo es posible que el desarrollador se oculte casi por completo del desarrollador? ¿Es correcto decir que el sistema operativo es una capa de software para el hardware? Un pequeño ejemplo: en la programación nunca me he encontrado con la necesidad de comprender qué es la caché L2 o L3. Para el típico entorno de aplicaciones empresariales, casi nunca es necesario comprender el ensamblador y los niveles más bajos de computación, porque hoy en día existe una pila tecnológica para casi cualquier cosa. Supongo que el objetivo de estos niveles inferiores es proporcionar una interfaz a los niveles superiores. Por otro lado, me pregunto cuánta influencia pueden tener los niveles inferiores, por ejemplo, todo este asunto de la informática gráfica.

Entonces, por otro lado, existe esta rama teórica de la informática, que funciona en modelos informáticos abstractos. Sin embargo, rara vez me encontré con situaciones, en las que me pareció útil pensar en las categorías de modelos de complejidad, verificación de pruebas, etc. Sé que hay una clase de complejidad llamada NP y que es imposible resolverlas. una gran cantidad de N. Lo que me falta es una referencia para un marco para pensar sobre estas cosas. Me parece que hay todo tipo de campamentos diferentes, que rara vez interactúan.

Las últimas semanas he estado leyendo sobre problemas de seguridad. Aquí de alguna manera, muchas de las diferentes capas se unen. Los ataques y exploits casi siempre ocurren en el nivel inferior, por lo que en este caso es necesario conocer los detalles de las capas OSI, el funcionamiento interno de un sistema operativo, etc.

La palabra clave para pensar en estas cosas es abstracción .

La abstracción solo significa ignorar deliberadamente los detalles de un sistema para que pueda considerarlo como un componente único e indivisible al ensamblar un sistema más grande de muchos subsistemas. Es inimaginablemente poderoso: escribir un programa de aplicación moderno mientras se consideran los detalles de la asignación de memoria y el registro de derrames y tiempos de ejecución de transistores sería posible de alguna manera idealizada, pero es incomparablemente más fácil nopensar en ellos y simplemente usar operaciones de alto nivel en su lugar. El paradigma informático moderno se basa fundamentalmente en múltiples niveles de abstracción: electrónica de estado sólido, microprogramación, instrucciones de máquina, lenguajes de programación de alto nivel, SO y API de programación web, marcos y aplicaciones programables por el usuario. Prácticamente nadie puede comprender todo el sistema hoy en día, y ni siquiera hay un camino concebible a través del cual podamos volver a ese estado de cosas.

La otra cara de la abstracción es la pérdida de poder. Al dejar las decisiones sobre los detalles en niveles inferiores, a menudo aceptamos que se pueden tomar con una eficiencia subóptima, ya que los niveles inferiores no tienen el 'Panorama general' y pueden optimizar su funcionamiento solo por el conocimiento local, y no son tan (potencialmente) Inteligente como ser humano. (Por lo general, por ejemplo, compilar HLL en código de máquina hoy en día a menudo es mejor para las máquinas que incluso para el ser humano más experto, ya que la arquitectura del procesador se ha vuelto tan complicada).

El tema de la seguridad es interesante, porque las fallas y 'fugas' en la abstracción a menudo pueden explotarse para violar la integridad de un sistema. Cuando una API postula que puede llamar a los métodos A, B y C, pero solo si se cumple la condición X, es fácil olvidar la condición y no estar preparado para las consecuencias que suceden cuando se viola la condición. Por ejemplo, el desbordamiento del búfer clásico explota el hecho de que escribir en celdas de memoria produce un comportamiento indefinido a menos que usted mismo haya asignado este bloque de memoria en particular. La API solo garantiza que algoocurrirá como resultado, pero en la práctica el resultado está definido por los detalles del sistema en el siguiente nivel inferior, ¡lo cual hemos olvidado deliberadamente! Mientras cumplamos con la condición, esto no tiene importancia, pero si no, un atacante que entienda ambos niveles íntimamente puede dirigir el comportamiento de todo el sistema como lo desee y hacer que sucedan cosas malas.

El caso de los errores de asignación de memoria es particularmente malo porque ha resultado ser muy, muy difícil de administrar la memoria manualmente sin un solo error en un sistema grande. Esto podría verse como un caso fallido de abstracción: aunque es posible hacer todo lo que necesita con el CmallocAPI, es simplemente fácil de abusar. Partes de la comunidad de programación ahora piensan que este era el lugar equivocado para introducir un límite de nivel en el sistema, y ​​en su lugar promueven lenguajes con administración automática de memoria y recolección de basura, que pierde algo de poder, pero brinda protección contra la corrupción de la memoria y el comportamiento indefinido. . De hecho, una razón importante para seguir usando C ++ hoy en día es precisamente el hecho de que le permite controlar exactamente qué recursos se adquieren y liberan cuando. De esta manera, el cisma principal entre los lenguajes administrados y no administrados hoy en día puede verse como un desacuerdo sobre dónde definir con precisión una capa de abstracción.

Lo mismo puede decirse de muchos otros paradigmas alternativos importantes en informática: el problema realmente surge todo el tiempo donde se deben construir grandes sistemas, porque simplemente no podemos diseñar soluciones desde cero para los complejos requisitos comunes hoy en día. (Un punto de vista común en la IA en estos días es que el cerebro humano en realidad hace el trabajo de esa manera - el comportamiento que surge a través de los bucles de retroalimentación, redes interconectadas masivamente etc. en lugar de módulos independientes y capas con elementos simples, interfaces abstractas entre ellos, y que es por eso que hemos tenido tan poco éxito en simular nuestra propia inteligencia).