Seems to me that there are 2 big benefits over sizeup (though i'm basing this entirely on their website, i've not used it)
1 - With sizeup you have to manually move your apps around. With this, new windows are automatically tiled (and you can then move things around afterwards with the keyboard shortcuts)
2 - This seems like it supports more complex layouts (with various layouts built in)
That is generally correct. I wrote a longer comment about this but SizeUp is about manually managing windows and Amethyst is about letting software manage windows for you. It's generally a matter of personal preference which you prefer.
Small comment: I was slightly confused by the new game form.
I assumed that your watermarked values were defualts (which i was happy with) .... so didn't change them, then couldn't work out why the create game button was disabled.
Both of these statements can be true ... if you specifically look around for people who are by themselves, they are easy to spot ... but the majority of people are not looking!
Just a heads up for anyone interested. I've been working on a very significant revamp of the Package Control site that coincides with all of my work on Package Control 2.0. I've been pushing hard the past couple of weeks, with a hopeful launch in the next couple of days.
The benefit of an online listing is easy access to package descriptions and repositories. When there are multiple packages for a given task, I'd like to know which is more heavily updated and supported. Correct me if I'm wrong, but I don't believe there's a way to open the Github page from that menu.
I like the idea of this, would be good to wean a few people off the github client onto the command line.
I can understand that this wants to create a real repository on my github, but it is asking permission to read/write to private repos, so I stopped at that point.
Why would people need to be "weaned" off of a graphical client towards a command line? Is it a specific client or all of them?
Maybe I'm misunderstanding your sentiment - are you one of those people who thinks that all GUIs are for children and that command lines are for adults or something along that line?
I think it's a case of leaky abstractions: git is sufficiently complicated that no-one (to my knowledge) has abstracted away the original CLI into a GUI that works for everything one would want/need to do with git.
Because graphical clients tend to cause problems when interacting with other people (no shared lingo, using features that aren't implemented in the client, etc), and because Git GUIs in particular tend to be very anaemic compared to the CLI. In particular, I have yet to see a GUI give you access to the reflog so you can undo many kinds of destructive changes, which seems like it would be a useful thing to have for people who don't really understand the system they're using.
Do you have some evidence for your claim that graphical clients tend to cause problems when interacting with other people?
Does one missing feature really make them anaemic?
I understand the git system just fine, I've worked with many other developers who use a disparate set of git tools and I've seen no such problem. I rarely touch the command line and it's just amazing - it's like I have this brain that can understand a system without using the same exact tool that you use to work with it.
Really, I just love the elitist remarks from people who love the command line.
Sure. Few clients (any?) support rebasing or squashed merge commits. So if you work with people who like a simple single-commit-per-feature workflow on the master branch, you're left learning the CLI. Also, "shared lingo": cryptic error messages have been stated elsewhere on this post, and there's no reliable way to tell people how to resolve them (if it's even possible in the GUI they're using).
And stop being an ass by assuming I'm being an ass, please.
TortoiseGit supports them both. Even if none of them did...anemic? Really? I didn't think I was assuming; it was fairly self evident to me, based on the amount of hyperbole being too damn high.
"RavenDB supports multi document (and multi node) transactions, but even so, it isn’t recommended for common use, because of the potential for issues when using distributed transactions."
So, the differentiator is that FoundationDB is built from the ground up to support these type of transactions at high performance levels with no "potential issues".
That remark seems a bit unfair. That document is two years old, from long before version 1.0. RavenDB is now at version 2.0. It was also built with transaction support from the start. The default setting for TransactionMode is Safe (http://ravendb.net/docs/server/administration/configuration) so most users will use that, if there were any issues with it that would certainly be known by now.
The current RavenDB documentation still warns against using "system transactions" because of performance reasons (http://ravendb.net/docs/client-api/advanced/transaction-supp...), so I think it is still fair to say that RavenDB was not designed for applications requiring high performance cross node transactions.
System.Transactions refers to support by RavenDB of the Distributed Transaction Coordinator service on Windows. This makes it possible to enlist transactions in multiple systems (MSSQL, MSMQ, RavenDB, NServiceBus) in one single transaction with the possibility of a rollback. It is not needed for transactions inside RavenDB, and I think foundationdb does not even support something like that (it is Windows specific, although Mono supports it on other platforms).
My first Mac/Swift app .. be gentle :)