+ - Microsoft reads your Skype chat messages-> 1
Link to Original Source
Comment: Re:Only 20? (Score 1) 300
Yeah...if they had had categories for 20-50, 50-100, 100-200, 200+ we might get some actual results.
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.
And I would have actually had to ~count my tabs.
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.
Comment: Re: GUIs: GIMP vs Photoshop (Score 1) 658
Single-window mode has absolutely nothing at all to do with why the GIMP GUI sucks. Switching to single-window mode is actually worse, not better.
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.
Comment: Re:I tried this... (Score 4, Informative) 658
1. 16bpc (and 32bpc) (native, pending for GIMP 2.9+)
2. CMYK (Plugin, supporting GIMP 2.4+)
3. Single-window mode for GUI (native, GIMP 2.7.3+)
You only used one out of three, you guys are putting less effort into this as the years go by. Guess Gimp has been winning for a while now
Now who's not putting in enough effort?
Comment: GIMP 2.10 to support 32bits per color channel (Score 3, Informative) 658
Still no support for 16-bit per channel after all these years.
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).
The worst thing about GIMP is that its existence leads the FOSS community into complacency. People need to realize that there really is no good open-source competitor to Photoshop and start working on one, rather than pretending that GIMP fits the bill and then arguing with creative professionals who repeatedly point out why it doesn't.
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
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.
Eric Schmidt: Regulate Civilian Drones Now 420
from the ban-telescopes-and-corrective-lenses-as-well dept.
+ - Africa's Coming Cyber-Crime Epidemic->
Link to Original Source
Comment: That's HALF of NASA's budget (Score 5, Informative) 64
That's a lot of money for space research. . Do they know something we don't?
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.
Comment: Re:who is doing this? (Score 1) 212
For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.
So what your telling me is that they decided that a password that said user probably wrote on a sticky-note attached to their laptop or saved in a plaintext password is more secure than a ssh private key that MIGHT not be password protected?
If a user isn't going to properly secure an ssh private key, there is no way in hell they are going to properly protect a password!
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.
Comment: Re:Inability of server to enforce policy (Score 1) 212
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.
Comment: AuthorizedKeysCommand can police this easily (Score 1) 212
In my opinion, this is the interest of the new authorizedkeyscommand. A sample usage is available at http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/
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.
Comment: Re:who is doing this? (Score 1) 212
Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.
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.
How Do YOU Establish a Secure Computing Environment? 314
from the can't-root-this dept.
Lax SSH Key Management A "Big Problem" 212
from the we're-all-doomed dept.