Adobe Is Finally Ending Flash Support... In 2020

[Hi-Angel]

gnash, swfdec, lightpeak, shumway... Any of these projects still alive?
I think read somewhere that mozilla stopped the shumway project.

I think the idea is that companies that want to use Flash beyond 2020 might put resources into one of them.

[RussianNeuroMancer]

I think read somewhere that mozilla stopped the shumway project.

Yep, that the point of my post.

[caligula]

That's because RAM is not storage and storage is not CPU speed. I know it sounds awkward, but that's why.

The whole latency would be in reading storage and it's CPU speed.

Listen dude, if the media is 100 MB in size (e.g. OpenELEC) and the read speed is 100 MB/s, explain why it takes more than one second to load. E.g. OpenELEC (and OpenWRT and LEDE ...) uses squashfs so you'll be reading large blocks anyway. It's not standard high IOPS random access.

The answer is, it's not really disk bandwidth constrained. Initializing the hardware takes time.

[Duve]

but muh old newgrounds games. The only thing I ask for is support up to flash 10/11.

Well either they adapt to the new reality or be forgotten, the internet waits for no-one.

I guess someone have to get Shumway into working state.

Again, leave it to be burried. With most sides using HTML5 video now, there is no real point to bring this back from the dead.

[Zucca]

Oh no... I just realized: http://sieni.us ;(

[Hi-Angel]

Oh no... I just realized: http://sieni.us ;(

What is there anyway? I am not motivated enough to install Flash player, so I just see a black background, a few links, and random text. For some reason they didn't even made a text "install flash player" if that's the problem.

[Zucca]

What is there anyway? I am not motivated enough to install Flash player, so I just see a black background, a few links, and random text. For some reason they didn't even made a text "install flash player" if that's the problem.

I just installed shumway to test out few of them (and few only actually work).
Anyway. That site contains a collection of looping flash animations. Some of which are pretty famous.
Gnash shoud be able to run most of them...

[Hi-Angel]

An interesting fact: I was crawling for whether there are sites with bounties for implementation features into FOSS, and found this:

Convert the Gameswf flash player into a Firefox plugin..
More information is available.
Bidders:

• rob is bidding 30000.00 to work on this.

The total funding for this project is 30157.14.
All funding amounts are in US dollars.

FTR: bounties are probably disfunctional already, because they all look very old, links are mostly dead, and the site don't even care to fix SSL errors. But it's still interesting to know that at some point somebody offered 30k$ for, well, not even making the flash replacement, but just converting GNASH into a plugin for FF.

[caligula]

That's because RAM is not storage and storage is not CPU speed. I know it sounds awkward, but that's why.

EDIT: A lot of boot time is all the latency it takes for information to move around a systems memory hierarchy.

EDIT: If RAM was storage and storage was CPU speed, then you would never have to "load" anything There would be no start time. The whole latency would be in reading storage and it's CPU speed.

I don't care about this discussion anymore, but just wanted to point out you're wrong. Booting a computer is NOT just about moving bits from disk to RAM. I can give you another example - on some systems the U-Boot boot loader loads the whole OS (the device tree blob, initramfs & kernel) in RAM. After U-Boot hands over the control to kernel, the booting still takes several seconds even though all the data is already in RAM. Why? All the device drivers need time to initialize their stuff. Hardware such as displayport negotiates the link parameters, it doesn't happen instantly. Hard drives need time to spin even when not reading any OS data during the boot. Network driver might wait for dhcp broadcast. Why these systems boot so slow is that their initialization code has too much unimportant initialization in their critical path.

[SystemCrasher]

We can all thank split memory architectures for that. If applications ran from storage an it was the speed of the CPU, then you could have true instant on capability.

Its not as simple as that. Say, NOR flash could enjoy by direct code execution straight from storage. However, guess what? Modern CPUs and RAM are much faster compared to NOR, so re-loading code to RAM brings considerable speed boost. NOR also "enjoys" by low capacity and is expensive by design, so it makes a lot of sense to compress everything you can. But you can't execute compressed code directly. Nor you can have direct access to compressed data. So overall there is only RAM which is fast, read-write and offers anyhow sane capacity. But it is volatile, which implies some persistent storage. There're some non-volatile equivalents of RAM but they are of lower capacity, more costly and some of them are pretty much experimental. So we have persistent storage to deal with RAM volatile nature and RAM as main operational area used once system is operational. But it forgets everything once power is lost. It's not like if this design superior to others, or something. Its just because better designs which would manage to outperform it haven't appeared to the date. Still there're some tricks to do boot really fast (high-score for Linux is about 0.3 second or so) or to do some rather tricky suspend to avoid doing full boot. However, all this comes at certain price. Very fast boot implies inflexible design, where heavily minimized kernel launches app instead of init, so it happens to be very limited kind of Linux. It could even utterly lack shell, if app does not bothers about it. Tricky suspend schemes where system rather restores state from RAM or storage have their own shortcomings and issues. Suspend to RAM could be fast, in best case it almost like instant on, but it depends on power supply, should power get lost, state is lost and it appears like sudden crash. Suspend to non-volatile storage requires to xfer state back to RAM, it takes some time and in worst case just plain reboot could get even faster and "more asynchronous" since it increases RAM usage gradually, over normal course of actions. Not to mention "proper" reboot brings OS to well defined state and gets rid of transient glitches, should there be any for whatever reason.