A Debian 7-tel érkezhet a multiarch támogatás

Debian

Alexander Reichle-Schmehl minap küldött levelében az olvasható, hogy a 2013-ban érkező Debian 7 "Wheezy" kiadási céljai közt szerepel a multiarch támogatás. Részletek itt. A hivatalos bejelentés itt olvasható.

( utpKabel | 2011. 07. 27., sze – 23:09 )

"[Multiarch] in the future will even allow live migrations from 32-bit to 64-bit systems."

( bervi | 2011. 07. 28., cs – 04:31 )

a virtualizáció korszakában abszolút nem látom ennek értelmét...

Nem tudom, én használom (Fedora 15), és néha nem árt(ana, ha rendesen megcsinálták volna, hogy a glib 32 és 64 bites csomagja ne ütközzön).
Minek indítsunk egy program kedvéért külön virtuális gépet külön OS-sel, stb.

Mondjuk egy Xilinx fejlesztői környezet (amiből persze van 64 bites, de a példa kedvéért jó lesz) egy óriási nagy dög, abszolút számít minden bytenyi szabad memória. És akkor sokkal jobb, ha nincs mellette virtuális gép, másik OS, stb.
Meg van olyan hardver, ami nem virtualizálható. De egyes programok azért használnák. Szóval nem hülyeség, ha van.

Hát, a fejlesztői részről tényleg sok a szenvedés, ezt elismerem. De ha működik, akkor már inkább ez, mint egy virtuális gép. Tudom, a hardverhozzáférés is megoldható lenne pci passthrough segítségével (xen vagy mittoménmi használatával), de azért ne bohóckodjunk már.
Tudtommal egyébként a windows tudja rendesen kezelni a 32 bites programokat. (Habár abból volt már bajom, hogy a 64 bites windows I:\ meghajtónak nevezi azt, amit a 32 bitesek C:\-nek feltételeznek alapból...).

Desktop felhasználásnál a virtualizáció sem old meg mindent, például 3D grafika. Azért fusson fele fps-el egy game mert csak 32-bites változat van belőle és az os 64-bites?
Jó lenne ha más architectúrák is mennének így. Például el lehetne indítani az androidos arm alkalmazásokat. Az x86 procik gyorsabbak annyival az arm-oknál ami pótolja az emulációs veszteséget.

istenem... tudod mit? inkább hagyjuk. nem akarlak téged összezavarni ilyenekkel, mint pl. a 32bit-only wine, zárt forrású, 32 bites programok, cross-compiling, tesztelés, stb... a lényeg, hogy játszhassunk sparc-on androidos játékokkal, sebességvesztés nélkül. mert hát az androidos játékoknak erőmű kell...

32bit-only wine, erről melyik lug mesekönyvben olvastál? :-) Ha szereted feleslegesen szopatni magad, akkor csak hajrá! :-)
Lazán működnek a win32 alkalmazások 64-bites wineon!
A cross-compiling és teszteléstől ne várj sokat, ez most csak egy fő arch-on belül tenné lehetővé 32 és 64-bites binárisok együttes használatát. 64-bites Pc-n elindíthatod a 32-bites linux alkalmazásidat. Ugyanez 32 és 64-bites Mips-en, Sparc-on. De Pc-n nem használhatsz teljesen más architecturát, mondjuk mips-et.
Az osx ennél sokkal többre képes már évek óta.
Ha nem csak játszadozol és hobbiból cross-compilingolsz valamit, akkor úgysem spórolhatod meg a normális tesztelést a célrendszeren.

^^^Ilyen az amikor a butaság határtalan arroganciával párosul.
(bervi azóta is keresi a "sparc" szót a hivatkozott hozzászólásban, de nem találja. Dühében hamarosan anyázni is fog. Bár most, hogy ezt leírtam valószínűleg csakazértsem, más módon szór majd válogatott átkokat :-)

( nice | 2011. 07. 28., cs – 08:50 )

Ez az openSUSE-ban frankón meg van oldva már a neolitikus kor óta.

( kirsa74 | 2011. 07. 28., cs – 11:12 )

