OldComp.cz
http://www.oldcomp.cz/

Retro Linux
http://www.oldcomp.cz/viewtopic.php?f=54&t=8520
Stránka 35

Autor:  ctirad [ 11.05.2020, 10:35 ]
Předmět příspěvku:  Re: Retro Linux

Jinak, zkoušel jsi udělat build s uclibc-ng nebo jinou dietní libc? Ušetříš dost paměti i místa na disku (přepínač -Os) a dnes už s tím jde zkompilovat skoro všechno.
A pokud neznáš distcc, tak to ti umožní síťově kompilovat na jiném stroji. Je to sice primárně určené na škálování kompilace mezi víc strojů z důvodu zrychlení, ale jde to nastavit i tak, že stařeček bude jenom vyměňovat data s nějakou rychlou mašinou, která bude provádět vlastní kompilaci. I tak to asi bude dost pomalé, protože pomalá síť a pomalý disk.

Autor:  zxcygnus [ 11.05.2020, 11:09 ]
Předmět příspěvku:  Re: Retro Linux

ctirad píše:
V případě Linux celkem fuk. Bios potřebuješ jenom na natáhnutí bootloaderu, takže malý oddíl boot na začátku disku, kam ještě bios vidí, a pak už si to celé přebere systém.
Přesně tak. Jakmile nastartuje Grub a předá řízení jádru, tak na BIOSu nezáleží. Původně jsem to zkoušel s malým /boot, jenže to je maličko pracnější, než se vejít s rootem pod 8025MiB tím, že z něj oddělím ty skutečně velké kusy, tj. /usr/portage, /usr/src, /var a /home.

Resp. /var a /home velké nejsou, ale velikost /var je proměnlivá, podle tmp, logů atd... a velikost /home taky, podle toho, co si tam nakopíruje uživatel. Naopak spousta složek, jako /bin /sbin /opt /lib a /usr bez instalačních zdrojů jsou neměnné, nic se do nich po dokončení instalace nepřidává, /etc je malý z principu a ty zbývající jsou virtuální (/dev - statická část je malá, /run /proc /sys jsou jen mountpointy).
ctirad píše:
Jinak, zkoušel jsi udělat build s uclibc-ng nebo jinou dietní libc? Ušetříš dost paměti i místa na disku (přepínač -Os) a dnes už s tím jde zkompilovat skoro všechno.
Nezkoušel, protože ta moje instalace není tak úplně dnešní, ale cca 3.5 roku stará (2016/09). Částečně kvůli těm KDE 4.x (nechci nedokončené 5.x), kvůli absenci systemd (chci to postavené na openrc) a částečně kvůli tomu, že jsem k tomu nenašel odvahu :)
ctirad píše:
A pokud neznáš distcc, tak to ti umožní síťově kompilovat na jiném stroji. Je to sice primárně určené na škálování kompilace mezi víc strojů z důvodu zrychlení, ale jde to nastavit i tak, že stařeček bude jenom vyměňovat data s nějakou rychlou mašinou, která bude provádět vlastní kompilaci. I tak to asi bude dost pomalé, protože pomalá síť a pomalý disk.
Četl jsem o tom, ale usoudil jsem, že by mi to čas moc neušetřilo. Počínaje tím, že i SSH je pomalé.

Mám tu instalaci ve virtuálu na 3.5GHz Core i5 s 16GiB RAM s SSD na SATA III. Sice jsem tomu přidělil jen 2 jádra a 4GiB RAM, ale to docela stačí, nikam nespěchám, dělám u toho jiné věci.

K tomu mám připojený image se stejným počtem LBA bloků jako má fyzický HDD rozdělený na oddíly tak, jak to chci na cílovém stroji. Obsah oddílů můžu docela snadno aktualizovat rsyncem s tím, že vynechávám pár konfiguráků a samozřejmě /home.

