Of course, if Microsoft has patents on any of this, it's likely that Real is out of luck even if they did a complete "clean room" implementation of the software.
This past Saturday seemed to be all the "plot" episodes, touching on Spike, Vicious, and the syndicate, from the first episode, to "Ganymede Elegy", to the last two episodes.
Next weekend is supposed to be "fan favorites"; don't know if that's going to be the same or not.
If they wanted slower, sustainable growth and not an overvalued stock price, maybe they should have thought twice about all of that earnings management over the last few years. They've had a number of run-ins with the SEC on that score, each culminating in a gentleman's agreement "just don't do it again, OK?".
The stock price may be overvalued now, but it's mostly because Microsoft wanted it that way for the past few years.
Incidentally, I recall that the first time Ballmer made that comment, he kicked off a mini-slump in the stock price. Maybe he has a well-hidden short in their stock somewhere:)
Scrambling right before the build is a process problem, not a ClearCASE problem. Put all your bug fixes on branches, and only allow the CM team to merge in fixes to the project mainline. Developers are responsible for notifying the CM team (through email or some bug tracking tool) that their branch is "ready to go". Official builds are only done in the one official CM view. Really, the view shouldn't be an issue at all; every build view's config spec should just be the previous build's label (you are labeling every build that you release, right?) plus the fixes for this new build. Your total time to do a build is just the time to have a meeting and agree which bug fixes you're picking up, the time to do a (mostly-automated) merge of all the branches to the project mainline, the time to actually run the build, and maybe some verification at the end before you release it. Oh, and writing release notes, which can be pretty much automated as well. ClearCASE is built for scriptability and automation; learn to use it and it will save you so much time and help avoid so many simple errors.
ClearCASE can be seriously screwed up by bad admins; five admins for 50 coders indicates to me that at least four of your admins didn't know what they were doing:) One admin, part time, should be good for 100-200 developers, unless you're expecting that developer to also be developing extra "gravy" like reports and ClearCASE trigger scripts.
I'll agree with that - after a few months stuck using Visual Basic, I found that it was very difficult to move back to real programming exactly because I was used to the crutch of hitting TAB to fill out the property name or using '.' to find out the available properties. I had to train myself to attain my old level of API knowledge, and get my fingers to quit doing TAB.
And no, I didn't find that "Intellisense" really made me that much more productive; I still had to look up what the API did, otherwise I'd just use things in ways they weren't supposed to be. Although the tab-completion does explain why Windows-oriented source code is so damn wordy all the time.
No, read again. If you want to remove an element for good, revision history and all, use "cleartool rmelem". If you just want to not see the element in this directory any more, checkout the directory and do "cleartool rmname". You can then easily restore the missing file from an older version of the directory if you ever decide you want it back. You almost never need to do rmelem; in four years as a ClearCASE user and admin I've only completely removed a file once.
ClearCASE doesn't always document exactly all the things you can do with directory versioning, which is a bit of a downside (from what I hear, a lot of people even with Rational don't completely understand directory merging, etc.). But once you get a couple rules of thumb straight, this particular problem is not much of an issue.
Hmmm, so half the people commenting on this article want better and more powerful tools, but the other half are afraid to learn to use better and more powerful tools?
I read this every time ClearCASE comes up here, and I still don't agree with this viewpoint. ClearCASE is easy to use from the GUI; anybody can sit down, check out a file or make a branch, and get to work with no problems. Sure, there's extra power under the hood for the admin to tinker with; that's the extensibility that makes people recommend ClearCASE in the first place, rather than just using a GUI slapped on top of CVS. The ClearCASE GUI isn't perfect, but it's as easy as or easier to use than the other GUIs that I've tried, including VSS (what a dog that was).
The reason that the only people commenting about ClearCASE's good points are ClearCASE specialists/admins (yes, me too) is because your average ClearCASE user isn't an admin, and also frankly doesn't care enough about version control to be posting about it on/.:)
But your target platform has nothing to do with your development tools in this case; the version control system just sits on a box in the closet, it's not like you also have to be able to test on it or write pretty management reports or whatever. For example, with many of these systems you could use a Windows client but still have a BSD server, etc.
Some ClearCASE changes to a file's attributes are version controlled through the containing directory - like the file's name. Unfortunately, the permissions themselves are not controlled in this way, nor is the user or group ownership information. Directory versioning would be the logical place to do this kind of version control, though.
ClearCASE works this way as well; you can get the revision history for any branch, version, or file/directory element, and you can have triggers that force people to enter meaningful revision history comments. Of course, you have to define "meaningful":)
Well, if it met the accepted standards of other source code control systems (free or cheap, portable to almost any platform, and possibly with source code available) then we'll take a look at it. Microsoft seems to have some problems meeting those requirements based on past experience, though, so I wouldn't hold my breath.
It's not that we don't like Microsoft; it's more like Microsoft doesn't like the rest of the computing world that's not Microsoft.
Sure, but on the other hand, if a problem is found, everybody just upgrades their BEEPlib or BEEP stack and moves on. Versus the current situation, where we have to fix essentially the same type of buffer overflow in each application that implements HTTP, or FTP, or SMTP, or DNS, etc.
The BEEP writeup did describe some sort of optional "pluggable" security system, so you could enable security features if you wanted them, or leave them off for performance reasons. I like the idea of a protocol framework where you can then enable or disable the bells and whistles of the protocol at will. Although it remains to be seen whether that level of control can really triumph over the XML-ness of BEEP:)
The problem is that our legislators are happy to give away our freedom. You can bet that they don't intend any of these laws to actually apply to themselves; it would be an outrage!
Triggers - must be able to specify a script to run when certain events happen, like checkin, checkout, add label, etc. Triggers should also be able to prevent an action from occurring if the trigger script decides that a condition has not been met.
Multi-site - the system must be set up so that developers at multiple sites around the world can collaborate on the same sources fairly easily. This is more of an enterprise feature, I would think.
Securable - at least make it tunnelable over SSH or something like that, at a minimum.
Transparency - must be able to dig out all of the details about the system and the files and versions contained in it automatically from the command line or some API, so that the system can be analyzed and manipulated by automated tools for metrics reporting, etc.
Here's a good question that you raised - is a three-way graphical merge really the best way to do a complex merge? I've done a lot of them and it mostly works, but at times it still seems like a sub-optimal solution. Does anyone else have a better system for complex merges that they do?
ClearCASE rocks in terms of scriptability, built-in triggers, etc. Also I much prefer branching individual files and using views, to the typical Open Source CM scheme of having separate trees. Too bad that the ClearCASE *nix GUI has gotten progressively worse for two major releases since their high-water mark (IMHO), ClearCASE 2.1. They've never fixed the problem where sometimes you click to select a version and it looks selected but isn't really, and in many cases have introduced GUI bugs, made the whole thing slower by using a special "properties browser", etc. I have a bunch of hacks in ~/.grp to get it customized back to the way that it used to work so that it's even halfway usable.
Slashdot Mirror
Of course, if Microsoft has patents on any of this, it's likely that Real is out of luck even if they did a complete "clean room" implementation of the software.
That's a pretty accurate description, but that's what the ladies like, so who am I to complain?
Congratulations, you have provided me with new bio information. If we'd had this conversation on k5, I think I'd have a new .sig too :)
I sincerely doubt that he said "yow". Unless Himmler really is Zippy the Pinhead :)
This past Saturday seemed to be all the "plot" episodes, touching on Spike, Vicious, and the syndicate, from the first episode, to "Ganymede Elegy", to the last two episodes.
Next weekend is supposed to be "fan favorites"; don't know if that's going to be the same or not.
"See you sometime, somewhere space cowgirl!"
And, last night (final episode, yay I finally caught it!): "You're Gonna Carry That Weight".
You haven't read Doom until you've read it in the original Klingon :)
Double the estimate, and move to the next higher unit of time measurement.
"Could take weeks, sir!"
I don't get it - Forbes usually has very good grammar and spelling. There's no way they're getting anything from /. :)
If they wanted slower, sustainable growth and not an overvalued stock price, maybe they should have thought twice about all of that earnings management over the last few years. They've had a number of run-ins with the SEC on that score, each culminating in a gentleman's agreement "just don't do it again, OK?".
The stock price may be overvalued now, but it's mostly because Microsoft wanted it that way for the past few years.
Incidentally, I recall that the first time Ballmer made that comment, he kicked off a mini-slump in the stock price. Maybe he has a well-hidden short in their stock somewhere :)
It's amazing how many people replied to your post without any trace of a sense of humor. /. is truly inhabited by some stupid, stupid people.
Very true - it is not a good fit for the typical open source project, but that's not the assertion that I'm arguing against :)
Scrambling right before the build is a process problem, not a ClearCASE problem. Put all your bug fixes on branches, and only allow the CM team to merge in fixes to the project mainline. Developers are responsible for notifying the CM team (through email or some bug tracking tool) that their branch is "ready to go". Official builds are only done in the one official CM view. Really, the view shouldn't be an issue at all; every build view's config spec should just be the previous build's label (you are labeling every build that you release, right?) plus the fixes for this new build. Your total time to do a build is just the time to have a meeting and agree which bug fixes you're picking up, the time to do a (mostly-automated) merge of all the branches to the project mainline, the time to actually run the build, and maybe some verification at the end before you release it. Oh, and writing release notes, which can be pretty much automated as well. ClearCASE is built for scriptability and automation; learn to use it and it will save you so much time and help avoid so many simple errors.
ClearCASE can be seriously screwed up by bad admins; five admins for 50 coders indicates to me that at least four of your admins didn't know what they were doing :) One admin, part time, should be good for 100-200 developers, unless you're expecting that developer to also be developing extra "gravy" like reports and ClearCASE trigger scripts.
I'll agree with that - after a few months stuck using Visual Basic, I found that it was very difficult to move back to real programming exactly because I was used to the crutch of hitting TAB to fill out the property name or using '.' to find out the available properties. I had to train myself to attain my old level of API knowledge, and get my fingers to quit doing TAB.
And no, I didn't find that "Intellisense" really made me that much more productive; I still had to look up what the API did, otherwise I'd just use things in ways they weren't supposed to be. Although the tab-completion does explain why Windows-oriented source code is so damn wordy all the time.
No, read again. If you want to remove an element for good, revision history and all, use "cleartool rmelem". If you just want to not see the element in this directory any more, checkout the directory and do "cleartool rmname". You can then easily restore the missing file from an older version of the directory if you ever decide you want it back. You almost never need to do rmelem; in four years as a ClearCASE user and admin I've only completely removed a file once.
ClearCASE doesn't always document exactly all the things you can do with directory versioning, which is a bit of a downside (from what I hear, a lot of people even with Rational don't completely understand directory merging, etc.). But once you get a couple rules of thumb straight, this particular problem is not much of an issue.
Hmmm, so half the people commenting on this article want better and more powerful tools, but the other half are afraid to learn to use better and more powerful tools?
I read this every time ClearCASE comes up here, and I still don't agree with this viewpoint. ClearCASE is easy to use from the GUI; anybody can sit down, check out a file or make a branch, and get to work with no problems. Sure, there's extra power under the hood for the admin to tinker with; that's the extensibility that makes people recommend ClearCASE in the first place, rather than just using a GUI slapped on top of CVS. The ClearCASE GUI isn't perfect, but it's as easy as or easier to use than the other GUIs that I've tried, including VSS (what a dog that was).
The reason that the only people commenting about ClearCASE's good points are ClearCASE specialists/admins (yes, me too) is because your average ClearCASE user isn't an admin, and also frankly doesn't care enough about version control to be posting about it on /. :)
But your target platform has nothing to do with your development tools in this case; the version control system just sits on a box in the closet, it's not like you also have to be able to test on it or write pretty management reports or whatever. For example, with many of these systems you could use a Windows client but still have a BSD server, etc.
Sorry to hear about your management, anyway.
Some ClearCASE changes to a file's attributes are version controlled through the containing directory - like the file's name. Unfortunately, the permissions themselves are not controlled in this way, nor is the user or group ownership information. Directory versioning would be the logical place to do this kind of version control, though.
ClearCASE works this way as well; you can get the revision history for any branch, version, or file/directory element, and you can have triggers that force people to enter meaningful revision history comments. Of course, you have to define "meaningful" :)
Well, if it met the accepted standards of other source code control systems (free or cheap, portable to almost any platform, and possibly with source code available) then we'll take a look at it. Microsoft seems to have some problems meeting those requirements based on past experience, though, so I wouldn't hold my breath.
It's not that we don't like Microsoft; it's more like Microsoft doesn't like the rest of the computing world that's not Microsoft.
We're so far behind the curve - we've just managed to upgrade to CC 4 around here :) Maybe in a year we'll be at that exalted level.
Sure, but on the other hand, if a problem is found, everybody just upgrades their BEEPlib or BEEP stack and moves on. Versus the current situation, where we have to fix essentially the same type of buffer overflow in each application that implements HTTP, or FTP, or SMTP, or DNS, etc.
The BEEP writeup did describe some sort of optional "pluggable" security system, so you could enable security features if you wanted them, or leave them off for performance reasons. I like the idea of a protocol framework where you can then enable or disable the bells and whistles of the protocol at will. Although it remains to be seen whether that level of control can really triumph over the XML-ness of BEEP :)
Sounds like someone needs to watch some more Schoolhouse Rock :)
Oh, I'm just a bill, yes I'm only a bill, and I'm sitting here on Capitol Hill...
The problem is that our legislators are happy to give away our freedom. You can bet that they don't intend any of these laws to actually apply to themselves; it would be an outrage!
I'll add a couple things:
Here's a good question that you raised - is a three-way graphical merge really the best way to do a complex merge? I've done a lot of them and it mostly works, but at times it still seems like a sub-optimal solution. Does anyone else have a better system for complex merges that they do?
ClearCASE rocks in terms of scriptability, built-in triggers, etc. Also I much prefer branching individual files and using views, to the typical Open Source CM scheme of having separate trees. Too bad that the ClearCASE *nix GUI has gotten progressively worse for two major releases since their high-water mark (IMHO), ClearCASE 2.1. They've never fixed the problem where sometimes you click to select a version and it looks selected but isn't really, and in many cases have introduced GUI bugs, made the whole thing slower by using a special "properties browser", etc. I have a bunch of hacks in ~/.grp to get it customized back to the way that it used to work so that it's even halfway usable.