Adobe Flash Player 10 pre

Internet, Közösségi média

Az Adobe Labs kiadta a Flash Player 10 (kódnevén "Astro") első pre verzióját. A cég az új playerrel egyebek mellett jobb teljesítményt, javított szövegkezelést, fotó effekt szűrőket, natív 3D animációt ígér. A kiadás érdekessége, hogy a Linux sem mostohagyermek már az Adobe-nál, hiszen nem hónapokkal vagy évekkel a Windows és Mac kiadás után érkezik immár a legfrissebb stuff, hanem azokkal egy időben. Részletek itt. A kiadással kapcsolatos információk és letöltési lehetőség az Adobe Labs oldalán.

( tiger | 2008. 05. 15., cs – 18:14 )

"nativ 3D gyorsitas" - remelem nem kell majd egy rohadt honlap miatt felraknom a videokartya drivert. Tudom tudom, compiz nelkul nem elet az elet, de engem nem erdekel :P
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

( Yorirou | 2008. 05. 15., cs – 18:17 )

Ez már nem fog olyat csinálni, hogy bent hagyom a videót a böngészőben 2 órára, és mire visszajövök megevett 2 GB memóriát?

( hofi75 | 2008. 05. 15., cs – 18:26 )

gondoltam, hogy ez lesz: 


gabor@ubuntu:~/install/install_flash_player_10_linux$ ./flashplayer-installer

ERROR: Your architecture, \'x86_64\', is not supported by the
       Adobe Flash Player installer.

gabor@ubuntu:~/install/install_flash_player_10_linux$

azt hiszem visszaallok 32bit-re, na de akkor miert is van mar 5 eve az x86-64 plattform.

( emberk | 2008. 05. 15., cs – 18:36 )

Rákérdezek. Tesznek továbbra is a 64-bitre?
Naná.

Ez ilyen tyuk-tolyas problema. Hany stabil hivatalosan kiadott 64-bites bongeszo plugin van? Java, flash kihuzva az biztos.

En egyebkent stabil, hivatalosan Gentoo altal kiadott 64bit-es firefox-ot hasznalok. Es biztos vagyok benne, hogy Epiphany-bol es Konqueror-bol is van 64bit-es verzio. Hirtelen nem jut eszembe masik opensource bongeszo :D De megkockaztatom, hogy az oszes opensource bongeszobol van 64bites verzio!

Írtam egy kis kódrészletet: 


// helloworld.c
#include <stdio.h>
#include <limits.h>

int main()
{
        printf("Hello Vilag, a maxint ezen a vason: %d\n",INT_MAX);
        return 0;
}

Fordításhoz: gcc helloworld.c -o helloworld

Két vason próbáltam (AMD64 és 32 bites ARM):
* helloworld: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
* helloworld: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, not stripped

Mindkét vason ugyanaz a kimenet: 


Hello Vilag, a maxint ezen a vason: 2147483647

Nem ez a gond, hanem hogy egy pointer 32 vagy 64 bites. Ha 1000 helyen castolgatják a pointereket intre oda-vissza, vagy hardkódoltan 32 bittel shiftelnek meg rendezgetik a biteket, akkor azt elég sok idő lenne kigyomlálni. Nem kell ahhoz asm betét, hogy ne lehessen 64 bites binárist csinálni belőle, ami nem segfaultol el rögtön.

Valóban, az egészek mérete nem pontosan specifikált. 64 bites Windowson a long 32 bit széles, míg 64 bites Linuxon a long 64 bit széles.
"in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide, and even SILP64 where "short" variables are also 64 bits wide [...] Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit."
Forrás: http://en.wikipedia.org/wiki/64-bit#64-bit_data_models

És ennek miért is lenne értelme?
Ez kb. olyan, mintha a sebességkorlátozást is tetszőlegesen lehetne értelmezni (Elnézést de az a 50-es tempó városban nem mérföld/óra volt?)
Csak arra kívántam rámutatni, hogy az Adobe kiadhatna 64 biteset, ha akarna. De nem akar, ez látszik. Érdekes módon az Nvidia ki tud adni 64 bites display drivert, ami nem hiszem, hogy nagyságrendekkel egyszerűbb lenne, mint a Flashplayer.

Egyébként elindul forrás shell szkriptként, de nem adja vissza a parancssort egyik vason sem 15 percen belül - így kérdéses a használhatósága.

Viszont részemről a téma lezárva, mert a topik nem erről szól, hanem arról, hogy kijött egy új Flashplayer (és 64 bites portja most sincs, de ez csak egy mellékzönge).

