"Melyik projekt áll több kódsorból: egy DVD lejátszóé vagy egy F22–Raptor fedélzeti számítógépé?"

Hozzászólások

Jó összehasonlítás de ezek között vannak soronként polírozott szénné optimalizált rendszerek, meg vasvillával összehordott retkek is. Maga a LOC messze nem írja le a beletett munka mennyiségét és minőségét.

Gábriel Ákos

Egy új e-autó 100 millió kódsoros rendszerét én egy kicsit durvának érzem.
Meg kérdés az, hogy ebből mennyi a komment? :D

Nem túlzás, mert ezek 10+ évvel ezelőtti számok, akkoriban volt kapcsolatom ilyen dolgokkal és már akkor ezek a számok voltak. Jó része annak a temérdek kódnak a diagnosztikával kapcsolatos. Azóta csak több a sw a kocsiban, mert akkor még sehol nem voltak a mai vezetéstámogató rendszerek pl a radarral, lézerrel, támogatott adaptív tempomat, vagy még kamerával kiegésztve a sávérzékelőnek, táblafelismeréshez, holttérfigyelővel, ultrahangos közelség érzékelővel, akár önvezetéssel, a mobiltelefonnal integrálódó utastéri szórakoztató elektronikák, elektronikus műszerfalak, sokzónás klíma, full elektronikus vezérlés (kormány, gáz, fék by-wire) 7-9 fokozatú automata váltó, euro6d emissziós normákhoz illeszkedő kipufogórendszer ami egy kis vegyi üzem és annak az adatgyűjtése/vezérlése sem kis falat már stb. Egy korszerű, magas felszereltségű, modern autóban lehet hogy van 100 körül úgynevezett ECU a CAN buszra kötve. 

Gondolatok ébredtek bennem!

Nyilvánvalóan gondosan megtervezték, hiszen a CD játszón keresztül is lehet irányítani a motort.

Az ECU (= Engine Control Unit = motor vezérlés) 100 részre van szétdobva? Akkor ez olyan, mint a csótány, aminek még a lábában is van agya.

A mondat inkább kétszer kifordítva lehet igaz: Az ECU 100 körüli érzékelő (whatever) adatait fogadja CAN buszon keresztül...és a CD játszó is az ECU-ba van integrálva.

Ne kopjon a D betű!

:-D

Nem szokták már úgy hívni, hogy Engine Control Unit, olyan van, hogy Electronic Control Unit, aminek egy fajtája az Engine Control Module.

Így aztán egy autóban 1 (max 2) ECM van, de 100 környéke (a 12 éves Caddy-mben 20+) ECU, amiből 1 (max 2) felel a motor működéséért.

Ezek tényleg ekkora nagyságrendes számok, de igen, nem csak te érzed durvának, hanem minden épp eszű laikus és szakember is. És itt nem az a baj, hogy az erőforrásokkal spúrkodunk, meg nem akarunk új gépet, új hardver venni. Hanem hogy ezek a irdatlan, sok millió kódsoros monstrumok nem fenntarthatók, emberi mértékkel nem karbantarthatók rendesen, szinte lehetetlen debugolni, foltozni, már ezt is AI-nak kell csinálni, de az meg nem tudja normálisan. És nem csak a végfelhasználó oldaláról kér nagyobb hardvert, de a fejlesztőnek is megnehezíti a dolgát, hogy még 64-128 magos magos fordítószervereken is órákon át fordulgathatnak ezek, minden egyes release-kor, akkor is, ha csak egy pár soros folt miatt adnak ki új verziót. Egyszerűen agyfasz, akkor terhet ró a fejlesztőkre is, hogy már csak billiárdos mega-giga multik bírják szusszal meg pénzzel, és ennek mentén kisajátítanak minden technológiát, mindenki tőlük függ.

A másik véglet az, amit a suckless csinál, egy komplett WM, 2000 SLOC, minden annyira minimalista, hogy már csak erős kompromisszumokkal használható, rugalmatlan, se rendes dokumentáció, se emberi konfigfájl, se scriptelhetőség, semmi rugalmasság.

Az ideális középút a kettő között van, pár tizen-száz ezer soros kódméret fölé egyik projektben sem kéne menni, de a kód tudásához is kell mérni. Kb. száz ezer sortól van az, hogy egyre nehezebb áttekinteni, egyre nehezebb új fejlesztőnek a projektbe bekapcsolódni, minden exponenciálisan nehezebb ettől a ponttól. Ezért kéne arra törekedni, hogy a kód tudásához mérten reális, kezelhető legyen a kódméret. A kód tudását úgy mérve, ahogy a videó is mutatja, 120 millió kódsor kb. egy egér, 3300 millió kódsor meg egy ember teljes génállománya. Nyilván ennek alapján nem áll meg, hogy egy DVD lejátszó, meg egy plain text editor millió kódsoros legyen.

