[arch-general] [arch-dev-public] dropping flashplugin x86_64
Heiko Baums
lists at baums-on-web.de
Wed Jun 16 08:59:34 EDT 2010
Am Wed, 16 Jun 2010 00:08:09 -0400
schrieb Caleb Cushing <xenoterracide at gmail.com>:
> with the exception of a few movie websites which were kinda
> entertaining I agree.
These movie websites are just annoying, too. Why can't the studios
present their informations about a movie in plain HTML with a trailer
presented with a pure video plugin? Then you get every information
about the video you need and it's much faster and much more stable.
> yes... and then how're you going to serve them up in a cross compat
> way?
Build / compile a version for Linux, one for MacOS and one for Windows.
That's all. And then it runs much faster, smoother and much more stable
on every OS than with Flash or Java. Java is as annoying as Flash and
it's also much slower than native binaries.
> before flash it was gifs...
But gifs can be filtered or blocked much better than Flash animations
without being forced to block useful and wanted content by web filters.
And web filters can't only block gifs completely but alternatively just
show e.g. the first or the last image of a gif, so that you can see the
gif but without the flickering. That's not possible with Flash. With
Flash you can either block every Flash animation incl. the useful ones
or accept every Flash animation incl. the annoying ones.
> don't get me wrong... I don't love flash but it's been much better to
> me than everything else. Honestly I wish people would just stfu about
> the death of flash.
I hope, and I'm sure that the death of Flash will come, hopefully as
soon as possible.
> I'm pretty sure the problems with the daily show were
> how they've built their stack, because youtube and abc.go.com both
> work flawlessly.
After all a bug in Flash. Doesn't work Flash really so well?
> seriously it's easier to block flash than gifs and the caching on
> mplayer-plugin never worked that well...
If caching of mplayer-plugin doesn't work for you, you probably haven't
configured it well. You know that it has a separate config file?
These values work for me perfectly:
cache = 8192
cache-min = 20.0
cache-seek-min = 50
Set these in mplayer.conf, mplayer-plugin.conf and/or gnome-mplayer's
and gecko-mediaplayer's configuration and it should work.
> don't blame the tool. (and no I don't like proprietary software, I
> wish flash were open source. but I'll wait for webm to be a proven
> technology before I jump on that bandwagon)
I indeed blame the tool, because if those tools would exist then people
couldn't write software with these tools. And it's usually not the
software written by / for these tools (Flash animations, Java
applications, etc.) which make them slow and unstable, it's indeed the
tool itself, the Flash plugin and the Java runtime engine.
It's just because a native binary (written in C e.g.) can be loaded
directly into the computer's memory and be run from there directly on
the CPU, while for running Flash animations and Java applets
and applications first a big interpreter needs to be loaded into the
computer's memory as a native binary and be run from there on the CPU.
Then the user's software needs to be loaded into memory, interpreted
(not run natively) and translated into native code which then can be
run on the CPU.
You see the differences? You see that such "languages" like Flash and
Java can't be as fast as a native binary? That's just not possible. And
it takes more time until the software is loaded, because not only one
but two applications need to be loaded, one of them is usually pretty
big.
And because of the additional and rather unnecessary layer (the Flash
plugin or the Java runtime engine) you have several sources of trouble
more than with a native binary. If such a program doesn't work
correctly the bug can be in the code of the animation or application,
but it can also be in the plugin or the runtime engine. If a native
binary doesn't work correctly the bug can only be in the application's
code.
And if you need a proprietary plugin it's not possible to check the
plugin's code for bugs. So you rely on the plugin's developer's mercy.
Heiko
More information about the arch-general
mailing list