LX7 Puppy

[ticoo1]

Szia nocsak!

Tettem fel egy xenial64-32 bitest is (a "Teszt"-be), ugyan próba névvel, de valójában szerintem egész jó. Ezt is meg kellene nézned (meg másoknak is). Persze most, sem a mérete, sem tartalma nem érdekes, csak az, hogy alapelképzelésnek jó vagy sem. Wine azért van benne, mert ha, lassan is át kell térni a 64 bitre, s én egy rendszeren belül szeretném futtatni kedvenc 32 -es játékaimat és erre ez jó. A Bionicdog64 még messze nincs azon a szinten, hogy rendesen meg lehessen oldani a problémát. De hát még béta.

A 4.9.58-al megnézem és azt is, hogy mit lehet benne tartani belőle, de ehhez még egy picit el kell gondolkodni. Szerintem itt már hozzá kell, hogy nyúljak az eredetidhez. Persze próbálni mindent lehet.

[csipesz]

Pontosan ugyanezek a tapasztalataim a bionicpup 64 bites változatán a wine-nal kapcsolatban - vagyis egy katasztrófa. - Szenvedtem vele vagy 2 napot, mire azt mondtam: elegem van...

[nocsak]

Sziasztok!

Nincs sok időm, így a lényeg:

Most ott tartok, hogy a ticoo1 által 64 bitessé tett LX7 fut a modern alaplapos konfigomon... "modern" tehát a régi egyáltalán nem vagy csak trükkösen futott.
Az alsa is pöccre működik, minden ami LX7, csak a "Trabant kaszniba" most egy koenigsegg motor került. Viszont!
Ami a lényeg, hogy így ebben a formában fordítani rá semmit nem lehet önerőből, a links 2.17-et próbából beleforgattam, és kaptam egy nagy error tengert mert nincsenek meg a lib64 könyvtárak, és a 32 -esek a lib64 helyén vannak értelem szerűen mert alaphangon az LX7 az 32 bites. Most ugye az van, hogy a 64 bites kernel ami képes 32 bites alkalmazások futtatására, így az hajtja az LX7-et.. mint egy hagymahéj szerűen rétegesen... ám így a nevezett koenigsegg motor érinthetetlen. Erre 1 részleges megoldás van:

Régi LX7-en fordítok, és csak olyat ami nem használ kernel modult, vagy a /lib/modules/3.2.32 könyvtárat... csak az usr etc stb-t.

Viszont cserébe a 64-es kernel, bocsánat ha hülyeséget írok, de ezek szerint képes lenne akár egy modernebb gépen is elindulni akár több mint 16GB RAM-mal. Ha meg ticoo1-gyel össze lehetne kovácsolni egy olyan elképzelést amit az ezt megelőző hozzászólásomban írtam akkor az ütőképesebb lehetne.

[NTamas]

Azért talán azt is meg kellene vizsgálni, hogy az így ún. modernizált 64 biten is futtatható puppy-ban lévő csomagkezelő használható e?
Az abban lévő tárolókból milyen csomagok tölthetőek le? - (32bit vs.64bit?) és azok egyáltalán futtathatóak e?
És még egy dolog, ha jól emlékszem csipesz már pedzegette, a függőségek problémáját, ez ugye a csomagkezelőre is érvényes, ha onnan egy akármilyen programot leszedek, akkor az milyen verziójú (32bit vs.64bit?) függőségeket fog lehozni hozzá, már, ha lehoz egyáltalán.
Gyaníthatóan ez lesz ennek a kernelcserélgetős megoldásnak a legnagyobb hátránya, illetve a megfelelő videó driver legyártása, lásd pl. nvidia videódriver készítés!
Az odáig oké, hogy nocsak a régi 32 bites gépén pár szoftvert lefordít, de a többivel mi lesz?
Az is oké, hogy elvileg a 64 bites rendszer képes a 32 bites programokat futtathatni, feltéve, ha minden szükséges dolog, függőség megvan hozzá, de mi van akkor, ha ezek közül valami hiányzik? - és mondjuk már nem beszerezhető, pl. a rendszerben lévő csomagkezelőből?
Azt se hagyjátok ki a számításból hogy egyre több cucchoz szűnik meg a gyári, 32 bites drivertámogatás, ami azt is magával hozza, hogy lassan a régi 32 bites driverek már nem lesznek, -vagy csak nagyon nehezen, nagy kereső munkával- elérhetőek, és ezen régi, de még működő eszközökhöz már 64 bites drivert nem fognak készíteni, ezt is be kéne kalkulálni.