Az egyik legfőbb kódcsökkentési pont az lenne, ha nem ész nélkül, lustaságból támaszkodnának a fejlesztők csomó extra réteg API-ra, libre. Persze, az API réteg absztrakció, adhat némi rugalmasságot, de csak egy pontig, amíg a sok extra API, lib, köztes réteg nem megy át millió kódsoros dependency hellekbe. Pl. egy egyszerű chatszoftvert, vagy plain text editort nem kéne Electron appként erőltetni minden áron, mert légyre ágyúval kategória, és senkinek nem jó, mindenki szív miatta.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Vannak erre módszerek. Nem pici pénzbe kerül, nem kevés ember, nem kevés munka de meg lehet csinálni.
Sőt egész jól le is lehet tesztelni. Minél inkább automatizálod annál jobb, ehhez még messze nem kell AI.

Az a DVD lejátszó például egész biztos vagyok hogy úgy jöhet ki, hogy csilliárd féle tömörített retket lejátszik és az ahhoz szükséges összes libet belehányták.

Gábriel Ákos

Szerkesztve: 2021. 12. 04., szo – 19:05

kódsor mennyisége nem minden, szerintem.

pl: Commodore 64 assembly kódolásnál van egy olyan hogy speedcode.
kódból generálják a kódot és hasonló agymenések!:D

de mondhatnám a 256 byte vagy 64 KB kódereket is!:D

És úgy dobálóztak ezekkel a fogalmakkal (abban a korban, amikor még casio számológépes karóra volt a lakossági számítástechnika csúcsa), mintha legalábbis azonnal vágni kellene, hogy eszik-e vagy isszák... :) mindenesetre valahogy csak megtanultuk a szükséges dolgokat, bárhogy is titokzatoskodtak ezekben a szakkönyvekben... :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

az egy funkció lista, hogy mi micsoda. pl. $FCE2 vagyis SYS 64738 ami egy reset!:D

alapnak jó, de én mindig ráuntam!:D izgalmasabb volt időzíteni zenére effekteket, irq loader,stb.

emlékszem amikor bejöttek a navigációs rendszerek és volt ugye az IGO, akkor a demoscene-ben vadásztak programozókra. onnan tudom mert engem is megkerestek!:D
 

Inkább úgy érdemes nézni, kik és mikor írták.

Ha most kéne megépíteni egy lejátszót, 2021 babzsákfejlesztői simán megoldanák, hogy egy DVD lejátszó firmware-e bőven 1 GB fölött legyen.

Gyakran írok egyszerű algoritmusokat. A kipróbálás C vagy awk, majd a kódot beemelem az assembler forrásba és átírom. A 8 bites procin néhány sorral több, mert a 16 bites adatokhoz néha 2-3 utasítás is kell.

Egyszer soap protoklollra kellett írnom. A legkisebb linuxos soap forrás fordításkor (lex+yacc) 400.000 sort számlált, de még a feladatot is meg kellett oldani. Az pedig http szerver, kommunikáció több irányban, diszk tranzakció, adatbázis+keresés, stb. A soap lib használata helyett megítam 3800 sor C-ben. Ebből 600 sor a flavicon.ico volt, hogy kézi teszteléskor megjelenítse még a cég logóját is. ;) Persze 2-3 adat írogatásakor (a kódban 3 sor) nem használtam a 400.000 soros libet, így nem is függtem tőle.

Az utóbbi példa arra, hogy mondjuk 450.000 soros programot meg lehet írni 3800 sorban is. Ugyanakkor a projekt másik részét 3 cég, kb. 20-25 ember készítette. Na itt dolgoztam olyan táltosokkal:

Én: Rossz a http rq.

Táltos: Pedig én szabvány java http() hívást alkalmaztam.

b.

Én meg elolvastam az rfc-t - onnan tudom, hogy rossz. Aztán elolvastam a java http() leírását is, és elmondtam hogyan kellett volna paraméterezni.

Szóval lehet hencegni a sorok számával, de a magas sorszám gyakran csak a nem megfelelő eszközválasztást vagy a dilettáns programozást jelenti.

Ha én sorszámmal hencegek, mindig hozzá szoktam tenni: De olyan eszközökkel dolgozok, hogy ez legalább 3x annyit jelent. :-D

Minden szavad aranyat ér, csak rosszul ejted. ;)

