Hlavní navigace

Názor k článku Domácí routery obchází nový strašák: chyba Misfortune Cookie od Trident - Pokud je uvnitr routeru treba linuxovy kernel, tak...

  • Článek je starý, nové názory již nelze přidávat.
  • 21. 12. 2014 14:02

    Trident (neregistrovaný) ---.tmcz.cz

    Pokud je uvnitr routeru treba linuxovy kernel, tak i po osekani je to sakra komplexni vec.
    Spis jde o to jak je vyvoj kontrolovan,sle­dovan a testovan. Jakym zpusobem se hlida komplexita. U kritickych veci uz s americkym result oriented pristupem nepochodite. A neni tam ani mozne plne aplikovat agilni metodiky. Tam je i lepsi kdyz se to trochu zdrzi, nebot sankce za dodani spatneho reseni byvaji vyssi nez za nedodani k terminu. Jsou totiz na to navazane dalsi veci - pojisteni - audity - spadle letadlo/mrtvy pacient/satelit na kasi.

    Ja kdyz vidim jak se vyviji software ve vetsine firem, tak na mne jdou mrakoty. A u low cost zarizeni jako je router to nebude lepsi.
    Zjistil jsem ze narozdil od sysadministratoru programatori proste miluji bordel a mysli si ze podle jejich bordelu pujde zbytek projektu. Manazeri jim svou neznalosti jeste prizvukuji. Ten bordel je na vsech urovnich. Od dodavatele devkitu po final assembly.

    0) Chybejici standardizovane build prostredi, nejsou maintaineri jednotlivych komponent. Nikdo nekontroluje aktualizace jednotlivych casti. Manazer spokojenej ze "to funguje".

    1) Tragicka dokumentace devkitu
    Potrebujes nekolik devkitu k desce tveho zarizeni ale kazdy jde nastavit ruzne a z jednoho webu stahnes dve ruzne sady podle toho jak se maintainer vyspal. Zadny check, zadne checksumy souboru devkitu v buildu. Kazdej progros developi s jinym. Neudelas nic. Deska je sice draha ale devkit je zadarmo nebo za male penize. Strategicka volba dodavatele nemela jako metriku determinismus a dokumentaci devkitu.

    2) U mne to jde prelozit / u mne to funguje
    Kazdej progros jine prostredi a jinak nastavenej devkit. Souvisi s 1 Je to na palici vysvetlovat lidem kteri by mne mohli ucit dulezitost jednotneho prostredi

    3) Progrosi neradi aktualizuji komponenty protoze by si podelali prostredi a nedodali v terminu
    Souvisi to s podem 1. a tim ze update devkitu a vsech knihoven okolo neni bezproblemovy. Vsechny devkity(ten nejlevnejsi) delali asocialove kteri si mysli ze kazdej premysli stejne jako on

    4) Programatori dost casto doufaji v x
    Komplexita veci je tak velika, ze jim staci jen aby to nejak behalo a slo prelozit. Ze celou dobu s sebou taha starou deravou knihovnu ho netoci.

    5) Release jde pokazdy od nekoho jineho
    Neexistuje zodpovedna osoba za releasy. Pokazdy je dela nekdo jinej v zavislosti na tom jestli je dostupny. Jednou to dela John a podruhy Eric, potreti nove nastupujici kolega ktery nema ani info z internich dokumentu. No hlavne ze muze videt roadmap projektu.

    6) Security veci vetsinu progrosu netoci pokud se to netyka zrovna primo jejich prace

    7) Dulezite je dodat vcas a ne bezpecne. Stejne desku za chvilku obsoletnem. A update udelame jen kdyby nekdo rval

    8) Patch na starou verzi muze hodne bolet
    Progros co delal posledni release samozrejmne nedokumentoval se kterym devkitem to delal a zbyly jen tagy v SVN. Jen contractor ktery udela a odejde. Takze se stalo to ze

    Vyvoj pro letecky prumysl na vas ovadi programatorsky! Kazdy radek kodu musi byt zduvodnen. A ne ze tady vezmem nakej kernel+nakou newlibc+libovolny bordel z sdk s ruznym datem a je hotovo

    https://chess.eecs.berkeley.edu/hcssas/papers/Sha%20Avionics%202.0%20doc.pdf