Tesztelhető a Moonlight 4 Preview

Novell

A Novell tegnap sajtóhírben jelentette be, hogy elérhető tesztelésre a nyílt forrású, linuxos Silverlight implementáció, a Moonlight legújabb előzetes kiadása. A bejelentés szerint a Moonlight 4 preview a Mozilla Firefox és Google Chrome felhasználók számára elérhetővé teszi Linux-on a legújabb Silverlight tartalmakat. A Moonlight 4 béta letölthető innen. A bejelentés itt.

( trey | 2011. 02. 16., sze – 08:10 )

Használja innen valaki aktívan a Moonlight-ot?

--
trey @ gépház

Igen, nagyjabol csak erre hasznaljak, ami jol mutatja az atlagos webfejlesztes fantaziadussagat :). Azert pont videolejatszas, mert a Microsoft ezzel demozta az elejen a platformot (ugyes savszelessegmenedzsmentet tud).
Apro RIA-k eseten a Flash / stb. ugyanolyan jo lehet, komplex webalkalmazasoknal tudna sokat mutatni, de a fejlesztok meg felnek egy megaprojektet egy nem elegge elterjedt platformra alapozni.

Szoval szerintem a weben buko lesz, bar mint technologia kivalo. Lattunk mar olyat, hogy igy alakult a technikatortenet. :)

----------------------
while (!sleep) sheep++;

"Szoval szerintem a weben buko lesz, bar mint technologia kivalo. Lattunk mar olyat, hogy igy alakult a technikatortenet. :)"

+1, ha valami a weben celba akar erni, akkor ahhoz minimum a php/html platformfuggetlensegi szintjet kell mutatnia, az Adobe is ezzel szenved miota, hogy minden mobil platformra is legyen vegre villanaslejatszo (ezert panaszkodtak az API jungle-okre is). Nos a Microsoft ezt a cirkuszt nyilvan sosem fogja vegigjatszani a Silverlighttal, vannak platformok, amikre meg eletukben nem is fejlesztettek es elvbol nem is fognak. Az eleg lenne, hogy Desktopon tamogatja a Wint meg az OS X-et, de a mobil bongeszesbe mar most beletort a bicskajuk (youtube-ot, vimeot, stb.-t meg pl. mar miota lehet mobilrol nezni, lassan HTML5-ben is)

Jogos :) de arra irtam, hogy szerintem nem maradsz le semmirol. En csak a telerik.com, channel9.msdn.com stb helyeken talalkoztam silverlight-tal, de ezek meg direkt sl ill. ms fejlesztoknek szolo anyagok :)

Linuxot csak szerveren hasznalok egy ideje, de azelott sem neztem a moonlightot. Lehet, hogy kivancsisagbol megnezem, hogy egy ket speci sl-es megoldast, hogy vesz le :)

Használtam már párszor, ritkán rtlmoston, budapestgameshow honlapján is működött 2.x miatt marhalassan, egy-két honlapon is előfordult, és most megnéztem ezt a 70 Billion pixel Budapestet amit itt linkelt valaki. Most épp a 3.99-es moonlight- al valamivel gyorsabb mint eddig, de még így is lassú.
Meg lennék nélküle, de ha már van akkor miért ne.
--
AGA@
Clyde Radcliffe Exterminates All the Unfriendly Repulsive Earth-Ridden Slime

Akadozik, de nézhetetlenül. Sőt, van hogy a kép teljesen meg is áll.
Ugyanebbe a virtuális gépbe próbáltam 1080p h264-es mkv-t, hát nem volt 30 fps, meg amikor nagyobb változás volt a képen, bedarált-beakadt, de vitte... Azt mondta az illetékes, hogy valószínűleg azért, mert ez stream, ennek még nagyobb az erőforrás igénye (a stream elvileg szintén 1080p, bár megvallom őszintén, a múltkor nem néztem meg). Az volt a javaslat, hogy telepítsek natívan windózt.
--
Discover It - Have a lot of fun!

( uid_18247 | 2011. 02. 16., sze – 09:43 )

mi mindenre lenne használható ez a platform, ha tényleg megérné felhasználni? miért nem éri meg jelenleg tömegesen használni? merre fejleszthető, hogy jó legyen? milyen roadmap viheti süllyesztőbe? (az utolsót pontosítva: hogyan lehet tönkretenni a platformot?)