Magára a soap-ra nem volt szükség. Mutatom az adattartalmat:

  • hívószám
  • helység
  • cím
  • flag

Egy telefonszámhoz tartozó cím soha nem fog bővülni, így a flexibilis formátumnak nincs értelme. Figyelemre méltó a "flag", ami azt jelzi, hogy a telefonszámhoz több cím is tartozik - vagyis bizonytalan a cím. No, ezt már nem értették a rendőrök. :-)

De tovább is csiszolhatjuk a gyönyört! A hozzáértők szerint az ISDN tartalmaz olyan mezőt, amibe a fenti információkat is lehet továbbítani  - a híváson belül. Tehát a rendszer java része is felesleges. Pedig a soap-hoz legalább 4x2 db Sun szerver kellett - mert más hozzáértők szerint csak ezen lehet megvalósítani ilyen alkalmazásszervert. :-D Mint írtam: "a magas sorszám gyakran csak a nem megfelelő eszközválasztást vagy a dilettáns programozást jelenti". Ezt még kiegészíteném a dilettáns rendszerrel is. Tudod láttam már pl. ügyfélszolgálati rendszert egységnyi költséggel, meg egy nagyobb terhelésre készültet 1/20 költséggel. Az utóbbit szakember tervezte. ;)

Köszi! Ez már szinte dícséret volt, ami helyett inkább lehülyézés szokott járni, itt a hupon. :-D

A soap-xml-hez kellett még egy cég, szakértővel. Meg is tudta tőlem, hogy az irányítószám = 0..5 karakter numerikus - kis országunkban - nem állja meg a helyét. ;) Az én xml-em pedig egy C header lett, ahol az xml-t tartalmazó stringet a fenti helyeken egy-egy %s tarkította.

Egyébként ez a munka 112 vezetékes része volt. A vonatkozó kormányrendelet 3 mintasort tartalmazot "*" mezőszeparátorral: vezetékes, mobil egyik és másik fajta koordinátákkal. Ebből lett az xml...

A soap egy olyan beteg állat, hogy az ismerkedésünk szinte első pillanatában egy olyan fórumon találtam magam, ahol két guru beszélgetett a csak ellentmondóan megvalósítható hibajelzésről. Ez van, amikor a jól bevált rpc-t http-re ültetik, ami ugye minden, csak nem rpc. Csak lenne annyi forintom, ahány felesleges protokoll született így! Talán az egyébként okos emberek - alapismeretek hiányában, mert az már elavult - fel-feltalálnak új dolgokat, amiket simán össze lehetne rakni a meglévőkből. Néha talán még hatékonyabb is lenne.

A SOAP egy nagyon elbaltazott protokoll, egyreszrol tul van bonyolitva, masreszt meg a neve is ellentmondasos. Ugye az S a simple elso betuje lenne, ami ugy ahogy van, hazugsag. HTTP felett egyebkent nem csak SOAP mehet, sima http requestekkel is meg lehet oldani egy csomo mindent. Amit csinaltal (gondolom mikrokontrolleren), az gondolom nem foglalkozott WSDL-lel sem, nem csoda, hogy ennyivel kevesebb sorbol kijott. A teljes implementacio meg megoldja neked, hogy letrehozza a megfelelo metodusokat, az azert akkora. Nem veletlenul nem irjak meg maguknak a szukseges subsetjet, hanem behuzzak a libet. Normalisan megtervezett (es nem tulbonyolitott) protokollnal nem lenne ekkora gond ezzel. Viszont annak is van elonye, hogy behuzod a soap libet, es csak hasznalod, az implementaciojaval meg szivjon, akinek ez a dolga, te csak a sajat reszeddel foglalkozol.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Dehogynem, volt ott WDSL is, meg minden is. Egyszer generálták az üzenetet, amit beleraktam statikusan a headerbe. Ugyanúgy a nyugtázásnál volt egy pozitív válasz, és akár többféle negatív válasz. Tehát annyit kellett megállapítani, hogy pozitív-e, mert a többivel úgy sem tudtam mit kezdeni. Csak megállapítottam, hogy ez valami válasz féle és megkerestem benne az ok-t. Ha volt vagy a node párja közben már nyugtázott, akkor abbahagytam, ha nem akkor ismételetem. (4x2 irányba kellett az üzenetet elküldeni.)

A Simple olyan, mint amikor veszek egy tyúkot 5 garasért. Hát odaadom a pénzt. Most meg közbeékelődött a bank, a kátyakibocsátó, internetszolgáltató, hitelesítő, mobilszolgáltató, terminál üzemeltető és a hálózat. A Jurassic park matemetikusa szerint: Minden paraméter a mutatókon belül, a rendszer hibátlanul működik. Közel van a teljes összeomlás. ;)

