Slashdot Log In
Adobe Joins Linux Foundation, Develops AIR For Linux
Posted by
CmdrTaco
on Mon Mar 31, 2008 09:17 AM
from the do-we-trust-these-guys-yet dept.
from the do-we-trust-these-guys-yet dept.
2muchcoffeeman writes "Adobe announced Monday that it is joining the Linux Foundation and alpha-released a Linux version of its new Adobe Internet Runtime environment, which allows Internet-enabled applications to run on Windows and Mac OS desktops, for Linux. According to Adobe, the alpha version lacks some key features that will be available in the final product and only runs with Sun Java, not GNU Java. Adobe also released an alpha of Flex Builder for Linux Monday."
Related Stories
This discussion has been archived.
No new comments can be posted.
Adobe Joins Linux Foundation, Develops AIR For Linux
|
Log In/Create an Account
| Top
| 171 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Adobe quoted as saying... (Score:4, Funny)
How is AIR different from, say java? (Score:3, Insightful)
Re:also (Score:4, Informative)
Parent
Re:How is AIR different from, say java? (Score:5, Informative)
Parent
Re:How is AIR different from, say java? (Score:4, Interesting)
Parent
Flash! Ajax! Buzzword Central! (Score:5, Funny)
It was a terrible thing to watch. The emotional stress that the mother elephant went through was so tangible and human-like that I was really moved.
Kinda like I am with Adobe fans.
Re:Flash! Ajax! Buzzword Central! (Score:4, Funny)
Parent
GNU Java? (Score:2)
How big is this? (Score:2)
So ... any known application that uses this?
I had to look it up on google to fid out what exactly adobe AIR is. How big is this?
First things first... (Score:5, Insightful)
Re:First things first... (Score:4, Insightful)
Parent
Flash for PPC? (Score:2)
What is AIR (Score:5, Informative)
AIR is a desktop runtime environment. You can run either Html/Javascript or Flash based applications inside it. AIR provides a few interesting features beyond HTML/Flash including:
1) File I/O
2) SQLLite Support
3) An integrated web browser (based on WebKit) that you can use inside applications.
4) A fairly good distribution mechanism
5) Desktop integration (OSX Dock icons, Win32 systray support, etc.)
It's a great technology if you're using Adobe products to make web applications and you want to branch into making desktop apps.
It's a great technology if you want to make a desktop app that may later become a web app and you want to share most of the code.
It's a horrible technology if you're a desktop developer who's looking for a different technology.
It's way more write-once run-anywhere than Java ever was.
It does not pick up the system's native UI widgets.
Re:What is AIR (Score:4, Insightful)
The notion of trust is nothing new. The basic question comes down to this, do you trust the code (or coders for the code that) you are about to run or not? If you don't, then don't run the code. If you do, then go ahead and run the code.
That question may be easy to ask but not so easy to answer. Maybe you trust the organization but there could be inadvertent security vulnerabilities in the code. Or maybe you don't know much about the organization who authored or published the application. How do you decide whether or not to trust the application?
In theory, open source mitigates this trust issue because you can study the code yourself. In practice, it's not so easy. First of all, access to the source code is immaterial to people who are not coders themselves. Second, it would take a lot of time and mind to study the code for a large project. Sure, any competent programmer could study and verify for his or herself that my open source project [sourceforge.net] can be trusted because it really isn't all that big. How can you be sure that Firefox [mozilla.com] doesn't have any malicious code in it?
One approach to this problem is to run programs in what is called a sandbox [wikipedia.org]. What that means is that the program isn't written in what is called the native "machine" code. Rather, it is written in a code for a virtual machine [wikipedia.org]. Every time that code makes an API call, the virtual machine checks to see if it is permitted from a security perspective. Applications that run in a sandbox don't get a lot of permissions. It is OK to run an application that you don't completely trust within the sandbox because the virtual machine is going to deny any requests that could compromise or take advantage of your system anyway.
That is why the complaint about ActiveX. Both ActiveX controls and Java applets run in a web browser. The Java applet has to run in the sandbox (unless it is signed but it is beyond the scope of this post to introduce PKI and X.509 certificates) but the ActiveX control never runs in a sandbox.
Later iterations of this sandbox concept allow the user more control over what the program can and cannot do. In .NET, this is called Code Access Security and in J2SE, this is called Java Security Policy. Before running an application, the user can specify what API calls that the application can and cannot call. The problem here is that this specification is not easy to tweak for mere mortals. When you just double click the application icon, you are running the application with whatever policy that the publishing company specified. So, you are back to trusting that company since there is nothing that keeps them from specifying a policy that is wide open.
I have no experience in AIR so I could not tell you whether or not that virtual machine implements any kind of policy control. Perhaps someone that is knowledgeable about AIR would care to clarify here?
Parent
Excellent news. (Score:4, Interesting)
Adobe Loses to SWF (Score:5, Informative)
Meanwhile, the GNU implementation of SWF is GNASH [gnashdev.org], which just released a new version. GNASH is also not preinstalled, but it's in some ways superior to Adobe's Flash, while remaining compatible (with practically all features found in the wild, and adding the rest) - and free, including not adding DRM you don't want. And GNASH was announced to be part of the new KDE, so it will in fact be preinstalled on lots of Linux machines.
Re:Adobe Loses to SWF (Score:4, Insightful)
Parent
What adobe should do... (Score:1, Offtopic)
Photoshop for Linux? (Score:4, Interesting)
Parent
Just don't plan on trying to hack AIR (Score:4, Interesting)
In other words, "We'll let you play in our sandbox, but don't try to figure out how we built our sandbox so you can build your own sandbox that looks just like our sandbox."
probably gonna suck (Score:1)
In order to get a decent version of AIR for Linux, we'll have to write an open source version ourselves.
namespace clashes (Score:1)
Is GNU gonna be sued because of the name "flex"?
dont get too excited.. (Score:4, Informative)
I am finding the Flex3 framework to be buggy as hell.
* I have been having constant crashes from Flex Builder (It is built on eclipse)
* The ui components are coded like dogshit. (i ended up coding custom elements in flash which are the tenth of the size, and work as intended)
* Some documented features dont work.
* I have spent alot of time figuring out work arounds/undocumented features.
sorry for the rant.. but the claim that it is easy to develop flex apps is bullshit.
I have been using flash since it was called FutureSplash, so after over 10 years of day in day out
developing and making bread with this tech, I think I can speak with some authority.
It seems to me that Adobe is glorifying their steps into open source.
I just have a funny feeling that it is not as good willed, as intended,
but just as a way to get their shit coded/fixed for free,then reimplemented
in their closed source upscale/addon technologies.
Which I might add, allows adobe to compete directly against the very developers
that buy into their software.
The flash format is a trap, careful (Score:5, Interesting)
-- This license does not permit the usage of the specification to create software which supports SWF file playback.
That's pathetic. Adobe is explicitly trying to control the _format_, while trying to convince (and confuse) people by releasing the runtime and SDK as open source. Which means they still retail all the control of closed-source software, without many people even being aware of it. Once (hopefully not) AIR or Flash becomes a widely accepted platform for applications, Adobe can easily ask people to pay up or do whatever.
These days, I get frustrated by the number of people who mention that Adobe is a major supported of open source, and get excited about it. Java may suck, but it sure is not a lock in.
Not sure what to think... (Score:3, Insightful)
- Flash isn't OSS
- The Linux Flash binary-only plugin is still WAY behind the Windows version in quality and stability (remember how long we had to wait for Flash 9.x on Linux??)
- Shockwave Director isn't OSS (and isn't even ported to Linux in a binary-only format, despite the 29511 [petitiononline.com] signatures in the online petition that's been going on forever). Not a peep from Adobe on if this will ever even happen, even though revisions are still being made and it being widely used
- No intention of porting Flash to x86-64 platforms, on Linux -or- Windows (at least AFAIK)
- Just in my experience alone, COUNTLESS other buggy applications (like the other week, installing a version of Acrobat with a
I agree Adobe has a LOT of momentum behind them with the Internet community. With this, however, comes great responsibility. If they want to play in the OSS playground, I think they need to share all of their toys like the others do.
so how bout those amd64 flash/java plugins? (Score:2)
"for Linux"? (Score:2)
anthrax song... (Score:1)
Only supports Sun Java clarification (Score:2)
test market? (Score:1)
Well alrighty then - Where's FrameMaker? (Score:1)
A Day Early (Score:2)
selling to us (Score:2)
fingers crossed... (Score:1)
Mistakes and security flaw (Score:2, Informative)
Hello there,
I've just posted a review and a comment at my site [efeitodoppler.org] (translation [google.com]) where I point that Adobe makes an amateur mistake, by installing all AIR files as the user who launched the installer, despite the fact that it asks for root access via gksu (a graphic sudo replacement). This makes the user owner of the files "AIR root", letting him able to compromise AIR Apps to all users of the system (either voluntarily or by a virus for example). This goes against all security policies I've ever seen. System wide programs must be read only to every one, except for root, which is a user that "is just meant not to be used".
I also pointed at my site to at least two packaging mistakes: broken dependencies and garbage after uninstall.
I wonder: why in hell they have to make that annoying Windows-like installer, more vulnerable to this sort of error, than simply give a package and a software repository? Or at least give direct access to a "traditional" RPM or Debian package... Doesn't they know the KISS rule?
Hope this sort of stuff does not happen when it comes to be final.
Re:gnu software is crap (Score:2)
Parent
Re:gnu software is crap (Score:1)
Parent
Reminds me of an old Sesame Street skit. (Score:1)
I'm not selling the bottle, just what's in it!
Parent
Re:Stop it Adobe, you're making me laugh.... (Score:2)
Parent
Re:gnu software is crap (Score:2)
I think that I tend to produce very good code...but it takes me a long time compared to many others. Possibly there's a tradeoff here.
The nice thing about FOSS projects is that it lets you get SOMETHING out there fast, and then if there's a need, it will be continually improved. I do believe that commercially sponsored projects can develop large applications to a decent level of reliability more quickly. For this purpose ANY FOSS license will work....any that's accepted by the community, and I believe that GPL3 readily qualifies here. It may well be, however, that GPL3 projects are less likely to attract commercial sponsors. OK. They aren't allowed to fork the code into a closed tree. That makes it less attractive to them. But more attractive to me.
Over time I believe that the FOSS projects will provide the higher quality code that fit better with the need of both the developers and the end-users. This doesn't mean that it will happen as quickly with FOSS code as it would with commercial code. But it will be more usable, and more tailored to the "customers" desires. (And, naturally, also more tailored to the desires of the developers.) Over time.
Anecdotally the use of MOST FOSS licenses is increasing. (Not all. Artistic seems on the decline, as does the GNAT variant of the GPL. I'd say the same about the Eiffel variant, but it never was popular enough to estimate. And about most I don't have even enough anecdotal evidence to make a guess.)
P.S.: I *do* count gcc. That may have been a hostile fork, as you say, but it was one specifically allowed by the license. I also count X Window, for the same reason. That's a part of how FOSS operates.
Parent