Egyszerre mind a 4096 szín Amigán

Sárgadinnyés bivalyfőzeléket mindenkinek, ma ügyködünk egy kicsit Amigán: kirakjuk az OCS/ECS gépeken elérhető mind a 4096 színt egyszerre a képernyőre.

"Elősör" egy kis gyorstalpaló az Amiga (non-AGA) képernyőiről, illetve azok színkezeléséről. Az AGA megjelenése előtti Amigák 12-bites (csatornánként 4-bites) színmélységgel bírtak, azaz a teljes színskálájuk 4096 színre rúgott. A gépnek viszont csak paletta-bázisú képernyőmódjai voltak, a hardware maga 32 színregiszterrel bírt, a - planár felépítésű - videomemória maximálisan 6 bitplane-ből állhatott. A planár felépítés azt takarja, hogy a pixelek bitjei nem "pakolva" tárolódtak, pl. '76543210 76543210 76543210 76543210 76543210 76543210 76543210 76543210', hanem "síkokban", szétbontva: '00000000 11111111 22222222 33333333 44444444 55555555 66666666 77777777'. (A számok az egyes pixelek bitjeit jelölik.) Ezt a fajta felépítést ugyan jóval nehézkesebb "egyszerűen" kezelni, mint a chunky felépítést, viszont - többek között - az az előnye, hogy a bitsíkokat egymástól függetlenül is lehet kezelni, (pl. adatmozgatásnál, ha nincs minden síkra szükség, akkor nem kell mindet másolni, vagy a felesleget maszkolni), valamint, hogy a "nem szimmetrikus" (nem kettő hatványú) bitmélységeket így pazarlás és túlbonyolítás nélkül is lehet tárolni. Ennek megfelelően az Amiga nem csak a legtöbb gépen ismert 1, 2 és 4-bites - azaz 2, 4 és 16 színű - üzemmódokat támogatta, hanem a 3 és 5-bites - azaz 8 és 32 színű - felbontásokat is. Eddigre biztos feltűnt már pár kollégának, hogy ha 32 színregisztere van a gépnek, akkor miért állhat a videomemória 6 bitplane-ből? Nos, a hatodik bitplane három esetben van használva. Egyik eset az ún. "Dual-playfield", amikor két darab - egymástól függetlenül kezelt (mozgatott, módosított, stb.) - 3-bites képernyőt használunk egyszerre, amiből a "felül" lévő 7 színű lehet (a 0. szín "átlátszik"), az "alul" lévő pedig 8 színű. (A DPF lehet 2x1 vagy 2x2 bites is, de az értelemszerűen nem fog 6 bitsíkot elfoglalni.) A másik eset, az "Extra Half-Brite" mód (EHB), amikor az alap 32 szín mellett van egy az első 32 színből képzett imaginárius fél-fényerejű szekunder palettánk, azaz ha a hatodik bitplane-en egy bit 1-es, akkor a hozzátartozó pixel fényereje megfeleződik. A harmadik eset pedig a bennünket jelenleg érdeklő "Hold-And-Modify" mód, innentől HAM, pontosabban HAM6, mert a HAM üzemmód lehet 5, illetve AGA-n 7 és 8-bites is. (Bár az 5 és 7-bites verziókban csak a kék összetevőt lehet variálni, úgyhogy, kb. szinte semmi sem használja.) A HAM módok lényege, hogy egy pixel nem feltétlenül "standalone", hanem az esetek többségében az előző pixel módosulata. A HAM6 (és az 5 is) úgy működik, hogy van egy 16 színű palettánk, aminek színeivel bárhol lerakhatunk egy pixelt és utána az egyes csatornák összetevőit megváltoztathatjuk, de egyszerre csak egyet. (Illetve HAM5-ben csak a kéket.) Egy HAM6 pixel így néz ki:

54 3210
ii vvvv

Az ii az utasítás, a vvvv az érték, a számok itt is a pixel bitsorszámát jelölik. Az utasítás - értelemszerűen - négyféle lehet:

00 - pixel színe a palettából
01 - kék összetevő beállítása
10 - vörös -||-
11 - zöld -||-

Az érték az első (00) esetben a színregiszter indexe, a többiben pedig a kiválasztott csatorna új értéke. (És ebből az is kiderült, hogy a HAM5 miért csak a kék összetevőt tudja variálni.) Namármost, ebben a módban igazából mindennemű trükközéssel is ki lehet rakni mind a 4096 színt, csak beállítjuk valamelyik színregisztert feketére, kirakjuk legelsőként, majd egyesével elkezdjük inkrementálgatni a pl. vöröset, aztán, ha elérte a maximumot, akkor két lépésben - és két pixelben - visszavesszük nullára és mellette pl. a zöldet meg inkrementáljuk és - ha mindkettő elérte a maximumot, akkor - ugyanezt a kékkel is, csak azt már három lépésben. Ez azonban így ocsmány, összefolyó lesz, az egyes színek egypixelnyiek, azaz megkülönböztethetetlenek, ráadásul a "váltásoknál" látszani fog a "maszatolás" is. Ennek megfelelően, ha valami ilyesmit szeretnénk csinálni,

ami ki is néz valahogy, akkor bajban leszünk, a "váltások" miatt, hiszen - mint kitárgyaltuk - egyszerre csak egy színösszetevő változtatható meg, azaz, ha nem akarjuk, hogy amikor egyszerre kettőt kell megváltoztatni, akkor maszatoljon, akkor ott nem változtatni kell, hanem a palettát használni. Igen ám, de a paletta csak 16 elemű, "váltás" meg összesen 256 lesz (4096 / 16). Egyszóval már a 256. színnél ki fogunk futni a palettából. Itt jön képbe a Copper nevű co-processor, aminek funkciója, hogy a képernyő elektronsugarának pozíciójával időzítve tudja írkálni az Amiga hardverregisztereit. Mivel színsoronként kemény 4 db "váltás" van, ezért kibökjük mondjuk a 4-7-ig terjedő színregisztereket erre a célra és színsoronként - azaz 4 soronként (mivel egy ilyen négyzet 4x4-es) - újratöltjük őket a következő színsor által igényelt színekkel. Így gyakorlatilag a kék és zöld összetevők cserélgetését a Copper fogja intézni, nekünk a bittérképben csak a vörössel és a palettával kell foglalkoznunk. Ennek megfelelően egy sor bittérképe (egyelőre chunky felírással) így áll össze (itt egy sor egy két "váltás" közti "szekció", de az egész egy színsorhoz tartozik):

00.0100|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0101|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0110|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0111|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111

Illetve, mivel ez így még csak 64 pixel széles, ezért az egyes elemek négyszer fognak ismétlődni. És - mivel a többivel a Copper foglalkozik - ezt kell megismételni 256-szor. Viszont, mivel ez chunky, így ezt még át kell írni planárra. A hat bitplane egy-egy sora tehát hexában így fog kinézni:

plane 0: 0f0f 0f0f 0f0f 0f0f * ff0f 0f0f 0f0f 0f0f * 0f0f 0f0f 0f0f 0f0f * ff0f 0f0f 0f0f 0f0f
plane 1: 00ff 00ff 00ff 00ff * 00ff 00ff 00ff 00ff * f0ff 00ff 00ff 00ff * f0ff 00ff 00ff 00ff
plane 2: f000 ffff 0000 ffff * f000 ffff 0000 ffff * f000 ffff 0000 ffff * f000 ffff 0000 ffff
plane 3: 0000 0000 ffff ffff * 0000 0000 ffff ffff * 0000 0000 ffff ffff * 0000 0000 ffff ffff
plane 4: 0000 0000 0000 0000 * 0000 0000 0000 0000 * 0000 0000 0000 0000 * 0000 0000 0000 0000
plane 5: 0fff ffff ffff ffff * 0fff ffff ffff ffff * 0fff ffff ffff ffff * 0fff ffff ffff ffff

Akkor itt az ideje, hogy kódoljunk is egy kicsit. Nyitásként pl. húzzuk be a szükséges headereket.

#include <exec/types.h>
#include <exec/memory.h>
#include <clib/intuition_protos.h>
#include <clib/graphics_protos.h>
#include <graphics/gfxmacros.h>
#include <hardware/custom.h>

Aztán a main()-ben nyissunk egy HAM6 képernyőt:

struct NewScreen ns;
ns.LeftEdge = 32;
ns.TopEdge = 0;
ns.Width = 256;
ns.Height = 256;
ns.Depth = 6;
ns.DetailPen = DETAILPEN;
ns.BlockPen = BLOCKPEN;
ns.ViewModes = HAM;
ns.Type = SCREENQUIET;
ns.Font = NULL;
ns.DefaultTitle = (void *)"";
ns.Gadgets = NULL;
ns.CustomBitMap = NULL;
struct Screen *screen = OpenScreen(&ns);
SetRGB4(&screen->ViewPort, 0, 0, 0, 0);

Amint látszik, a szokásos 320 pixel széles képernyő helyett direkt egy 32 pixelnyivel eltolt 256 pixeles képernyőt nyitunk, így nem kell a középreigazítással foglalkozni, lehet folyamatosan írni a képernyőmemóriát, bár igazából ez mellékes. A program befejezésekor kell neki egy CloseScreen(screen); meghívás is (legvégén, hibakezelésnél, stb.). Eztán, foglaljunk némi előre törölt memóriát a Chip RAM-ban Copperlist-nek. (Hibakezelést majd mindenki maga.)

struct UCopList *copperlist = (struct UCopList *)AllocMem(sizeof(struct UCopList), MEMF_CHIP|MEMF_PUBLIC|MEMF_CLEAR);

(Gyors magyarázat, hogy mi az a Chip RAM: Amigán alapvetően kétféle RAM van, a custom chipek által is "látott" Chip RAM (maximum 2 MB), illetve a csak a CPU által hozzáférhető Fast RAM (maximum 2 GB, mínusz, ami a különféle címterekkel lejön belőle). Akit jobban érdekel, itt találhat egy memóriatérképet.) Ezután inicializáljuk a listát a CINIT() makró segítségével.

CINIT(copperlist, (64 * 5) + 1);

A második paraméter nem byte-okat, hanem Copper utasításokat takar. A Copper háromféle utasítást ismer:

  • Az elektronsugár pozíciójára várakozó WAIT-et
  • A regiszterekbe írkáló MOVE-ot
  • És az adott feltétel (elektronsugár pozíciója) esetén a következő MOVE utasítást átugró SKIP-et, ami egyébként bennünket most nem érint.

Nekünk 64 színsorunk van és minden színsorban 4 regiszter-írásra van szükségünk, viszont meg is kell várni a következő színsort (minden 4. sor), tehát egy színsorhoz 5 db Copper utasítás fog tartozni. Így jön ki a 64 * 5. A +1 az a lezáró utasítás a lista végén. Kell tehát egy 64 iterációból álló ciklus (pl. for (int i = 0; i < 64; ++i)), amiben a következő utasítások szerepelnek. Először is meg kell várni a megfelelő sort a CWAIT makróval:

CWAIT(copperlist, i << 2, 0);

(Az i négyszerese adja ki mindig a megvárandó sort, lévén egy színsor 4 pixel magas, a vízszintes koordináta pedig nulla, azaz az újratöltéseket a HBlank alatt fogja intézni.) Utána pedig fel kell tölteni a regisztereket a CMOVE makróval:

CMOVE(copperlist, custom.color[4], cc[i]);
CMOVE(copperlist, custom.color[5], cc[i] + 0x10);
CMOVE(copperlist, custom.color[6], cc[i] + 0x20);
CMOVE(copperlist, custom.color[7], cc[i] + 0x30);

A custom a hardware/custom.h headerben található struct Custom struktúrára hivatkozik (extern struct Custom custom;), amit a linker a végén a hardware regiszterekre (0x00dff000) irányít majd át. A cc tömb pedig az egyes színsorok elején szükséges zöld és kék összetevőket tartalmazza, a zöld csatorna menetközbeni inkrementálását pedig helyben adjuk hozzá. Mint a képen látszik, a "mátrix" 64x64-es, azaz egy sorban négyszer megy körbe a vörös és négyszer inkrementálódik a zöld, míg a kék négy soronként lép egyet előre, azaz a táblában a zöldet elemenként néggyel, a kéket meg négy elemenként kell inkrementálni.

const UWORD cc[0x40] =
{
	0x0000,	0x0040,	0x0080,	0x00c0,
	0x0001,	0x0041,	0x0081,	0x00c1,
	0x0002,	0x0042,	0x0082,	0x00c2,
	0x0003,	0x0043,	0x0083,	0x00c3,
	0x0004,	0x0044,	0x0084,	0x00c4,
	0x0005,	0x0045,	0x0085,	0x00c5,
	0x0006,	0x0046,	0x0086,	0x00c6,
	0x0007,	0x0047,	0x0087,	0x00c7,
	0x0008,	0x0048,	0x0088,	0x00c8,
	0x0009,	0x0049,	0x0089,	0x00c9,
	0x000a,	0x004a,	0x008a,	0x00ca,
	0x000b,	0x004b,	0x008b,	0x00cb,
	0x000c,	0x004c,	0x008c,	0x00cc,
	0x000d,	0x004d,	0x008d,	0x00cd,
	0x000e,	0x004e,	0x008e,	0x00ce,
	0x000f,	0x004f,	0x008f,	0x00cf
};

A ciklus után le kell zárni a listát a CEND() makróval. Utána a kapott listát csatolni kell a képernyőhöz úgy, hogy először letiltjuk a taszkváltást a Forbid()-dal, majd a listát belerakjuk az elején megnyitott képernyő ViewPort struktúrájának UCopIns tagjába, utána pedig Permit()-tel feloldjuk a taszkváltási tilalmat, végül újrarajzoltatjuk a képernyőt a RethinkDisplay() meghívásával.

CEND(copperlist);
Forbid();
screen->ViewPort.UCopIns = copperlist;
Permit();
RethinkDisplay();

Ezzel meg is van a Copper része, most már csak a képernyőmemória bitplane-jeit kell feltölteni adattal. Egy sor 256 pixel széles, azaz egy bitplane egy sora 256 bit hosszú, ahogy a fentebbi táblában látszik is. Ha jobban szemügyre vesszük a táblát, akkor kiderül, hogy a 4-es bitplane mindig nulla, a 2-es, 3-as és 5-ös pedig 4 szavanként ismétlődik. Ennek megfelelően a következő LUT-öket tudjuk létrehozni:

const UWORD p0vals[0x10] = {0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0xff0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0xff0f, 0x0f0f, 0x0f0f, 0x0f0f};
const UWORD p1vals[0x10] = {0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0xf0ff, 0x00ff, 0x00ff, 0x00ff, 0xf0ff, 0x00ff, 0x00ff, 0x00ff};
const UWORD p2vals[0x04] = {0xf000, 0xffff, 0x0000, 0xffff};
const UWORD p3vals[0x04] = {0x0000, 0x0000, 0xffff, 0xffff};
const UWORD p5vals[0x04] = {0x0fff, 0xffff, 0xffff, 0xffff};

(Igen, a 0-ás és 1-es bitplane 2-2 szót leszámítva mindig ugyanaz, de összesen 64 byte-ot spórolnánk meg a LUT-jükön, viszont a ciklust megspékelnénk 4 db komparálással (+ a bitaritmetika és a komparálások közti OR) és utána vagy egy-egy ternary-vel, vagy egy-egy a komparációk eredményével indexelt tömbolvasással (ami +8 byte-ot jelent, tehát úgy csak 56 byte-ot spórolnánk). Több kár, mint haszon.) A képernyő 256x256-os, amit 16 bitenként 4096 körből tudunk végigírni. Előbb azonban szükségünk lesz hat darab pointerre, hogy legyen mivel címezni a bitplane-eket, meg be kell állítani őket az egyes síkok kezdetére.


UWORD *p0 = (UWORD *)&(screen->RastPort.BitMap->Planes[0][0]);
UWORD *p1 = (UWORD *)&(screen->RastPort.BitMap->Planes[1][0]);
UWORD *p2 = (UWORD *)&(screen->RastPort.BitMap->Planes[2][0]);
UWORD *p3 = (UWORD *)&(screen->RastPort.BitMap->Planes[3][0]);
UWORD *p4 = (UWORD *)&(screen->RastPort.BitMap->Planes[4][0]);
UWORD *p5 = (UWORD *)&(screen->RastPort.BitMap->Planes[5][0]);
UBYTE tmp;
for (i = 0; i < 4096; ++i)
{
	tmp = i & 0x0f;
	*p0++ = p0vals[tmp];
	*p1++ = p1vals[tmp];
	tmp &= 0x03;
	*p2++ = p2vals[tmp];
	*p3++ = p3vals[tmp];
	*p4++ = 0x0000;
	*p5++ = p5vals[tmp];
}

Vagy, ha valaki spórolni akar a címregiszterekkel, akkor használhat egy darab pointert is, amit a nullás plane elejére állít be, viszont akkor azt minden kiírásnál 8192 byte-tal kell odébbléptetni, hogy a következő sík aktuális címét megkapjuk, majd az utolsó sík után 40958 byte-tal vissza ((5 * 8192) - 2). Kinek mi tetszik jobban. Ezután már csak várakoztatni kell a programot valami inputra, hogy ne lője le magát azonnal és lássuk is a végeredményt, pl. egér/joystickgombra (while ((*((UBYTE *)0xbfe001) & 0xc0) == 0xc0)), csak ne felejtsünk el időzítést is rakni bele, hogy ne terheljük rommá a rendszert. Erre a célra itt van pl. a Timer unitom, aki akarja viszi. A már futó program WinUAE-ből:

Az A500+-omon vaku nélkül:

Az A500+-omon vakuval:

A program elérhető itt, ha valakit érdekelne. Elméletileg működik minden Amigán, én 1.3-on, 3.1-en, valamint A500+-on és A1200-on teszteltem. Lábjegyzetnek még annyit, hogy bár a Copper egy soron belül is képes várni, a vízszintes minimum, amire várni tud, az 4 pixel, ha alacsony felbontásban vagyunk és 8 pixel, ha magasban, azonfelül maguk az utasítások is időbe kerülnek, 5 bitplane-ig 8 ciklusba (pixelbe), 5 bitplane-en 8 vagy 12 ciklusba, 6 bitplane-en pedig 16-ba. Ez azt jelenti, hogy a kevés színű bitmélységeknél túl sűrűn kéne ahhoz írni a regisztereket, hogy ne essen szét az egész, a sokszínűeken meg túl sok regisztert kéne egyszerre átírni. Arról nem is beszélve, hogy a 0. színregiszter piszkálása a keretszínt is állítani fogja. Ennek megfelelően ezt ilyen egyszerűen csak HAM képernyőn lehet kivitelezni. (Biztos megoldható máshogy is (pl. CPU-ból időzítve az egész regiszterírásosdit), csak az minden lesz, csak triviális nem.) Hát ennyi volt az Amiga/kóderrovat mára. Remélem, ha más nem is, legalább érdekes volt.

Hozzászólások

Jo kis leiras, erdekes!

Igen, anno a pc-s VGA-n, 640x480x16-os uzemmodban is ilyen bitplane-k voltak, de ott nem volt 5. meg 6. bit, csak 4. Emiatt relative egyszerubb volt a kezelese. Asszem ebben a konyvben minden le van irva jol a VGA-rol is ;)

Köszönjük! Nagyon szuper tartalom!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Akkor a következő kérdés: miért tartod az oldalad (amiben láthatóan van sok munkád) egy olyan szolgáltatónál, amely képes volt a saját címéhez igényelt tanúsítványt beállítani a te domainedhez is, ami kvázi rosszabb, mintha nem is lenne? Manapság már alap, hogy egy tárhelyszolgáltató biztosítson "1-klikkes" tanúsítványt is, mert pl. a Google bünteti a hiányát a rangsorolásban.

Egy szinvonalas szolgáltatás meg évi ezer forint körül kijönne erre a static tartalomfelrakós történetre.