Amit én láttam SL, az egy ügyviteli rendszer volt, de az ott úgy lett megoldva, hogy WPF-ben és SL-ben is működjön a felület. Vagy pl. a webaudit oldala is SL, bár tudnám minek.

Személyes véleményem az, hogy nem lenne az SL rossz, csak egy rakás alapdolog hiányzik belőle és hogy nem kellett volna külön frameworkot használni, hanem mehetett volna a rendes .NET FW-re.

(Szakdogánk .NET-s, egyik barátom akarta csinálni SL-ben a felületet, kb. ez volt a legelső komolyabb változtatás az eredeti koncepciótól, hogy SL helyett WPF)

----------------
Lvl86 Troll

Kedves "saxus"!

Azt írtad fentebb, hogy: "egy rakás alapdolog hiányzik belőle és hogy nem kellett volna külön frameworkot használni, hanem mehetett volna a rendes .NET FW-re"

A Silverlight-ban (és a Moonlight-ban is) a .NET/Mono Framework funkcionalitásának csak a töredéke található (6.1 MB-ba amúgy se sok minden férne bele). Ez azért van így, hogy a Plug-in minél gyorsabban letöltődjön a felhasználó gépére - egyszer, először és utoljára.

A Silverlight gyakorlatilag részhalmaza a .NET Framework-nek. Benne vannak az alaptípusok, a Framework Class Library lényege, multimédia, grafika, animáció, felhasználói felület vezérlők, XML-kezelés, hálózati kommunkáció, WCF webszolgáltatás hívás, biztonsági felügyelet. A Silverlight csak funkcionalitásában és kompatibilitásban közös a "nagy" Framework-kel, a kódbázisa nem (vagy csak nagyon kis mértékben). Ugyanis rengeteg dolgot erősen optimalizálva vagy lecsontozva kellett megvalósítani, újraírni.

Nálunk intenzív használatban van, de nem multimédiára (az ugyanis nem érdekes), hanem gazdag felhasználói felülettel rendelkező, többrétegű, elosztott üzleti/ügyviteli alkalmazások fejlesztésére, melyek böngészőben vagy attól függetlenül (out of browser módban) működnek.

Sokan azt hiszik a Silverlight/Moonligh = videó lejátszás. Súlyos hiba ezt gondolni, mert ennél sokkal-sokkal több. A Silverlight olyan, mint egy homokozó, a vele készített (főként intranet/RIA vagy vékony kliens alkalmazások) felhasználói felülete minden böngészőben, tehát IE, FF, Chrome alatt és azon kívül is pontosan ugyanúgy működnek és ugyanúgy néznek ki. Nem függünk a böngésző szeszélyétől (valójában a böngésző csak azért van, hogy elindítsa a Silverlight alkalmazást).

A Silverlight alkalmazás (ami nálunk valójában csak a felhasználói felületet és a háttérkomponensekkel való kommunikációt jelenti) az első használatkor letöltődik a webszerverről a kliensre úgynevezett "xap" (zap) fájl formájában. Ez a fájl ZIP formátumú és bele vannak csomagolva a felhasználói felületet alkotó .NET szerelvények, erőforrások, egyebek. Legközelebb már csak akkor töltődik le a szerverről (automatikusan), ha a GUI változik és a kliensen régebbi van, mint a szerveren.

Egy Silverlight alkalmazásnak csak a kliens gépen lévő fájlrendszer egy meghatározott és elkülönített területére van joga írni, melynek neve: Isolated Storage, és a méretkorlátja kezdetben 1 MB (out of browser módban 20 MB). Ha ennél több hely kell vagy ha az Isolated Storage területen kívülre is kellene írni/olvasni, akkor a Silverlight Plug-in automatikusan kéri a felhasználó engedélyét hozzá (kikerülni nem lehet). Azonban a helyi merevlemez írását/olvasásást csak a felhasználó által birtokolt helyekig lehet kiterjeszteni (Windows-on ez a saját dokumentum könyvtár, stb). Engedélyt kér akkor is, ha az alkalmazás szeretné a gépen lévő mikrofont vagy a kamerát bekapcsolni.

