Szoftver bloat érthetően

 ( pehsa | 2018. szeptember 30., vasárnap - 8:00 )

Aki hajbazer kollégára számított, azoktól bocsánatot kérek. :)

Nikita Prokopov (Tonsky) írt egy nagyon jó blogbejegyzést a bloat témájáról. A megfogalmazása és érthetősége sokkal jobb, mint hajbazer dobálózása itt a HUP-on. (Lehet tanulni a normális megfogalmazást és nem csak dobálózni kellene azzal, hogy az XP jobb...)

http://tonsky.me/blog/disenchantment/

Egy-két dologgal azért én magam sem értek egyet, mint például amikor a Windows 95 és a Windows 10-et olyan egyszerűen hasonlítja össze, hogy mind a kettő ugyanazt csinálja mégis 133-szor nagyobb a 10 mérete.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Amit a "tonsky" programozói önostorozásként leír, az az emberi társadalom egyértelmű elhülyülésének eredménye. "Ha nincs ló jó a szamár is". Erre az elvre épül ma a világ fogyasztási mókuskereke. Nincs az emberekben önismeret, büszkeség, eltántoríthatatlan akarat a jobbra, az igényességre. (Ezeknek az erkölcsi kategóriáknak a helyét a programozóknál is az önfényezés vette át a szerepét.) A munkahelyeken a maximális minőségi kvalitásokat igénylő erőfeszítések után sem kapkodnak az emberek. Nem vívhatjuk ki a közösség elismerését a jól végzett munkákkal, de ha valaki véletlenül ezzel a szemlélettel próbálkozna a munkahelyén, az "plecsniként" gyorsan megkapja a hülye munkamániás jelzőt.

Nem akar senki világot megváltani, mint annak idején pl. Linus és a vele párhuzamos időben munkába álló emberek. Ma mindenki elégedett azzal ha pénzt keres, 3 évenként még nagyobb autót használhat. Nincsenek nagy célok. Csak pénzt érő blöffök. Ez az emberiség kipusztulása előtti utolsó nagy nihili korszaka. Nem véletlen, hogy nem a tanulásért és a világ megváltásáért harcolnak mozgalmak, pártok, de pl. a fű legalizálásáért, homoszexuálisok jogaiért, "ingyen sörért", stb., igen hangosan. Elhülyülni manapság igazán trendi dolog. (Véletlennek azt sem tarthatjuk, hogy a komédiák világa Melissa McCarthy-kért "esedez". Erre van tömegigény. - Szuper!)

...az az emberi társadalom egyértelmű elhülyülésének eredménye...

Minden szavad igaz, de ez az egész jelenség még jobban megérthető a gazdasági jelenségek, - és most itt hegyezzük ki - a szakmai folyamatok tükrében.

Volt először a hardver...
Nem a szoftver, hanem "a hardver futott". Ebben a korszakban a szakemberek számára szinte nulla volt a tévesztési lehetőség. Ez alatt természetesen nem azt értem, hogy nem tévedhetett egy ember, hanem a produktum nem tartmalazhatott hibákat.
A következő a gépi kód és assembler állomása. Ez még mindig hardver, csak flexibilis eszközök segítségével megfogalmazva. Ezzel párhuzamosan megjelent a szoftver is. Az assemblerben kivitelezett produktum, - mivel hardvert valósít meg - még mindig nulla közeli hibalehetőséget enged meg. De ugye, a szoftver már nem. ;)
Aztán jött a C, amely lehetővé tette a gépközeli programozást és szoftvertermékek előállítását is. Míg az assembler eleinte a hardverhez értő kevés szakember privilégiuma volt, a fejletteb nyelv már szélesítette az alkotásban résztvevők körét.
A C++ már igazi tömegek számára biztosított munkát. Ezzel egyúttal elindította a szakma felhígulását.
No, és hol tartunk most? Informatikus hiány van! Fluktuáció, nincs igény, tudás, hajlandóság az alapos munkavégzésre.
(Mielőtt bárki is belekötne, ez nem egy szoftvertörténelem óra, csak kiragadott példa.)

A dolog buktatója a hardver. Van egyszer a Moore-törvény, ami a sebesség exponenciális növekedését jósolta és az idő bebizonyította a sejtés működését.
Sajnos a szakma felhígulása, a szereplők (összefoglalásként) trehánysága, és az ilyen hozzáállással készült toolok használata a lassulásban magasabb negatív kitevőt eredményeznek.
Egyszer oktatás közben - régi szép időkről mesélvén - kaptam egy kérdést, hogy miként értékelem a fejlődést? Hiszen a "személyi számítógépek hajnala óta" a szakmában vagyok. Rövid fejszámolás után - amit extrapolálok a mai napra - a következő megállapítas tehető: Azóta a processzorok teljesítménye 5000000x (ötmillíószor) nagyobb, miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el.

A cikk írója szerint: That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.
Ezt kellene megérteni néhány huptársunknak is, akik szerint én vagyok a rossz, amikor nem tudok, se nem is látom értelmét annak, hogy egy feladatot perlben oldjak meg.
Igen, már megint a hardvernél tartunk! Az OOP esetében fel kell fogni a sok absztaktció mellett azt az egyszerű tényt is, hogy bizony a 10x több memória megtöltése 10x annyi időbe kerül. Ez egy gyors gépen persze nem számít. Biztosan nem számít, hiszen ettől (is) lassabbak a programok. :-D És nem szabad beérni azzal, ha a fejlesztő gépén még elfogadható idő alatt lefut a feladat! Hiszen ma már kizárólag multitasking környezetben futnak a programok. A feleslegesen felhasznált erőforrások a többi program elől veszik el a lehetőséget.
Az ilyen dolgokat összevonva a hasonló elvek szerint készült libbel és a nem túl nagy kvalitású programozóval máris jól megdöntöttük a Moore-törvényt!

Sok esetben tapasztaltam, hogy egy rendszert modernizálva és korszerű gépen futtatva a jelentős mértékű lassulás mellett funkcióvesztés is fellép. Vagyok annyira szkeptikus, hogy előre meg tudom jósolni a romlás mértékét. De mindig bejön. ;)

I’ve been programming for 15 years now.
No, én meg 35. Nem dobálodzom azzal, hogy az XP jobb. Egyszerűen - előzetesen hozzáértő szakemberekkel konzultálva - nem vállalom fel a fenti jelenségek miatt keletkező extra szívást. Így aztán nyugodtabb az életem.

Az alapgondolatokkal egyetértek, de érzek túlzást a mondanivalódban. Azért ZX Spectrumon egy sin(x) függvény kirajzolása súlyos időbe telt, ellenben egy mai PC-n akár egy viszonylag lassú script nyelv felhasználásával is elenyészően rövid idő alatt megtörténik ez.

A mai gépek sokkal jobban használhatók, mint a régi picikék. Viszont az igaz, hogy közel sem nyújtanak a maiak akkora gyakorlati előnyt, mint ahányszoros a számítási kapacitásuk, s ebben a software-esek keze vaskosan benne van.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem is értem miért vetsz össze egy minimál kiépítésű 8 bites mikrogépet egy 32/64 bites pécével. Erről nem volt szó. A sin(x) egy mai, akár több fpu-t tartalmazó gépen nem gond.

A pici gépekre meg jó tréfa az Iron Sky, amiben okostelefonnal irányítják az űrhajót. ;) Megtehetik, hiszen milliószor nagyobb a számítási teljesítménye, mint az AGC-nek. A holdra szállás szkeptikusok meg mitsem értve ehhez, megkérdőjelezik a holdra szállást az alacsony számítási teljesítményre hivatkozva.

No, de mi a túlzás?

Ez:

Azóta a processzorok teljesítménye 5000000x (ötmillíószor) nagyobb, miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ok, számoljunk!
Egy i8080 2MHz, egyelőre a "másik"* 4,2GHz: 2100x
Egy utasításhoz szükséges órajelek száma (átlagosan) 7 - 1: 7x
Egy ciklus alatt végrehajtott utasítások száma 1-6*: 6x
INT méret 8-32, legyen: 2x
Magok száma 1-8: 8x

