CodeWeavers Google Chrome böngészőt csomagolt Linux-ra és Mac OS X-re

Intel

A CodeWeavers-es srácok úgy gondolták, hogy nem várják meg a natív linuxos és OS X-es Google Chrome megjelenését, hanem egy majd' két hetes kísérletezés eredményeként elérhetővé tesznek egy Wine-ra épülő csomagot. A kísérlet egyik célja az volt, hogy megvizsgálják, hogy mennyire kiforrott a Wine, azaz, hogy mennyi idő alatt lehet egy modern Windows alkalmazást átültetni Linux-ra vagy OS X-re.

Chromium Ubuntu-n

A CodeWeavers csapat elérhetővé tette a Chromium-ot az összes modern Linux disztribúcióra és az Apple Mac OS X 10.4 vagy újabb operációs rendszerére.

A stuff letölthető:

Apple Mac OS X (Intel)

Linux

Természetesen ez a kiadás messze van a tökéletestől, inkább amolyan technikai demóként fogható fel.

A részletek itt olvashatók.

( trey | 2008. 09. 16., k – 12:47 )

Sokat ne várjon tőle senki, lassú mint a bűn.

--
trey @ gépház

( Csigaa | 2008. 09. 16., k – 13:11 )

A kísérlet egyik célja az volt, hogy megvizsgálják, hogy mennyire kiforrott a Wine, azaz, hogy mennyi idő alatt lehet egy modern Windows alkalmazást átültetni Linux-ra vagy OS X-re.

Wine != átültetés (eredeti szövegben 'porting', hát persze, ROFL)... legfeljebb átgányolás, vagy félmegoldás lehet a megfelelő szó.

szerk: ja jó, az "eladjuk neked a wine-t sokpénzér" CodeWeavers csinálta. Akkor nem lepődtem meg...

1. Közvetlenül támogatni a wine fejlesztését nem lehetne? De igen! (jó, a transgamingnél tényleg jobbak, de asszem nem a legmocskosabb szemetek kéne a mérce legyen)
2. Ez a chrome "portolás" még viccnek is rossz. Ennyi erővel a MS Office is natív linux alkalmazás (elindul CX-el, csak pár helyen fagy, azokra nem szabad kattintani ;) )...

Az Apple support kényelmes a MS-nak, mert nem okoz neki nagy piaci hátrányt, viszont lobogtathatja, hogy ő bizony multiplatform szoftvereket fejleszt.

A kötött és durván túlárazott hw miatt Maceket nem fognak irodákban, kormányhivatalokban használni, így a nagy tételű OS megrendelésektől nem esik el, a pár idióta amcsi ill. dúsgazdag fanatikus meg annyira nem számít (ők elég, ha a Mac Office-szal termelnek nekik hasznot)

wine-ra szvsz semmilyen formában nincs szükség, natív kereskedelmi alkalmazásokra lenne.
Ha már valamit ezzel kell futtatni, abból konstans szívás és windows telepítés lesz napokon belül úgyis.
Ha nem létezne, pár csakazértislinuksz fanatikus megspórolna magának álmatlan éjszakákat.

Az lehet, de amig nincsenek, addig is melozni kell valamivel. Es jobb, mint a semmi. En speciel orulok, hogy vannak es jobb munkat vegeznek, mint a Transgaming es a Wine team. Megha az o munkajukra is epitik a szolgaltatasukat. Volt mar par eset, mikor kisegit a cuccuk.

---
pontscho / fresh!mindworkz