Természetesen más opciók, lehetőségek, optimalizációk is vannak, de idő hiányában a további magyarázatot későbbre halasztjuk.

A fejlesztői csoportom és jómagam (összesen nyolcan vagyunk) szeretjük a Silverlight-ot - és nem a multimédiás képessége miatt. Csekély mérete ellenére elképesztően sok programozási lehetőséget tartalmaz és egy jól átgondolt infrastruktúra van mögötte. A felhasználói felület definíciója XAML (XML) nyelven van megfogalmazva, a hozzá tartozó mögöttes logika pedig C# (vagy bármely más .NET nyelven), így a fejlesztése és a fejlesztői környezete - kis túlzással - nem sokban különbözik a hagyományos .NET alkalmazástól. Tökmindegy, hogy vastag, vékony, webes vagy mobil kliens (Windows Mobile 7), a Silveright-os alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak.

További információ:
- Silverlight demó alkalmazások (ha mást nem, ezt mindenképp érdemes megnézni)
- Silverlight vezérlők demója
- A legjobb Silverlight programozási könyv (angolul)
- Silverlight programozási könyv (magyarul)

Köszönöm a figyelmet.

Jó munkát, jó egészséget!

Üdv,
PutAbout

Java alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak.
JavaScript alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak.
Flash/AC alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak.

"Java alkalmazást mindegyik platformra ugyanúgy kell készíteni."

Java SE vs. Java ME?

"JavaScript alkalmazást mindegyik platformra ugyanúgy kell készíteni"

Aha, touchscreen-en általában az onmouseover, onmouseout nincs értelmezve általában (ellenben pl. iPhone-os Safariban vannak touchscreen specifikus események), hogy csak a legtriviálisabb különbséget említsem. Arról nem is beszélve, hogy a javascript alá kell egy html oldal, amit minden browser máshogy kezel.

"Flash/AC alkalmazást mindegyik platformra ugyanúgy kell készíteni."

Flash vs. Flash lite vs. iPhonoe?

--
Don't be an Ubuntard!

"Java SE vs. Java ME?"
ez nagyon gyenge érv. Java ME mobitelefon kategória, a Silverlight a mobilok hány százalékán támogatott? szerencsétlen Symbian kinyírásával, most gyorsan csökkenni fog ez az arány:) egyébként a symbianos silverlight sem épp problémamentes.
megjegyzésként, a Java ME már a múlt. Dalvik lépett a helyébe, ami forrás kompatibilis a Java SE alkalmazásokkal. de ez itt most mellékes.

"Aha, touchscreen-en általában az onmouseover, onmouseout nincs értelmezve általában (ellenben pl. iPhone-os Safariban vannak touchscreen specifikus események), hogy csak a legtriviálisabb különbséget említsem. Arról nem is beszélve, hogy a javascript alá kell egy html oldal, amit minden browser máshogy kezel."
megint egy mobilt hoztál fel. iPhoneon hogyan működnek a Silverlight alkalmazások?:)

"Flash vs. Flash lite vs. iPhonoe?"
akkor újra:D megint egy mobilt hoztál fel. iPhoneon hogyan működnek a Silverlight alkalmazások?:)

a Moonlight pedig egy vicc, méghozzá egy nagyon rossz vicc. az RTLMost n.edik nekifutásra MOST sem működik, a Moonlight 4 Previewal sem. néhány kitartó próbálkozónak sikerült néha véletlenül elindítania ott egy videót, amit általában a következő Moonlight update agyonvágott. hát ennyire működnek minden platformon ugyanúgy a Silverightos alkalmazások.

Azt nem írtad, hogy milyen platformfüggetlenségről beszélsz. PutAbout pedig így írta: "Tökmindegy, hogy vastag, vékony, webes vagy mobil kliens (Windows Mobile 7), a Silveright-os alkalmazást mindegyik platformra ugyanúgy kell készíteni." Ebből nekem az következik, hogy vertikális platformfüggetlenségről van szó, és én is aszerint válaszoltam.

--
Don't be an Ubuntard!