Ez idáig: 1.411.200

* A "másik" cpu itt üldögél a szomszéd szobában, és 14 éve nem gyártják: IBM POWER4+
A csalások:
- A régi cpu csak 1,2GHz-es, megelőlegeztem neki a manapság egyáltalán nem kiugró 4,2GHz órajelet.
- Szintén megelőlegeztem a 8 magot és nem vettem figyelembe a "multiprogramozási veszteséget", bár jobb helyeken a multiprogramozás (pl. hyperthreading) vesztesége már régen 0.
- Nem vettem figyelembe, hogy a pc korszak kezdetén általában direktvideót használtak, míg a mai rendszereknél a gpu tehermetesíti a cpu-t.
- Az INT méretet 32 bitre 2x szorzóval vettem figyelembe. Ezen lehet vitatkozni, de manapság úgy is a 64 bit a divat. Valamint ->
- Szó sincs az egy utasítás hosszánál:
-- Az egy fpu utasítás elég sok 8080 utasítást ér.
-- Elég régen használnak altivec (MMX, 3Dnow!, stb.) egységet, ami órajelenként és magonként több utasítást képes egy órajel alatt végrehajtani.
-- Azt, hogy manapság a crypto engine, meg még jó néhány turpisság is teljesen természetes - már meg se említem. ;)

Szóval az 5M szorzót úgy is lehet érteni: nagyon-nagyon minimum. :-D
Ha úgy tetszik, a 4,7MHz-es pécét is veheted alapul, mert azzal is bőven el lehet érni ezt az arányt.
Legalábbis POWER platformon. Az Intel meg sokkal jobb, mint az IBM (egyes újságírók szerint), tehát biztosan! XD

A magok szama tobb:
https://arstechnica.com/gadgets/2018/06/amd-unveils-threadripper-2-up-to-32-cores-64-threads-for-an-enthusiast-chip/

csak hogy meglegyen az 5M+ ..
es van MMX,SSE,AVX .., 512 bit register.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem akartam egyből bézbólütővel jönni, ezért választottam egy 14 éves szerkezetet:
Ez egy kicsit jobb: https://en.wikichip.org/wiki/ibm/microarchitectures/power9
Itt is van altivec, de már régen sem volt bekötve a cpu-ba.

Ezzel már talán a 100M+ is bőven összejön, de nem tipikus desktop. ;)

Most már csak az szorul magyarázatra, hogy egy 5e6-szor gyorsabb gépen miért fut valami lassabban, mint az eredetin. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kedvecem az esemény-lavina. Pont most fogtam egyet. A vicc az, hogy a mai gépek annyira erősek, hogy sokszor észre sem vesszük - fejlesztőként - az ilyet. Főleg, ha mondjuk egy i7-en fejlesztünk kis adatbázisokkal, és aztán élesben egy Atomon futtatják nagy adatbázissal. Persze ha komoly dologról van szó, és mérünk meg minden, akkor nehéz benézni, de ha csak valamit gyorsan összeütünk, akkor előfordulhat.

A lényege az, hogy a mai GUI objektumoknál bevett gyakorlat, hogy listenereket aggatunk az értékekre: például ha megváltozik egy css bejegyzés, akkor újra kell rajzolni az általa érintett egyéb objektumokat. Ha a kiválasztott elem változik - pl egy listában a leveleink - akkor a hozzá tartozó információt - előnézetet - befrissítjük.

Na most ha nem vigyázunk, akkor lehet olyanokat csinálni, hogy egy változás miatt újrarajzolunk egy egész fát, de az újrarajzolás minden lépésére újrarajzolunk egy kisebb fát, aminek minden ágára újrarajzolunk egy ikont. (Persze vektorosan nagyfelbontásban, amit aztán leskálázunk kicsire, mert úgy a leghatékonyabb).

Ilyen módon simán lehet a modell elemszámával szorozni a futásidőt akár kétszer háromszor is. (n négyzet, n köb futásidő megvan egy pillanat alatt) Az ilyen gyakorlat alá lehetetlen elegendő vasat tolni. Ezzel még Moore is alig tudott versenyezni, és most hogy vége van, muszáj újra megtanulni programozni :-).

Gondolom, valami elgépelést javíthattál, mert olvastam már... :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Á, ez nem esemény-lavina. Hanem az a hibahalmozási eset, amikor
- a fejlesztő gépe a leggyorsabb, és
- nem valós adatokon,
- nem a tényleges adatmennyiséggel dolgozik.
Az éles rendszer sebessége számítható. Nem is kell GUI, meg ilyen bonyolult felépítés ahhoz, hogy valami tényleg lassan fusson. Annak idején a "pécémen 100.000 adattal lefut..." számszerű értéke soha nem érdekelt, és nem is vettem át üzemeltetésre.

Abban nagy igazságod vagyon, hogy meg kell tanulni programozni. Aki nem tud, az i7 nélkül fel fogja adni, és nem fogja befejezni a munkát. A rutinos versenyző már előre elkerüli az önszopatást. ;)

Igen, de ha van egy algoritmus, amiről tudom, hogy lineáris, és tudom, hogy adatom nem lesz több 1000-nél, és mindez nem kritikus helyen fog futni, akkor előfordul, hogy nem mérek - értsd próbálom ki :-) - lassabb gépen. Mert minek, ha egy 8086-oson is elfutna kellemes tempóban? Kivéve, ha van egy eseménylavina, amire épp nem számítottam :-P

Erre még mindig áll a fenti dolog. Már megint nincs kedvem dolgozni, ezért mesélek két példát.

Hasonló elvekkel írtak meg egy programot és futtattak egy programrendszert. Az eltérés csak annyi, hogy 1000 helyett 3M adat és napi működés volt az előírás. A program egy formátumkonverter előtét volt. A teljes programrendszer tartalmazott néhány sort jellegű műveletet is, ami több szegmensre darabolt adatokkal (a sort így működik) szintén lineárisnak tekinthető. Az eredeti futásidő 4 óra körül alakult.
Telt-múlt az idő, és az adatok néhány százalékkal bonyolultabbak és lassanként több mint kétszer annyian lettek...A futásidő meg "lineárisan" tartott a napi 120-130 óra felé. ;)
Átraktam egy 4-8x gyorsabb gépre a cuccost. A főnököm megbízta a tojáshéjas új kislányt a 19 órás konverter program újrakomponálásával és csiszolgatásával. Specifikáltam a feladatot és az eszközöket, valamint az új gépen futtatott cat jellegű programmal végzett sebességmérés alapján a 19 óra helyett - az adatok harmadára =2M - 14 perces futásidőt. Azért is, mert a megnövekedett adatmennyiséget bizonyos korlátok miatt már 3 részre kellett osztani. Ez a felosztás az addig lineáris működésű sorttmp területet négyzetesen lassítja, tehát kicsit hangolni kellett a diszkeket. Az előállított adatok vidéki telephelyekre terjesztését is módosítottam 3-4 óráról 8 percre. A végeredmény stabil 2 órás futásidő lett, ami a 130-hoz képest nem is olyan rossz. :)
Az adatmennyiség további növekedése és az idő vasfoga miatt meglépett újabb gépcserénél a számított futásidő 17 perc, a mért 12 perc lett. Igaz, ekkor már 5 szegmesre kelett osztani a 6->14M adatot.
Szerintem nem túl gyakori az olyan megoldás, amikor az adatmennyiség nő, a gép is gyorsul és a futásidő csökken. ;)