Komolyan ki szokott mozilla.org-rol letoltott firefox-ot hasznalni? Azert van csomagkezelo a Linux disztrokban, hogy hasznaljuk. Szerintem a 64bites dosztrok tobbsege 64bites firefox-ot csomagol. Ha neked egy Debian, Ubuntu, Fedora, SUSE, Gentoo firefox maintainer ilyen Pistike kategoriaba esik akkor no comment.

Az, hogy mi szamit hivatalos firefox kiadasnak egy eleg szurke terulet. Mindenkinek igaza van. Engem tulsagosan nem is erdekel.

Ha megnezzuk a mozilla 32bit-es bongeszot ad ki mivel nincsen 64bit-es flash, java plugin. De ha akarnak akar holnap kint lehetne a 64bites verzio. A Linux disztrok mar egy jo ideje azt szallitjak.

Mig az adobe azert nem ad ki 64bit-es flasht, mert nincs 64bites bongeszo. Illetve mert nem tudnak csinalni.

Egyebkent igeny van 64bit-es pluginokra. Eleg megnezni a 64bit-es java plugin requestet a sun oldalan. Jelenleg ez a request all az elen az oszes javas RFE (Request for Enhancements) kozott. Most, hogy megneztem latom, hogy update-eltek es nem csak java 7 alatt lesz megoldva, hanem lesz java 6 verzio is. Mondjuk a 2009 eleje eleg tavol van.

"The date for JRE 6 update release which has this 64bit JRE support will be early 2009."

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695

Jelenleg ez a bug a sun legnagyobb szegyene. Legalabbis az en szememben biztos.

- Igény lenne rá. Jobb megoldás, mint 64 bites OS-ben 32 bitesen futtatni a plugint.

- Idő? Vajon mennyi idő alatt fordul le egy forráskód, ami pár megás binárist eredményez. De komolyan: aláírnék titoktartási nyilatkozatot, ha megkapnám a flashplayer forrását fordításra.

- Pénz? Mennyibe kerül vajon legfeljebb 1 órányi gépidő manapság + pár extra karakter beírása?

Kb 1% használná, ha lenne 64 bites, de ez az 1% így is meg tudja oldani máshogy.
Nem a fordítás egy program fejlesztésekor a nagy idő. Az időt mérnökórában mérik. A pénzt úgyszintén.
A flash-t annak idején 32 bit only-ra írták. Nem lehet 64 bitre fordítani. Akik ezt sok évvel ezelőtt fejlesztették, már akár ott se dolgoznak, de ha igen, akkor se emlékeznek, melyik sor mit csinál. Újraírni nem lehet, mert nem lenne kompatibilis a jelenlegi flash-el. Reverse engineering-elni pedig nagyon sok munka. Sok munka, tehát sok mérnökóra, sok idő és pénz. A szerezhető profit kevesebb, mint ez a pénz. Tehát nem csinálják.

Újraírni nem lehet, mert nem lenne kompatibilis a jelenlegi flash-el.

Azért visszaolvastad miket írtál?
Miért ne lenne kompatibilis? Szerinted nincs dokumentálva cégen belül a formátum, és minden kiadásnál izgatottan rágják a körmüket, nehogy elrontsák a számukra ismeretlen, már elfelejtett (ez is ROFL a hozzászólásodban) funkciókkal való kompatibilitást?

Ezt azért gondold át mégegyszer... A te elgondolásod alapján a legújabb WinNT, OSX, Linux és Solaris flashplayer nagy részben azonos kell legyen az eredeti Win95-ös 1.0 kiadással, különben nem működne........
A flash player valóban elég gány, de ilyen szintű átgondolatlanságot nem lehet feltételezni, azért mégse majmok írták.

Látom, nem vagy programozó... Elmagyarázom.

1. "Miért ne lenne kompatibilis?" Mert egy ilyen 10 éves, 10 nagy verzión át toldozgatott formátumot nincs az az isten, aki még egyszer úgy tudna implementálni, hogy abban az eredeti kódbázis összes bugja benne legyen. Márpedig anélkül nem fognak menni a meglévő flash animációk, ami megengedhetetlen. A gnash próbálkozik vele, de egyelőre használhatatlan.

2. "Szerinted nincs dokumentálva cégen belül a formátum" Valahogy le van, az újabb verziókét még ismerik is a munkatársak. A Win32 API és a Word 97 .doc formátum is nyilvánosan elérhető, de ugyanúgy nem fogja soha senki bugról bugra implementálni, ahogy eredetileg sikerült. Még az m$ se.

3. "minden kiadásnál izgatottan rágják a körmüket, nehogy elrontsák" Nem. A régi kódhoz hozzá se nyúlnak. Meghagyják úgy, ahogy van.