a Windows Phone7 jelenleg a Bada mögött a 6odik 1.5%os piaci részesedéssel. az elődje a Windows Mobile ha jól emlékszem 2.4%al exitált. ennyit a mobil kliensről. webes kliensen nem tudom mit értesz? ChromeOSen biztosan nem lesz Silverlight támogatás, és a mostani tablet dömping egyik bajnok OSén, sem az Androidon sem az iOSon nincs Silverlight. gyárt még valaki tabletet Microsoft OSel? mert egy évtizede próbálkozik a MS, ennek ellenére 1%ot sem érik el a Ms tablelek a piacon.
így a "vastag és vékony kliens" ugyanazt a PC platformot jelenti asztali, notebook és netbook kivitelben. ezért a "vertikális platformfüggetlenséged" érdemben csak desktoptól a netbookig terjed.
ezen a tartományon belül egy szót nem szólhatsz a JavaScriptre, mert JS alkalmazások detto ugyanúgy működnek Desktopon, mint netbookon:) sőt nemcsak windows os platformon, hanem Linuxon, OSXen, Free/net/open/dragonflyBSD és Solarison is:)

ilyen erővel a Python, Ruby és társai is beleillenek a "FOO alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak" jelmondatba:) hiszen vannak linuxos eszközök mobil, tablet, webes, vékony és vastag kliens kiszerelésben is:) tökéletes vertikális platformfüggetlenség!

fogalomtisztázás a linkelt írásod alapján,
"Azt nem látod, hogy két típusú platformfüggetlenség van, nevezzük mondjuk horizontálisnak és vertikálisnak. Előbbi esetében a hardware platform legyen fix, és csak a software platform változzon (például fixen pc platform, és az os-ek változnak), utóbbi esetén a hardware platform se legyen fix (például pc, mobiltelefon, konzol)"
tehát a Microsoft Silverlightja csak horizontális platformfüggetlenségben jeleskedik. mobilon és tableten minimális a MS jelenlét. Xbox360 konzolon nincs Silverlight tudtommal, de fixme.

A vertikális platformfüggetlenségnek nem feltétele a horizontális platformfüggetlenség. Azaz megfelel a definíciónak az is, ha a vertikálisan platformfüggetlen termék egy adott platformon csak olyan eszközökön fut, melyek piaci részesedése az adott platformon elenyésző.

Konkrét példa: tegyük fel, van egy cégem, és egy céges rendszert az összes beosztottamnak használnia kell. Ezért én akarok egy olyan kliensprogramot, ami elfut a munkaállomásokon, a céges telefonokon, meg elérhető webböngészőből is végszükség esetén. Mivel én adom a munkaállomásokat is, a céges telefonokat is, engem egyáltalán nem fog érdekelni, hogy például a céges telefonokon nem a legelterjedtebb okostelefon platform (android?) fut, hanem mondjuk a jelenleg egyik legkevésbé elterjedt (windows phone 7). Persze itt feltételezzük, hogy egyelőre nem adtam még semmilyen eszközöket a beosztottjaimnak, mert ha adtam volna, azok esetleges lecserélésével jobban megnövelném a költségeket, mint külön kliensprogramok kifejlesztésével.

--
Don't be an Ubuntard!

ez természetesen nézőpont kérdése, de ebben az esetben a második bekezdésben írottak abszolút érvényesek, azaz
ilyen erővel a Python, Ruby és társai is beleillenek a "FOO alkalmazást mindegyik platformra ugyanúgy kell készíteni. Óriási könnyebbség ez a programozónak" jelmondatba:) hiszen vannak linuxos eszközök mobil, tablet, webes, vékony és vastag kliens kiszerelésben is:) tökéletes vertikális platformfüggetlenség!
természetesen továbbá Java, JS, Flash ebben az esetben is.

a windowsal szemben a linux valóban jelen van vertikálisan minden platformon routerektől supercomputerekig, illetve mivel itt elsősorban usereknek szánt interaktív alkalmazásokról van szó, mobiloktól desktopig. és itt ugyanarról a linux operációs rendszerről van szó, nem két különböző rendszerről, amiknek csak a nevük hasonló, windows7/windows phone7.

