I was frankly quite surprised that the 20+ category wasn't orders of magnitude more popular. As of this writing, the tally is 8818 vots for 1-5 tabs versus 8304 (3256+1476+768+2804) for 6+. That really does not sound realistic.

I have 154 tabs open right now, and even then only because I've recently purged a bunch. However, only 38 of them are actually loaded at the moment (huzzah for session management/crash recovery!).

Using an add-on like Tab Mix Plus can help (or empower, which may be a mixed blessing); I've configured it to show me three rows of tabs at a time, and I can scroll them vertically with the mouse wheel, much like a filing cabinet. Really, it's just super-intensive AJAXy apps like Facebook that hog memory and resources. Those need to be kept to a minimum while others are fine.

Assuming Firefox, hit CTRL+SHIFT+E (I'm not sure of the Mac equivilent) to go to the Group Your Tabs view. Not it's just a matter of counting rows and columns and then multiplying.

It seems like 80-90% of the complaints regarding GIMP's UI are from people who won't be satisfied with anything but a full Photoshop GUI rip-off (e.g. the way LibreOffice mimics MS Office; Gimphoto and the defunct GIMPshop get close on this front). Their top issue is (well, was) the lack of a single-window mode. To shut them up, given how trivial it was to implement, it was added. I agree with you on the fact that the mode doesn't improve the UX, but it does shut down the #1 complaint, which is something.

What else is (independently) bad about the UI? I started my graphics career on Paint Shop Pro (a plugin-compatible Photoshop knock-off that I actually preferred due to better use of the right mouse button) and was able to seamlessly upgrade to Photoshop given the similar UI. GIMP therefore had a steep learning curve for me, but I have grown to prefer it over time (though I still have to hold back from certain ~hard-wired PSP keyboard shortcuts).

I think the real issue here is merely that GIMP is not a Photoshop clone and image professionals aren't as proficient with computers as professionals of other industries that spend similar amounts of time on computers. They took a very long time (running through tutorials and perhaps paid classes) to learn Photoshop, and there are no equivalents for GIMP (at least, not with the same polish, which these users need), not to mention the fact that it's a serious time (and often monetary) commitment. The only solutions for these uesrs are to make GIMP bi-modal (GIMPshop mode) or to both improve overall computer proficiency (which is happening over time anyway) and create highly polished tutorials and professional courses on GIMP.

Even then, GIMP would still need to absorb (or better partner with) the features currently relegated to the Separate+ and PSPI plugins.

As I've said elsewhere in this article's comments, GIMP is not really professional-grade, it's just close enough for people to make the comparison. LibreOffice has commercial backing, as does the Linux kernel, as does WINE. Perhaps what GIMP "needs" is a commercial backer, that implements new features within a non-free plugin suite (and/or a fork that somehow gets around the GPL) and expands GIMP's base to maintain compatibility, even slowly trickling their commercial features into GIMP over time so as to merely represent what the Free Software version will get in a release or two.

Now who's not putting in enough effort? ;-)

Isn't that implemented by the Generic Graphics Library (GEGL), partially implemented in GIMP 2.6 with a migration path that should end with GIMP 2.10 (the next version) fully utilizing it? 2.10 has been specifically noted as supporting 16 (and 32!) bits per color channel. That link, from a year ago, even has a screen shot. Still, 2.10 doesn't have a release schedule, and despite that the developers are committed to "shorter development cycles," it looks more like it's still a ways out (2.9, the dev pre-release, is still several months out at the earliest). Still, it's heartening to know they're on the right path (and that they've gotten around the design flaws that preiviously made this kind of feature impossible to implement).

Again, GEGL comes to the rescue. The whole point of it is to make it a library so it can be used from GIMP or any other utility. It represents that ground-up rewrite you so desperately plea for.

Regarding a professional-grade tool ... Free Software never really offers that. You can get close, and sometimes you get lucky, but for the most part, there is no free ride. Generally, the best you can hope for is a commercial closed-source application that works well in an otherwise Free Software environment. It's icing on the cake when the vendor of such software offers a Free version of it (e.g. Codeweavers and Crossover vs WINE).

There's always "more" work needed, and for high-end items like the Photoshop features missing from GIMP, there's rarely enough community-driven (read: volunteer) time and energy to make it happen. It's worth noting when a major feature is missing, as car mechanics tend not to be racecar drivers (as mentioned elsewhere in the comments), but it's not worth complaining unless you're rolling up your sleeves and/or putting up a bounty to make developers' time easier to allocate.

What are you talking about? No it is not!

They use some of that money for manned space missions rather than for research. Still, their previous $3 billion annual budget could afford to send men to space while NASA's $18 billion annual budget apparently cannot. Now Russia announces a spending increase up to USD$68.71 billion over eight years (USD$8.59b a year), roughly half of what NASA's sliced up budget is currently.

Neil deGrasse Tyson's video pleas We Stopped Dreaming and its follow-up A New Perspective proposed we increase NASA spending to 1% of the US Federal Budget (current spending: 0.49%) suggests we could go to Mars and innovate the way we did in the 70s. That's significantly more than Russia's new investment and would help us keep our lead. Otherwise, we're losing both innovation and innovators.

I'd like NASA to be funded by the largest of:
* 1% of the US Federal Budget ($3.8t -> $38b in 2011)
* Half of the US DOD's Research, Development, Testing & Evaluation budget ($79b -> $39b in 2010)
* 5% of the whole US Military budget ($550b -> $27b in 2011, $708b -> $35b in 2012)

This extra funding would come from otherwise allotted military spending (so an increase to the military budget would typically increase NASA's budget as well). As I noted a few paragraphs earlier, this would roughly double the current $18b budget and would bring us to Mars.

I've been in IT. I've seen it first hand. These people do understand and have decently secured systems, but trade off security for convenience rather than learning ssh-agent, missing the point that their perceived "minor" security issue isn't as personal as they think and risks exposing things like code trees and proxies to would-be attackers.

My "solution" was to serve on an alternate SSH port, since they also didn't use ~/.ssh/config, so anybody stealing their keys would also have to troll their ~/.bash_history to figure out what the keys opened. I also walked around the office and emailed people with walkthrough instructions for using ~/.ssh/config and ssh-agent/Pageant (PuTTY's agent) on Linux, OS X, and Windows.

There are two (very ugly) "secure" solutions to this.

1. Draconian: The IT department requests the private key, tries to brute force access, then deletes it after a certain degree of failure. IIRC, pubkeys can be generated from private keys without passwords, so it's verifiable. Big snag: the user could remove the password later. As long as the private key is safely and securely submitted (say via an SSL form) and safely/securely stored during the brute forcing, this is as secure as your trust in the sysadmins (and/or your password strength).

2. Policy: enforce via required educational video or similar nonsense plus a legal contract. Best done in physical form since nobody actually pays attention to EULAs and whatnot. Can be combined with Draconian #1 above.

Nice! AuthorizedKeysCommand (introduced 2012/10/31) can do exactly what we need: Set up a script that (securely) logs key usage and e.g. deny any key that is older than 366 days (by first use or else filesystem timestamp) and hasn't been used in 90 days or for any user whose last login (regardless of which key) was over 60 days ago, with a list of exceptions (by key, not user).

That's still messier than something that can go right into the authorized_keys file as a parameter, but it would do the trick handily.

From the IT policy standpoint, there's no way of requiring that a key has a password. There are lots of people who don't understand (or otherwise care to use) ssh-agent and similar mechanisms, and there are lots of people who assUme that their own systems' security is sufficient and don't realize that it jeopardizes the security of the IT department's systems.

For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.