Vlákno názorů k článku
Bude příští kernel napsaný v Go? od jouda - Tak nevím, jestli zjištění že "v jazyce který...

Tak nevím, jestli zjištění že "v jazyce který neumožňuje memory related bugy je méně memory related bugů" implikuje "kernel bude bezpečnější", na nějaké závěry by to chtělo několik let být v focusu bug hunterů, pak teprve by porovnání dávalo nějaký smysl.
Cena 10% výkonu dolů taky není zanedbatelná, i když ve stínu Spectre/Meltdown je to drobnost.

Ostatně php je taky memory safe jazyk, a že by byly v něm psané weby nějak extra bezpečné se říct nedá.

ale o to jde, ne? Zrušit celou kategorii bugů dříve než se odhalí.

Bezpečnostní problémy v PHP nepramení z PHP, ale z jeho použití, buď přes ně protlačím data, která se pak spustí až na prohlížeči, tj. s PHP to nemá moc společného. Nebo nechám zapsat soubor, který zase s PHP spustím, opět to není tak moc zranitelnost samotného jazyka. Tyhle chyby se ale dají velice efektivně odchytit přes review, race condition, memory related bugy se už daleko hůře ručně objevují a spousta objevených CVE v kernelu z poslední dobu je z fuzzy testování.

Tak moment, to že dám do cookie "group=admin", případně (např.) chybná podmínka takže se do procesu namapuje R/W celá dostupná RAMka je problém použití jazyka, ale a[-1]=0 je zranitelnost jazyka?
Pardon, to mi připadá jako hraní se slovíčky, aby preferované řešení vypadlo jako lepší (neříkám že není, jen mě trochu vadí hypování a co je staré to je špatné), ale ve finále je výsledek stejný, dojde patrně ke kompromitaci.

Navíc tu jsou sociální faktory, třeba nižší laťka pro schopnosti programátora v jazyce, který za něj chodí i na záchod, se může dost negativně projevit na kvalitě výsledného kódu, takže sice jsme se vesele zbavili celé kategorie chyb, ale bezpečnost to nějak zvlášť neposílilo.

BTW: Zkusil někdo vymyslet třeba side channel timing útok na garbage collector, jaká data tak můžou utéct? (tedy něco co ve standardním kernelu není - takže potenciální pole neorané a pravděpodobně dosud neznámá nová kategorie bugů).
Nemyslím že by analýza podobných nechtěných následků byla triviální.

"Nemyslím že by analýza podobných nechtěných následků byla triviální."
Naopak, cim vic takovych samoseroucich se veci v kodu mas, tim hur se potencielni chyby odhalujou, protoze ve finale vlastne nikdo nevi, co to dela a kdy to dela a proc to dela, takze kdyz pak nekdo na neco narazi ...

Bejvaly casy, kdys moh prikaz po prikazu prelozit danou vec do asm, a vedel si, ze vicemene totez vypadne i z kompilatoru. Takze si vedel co to ve finale bude delat. Dneska mas kompilator kterej se snazi myslet za tebe, mas cpu kterej se snazi myslet za tebe, maz jazyky ktery za tebe chodej na ten hazlik, takze vysledek je, ze uz vlastne nikdo nevi, co to bude ve finale delat.

Tak hlavně aby na ten jazyk byla dostupná dokumentace na úrovni což se moc o PHP říct nedá..

Jeden příklad za všechny.

Tenkrát jsem potřeboval zapsat data do souboru po ukončení načítání dané stránky.
Ze začátku to bylo lehký. Použil jsem "register_shut­down_function" a myslel jsem, že je hotovo.
No a v dokumentaci se už třeba nikde nepíše, že se po zavolání fce mění aktuální cesta na nějaký základní s*it..

Opravdu krásně ztracených 15 minut něčím co by mohlo být v dokumentaci..

PS: Pro ty z Vás, kteří neumí číst a myslí si, že haním PHP, tak omyl, jen jeho dokumentaci...

php nema dokumentaci, ale forum, kde se vsichni dohaduji jak to vlastne funguje.

@Grammar nazi

39 livejournal.com/~sin­de1/ 12 years ago

If you want to do something with files in function, that registered in register_shut­down_function(), use ABSOLUTE paths to files instead of relative. Because when script processing is complete current working directory chages to ServerRoot (see httpd.conf)

[http://php.net/manual/en/function.register-shutdown-function.php, 2018]

Naopak bych řekl, že jsem viděl spoustu horších dokumentací.

A nechcete si ty žabomyší války o PHP jít řešit na fórum? U každé diskuze na rootu dominuje nějaké off-topic téma, které už bylo diskutované snad 100x a lidi pořád baví to psát znovu a znovu :)

Jenze ono to neni 10%. Kdyz implementujes veskerou funcionalitu kterou ma kernel, tak to bude rozdil v nasobcich. Viz vejs, i kdybys to prepocital jen na rozsah kodu, tak to mas rekneme 100k vs 20M => 200x ... (neda se to samo takhle uplne vynasobit, ale ten rozdil bude naprostro tristni).

A jak sam pises, budou v tom jiny chyby, prevazne jeste mnohem zaludnejsi.

A ty drivery nebezej a nic nedelaj ... takhle to vidis?

Mistni squadra negramotnych blbu totiz nezvlada ani scitat, a ten vykon se nebude scitat ale nasobit ... protoze on bude o tech 10% poamelejsi taky... trebas filesystem, takze ... se na nej bude o to dyl cekat. O 10% pomalejsi bude sitovani ... atd atd atd atd.