Posted
by
kdawson
on Thursday February 28, 2008 @12:32PM
from the breath-of-fresh dept.

unityofsaints writes "Up until now, Adobe hasn't done much in terms of porting its applications to Linux, as its only product to have recieved any kind of Linux implementation is Flash. This may be about to change because the company has announced a Linux port of AIR, its web application development software. No definite release date is mentioned in the interview with Adobe CTO Kevin Lynch, just a vague 'later this year.'"

The funny thing is that at this point it would probably take about an afternoon for Adobe to port Photoshop to Linux.

Yes, I'm exaggerating... but only slightly. Currently Photoshop runs essentially flawlessly using up-to-date versions of Wine. Remember that Wine is intended both as a run-time compatibility layer, but also as a set of Windows API libraries that you can compile your Windows code against in order to make a native Linux application. (Well, some people might debate that the resulting app is actually native since it relies on Wine libraries being installed, rather than the more widespread Linux toolkits like GTK or QT.)

Given that the Wine project has already done 99% of the work, I can't imagine it would be very difficult to port Photoshop to Linux... The same is probably true for the rest of the suite. So, one wonders why they haven't bothered yet.

Yeah, it couldn't possibly be a massive undertaking to port almost 15 years of built up code, working across an entire suite of interconnected programs, to a completely differnt set of APIs. They should get on that right away!

Please note, of the programs you listed, combined they are a drop in the bucket in terms of code base and complexity compared to the full Adobe Suite. You may not agree with commercial software and that is fine, but don't try and pass it off as less than it is.

I don't think you got what the parent was trying to say. Not only does wine allow you to "emulate" (wine insists it's not an emulator) the windows system calls and run binaries compiled against native windows libraries, they strive for source-level compatibility with the windows libraries. They could build against wine by just changing their buildchain to point to the wine headers and libraries.

The actual situation is most likely in-between the two extremes posited by parent and GP. Adobe has its own abstraction layer that they program against, so once they have a way to target GTK or Qt with that backend, compiling the applications should be quite straightforward.

(This layer is likely to be rather complex -- witness how long it took them to bring Photoshop to MacIntel)

(This layer is likely to be rather complex -- witness how long it took them to bring Photoshop to MacIntel)

Speaking as a programmer myself, I know the step from linux code running on macintel or vice versa is not an extreme step to take. I release demos on all three major platforms and by using libraries that helps us with input/output (such as glfw and audiere, but there are plenty of others for each use) it's not a huge task to take on.

And this day of age your code (or 99% of it) shouldn't been done in assembly either, so no problem porting to other platforms really. And they don't utilize sound:)

Adobe also uses GTK+ for their port of the Adobe Reader. Also, I'd prefer GTK+ simply because it looks and feels the way an X11 toolkit library should; I've find Qt programs like Opera and Skype have a non-native, ported feel to them. If you're going to settle for a non-native, ported feel, why not just use Wine Lib?

Except that you're wrong. Adobe is actively trying to eliminate the vast majority of their GUI-library dependent code with the EVE2 and Adam libraries. I know these things because I am one of the researchers developing the data-limiting constraint language to be used. It is part of their core internal road-map to move all Adobe projects off of specific GUI dependence. Before any of you start talking "cross-platform", what Adobe wants out of cross-platform is not wxWidgets or the Mozilla-stuff; what they want is very similar to the AbiWord notion of cross-platform.

the newest beta of Picasa for linux is much, much better. Importing from my camera via USB now works, uploading to web albums work now, the performance is almost as good as the "native" windows client, except for a delay in the startup. It takes a few seconds longer to start on my computer. the file management stuff is still a little weird.. Some places it opens up in its own "wine" file browser, others use Ubuntu. In fact, my only real complaint right now is the newest picasa beta for linux still doesn

No GTK apps are what I would consider to be truly cross platform. GIMP on Windows looks like GIMP on linux with a theme applied. No GTK apps integrate properly with the native environments in Windows or OS X. Qt at least makes a decent attempt. So a port to GTK would make Photoshop only gnome-native anyway. Better to just use Wine, make the interface exactly familiar to all users of photoshop, and save thousands of man months of effort.

