Um, UNCOMPRESSED MPEG-2? Why do people choose to let the entire Universe know what morons they are by typing in such utterly stupid statements as that?
I bet he also has a collection of uncompressed MP3s.
I don't think you'll do any better than StarTeam (now sold via Borland). What is particularly good about StarTeam is that is was born and grew up on Windows, with Unix ports coming later. It feels and acts (for the most part) like a Windows application should -- which can hardly be said about creatures such as ClearCase and MKS.
There is a nice API to extend it to do new, nifty things. It has bug tracking. It has threaded discussion (which can be associated with items in the repository). You can reach it with a rich Win32 interface, with a web interface, with a java client, with the command line, etc. It can even tie into Explorer so that the entire repository can be mounted as a drive letter.
Visual Studio integration is rock solid and acts just like a VSS person would expect (minus the VSS bugs) -- which I cannot say about Jalindi Igloo (you get what you pay for). There are also intergrations for a number of other tools.
When they were their own company (StarBase), support was fantastic. I dunno if that changed under Borland. Also, in the StarBase days, they really did listen to users. If you made a reasonable case for a new feature, it usually made it into a future release.
On the Free and free side of the world, CVS on Windows using, say, cvsnt and WinCVS is not a bad combination, but once you've had a taste of a great tool like StarTeam, cvs leaves a LOT to be desired.
Right now, I am personally using cvsnt + WinCVS as budgets are tight, but StarTeam is on my short list of future capital expenditures.
HDTV pixels are square, and NTSC pixels are not. Perhaps the viewing software was adjusting for rectangular pixels when it should not have been.
SOAP runs over a lot of things
on
.NET or CORBA?
·
· Score: 1
SOAP runs over HTTP
It's okay to make that statement, provided we are all clear that what you hopefully really meant was that SOAP messages can be exchanged via HTTP bindings (both GET and POST). Likewise, SOAP messages can be exchanged via SMTP bindings. And pretty much any other protocol for which a protocol binding is defined.
It simply worries me that far too many developers believe that SOAP is deeply connected to HTTP.
Now, back to the original poster's question. I'm not sure what.NET has got to do with remoting of anything -- perhaps he was really asking about, well, '.NET Remoting,' the.NET standard for RPC. And even that is a misleading statement, for.NET Remoting can be bound to any of several protocols -- SOAP, Microsoft's BinaryFormatter, COBRA, DCOM, etc. etc. -- and each channel can have a unique set of attributes (e.g. encryption, authentication, etc.) -- and these attributes have their own properties (authenticate connection or autenticate every packet, etc. etc.). Personally, I like.NET remoting because it is very easy to write a client, and, via an XML config file, change the communication channel without recompiling. And making a client is pretty much as easy as using a local object. For example, in this fragment:
Foo myFoo = new Foo(); Foo.DoSomething();
it is impossible to tell from this fragment if Foo is a local object or if Foo is actually running half-way across the planet..NET makes it fairly easy to map types (in this case, the class Foo) to remoted instances. How the remote instance is found can be controlled via an XML config file. So if I suddenly want to run Foo on machine X, I change the config file. (Granted, the process needs to be singaled to reread the config file, or it needs to be restarted.) As someone who lived through the nightmares of DCOM and it's 'interesting' security models with those oh-so-helpful C0000005 error messages,.NET Remoting is a real joy.
Oh, and I've also been through RMI, and, just my $0.02,.NET Remoting is a lot easier to get up-and-running. I won't comment on COBRA, as my experiences with COBRA ended about 5 years ago, and people keep telling me that it's much better these days...
Since you can't cause a buffer overrun/overflow in something like Java or.NET, maybe that's a good choice to write stuff in.
Or maybe not - someone will find a way to exploit those and anything alse that catches on.
I think you are missing an important point. There is a big difference between exploitation and honest mistakes. The CVS bug is just that -- an unintentional bug. The (debatable, but I agree with) advantage of languages such as Java and C# is that make it much harder for us mere mortals to accidentally introduce system-level bugs into our code. I ran FAR FAR away from C/C++ when Java became a reasonable alternative, because I saw countless incidents of crash bugs caused by mismatched malloc/free or new/delete.
Now, I'm certainly not recommending that anyone go and write an OS kernel in Java. While it would likely be a 'safer' kernel for a particular group of common bugs, it would also likely be dog slow. But, I'm amazed at what people pull off with VM-based languages everyday, so, who knows? I remember the sick guy back in college 12 years ago who seriously considered writting an OS in ML (ML the langauge, not machine language) because it would be so safe and easier to prove correct.
Back on topic, I think we'd be hard-pressed to find a CVS server that is taking such enormous load that it couldn't be implemented in Java or C# and perform perfectly well. Look at what people have done with resin -- a J2EE app server written in Java -- as reported on/.
Mind you, I'm not volunteering for the port -- won't pay the bills and all that -- but I wish I had the time to do it.
While I always hate to see soem "bad guy" get off on a technicality, here's a case where one of the good guys squeaked by for similar reasons.
The key to winning the case was that Pavlovich did not know that DVD CCA is based out of California (until after they sued him), and because he did not know this, certain legal tests fail, and he cannot be pursued as the suit was filed.
Yes, there were many other deep, legal issues, but thisone appears to be the main reason.
Maybe he learned something from Bill Gates, who did a fabulous job during this legal battles to convince the judge that he could not remember a single thing. What lessons are our higher courts teaching us?! I thought learning from the past was a good thing, but apparently forgetting the past is much safer.
I recently departed a high-level position at a commerical search software company. I can tell you that it was not very common for OSS search engines to be part of the final round of competitors, and, when OOS did make it into the (say) top-3, it RARELY won. In fact, I can only recall one time that OSS "won" the deal, and this was with a company with a legion of developers sitting in Israel just looking for something to do at dirt-cheap prices.
No one should take this as an attack on OSS in general -- the posting was specifically about search engines, and I'm replying with specific knowledge in that space.
At while I use my "free time" to work on my next great application, I have been actively consulting to people deploying search solutions, both commerical and OSS. So, yes, there are people out their supporting OSS on a contractual basis (duh), but specifically 'yes' with respect to search engines.
Slashdot Mirror
True, but they are not the same query (different terms in a different order). Note that
"motherboard" +K8NNXP +review
and
motherboard K8NNXP review
do give the same results.
Um, UNCOMPRESSED MPEG-2? Why do people choose to let the entire Universe know what morons they are by typing in such utterly stupid statements as that?
I bet he also has a collection of uncompressed MP3s.
I don't think you'll do any better than StarTeam (now sold via Borland). What is particularly good about StarTeam is that is was born and grew up on Windows, with Unix ports coming later. It feels and acts (for the most part) like a Windows application should -- which can hardly be said about creatures such as ClearCase and MKS.
There is a nice API to extend it to do new, nifty things. It has bug tracking. It has threaded discussion (which can be associated with items in the repository). You can reach it with a rich Win32 interface, with a web interface, with a java client, with the command line, etc. It can even tie into Explorer so that the entire repository can be mounted as a drive letter.
Visual Studio integration is rock solid and acts just like a VSS person would expect (minus the VSS bugs) -- which I cannot say about Jalindi Igloo (you get what you pay for). There are also intergrations for a number of other tools.
When they were their own company (StarBase), support was fantastic. I dunno if that changed under Borland. Also, in the StarBase days, they really did listen to users. If you made a reasonable case for a new feature, it usually made it into a future release.
On the Free and free side of the world, CVS on Windows using, say, cvsnt and WinCVS is not a bad combination, but once you've had a taste of a great tool like StarTeam, cvs leaves a LOT to be desired.
Right now, I am personally using cvsnt + WinCVS as budgets are tight, but StarTeam is on my short list of future capital expenditures.
HDTV pixels are square, and NTSC pixels are not. Perhaps the viewing software was adjusting for rectangular pixels when it should not have been.
SOAP runs over HTTP
It's okay to make that statement, provided we are all clear that what you hopefully really meant was that SOAP messages can be exchanged via HTTP bindings (both GET and POST). Likewise, SOAP messages can be exchanged via SMTP bindings. And pretty much any other protocol for which a protocol binding is defined.
It simply worries me that far too many developers believe that SOAP is deeply connected to HTTP.
Now, back to the original poster's question. I'm not sure what .NET has got to do with remoting of anything -- perhaps he was really asking about, well, '.NET Remoting,' the .NET standard for RPC. And even that is a misleading statement, for .NET Remoting can be bound to any of several protocols -- SOAP, Microsoft's BinaryFormatter, COBRA, DCOM, etc. etc. -- and each channel can have a unique set of attributes (e.g. encryption, authentication, etc.) -- and these attributes have their own properties (authenticate connection or autenticate every packet, etc. etc.). Personally, I like .NET remoting because it is very easy to write a client, and, via an XML config file, change the communication channel without recompiling. And making a client is pretty much as easy as using a local object. For example, in this fragment:
it is impossible to tell from this fragment if Foo is a local object or if Foo is actually running half-way across the planet. .NET makes it fairly easy to map types (in this case, the class Foo) to remoted instances. How the remote instance is found can be controlled via an XML config file. So if I suddenly want to run Foo on machine X, I change the config file. (Granted, the process needs to be singaled to reread the config file, or it needs to be restarted.) As someone who lived through the nightmares of DCOM and it's 'interesting' security models with those oh-so-helpful C0000005 error messages, .NET Remoting is a real joy.
Oh, and I've also been through RMI, and, just my $0.02, .NET Remoting is a lot easier to get up-and-running. I won't comment on COBRA, as my experiences with COBRA ended about 5 years ago, and people keep telling me that it's much better these days...
Since you can't cause a buffer overrun/overflow in something like Java or .NET, maybe that's a good choice to write stuff in.
Or maybe not - someone will find a way to exploit those and anything alse that catches on.
I think you are missing an important point. There is a big difference between exploitation and honest mistakes. The CVS bug is just that -- an unintentional bug. The (debatable, but I agree with) advantage of languages such as Java and C# is that make it much harder for us mere mortals to accidentally introduce system-level bugs into our code. I ran FAR FAR away from C/C++ when Java became a reasonable alternative, because I saw countless incidents of crash bugs caused by mismatched malloc/free or new/delete.
Now, I'm certainly not recommending that anyone go and write an OS kernel in Java. While it would likely be a 'safer' kernel for a particular group of common bugs, it would also likely be dog slow. But, I'm amazed at what people pull off with VM-based languages everyday, so, who knows? I remember the sick guy back in college 12 years ago who seriously considered writting an OS in ML (ML the langauge, not machine language) because it would be so safe and easier to prove correct.
Back on topic, I think we'd be hard-pressed to find a CVS server that is taking such enormous load that it couldn't be implemented in Java or C# and perform perfectly well. Look at what people have done with resin -- a J2EE app server written in Java -- as reported on /.
Mind you, I'm not volunteering for the port -- won't pay the bills and all that -- but I wish I had the time to do it.
While I always hate to see soem "bad guy" get off on a technicality, here's a case where one of the good guys squeaked by for similar reasons.
The key to winning the case was that Pavlovich did not know that DVD CCA is based out of California (until after they sued him), and because he did not know this, certain legal tests fail, and he cannot be pursued as the suit was filed.
Yes, there were many other deep, legal issues, but thisone appears to be the main reason.
Maybe he learned something from Bill Gates, who did a fabulous job during this legal battles to convince the judge that he could not remember a single thing. What lessons are our higher courts teaching us?! I thought learning from the past was a good thing, but apparently forgetting the past is much safer.
I recently departed a high-level position at a commerical search software company. I can tell you that it was not very common for OSS search engines to be part of the final round of competitors, and, when OOS did make it into the (say) top-3, it RARELY won. In fact, I can only recall one time that OSS "won" the deal, and this was with a company with a legion of developers sitting in Israel just looking for something to do at dirt-cheap prices.
No one should take this as an attack on OSS in general -- the posting was specifically about search engines, and I'm replying with specific knowledge in that space.
At while I use my "free time" to work on my next great application, I have been actively consulting to people deploying search solutions, both commerical and OSS. So, yes, there are people out their supporting OSS on a contractual basis (duh), but specifically 'yes' with respect to search engines.