Az a baj a szolgáltatóddal hogy nem http plain onlyban megy, hanem https-en is beszél, csak rossz certet mutat fel. Ne működjön a https egyáltalán, akkor az elbaszott böngészőkben is meg fog jelenni, amik bepróbálkoznak vele.

Persze mindenki maga dönti el, hogy hány éves a kapitány.

 

Amúgy a szálnyitónak: valahol https enforce van nálad, azért nem jelenik meg. Vagy mert tiltod a mixed https/http tartalmat.

Jelen pillanatban semmi pénzem sincs, úgyhogy ez felejtős. Egyébként sincs kedvem 16 év után szolgáltatót váltani, amikor 16 év alatt össz-vissz ennyi volt vele a gond és ez sem az én gondom.

Nem tudom, mit csinálok rosszul, de a múltkor is és most is világosan le volt írva, hogy HTTP-n keresztül vannak belinkelve a képek, azaz pont úgy, mintha egyáltalán nem lenne HTTPS és sokadjára sem érted meg. Nem tudom ennél szájbarágósabban elmagyarázni.

Amit meg a szálnyitónak írtál, azt már többen is leírtuk.

A probléma pont az, hogy egy HTTPS oldalba ágyazol be HTTP-n keresztül képeket. Ezt nem szeretik a böngészők. A FF csak panaszkodik, hogy itt valami nincs rendjén, de a Chromium nálam (és a szálnyitó pch-nál) egyszerűen nem tölti be ezeket a képeket. Abban gondolom egyetértünk, hogy ha az emberiség el tud juttatni egy autó méretű, atommeghajtású robotot a Marsra, akkor elvárható, hogy egy blogposztban jelenjenek meg a képek anélkül, hogy a biztonsági beállításokban kelljen matatni. :)

De van egyszerű megoldás, és egy fillérbe se kerül: van egy rakás képekre szakosodott CDN, pl. https://cloudinary.com A legtöbbnél van ingyenes fiók, ahol x GB-nyi havi forgalom lehet. Egy blogposztnak bőven elég.

Hogyne lenne elvárható, hogy ne kelljen benne matatni: egyszer kell engedélyezni a mixed contentet és akkor többször garantáltan nem kell matatni benne, egyszerűbb, mint eljutni a Marsra. Vagy olyan browsert használni, ami nem a felhasználó helyett dönti el, hogy mit nézhet meg és mit nem.

És mi ezeknek abban az üzlet, hogy ingyen tárolják a képeimet?

Nem lehetne beállítani egy letsencrypt tanúsítványt a te domain nevedhez és tartalmadhoz a haveri alapon megosztott gépen?

Elméletileg nem kell hozzá szinte semmi (egy kis konfiguráláson túl), és utána tudnál https linkeket írni akárhová.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Jó kis teszt-stuff! :) Én sajnos (? :) ) nem programoztam AMIGÁt, de jó látni, hogy milyen funkciókat hogyan is lehet használni. :) Lehet hogy átsiklottam csak felette; ezt mivel fordítod?

A HAM6-ot olvasva elkezdtem gondolkozni rajta, hogy ezt az EHB üzemmóddal is meg lehetne-e csinálni. (Azzal is lehet 64 szín egy sorban.) „Csak” a megfelelő palettaszíneket kellene hozzá kiválogatni... De aztán jól belekeveredtem. :) Az biztos, hogy nem lenne ilyen "szép" a színsorrend. Illetve palettát ott is kellene váltani, a copper-mágiát nem úsznád meg. Vagy ugye ugyanazt CPU-val, de minek, ha pont az ilyen feladatokra ott van a hardver a gépben? ;)

Illeve a WinUAE az hogy fut? WineUAE? :-D

Thx. Ezt a bebbo féle 6-os GCC-vel fordítom, de elméletileg SAS/C-vel is fordulnia kéne, csak most minden szét van itt szedve/borítva, nem próbáltam le az original gépen, a régi környezet még a RocTec-es HDD-ken van.

Nem, ezt EHB-vel nem lehet megcsinálni, legalábbis triviálisan biztos nem, két okból. Egyfelől ugyan az igaz, hogy az EHB 64 színű, tehát abból is lehet 64 egy sorban, de ebből csak 32-őt lehet szabadon állítani, ez pedig minduntalan összeakadásokba fog torkollni, még a csatornák színei is ütközni fognak; nem tudsz olyan palettát összeállítani még egy sorra sem - még akkor sem, ha a színsorrendet figyelmen kívül hagyjuk - ami jó lenne. (Arról konkrétan infóm sincs, hogy a felezés analóg módon történik-e, a "digitális hardware-en túl", azaz a valós feszültségértéket fogja felezni a rendszer a kimeneten és így pl. egy 9-es összetevőből "4.5" lesz, vagy pedig "belül" feleződik és mivel a hardware csak 16 szintet tud per csatorna, így ez 4-re redukálódik és ez is ütközni fog a 8-asból felezett 4-essel.)
A másik ok meg az, hogy Copper mágiát itt lehetetlen lenne alkalmazni, pont az miatt, amit a záróakkordban leírtam: a Coppernek is van késleltetése (konkrétan a 32 színregiszter végigírása 6 bitplane esetében 528 pixelig tartana ((1 + 32) * 16)) és a felbontása 4 pixel "durva", tehát csak nagyobb négyszögeket lehetne vele csinálni, ami meg már nem férne rá a képernyőre.
Pont CPU-val lehetne megcsinálni, mert annak ilyen bajai nincsenek, csak oda meg minek EHB, akkor a monokróm képernyő is jó, teleírva egyessel, majd CPU-ból időzítve az 1-es színregisztert módosítjuk végig. :)

Bezony, ez WineUAE. :)))

Ez az EHB tényleg olyan, amibe jól bele lehet keveredni... :)

Arról konkrétan infóm sincs, hogy a felezés analóg módon történik-e

A gépben a 3×4 bites D/A után már semmi se szól bele az analóg jelbe, emiatt ennek a felezésnek még a digitális oldalon kellene megtörténnie. Tippem szerint a 4 bites érték simán le van shiftelve egy helyiértéket. És akkor valahol itt keveredtem bele a „keresett” palettába; olyan színeket kell összeválogatni, ahol a MSb 1, a fennmaradóknak meg minden variációja előfordul (azaz %1000..%1111, 8 fajta érték), amikor az MSb 0, azokat a szinteket meg felezéssel elő lehet állítani. Ez szép és jó egy csatornára, na de itt 3 van! :-D

A palettacserével (legyen az copper vagy CPU) azért nem lenne gond, mert "soron belül" (az aktív tartalom alatt) nem kellene állítani, a keret / vsync alatt meg van rá idő. De az EHB üzemmódnak nem lenne semmi előnye, innentől kezdve az egész kérdés nem kérdés. ;)

Erről beszéltem, hogy nincs nyerő kombináció, mert a felezés miatt még egy csatornán belül is összeakad, nemhogy hármon. Ezek szerint akkor még az miatt is, hogy a felezés belül történik.

Hát pont ez az, hogy nagyon is kellene állítani soron belül, mert 64 színünk van egy sorban, de csak 32 regiszterünk, azaz félúton cserélni kell az egész palettát. Hogy a HBlank alatt van-e 396 ((1 + 32) * 12) pixelnyi idő a 32 regisztert újraírni, azt nem tudom, de még ha van is, a sor közepén, amikor a második 32 szín kezdődik, ott biztos nem lesz (igen, innentől az EHB-nek nincs értelme).
Ezt Copperrel nem lehet így megoldani, hacsak nincs valami nagyon durva trükk rá. CPU-val időzítve lehet, de akkor meg megeszi a gépet reggelire. :)

Max. azt tudom elképzelni, hogy nem 64x64-es lesz a mátrix, hanem LACED képet nyitunk és 32x128-as. Ebben az esetben egy sort elég egyszer újratölteni és ha tényleg van a HBlank alatt kb. 400 Copperciklusnyi idő, akkor nem kell HAM üzemmód. Viszont akkor úgy fog villogni, mint a búbánat. :P

Hirtelen néztem, hogy a képek ugyanott vannak, akkor mit igazítottál rajtuk, aztán láttam, hogy az előttük lévő tördelést változtattad meg.
Igen, a HTML-t kézzel megírtam offline, ott nézegettem browserben, aztán behúztam az egészet a formba és amit még kellett, azt az előnézetekkel kijavítgattam benne.

Sz*rk: Az egy sor chunky szerkezetét mutató kód elé valahogy bekerült egy üres paragrafus és lejjebb tolta a kódblokkot, üres teret hagyva felette, azt kiszedtem.

hogy en ezeket mar mennyire elfelejtettem. latszik nem foglalkozom vele :(

oszi szunetben kiprobaltam, mindharom Amigam mukodik, keresztlanyom occse meg is jegyezte hogy ennek csunya hangja van (a floppynak nem az audionak) :) most latott eleteben eloszor floppyrol betolteni jatekot.

neked aztan fura humorod van...

Nem, a külső floppy porton van 3 pin, SEL1-SEL3, a meghajtó kiválasztásához. A nullás drive meg mindig a belső (kivéve ha megcseréled a CIA lábait egy átkapcsolóval/adapterrel), hogy a SEL0-t routolja a külső portra és a SEL1-et a belső drivehoz.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Megfogalmazom máshogy: ha van kedved, átírhatnád FPC-be, mert jó lenne pár grafikus példaprogram a classic, azon belül is a legacy supporthoz. Már rajta van a listán mindenféle HW-banging effektet írok, scroller, bitplane trükkök, meg copperbars, de sajnos az időkibővítő gépen végzett munka elvitte az összes szabadidőm.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Szerkesztve: 2021. 02. 22., h - 12:13

BTW, fasza cucc, és jó a leírás.

A következő lépés az ún "2x széles HAM6" mód, amikor kvázi 640x256-ban tolsz HAM6-ot, de úgy vannak beállítva a bitplane modulók, hogy csak minden második pixel jelenik meg. Viszont a chipset a háttérben kiolvassa a maradék értékeket is, ergó pixelenként az RGB-ből 2 komponenst tudsz átállítani, nem 1-et. Erre már egész jó dither-t lehet írni, úgy hogy az előző pixelhez képest a két legnagyobbat változott értéket állítod át.

Mivel az AGA tud 1280 széles módokat is, ezért ott 4x széles HAM is van és 8 bitplane, amivel már 262144 színű truecolort is lehet csinálni, artifactok és SHAM nélkül.

Bónusz fun fact: a HAM módot eredetileg valami chipset színleképzés debugra építették be, és Jay Miner ki akarta szedetni a mielőtt a final verzió gyártásba megy. De a chip layouter csóka megpróbálta, aztán mondta Jay-nek, hogy egy rohadt nagy lyuk maradna a chipek közepén utána, hacsak az egészet nem akarják újra layoutolni. Ezért inkább benne maradt. Hála istennek. Talán Jay Miner mondta ezt egy interjúban, vagy valami. Meg azt is, hogy meggyőződése volt, hogy ezt soha senki semmire nem fogja használni, mert túl bonyolult. Néha a legnagyobb vízionáriusok is tévednek. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Thx.

640 széles LORES, ami 320-nak látszik? Ezt a trükköt nem ismertem, de nem lep meg, hogy az Amigából ezt is ki lehetett sajtolni. Ennek majd utánaolvasok, köszi az infót. Így már meg lehet úszni a Copperlist-et, bár maga a setup nem tudom mennyire triviális.

Az megvolt, hogy az AGA bármelyik febontásban tud már 8 bitplane-t; mondjuk, ha mind a 262144 színt ki akarod rakni, akkor még 1024x512-ben is elég pici hely fog jutni az egyes színeknek (2x1 vagy 1x2 pixel).

Előfordul. Azt nem tudtam, hogy az egész HAM módot csak benne hagyták, de a HAM5 esetén szilárd meggyőződésem volt, hogy csak azért létezik, mert csak bonyolította volna az áramkört, ha direkt letiltják, mint ha a generikus lekezelés mentén elérhető marad.

A kb. húsz éves videóplayerek mint a MooVid meg a RIVA (mindkettő magyar termék amúgy), azok tudnak ilyet "production" kódban, rendszerbarátan is, szóval annyira nem fájhat a setup, de én is csak elméletben ismerem. A 4x-széles HAM8-t emellett még több 060-at igénylő AGA-s demó is használja, pl. a Subside az Unique-tól.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Számomra a demoscene az iskolapéldája annak, amikor a fiatalok értelmes dologgal töltik el az idejüket tévézés (fészbukozás) és piálás helyett.
Biztatom őket az efféle vagy hasonló tevékenységek művelésére. Így lehet tanulni, fejlődni.
F*szlengetésből és videojátékozásból meg nem lesz semmi.

videojátékozásból meg nem lesz semmi

Nem feltétlen. Ha annyira felkelti valakinek az érdeklődését egy játék, hogy elkezd hozzá modokat is készíteni, az megint egy elég kreatív folyamat (mod szkriptnyelvének megtanulása, 3D modellek készítése, stb.) Nem egy olyat hallottam már, ahol egy mod alkotója végül bekerült az eredeti játékot készítő csapatba is.

Nem tudom. Pedig kár, mert

. megtanul az ember másokkal kommunikálni, kooperálni
. megtapasztalja egy szubkultúra folyamatos formálódását, annak interakcióival
. gyakorolja, hogyan lehet kifejezni valamit
. szívből és lelkesedésből programoz vagy komponál, ami az egyik legjobb tanulási mód
. rendkívül élvezetes időtöltés

Az általam ismert demoscener-ek többsége fiatal felnőttként rendkívül jó munkalehetőséghez jutott. Nagyrészük valamilyen játékfejlesztő vagy grafikai stúdióhoz került. Színvonalas nevelés volt számukra ez a szubkultúra, nem csak szakmai síkon, de személyiségfejlődésben is.

Csak 2021-ben már kicsit anakronisztikus ez az egész. A hozzám hasonló faszok ömlengenek már csak ezen; a fiatalok többsége azt se tudja, mi az az Amiga vagy egyáltalán a kilobájt.
Régen nem volt internet, mégis úgy érzem, sokkal jobban áramlott a tudás. Személyesen, diskmagokban, újságokban. Vagy talán csak nem árasztott el minket a silány szenny. Ma elvileg minden adott, mégsem látom azt a fajta közösségformálódást. Sokkal individuálisabb lett a világ. Individuumok kapcsolati hálózata.

Kevesen, de vannak. A mostani "öregek", lehozzák a gyerekeiket party-kra, akikből jó eséllyel később aktív scener lesz. De most is van pár tízen és huszonéves a magyar scene-ben is. Azért elférne több.

Kiváló! Köszönet érte.
Több ilyen kellene.

Ezt a világot szerettem.

Érdekes volt.

Meglepett, hogy ilyen feladatott C-ben írt meg valaki.

Annó, amikor ilyesmivel foglalkoztam, alap volt, hogy assembly-ben írtuk a programot és az OS letiltása volt az első lépés, hogy ne maszatolja szét az időzítést semmi (vagy leginkább, hogy a nagyon rövid időszeletbe, amibe be kellett férni, beleférjek, és ne az OS épp valami mást csináltasson közben a processzorral)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Valóban; pusztán a feladatra szorítkozva írhatta volna assembly-ben is. Sejtek azonban két további okot, ami miatt végül C-ben lett:
- bemutatta, hogy történik ez a clib prototípusait használva (azaz hogyan csinálnád egy ,,igazi" programban, ami nem kizárólag színeket rajzol);
- didaktikailag jobban követhető és át tudja adni a szemléletet, sőt, szerintem egy kicsit az Amiga programozás hangulatát is.

Úgyhogy kudos, nagyon jól van ez így.
Vigasztaljon, hogy igazából a C is assembly, pár makróval ;-)

Thx.

> alap volt, hogy assembly-ben írtuk a programot

Ez maximum a 8 és 16 bites konzolokon volt alap, a homecomputereken viszont úgy nézett ki, hogy a sebességkritikus részeket volt célszerű assemblyben megírni, a többit meg abban, ami jól esett (C, BASIC, Pascal, FORTRAN, Amigán esetleg E és a többiek).
Ha valami szerintem alap, akkor az az, hogy az eszközt a feladathoz választjuk és nem a feladatot igazítjuk az eszközhöz. A 8 és 16-bites konzolokon gyakorlatilag a dolgok 95+%-a sebességkritikus volt, a maradék meg olyan kevés, hogy akár assemblyben is meg lehetett írni, tehát ott nem volt értelme bármi mást használni (meg ugye ott a futtató környezet is megnehezítette a dolgokat), de itt pl. mi előnyünk származott volna abból, hogy assemblyben írjuk meg az egészet? Semmi, lévén az OS függvényeit mindegy, hogy miből hívod, a videomemória egyszeri végigírása meg így tömbösen assemblyből kb. pár mikroszekundummal lett volna gyorsabb.

Fogok majd mutatni olyan cuccot, amiben lesznek assembly betétek, de az assemblyt tisztán erőltetni sosem volt túl sok értelme egy homecomputeren, maximum, ha az volt a cél, hogy beleférjen pár byte-ba. Bár egyébként még a 8-bites homecomputereken is ott volt a tokenizált BASIC, ami nem ritkán kisebb kódot eredményezett, mint az assembly (nyilván lassú volt és kellett hozzá a BASIC interpreter is, de most nem sebességkritikus dolgokról beszéltünk, a BASIC interpreter meg az alapfelszereltséghez tartozott).

> és az OS letiltása volt az első lépés, hogy ne maszatolja szét az időzítést semmi

Igazán nem kötekedésből írom, de pont ez a mentalitás volt az oka annak, hogy Amigán nagyon sok nyögvenyelősen használható szoftver keletkezett, mert nem rendszerbarát módon írták meg őket, hanem a rendszer megkerülésével, a hardware közvetlen - és nem jól implementált! - piszkálásával, holott a rendszer több, mint partner volt abban, hogy ugyanúgy meg tudd írni, hogy ne essen szét sem időzítés, sem semmi.
De sok 8-bitről és árkádról átszabadult programozó azzal nyitott, hogy letiltotta a rendszert, megkerülte a hardware funkciókat rendesen felprogramozó OS rutinokat és behányta a biteket úgy, hogy az ő gépén ment, aztán meg csodálkozott, hogy amit írt az stock A500/KS1.2-only; gyorsabb CPU-val nem megy, 32-bites címbuszú CPU-val nem megy, újabb KickStarttal nem megy, FastRAM-mal nem megy, HDD-vel nem megy, ECS-el nem megy, urambocsá' AGA-val nem megy...és még sorolhatnám.

A rendszert letiltani egyébként C-ből is le lehet...csak itt éppen minek?

> alap volt, hogy assembly-ben írtuk a programot

Ez maximum a 8 és 16 bites konzolokon volt alap, a homecomputereken viszont

Konzolokat nem programoztam, csak C=64-et és Amigákat.

Úgy értem, ilyen módon, amit írtam.

de itt pl. mi előnyünk származott volna abból, hogy assemblyben írjuk meg az egészet? Semmi, lévén az OS függvényeit mindegy, hogy miből hívod, a videomemória egyszeri végigírása meg így tömbösen assemblyből kb. pár mikroszekundummal lett volna gyorsabb.

Nem azt mondom, hogy neked bármi miatt assembly-ben kellett volna ezt írnod, illetve bármi előnyöd származott volna belőle. Csak azt mondom, hogy 20 évvel ezelőtt, amikor mi hasonló dolgokat csináltunk (demók, játékok), akkor assembly-t használtunk és rácsodálkoztam, hogy valaki máshogy közelíti meg, mint mi akkor. Hogy mi miért assembly-ben az OS és interruptok letiltása után programoztunk annak két (lehet, hogy három) oka volt:

  1. az interruptok és a multitaszk rendszer bármikor elveheti a vezérlést. Ha a processzor annyira gyors, hogy egy erősen optimalizált ciklust megszakítás nélkül végrehajtva pont jól sikerül kirajzolnia egy képet, akkor logikus volt ezt a lehetőséget letiltani. Pl. egy pixel széles oszlopokból kirajzolt szinusz scroller nem hagyott sok időt másra.
  2. Nem az OS függvényeit hívtuk, hanem kézzel hajtottuk végre kb. ugyanazt (illetve gondolom néhány esetben egyszerűbbet, kevesebbet, csak annyit, amennyit éppen kellett. Elhagyva ilyen-olyan paraméterek vizsgálatát, elhagyva mondjuk nem kritikus hibák kezelését, stb.) Én nem teszteltem, de elfgoadtam amikor a nálam okosabbak és tapasztaltabbak azt mondták, hogy az OS függvényeket nem lehet használni mert túl lassúak.
  3. Simán lehet, hogy megszokás volt a legfontosabb. C=64-en assembly-ben toltuk, Amigán meg csak ugyanazt a megközelítést folytattuk.

