Szépen halad a linuxos Flash 9 Player fejlesztése

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

A Penguin.SWF blogoldal - amely a linuxos Flash 9 Player fejlesztését követi nyomon - legújabb bejegyzésében Mike Melanson arról számol be, hogy az általa mostanában látogatott Flash-t használó oldalak kivétel nélkül jól működtek a fejlesztés alatt álló linuxos Flash 9 Player-rel.

Teszt gyanánt a YouTube és a MySpace videoit nézegette, de hibát nem tapasztalt, a lejátszó teljesen stabil volt. Összegzésként Mike megállapította, hogy a lejátszó a nagyobb weboldalakon sikerrel vizsgázott az általános, magasszintű funkcióteszteken. Most specifikusabb, alacsonyabb szintű, finomabb tesztek következnek, hogy biztosak legyenek benne, hogy minden rendben van.

Ez azt is jelentheti, hogy Flash 9 Player linuxos verziójának kiadása már nincs messze.

Bővebben a blogbejegyzésben.

( turul16 v | 2006. 08. 26., szo – 20:03 )

amd64 támogatásrol mit tudni, lesz ? Vagy csak nspluginwrapper -el fog menni?

Regeben ala irtam ilyesmit meg e-mailt is kuldtem..
Ez is eleg regi, Macromediank van cimezve, pedig mar Adobe lenne a cimzet ui. megvette.

Miota van 64bittes browser folyamatosak a keresek, de eddig nem hatotta meg oket..

32bittes Linux tamogatassal se foglalkoztak sokat az utobbi idoben, marcius ota nincs uj release linuxra, winre adtak ki tobbet is

Par datum (wikirol)
(ver 7) (9 September 2003)
8 (released on September 13, 2005)
9 (released on June 27, 2006)
Linuxra meg mindig csak 7-es van.

De hatha jo fej lesz, az Adobe ;-)

( Syrius | 2006. 08. 26., szo – 20:05 )

És ha én türelmetlen vagyok le tudom szedni azt a verziót amit teszteltek ?
Mert az Adobe oldalán ott virít a Download flashplayer 9 de a fájl amire mutat az a 7-es verzió.

Q. Wasn't there supposed to be a simultaneous release of the Linux version of Flash Player 9?
A. Not exactly. We never said it would sim ship. We did say that we were skipping the v8 port to get a start on porting v9 (formerly known as v8.5). We are working on it, and expect to release in early 2007. Which means a beta should be here very soon. For progress and updates, check Mike's Penguin.SWF blog.

( toros | 2006. 08. 26., szo – 20:56 )

Szépen halad... persze... ha egyáltalán lesz valaha belőle valami. Csakhogy amíg windows alatt már régóta van 9-es, addig Linux alatt még mindig a hetesnél tart. Majd akkor hiszem el, hogy lesz is belőle valami, és nem csak szöveg az egész, ha feltelepítettem a gépemre. Addig csak üres és komolytalan duma az egész.

Megjegyzem, a YouTube-hoz nem is kell kilences Flash, mert a videók a hetes verzióra vannak optimalizálva. Úgyhogy óriási eredmény, hogy a linuxos kilences flash tudja azt, amit egyébként a hetes is.