"Persze itt feltételezzük, hogy egyelőre nem adtam még semmilyen eszközöket a beosztottjaimnak, mert ha adtam volna, azok esetleges lecserélésével jobban megnövelném a költségeket, mint külön kliensprogramok kifejlesztésével."
sőt az sem utolsó szempont, hogy csak néhány gyártó kevés és általában magas árazású modellje között válogathatok, vagy egy sokkal szélesebb termékpalettáról. Android már alsóközép árkategóriában is jelen van, rengeteg gyártó számtalan modelljéből lehet választani.
így jelen körülmények között a költségeket figyelembe vége, és a jövőt is szemmel tartva a JAVA az optimális választás. minden PC hw alapú platformon elérhető, sőt mellesleg más hw platformon is elérhető, böngésző pluginként is rendelkezésre áll. Androidra jóformán csak újra kell fordítani, ennek minimális költsége jóval alatta van annak, amit a széles Android mobilkínálaton nyerni lehet, pláne akkor ha már egyébként is vannak Android telefonok a cégen belül.

továbbá megfontolandó szempont az a körülmény, hogy a Microsoft közelmúltban két mobil platformot is dobott. ebből a windows mobile sok céget érzékenyen érintett. amikor a MS 2003ban áthozta a PDA rendszerét mobilra, sokan gondolták a PC múlt miatt is, hogy ott is tarolni fog. és egy darabig második is volt a Symbian mögött az elemzőcégek első helyre várták a WinMobilet domináns részesedéssel, sok vállalat fejlesztett céges alkalmazásokat WinMobilera. most jól megszívták, amikor a Microsoft megtörte a Windows Phone7el a kompatibilitást. ezt nem fogják elfelejteni sok cégnél.

Azt felejted el, hogy a linux csak kernel szinten van jelen mindenhol, a rá épülő libek korántsem annyira platformfüggetlenek vertikálisan. Például ha androidon is akarod futtatni az appod, már eleve csak java-ban gondolkodhatsz, de a desktopodon egy java se nem lesz elég az alkalmazás futtatásához, ahhoz kell az android for x86 is. Persze, ez így megoldható, bár nem esküdnék meg, hogy az android for x86 sokkal jobban áll, mint a moonlight, azaz nem production-ready.

--
Don't be an Ubuntard!

az előbb csak ezekről volt szó,
Java, JS, Flash, Python, Ruby és tsi. ott konkrétan gnu/linuxra gondoltam, így lett volna pontos a megnevezés, ezért jogos a megjegyzésed.
a Pythonos részben volt azért némi irónia, a WP7 marginális piaci részesedésére utalva. akkor már a Maemo gyakorlatilag Debian/Arm, illetve a Sharpnak és más távolkeleti cégeknek is vannak mini/mobil méretű gnu/linux cuccai.
ezeken ugyanaz a userland érhető el mint asztali gnu/linuxon. a python, ruby stb pedig hw platform függetlenek.
Androidon nem csak Javaban lehet gondolkodni, amióta van ndk.
desktop java pedig 99% forráskompatibilis az Androiddal, ezért minimális költségű újrafordítás esetén, nem kell Dalvikból x86 port az átjárhatósághoz. egyébként most, hogy a Nokia pálfordulásával cserben hagyta az Intelt, igen valószínű, hogy ők ezek után a MeeGo helyett az Android x86ot fogják tolni, már korábban is bejelentették készít az Intel x86 portot. ezért várhatóan felgyorsul az Android x86 projekt fejlesztése.

a Moonlight pedig egy vicc, méghozzá egy nagyon rossz vicc. az RTLMost n.edik nekifutásra MOST sem működik, a Moonlight 4 Previewal sem. néhány kitartó próbálkozónak sikerült néha véletlenül elindítania ott egy videót, amit általában a következő Moonlight update agyonvágott. hát ennyire működnek minden platformon ugyanúgy a Silverightos alkalmazások.

Ez speciel nem epp a Silverlight sara, tegyuk hozza a korrektseg kedveert.

---
pontscho / fresh!mindworkz

Windows-on, osx-en valoban. Az, h linuxon mit szuttyog a Novell, keves embert erdekel. :) Az elozo ket platform lefogja a desktop rendszerek 95%-at. Van egy olyan sejtesem, h ha akarna a Microsoft meg tudna egyezni az Apple-lel egy MobileSafari plugin elkesziteseben es rogton nem 1.6% lenne az elterjedtsege hanem 1.6+symbian+apple, ami mar eleg merv ado, plane, h ez utobbi "kinyilatkoztatasai" az iparban a valos ertekenel joval nagyobb sulyt kepviselnek.

