Going to File->Save As... and trying to save to .jpg brings up a dialog box telling me to exit the current Save As dialog and go back to File->Export to save as .jpg. Asinine.
That way it would satisfy both the elitists and the people who just want to do their jobs.
The work flow is really awkward then. You are exporting a jpg from a jpg? Oooookay....
I think they value developers and people who use their software frequently. As a developer, I love the separation of save and export. They really are separate functions, and the XCF actually saves the export location relative to the original XCF location. It makes working on large projects so much easier.
If I wanted to just do a quick edit to something, Gimp isn't the ideal tool for that job anyways. If I wanted to make it so, selecting export instead of save is really fine, especially since it gives the option in the menu to overwrite whatever JPG you just opened.
And they STILL only have 8 bits per plane (people were whining about this in the 90s ... when Bill Clinton was president), STILL can't remember sub-pixel rendering steps ... other than improved PSD importing, I don't see why.
I'm sure they've put a lot of work into this; but not in the right areas.
Their target audience should be highly technical people that need to do image work and want a tool like vim/emacs/zsh etc but for images; learning curves are ok as long as you can combine simple steps in composable tasks to do amazing things.
I say the same things about all my good tools: "I've been using it for 10+ years, I totally suck at it still, and I would never use anything else". You can say that about paintbrushes, driving, violins, maybe even photoshop or excel; but not gimp.
They were going down that road for a while in the 2.2 or so days, but then they did a 180.
I use their software very frequently, and the biggest frustration with this is that it completely screws with my muscle memory for the Gimp and every other application. I continue using 2.6 because 2.8 is just too frustrating.
When working with images so much that you no longer think about the keyboard and mouse, but you think "Save" and it just happens, a change like this is like rewiring your hand so that all the fingers' nerves are reversed, and you have to get permission from your navel before you can lift your pinky.
If I wanted to just do a quick edit to something, Gimp isn't the ideal tool for that job anyways.
Gimp has always been the ideal tool to just do a quick edit to something, because it's the tool I know. I've been using it for more than a decade. I don't need some new developers to come along and think they know better than me how I use their software. That's Apple's billion dollar job, and even they get it wrong often enough.
If I wanted to make it so, selecting export instead of save is really fine, especially since it gives the option in the menu to overwrite whatever JPG you just opened.
Clearly you're not working fast enough for your fingers to be ahead of your brain. I don't need options, I need my tools not to talk back to me.
I think this is very relevant: http://xkcd.com/1172/
Clearly you're not working fast enough for your fingers to be ahead of your brain. I don't need options, I need my tools not to talk back to me.
If you have any constructive feedback - or better yet, _code_ - make a polite post on their forum or mailing list. No one here cares about your specific workflow.
Actually, you're the only one here vehemently defending the Gimp's new behavior. The other comments seem to prefer Gimp 2.6's Save behavior. But this is getting unnecessarily petty and personal; it's obvious we disagree, and I'll just stick to 2.6 and stop recommending Gimp to people who would otherwise be happy pirating something more expensive.
Don't take it upon yourself to speak for everyone.
I think people who use their software frequently would take offense to the software telling you to fuck off and go do it a different way.
The intent is obvious, both to the user and the developer. Why make people's lives more difficult for such questionable benefit? MS Paint doesn't have this problem. Photoshop doesn't have this problem. The user knows what they want to do, and they could do it before the change. Why are you getting in their way?
If you really want to destroy your layers and history (which GIMP saves into XCFs) there is a menu option for that. But you almost certainly don't want to do that.
When you save a layered file in a unlayered format photoshop just forces the "Save Aa a Copy" option to be checked and then saves a flattened version while preserving the open one, thus if you then decide to quit without saving a layered version you get a "Are you sure you wish to quit without saving document x?"
The way Photoshop handles it is far superior imho. With gimp iirc even if the file is not layered you still have to do export?
And for many edits, i simply don't want to save layers or history. there's just no point if i'm cropping, converting, re-sizing, or quickly fixing something. If i do then i'll save it as a layered file and layered is by far in the minority. I know what i'm doing i don't need the app to 2nd guess me, and it seems the new workflow is better for people who don't understand the difference between layered and un-layered files.
So what smaller, simpler program (other than Gimp 2.6) has all of Gimp's features, but is suitable for a quick edit? Say I have a .png image stored in a version control system, with no need for layers or history, and I want to do a quick perspective clone to paint over something?
I was so excited when they made it a native app, too.
If Command-E actually brought the window up in front of the rest of the windows instead of hiding it behind the main window, it might have been a different story.
Just my two cents.
For example, I open a jpg and go to save it as a PNG. I select PNG from the drop down list of available types and type the filename, but unless I also add .PNG to the filename it makes a jpg again.
>> "Another device on the network is using your computer’s IP address."
I know that the thing to do here is renew the DHCP lease. Most people don't. Just renew it for me, please.
The many procedures you can do to fix a network connection in Windows are even worse. Do these for me before you show me any troubleshooting messages.
That said, I agree that it should suggest renewing the DHCP lease.
If the DHCP is set to serve a static IP for the MAC, the problem will presist, if the DHCP server is dynamic it will just do what its desgined to do and assign a unused address fixing the problem while not changing the network configuration at all.
[ http://news.ycombinator.com/item?id=2755461 ]
Does anyone know what the iPhone/iPad/etc. do in this case?
Use exit() or Ctrl-D (i.e. EOF) to exit
Thanks, tcsh. Now I remember why I don't use you.
Use exit() or Ctrl-Z plus Return to exit
But that's minor. The bad part is if I'm used to Linux and try to exit on Windows with Ctrl+D, I get this cryptic message:
File "<stdin>", line 1
SyntaxError: invalid syntax
Now what happens if I switch to Linux (as an inexperienced Linux user) and try to use Ctrl+Z to exit? Yes, I get this somewhat cryptic message:
+ Stopped python
If you prefer you can use another pager like more that will let you ctrl-c:
export PAGER='less -K'
If your state is just sitting in the file, interpret the signal as exit.
As another example, perhaps it would be nice if ctrl-w deleted one word backwards if you were currently editing text in your webbrowser, but close your current tab/window otherwise. If the state is always what the user expects when they press ctrl-w it would work fine, but in reality you would have lots of people accidentally closing tabs.
Ctrl+C doesn't mean "end this program." If you want that, consider Ctrl+\.
It enables you to search using '/keyword', for example.
The source :rubygems is deprecated because HTTP requests are insecure.
Please change your source to 'https://rubygems.org' if possible, or 'http://rubygems.org' if not.
No, SemVer means you increment major version numbers if, and only if, you break backwards compatibility.
That's true, but both silly and not what you said before.
There's no good reason to care about version numbers in and of themselves, if you care about them at all, its because of their semantics: using SemVer doesn't make you not want to break backward compatibility, not wanting to break backward compatibility is independent of the use of SemVer. Of course, if you don't want to break backward compatibility, you won't end up bumping the major version number under SemVer, but you've got the whole direction of cause-and-effect wired backward when you say that SemVer is the reason not to break backward compatibility.
No one wants a major version bump in Bundler in order to change the primary rubygems URL because historically there is a lot of potential pain in Bundler updates, and so you better be getting something new that's worth the pain, not just a superficial change that happens to break compatibility only as a technicality.
SemVer seems pretty much tangential to that, that's a problem with the particular history of the particular project.
If the original claim had been "Bundler's history of major version updates means that they don't want to bump their major version; combined with their commitment to SemVer, that means that any backward incompatible changes are avoided", rather than just that SemVer alone led to people in general seeking to avoid backward-incompatible changes, I wouldn't have challenged it.
I think that's highly dependent on the particular market that a product is in, and how its version numbers are used in marketing. Chrome (which neither heavily markets around version numbers nor uses SemVer, but instead increments the major version number with every regularly-scheduled feature release) end-users (whether you are speaking of regular end-users or developers) probably don't have any particular expectations tied to major version bumps.
Microsoft Windows (which doesn't use SemVer, but does heavily market around major versions) end-users probably have much bigger expectations for major versions, as a direct result of the vendor's marketing investments.
A developer-focussed product that consistently uses SemVer and markets around particular new features rather than major version numbers probably won't have much expectation from its target users tied to major release bumps except that they will meet the SemVer definition of a major release bump.
What sensitive data are people passing back and forth to rubygems of all places that needs encryption? Especially in the context of a bundle where you're more likely than not pulling down or updating gems (from a public repository, which contains no sensitive data)? And this need is apparently so pressing that it should be complained about to the user?
Oh, wait, this is rubyland. Nevermind.
I've been on a plane all morning and am in no condition to be parsing the topics here :)
What they probably could do, though, is a 302 redirect to https. But that's frown upon by some, too.
In browsers this is sort of acceptable because they let you visually confirm that you've been upgraded to https, and are now securely connected to the right server.
In a text mode app that does the connection behind the scenes and fully automatically, there's no such confirmation or even intervention, so there's no perceptible difference between http and http 302 to https.
Ruby (on Rails) values convention over configuration. It should have made https obligatory per default and overrideable with a flag per this guideline.
This assumes the client doesn't kick up a fuzz. The entire point is Bundler now does kick up a fuzz. But it could also be made to follow any redirect first, and only kick up a fuzz if the final resource is not https.
I still think mdavidn is probably right that 95% or similarly high number has OpenSSL available, and it makes little sense to inconvenience all of those users when you can inconvenience "just" the few who don't instead.
/path and /path/ are two totally different things in the standards, just like /path and /path2. Sure in most cases with and without trailing slash gives the same page; but it's not something you can assume.
Same reason why "we don't allow https links" doesn't mean you can just drop the s.
foo.com/bar and foo.com/bar/ (-> foo.com/bar/index.html) can be totally seperate URLs.
In the uri standards, /path and /path/ are just as different as /path and /path2.
Now click "Use .tar.gz" => file now has name foo.tar.tar.gz
$ git submodule update
You need to run this command from the toplevel of the working tree.
You can update only a specific repo if you'd like. In which case it would be possible to limit the submodule command to only submodules existing in the current directory.
Yes, it would need to scale back up to the .gitmodules file, but it is still possible.
In other words, git knows "exactly where that is" by searching parent directories until it sees a ".git". Unfortunately, submodules also have ".git" in them since they're full git repositories themselves.
git submodules are not the nicest part of git, unfortunately.
For those also annoyed, I use this git alias, which does what I want:
sup = !sh -c 'cd `git rev-parse --show-toplevel` && git submodule update --init' -
I mean, christ, I fetch and merge as separate steps.
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0440 for './id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
edit: to be clear, this is SSH's "shitdick excuse" not Heroku's.
If your account or computer has already been compromised you're still screwed but this helps considerably on shared computers, NFS, etc. where the access situation is easier to misunderstand.
If you take a look at , you will see that the wiki provides a lot more than just commands to type in, but also a rationale and explanation what each component does. Usually there are also links for further reading that should help your understanding of the topic.
Was looking for some help getting started with Awesome WM as well as sorting out an issue with crap Broadcom wireless card -- both searches led me to Arch, and it was there that I found informative, detailed threads that led to the solutions.
So, I started recommending it to a bunch of people I know as an excellent development environment. What was odd was that they all reported back that it was incredibly hard to do and manage.
It turns out that just days after I had done this install, Arch completely removed AIF in favor of a bunch of smaller, much less helpful scripts specifically so that it wouldn't be as simple (and thus less flexible) to install.
I was, and still am, totally floored by this. I switched to using Ubuntu Server with my own choice of UI layer (Xmonad for life!) after dealing with that.
"Database connection closed. Reconnect?"
heroku console -> heroku slightlydifferentsyntaxforconsole
$ git statis
error. Did you mean status? Y/n
> ce somedir
zsh: correct 'ce' to 'cd' [nyae]? y
git config --global alias.s 'status --short --branch'
Crap.. I meant "DELETE FROM some_table WHERE id=1"
More commands could use options to adjust how big guns they let you fire at your feet with...
WHERE id = 1
ctrl + a
Found it's also helpful for writing SELECTS and avoiding the whole "oh crap, now let's load the entire DB" type of moments.
select * -- delete
where id = 1
All my deletes written first as selects now, as a sibling comment suggested.
Oh yeah, you're using a toy database aren't you.
~/foo$ mv bar baz
~/foo$ cp baz bar
cp: omitting directory `baz'
FreeBSD `cp(1)`: `copy_file()` does a simple `read()`/`write()` loop with a buffer (despite ZFS maybe supporting CoW).
GNU coreutils `cp(1)`: `copy_reg()` calls out to `clone_file()` if and only if `--reflink` was passed, and `clone_file()` fails on everything but btrfs.
: FreeBSD `copy_file()`: https://github.com/freebsd/freebsd/blob/master/bin/cp/utils....
: coreutils `copy_reg()`: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
: coreutils `clone_file()`: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
I think it's enough to stop right there. :)
No reason to associate gays with people who can't program and/or design software competently.