PDF-ben futó Linux

Egy nagyon nem normális pdf-be ágyazott JS-re fordított RISC-V emulátorban futtatott Linuxot, egy másik meg Doom-ot. Elismerésre méltó, de felhívja egy nagyon káros mai trendre a figyelmet. A modern formátumok túltervezettek, túl nagy komplexitást tesznek lehetővé. A pdf arra szolgálna, hogy dokumentumok mindenféle megjelenítőn és hordozón azonosan nézzenek ki, ne essen szét a formázás, meg ne torzuljanak a színek. Ehhez képest már formkezelést, 3D funkciókat, JS-tet, meg minden szart beletettek, aminek semmi köze nincs már az eredeti céljához, csak a felesleges bloatságot növeli, és esetleges biztonsági lyukat is képez, visszaéléseket bevonzva. Lényegében egy dokumentummegjelenítő nyelv a pdf, nem interaktív felület, meg Turing-képes futtatási platform.

Hála istennek a szög egyszerű xpdf, mupdf, Zathura nem is jeleníti meg ezeket, és ennek kifejezetten örülök, hogy csak statikus pdf-et lehet velük nézni, garantáltan egyszerűek és biztonságosak, nem futhat le rajtuk káros kód, nem ömölhet be a futtató rendszerre a bloat.

Ugyanez pepitában az Excel-ben emulált komplett CPU. Na, annak sincs már köze a táblázatkezeléshez. Szép mutatvány, de minek. Ahogy a böngésző se webalkalmazások futtatására lenne való, hanem weboldalakat böngészni, abból is statikus tartalmat, nem izgő-mozgó, zenélgető bannereket, meg JS hegyeket. Ezért van az, hogy a mai modern böngészők már rég nem is html-megjelenítők, hanem komplett, sandboxolt OS-ek, és az elsőfokú veszélyforrások a rendszerre nézve, mert kontrollálhatatlan kód fut rajtuk, és óriási bloatok is, aminek a mentén elavultatják a régi gépeket.

( hunludvig v | 2025. 02. 06., cs – 07:56 )

> garantáltan egyszerűek és biztonságosak, nem futhat le rajtuk káros kód

Ühüm

Ez ilyen. Látom nem értesz vele egyet, de komolyan írtam, és még mindig fenntartom. Nem is akarnám, hogy ezt tudja, meg ezek a JS szutykok lefussanak, csak felesleges extra bloat és biztonsági rés lenne. Sokszor a kevesebb több.

Nem véletlen, hogy a Unix filozófia is erre épült, hogy minden program csak egy dolgot tudjon, de azt jól, nem tömték tele funkcióval, azokat rábízták másik programra. Ez a mai napig így van, Linuxnál is még a DE-k, WM-ek modulárisak, te válogatod össze, hogy milyen dokk, milyen panel, milyen asztali téma, rendszerértesítéseket hogy oldod meg, X vagy Wayland, milyen hangszervert használsz, milyen initrendszer, milyen naplózó, milyen shell, stb..

Igazából te is egyetértenél, ha átgondolnád. Szerinted az ma szükséges, hogy minden szoftvert teletömnek webes szeméttel, reklámokkal, AI-vel, kémprogrammal, telemetriával, fél évente átdizájnolják a felületét, stb.. A lőtéri kutyának nincs erre szüksége igazából.

Sokszor még a hasznos feature-öket se kéne beletenni. Pl. Windowson minden program saját maga gondoskodik az update-ek megkereséséről, telepítéséről, de minek. Ezt egy kulturált rendszeren a csomagkezelőnek kéne intézni, hogy a rendszer és programfrissítéseket lehúzza az egységes tárolókból, a kiválasztott legközelebbi tükrök valamelyikéről. Cipőt a cipőboltból, ahogy a mondás tartja. Ennek alapján minden szoftvernek és formátumnak csak annyit kéne tudjon, amennyi feltétlenül szükséges az eredeti funkciója teljes nyújtásához. Enélkül az van, ami ma, minden szétbloatosítva, sok millió kódsoros projektek futnak, már a fejlesztők is kínlódnak, hogy a gigantikus kódbázis nem bírják átlátni.

systemd-vel is ez a baj, nem initrendszer. Eseményekre reagál (mondjuk csatlakoztattál egy hardvert), naplóz, felhasználókat kezel, stb., csak minek, lassan már egy komplett kernel a Linux kernel mellett. A hangrendszerek is épp így bloatosodnak, ALSA-ra jött a Pulseaudio, de már az se volt elég, itt a Pipewire, de abban is Pulseaudio modul fut, meg Wireplumber, de még videó/kamerasztreameket, képernyőmegosztás, stb.-t is kezel, csak minek, mikor egy HANGrendszernek nem ez a dolga.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