A másik példa pedig nem az offline feldolgozás területe. Az alap egy sybase karbantartó rendszer, 30-50 felhasználó és napi adatexport. Az egészet több öreg profi tervezte. Az adatbázis mérete 1GB + 3GB "játszótér", amelyhez 256MB memória is kell. Az export ideje 2 óra. Hozzáértő szakember (matematikus, aki 10 évig vitte a rendszert) el is magyarázta, hogy ez egy cat szerű művelet, nem igazán lehet gyorsítani.
Nosza, modernizáljuk a rendszert a szabványos eszközökkel, és irdatlan mennyiségű erőforrással!
(Hülyevagynemérteszhozzá! Az óra-kell, meg a táblaterek... :))
A végeredmény elég jó lett:
- A hardver 22x gyorsabb.
- A diszk és ram mennyisége leírhatatlan. ;)
- Alkalmazásszerver, korszerű felépítés, vékony kliens, nagy biztonság, stb.
- A munkavágzés sebessége az eredeti töredékére lassult. A felhasználók több perces várakozások mellett dolgozhatnak.
- Az export idő 2->19 óra. Magyarázom: belelóg a munkaidőbe, ami alatt a felhasználók malmoznak. Bár ez egy agy nélkül betervezett tűzfal elhagyásával 11 órára csökkent. Igaz, néha megvadult és akkor a futásidő értéke beláthatatlan lett. :-D
- A költségek 300->1500MFt és a rendszer még nem készült el.

Hosszabb ideig dolgoztam külsősként a cégnek. Véletlenül mindig akkor tárgyaltam a főnökkel, amikor megjelent egy emberke: Írd már alá a memóriabővítést! :-D
A fenti projekt rengeteg üde színfolttal rendelkezett. A projektet országos hírű szakember vezette, az egyetemen adatbázist tanított! A pörformanszra* vonatkozó aggályaimat rendre, gúnyos magyarázatokkal le is szerelte. (Én meg az elmúlt 10 évben az adatbázisszervert üzemeltettem, hangoltam.) A későbbiekben kiderült, hogy a jelenlévő 30 főből a tender címét csak hárman ismerjük. XD

* Columbo felügyelőnek magyarázzák: Tudja, olyan pörformansz! Amikor a színpadon belehugyozik egy pohárba és utána megissza.

Mi ebből a tanulság? Az üzleti siker nem mindig párosul a kielégítő működéssel. A fiatalok nem buták, - hiszen egy ilyen kijelentés az emberi jogaikat sértené :) - csak nem tanulták meg az alapos munkavégzést. Ebben pedig semmi hiba, hiszen nincs is rá szükség.

Hiába no, te vagy a helikopter...
--
Gábriel Ákos

Inkább, mint a rénszarvas. ;)

Sem Jénszajvas? :))


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

https://www.tomshardware.com/reviews/15-years-of-hard-drive-history,1368-3.html elvileg catolni 1996 -ban is gyorsabban lehetett.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Túl sokat emlegettem a catot. ;)
Ezzel csak a lineáris feldolgozás elméleti sebességét mértem, amit még szorozni kellett a szoftver "lassító hatásával".
A diszk sebsességét nyugodtan lehet szorozni 10-12 értékkel, mert a feldolgozás
- külső zónán,
- tükrözve 2 diszken, a sort 3 diszkes bufferre optimalizált stripe, és
- tömörített inputból ment - aminek a kifejtési ideje gyakorlatilag 0.
A tömörített adat általában "éppen most érkezett", ezért feldolgozáskor inkább a bufferben tartózkodott, mint a diszken. Ha ehhez hozzáveszed az 1,8GB/s memória sávszélességet, akkor még 1996-ban is elég gyorsan lehetett catolni. ;)

Már megint nincs kedvem dolgozni...

Látod-látod, az AIX-esek :-D

Viccet félretéve: az a különbség köztünk, hogy más problémákat szeretnénk megoldani. Azokat a problémákat, amelyeket a threadben felvetsz (pl. relatíve sok, de egy gépen belül elférő adat rendezése hatékonyan) bizonyára pont úgy kell megoldani, ahogy írod. Működik is jól, amíg:

- elfér az adatmennyiség a gépedben és/vagy a környékén (mondjuk néhány terabyte méretekig)
- a géped nem romlik el (azért nem teszed a vacak x86-ra az alkalmazást a kiváló Power helyett, mert gyakrabban romlik el).

Próbáld meg megoldani ugyanezt a problémát a gépeddel akkor, amikor az adatmennyiség mondjuk petabyte-okban mérhető. Egyáltalán nem lesz lineáris a sort algoritmusod, szűk keresztmetszet lesz pl. a processzorok darabszáma. Persze adódik a megoldás: több gép kell, szét kell osztani rájuk a terhelést. Az algoritmus ugyanaz, mint a sort mögött, csak most úgy hívják, hogy MapReduce és nem több processzorra, hanem több gépre tolja szét a terhelést.

Viszont ha ez így meg van oldva szoftverből, akkor miért is kell a nagyobb megbízhatóságú és drágább Power gépeket venni az x86-ok helyett? Ööö, nem kell. Olcsóbb, jobb, hatékonyabb.

És visszatérve az eredeti méretű problémához: ha van egy olyan jól működő módszer, amellyel akár három nagyságrenddel nagyobb méretű adatokon bizonyíthatóan működik minden, és nincs hátránya kicsiben is úgy csinálni, mint nagyban, akkor miért ne csinálnánk kicsiben is úgy?

Egy helyen egyébként feljebb csúsztattam. A Power gépek, amelyekkel találkozok a munkám során (E870-ek, 30-40 processzorral, 1-2 TB memóriával, van belőlük 3 db) konkrétan több gondot okoznak az üzemeltetésnek, mint pl. (az egyébként tényleg vacak) HP DL460c-k. Két okból:

- az egyik, hogy gyakrabban vannak hülye hibái a Power-es gépeknek (pl. failoverelt a storage? akkor megállok...), amelyet hogy-hogynem általában egy firmware frissítés javít meg (olyan, mintha nem kapna elég gyakorlati tesztelést a platform, és elméletem szerint a piaci elterjedtség alacsony volta miatt pont ez is van)
- a másik, hogy ha elveszítesz egy vasat (egy alkalommal fordult elő 4 év alatt), akkor elveszítetted az infrastruktúrád harmadát, ami fájdalmas (ellenben az x86-os blade-ek tényleg gyakrabban halnak meg, de pont nem fáj egyáltalán, ha elveszíted az infrastruktúra 0.3%-át...)

Vagy egy szavazásba vagy az itteni blogomba mindjárt csinálok egy kapcsolódó folytatást...

"Ez alatt természetesen nem azt értem, hogy nem tévedhetett egy ember, hanem a produktum nem tartmalazhatott hibákat."

Persze, ezért sípolt folyamatosan Apollo 11 leszállása közben a hibajelző, mert "régen minden jobb volt". :)

"A C++ már igazi tömegek számára biztosított munkát."

A C++ konkrétan az egyik legbonyolultabb programnyelv. Bár tény, hogy bizonyos dolgokra jobb absztrakciót adott, mint a C.

"miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el."

Kérdés, hogy hol húzod meg ugyanazt a feladatot. Szöveget lehet beírni egy dobozba? Szöveget lehet beírni egy dobozba, ahol automatikus helyesírás-ellenőrzés van és már a végső, nyomtatásban megjelenő formázási állapotával együtt látod? Mindkettő "csak" egy szövegszerkesztő.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem ártana elolvasnod miről beszélsz. ;)
A szoftver pont jó volt, csak elfogyott a 64GB ram. :-D Különösen szép, hogy Win95 példa is van a végén.
Ugyanezt a FejlettFirefox olyan automatikusan oldja meg, hogy kiveheted a pipát - ha tudod mi szállt szét. Esetleg korábban feldob egy ablakot: Az oldalon script fut, de qrvalassan. Micsinájjak? (Futtasd gyorsabban!)

A C++ -ról véletlenül Bjarne Stroustrup egy mondatát idéztem. De nem ez volt a lényeg. Az úgy látszik nem jött át.

Példádban az "ugyanaz a feladat" legyen szövegbevitel. Manapság egy igen gyenge gép tőlem közben lefordíthatja akárhány nyelvre is. Rendelkezésre áll a technológia és elegendő erőforrás, hogy a szövegbevitel ne legyen lassabb. De nem így van.