Az én véleményem az, hogy a régi, 32 bites gépeken, ha még mennek, használjuk inkább a 32 bites dolgokat, és a 64 bites gépekre meg inkább az ahhoz való 64 bites programokat.
És persze, aki ért hozzá, és tud forráskódból - már, ha van ilyen- programok készíteni/fordítani az inkább ezt a 64 bites rendszerre! tegye meg, nagy munka, persze, de legalább, ha sikerül, van egy (vagy több jó) 64 bites programja, és az(ok) legalább jól mennek, nem úgy, mint pl. a 32 bites wine a 64 bites rendszeren.

[janugsa]

Ez a puppy 32 bites és az is marad.
Ticoo nagyon ügyesen megoldotta a kernel elkülönülését, és ezáltal cserélhetőségét, akár 64 bites kernelre is.
Így képes új gépeken is futni, nagyobb memóriát látni.
De a puppy 32 bites.
Nem tudtam mentés fájlt készíteni, mást nem tapasztaltam.

[Asterix]

Üdv!
Bocsi, de csak a hétvégén tudok foglalkozni "vele" !

[nocsak]

Az én esetemben a kérdés az, ki(ke)t érdekel rajtam kívül annyira az LX7, hogy ekkora hátszelet fújjunk neki? Ugye az számomra elvben lehetséges megoldás, hogyha ticoo1-gyel lehetne mögé rakni egy építhető 64 bites vázat 2 PPM-mel, egy natív 64-es xenial és a sajátja ami kooperálhatna egymással. Még 100%-ig nem állt össze a fejemben és lehet nem is fog mert lehetetlen, de kattogok még rajta.

NTamas részemről hibátlanul vázolta a valós aggályokat. A kérdés tehát, mire fókuszáljunk.... Lehetne erről egy facebookos szavazást is indítani ki mire szavaz, vagy valahol ahol a legtöbben tudnának véleményt nyilvánítani, mivel lenne érdemes foglalkozni. Fontos, mert különben hamar lelombozódhat a lelkesedés, ha viszont olyan fába vágjuk a fejszét ami kellemes és hasznos, az motiválna is minden résztvevőt. Most arra értem, hogy a haladás útja időben is adott... tehát a 64 bit a jövő. Lassan tényleg még firefoxot sem fogunk tudni telepíteni, mert jön valami biztonsági rés és elvágják a 32 bitet. (Ha klasszikus tendenciára alapozok.)

/*off
Erről a hibrid LX7-ről meg az jut eszembe amit egy könyvben olvastam, amikor a gépek összeolvadnak az emberekkel. Addigra nem mi futtatunk mondjuk 256 bites Puppy-t, hanem minket futtatnak majd valami hyperszámítógépen....
*/

Nekem sikerült mentésfájlt készíteni... most is a "hibrid" LX7-ről vagyok. Teszem hozzá a legelső iso-ból. Nem amit utána felrakott ticoo1...

[ticoo1]

Úgy látom valamit tisztázni kell.

"janugsa" írta: "Ez a puppy 32 bites és az is marad.". Pontosan így van. Nem 64 bites rendszert akartam csinálni, csak a "kötött kernelt" szerettem volna cserélhetővé tenni, a Pae végett. A 64 bites huge véletlenül maradt benne, mivel ua. verziószámmal van 32 bites is, s csak összekeverten a végén. Amint "Asterix" jelezte, hogy valami nem tiszta, lecseréltem az ISO-t. Tehát azóta 32 bites huge van benne (mármint zdrv-ként az ISO-ban, mert egyébként "üres", nincs /lib/modules).

Ez szerintem soha nem lesz 32/64 bites -- próbáltam már ilyet csinálni, de a vak ló is hamarabb látja meg a napot, mint bármelyik program a 64 bitet combo üzemmódban a 32-vel. Ha véletlenül belekerül egy 64 bites huge kernel, akkor odáig el lehet jutni, hogy egy-egy x86-64-es program feltelepül, de amint futtatni akarjuk jönnek a hiányok és, ha egyet pótolsz, akkor kapsz másik tízet, s ha már minden jónak tűnik, akkor jön egy BASH üzenet.... Igen és "NTamas"-nak teljesen igaza van, hogy akkor mihez is kellene igazodni?