Takže můžu buď zkopírovat dd celý ten image (32'253MiB), což trvá asi 20minut, protože fyzický HDD je pomalý (velmi zhruba 25MB/s přes USB redukci, i to je 2x rychlejší než na Pentium@150MHz). Nebo můžu stejně, jako aktualizuji ten image, pomocí rsyncu. I když jsou změny velké, rsyncem to jde rychleji než celý image dd a je to spolehlivé.

Drobný bonus je, že instalaci můžu klonovat do dalších virtuálů a provádět experimenty, aniž bych si tu původní rozbil a zároveň můžu kopírovat výsledek na víc HDD, nemusím se spoléhat na jeden fyzický disk, který se nakonec může i fyzicky rozbít.

Btw... koukal jsem, že uschovna.cz má limit na soubor 30GB, kdybych to zagzipoval, tak se to vejde :) Nechce někdo taky experimentovat?

Autor:  Czech Human [ 11.05.2020, 11:57 ]
Předmět příspěvku:  Re: Retro Linux

Mě by se líbilo takový systém na hraní mít, mám i K6-3 apod. s dostatkem RAM (MVP3 čipset tuším umí maximum 1GB) ty by mu víc chutnaly, jen by tedy musela proběhnout rekompilace aby z toho byl větší užitek a běhalo tam 3DNow! apod. :-). Ale nemám tam účet tak nevím jak dlouho by to trvalo nebo zda by mě to coby 30GB pijavici nevykoplo. Myslím že maximum co to posílá je ale pořád slušných 300kB a času mám na to dost. Na druhou stranu s Gentoo pracovat neumím, já spíš Debian/Blbuntu jsem jen linuxový BFU :-).

Autor:  ctirad [ 11.05.2020, 13:28 ]
Předmět příspěvku:  Re: Retro Linux

Pokud máš hodně starou gentoo instalaci, tak je to na houby, protože to kvůli starému EAPI už ani nupgraduješ.
Já osobně bych začal znova z aktuální uclibc stage3.
Každopádně 30GB? To je šíleně moc. Musíš tam mít 20-25GB balastu v cachích a distfiles. Promaž to.

Autor:  ctirad [ 11.05.2020, 13:29 ]
Předmět příspěvku:  Re: Retro Linux

Czech Human píše:
Mě by se líbilo takový systém na hraní mít, mám i K6-3 apod. s dostatkem RAM (MVP3 čipset tuším umí maximum 1GB)


Na tom bys měl rozjet snad už jakékoli modernější 32bit distro.

Autor:  Czech Human [ 11.05.2020, 13:39 ]
Předmět příspěvku:  Re: Retro Linux

ctirad píše:
Na tom bys měl rozjet snad už jakékoli modernější 32bit distro.


Vypadá to tak, ale není to tak. K6 totiž není i686 kompatibilní, jen i586. Je to takové Pentium na steroidech. Stejně tak všechny tyhle Cyrixy, Pentium MMX, K5 apod. Podpora 586 v hlavním proudu linuxu totiž je jaká? Jedním slovem žádná, na Pentiu už dneska nikdo nefunguje. Důvody jsou jasné - málo RAM, málo MHz, málo jader, výkonové propady vůči pokročilejší 686... i586/Pentium je nepodporované už pěkných pár let. Jen u na míru kompilovaného Gentoo to není problém, ale žádnou moderní distribuci staženou z internetu na tom nerozjedeš :hang:. Nehledě k tomu že kdybys kernel přemluvil, většina balíčků už je kompilovaná na i686 takže opět smolíček pacholíček. Nejnižší sestavu co bez problému rozjedeš je paradoxně dost výkonově fousatější Pentium Pro, ale to je i686 takže běží...

Autor:  misticjoe [ 11.05.2020, 14:01 ]
Předmět příspěvku:  Re: Retro Linux

Počkej, počkej - K6 vážně není i686? Já měl, za to, že ano.

Autor:  ctirad [ 11.05.2020, 14:06 ]
Předmět příspěvku:  Re: Retro Linux

Pravda, jestli to není K6-III není i686, tak by bylo potřeba jiné jádro.

EDIT: Tak nevím 100%. K6-II je i586, K6-III je prý "almost 686". Takže asi nezbývá než najít nejnovější verzi distra, co ještě podporuje i586 (což by třeba u Debianu nemuselo být tak dávno) nebo si zbuildit vlastní.