garantáltan egyszerűek és biztonságosak, nem futhat le rajtuk káros kód

Ilyet szerintem nem jelenthetsz ki semmire.

De teljesen egyet értek azzal amit írtál, ma minden hülyeséggel telepakolnak mindent is. A hajszárítóban is AI fog futni, és a fogkefe meg a cloudba ment, és streamel. Teljesen felesleges, és fájdalmas, de ezt a sok sz*rt arra használják, hogy ezzel próbálnak eladni dolgokat, követni a trendeket, vagy kémkedni, adatot lopni...

De, kijelenthetek. Emlékszem anno járt közkézen egy rosszindulatú pdf, ami szétfagyasztotta a gépeket, végtelen rekurzív kóddal, Zathura alatt meg csak simán megjelent, mint hiányosan renderelt doksi, semmi nem fagyott le tőle, nem okozott memóriaszivárgást.

Ugyanez volt egy másik rossz indulatú fájlnál, ami egy végtelen kitömörítésű, szándékosan hibásra preparált .zip fájl volt, szintén gépek lefagyasztására, az infozip az se bontogatta a végtelenségig, egy részt kibontott belőle (azt se tartotta meg), aztán leállt, hogy hibás az archívum.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Értem amit mondasz, de úgy értem, hogy egy szög egyszerű txt fájlra sem lehet ma kijelenteni, hogy veszélytelen, és biztonságos. Főleg nem lehet egyszerűnek nevezni semmit ami PDF-fel kapcsolatos, mert egy PDF megtekintő egy böszme bonyolult valami. 

Ezek valószínűleg jó programok, amiket felsoroltál, de olyan nem létezik, hogy valaminek nincs sérülékenysége potenciálisan. Gondolom a preparált zipfájllal ezt a zipbomb: https://en.wikipedia.org/wiki/Zip_bomb , vagy hasonló sérülékenységet akartak tesztelni, de ezek ismert sérülékenységek. Én azokról beszélek, amiket még nem ismernek, csak egy találékony tinédzser majd rájön.

De teljesen igazad van, hogy mindennek a tetejébe még nem is foglalkoznak azzal hogy egyszerűek legyenek a programok, teljesen feleslegesen telepakolják őket mindennel, és már régen elértünk egy olyan komplexitást, amit követni nem lehet.

Sőt az egészben a legérdekesebb plot twist, hogy a Postscript volt előbb, ami eleve egy Turing-teljes runtime volt. Annak egy (vezérlési szerkezetek szempontjából) lebutított változata lett pdf, hogy ne legyen mégse annyira generikus imperatív programfuttató környezet belőle. Tett az ipar egy nagy kört, majd visszatért oda ahonnan eleve indult.

Régóta vágyok én, az androidok mezonkincsére már!

Igen, a PS is Turing-képes nyelv, a Forth klónja, de az nem valós időben fut, hanem a dokumentum renderelésekor egyszer, onnan statikus marad. Ez a JS, meg amiről szó van, még fut akkor is, ha már a dokumentum le van renderelve. Óriási biztonsági kockázat ez, mint az Office makrók, azoknál is nem véletlen lett a default, hogy külön kézzel kell engedélyezni a futásukat, vírusterjesztésre voltak használva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( end | 2025. 02. 06., cs – 08:18 )

Szerkesztve: 2025. 02. 06., cs – 08:19

Mélységesen egyetértek! - A szoftverfejlesztésben is kellene a funkcionális minimalizmus a fenntartható fejlődésért.

( blr v | 2025. 02. 06., cs – 16:24 )

Szerkesztve: 2025. 02. 06., cs – 16:25

Ehhez képest már formkezelést, 3D funkciókat, JS-tet, meg minden szart beletettek

Már?

A formok 29 éve, a JavaScript 25–28 éve, a 3D 21 éve támogatottak.

Ezzel szemben a PDF/X, ami a nyomdai „formátum”, is csak 24 éves!

A JavaScript az 1.3-as PDF óta támogatott, amit először az Acrobat 4.0 kezelt 1999-ben, de valamiért úgy rémlik, hogy már az Acrobat Exchange 3-ban is lehetett használni (baromi régen volt, a kutya sem emlékszik pontosan). 3D a PDF 1.6 óta kezelhető, amit megjeleníteni ugyan már az Acrobat 7 tudott először, de az Acrobat 9 előtt a szerkesztéshez külön verziót kellett megvenni, a Professionalnél drágább 3D-t.

Soha nem volt szükségem egyikre sem, de anno a JS-sel azért poénból játszottunk egy picit.

( sly007 v | 2025. 02. 07., p – 12:07 )

 Excel/Word Libre/Open/Pepita megoldásokban mindig kiakaszt, hogy minden hülyeséget bele építenek csak a statikus adatstruktúrákat nem.