esetemben, egy "mókás" szitu miatt pl szívesebben használom a wine-t, mint a windowst.
konkrétan a star wars galaxies-ról van szó, ez egy mmorpg játék. a játék hibátlanul fut wine-al (alap esetben csak wine swg_clientr.exe és megy, 1-2 apróság miatt nem árt wine.conf-ot túrni).
a mondandóm lényege, hogy az swg-t fejlesztő soe (sony online entertainment) sikeres patcheinek köszönhetően windows-on játszhatatlan a játék (persze nem mindenkinek, "csak" pár százalék, épp ezért szarnak is rá....). sok játékosnak xp esetén loginnál, vagy a játékban 1-10 perc után crashel a játék (nekem az utóbbi a jellemző, bár 1-2 napig átéltem a login->crash szitut is). vista picit szerencsésebb, ott logout esetén crashel (az ugye annyira nem zavaró). persze a telepített windows rendszerre is lehetne fogni, de nem hinném, hogy a hiba ott keresendő. igaz, én nem tettem újra (lévén nem a windowsomat érzem hibásnak, drivercseréig mentem el maximum), páran megtették, de az új telepítésű windows sem orvosolta a helyzetet.
a poén, hogy wine-al egyik hiba sem jelentkezik, a játék fórumán ezt páran jeleztük is, hogy wine-al egyik crash sem jelentkezik, akkor pár jogosan dühös játékos megnézte wine-al, náluk is teljesen hibátlan így a játék.

ez nem egy wine4tw post, csak érdekesség miatt írtam. soha nem gondoltam volna, hogy azt mondhatom, hogy egy alkalmazást wine-al futtatva kevesebb nyűgöm lesz mint windows alól.

Meg kell mondjam oszinten, a porting se jo szo, mert ugye az azt vonna maga utan, hogy belenyulnak az illeto app forrasaba (bar itt a lehetoseg adott lenne, ugy gondolom nem eltek vele).

Ha a te gondolatmenetedet vesszuk alapul, az egesz wine amugy is csak egy ganyhalom, tessek windows-t hasznalni windowsos programokhoz. Hat nem is tudom...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mivel a két rendszer már az object file formátumtól (ELF vs PE) kezdődően gyökeresen különbözik, erre nincs sok esély.
Vagy arra gondolsz, hogy a távolról sem teljes, távolról sem stabil, visszafejtett Windows API wrapperrel (wine ugye) működne? Megint visszajutottunk oda, hogy 1. az mitől linux alkalmazás 2. a wine-nal kevés kivételtől eltekintve csak baj van.

