SphinUX OS

[Grof]

Sreća pa sam ja to ispravio! Inače ne znam kako bi se to riješilo.

vjerojatno nikako...

[mario1]

Evo SphinUX OS-a na Distrowatchu (DistroWatch Weekly - New distributions added to waiting list) ...

[Grof]

Ha, jako zgodno, no SphinUX-ovi repositoriji već nekih tjedan dana uopće više ne rade. IIS server baca grešku (da isti su bili na Windows serverima), ma predivno nešto.

[shrike]

to je žešći fail :D

[mario1]

A njihova oficielna stranica ima još samo link na Sourceforge download ...

[shrike]

ok, očito je sve to žešći troll bio. Ipak, ideja je zapravo genijalna i ako bi se implementirao neki "windows driver layer", to bi bila baza za najbolji OS ikada.

[Grof]

ok, očito je sve to žešći troll bio. Ipak, ideja je zapravo genijalna i ako bi se implementirao neki "windows driver layer", to bi bila baza za najbolji OS ikada.

Da, definitivno, samo ja nemam takva znanja da mogu tvrditi da li je takvo što uopće moguće.

Naime, imati jedan Caching kernel koji "vozi" po potrebi druge kernele i iskorištava ih po načelu AI-a ili neke druge tehnologije koja bi odlučivala što je u datom trenutku najbolje za iskoristiti iz svih tih keširanih kernela.
Sve skupa zaista zvuči kao revolucionarna ideja, ali ako takvo što nema tehničku bazu za izvesti, onda je to samo loša Science Fiction.

Jer, kako ja vidim da bi to trebalo raditi (na jednom vrlo banalnom primjeru):

• putem cp komande (ili grafičkog sučelja, nebitno) počinjem s kopiranjem datoteka
• biblioteka koja je zadužena za kopiranje datoteka šalje sistemski poziv Linux kernelu koji počinje odrađivati posao na "nižoj razini"
• Kod uobičajene prakse Linux kernel daje pozive hardveru i zajedno s njim odrađuje posao.
• U slučaju Caching kernela, sistemski poziv koji je morao preuzeti Linux kernel (jer je zahtjev došao s Linuxovog userspacea), isti taj Linux prebacuje ne hardveru, nego tom Caching (glavnom) kernelu, koji putem nekog sustava odlučivanja, taj sistemski poziv, nekako preusmjerava u onaj kernel koji to "bolje, brže, jače" izvršava, odnosno dijelove poziva preusmjerava dalje na hardver.
• Dakle, zbog potrebe pristupa diskovima, Caching kernel poziva neki mikrokernel koji brzo radi I/O, pa zbog potrebe pristupa RAM-a, poziva drugi mikrokernel koji opet to odrađuje.
• Sve potrebno slijeva se u isti, dijeljeni dio RAM-a, gdje svi kerneli surađuju i pod kontrolom Caching kernela izmijenjuju podatke.
• Na kraju izvršenog posla, interrupt, sistemski poziv, nešto od strane Caching kernela "javlja" Linux kernelu, da je posao završen, a ovaj to vraća u userspace dotičnoj biblioteci, odnosno aplikaciji.

Ne znam, zvuči podosta apstraktno da bi to moglo stabilno ili uopće raditi. No, velim, nemam takva saznanja iz kernelsko/hardverskog područja da bi mogao reći: DA, to je super i izvedivo je, ili pak NE, ovo što su napričali zapravo je hrpa tehničkih nebuloza koje dobro zvuče.