People in the UK make fun of the intelligence of the Irish and then say that the single-transferable vote system (used in Ireland) would be too complicated for the English voter, so don't be too surprised.

Just wanted to thank you for the links. I was especially pleased to find that Python is supported!

Thank you! You've given me reason to sit up and pay attention when 3 rolls around, I appreciate that.

I would recommend against showing the more diehard Photoshop fans that link, though. It won't get you anywhere because what it really needs to be is a list like this:

- GIMP has a plugin/feature for automatically generating normal maps from elevation data.

- GIMP has a perspective correction feature that is superior to Photoshops in that it...

- GIMP's 'save all layers' button saves all of the layers in your file into seperate files.

.. or something like that. In the list you gave me, points 1 through 4, and 7, are irrelevant if somebody already has Photoshop. Given its de-facto marketshare, that is likely.

5 is horribly overrated. Lots of artists can script, but few (if any) can make actual plugins or modify the source code. (Even if they do dig in to the code how do they maintain those features when a new version of GIMP comes along?) I do want to mention, though, that there's another reply to my original post that seems to have covered the scripting point. I haven't checked it out yet but given that scripting is something I do, I'm certainly interested in trying that out.

6 needs an extra line, something like: "its better than Photoshop's Batch feature because...."

10... actually this is a really good one. In fact, just before this thread started, I went and found the portable version and downloaded in. Why? Welp, if the scripting that Culture20 posted a link to turns out to be worthwhile for me, coupling that with a portable version of GIMP is *awesome*. What that means is I will be able to automate certain tasks AND keep a fresh install on my DropBox account so I can even use it off-site. This is 1 out of 9.5 (I gave partial credit to the source-code bit) and, as you can already see from other replies you've gotten, most are refutable.

I'm a little worried you might read my post and think that I'm trying to perpetuate the GIMP vs. Photoshop debate. I'm not, instead I'm trying to explain what needs to happen explanation-wise to get more Photoshop people to try GIMP out. I think there's this mentality that people should switch to GIMP and that's simply not true. If you got the professional Photoshop users to start using GIMP for certain tasks, you may find that some studios may find it worth their time to invest some development time into improving it. Given how Adobe has been dicking around with the licensing, this would be a good time to get that ball rolling. Start touting the unique features it has that shave man-hours off a project. If those features don't exist, then the team needs to start talking to people like me and finding out what else they need.

Care to run off a list of ways that "GIMP doesn't come close"? If it's really so bad, it shouldn't be that difficult to name at least a dozen or so... In actuality, I expect that enumerating the shortcomings of GIMP will not be in quantity, but in terms of a relatively small number of particularly desirable features that many may perceive as critically important in such software.

Hi, professional artist here. Your latter point, at least from my perspective, is correct. I know Photoshop really well, but since I make my living doing this work I am not biased in a way that'd prevent me from using a free tool. Let me be extra clear: It would hurt me to be fanboyishly loyal to be any particular app. I do pick up and mess with GIMP from time to time, but it has two critical omissions from Photoshop that make it unusable in my field. First, it lacks adjustment layers. Second, it lacks Smart Objects.

These are both features intended to do non-destructive editing of imagery. Let's say you have a tree with green leaves. You can create a Hue/Saturation 'adjustment layer' that will turn all the green pixels beneath it blue. If you put a picture of a different tree below that layer, its leaves would turn blue, too. If you took that tree and made it a 'smart object', you'd effectively be snapshotting that image and every operation you do causes it to regenerate itself. In other words, if you shrank a Smart Object down, then scaled it back up again, you'd get all its original detail back.

If you're creating imagery it doesn't take long for these two features to change your workflow in such a way that you gain a HUGE time savings. In fact I have created several templates to speed up the generation of images I do that I just plain cannot do in GIMP. Realistically speaking that is enough man-hours lost that I'd actually make a greater profit paying for Photoshop than I would saving the cost of the license in favor of GIMP.

With that said, I'd be *very* happy if you told me that version 3 would add these features. I'd also be very happy if somebody could tell me what GIMP does that Photoshop doesn't. It's free. if it shaves man-hours off my work, then load me up with the tips. I ain't gonna switch, but I ain't above using both.