És abban igazad van, hogy ha az OS függvényeit hívjuk, akkor nincs semmi értelme assembly-ből hívni. Én pont akkor kezdtem el sok év assembly programozás után C-t megtanulni és használni, amikor olyan programokat kezdtem írni Amigán, amik OS függvények hívásával dolgoztak. Viszont ezek nem próbáltak időkritikus módon video memóriát manipulálni, stb. Kitettek ilyen-olyan requestereket meg ablakot rajzoltak meg fájlokat nyitottak meg, írtak, másoltak, stb.)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Én meg pont erről beszéltem, hogy pont a homecomputereken nem volt túl sok értelme erőltetni a tiszta assembly-t, főleg 16 biten nem. Ami sebességkritikus azt célszerű assemblyben megírni, a többinek meg teljesen mindegy.

Arról, hogy ahogy te megközelítetted, annak a konzolokon volt értelme egyedül (meg árkádon). Mondjuk C64-en még csak-csak meg lehet indokolni, hogy a gyári BASIC-ja gagyi és a hardware meg a rendszer is viszonylag egyszerű, tehát lehet több pepecselés lesz, ha beviszel valami magas(abb) szintű nyelvet is a képletbe, mint ha azt a pár tucat rutint/makrót egyszer megírod, aztán csak használod minden cuccodban, de a két nagyságrenddel bonyolultabb hardware-es és software-es környezettel bíró Amiga gépcsalád esetén nem sok indokot lehet felsorakoztatni a mindent is assemblyben megközelítés mellett.

Sz*rk: Alámszerkesztettél.

> Csak azt mondom, hogy 20 évvel ezelőtt, amikor mi hasonló dolgokat csináltunk (demók, játékok), akkor assembly-t használtunk és rácsodálkoztam, hogy valaki máshogy közelíti meg, mint mi akkor.

Pont ezt magyarázom, hogy az a megközelítés nem feltétlen volt jó.

> az interruptok és a multitaszk rendszer bármikor elveheti a vezérlést. Ha a processzor annyira gyors, hogy egy erősen optimalizált ciklust megszakítás nélkül végrehajtva pont jól sikerül kirajzolnia egy képet, akkor logikus volt ezt a lehetőséget letiltani. Pl. egy pixel széles oszlopokból kirajzolt szinusz scroller nem hagyott sok időt másra.

Nem azt mondtam, hogy nem volt értelme átkapcsolni kizárólagos módba, hanem azt, hogy nem alap, hogy ezzel nyitunk, hogy letiltjuk az OS-t. Nyilván, egy demo-nál kellett az egész gép, de mi van a felhasználói cuccokkal, vagy a játékokkal?

> Nem az OS függvényeit hívtuk, hanem kézzel hajtottuk végre kb. ugyanazt (illetve gondolom néhány esetben egyszerűbbet, kevesebbet, csak annyit, amennyit éppen kellett. Elhagyva ilyen-olyan paraméterek vizsgálatát, elhagyva mondjuk nem kritikus hibák kezelését, stb.)

Hát pont ez az, hogy "kb. ugyanazt (illetve gondolom néhány esetben egyszerűbbet, kevesebbet, csak annyit, amennyit éppen kellett. Elhagyva ilyen-olyan paraméterek vizsgálatát, elhagyva mondjuk nem kritikus hibák kezelését, stb.)". Egyszóval nem úgy lett a hardware felparaméterezve, ahogy kellett volna. És így keletkezik a non-portable Amiga software, meg az upgrade-blocking Amiga software. Arról nem is beszélve, hogy ha tényleg ugyanazt implementáljátok le, mint az OS függvény, akkor elhanyagolható lesz a különbség, amit nyertetek vele; pont azért volt gyorsabb, amit a rendszerkerülgető kóderek írtak, mert a felét nem csinálta meg annak, amit kellett volna.

> Én nem teszteltem, de elfgoadtam amikor a nálam okosabbak és tapasztaltabbak azt mondták, hogy az OS függvényeket nem lehet használni mert túl lassúak.

Mely rutinok? Milyen körülmények között? Mihez képest? És mi az, hogy "nem lehet"? Miért lenne blocker egy könyvtárlista, egy fájlnyitás, vagy egy képernyő nyitása? Vagy a GUI programozása? Nem csak demoeffektek vannak, amiknek kell a hardware 101%-a. (Illetve ez sem igaz, mert általában zene is szólt alatta, tehát volt még szabad erőforrás az effekten túl.) Egyébként egyel feljebbi bekezdés: ha rendesen ugyanazt leimplementáljátok, mint az OS, akkor nem sokkal vagytok előrébb.

> Simán lehet, hogy megszokás volt a legfontosabb. C=64-en assembly-ben toltuk, Amigán meg csak ugyanazt a megközelítést folytattuk.

Erről beszéltem.

> Én pont akkor kezdtem el sok év assembly programozás után C-t megtanulni és használni, amikor olyan programokat kezdtem írni Amigán, amik OS függvények hívásával dolgoztak.

A nyelv mellékes, assemblyből is lehet hívogatni az OS-t. Csak pepecselősebb.

> Viszont ezek nem próbáltak időkritikus módon video memóriát manipulálni, stb. Kitettek ilyen-olyan requestereket meg ablakot rajzoltak meg fájlokat nyitottak meg, írtak, másoltak, stb.)

Tehát nem is volt értelme assemblyben megírni. Vagy letiltani hozzá az OS-t.

Pont ezt magyarázom, hogy az a megközelítés nem feltétlen volt jó.

Nem akartam minősíteni se az egyiket, se a másikat.

Abban az időben mindenki ezt csinálta, akivel csak beszéltem, vagy akiről csak hallottam. Ez elég sok ember volt, Magyarországon is és külföldön is.

Ezt nem azért írom, hogy ezzel azt bizonyítsam, hogy az a megközelítés jobb, csak azt mondom, hogy az alatt a nem is tudom 6-7 év alatt, amíg ezzel foglalkoztam, nem láttam senkit, nem hallottam senkiről, aki nem így csinálta volna.

Ezért volt meglepő, hogy te egy másik megközelítést használtál.

Nyilván, egy demo-nál kellett az egész gép, de mi van a felhasználói cuccokkal, vagy a játékokkal?

Mi (a haverjaim és én) nem felhasználói programokat írtunk. Természetesen azok teljesen másként működtek.

A játékok abban az időben nem sokban különböztek a demóktól, ugyanazokon a korlátokon ugyanazokkal a módszerekkel kellett áttörni.

A500-on a legtöbb játék bootolható lemezről a gép teljes átvételével működött. A Kickstart nem a Workbench-et töltötte be, hanem a játékot.

Egyszóval nem úgy lett a hardware felparaméterezve, ahogy kellett volna. És így keletkezik a non-portable Amiga software, meg az upgrade-blocking Amiga software. Arról nem is beszélve, hogy ha tényleg ugyanazt implementáljátok le, mint az OS függvény, akkor elhanyagolható lesz a különbség, amit nyertetek vele; pont azért volt gyorsabb, amit a rendszerkerülgető kóderek írtak, mert a felét nem csinálta meg annak, amit kellett volna.

Ebben teljesen igazad van, de más volt a célunk. Nem volt akkor szempont az, hogy majd évek múlva megjelenő másik gépeken is menjen esetleg az a demó vagy az a játék, hanem az volt a cél, hogy ne csíkozzon bele a lemezművelet a háttérbe, ne csússzon el az akárminek a kiírása, és minél több minden férjen bele az időbe. Ugye az időt a CRT elektronsugarának a haladása diktálta, ezért kellett real-time-nak lennie a programnak. És természetesen egy program nem lehet real-time, ha egy nem real-time OS-re kell várnia.

És igazad van abban is, hogy ez később gondot okozott. Amikor az Amiga 1200-as megjelent, kb. onnantól álltunk át rendszerhívásokra, onnantól ment a C programozás, és a teljesen más megközelítés. Ettől függetlenül, az A500-as kiadása és az A1200 kiadása között eltelt évek alatt ez egy eléggé elterjedt megközelítés volt.

Miért lenne blocker egy könyvtárlista, egy fájlnyitás, vagy egy képernyő nyitása?

Félreérted :-) Nem könyvtárakat és fájlokat olvastunk a floppyról, hanem a floppy drive hardver-t közvetlenül kezelve blokkokat.

Mondom, OS nem kapott szerepet.

Tehát nem is volt értelme assemblyben megírni. Vagy letiltani hozzá az OS-t.

Így van. Ezeket én is C-ben írtam meg. Csak a demókat és játékokat írtuk assembly-ben, OS nélkül.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

> Nem akartam minősíteni se az egyiket, se a másikat.

> Abban az időben mindenki ezt csinálta, akivel csak beszéltem, vagy akiről csak hallottam. Ez elég sok ember volt, Magyarországon is és külföldön is.

> Ezt nem azért írom, hogy ezzel azt bizonyítsam, hogy az a megközelítés jobb, csak azt mondom, hogy az alatt a nem is tudom 6-7 év alatt, amíg ezzel foglalkoztam, nem láttam senkit, nem hallottam senkiről, aki nem így csinálta volna.

> Ezért volt meglepő, hogy te egy másik megközelítést használtál.

Nekem a scene, meg az egész közösségi rész kimaradt. Ugyan 87-88 magasságában lett a családban C64 (majd C128) és 89 karácsonyán A500 (egész pontosan ez volt a mi gépünk; a képen látható összes cucc megvan még (ill. a nyomtatót nem tudom), de a gép sajnos el lett adva annak idején, valahova Százhalombattára...), de nekem annyi infóm volt, amit Apa újságjaiból összeszedtem. Pl. a GURU hasábjain is volt programozási rovat és ők speciel próbálták erőltetni a rendszerbarát megközelítést (Brazil még kiselőadást is tartott a levrovban, hogy miért is); ugyan többnyire assembly volt, de rendszerbarát módon.
Az amigás közösséggel csak 2005 legvégén, vagy 2006 legejején találkoztam. (Felejthetetlen volt, felmentem az #amigahu csatornára és /join után azonnal jött az instakickban; még megszólalni se nagyon volt időm. Utána valaki (talán Leeroy, vagy Artlace) rámqueryzett és "levizsgáztatott", hogy amigás-e vagyok...)

> A játékok abban az időben nem sokban különböztek a demóktól, ugyanazokon a korlátokon ugyanazokkal a módszerekkel kellett áttörni.

Hát azért nem egészen. Egy játék erőforrásigénye jóval kisebb volt, mint egy demo-é. Oké, nem feltétlenül, mert egy Doom-klónra ez pont nem igaz, de azt meg pont nem futtattad stock A500-on.

> A500-on a legtöbb játék bootolható lemezről a gép teljes átvételével működött. A Kickstart nem a Workbench-et töltötte be, hanem a játékot.

Igen, volt szerencsém ilyen játékokhoz, amiket nem lehetett HDD-ről bootolni, volt amit át is írtam HDD-sre (fun fact: ennek a programnak a ringyózos átirata volt a technikusi vizsgamunkám. :P); speciel egy ilyen Mastermind klónnál mégis mi indokolta, hogy az egész rendszert lekapcsolják és blokkonként olvassák szerencsétlen floppy-t?
A WHDLoad projektet ismered? Azzal foglalkoznak, hogy HDD-ről bootolhatóvá tesznek játékokat. A játékok elsöprő többségének egyáltalán nem volt szüksége arra, hogy úgy írják meg, ahogy megírták.

> az volt a cél, hogy ne csíkozzon bele a lemezművelet a háttérbe

Ha nem a vasat bombáztátok volna közvetlenül, akkor nem csíkozott volna bele...

> ne csússzon el az akárminek a kiírása, és minél több minden férjen bele az időbe. Ugye az időt a CRT elektronsugarának a haladása diktálta, ezért kellett real-time-nak lennie a programnak. És természetesen egy program nem lehet real-time, ha egy nem real-time OS-re kell várnia.

Az időt leginkább a CPU és a chipset korlátai diktálták, de a játékok jórésze nem igényelte azt a megközelítést, amit a demo-k.

> Félreérted :-) Nem könyvtárakat és fájlokat olvastunk a floppyról, hanem a floppy drive hardver-t közvetlenül kezelve blokkokat.

Te értetted félre a kérdést: ugye az volt az állítás, hogy az OS rutinjai túl lassúak, de pl. pont a lemezműveleteknél a bottleneck az nem az OS rutinjának a sebessége volt, hanem a floppy-é, vagy akár a HDD-é. Erre próbáltam célozni. Meg arra, hogy egy képernyő kinyitása sem lesz lassú, ha az OS rutinjait használod, de legalább be is lehet zárni, ellentétben a bitbanggel létrehozott és a képernyőre tolt nyers képernyőmemóriával. Vagy a GUI programozása; hát ott kb. a felhasználóra várunk; mitől lenne az lassú? Arra próbáltam reflektálni, hogy ezt így sommásan kijelenteni, hogy az OS rutinjai lassúak, nem lehet.

de nekem annyi infóm volt, amit Apa újságjaiból összeszedtem. Pl. a GURU hasábjain is volt programozási rovat

Igen, akkoriban ilyen cikkek voltak egy folyóiratban. A chip magazinban is jelentek meg rendszeresen assembly rutinok és tippek demo programozáshoz. Nagyon szerettem.
Ezt váltotta le sajnos a ,,Tíz Windows tipp", ,,A nagy víruskereső-teszt" korszak.

Az Amiga nekem kimaradt. Mivel az én szüleim mással foglalkoztak, nálunk én voltam a családban a számítógépes úttörő gyerekfejjel. A C16 után lett egy használt 286-om, Hercules monóval, 40 MB HDD-vel. Innentől kezdve én PC-s voltam.
Felénk vidéken sajnos nem nagyon volt olyan közösség, ami felkarolhatott volna. Egyedül, elszigetelten tanultam meg programozni, BASIC-ben, Assembly-ben, Pascal-ban majd C-ben. Célirányosan algoritmusokkal csak az egyetemen kezdtem foglalkozni.

Ahogy bilgéc beöntötte a jónépet a számítógépek világába, úgy adták le a nívót a számítástechnikai magazinok is. Meg egyébként minden más is.

Pedig a C16 és tsai. (C116, +4) idehaza elég nagy közösségi karriert futottak be; miért nem próbáltál a CoV hirdetésein keresztül levelezőpartnereket keresni?
Látod, én meg semmilyen algoritmust nem tanultam az egyetemen, mert kihullottam a matek miatt. :P (Ebben a külön röhej, hogy assemblyben az egész évfolyamon én tudtam egyedül rendesen programozni, de idehaza a matek a szent grál...)

Igen, sajnos nem minőségi váltás történt :-(
Illetve de, csak visszafelé.

Látod erre nem is gondoltam, hogy levelezőpartnert keressek. A diskmag világba is csak viszonylag a végén csöppentem bele (Terror News, Kendermag), illetve amikor jött az e-mail meg a levlisták, volt egy győri srác, akivel 97-98 körül leveleztem, de inkább elektronikai témákban. Addigra meg már kifutott ez az egész, és az első Linuxom feltelepítésén gondolkoztam a LiveCD-s szárnypróbálgatások után.

Egyetemen én meg matekból voltam jó. Nagyon szerettem. Ötösre szigorlatoztam (ez csak kivételesen keveseknek sikerült az évfolyamon).
Programozást tekintve első sorban mindig C-s voltam (habár a C is gyakorlatilag egy assembly, makrókkal).
Assembly-ztem is 8 és 16 biten (foglalkoztam processzor-architektúrákkal is). Hoztam egy szintet, de sosem tartottam magam igazán virtuóznak. Egy demoscenerrel például fénykoromban sem vettem volna fel a versenyt. A kanyarban sem lettem volna.
Holott a különböző processzorokat kimondottan jól ismertem (főleg RISC, illetve 80386).

Egy darabig csináltam a firmware programozást, illetve a nem-IP protokollok kezelését. Azóta pedig egészen mással foglalkozom. Gyakran elmerengek, hiányzik a kódolás. Programozóként éreztem igazán teljesnek magam. De amerre tart ez az egész, lehet nem is baj, hogy váltottam.

> Kollektíve mindenki?

Nnna... Kezdődik... Hol írtam ilyet?

> Mi a jelenlegi rossz irány és szerinted mi lenne a jó?

A provokatív szalmabábcséplő kérdés alapján ebbe felesleges belemenni, mert te már a kérdés feltevése előtt eldöntötted, hogy mit akarsz hinni. Hát...higgyed.

Hol írtam ilyet?

A hozzászólásodban, amire válaszoltam? :D "A mai programozóvilág baromi rossz irányba tart". Nem azt írtad, hogy egy csoportja (mondjuk a két havonta új JavaScript framework-öt írók), hanem az egész világ. Ha ilyen sarkalatos megjegyzést teszel, mint a viccben a "mindenki hülye, csak én vagyok helikopter", akkor nem ártana kicsit kifejteni, hogy mire gondolsz. Félig-meddig programozó is vagyok (fizikai szimulációk kódolásával lett doktorim), így beletartozom a "programozóvilágba", légy szíves fejtsd már ki, hogy mit csinálok rosszul. És ezt most csak félig írom ironikusan, mert egyébként tényleg érdekel, hogy mit gondolsz. Ha csak panaszkodsz, de minimálisan se fejted ki a panaszod tárgyát, azzal nem lesz előrébb senki.

A mi szempontunkból, saját megítélésünk szerint tart rossz irányba. Szerintem egyébként nem csak a programozás.

Mióta gazdasági szakemberek irányítanak, a marketing meg leuralt mindent, azóta kb. minden rossz irányba tart, értékbeli silányodás figyelhető meg.
Lehet persze olyan nézőpontokat kialakítani, amelyekből nézve ez valakinek lokálisan éppen jó. De generálisan tekintve szerintem semmiképp.

Azt sem állítom, hogy nincsenek komoly programozást vagy módszertant érintő vívmányok.
Azért ne menjünk bele szerintem, mert a nézőpontjaink és az értékrendünk különböznek nagyon sarkalatosan. És ez a thread alapjában véve nem is erről szól; aligha lenne konstruktív és releváns kimenete ennek a konkrét vitának. Hagyd meg inkább nekünk a nosztalgiázás örömét ebben a topikban.

a nézőpontjaink és az értékrendünk különböznek nagyon sarkalatosan

Ezt honnét veszed? Abból extrapoláltad, hogy szerintem a mai webre illik beállítani 2 perc alatt egy tanúsítványt? :) Emiatt a szemedben én már a marketingesek által kijelölt rossz irányt követem?

 

Hagyd meg inkább nekünk a nosztalgiázás örömét ebben a topikban.

Lehet úgy is nosztalgiázni, hogy közben nem szólod le a mai állapotot. Vagy ha már leszólod, legalább hozz fel pár konkrét érvet, amivel aztán egyet lehet érteni, vagy nem.

Részemről ennek semmi köze a nosztalgiához. Pont azt fejtegettem a topicban - ha nem tűnt volna fel - hogy Amigára is rengeteg silány szoftver született a rossz felfogás miatt: mert kóderek írták őket, nem programozók. Kóderek, akik algoritmizálni és optimalizálni baromira tudtak, de tervezni és gondolkozni nem, csak fusson, csak addig maradjon egyben az egész, amíg a a kiadó leteszteli A500-on, vagy amíg következő demoparty-n lemegy az A500-as compogépen. Igen, belefért 3 byte-ba és lefutott 2 nanoszekundum alatt, de futni csak közel 100%-os környezeti egyezés mellett futott, de még akkor is esetlegesen.

