It still doesn't give me what I want, because I want to be able to commit on my laptop when I have no Internet connection of any kind. But yes, it comes closer.
I also feel the Perforce's tracking of merges is somewhat lacking and a bit confusing in comparison with how they're tracked in a DVCS. But it's certainly a whole ton better than either CVS or Subversion.
It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.
First, a few questions:
Does reset --soft HEAD~5 remove any revisions from the repository?
What does the '~5' mean?
How does the meaning of ~5 change if there are merges or branches in the very recent history?
If I have the answers to those questions, I can tell you which Mercurial command (or short series of commands) does it, though if your answer to the last one is particularly interesting, it may be kind of complicated.
Well, no offense, but it sounds like you're just not trying that hard. Git's terminology is slightly odd (the term 'index', referring to the staging area, is a certainly strange), but fundamentally, it's operations are just operations on the commit tree. There's nothing really that confusing going on there, save that some of git's commands allow for some fairly low-level manipulation of said tree.
That's true, but, for example, the 'reset' command suggests absolutely nothing to me. Why isn't it named 'rollback' or 'undo' or 'revert' or something else vaguely related to revisions and transactions?
I'm not misunderstanding. I'm pointing out where git allows a hack to "change history" that should not be there, and it's existence adds extra complexity and opportunities to shoot yourself in the foot. It should not be like that.
Well, Mercurial makes it a lot hard to change history than git does. But it's still possible.
And no Perforce shop I've ever seen has ever had a private branch for each developer. You could work that way, it's true, but I've never seen it done.
Re-writing history isn't exactly bad. In a DVCS system, you have a local repository that nobody else has seen yet. You commit things to this early and often, frequently things that make no sense to anyone else. And this is because nobody can see them.
Re-writing history is often a very nice thing to do before you publish your changes to a wider audience.
In systems like Perforce, you often work on a change for days before actually committing it because once you commit it, it's in the big centralized repository forever. In Mercurial (which is very much like git, except that the command syntax actually makes sense) I commit every hour or two.
Personally, I prefer very structured means for maintaining my change history before I submit it upstream. I like using the Mercurial 'mq' extension which allows you to keep a stack of pending changes and go back and edit them into submission before you push them upstream and they become permanent.
So, you are partly right, and partly misunderstanding. The workflow for a DVCS is somewhat different than for a centralized system like Perforce.
Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand.
I really dislike working with git because it is strange, confusing and makes no sense. And that's not just a matter of being very familiar with the Mercurial command syntax. I know how hash DAG based DVCS systems work, and git still makes no sense.
Oh, so git reset --soft HEAD^ is like hg debugsetparents, which sets what changeset(s) Mercurial considers the working directory to be a branch off of.
And git reset --hard HEAD^ is like hg update -C <revnum>.
You should give Mercurial a try. The thing that got me to use it in 2005, when it was pre-1.0, was how clean and obvious the command line interface was. I don't generally use graphical tools for development work, so I can't gauge the various GUIs available for it, but I do know that a lot of people like TortoiseHG.
I've used Perforce as well, and it has its strange quirks and complexities too, though I agree that git's command line interface leaves a great deal to be desired in comparison. I think Mercurial's command line interface is more intuitive and clearer than Perforce's.
Mercurial is just as free, and just as easy to set up. Code hosting repositories are about someone else managing your connectivity, storage and backups for you, not about them building DVCS software for you.
As someone pointed out, every device that's IPv6 capable gets a link local address without any configuration on anybody's part. And while all the one's I've seen start with fe80, the range for link local addresses start with fe80::/10 (i.e. only the first 10 bits are constant).
Devices send packets out for a number of reasons, though if you've never configured IPv6 of any kind, the most likely packets you're seeing are router solicitation packets asking any routers on the network to please respond. IPv6 doesn't really need DHCP, though DHCPv6 does exist in the IPv6 spec. Mostly IPv6 devices find a router and ask it what prefix they should configure themselves with. Often routers will simply announce themselves and say what prefix hosts should be using.
Additionally, newer versions of Windows have a number of features designed for tunneling IPv6 packets over the IPv4 network. This enables them to speak IPv6 and talk to other IPv6 machines even though the intervening network is not aware that IPv6 exists.
Ahh, a denier. I've seen you people too. The estimates that you claim to hear periodically keep on changing as the estimates change. I think you are mistaking early warnings for estimates that IPv4 will run out of addresses in a short period of time.
For the past 3 years, the date has remained relatively consistent. I have a nice phone app that shows exactly how many blocks are left. The number's been going down right on schedule.
And at every job I've worked in the past 5 years, management has completely had their head in the sand about it.:-( And none of the developers understood enough about IPv6 to push in an even faintly credible way.:-(
I've been running IPv6 on my home network since about 2002. It's just not that hard. In fact, it's a lot easier than running IPv4. My IPv4 home network has a seriously contorted configuration because of the constrained addressing. When I wasn't even given a block of IPs but instead given X number of individual IP addresses it was even worse. My IPv6 network, OTOH, is configured quite simply and obviously.
OTOH, even though I've had an IPv6 DNS server for ages, my stupid registrar STILL does not support IPv6 glue records. It's ridiculous. The standard has been stable enough to do something like that for at least 3-4 years now. I just want to strangle them.
Last I checked, we only have about 200 days before ARIN stops being able to hand out new IPv4 addresses. It's around 7 months. After that, hosts start appearing on the Internet that only have IPv6 addresses. The connectivity breakage will be slow, subtle and inexorable. I bet it takes the tech industry at least another 5 or 6 years before they have to fix the problem or not have customers, and I bet it won't be fixed before then. So very very stupid.
I can understand about military situations being distinctly different from civilian ones. But this seems really dumb. What you want is people who can see patterns in stuff happening that nobody else would notice. You want human intrusion detection.
The most dangerous cyber attacks are very subtle. I think talent and familiarity with the technical details are much more important than the ability to make quick decisions under intense pressure.
The ability to make decisions under a lot of pressure can be an important skill, but spotting things that are subtly off, in my experience, requires intimate familiarity with the environment. A person's technical experience has a much greater correlation with that familiarity than combat experience.
Nonetheless, if you can find a way to reliably distinguish DES output from random bits, without knowledge of the key and with remotely-practical efficiency, you can publish a paper that will gain you substantial name recognition among the world's cryptographic elite.
If you have enough DES output you can do this. Someone already mentioned that if you use a strong cipher, even AES-256 in ECB (electronic codebook mode) then the output is nearly trivially distinguishable because repeated plaintext patterns of the size of the block the block cipher algorithm uses will encrypt to identical ciphertexts.
Even if you use CTR mode or CBC mode, patterns in the plaintext show up in the output if you encrypt enough data.
For example, if you by chance end up with the same ciphertext output block in CBC mode you can obtain the XOR of the corresponding plaintext blocks by XORing the two immediately preceeding ciphertext blocks. If you encrypt enough blocks, the laws of statistics favor two blocks ending up being identical by chance. And this XOR equality allows you to determine if the data is encrypted because it's generally relatively easy to tell if the XOR is the result of XORing two pieces of unecrypted data.
CTR mode has a different sort of relationship that can be exploited. You know that the XOR of any two ciphertext blocks is not equal to the XOR of the corresponding two plaintext blocks. This can eventually leak information about the plaintext with enough blocks to work with. But using the inequality to determine if the bunch of data is truly random or encrypted data takes a lot fewer blocks.
And, of course, if your blocks are larger you need many more of them for the statistics to work out in your favor for attacking the cipher. This is why block ciphers should be re-keyed periodically when encrypting a lot of data. It's also why it's much easier to write a distinguisher for DES (64-bit blocks) than AES (128-bit blocks) that distinguishes between encrypted and random data.
As an ideal, yes. But compressed data is still pretty distinguishable from random data. In particular, many compression formats have small markers in various places so that the decompressor can attempt to recover a corrupted file. Also, no compression technique is perfect, so even without these the data is still distinguishable.
And that's interesting to know, and I believe it. But it doesn't change anything I said. While it's lots more expensive than a software hack would be, I could go and get the crippling reversed.
Your analogy also fails. To go back to the knife and compass... the knives are sold without a compass, but secretly has one hidden behind a sealed metal shield in the handle. You are expressly prohibited from messing with the metal shield yourself, you have to have an 'authorized service technician' remove the metal shield for some extra cash.
And that's pretty darned stupid. I bought the knife, metal shield, compass and all. If I want to remove the metal shield and have the tools I'm darned well going to regardless of any silly rules the seller tries to impose on what I can and can't do with my knife.
Nobody should be allowed to impose post-sales restrictions on your property without a contract they negotiate explicitly with you. The key word being 'negotiate' implying that the terms can be modified in detail by you or the other party before either signs it.
Yes, this is a case in which I'm willing to believe Google acted anticompetitively and with monopolistic intent, but I would like to see all the facts first. The charges Skyhook lodges are serious, and unlike the charge over search engine results, completely believable. But I still want to have more data on what actually happened before I decide on this one.
Unfortunately, I agree with you.:-/ Bureaucracy is annoying, but there needs to be some really hard accountability about who's accessing people's personal data, why, and when.
I generally agree with you, except to add that for something like this, data mobility is still really important. You have to be able to easily move your account to some random other Diaspora node relatively easily or you will be stuck with your DIaspora provider and whatever kinds of garbage they want to foist on you.
And if specialized service providers sprout up to host this data, wouldn't that be creating the same situation that this software is supposed to be trying to get away from: other having control of your data?
So, would you rather 50 or 60 service providers, each of which host a couple hundred thousand people, or one that hosts 500 million? Which is more dangerous, overall, from a privacy perspective? And if people can switch providers easily (which is another goal) providers will have to compete on privacy protection since if they mess up, people will just take their data elsewhere.
It's like having a free market vs. a monopoly. Just because the free market doesn't eliminate money doesn't mean it's not better.
You don't have a clue what you're talking about. The whole point is that I can host my very own Diaspora node and anybody on any other Diaspora node can link to me.
Your statement is like saying "If Apache really wants to be a competitor to Geocities they need to have massive numbers of servers like Yahoo does!".
DIaspora does not need centrally administered computing resources to work. Sure, if you are hosting the Diaspora node of a celebrity you might need a server farm, but most people could host their Diaspora node off a cable or DSL line.
Slashdot Mirror
It still doesn't give me what I want, because I want to be able to commit on my laptop when I have no Internet connection of any kind. But yes, it comes closer.
I also feel the Perforce's tracking of merges is somewhat lacking and a bit confusing in comparison with how they're tracked in a DVCS. But it's certainly a whole ton better than either CVS or Subversion.
It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.
First, a few questions:
If I have the answers to those questions, I can tell you which Mercurial command (or short series of commands) does it, though if your answer to the last one is particularly interesting, it may be kind of complicated.
Well, no offense, but it sounds like you're just not trying that hard. Git's terminology is slightly odd (the term 'index', referring to the staging area, is a certainly strange), but fundamentally, it's operations are just operations on the commit tree. There's nothing really that confusing going on there, save that some of git's commands allow for some fairly low-level manipulation of said tree.
That's true, but, for example, the 'reset' command suggests absolutely nothing to me. Why isn't it named 'rollback' or 'undo' or 'revert' or something else vaguely related to revisions and transactions?
I'm not misunderstanding. I'm pointing out where git allows a hack to "change history" that should not be there, and it's existence adds extra complexity and opportunities to shoot yourself in the foot. It should not be like that.
Well, Mercurial makes it a lot hard to change history than git does. But it's still possible.
And no Perforce shop I've ever seen has ever had a private branch for each developer. You could work that way, it's true, but I've never seen it done.
Re-writing history isn't exactly bad. In a DVCS system, you have a local repository that nobody else has seen yet. You commit things to this early and often, frequently things that make no sense to anyone else. And this is because nobody can see them.
Re-writing history is often a very nice thing to do before you publish your changes to a wider audience.
In systems like Perforce, you often work on a change for days before actually committing it because once you commit it, it's in the big centralized repository forever. In Mercurial (which is very much like git, except that the command syntax actually makes sense) I commit every hour or two.
Personally, I prefer very structured means for maintaining my change history before I submit it upstream. I like using the Mercurial 'mq' extension which allows you to keep a stack of pending changes and go back and edit them into submission before you push them upstream and they become permanent.
So, you are partly right, and partly misunderstanding. The workflow for a DVCS is somewhat different than for a centralized system like Perforce.
Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand.
I really dislike working with git because it is strange, confusing and makes no sense. And that's not just a matter of being very familiar with the Mercurial command syntax. I know how hash DAG based DVCS systems work, and git still makes no sense.
Oh, so git reset --soft HEAD^ is like hg debugsetparents, which sets what changeset(s) Mercurial considers the working directory to be a branch off of.
And git reset --hard HEAD^ is like hg update -C <revnum> .
The equivalent in Mercurial is `hg rollback`. ;-)
You should give Mercurial a try. The thing that got me to use it in 2005, when it was pre-1.0, was how clean and obvious the command line interface was. I don't generally use graphical tools for development work, so I can't gauge the various GUIs available for it, but I do know that a lot of people like TortoiseHG.
I've used Perforce as well, and it has its strange quirks and complexities too, though I agree that git's command line interface leaves a great deal to be desired in comparison. I think Mercurial's command line interface is more intuitive and clearer than Perforce's.
Mercurial is just as free, and just as easy to set up. Code hosting repositories are about someone else managing your connectivity, storage and backups for you, not about them building DVCS software for you.
I think that's testimony to how well IPv4 has worked, and I think that deserves some recognition. Three cheers for IPv4 and those who made it happen!
*grin* I agree with you, though it's still frustrating.
Thanks for the tip. I've been considering switching registrars over this, even though most of my domains have a year or two left on them.
As someone pointed out, every device that's IPv6 capable gets a link local address without any configuration on anybody's part. And while all the one's I've seen start with fe80, the range for link local addresses start with fe80::/10 (i.e. only the first 10 bits are constant).
Devices send packets out for a number of reasons, though if you've never configured IPv6 of any kind, the most likely packets you're seeing are router solicitation packets asking any routers on the network to please respond. IPv6 doesn't really need DHCP, though DHCPv6 does exist in the IPv6 spec. Mostly IPv6 devices find a router and ask it what prefix they should configure themselves with. Often routers will simply announce themselves and say what prefix hosts should be using.
Additionally, newer versions of Windows have a number of features designed for tunneling IPv6 packets over the IPv4 network. This enables them to speak IPv6 and talk to other IPv6 machines even though the intervening network is not aware that IPv6 exists.
Ahh, a denier. I've seen you people too. The estimates that you claim to hear periodically keep on changing as the estimates change. I think you are mistaking early warnings for estimates that IPv4 will run out of addresses in a short period of time.
For the past 3 years, the date has remained relatively consistent. I have a nice phone app that shows exactly how many blocks are left. The number's been going down right on schedule.
And at every job I've worked in the past 5 years, management has completely had their head in the sand about it. :-( And none of the developers understood enough about IPv6 to push in an even faintly credible way. :-(
I've been running IPv6 on my home network since about 2002. It's just not that hard. In fact, it's a lot easier than running IPv4. My IPv4 home network has a seriously contorted configuration because of the constrained addressing. When I wasn't even given a block of IPs but instead given X number of individual IP addresses it was even worse. My IPv6 network, OTOH, is configured quite simply and obviously.
OTOH, even though I've had an IPv6 DNS server for ages, my stupid registrar STILL does not support IPv6 glue records. It's ridiculous. The standard has been stable enough to do something like that for at least 3-4 years now. I just want to strangle them.
Last I checked, we only have about 200 days before ARIN stops being able to hand out new IPv4 addresses. It's around 7 months. After that, hosts start appearing on the Internet that only have IPv6 addresses. The connectivity breakage will be slow, subtle and inexorable. I bet it takes the tech industry at least another 5 or 6 years before they have to fix the problem or not have customers, and I bet it won't be fixed before then. So very very stupid.
I would replace 'not tomorrow' with 'probably not tomorrow'. Stuff can happen surprisingly quickly.
I can understand about military situations being distinctly different from civilian ones. But this seems really dumb. What you want is people who can see patterns in stuff happening that nobody else would notice. You want human intrusion detection.
The most dangerous cyber attacks are very subtle. I think talent and familiarity with the technical details are much more important than the ability to make quick decisions under intense pressure.
The ability to make decisions under a lot of pressure can be an important skill, but spotting things that are subtly off, in my experience, requires intimate familiarity with the environment. A person's technical experience has a much greater correlation with that familiarity than combat experience.
Nonetheless, if you can find a way to reliably distinguish DES output from random bits, without knowledge of the key and with remotely-practical efficiency, you can publish a paper that will gain you substantial name recognition among the world's cryptographic elite.
If you have enough DES output you can do this. Someone already mentioned that if you use a strong cipher, even AES-256 in ECB (electronic codebook mode) then the output is nearly trivially distinguishable because repeated plaintext patterns of the size of the block the block cipher algorithm uses will encrypt to identical ciphertexts.
Even if you use CTR mode or CBC mode, patterns in the plaintext show up in the output if you encrypt enough data.
For example, if you by chance end up with the same ciphertext output block in CBC mode you can obtain the XOR of the corresponding plaintext blocks by XORing the two immediately preceeding ciphertext blocks. If you encrypt enough blocks, the laws of statistics favor two blocks ending up being identical by chance. And this XOR equality allows you to determine if the data is encrypted because it's generally relatively easy to tell if the XOR is the result of XORing two pieces of unecrypted data.
CTR mode has a different sort of relationship that can be exploited. You know that the XOR of any two ciphertext blocks is not equal to the XOR of the corresponding two plaintext blocks. This can eventually leak information about the plaintext with enough blocks to work with. But using the inequality to determine if the bunch of data is truly random or encrypted data takes a lot fewer blocks.
And, of course, if your blocks are larger you need many more of them for the statistics to work out in your favor for attacking the cipher. This is why block ciphers should be re-keyed periodically when encrypting a lot of data. It's also why it's much easier to write a distinguisher for DES (64-bit blocks) than AES (128-bit blocks) that distinguishes between encrypted and random data.
Doesn't compressed data look random?
As an ideal, yes. But compressed data is still pretty distinguishable from random data. In particular, many compression formats have small markers in various places so that the decompressor can attempt to recover a corrupted file. Also, no compression technique is perfect, so even without these the data is still distinguishable.
And that's interesting to know, and I believe it. But it doesn't change anything I said. While it's lots more expensive than a software hack would be, I could go and get the crippling reversed.
Your analogy also fails. To go back to the knife and compass... the knives are sold without a compass, but secretly has one hidden behind a sealed metal shield in the handle. You are expressly prohibited from messing with the metal shield yourself, you have to have an 'authorized service technician' remove the metal shield for some extra cash.
And that's pretty darned stupid. I bought the knife, metal shield, compass and all. If I want to remove the metal shield and have the tools I'm darned well going to regardless of any silly rules the seller tries to impose on what I can and can't do with my knife.
Nobody should be allowed to impose post-sales restrictions on your property without a contract they negotiate explicitly with you. The key word being 'negotiate' implying that the terms can be modified in detail by you or the other party before either signs it.
Yes, this is a case in which I'm willing to believe Google acted anticompetitively and with monopolistic intent, but I would like to see all the facts first. The charges Skyhook lodges are serious, and unlike the charge over search engine results, completely believable. But I still want to have more data on what actually happened before I decide on this one.
Unfortunately, I agree with you. :-/ Bureaucracy is annoying, but there needs to be some really hard accountability about who's accessing people's personal data, why, and when.
I generally agree with you, except to add that for something like this, data mobility is still really important. You have to be able to easily move your account to some random other Diaspora node relatively easily or you will be stuck with your DIaspora provider and whatever kinds of garbage they want to foist on you.
And if specialized service providers sprout up to host this data, wouldn't that be creating the same situation that this software is supposed to be trying to get away from: other having control of your data?
So, would you rather 50 or 60 service providers, each of which host a couple hundred thousand people, or one that hosts 500 million? Which is more dangerous, overall, from a privacy perspective? And if people can switch providers easily (which is another goal) providers will have to compete on privacy protection since if they mess up, people will just take their data elsewhere.
It's like having a free market vs. a monopoly. Just because the free market doesn't eliminate money doesn't mean it's not better.
You don't have a clue what you're talking about. The whole point is that I can host my very own Diaspora node and anybody on any other Diaspora node can link to me.
Your statement is like saying "If Apache really wants to be a competitor to Geocities they need to have massive numbers of servers like Yahoo does!".
DIaspora does not need centrally administered computing resources to work. Sure, if you are hosting the Diaspora node of a celebrity you might need a server farm, but most people could host their Diaspora node off a cable or DSL line.