- A hozzászóláshoz be kell jelentkezni
- 663 megtekintés
Hozzászólások
Kedvenc 2021-es feature-om:
"Floppy Edition now uses compression and requires about half as many diskettes"
:D
- A hozzászóláshoz be kell jelentkezni
Ósdinak hangzik, de van valóságalapja. A FreeDOS-t nem csak modern gépekre szánják, hanem legacy PC-kre is, és azoknál egészen a P1-P2 korszakig jellemző volt, hogy CD-ről nem tudnak bootolni, se USB-ről. Így floppy-ról kell telepítsél, és ugyan vannak kerülőutak, pl. bootfloppy ODD driverrel, majd onnan indítva a CD-s installt, de felkészülnek olyan gépekre is, amiben tényleg csak HDD és FDD van.
Az is figyelemre méltő, hogy fele annyi floppy kell, az kb. 50%-os tömörítési arány, ami ma már nagyon alacsonynak számít, hiszem a FreeDOS java csak plain text file (forráskód, doksi) és bináris, ezek mindegyike jól tömöríthető, kb. 20-25%-ra összenyomható lenne egy modern tömörítővel. De megint ugyanaz a téma, a modern tömörítők beállnak, mint a szög régi legacy gépen, ahol se elég memória nincs, proci, HDD bűn lassú. Ne felejdük, hogy a modern tömörítők (7-zip, zstd, Rar5-6, stb.) már gigás szótármérettel tömörítenek, és a memóriaigényük is durva tud lenni, így tömörítésnél is csak egyszerű legacy tömörítések játszanak, zip deflate, Rar 2.x, arj és hasonlók. FreeDOS-nál még az is megkötés, hogy csak FOSS komponenseket használnak és szállítanak a devek, így a Rar kiesik (arj-vel kivételt tesznek, úgy nézem mellékelik), marad az infozip vagy gzip (pkzip kompatibilis ez a kettő) meg esetleg lzop, aminek kicsi a memória/CPU igénye. Ez a DOS ilyen műfaj, ha meg akarják tartani a visszafelé kompatiblitást, vissza kell mindenből menni a kályháig, kb. 20 évvel ezelőttig. Mellékelik persze a p7zip-et, lzma-t, bz2-t, de az modernebb gépekhez van, ilyen XT-ken, meg gyengébb 386-486-osokon felejtős.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Kb. lényegtelen apróság, de az arj-nek létezik 100% open source implementációja.
- A hozzászóláshoz be kell jelentkezni
Igen, közben én is látom, hogy rosszul emlékeztem. Lejárt róla néhány éve a szoftverszabadalom, és lett GPL változata. Jó tudni.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
a FreeDOS java csak plain text file (forráskód, doksi) és bináris, ezek mindegyike jól tömöríthető
A binárisok pont, hogy rosszul tömöríthetőek, a magas entrópia miatt.
- A hozzászóláshoz be kell jelentkezni
Egy bináris nem csak kódból áll. Ha nem így lenne nem lenne értelme az exe packereknek.
- A hozzászóláshoz be kell jelentkezni
Igen, de ezek egyszerű rendszerprogramok, ott ez kevésbé jellemző, mint pl. egy játéknál, ahol az összes grafikus assetet pl. belepakolják az exe-be.
“Any book worth banning is a book worth reading.”
- A hozzászóláshoz be kell jelentkezni
Miért ne lenne értelme? Ha csak minden binárison 5%-ot fog, lehet, hogy felfér még egy apró bináris a floppyra, persze az is tömörítve.
- A hozzászóláshoz be kell jelentkezni
Ez ugyan 64 bites Linux, de még egy gzip is képes > 50%-ot hozni rajta, ami azért egy picit több az 5%-nál.
$ uname -a
Linux Lenovo-510 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
$ tar -czf bin.tgz /bin
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
$ gzip -l bin.tgz
compressed uncompressed ratio uncompressed_name
7762829 17285120 55.1% bin.tar- A hozzászóláshoz be kell jelentkezni
Ja, az xz / lzma megoldások még jobbra összetömörítik. De még a zstd is kicsivel jobban tömörít, mint a gzip/rar, de azoknál jóval gyorsabb, próbáld csak ki, hogy milyen veszett gyors, a -1 helyett használhatsz más tömörítési fokot is, -1 és -19 között:
time tar -I "zstd -T0 -1" -cfv bin.tar.zst /bin
time zstd -t bin.tar.zst
Ezzel a zstd legalacsonyabb tömörítési fokkal nekem a betömörítés a /bin mappára 0,661 sec, a kitömörítés pedig 0,714 sec, tömörítési arány 40%. A gzip alap fokozattal betömörítés 25,235 mp, kitömörítés 3,238 sec, tömörítési arány 63% (natív Arch Linux, 64 bit, lehet nagyobb a /bin/ mérete és a tömörítés is gyorsabb, mert natívan fut, nem WSL2 alatt). Persze vannak erősebb tömörítési fokozatai a zstd-nek, pl. a 19-es fokozaton már 26%-ra tömörít, de kétszer olyan lassú, mint az alap gzip, de cserébe a kitömörítés még mindig sokkal sebesebb, 1,033 sec.
Az xz jobban tömörít, 21,7%-ra, de 93,811 sec alatt tömörít be (az összes magot használva) és 7,519 sec alatt ki (csak egy szálat használva). Arányban csak 4,3% helybeli nyereség általában nem ér meg 10-142-szeres sebességkülönbséget.
Elvileg az lz4 és az lzop a leggyorsabb, de irtó gyenge a tömörítési fokuk meg csak egy szálon tömömörítenek be/ki. Ezzel szemben zstd-nél nem csak a betömörítés több szálú (ahogy a legtöbb tömörítőnél), hanem még a kitömörítés is, ezért egy tisztességes modern gépen több giga/sec-kel tömörít ki, úgy, hogy a tömörítési fok se rossz. Nem a legek legje, mert ilyen xz, lzma, 7z, meg brutális nanozip, paq, stb. szintet nem ér el tömörítésben, de a veszett gyorsasággal ellensúlyoz, állva hagyva minden mást.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Frissült a zsdt 1.5.0-ról 1.5.1-re, amiben volt pár sebességoptimalizáció, és azonos beállításokkal, ugyanarra a /bin mappára (telepítítve nem lett progi bele, de volt, ami frissült benne új verzióra) kb. a beígért 19%-kal javult a be/kitömörítési sebesség is, igaz ez ennél a nem túl nagy, pár száz megás méretnél csak század másodperceket jelent, max. egy tizedet, egy eleve 1 mp-nél sokkal rövidebb időből. A tömörítési arány csak 1 ezrelékkel javult, az elhanyagolható, pár KB-ot jelenthet.
Az is igaz, hogy a zstd csak normál tömörítésre, archiválásra, tömörített állományok szokványos megosztására, terjesztésére a leggyorsabb. Vannak speciális esetek, mikor jobb rá lz4 vagy lzop, pl. kernelimage, initramfs kicsomagolásánál, ahol csak egy szálon megy a kitömörítés (boot korai szakaszában még nem játszik a többszálúsításos móka), ott a zstd kicsit lassabbnak érződik, megint csak tized mp. lehet kb., de érezhető, jelen van.
A másik jelenség, amit a tömörítőket az elmúlt 20 évben érintette, hogy azóta megnőttek a tárhelyméretek, netsávszélességek, és már nem fontos annyira, hogy egy tömörítő, vagy algoritmus annyira ultra jó tömörítést végezzen. Régen fontosabb volt, mint pl. most a FreeDOS esetében is, hogy valami a legkevesebb számú floppy-ra ráférjen, meg minél hamarabb átmenjen telefonvonalon, ott inkább extra ki/betömörítés idővel fizettünk inkább a helyspórolásért. Ma már fordítva van: legyen gyors ki/betömörítés, mindenki azonnal akar mindent, sietve, futva, a tárhely, sávszél, memóriaigény már nem annyira számít, csak kb. legyen valamennyire betömörítve. Médiaformátumoknál dettó, régen még ment azon a fetrengés, hogy hol van egy lossy audiótömörítő transzparenciahatára, mert számított, hogy 256 kbps vagy 128, de ma már meg elég a flac is, igaz, hogy 50-70%-ra tömörít, a 320 kbps-nak duplája, triplája, de az is elég, mert már nem kell a hellyel spórolni, lassan már a tömörítetlen CD audio sem tétel hely/sávszélügyileg. Változnak az igények, eltolódnak súlypontok.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Egy 64-bites binárisban egy csomó címfeloldás történik 32 ill. 64 biten úgy, hogy csak pár bit van belőle használva, ergo tele lesz nullával. Kinyitsz egy ilyen binárist, van benne header, data section, meg minden túró, ami megint csak tele van nullával. Van benne egy raklap string is. Ezek mind-mind jól tömöríthetőek. De egy headerless, code-only, 16 - vagy 8 - bites binárist, amiben maximum pár tucat karakternyi string van, nem fogsz ekkora hatásfokkal betömöríteni. Minden azon múlik, hogy mennyi a fájlban az aránya a magas entrópiával bíró bináris részeknek. Ha a bináris kvázi alig tartalmaz bináris részeket, csak stringeket, meg egy raklap nullát, az persze, hogy jól tömöríthető.
- A hozzászóláshoz be kell jelentkezni
Ebben igazad van, de a legtöbb kód pont olyan 32-64 bites, headeres, csomó string section-ös cucc a való életben, ami rettenet jól tömöríthető. Eleve 8/16 bites bináris már kb. sehol nem fordul elő, főleg nem ilyen headerless, meg ezek a binárisok eleve nem is foglalnak sokat méretben, pár KB, így nem fontos, hogy annyira jól legyenek tömörítve. Sose mentem bele az okába, de már a DOS korszaktól fogva csináltam egy csomó rendszermentést, tömörített másolatot szoftverekről, ahol bináris, dokumentáció, meg médiatartalom is volt, és az volt a tapasztalat, hogy jól tömöríthető, mind a 16-32 bites átlag kód, és ez 64 bit alatt sem változott (Win, Linux, BSD).
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ebben igazad van, de a legtöbb kód pont olyan 32-64 bites, headeres, csomó string section-ös cucc a való életben, ami rettenet jól tömöríthető.
De itt egy 16-bites OS binárisairól és annak tömörítéséről volt szó; a 32 és 64-bites, mindenféle szekcióval telepakolt binárisok tömöríthetősége itt irreleváns.
Eleve 8/16 bites bináris már kb. sehol nem fordul elő
Kivéve a retro-realm-ben, amihez tartozik az éppen tárgyalt FreeDOS is; itt pont, hogy 16-bites binárisok fognak előfordulni és azokat kell tömöríteni.
főleg nem ilyen headerless
Kivéve pl. pont DOS alatt a .COM fájlok.
meg ezek a binárisok eleve nem is foglalnak sokat méretben, pár KB, így nem fontos, hogy annyira jól legyenek tömörítve.
Kivéve, ha a disztribúció primer adathordozója a jó öreg 720k-s floppy, mert akkor mindjárt számít, hogy binárisonként sikerült pár kB-ot fogni, ha van mondjuk 100 bináris.
Sose mentem bele az okába, de már a DOS korszaktól fogva csináltam egy csomó rendszermentést, tömörített másolatot szoftverekről, ahol bináris, dokumentáció, meg médiatartalom is volt, és az volt a tapasztalat, hogy jól tömöríthető, mind a 16-32 bites átlag kód, és ez 64 bit alatt sem változott (Win, Linux, BSD).
Nem, a kód semmiképpen sem lesz jól tömöríthető, pont annak magas az entrópiája (hacsak nem 100%-ig NOP-okból áll). A bináris lehet jól tömöríthető, attól függően, hogy mennyi kód és mennyi adat van benne és az adatnak mekkora az entrópiája.
- A hozzászóláshoz be kell jelentkezni
De pont azért írom, hogy én életszerűségről beszélek, és 16 bit alatt is ezt tapasztaltam. Telepíts fel egy full FreeDOS-t (nem floppy-s, hanem full CD-s verzió full telepítése, összes csomag, összes szoftver, dokumentáció, forráskód), mondjuk virtuális gépbe, akár még Windows 3.x vagy más is mehet rá, DN-ral és minden földi jóval, és tömörítsd be, már egy sima gzip is átlag 50%-ra összetömöríti (akkor is, ha csak a binárisokat nézzük), zstd kicsit az alá (bár ennek a sebessége a lényeg, hogy pislogni nincs időd, olyan gyors), xz/7z/lzma kb. 40%. A PAQ-klónok talán 30 közelébe is lemennek, de azok már sok órán át tömörítenek ki/be, meg sok giga memóriával, az már csak cirkuszi mutatvány, nem életszerű. Mondom, átlag tömörítés, átlag szoftveres, szövegszerkesztők, rendszertoolok, CLI programok, fordítók, grafikus felületek, játékok, stb., átlagban 40-50%, de nem kell hozzá nagy szerencse, hogy még jobban tömöríthető legyen.
Már anno DOS alatt is ezt tapasztaltam, mikor még mindenki azt használt. Pedig akkoriban még a tömörítők nem voltak ilyen jók, mint most a 7z, nanozip, PAQ, sem olyan gyorsak, mint a zstd, lz4, lzop. Javarészt arj-t használtunk, de a rar azonnal kiszorította. pkzip-ből inkább csak kifelé tömörített mindenki. De már ezeken is kb. a 40-50%-os arány játszott binárisoknál. Persze már ebben az időben is voltak fetisiszták, akik olyan ritkább tömörítőket erőltettek, mint a jar, ain, uc2, zoo, lzh, lha, pkpak, ace, arc, stb., annak ellenére, hogy semmi előnyük nem volt, csak nehezebb volt kibontani.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
A FreeDOS-szal pont nincsenek tapasztalataim, de ami van - akár old, akár newschool - az azt mutatja, hogy minél nagyobb a binárisban a kód aránya, annál kevésbé tömöríthető. Viszont a régi rendszerek közt sokkal több volt az olyan bináris, ami (közel) 100% kód.
- A hozzászóláshoz be kell jelentkezni
Ezzel sajnos 30+ évnyi tapasztalatom ellenkezik. A binárisok nekem általában mindig is elég jól tömöríthetőek voltak. Még azok is, amikben nem volt sok string. Ezzel nem azt mondom, hogy minden bináris kivétel nélkül jól tömöríthető, mert egyedi kivételek biztosan vannak, de általában egész kicsire összenyomhatók, ha a nagy átlagot nézzük. A legjobban tömöríthető adat meg a plain text file-ok között is a logok, hiszen sok minden ismétlődik bennük, azok tényleg nevetséges százalékra lenyomhatók. Amik még nagyon jól tömöríthetőek, azok a plain text / XML alapú szótárak, adatbázisok, amikben emberi szöveg van, illetve a forráskódok, a sok ismétlődő nyelvi szintaxiselem és újra-újra előforduló változó, függvény, objektum, stb. nevekkel.
A random és pseudorandom adat az, ami tömöríthetetlen, meg az eleve tömörített dolgok (akár szótár alapú, akár lossy médiatömörítések, képek, hang, videó, stb.).
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
A binárisok nekem általában mindig is elég jól tömöríthetőek voltak.
Attól függ, hogy mi volt benne.
egyedi kivételek biztosan vannak
Nem, nem egyedi kivételek vannak, hanem a tartalomtól függ.
A random és pseudorandom adat az, ami tömöríthetetlen, meg az eleve tömörített dolgok (akár szótár alapú, akár lossy médiatömörítések, képek, hang, videó, stb.).
Igazi random nem létezik, de ez mellékes. Ami fontos, hogy nem az számít, hogy milyen adat az, hanem az entrópia. Ha egy olyan pszeudorandom fájlod van, amiben csak ASCII számok (48-57) vannak, de azok pszeudorandom módon összehányva, azt azért valószínűleg legalább 50%-os hatásfokkal lehet tömöríteni. Ha van egy 2 MB-nyi nullából álló fájlod, amit úgy tömörítettél le, hogy egy byte mondja meg, hogy a következő szakasz milyen byte-ból fog állni és egy byte, hogy mennyiből, akkor abban végig az van, hogy 0x00 0xff, amit alaphangon nyolcadára lehet tömöríteni, pedig már tömörítve van.
Ez nem szarrágás, csak szemléltettem, hogy ellenpélda mindenre van. Jól tömöríthető pszeudorandomra és tömörített állományra is, meg jól tömöríthető binárisra is. Az entrópia a lényeg, egy bináris kód entrópiája meg általában magas.
- A hozzászóláshoz be kell jelentkezni
Remélem ha új laptopot veszek már ezzel jön! :)
- A hozzászóláshoz be kell jelentkezni
Szivesen olvassuk majd a tesztelés során szerzett tapasztalataidat. :)
- A hozzászóláshoz be kell jelentkezni