---
pontscho / fresh!mindworkz

igenam, csak 2011-et irunk, nem csak Windows, Desktop Linux es OS X van, van iOS, Android, Symbian, BlackberryOS, stb (de meg WinMo6 is tobb, mint WP7). Az Adobe egesz jol ki tudja adni rajuk a flash playert, a Silverlight pedig sosem lesz bongeszo szinten platformfuggetlen.

Ezert mondtam fentebb is, amit mondtam

A klasszikus ertelemben vett desktop linux vicc. Az android port valoban erdekes kerdes, az IOS, BOS port pedig ugy sejtem siman megoldhato, leven ez csak ket ceg kozotti megallapodas kerdese. :)

A flash playert pedig inkabb ne keverjuk ide, ugyanis ha az Apple nem kezdi el verni a tamtamot es kurja ki az osx-bol teljesen jogosan (valoban egy nagy rakas szar, ahogy ezt mar itt hupon is sokan kifejtettek, de mivel Jobs mondott ilyet ezert rogton a vedelmebe vette a melyen tisztelt floss kozosseg:) rogton ra tudtak lepni a gazra es ossze tudtak vakarni egy olyan plugint ami nem hanyja ossze magat lepten nyomon. Persze rendes desktop gepeken, a flash for mobile device meg mindig egy nagy rakas loszar amit kerulni kell. Amugy fyi, flash is vm-ben (konkretan llvm-ben) futtatott bytekodot hasznal, mint az sl es a java. :)

---
pontscho / fresh!mindworkz

"A klasszikus ertelemben vett desktop linux vicc".
ha csak a piaci részesedést veszed alapul akkor természetesen igaz az állítás. bár a WP7 részesedése is a desktop linux szintjén áll. a használhatóság szubjektív pláne a hupon, még szenvedélyes hitvitáknak is örökzöld témája. az mindenesetre tény, hogy a WP7 multitaskot nem támogat 3rd party alkalmazásoknál, ami pont érinti a vállalati alkalmazásokat, és copy/paste sincs, tethering sincs, stb. ezek a hiányosságok erősen rontják a WP7 használhatóságát.

Mindezek egy-egy uj fw-ben gond nelkul hozzaadhatoak. Most ne abbol indulj ki amit androidon tapasztalni, h talan a telefon gyartoja meltoztatni fog hosszas konyorges utan (mint pl. ahogy a Samsung csinalja) kiadni egy uj fw verziot ami mar tamogatja ezeket, vagy barkacsolsz magadnak egyet. Normalisabb platformokon egy kattintassal telepitheto gond nelkul az uj fw, nem kell hozza semmi, csak a sajat geped egy net csatlakozassal. Es ahogy halad az ido, fixalni is fogjak, mert pontosan tudjak - mivel a hupos hiedelmekkel ellentetben ott sem hulyek dolgoznak -, h ezekre mar rovid tavon szukseg lesz. Amugy az egyik legletisztultabb es atgondoltabb UI-t a wp7 tudhatja magaenak, meg az iOS-t is veri e kerdesben. Es ahogy a wp7 toreshez az ms legutobb hozzaallt, az szinte pelda erteku.

---
pontscho / fresh!mindworkz

nekem turhetoen mukodik a Flash player az erosen aluleroforrasozott HTC Wildfire-omon is.

Komolyra forditva a szot, jo dolog a Silverlight, de azert bongeszoszinten platformfuggetlen sose lesz meg annyira se, mint az Adobe flash, hat meg egy nyilt szabvany (php/html). En orulok, hogy sokan szeretnek Silverlightban fejleszteni, de tovabbra is fenntartom, hogy bongeszoben _semmi_ keresnivaloja, meg a flashnel is kevesebb. A Microsoft sosem fogja vegigcsinalni minden elbaszott API jungle-lel azta cirkuszt, amit az Adobe meg ugy ahogy vegigjatszott a Flash-sel, mert az Adobe-nak nem volt mas valasztasa, emgirta midnenre a klienst, ha weben eletben akart maradni. Meg WinMo 6ra is van flash player, Androidra is, Maemora is (azon gyonyoruen is mukodott), mindenre lassan, kiveve Apple termekeket

