Clarifications about Flashy 32bitterness

After my last post was dugg (765 diggs) and after reading my blog's and diggers' comments, I feel I need to make some clarifications about the matter.
I'm not questioning the fact Adobe didn't compile it yet whatever reason is. To me they can even never compile it to amd64 or PPC for what matters. I'm questioning the lack of _clear_information_ from them about _when_ (because they'll be armtwisted by market forces to do it sooner or later) if ever. A timeframe would be nice, but more than ten months of silence about the progress (or lack thereof) of this port and ignoring recurrent complains from people is just disrespectful to us "consumers". A "No, we'll not port it to amd64, so move along, nothing to see there" statement would suffice, and we would have a clear message to motivate us to really _move_along_ and _do_something_ instead of wait the G*d's mana fall from Heavens. The current situation is different from to the one of XFree86's before the fork (diva programmers' overfilled-egos preventing a faster development of the de-facto X implmententation to maintain their own status quo - the change to the license just confirms it), but the result is the same: stagnant progress preventing people from doing something to get out of the "comfort zone", as people settle for "good enough".
Let me make clear and say 32bit Flash didn't prevent me from running a 64bit operating system. I know the cumbersome nspluginwrapper trick, but it's a sub-optimal situation, prone to crashes, performance killer (processor context changes), memory hungry (need to load tens of MB of 32bit compatibility layer just to check YouTube) and bloated (need to have 32bit compatibility layer installed in my machines). A PowerPC or z390 user can run Win98 on Bochs and enjoy Flash content. An amd64 user can choose to run a 32bit OS and lose the overall speed gain (around 30% in my tests encoding audio files) from additional 64bit registers and other niceties. The sad thing is people are resorting to such measures and subjecting themselves to it to be able to see content because of vendor lock-in.
The current Flash vendor lock-in is way more dangerous than O.S. lock-in or www browser lock-in, because it's so pervasive people don't seem to think about it. The present state of rich media internet is not reflected by W3C, ISO, ECMA (yes, I'm aware of ECMAScript), IETF or whatever regulatory/standards body of my knowledge, leaving us in a void not filled by the SVG spec or any of its implementations, having as only resort Adobe's Flash. And it makes business sense in short term, as almost every Mom 'N Pop's Store, Nvidia, AMD/ATi, Intel, ASUS, Google, Sun and even Microsoft use Flash to generate and display rich media. In medium and long terms it's another story, because the decomoditization of the world wide web will make the www browser less and less relevant as long as it serves as a shell to run Flash content.
Some initiatives are being done to level up the fight, as the sight of Silverlight cast new shadows on the tubes. Some people have the power to do something to change this situation, but let's number some of the outcomes:

1. Adobe updates Flash to retain market share and avoid dissent. Very unlikely based on current behavior.
2. Adobe's corporate heart is touched and they release a free, unencumbered specification just like they did with PDF, submitting it to evaluation by a standards body. And We The Coders(tm) implement it while Adobe maintains its stronghold with the creative tools. Acceptable.
3. Adobe ignores the Vocal Minority(tm) while Gnash and SwfDec try to catch on. Or, more precisely, the current situation.
4. Microsoft does to Silverlight what Adobe should have done to Flash in item 2, but with MS's track record of openness and transparency we may expect something like OOXML in the end.
5. Moonlight does to Silverlight what Gnash does to Flash, only spending 27MB of memory for a 160x100 "CLICK HERE!! NOW!!!" seizure-inducing banner. Tastes like moonshine.
6. Sun makes a rich media content creation suite with files playable via its Java plugin. Interesting.
7. Somebody else makes a rich media content creation suite with files playable via Sun's Java plugin. Less interesting.
8. Some regulatory/standards body starts to think about it and something shows up in at least ten years from now. Bringing a full-fledged implementation as useful as Amaya.
9. _We_ F/OSS people do something, organize a group, start a project and code, just like Xiph.Org Foundation has done with Vorbis, Theora, FLAC, Speex, Ogg and others.
10. Somebody hires me to put up or shut up. :D

The 2nd outcome is not out from ignorance: Tamarin's ECMAScript v4 Virtual Machine is slowly but steadily being adjusted to be able to compile in 64bit environments. But Tamarin/ECMAScript it is not the SWF and FLV File Format Specification as defined by Adobe, and the license agreement states in clause 3.a. "You may not use the Specification in any way to create or develop a runtime, client, player, executable or other program that reads or renders SWF files.". I'm not able to compare both so I will not be tainted by Adobe's license, but I'd like to know I'm wrong and both are the same thing, making Adobe's license a moot statement. A word from Tinic Uro or Mike Melanson about it would be very enlightening and drive some F/OSS developers in to it (me probably included).
Gnash, SwfDec, Moonlight, Wine and others help the Free/Open Source Movement to conform to the present but not to shape the future. Backward compatibility and being able to handle current formats are important to assure the recoverability of our data, but if we want to warrant our freedom for the coming years, we need to do something _now_, with or without Adobe's help. If Gnash, SwfDec, Plasma (hi, Aaron) and others join forces do develop a common specification for rich media content (or expand the Dynamic SVG spec to meet the demmand) and implement it at library level, allowing the creation of platform-independent web plugins, stand-alone players, embedded parts, desktop gadgets, creative media suites and other yet-to-be-seen applications, then we'll be really shaping the future.

Flashy 32bit diehards

Some days ago Mr. Mike Melanson of Adobe Flash's Linux port fame posted in Penguin.SWF blog about the news of H.264 coded support in Flash. Nice, a new codec. But there's a question that doesn't want to be silenced:
What about a nice, clear and objective answer about the availability of a 64bit version of the Flash plugin?
I know "Requests for such features as alternate operating system or CPU architecture support are more suited for the Adobe Wish Form", but come on. We users don't get any answer at all, clear or not, about it since yesteryear (21th july 2006 to be more precise), and submitting something to the Adobe Wish Form is just like waiting an answer from a cold, silent tombstone. At least Mr. Melanson talks to us from time to time, but his apparent policy of not discussing 64bit at all is such a denial mode that makes us think what's going on inside Adobe's corporate mind (as I believe he would like to be able to discuss it but his Management prevents him from doing so).
I posted something around these lines in the comments' session of his blog, knowing the odds that such comment would not be approved were high, but sincerely, people are starting to get fed of Adobe's silence (as increasingly frequent comments like "64-bit version or die" are quite revealing). Why have plugin versions to computer minorities as Linux-x86 and Solaris and deny Linux-amd64 users? Sincerely I would feel better if only Win32 versions were available, so the F/OSS community would reinvent itself again and bring up a free-as-in-speech multiplatform competitor with its proper creative tools (maybe even with a little help from the ones like Google, who has a huge interest in online media and owns two video-sharing portals) instead of settling for less and an implicit promise to deliver it "when it fits company's mood". This wait is a deja-vú of the XFree86's slowness before Keith Packard gently triggered the chain reaction who generated the XOrg's revolution, but in Flash's case it's closed source and closed-spec. Adobe's position about the PDF format represents a good balance between openness and commercial interests, but the same doesn't apply to Flash.
I and others recognize the efforts of some valiant people inside Adobe's headquarters to bring updated versions of the technology and to be more open and I hope they'll prevail and Adobe's management will understand this current window of opportunity to stay relevant in the rich media for the internet in the next decade.
People get fed, and not aways in the Gnash's sense. Sometimes it's in OpenOffice.org/ODF's sense (full creative suite that was the motivator and currently implements the ISO standard for office documents). Maybe Adobe will understand this before it's too late.

Victory!!!

Court Rules: Novell owns the UNIX and UnixWare copyrights! Novell has right to waive!

KDE and employment - Sebas is right

"Once upon a long ago" I started to contribute to KDE (my longtime DE of choice) for very personal reasons (needed to see my significant-other-at-that-time via IM, who was enduring a life threatening illness, and I refused to use closed source software to do so - but it seems to be a matter to a PBK interview, not a blog).
Despite of our fate as a couple, the fruit of my love for her and for the Free Software ideals was my code, and it was being used by thousands of people. "Why not put my participation in the Free Software Community in my CV?" I did, and things started to fare better as time passed. I was better received in interviews and got some nicer job offerings, even outside Brazil. My local colleagues started to see some sort of übergeek aura surrounding me :), even if I was unwilling or unable to write a simple "hello word" in Delphi (writing a Bluetooth driver or a stream server for Linux is way easier in my opinion). And when I'm asked about what people can do to become Free Software developers, I say the basic statements (use and get used to Free Software, learn how to speak English, identify something that's missing and try to fix/implement/improve it, interact with other developers, etc.).
Being a KDE developer helped me to take care of personal affairs,help other people to communicate using Kopete and to improve my professional life. It's a fine everybody-wins situation, and future contributors should be informed that it will probably be the same to them. ;)

Konquigotchi - a would-be plasmoid

Our fellow KDE gearhead Wendy Van Craen gave us a wonderful idea to a Plasmoid:

The Konquigotchi!
It would serve to educate the fellow user/developer too, remembering him/her to:

1) Eat;
2) Drink;
3) Go to bathroom;
4) Change his/her underpants;
5) Sleep.

It could be programmed to shut down the computer when it's time to go to bed, start the screensaver when you need to take care of your body and trigger a lot of events (signals) when you have to do something. All of it encapsulated in an animated SVG picture of a dragon with a diaper and a pacifier. :D

In Soviet Russia Knoquigotchi watchs YOU!!!

AK47

AKademy, kde4, 2007.

No, I'm (sadly) not attending. Maybe another year, if [Deity] blesses me.
After a frustrating try to get an H1-B, I'm going back to Uni so it'll be easier next time a job opportunity outside Brazil appears again (so I hope). Meanwhile it's time to restructure some things and take care of n (aseigo has p man, I have n girl), a girl in her teens I'm proud of.
I wish Good Hacking(tm) to our fellow KDE koleagues there in Scotland, and please don't miss an opportunity to enjoy some GHB music, even more if it's Albannach.

Scots Wha Hae!