És még meg is magyarázod: Ez az 1000LE teljesítményű autó azért megy feleolyan gyorsan, mint egy trabant, mert cédét is tud játszani. KETTŐT! :-D

Példádban az "ugyanaz a feladat" legyen szövegbevitel.

Nade nem ugyanaz a feladat. Bemész a boltba, és lassan már nem nagyon tudsz fullhd alatti felbontású monitort venni (vagy ha igen, azt nem akarod megvenni). Ergó az átlag felhasználó bizony a 25 évvel ezelőtti felbontásnak az n-szeresével nézelődik. Szigorúan grafikus felületen (ellentétben a 25 évvel ezelőtti átlaggal). És ha pixeles fontot tolsz az arcába, akkor még el is hányja magát, hogy mi ez a fos... Tehát míg 25 évvel ezelőtt 3 assembly utasítás volt kirajzolni egy betűt a DOS képernyőjére, ma az antialiasolt fonttal a betű kirajzolásán még a GPU is megizzad. Mert az "ugyanaz a feladat" valójában sokszorosára nőtt. Nőttek a lehetőségek - nőttek az igények is, sokszor öntudatlanul. Én sem szeretnék pixeles fontokat nézegetni ma már...

Az autós példa amúgy nagyon jó: már senki nem nagyon vesz 100 paci alatti autót - miért? mert min. 300kg-val nehezebb az átlagos autó a 25 évvel ezelőtti állapotokhoz képest. Mert valahová el kellett rakni a sok vasat, ami a töréstesztek szintén jogosnak tűnő igényei miatt kell. Ugyanaz a feladat? Hát igen, a-ból b-be... közben meg nem, mert időközben megnőtt az az igény, hogy egy átlagos balesetben ne dögöljön már meg számottevő eséllyel a fél család. Ja, és közben lehetőleg pöfögjön (= fogyasszon) kevesebbet a gép, mert megfulladni sem szeretne az emberiség.

Ebből is pont az látszik, hogy a hardver támogatás létezik. A 3 utasítás ideje alatt lefut (jó néhányszor) az a néhány száz utasítás, ami a mobilokban is jelen levő gpu felé tolja a feladatot.
Így időben ugyanott vagyunk, amikor ki kell írni egy karaktert. Továbbra is marad a kérdés, hogy a 3 régi utasításnyi időn kívül (az i8080 "néhány százezer" utasítás/s) mi a rosseb történik az 5Mx gyorsabb hardveren - amitől lassabb lesz?

Tehát míg 25 évvel ezelőtt 3 assembly utasítás volt kirajzolni egy betűt a DOS képernyőjére,...

Leírnád ezt a három utasítást?

mov DX,(string address)
mov AH,09h
int 21h

Ja, most ez egy Java sor...

--
https://iotguru.live

Mutass java processzort. Processzor utasításokról van szó. A java kiíratás mögött kódtömegek állnak.

Szerinted a 21-es megszakítás mögött mi állt, ha nem kódtömegek? :)

--
https://iotguru.live

olvass tovább vagy újra vagy értő módon.

Én teljes mértékben értően olvastam. Arról volt szó, hogy három assembly utasítás kirajzolni egy karaktert. Ja, hogy az a három sor egy függvényhívás, ami elvégzi a feladatot? Ja, akkor ennyi erővel bármilyen nyelven kiírni egy karaktert egy sor. Ami ugyanúgy egy függvényhívás. Ez mindössze ennyiről szól. Minden mást már te képzelsz hozzá.

--
https://iotguru.live

A karakter kiíratás az int10h volt. És ez, amit betettél, nem három utasítás, mert az int 21h (vagy az int 10h) egy eléggé terjedelmes kódot futtat. Az int 10h mögötti megszakításkezelő rutin forrása 2000 soros ass kód. Az int 21h mögötti kód ennél nagyságrenddel hosszabb.

Még annyit, hogy az int 21h az szoftveres megszakítás, míg az int 10h az hw-es volt, ha jól emlékszem...az int 21h 9h funkciója egyébként az int 10h megszakításkezelővel rakosgatja ki a karaktereket. Tehát az int 21h (vagy 10h) valóban egy utasítás...de csak egy kódot hív, mint a call pl.

Gondoltam szólok.

Vágom. Nyilván nem lehet egy utasítással karaktert kiírni. Mondjuk szeriálon AVR-en lehet: UDR0=65 és még maradt is 2 utasításom :-)

Tollal vagy ceruzával meg 0 utasítás. De itt nem ezek az esetek voltak felsorolva, hanem az intel a 8080-tól napjainkig.

Az int10 BIOS hívás, az int21 DOS rendszerhívás. Mindegyik szoftveres, és funkcionálisan megfelel a következőnek:

                PUSHF
                CALL vector (0..255)

Ez meg a "3 soros" program töredék, ami közvetlenül ír a video memóriába, monokróm vagy egyéb (CGA, VGA) képernyőre. (A teljesség igény nélkül.)
- a karaktert és az attribútumot beírja a video memóriába, a pointerét inkrementálja és menti
- inkrementálja a kurzor pozíciót (SET_CP) - de ez nem szükséges
Mondjuk a scroll és hasonló finomságok hiányoznak.

                mov     ah,ATTRIBUTE
                mov     al,CHAR
                les     di,dword ptr VIDEO_OFFSET
                stosw
                mov     VIDEO_OFFSET,di
SET_CP:
                mov     dx,CRT_INDEX            ; MDA/EGA reg index
                mov     al,CRT_R14              ; cursor position hi
                out     dx,al
                inc     dx
                mov     ax,VIDEO_OFFSET
                shr     ax,1
                xchg    al,ah
                out     dx,al                   ; MDA/EGA indxd data
                mov     al,CRT_R15              ; cursor position lo
                dec     dx                      ; MDA/EGA reg index
                out     dx,al
                inc     dx
                xchg    al,ah
                out     dx,al                   ; MDA/EGA indxd data
                mov     ax,VIDEO_OFFSET
                shr     ax,1
                div     ROW_SIZE
                xchg    ah,al
                mov     CURSOR_LOC,ax

Nagyjából hasonló áll az int10 mögött (bár ez nem az). Az int21 először dekódolja a hívást, majd hívja az init 10-et egyszer vagy többször.

A DOS és BIOS megszakítások kódja lehet hosszú, de csak ilyen rövid kódrészletek futnak. Ennek ellenére a "3 utasítás" nem nagy túlzás akkor sem, ha 53. Az is hamar lefut.

Nagyjából. Csak jóval több, mert először megnézegeti a video hw típusát, beállítgatja a paramétereit, címeket, anyjakínját, stb., lekéredezi az aktuális videomódot, a kurzor pozícióját a lapozható videómemória esetén az aktív lap címét...stb...

Az az 53 is inkább egy nagyságrenddel, de lehet hogy kettővel több...ami már számít. Vagy ha ilyen lazák vagyunk, akkor tényleg a java egy utasítással ír a épernyőre.

Ez nem így van. Az alapadatokat gyakorlatilag a BIOS biztosítja, amit elég egyszer megkérdezni.

VIDEO_SETUP     proc
                mov     ah,0f
                int     10                      ; get state, al=mode, bh=page
                mov     ORIG_VIDEO_MODE,al
                mov     ah,12                   ; check for VGA
                mov     bl,10
                int     10
                cmp     bl,10
                je      NOVGA
NOVGA:
                cmp     ORIG_VIDEO_MODE,MONO_MODE
                jne     COLOR_CARD
                mov     VIDEO_SEG,MONO_SEG
                mov     VIDEO_MODE,MONO_MODE
                jmp     TEST_CFG_EXIT
COLOR_CARD:
                mov     VIDEO_SEG,COLOR_SEG
                mov     VIDEO_MODE,COLOR_MODE