It is not technical it is financial. There have been versions of Photoshop that runs on Unix Systems, I rember seeing an add for Photoshop for Sun Work Stations. It is not a situation that they can't make a Linux Version it is more of an issue they Won't make a Linux version unless it takes 0 effort on their part. Linux is strong in the Server Market but in the Desktop Market and Workstation market they are not really there where at best guesses Linux is less then 1% of the market share. Then I would suspect about 25% of them are Open Source Zealots who will not use a BSA Backed Closed Source Tool on Linux no matter how good it was. Then you have by my estimate 50% people who are just to cheap/unable to afford to shell out a few hundred - a few thousand bucks for a software package. Now we are left 25% Now that leave the people who want or need photoshop so lets say less then 1/2 of the 25% that leave 12% Now we figure a 1/3 will pirate a copy so that is 8% of Linux Users Left... Then We can assume from that 8% left 3/4 of them would use an other platform to use photoshop anyways so that 2% out of 1% Market Share that would be new Customers so that means 0.02% change in new customers. Now if 1/4 of the World Population Uses Computers that can meet the system requirements. estimating 6 billion in population that will be 300,000 copies sold over a 4 year life cycle meaning an average of 75,000 copies sold a year. Creating 37.5 Million Gross estimating 25% margins on the copy making 9.4 Million Net. Which may be a lot for You or Me. For for a Company Adobe's size that may not be the best bang for the effort. Because effort towards Mac or Windows user for the same cost could Lead to much higher Sales perhaps 10 or 100 fold. Efforts in making Adobe Wine Compatible or close to it may yeald better results for less effort.

Why would Adobe care? People switching from platform a to platform b will just cause them to loose money on their other platforms and make it up on their Linux platforms. These people are Net 0, as well if they did switch to Linux and depending on what they did with graphics they may find that The GIMP does the work for them that they want to do (Yes there is GIMP for windows too, but it is not defaultly installed). So they could loose costomers in the process. If people feel locked into their product the l

Because folks (especially Web developers) moving from Windows to Linux would effectively stonewall Microsoft's Silverlight initiative, as there's no (good) Silverlight/Moonlight development tools available on Linux. And there's not likely to be any good ones, judging by how far Mono lags now (after years of development) in functionality behind.NET, even with MS's cooperation. Meanwhile, Microsoft has gotten serious about trying to take the Web away from Flash and pulling the rug ou

I'm not sure that's true of Photoshop's target demographic.Many people I know who use Photoshop (i.e. people who actually pay for licenses) often also use other pre-press software that aren't available on Linux. One would have to port the other tools too, and deal with lack of availability of drivers for special equipment. Photoshop is only one tool in the pre-press production chain. Hence the inertia.

I'm a Debian user myself, but I personally agree with the GP that the target market is just too small.

Amusing side note: In the nineties several popular programs were ported to Unix for reasons I didn't understand then, and don't now. In addition to Photoshop also MS Internet Explorer [wikipedia.org] and Outlook. Imagine my disbelief and horror when I found that nasty couple installed on a production HPUX server...

I wouldn't think Adobe has just thrown away the source portability. After all portable code is expensive to create in the first place, but once you're there it's pretty cheap to maintain portability. If this is the case then they have probably had a Linux version of Photoshop, and perhaps other products for years, they just don't feel like selling them at this point.

The point I want to make is that yes, indeed, Adobe could probably release Photoshop for Linux tomorrow. Wine wouldn't be necessary. It would be the real deal, a fully native Unix/X11 application. Unless of course Adobe hasn't done criminally stupid things to the code base in the past decade...

