Am Wed, 16 Jun 2010 00:08:09 -0400 schrieb Caleb Cushing <xenoterracide@xxxxxxxxx>: > 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