(gondolom mikrokontrolleren)

Ez megtisztelő! :-D Valójában 4+1 AIX szerveren futhatott - széljárástól függően max. 2 dolgozott. A feladat nagyságrendje miatt a futottak még kategóriában. A kb. 1 GB bemenő adatból keletkezett 50 MB, ami elég a vezetékes telefonszámok 2/3-ához tartozó címek tárolásához. (2006 körül, akkor még sokan voltak!) A lekérdezés ideje 220 ns, a diszk tranzakció <10 ms. A "soap -> put" 4x az összes feladat, amit 1 db printf végzett.

az implementaciojaval meg szivjon, akinek ez a dolga

Ez is egy álláspont. Az open source - különösen, amit sokan használnak - biztosan hibátlan. Nekem meg dokumentációval, mérésekkel, garantált megbízhatósági paraméterekkel kellett átadnom a rendszert. (Nem vitás, amire garanciát kellett vállalni, annak egy részét én találtam ki.) Mikor jobb az esélyem, - ha elhisszük, hogy valahány soronként általában van hiba - 3200 vagy 3200+400.000 sor esetén?

Az egész alapvetően egy fejlődés része volt. Ugye volt régebben a Corba, amelyik bináris protokoll volt, szarabbnál szarabb implementációkkal (megszakadó kapcsolatnál elhalt az egész, stb.). Az első dolgunk anno az volt, hogy megfogtuk, és leváltottuk saját megoldásra, amelyik pont kezelt mindent ami nekünk kellett.

Ettől függetlenül, az összes ilyen DCOM, Corba, stb. vacakkal az volt a gond, hogy nagyon nehéz volt vele a rendszerintegráció, mert ugye a 80-as porton kívül mást nem akar senki se engedélyezni, nem volt egy közös leíró, és az adatok binárisan mentek ami pl. a különböző processzor architektúrákon is jelenthetett problémákat, ráadásul sokszor baromira platform specifikus volt (DCOM), vagy iszonyat bonyolult a bekonfigurálása (megint csak DCOM). Erre lett az a megoldás, hogy csináljunk egy egységes leíró nyelvet (ezt végülis a corban-nal is megvolt) ami lett a WSDL ami viszont a corba összes hiányosságát pótolja, majd ebből generáljuk a kódokat (stub), amihez az egyes programozási nyelvekben már csak az üzleti logikát kell megírni. Az adat menjen XML-ben, ami szöveges, és tudjuk olvasni, és normálisan loggolni. Az egészet szabványosítsuk le, és csinálunk egy test suite-ot, ami biztosítja, hogy az adott SOAP implementáció megfelel a szabványoknak.

Alapvetően a SOAP lett a nagy rendszerintegrációs projekteknél az a közös nyelv, amit a mindenféle nyelvben írt, mindenféle rendszerek támogatni tudnak. Van validáció, van verziókezelés, van minden, és alapvetően egész jól működik (amikor működik). A te oldaladról nézve egyébként lehet, hogy overkill, csak a másik oldalról nézve, amikor több ezer rendszerrel kell integrálódni, ez a fajta szabványos működés - még ha mindenki tudja hogy bloated is - stabilan tudja hozni az üzleti elvárásokat. És ilyen méretben bizony ez felülír minden mást.

 

Igazad van, fejlődés és szabványosítás. És még az eszköz is jó. Én meg az örök szkeptikusként csak azt kérdőjelezem meg, hogy az a szakértő, aki a 0..5 numerikus specifikációt adja az irányítószámokra (és magyar!), hát ugye. Hallottam olyan kijelentést, miszerint tanultam ilyen szervezési módszert, olyan projekmenedzselési módszert, de: Ha nem arra bízod a feladatot, aki meg is tudja csinálni, akkor megszívtad!

A platform specifikus (win),  "a különböző processzor architektúrákon" (Intel 8 bit), meg a 80-as port (az meg a brózer, amin adatokat továbbítunk??), mind olyan csökevény, amin már régen túl kellet volna lépni.

A felsorolt pozitívumok ellenére csak nő a kódbázis, amit már biztosan nem fog átlátni senki. Érdemes olvasgatni a joelonsoftware cikkeit, mert ahogyan az ember mindig háborúzik, úgy ezek a tapasztalatok is nem csak a szakmát, akódolást, a projekteket, hanem az aktorok viselkedésének vetületét írják le.