Even if it did take, literally, only an afternoon to port, the question is how many more sales would Adobe get from such a port? (i.e., sales that didn't cannibalize from existing Windows or Mac sales)

And how much would it cost to support such a port? The huge number of distributions means that probably only a well-restricted subset would be "officially" supported.

Right about now it'd cost much more than it'd be worth in new sales. However, the market is getting increasingly OS agnostic, and it's not in Adobe's interest long term to stay tied to any OS. The more cross-platform they get, the more versatile they will be to OS changes.

Just look at Silverlight - it's directly targeted at Flash, and the only reason it'd succeed is because.NET is still king, and the only reason.NET would stay king is because Windows is still king. Silverl

Nice. But how about getting Flash to work natively on FreeBSD also? Petition here [petitiononline.com]. There are over 5,600 signatures. FreeBSD currently uses the linux emulation layer to run flash, but it's not perfect.

With any such "port my favorite non-OSS app to Linux!" request, two thoughts come to mind:

Is there really a market that would pay for the development and QA effort? In the case of Photoshop, I would suspect that many of those potential users are simply using Mac OS X as their platform of choice these days.

Which release of which distro? You've got to develop and QA against something, and as anyone who has worked with a variety of distros knows, they often just aren't drop-in interchangeable. This question

I'm not knowledgeable about it, but Flexbuilder lets you make applications for AIR? I thought Flex and AIR were mostly unrelated... I figured to develop AIR apps you just developed a conforming web app (using a few special action script APIs for integration) and ran it through some compiler tool. Or something along those ideas. Seeing in the showcases how many existing web apps were ported in a few days to AIR, what exactly is Flexbuilder's role in that?Thats an honest question btw, not a sarcastic jab (sin

The AIR stack is essentially composed of two parallel environments. One being an embedded web browser (webkit) with javascript (ECMAScript3) bindings into the runtime. The other side is an embedded Flash 9 player with access to all that Flash offers as well as the additional AIR libraries such as sqlite. I believe FlexBuilder allows you to develop either one though I have only used it to do a Flash based AIR app.

The AIR stack is essentially composed of two parallel environments. One being an embedded web browser (webkit) with javascript (ECMAScript3) bindings into the runtime. The other side is an embedded Flash 9 player with access to all that Flash offers as well as the additional AIR libraries such as sqlite. I believe FlexBuilder allows you to develop either one though I have only used it to do a Flash based AIR app.

Looking at APIs that AIR relies on shows that it could potentially be ported to any platform:

The newest release of FlexBuilder (3.0) let's you compile the same codebase down to a.swf or AIR application. This was not the case with version 2 I believe. Adobe is also working on an offering called "Thermo," that will let graphic teams develop skins and UI's in CS3 that will compile down to a Flex application that can be imported into FlexBuilder. I pray that this happens sooner rather than later, because I have had it with our creative team doing all their work in CS3, taking screenshots, and having u

You can try hiding the Window with P/Invoke and then killing the process (or being nice and using WM_CLOSE) once the printing is complete. Just be sure to check to see if it's already open and the user is using it before running it so you know not to hide or kill it.

Actually, this is partially incorrect. While Adobe did not initially help out in the linux world, they have since ported the Acrobat Reader, and it works fairly well. In Ubuntu it's available from the commercial-unsupported repository, the package name is acroread. I had to find it because my school DRMs the PDF Textbooks with phone-home Ecmascript, and it only works in the Adobe pdf reader. (not document viewer or evince.)

AIR is a cross-platform development environment that also allows easy porting between desktop and web-based applications. Adobe is planning on creating webapp versions of their major desktop software, including photoshop, within the next 5-10 years. How are they going to do this and keep a manageable code base? You guessed it, they are porting them all to AIR. So Linux should get a native port of Photoshop when that effort is completed, whose "nativeness" is roughly equivalent to the "nativeness" of XUL-Runner applications like Thunderbird.

Here is one article on arstechnica [arstechnica.com] that has a little more detail. I'm sure you can google for more.

Congratulations! It's been only 23 minutes since an article mentioning Adobe and Linux has been posted, and already you've mentioned the gimp. In doing so you've made one or several incorrect assumptions:
1. Adobe ported Photoshop to Linux and renamed it to the gimp. (We're all hoping it's not this one).
OR
2. The gimp is a viable replacement for Photoshop for Adobe's target group (professionals).
OR
3. Slashdot users don't already know about the gimp. If this was an article discussing Photoshop alternatives for Linux, maybe it would be nice to mention the gimp; it's not. These comments wouldn't be so annoying if they didn't show up every single time there is an article about Adobe. The "use Linux!" comments on every Windows article can be funny (sometimes) because at least everyone knows they're more or less joking.

The gimp is not Photoshop, and is still missing some features that professionals really need, it isn't a viable replacement yet.

Adobe FrameMaker has run on more than 10 Unixes over the years, including Linux. Consider this nit picked!

Actually Frame Technology Corp. wrote Framemaker and ported it to many Linux/UNIX based OS's, Windows, and Mac OS. Once Adobe acquired Frame Technology Corp. they slowly dropped all the other versions until 2004 when they finally dropped Mac OS (who at the time comprised about half of their user base), making this product a Windows only. They basically put the whole program in the deep freeze with minimal updates to keep things working and no new features while they tried to migrate users to their home grown InDesign which was written originally for making magazines and was very unsuited to technical books (which was Framemaker's main target). In fact, they only recently started up development again (outsourced to India) when MadCap Software announced a new program called Blaze, which was billed as having every feature of Framemaker, but implemented from scratch with many new features and an order of magnitude better performance. As of 2007, they claimed to have no plans to support anything but Windows going forward.

Bwha? Yeah, "over the years" is the key phrase here. They experimented wide and far during the dot-com bubble, as everyone else did, but the only versions that count (i.e., anything past 2004) are essentially Windows-only. Luckily, FrameMaker is being dustbinned by the switch to XML documentation. Their version 8 is a pathetic attempt to remain competitive. RIP, I say. I really like Frame, but Adobe's massive lack of support for it has led it into a dead end.

I used Frame(Maker) on a number of unix systems and Linux (for a short while) and on MacOS, it worked just fine but Frame was not an Adobe product and Adobe kind of dropped the whole thing.

MacOS X is a unix and the whole Adobe suite runs on OSX, how hard would a port to linux be when it already runs on one unix? If Adobe wanted to it would have been done years ago, actually I have who used to work for Adobe and he said CS was already running on Linux but Adobe was not going to release it.

Maybe by "has run" you mean "once upon a time an obscure beta of this ran un Unix";)

