Poslední příspěvky1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 20:03:35 »Jo ten audit C++ závislostí bych chtěl taky vidět, to nejde udělat, pokud ty závislosti mají miliony řádků unsafe kódu...
Slovo „unsafe“ je tady dost zavádějící. Bezpečnostní audit neděláš jen kvůli náhodným chybám (z nichž jen část je způsobena „unsafe“ kódem – spousta z nich jsou chyby v logice – špatně napsaný IF, použití jiného atributu, volání jiné metody nebo metod ve špatném pořadí, chybné parsování vstupu atd.), ale i kvůli záměrným dírám a zadním vrátkům, které tam nechal autor, nebo podstrčil nějaký „brigádník“ či náhodný „přispěvatel“ a za kterými ve skutečnosti stojí nějaká zločinná organizace. A tyhle chyby (nebo spíš záměrně škodlivé vlastnosti) můžou být i v programu či knihovně psaných v tom nejbezpečnějším jazyce na světě.
Balíčkovací systémy jsou obecně dobrá věc a umožňují problém řešit více systematicky. Má to ale svoje úskalí:
1) Tím, jak je jejich použití jednoduché, nad tím lidé míň přemýšlejí. Stačí se podívat, co všechno se stahuje z internetu v rámci sestavení běžné moderní aplikace. To množství knihoven často dosahuje hrůzných rozměrů i u relativně triviálních aplikací, které nic moc nedělají. Množství knihoven, autorů a řádků kódu, které jsou za tím, je enormní. Jak píšu ve svém článku o komplexitě softwaru:
Citace
Důležité ale je nezapomínat, proč to děláme a na jakém předpokladu naše rozhodnutí (přidat tu či onu závislost) stálo. Tento předpoklad bychom měli průběžně testovat – a pokud zjistíme, že platit přestal, tak z toho vyvodit patřičné závěry. Neměli bychom zapomínat na to, že samotný vyšší programovací jazyk (např. Java nebo PHP) spolu se svojí standardní knihovnou jsou samy o sobě frameworkem, stejně jako je frameworkem UNIX (resp. dnes převážně GNU/Linux) a že poskytují víc než dostatečnou úroveň abstrakce pro vývoj mnoha aplikací.
Je to trochu paradox, protože ten čas, který nám balíčkovací systém ušetřil, bychom mohli věnovat přemýšlení, jestli tu či onu knihovnu skutečně potřebujeme případně jejímu nahrazení něčím jednodušší. Ale není tomu tak. To pohodlí spíše to přispívá k tomu, že software není příčetný. Zatímco ta ruční správa závislostí fungovala jakási přirozená brzda před tím, aby programátor do projektu nezatáhl kde co. Minimálně u průměrných vývojářů to tak funguje. Čest výjimkám.
2) Balíčkovací systémy specifické pro daný programovací jazyk jsou nešťastné. Někdy vznikaly pod tlakem okolností a z nedostatku jiných řešení nebo neochoty se dohodnout, někdy jsou důsledkem egocentrického myšlení autorů, kteří jsou přesvědčení o výjimečnosti svého programovacího jazyka a trpí utkvělou představou, že teď se do něj přepíše všechen software světa. Podobně jako když si autor programu myslí, že jeho výtvor je středem vesmíru a že se mu ostatní musí přizpůsobit. Ve skutečnosti jsou ale softwarové systémy mnohem pestřejší a heterogenní, vždy budou, a je potřeba se s tím smířit. Proto dávají smysl balíčkovací systém obecné, fungující napříč programovacími jazyky (a kolikrát je potřeba spravovat i data, ne jen spustitelný kód), které umožní správu toho heterogenního celku. Správa závislostí je abstraktní úloha a logika specifická pro konkrétní programovací jazyk by měla být leda zapouzdřena ve volitelném modulu pro daný jazyk, který se do toho obecného balíčkovacího systému připojí.