... és így tovább még egy oldalon keresztül...

Belinkeltem a bios forráskódját. Legalább azzal ne vitatkozz!

Kikérem magamnak! Én csak állítottam valamit rutinból. Aki vitatkozott, az Te voltál. :)

A linkelt biosban a karakter kiírása mindennel együtt lineárisan 104 utasítás - ezek szerint ennél lehet egy kicsivel kevesebb is. A hívás előkészítéssel együtt kb. 107. Ez azért elég messze van a bepoénkodott 53 x egy-két nagyságrendtől.

A bemásolt kódrészletek egy bios extension-ként, vagy dos programként is futó Wyse60 terminálból származnak, amit - mivel nem általános feladatra készült - kicsit gyorsabbra írtam biosnál.

Aztán egy bios nem csinál nyarat. A rengeteg gyártónak rengeteg féle, akár az IBM specifikációnak nem megfelelő biosa van. Néha meg pont az IBM nem kompatibilis önmagávl. ;)

Nos, nem. A karaktert az ember a videómemóriába írással rajzolta ki. Karakteres üzemmódban egy betűt egy word beírásával lehetett megjeleníteni. Ez sorfolytonos megjelenítésnél a kiírandó adat betöltése (ideális esetben 1-2 utasítás), plusz egy szál stosw. Az előkészítés (szegmensregiszter feltöltése: 2 utasítás, címregiszter beállítása: 1 utasítás) sem egy "ökör ára", és az csak ritkábban kell.

Ez az int 21h-s, de még az int 10h-s amúgy fényévekkel lassabb volt.

Hopp, igazad van.

Ez egészen a cga kártyákig volt igaz. A VGA megjelenésével viszont már kénytelen voltál az int-eket használni vagy a hordozhatóságról lemondani. A direkt írás addig volt menő, amíg nem létezett más videomemória cím, mint a B800h és a C800h (ha jól emlékszem). A VGA megjelenésével viszont annak saját biosa is működni kezdett...

Régen volt, kopott már ez a dolog sokat. :D

Ebből csak az következik, hogy már a VGA is bloat volt!

Én el tudok lenni karakteres képernyőn is. Adatfeldolgozáshoz bőven elég.

HUP-ozni pl. tök kényelmetlen lynx-szel és társaival... :-)

Na tényleg! :)

De ha már..., akkor ki emlékszik a DOS-os idők modemmel hívható nem tudom milyen csoportok vagy mik, ahonnan letöltögetni lehetett...és ott is ment a fórum rendesen. Az első modemem 1200baudos volt...de már faxmodem volt! :)

Karakteres std módokban nem külöbözik a VGA az egyszerűbb kártyáktól. A video memória címet meg az aktuális lapot (képernyőt) meg lehet szerezni, utána megy minden a megszokott módon.

A probléma akkor kezdődik, amikor egy direktvideós pc programot raksz át terminálra. A terminál optimalizálóhoz nem jut el az információ és mindig meg kell fejtenie mi történt. Ilyenkor a képernyő részlet megváltozása helyett gyakran törlődik, majd újraíródi az egész kép. És ez bizony nagyon csúnya a soros vonal alacsony sebessége miatt.

Mindegy. Aki nosztalgiázni akar, az itt kutakodhat: https://github.com/kaneton/appendix-bios/ :)

A standard DOS konzol CGA-kompatibilis karakteres módban ment, és én pont erről beszéltem (az átlag karakteres DOS-os program is pont ezt használta - mondjuk ha Turbo Visionben írtál valamit :-)

A palettás, 8-bites grafikus üzemmódban (ilyen ugye egy volt a standard VGA-ban) is lehetett hasonlóan direktben írni a memóriát, csak ott már egy pixel volt egy byte, ergó egy karakterhez sokkal több adatot kellett beírni...

Linus (és a linux) baromi jókor volt baromi jó helyen.
(Az akkori helyzetről ld. pl. "The art of unix programming.")

Most sokkal több a lehetőség, millió egy projekt van, csak már nehéz kitörni, mert az igények nagy része már így-úgy le van fedve.

> Linus (és a linux) baromi jókor volt baromi jó helyen.

No meg, hogy a közösség felkarolta és kipofozta neki.

@@
"You can hide a semi truck in 300 lines of C."

Neki? Esetleg mindenkinek, vagy mindenki magának.
De nem neki.

" mint annak idején pl. Linus"

Linus annak idején csak írni akart egy oprendszert, hogy megismerje a 386-os programozást. Valóban világmegváltás volt az eredeti cél. ;)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

jó jó! csak a saját kis világocskáját akarta megváltani, de akkor is!

Jó, hát ahhoz képest kicsit valóban elszaladt a ló. :)

De csak azért tudott elszaladni, mert volt egy niche amit be lehetett tölteni és volt erőforrás (ráérő, unixtól/bsd-től éppen elforduló developerek) akik beszálltak hekkelni.

Én nem igazán látom, hogy a "pl. a fű legalizálásáért, homoszexuálisok jogaiért" harcoló mozgalmak miben akadályoznák a "tanulást és a világ megváltását".

A tanulás többnyire szabadon hozzáférhető. Még ha az iskolai oktatás fizetős is, de az interneten szó szerint mindent megtalálsz, mindenhez _is_ találsz tananyagot ami a nulláról kb. egyetemi szintig elvisz, ingyen.
A világmegváltás pedig, hát az eléggé szubjektív. Vannak akik számára ebbe beletartozik az, hogy nem tiltanak neki olyan dolgokat, amivel senkinek se árt.

++ ahogy már írták is, Linus-nak meg se fordult a fejében a "világmegváltás", ő csak egy unix-like OS-t kezdett el farigcsálni hobbiból, mert meg akart ismerni egy procit.

Egy-két dologgal azért én magam sem értek egyet, mint például amikor a Windows 95 és a Windows 10-et olyan egyszerűen hasonlítja össze, hogy mind a kettő ugyanazt csinálja mégis 133-szor nagyobb a 10 mérete.

Ezt egy kicsit körülírhatnád!

Segítségül: Egy XP kb. 3GB. Amit használok, az pedig csak 1GB + >1GB utility.
A 10 éve, elég trehány módon belakott rendszeremnél a WINDOWS=3GB, a Program Files=11GB.
Bár itt azért anyai-apai is fel van még rakva. ;) (Fejlesztőrendszerek, toolok, driverek, stb.)

Érdekességképpen megnéztem, hogy a kb. fél éve telepített Windows 10-es PC-men mekkora könyvtárak vannak:

- Windows --> kb. 26 GB, ebből pl.:
--- WinSxS --> 9 GB (ez a Windows komponensek régi és aktuális verzióit tárolja - a régieket kipucolva kb. 4 GB maradna belőle)
--- System32 --> 8 GB (ez maga a rendszer, a legnagyobb része a 3.5 GB-os driver gyűjtemény)
--- SysWoW64 --> 1.6 GB (az előző kettő kombinációja :-p)
- Program Files (több könyvtár) --> 14 GB, ebből a legnagyobb:
--- NVIDIA Corporation --> 3 GB (videókártya driver és hozzá kapcsolódó dolgok)

Ez összesen valami 40 GB körüli rendszerméretet ad. Egy ekkora SSD-t kb. 8 ezer Ft-ért lehet kapni tetszőleges boltban. Ekkora HDD-t nem lehet kapni, csak tízszer ekkorát.

Akkor miért is érdekeljen a dolog?

Mert ezt az adatmennyiséget mozgatni is kell, nem csak tárolni. No, nem egyszerre. Azért az nVidia 3 GB elég erős. A nouveau Linux driver 600 kB nagyjából. Tartozik hozzá kb. 2 MB firmware is, de ez az összes hardware-re vonatkozik, egyszerre csak egy kell belőle. A Xorg részéről nem tudom, mennyi még, de hasonló nagyságrendre számítok.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vigyázz, ez nemcsak a driver, hanem a körülötte lévő cuccok is. Mindenféle nagyfelbontású képek, videók (!), nagyméretű logok és hasonlók is vannak közöttük. Jó kérdés, hogy ezekre van-e szükség, és az a gyanúm, hogy kicsit odafigyelve fel lehet rakni ezek nélkül is a drivert. Ezzel spórolnék 3 gigát (400 Ft), cserébe befektetnék 5 perc munkát. Ennél jobb az órabérem, ennyiért nem dolgozom, és másnak sem célszerű...