Actually by "has run" he means "before Adobe bought the company that made it and then killed everything but the Windows version." FrameMaker started out as a SunOS app and the second supported platform was Mac OS.

I realize that Adobe's code can be... err, messy, to be charitable about it (at least judging by Acrobat Reader and FrameMaker).

Question is this: is this a step towards (hopefully) Adobe going over their existing products and re-writing them so as to make porting easier? I know they're working with Codeweavers to get P-shop to work on a Linux platform (via WINE), but it would be cool to see some native implementations instead.

I figure once/if Adobe can get things like P-Shop and Illustrator to work on a Linux platform, other graphics companies would have that final impetus to follow. While the higher-end CG vendors usually have Linux ports or Linux-native apps (Shake, Maya, etc), the mid-range, amateur, and pro-am ones usually don't (Modo, Silo, DAZ|Studio and Poser, Vue d' Esprit, Carrara, Bryce, etc).

It'd be hella nice to see the CG/gfx companies take Linux seriously across the board, and not just as niche/custom items, or as "hey, that OS makes a great render farm node!" type of platform.

I agree with you, it would be great if Adobe would start supporting Linux natively. I was even thinking that once Photshop is better supported under WINE, they may have a better picture of how many people use their products in Linux. Unfortunatly, Photoshop would not be able to accurately report back what systems people are using. This brings me to the OT rant. Some apps report back what system the user is running, essentially a survey so the company knows their market better. I encountered this with S

Just from a quick perusal of The Google, I'm getting a distinct feeling AIR is something of a glorified web browser. So you can run offline and on your desktop? Hmmmm... Does anyone remember Push technology? [wikipedia.org] Or Active Channels? [microsoft.com] It seems a little like that, but heavy on the Web 2.0 sauce. But like I said, this was just from a quick perusal of Google results. If anyone would care to point out what makes AIR, more than a glorfied Browser+AJAX, I'm all ears...

Not so much a browser but a runtime that allows you to create desktop applications using browser technologies. You wouldn't open the runtime and browse from site to site. An individual site might provide a desktop application that interacts with their own back end but also allows you to access your desktop resources better. Yes you do have to trust the publisher a lot more than when you surf to that same publisher's web site. You are after all downloading an actual program. As for the usefulness of it?

