Adobe Releases Cross-Operating System Runtime
An anonymous reader writes to mention that Adobe released the first public version of their new cross-operating system runtime today nicknamed 'Apollo'. "The software relies on HTML, JavaScript, Flash, and Adobe Flex. The alpha version, which presently works on Windows and Macintosh, can be downloaded for free at http://www.adobe.com/go/apollo. Once the Apollo apps are created, users can launch them from their desktops, without using their browser or connecting online. An Apollo application can connect automatically to online data or services when an Internet connection is detected, with new components automatically downloaded and integrated. The user needs the Apollo runtime to run the apps, just as a Flash player is needed to run Flash animations."
Is this supposed to replace Java or similiar technologies?
So in other words it's a wrapper for existing technologies? It could be useful I suppose, but I'm thinking it's being hyped up already by Adobe. Abstraction of the underlying technolgies is good in some cases, but I can just see the horrid things people will do with this. Flash alone is bad enough as it is the way it's often implemented.
Hmm, why did I instantly think of cross-platform viruses/worms being early uses of this technology? Self-propagating flash-based avertising?
Surely an architecture like this can't function without duct tape.
Why would we need another java or flash? TFA is very sparse on details what is so much better about apollo and why that can't be done with flash or java. But their little project is doomed since people will tend to refuse downloading/installing new software unless the added value is clear. So unless they can generate a massive switchover from a lot of websites/developers to apollo, this technology is dead as a duck in the water.
This space is intentionally staring blankly at you
Any Linux support on this one?
In a browser environment, the browser operates the app in a sandbox and controls access to the machine. Sure hope Adobe's runtime does the same (preferably with fewer security bugs).
[Insert pithy quote here]
Anyone who has ever had to make a cross platform GUI application that works identically on Linux, Mac, and Windows, can tell you what a nightmare it is. Even if you use a good cross platform toolkit like Qt or wxWidgets, the apps are still not *identical*. And you have to build them and test them for every platform. And you have to account for the myrid of possible library combinations the users my have installed. Etc etc.
This is why so many companies are embracing web applications - but web applications can't do it all. Some things you just *need* to do client side. This Apollo thing could be a really great way to do it.
And what may make it even more killer, would be the fact that you could perhapse share GUI code between your web applications and your client applications - so a user could run his UI over the web *OR* locally. Excellent.
I will definitely be taking a close look at this.
The first reason, and the less sure one and more petty one, is that I feel that Adobe ruins all software over time. If you think carefully about this, and if you have sufficient experience with Adobe software, you will agree with me. The only project Adobe has not completely destroyed is Photoshop, and that is only because they move most cautiously with that product. If they screwed up Photoshop they would cease to exist yesterday.
The other reason, however, and the one that I expect more support on, is the Apollo Runtime Licensing Agreement. It contains such gems as "2.2 Distribution. You may not sublicense or distribute the Software.", "2.3 Backup Copy. You may make one backup copy of the Software, provided your backup copy is not installed or used on any computer. You may not transfer the rights to a backup copy unless you transfer all rights in the Software as provided under Section 4." And then there's "2.4 No Modification. You may not modify, adapt, translate or create derivative works based upon the Software.". Here's another fun one: "3.1 Prohibited Devices and Systems. You may not install or use the Software on any non-PC device or with any embedded or device version of any operating system. For the avoidance of doubt, and by example only, you may not install or use the Software on any (a) mobile devices, set top boxes (STB), handhelds, phones, web pads, tablets and Tablet PCs that are not running Windows XP or Vista Tablet PC Edition, game consoles, TVs, DVD players, media centers (excluding Windows XP Media Center Edition and its successors), electronic billboards or other digital signage, internet appliances or other internet-connected devices, PDAs, medical devices, ATMs, telematic devices, gaming machines, home automation systems, kiosks, remote control devices, or any other consumer electronics device, (b) operator-based mobile, cable, satellite, or television systems or (c) other closed system devices."
Now consider Apollo in the context of actually using it; the only place you can install it is on a web server. The license does not even permit installation on a web server appliance! I am not making this up; you are prohibited from installing it on "internet appliances or other internet-connected devices". You cannot install the software on a PDA used as a webserver. You cannot use the software as the interface for a set-top box. You cannot, in fact, use the software anywhere other than a webserver (but not an appliance!) or pretty much anything running Windows XP (tablet PCs and media centers NOT running Windows XP are explicitly prohibited.)
Avoid this software at all costs! It's just an attempt by Adobe to create lock-in. Use ANY alternative.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
Ah. Cross-operating systems.
Where's the OpenBSD version? Where's the DragonFlyBSD version?
{{.sig}}
From the site:
RIAs? So basically, you want me to not only have a wrapper agent on my system but also a network and system app layer that will have direct access to other remote like objects? Hmmm, gee, has anyone told Citrix this?
So this won't fly in an Corporate Enterprise environment and for home use...well, does anyone want mySpace resource hogging your whole system and not just your browser's use of your resources? Uhm, no thanks.
"Once the Apollo apps are created, users can launch them from their desktops, without using their browser or connecting online."
9 7348.aspx
Sounds a lot like Microsoft's ClickOnce technology: http://msdn2.microsoft.com/en-us/netframework/aa4
And Microsoft "auto-updates" Windows machines (whether or not you want them to, it would seem) to include the latest frameworks and such. Regardless, how does what Adobe does improve on what Microsoft (and I'm sure some F/OSS alternatives) already do?
I'm sure the player will be free, the SDK not so free.
I'm curious how much memory this thing's going to eat, and how annoying the upgrade prompts will be. If it integrates Acrobat, I wonder how many times I'll need to reinstall it each year in order to keep it from hanging.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
isn't the same thing? i remember playing with a thingie called XULPlayer, i loved it.
The Apollo SDK EULA is considerably less draconian.
The land shall stone them with the bread of his son.
http://labs.adobe.com/wiki/index.php/Apollo
Apollo is targeted at allowing web developers to build and deploy web applications to the desktop.
Linux?
Apollo 1.0 will not be available on Linux. We plan to release Linux support shortly after the 1.0. release.
Which means, like maybe when a big-fish pays us for the port.
Then there's very-non-free License terms:
You may make a limited and reasonable number of copies of the SDK Components
The structure, organization and code of the SDK Components provided to you in compiled or object code form are the valuable trade secrets and confidential information of Adobe Systems Incorporated and its suppliers.
may be expressly permitted to decompile...it is essential to do so in order to achieve interoperability with another software program, and you have first requested that Adobe provide the information necessary to achieve such interoperability and Adobe has not made such information available. Adobe has the right to impose reasonable conditions and to request a reasonable fee before providing such information.
What about the malware factory you are creating?
You shall not use the SDK Components to create, develop or use any program, software or service that (a) contains any viruses, Trojan horses, worms, time bombs, cancelbots or other computer programming routines
That'll stop em.
Got Trader Joe's? friendwich.com RSS feeds work now!
Sounds like a future replacement to Director and Shockwave to me.
Maybe there's some perl in there ;)
I wonder? Oh, yeah, ActiveX.
What's the point? We have Mozilla's GRE (plus XUL), and Apache's whatever-they-call-it?
Were that I say, pancakes?
they want java back.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
They're running Linux. Netcraft confirms it: http://uptime.netcraft.com/up/graph/?host=labs.ado be.com
Clearly the best tool for the job.
Now, when will the PHB's at Adobe get the message that the only best tools run on Linux natively?
Got Trader Joe's? friendwich.com RSS feeds work now!
XULRunner = HTML, js, canvas and SVG.
Java is under the GPL and other stuff like HaXe is also free.
Where does that leave this proprietary crud? I have a love/hate relationship with Adobe, mostly hate since they acquired Macromedia.
Oh, wait, it's not.
Nevermind.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
In which way is this different from Java webstart? AFAIK that does about everything described above? Maybe it has more shiny graphics? PSSST, Adobe, hear this.... Make some software which makes it easier to develop forms on websites. Make it connect to and auto-update from your servers. If "Country" is needed, you guys supply a current list of all countries in the world. If the end user selects "Germany", you change the "Postcode" field automatically so it will only accept "D-xxxx" where x is a digit. Get the picture? A nice graphical UI on the develloper side where you can say "Date of Birth" has to be a valid date between 18 and 120 years ago. (You know, instead of a whole bunch of javascript with bugs in.) Add the posibility to map the fields graphically to a column in a database. Then release a free client with the next release of Flash, where the user can store his personal data, password protected, to autofill the said forms. Instant $$$$! Promess!
10 ?"Hello World" life was simple then
Now you're going to say: "Of course, it's because Adobe is the inventor of the stupid portable document format, so no wonder they know all the tricks." You know what? You're right. In fact, Adobe even changes the definitions of pdf with every new release of the reader. I don't care. PDFs are the only format for documents besides Microsofts moronic
Available for XP only.Irony.
they said something about changing their minds.
The view was horrible and the smell was even worse; Julie severely regretted becoming a proctologist.
Its an alpha release. I suspect the licensing, particularly the restriction on where you may use the software, reflect that. Imagine the damage to the product brand if some company included it on the kind of devices it uses as examples of prohibited devices (like ATMs or medical devices or set-top boxes), and it (as an alpha produce is wont to do) failed spectacularly in an unforseen manner.
The license isn't made, I suspect, with individual hackers modding their own internet appliance, set-top boxes, etc., in mind. Sure, it technically prohibits it, but Adobe isn't going to know if you do it, isn't going to care if you do it, and isn't likely to do anything more than mention that its a license violation and not their fault when it screws up if somehow you manage to even get their attention with the fact you've done it.
I don't think setting up a webserver on their desktop PC and then browsing to http://localhost/ is a good solution for the average user.
sig? uhh, umm, ok
While I agree with you about most of the text, the prohibition against embedded devices, set-top boxes, etc., is likely designed to prevent you from using it in such a device; and you're likely to see the same EULA on the Linux version. I'm guessing that they don't want people developing set-top boxes based on this technology without licensing the technology from Adobe.
My blog
Is there any real advantage to using Apollo over similar runtimes such as Mozilla's Zul?
They want Smalltalk back.
The world has changed and we all have become metal men.
Is this the old java byte code is slow due to the JIT vs. the flex is fast because of its JIT argument?
Will save a lot of time.
I'm a bit confused on this. I suppose the obvious would be cross-platform support. Is that really the only difference, though?
Intentional mixup of dead in the water and a sitting duck. It made you blink ey?
This space is intentionally staring blankly at you
> Adobe Releases Cross-Operating System Runtime
Thanks Adobe. Porting my viruses to Windows, OS X, Linux, *nix, *nix, *nix is such a pain in the ass.
Now I can do it in just one go! Oh sweet!
There's already a cross-platform runtime out there that has all those features: it's called Firefox (or xulrunner, if you prefer). In the next version, it will be getting support for off-line application development.
Let's not let the web get hijacked by Adobe or Microsoft again; we don't want to repeat ActiveX or Flash.
... that's what I fear anyway. A solid cross plattform multimedia ready RIA enviroment with a reliable roadmap and good backing is what the world is desperately crying for. Flash could easyly be and stay king of the hill in that game. Java slowpocked to long and Flash has the largest installbase of any plattform ever. ... Ouch.
I wonder why they don't just continue to improve Flash/AS. Is it the Community that needs rebranding?
Apollo could give the whole Flash/AS thing a fresh start and remove those psycho barriers anti-flash zealots have had trouble with to overcome. I hope this won't put of anyone who has hoped for a consolidation of the RIA industry. Yet again it goes without saying that they won't get any foothold if they don't release a Linux version of it pronto. Make *nix the stepchild and all opinion leaders will turn your back on you. For good reasons too. I thought Adobemedia had gotten that by now. Looks as if they're losing focus again. If this turns into yet another 'We'll be 1.5 years late again with Linux' fiasco then they can shove their Apollo. Bow, Arrow and all.
We suffer more in our imagination than in reality. - Seneca
Where are the sources?
From the Developer FAQ:
Will Apollo's use of WebKit result in a new HTML engine that developers have to account for?
No. Our goal is to maintain complete compatibility with existing WebKit implementations. This will help ensure that content that runs in WebKit based browsers, such as Apple's Safari, will also run within Apollo applications.
Which means that any changes that Adobe makes to WebKit go back to the WebKit project. There is no need to distribute separate source, you can get it at http://www.webkit.org./
The only project Adobe has not completely destroyed is Photoshop
Flash is possibly one of the most important technologies out there. It is available in *almost any* web browser, and allows you to do non-trivial things without jumping through mind numbing browser-compatibility hoops, and does them at a speed that a browser cannot even dream about. Neither Microsoft, due to it's insecurities about becoming irrelevant, nor Mozilla and Apple with their limited market shares have been able to archive this holy grail of cross platform, install-free computing.
What they are doing is trying to extend this *very enviable* position into enabling a richer range of applications. And even if it does seem a little risky, *if they succeed* they may well transform client side computing. And as far as I can tell, all they have to do is package Apollo with Flash, and they will have the most installed middle-ware ever.
As for your legal concerns, they are very real. However, it isn't going to keep them from succeeding on the desktop where this is headed. The reason for the restrictions, I assume is so that they cam make a buck selling those versions. However it seems reasonable to assume that if they succeed the Mozilla/XUL codebase can be made to run Apollo apps if the need arises.
-- http://thegirlorthecar.com funny dating game for guys
I could get by with GIMP I just don't like it. Getting by doesn't mean a whole lot and its a down right horrible phrase to use if you want to convince someone to use a product. I use a few titles (Photoshop, Fireworks etc)to do tasks that could probably all be done with Photoshop, but that doesn't mean it could be done better, more efficiently or to my preferences. I could name a lot of titles that I prefer that aren't available on Linux. PSPad is an example. Sure there is something else I can use, but since I have a choice, I choose my own preferences over yours. I see no reason to use software I don't prefer just because it works when the software I am using works. Just because something is an alternative doesn't mean its an alternative that the user will like. A large portion of users don't want to settle for software titles that fit their specifications but not their preferences. Inregards to Linux, instead of trying to force your ideals on non-Linux users and dictate their needs, you should also address their preferences and if you can't satisfy them then they have a valid reason for going elsewhere. But you are correct that Photoshop is not going to sell Linux to these people. It would take a lot more than that.
They want Smalltalk back.
And they're welcome to it. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Wow. Most of the posts on this topic are so far from reality, I'm not sure where to begin. Maybe this comment will be modded up as flame bait or 'Adobe FanBoy', but oh well.
I was at the Apollo pre-release event in San Francisco last Friday night, along with 200 other geeks. Adobe called it ApolloCamp, but there were no wienie roasts or sleeping bags. Adobe put on a fine show, with each attendee receiving a free full version of Flex Builder 2 for either Mac or PC, plus a copy of the Apollo alpha runtime, a free DVD of instructional material from http://www.lynda.com/.
I wrote my first Apollo app at about 12:30 AM Saturday morning, 20 minutes after I got out of the cab returning from the Adobe event. If you're already a Flex developer (and I wasn't), then you're an Apollo developer now too! If you have a web-based app that already runs in Safari, chances are very good it will just run on the Apollo runtime too. Oh, and if you were a web developer, now you're a desktop developer too.
I think Adobe has a winner on their hands, so it will be interesting to look back at this post in a couple of years and see how things go.
Check out the videos of the event at http://video.onflex.org/ to get a more clear idea of what Apollo is and isn't. Yes, Linux support isn't in 1.0, but it is planned. Many of the developers in attendance were asking about Linux. Other platforms being targeted after Linux include mobile devices and game console platforms.
Dont we have enough of these things already? How about lets all work on making one better, then just adding another to the pile?
---- Booth was a patriot ----
Are you sure you're not working in Adobe's marketing department?
New Rule: You're not allowed to call your software cross-platform if it only runs on two platforms. Instead, Apollo is just bi-curious.
I'm with you brother. Oh God why is /. so conservative and predictable? The comments here run through pretty much every cliched attack...
.NET.
- It's crap because it doesn't run on 64 bit Linux
- It's crap because it's not open source and XUL is a perfectly good alternative
- It's just a new version of Java
- Look at the evil license. OMG they're trying to lock you in!
- No Ogg support. Less space than a Nomad etc etc.
Here's a radical idea. How about, just once, actually looking at a non open source app objectively? I never drank the Flex Kool-Aid (no big benefits over AJAX IMO), but Apollo really has quite a lot going for it:
1. It's truly cross platform on the major desktop OSs of Windows and OSX. Look at Linux's desktop market share FFS. If Adobe released ANY Linux version it would be generous, yet they'd still be derided by bearded clowns howling about the lack of 64bit support on PowerPC and Stallman's accolytes decrying the runtime as closed source.
2. It's designed for occasionally connected apps with local file system access. It has the advantages of a thick client but it's much, much easier to develop for than Java or
3. It's significantly more media capable than XUL. Can XUL do video conferencing or stream audio/video? Oh sorry that's right - real computer users don't like video (it's all ads) and should be recompiling their Gentoo kernel from a command prompt instead.
I don't think Adobe are perfect by any means. I have some very big concerns about Apollo's security that I'd like to see addressed. One example - how does it stop an app that's been given file system access from dynamically including a compromised SWF on the server?
Slashdot is rarely the place for constructive criticism. Even mildly intelligent criticism is increasingly rare. But is it too much to ask that it's, at least, informed?
One of these days I'm moving to Theory - everything works there
The security of the Apollo runtime sandbox is still unknown. At least, that is the official word from Adobe. A number of developers in attendence on Friday night were asking security-related questions about the new framework, and Adobe was pretty up front that the final security architecture has not been chosen.
It wasn't the case that the Apollo product was dealing with security as an afterthought, instead I got the feeling that they were evaluating a bunch of different options and were asking for feedback about how fine-grained the security control should be. I'm guessing that each implementation choice will need to be reviewed and vetted by people much smarter than I.
Here are a few security-related observations from Friday's discussions:
1) The installation process for Apollo apps will allow for digitally signed apps.
2) The Apollo team was saying that people should treat the installation of an Apollo app just like the installation of any other desktop app. If you don't trust the supplier of the app, don't install it. Use #1 to verify the supplier of the app.
3) Security is just plain hard, even with VMs like Java or Apollo.
I think that the Apollo runtime will suffer from the same firewall problems as Java apps. Apollo apps are launched within a process called adl (ADobe Launcher, I'm guessing). Java apps are launched within a process called javaw. I'm betting there will be a bunch of WinXP firewall exceptions listed as "adl.exe" just like there are currently many exceptions for "javaw.exe".
The Apollo architect raised an interesting point when he said it was fine for all of us geeks to talk about the details of various security implementations, but how do we architect a security solution so that our grandparents can understand the right thing to do. The answer isn't obvious at all.
It's kind of pointless if there's no Linux build. I wonder if it'll work in Wine.
At least they're not using Microsoft's definition of cross-platform: It runs on Vista _and_ XP.
Oops. I should have double-checked before I posted the last reply.
A properly-installed Apollo app does change its process name to the app name, so that will make software firewall configuration more manageable than Java apps. My first test was on an Apollo app launched from with the Flex builder IDE. But after checking some of the other apps installed on my system, I confirmed that process is correctly named after the app.
I think the signing approach is the right one. However, to allow for dynamic SWF inclusion that'd mean every included SWF would also need to be signed and checked at run time before it was used. Not a scenario that sounds either fast or easy!
One of these days I'm moving to Theory - everything works there
Yes. Apollo apps will usually be backed by server side code in the same way as AJAX (shudder) applications need the server code in the backend to do the work. Think of that paradigm, but with much nicer (visually) and easier to develop GUIs than pure Javascript+[insert JS library of choice] However, Apollo apps will have a local data store which can be accessed by the app, if that's what you meant.
Client side functionality and data storage. Just synch and go. Stays in the sandbox. Leverages existing open technologies. Is available from more than one vendor. No BSA. Maybe a bit more challenging than this Adobe product, but a lot safer.
If you would have bothered to check their Website you would have found this on the FAQ page:
o perfaq#Does_Apollo_support_Linux
http://labs.adobe.com/wiki/index.php/Apollo:devel
Does Apollo support Linux
Apollo 1.0 will not be available on Linux. We plan to release Linux support shortly after the 1.0. release.
While we had originally planned to support Linux in the 1.0 timeframe, we have had to wait on the core Flash Player's support for Linux to be finalized.
I might give it a try for my Computer Store Work Order Tracking program.
Everyone who buys Wild Hunt will receive 16 specially prepared DLCs absolutely for free, regardless of platform.
No, I don't think a Flash developer will find the switch to Apollo as seemless as Flex developers. But the transition is still doable if you are quite comfortable with ActionScript in your Flash apps. Said differently, if you are more of a Flash coder than a Flash designer, you should be up and running in Apollo fairly quickly. I'm not sure how many Flash developers that previous statement applies to, since any of those Flash coder could have made the switch to Flex months ago. If they didn't make that switch because the they couldn't grok Flex, then they will have a hard time groking Apollo as well.
The developer transition cases as I see them:
If you're a Flex developer comfortable with ActionScript 3
Apollo is just a minor tweak on things, adding a few more classes to the framework. You'll be up and running in minutes, not hours or days.
If you're a Flex developer, but limited to ActionScript 2
The biggest hurdle is the switch from the AS2 framework to the AS3 framework. The Apollo VM can still run AS2 code and does allow AS2 code to bridge into AS3 code and vice versa, but that soon turns into a maintenance hassle. A couple of the developers I spoke with at Adobe said it was really worth the hassle to convert the AS2 code to AS3 first and then recompile for Apollo.
If you're a Flash developer
Get comfy with Flex first, then move to Apollo. http://www.lynda.com/ has great online courses for learning Flex and ActionScript3.
If you're an HTML/CSS/AJAX developer
If you're app runs in Safari, then it very likely will work in an Apollo sandbox as well. The biggest hurdle for these developers will be choosing how to integrate Apollo into their development environment. They could switch over to Flex builder ($$), switch over to Eclipse with Flex&Apollo plugins (free), or just integrate some of the Apollo command line tools into their existing configs.
NetBSD and Linux run on a lot of platforms.
I'd love to see this thing on all of them,
only then can Adobe claim being truly cross-platform.
(If anyone in Adobe is serious and reads this, I'm willing to act as contact for NetBSD)
- Hubert
Thank you, b4h :)
meep