The dhcp client in OS X runs sandboxed (I believe), so there's less potential for an attacker to exploit it if they can make it run arbitrary things - it doesn't have general filesystem access.

The issue I'be had with it is that it doesn't really do merging, it does 'server always wins'. This means that if you delete an event locally, on the next sync it will reappear. It's fine for new events created on the device and for events created elsewhere if you just want to view them on the device. I use owncloud on the server and iCal on my laptop and editing things on either of those is fine.

The reason I stopped using the search engine was that they made a UI that pissed me off enough to make me quit. I've not found Google UIs to be particularly well designed in general - I could file a few hundred UI bug reports on the general Android system, including a lot that are regressions.

One use case that's often touted for this kind of thing is having appliances that can work on spot pricing for electricity. Over the course of the day, you get spikes from solar and wind (and tidal and so on) production when electricity is cheap. You get periods when power plants need to reduce capacity for maintenance when it is expensive. There are massive power storage facilities that profit from this: there is one near where I used to live that pumps water up a hill into a reservoir when electricity is cheap and then lets it flow down again and generate power when it's expensive. Now imagine if your fridge or freezer could get this information in real time and could run the compressor a bit more when electricity is very cheap, then use the cooled coolant to keep your food cold when the price goes up.

Almost 50% of the electricity generated in the USA is wasted because the supply can't adapt to demand fast enough. There are some very big savings to be made by having demand adapt to supply.

Really? About the only Google app that I haven't replaced with something better (and open source, so money / distribution rights are not an issue) is Google Play, and that's only because my bank and a few other companies only make their app available via Google Play.

A few of the HTC apps were nicer than the AOSP versions and the same is true of the Motorola ones. The problem for people who don't drink the Google kool-aid is that hardly anyone is working on the AOSP versions of most apps. If you buy a new Android device, there's no calendar app that can talk to a CalDav server (which, for example, any iOS device and most open source calendar apps for desktop can do out of the box). F-Droid has one that is designed to, but it has a terrible UI and doesn't integrate nicely with the rest of the system. There are a couple of sync adaptors, but Google has increasingly broken the sync APIs for things that are not Google.

I completely agree. If you try to become involved with an open source project because you think it would be fun, your enthusiasm will likely fizzle out fairly quickly. If you try to become involved with an open source project because you actually want to use it and want want to improve it, then every time that it doesn't do something that you need then you'll find yourself with a project. One of the nice things about a project like FreeBSD (to give an example of a project that I'm heavily involved in - there are others that have this attribute) is that there are enough small parts that it's easy to find small projects in the individual components to keep yourself occupied.

The real problem has nothing to do with types, it has to do with design compromises to work around the fact that UNIX lacked shared libraries. Rather than provide a glob function that everyone could use (as with later versions of UNIX, after shared libraries were added), they put globing in the shell. This meant that the shell became responsible for handling some arguments, the command for handling others. As a natural consequence, you needed to provide a mechanism to escape the command-line arguments that you didn't want the shell to get at. And then you start using shell invocations as your mechanism of running programs (via the system() C library call) and now you need double escaping or triple escaping and so on.

Re-read the latest CVEs. There are bugs in the parsers that can be exploited, so even if you're never invoking the functions they're already run through the parser and the parser is breaking things for you.

On the open source projects I've worked on where Google is a big contributor, they are very keen to push features and randomly refactor large parts of code, but I've never seen them do anything like a security audit. They did, however, do a big audit of libavcodec (which they use) and fix around 300 security holes...

The second vulnerability is a lot harder to exploit. Most vulnerable things only allow attackers to set specific environment variables. If you can set arbitrary ones, then setting things like PATH or LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OS X) are already exploitable, at least for privilege escalation.

I've run all of the updates on OS X and I still got the vulnerable message. A couple of days after the bug was public and the patches were available, I grabbed the source from opensource.apple.com, applied the FSF patches (which required some manual intervention, as they didn't apply cleanly) and recompiled. I'm now running a patched bash that isn't vulnerable, but it's not the one that Apple supplied.