Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
A kdyby místo Rustu použili HolyC, tak je ten systém ještě efektivnější ;)
A kdyby místo Rustu použili HolyC, tak je ten systém ještě efektivnější ;)
https://diit.cz/clanek/redox-os-bootuje-na-risc-v-raspberry-pi-4/diskuse#comment-1479399 +Efektivita Rustu nespočívá v rychlosti výsledného kódu, nýbrž v tom, že za půlku času v něm napíšu 2xtolik kódu s polovinou chyb.
Není psaní kódu "jednorázovým" nákladem autora(vydavatele), přičemž případná runtime neefektivita (časová/energetická/investiční) vyplývající z volby jazyka s celkovým nákladem, daným souhrnem všech budoucích použití od doby vydaní programu do běhu posledního instance, ve výsledku výrazně převyšující původní úsporu (byť někoho zcela jiného)?
Efektivitu runtime dneska nikdo neřeší, teda pokud není vyloženě excesivní. Však se podívejte v čem se dneska píše kód, všude samá java, android, .net managed code atd.
Psaní kódu je jednorázovým nákladem pouze v případě ukončených projektů. Operační systémy tak nějak z principu ukončeným projektem nejsou, tedy alespoň do doby, dokud jsou používané a podporované.
>> byť někoho zcela jiného
Z cizího krev neteče.
A wo tom to je.
V pripade rustu je to skor, ze cas o 50% dlhsi napisem kod, bude mat ale 4x menej chyb, hlavne pamatovych. Syntax rustu a myslenie nie je jednoduche si osvojit, hlavne zo zaciatku to trva trochu dlhsie.
2x viac s polovicou chyb je to iste v pocte chyb.
ma to potom vyznam?
(joke)
zasadni vyhoda Rustu je pametova bezpecnost zarucena v compile time, nikoli v runtime, jako to ma java a pod. odpada tedy 90% security chyb zpusobenych pretecenim zasobniku, pritom je ten kod +- stejne rychly jako C, nekdy rychlejsi.
90 % ale není "zaručené" a máš problémy se sdílením dat mezi více částmi kódu. Obzvláště problém při psaní ovladačů v kernelu, kam se Rust cpe se smíšenými pocity už i od Torvaldse. Ta Java apod. nejsou pomalé kvůli kontrolám za běhu, to zvládal už dosovský Pascal. Java se navíc dnes na serveru často komplikuje Ahead of Time a .NET má výkon i na emulaci Nintendo Switch ( https://github.com/Ryujinx-NX/Ryujinx?tab=readme-ov-file ). I ten blbej Python dostane aspoň JIT.
nevim zda to chapu dobre "kombinující display server, kompozitor a okenního správce v jednom"
ale pokud ano tak to je dle meho nic moc.
U vetsiny unix/unix-like systemu opravdu ocenuji to, ze X server/Wayland a spravce oken jsou samostatne programy, takze kdzy chce nekdo napsat novy/jiny spravce okon nemusi resit ty dalsi veci okolo.
Ta "stavebnicovost" je dle meho na Linuxu/*BSD systemech to nejlepsi a "monolity" Windows /Macosu je pro me jako uzivatele dost peklo.
Žiješ v minulosti. Wayland, systemd, ...
ani omylom.
stale sysVinit, runinit a samozrejme bez systemd.
To je ta 10% menšina z linuxové 2-4% menšiny?
Obavam se, ze peklo pro uzivatele je prave ten "neskutecny bordel".
A proto maji ty osklive monolity 72.17 % a 15.42 %...
Pri Wayland-oidnej architekture to v podstate plati tiez. Tam sa display server zmrskava v podstate na nejake pomerne lightweightove IPCcko a vytvaranie framebufferov pre jednotlive top-level okna. Window manager si potom riesi veskeru kompoziciu, menezment okien a snad aj routovanie event na pomerne nizkej urovni. Tie tri funkcie od seba asi ani nejde oddelit ako pri Xkach, kde compositing a window manager su dve odlisne role.
A da sa povedat, ze Xka su v tom dost osamotene. Valna vacsina grafickych architektur v historii bola monoliticka.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.