Yes, that's under reality, where OpenSSL made a bad choice to use an awful custom allocator. But that's not what you were talking about:
And even if they had, there's all these non-OpenBSD servers that are getting hacked and nobody can say if they're hacked or not, so we just get ourselves into this exact situation sooner. We don't come away with smaller collateral damage; EVERY SSL CERTIFICATE EVER ISSUED IS NOW INVALID.
Getting into the same situation and discovering it sooner leads to smaller collateral damage! If this problem had been discovered in 2012 instead of now, it means that any certificates issued in 2013 or 2014 (except from versions left vulnerable) would have been fine in that scenario. Currently, now they're suspect.
Not exactly crypto, but an amusing article on producing a way to compute the entire shuffle of a deck of cards in online poker based on those that were visible: How We Learned To Cheat At Online Poker
Uh, no. The heartbleed bug isn't a result of OpenSSL breakage in the way it allocates memory; it's actually a result of incorrectly handling memory allocated properly. That OpenSSL can't work when compiled against normal malloc() implies other issues unrelated to this one.
It's not unrelated in the sense that a hardened malloc is specifically designed to help limit damage in the face of vulnerabilities such as the heartbeat one.
Had they tested OpenSSL on OpenBSD, the crash would have happened and someone would have looked into the cause.
No, for two reasons:
1) Theo's main point, about malloc, is that if you disable their custom allocator on any system (or any system that doesn't return a just-freed block in malloc, anyway) then it won't work -- nothing OpenBSD specific at all.
2) Even if you could disable the custom allocator, the crash would only happen in the face of the exploit. So if you don't have a test for the exploit then you wouldn't discover the crash during testing anyway.
The custom allocator matters for two reasons. First, it provides a last layer of defense for OpenBSD users. Second, if the attack was in use in the wild and someone with OpenBSD discovered it, then they could have found it sooner.
Knowing that this happened, I would hope that the OpenSSL maintainers would turn off that compiler flag...
It's not a compiler flag, it's code. Also they have some bugs to fix before they can do it. They almost certainly will, and perhaps already have.
Nothing Theo suggested changes the situation. Implementing malloc() protection everywhere might; but if you can show any ability to beat that protection a percentage of the time, then we're also in the same situation. We're talking about reads, so canaries aren't it. If you're crashing out on reads, then every malloc(1) that crashes if you read 2 requires 4096 bytes of real RAM to store 1 byte of data--we get into costs.
You lack imagination. The choice isn't between "traditional dense allocation" and "one page per allocation." I don't know what OpenBSD's allocate does, but it would be entirely possible to make an allocator that is comparably dense to a traditional one but still uses discontinuous pages. Such an allocator would still dramatically limit the amount of data that could be read on a system with such an allocator, because you would be unlikely to be able to overread past the end of the page. You could still get some data, but there'd be a "hard" limit of under 4K (16x less that what's possible) and even under that limit the more you request the more you run the risk of running into the neighboring unmapped page.
... if you can show any ability to beat that protection a percentage of the time, then we're also in the same situation
I also reject this argument. If that were true, we might as well give up on security. Probably nothing is ever going to be 100% perfect (at least before the singularity). Using a hardened allocator, in many cases, will make attacks more difficult in the sense that you'll be relying on luck in terms of not overrunning the page. (Sometimes you'll hit something that can be done determistically, but I suspect this is not the general case except perhaps where you can leak the seed used for randomization.) Harder attacks means they'll fail more often, and each failure gives a chance of detection and discovery.
We don't come away with smaller collateral damage; EVERY SSL CERTIFICATE EVER ISSUED IS NOW INVALID.
I conclude from this you think no SSL certificates were issued between, say, in 2013 or 2014. I'm curious what evidence you have for this. *eyeroll*
You're also ignoring software versions. Suppose that this had been discovered 6mths after the original version was released. Anyone who didn't upgrade during that 6 mths would have been safe. If the discovery of the bug was delayed by a significant margin, that means that many more people became vulnerable.
All the usual measures against buffer overwrites don't help, because there is no buffer overwrite....You'd need a malloc that will crash if you read past the end of a malloc buffer. That's hard to do efficiently.
OpenBSD's "usual measures" would have helped, because the OpenBSD allocator will often put allocated memory in isolated pages. So it's quite likely that 64K read will cross into an unmapped page, and boom, you have your crash.
This level of overread protection is close to free.
Theo's "rant" isn't brought about by a typical bug in the sense of a mistake in the code. His rant is brought about by the fact that OpenSSL deliberately introduced wrapper functions for malloc/free, making it impossible for a system to provide hardened ones, then made those wrappers default. He further rants about the fact that, because it's default, they later introduced a bug that means you can't turn the wrappers off.
The heartbeat bug itself was a mistake and a bug in the traditional sense. The "hey let's replace malloc/free" is much closer to "bad decision" than "mistake."
The OpenSSL team doesn't fully test their product.
I agree with Theo on the broader point, but disagree here: "their product" is the code they wrote with their custom memory allocator. It's not the code they wrote with some changes someone outside the product made. Their custom allocator isn't disabled or enabled depending on configuration checks or something like that, it's always part of the product.
Were OpenSSL's developers aware that malloc()/free() have special security concerns that OpenBSD's developers had specifically addressed (I assume that's what meant by "a conscious decision to turn off last-line-of-defense-security")
My impression is OpenBSD's hardened allocator is relatively common knowledge and definitely should be among people writing security software. And that's not even remotely the only such allocator out there that does that sort of thing too, though it's probably the most well-known from the industrial side.
Really legit mailing lists should be rewriting the sender headers to reflect that the mail has been redelivered by the mailing list, the only difficulty this would cause is when users try to reply directly to messages rather than forwarding their replies to the list itself.
No no no no no no no. "When users try to reply directly" is a significant problem -- "reply" going to the sender only is fail-safe. "reply" going to the list results in things like "take me off this list" bombs, people accidentally disclosing confidential or embarassing information to the list, etc.
In addition to that, if you have a reply-to-sender mailing list, replying to the list is easy: you just click reply all. (At least that's my default action when replying to an email anyway.) If you have a reply-to-list mailing list and want to reply to just the sender, now neither of your reply buttons work.
My take is that the start menu required a "lot" of work to maintain if you actually wanted it to be a useful hierarchy. If you just let stuff install by default and never changed things, then I think it turned into more of an almost-not-hierarchical view of a bunch of crap, personally. It'd be one thing if programs installed an icon or two (or even a submenu) under categories like Games/Productivity/Development/etc. like you get with Linux distros, but that would require cross-vendor cooperation (perhaps enforced by MS); instead you just got programs would install to Start Menu/Programs/My Crappy Company/My Crappy Software/* or, even worse, Start Menu/Programs/My Crappy Software and Start Menu/Programs/Help For My Crappy Software and Start Menu/Programs/Visit My Crappy Website etc.
I hesitate to call that "useful" personally, and it's the main reason that once Vista introduced the search functionality I very rarely actually navigated the start menu itself. On Vista/7 navigating it was actually a lot worse than it was in previous versions IMO because everything got squashed into a very small space as opposed to getting expanded out a bit more; but I was one of those weirdos who used Vista by choice and a lot of that was due to the search feature, because that made up for everything else I saw wrong with it. (I discovered Launchy a bit too late.)
I don't know what to think of 8. Vista/7 got me spoiled with the search feature so that's what I use on 8 (I also use that by choice...), and as a result my day-to-day use is basically identical between 7 and 8, and I basically never use the start screen except via search. I feel like the default program launcher on 8 (what you get when you hit the Windows key/button) requires the same sort of manual maintenance as the start menu "needed", and I haven't bothered to do that. The all programs menu I think works better than the start menu if you left the latter alone. People complain about how the start screen takes over your whole display, but I view that as a virtue -- it means a lot more can be displayed at once and, I think, it's easier to scan. I've also never wanted to see something I had open when I was figuring out what to launch. The down side is that it basically collapses the heirarchy -- but I think that unless you groom the start menu yourself, there's usually very little meaningful hierarchy for it to collapse.
That's my opinion anyway. (And no, I do not and never have had a relationship with MS.)
Eh, it's my current car so it's what I jumped to. My point was mostly that "it's as expensive as a full sized car" is only true for maybe the absolute lowest end of full-sized cars.
Do yourself a favor and buy a used Hyundai Accent instead. Trust me, it's a better car. (Even a 10-year-old Accent is a better car than a brand new Smart.) Or buy a Mazda, or a Ford, or, Hell, even a Scion. There is no small car worse than a Smart.
My main attraction to the Smart is to make parallel parking in tight spots easy; it's substantially better at that than basically anything else. But it's off the table anyway because I'm only going to have one car, and a substantial portion of my driving is on long trips and I'm not doing that in a Smart. But if I was considering a second car, that's where I'm willing to compromise on many of the things that the Smart isn't as good at.
Sorry, I just really hate that car, it's only real up side is that you can pull into a parking space normally reserved for parallel parking. Something that can be overcome by learning how to drive, which would then mean you could parallel park.
How did you get so close to the benefit and still miss it? It's not that you can pull into a parallel spot, it's that you can fit into parallel spots that are just flat out too small for larger cars. Learning to drive won't change fact that, say, a 12 foot space will comfortably hold a Smart car (8-9ft long) but not, say, a Civic (15 feet).
They aren't particularly fuel efficient, their crash test ratings are far from stellar, they don't have a lot of space & cost as much as a full sized car.
I think several points are off. For instance, if I look at new cars on cars.com around me, the cheapest fit is $14,370. If I check out the cheapest Civic, it's $18,980. That's 25% less than an already cheap car. The Smart gets 34/38 mpg; the Civic gets 28/36. The Civic is a manual, the Smart an automatic transmission. (At least in the US, many people would consider a manual a deal-killer.) The Civic is bigger, but it's also far from big, and how big would you really need for a daily commute for instance? And the smaller size has a big benefit for people who do a lot of street parking: imagine being able to fit places where almost no one else can, or having a much easier time getting into tight spots.
The thing is that no car is going to be perfect -- there are always compromises in terms of cost, size, performance, safety, etc. But I think the Smart car fills a niche that would be pretty useful. I was just looking at cars earlier today because there's a hopefully-very-small chance I'll need a new one like, now, and if all I did was drive around town to and from work and errands and stuff, I'd seriously consider getting one.
Its probably possible to create a compiler mode that will compile bounds checking code into existing C programs.
It's somewhat possible, but not possible to do for general C programs. The CCured project has done something like this, but like I said it isn't fully general even for programs that are technically legal C. Many programs aren't and rely on specific implementations of certain undefined behaviors -- e.g. the Linux kernel needs to disable GCC's optimizations based on the strict aliasing rule, and that would almost certainly break a lot of approaches along the line of CCured.
C is a very poorly behaved language from a formal verification standpoint.
All the good games nowadays are multiplatform or platform-independent (java/mono)...
That depends what you mean by multiplatform. If you mean Windows + Linux - WINE, IMO the answer to that is "not even close." It's quite popular for Indie games to release Linux ports now, and that's great don't get me wrong. I'm also really encouraged by not just Steam on Linux but Valve's porting of several of their big-name games over. But even though I'm not a big gamer, there are still way too many omissions to move to Linux as a gaming platform.
Things open up more of course if you start including Mac & consoles in "multiplatform". But at least for me, both of those have far more significant drawbacks than Windows has.
The extra 5% you get out of Photo$hop or Office is more than offset by their hundreds (or thousands in the case of photoshit) of dollars of price difference.
That depends what you're doing of course. A while back I thought I would be creating quite a lot of PowerPoint presentations for a course I was teaching. (That turned out to not be the case both because I was spending a completely-unsustainable amount of time on each lecture and because I got a lot more comfortable with lecturing from a blackboard.) I tried out a couple different options for presentation software, and even though I have a lot of things I don't like about PowerPoint everything else sucked so much more that it was easily worth the price -- and that was true even on a grad student salary. (Keynote seems promising, but I neither have a Mac nor see myself buying one with anything close to Apple's current lineup.)
If you _need_ that extra five (or maybe tops, ten) percent, well, maybe you should find another job.
What if your job is awesome? That's a remarkably stuck up attitude: "I don't like your tools. You should change."
Actually I've been using Windows 8 for a while. I think I'm almost the one person who... is pretty indifferent about the changes overall. Doesn't affect my usage patterns much at all. I ignore the metro desktop and carry on with my life.:-)
Yeah, same here. Later in the day, after they carried it over to Twitter and stuff, I posted the "news" to a chat I was in saying basically "The SVN project is either (1) moving to git or (2) in the mist of an incredibly committed April Fool's day joke, and I honestly can't tell which it is."
A lot of other sites had nice gags for the 1st, but this was the only one I saw that could legitimately earn the "April Fools" label.
Resolving as "Not a problem". We sure as hell don't want to do this.:-)
My major thanks to [~jfarrell] for the concept.
And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse:-) ⦠the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagons⦠Thank you all for making this work!!!
To counter your terminology argument, often in technology, backwards compatible is preferable to a redesign.
I agree... but at the same time, I think the opposite is true too: it's really easy to cling to backwards compatible way too much. That's the source of most of Windows's biggest problems, for example.
Only the most stubborn git users would say git has a better interface than subversion, which has an excellent one.
That depends on what you consider part of the interface. For example, if you say that the index and git add --interactive (primarily --patch, but the "nice" UI to the index is really good too apart from inventing new terms for the hell of it) is part of "the interface", that alone is useful enough to make up for all of git's other UI deficiencies to my mind. If you demanded that I choose between Subversion as it is today and a modified version of Subversion that had a UI as confusing to learn as Gits but it had the index and interactive adding, I'd pick the latter.
I know some people dislike the index, but to me its one of the star attractions of git. It's not so useful most of the time, but boy, when it is useful it's amazing.
To make me never think of git again, subversion needs:
To that list I would add rebasing support, both branch-style rebasing (as an alternative to merging) as well as rebase --interactive-style rebasing (for cleaning up a WIP to make it presentable).
For git to be better than subversion with those features, it needs a complete redesign.
That... I think depends on whether you prefer front end or back end design.:-) I suspect that either supporting decent offline operation or awesome git-style merging would be a substantial undertaking, while at the same time I suspect you could graft a Mercurial-style UI (which most people say is also really good) onto the Git back end without really changing the back end.
Slashdot Mirror
Yes, that's under reality, where OpenSSL made a bad choice to use an awful custom allocator. But that's not what you were talking about:
And even if they had, there's all these non-OpenBSD servers that are getting hacked and nobody can say if they're hacked or not, so we just get ourselves into this exact situation sooner. We don't come away with smaller collateral damage; EVERY SSL CERTIFICATE EVER ISSUED IS NOW INVALID.
Getting into the same situation and discovering it sooner leads to smaller collateral damage! If this problem had been discovered in 2012 instead of now, it means that any certificates issued in 2013 or 2014 (except from versions left vulnerable) would have been fine in that scenario. Currently, now they're suspect.
Not exactly crypto, but an amusing article on producing a way to compute the entire shuffle of a deck of cards in online poker based on those that were visible: How We Learned To Cheat At Online Poker
Crypto is harder than card shuffling. :-)
Yeah, it's way better to have the potential for both memory and logic errors. Logic errors alone are boring. *eyeroll*
It's not unrelated in the sense that a hardened malloc is specifically designed to help limit damage in the face of vulnerabilities such as the heartbeat one.
No, for two reasons:
1) Theo's main point, about malloc, is that if you disable their custom allocator on any system (or any system that doesn't return a just-freed block in malloc, anyway) then it won't work -- nothing OpenBSD specific at all.
2) Even if you could disable the custom allocator, the crash would only happen in the face of the exploit. So if you don't have a test for the exploit then you wouldn't discover the crash during testing anyway.
The custom allocator matters for two reasons. First, it provides a last layer of defense for OpenBSD users. Second, if the attack was in use in the wild and someone with OpenBSD discovered it, then they could have found it sooner.
It's not a compiler flag, it's code. Also they have some bugs to fix before they can do it. They almost certainly will, and perhaps already have.
You lack imagination. The choice isn't between "traditional dense allocation" and "one page per allocation." I don't know what OpenBSD's allocate does, but it would be entirely possible to make an allocator that is comparably dense to a traditional one but still uses discontinuous pages. Such an allocator would still dramatically limit the amount of data that could be read on a system with such an allocator, because you would be unlikely to be able to overread past the end of the page. You could still get some data, but there'd be a "hard" limit of under 4K (16x less that what's possible) and even under that limit the more you request the more you run the risk of running into the neighboring unmapped page.
I also reject this argument. If that were true, we might as well give up on security. Probably nothing is ever going to be 100% perfect (at least before the singularity). Using a hardened allocator, in many cases, will make attacks more difficult in the sense that you'll be relying on luck in terms of not overrunning the page. (Sometimes you'll hit something that can be done determistically, but I suspect this is not the general case except perhaps where you can leak the seed used for randomization.) Harder attacks means they'll fail more often, and each failure gives a chance of detection and discovery.
I conclude from this you think no SSL certificates were issued between, say, in 2013 or 2014. I'm curious what evidence you have for this. *eyeroll*
You're also ignoring software versions. Suppose that this had been discovered 6mths after the original version was released. Anyone who didn't upgrade during that 6 mths would have been safe. If the discovery of the bug was delayed by a significant margin, that means that many more people became vulnerable.
It's related though, because the use-after-free bug occurs if you enable a configuration that would have somewhat mitigated the heartbeat bug.
OpenBSD's "usual measures" would have helped, because the OpenBSD allocator will often put allocated memory in isolated pages. So it's quite likely that 64K read will cross into an unmapped page, and boom, you have your crash.
This level of overread protection is close to free.
Theo's "rant" isn't brought about by a typical bug in the sense of a mistake in the code. His rant is brought about by the fact that OpenSSL deliberately introduced wrapper functions for malloc/free, making it impossible for a system to provide hardened ones, then made those wrappers default. He further rants about the fact that, because it's default, they later introduced a bug that means you can't turn the wrappers off.
The heartbeat bug itself was a mistake and a bug in the traditional sense. The "hey let's replace malloc/free" is much closer to "bad decision" than "mistake."
I agree with Theo on the broader point, but disagree here: "their product" is the code they wrote with their custom memory allocator. It's not the code they wrote with some changes someone outside the product made. Their custom allocator isn't disabled or enabled depending on configuration checks or something like that, it's always part of the product.
It was still a pretty stupid decision.
My impression is OpenBSD's hardened allocator is relatively common knowledge and definitely should be among people writing security software. And that's not even remotely the only such allocator out there that does that sort of thing too, though it's probably the most well-known from the industrial side.
No no no no no no no. "When users try to reply directly" is a significant problem -- "reply" going to the sender only is fail-safe. "reply" going to the list results in things like "take me off this list" bombs, people accidentally disclosing confidential or embarassing information to the list, etc.
In addition to that, if you have a reply-to-sender mailing list, replying to the list is easy: you just click reply all. (At least that's my default action when replying to an email anyway.) If you have a reply-to-list mailing list and want to reply to just the sender, now neither of your reply buttons work.
I guess they paid for an internship interview trip for me almost a decade ago. No offer.
My take is that the start menu required a "lot" of work to maintain if you actually wanted it to be a useful hierarchy. If you just let stuff install by default and never changed things, then I think it turned into more of an almost-not-hierarchical view of a bunch of crap, personally. It'd be one thing if programs installed an icon or two (or even a submenu) under categories like Games/Productivity/Development/etc. like you get with Linux distros, but that would require cross-vendor cooperation (perhaps enforced by MS); instead you just got programs would install to Start Menu/Programs/My Crappy Company/My Crappy Software/* or, even worse, Start Menu/Programs/My Crappy Software and Start Menu/Programs/Help For My Crappy Software and Start Menu/Programs/Visit My Crappy Website etc.
I hesitate to call that "useful" personally, and it's the main reason that once Vista introduced the search functionality I very rarely actually navigated the start menu itself. On Vista/7 navigating it was actually a lot worse than it was in previous versions IMO because everything got squashed into a very small space as opposed to getting expanded out a bit more; but I was one of those weirdos who used Vista by choice and a lot of that was due to the search feature, because that made up for everything else I saw wrong with it. (I discovered Launchy a bit too late.)
I don't know what to think of 8. Vista/7 got me spoiled with the search feature so that's what I use on 8 (I also use that by choice...), and as a result my day-to-day use is basically identical between 7 and 8, and I basically never use the start screen except via search. I feel like the default program launcher on 8 (what you get when you hit the Windows key/button) requires the same sort of manual maintenance as the start menu "needed", and I haven't bothered to do that. The all programs menu I think works better than the start menu if you left the latter alone. People complain about how the start screen takes over your whole display, but I view that as a virtue -- it means a lot more can be displayed at once and, I think, it's easier to scan. I've also never wanted to see something I had open when I was figuring out what to launch. The down side is that it basically collapses the heirarchy -- but I think that unless you groom the start menu yourself, there's usually very little meaningful hierarchy for it to collapse.
That's my opinion anyway. (And no, I do not and never have had a relationship with MS.)
Eh, it's my current car so it's what I jumped to. My point was mostly that "it's as expensive as a full sized car" is only true for maybe the absolute lowest end of full-sized cars.
My main attraction to the Smart is to make parallel parking in tight spots easy; it's substantially better at that than basically anything else. But it's off the table anyway because I'm only going to have one car, and a substantial portion of my driving is on long trips and I'm not doing that in a Smart. But if I was considering a second car, that's where I'm willing to compromise on many of the things that the Smart isn't as good at.
How did you get so close to the benefit and still miss it? It's not that you can pull into a parallel spot, it's that you can fit into parallel spots that are just flat out too small for larger cars. Learning to drive won't change fact that, say, a 12 foot space will comfortably hold a Smart car (8-9ft long) but not, say, a Civic (15 feet).
I think several points are off. For instance, if I look at new cars on cars.com around me, the cheapest fit is $14,370. If I check out the cheapest Civic, it's $18,980. That's 25% less than an already cheap car. The Smart gets 34/38 mpg; the Civic gets 28/36. The Civic is a manual, the Smart an automatic transmission. (At least in the US, many people would consider a manual a deal-killer.) The Civic is bigger, but it's also far from big, and how big would you really need for a daily commute for instance? And the smaller size has a big benefit for people who do a lot of street parking: imagine being able to fit places where almost no one else can, or having a much easier time getting into tight spots.
The thing is that no car is going to be perfect -- there are always compromises in terms of cost, size, performance, safety, etc. But I think the Smart car fills a niche that would be pretty useful. I was just looking at cars earlier today because there's a hopefully-very-small chance I'll need a new one like, now, and if all I did was drive around town to and from work and errands and stuff, I'd seriously consider getting one.
I didn't mean the second half of that to be so categorical. Saying "but probably not a practical" would have been more accurate.
It's somewhat possible, but not possible to do for general C programs. The CCured project has done something like this, but like I said it isn't fully general even for programs that are technically legal C. Many programs aren't and rely on specific implementations of certain undefined behaviors -- e.g. the Linux kernel needs to disable GCC's optimizations based on the strict aliasing rule, and that would almost certainly break a lot of approaches along the line of CCured.
C is a very poorly behaved language from a formal verification standpoint.
That depends what you mean by multiplatform. If you mean Windows + Linux - WINE, IMO the answer to that is "not even close." It's quite popular for Indie games to release Linux ports now, and that's great don't get me wrong. I'm also really encouraged by not just Steam on Linux but Valve's porting of several of their big-name games over. But even though I'm not a big gamer, there are still way too many omissions to move to Linux as a gaming platform.
Things open up more of course if you start including Mac & consoles in "multiplatform". But at least for me, both of those have far more significant drawbacks than Windows has.
That depends what you're doing of course. A while back I thought I would be creating quite a lot of PowerPoint presentations for a course I was teaching. (That turned out to not be the case both because I was spending a completely-unsustainable amount of time on each lecture and because I got a lot more comfortable with lecturing from a blackboard.) I tried out a couple different options for presentation software, and even though I have a lot of things I don't like about PowerPoint everything else sucked so much more that it was easily worth the price -- and that was true even on a grad student salary. (Keynote seems promising, but I neither have a Mac nor see myself buying one with anything close to Apple's current lineup.)
What if your job is awesome? That's a remarkably stuck up attitude: "I don't like your tools. You should change."
Actually I've been using Windows 8 for a while. I think I'm almost the one person who... is pretty indifferent about the changes overall. Doesn't affect my usage patterns much at all. I ignore the metro desktop and carry on with my life. :-)
I sometimes run Linux and sometimes run Windows. Why? Because it's nice for my OS to piss me off in different ways instead of always the same ways. :-)
Yeah, same here. Later in the day, after they carried it over to Twitter and stuff, I posted the "news" to a chat I was in saying basically "The SVN project is either (1) moving to git or (2) in the mist of an incredibly committed April Fool's day joke, and I honestly can't tell which it is."
A lot of other sites had nice gags for the 1st, but this was the only one I saw that could legitimately earn the "April Fools" label.
Turns on it's the latter. From the issue thread:
Resolving as "Not a problem". We sure as hell don't want to do this. :-)
My major thanks to [~jfarrell] for the concept.
And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse :-) ⦠the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagons⦠Thank you all for making this work!!!
I agree... but at the same time, I think the opposite is true too: it's really easy to cling to backwards compatible way too much. That's the source of most of Windows's biggest problems, for example.
That depends on what you consider part of the interface. For example, if you say that the index and git add --interactive (primarily --patch, but the "nice" UI to the index is really good too apart from inventing new terms for the hell of it) is part of "the interface", that alone is useful enough to make up for all of git's other UI deficiencies to my mind. If you demanded that I choose between Subversion as it is today and a modified version of Subversion that had a UI as confusing to learn as Gits but it had the index and interactive adding, I'd pick the latter.
I know some people dislike the index, but to me its one of the star attractions of git. It's not so useful most of the time, but boy, when it is useful it's amazing.
To that list I would add rebasing support, both branch-style rebasing (as an alternative to merging) as well as rebase --interactive-style rebasing (for cleaning up a WIP to make it presentable).
That... I think depends on whether you prefer front end or back end design. :-) I suspect that either supporting decent offline operation or awesome git-style merging would be a substantial undertaking, while at the same time I suspect you could graft a Mercurial-style UI (which most people say is also really good) onto the Git back end without really changing the back end.