User Interaction management

Acest rol este vital pentru dezvoltarea și longevitatea unui OS. Dacă utilizatorii nu pot intracționa eficient cu sistemul atunci ei nu vor mai intracționa deloc. Gadget-urile smart și-au luat avînt DOAR DUPĂ ce a apărut o interfață prietenoasă. Unii afirmă că acel scroll gesture a simplificat suficient lucrurile pentru user. Nu e adevărat, dar gestures au o greutate mare în adoptarea smart-X-urilor.

Deși toată lumea a fost de acord, încă de la inventarea fotografiei, că o imagine face cît o mie de cuvinte, interfața grafică de interacțiune cu un computer s-a născut destul de greu. Chiar dacă hardware-ul a permis-o relativ repede (de la începutul anilor 1970), doar pe la jumătatea deceniului opt (după lupte seculare în ani-tehnologici) interfața grafică a devenit suportată pe sisteme. Motivul invocat va fi fost costul, dar eu cred că e ceva mai adînc, psihanalizabil, legat de castă – it-iștii cu hieroglifele lor urmau avocații cu avocățeasca lor sau contabilii cu contabiliceasca lor. Greșeală fatală, azi miliardele se fac din accesibilitatea publicului larg la tehnologie.

Cerințele moderne ale UI sunt legate de user experience, multi user și remote acces. Remote acces este mai mult legată de Communication Management, dar atîrnă greu în balanță modul cum interacționezi remote cu un sistem.

Communication management

La începuturile erei noastre computerul era suficient sie însuși. Dacă mai avea și o imprimantă legată la un port intern era o unealtă și mai folositoare. Odată cu creșterea cantității de date (în lume datele se dubleză la fiecare doi ani) a existat nevoia comunicării între computere. Bumul tehnologic de astăzi se datorează proiectării inițiale corecte a acestui rol. Au creat protocoale de comunicație atît de bune încît tehnologii care nu existau în momentul proiectării au fost integrate foarte ușor, natural, în sistem. Cel mai bun exemplu sunt tehnologiile wireless care nu existau în anii 1970 cind au creat protocolul TCP/IP și care apoi au folosite împreună natural, fără eforturi de integrare.

Succesul acestui model s-a bazat pe abstractizarea diferitelor funcții necesare într-o comunicare, de la transport – mediu de comunicare, protocol, pînă la limbaj și application specific. Modelul teoretic (diferit de practica curentă) este numit Open Systems Interconection (aka OSI model). El identifică șapte nivele/layere: physical, data link, network, transport, session, presentation și application. În practică au mai apărut diverse nevoi pe care modelul standard nu le-a prevăzut, ca VLANuri, VPNuri sau transport criptat (altceva decît datele criptate), dar cum în IT practica primează acestea au fost înghesuite în OSI (cu bătăi de cap doar pentru teoreticieni).

Comunicarea între sisteme diferă esențial de comunicarea între obiecte descrisă în capitolul Object Management prin natura tipului de comunicare. În primul caz sistemele sunt procupate de legătură și transport, pentru ele datele transportate fiind necunoscute, iar în al doilea tip de interacțiune – aplicațiile cunosc serviciile pe care le consumă, dar nu le pasă cum ajung la ele. În mod ideal cele două nu se intersectează, dar în practică acestea se suprapun în nenumărarte sisteme. Cel mai bun exempl este storage-ul. Inițial, era treaba unei aplicații (de tip serviciu, dar de nivel superior) să dea acces la storage (printr-un protocol special de acces, SMB, NFS, FTP) unui sistem remote, azi storage-ul poate fi virtualizat printr-un seviciu de nivel inferior al sistemului, așa încît datele să stea în toată lumea și aplicațiile care-l folosesc să naibă habar pe unde sunt dale lor

Definiție: Sistemul de operare este o aplicație software care joacă rolul de “Master Control Program” și care face legătura între hardware și celelalte aplicații software.

Principalele atribuțiuni ale unui OS sunt:

• hardware management – gestionarea diferitelor device-uri hardware;
• process management – executarea diferitelor aplicații software;
• object management – gestionarea diferitelor obiecte software (fișiere, aplicații, mașini virtuale, hardware virtualizat etc);
• user interaction management;
• security management;
• communication  management;
• instrumentation and orchestration;
• application development;
• audit.

Hardware management

Acesta este rolul primordial al unui OS. Chiar prin definiție rolul său este să facă legătura între hardware și celelalte aplicații software.

Deși putem imagina multe device-uri hardware pe care ar trebui să le cunoască un OS, în fapt, de-a lungul timpului obiectele hardware s-au separat în cîteva categorii bine definite, 10-12 toate. Vom găsi, în ordinea importanței hardware: procesoare, motherboards, RAMi, video, storage, networking, HIDs (human interface devices), audio. Celelalte cad în categorii foarte specializate, rămînînd pentru OS doar sarcina găsirii unor mijloace (aka porturi) de conectare la aplicații. Și porturile hardware au avut aceași evoluție și s-au standardizat, cele mai folosite azi sunt porturile seriale și porturile USB (deși USB este un port hardware și are caracter serial, nu este un port serial, fiind folosit doar pentru transport).