A múltkor szedegettem össze egy HP-s laptop drivereit. Nem értettem, hogy a toszba lehet a touchpad drivere 200MB! Hát, voltak benne helyes kis Windows Movie File-ok, amik olyan nevekkel rendelkeztek, hogy balegérkattinás, jobbegérkattintás, scrollozás, meg hasonlók. Nem néztem beléjük, de biztos van valami GUI, ahol ezeket a műveleteket videó formájában mutatja meg a driver (mellé csomagolt progi), hogy a clueless felhasználó tudja, hogyan is kell használni egy szaros touchpadet. Na ettől lesz egy fostos touchpad driver 200MB B+

A man page rövidebb, hatékonyabb, pontosabb. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hülyeséget beszélsz! Ahhoz kell tudni olvasni is. ;)

Mozgatni alatt mit értesz? Gigabites hálót kapok valami 4800 Ft/hó pénzért (Digi), az USB3-as vagy USB-C pendrive még gyorsabb, a diszken belül majdnem 1 GB/sec-cel tudok másolni. Ehhez képest nem méretek ezek.

Túl kell lépni azon az időszakon, amikor a PC egy drága és megbízhatatlan XT volt, béna MS-DOS oprendszerrel. Ha ma bemegyek egy Tesco-jellegű boltba és megveszem az első kezembe akadó PC-t 100 ezer Ft alatt, akkor is röhögve elbír ezekkel a mennyiségekkel. Ha értek hozzá és odafigyelek, hogy mit veszek, akkor meg még kevesebb gond adódhat...

Épp erről a hozzáállásról szól ez a topic. Az egy nagyon destruktív szemlélet, hogy a hardware elég gyors, a RAM meg a háttértár elég nagy, ne foglalkozzunk semmivel, ne számoljuk ki, pontosan mennyi RAM kell, foglaljunk le egy 10 MB-os blokkot, abba majd belefér ez a string, ami általában ugyan 5 karakter, de néha lehet nagyon sok is. Valahogy nem nagyon látom azt sem, hogy valaki ns-okban számolna kritikus helyen futásidőt. Legalább ott, ha máshol nem is.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miért gondolod, hogy ez a szemlélet destruktív?

Azért, mert a minőség rovására megy mind sebességben, mind tárhelyben. Ez ugyanaz az igénytelenség, amely máshol is tettenérhető, s a kapitalizmus következménye. Nagyjából a fogyasztási kényszer, pazarlás, környezetszennyezés. Mindent feláldozunk a gazdaságosság, a pénzügyi sikerek oltárán, s nem akarjuk észrevenni, hogy a gazdaságnak kellene szolgálni az embert, az emberi életminőséget, nem pedig az embernek a gazdaságot.

Jut eszembe, középiskolás koromban ZX Spectrumra Z80 assembly-ben 1313 byte-ban írtam meg egy Tetris játékot.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tényleg nem is olyan rossz!
Bár az AIX 4.2 környékén a rendszer 16-32MB memóriában futott. Ha még desktop is kellett, akkor akár 1-2MB-ot is hozzáadhattál userenként. ;) A diszk felhasználás kb. ezzel arányos volt: néhányszor 100MB.

Es milyen jol elfutott rajta a bongeszo es hogy kirenderelte a facebook-ot. Aham... :D

De mondok mast. Par ezer evvel ezelott, ha eltort volna az asobotom, hat letortem volna egy masik agat. Ma meg el kell mennem az OBI-ba. :(

Regen minden jobb volt!!! :D

a QNX egyfloppys rendszerei megvannak? :)

Megvannak. :D
En csak az ordog ugyvedjet jatszom ebben a topicban, ahol a bloat a tema. En meg megirom, hogy neha miert kell a bloat. Hogy egyszeruen hasznaljunk dolgokat, vagy mert ez a business igeny es kesz. Tetszik nem tetszik gyorsan es olcson kell szart lerakni az asztalra. :D

Az, hogy a facebook igénye 1GB felett kezdődik, az nem az AIX hiányossága szerintem.

--
openSUSE 42.2 x86_64

Felreertettel. Az AIX nagyon jo dolog, bar akkor en inkabb mar egy jo oreg SCO unixWare 2-es mellett tennem le a voksot. :D
Mint fentebb is irtam, csak az ordog ugyvedjet jatszom. ;)

Aham!

Pont erről szól ez a topic.

Régesrég készítettünk egy terminálos rendszert. Kikértük egy okos ember véleményét a soros vonal sebességéről. Bizony, 9600bd volt a javaslata. Ha belegondolsz, 20kbd a sebességgel 1s alatt tele lehet írni az egész képernyőt, de a terminálon nem így működnek. A releváns adatok cseréje a másodperc töredéke alatt megtörténik. Csak gondolkodni kell!

Az a tény, hogy a fb képtelen működni kevesebb erőforrással nem igazán a fejlődés jele.

Az FB-nek van azért némi hozzáadott értéke egy terminalon megjelenő szöveghez képest. Jelentősen több információt nyom az arcodba egy képernyőn (pl. képeket), ehhez pedig tényleg több/jobb/gyorsabb gépezet szükséges. Ami nem is baj, mert ez a gépezet létezik, és még olcsóbb is, mint annak idején a terminal volt...

Nem is a terminált hasonlítottam össze a fb megjelenítéséhez szükséges erőművel.

A Monte Cristo grófja három kötetben 1 floppy szinte bármilyen formátumban. Ugyanezt az információt filmként is meg tudom jeleníteni akár streamelve is. A fb meg egy weboldal.

A gépezet olcsó. Az átlagfelhasználó véleménye: Már megint lassú a fb!
Azt persze tudjuk, hogy inkább az átlagos gép a lassú. A technológia nem képes kiszolgálni a felhasználói igényeket a technológia miatt. Kérdés?

Az AIX a saját memóriája helyett a Te agyadat használja. Az összes egyáltalán nem intuitív korlátozását a fejedben kell tartanod, ahelyett, hogy egy intuitívabb réteget alakítanának ki rajta. Az általa kiadott adatok általában tömörek, és a dekódolásukhoz gondolkodni kell.

Ezekkel mindig az a baj, hogy az "átlagember" nem tudja/akarja használni az agyát. Lehet sírni, hogy milyen rossz az élet amiatt, hogy ez így van, de én pl. nem szeretek ilyesmi miatt sírni. A világ egy ilyen egészen kegyetlen hely, és az optimális megoldások általában azok, amelyek a világ valóságát figyelembe veszik.

Egész AIX-es pályafutásom alatt aszittem, hogy csak egy oprendszerrel van dolgom. Nem tudtam, hogy agyszívó! :-D

Egyúttal hájjal is kenegetsz: Ezek szerint átlagon felüli vagyok, hiszen egy ilyen vacak rendszert is eredményesen tudtam használni. :-)))))))))

Simán. Ezért is irtom az AIX-et mindenhonnan, ahol érem - tök nehéz és drága embert találni az üzemeltetésére.

Okos gondolat.

Csak a TCO-val baj ne legyen :)
____________________
echo crash > /dev/kmem