Autor:  zxcygnus [ 11.05.2020, 14:10 ]
Předmět příspěvku:  Re: Retro Linux

No jo, jenže já tam nemám ani podporu MMX, to ti to poběží pomalu :P

Autor:  Panda38 [ 11.05.2020, 14:14 ]
Předmět příspěvku:  Re: Retro Linux

K6 nepodporuje 686 instrukci cmov, má ji až od K6-III+

Autor:  zxcygnus [ 11.05.2020, 14:17 ]
Předmět příspěvku:  Re: Retro Linux

ctirad píše:
Pokud máš hodně starou gentoo instalaci, tak je to na houby, protože to kvůli starému EAPI už ani nupgraduješ.
Pravda. Ono upgradovat pouhý rok staré Gentoo je docela utrpení.
ctirad píše:
Každopádně 30GB? To je šíleně moc. Musíš tam mít 20-25GB balastu v cachích a distfiles. Promaž to.
30GiB je velikost image HDD i s volným místem.

Reálně to má necelých 20GiB z čehož 9.6GiB je portage a 3GiB jsou dvě zkompilovaná jádra.

Cache a tmp promazané jsou.

V portage určitě je spousta balíčků navíc, ale jsem rád, že tam jsou, protože některé je velmi obtížné najít. V oficiálních repozitářích nejsou, některé se nedaly vygooglovat ani vydolovat z web.archive.org, u některých jsem musel volit novější verze než default pro tu instalaci. A takové NetherEarth, které bych docela rád zprovoznil jsem sice nakonec zkompletoval i s patchi, ale zas poslední patch neproběhne... na tom budu muset zapracovat.

Autor:  Czech Human [ 11.05.2020, 14:53 ]
Předmět příspěvku:  Re: Retro Linux

Saje mě že mám K6-2,K6-2+,origo K6-III s vylepšeným jádrem taky, ale K6-III+ ne-e. Ona její dostupnost byla už tehdy řekněme dost vachrlatá, OEM to snad vůbec nedodávali, byla to jen náplast do notebooků a to po velice krátkou dobu, kdy K7 na notebooky moc žralo a levné noťasy se prodávaly. Stejně na tom ani nevydělali, kvůli výrobnímu procesu to ve finále levné CPU užíralo kapacity pro K7, které byly mnohem ziskovější a lepší.

Navíc i s celou její kvazi686 podporou ji povšechným výkonem lehce zadupe do země každý Duron, nedejbože Athlon. I když má CMOV tak bych na to že to bude 100% fungovat moc nespoléhal, tyhle raritní kočkopsy opravdu jen vzácně fungují na softwaru vydaném 22 let po jejich vydání na trh pro architekturu, která je komplexnější než kočkopes...

Nejjednodušší z pohledu rozběhání linuxu na tyhle staré střepy je dneska paradoxně být skalní gentooista ale zase moderní stroje nemají vůbec 3DNow! takže i emulace běhu bude jistě dost problematická (jedině AMD do generace K10, tuším že neoficiálně byly ještě v Bulldozeru ale tam už to bylo deaktivované a nebyla od AMD garance spolehlivé funkce) a na reálném hardwaru K6-2+ kompilovat dnešní gentoo to už bude soutěžit s tím, kdy vám zlí lidé nacpou věc velikosti a tvaru mexické agáve tam, kam se dívají jen celnící... :-).

Bez podpory MMX/3DNow to nemá moc smysl, ty procesory jsou rychlejší hlavně kvůli nim (a full speed L2 cache). To je lepší to udělat celé od začátku i se SIMD sadami...

Autor:  ctirad [ 11.05.2020, 18:27 ]
Předmět příspěvku:  Re: Retro Linux

zxcygnus píše:
Reálně to má necelých 20GiB z čehož 9.6GiB je portage a 3GiB jsou dvě zkompilovaná jádra.

Njn, obrazy celých disků jsou problém. Předpokládám, že ve zdrojácích jádra si dal "make clean", pokud je tam chceš opravdu mít. Pakovatelnost můžeš výrazně zlepšit zmenšením systémového oddílu na úroveň zaplněnosti daty a vzniklé prázdné místo až do konce disku (předpokládám, že je poslední na disku) vyplnit nulama.

