For small (less than 200.000 lines of code) projects it's pretty good. You should know the limits like the size of the database shouldn't exceed 1GB, but overall the tool works seemlessly. Here we have over 20 projects in several databases and haven't found any problem with it since we started using it back in 1999. (Yes we check for errors;) ). For the small price-tag it has, it has a lot of features and a nice gui, which supports visual conflict resolving, drag/drop sharing/branching etc.
You shouldn't use it for large projects. So when people still use it for large projects, it can be cumbersome and slow.
So your 'it's a total piece of shit' is way off base, or you're one of these people who cram 1.5 million lines projects in Sourcesafe and then start complaining.
Reading this and putting the 'vision' (if you can call it that) of the USA's government in perspective, you start to wonder why the USA still are calling themselves "Leader of the Free World". Must be a different definition of 'Free' than I have...
How can a hotfix break a tool? There is just 1 reason why: because the tool ASSUMES undocumented behaviour which is gone with the hotfix (f.e. it patches something and the behaviour isn't there anymore). No hotfix will replace COM ID's with new ones or change interfaces, they just update dlls with new versions. I don't see how a good application can be broken by patching an OS part with a version that has the same interface and behaves as documented.
(and no, undocumented crap is not needed for developing software)
If a hotfix breaks an app, kick the developer.
on
Happy Birthday Code Red
·
· Score: 4, Interesting
Hotfixes don't kill webapps. I develop webapplications (the n-tier stuff, VC++/VB/ASP/IIS/SQLServer etc) for over 5 years now and have applied a zillion or so hotfixes on IIS and NT / Win2k server to keep the systems up to date, but never ever have I encountered 1 single hotfix which killed a webapplication nor did I hear from collegues that hotfixes killed their webapplications. If the webapp is written solidly, by the guidelines MS has supplied, you can apply any hotfix, period.
When your developers are not that educated however, perhaps they use dirty tricks which will break when a hotfix is applied (allthough I doubt it, hotfixes mostly overwrite existing files without updating CLS_ID's etc, because these stay the same) and the app will die after the hotfix is applied: one reason to kick them out the door for some real professionals.
... but testboxes or homeusers with an IIS installation on their win2k pro or win2k server OS they used. This is noticable by the fact that most attacks were and are originating from cable-internet connected boxes.
Most IIS admins who are responsible for webservers who run company websites did patch IIS long before the worm started or better: did like MS told them to do: disable all extensions not used on the box, like htr and ida. (Oh, and removed the examples)
Ok, some company-used webservers were exploited, but this number is not a majority by far.
In the real universe, it's M$loth's excuse to port the.exe PE file format to other platforms, with 2 reference implementations' sources available so they can get let off by the DoJ.
What's 'M$loth' ? And what does the DoJ crap has to do with the quality of.NET? Nothing. Still you find it useful to flame the living crap out of it. Which was my point exactly.
There's also nothing new under the sun. Running other language environments ("hosting", my ass) has been done ever since emacs was written in lisp running on a C-based machine.
Fyi: Lisp is interpreted, C# and the other 20 or so languages for.NET are not.
Looking at most of the postings here, allthough most of them are posted by non-developers and brainless collegekids, I can only think: what a sad bunch of people..NET is one hell of a platform with a very well thought out API, documentation and complete functionality. Now there is this Linux developer and his team at Ximian who ports that platform to Linux and all the fools at/. are able to do is cry out what a crap.NET is, how Miquel is a slave of MS, oh sorry, M$, and that Mono will suck as.NET already does.
*RRRRT*
If Mono fails on Linux, Linux is dead. Be aware of that.
That's the reason why servers go down and planes do not (well.. most of the time): people expect that the server they get for 3000$ will run a corporate mission critical system for years without a crash. Planes costs millions, are tested on hardware every time they're used, servers are not. Do you test your server's hardware every week? (or day?).
The question is, what does this mean for Linux -- how will Microsoft exercise their "rights"? Like they always do with patents: only force them when someone squeeses MS' thumbs for a couple of bucks. MS patents a lot of technology, but not for money, but for the possibility to KEEP using the technology without having to pay a huge amount of money or worse: having to battle in court.
This is not an imaginary thing: Rotor, the shared source.NET implementation released by MS and Corel to run on Windows and FreeBSD is ported to Linux not long ago. But I doubt they will show that off on their booth:)
This morning windows updater had already downloaded the patches, all I had to do was confirm the installation.
People can whine all they want about that there are security flaws and ofcourse it's sad these still pop up, but the patches are there, the system to install them is VERY easy (just click one single button) so in the end, the end-user is not that much hurt by them, simply because the patches are installed so easily.
The discussions about 'security flaw free' software are endless and allthough they should be held, are nowhere near consensus: as long as there are humans involved in hammering out code and as long as the computer/software based checkinglogic is not up to par as where it should be, these flaws WILL be there, possibly in every tool written by man. Until computer science reaches the point where a compiler can proof that software is security flaw free, we should be grateful that the FIXES for security flaws are installed using the most easiest way: by simply clicking one single button.
.HTR is a flawed protocol and should be avoided. No sane developer will use.HTR pages in his site on an IIS machine, since the.HTR parser is crappier than crap since day one with buffer overruns all over the place. Most sysadmins have.HTR disabled anyway, since it's of no use. When there is a bug in that parser, thus _NOT IN IIS!_ but in an extension (like mod_perl to apache), and that parser is not used by a lot of people, would you put a lot of developers on that bug? No.
The recommended way has always been: trusted connections, at least since 7.0. (which is pretty old by now). The 6.5 legacy from sybase had a different policy due to the lack of good integration with NT security.
So the SA account is never needed: connect using trusted connections.
Examples most of the time mention 'sa' with no password, but that are examples, what way should they then mention a connection string?
Most tools/software on the server itself connect via named pipes local on the system anyway. So these tools will not have a lot of problems. Most SQLServer's exposed on the internet are installed on systems which also run IIS, thus 1 server for the complete stack of servers for a webapplication. Having this port open is not needed.
Start the server network utility and change the port on the TCP/IP protocol. Click OK and restart the MSSQLSERVER service.
btw, Oracle is superior in which way? Oracle has also a 'default' password: empty or a default well known password.. it doesn't matter. People simply should understand what they put online.
When I start a little tool on my online SQLServer machine I get 4 servers listed which run on the same network segment as my server (in the co-located rack at my ISP). a) these servers are running the server service, which shouldn't be running, b) these servers have port 1433 open and c) have set their server to not hide it for the outside world.
Pretty basic stuff that should be switched off, but isn't because the admins probably don't know that it's necessary to switch it off or even how to do that.
Let me get this straight: - It's totally free - They provide a huge pile of hardware, software and people to keep up the site and datastores. - They don't want money in return - Everything but the sun costs money
So you people think that MS is a philantropic organisation? ALWAYS ask yourself when something is 'free' and the provider of the service has to spent a lot of money to give you this service for 'free': "Where's the catch?". I find this moaning about Hotmail rather silly, if you ask me. If you don't like it, get a real ISP account. Yes that costs money, start wondering where that money's for.
... afaik, the patent is about customisation in tabbed windows, thus customize your tabs. VS.net has that too. I'm sure MS will come up with 'but these are 'dockable windows' instead of tabs', but it could be fun to see some jury of non-geeks break their minds on that case:)
Btw, Macromedia isn't that small, they bought a lot of companies in the last couple of years and hold a strong marketshare in the webdesign market, where Adobe is, except for photoshop, a smaller player.
"...but is it right to take a good product away from so many people who really do like it just because another company's product isn't taking over the market like they hoped it would?" Suddenly, 'Internet Explorer' comes to mind, looking from an average Joe Windowsuser POV.
Up till a few months ago I ran Winroute Pro, a firewall, and everytime I booted the win2k server it was installed on (I boot the machine every morning, it's my development box also and I don't need a server running at night, so why burn the electricity?) I saw in the log of Winroute Pro the Win2k server wanted to send out DNS records to the root servers. This is only done at boottime though afaik, since I didn't find this activities again in the logs, until the next boot.
Buffer overflows... these are implementation-specific bugs and should be easily patchable. However, MS put a lot of functionality into IE (for the most part because it's bundled) and when you look at the separate parts of all this functionality, you don't see exploitable stuff. However, combining parts of the functionality CAN LEAD to a situation that wasn't forseen, and perhaps will lead to a vulnerability.
It's easy to say "Crap!" but it takes a wicked mind to combine the right parts of the functionality of a program to create a hole, a mindset which is obviously not present under the IE designers. (but which should be though).
As a true microsoftie I more and more begin to realize that the bundling should be undone, so the set of functionality build into the webbrowser is simply focussed on what it should do: rendering pages.
Using another browser is not the answer however. The only browser that comes close to IE6 is Netscape/Mozilla, however these browsers are also packed with features you'll probably never need but CAN probably be used to create a hole when combined with other functionality in the program.
I'm a Microsoft-product-user, sue me, and IIS' design is IMHO ok, however if I could switch this minute, why wouldn't I? Well... I can't run an ASP.NET application on Apache. (shouldn't be that hard to implement however, the ASP.NET runtime is a separate process) So there is no WAY I can switch to apache.
'same performance, better security'... Hot air to me, sorry. 'Same performance', I have to see that first, and 'better security'... people who have locked down their IIS webservers the way it should be and the way Unix admins do normally, don't have to worry. Sure, you have to patch the webserver sometimes. Like you have to patch other software as well. Don't kid yourself with the idea that Apache is 'total secure'. You don't have proof of that.
What's the big deal? VI rocked back in the days when 80x24 amber/green monitors / terminals were the thing to use, but today editors which are SMART are way more productive, since they let the developer focus on the job that has to be done, instead of looking up information that should be available at the fingertips. Any editor without intellisense-like functionality is a waste of time. Seriously.
Not to sound like a troll or anything, I used VI for years, but this is 2002, the year in which we can buy a tiny mobile phone which can be used to watch a movie on it or browse websites, so using an ascii based editor that hasn't any tricks up its sleeve besides coloring keywords is IMHO kidding yourself with irrelevant reasons like "the new stuff is not worth it, this is more productive" etc.
(NOTE: The uni I graduated was a 100% unix shop, I developed on Unix for years, now I'm a 100% windows/.net developer, I know both sides)
A general rule: MS-targeting developers are used to have powerful tools that do stuff with a click of a button. Don't bore them with commandline tools. Sure, on windows commandline tools are also used, but since a lot of tools have powerful gui's, they're not that necessary, especially not when you're a developer and living in visual studio all day.
It's of no use to teach these developers what AWK is or bash-scripting. What they need to know is how to connect from a windows box to a linux box to do stuff they otherwise would have programmed into SQLserver f.e. _THAT_'s knowledge they will not learn otherwise plus it's knowledge that comes in handy.
Teaching windows developers how great linux is from the point of view of a linux user, is useless, since windows developers know what they have, know what their system can do and will compare their system with what you'll teach them. And no offence, but nothing compares to visual studio at the moment.
Again: the problem with windows developers is that sometimes they lack knowledge about how to use a database or service (call it daemon, whatever you want) located on a different platform in a way that is efficient. However, this knowledge has to be taught with a windowsdeveloper's POV in mind, since THEY are going to use that knowledge. So commandline tools how to query a MySQL database is not useful. How to set up a VB program to connect to a MySQL database IS useful, plus show how to program transactions using innoDB, if that's possible (but I doubt the latter, since afaik MySQL doesn't have a DTC driver)
When people have to possibility to use Visual Studio.NET or Visual Studio 6, why would they be impressed by a stack of commandline tools, emacs and CVS?
What these people NEED to learn is HOW to connect to other machines from their windows boxes, like connect to an Oracle installation or a postgresql installation on Linux/sun/other unix. But frankly, most of them will simply look for an ODBC driver, if it's not there, they will leave it or look for Host Integration Server to do the job.
More support information than you'll ever need. Oh, you need still MORE information? Perhaps you're then not the right person who should admin these boxes.
Slashdot Mirror
For small (less than 200.000 lines of code) projects it's pretty good. You should know the limits like the size of the database shouldn't exceed 1GB, but overall the tool works seemlessly. Here we have over 20 projects in several databases and haven't found any problem with it since we started using it back in 1999. (Yes we check for errors ;) ). For the small price-tag it has, it has a lot of features and a nice gui, which supports visual conflict resolving, drag/drop sharing/branching etc.
You shouldn't use it for large projects. So when people still use it for large projects, it can be cumbersome and slow.
So your 'it's a total piece of shit' is way off base, or you're one of these people who cram 1.5 million lines projects in Sourcesafe and then start complaining.
Reading this and putting the 'vision' (if you can call it that) of the USA's government in perspective, you start to wonder why the USA still are calling themselves "Leader of the Free World". Must be a different definition of 'Free' than I have...
How can a hotfix break a tool? There is just 1 reason why: because the tool ASSUMES undocumented behaviour which is gone with the hotfix (f.e. it patches something and the behaviour isn't there anymore). No hotfix will replace COM ID's with new ones or change interfaces, they just update dlls with new versions. I don't see how a good application can be broken by patching an OS part with a version that has the same interface and behaves as documented.
(and no, undocumented crap is not needed for developing software)
Hotfixes don't kill webapps. I develop webapplications (the n-tier stuff, VC++/VB/ASP/IIS/SQLServer etc) for over 5 years now and have applied a zillion or so hotfixes on IIS and NT / Win2k server to keep the systems up to date, but never ever have I encountered 1 single hotfix which killed a webapplication nor did I hear from collegues that hotfixes killed their webapplications. If the webapp is written solidly, by the guidelines MS has supplied, you can apply any hotfix, period.
When your developers are not that educated however, perhaps they use dirty tricks which will break when a hotfix is applied (allthough I doubt it, hotfixes mostly overwrite existing files without updating CLS_ID's etc, because these stay the same) and the app will die after the hotfix is applied: one reason to kick them out the door for some real professionals.
... but testboxes or homeusers with an IIS installation on their win2k pro or win2k server OS they used. This is noticable by the fact that most attacks were and are originating from cable-internet connected boxes.
Most IIS admins who are responsible for webservers who run company websites did patch IIS long before the worm started or better: did like MS told them to do: disable all extensions not used on the box, like htr and ida. (Oh, and removed the examples)
Ok, some company-used webservers were exploited, but this number is not a majority by far.
In the real universe, it's M$loth's excuse to port the
What's 'M$loth' ? And what does the DoJ crap has to do with the quality of
There's also nothing new under the sun. Running other language environments ("hosting", my ass) has been done ever since emacs was written in lisp running on a C-based machine.
Fyi: Lisp is interpreted, C# and the other 20 or so languages for
Looking at most of the postings here, allthough most of them are posted by non-developers and brainless collegekids, I can only think: what a sad bunch of people. .NET is one hell of a platform with a very well thought out API, documentation and complete functionality. Now there is this Linux developer and his team at Ximian who ports that platform to Linux and all the fools at /. are able to do is cry out what a crap .NET is, how Miquel is a slave of MS, oh sorry, M$, and that Mono will suck as .NET already does.
*RRRRT*
If Mono fails on Linux, Linux is dead. Be aware of that.
That's the reason why servers go down and planes do not (well.. most of the time): people expect that the server they get for 3000$ will run a corporate mission critical system for years without a crash. Planes costs millions, are tested on hardware every time they're used, servers are not. Do you test your server's hardware every week? (or day?).
The question is, what does this mean for Linux -- how will Microsoft exercise their "rights"?
Like they always do with patents: only force them when someone squeeses MS' thumbs for a couple of bucks. MS patents a lot of technology, but not for money, but for the possibility to KEEP using the technology without having to pay a huge amount of money or worse: having to battle in court.
4.
This is not an imaginary thing: Rotor, the shared source
This morning windows updater had already downloaded the patches, all I had to do was confirm the installation.
People can whine all they want about that there are security flaws and ofcourse it's sad these still pop up, but the patches are there, the system to install them is VERY easy (just click one single button) so in the end, the end-user is not that much hurt by them, simply because the patches are installed so easily.
The discussions about 'security flaw free' software are endless and allthough they should be held, are nowhere near consensus: as long as there are humans involved in hammering out code and as long as the computer/software based checkinglogic is not up to par as where it should be, these flaws WILL be there, possibly in every tool written by man. Until computer science reaches the point where a compiler can proof that software is security flaw free, we should be grateful that the FIXES for security flaws are installed using the most easiest way: by simply clicking one single button.
.HTR is a flawed protocol and should be avoided. No sane developer will use .HTR pages in his site on an IIS machine, since the .HTR parser is crappier than crap since day one with buffer overruns all over the place. Most sysadmins have .HTR disabled anyway, since it's of no use. When there is a bug in that parser, thus _NOT IN IIS!_ but in an extension (like mod_perl to apache), and that parser is not used by a lot of people, would you put a lot of developers on that bug? No.
The recommended way has always been: trusted connections, at least since 7.0. (which is pretty old by now). The 6.5 legacy from sybase had a different policy due to the lack of good integration with NT security.
So the SA account is never needed: connect using trusted connections.
Examples most of the time mention 'sa' with no password, but that are examples, what way should they then mention a connection string?
Most tools/software on the server itself connect via named pipes local on the system anyway. So these tools will not have a lot of problems. Most SQLServer's exposed on the internet are installed on systems which also run IIS, thus 1 server for the complete stack of servers for a webapplication. Having this port open is not needed.
Start the server network utility and change the port on the TCP/IP protocol. Click OK and restart the MSSQLSERVER service.
btw, Oracle is superior in which way? Oracle has also a 'default' password: empty or a default well known password.. it doesn't matter. People simply should understand what they put online.
When I start a little tool on my online SQLServer machine I get 4 servers listed which run on the same network segment as my server (in the co-located rack at my ISP). a) these servers are running the server service, which shouldn't be running, b) these servers have port 1433 open and c) have set their server to not hide it for the outside world.
Pretty basic stuff that should be switched off, but isn't because the admins probably don't know that it's necessary to switch it off or even how to do that.
Again, an admin-flaw, not a softwareflaw.
Let me get this straight:
- It's totally free
- They provide a huge pile of hardware, software and people to keep up the site and datastores.
- They don't want money in return
- Everything but the sun costs money
So you people think that MS is a philantropic organisation? ALWAYS ask yourself when something is 'free' and the provider of the service has to spent a lot of money to give you this service for 'free': "Where's the catch?". I find this moaning about Hotmail rather silly, if you ask me. If you don't like it, get a real ISP account. Yes that costs money, start wondering where that money's for.
... afaik, the patent is about customisation in tabbed windows, thus customize your tabs. VS.net has that too. I'm sure MS will come up with 'but these are 'dockable windows' instead of tabs', but it could be fun to see some jury of non-geeks break their minds on that case :)
Btw, Macromedia isn't that small, they bought a lot of companies in the last couple of years and hold a strong marketshare in the webdesign market, where Adobe is, except for photoshop, a smaller player.
"...but is it right to take a good product away from so many people who really do like it just because another company's product isn't taking over the market like they hoped it would?"
Suddenly, 'Internet Explorer' comes to mind, looking from an average Joe Windowsuser POV.
knock yourself out
No '$1000' needed. Oh, and grab a copy of the free, open source C# developmenttool SharpDevelop.
Up till a few months ago I ran Winroute Pro, a firewall, and everytime I booted the win2k server it was installed on (I boot the machine every morning, it's my development box also and I don't need a server running at night, so why burn the electricity?) I saw in the log of Winroute Pro the Win2k server wanted to send out DNS records to the root servers. This is only done at boottime though afaik, since I didn't find this activities again in the logs, until the next boot.
Buffer overflows... these are implementation-specific bugs and should be easily patchable. However, MS put a lot of functionality into IE (for the most part because it's bundled) and when you look at the separate parts of all this functionality, you don't see exploitable stuff. However, combining parts of the functionality CAN LEAD to a situation that wasn't forseen, and perhaps will lead to a vulnerability.
It's easy to say "Crap!" but it takes a wicked mind to combine the right parts of the functionality of a program to create a hole, a mindset which is obviously not present under the IE designers. (but which should be though).
As a true microsoftie I more and more begin to realize that the bundling should be undone, so the set of functionality build into the webbrowser is simply focussed on what it should do: rendering pages.
Using another browser is not the answer however. The only browser that comes close to IE6 is Netscape/Mozilla, however these browsers are also packed with features you'll probably never need but CAN probably be used to create a hole when combined with other functionality in the program.
I'm a Microsoft-product-user, sue me, and IIS' design is IMHO ok, however if I could switch this minute, why wouldn't I? Well... I can't run an ASP.NET application on Apache. (shouldn't be that hard to implement however, the ASP.NET runtime is a separate process) So there is no WAY I can switch to apache.
'same performance, better security'... Hot air to me, sorry. 'Same performance', I have to see that first, and 'better security'... people who have locked down their IIS webservers the way it should be and the way Unix admins do normally, don't have to worry. Sure, you have to patch the webserver sometimes. Like you have to patch other software as well. Don't kid yourself with the idea that Apache is 'total secure'. You don't have proof of that.
What's the big deal? VI rocked back in the days when 80x24 amber/green monitors / terminals were the thing to use, but today editors which are SMART are way more productive, since they let the developer focus on the job that has to be done, instead of looking up information that should be available at the fingertips. Any editor without intellisense-like functionality is a waste of time. Seriously.
Not to sound like a troll or anything, I used VI for years, but this is 2002, the year in which we can buy a tiny mobile phone which can be used to watch a movie on it or browse websites, so using an ascii based editor that hasn't any tricks up its sleeve besides coloring keywords is IMHO kidding yourself with irrelevant reasons like "the new stuff is not worth it, this is more productive" etc.
(NOTE: The uni I graduated was a 100% unix shop, I developed on Unix for years, now I'm a 100% windows/.net developer, I know both sides)
A general rule: MS-targeting developers are used to have powerful tools that do stuff with a click of a button. Don't bore them with commandline tools. Sure, on windows commandline tools are also used, but since a lot of tools have powerful gui's, they're not that necessary, especially not when you're a developer and living in visual studio all day.
It's of no use to teach these developers what AWK is or bash-scripting. What they need to know is how to connect from a windows box to a linux box to do stuff they otherwise would have programmed into SQLserver f.e. _THAT_'s knowledge they will not learn otherwise plus it's knowledge that comes in handy.
Teaching windows developers how great linux is from the point of view of a linux user, is useless, since windows developers know what they have, know what their system can do and will compare their system with what you'll teach them. And no offence, but nothing compares to visual studio at the moment.
Again: the problem with windows developers is that sometimes they lack knowledge about how to use a database or service (call it daemon, whatever you want) located on a different platform in a way that is efficient. However, this knowledge has to be taught with a windowsdeveloper's POV in mind, since THEY are going to use that knowledge. So commandline tools how to query a MySQL database is not useful. How to set up a VB program to connect to a MySQL database IS useful, plus show how to program transactions using innoDB, if that's possible (but I doubt the latter, since afaik MySQL doesn't have a DTC driver)
When people have to possibility to use Visual Studio.NET or Visual Studio 6, why would they be impressed by a stack of commandline tools, emacs and CVS?
What these people NEED to learn is HOW to connect to other machines from their windows boxes, like connect to an Oracle installation or a postgresql installation on Linux/sun/other unix. But frankly, most of them will simply look for an ODBC driver, if it's not there, they will leave it or look for Host Integration Server to do the job.
http://www.microsoft.com/technet/
More support information than you'll ever need. Oh, you need still MORE information? Perhaps you're then not the right person who should admin these boxes.