Cel mai mare succes în managementul hardware-ului l-a avut Windows-ul pentru că a introdus un layer de abstractizare (HAL), ceea ce a permis dezvoltarea unitară a drivere-lor hardware. (definiție: driver-ul este o aplicație software specifică unui hardware ce permite sistemului de operare accesul la funcțiile device-ului.) Astfel, aplicațiile au avut o interfață unitară pentru accesul la o întreagă clasă de device-uri fără a-i păsa ce producător a construit-o. Și invers, producătorii de hardware au avut un framework unitar pentru a-și dezvolta driverele, fapt ce i-a ajutat să creeze niște aplicații robuste (fără bug-uri).

Process management

Tot definiția ne îndrumă cătrea al doilea mare rol al unui OS. În process management sistemul încarcă în memorie o aplicație software și execută instrucțiunile sale în limbaj mașină (aka cod mașină). Procesele trebuie să fie izolate, cu acces direct doar la spațiul de memorie alocat. Accesul la resurse nu se face direct, ci prin intermediul serviciilor de sistem (sau funcțiilor de sistem, dar un serviciu, spre deosebire de o funcție, are posibilități de autentificare, de prioritizare și alte atribute moderne). Cea mai mare provocare a acestui proces este de a pune la dispoziția aplicațiilor mecanisme să-și păstreze ACIDitatea (atomice, consistente, izolate și durabile).

Caraterul ACID este dat de:

• Atomicitate – orice operațiune fie se termină cu succes, fie se termină cu eroare nelăsînd părți modificate;
• Consitență – orice operațiune trebuie să fie validă, ducînd aplicația dintr-o stare validă într-o altă stare validă (validă din punct de vedere al OS și nu al aplicației pentru că OSul nu poate ști ce e aia stare validă pentru ea);
• Izolare – OSul trebuie să asigure spațiu de memorie izolat fiecărei aplicații, nepermițînd unui alt software să modifice direct în spațiul dedicat;
• Durabilitate – odată ce o operație s-a terminat toate efectele sale rămîn, orice altă operațiune ulterioară nemaiavînd acces la datele inițiale.

Object management

Dacă primele două roluri au fost evidente și cam toate sistemele de pînă acum s-au achitat onorabil în implementarea corectă a lor, partea de Object Management a fost PROST gîndită în toate OSurile cunoscute. Daca în vremurile cu hardware scump se putea trece cu vederea lipsa de viziune asupra acestui rol primordial al OSului, azi trebuie să-l avem în centrul atenției pentru că obiectele care există și interacționează într-un OS sunt suficient de complexe și diferite așa încît comunicarea dintre ele să nea de peste cap (să introducă o complexitate nejustificată) multe aplicații propuse.

Abordarea inițială a fost everything is a file și a funcționat o vreme. Prin simplitatea ei a permis orientarea țintelor optimizării software către primele două roluri, ceea ce e de înțeles pentru că hardware-ul era scump și nu așa de rapid. UNIXul a rulat inițial pe hardware de sub 1MHz !!?! Critica principala a acestui model o aduc virușii. Nediferențierea între o aplicație și un fișier de date a făcut posibil ca aplicații malițioase să se camufleze sub formă de date (documente, poze, etc). De asemenea, dacă într-un sistem modern un obiect poate fi izolat doar la acțiuni specifice, în vechime everything is file a permis accesul tuturor aplicațiilor la tot sistemul de fișiere (fie ele de bună credință sau malware). Chiar dacă teoretic sub drepturi de acces, o simplă operațiune ce pretindea drepturi full-admin putea duce la infectarea sau accesul la date confidențiale a unei aplicații răuvoitoare latentă în sistem.

Sistemele moderne trebuie să cunoască natura obiectelor (aplicații, date chioare, hardware virtualizat, video, formulare), să le identifice, să le izoleze și să le permită doar acțiuni specifice. În ziua de azi autentificarea se face ușor prin certificate SSL, prin același mecanism de identificare existent și testat pe internet. Se practică și identificarea sursei de instalare, Apple App Store, Windows Store, GPlay obligînd dezvoltatorii să-și publice aplicațiile în cadrul unor servicii publice unice. Mecanism prin care marii producători pretind că verifică aplicațiile, fapt imposibil dat fiind numărul mare de programe și producători, dar care nu face decît să le dea un control foarte mare asupra distribuției (care azi înseamnă publicitate pe bani mulți).

Tot aici se va asigura comunicarea (standardizarea comunicării) între obiecte. S-au dezvoltat două mari protocoale DCOM și CORBA (după două mari categorii de OSuri, Win și *NIX). Practic un obiect își înregistrează serviciile publice într-un registru gestionat de sistem de unde clienții află de ele și încearcă să le consume. Celebrul Copy/Paste, indispensabil azi, este cel mai bun exemplu de comunicare asigurat de rolul Object Management și care nu era posibil în era EisF.