Ma a mainstream-ben, ennek a morbid inverze igaz. Megírják a kóderek úgy, hogy minden mainstream izén fusson, de teszik ezt elfuserált nyelvekkel és bloated futási környezetekkel, könyvtárakkal, keretrendszerekkel, amik iszonyat konvulens - túlmérnökölésnek is csak borzalmas jóindulattal hívható - módon oldanak meg mindent, hurcolják magukkal a sokszáz MB-ra, vagy akár GB-okra rúgó függőséghalmaikat, de nem számít, csak fusson windózon, macOS-en, Linuxon, vagy az okostelefonokon, vagy a browserekben.
Az optimalizációt meg elfelejtették; megírta a kóder a matematikai - vagy bármilyen - modelljét a függvényeiben, aztán hívogatja cikluson belül, de az nem jut eszébe, hogy a bemeneti értékkészlet számossága alacsony, tehát nyugodtan kitehette volna a függvénye végeredményeit egy táblába.

hurcolják magukkal a sokszáz MB-ra, vagy akár GB-okra rúgó függőséghalmaikat

Pl. Electron? :) Ebben egyetértünk, nincs ingyen egyelőre az ilyen multiplatform-képesség. Vannak azonban kezdeményezések a lecserélésére, amivel töredékükre esne vissza az ilyen programok mérete és memóriafogyasztása. (Lényegében az kellene, hogy legyen egy gyári HTML/CSS render motor, ami mindenhol pixelre pontosan ugyanúgy viselkedik.) Azonban még mindig jobb ha egy program Electron-t használ, mintha el sem készülne az általam használt rendszerre. Jelenleg 3 Electron-ra épülő programot használok napi szinten, ha nem is olyan fürgék, mint mondjuk egy Qt-s program, de teljesen használhatóak. Ha meg egyszer megérkezik a várva várt Electron alternatíva, üdvözölni fogom ha átállnak rá és még gyorsabbak lesznek.

 

Az optimalizációt meg elfelejtették

Ehhez kapcsolódóan megemlítem, lehet értékelnéd, amivel foglalkoztam, ugyanis a szimulációs programok többségét GPU-ra írtam, ott meg napi feladat a kódok optimalizálása a hardverre. Egy pár éves top GPU-ban van kicsivel több, mint 5000 mag(nak kvázi megfelelő egység). Nem triviális feladat írni rá egy olyan programot, ami ki is tudja használni a számolási kapacitást. Eggyel tovább lépve meg ha van 4 db ilyen GPU egy szerverben, akkor ~20000 magra kell szétosztani a számolási feladatokat figyelembe véve, hogy mindegyikre kb. ugyanannyi feladat jusson, ne zavarják egymás memóriaműveleteit, stb. Debuggolni se egyszerű, optimalizálni meg legtöbbször csak egy külön profilerrel lehet, amivel láthatóvá válik, hogy miként futott le a GPU-n a program.

De ez csak egy speciális alkalmazási terület. Electront (meg hasonló "bloated" környezetet) nagyságrendekkel többen használnak, és megértem azokat, akik webes technológiákat akarnak máshol is használni ahelyett, hogy egy teljesen új nyelvet/környezetet tanuljanak meg. Véleményem szerint ez még mindig jobb, mintha el sem készülne az adott program és inkább a bloated környezet alkotóinak adnak vele feladatot, hogy írják át kevésbé bloated-re a futási környezetet. (Ezzel próbálkoznak is több-kevesebb sikerrel.) Szerencsére legtöbbször van alternatíva, így nem kötelező a bloated változatot használni.

Az a baj, hogy az Electron csak egy a problémás ökoszisztémák közül. Az egész webkettő ennek a mocsárnak az eklatáns példája, amikor egy weboldal minimális funkcionalitásáért többféle többmegás JS keretrendszer felel, vagy a backenden terpeszkedő sokmegás, mindenre jó, de valójában semmire sem PHP-s keretrendszerek (a szerveroldali JS-ről már nem is beszélve). Vagy ott van a bankokat meghódító Java; az a nyelv is egy rémálom, meg az is, amit kiokád magából, meg az is, ahogyan utána futtatja. De ott van a Python is, illetve pontosabban nem maga a Python, mint nyelv, mert abból van még mikrokontrolleres verzió is, hanem konkrétan a desktopon felépült Pythonos ökoszisztéma a többféle csomagkezelőjével, ezerféle függőségével (és függőségkezelésével!); hacsak meglátom, hogy valaminek Pythonos a buildkörnyezete, már előre csikorgatom a fogam... Aztán ott a dotnet, amiből blikkre húzogatnak be mindent, ha kell, ha nem, aztán csodálkozunk, hogy egy ablak kirajzolása meghaladja a gép képességeit (ld. még a régi ATi Catalyst Control Center, vagy a windows vista egyes részei).
És nem is kell föltétlen az új nyelvekre és környezetekre mutogatni, mert egy igazi lamer bármilyen nyelven tud jávaszkript kódot írni: ld. GTK sorozat, na az is egy kupac szar, spagetti kód, agyhalott, körkörös függőségek, a 3-as meg már olyan lassú is, mint egy reumás csiga, pedig az pure C kód...

Értékelem én, hogy vetted a fáradságot, hogy rendes terheléselosztást csinálj, csak nem tudom, hogy ez hogy kapcsolódik ahhoz, hogy a programozóvilág rossz irányba megy. Felesleges volt magadra venned bármit is egy általános tendencia megemlítése miatt.

Én viszont nem értem meg azt, aki nem akar megtanulni semmit sem rendesen és mindenhova a kicsorbult svájci bicskáját akarja használni, akkor is, ha léggömböt kell felfújni. A program pedig elkészülne, mert szükség lenne rá, csak akkor nem lehetne összekókányoltatni másnapra fél fillérért. Itt leginkább az játszik közre, hogy rengeteg a meló és nincs elég ember, ezért olyanokkal is dolgoztatnak, akik nem csak, hogy nem értenek hozzá, de le is szarják az egészet; na nekik készülnek ezek az agyhalott ökoszisztémák.

Ma is lehet olyan weboldalt készíteni (szoktam is), ami méretben és egyszerűségben megegyezik a 20 évvel korábbi társaival, de az ugyanannyit is fog tudni: szöveget megjeleníteni egy-egy képpel. Ha azonban több funkcióra van szükség, akkor nagyobb lesz az oldal mérete, ebben nincs semmi meglepő. A mai web egy teljes platformmá nőtte ki magát, akár Quake 3 is fut egy átlag böngészőben, ami elég elképesztő, ha megnézzük honnét indult az egész. A web meg elég nagy ahhoz, hogy mindkettő elférjen egymás mellett. Ha egy sima blogot olvasok, elvárom, hogy egyszerű és kis méretű legyen, hiszen csak szöveget jelenít meg végeredményben. Ha azonban valami komolyabb szolgáltatást használok online, akkor nem csodálkozok, hogy szükség lesz hozzá JS-re is, hiszen annyi funkciót tud, amiért korábban egy külön programot kellett volna letöltenem a gépemre és offline futtatnom. Most mindez megoldható sok esetben egy böngészőn keresztül is. Mutass egy olyan oldalt, ahol több MB-nyi JS kell egy alapvető funkcióhoz (valami nagyon elszúrhattak rajta). Mellesleg az összes JS-bundler kiabál, ha pár száz kB-nál nagyobb lesz a végső csomag mérete.

 

a desktopon felépült Pythonos ökoszisztéma a többféle csomagkezelőjével, ezerféle függőségével

A Python még azelőtt született, hogy rájöttek volna: egy nyelvhez kell gyári csomagkezelőt is mellékelni, hogy sikeres legyen. Azonban az évek során szépen lassan kiforrott a dolog, sok Python csomagot használok, meg fejlesztek is Pythonban, nem szoktam problémába ütközni.

 

mindenhova a kicsorbult svájci bicskáját akarja használni

A bicska néhány pengéje élesebb, mint bármi más, ezért akarják máshol is használni őket. Ott van pl. a CSS flexbox, amivel triviális különféle elemeket tetszőlegesen elrendezni, ami alapvető funkció egy GUI-nál. Minek akarjon valaki megtanulni egy tök más megoldást erre, ha ez már bevált és könnyű használni? Az Electron-nal írt programok nagy része nem is csinál mást, kvázi ugyanúgy néz ki, mint egy weboldal. Sokan pont ezért választják, hogy nagyrészt közös kódbázissal megoldható legyen a multiplatform kiadás.

De persze én is találkoztam már számos pocsékul összerakott szoftverrel, amiket utána messziről elkerültem. Szerencsére legtöbbször van alternatíva, ami megfelel az igényeimnek.

Ma is lehet olyan weboldalt készíteni (szoktam is), ami méretben és egyszerűségben megegyezik a 20 évvel korábbi társaival, de az ugyanannyit is fog tudni: szöveget megjeleníteni egy-egy képpel. Ha azonban több funkcióra van szükség, akkor nagyobb lesz az oldal mérete, ebben nincs semmi meglepő.

Nagyobb lesz, de ennyivel? Ez a pszeudoprogresszívek fals dilemmája, hogy ha több funkció kell, akkor az sokkal több kódot jelent. Hát nem. Komplett webes vállalatirányítási rendszereket fejlesztettem le, amiben töméntelen RT funkció és segédeszköz volt, a JS kód meg még egy C64 memóriáját sem töltötte volna meg. Az előző melóhelyemen én csináltam egy autonóm beléptetőpanel szoftveres részét és volt webes backend, annyi beállítással, funkcióval, szenzoradattal, ami egy karácsonyfának is sok lenne, a JS kód pedig 17.3 kB. Nemrég volt egy próbafeladatom, ahol egy kereshető sorrendezhető táblát kértek, jQuery-vel és táblapluginekkel; a jQuery alaphangon 90k, a táblapluginek meg többszáz kilósak. Én kevesebb, mint 8k-ból megoldottam a JS részt. És még többet is tudott, mint egynémelyik soktízkilós táblaplugin, ami jó esetben egy mezőre tud szűrni, vagy rendezni.

Szóval rohadtul nem indokolt, hogy ennyire baromi sok kódból oldjanak meg dolgokat. Egyszerűen csak a webkettő úgy néz ki, hogy a divatkeretrendszereket használni kell és punktum.

A mai web egy teljes platformmá nőtte ki magát, akár Quake 3 is fut egy átlag böngészőben, ami elég elképesztő, ha megnézzük honnét indult az egész.

Ja, tényleg elképesztő, csak épp almát hasonlítunk a körtével; nem a Q3 JS verziójával van baj, hanem azzal, amikor ötven JS keretrendszert használnak egyszerre.

A web meg elég nagy ahhoz, hogy mindkettő elférjen egymás mellett. Ha egy sima blogot olvasok, elvárom, hogy egyszerű és kis méretű legyen, hiszen csak szöveget jelenít meg végeredményben.

Csakhogy a blog alatt is többszáz kB JS fog futni, mert csak.

Ha azonban valami komolyabb szolgáltatást használok online, akkor nem csodálkozok, hogy szükség lesz hozzá JS-re is, hiszen annyi funkciót tud, amiért korábban egy külön programot kellett volna letöltenem a gépemre és offline futtatnom.

Nem. Ld. a válaszom első szakaszát.

Mutass egy olyan oldalt, ahol több MB-nyi JS kell egy alapvető funkcióhoz (valami nagyon elszúrhattak rajta).

Ott a youtube. Már egy sima oldalt sem kapsz JS nélkül, mert 100% JS render az egész. Pedig valamikor még letiltott JS mellett is ment. Aztán ilyen nyalánkságok vannak benne, hogy egy URL visszaadásához is többtíz kilónyi JS hegyeket kell futtatni.

Mellesleg az összes JS-bundler kiabál, ha pár száz kB-nál nagyobb lesz a végső csomag mérete.

Biztos érdekli a webkettő gányereket.

A Python még azelőtt született, hogy rájöttek volna: egy nyelvhez kell gyári csomagkezelőt is mellékelni, hogy sikeres legyen. Azonban az évek során szépen lassan kiforrott a dolog, sok Python csomagot használok, meg fejlesztek is Pythonban, nem szoktam problémába ütközni.

Jó neked. Én meg szívok vele, amikor kitalálja a buildsystem, hogy a pip-en keresztül rakjak fel Wheelt, meg utána Meson-t, meg Ninja-t, meg mittudomén, az egyik ezzel nem kompatibilis, a másik azzal, a Debian Team meg felrakott egy olyan Meson-t a repoba, amihez Python 3.5 kell, Pythonból meg 3.4-et raktak fel...

A bicska néhány pengéje élesebb, mint bármi más, ezért akarják máshol is használni őket.

Mondom kicsorbult svájci bicskát.

Ott van pl. a CSS flexbox, amivel triviális különféle elemeket tetszőlegesen elrendezni, ami alapvető funkció egy GUI-nál. Minek akarjon valaki megtanulni egy tök más megoldást erre, ha ez már bevált és könnyű használni?

Hogy minek? Hogy ne kelljen a szemetéhez egy komplett webes rendering backend, talán annak.

Az Electron-nal írt programok nagy része nem is csinál mást, kvázi ugyanúgy néz ki, mint egy weboldal.

És annyit is zabál, mint egy JS-sel telibevert oldal. Ezt még te sem tagadtad, hogy az Electron egy bloatgenerátor, sőt te hoztad fel példának.

Sokan pont ezért választják, hogy nagyrészt közös kódbázissal megoldható legyen a multiplatform kiadás.

És én mit mondtam az elején? Ezt: "Megírják a kóderek úgy, hogy minden mainstream izén fusson, de teszik ezt elfuserált nyelvekkel és bloated futási környezetekkel, könyvtárakkal, keretrendszerekkel, amik iszonyat konvulens - túlmérnökölésnek is csak borzalmas jóindulattal hívható - módon oldanak meg mindent, hurcolják magukkal a sokszáz MB-ra, vagy akár GB-okra rúgó függőséghalmaikat, de nem számít, csak fusson windózon, macOS-en, Linuxon, vagy az okostelefonokon, vagy a browserekben."

Örülök, hogy konszenzusra jutottunk.

Nemrég volt egy próbafeladatom, ahol egy kereshető sorrendezhető táblát kértek, jQuery-vel és táblapluginekkel;

Hogy manapság már tök fölösleges a jQuery, abban egyetértünk. 10-15 évvel ezelőtt még egy fontos szerepet töltött be, mára azonban a böngészők megoldották azt a problémát, ami miatt a jQuery született. A 8 kB-os megoldásod feltételezem nem támogatta IE9-et, mint a jQuery, szóval annyira nem fer az összehasonlítás. :)

 

Egyszerűen csak a webkettő úgy néz ki, hogy a divatkeretrendszereket használni kell és punktum.

A fejlesztők többsége azért használ egy library-t, mert nem akar egy korábban megoldott problémát újra megoldani, hanem a saját dolgaival akar inkább foglalkozni. Én nem állnék neki írni egy n+1. táblázatkezelő libet, ha van már olyan, ami a céljaimnak megfelel.

 

Csakhogy a blog alatt is többszáz kB JS fog futni, mert csak.

Egyesével megnézed, vagy miként tűnik ez fel? Ha valami nagyon lassan tölt be, lehet bezárom még azelőtt, hogy megjelent volna és ezzel nem csak én vagyok így, a Google is bünteti a lassú oldalakat. Ez valamilyen szinten megakadályozza a több száz kB-os JS-t futtató blogokat, mert senki sem fogja őket olvasni. Ha leterheli a CPU-t a fölösleges JS, akkor is bezárom az oldalt.

 

Ott a youtube. Már egy sima oldalt sem kapsz JS nélkül, mert 100% JS render az egész.

A Youtube tök más tészta. Nem a hozzá nem értés miatt ilyen, hanem ez a termékük szerves része. Azért így oldották meg, hogy minél nehezebb legyen lelopni a tartalmat róla, mert az nekik nettó veszteség a kieső reklámbevétel miatt.

Egyébként meg a statikus oldalgenerátorok épp reneszánszukat élik. Van közöttük JS alapú is, de a legtöbb sima HTML-t generál. A Netlify és társai ezt a hullámot meglovagolva nőttek óriásira.

 

Hogy ne kelljen a szemetéhez egy komplett webes rendering backend, talán annak.

Miért ne? Miért töltse egy fejlesztő azzal az idejét, hogy az x. platform y. keretrendszerét is megtanulja, hogy abban is lekódolja ugyanazt a GUI-t, amit már z db másik platformon lekódolt? Kidobott idő. A webes technológiák elég jók ahhoz, hogy egy minimál multiplatform GUI-t össze lehessen rakni velük. Mint mondtam, az oprendszerek gyártóinak kellene egy konzisztens HTML render motort gyárilag leszállítani és akkor nem kéne Electront használni.

 

És annyit is zabál, mint egy JS-sel telibevert oldal.

A natív programok is eszik a memóriát, kérdés, hogy mennyi a különbség. Láttam már tetű lassú Electron-os programot, ami helyett kerestem inkább mást. De az a pár Electron-os program, amit használok, elfogadható mennyiségű memóriát és CPU időt fogyaszt.

Hogy manapság már tök fölösleges a jQuery, abban egyetértünk. 10-15 évvel ezelőtt még egy fontos szerepet töltött be, mára azonban a böngészők megoldották azt a problémát, ami miatt a jQuery született. A 8 kB-os megoldásod feltételezem nem támogatta IE9-et, mint a jQuery, szóval annyira nem fer az összehasonlítás. :)

ie9-em hirtelen nem volt, de volt itt egy kimustrált virtuális xp ie8-cal, azaz egyel korábbival. Kíváncsiságból kinyitottam benne (nem meglepő módon nem ment) és elkezdtem fixálni a funkciókat. Kifixáltam az AJAX-ot, a tábla megjelenítését, a keresést, sorrendezést, szerkesztést (már 95+%-os funkcionalitásnál járunk), aztán belefutottam valami cacheing mizériába és meguntam. De még mindig csak 7.5 kB-nál járok; egy-két sort kellett hozzáadni per funkt. Remélem nem azt akartad megmagyarázni, hogy a jQuery ie-kompatibilitási rétegre épülő tábla plugin többszáz kilója az ie-kompatibilitás miatt többszáz kiló, ha azt már a jQuery megoldotta. És nem, még az ie kompatibilitás sem csinál többszáz kB-nyi plusz kódot.

A fejlesztők többsége azért használ egy library-t, mert nem akar egy korábban megoldott problémát újra megoldani, hanem a saját dolgaival akar inkább foglalkozni. Én nem állnék neki írni egy n+1. táblázatkezelő libet, ha van már olyan, ami a céljaimnak megfelel.

Úgy tényleg nincs értelme a vitának, ha nem arra válaszolsz, amit írtam. Nem egy db. konkrét célú JS libről van szó, hanem komplett keretrendszerekről, ráadásul többről, egyszerre.

Egyesével megnézed, vagy miként tűnik ez fel?

Felbőgnek a ventilátorok, megugrik a load, aztán JS tilt és hirtelen minden megint csendes.

a Google is bünteti a lassú oldalakat.

Mi számít a google-nek lassúnak? Ha a krómban kipróbált kód még ma betölt krómban? És a többi browser? Egyébként, ha a legtöbb oldal ilyen trágya, akkor nem számít a google büntetése, mert mindet büntetni fogja.

Ez valamilyen szinten megakadályozza a több száz kB-os JS-t futtató blogokat, mert senki sem fogja őket olvasni.

A fenét. A júzereket még a cryptomining sem zavarja. Fel sem tűnik nekik, hogy az egész olyan, mint a csiga.

Ha leterheli a CPU-t a fölösleges JS, akkor is bezárom az oldalt.