Ennek ellenere Jobsnak igaza volt, hogy azert megprobalhattak volna a hardveres gyorsitast, Linuxon is egyedul nvidia >8000 kartyakon van GPU gyorsitas flash-hez

jo dolog a Silverlight, de azert bongeszoszinten platformfuggetlen sose lesz meg annyira se, mint az Adobe flash

Ebben van nemi igazsag.

hat meg egy nyilt szabvany (php/html).

php meg csak meg sem kozeliti a szabvany fogalmat, az csak egy programozasi nyelv.

En orulok, hogy sokan szeretnek Silverlightban fejleszteni, de tovabbra is fenntartom, hogy bongeszoben _semmi_ keresnivaloja, meg a flashnel is kevesebb.

Muszaki szempontbol pont annyi keresnivaloja van a bongeszoben, mint a flash-nek. Az uzleti szempont mar egy masik kerdes.

A Microsoft sosem fogja vegigcsinalni minden elbaszott API jungle-lel azta cirkuszt, amit az Adobe meg ugy ahogy vegigjatszott a Flash-sel,

Nem tudom... minden .net fejlesztotol azt hallom, h mennyire atgondolt es jol kitalalt api-ja van a dolognak, marpedig az sl ennek egy vadhajtasa.

mindenre lassan, kiveve Apple termekeket

Nem hivatalosan arra is van, a gyakorlatban az elmult 3-4 evben kereken nulla egesz nulla alkalommal hianyzott a flash a telomrol. Legalabb nem szivja horpadra az aksimat. Eleg jo ervei voltak az Applnek a nemre amiert dobta azt a szart. SL-lel kapcsolatban nincs velemenyem, nem futottam bele eleg oldalba ami igenyelte ahhoz, h konkret velemenyem legyen.

Ennek ellenere Jobsnak igaza volt, hogy azert megprobalhattak volna a hardveres gyorsitast

10.2-ben elvileg minden platformra megjelent. De ehhez kellett n+1 ev es egy masik ceg egesz vilag elotti anyazasa... es ez szanalmas. Foleg mert az Adobe premium support is oly annyira hihtetlenul otvar, h szavak sincsenek ra. De mivel Jobs azt mondta ra, h fujj, ezert a kozosseg szemeben rogton vilagmegvalto es perfekt technologia lett. :)

---
pontscho / fresh!mindworkz

ez csak feltételes mód, amiből nem lesz semmi. egyébként is egyszerűbb volna, ha maga a Microsoft is csinálna SL plugint Androidra. azt a Google megkérdése nélkül is berakathatná a platformba a mobilgyártókkal egyezkedve. mégis előre borítékolható, nem fog ilyet tenni a Ms.

Értem én, hogy mi szeretne lenni az SL, de nekünk kellett unsafe kód (nem néztem utána, de a barátom mondta, hogy most már van) és gyors képrajzolás, amire az SL nem volt alkalmas. És én egy szóval nem említettem a videólejátszást. Emiatt végül váltottunk WPF-re. (És igazából örülök, hogy nekem maradt a szerver része, mert az egész XAML+MVVM patterntől kihullott volna a hajam. Egyszer kellett komolyabban belenyúlnom a kliensbe... hát, fájt.)

Az üzleti felhasználását ismerem, említettem is.

----------------
Lvl86 Troll

( nagy_peter v | 2011. 02. 16., sze – 10:07 )

Szerintem nem fog ez sosem elterjedni, mivel a HTML5+Flash szerencsére mindent tud, ami miatt csak szükség lehetne erre.
Bízom benne, hogy ezt az rtlmost-nál is be fogják látni, mert én is nézném néha, de sosem megy...

( prygme | 2011. 02. 16., sze – 14:59 )

az RTLMost most ott akad el, amikor le kellene tölteni a codec packet:) Failed to download EULA, please try again later.
szerencsére nem szoktam nézni az RTLt, TVből sem igen, internetről pláne nem.

Nekem eddig nem mentek az rtlmost-os video-k.
Most viszont megy!!!