Samozřejmě řádově lepší je zaarchivovat si jenom rozdělení
Kód:
sfdisk -d /dev/zarizeni_disku  > /soubor_rozdeleni_disku.tbl

a jednotlivé oddíly zazálohovat nástroje, co umí filesystémy (partclone..) a zkomprimovat něčím, co je rychlé a má dobrý poměr, typicky zstd.

Citace:
V portage určitě je spousta balíčků navíc, ale jsem rád, že tam jsou, protože některé je velmi obtížné najít. V oficiálních repozitářích nejsou, některé se nedaly vygooglovat ani vydolovat z web.archive.org, u některých jsem musel volit novější verze než default pro tu instalaci.

Myslíš ebuildy nebo binárky v distfiles? Na to by bylo rozumnější udělat nějaký overlay včetně archivu zdrojáků přístupný někde na síti.

Autor:  zxcygnus [ 12.05.2020, 10:38 ]
Předmět příspěvku:  Re: Retro Linux

ctirad píše:
zxcygnus píše:
Reálně to má necelých 20GiB z čehož 9.6GiB je portage a 3GiB jsou dvě zkompilovaná jádra.

Njn, obrazy celých disků jsou problém. Předpokládám, že ve zdrojácích jádra si dal "make clean".
Nedal. Jádro upravuju a chci mít možnost se k němu vracet aniž bych pokaždé překládal vše znovu. Dá se udělat dodatečně.
ctirad píše:
Myslíš ebuildy nebo binárky v distfiles? Na to by bylo rozumnější udělat nějaký overlay včetně archivu zdrojáků přístupný někde na síti.
Myslím celý /usr/portage včetně distfiles. A overlay na síti je pro mě asi zbytečný. Ledaže bych si do něj chtěl sesypat všechny balíčky ze všech retro záloh, co mám... moc práce.

Ono to i tak sežralo příliš mnoho času, takže to to na nějakou dobu odložím a nechám uležet.

Mezitím jsem přišel na to, že s jádrem 4.9.222 to běhá pomaleji a to tak o 10 - 15% pocitově a trochu podle glxgears. Se 4.4.222 to naopak běhá lépe než s 2.6.38. Rozdíl je maličký, ale třeba mp3 se dají přehrávat lépe a stabilněji. S jádrem 4.9.222 to 192kBit mp3 kazilo a zvuk se trhal (se 486 si troufli jen na wav :))

Což znamená, že jsem opravil i zvuk, resp. překompiloval jsem jádro bez podpory jiných x86 CPU a to nejspíš pomohlo k tomu, že mi alsamixer přestal hlásit neplatnou instrukci a taky jsem přidal GUS PnP do jádra, ne jako modul.

Stále se mi to nepovedlo zatuhnout, nebo jinak rozbít a to jsem omylem spusil i Gimp, když jsem zkoušel zobrazovat JPG... no swapovalo to pár minut a pak se prostě spustil a obrázek zobrazil (800x600 JPG). Ale použitelné to není. Gpicview trochu ano, zobrazí, ale bylo to pekelně pomalé, protože se obrázek neměl šanci vejít do RAM (nějaká 8MPx fotka), pro změnu jsem na jednoduchý prohlížeč zkusil mnohem větší obrázek.

Video bez šance i když cvlc (konzolové VLC) se snaží a z jednoho videa jsem zobrazil 2 statické snímky po minutách počítání.

Už mi fungují floppy mechaniky, zprovoznil jsem fdutils, ale chybí mi fdformat, nicméně v skrz PCManFm se disketa dala přimountovat (ano, dá se spustit celé LXDE). Zkusil jsem i USB floppy a to funguje stejně dobře jako jiné USB HDD a Flashky. Takže jsem si nakopíroval VC a zkusil DOSBox.

Co myslíte, dá se DOSBox spustit a používat na 150MHz Pentiu s 80MB RAM?

Ano, dá. Pomalu. Velmi pomalu. Nemám srovnání, ale pocitově podle chování Volkov Commanderu je to trochu pomalejší než 4MHz PC XT, ale překvapivě se to dá použít.

