Nagyobb összegű, névtelen adományt kapott a Redox OS

Ez jó. Valaki kifejleszthetne már egy frankó, új op.rendszert

/off

A fosstodon.org domain nev erdekesen hangzik magyarul :)

/on

Nem hallottam meg rola, ugy latom elsosorban desktop OS-nek keszul.

CPUs

• Any x86_64 CPU is supported
• i686 CPUs from the Pentium II and up are supported, however, support is not as complete as x86_64 support

A fentiekbol ugy tunik, hogy a legujabb architekturat celozzak, akkor lehet erdemes lenne az arm64 fele (is) menni.

A nevtelen adomanyozo csak annyit kert nevtelenul cserebe, hogy az osszegert cserebe csinaljon egy ragequit posztot twitterre?

Lehet, Musk dobott egy kis pénzt, hogy legyen saját OS a telefonjaira :D

PS: beelőztek :)

> A UNIX-szerű, Rust-ban írt operációs rendszer

Hogy egy kicsit szakmázzunk is: üdvözlöm, hogy Rust-ban írnak operációs rendszert! A memória korrupciós bugokat elvileg teljesen kizárja ez a megközelítés, ami által nagyon biztonságos lehet ez a rendszer majd. Ráadásul a teljesítménye is kompromisszum-mentes lehet.

A másik tagmondat az amibe belekötnék: véleményem szerint a UNIX elvektől meg kellene végre szabadulni. Nevezetesen attól, hogy minden program egy bemeneti streammel és két kimenetivel indul. Szerintem a programoknak API-k mentén kellene kapcsolódniuk az oprendszerhez, és ezeknek mennél magasabb kellene, hogy legyen az absztrakciós szintjük. Hogy érthető legyen: ha egy program mondjuk logokat ír az stderr-re, akkor neki nem egy stderr-re van szükségük, hanem egy log kimenetre. Ha egy program fájlok listáját adja vissza, akkor nem egy stdout-ra van szüksége, hanem egy fájlok listáját fogadó API-ra.

A bináris csatornákon való összekötés következménye, hogy egy rakás felesleges formázást és parszert írunk, ami a hibalehetőségek tárházát adja. Ezt el lehetne kerülni a típushelyes API-k használatával, ami nem rakétatudomány 2022-ben, de mégis ezen a szinten még nem jelent meg.

A következő probléma az, hogy az stdout/stderr-en kívül minden hardver elemet felderítéses módszerrel érnek el a programok. Ez értelmetlen plusz terhet ró a programozókra, mert meg kell írni a felderítő és kiválasztó program részeket. Ehelyett ennek az oprendszer feladatának kell lenni, ami már a konkrét felkonfigurált API-t adja át a program számára.

Ilyen volna jövő operációs rendszere.

Egyenlőre valamire való op rendszer legalább önmagával legyen kompatibilis...
API amikor egy xml leíróból fejtsd vissza, mit akartak, vagy van egy sima text output...
Gyakorlatilag 25 év után azt mondom vissza a gyökerekhez, mert túlzott API-knak hála, szinte minden BUG-os.
Teljesség igénye nélkül
vasak:
Honeywell HDC 402 - egy holdraszállást megoldott API nélkül pár kb-ból
Hubble - 8bit CPU +upgrade 386 cocpu, később upgrade 486-ra itt se egy mai szemmel komoly API-val oldották meg a 30 éves működést, mégse fagy be. OS VRTX laza 40+ éve (assembly-ben írták emlékeim szerint)
ISS '98-ban CC egy i386 :) viszont itt már megjelent másodlagos/harmadlagos rendszereknél az NT 3.51, jelenleg pedig úgy tudom talán DEBIAN-ra álltak át.
Komolyabb ugrás 2011- körül megjelent 200mhz-re sugárvédett RAD750 15+ éves tervezett és egyenlőre be is vállt élettartalommal.
NASA a mai napig az egyszerűségre törekszik mindenre is felkészülve, persze ott is vannak már erőteljes hullámvölgyek, de nem a a fontos, hogy egy API szép legyen és modern, hanem 15 év múlva naprendszerünk széléről is küldjön adatokat. Itt már megjelent a RTOS egy jobban szeparált rétegelt változatai és igen már használhatod a rust-ot is ha erre fejlesztesz :)
De vigyázz 200mhz a teljes teljesítmény és mindennel is osztozol rajta +1gb memória, sajnos sok programozónak már az is kihivás, hogy ezt megoldja
Ha pedig valami egyszerű könnyű kis API akkor te is építhetsz egy ilyet:
https://www.youtube.com/watch?v=0efTTWMl3v0
Jók  modern API-k amikor bankbiztonságról beszélünk, vagy egészségügyi adatokról, de két szoftver közötti adatcserét feleslegesen bonyolítunk meg sokszor.
Úgy gondolom jó lenne ha az egész világon bevezetnék, hogy minden páratlan évben, nincs új funkció fejlesztés, csak a régieken hibajavítás. Tökéletesebb programok esetén kisebb lenne a vágy, hogy újabb és újabb "megoldásokat" találjunk ki. Egyre sűrűbben látom hogy kanyarodunk vissza txt-hez, és már azt sem tudják megugrani a programozók, hogy csv exportnál, ne legyen vessző az exportált szövegben, vagy más legyen az elválasztó :(
API-k dátum mező illesztése két rendszer esetében amikor az egyikben szabadon válaszható a régió :) Ja hogy önök másképp írják... erre nem gondoltunk ...
 

Mikroadományok tízezrei :D

Elhiszem, hogy nem merik leírni Putyin nevét.

Soros!