I have just about zero interest in it. For one thing, now there would be one more thing (AIR runtime) to make sure that my clients would have installed and up to date on their systems.

One of the reasons the web is so useful is that it is a very well understood, open specification. Anyone from major corporations to my grandmother can (relatively) easily create content than then becomes viewable to anyone with an internet connection and a web-browser

I would say the biggest difference is that AIR apps are not web pages. They are applications that have to be installed and have full desktop rights. So, anyone that can do html+ajax or flash can now create desktop apps.

I imagine the full desktop rights is the big kicker as they can interact with and affect the computer. Breaking out of the sandbox if you will. I would compare it to desktop java vs applets. The difference in capabilities is amazing when you are no longer restricted to the browser sandbox.

I've not given Adobe a single dime in a decade*. First it was their overpricing themselves out of all but the students-and-pirates market. Then it was about using their corporate power to influence our government against the valid rights of individuals [freesklyarov.org] who were speaking out about data security and the freedom to read.

I'm sure some cash went from Canon or Apple to these jackasses, when I bought hardware that bundled their teaser products (which I don't use). I regret even that level of support for Adobe.

...as Adobe has said all along that for Apollo/AIR 1.0 it would be Mac/Windows only. Once 1.0 was reached, then Linux would follow. I'm glad that Adobe's CTO came out and made the announcement, though. This continues to lead credence to Linux being a top-tier platform from desktop/productivity applications.I think the REAL interesting part, though, is how AIR relates to an earlier statement made by Adobe's CEO. He mentioned that in the future, all Adobe apps would be on the web. I think that statement

Top-tier? Their linux flash releases are buggy and always behind those of windows and osx. Even simple changes that should take a day to roll out wind up taking months. And air from the beginning was pushed back because they couldn't be bothered to step up the work on the flash player for linux. As much as I'm happy to see any support of linux, adobe's doing it as an afterthought at best.

AIR is a desktop runtime. When you install an AIR based app, it actually installs an application on your desktop. It just gives the developer the ability to write a desktop app using web technologies (i.e. Flex, HTML & Ajax, Javascript, Flash) rather than using C, C++, etc..

Yes, AIR is a desktop runtime...for a Web-based application. There's a lot of risk in letting Web apps loose outside of the browser security sandbox. It seems like a better choice would be to use Flash or Silverlight which run withint the browser security sandbox or run a "real" desktop application using.NET/WPF which uses the.NET security model.

AIR apps are desktop apps, period. They can access all your files, listen on sockets, draw non-rectangular windows, etc. As long as you treat them like desktop apps (by thinking before installing), there's no problem.

I think Adobe concerns itself with security. I just think that AIR does not have a well developed security model. Check it out yourself and see whtat you find. There's no question that.NET has a better security model than AIR. AIR will probably improve over time. What Ballmer FUD? Show me a link. No, every computer doesn't run.NET. Most do but not all. The full.NET framework doesn't run on Mac or Linux. Silverlight uses/will use the same basic programming model and does run on Mac and will run on Linux.

I guess Slashdot's trend toward suckage continues. Yes, I love that Slashdot is becoming a political site more than a tech site and the bias' run deep.

So Slashdot rejected the story submission about Adobe's release of AIR, and announcement that they were open-sourcing the Flex 3 SDK. And had released a new open-source project site for Flex, Tamarin and a few other products. Nope...that stuff isn't noteworthy to Slashdot's editors.

Bah!...rest assured if there is any political BS topic it'll be posted (even if it's been posted 2-3 times and is a year old).

So yes...

> Adobe AIR launches> AIR being ported to Linux> Flex Builder 3 being ported to Linux> Flex 3 SDK being open sourced

