It has a "shelf" which is much like the Git staging area, only reversed. In Git, nothing is committed by default unless you stage it first. In Bazaar, everything is committed by default unless you shelve it first.
This works the same in practice: if you want to commit only part of your changeset, first you shelve everything you don't want to commit, then commit, and then unshelve again. I find that I make far fewer "accidentally forgot to commit something" errors. (A friend of mine came all the way to work one day, realised he forgot to stage something in Git from his home computer, and then immediately left and went all the way home again.)
I tend think the argument "I haven't learned it yet" isn't a good argument.
No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.
if you need that (like I do sometimes) you simply create two workspaces or checkout the files to a separate folder, both of which end up having the same effect as the Bazaar solution
Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)
This happened to me at a previous company using SVN. It had to do with the fact that a build system built several projects. I don't remember why... I suppose they were separate directories which had individual trunk/branch/tag directories (module1/trunk and module2/trunk). If you tried to build a tag or branch, it was in one directory up past trunk (i.e. module1/trunk/project vs module1/tag/v1/project). You literally had to copy the subdirectory to the parent directory for it to build properly.
It seems like things weren't set up very well. I fail to see how any revision control system could deal with this. If you had been using Git, you wouldn't have had access to those branches at all. The build system should be contained within the repository, not outside it, so it shouldn't matter what directory the repository is stored in on disk.
I simply don't think having separate directories for tags/branches is a good idea
I may have misled you into thinking that Bazaar treats branches the same way as SVN: It doesn't and that would be awful. Subversion stores tags/branches as subdirectories of the repository -- that means you have them locked into a particular location. Bazaar stores branches as parent directories of the repository -- they are just ordinary directories anywhere you like on your file system which contain checkouts of a repository inside them (but unlike Git, they only contain a single branch, and if you want multiple branches, you create multiple directories).
This is wrong. One can. The commit 83c7 and the commits e337 both would clearly state which tags are their parents: 83c7 would say "branch1" and e337 would say "release1.5", for example.
Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect? In my experience, most merges just show up as a single object with what looks like two randomly-named parents (I know they're hashes but that doesn't help me as a human).
Most of my comments above are opinions, and I would think myself very rude if I said to you or anyone that such opinions are "right" instead of "what I prefer".
Of course. I'm only saying what I prefer, but my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 2
That would certainly help. I was extolling the merits of Bazaar's revision numbering scheme on my post above (titled "Bazaar"). The problem as I see it is that unlike Bazaar, Git doesn't assign any significance to the master parent of a commit. I'll shamelessly rip some text from my own explanation above:
For example, in Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch.
The difference is that in Bazaar, a merge is asymmetrical: you merge from one branch to another, and it makes a difference: the "to" branch (typically the trunk) gets to keep its original revision numbering scheme, while the "from" branch gets relegated to the x.y.z scheme. In Git you merge between two branches (the order does not matter) and then commit the result to one of them (typically the master).
I would like a scheme where Git places significance on the to branch like Bazaar does, but then the Git fanatics would cry that it's possible to break things by merging the wrong way (which is certainly possible in Bazaar, but I think it's better than not having that metadata at all).
An important distinction with Subversion (which I think handles branches atrociously): In Subversion, branches are separate folders within the repository; a repository has a single linear history with branch directories inside of it. In Bazaar, branches are separate folders outside of the repository; each branch has its own history and branches are treated as separate objects. Sorry if I didn't make that clear.
As for revision numbers, on the contrary: they aren't really meaningful until you start doing non-linear history (merging). Once you start merging, it is very nice to be able to see "oh, this is revision 173 and its parent is revision 172, but it also had a merge from a branch revision 168.1.32," as opposed to Git where all you can say is "oh, this is revision 0f3bc3df and it has two parents: 83c7ac39 and e337cb8a; I don't know which one is the actual trunk history and which one is the branch commit."
Half of your ideas really ARE better; for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. However, branches in separate file-system directories and trunk vs merged is a superfluous way of describing the same concept, which is branches, and Git (and others) still maintains that concept.
Well of course Git has a concept of branches, but it only lets you access one at a time. What I find frustrating about this (besides the educational overhead of having to learn how to switch branches, and figure out which ones are being pushed and to where) is the fact that there is no URL for identifying a particular branch in Git -- URLs identify repositories, and then branches are identified by additional syntax I still haven't grokked fully.
I will argue, with both reason and experience, that separate directories for branches/trunks/tags are BAD. For example, they take up a linearly larger amount of space on your local storage media when checking everything out.
This is a common (and untrue) criticism of Bazaar. Bazaar has a feature called "shared repositories" which allows you to create a directory and say "all branches in any subdirectory of this will share revision data". The shared repo has no semantic meaning (it isn't like a Git repository) -- it's purely an optimisation to address exactly this problem. Now admittedly, it is an advanced feature that a basic user may not know about, but if you aren't using Bazaar enough to learn this feature, then you probably haven't got enough data in it to warrant this optimisation anyway.
Another example is that build systems can be messed up by differing directories... if you have trunk/ and branch/1 you have different levels of directories so ".." relative paths are screwed.
When do you ever use relative paths that go up outside the current branch into another? If you ever did that (say, a file in 'trunk' refers to "../branch"), then it would break in Git anyway, where you can't refer to another branch. I think this is a non-argument. Besides, common practice in Bazaar is to have all the branches in one directory, and also have "trunk" in the same directory (it's just another branch, that happens to be called "trunk").
Another important point: you say that "trunk vs merged" in Bazaar is equivalent to Git, but it isn't. Git's data structure is quantifiably lacking some information that Bazaar includes. In Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch (and furthermore, the branch names are also stored in the commit metadata).
So yes, Git does support the concept of a master branch and other branches, but it doesn't remember, historically, which commits came from where, and thus is a poorer data structure than Bazaar's.
I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.
I've been using Bazaar for everything I do, large and small, for the past three years. I can't say I've ever noticed any delay in committing, branching or merging. Of course, if you are operating in bound mode (i.e., keep synchronised with the server) then it's a different story, but that's an optional feature that Git doesn't even have. From what I hear, Bazaar used to be much slower than it is now.
And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other.
Uhh, how about this hypothetical scenario: half the world uses Git. You prefer a different tool.
Seriously, it is this closed-minded thinking that I meant when I said "what a selfish decision." If everybody used Git without complaint, you would have no need for using two VCSes on the same repository. But since I prefer Bazaar, and a good portion of projects are hosted with Git, I would very much like to be able to "bzr branch" a Git repository, work with it locally as if it were a Bazaar branch, commit, then push up to the Git server. In this ideal world, we don't need to argue over which VCS is better, because I can use mine and you can use yours (just as I can use my preferred web browser and you can use yours).
Why can't we have this ideal world? Because Git lacks metadata support. The above scenario already works with Subversion. I do it all the time: I "bzr branch" a Subversion repository, commit locally, then push, and it works fine -- my colleagues who use Svn don't even notice that I used a different client. The reason this works is because bzr-svn stores its own metadata in the Subversion properties (which means that another colleague who uses Bazaar can "bzr branch" the same Subversion repository and she'll see all of the Bazaar merge history). But I can't do this with Git.
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.
Well that's really what GitHub is... much like Facebook treats every "object" (status update, photo, event) as a commentable, likable object, so does GitHub for VCS objects such as commits.
It's quite funny to see a commit with a comment thread attached to it. I saw one that went viral and ended up with 88 comments including meme images.
I don't really use tools other than the command-line, but I believe Bazaar has had TortoiseBzr included in the main Windows package for some time now. I don't think there's Eclipse integration though.
Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."
It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).
I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.
Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X, which I wrote a rebuttal of at Why Git Ain't Better Than X.
It's like in the final season of 24, when Jack Bauer was on the run from the government, he bought about a dozen cell phones. Every time he made a phone call he would immediately throw the phone in a bin.
Well I was glad to find that ABC article (via Slashdot), since I've read The Age, and figured it was bullshit, but hadn't got nearly as many facts until I read TFA.
but I guess one hard up for ideas editor of - what is it even, an Australian gaming blog?
The Sydney Morning Herald is the major broadsheet newspaper in Sydney. This article also appeared in other Fairfax publications such as The Age (the major broadsheet newspaper in Melbourne), and it appeared on the headlines on The Age website for awhile. So no, this is not some obscure blog.
The rebuttal article is from the Australian Broadcasting Corporation website, the primary government-funded television network in Australia.
I don't know about the rest of the world, but in Australia, the media has gone nuts over this video game connection to the Oslo attack -- possibly because of all the noise made by the very powerful Australian Christian Lobby.
But that's why it's using a cryptographic hash first (SHA-512). The process is text -> SHA-512 hash -> image. Even if the image generation algorithm might only move the flower a little to the left if you change one bit of the hash, it doesn't matter. Because if you change one bit of the text, the hash will completely change, and so will the image. There is no computationally feasible way to change one bit of the hash.
Yes I realise I am more than a week late in posting this.
Couldn't you also use a regular computer to verify it with 100% accuracy (for some classes of problems)?
For example, I can (as I understand it) use a quantum computer to find the two prime factors of a semiprime number. Say that the QC can give me the correct answer with, say, 60% accuracy. Now I just need to take the answer and use a regular computer to multiply the two numbers and see if they give me the original number. If they don't, I ask the QC again until it gets it right. No need to continuously run the computation to reduce the probability of error. Is there some reason this might not work?
Let me clarify your post so it is absolutely clear to people reading it: when you say "voluntary filtering", you are referring to a filter that ISPs may voluntarily enable, for all of their customers. In this respect, I can join an ISP that has elected not to enter the trial, but I cannot opt-out of the filter without changing ISPs.
It is extremely dangerous to assume everything is okay at this point. Implementing a voluntary DNS filter is a clear first-step "foot in the door" towards implementing a mandatory filter that goes beyond DNS queries.
Re:Tau is already used
on
Happy Tau Day
·
· Score: 1
And I'm not sure what's up with/.'s unicode support. But I don't seem to be able to use the symbols for "pi" or "tau".
Re:Tau is already used
on
Happy Tau Day
·
· Score: 1
I know I'm a few days late, but TFA explicitly has an entire section to address this:
Fortunately, although the letter appears in some current contexts, there are surprisingly few common uses.... Despite these arguments, potential usage conflicts are the greatest source of resistance to .... But scientists and engineers have a high tolerance for notational ambiguity, and claims that -the-circle-constant can’t coexist with other uses ignores considerable evidence to the contrary. For example, in a single chapter (Chapter 9) in a single book (An Introduction to Quantum Field Theory by Peskin and Schroeder), I found two examples of severe conflicts that, because of context, are scarcely noticeable to the trained eye.
More examples are given, but the point is that many mathematical symbols, including , are already overloaded, and we get along fine.
I've played a lot of video game remakes. I'm really a fan of the concept. I love playing old games with a facelift. But I don't consider them to be a replacement of the original, but a new experience. For example, in 2000 they made a fully 3D version of Myst called realMyst. I think it's wonderful (and it even has bonus content), but I still play Myst equally as much as realMyst.
Now here's the key to enjoying the original and the remake -- the "switch" key that LucasArts implemented in the Secret of Monkey Island and Monkey Island 2 special editions. With one keystroke, you can flick between a precise replica of the original game (with the original graphics, music and user interface) and the modern remake version. It's quite fun to periodically switch between the two modes to see the differences.
Does anybody know of another remake that does this? (Pre-2009?)
I was shocked when I found out the private keys are stored locally in an unencryped file - that's a f***ing travesty.
Me too. But you have to consider the current software implementation of Bitcoin to be in beta. It is absolutely very rough, both from a usability and security standpoint. The actual Bitcoin network, however, is rock solid. (Which is good, because we can change the client, but not the network.)
So yes, that's bad, but they're apparentlyworking on it. In the meantime, if you want to be trying "beta" quality software, you have to put up with problems like this, and that means either taking a risk or doing your own encryption.
Slashdot Mirror
It has a "shelf" which is much like the Git staging area, only reversed. In Git, nothing is committed by default unless you stage it first. In Bazaar, everything is committed by default unless you shelve it first.
This works the same in practice: if you want to commit only part of your changeset, first you shelve everything you don't want to commit, then commit, and then unshelve again. I find that I make far fewer "accidentally forgot to commit something" errors. (A friend of mine came all the way to work one day, realised he forgot to stage something in Git from his home computer, and then immediately left and went all the way home again.)
No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.
Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)
It seems like things weren't set up very well. I fail to see how any revision control system could deal with this. If you had been using Git, you wouldn't have had access to those branches at all. The build system should be contained within the repository, not outside it, so it shouldn't matter what directory the repository is stored in on disk.
I may have misled you into thinking that Bazaar treats branches the same way as SVN: It doesn't and that would be awful. Subversion stores tags/branches as subdirectories of the repository -- that means you have them locked into a particular location. Bazaar stores branches as parent directories of the repository -- they are just ordinary directories anywhere you like on your file system which contain checkouts of a repository inside them (but unlike Git, they only contain a single branch, and if you want multiple branches, you create multiple directories).
Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect? In my experience, most merges just show up as a single object with what looks like two randomly-named parents (I know they're hashes but that doesn't help me as a human).
Of course. I'm only saying what I prefer, but my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.
Someone already mentioned this. I'll paste what I said above there (and it's backed up by your second link too, see the section "Sharing Notes"):
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.
That would certainly help. I was extolling the merits of Bazaar's revision numbering scheme on my post above (titled "Bazaar"). The problem as I see it is that unlike Bazaar, Git doesn't assign any significance to the master parent of a commit. I'll shamelessly rip some text from my own explanation above:
For example, in Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch.
The difference is that in Bazaar, a merge is asymmetrical: you merge from one branch to another, and it makes a difference: the "to" branch (typically the trunk) gets to keep its original revision numbering scheme, while the "from" branch gets relegated to the x.y.z scheme. In Git you merge between two branches (the order does not matter) and then commit the result to one of them (typically the master).
I would like a scheme where Git places significance on the to branch like Bazaar does, but then the Git fanatics would cry that it's possible to break things by merging the wrong way (which is certainly possible in Bazaar, but I think it's better than not having that metadata at all).
An important distinction with Subversion (which I think handles branches atrociously): In Subversion, branches are separate folders within the repository; a repository has a single linear history with branch directories inside of it. In Bazaar, branches are separate folders outside of the repository; each branch has its own history and branches are treated as separate objects. Sorry if I didn't make that clear.
As for revision numbers, on the contrary: they aren't really meaningful until you start doing non-linear history (merging). Once you start merging, it is very nice to be able to see "oh, this is revision 173 and its parent is revision 172, but it also had a merge from a branch revision 168.1.32," as opposed to Git where all you can say is "oh, this is revision 0f3bc3df and it has two parents: 83c7ac39 and e337cb8a; I don't know which one is the actual trunk history and which one is the branch commit."
Well of course Git has a concept of branches, but it only lets you access one at a time. What I find frustrating about this (besides the educational overhead of having to learn how to switch branches, and figure out which ones are being pushed and to where) is the fact that there is no URL for identifying a particular branch in Git -- URLs identify repositories, and then branches are identified by additional syntax I still haven't grokked fully.
This is a common (and untrue) criticism of Bazaar. Bazaar has a feature called "shared repositories" which allows you to create a directory and say "all branches in any subdirectory of this will share revision data". The shared repo has no semantic meaning (it isn't like a Git repository) -- it's purely an optimisation to address exactly this problem. Now admittedly, it is an advanced feature that a basic user may not know about, but if you aren't using Bazaar enough to learn this feature, then you probably haven't got enough data in it to warrant this optimisation anyway.
When do you ever use relative paths that go up outside the current branch into another? If you ever did that (say, a file in 'trunk' refers to "../branch"), then it would break in Git anyway, where you can't refer to another branch. I think this is a non-argument. Besides, common practice in Bazaar is to have all the branches in one directory, and also have "trunk" in the same directory (it's just another branch, that happens to be called "trunk").
Another important point: you say that "trunk vs merged" in Bazaar is equivalent to Git, but it isn't. Git's data structure is quantifiably lacking some information that Bazaar includes. In Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch (and furthermore, the branch names are also stored in the commit metadata).
So yes, Git does support the concept of a master branch and other branches, but it doesn't remember, historically, which commits came from where, and thus is a poorer data structure than Bazaar's.
I've been using Bazaar for everything I do, large and small, for the past three years. I can't say I've ever noticed any delay in committing, branching or merging. Of course, if you are operating in bound mode (i.e., keep synchronised with the server) then it's a different story, but that's an optional feature that Git doesn't even have. From what I hear, Bazaar used to be much slower than it is now.
Uhh, how about this hypothetical scenario: half the world uses Git. You prefer a different tool.
Seriously, it is this closed-minded thinking that I meant when I said "what a selfish decision." If everybody used Git without complaint, you would have no need for using two VCSes on the same repository. But since I prefer Bazaar, and a good portion of projects are hosted with Git, I would very much like to be able to "bzr branch" a Git repository, work with it locally as if it were a Bazaar branch, commit, then push up to the Git server. In this ideal world, we don't need to argue over which VCS is better, because I can use mine and you can use yours (just as I can use my preferred web browser and you can use yours).
Why can't we have this ideal world? Because Git lacks metadata support. The above scenario already works with Subversion. I do it all the time: I "bzr branch" a Subversion repository, commit locally, then push, and it works fine -- my colleagues who use Svn don't even notice that I used a different client. The reason this works is because bzr-svn stores its own metadata in the Subversion properties (which means that another colleague who uses Bazaar can "bzr branch" the same Subversion repository and she'll see all of the Bazaar merge history). But I can't do this with Git.
From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).
Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.
Well that's really what GitHub is ... much like Facebook treats every "object" (status update, photo, event) as a commentable, likable object, so does GitHub for VCS objects such as commits.
It's quite funny to see a commit with a comment thread attached to it. I saw one that went viral and ended up with 88 comments including meme images.
I don't really use tools other than the command-line, but I believe Bazaar has had TortoiseBzr included in the main Windows package for some time now. I don't think there's Eclipse integration though.
Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."
It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).
I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.
Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X, which I wrote a rebuttal of at Why Git Ain't Better Than X.
It's like in the final season of 24, when Jack Bauer was on the run from the government, he bought about a dozen cell phones. Every time he made a phone call he would immediately throw the phone in a bin.
Thanks! Very informative. And ... Slashdot requires that I say more than just this. Hmm. Extremely informative?
Well I was glad to find that ABC article (via Slashdot), since I've read The Age, and figured it was bullshit, but hadn't got nearly as many facts until I read TFA.
The Sydney Morning Herald is the major broadsheet newspaper in Sydney. This article also appeared in other Fairfax publications such as The Age (the major broadsheet newspaper in Melbourne), and it appeared on the headlines on The Age website for awhile. So no, this is not some obscure blog.
The rebuttal article is from the Australian Broadcasting Corporation website, the primary government-funded television network in Australia.
I don't know about the rest of the world, but in Australia, the media has gone nuts over this video game connection to the Oslo attack -- possibly because of all the noise made by the very powerful Australian Christian Lobby.
But that's why it's using a cryptographic hash first (SHA-512). The process is text -> SHA-512 hash -> image. Even if the image generation algorithm might only move the flower a little to the left if you change one bit of the hash, it doesn't matter. Because if you change one bit of the text, the hash will completely change, and so will the image. There is no computationally feasible way to change one bit of the hash.
Yes I realise I am more than a week late in posting this.
Couldn't you also use a regular computer to verify it with 100% accuracy (for some classes of problems)?
For example, I can (as I understand it) use a quantum computer to find the two prime factors of a semiprime number. Say that the QC can give me the correct answer with, say, 60% accuracy. Now I just need to take the answer and use a regular computer to multiply the two numbers and see if they give me the original number. If they don't, I ask the QC again until it gets it right. No need to continuously run the computation to reduce the probability of error. Is there some reason this might not work?
Beautiful!
Let me clarify your post so it is absolutely clear to people reading it: when you say "voluntary filtering", you are referring to a filter that ISPs may voluntarily enable, for all of their customers. In this respect, I can join an ISP that has elected not to enter the trial, but I cannot opt-out of the filter without changing ISPs.
It is extremely dangerous to assume everything is okay at this point. Implementing a voluntary DNS filter is a clear first-step "foot in the door" towards implementing a mandatory filter that goes beyond DNS queries.
And I'm not sure what's up with /.'s unicode support. But I don't seem to be able to use the symbols for "pi" or "tau".
I know I'm a few days late, but TFA explicitly has an entire section to address this:
More examples are given, but the point is that many mathematical symbols, including , are already overloaded, and we get along fine.
I've played a lot of video game remakes. I'm really a fan of the concept. I love playing old games with a facelift. But I don't consider them to be a replacement of the original, but a new experience. For example, in 2000 they made a fully 3D version of Myst called realMyst. I think it's wonderful (and it even has bonus content), but I still play Myst equally as much as realMyst.
Now here's the key to enjoying the original and the remake -- the "switch" key that LucasArts implemented in the Secret of Monkey Island and Monkey Island 2 special editions. With one keystroke, you can flick between a precise replica of the original game (with the original graphics, music and user interface) and the modern remake version. It's quite fun to periodically switch between the two modes to see the differences.
Does anybody know of another remake that does this? (Pre-2009?)
Yet (in Australia at least) our politicians aren't willing to do anything about climate change, because "maybe it won't happen."
Me too. But you have to consider the current software implementation of Bitcoin to be in beta. It is absolutely very rough, both from a usability and security standpoint. The actual Bitcoin network, however, is rock solid. (Which is good, because we can change the client, but not the network.)
So yes, that's bad, but they're apparently working on it. In the meantime, if you want to be trying "beta" quality software, you have to put up with problems like this, and that means either taking a risk or doing your own encryption.
Notifications are part of HTML5. As far as I know, only Chrome supports it at the moment, but it is being standardised.