Az se rossz, de én inkább tiltom a JS-t.

A Youtube tök más tészta. Nem a hozzá nem értés miatt ilyen, hanem ez a termékük szerves része. Azért így oldották meg, hogy minél nehezebb legyen lelopni a tartalmat róla, mert az nekik nettó veszteség a kieső reklámbevétel miatt.

Kár volt belinkelni az URL védelmet, mert így teljesen ignoráltad az első felét: a 100% JS-rendernek nincs köze a tartalom lelopásához. A hozzáértésről meg ennyit: http://www.commitstrip.com/en/2016/07/04/pre-roll-video/ (Igen, én is tudom, hogy ez vicc, de van benne igazság.)

Egyébként meg a statikus oldalgenerátorok épp reneszánszukat élik. Van közöttük JS alapú is, de a legtöbb sima HTML-t generál. A Netlify és társai ezt a hullámot meglovagolva nőttek óriásira.

Hogy jön ez ahhoz, hogy a webet elárasztotta a JS? Vagy a bankok Java appjaihoz, vagy a dotnet cuccait blikkre berángató alkalmazásokhoz? Vagy ahhoz, hogy a windows 10-ben ötvenszer tárolják le ugyanazt a kódot/adatot redundánsan és még a debug infókat sem strippelik a libekből? Ha vannak ezek a statikus generátorok, akkor a többi nincs?

Miért ne? Miért töltse egy fejlesztő azzal az idejét, hogy az x. platform y. keretrendszerét is megtanulja, hogy abban is lekódolja ugyanazt a GUI-t, amit már z db másik platformon lekódolt?

Szalmabáb érvelés. Nem azt mondtam, hogy kódoljon le mindent nulláról, hanem azt mondtam, hogy az Electront kerülje el. Miért? Mert így sokkal több erőforrást zabál a szemete. Ez csak a hardwaregyártóknak jó, senki másnak.

A webes technológiák elég jók ahhoz, hogy egy minimál multiplatform GUI-t össze lehessen rakni velük.

Több, mint másfél évtized webfejlesztés után azt hiszem megalapozottan mondhatom, hogy a webes taknyológiák semmire se jók. (Kis túlzással.)

Mint mondtam, az oprendszerek gyártóinak kellene egy konzisztens HTML render motort gyárilag leszállítani és akkor nem kéne Electront használni.

Milyen szempontból konzisztens? A vizuális végeredményből? Hát abból a szempontból nagyjából konzisztensek a létező motorok, amit a HTML kód leír, az közel azonosan néz ki mindegyikben, ami eltérés akadhat is, az a default CSS beállításokból ered. (Mínusz a HTML5 még nem támogatott elemei az adott motorban.) Mire gondoltál?

A natív programok is eszik a memóriát, kérdés, hogy mennyi a különbség.

Programfüggő, mint mondtam, egy igazi lamer bármilyen nyelven tud jávaszkript kódot írni; de azért nem a C++ szokott lassú lenni. Hovatovább, az Electron még mindig csak egy példa volt.

Remélem nem azt akartad megmagyarázni, hogy a jQuery ie-kompatibilitási rétegre épülő tábla plugin többszáz kilója az ie-kompatibilitás miatt többszáz kiló

Nem. Melyik tábla plugin volt ez? Könnyű egyébként gyűjteni a kB-okat, ha mellékel saját CSS-t, meg mobilon is jól működik, meg általános használatra készül sok funkcióval. A te tábla megoldásod biztos jó volt arra a pár funkcióra, amire kifejlesztetted, de nem egy általános pluginnak készült.

 

Nem egy db. konkrét célú JS libről van szó, hanem komplett keretrendszerekről, ráadásul többről, egyszerre.

Mi neked a keretrendszer? Nekem pl. Angular/React/Vue/stb. Soha nem láttam még olyat, hogy valaki egyszerre használt volna ezekből többet. Minek? Ugyanazt valósítják meg, csak máshogy.

 

Mi számít a google-nek lassúnak?

Ami egy felhasználónak is: max 1-2 mp a felső limit az első betöltésnél.

 

a 100% JS-rendernek nincs köze a tartalom lelopásához

Mi a problémád a 100% JS renderrel, azon a nyilvánvaló eseten kívül, hogy letiltott JS mellett nem megy? Van annak is jó néhány előnye és nem jelenti egyből azt, hogy lassú lesz az oldal.

 

Hogy jön ez ahhoz, hogy a webet elárasztotta a JS?

Hát pont úgy, hogy ezek gyakran JS nélküli sima HTML-t generálnak és az "érdekes" (szubjektív persze) web jó részét alkotják. A többi felsorolt problémához nincs közük nyilván.

 

Vagy a bankok Java appjaihoz

Van még ilyen egyáltalán? Pláne böngészőbe ágyazott.

 

Nem azt mondtam, hogy kódoljon le mindent nulláról, hanem azt mondtam, hogy az Electront kerülje el.

És hogy készítsen asztali változatot a webes szolgáltatásából egy fejlesztő anélkül, hogy 0-ról újraírja a GUI-t?

 

Több, mint másfél évtized webfejlesztés után azt hiszem megalapozottan mondhatom, hogy a webes taknyológiák semmire se jók. (Kis túlzással.)

Powered by lesajnált webes technológiák. :D Egyébként minek foglalkozol akkor még mindig vele, ha 15 év alatt se találtál egy neked tetsző webes stack-et? Felsorolni se lehet hányféle megoldás van, és sajátot is létrehozhattál volna ennyi idő alatt.

 

Milyen szempontból konzisztens? A vizuális végeredményből?

Közel pixel pontos megjelenés mindenhol és ne kelljen azzal törődni, hogy melyik platformon milyen feature támogatott, hanem egy egységes API legyen. Az Electron pont azért készült, mert a natív webview komponensek platformonként eltértek render végeredményben és elérhető funkciókban is. Amíg ezt nem oldják meg, addig marad az Electron.

> Melyik tábla plugin volt ez?

Több is. Keress táblaplugineket a jQuery-hez. (Gondolom, most mindjárt megkeresed a legprimitívebbet, ami csak 30 kB...)

> Könnyű egyébként gyűjteni a kB-okat, ha mellékel saját CSS-t, meg mobilon is jól működik, meg általános használatra készül sok funkcióval.

JS kódról beszélünk, nem CSS-ről.

> A te tábla megoldásod biztos jó volt arra a pár funkcióra, amire kifejlesztetted, de nem egy általános pluginnak készült.

Minden további nélkül lehet arra használni. Ami miatt "nem általános", hogy a mezők kézzel vannak megadva benne. Pár sor kód és jöhet konfigtömbből. Próbálhatod bagatellizálni, csak felesleges. A jQuery-s táblapluginok többsége, ahogy néztem egy mezőre tudott szűrni és rendezni, nem volt multifield filter és order, pláne nem prioritizálható sorrenddel.

> Mi neked a keretrendszer? Nekem pl. Angular/React/Vue/stb.

Nekem is ezek.

> Soha nem láttam még olyat, hogy valaki egyszerre használt volna ezekből többet. Minek? Ugyanazt valósítják meg, csak máshogy.

Mert nem éltél webfejlesztésből... Az egyik funkciót ezzel a keretrendszerrel valósítják meg, mert ehhez van plugin, a másikat azzal, mert ahhoz van plugin...

> Ami egy felhasználónak is: max 1-2 mp a felső limit az első betöltésnél.

Ehhez képest baromi ritka, hogy valami 1-2 sec alatt bejöjjön. (Ld. hup-os topicok, ha már szóbahoztad a hupot.) Egyébként melyik browserből 1-2 sec? Nem csak króm van. Nem véletlen, hogy a gugli ennyire erőlteti a JS-t; a króm JS motorja a legerősebb, ha az egész átáll a JS-erőltető megoldásokra, a króm versenyelőnye fokozódni fog.

> Mi a problémád a 100% JS renderrel, azon a nyilvánvaló eseten kívül, hogy letiltott JS mellett nem megy? Van annak is jó néhány előnye és nem jelenti egyből azt, hogy lassú lesz az oldal.

Az, hogy szerver oldali rendernél a szervert terheljük vele, jóesetben egyszer, amíg a cache nem lesz invalidálva, míg kliensoldalinál minden egyes klienst, ugyanazzal a renderfeladattal, sokszor. Miért is kell ez? Egyik példa pl., hogy meg lehessen indokolni az okostelefonok gyors erkölcsi avulását.

> A többi felsorolt problémához nincs közük nyilván.

Ehhez képest szépen leragadtunk a JS/Electron körben, pedig mint mondtam, csak egy közülük.

> Van még ilyen egyáltalán? Pláne böngészőbe ágyazott.

ie-only oldalak is vannak még, a pénzügyi szektor nehezen mozdul.

> És hogy készítsen asztali változatot a webes szolgáltatásából egy fejlesztő anélkül, hogy 0-ról újraírja a GUI-t?

Qt-hoz van saját stylesheet (QSS), lehet a CSS-t konvertálni, de egyébként színes-szagos, seggkinyalós GUI buildere is van.

> Powered by lesajnált webes technológiák. :D

Mert ugye itt a Drupal 8-ra való átállással is sokkal jobb lett minden.

> Egyébként minek foglalkozol akkor még mindig vele, ha 15 év alatt se találtál egy neked tetsző webes stack-et?

Azzal foglalkozom, amit megfizetnek. Ha van más, azt csinálom.

> Felsorolni se lehet hányféle megoldás van,

A többségük szar, max. egy-két specifikus célra létrehozott cucc van, ami azt tényleg jól tudja, amire kitalálták.

> és sajátot is létrehozhattál volna ennyi idő alatt.

Szerinted nem csináltam, többször is, a különféle cégeknek? Ott örültek, hogy milyen gyors, aztán annyi.

> Közel pixel pontos megjelenés mindenhol és ne kelljen azzal törődni, hogy melyik platformon milyen feature támogatott, hanem egy egységes API legyen. Az Electron pont azért készült, mert a natív webview komponensek platformonként eltértek render végeredményben és elérhető funkciókban is. Amíg ezt nem oldják meg, addig marad az Electron.

Pedig pont erre törekednek és elég nagy százalékban ugyanaz is jelenik meg, a maradék meg a default CSS-en múlik, de épp ezért vannak ilyen reset CSS-ek is. Egyébként hogyan is szabadulunk meg a webes technológiától, ha a browserek eljutnak oda, ahova te mondod?

Egyébként, ahhoz képest, hogy állításod szerint a véleményem érdekelt, már elkezdted bagatellizálni amiket csináltam és már kezded a véleményemet is karikírozni; már próbálod rámhúzni a csörgősipkát. Megmondtam, hogy magasról teszel a véleményemre, te már eldöntötted az elején, hogy mit akarsz hinni.

Az, hogy szerver oldali rendernél a szervert terheljük vele, jóesetben egyszer, amíg a cache nem lesz invalidálva, míg kliensoldalinál minden egyes klienst, ugyanazzal a renderfeladattal, sokszor.

Ez csak addig igaz amíg nincs felhasználó függő dinamikus tartalom az oldalon. Amint van, a teljes renderelt oldal cache-elése szinte lehetetlen. Azonban az oldalt összeállító kérések egy része lehet teljesen statikus vagy ritkán változó, amit már lehet hatékonyan cache-elni.

Másrészt ha már betöltötted az oldalt, sokkal egyszerűbb egy lekérés után a DOM egy részét frissíteni, miközben a nem változó tartalom a memóriában marad, mint teljesen újratölteni az oldalt, minden adat újabb lekérdezésével együtt.

Ez amit írsz, ez a dinamikus oldal/dinamikus betöltődés, én pedig nem erről beszéltem, hanem a kliensoldali renderről, direkt ki is emeltem, hogy arról van szó.
Nem az a baj, amikor AJAX-szal behúzol plusz HTML kódot a szerverről amit egy-az-egyben egy darab insertAdjacentHTML() vagy innerHTML segítségével beraksz a helyére, az a gáz, amikor kliens oldalon renderelődnek az oldal, akár statikus, akár dinamikus részei, ahol HTML helyett kap egy JSON tömböt, azt először felparse-álja objektumtömbnek, aztán végigiterálja és createElement-ekkel, attribútum beállításokkal és appendChild-ekkel szerel a helyére, azaz egyetlen értékbeállító parancs helyett - ami a natív HTML parser-t hívná meg - inkább a script-ből interpretálva létrehozza egyesével az érkező node fa elemeit, mint ha kliens oldalon születtek volna, holott nem.

A renderről beszélgetünk, nem a betöltésről.

Nem véletlen, hogy a legtöbb API nem nyers HTML-t ad vissza. Pl. ugyanazt az API-t hívja a weboldal és a mobil appok, vagy az API nem rendelkezik minden információval, ami a rendereléshez kell. Persze erre még mondhatod, hogy akkor hiányzik egy réteg a backenden, ami elvégzi az API hívást majd rendereli a választ a kliensnek. De ezzel egy rakás problémát a nyakadba veszel, pl. ha egy új feature-höz több infó kell a klienstől, hogy megváltoztasd a kimenetet, akkor a klienst is változtatni kell, vagyis verzióznod kell mert a már betöltött kliensek nem fogják elküldeni a hiányzó paramétert. Nyilván ez a probléma valamennyire jelen van akkor is, ha közvetlenül hívod a nyers adatot visszaadó API-t, de jóval kevésbé jellemző.

Még egy dolog eszembe jutott, ha a renderelt tartalomban interaktív elemek vannak, akkor azt a betöltés után még hidatálni kell (pl. eseményvezérlőket kell rakni ezekre az elemekre), vagyis a kliensnek ismernie kell valamilyen módon, hogy mit tölt be. Amíg kevés ilyen tartalom van addig ezt le lehet implementálni pár selectorral tartalomtípusonként, de amikor a teljes oldalt így építed fel akkor ez nagyon nehezen lesz karbantartható.

A gond alapvetően azzal van, hogy elválasztod egymástól a komponensek renderelését és eseménykezelését. Igen, az se jobb, ha ezt az onload eseménykezelője csinálja, ezt írtam is feljebb. Ha a HTML kódba van beleszórva az eseménykezelés (vagy legalábbis annak meghívása), azzal függővé teszed a szerveroldali renderelést egy általad definiált kliensoldali API-tól. Vagyis eljutottál oda, hogy a két kódbázis egymástól függ, innentől bármilyen változtatás potenciálisan mindkét kódbázist érintheti, miközben figyelni kell a visszafele kompatibilitásra is. Az automata integrációs tesztelésnek innentől az eseménykezelés is része kell, hogy legyen, ami csak böngészőből lehetséges.

Ameddig adatcsere van a két oldal között, addig a két kódbázis mindenképpen függeni fog egymástól, ezen nem tudsz változtatni. Az, hogy van egy API-d, amit egymás között használnak és amíg annak az API-nak megfelelnek, addig cserélgethető a két oldalt meghajtó motor, az a függés tényén nem változtat. Részemről pedig mindig azt preferáltam, ha a kliens és a szerver "egymáshoz" lettek írva és nem pedig összeollóztam az egymáshoz semmi közzel nem bíró backendet és frontendet.

Valamilyen függés lesz, de általában ez egyirányú, vagyis a kliens függ az API-tól és az API-nak csak arra kell figyelnie, hogy minden változás visszafele kompatibilis vagy megfelelően verziózott legyen. Amit te felvázolsz ott kétirányú függés van, vagyis nem lehet az API-hoz új feature-öket úgy hozzáadni, hogy azt a kliens ne támogassa, vagyis előbb a klienst is fel kell készíteni. Ez még működőképes lehet ha egy csapat dolgozik az adott szoftveren és van pár hetente egy release, de amikor a szoftveren több csapat dolgozik folyamatosan több kontinensen szétszórva és akár több production deployment is van egy nap, akkor ezek a problémák már sokkal nehezebben managelhetőek.

Én se úgy értem, hogy a kliens és az API egymástól független, nyilván az API a kliensek igényét hivatott kiszolgálni és ennek mentén van fejlesztve. Csak azt mondom, hogy az API-nak nem kellene számon tartania, hogy mit és hogyan támogatnak a kliensei, pláne mivel több kliens verzió futhat párhuzamosan.

A példa kedvéért tegyük fel, hogy egy webshopot építünk, aminek a keresőoldalán a találati listát egy ilyen API-val töltjük be. Tehát lesz egy API végpontunk amit hívjunk keresésnek, aminek átadjuk a keresési paramétereket és visszaad egy renderelt listát. Mindegyik termék mellé tesz egy gombot, amivel hozzáadható a termék a kosárhoz. Továbbá lesz egy másik API végpontunk amit hívjuk hozzáadnak, ami megkapja a termék számát és hozzáadja az adott terméket a user sessionben tárolt kosárhoz, valamint visszaad egy üzenetet, hogy a hozzáadás sikerült. A kliens úgy valósítja meg a gomb eseménykezelőjét, hogy meghívja a hozzáad API végpontot az adott termék számával, majd megjeleníti a visszaadott üzenetet.

Miután mindez működik az éles oldalon, kapunk egy olyan feladatot, hogy egyszerre több darabot is hozzá lehessen adni a kosárhoz az adott termékből. Ehhez a gomb mellé kell rakni egy mennyiség mezőt, aminek az alapértelmezett értéke egy, és amit a felhasználó tetszőleges mennyiségre növelhet. Valamint a hozzáad API végpontot is módosítani kell, hogy a termék száma mellett meg lehessen adni a mennyiséget is. Mivel az eseménykezelést a kliens valósítja meg, ezért a klienst is módosítani kell, hogy elküldje a rendelt mennyiséget a hozzáad API-nak. Itt már eleve felmerül a kérdés, hogy a kliens a DOM-on keresztül olvassa ki a mennyiséget, vagy az a mező is kapjon egy eseménykezelőt amin keresztül a kliens kód meg tudja jegyezni, a felhasználó hány darabot rendel. Akárhogy is csináljuk, előbb a klienst kell módosítani, hogy tudja kezelni a találati listában az új mezőt és elküldje a hozzáad API végpontnak, majd ezután deploy-olható az API változtatás.

Azonban mi történik akkor, ha egy felhasználó nyitva hagyott egy tabot pár nappal ezelőttről, és indít egy új keresést? Meg fogja kapni a találati listában a mennyiség mezőt, amivel az ő kliens verziója nem fog tudni mit kezdeni. Ahhoz, hogy ezt a problémát kezeljük, az API-t verziózni kell, és fel kell készíteni a klienst, hogy tudja használni az új API-t. Ekkor előbb az új API verziót kell deploy-olni, ezután lehet frissíteni a klienst, ami már az új API verziót használja. A régi API verziót addig kell támogatni, amíg a régi kliensek végleg eltűnnek (ezt legfeljebb az API monitorozásából deríthetjük ki, meddig érkeznek kérések a régi végpontra).

Valamilyen függés lesz, de általában ez egyirányú, vagyis a kliens függ az API-tól és az API-nak csak arra kell figyelnie, hogy minden változás visszafele kompatibilis vagy megfelelően verziózott legyen. Amit te felvázolsz ott kétirányú függés van, vagyis nem lehet az API-hoz új feature-öket úgy hozzáadni, hogy azt a kliens ne támogassa, vagyis előbb a klienst is fel kell készíteni. Ez még működőképes lehet ha egy csapat dolgozik az adott szoftveren és van pár hetente egy release, de amikor a szoftveren több csapat dolgozik folyamatosan több kontinensen szétszórva és akár több production deployment is van egy nap, akkor ezek a problémák már sokkal nehezebben managelhetőek.

A függés mindenképpen kétirányú; szerinted, ha a backend nem támogat valamit, akkor hogy adsz hozzá új feature-t a klienshez? Mármint olyat, aminek szólnia is kell a backendhez, a tisztán kliensoldali feature-öknek érdektelen az API.