Ha mégis a 64-et és a 32-őt együtt szeretnénk használni, akkor egy 64 bitest kellene alkalmazhatóvá tenni erre. Ezért raktam fel egy xenial64--32-őt próbára, szerintem ehhez alkalmas lehet. Persze kell csinálni belőle egy alapot, csak előtte meg kellene mélyebben nézni. Én ehhez kevés vagyok.

"nocsak" ezektől függetlenül megcsináltam amire gondoltál. Alapból benne van a K-4.9.58 és lehet is telepíteni x86-64-es progikat, de a képen láthatókat kapom. Az ISO-t feltettem ....proba2... Pae huge-val indul.

K-4.9.58.jpg (338.86 KiB) Megtekintve 4745 alkalommal

64 bites csomagok telepitese.jpg (317.32 KiB) Megtekintve 4745 alkalommal

[nocsak]

"ha egy i686-os rendszert tudsz futtatni, akkor az még nem garancia hogy az i686 tud futtatni 64-et hiába 64-es a kernele?"
Hangzott az imént a kérdésem. És Igenleges választ kaptam. Úgyhogy nem erőltetem a témát, de van egy jó mondás erre, nem szó szerint idézve, ha valaki nem megy a hegyhez, majd a hegy megy valakihez. De ez már az én szóló projektem lesz.

Most a ticoo1 féle Xenial alól vagyok tegnap óta nyúzom. Elsőre semmi gond, talán majd a palemoon-t és a firefoxot, és az apulse-ot amiből ha jól veszem ki, majd fordítok rá, ahhoz kell a libkorrigáló ff és pm szkriptek. Elvileg meg van a kernel forrás, és a 7.5-ös xenial 64 devx is. Beírtam terminálba, hogy sfsget és igén érdekes dolgokat találtam köztük egy nvidia_firmware.sfs-t... mert ugye én nagy elánnal anno póbáltam fordítani nvidia drivert 64-es xenialra, de akkor még nem voltak benne a 32 bites libek. Jelen pillanatban itt tartok... majd hétvégén talán tovább jutok.

Update: Mivel a 32 bites libek benne vannak ebbe a xenialban, így tettem egy próbát, vettem az LX7 alatt fordított apulse petet, felraktam, vettem az LX7-re készített firefox 61.0.2-es petet, felraktam, mennek. Alakul...

[ticoo1]

'nocsak", most valószínűleg egy rakás hüleséget fogok írni.

Szóval, ugye a 64 biteseknél úgy van, hogy pl. /lib és lib64 link ami a /lib-re mutat. Jelenesetben az Lx-ben a /lib egy 32-es könyvtár. Na mármost az kellene, hogy ez 64-eshez passzoljon, mivel a /lib64 link ide mutat és a progik is itt matatnak. Ha az LX /lib-ét átpakoljuk /lib32-re, akkor "kakukk". De "kecske-káposzta" alapon ezt a problémát talán úgy lehetne megoldani, hogy a 64-es "sima" /lib rejtett legyen --/.lib. Ebben az esetben az LX 32 bites /lib-je megfér a /.lib-bel, vagyis ott van a gyökérben (tudom, hogy az usr-ben is, de most e gondolatban semleges, mivel analóg a gyökérben lévővel), kipróbáltam, megfér. Ott buktam el, hogy nem tudtam egy olyan linket csinálni, /lib64, ami a /.lib-re mutasson. Ha ezt meg lehetne csinálni, akkor szerintem itt az LX-ben is működne a 64 bit, hiszen remekül elkülönülnek egymástól! Az eredeti 32-sek keresgélhetnek a helyükön és a 64 bitesek is megtalálják a sajátjukat, mivel a /lib64 link oda irányítja őket (/.lib)! Fontos, hogy az usr-ben megcsináljuk ue. Tudom egy-két programnak is meg kell magyarázni, hogy a közvetlen elérés /.lib-ben van. De ez valóban csak egy hüle elmélkedés..., én elbuktam vele...