Just to give some background on this. AIR is an equivalent to the Java Runtime Environment. Now unfortunately (or fortunately) Adobe also released Flex 3 Builder (application development for Flash 9) at the same time and made it the easiest way to deliver AIR apps. You could easily build air apps using Flash 9, javascript or even plain html but I can't see the point to this.
There are certain things Air does provide that will be interesting to see how they are used: SQLLite engine and system resource (disk drive etc) access. The latter screams security risk however this the same risk as installing any app on your computer.
To be honest there are a couple of big companies (e.g. Ebay) that are writing AIR apps, but I don't really see there being much need in that arena (searching for auctions). I think it's is going to shine when hooking up to business applications (which is also indicative of the number of financial institutions looking for Flex developers).
As an example, I've written an air app that hooks into our servers and provides an easy way to managing our error log entries, and various data characteristics. Previously this would be a case of logging into the back end through a browser and finding this out from various reports. There may be a case that a better dashboard design would have made this simpler, however I can have an AIR app sitting in the background feeding this information to me, and most importantly, it took very little time, as it hooked into existing web services.
Personally it has a lot going for it, but it really is going to shine in big business.
Oh and please don't compare it to MS Silverlight. Compare Flash to Silverlight, but not AIR.

They could also make Flash actually work before moving on to traditional development tools. Supporting the half dozen Alsa derivatives & video scaling R the main issues. However, moving to development tools instead of focusing on Flash makes sense since Linux is mainly a development platform.

4) Adobe AIR isn't a web application development environment of any sort... that's completley messed up. It's the runtime component of a connected desktop app platform that supports HTML/CSS/JS/PDF/Flash content.

5) Macromedia (now part of Adobe) has made attempts to commercialize Dreamweaver/Flash/Freehand on Linux before utilizing Wine-compatible releases, but there was no enough demand to pay the bills, so the project was canned. I have the feeling they'll be trying this with selected Adobe CS applications again within 24 months, but it'll be expensive, so the market should show enough demand, and put their money where their mouth is, this time.

With a number of originally-for-Linux apps having been ported to OS X, without apparently calling for any overwhelming expense, why should Adobe's stuff, all of which runs on OS X, take much effort to port to Linux?

I'm sure it's not something done for free, but expensive? On the scale of what Adobe pays for office coffee each day?

With a number of originally-for-Linux apps having been ported to OS X, without apparently calling for any overwhelming expense, why should Adobe's stuff, all of which runs on OS X, take much effort to port to Linux?

OSX has a fully features POSIX layer (what Linux apps use), but Linux has no Carbon/Cocoa layer, which is what OSX apps use.

In other words, because you can run some DOS command lines in Windows, doesn't mean it's equally easy to run some Windows GUI apps in DOS.

In my day job as a tech writer, the only thing that keeps me tied to my Windows box is FrameMaker. Of which, at one time, there was a Linux version, later canceled for (apparent) lack of interest. Unfortunately, the project didn't live very long, and I wasn't able to get a copy while it was alive... something that I regret morning when I fire up Windows.I can get email (the company uses Outlook) through the Web-based Outlook tool, I use vi to write man pages and do HTML, and I can read various Word/Excel fi

It should be noted that the Linux version of Acrobat Reader seems fairly antiquated compared with its Windows counterpart. The last time I used acroread I was unable to fill PDF forms with it.

Actually it has worked with PDF forms for quite some time. The latest version I have (8.1.2) feels pretty nice and unixy overall. Of course it's still binary for i386, but it's much better than before.

You say that, and yet there are plenty of proprietary binaries available for Linux. Many distros have huge repositories of "non-free" stuff. Plenty of proprietary vendors make Linux binaries available (e.g. nVidia binary driver, Opera [opera.com], Skype [skype.com], etc. See also this list [wikipedia.org], much of which is distributed in binary-only form).

Yes, the vendor will probably only pre-compile binaries for the most popular architectures (32-bit x86 being the main one), and only for the most popular packaging formats (deb and rpm). But

Oh, I see. It's not that you missed the point. It's just that you don't care about the rest of the community that's worked their butts off for years to give you freedom. As long as YOU have an executable, it's OK. Great solidarity there.

I agree that having the code makes stuff easier, but there is no reason why companies wouldn't be able to run closed source software on an open source OS. And even if you don't want to compile _everything_ into a single binary, there's always the option of LD_PRELOAD together with your own shared libraries.

That is why they established the Linux Standard Base (LSB) [linux-foundation.org] and freedesktop.org [freedesktop.org]. You say "My software runs on LSB 3.2 IA32 and IA64" and provide a.deb and.rpm for each and be done with it. It's no more difficult that supporting Win32 and Win64 and providing a.exe and.msi for each.