Elgondolkodtató, de azért hadd hozzam fel példának az Mplayert, ami runtime képes kiválasztani az adott cpu-hoz melyik codepath a legjobb és támogat MMX-et, 3dnow-t, SSE-t SSE2-t, ha jól rémlik a cikkben rémesnek titulált altivec-et is. Pedig ezt is emberek írták...
Az érzésem az, hogy az mplayernél azért tudták megcsinálni, mert a fejlesztés úgy ment, hogy először C-ben írták meg a függvényeket és utána valaki (most nem nézem meg, hogy pontosan ki is volt az) nekiállt a sokat futó és látszólag jól párhuzamosítható függvényekből 1-1 alternatív asm optimalizált változatot csinálni, amit eleinte fordítási időben lehetett választani az eredeti C-s függvény helyett, később megcsinálták, hogy futási időben is lehessen. Az ASM optimalizálást alapvetően így kell csinálni, ennek ez a helyes, használható módszere.
A flash fejlesztők viszont szerintem nem így dolgoznak. Akárki akármit mond, a cégnek nem volt prioritás a Linux support, ezért 1-2 embert állítottak csak rá, odaborították nekik a windows-os flash player orrba-szájba hackelt, itt-ott ötletszerüen x86 asm optimalizált kódbázisát (természetesen 0 dokumentációval, ahogy ez tipikusan szokott lenni), hogy "nesze ezt portoljátok linuxra". Nyilván eleve nem platformfüggetlenre tervezték, nincs normális build rendszer, ami lehetővé tenne akárcsak fordítási időben platform-specifikus kódválasztást. Az ASM betétek nem úgy vannak, hogy egy egyébként C-ben megírt függvény funkcióban azonos alternatívái, amihez vissza lehet térni, ha valamiért az assembly mégsem járható út, hanem a függvény egyetlen változata az ami ASM-ben van lekódolva. Hát ez így tényleg elég frusztráló tud lenni, ha egy átláthatatlan, összegányolt kódból kell valami használhatót kihozni. Ennél már az is jobb, ha from scratch újraírják, csakhát ahhoz rendes specifikációk, komoly dokumentáció kell, ami könnyen lehet, hogy nincs.
A csávóka meg itt arról beszél, hogy mekkora teljesítményveszteséggel jár, ha nem használnak ASM-et, de basszus, teljesítményvesztés ide vagy oda, először egy funkcionálisan működő változatot kell csinálni és csak utána lehet egyáltalán szó arról, hogy teljesítményre optimalizálnak. Máshogy nem megy, esélytelen. Na én először ezt a változatot szeretném látni, már ez is komoly előrelépés lenne.
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

Teljesen egyetértek veled.
Nekem a cikkből kb. az jött le, hogy "Jézus Mária ez a kód nem írja meg saját magát!", azért aki programozó és még fizetést is kap azért amit csinál, annak tudnia kéne azt, hogy az asm kódot, azt esetenként meg kell írni és nemcsak úgy feltűnik a semmiből.
Az is érdekes amit a támogatandó hangrendszerekről írt; eddig nem sok mindent támogattak, akkor most mi ez a hatalmas elán, hogy most akkor nem csak alsa,oss hanem még arts és gstreamer is?! Nem volna elég arts és gstreamer?
__________________________________________
Wenn ist das Nunstück git und Slotermeyer?
Ja! ... Beiherhund das Oder die Flipperwaldt gersput.

Nem, elég volna a libao nevü könyvtár használta, ami automagically mindent támogat. Az egyetlen kellemetlen tulajdonsága, hogy GPL, ami miatt zárt forrással nem jön össze. (De persze egy GPL alatt kiadott flash player nem ártana egyáltalán, sőt...)
Az a probléma egyébként sajnos valós, hogy nincs egy de facto audio protokoll, ami minden unixon garantáltan működik, mint pl az X11 a grafikus felülethez. Az OSS áll ehhez legközelebb, de csomó minden nem tud (mixing, multichannel, normális felvétel támogatás stb) és nem működik hálózaton vagy socketen keresztül. Az Alsa linux specifikus és annak sincs hálózati támogatása, de legalább a hardveres feature-öket elég jól kezeli.
Audio serverek valamelyike jó lenne, de egyrészt a kelleténél többféle van belőlük (aRts, esd, jack, nas), másrészt kevés alkalmazás támogatja őket, harmadrészt pedig trágya a designjuk, olyan nagy a késleltetést eredményeznek, ami pl telefonálásra, játékra, zeneszerzésre használhatatlanná teszi őket. Technikailag az egyetlen jól megcsinált audio server a jack, amit tényleg komoly zenei munkához találtak ki, de sajnos talán ezt támogatja a legkevesebb alkalmazás és nagyon kevés distroban van benne alapból. Ráadásul macerás belőni, mert a daemonnak realtime prioritás kell (érthető okokból), ahhoz meg kernelt kell patchelni.
Mondjuk egy nagy lökést adna neki, ha pl a KDE dobná végre az arts-ot és a jacket választaná helyette. Már egy ideje lóg a levegőben mert az arts már évek óta unmaintanined.
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