Rossz gondolat!
A divatot, irányzatokat nem lehet meghágni. Már Az összes egyáltalán nem intuitív korlátozását a fejedben kell tartanod... kijelentésre sem volt értelmes válaszom. Talán nem is értettem. Adva van egy olyan rendszer, ami több unix-féleség lehetőségeit tartalmazza. Ehhez társul egy olyan flexibilis kezelési lehetőség, amelyet más rendszerek meg sem közelítenek. A linux látszólagos flexibilitása mögött meg nincs tartalom és hardver. Aztán ott van az ipari szintű megbízhatóság, meg - ahogy manapság mondják ;) - skálázódás. Végül megemlítem, hogy az AIX az egyik legjobban dokumentált rendszer, amit idáig láttam. Ami alulról közelíti, az talán a RHEL. Mindenesetre csak a közel 20 éves AIX fejlesztői és üzemeltetői pályafutásom alatt részesültem abban a felhasználói élményben, hogy leülök és megoldom a feladatot. Mondom ezt annak ellenére, hogy előtte, alatta és utána is dolgoztam linuxon, sőt sco-n is.

A tök nehéz és drága embert találni az üzemeltetésére kijelentésben is van némi igazság. Nyilvánvalóan a linuxon és windowson szocializálódótt emberek között nem fogsz AIX üszemeltetőt találni. Ezek az emberek megszokták a kevésbé hatékony, bizonytalan kimenetelű munkavégzést. Természetes számukra, hogy megbízható dokumentáció hiányában fórumkat bújva jutnak hozzá a munkavégzéshez szükséges információhoz. Számukra még az sem újdonság, hogy egy frissítés után nem áll fel a gép - hiszen ez az élet része. És ez is a TCO része, pro és kontra módon is.

Nem tudom eszre vetted -e, de manapsag x86 szerverhez is lehet 7 ev supporthoz jutni.
Serverek eleg ritkan doglenek manapsag, csak a disk ..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mer megint ezek a business igenyek irjak felul azt, hogy "szep" meg hogy "kicsi" meg hogy "elegans kod" :D

A dragasag relativ, wannabe Linux rocksztarok se kerulnek kevesebbe, sot.
____________________
echo crash > /dev/kmem

Ugye programfejlesztéskor nem az efficiency, simplicity, and excellence a legfontosabb szempont, sokkal inkább a gazdaságosság, karbantarthatóság és a gyors fejlesztés. Szóval az előbbieket elvárni minden programozótól, amikor nem az a cél, naivitás. Ráadásul biztosan nem igaz, hogy nem kell géniusznak lenni, hogy gyors, egyszerű és szép kódot írj. Még a géniuszoknak sem megy gyakran csak kettő a háromból...

A probléma valós, de nem attól fog megoldódni, hogy rácsapunk az asztalra. Inkább arról kéne írni, hogy mitől változhatna ez meg, ha egyáltalán.

Ja meg hát szoftvert nem a szépségért szokás írni, hanem a business igényekre, ott meg szokták a költségeket is nézni, stb. stb. Ha valaki az én igényeimre ír valamit, nem érdekel a kód szépsége, max ha feltétel ez is. Addig elég ha karbantartó olcsón, meg hordozható, meg főleg olcsóbb, mint a szuperszép kód.
El lehet polemizálni ezen, de a prigramozókat az üzlet tartja el, nem a szépművészeti múzeum tárlatán mutogatják a kódjukat.
A bloatról még annyit, hogy ma már mindennel is kompatibilisnek kell/illik lenni, ezt meg nehéz 20 sorban megcsinálni.

A kompatibilitás nem is tartozik a bloat-ba, viszont ahogy a blogban is írva van az már az, hogy a sok idióta webes komplett framework-öt behúz azért, hogy egy-két funkciót használjon belőle, majd pedig jön a depedency hell.

> majd pedig jön a depedency hell.

De van ra tree-shaking!

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez meg legyen a megrendelo baja. Ha o kifizeti, hogy az igy behuzott komplett framework miatt az alkalmazas lassabb lesz, hat tegye. Lehet ezzel viszont lerovidul a fejlesztes ideje egy-ket nappal, ami erosen sok penzt (is) jelnethet.
En uzleti szempotnok szerint nezem az alkalmazasfejlesztest. Neked masok a szempontjaid.
Mint alkalmazasfejleszto lehet jo is az, ha jon a dephell, mert tudok supportot adni. Meg egy uzleti szempont. Lehet nem is olyan idiotak am azok a fejlesztok. :D

A mostani megrendelő management simán valószínű, hogy nem egyezik a két év múlvaival (és ezt persze tudja is). A prémiumuk sem, ergo pont nem fogja érdekelni, hogy a karbantarthatóság milyen lesz.

Na ez a masik :D

+1. Ha épp az optimalizálás az igény, akkor optimalizálva lesz a cucc. Addig meg ameddig benne van a requirementeken belül viszont hiányzik egy halom feature, addig a featureket pakoljuk bele.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

[Feliratkozás]

azért azt nem kéne elfelejteni, hogy azért ha valamiben sikerült előrébb lépnie a win7-10-nek, az a kompatibilitás. Pedig azóta sokkal több gyártó lett.
XP alatt azért ment a vadászat a driverekre, és elképzelhetetlen volt egy másik gépbe berakva működtetni egy Windowst mindenféle varázslatok nélkül.
Azért most túlnyomórészt megy.

Szerintem az MS legnagyobb púpja a visszafelé kompatibilitás, még ha már az elmúlt pár évben már azért fel-fel adna ezzel kapcsolatban elveket. Pl már nem kell IE6-al kompatibilisnek lenni, ami rég viszont rengeteg nagy cég MS (crm, navison) rendszereihez kellett.

XP alatt azért ment a vadászat a driverekre
Ez azért költői túlzás. Csak le kell tölteni a gyártótól.
Igaz, most már a rendszer magától kitalálja mit kell letölteni a MS-tól. Igaz, rosszabb esetben megbénul a wifi, a szoftverek fele, vagy aktiválodik az 1817-ben gyártott MS egér. Bár az is lehet, hogy csak rossz időben voltam rossz helyen. ;)

Másrészt bizonyos dll-ek úgy is a BIOS-ban vannak. (Remélem újat mondtam.)

"Csak le kell tölteni a gyártótól."

Ja, hálókártyák kb 80%-a ilyen volt. A _hálózati_ kártyák.
Driver meg kis floppy-n.

Azt meg letöltöd modemen.
Amikor floppy volt - modem is volt! ;)

Na igen, a winmodemek, és az ő drivereik :/

Olvastam régen, hogy a winmodemek valójában csak A/D átalakítók voltak. Magát a modulációt/demodulációt pedig szoftver végezte - többnyire csak volna, mert akinek ilyenje volt, az úgyse használta vagy vett mellé egy rendes modemet :-P.

Persze meg lehetett volna ezt csinálni rendesen, egyszer elég lett volna írni egy működő szoftveres modemet, és ahhoz tényleg A/D átalakítóként - AKA hangkártya illeszteni a vasat, de ez csak egy álomvilágban működik így. A valóságban minden gyártó a saját driverébe tette bele a szoftver modemet, amik úgy-ahogy működtek Windowson, Linuxon meg leginkább sehogy.

Én 2003 környékén használtam ilyeneket, tudom akkor már ciki volt, de addigra egy erős géppel pont használhatóak voltak a connexant-os példányok. Volt amúgy a HSF mellett HCF példány, ami elvileg "csak" a soros portot emulálta szoftveresen és DAC mellett volt benne valamennyi DSP funkció is. Én elégedett voltam HSF-fel is, két hét alatt szedtem le az XP SP2-őt, de csak azért olyan lassan, mert 6-kor keltem és 7-ig volt kedvezményes a net, az FDM meg apránként lehúzta, közben még kicsit böngésztem is.

Onnan ismertem fel a linuxos arcokat, hogy drága, külső modemje volt mindnek xd

Volt? Még megvan, eltéve...
;-)

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

:D

Jó cikk, sokmindenben igaza van. Szoftverfejlesztőként el kell gondolkodnom, hogy mennyire vagyok én is hibás.

Nem vagyok egyedul ;-)

A problema az hogy 16x novekedes tenyleg indokolt,
de valojaban 64x..256x szoros erroforras igeny van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Elolvastam.