Wine je tam taky nainstalovaný, ale to asi nechám na někom jiném :) Ve virtuálu se spuštění Notepadu, nebo Regeditu nezdálo nějak náročné, tak je možné, že něco jednoduchého na tom i půjde.

Z webových prohlížečů funguje W3M docela bez problémů, zvlášť v textové konzoli a v grafice funguje Dillo. Je to pomalé, neumí to skoro nic, takže se dají zobrazit jen primitivně jednoduché weby, jako je ten můj https://cygnus.speccy.cz a dá se zobrazit i OldComp.cz, ale spousta jiných se rozpadne k nepoužití.

Další síťové věci jsem moc netrápil, SSH určitě funguje, VNC klient taky, je tam iptraf-ng na sledování provozu, což funguje, ale když udělám flood ping z rychlého stroje, tak sice PC komunikuje, ale už nestíhá zobrazovat. Nezkoušel jsem připravenou Sambu a Apache + PHP 5.6 (ve virtuálu fungují). MySQL tam nemám.

Office věci jako AbiWord a Gnumeric fungují, extrémně pomalu, ale fungují. LibreOffice je v distfiles, ale nainstalovaný není, ani libreoffice-bin.

Pak je tam hromada jednoduchých xkových utilitek a hraček. S nimi většinou není problém, jsou tak malé a nenáročné, že se to v přiměřeně jednoduchém WM (třeba JWM, nebo TWM) chová velmi podobně W98. Tj. dá se to použít bez větších omezení.

Zkusil jsem i nějaké hry. Většinou se to chová pomalu a nehratelně. Ale tomu jsem věnoval málo času... třeba takový LTris, který mi s předchozí instalací zatuhnul celý systém, tak funguje, ale hrát se to nedá. Podobně další věci. To ještě zbývá prozkoumat.

Fakt by mě zajímalo, jestli by se s 3D akcelerací dal hrát třeba Battalion. Tím bychom se přiblížili alespoň tehdejším SGI (hra je z roku 1994, ale bez OpenGL nepoužitelná https://www.evl.uic.edu/aej/AndyBattalion.html).

Autor:  Czech Human [ 12.05.2020, 13:27 ]
Předmět příspěvku:  Re: Retro Linux

Tady je videjko co se stane když používáte "špatné" CPU řady K6 a hodně RAM, na kterou se není schopná cache namapovat. Výkonnostní rozdíl je ne příliš překvapivě nejhorší pro K6-2, která parametry svojí L2 plně závisí na desce, naopak ti šťastlivci co používají K6-2+/3/3+ se svou vlastní L2 cache mohou bez problémů používat i necachovatelné množství RAM bez dopadů na výkon, případně cache úplně vypnout a rozdíl bude opět zcela marginální. K6-3 na 400MHz a s 66MHz FSB pak lehce výkonově dorovná či dokonce překoná i K6-2 sprintující na 550MHz s 100MHz FSB, které zase naopak 400MHz verzi uteče, když je objem RAM v cachovatelném rozsahu... Velmi krásný příklad toho jak malá propustnost RAM dovede výkonově zaříznout seberychlejší CPU https://www.youtube.com/watch?v=A2Oymnq5DEQ

Díval jsem se i po podpoře CMOV u K6-III+ ale žádný datasheet ji nezmiňuje a internet mlčí. Kouzlo 686 je částečně v přítomnosti PAE a CMOV, ani jednu instrukci AMD do uvedení Athlonu nemělo. Vzhledem k tomu že K6-2+ je nepovedená K6-3+, tuším že takové K6-686 CPU bude nejspíš z říše městských legend. Manuál totiž výkon CPU popisuje jednou větou "přináší výkon šesté generace" což se zcela jistě nedá chápat jako "je to šestá generace" ale normální reklamština. Zatímco o CMOV jsem nic nenašel, našel jsem reference na lidi co zkusili použít i K6-3+ s i686 jádrem, ale tato kombinace jim nikdy nefungovala.

Stránka 35 Všechny časy jsou v UTC + 1 hodina [ Letní čas ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/