Én se úgy értem, hogy a kliens és az API egymástól független, nyilván az API a kliensek igényét hivatott kiszolgálni és ennek mentén van fejlesztve. Csak azt mondom, hogy az API-nak nem kellene számon tartania, hogy mit és hogyan támogatnak a kliensei, pláne mivel több kliens verzió futhat párhuzamosan.

Nagyon nem értek egyet; mi van, ha valaki nekiáll bullshittel bombázni a backendet? Mi van, ha valaki szándékosan kitörölget az elküldött lekérésekből? De, az API-nak tisztában kell lennie azzal, hogy hány és miféle értéket vár és ami hibádzik, azt ki is kell pótítania.

Miután mindez működik az éles oldalon, kapunk egy olyan feladatot, hogy egyszerre több darabot is hozzá lehessen adni a kosárhoz az adott termékből. Ehhez a gomb mellé kell rakni egy mennyiség mezőt, aminek az alapértelmezett értéke egy, és amit a felhasználó tetszőleges mennyiségre növelhet. Valamint a hozzáad API végpontot is módosítani kell, hogy a termék száma mellett meg lehessen adni a mennyiséget is. Mivel az eseménykezelést a kliens valósítja meg, ezért a klienst is módosítani kell, hogy elküldje a rendelt mennyiséget a hozzáad API-nak. Itt már eleve felmerül a kérdés, hogy a kliens a DOM-on keresztül olvassa ki a mennyiséget, vagy az a mező is kapjon egy eseménykezelőt amin keresztül a kliens kód meg tudja jegyezni, a felhasználó hány darabot rendel. Akárhogy is csináljuk, előbb a klienst kell módosítani, hogy tudja kezelni a találati listában az új mezőt és elküldje a hozzáad API végpontnak, majd ezután deploy-olható az API változtatás.

Akkor kezdjük azzal, hogy ezt akár úgy is át lehet hidalni, hogy a backend felé kommunikáló részek előbb mindig lekérhetik a backendtől az aktuális selectorlistet, hogy miket is kell nekik összeszedniük és átküldeniük, aztán amit még nem létezés okán nem talált még meg a kliensoldalon azt a szerveroldalon default értékkel helyettesítjük. Ily módon a kliens verziója irrelevánssá válik, mert a backend mondja meg neki, hogy mit kell visszaadnia, tehát a kliensoldali kódnak soha nem is kell tudnia, hogy miket kell átadnia, ezért nem is lesz beledrótozva, viszont ennek a hátulütője, hogy van a legtöbb AJAX-oló részben plusz egy request. De van jobb megoldás is...

Azonban mi történik akkor, ha egy felhasználó nyitva hagyott egy tabot pár nappal ezelőttről, és indít egy új keresést? Meg fogja kapni a találati listában a mennyiség mezőt, amivel az ő kliens verziója nem fog tudni mit kezdeni. Ahhoz, hogy ezt a problémát kezeljük, az API-t verziózni kell, és fel kell készíteni a klienst, hogy tudja használni az új API-t. Ekkor előbb az új API verziót kell deploy-olni, ezután lehet frissíteni a klienst, ami már az új API verziót használja. A régi API verziót addig kell támogatni, amíg a régi kliensek végleg eltűnnek (ezt legfeljebb az API monitorozásából deríthetjük ki, meddig érkeznek kérések a régi végpontra).

...ami pedig a rendszer felkészítése arra, hogy a kliens megváltozhat. Van egy lekérhető pont a rendszerben, hogy mikori az utolsó kliens revízió, amit ciklikusan le is kér a kliens és ha a kapott érték magasabb, mint az, ami a kliensben épp tárolva van, akkor újra kell húzni az oldalt.

Több is. Keress táblaplugineket a jQuery-hez.

Megnéztem párat, elég nagy a szórás (*.min.js méretek):

  • Tabulator - 351 kB
  • StackTable - 8 kB
  • tabellajs - 16 kB
  • DataTables - 84 kB
  • tabular - 9 kB
  • jspreadsheet - 549 kB
  • jquery-gettable - 3.6 kB
  • FancyGrid - 630 kB
  • restables - 3 kB
  • jtable - 207 kB

A képességeket nem hasonlítottam össze, de feltételezem korrelálnak a mérettel. Persze könnyedén előfordulhatott az is, hogy egy nagy méretű plugin nem tudta azokat, amire neked szükséged volt, így az lett a benyomásod összességében, hogy ez egy tök fölösleges bloated plugin. A jQuery korában sajna nem volt még tree-shaking meg hasonlók.

 

Mert nem éltél webfejlesztésből...

Ez téves feltételezés. Webfejlesztés miatt tanultam meg programozni, ami meg követelmény volt a csoportnál, ahol anno elkezdtem alapkutatással foglalkozni (attól most tekintsünk el, hogy persze teljesen más felfogású programot kell fejleszteni).

 

Az egyik funkciót ezzel a keretrendszerrel valósítják meg, mert ehhez van plugin, a másikat azzal, mert ahhoz van plugin...

Hát abban egyetértünk, hogy ez így elég béna megoldás.

 

Ehhez képest baromi ritka, hogy valami 1-2 sec alatt bejöjjön.

Nagy oldalaknál ritka, blogoknál azért nem. Sima statikus oldalak pár tized mp alatt bejönnek (persze ehhez megfelelő szerver/CDN is kell).

 

Ld. hup-os topicok, ha már szóbahoztad a hupot.

Egy HUP topik betöltése leginkább a hozzászólások számától függ. A kisebbek betöltődnek 2 mp alatt (FF, 7 éves laptop), a nagyobbaknál tovább gondolkodik a szerver.

 

Az, hogy szerver oldali rendernél a szervert terheljük vele, jóesetben egyszer, amíg a cache nem lesz invalidálva, míg kliensoldalinál minden egyes klienst, ugyanazzal a renderfeladattal, sokszor.

Ez azért jóval összetettebb kérdés, minthogy minden kliensoldali render rossz. Egy mobil egyszerre olyan kevés tartalmat jelenít meg, hogy annak renderelése nem okozhat problémát, a további tartalmat meg lehet folyamatosan betölteni, így sávszélességet is lehet spórolni, ami inkább szokta jelenteni a szűk keresztmetszetet. Cachelni SPA-nál is lehet a szerverről érkező adatokat, a kliens oldalon meg csak azt kell újra renderelni, ami megváltozott, nem az egész oldalt. Szerintem az SPA-knak is megvan a saját alkalmazási területük, ahol a legjobb összteljesítményt nyújtják, egy sima statikus blogra fölösleges.

 

Ehhez képest szépen leragadtunk a JS/Electron körben, pedig mint mondtam, csak egy közülük.

Nem akartam olyan technológiához hozzászólni, amit nem nagyon ismerek fejlesztői szemszögből (java, dotnet). Biztos vannak itt is pocsék megoldások, de mellette jók is, mint bárhol máshol. Csak te nagyon leragadtál a pocsék megoldások tárgyalásánál, mintha nem is lenne más.

 

Qt-hoz van saját stylesheet (QSS), lehet a CSS-t konvertálni

Ez nekem új. Át lehet konvertálni közvetlen HTML/CSS kombót Qt kódba, ami ugyanúgy fog kinézni, mintha Electron-nal készülne?

 

Szerinted nem csináltam, többször is, a különféle cégeknek? Ott örültek, hogy milyen gyors, aztán annyi.

Ha van saját keretrendszered, ami teljesen bloatmentes, minimális kliensoldali JS mellett is tud csomó interaktivitást, akkor nem értem miért van ilyen negatív véleményed a webes technológiákról, hiszen egy jó dolog már legalább készült vele. Mellesleg felrakhatnád pl. GitHub-ra, hogy más is használhassa, és gyors, bloatmentes oldalakat fejlesszen vele. Hiába erősen szaturált a piac, ha tényleg jó, fogják a fejlesztők használni. (Mindegyik más keretrendszer is így indult, valamit jobban oldott meg mint a többi.)

 

Egyébként hogyan is szabadulunk meg a webes technológiától, ha a browserek eljutnak oda, ahova te mondod?

Nem a hagyományos böngészőkről volt szó (ott már többnyire megoldott probléma ez), hanem az oprendszerekbe gyárilag beépülő webrender motorról/API-ról, amivel desktop programokat lehetne írni webes technológiákkal. Olyat sosem írtam, hogy meg kéne szabadulni a webes technológiáktól. Azt írtam, hogy az Electront kéne lecserélni gyári, optimalizált megoldásra, ezáltal jelentősen lecsökkenne a memóriafoglalás és gyorsabbak is lennének ezek a programok. Utána teljesen mindegy lenne, hogy pl. natív Qt-vel, vagy sima HTML/CSS-sel készít valaki desktop programot.

 

Egyébként, ahhoz képest, hogy állításod szerint a véleményem érdekelt, már elkezdted bagatellizálni amiket csináltam

Hol csináltam én ilyet? Megint túlreagálsz. Ha nem érdekelne a véleményed, akkor minek válaszolgatnék? Arról valóban nem tudtál meggyőzni, hogy a mai webes technológiák többsége rossz lenne, nekem más a tapasztalatom. De ettől függetlenül kíváncsi vagyok mások véleményére, gyakran lehet belőle tanulni.

(*.min.js méretek):

(Just for the record: az enyém minifizálás nélkül és kommentekkel együtt volt < 8 kB.)

A képességeket nem hasonlítottam össze, de feltételezem korrelálnak a mérettel. Persze könnyedén előfordulhatott az is, hogy egy nagy méretű plugin nem tudta azokat, amire neked szükséged volt, így az lett a benyomásod összességében, hogy ez egy tök fölösleges bloated plugin.

Ha korrelálnak a mérettel, akkor hogy futhattam bele olyan heavyweight pluginba, ami szinte semmit sem tudott? Egyébként jellemzően a méretnek semmi köze nincs a tudáshoz; hogy ne csak a jQuery körül kerengjünk, ott van mérlegpéldának az Adminer és a PHPMyAdmin.

Ez téves feltételezés. Webfejlesztés miatt tanultam meg programozni, ami meg követelmény volt a csoportnál, ahol anno elkezdtem alapkutatással foglalkozni (attól most tekintsünk el, hogy persze teljesen más felfogású programot kell fejleszteni).

Én azt mondtam, hogy abból élni, nem azt, hogy foglalkozni vele. Ha te a webfejlesztéssel egy tudományos csoportban folyó kutatás kapcsán találkoztál, akkor sose nézhettél igazán annak mocsoknak mélyére, ami a webfejlesztő cégek berkein belül, a konzumer szférában folyik. Láttál már Smarty-s template-ezést? Vagy egy "classic" WP portált belülről? Már bocs, de egy elefántcsonttoronyból könnyű azt mondani, hogy azért annyira azért nem szar ez.

Nagy oldalaknál ritka, blogoknál azért nem. Sima statikus oldalak pár tized mp alatt bejönnek (persze ehhez megfelelő szerver/CDN is kell).

Egy HUP topik betöltése leginkább a hozzászólások számától függ. A kisebbek betöltődnek 2 mp alatt (FF, 7 éves laptop), a nagyobbaknál tovább gondolkodik a szerver.

Az oscomp vendégkönyvében közel 4000 poszt jön le 1-2 sec alatt. A BGAFC 21000 posztja kb. 15 sec, de az sem azért, mert a kód lassú (mármint PHP-hoz képest), hanem mert 32 MB-nyi szöveg van benne. Cache-ing egyik alatt sincs.

Egy mobil egyszerre olyan kevés tartalmat jelenít meg, hogy annak renderelése nem okozhat problémát

Nem okoz problémát != nem okoz plusz többletterhelést. Gyorsan lemerül az okostelefon akksija böngészés közben? A kliensoldali rendering energiaigényes. Szorozd fel a mobilok számával.

a további tartalmat meg lehet folyamatosan betölteni, így sávszélességet is lehet spórolni, ami inkább szokta jelenteni a szűk keresztmetszetet. Cachelni SPA-nál is lehet a szerverről érkező adatokat, a kliens oldalon meg csak azt kell újra renderelni, ami megváltozott, nem az egész oldalt. Szerintem az SPA-knak is megvan a saját alkalmazási területük, ahol a legjobb összteljesítményt nyújtják, egy sima statikus blogra fölösleges.

De már megint összemossátok a dinamikus tartalombetöltést a kliens oldali renderinggel. A kettő baromira nem ugyanaz.

Nem akartam olyan technológiához hozzászólni, amit nem nagyon ismerek fejlesztői szemszögből (java, dotnet). Biztos vannak itt is pocsék megoldások, de mellette jók is, mint bárhol máshol.

A Java-s világ kb. en-bloc tűzrevaló.

Csak te nagyon leragadtál a pocsék megoldások tárgyalásánál, mintha nem is lenne más.

Szalmabábu strikes again. Nem mondtam ilyet, hogy nincs más.

Ez nekem új. Át lehet konvertálni közvetlen HTML/CSS kombót Qt kódba, ami ugyanúgy fog kinézni, mintha Electron-nal készülne?

Hogy ugyanúgy néz-e ki, azt a tököm tudja, de idézem:

Qt Style Sheet terminology and syntactic rules are almost identical to those of HTML CSS.

Elég ráereszteni pár find/replace kombót. A Qt5-nek is megvannak a maga "Electronos" megfelelői a QML és a QSS. Itt egy gyors benchmark, a Qt5 fórja az Electronnal szemben közel 4x-es a memóriazabálás tekintetében. Vicces amúgy, ahogy a csávó az Electront akarja mosdatgatni ennek ellenére. (És még a Qt5 is eléggé elkeserítő, hogy egy szimpla ablak, menükkel közel 100 MB...)

Ha van saját keretrendszered, ami teljesen bloatmentes, minimális kliensoldali JS mellett is tud csomó interaktivitást, akkor nem értem miért van ilyen negatív véleményed a webes technológiákról, hiszen egy jó dolog már legalább készült vele.

Ez valami asszertív kommunikáció akar lenni? Az a "jó", az elég idézőjeles jó, mert maximum kevésbé szarabb. A web az web marad. A HTML-t és a CSS-t dokumentumokra találták ki (arra egyébként jó is). A PHP-t gyors szövegfeldolgozásra (arra egyébként jó is). A JS-t meg elméletileg a DOM fa csesztetésére, de leginkább úgy hányták össze, ahogy épp gondolták és leginkább semmire se jó. Semmire se. És ezekben írunk ma alkalmazásokat.

Mellesleg felrakhatnád pl. GitHub-ra, hogy más is használhassa, és gyors, bloatmentes oldalakat fejlesszen vele.

Jól rommá is perelnének, teljes joggal.

Hiába erősen szaturált a piac, ha tényleg jó, fogják a fejlesztők használni. (Mindegyik más keretrendszer is így indult, valamit jobban oldott meg mint a többi.)

Dehogy fogják. Szembemegyek minden paradigmával, amit a webkettő diktál. És amikor megmutatom, hogy mennyivel gyorsabb, vagy egyszerűbb, vagy akármi, akkor megkapom, hogy de ezt nem így kell csinálni. Ez egy vallás.

Nem a hagyományos böngészőkről volt szó (ott már többnyire megoldott probléma ez), hanem az oprendszerekbe gyárilag beépülő webrender motorról/API-ról, amivel desktop programokat lehetne írni webes technológiákkal.

Szépen kikerülted a kérdést. Akkor legyenek a motorok, tök mindegy. Hogy szabadulunk meg a webes technológiáktól, ha a motorok eljutnak oda, ahova mondod?

Olyat sosem írtam, hogy meg kéne szabadulni a webes technológiáktól.

Egy szóval nem mondtam, hogy te mondtad. Én kérdezem.

Azt írtam, hogy az Electront kéne lecserélni gyári, optimalizált megoldásra, ezáltal jelentősen lecsökkenne a memóriafoglalás és gyorsabbak is lennének ezek a programok. Utána teljesen mindegy lenne, hogy pl. natív Qt-vel, vagy sima HTML/CSS-sel készít valaki desktop programot.

És hogyan szabadulunk meg a webes szeméttől, ha ez továbbra is webes render lesz?

Hol csináltam én ilyet?

Pl. ott, ahol elkezdtél lealkudni a táblagenerátor tudásából, bár nem tudom mire alapozva. Vagy a "Powered by lesajnált webes technológiák. :D" kitételnél.

Ha nem érdekelne a véleményed, akkor minek válaszolgatnék?

Gondolom, hogy a többieket meggyőzd, hogy a trécéhá egy laggard, aki szerint régen minden jobb volt, alien a haladás. (Just for the record: nem a haladással magával van bajom, hanem azzal, amit manapság pénzügyi érdekekből mögévetítenek; ami ma az iparban megy, az nem haladás, hanem álhaladás; rommábutítás, agyonbonyolítás, silány szemét eladása. Ez maximum a szakadék felé haladás.)
Bár ki tudja, lehet tévedek és csak a topicot akarod szétoffolni. Ezt egyébként elismerem nagyon jól csinálod, először a HTTPS-sel, most meg azzal, hogy merre megy vagy nem megy a programozói világ.

Arról valóban nem tudtál meggyőzni, hogy a mai webes technológiák többsége rossz lenne, nekem más a tapasztalatom.

És ebből a tapasztalatból mennyit szereztél a konzumer szférában és mennyit tudományos projektekben?

Én azt mondtam, hogy abból élni, nem azt, hogy foglalkozni vele.

Webfejlesztéssel ~10 évvel hamarabb kezdtem el foglalkozni (még középiskolásként), minthogy meglett volna a fizikusi diplomám. Pár évig éltem belőle szabadúszóként.

 

Láttál már Smarty-s template-ezést? Vagy egy "classic" WP portált belülről?

Igen és igen. Sőt, még PHP Nuke-ot is az IE6-os sötét korszakban, aztán Drupal 5-6-7, tovább nem mentem PHP vonalon. Smarty nem igazán jött be, a Twig/Jinja/Django típusú template rendszer jobban kézre esik.

 

Már bocs, de egy elefántcsonttoronyból könnyű azt mondani, hogy azért annyira azért nem szar ez.

Bárcsak egyszer elefántcsonttoronyban dolgoznék, megtudnám milyen az. A második világháború után 5 évvel felhúzott épületet nagyon nem nevezném annak. :D

 

Gyorsan lemerül az okostelefon akksija böngészés közben? A kliensoldali rendering energiaigényes.

A kijelző fogyasztja általában a legtöbbet. Egy weboldal nem járatja folyamatosan a CPU-t.

 

De már megint összemossátok a dinamikus tartalombetöltést a kliens oldali renderinggel. A kettő baromira nem ugyanaz.

Itt valahogy nagyon elbeszélünk egymás mellett. Egy jól megírt SPA szerves része a kliens oldali HTML összepakolása a dinamikusan letöltött JSON (vagy akármi más) tömbök alapján, erre vannak a komponensek. Egy komponens előállítja az adatok alapján a HTML-t, amit az SPA bepakol a megfelelő helyre és a böngésző végül megjeleníti a tartalmat. Egy komponenst egyszer kell csak letölteni a szerverről ezután a kliens oldali JS tudni fogja, hogy az adatok alapján milyen HTML-t kell gyártania. Emiatt ha a látogató navigál az oldalon, csak a nyers adatokat kell lekérdeznie a szerverről, a template már ott van a cache-ben lévő komponensben. Az SPA csak azt a tartalmat fogja lecserélni az oldalon, ami változik, nem kell újrarenderelnie a böngészőnek ezáltal a teljes oldalt, ezáltal jóval gyorsabb is lehet.

Egy SPA azonban úgy is működhet, hogy nem nyers JSON adatokat fogad a szerverről, amikor oldalak között navigál a látogató, hanem a szerver előállítja a HTML fragmenteket a sablonok alapján és ezt küldi vissza. Ekkor a kliens oldalon az SPA-nak már nem kell egy komponens alapján előállítania a HTML-t, hanem csak lecserélni a megfelelő részeket az oldalon a letöltött fragmentekkel.