4. "A te elgondolásod alapján a legújabb WinNT, OSX, Linux és Solaris flashplayer nagy részben azonos kell legyen az eredeti Win95-ös 1.0 kiadással" Nem. Hozzátesznek kódot a régihez, ráépítenek újabb függvényeket, a régit is meghagyva. Új formátumot új kód játszik le, régit a régi. A nagyon régit egyszerűen elhagyják.

5. "azért mégse majmok írták" Nem. Programozók, és ismerem a hozzáállásukat.

Majd ha évek alatt kifut mondjuk a flash 7-es kód a piacról, és nem lesz nagy baj, hogy az 5-10 éve gyártott animációk nem mennek, akkor kidobhatják a hagyatékot. Ha és amennyiben az elmúlt pár évben termelt kód már fordítható 64 bitre, akkor egy idő után lehet 64 bites lejátszó.

Írták több helyen: nem tűnik reálisnak hogy IA32-n/IA32-re fejlesztett kódot SPARC-ra, PPC-re, ARM-re könnyebb átültetni, mint AMD64-re.
Nem-x86 esetén nincs olyan hogy "megvárják míg kifut az IA32 kód" hiszen ilyen nem is létezhet abban a verzióban. Mégis van ilyen flashplayer verzió, és működik is. Ez, ha igaz amit írtál, hogyan lehetséges?

"- Idő? Vajon mennyi idő alatt fordul le egy forráskód, ami pár megás binárist eredményez. De komolyan: aláírnék titoktartási nyilatkozatot, ha megkapnám a flashplayer forrását fordításra."

Ennyire magasrol -remelem- azert csak nem tesz ra az Adobe...
Gondolom azert tobbrol van szo mint egy sima forditasrol pl.: lehet, hogy tele van asm betetekkel.

Mert "worksforthem", amíg van IA32-IExplorer meg nspluginwrapper, addig nincs gond, nem akarnak energiát fektetni olyan platformba ami félig-meddig támogatott.
A Solaris portért gondolom fizetett a Sun, nem áll távol tőlük ekkora meggondolatlanság: nem akarom megtudni mennyi veszteséget okoz nekik ez meg a múzeális, de fizetős CDE freeware-ré licenszelése...

Egy böngésző pluginben nem tartom valószínűnek, hogy lenne akár egy sornyi asm is. Ez nem olyan, mint egy játékprogram vagy hang/videódigitalizálás, ahol minden órajel számít. Ha meg valami magasabb szintű nyelvben írták, akkor ott meg nem hiszem, hogy akkora problémát okozna a dolog.

Nem-x86 legfeljebb 10%, és az átlag PC-k cserélődési idejét figyelembe véve az x86 90%-ából legalább 40% AMD64, de egy év múlva akár 60-70% is lehet.
Viszont az operációs rendszerek nagy része IA32 Windows XP egyelőre.

Minden persze csak nagyságrendi közelítés, mondom, pontos adat nincs.

Nekem nem kellene optimális bináris, azzal is beérném, ha egyáltalán létezne valamilyen - figyelembe véve, hogy elsődlegesen nem flashes oldalak böngészésére használom a gépemet. (Az opensource kezdeményeket még nem találom igazán használhatónak.)

Egyébként az march onnan jött, hogy az egyik videóvágó program ./configure után módszeresen elcseszi AMD64-en a march értékét. :-)

( wladek1 | 2008. 05. 15., cs – 18:40 )

Ígéretesnek tűnik...
100 helyett csak 50% a CPU terhelés egy youtube videónál...

kötöjelkötöjel
//:wladek's world

( zZsOlTi v | 2008. 05. 15., cs – 19:11 )

Windowless mode-ot még mindig nem tudja a Linuxos verzió -évek óta-, úgyhogy lehet tovább bosszankodni az olyan weboldalakon, ahol a legördülő menüket eltakarják a flash betétek (pl tcom.hu, wizzair.com). Fullscren mód sincs.

( asch v | 2008. 05. 15., cs – 21:13 )

Következő kiadás már open source lesz?

( kikke | 2008. 05. 16., p – 11:30 )

Csak egy picit gyorsabb.
Userplane-es userlistán lassú a görgetés, fullscreen youtube után visszaváltva bedermed. (Mondjuk minek youtube-ot fullscreenben nézni?)
--
the tide is turning

( trey | 2008. 05. 16., p – 07:56 )

Kipróbáltam. YouTube lejátszás kb. 20% - 30% CPU (hang), 40% - 45% ha képet is akarok egy 1.7-es Pentium M-en. Fullscreen működik.

--
trey @ gépház