biztos vagy te ebben? Attól, hogy valaki ismeri az assembly utasításokat, attól még nem biztos, hogy rögtön meg tudja írni a gcc-t is, pláne nem egy komplett, kényelmes, magasszintű szoftverfejlesztő csomagot.
De ha mégis, még akkor is az adobe flash editornak ugyanaz lehet az előnye, mint a Photoshopnak. Hiába van ingyen a gimp, a grafikus designerek többségének a photoshop jobban kézre áll, ezért megveszik.
Ja persze ezt az adobe vezetőségének is fel kéne ismernie...
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.

nem biztos, de valoszinu. eddig is voltak animacio, vektorgrafikus szerkesztok. kepzeld el, mennyi energia kellene egy inkspace plugin megirasahoz, ami alap flash9-et general, mondjuk par effektel. azert elegge kiszamithatatlan lenne ez az adobe szamara, meg mit varhatunk egy olyan cegtol, aki teljes mellbedobassal tamogatja a bsa-t, mi ha torvenyes is, de szerintem nem eppen etikus uzleti viselkedes az egyszeru othoni felhasznalokkal szemben. ez egy olyan ceg, aki mindenben a sajat erdeket keresi, es egy jo pontert nem fog baratsagos lepest tenni a free software iranyaba, hacsak erre nincs nagyon nyomos erve.

Adalek:
flash szerkeszto: http://www.swishzone.com/ http://www.sothink.com/product/swfquicker/

igen szep peldak: http://www.sothink.com/product/swfquicker/samples/index.htm

Az OSS áll ehhez legközelebb, de csomó minden nem tud (mixing, multichannel, normális felvétel támogatás stb) és nem működik hálózaton vagy socketen keresztül.

Hm, igaz az, hogy ez az OSS, mint olyan, hiányossága? Nem esetleg csak a Linuxos implementációé? Nem értek a hanghoz, de a FreeBSD 6.1 OSS alapú hangrendszere állítólag nagyon jó...

Audio serverek valamelyike jó lenne, de egyrészt a kelleténél többféle van belőlük (aRts, esd, jack, nas), másrészt kevés alkalmazás támogatja őket, harmadrészt pedig trágya a designjuk, olyan nagy a késleltetést eredményeznek, ami pl telefonálásra, játékra, zeneszerzésre használhatatlanná teszi őket.

Szerintem az egész audio-démon idea egy rossz design. Az általuk nyújtott szolgáltatás nem transzparensen érhető el, explicite meg kell határoznia egy programnak, ha az xyz audio szervert akarja használni. Ez agyrém. Az egész csak kernel támogatással működhetne jól. Ha túl necces a kernelbe tolni egy egész démonnyi kódot, akkor csinálni kéne egy kernel/userspace interfészt, amin keresztül a démonok userspace-ből irányíthatnák a kernelt.

Az a probléma egyébként sajnos valós, hogy nincs egy de facto audio protokoll, ami minden unixon garantáltan működik, mint pl az X11 a grafikus felülethez.

SDL? Hordozható, és nem akar mást csinálni, mint ami a tulajdonképpeni dolga egy audio-rendszernek (az audiót illetőleg, mármint).

Szerintem Knuth-nak csak több évtizeddel ezelőtt volt igaza.
Akkori gyakorlat szerint minden volt az algoritmus.

Ma ez nem igaz, mert sokkal bonyolultabbak a programok, és az algoritmus mellett igen fontos az is, hogy adott feladatra írt egy tucat különféle library, technika, platform, módszertan, prog.nyelv közül melyiket választod.