Szóval nem értem teljesen mit akarsz mondani ezzel a "dinamikus tartalombetöltés != kliens oldali rendering"-es dologgal. Persze hogy nem az, de ilyet senki nem is állított. Az egy architekturális kérdés, hogy JSON-t töltsön le csak a kliens vagy már összepakolt HTML-t. Mindkettőnek van előnye/hátránya. Ha egy SPA mögött nincs is saját backend szerver, hanem csak egy külső API-t ér el, akkor egyértelmű, hogy minden sablon kliens oldalon lesz komponensekbe csomagolva.

 

Elég ráereszteni pár find/replace kombót.

Tényleg hasonlít a CSS-re, de mi van a HTML-lel? Azt mintha le kéne cserélni a Qt-s ekvivalens komponensekre, így visszajutottunk oda, hogy két kódbázist kell karbantartani. Ha erre nincs kapacitása a fejlesztőnek, akkor nem fog ezzel foglalkozni, ha az Electron-os változat "elég jó".

 

A JS-t meg elméletileg a DOM fa csesztetésére, de leginkább úgy hányták össze, ahogy épp gondolták és leginkább semmire se jó. Semmire se.

Hát, minden indult valahol. :)

 

Jól rommá is perelnének, teljes joggal.

Nem a konkrét céges oldalra gondoltam, hanem az alacsony szintű, általános komponens-gyűjteményre.

 

Dehogy fogják. Szembemegyek minden paradigmával, amit a webkettő diktál.

Így születnek az újdonságok, nem te lennél az első, aki paradigmaváltást hoz a weben.

 

akkor megkapom, hogy de ezt nem így kell csinálni

Ez nekem inkább úgy tűnik, hogy toxikus helyen dolgozol. Ha kitalálsz egy jobb dolgot, amivel spórolni lehetne szervereken, azt be kéne inkább építeni a kódbázisba.

 

Hogy szabadulunk meg a webes technológiáktól, ha a motorok eljutnak oda, ahova mondod?

Én nem akarok megszabadulni a webes technológiáktól. Ha meglenne a gyári Electron alternatíva, akkor tök mindegy lenne, hogy mivel írták meg az adott programot, annyi erőforrást enne, mint bármi más.

 

Gondolom, hogy a többieket meggyőzd, hogy a trécéhá egy laggard, aki szerint régen minden jobb volt, alien a haladás.

Abban tévedsz, hogy bárki más is követi ezt a szálat. :D

 

Bár ki tudja, lehet tévedek és csak a topicot akarod szétoffolni.

Bocs, abbahagyom. Tévesen feltételeztem, hogy akarsz ilyenekről beszélni. Távol álljon tőlem más idejét fölöslegesen rabolni.

 

először a HTTPS-sel

Írd fel a bűnlajstromomra, hogy megpróbáltam segíteni egy fórumtársnak, hogy meg tudja nézni a posztodba berakott képeket.

 

És ebből a tapasztalatból mennyit szereztél a konzumer szférában és mennyit tudományos projektekben?

A "konzumer" webfejlesztői tapasztaltaimat vittem át inkább az alapkutatásba. Pl. az egyetem alatt még LaTeX beamerrel készítettem az előadásaimat PDF formátumba. Aztán pár év múlva átálltam https://revealjs.com/ alapra ami egy HTML5 oldal + JS lépegetés + MathJax + videók kombó. Ez nekem tökre bevált. Fent van az összes előadásom egy tárhelyen, bárkinek bárhol meg tudom őket mutatni, csak kapja elő a mobilját/laptopját. Animációt PDF-be berakni kínkeserves, HTML5-be triviális manapság. Amikor konferencián előadtam, csak megnyitottam egy böngészőt, bepötyögtem a címet, fullscreen F11-gyel és kezdhettem is.

Webfejlesztéssel ~10 évvel hamarabb kezdtem el foglalkozni (még középiskolásként), minthogy meglett volna a fizikusi diplomám. Pár évig éltem belőle szabadúszóként.

Igen és igen. Sőt, még PHP Nuke-ot is az IE6-os sötét korszakban, aztán Drupal 5-6-7, tovább nem mentem PHP vonalon. Smarty nem igazán jött be, a Twig/Jinja/Django típusú template rendszer jobban kézre esik.

Bárcsak egyszer elefántcsonttoronyban dolgoznék, megtudnám milyen az. A második világháború után 5 évvel felhúzott épületet nagyon nem nevezném annak. :D

Akkor meg végképp érthetetlen, hogy szerinted nem tűzrevaló az egész, úgy, ahogy van, ha egyszer láttad, hogy mekkora rakás szar az egész.

A kijelző fogyasztja általában a legtöbbet. Egy weboldal nem járatja folyamatosan a CPU-t.

Egyszer nézz meg egy heavyweight JS-es weboldalt, hogy hány szállal pörgeti a háttérben a CPU-t.

Itt valahogy nagyon elbeszélünk egymás mellett. Egy jól megírt SPA szerves része a kliens oldali HTML összepakolása a dinamikusan letöltött JSON (vagy akármi más) tömbök alapján, erre vannak a komponensek. Egy komponens előállítja az adatok alapján a HTML-t, amit az SPA bepakol a megfelelő helyre és a böngésző végül megjeleníti a tartalmat. Egy komponenst egyszer kell csak letölteni a szerverről ezután a kliens oldali JS tudni fogja, hogy az adatok alapján milyen HTML-t kell gyártania. Emiatt ha a látogató navigál az oldalon, csak a nyers adatokat kell lekérdeznie a szerverről, a template már ott van a cache-ben lévő komponensben. Az SPA csak azt a tartalmat fogja lecserélni az oldalon, ami változik, nem kell újrarenderelnie a böngészőnek ezáltal a teljes oldalt, ezáltal jóval gyorsabb is lehet.

De nem lesz gyorsabb, mert az egy darab insertAdjacentHTML vagy innerHTML gyorsabb lesz, mint a kétszázötven sorból álló JSONToObjectListToNodeTree builder. És már megint kevered a dinamikus betöltést a kliensoldali renderrel. Nem az a baj, hogy nem kell újrarenderelnie az egész oldalt, hanem, hogy a cserélendő részt hogyan rendereli le. Még mindig nem a dinamikus betöltéssel van bajom.

Szóval nem értem teljesen mit akarsz mondani ezzel a "dinamikus tartalombetöltés != kliens oldali rendering"-es dologgal. Persze hogy nem az, de ilyet senki nem is állított.

Mégis keveritek.

Tényleg hasonlít a CSS-re, de mi van a HTML-lel?

Ott a QML. Nem lehet akkora kunszt átkonvertálni.

Ha erre nincs kapacitása a fejlesztőnek, akkor nem fog ezzel foglalkozni, ha az Electron-os változat "elég jó".

De az Electron nem elég jó, sőt egyáltalán nem jó.

Nem a konkrét céges oldalra gondoltam, hanem az alacsony szintű, általános komponens-gyűjteményre.

Abból szoktam néha-néha publikálni egy-egy darabot BGAFC-n, vagy oscompon, de ilyenekből borítva van a net.

Így születnek az újdonságok, nem te lennél az első, aki paradigmaváltást hoz a weben.

Biztos baromi népszerű lennék a JS kiirtásának kísérletével...hatvannyolcezer felbőszült webkettő hívő esne nekem per nanoszekundum, hogy bántom a vallásukat.

Ez nekem inkább úgy tűnik, hogy toxikus helyen dolgozol. Ha kitalálsz egy jobb dolgot, amivel spórolni lehetne szervereken, azt be kéne inkább építeni a kódbázisba.

A melóhelyi kollégák még hagyján voltak (bár volt pár érdekes eset, mint pl. az, aki szerint PHP-ban a globális változó tervezési hiba, vagy az, aki szerint a jövőben nem kell majd CPU, mert ott a jávaszkript...), de a neten hittérítő webkettősök...

Én nem akarok megszabadulni a webes technológiáktól.

Nem mondtam, hogy te akarsz megszabadulni tőlük; én akarok megszabadulni tőlük. Te azt erőltetted, hogy legyen egy konzisztens webes rendermotor ugyanarra a célra, hogy leválthassuk az Electront, én meg próbáltam rákérdezni, hogy azzal hogy szabadulunk meg a webes alapú renderingtől; azaz, hogy cseberből vederbe. Nem kéne webes alapon programokat építünk, mert nem arra való.

Abban tévedsz, hogy bárki más is követi ezt a szálat. :D

Én? Már az elején megmondtam, hogy "Már mindenki lelépett rajtunk kívül.".

Bocs, abbahagyom. Tévesen feltételeztem, hogy akarsz ilyenekről beszélni. Távol álljon tőlem más idejét fölöslegesen rabolni.

Pedig megmondtam a legelején, hogy nem akarok belemenni, mert te már eldöntötted, hogy mit akarsz hinni.

Írd fel a bűnlajstromomra, hogy megpróbáltam segíteni egy fórumtársnak, hogy meg tudja nézni a posztodba berakott képeket.

Ne csúsztass. Én nem erről az egy szál posztodról beszélek, ahol segítettél valakinek, hanem az utána következő szálról, ahogy utána kötötted az ebet a karóhoz.

A "konzumer" webfejlesztői tapasztaltaimat vittem át inkább az alapkutatásba.

Erre már fentebb válaszoltam, hogy ez esetben érthetetlen, hogy miért fogja valaki a webhulladék pártját, ha látta, hogy milyen belülről.

az oprendszerek gyártóinak kellene egy konzisztens HTML render motort gyárilag leszállítani és akkor nem kéne Electront használni

PWA-kat támogatják a nagyobb app store-ok (Apple, Google, Microsoft), itt egy cikk hogyan. Szerk: úgy tűnik Apple annyira azért mégsem.

Nem itt fent panaszkodtak páran, hogy a képeid nem látszanak náluk, mert a https hup tartalom mellé a http képeket a böngésző nem tölti be?

Szóval hogy miért gáz: azért, mert előfordulhat bármikor, hogy valaki linkelni akarja, ha már publikusan elérhető, és ez simán lehet, hogy nem működik a titkosítás hiánya nélkül.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ahol nincs mit titkosítani, ott minek titkosítani?

Ezt az érvet megértem és elfogadom.
Amiért mégis érdemes titkosítani, az a böngészők köcsögölése. Érezhető a törekvés a google és a mozilla részéről, hogy az egész webet ssl alá tegyék.
Mióta van let's encrypt és gyakorlatilag ingyen és automatizáltan tudok certet igényelni és megújítani, én beadtam a derekam.

Egyébként nem csak a titkosítás fontos, hanem az authentikálhatóság is: hogy ellenőrizhető legyen, tényleg az a tartalom érkezik-e meg, amit Te feltettél (senki nem mókolt vele útközben).

Jó, ezt aláírom én is, már mondtam is, hogy ha rajtam állna, akkor megcsinálnám, csak, hogy a folyamatos pampogás megszűnjön, de nincs hozzáférésem.

Az MITM lehetőségét viszont nem tudom elfogadni a HTTPS melletti érvként ameddig:
  a) ha gyakorlatilag bárki, akinek a certjét elfogadtad, játszhat MITM-et (internetszolgáltatók és driverek (!) előnyben),
  b) elég a hulladék key-exchange segítségével összeszedegetni a kulcsokat a crackhez,
  c) magát a HTTPS-t is törték már meg nem egyszer,
  d) az egész cert-authority és cert-credibility ökoszisztéma egy rossz vicc.

Valóban vannak az ökoszisztémának gyenge pontjai (a CRL-t még hozzátenném), de látni kell a mitigation-öket is, mint pl. a HSTS vagy az OCSP stapling.

Szerintem olyan nincs, hogy magát a https-t megtörték. Legfeljebb az SSL/TLS valamelyik verzióját, vagy valamelyik implementációt (PRNG körüli balhék szoktak lenni, esetleg valamilyen side channel attack).
Az igaz, hogy egy szar szerveroldali konfig simán lehetőséget nyújthat erre. De ez nem általános és nem törvényszerű.

A Let's Encrypt sima domain validation cert-et ad, ami nyilván nem nyújt olyan védelmet MITM ellen, mint egy EV cert (amit nem adhat ki gyakorlatilag bárki). De itt már valamilyen attack-re legalább szükség van a hostod ellen, hogy megvalósuljon a MITM.

Valójában teljesen mindegy, hogy mit gondolunk mi erről. Gyakorlatilag alig lehet már megnyitni sima http-t mainstream böngészőből és akkor is villognak a warning-ok. És ez valószínűleg nem javulni fog. Pagerank is lejjebb sorolja az oldalad, büntetik mindenhol, ahol csak lehet. Szép fokozatosan szorul a hurok.

És mi értelme, hogy mitigálunk egy olyan ökoszisztémát, ami számos ponton törött, ahelyett, hogy mást használnánk, pl. titkosított VPN-t? Mármint azon túl, hogy a VPN-t bármilyen browserrel lehet használni, míg az új titkosítási protokollokat és ciphereket csak az új browserekkel, azaz, ha a többség által használt browserek megkövetelik ezeket, akkor ezáltal a website-ok adminjaitól kikényszerítik a latest titkosítási technológiák használatát, azaz ki lehet tiltani a régebbi böngészőket a netről, amik még nem kémkednek a júzer után és nem szabják meg, hogy mit nézhet és akkor ki tudják kényszeríteni a latest - kémkedő és korlátozó - browserek használatát mindenkitől.

A HTTPS csak a "konténer", annak a titkosítása akkor van megtörve, amikor az adott SSL/TLS verziót megtörték, vagy megkerülték, erre pedig volt már precedens.

És itt a probléma másik fele, hogy nem adhat ki gyakorlatilag bárki. Amíg ez csak opció, addig igazából mellékes, de ha a browserek ezt is elkezdik megkövetelni és a Let's Encrypt és a self-signed is tiltva lesz, akkor gyakorlatilag tökönlőtték a net-neutrality-t, hiszen akinek nincs pénze a certre, annak nem lesz website-ja sem, mert az új browserek nem nyitják ki, a régieket meg letiltották a netről. Na persze mehet a felhőbe, ami viszont nem az övé, akkor teszik, ki, amikor akarják, azaz amikor olyan lesz a weblapján, ami az uralkodó pénzügyi köröknek bármilyen érdekét sérti.

Igen, ez sajnos így van, legalábbis az újkori browserekkel. Persze lehet használni Squidet és hasonlókat, de a többség nem fog. A cél a net feletti totális uralom, csak az kerülhet fel és azt láthatja a jónép, amit a pénzemberek akarnak.

Ennyire azért nem vagyok borúlátó. A https-t érintő törések nagyrésze protocol fallback-re épül.

VPN-t imho nem tudnál ilyen szinten használni, legalábbis minden böngésző session-nek vagy fülnek külön konténerben kellene futnia natolt környezetben, hogy egyenként tudj VPN kapcsolatokat létesíteni a szerverekkel.

A Let's Encrypt-et nem cél tiltani, sőt, éppen azért jó, mert bárki tud csinálni valid cert-et, ami nem self-signed (ami ugye semmi).
Itt legalább az ellenőrizve van, hogy valóban diszponálsz-e a domain fölött és mivel három hónap a lejárati/megújítási idő, nem is ragadnak bent sokáig az abandoned cert-ek.
Szerintem nem ördögtől való ez, hogy legyen kriptó és autentikáció a forgalmon. Plaintext forgalmat támadni vagy sniffelni tulajdonképpen még erőfeszítésbe sem kerül.
Egyetemista koromban pl. wifi sniff + stringdump-ban simán láttam, mit beszélget a szomszéd kiscsaj msn-en. Ezt azért szerencsére már magunk mögött hagytuk.

A https kezd mature lenni, ha nem kúrod el a szerver oldali konfigot, akkor azért van esély jól csinálni.
Sokkal égetőbb probléma szerintem a DNS autentikációja, ami ráadásul UDP felett megy és simán spoofolható.

Abban teljesen együttérzek Veled, hogy szintén sajnálom, hogy ide jutottunk. Szép volt a netkorszak hajnalán, hogy minden egyszerű volt és letisztult, ma meg elkeserítő, mi mindenre fel kell készülni. De azt a világot magunk mögött hagytuk. Sajnos.

Nemrégiben a következő dilemmán gondolkodtam: régen volt anonimitás a neten, mára ez gyakorlatilag megszűnt. Nem tudsz már egy email fiókot sem létrehozni a személyazonosságod felfedése nélkül. Próbáld csak meg tor mögül, legtöbb szolgáltató rögtön telefonszámot kér. Amit megint csak nem tudsz már személyazonossághoz kötöttség nélkül birtokolni.
Ez számomra, mint jóhiszemű ember, gáz.
Ugyanakkor láttam azt is, hogy kevésbé jószándékú emberek hogyan éltek vissza az anonimitással.
Eljutottam arra a pontra, hogy nem tudom, mi a megoldás.

Az értékrendemben alapvető helyet foglal el a szabadság és a privacy, és alapvetően elutasítom a nyomkövetés és megfigyelés minden fajtáját. E mellett ha nem is értek egyet vele, de megértem, hogyan jutottunk el ide, ahol tartunk.

Nagyon jól látod, a világot a pénz és a marketing mozgatja. De szerencsére még vannak szigetek, ahová a conscious ember menekülhet. Szeretnék abban bízni, hogy ez megmarad.

Tudod az a gond, hogy a népesség túlnyomó többsége tisztában sincs ezekkel a problémákkal, kérdésekkel, dilemmákkal. Meg sem értik, miért fontosak ezek. Legtöbb ember lusta már olyasmivel foglalkozni, ami nem megzabálható, elfogyasztható. Ez együtt jár az ember alaptermészetével. Megfelelő oktatással, neveléssel lehetne rajta változtatni, amiben szerintem piszkosul el vagyunk maradva.

Számít mire épül a törés? Egyébként is a törés csak egy probléma. A key-exchange sérülékenysége egy másik drasztikus probléma. A certek pedig önmagukban alkalmatlanok bármilyen garanciára, amikor gyakorlatilag akárki állíthat elő, vagy hamisíthat certet, a CA-k pedig korruptak/korrumpálhatóak (ha nem így lenne, nem lenne Certificate Patrol sem).

Ez attól függ, hogy a különféle szerverek külön-külön VPN-eken találhatóak-e, vagy sem. De még ha a válasz igenlő is, ha igazi biztonságot és szabadságot akarsz, az kompromisszumokkal jár. Az, hogy a jócégek majd mindent megoldanak, az egy nagy kamu.

A Let's Encrypt-et pont azért lehet cél majd tiltani a közeljövőben, hogy ne tudjon mindenki certet csinálni. A bootloaderek aláírási mizériája mi célt szolgálhat? Ugyanezt, pepitában. A techcégek akarják eldönteni, hogy mit rakhatunk a gépünkre, mire használhatjuk azt, mit nézhetünk meg vele az interneten, sőt azt is, hogy az interneten mi lehet.
Ha nem wifit használ az ember, azt hogy sniffelik? (Nem, nincs okostelefonom.)

A HTTPS kb. úgy, ahogy van, fundamentally broken. Hogy a DNS auth-tal problémák vannak, az lehet, de nem negligálja a HTTPS-sel kapcsolatos agyhalálokat. A HTTPS azért nem megoldás semmire sem, mert az egész trust faktorja a certekre épül, márpedig a certek alkalmatlanok a trusted networkingre, mert ha bárki csinálhat certet, akkor az egész annyira megbízható, mint egy tisztességes windóz, ha meg csak adott cégek csinálhatnak, akkor meg onnantól kezdve azok a cégek döntik el, hogy kinek van joga a neten weblapot publikálni.

Egyébként lehet még személyazonosság nélkül emailfiókot létrehozni, csak olyan szolgáltatót kell keresni; a ProtonMail pl. ilyen. Tőlem nem kért telefont. Ha kért volna, azon nyomban ott is hagytam volna. Még egyetlen helyen sem adtam meg a telefonszámomat, ahol kérték.
(Egyébként állítólag lehet még venni "eldobható" SIM kártyákat.)
A megoldás pedig az, hogy ellenállsz a techcégek szemétdömpingjének, amennyire tudsz, alternatívákat keresel és ahol megpróbálnak profilozni, személyes adatokat kicsikarni, onnan lépni kell. Nyilván előferdülhet, hogy nem megkerülhető, sajnos, de ott is akkor minél kevesebbet, pl. telefonszámot, fényképet sohasem...