Amúgy összesen 1 db hivatalosan wine-al is tesztelt, ezt figyelembe véve fejlesztett és valóban működő program létezik, ez a uTorrent bittorrent kliens... A többire azért nem írják rá mert nem is veszik a fáradságot (és a reset gomb kopást, durvább esetben ;p) hogy kipróbálják wine-nal linux/*bsd/solaris alatt, ugyanis legtöbbször a mázlin és az épp beküldött patcheken múlik, hogy az aktuális wine viszi-e, vagy éppen megint broken státuszú mert új bugot tettek bele, vagy abszolút használhatatlan még mindig. A fejlesztőnek rengeteg idő, töredék megtérüléssel, úgyis a legtöbb (normális) ember Windowsos programot Windowson használ. Ha Linux/BSD/Solaris platformra fejlesztik, majd akkor azon fogják tesztelni.

Nem igazan ugyanaz. Mivel az utobbi esetben a binarist egy "vm"-ben futtatja, addig az elobbi esetben nativan fog futni. Mivel van egy wrapper, ami a kodban hasznalt API hivasokat alakitgatja. Az mar mas kerdes, h a wrapper minosege szar, az okot lehet fejtegetni, de az most ugyis lenyegtelen.

---
pontscho / fresh!mindworkz

( 2Geza | 2008. 09. 16., k – 13:17 )

Debazmeg, ennek mi ertelme van? Ez a software engineering legalja.

( psc | 2008. 09. 16., k – 13:57 )

"A kísérlet egyik célja az volt, hogy megvizsgálják, hogy mennyire kiforrott a Wine,"
Van még hova fejlődni. Mondjuk futni fut, tehát végülis jó eredményt kaptunk, csak bűn lassú, illetve valamit ki kéne találni, hogy ne Pistás kinézete legyen az aablakoknak/controlloknak, hanem legalább hasonlítson a gazdarendszerre.

a wine widgetjeinek a kinézetét lehet állítani, azt hiszem van pl. ubuntus téma alá... De a google hülye custom widgetjeivel felteszem nemigen lehet mit kezdeni... 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

emlékeim szerint az ubuntus témát is le kellett rántani valahonnan ... valahol olvastam, hogy deviantartról lehet szedni témákat a windowshoz, nekem személy szerint ennek ellenére nemigen sikerült demóznom a dolgot.

Ellenben azt is olvastam, hogy a témák ...ra lelassítják a wine-t. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( lilo v | 2008. 09. 16., k – 14:35 )

Csak egy költői(!) kérdésem lenne:
- Minek?

:)

néha nem árt, ha a google által gányolt webkit motorral is meg lehet nézni egy weboldalt linux alól — ergó tesztelésnek szerintem jó. Már ha nem ugyanúgy fut, mint az ie6 asszem, ami wine alól futva mást mutatott nálam, mint win alól:D 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

1. ha nem módosított volna, nem küldene kódot bele.
2. a javascript motorja pl. végképp tökmás, webkitesek felteszem még mindig szenvednek vele, hogy beledrótozzák opcionálisan.
3. úgy rémlik, hogy a különféle webkitek (qt, gtk, stb) egymás közt sem teljesen ugyanolyanok. Minden esetre jobb híján midorit használok a webkites tesztelésre. (az egyébként egyre jobb) 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( kmARC v | 2008. 09. 16., k – 15:26 )

Proxy, proxy, proxy. Mindig ezzel van a gond. Nem tamogatja a chromium wine-os valtozata, mivel a wine sem, a pidgin segfaultol a gnome-os proxy settingtol, a dropbox sem mukodik a proxynk mogul, a googleearthnel is hekkelni kell... ahh... es meg az iwiwes terkep sem megy innet... bezzeg windowseknal, ahol erre is van api, hja.

No mindegy.

No igen. Ezert lenne jo pl. rendes halozati profil-tamogato API linux ala (dhcp, dns, http(s) proxy, smtp, egyebek, ne csak az interface beallitasai, hanem bizonyos alapveto halozati szolgaltatasok beallitasai). Win alatt meg ott a registry, abban tarolodik a system-wide proxy, mindenki aki akarja, azt hasznalja. Chrome es Safari helyesen meg is teszi. FF, Opera nem.

$http_proxy ill. $https_proxy környezeti változókat szokták figyelni Linuxban (*NIX-ben? FIXME) a programok. Ezeknek a beállításait még a KDE(!!) is átveszi.
Más kérdés hogy a FF nem. De az semmilyen rendszeren sem foglalkozik ilyesmivel...

SOCKS proxyra meg használható a tsocks transparent wrapper.

a $http_proxy ill. $https_proxy ill. $ftp_proxy ill. $no_proxy nem eleg.

Gondolj bele: ha mar el a rendszer, fut az X, a KDE4, a whatever rajta, es lehal idokozben a proxy1.xxxx.xx es meg kell mondani a programoknak, hogy a proxy2.xxxx.xx-t hasznalja. Kilepsz grafikus feluletrol (MELYTERMINAAAAAL), atirod valamelyik rc.conf-ban, visszalepsz? Netan ujrainditod a gepet?

Megiscsak jo lenne az az api.

( vector | 2008. 09. 16., k – 16:33 )

A wine és cx fejlesztésnek az a lényege, hogy aki használja kb 1 hét után rájöjjön. hogy semmi értelme win alkalmazást futtatni. :)

----- www.blackpanther.hu -----

( kikke | 2008. 09. 16., k – 23:53 )

Attól tartok ez lesz a hivatalos megoldás is, lásd Picasa.
=]