kicsit szomcsy, hogy a szarazoesiksz ezt már 6 éve tudja, a fentivel szemben teljesen backward/forward-compatible, és nem szemetel, mint ez ;((((((

> Multiarch is a radical rethinking of the filesystem hierarchy with respect to library and header paths, to make programs and libraries of different hardware architectures easily installable in parallel on the very same system.

igen, természetesen a rosetta ezt a funkcionalitást valósítja meg (nem)

Annyiban mondjuk könnyebb dolguk volt, vagy legalábbis szerintem könnyebb dolguk volt, hogy a Mac (HW és SW is) fejlesztésnél van egy központ, ami megmondja, hogy ezt csináld, és akkor azt meg is valósítják. Ha Linuxhoz alatt kitalál valaki valamit, azt vagy átveszi a többi distro vagy nem. Általában vagy nem.

Ennyiből google segítségével el lehet egyébként indulni.

http://wiki.beszeljukmac.com/mediawiki/index.php/Universal_Binary

Az mondjuk igaz, hogy annak, aki nincs benne (pl. én), ez tényleg nem sokat mond.

Szerk: de azért lássuk be, ez egészen mást csinál. Nem azt, hogy 32 bites program fut 64 biten, hanem egy file tartalmazza mindkét architektúrára a lefordított binárist. Vagy ha tévedek, majd beszólnak.

Pedig tényleg igen, az universal binary-k 32 bites és 64 bites, PPC és X86 architektúrás buildeket is tartalmazhatnak, de Rosetta-val a mindössze PPC-re elérhető alkalmazások is futtatható X86-on.

Mindez transzparensen, a felhasználónak csak el kell indítania az alkalmazást.

Linuxon ez kevésbé kézenfekvő, ha 64 biten akarok egy 32 bites alkalmazást használni, akkor az ahhoz tartozó 32 bites library-ket és minden más dependency-t fel kell tennem (az Arch Linux multilib tárolójával, a lib32-es csomagokkal ez egyszerűvé tehető), és persze a compilerekkel nem lehet universal binary-ket létrehozni.

Néhány hete használok OS X-et egy MacBook Pro-n és azt kell, hogy mondjam, hogy sohasem találkoztam még ennyire nagyszerű operációs rendszerrel és notebookkal, bár most éppen Arch Linuxot futtatok rajta.

Gabucino csak egyvalamiben téved, az Apple nem 6 éve, hanem már legalább 15 éve megoldotta ezt amikor a Motorola processzorokról váltottak.

Szerintem olvasd el, mirol szol a multiarch. Mert nem (csak) errol.

Egy reszet persze lefedi, amit az Apple valoban egy evtizeddel mindenki mas elott megoldott. De az csak egy resze annak, amit multiarch megold. Persze van olyan resze is az apple fele fat binary izenek, amit multiarch nem tud (konkretan, hogy egy binarisban osszegyurja az osszes tamogatott platform kodjat), de ez egyelore nem is celja.

Nagyon egyszeru lebecsulni a multiarchot, ha az ember nem olvassa at teljesen a leirast.

En pl szivesen megneznem, hogy egy inteles macen hogyan forgat az ember ppc-re ugy, hogy a cross-compile csak buildnel fut, configurenal viszont nativan, test suitenal detto. Vagy teszemazt ugyanezt arm-ra, nem pedig ppcre. Mindezt ugy, hogy a mindenfele dependencyket korrektul kezeli.

Ha letezik ilyen megoldas Macre, akkor szoljatok, mert en meg nem talalkoztam vele.

--
|8]

namost, inteles mac -en az ember halal ugyan ugy forgato_tt_ ppc -re, mint ugy allt.
ha fent van az xcode ( ugye az kell mindenhez, ami fejlesztes ), akkor a gcc -nek, kb felsorolas szeruen:
-arch i386 -arch x86_64 -arch ppc

Es kesz a fatbinary.

Azert multido, mert a lion megjelenesevel a PPC tamogatas megszunt ( RIP )

Az erthetoseg kedveert ujrafogalmazom a kerdest:

MacOS-en meg lehet azt csinalni, hogy kb ~3 sor megfelelo configfileba tevesevel megoldhato legyen az, hogy egy teljesen masik architektura libjeit felpakoljam, azokhoz crosscompilerrel forditani tudjak, es a keletkezo binarist (par perc setup utan) futtassam? Anelkul, hogy a host architekturara is lefordulna ez az egesz?

Es hogy a libek ne vesszenek ossze? Es en tudjam megvalasztani, hogy mely architekturak libjei legyenek fenn? Pl x86_64, mert az a host, mellette arm, ppc es sparc? Es kedvemre valogathassak, hogy epp melyik kell?

Es hogy ez az egesz ne zavarja ossze a csomagkezelot?

--
|8]

En pl szivesen megneznem, hogy egy inteles macen hogyan forgat az ember ppc-re ugy, hogy a cross-compile csak buildnel fut, configurenal viszont nativan, test suitenal detto. Vagy teszemazt ugyanezt arm-ra, nem pedig ppcre. Mindezt ugy, hogy a mindenfele dependencyket korrektul kezeli.

Tulajdonkeppen siman. Van komplett build frameworkunk ami ezt oldja meg opensource libek jujuj tipusu autoconfjaval es automakejevel is.

---
pontscho / fresh!mindworkz

( bert750 | 2011. 07. 30., szo – 18:29 )

aki nem tudja eldonteni milyen archot hasznal, mehet a hivatalba. ertelmetlen.