Van benne 1-2 értelmes gondolat meg egy csomó tévedés/baromság/csúsztatás.
Így aztán nem annyira jönnek ki a valóban jogos kritikák.

Szerintem amúgy a szakma akkor kezdett el lecsúszni amikor megjelent a php és a fejlesztése során használt ideológia.
Na meg az outsourcing se tett jót - ebből már kezdünk visszajönni talán.

--
Gábriel Ákos

Mi az ami csúsztatás?

A php az a szerveroldali webprogramozas python-ja: lehetne benne jol dolgozni megfelelo programozoi rutinnal - de mindenki azt hiszi hogy ert hozza 10 perc utan es csak ugy fossa ki magabol a szart merthogy ez ilyenmegolyan egyszeru plusz trendy is.

"megjelent a php és a fejlesztése során használt ideológia"

Ez alatt mit értesz? (Csak kiváncsiságból kérdezem, nem kötekedés)

Mindenféle hosszútávú stratégia, tervezés, meggondolás nélkül fejlesztették éppen arra amerre a community kívánta.

--
Gábriel Ákos

Ok! Köszi :)

Vagy ahogy épp aznap felkeltek.

Mert olyanok írták, akik kibaszottul nem értettek hozzá. Én jobb nyelvet csináltam volna, b+...

Ezen rendszerszinten nem lehet változtatni. Mert tegyük fel MS ráállít tízszer annyi fejlesztőt a Word-re, cserébe kétszer gyorsabb lesz, tízszer annyiba kerül, és mellette nem jut ember Excel meg Outlook fejlesztésére. Így is programozóhiány van, és ez nem azon múlik, hogy ma hatékony kódot programozó lábbal keltem fel, hanem időn és azon, mennyi kész komponenst használunk fel. Ennyiféle informatikai termékre nem nagyon lehet jobbat, és azt a jobbat senki sem fizetné meg.

Hosszu a kifogas tar mi ;-)

A dolog az hogy a lassu szoftware rengeteg CI/QA timeot is elvesz,
azon kivul gyakran a tenyleges plusz ido raforditas csak +10..20% lenne.
Azon kivul, a feedback loop is hosszabb, lehet hogy egy 4 szer gyorsabb szoftware 4-edlei
a feedback loopot, 4-edeli a szukseges CI errofarasokat, es vegeredmenyben tobb featuret lehet
betolni ugyan azon ido allatt, mert kevesebbet varsz a `semmiert` .


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Inkább fordítva, 10-20% gyorsulás négyszer annyi ráfordítással. Mindezt úgy, hogy agilisek vagyunk, ami annyit jelent, hogy mindent megbecsülünk, de úgy hogy a nyakunkba liheg a PM, hogy csak kis számokat használjunk, mert szívbajt kap a megrendelő, utána meg a megrendelő a becslés alapján veri az asztalt. Jó, ha a legarcbamászóbb technical debtekre jut idő. Előző projecten tudtunk volna faragni havi cloud számlán pár ezer eurót, a költségek kb 10-20%-át. Jeleztük ügyfélnek, aki inkább fizette tovább a nagyobb havi számlát.

Tudom hogy vannak projektek ahol tenyleg sokszorosa lenne, de az nem sok.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igazából még a gépeken való spórolásnál is fontosabb, hogy az emberek munkáján is lehetne spórolni. Sőt! A fejlesztők munkáján, amiből kiindultunk, hogy az a drága.

Ha az alapok rendbe vannak rakva, akkor minden fejlesztő könnyebben dolgozik, sokkal produktívabb. Igazából ezekkel az újabb meg újabb layerekkel a fejlesztők erejét is pazaroljuk, nyilván nem lesznek attól gyorsabbak, hogy fogalmuk sincs mi történik a rendszerben, amin dolgoznak. Csak ez a projektek elején még nem nyilvánvaló, mivel prototípusokat még viszonylag gyorsan ki lehet köpni a rétegek egymásrarétegezésének módszerével.

Mind mondtam az emberek nem tevekeny varakozasa a problema.
Ill vannak olyan projektek ahol CI hardwert $M USD -ben merik.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Ill vannak olyan projektek ahol CI hardwert $M USD -ben merik."

Na, az is egy kellemesen elbaszott projekt lehet...

--
https://iotguru.live

Mondjuk nekem az első gépemen legalább fél percig indulgattak ilyenek, mint Word 97 meg Excel 97, most meg ha két másodpercet kell várni, akkor már azt mondom, hogy lassú.

De ugyanígy VC6, VS2008 vs VS2010+ Ég és föld az újak javára.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nekem is , de aztan 32MB RAMot lecserltem 128/256MB aztan jo lett, foleg a 2th inditas.
Win 9x (P1) idejen sok swappolas, ill lassu disk volt a problema, valamint a
dinamikus linkeles sem gyors aminek az aslr (vs prelink) sem tett jot.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Te most ugye viccelsz? :) Windows 95 korában 128 Mb ram az nagyon nem a sima home user felhasználás. 128 mega ramom nekem 2002-ben lett...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

mind mondottam 32MB -vel kezdott az a gep, az hogy mikor lett tobb arra nem emlekszem pontosan,
de 2~3 ev eltelt, 2001~2002 kornyeke es meg mindig SD ram.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hát nekem a P1-esem EDO-val kezdődött, igaz az alaplapon már volt SD foglalat. 2002 környékén meg már volt DDR.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nekem az kimarat , az az elotti gepbe (286AT) https://en.wikipedia.org/wiki/SIPP_memory lehetoseg volt,
de penz meg nem.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pont ugyanúgy ahogy a kézműves csokit, bútort, házat kevesen fizetik meg, a kézműves szoftvert is kevesen fizetik meg.
Létezik ilyen, de nincs nagy publicitása.

--
Gábriel Ákos

Így van, ahol megéri, vagy máshogy nem is lehet megoldani (űripar pl) ott kifizetik. A linkelt hőbörgés kb arra hasonlít, hogy ha lehet Ferrarit gyártani, akkor miért nem gyorsul 4 sec alatt százra a négymilliós Fabia is, elvégre autó-autó.

majd ha az számítástechnika is 6000 éves lesz, mint az építészet, vagy 2-300 éves lesz mint a gépipar, akkor lesznek olyan energia- anyagtakarékos struktúrák, mint azokban az iparágakban.

Vannak már ilyenek bőven, nem ezzel van a baj.
Igény/pénz nincsen rá ugyanúgy ahogy építészeti és gépészeti csodákra sincs általában.
Az se kedvez a dolognak hogy az építészeti/gépészeti dolgok materiálisak (láthatóak és megmaradnak) az IT dolgok egyáltalán nem.
Az is tipikus IT-ban, hogy xy vezérnek a nagy projekt végén a szervertermet mutatják meg - mert az látványos és érthető - nem pedig a sokkal többe kerülő és szuperül összerakott bármit (ERP, workflow, whatever).

--
Gábriel Ákos

Plusz az építőiparban, gépészetben ami egyszerű, felesleges elemektől mentes az általában olcsó is, hiszen ahány példányt akarsz egy termékből, az annyiszor megy végig az előállítási folyamaton (itt segít, ha egyszerű) és annyiszor kell hozzá megfelelő mennyiségű és minőségű nyersanyagot biztosítani (itt segít, ha nincsenek benne felesleges elemek).
A szoftverfejlesztésben pont fordított a helyzet: minél univerzálisabbra, nagyobb tudásúra csinálsz meg egy modult, annál több helyen fogod tudni felhasználni (az újabb példány "ingyen" van), ezzel csökkentve az újabb termék előállításának költségét.

Subscribe

Az utolsó mondatot kb teljesen feleslegessé tette a cikk elolvasását. :)

Mondjuk az köztudott, hogy a software célja és értelme a hardware erőforrások elpazarlása, ezt legjobban a híres Strupstrup-álinterjúból érthetjük meg. Vagy a leftpad esetből: tényleg külső komponens kell, hogy egy stringet elhelyezzünk egy mezőben?