Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Redox OS bootuje na RISC-V a Raspberry Pi 4

A kdyby místo Rustu použili HolyC, tak je ten systém ještě efektivnější ;)

+1
+1
-1
Je komentář přínosný?

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.

+1
0
-1
Je komentář přínosný?

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)?

+1
0
-1
Je komentář přínosný?

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é.

+1
+1
-1
Je komentář přínosný?

>> byť někoho zcela jiného

Z cizího krev neteče.
A wo tom to je.

+1
0
-1
Je komentář přínosný?

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.

+1
+1
-1
Je komentář přínosný?

2x viac s polovicou chyb je to iste v pocte chyb.
ma to potom vyznam?
(joke)

+1
0
-1
Je komentář přínosný?

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.

+1
0
-1
Je komentář přínosný?

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.

+1
0
-1
Je komentář přínosný?

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.

+1
-1
-1
Je komentář přínosný?

Žiješ v minulosti. Wayland, systemd, ...

+1
-1
-1
Je komentář přínosný?

ani omylom.
stale sysVinit, runinit a samozrejme bez systemd.

+1
0
-1
Je komentář přínosný?

To je ta 10% menšina z linuxové 2-4% menšiny?

+1
-2
-1
Je komentář přínosný?

Obavam se, ze peklo pro uzivatele je prave ten "neskutecny bordel".
A proto maji ty osklive monolity 72.17 % a 15.42 %...

+1
+2
-1
Je komentář přínosný?

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.

+1
-1
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.