Pl jó lenne ha lehetne olyan sheetet csinálni, amiben adatbázis szerű működés érhető el. Tehát nem lehet bármilyen oszlopban bármilyen értéket beírni, működhetének rajta sql lekérdezések.

Vagy olyan dokumentumot létrehozni ahol a stílusok, formázások, struktúrák lekorlátozhatóak.

Lehet van már rá megoldás csak én nem tudok róla.

Ezekkel a magyarítsuk a "függvénynevet" dolgokkal nagyon messzire lehetne kergetni...
...ráadásul nem egymás mellett létezik egy "standard" és "nemzeti" névváltozat, hanem nyelvenként eltérő nevezéktant kell használni, amolyan pillanatnyilag jó ötletnek tűnt jelleggel.

Igen, egyértelműen az Excel is túltervezett, meg nem arra használják, amire való. Az táblázatokhoz van, hogy öltönyös-nyakkendősök tudjanak velük értekezletekre, prezentációkra, jelentésekbe anyagot gyártani, ahol táblázatos bontásban, meg grafikonon, diagramokon is látszanak az adatok, trendek. Nem matekszoftvernek írták, nem statiksztikai, mérési. logolós szoftvernek, nem arra, hogy ügyviteli meg könyvelési rendszert írjanak benne, meg nem adatbázis-kezelőnek, azokra mindre más megoldás való, nem Excel-ben összegányolni.

Persze, össze lehet gányolni Excelben is, működik, de sokszor szuboptimális, megborul, lassan nyílik meg, belassul alatta az Excel, nem minden verzión fut egyformán, hozzáköti a használóját az MS only ökoszisztémához (vendor lock-in), stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Access/Base egy amolyan szomszéd Pisti CRM-je. Leginkább tanítási szándékkal jó.  Én azt látom hogy inkább a táblázatokat próbálják ellátni ilyen funkciókkal, mint az űrlap, lekérdezés stb. Szebb világ lenne ha az Acces/Base funkció benne lenne a táblázatkezelőben. Sokat nem rontana a helyzeten. :D

Az Access/Base+SQLite az arra való, hogy nem kell neked egy adatbázisszervert elindítanod, hanem egy egyszerű fájlban tárolod az adataidat, de azokat az adatokat adatbáziseszközökkel (SELECT-ek és társaik) kezeled.

 

Szebb világ lenne ha az Acces/Base funkció benne lenne a táblázatkezelőben. 

Amúgy nagyon rossz, hogy táblázatkezelőnek hívjuk az Excelt, és sokan adattárolásra használják, miközben ez számolótábla igazából és arra kéne használni.

De hát azok nem lekérdezések mint egy adatbázisnál (ahol egy nagy adatfolyamból egy részt akarsz lekérdezni), hanem lookupok/indexek. Címzel egy cellát, mert a képlet azt használja. Nem véletneül VLOOKUP-nak hívják meg INDEX/MATCH-nek.

A kollega szerintem arra akar kilyukadni, hogy tulajdonképpen a számolótáblák és az RDBMS-beli táblák közt oly nagy különbség nincs, azonban két, egymástól teljesen eltérő standard alakult ki a kettőben, amik között nincs, vagy nagyon nehézkes az átjárás.

Nem feltétlen az itt a kulcs, hogy másra való, hanem az, hogy ha a másik irányból jössz, akkor nem egyszerűen egy másik nyelvet kell megtanulnod, hanem egy teljesen másik gondolkodásmódot, miközben mindkét esetben egy kétdimenziós adatmátrixról beszélgetünk, sorokkal és oszlopokkal.

Ez az, amit például a Google Spreadsheet meg tudott ugrani a QUERY() függvénnyel, amivel tudsz SQL queryt megfogalmazni egy spreadsheet-re (more specifically: egy range-re), és sokkal egyszerűbb eszközökkel ki tudsz fejezni egy amúgy bonyolult feladatot. Igen, valószínűleg egy végletekig limitált, és lebutított SQL subsetről beszélgetünk, amit ez tud, és nyilván nem lesz például típuskényszerítés, de jól látszik, hogy van is igény rá, meg nem is lehetetlen megvalósítani, a két dolog (relációs adatbázistábla és számolótábla) nem áll olyan nagyon messze egymástól.

És nevetni fogsz, de volt olyan számolótáblás feladat, amit ezzel egyszerűbb volt megvalósítani, mint a koordinátageometria mentén működő beépített függvényekkel (pl conditional SUM komplex feltételek mentén). Meg lett próbálva nem-SQL alapokon is a feladat, működött is, de a paraméterek módosítása lényegesen komplexebb volt. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-