Különösen akkor nincs igaza, ha teljesítmény kritikus dologról van szó.
Itt ugyanis igen óvatosan kell kiválasztani pl a használt alapkönyvtárat és a nyelvet, mert több évi fejlesztés után derülhet ki, hogy a feladat nem oldható meg a választott eszközökkel, és ez egy projektet sőt egy kisebb céget is elránthat.

ezt programtervezéssel meg lehet oldani. biztos lesz utólag jobb megoldás, de nehogy már azért álljon a fejlesztés, mert nem bírnak dönteni. knuth pedig ebben is igazat mondott sztem, mert nem a korszaktól függ az algoritmus megírhatósága. sőt... az aki programtervezés (mindegy milyen eszközzel) nélkül megy neki egy programnak (főleg nagyobbnak) már eleve kudarcok sorozatával kell számoljon, mert belefut olyanba, amit nem tud megoldani adott eszközzel. sztem nagyon félreértelmezted amit knuth írt

Szerintem meg siman arrol van szo, hogy nem is akarjak tamogatni Linuxot, vagy legalabbi nem olyan gyorsan mint mas OS-t pl. Emogott en inkabb egyeb (uzleti) erdeket feltetelezek, mert az nem fer a fejembe, mi olyan nehez egy vacak plugin portolasaban ... Meg ha egy full office rendszerrol lenne szo, vagy hasonlo ... Nekem ugyanigy gyanus hogy miert olyan nehez 64bites verziot kihozni (ha jol tudom windows ala sincs 64bites, vagy rosszul tudom?). Foleg mivel ha egyszer megirjak jol, akkor nem kell allandoan portolni, eleg erdekes lehet ott a fejlesztes menete, ha minden alkalommal nullarol kezdik egy-egy verzio portolasat. Vagy en nem ertem ...

Nem az a gaz, hogy nincs (?) a flash-bol 64 bites verzio, hanem hogy linuxon micsoda pain-in-the-ass modon lehet csak egymas mellett 32 es 64 bites programokat futtatni, emiatt aztan folyamatosan megy is a szardobalas ("mikorlesz XYZ") /o\

Ezt ugy hivjak: inkompatibilitas. Ellenpelda: OSX.

"Ezt ugy hivjak: inkompatibilitas. Ellenpelda: OSX."

Igen, nekem mind a 10 AMD64 gépemen OSX van, és szépen fut alatta a flash. ;-)
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

Hát, bár igaz lenne, amit mondok (főleg a mondat 1. része).
Sajnálom, erre a visszakérdezésre okosabb választ nem tudok kisajtolni magamból. :-|
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

( gyuri2012 | 2006. 08. 27., v – 02:54 )

Szoval ha mar "mindjart kesz", akkor csak le lehet tolteni valahonnan nem? Honnan?

( chrono | 2006. 08. 27., v – 09:05 )

Az az igazság, hogy már kezd elég nagy gond lenni, hogy nincs újabb Flash Linuxra. Nehéz megmagyarázni otthon, hogy miért nem működnek weboldalak. Tavaly még mentek a Grand Slam tornák scoreboardjai 7-es Flash-el, ebben az évben már nem. Pedig ez fontos lenne, hogy működjön.

US Open Live Scores

És ami a legszebb ebben, hogy Sponsored by IBM.

( ng | 2006. 08. 27., v – 14:32 )

Kár hogy nincs BeOS-re flash. Esetleg lehetne BeOS-re is portolni?

( _Joel | 2006. 08. 28., h – 17:03 )

A 7-es flash player verzio linuxra portolasat a sun csinalta kinaban (2004 kornyeken, ha jol emlekszem) parhuzamosan a solaris portokkal. A 9-es ennyire mas codebase lenne, hogy nem erte meg a 7-es portolasat vegzo embereket szerzodtetni?