Bár hozzá kell tennem, hogy előbb Chromiumban telepítettem a Moonlight 4 prev-et (az alap 32biteset), az leszedte a codekeket, és vitte az rtlmostot, bár kissé pixelesen (1.5 GH centrino duo, nVIDIA geforce 8400M G 256 MB - 2 GB rendszermemóriával 90 %-os proc használat mellett Ubuntu 10.10).

Aztán Firefoxban is megpróbáltam, ott is letöltöttem a Moonlight 4 pre-et, ott már nem kért codekeket, csak újraindítást, és szépen viszi az rtlmost- elsőre. Reklámblokkoló ki van kapcsolva.

És örülök, hogy végre megy. Mert Páromnak emiatt kellett win-xp-t indítani, mert wine alól sem ment korábban az rtlmost.

MOST megy, és örülök.

a 64bites windows átok még linuxon is utolér:) persze csak az olyan "nyúlványain" keresztül, mint a moonlight:)
valószínűleg az a probléma, hogy ez 64bites rendszer, és a codec pack amit le akar tölteni a MStól 32bites. pedig van belőle 64bites változat is, és kézzel le is töltöttem bemásoltam a megfelelő helyre, de úgysem jó.

Hát nem tudom, most újítódik fel éppen az asztali gép, és abban már 64 bites AMD proci van, így most töltődik a 64-bites Magyarubi.... ezek szerint nem lesz alatta akkor a Moonlight működőképes?

Dehát csak 64-bites dukálna rátenni, úgy értem disztrót.
Rosszul gondolom?

a kedvedért most kipróbáltam újra az rtlmostot és most megy. le tudta tölteni a megfelelő codec packot és nézhető is vele. sokat ne várj vele, mert lehet megint elcseszik. még annyit, hogy moonlight plugint upgrade előtt érdemes backupolni, mert volt már rá példa, hogy az upgrade csak elrontott pár dolgot, pl rtlmost.
ha nagy rtl rajongó vagy és az rtlmost musthave, akkor azért ajánlok egy virtuál windowsXPt is a biztonság kedvéért:) fent valakinek problémája volt virtuálisgép+windows összeállításnál a videóval. desktopon kompatibilitás biztosítására általában VmPlayer+WinXP használok és nem szokott velük gond lenni. ha kell a virtuális windowson videó is megy probléma nélkül, sőt még 3D grafika is, úgy egy GeForce4 szintjén.

az Ubuntu hivatalosan ma is 32bites változatot ajánl desktop felhasználásra. ha 3GB vagy kevesebb ram van computerben, akkor mindenképpen jobb a 32bites rendszer. 3GB felett sem kell feltétlenül 64bites, elég PAE kernelt használni, az 64GB ramig elégséges. ha zárt proprietary nyomtató vagy egyéb gyártói drivereket használsz, akkor is érdemes 32biten maradni, mert gyakran csak 32bites változat van az ilyen gyártói zárt driverekből.
nálam 64bites van és ez csak nagyon ritkán jelent problémát, mint most a moonlight, de ez is megoldódott. de ha nem lenne rtl a sem zavarna.

Köszönöm az instant választ, sok mindenre választ adtál egyszerre.
4 giga ram került a gépbe, ebből lecsíp 256-ot az alaplapi nVidia-nak.

Kérdeznék még.. hogy tudnék egyszerűen "moonlight plugint uprade előtt backupolni" -a szavakat értem, de nem tudom a mikéntjét a backupnak, vagy a rendszer melyik részét backupoljam?

PAE kernelt miként tudok választani (bocsánat a kérdésért, rá is kereshetnék.. tudom)
Így akkor 32 bites rendszert teszek fel.

Szerk: nos, a kernel szám végén szerepel a telepített rendszeren, hogy: pae.
Tehát magától így települt :) és valóban látja az összes memóriát.

firefox böngésző esetén célszerű lementened a teljes ~/.mozilla könyvtárat, továbbá a ~/.config/moonlight könyvtárban van még egy config file, ami a silverlightos mediapack helyét jegyzi. természetesen amikor visszaállítod a backupolt .mozilla könyvtárat ne fusson a firefox.

erről a kernelről van szó. természetesen csak 32bites csomag van belőle, 64biten nincs szükség ilyesmire.