A prolik régen is szartak bele az egészbe és akkor sem lehetett neveléssel változtatni rajtuk. Ez szerintem emberfüggő. Nagyon kevesen mozoghatnak pont a határvonalon, vagy annak a közelében, hogy át lehet őket lendíteni a "nem-proli táborba". De nem vagyok szociológus, úgyhogy ezt kéretik szigorúan csak sejtésként kezelni.

Igen, számít, mire épül a törés.

Tisztában kell azért lenni azzal a tradeoff-fal, hogy nem lehet mindig a tökéletes megoldást keresni. Mert minél tökéletesebb a megoldás, annál több ,,kompromisszummal" jár és annál kevésbé fog elterjedni a megoldás. Azt a legjobb már adekvát biztonságot nyújtó megoldást kell szerintem alkalmazni, ami már széleskörűen el tud terjedni.

Volt példa olyanra, amikor mondjuk a Symantec bukta a CA üzletágát, mert tömegesen fosták ki a megbízhatatlan cert-eket (asszem végül megvette tőlük a VeriSign). De ez is kiderült és azonnal felléptek ellenük.

Alapjában véve nem az a lényeges, hogy a Let's Encrypt-en keresztül bárki igényelhet cert-et. Az a fontos, hogy a Let's Encrypt által nyújtott domain validáció mennyire megbízható. Pont az általad is említett félmonopol helyzet enyhítésére (is) hozták létre.

A nagyobb megbízhatóságot követelő helyekre (pl. banking) meg ott az EV cert. Azt nem csinálhat bárki, és bele vannak drótozva a böngészőkbe a jogosult CA-k, nem lehet spoofolni, nem tud trükközni a munkáltató tűzfala sem.

Kerülön én is a mainstream dolgokat, mint pl. facebook, de van egy csomó olyan dolog, ami ellen nem tudsz tenni. Pl. a köztéri kamerák. Hiába veszel fel infravisszaverő szemüveget, az autód rendszámát akkor is látni fogják és a mozgásod elemzésével is fel tudnak ismerni. Valamint a ,,buta" telefon helyzetét is folyamatosan logolja a szolgáltató.
Hiába használsz protonmail-t, ha gmail-esekkel levelezel. Egyszer elérkezel a tökéletes rendszerbe, csak gyakorlatilag nem lesz ott rajtad kívül senki.
Szerintem sem így kellene lenni egy csomó mindennek, csak észre kell venni, hogy ezeknek a dolgoknak jelentős része kívül esik a cirle of control-on, és inkább a circle of concern-be tartozik sajnos.
Nem tudsz mindent elkerülni, kivédeni. Persze ettől még gondolkodni kell és ésszerűen döntéseket hozni, de mindent a helyén kell kezelni. Csak a saját körödön belül mozoghatsz. Én azt szeretném, ha minél tovább létezne ez a kör és minél nagyobb lenne.

Én sem vagyok szociológus, de szerintem az oktatás és nevelés nagyon fontos. Kisgyermek korban elkezdve lehetne magasabb tudatossági nívóra hozni a gyerekeket, hogy ne csak otthon lássák a proli szülők példáját. Nyilván mindenkinél nem fog ez se működni. De ugye tudjuk, hogy az életben nincs igen és nem; csak valószínűségekről és eloszlásokról lehet beszélni. És egy eloszlást el lehet szerintem tolni annyira, hogy bizonyos dolgok szignifikánssá váljanak.

All in all, szerintem az nem érv a https ellen, hogy hát ez sem tökéletes. A plaintext-tel szemben mindenképpen fényévnyi előrelépés.

Megjegyzem, nem a Te speciális esetedről és hostingodról beszéltem egyik hozzászólásomban sem, csupán generálisan az enkripsön vs. no-enkripsön témáról.

Nem tökéletes megoldásról beszélünk, mert olyan nincs, de a HTTPS nemhogy nem tökéletes, hanem képtelen ellátni a feladatát. Csak felrakod a kukkolni kívánó entitás certjét és abba néz bele, amibe akar. Az elterjedés meg a mi szempontunkból mellékes, hiszen a HTTPS-t sem a laikusok találták ki és terjesztik.

Szerintem a Let's Encryptes rész holtpontra jutott. Te azt mondod, hogy nem akarják blokkolni, én azt mondom, hogy a közeljövőben várható, hogy nem fogják a browserek elfogadni. Reméljük, hogy én tévedek.

A browserbe meg semmiféle CA sincs "bedrótozva"; remélem azt te is érzed, hogy amikor a browserek forrása szabadon elérhető, akkor kb. azt rak bele az ember, amit akar, vagy azt vesz ki belőle.

A ProtonMail nem csak a gmailnek tud levelet küldeni, azonfelül ha a ProtonMail sem tudja, ki vagyok, akkor a gmail se fogja tudni. Autóm nincs. Budapesten baromi keveset járok. (És a köztéri kamerák felvételeit nem látják a nagy tech cégek.) A butatelefon helyzetének loggolásáról meg annyit, hogy a butatelefonok helyzetlogja az alkalmasint akár többszáz négyzetméteres területet felölelő cellák információira korlátozódik, míg az okostelefonok méteres pontosságú nyomkövetést tesznek lehetővé, de ami még fontosabb, hogy a butafónok cellainformációit és a beléjük dugott SIM kártyákhoz tartozó személyes adatokat csak a szolgáltató látja, míg az okostelefon pontosan tudja, hogy ki vagy és direktben a nagy techcégeknek jelent és annak adják el az adataidat, akinek akarják. Azonfelül a butafón nem hallgatózik folyamatosan.

Az lehet, hogy az eloszlás határait lehet tologatni, csak azt felejted el, hogy nem egyedül tologatod őket. Amikor a pénzembereknek az az érdeke, hogy minél több hülye proli legyen, akkor erőlködhetünk itt a neveléssel, ha közben a fosbúkról, meg a szartéelklubból ömlik rájuk a populáris fos...de ez már offtopic. (Bár igazából az egész HTTPS is az volt.)

A HTTPS-sel meg mint mondtam, nem az a baj, hogy nem tökéletes, hanem en-bloc, alkalmatlan arra a célra, amire alkalmazzák.

Én is az enc-noenc témáról beszéltem. És nem is arról van szó, hogy noenc-FTW, hanem arról, hogy nem mindegy, hogy mit, hogyan és miért titkosítunk.

Az MITM lehetőségét viszont nem tudom elfogadni a HTTPS melletti érvként ameddig:
  a) ha gyakorlatilag bárki, akinek a certjét elfogadtad, játszhat MITM-et (internetszolgáltatók és driverek (!) előnyben),

Hát, nem tudom. Ez mennyire gyakori nálatok?

Én nem emlékszem, hogy valaha ISP tanúsítványát el kellett volna fogadnom bármilyen célból.

Hasonló dologgal egyedül céges hálózaton céges laptopot használva találkoztam, ahol a céges laptopra a céges IT feltette a saját tanúsítványaikat, és ezt használva a céges tűzfal ki tudta bontani és elemezni tudta a titkosított kapcsolatokat is.

De a magán laptopomat akárhol használva, vagy a cégeset nem a cégnél, ez már nem játszott.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Mi ez a többes szám? Mire vonatkozott a többes szám?

Ugye leírtam, hogy _nálam_ mi a helyzet.

És arra vagyok kíváncsi, hogy az összes többieknek, akik nem én vagyok, azoknak mi erről a tapasztalata. Pl. neked, meg mindazoknak másoknak, akik épp erre járnak és olvassák ezt az oldalt.

Nálam windows sincs, így engem speciel nem érint.

Miért függ az operációs rendszertől? Nem tudom, milyen OS-t használsz, én Linuxot, és Linux alatt az összes eddig próbált böngészőben volt lehetőségem tanúsítvány elfogadására. Pl. ha a NAS-omat piszkálom, akkor rögtön jön a kérdés, hogy self-signed, mi legyen. Ki tudom választani, hogy ezt fogadjuk el.

Vagy windows alatt kötelező elfogadni az ISP tanúsítványát?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

> És arra vagyok kíváncsi, hogy az összes többieknek, akik nem én vagyok, azoknak mi erről a tapasztalata. Pl. neked, meg mindazoknak másoknak, akik épp erre járnak és olvassák ezt az oldalt.

Hát akkor nagyon kriptikusra sikeredett; ha nekem címzed, akkor jelezned kéne, hogy mindenkinek szól...

> Miért függ az operációs rendszertől?

Mert a többi alatt nem túl gyakori, hogy zárt 3rd-party drivereket rakj fel. A macOS dedikált HW-en fut és az OS már alapból ismeri a gépet, a Linux/BSD/Solaris alapú cuccok alá meg ritkán szoktak a hardwaregyártók drivereket kiadni, általában vagy tudja az OS OOB, vagy valami nyílt forrású pótlék van. windows alatt viszont az az alap, hogy a hardware-hez feltelepítgeted a 3rd-party drivereket.

windows alatt viszont az az alap, hogy a hardware-hez feltelepítgeted a 3rd-party drivereket

A legtöbb esetben megteszik a WHQL driverek amiket a Windows Update-tel telepít a rendszer. Egyéb 3rd party szutyok leginkább csak akkor kell ha szükséged van a driverrel szállított beállító utilityre (pl. GPU driverek), de ez is egyre kevésbé probléma (lásd DCH).

Szerintem inkább attól függ milyen jellegű hardver. Nem foglalkozom napi jelleggel ilyesmivel, de az utóbbi ~tíz évben azon a pár gépen, amit én tartottam karban a Windows telepítése után gyakorlatilag minden hardver működött, volt hálózat (vezetékes és vezeték nélküli), hang, grafikus gyorsítás, mentek az energiahatékonysági dolgok, a kártyaolvasó, touchpad, stb. Ahol el tudom képzelni, hogy nem ilyen egyszerű a helyzet, az a nyomtatók, scannerek, egyéb nem szabványos perifériák, de ilyesmivel évek óta nem volt dolgom.

> A hozzászólásodban, amire válaszoltam?

Mondtam, hogy kötekedni akarsz. Olyat nem írtam, hogy "kollektíven mindenki".

> "A mai programozóvilág baromi rossz irányba tart". Nem azt írtad, hogy egy csoportja (mondjuk a két havonta új JavaScript framework-öt írók), hanem az egész világ.

Ezt hívják belemagyarázásnak. A "világ" az egy generikus kategorizálás, azt jelenti, hogy "általában" és nem azt, hogy "mindenki".

> Ha ilyen sarkalatos megjegyzést teszel, mint a viccben a "mindenki hülye, csak én vagyok helikopter", akkor nem ártana kicsit kifejteni, hogy mire gondolsz.

Hol hülyéztem le mindenkit? Hol ajnároztam magamat? Ezt hívják szalmabábcséplésnek.

Hovatovább itt máris sikerült magadat egy csinos önellentmondásba keverni, azzal kapcsolatban, hogy szerinted mit állítottam:
1.: Azt az állítást adtad a számba, hogy kollektíven minden programozó rossz irányba megy, márpedig a "minden programozóba" én is beletartozom, tehát azt állítod, hogy az én véleményem szerint én is rossz irányba megyek.
2.: Ugyanakkor az állítást is a számba adtad, hogy szerintem mindenki hülye, csak én vagyok helikopter, azaz mindenki rossz irányba megy, kivéve engem.

Tehát azt mondod, hogy szerintem mindenki hülye, beleértve engem is, de kivéve engem.
Ebből is látszik, hogy ez a szalmabábcséplés amit csináltál, ez közönséges provokáció volt, mert nem tetszik a véleményem.

Egyébként kinek kellett volna kifejteni? pinknek, akinek mondtam? Ő érti kifejtés nélkül is. Neked, aki triggerelődvén belekötöttél abba, ami el sem hangzott? Élek a gyanúperrel, hogy te kifejtés nélkül sem értenéd, mert nem akarod érteni. A többieknek? Már mindenki lelépett rajtunk kívül.

> Félig-meddig programozó is vagyok (fizikai szimulációk kódolásával lett doktorim), így beletartozom a "programozóvilágba"

Jó neked. Én meg 2-3 évesen írtam az első BASIC programomat C128-on. Na, mi számít nagyobb P-pénisznek; a fizika doktori, vagy az ovi előtt megírt első program?

Egyébként meg azt mondod: "fizikai szimulációk kódolásával lett doktorim". A kóder és a programozó nem ugyanaz. Lehet valaki jó kóder és rossz programozó és vice versa.

> légy szíves fejtsd már ki, hogy mit csinálok rosszul.

A provokációt.

> És ezt most csak félig írom ironikusan, mert egyébként tényleg érdekel, hogy mit gondolsz.

Dehogy érdekel. Magasról teszel a véleményemre. Sérti a világnézetedet.

> Ha csak panaszkodsz, de minimálisan se fejted ki a panaszod tárgyát, azzal nem lesz előrébb senki.

Azzal sincs előrébb senki, ha szalmabábcsépléssel provokálod azt, akinek nem tetszik a véleménye.

Ehh, veled tényleg nem lehet vitázni, túl érzékeny vagy hozzá, ahogy azt gee is kifejtette egy másik topikban. :)

 

Magasról teszel a véleményemre. Sérti a világnézetedet.

Honnét tudod, hogy mi az én programozói világnézetem? Odáig el sem jutott a szál, mert amikor azt kérdeztem, hogy mi a bajod a mai programozó világgal, csak kitérő választ adtál. Szóval még azt sem tudom, hogy mi a te véleményed. De szerinted nekem nem tetszik a véleményed... amit még el se mondtál. Oké. Hagyjuk ezt, így semmi értelme.

> Ehh, veled tényleg nem lehet vitázni, túl érzékeny vagy hozzá, ahogy azt gee is kifejtette egy másik topikban. :)

Rögtön azzal nyitottál, hogy olyat adtál a számba, amit én nem mondtam és velem nem lehet vitázni? Te triggerelődtél egy olyan generikus mondattól, hogy a programozói világ rossz irányba megy és én vagyok érzékeny?

> Honnét tudod, hogy mi az én programozói világnézetem?

A megnyilvánulásodból. Abból, ahogy rögtön szalmabábcsépeléssel indítottál, megpróbáltad azt a látszatot kelteni, mintha én tényleg azt hinném, hogy rajtam kívül mindenki hülye.

> Odáig el sem jutott a szál, mert amikor azt kérdeztem, hogy mi a bajod a mai programozó világgal, csak kitérő választ adtál. Szóval még azt sem tudom, hogy mi a te véleményed. De szerinted nekem nem tetszik a véleményed... amit még el se mondtál. Oké. Hagyjuk ezt, így semmi értelme.

A véleményemet meg pontosan ismered. Nem most futunk itt össze először. Nem egyszer fejtettem már ki, többek közt neked is. Még ebben a topicban is rászántam pár sort. Ennyit erről.

A WHDLoad projektet ismered?

Sajnos egyáltalán nem vagyok képben, hogy mi zajlik manapság Amiga fronton.

Kb. 1995-ig kitartottam, pl. amikor édesapám felajánlotta, hogy PC-t vesz nekem, mondtam, hogy az nekem nem kell, és vettem saját pénzen A1200-at az A500 után, de aztán 95-ben már munkához kellett egy PC, szóval vettem egyet valahogy nyáron. Ment rá Win95, aztán december körül Linux, aztán azóta ez van. PC+Linux. Az Amigát eladtam és azóta nem foglalkoztam a témával.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Mindegy, csak azért hoztam elő, hogy alátámasszam: a játékok elsöprő többségét meg lehetett volna rendszerbarát módon is írni.
A játékok nagyrészének a megvalósítása volt trehány, felfelé nem kompatibilis módon volt megírva, pedig az Amiga OS az API-jával brutális hordozhatóságot biztosított a gépcsaládon belül; még a hírhedt KickStart 1.3 -> 2.0 váltás se önmagában volt akkora compatibility-impact, hanem a kóder urak szerettek direkt címekre ugrálni a ROM-ban, ahelyett, hogy az API-t, vagy legalább az ugrótáblát (!!!) használták volna. A többi törésvonal (24-bites címbusz -> 32-bites címbusz, OCS/ECS -> AGA, Floppy -> HDD) meg aztán szinte mind a kivitelezés sara volt, hacsak nem futott az ember bugra az OS-ben, de azokat meg szorgalmasan javítgatták az új release-ekkel és a SetPatch programon keresztül.

a kóder urak szerettek direkt címekre ugrálni a ROM-ban

Ezzel a HP 48GX...49g...50g vonalon szoptam. Ezeket a számológépeket bár lehet assembly-ben is programozni, érdemesebb RPL-ben, azaz Reverse Polish Lisp-ben, mert így rendelkezésedre áll minden matematikai és ui funkció.
RPL-t lehet használni scriptként (UserRPL) illetve compiled módon (SystemRPL). A számológépen van egyébként beépített assembler/disassembler és RPL compiler/decompiler is (jobban mondva a régiekre külön fel kellett tenni; az én 50g-men már beépített).

Voltak supported és unsupported utasítások. A supported azt jelentette, hogy nem változik a címe az egyes ROM verziók között. Unsupported-ek általában nem is voltak dokumentálva, hanem valami másnak a segédeljárását használta ilyenkor a kóder, vagy egyszerűen beleugrott egy eljárásba in medias res (nem az elejénél). Az utasítások ugyanis memóriacímek voltak, amikhez tartozott egy leírótábla, ez adott nekik nevet (így fel tudtál bele venni tetszőleges új ROM címeket, ami tetszett - a megfelelő tábla hiányában ezeket "PNTR 57962"-szerű utasításokká fordította a decompiler). Érdekesség, hogy adatot bevinni több ciklus volt, mint utasítást hívni - ezért a gyakran használt számoknak volt külön utasítása, ami egyszerűen stack-re tette az adott számot és ez sokkal gyorsabb volt, mintha adatként adtad volna meg.
De voltak az egyes modellek között (pl. 49g és 50g) nüansznyi különbségek pl. a menet közben használt segédváltozókat illetően, amik szintén simán futtathatatlanná tudtak tenni egy programot a másik gépen.

Szimbolikus solver-eket portolgattam egy időben az 50g-re, ekkor futottam gyakran bele abba, hogy egész apróságon múlt az eredeti program hordozhatatlansága, és apró belegondolással generálisabban is meg lehetett volna írni, hogy alapból menjen a majdani újabb modelleken is.

Egyébként ha elkezd az ember használni egy RPN számológépet és megszokja, többé nem akar mást.

Hát valami hasonló ment az 1.X-es KickStartok használatánál is; induláskor ment a levesbe a rendszer, mert minek az oda, de utána a ROM-ok nem dokumentált címeire odaugráltak, mert tudták, hogy ott van egy adott rutin, vagy egy segédrutin és így kevesebb kódot kellett írniuk. Ami persze rendben lett volna, ha azt az ugrótáblával teszik, ahogy az le van írva a manualokban, mert így aztán a verzióbeli eltérések bizony címbeli eltéréseket is eredményeztek.

Csak a HDD-s részre reagálva, a másolásvédelem nem játszott közre? Ha lehet futtatni a játékot HDD-ről is akkor triviális másolni, viszont ha csak floppyról fut akkor vannak trükkök amivel ez megnehezíthető (persze a gyakorlatban ezeket rendszerint megtörték).

A floppyhoz kötött másolásvédelem nem zárja ki a DOS-os fájlrendszert és a HDD-re telepíthetőséget: a védelmi sávokat tartalmazó gyári lemezt akkor is bekérheti a játék egy pillanatnyi ellenőrzés erejéig, ha HDD-ről futtatják. (A crackerek egyébként mindent is megtörtek.)

Wow, 12 bites színmélység. Több ezer szín! Ennél több soha nem fog kelleni senkinek, majd meglássátok :D

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