If a car company sells you a car engine that bursts into flames, they're still held liable for damages. They can't just say "Uhmm... The engine may burst into flames, you should buy our next model".
The fact that Adobe can get away with this amazes me! With the theoretical engine problem you need to recall/repair each and every engine individually. With software, once you've developed the patch you can distribute it at next to no cost. There's no excuse for this.
Why can software engineers and companies get away with such horrendous practices?
> If a car company sells you a car engine that bursts into flames, they're still held liable for damages.
Not forever! Only for 10 years, after that they are no longer responsible. Software is the same way, only the timeframe is much shorter, and there is no set standard.
Although less than a year, like CS5.5 is too short. I would suggest double or triple the usual time between major versions as a reasonable timeframe, in this case that seems to be about yearly, so Adobe should provide support for 2 to 3 years for old versions.
But if cars are renewed annually with, say, one major revision every 4-5 years then the critical lifespan should be about double the time between major upgrades. That way old products can't be killed the day they're updated.
Why can software engineers and companies get away with such horrendous practices?
Because most of us who write software believe that the risks associated with effectively zero liability for software failure are far outweighed by the costs of government intervention. General purpose software is far too "easy" to create for mandatory liability to make any sense.
The better solution is for the market to demand simple security fixes in situations like this.
[Edited to clarify that software risk is less costly than government intervention]
They're not lazy. If you've ever used Fireworks in the Macromedia days and compare it to the massive behemoths of slowness they've added to each subsequent CS version, I can only conclude that they're not lazy. An effort this concerted to make no progress in ten years and add naught but a twenty second startup time on processors that weren't even conceived back in Macromedia Fireworks 8 days cannot be a product of laziness.
Just like I think that this here thing doesn't have anything to do with laziness. It's that Adobe wants you to pirate the crap out of CS6, because they know they won't get money from you anyway. They do know, however, that every cent they don't get directly from you is a cent they'll get from your future employer or customer or small business which is forced to buy Adobe CS6. It's not laziness, it's doing exactly what they need to to make sure that they keep their repeat customers upgrading.
Microsoft have the technical capability to deactivate pirate installs of Windows through WGA. Instead, they choose to display a nag message and disable software updates. Microsoft spent a ton of money developing a really sophisticated anti-piracy system, but decided against using it to prevent piracy by end-users. To me, that speaks volumes about how piracy fits into their business strategy.
The CS6 sub offer (50 bucks a month for everything) and preorder for old customer special ($30 bucks a month for everything) are making TONS of people sign up.
I am not so sure that they are lazy, per se - but I will say they have zero cult of personality in that company.
Name one famous employee of adobe along the same lines you would recognize with any of the tech titans: gates, jobs, ballmer, brin, zuck, etc. etc. etc.
Never has an Adobe's leader's name been in that list.
The reason this is important - is that there is no personal image attached to adobe's products. This lets them get away with more mediocrity than you would see with any of the above.
You don't have the scorn of the user all pointed at one person's identity - you have it pointed at the nebulous "adobe" as a whole.
If they had a charismatic, public figurehead I a sure there would be a lot different about how we view adobe and its products.
I was thinking this the other day, and given that Adobe is a company that could struggle with the demise of Flash on the web and growing discontent over its core product line the time is almost right for an evangelist to take control and make sweeping changes. If a person came along and made drastic changes, such as the re-branding of Flash, a complete overhaul of the Adobe Creative Suite and the stripping-down of the PDF format I can see a lot of people turning their heads.
There's an old joke - field marshal Model is asked the secret of his success as a commander. He says the key is managing the men under you. They are smart or stupid, energetic or lazy. The smart and energetic make excellent field commanders, the smart and lazy make good staff officers, and the lazy and stupid can handle supply. And the lazy and energetic? Transfer them elsewhere.
Adobe isn't lazy. It takes extra work to implement multiple cross platform ui libraries with twenty different slider widgets none of which work quite right.
Please stop comparing software with real world objects.
While popular the comparison between cars and computer programs are not well chosen. Actually comparing software to any physical object is point-less. These two only have anything in common on the surface.
If you were to make software require the rigorous testing that physical products like cars undergo you would likely never be able to ship anything. If you did the customer would not be willing to pay the price.
Software is infinitely more complex than even space shuttles. The number of possible combinations which you program can traverse is so big it doesn't make any sense.
You could of course start proving mathematically that your software will always behave correctly. This would require you to use a language which facilitates such a method like erlang. No more web development in PHP, Ruby, JavaScript or anything else which relies on probabilistic garbage collection.
I guarantee you that once you spend the money having your code proven your costs are so high that no one will buy your software. In stead they'll turn to the competitor who wrote it in VB and accept their EULA and live with any errors.
The nature of software is not the same as of physical objects. You can either accept this and plan accordingly or you can betray yourself and keep getting angry about bugs.
"Software is infinitely more complex than even space shuttles"
Hardly.
I write software for fun, everything from low level drivers up the stack to web apps. My job is engineering mechanical systems more complex than the space shuttle - and with more lives at stake.
There was actually a great story of the Space Shuttle software engineering team and their development practices. Generally speaking, they wrote code with zero bugs. Like...NONE. For 25 years.
They did it with an almost insane level of attention to detail.
Thanks for that link. I really like krschultz's parent comment and your follow up. Does anyone know how to get a single-page view of that article, though?
The process maturity index which used NASA/JPL as its exemplar was the big IT management fad of the late 90s (it dovetailed nicely with ISO9000 TQM) before XP and then Agile became popular.
In a sense, the problem with Adobe seems to me to be the alignment of organizational goals with user benefits, and not software process.
I don't have any experience with engineering mechanical systems, but I think there are at least aspects of software that are more complex than building physical things.
Software is expected to scale by many orders of magnitude in many dimensions. The equivalent would be a vehicle that supports carrying between 1 and 1 million people, can travel anywhere between 1 and 1 million mph, running off fuel between 1 and 200 octane. Physical objects are never expected to support such wide scaling parameters, and yet this is very common in software.
Software is also expected to run on lots of different kinds of hardware with different features and performance characteristics. A rough analogy is a physical design that has to support being constructed from either aluminium or steel.
Since software is more abstract in nature, you'll often hear people saying that they weren't even sure what they were building until version 2. The requirements are also more likely to change during the engineering process. Mechanical things seem more likely to have a well-defined purpose and scope throughout the engineering process.
Eh, I don't really buy any of that. Have you actually worked in the mechanical engineering world? I feel like it's far more gray than software engineering. I might have a specs on the output, but the environment is the actual physical world with all of its problems. Corrosion, temperature, vibration, dirt, dust, etc. It just screws with you the entire time. The abstract environment of a computer is tame in comparison. The only thing you have to worry about is the dependencies - which is basically configuration managament. Configuration managament is a problem in the mechanical world too. Except if you design a power plant to Rev B of the drawing, and show up with a Rev A drawing part that doens't fit, you might be out millions of dollars and months of times because there is no 'recompile' button when it comes to giant machined parts.
As for your specific examples, 'different kinds of hardware' is no different than saying my system needs to work at -30F and 130F temperature. Materials behave very differently at different temperatures and we have to account for that. Some metals are weaker in temperatures as high as +25F. That's something you will see all the time.
You are also vastly over-rating the complexity of scaling. It's really not that hard. Are you really going to tell me it's harder to figure out how to scale a web site than it is to build a rocket engine? Because there are about 1,000 web sites out there with millions of users and only about 10 organizations building rockets.
> Have you actually worked in the mechanical engineering world?
No (which I admitted up-front). But have you ever worked on large, high-availability distributed systems? When you say that scaling is "really not that hard" I'm suspect that the answer is no. It is absurdly more complex than single-machine programming. There may be more people building large websites, but that probably has a lot to do with the fact that a lot more people visit websites than ride on rockets. If you look at the number of support staff needed to run a website like Amazon vs. launch a rocket, I bet they wouldn't be that far off.
I'm not saying mechanical engineering is easy, I'm just saying the software isn't easy either. I also don't think that you can draw the conclusion that because we have 60 years of mechanical engineering process that software should fit into the same processes.
Having worked on large scale systems I would agree with him. Scaling is only hard when you completely ignore it at the design phase. IMO, designing scalable systems is often easier, because they need to be loosely coupled to handle failures. Honestly, I think most of the hard real world software problem tend to deal with legacy systems and the near organic mess that builds up over time.
So what's your database system like. Well, we are 1/2 though the transition between A and B, we don't have a DBA so Bob wrote something to create build scripts based on changes made in this file. It's buggy and we are starting to try out C but if you ...
These papers all describe solutions to "hard real world software problems" and have nothing to do with legacy systems. If you think there aren't hard problems in software, you're probably not working on one.
doc4t's next sentence ("The number of possible combinations which you[sic] program can traverse is so big it doesn't make any sense.") is critical in understanding the sentence you quoted. Writing software is not so complex, but guaranteeing its operation is insanely complex.
And how is that different from a mechanical system?
We have fatigue/vibration, corrosion, and wear. What's the equivalent in software? There is a reason they park perfectly good airplanes in the desert - we can't gaurentee they won't fall out of the sky because it's impossible to perfectly predict fatigue.
And I have issues all the time related to things failing 3 or 5 years after they were built (yet they have a 40 year design lifetime). Metals always seem to find a new way to corrode and bearings find new ways to fail. There is no equivalent to a corrosive, hostile, environment in software.
Not to mention the random things thrown at you in the physical world. If you design jet engines, be prepared for birds to get sucked in (hopefully not too many, and if so, hopefully your pilot can land in a nearby river full of ferries to pickup the passengers). If you design buildings, get ready for earthquakes of unknown size, hurricanes of unknown wind speed, and terrorists with various methods of taking your structure down.
We can't gaurentee anything. In fact we can barely test most of the complex stuff because it's too expensive. Cars are cheap relative to most things. They don't crash 737s to find out what happens or shake an entire city just to ensure that it is built correctly. You have to predict all of this stuff using calculations and it largely goes untested.
> And how is that different from a mechanical system?
Most mechanical components obey underlying physical principles that have linear or quadratic approximations, at least in certain regimes of environmental and other factors. Therefore, we can model the component and we can know when we are unable to model it.
We manage overall system complexity via physical/mechanical modularization, with things to insulate against thermal, mechanical, chemical, electrical coupling. By testing individual components, we have basic assurances on overall system behavior.
Software attempts to do this with "good design principles", but the truth of the matter is that just about any software component in a typical application can completely jack up the global environment for other components, and processes can make OS and environment modifications that completely break other processes belonging to the same user.
Try issuing performance guarantees on an airplane whose fuel pump can set μ0 and ε0 to -1 if the ground crewman that filled the wing tanks was named "Bob Null".
Computers are physical machines that obey the laws of physics. Flipping bits at a lower microcontroller level can be observed as literally directing electrons to travel to specific chip pins.
With unit tests and behavioral tests, we can assume basic assurances on individual components working as a whole.
Engineering also has good design principles. One does not make gear teeth perfectly angular (take a look at the Antikythera Mechanism) because it can lead to premature wear and will have poor performance. In fact, there are hundreds if not thousands of kinds of gear teeth, and interchanging them within the same application can have all kinds of long lasting effects. Take a look into any vehicle recall in the past 2 decades and see that nearly every one of them is an edge case bug that slipped by Q&A.
Not accounting for the string null being valid is a bad design principle within the domain of software. Just as using Frozen water as a bearing surface in high speed rotational machines (Hey! It's hard and slippery! It's perfect!) is a stupid mistake, not accounting for valid "Bob Null"s will also lead to premature failure if not for the database but for the business.
We've only been at software engineering for less than a hundred years. We've been at mechanical engineering for a good 2000 (see the aforementioned Antikythera). We might need a few more years to iron out best practices as an industry.
Here's the thing: physical processes and failures tend to average out to nice smooth functions with Gaussian distributions. Each additional random variable has a minimal contribution to the average state of the system. Wear and tear tends to accumulate gradually over time until some mostly predictable breaking threshold is met.
With digital computers, however, the size of the state space that the system can occupy grows exponentially with the number of bits of state in the system, and changing a single bit can result in an explosive cascade of changes to the rest of the system[0]. Accumulated random failures of computer software very rarely lead to a nice, smooth, predictable probability distribution. Software failures are not caused by anything remotely resembling wear and tear.
[0] Please excuse and correct any inadequacies in my autodidactically acquired understanding of information complexity.
Read Feynmans analysis of the Challenger disaster if you want to see just how well an physical engineering problem can grow exponentially due to changing the properties of a single bit - a difference in temperature of a few degrees changing the mechanical properties of a rubber o-ring in that case.
I never did any mechanical engineering so I trust your statement.
It's still a good example when trying to convey the complexity of software to people who don't understand computers since most have an idea that space shuttles are very complex (which they of cause are)
My point was that that testing all possible combinations of how your app can execute is next to impossible unless you are willing to cough up a serious amount of money for rigid mathematical proving. Which would then make it too expensive.
I think it does a disservice because it overlooks the fact that people have figured out how to solve these problems.
All engineers are human. Whether you are working on a space shuttle, an airliner, a nuclear power plant, or an iPhone app, you are a human. Humans make mistakes. Humans overlook things.
So how do we engineer really complex systems with hundreds or thousands of lives at stake to an exacting standard - knowing that the engineers are human?
The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process.
I know a lot of guys who love to wrench on cars. They swap parts, add horsepower, change out the suspension, etc. They can build a really fast car. But that's not mechanical engineering. They are mechanics.
In a lot of ways writing software is like that. Glue together some libraries and APIs the same way a tuner supercharges an engine. But that isn't engineering.
Obviously we don't need the rigour of the space shuttle to make an iPhone app, but if your application calls for that complexity (or your budget/liability is large), then you need to bring in the process mechanical engineers have been using for the last 60 years.
That means multiple people checking all the code. That means a well planned out arrangement/architecture. That means testing the individual parts thoroughly and the whole system together. And it means very specific configuration managament of every dependency.
It's not impossible, it's just not the willy-nilly fun part of hacking stuff together. It's the ugly paperwork inducing lame part of working in a big company. But that process if done correctly helps catch mistakes.
You can build software as reliable as a car, but that's not the issue. You cannot build software with all of the features desired by management in the time allotted and also make it robust. It's a matter of priorities, and robustness is not Adobe's priority.
Although you're right that for some projects, the poor quality is because it's more fun to just hack it together, but for many, it's a matter of business priority. I've worked on projects (avionics software) that had the rigor that you describe. I've also worked on projects where the developers consistently tried to add robustness, but management kept redirecting them to add more features.
"The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process."
I agree. I'm not sure it ever will. But comparing software to a car and the relationship between the buyer and seller is too simplified. Software have bugs. Many more bugs than cars. Because it's not tested properly. Which we don't do because no one would buy it at the price which comes from proper testing.
You can accept this and write your contract accordingly or you can sit down, muck and be disappointed when it fails.
I'm not saying it's right - it's just how things are.
> Software is infinitely more complex than even space shuttles.
That is not an inherent property of software, the problem with software is that it makes it all too easy to hide complexity, and that some of the costs of complexity are not superficially apparent.
Add on top of that how in the name of 'reuse' we pile more and more layers of complexity, and you end up with systems that are humanly incomprehensible.
But this doesn't mean that writing simple yet functional software is not possible, it just requires much more care, thought and self-discipline.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." — C.A.R. Hoare
"The computing scientist's main challenge is not to get confused by the complexities of his own making."
— E. W. Dijkstra
Most software complexity is of our (programmers) own making.
The OP are not comparing cars to software. They are comparing the natures of the commercial relationship between the owner and the car manufacturer and between the user and Adobe. Expecting free "recalls" from Adobe is not unreasonable.
Exactly. I was not saying software should be theoretically guaranteed -- the responder just assumed that.
Adobe has a fix to a serious vulnerability. Not releasing it when the cost to them is tiny is essentially criminal negligence, especially when they say the fix is available to those who are willing to pay...
This is the same company that owns Flash which runs on >99% of the desktop machines connected to the Internet.
You seem to be arguing against consumers insisting Adobe ship defect free software as the cost would be prohibitive, which is true. But that isn't what's being discussed here.
What is being discussed: when a defect is discovered in the product by the end consumer, is it a fair (or proper, or wise) business practice to charge the customer for the software patch?
No I don't think it is alright to charge for a patch.
It was not my intention to side track the discussion. I just don't like the simplification of comparing with cars - but the OP made it clear that I misunderstood his post.
You point out that real world comparison is pointless, fail to elucidate why, and then go and make some of your own comparisons with the space shuttle program...
Ok. The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops. If your program don't have it then I'm sure Node, Apache, Postgres, Rails whatever have plenty.
While many of these combinations may never happen you would still have to provide proof of all of them not causing your program to go into a state which you can not handle.
"and then go and make some of your own comparisons with the space shuttle"
This was a comparison of complexity - not a direct comparison between the two.
The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops.
Can you elaborate on this? I'm not convinced that this is true (but am willing to be proven wrong)
I ment the whole stack...not just a single fizzbuzz snippet.
As I see it this is what is going on when your users use a webapp.
The user runs some client code which you wrote. In a browser which other guys wrote. Running on an OS made by some one. Sending data back and forth via protocols and network equipment with software that other people wrote.
You server OS receives the request and passes it to your load balancer which distributes to Apache which forwards to PHP which routes to SQL...and all the way back.
With the millions and billions of lines of code involved in these steps it could likely be a number of this magnitude.
Those of you who are surprised must not be actual Adobe customers. Only when you've been through the process of handing of thousands of pounds for their software will you realise how awful a company they actually are.
It's a more of a subjugation than a transaction, like a sacrifice to a cruel god, the cherry on the cake is you have to actually wait until a person "approves" your purchase/sacrifice.
Given the enormous cost of Adobe software, you'd think they could afford to support their previous major release version with patches. CS5.5 is only a year old, and was not a free upgrade from CS5.
Other commenters here are right. Microsoft does the right thing by supporting old OS's with patches years after the new versions have been released. That's the kind of support you deserve when you pay a premium price for software. These aren't $2 app store diversions made by an indie developer.
> These aren't $2 app store diversions made by an indie developer.
That's kind of an insult to smaller devs, who by and large offer excellent service and typically provide multiple free content updates. I paid $2.99 for Plants Vs Zombies and it has been updated more times than I can count.
It's not so much an insult as it is a testament to the current state of customer service between indie devs and a megacorp like Adobe. I don't like the comparison though, if a $2 product doesn't get fixed, people won't buy it en masse (or recommend it), Adobe has an insane market position. People will buy their product. Watch Adobe not go out of business as people purchase CS6. Having said that I'm not sure how people can vote with their wallets when Adobe pull shit like this (security patch via purchased update).
Or they could have pushed a minor security upgrade that fixes this bug. For free. It's probably a simple buffer overflow bug and can be fixed with a change to only a few lines of code. After the problem has been identified, it takes roughly 10 minutes of coding to fix the issue and perhaps a day or two for regular testing and distribution processes.
Does anyone with legal knowledge know how a class action suit would play out here?
I own a copy of CS5.5 that was purchased 5 months ago.
I'm already frustrated at the cost of the CS6 upgrade. Now Adobe is publicizing a critical vulnerability in their software for which the solution is me paying them for that upgrade.
This feels a lot like extortion: "Sure would be a shame if someone followed our explicit directions and sent you a TIF file that took over your computer. Have you considered buying some protection?"
Does one need to wait for the threat to be carried out before one has a claim, or is the veiled threat itself illegal?
I agree that there is a difference, but I'm not sure that the courts do. Consider what Adobe's interpretation would be if someone was merely linking to a torrent of their software, rather than directly publishing it. Then consider that in this case their negligence yields them financial gain.
I don't know what the legal standard is in this case --- my question is genuine. But I do know that I consider Adobe's stance reprehensible, and as an affected party I would willing to be the lead plaintiff in a class action suit if a qualified attorney would like to take this on.
They're not exactly trying to get it taken down either. I'm sure that their legal team could make that happen, if it was in the company's best interest.
I have Photoshop CS5. I didn't event know there was a vulnerability in it. So, after all I paid for this, there is a vulnerability which lets an attacker take control of my system... and they aren't fixing it?
Seriously... what... the... fuck. I'm never buying an Adobe product again.
So, you pirate it instead. Adobe will still win out, since you'll still keep using Photoshop and are still bound to their toolkit. You'll put it on your resume, you'll be employed by a company that buys it and has to buy it legitimately. You're not punishing Adobe unless you create a genuine replacement for the toolbox of Illustrator, Fireworks, InDesign and Photoshop and are putting those on your resume, unless you're versatile with those more open-source tools, whenever they should exist.
Is Pixelmator not a decent alternative to Photoshop? What about the GIMP? I haven't installed Photoshop in years, but then again, I'm a developer, not a designer.
I've tries using pixelmator as an alternative to photoshop. The main problems: No layer effects, no pattern fill, no paths. Good for simple stuff though.
> Adobe released a security upgrade for Adobe Photoshop CS5.5 and earlier for Windows and Macintosh. This upgrade addresses vulnerabilities that could allow an attacker who successfully exploits these vulnerabilities to take control of the affected system.
so what is it now? Still - even using security fixes as a vehicle to push people into upgrading is a bit crazy considering that the new version has just come out. Not even volunteer-supported software stops supporting the previous version the moment the new one comes out.
It took me a while to fully understand this bulletin because the idea that Adobes suggested solution to a security vulnerability is to sell you CS6 was so foreign it didn't seem possible. It looks like CS6 is a $199 upgrade.
I've had "Make stuff in Flash" sitting on my todo list for a while now, I'm officially ready to strike it from the list of things I'd like to learn, if this is Adobe's corporate attitude.
To clarify, I wanted to submit to portal sites like newgrounds and kongregate, just for fun. Nothing commercial, just a bit of fun with some well established communities. But I don't see myself looking into it at all now.
If you want to do cartoon animation, look into ToonBoom. If you want to make games, you don't need to buy Flash, look into FlashDevelop and some AS3 game frameworks, etc.
This is coming from a guy who's been using Flash for years and every day at work. Adobe is really mishandling a lot of things at this point and in my mind the future of Flash is questionable at best.
Thankfully there are better options for what you're looking to do. :)
I have sent some emails internally at Adobe to clarify the message here and hopefully this will be addressed soon. The bulletin notes a security update to CS5.5 and earlier versions as well as this issue being resolved in CS6. I suspect that it is really a matter of poor wording within the bulletin but, as this isn't my area of expertise within the company, I am trying to confirm.
Please keep us updated! It's possible Adobe may have just alienated any of what remains of their remaining paying users. An exaggeration I know but who knows the extent.
Microsoft famously did this on a much higher level with their Exchange product. Not affecting individual users, but entire companies.
Exchange Server 5.0 was released without any relay control. Every Exchange 5.0 box would happily send all the porn spam anyone wanted to spend, with Microsoft customers paying for it with their bandwidth bill.
A missing feature, even an important one, is part of the initial purchase consideration. It's not comparable to a severe defect found months after purchase.
I'm looking at it in terms of a 5.0 product. Unless they secretly removed the feature from that version (I'm assuming not but please tell me if I'm wrong), then anyone buying it knew what to expect.
In terms of car analogies, one that 'bursts into flames' needs a recall, but one that tends to overheat in the worst days of summer, in a product line that's always done that, is a fair deal.
There was relay control on Exchange 2000 at the virtual server level. However, Exchange 5.5 added controls to the mail service interface, where they probably belonged. cite: http://technet.microsoft.com/en-us/library/dd277329.aspx
Don't forget that the majority of people see computers as tools or vehicles, and just like you have to fill your gas tank from time to time with expensive gas, they think it's perfectly normal to pay for software regularly, even when it doesn't offer new features. Just keeping it going costs money. That the upgrade from CS5.5 to CS6 is a 'Critical security vulnerability fix' is a detail most users won't even notice.
That's just like saying you should pay for car repairs when a faulty design of the cruise control made you loose control of it and crash into something.
Aviary (http://www.aviary.com/) comes to mind. For the book production, PressBooks (http://pressbooks.org/) is an attempt to simplify the process and disrupt the CS based tool chain.
I am also working on something in the domain. Hoping to show it to the world very soon!
"Fix it up" includes adding 16-bit-per-channel colour, something that photographers have been crying out for that the GIMP team hasn't managed in 15 years of trying.
GIMP 2.10’s core will be 100% ported to GEGL, and
all of the legacy pixel fiddling API for plug-ins
is going to be deprecated. Once the core is completely
ported, it will be a minor effort to simply “switch on”
high bit depths and whatever color models we’d
like to see.
More than 8bpp color depth is available in GIMP and has been so for a while now if you use the development version. GIMP was a little late to the game, but the issue has been fixed.
Also: your comment was arrogant and impolite towards the GIMP team.
It is extremely meaningful if you, you know, actually consider the context of this thread -- which is not someone telling an artist to use GIMP, but a discussion of "fixing up" the program.
Sometimes you just need a feature before it's available in a released version. You can either go get the dev version or bitch about it. I tend to do the former.
In fact, I use quite a lot of software from their development repositories, e.g. GCC and Blender. It is a very rare occasion that I come by a bug as most open source projects have sane version management practices and branching processes.
Unless I'm missing something, the latest download available on that site is 2.6. I realize it's free software, so it probably is a little cheeky to complain, but it can't be a photoshop alternative if it's not available on OSX. From what I understand, the new GTK broke tablet compatibility for OSX. If anyone knows enough about those issues and the underlying languages and libraries behind GIMP, consider this an invitation to get involved: http://www.gimp.org/develop/
I'm excited about the unified interface and the new transform tool, so here's hoping it is just a couple more days.
>So, is someone going to do a startup to obliterate Adobe's print and graphics production monopoly, or what?
Sure, they would just have to build a compelling set of apps, for Windows and Mac at the least, that have 90% of those features that Adobe has built to their apps since 1990.
There DO exist competing products for Adobe stuff, but they are disparate. The best of them is Quark (vs InDesign). Final Cut Pro/Avid et co do a nice work against Premiere. Inscape is quite good to replace Illustrator, maybe Corel Draw too. Gimp is not there yet, but Corel Photo-Paint and Painter combined would make a compelling proposal. So, you have parts here and there, but not streamlined nor combined. And for all the "bloat talk", Photoshop can handle huge images with ease whereas lesser programs throw the towel even at 200MB or so.
(We have tons of 20% solutions -- they are not any good for professional printing and graphics work with the ease and breadth current designers are used to, even missing extremely critical parts, like CMYK in some cases).
We have tons of 20% solutions -- they are not any good for professional printing and graphics work
Yes, that's the real problem.
None of the OSS offerings is really anywhere close to the equivalent CS tool yet: not Inkscape, not the GIMP, not Scribus.
Quark and Corel should have the pedigree, but last time I had this conversation I looked up the latest features in Corel's graphics software, and it's basically a second-tier player these days. I've never used Quark, but the picture painted by others looks similar.
The thing that puzzles me is why no-one has yet come up with a credible competitor to CS (or, similarly, to MS Office). Two of the most successful software companies on the planet make a very significant chunk of their profits on these product lines, and they are certainly open to disruption by competition based on usability and/or quality/reliability as well as functionality and workflow. Of course there's a substantial barrier to entry, but it's not that unassailable in software terms.
There are also network effects at play - your co-workers create .psd files, and your printing company takes .psd files, so you use Photoshop. There is also ample training material, frequent conferences, etc.
That was Corel's problem - not matter how good a tool they made, printers either could not open the files, or were scared off by bad experiences with previous versions.
Google docs has only succeed because "close enough" formatting was good enough for business docs and spreadsheets. Not so in graphic design.
Actually, Google Docs has not succeeded. You and I may used, but last time I checked it had something like a 1% share of the "office suite" (i.e if you include desktop Office et al).
Quark was the Adobe of their time. If you thought the licensing of Adobe is intrusive now you should here the stories of Quark licensing in the 90s. They took piracy paranoia to an insane level. And the companies that bought Xpress sometimes reverted to the pirated copies because at least those worked.
Quark became more and more user-hostile through the 90s, basking in the dominant market share of their (essentially) single product. Prices went up, the feature set stagnated, anti-piracy measures punished the honest, and Quark tried to push ill-conceived "multimedia" and web features into the product. Focus was lacking not only in their product, but in how the company was run: development and support were moved to India, and then a few years later moved right back. And despite all this, in terms of dominance Quark XPress was like the Photoshop of its time: with all the professional workflow based on the product, the ecosystem of expensive plug-ins, and the people whose jobs were practically defined by their Quark expertise, it was difficult to imagine how any competitor could gain traction.
But Quark's unpopularity with its captive customers created a fertile field of potential good will for anyone with the gumption to try jumping in. And the nimble upstart who finally gained traction was of course Adobe. InDesign was cheap, good, addressed many of the long-term unresolved Quark pain points, and, despite bugs and shortcomings, held the promise of a future outside Quark's cloak.
A decade later, where are we?
The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which.
Indesign 1.0 definitely did not. It was Quark's market to lose and by Indesign 2.0 prepress shops were just starting to take Indesign files. The rest is history.
The designers I worked with at the time were early proponents of InDesign and basically told printers: "If you want our business, you'll have to buy InDesign." They did.
Granted it's only image editing. And it's mac only. But I've pretty much stopped using Photoshop because of it. Though, I've never use any of the advanced Photoshop tools.
Many graphics folk on Photoshop are stuck cause they can't see any other product filling Photoshop's role.
I've looked into this internally and here is the official response from the security team:
While Adobe did resolve the vulnerabilities addressed in the security bulletin you are referencing below (APSB12-11) in the Adobe Photoshop CS6 major release, no dot release was scheduled or released for Adobe Photoshop CS5 or CS5.5. In looking at all aspects, including the vulnerabilities themselves and the threat landscape, the team did not believe the real-world risk to customers warranted an out-of-band release for the CS5 and CS5.5 versions to resolve these issues. The security bulletin for Photoshop is rated as a Priority 3 update, indicating that it is a product that has historically not been a target for attackers, and in this case we are not aware of any exploits targeting any of the issues fixed. Installation of the upgrade is therefore at the user’s/administrator’s discretion.
Installation of the upgrade is therefore at the user’s/administrator’s discretion.
If this is purely because it's not high enough priority to justify pushing a new release, they should provide an optional download link for security conscious users. Is there such a link? Sounds from the linked page that there isn't and that the only option is to shell out cash.
Why can the not just take the patch file from the commit which fixed the flaw, apply it against previous versions of Photoshop and release a upgrade for all versions instead of making people charge for it.
A better bit of advice would be "Do not use TIF files unless you have brought CS6"
It's a tough call for the company. They don't make money on old versions of Photoshop, they make money on selling the current version. Engineers may have long since all been assigned to working on the current version or later, or even switched companies. So if the fix required significant work you'd have to make some current product schedule slip to go fix an old product used by people who haven't bought the latest version and may never buy again. Do you put your resources into supporting your current and future buyers or put your resources into supporting old buyers who haven't upgraded and may not, just on the off chance it helps your reputation, and you get more buyers in general...it's an extra step of indirection that may lose the internal support to redirect the resources to fix the problem.
And yet, it makes me lose immense trust in their company. Why should I buy the current version if I'll just have to update from a security exploit in one or two years?
If the software is making you profit, it makes sense to buy.
If the software isn't then why are you paying money for it in the first place?
A software company survives on selling licenses, and although I understand the moral implications of selling a security update like this, I think they are justified if the fix costs a lot of resources.
"The Adobe Creative Suite Cleaner Tool helps resolve installation problems for Adobe Creative Suite 6, Adobe Creative Cloud, Adobe Creative Suite 5 - 5.5, Adobe Creative Suite 4, and Adobe Creative Suite 3 software. The tool can clean up install records for any pre-release (beta) installations of these Creative Suite products. The Adobe Creative Suite Cleaner Tool is designed to not interfere with existing installations of previous versions of Adobe Creative Suite products; it does, however, allow you to remove them as well, if you so choose to."
They have been lazy in essence. They decided not to backport the fix because it is too hard or it didn't fit in the schedule to ship CS6 out of the door.
Having paid for 5.5 just a year ago (and having gone through the hell of Adobe Support to get things working), I now fully and sincerely say FUCK YOU to Adobe and related parties. Anything and everything I can do to (legally) promote your downfall, I will. You FULLY deserve your AWFUL reputation. Die and burn in hell.
I know HN is not the place for outbursts. But I have seldom had a worse customer experience. I'm sure some good people work there. My advice would be: Get out!
I'd be surprised if this ends up being exploited - from a practical perspective it'd be extremely high effort for comparatively little reward. Both platforms are ASLR now + no bundled scripting ability in tiff + manual work flow (ie you can't feed it to an automated process 10,000 times in a row) + low install rate (compared to say, flash or qt).
Hell, at least Adobe doesn't charge you for a support contract just to let you read the CVE with WONTFIX :D
This vulnerability hasn't been seen in the wild they say. And yes, the likelihood of someone opening a TIFF file they received by email in Photoshop is low. A lot of work to create this virus for very little payoff. The people who open email attachments are not the same people that have Photoshop installed. And in this case, you'd probably need to save it to disk and specifically open in Photoshop since most people won't have TIFF associated with PS automatically.
It's a tough call to fix for every possible version of Photoshop affected when the likelihood of it even happening is very very low.
It would appear that Adobe think that Photoshop is a target for attackers as the company says that it does not believe that "the real-world risk to customers warranted an out-of-band release to resolve these issues" - see here: http://www.h-online.com/security/news/item/Adobe-Photoshop-i...
Another reason to support and use opensource software whenever it is possible. Thus even if the software doesn't provide any update you can easily fix and close the security hole. Adobe did the same for 64bit flash player in the past. They did update the 32bit flash player on Linux, but the 64bit one just waited ~1-1.5 year for an update.
Anyone knows what happens when you open the POC[1]? I read most of them try to open calculator(on Windows). What is the equivalent on Mac, or is it a windows-only POC? :P
Only took a quick look at it, but I can't see any NOP sleds - and you'd probably need more room to reliably spray the heap anyway. My guess is that it isn't weaponized at all - it'd just cause memory corruption (but I don't have PS).
Wow. I don't even. Not that I advocate hacking, but it would be righteously ironic if some of Adobe's employees hadn't upgraded to CS6 yet, and someone broke into their systems using this vulnerability.
It means Adobe is not aware of any attack exploiting these in the wild. They're declaring this security bulletin a priority 3 which reads[1]:
> This update resolves vulnerabilities in a product that has historically not been a target for attackers. Adobe recommends administrators install the update at their discretion.
Are they allowed? Consumer protection laws in the UK suggest that up to a year after purchase one may be able to get a full refund or a fixed product at the customers choosing ... not sure why/if that differs for some reason with digital products.
I'd guess most copies are bought by businesses whom such laws don't aid.
It probably isn't difficult to get around such laws in light of the fact that you're actually purchasing a license to use the software and not in fact buying the software. The license-purchase paradigm usually means the vendor can do whatever they please, up to and including pulling the software right off your machine should they feel like it. Examples of the aforementioned include the kindle book scandal and sony pulling games out of their online marketplace that people had already paid for.
The fact that Adobe can get away with this amazes me! With the theoretical engine problem you need to recall/repair each and every engine individually. With software, once you've developed the patch you can distribute it at next to no cost. There's no excuse for this.
Why can software engineers and companies get away with such horrendous practices?