Having PostgreSQL run native in Windows is a Good Thing. Although MSSQL does have some features that Postgres doesn't, most of them are not used (or should not be used!) by developers.
I expect this to take more of MSSQL's market share on the Windows space...for organizations that can't yet stop using Windows, but don't want to shell out for a database if they don't have to.
For smaller databases (the one I'm working with is in the 200MB range, so much smaller than what you're talking about), I haven't noticed any bumps when testing conversion to 8.0 (at least the betas). Data/schema, queries, etc. all were loaded in just fine, and apps so far have behaved as though nothing has changed. That all said, I won't begin to roll this into production until Summer due to app testing.
I am curious about the query optimizer and understanding what sort of improvements may have been made on it.
Postgres has been able to handle every problem I've slung at it, as you say, with grace. The value of the product to me is that they follow standards and have provided baseline RDBMS functionality (transactions, etc.) for a long time. It's not always as sophisticated as some databases (doesn't have all the storage options that say, Oracle has) but even for the enterprise systems I'm working with, this is not an issue.
The complaints about null are pointless. If you want to include/exclude null...just say so in your query! The complaint seems to be that of someone in their first week of SQL training (or starting a logic course). Yeah, it may not make 'common' sense, but only because commonly people don't face the concept of null, which is in fact very important in either procedural or SQL programming.
As for application portability...well, I used to really aim for DB portability. And my guess is that well over 95% of my queries are portable (the remainder would be easy to hunt down if necessary). But frankly, sometimes you have to plant your flag and say 'this is what language I'm programming in' or 'we use this database because it works, dammit!' I'm proud to do so with Postgres.
By the way, these 4 lines of code can be made into one line of code... Hardly an application re-write.
But this just checks the presence of the one known overlooked character, and performs one 'smell-test' check on the path. What about unicode variations? What about dot-dot variations? How often will this need to be tweaked before a patch comes out?
I agree, it's no re-write...it's a PITA production workaround.
Since this seems to be a problem with ASP.NET's evaluation of the URI, I'm wondering what their 'long-term' strategy is to fix this problem. Obviously, the short term strategy is to weed out those pesky backslashes in the ASP.NET auth code. However, shouldn't there be a standard tried-but-true method, available to any handler (ASP.NET, ASP, etc.) that parses the URI and verifies whether it is contained within a specific path?
The fact that this affects ASP.NET but not ASP would seem to indicate that they're using different parsing methods. That seems sort of dumb.
Oh, and to be petty--directory traversal is so late-nineties.
I don't care which way you vote, but I find your reasoning to be quite immature. You basically have the reasoning of a cliquish high-schooler (not to say that's unusual): you make your voting decisions based not on any interest in a candidate's position on issues but instead on wanting to be lumped in with the crowd you feel more comfortable with.
If you don't like either candidate or think they're too close to each other politically, vote for someone you do like. That will send a real message, not some sort of knee-jerk reaction to the fact that--gasp--some people express themselves in ways you don't like.
So unless Teresa Heinz personally gives me a blowjob
I generally agree with your post...one should always do the right thing. However, whistleblowers don't always get stellar treatment, even if they are protected. The bigger the fish, the more discredit you receive, the less likely your career can continue. Many whistleblowers are subsequently charged later on 'unrelated' charges (in bigger, more political scandals). Example here in Minn. is with the university's athletics program scandal...whistleblower was charged anyhow (of course in her case, she had already participated in the unethical activity).
And there's no guarantee that calling the authorities will exempt you from investigation. They'll only do that if they can't prosecute the criminals without your help. Just because you pick up the phone doesn't mean they're going to be grateful to you.
So regardless of whether you blow the whistle...don't do anything you morally or legally feel will be a problem.
These devices are designed to be run on a local network, which is likely behind some sort of DSL/cable-modem router, which means that unless the user goes to great lengths to do so, the devices are not visible.
Whether they are directly accessible from the Internet is important, but still limiting access from a local net hardly makes it safe. They would be vulnerable to any trojan, virus or other malware that runs on any workstation on that local network and performs network discovery (which most worms and such do). This is why so many 'secure' (firewalled or NATted) networks get infected with all kinds of crap. If a machine on the network actively/passively gets infected, the network is infected.
Furthermore it's easy to island-hop, so even directed attacks can be made against a device that doesn't have its own public IP address.
I'm not really saying you're wrong, or that having IP-enabled devices is a bad idea, it's just that this notion that direct Internet connections to boxes are needed to spread malware is sort of bogus. One should always keep in mind the risks of networking a device.
If either the copyright owner, or as you suggest someone else, tries to apply a new license using the clause you cited, you have effectively a fork. Not a code fork, a license fork. The reason this isn't a problem is because presumably code without the more restrictive license is already distributed, so people will simply continue to use the less restrictive code and license. No one would be forced to use that license, as long as other copies with the 'old' GPL still are out there. The owner has already granted the rights of redistribution of both current and derived code under the GPL, so their capacity to limit its distribution after using the 'old' GPL is nil as long as people perpetuate the use of the old license. That's the magic. The idiot who applied the more restrictive license, whether the owner or someone else, would see their code/license fork die.
To avoid SQL injection possibility, the most intuitive way is using placeholders. In ASP.NET (ADO.NET) code written using command.Parameters.Add(...) etc. looks better than [example]
Yep, placeholders/parameterized queries (usually putting a literal '?' in the SQL) has worked best for me visually and security-wise. What I like about it from a strong typing perspective is that when using placeholders, you're actually using two different systems of checking the parameter at the same time. e.g. in Java, PreparedStatement.setInt() [setDouble...] force the correct data type within Java, and generally the database's statement evaluator (or driver) also performs checks on the parameter. Having two independent checks on the parameter type is better than none, or even one (in case, for instance, the database's placeholder implementation is really just a poor string substitution...which some are).
I have never looked at OPENROWSET. Sounds nasty.
Other problems in the past have also been with basic overflow problems within the database itself, such as bad functions that could be abused to execute code on the server. That could be a problem with many databases, if function implementation is poor. I think that most databases are more up to snuff, but custom functions (esp. those written in C or other low-level languages, not so much in the DB's native scripting language) can be a source for problems.
Good post, I know people have been talking about SQL Injection for a while but I still see it all over the place.
Most likely, ALL DATA FROM DB CAN BE STOLEN
Worse yet, with such extended stored procedures as xp_cmdshell() (in MS SQL Server) you can execute code right on the server. You can launch island-hopping attacks this way (get beyond the DMZ and into the internal network, to launch further in). FYI xp_cmdshell() is only available to some logins, such as 'sa', but I see many people with their production sites running as sa.
Other databases and serving environments are just as vulnerable to general SQL injection unless you do strong typing at the parameter retrieval (ASP/JSP/PHP) and data query level (MSSQL/Postgres,etc.). However most DBs don't have as scary a function as xp_cmdshell().
The sad thing is that all environments have really good mechanisms for locking down this access, and NONE of them affect performance in any significant way. Generally I check values at each tier for validity, and when appropriate, for authority as well...in terms of speed, these checks do not generally affect performance and keep your code safer as well as better structured.
That's why this stupid VB programmer uses error trapping and does not pass ids in the querystring!
Well...sorry, I'm in a nitpicky mood...but how do you pass params from one page to another (usually you have to pass some sort of ID)? e.g. if you click to see article ID #123, that gets passed somehow...(whether it's POST or GET doesn't matter).
In other words, it's not so much 'don't pass ids in the querystring' as much as:
Check parameters on the server for proper type (integer, double, string...)
Abstract database access through methods that ensure proper types are used (e.g. to construct parameterized statements, or other strongly-typed access to data, not just raw SQL)
If access to the resource is limited by ID (e.g. I can read #123 but someone else can't) then both strong session management and server-side validation of the request (checking to make sure that mborland should have access to article #123) are required.
If you do that, it's perfectly fine to pass ids through the querystring/POST parameters.
Either this is just a fabrication, or you really don't know what you're doing.
OK, sceptic [sic], hold the judgment...I agree that it probably wasn't really a server-side error, but the Acrobat Reader plugin to IE is a piece of crap.
I've had to set up quite a number of sites that serve either static or streamed PDF content, and IE has problems with handling content in SSL in some inappropriate cases (Pragma/Cache headers cause IE to 'lose' a download file in SSL). The Reader plugin, like I said above, is a piece of crap and doesn't always render correctly, and can't always handle streamed content properly (probably related to IE's problems). The errors produced at this time are usually very misleading and often indicate a server problem (because Reader thinks it never got a file/stream).
Making Reader launch the actual app rather than the plugin helps with rendering and stream content, but again will have problems if IE can't find the file it just downloaded.
Mozilla/Firefox/Netscape do not have this particular problem, both because they don't use a plugin, but also because they present the app with a complete file (is that really so hard?).
I did tech support on a small campus when I was in college, mostly physically going to the site and doing diagnosis, etc. I have always considered this period of my career to be the most useful because I made LOTS of minor mistakes that I could learn from.
But anyway, in about 1992 I had to look at one of the more expensive laser printers on campus (thousands of dollars?) because it was acting flaky. It was pretty heavy and sat on a small shelf about 4 feet off the ground. I inched it toward me so I could unplug and check the connections in back and make sure everything was set up OK.
Suddenly I look down because the printer is falling to the ground. I swear, I saw it falling in slow motion (I was a film minor). I must have pushed it just too far...
Now, this is all happening in plain sight of one of my supervisors in a moderately well populated computer lab. In those brief moments, I could see my job ending pretty quick.
But then right as it's about to hit the floor...it just stops!
Security cable caught it in the nick of time. I think maybe a tray fell out, but no harm was done.
I looked at a supervisor and sheepishly placed the printer back on the shelf.
I never knew if it was related, but they transferred me to software support from hardware support the next year.
I agree...but almost MORE of a problem is the same thing with UPDATE. e.g. 'UPDATE foo set bar = 1' will set all table foo's rows' 'bar' values to 1.
Why is this more annoying? Well, sometimes it's not so obvious as a delete. The rows are all still there. Also, if you use foreign keys against the target table, an overly destructive delete may just carp at you. But a blanket UPDATE to a table may very well keep referential integrity, or otherwise only affect a field that doesn't crop up in public scrutiny frequently. So if you execute such a destructive UPDATE...it may be weeks before someone notices, and you may not be sure exactly when to recover to, or if it's really recoverable at all.
I have been lucky to only have done that once, my first year (working in Access) and in a none-too-critical database--and noticed it immediately, but about ten years later I'm still paranoid and run most my modifying statements thru a gauntlet of tests on shadow/test servers. Oh, and yes, turning off auto-commit helps, although I like doing the testing anyway.:-)
He clearly didn't like the NRA's political activism, but he didn't really go after the Second Amendment.
That's partly because Moore is a member of the NRA and stands behind the second amendment. He's a midwest, blue-collar/union-oriented liberal, not an liberal.
Disney made a decision as a private company and business that they will not produce and distribute a film.
Right, but if they are doing it because the government will place restrictions on Disney based on this incident, then we're taking another step toward Facism, a union of state and corporations.
Unless of course MS makes a "donation" of Windows and x86 hardware to a few of these countries. Say, maybe, in the schools where the future generations are being trained. And they'll learn on Windows and get used to Office. And then they grow up and get jobs in government or public sector. And guess what OS they'll want to buy? (Hint: not Linux)
OK, I agree with much of your post. However, it's my experience that people are not such simple programmable devices as you make them out to be. When you take your general Joe User who is my age, it's very likely that they had Commodore 64s and Apple ][s in their grade schools, used DOS in high school, used Macs in college, and Windows at their jobs out of college.
For those who make decisions about what technoogy their enterprises are going to use, I'm quite certain that (though it may produce some nostalgia) they're not likely to suggest a vendor simply because that's what they grew up with. This is software, not Coke.
I think in the short term, yes, users like to stick with what they have. But outside of the space of a year or so, people basically adopt what works better at that time.
I'll actually take the opportunity to congratulate you.
Lots of people say this is vigilantism. What they don't understand is that vigilantism is 'taking the law into ones own hands,' and specifically doing so by breaking the law (trespassing, illegal intimidation, murder, etc.). Putting together a blacklist does not make you a vigilante, by any stretch of the imagination.
If you have a large number of customers in Spain, and you're configured to use this blacklist... you're screwed.
It's more like losing a very small, temporary battle to help win the war. Think of it as a tough-love way to help the conditions in Spain. Got clients there? Get them mad about all that spam being sent through their ISPs--it's better for them in the long run. Screwed? Hardly. This is a temporary measure...if the Spanish ISPs know what is good for them and act.
Sort of like the situation where now many places block.zip files to counteract trojans. Overkill? Yes. Effective against dumb users? Pretty much. Is anyone screwed because of this? Hardly. Sysadmins would be much more screwed if every user on their network opened/ran these trojans, and the admins were left to pick up the pieces. These are both temporary inconveniences that hedge against a greater threat.
The Republicans did lose a very close election before, in 1960, and you didn't see Republicans whining about the result like the Democrats still are about 2000.
I generally agreed with your other comments, but actually the Wall Street Journal very frequently complains about the 1960 election (and that was over 40 years ago). They usually do so to imply that Democrats have always and will always commit massive voter fraud. (There was pretty well-documented fraud in Chicago in that year which favored the Democrats.)
Hey feller, your post reminds me of this song from the Fatima Mansions...'Only Losers Take the Bus.' I appreciate the luxuries of the car, too, but people need alternatives for any number of reasons. Your comment reflects the bold ignorance of the person in the song:
I'm not stupid--I'm a man (!ythgimla hsurdloG) I'm not stupid
I'm born again in hail and flames (Goldrush almighty!) Go tell it loud to all my slaves (Goldrush almighty!) You scum don't have the fear of God All that's left is the iron rod (Goldrush almighty!)
Let's go down, kiss the plough Public system--burn down! and let memory fade--nothing is wrong
Only losers take the bus Only losers take the bus
Churchill was a shopping bag (Goldrush almighty!) Can you draw the Chinese flag? (Goldrush almighty!) It's three blue lines and six dahlias Paris is in India (Goldrush almighty!)
Let's go down on my friends All alone, we descend Plastic food, TV--Take your eyes off of me!
Only losers take the bus Only losers take the bus
I hate misunderstandings Hey, get these dead bodies off my racetrack!
And we cry out with joy as we drive through the rain and our enemies claw from every goddamn side
Only losers take the bus.... Only losers, only losers, only losers take the bus I'm no loser, I'm a letch! Protect me! Protect me! I'm not one of them, I'm not one of them, I'm not one of them...
I mean, like X-server has been around for 20 yrs, can't I assume that it pretty much is safe from an external network attack?
Why do you need to expose it (or cups) to an external network?
What makes you assume it's an external network attack? These days you're likely (if you are not the only computer on the network) to get just as much a barrage of scanning/attacks from the inside as the outside.
But if you cannot give your troops clear, concise goals, then everyone will go in a million different directions. And nothing will get done!
True, and the 'troops' here are not only the programmers, but also the MS marketers and MS development community. XML features?.NET stuff? I am all in favor of having options, but I cannot imagine that each and every feature will be well-optimized or secure. MS SQL, which is and has been one of MS' best products, is going the way of Word by incorporating a bajillion features. All in all, this approach isn't bad (we all like features), except that this is a core element to businesses and you can't afford to put too much monkey s**t in it.
I suppose the crux is that databases like Postgres now features pretty robust, standard database functionality and so now MS thinks that they need to keep 'ahead' by putting all sorts of wonky stuff on top. I know I'm old-fashioned, but XML and.NET stuff...isn't that what middleware is for? Otherwise you're starting to embed way too much stuff too deep in your DB and not making it abstract/flexible...what DBs are supposed to be.
It's still beyond me why people even bother giving MySQL the time of day when the incomparably superior Postgres is available under GPL.
I'm with you on that one. Once I installed Postgres I haven't looked back. What I admire about the Postgres team is that they focus on standards first and speed second. Smart, because eventually speed catches up (through code optimization or just over time through hardware); whereas MySQL has to add in features afterwards, and do so without slowing it down (and thus pissing off its following). Please MySQL fans, no flaming.
Postgres vs. MS SQL is sort of a different issue. MS SQL has all kinds of features Postgres doesn't have, e.g. lots of replication features (I believe, though I've never had to use them) and its optimizer seems more intelligent than Postgres'. That said, very few dataservers actually use the extended features, and my casual complaints about Postgres' optimizer are quelled by a) fixing my query b) VACUUMing the database as instructed or c) realizing that it was only a few ms slower anyway. Cons on the MS SQL Server side are that a) it ties to you one platform, b) tends to have large gaping security holes and c) tends more often to be implemented by those without a clue of DBAing or security.
Slashdot Mirror
I expect this to take more of MSSQL's market share on the Windows space...for organizations that can't yet stop using Windows, but don't want to shell out for a database if they don't have to.
I am curious about the query optimizer and understanding what sort of improvements may have been made on it.
Postgres has been able to handle every problem I've slung at it, as you say, with grace. The value of the product to me is that they follow standards and have provided baseline RDBMS functionality (transactions, etc.) for a long time. It's not always as sophisticated as some databases (doesn't have all the storage options that say, Oracle has) but even for the enterprise systems I'm working with, this is not an issue.
The complaints about null are pointless. If you want to include/exclude null...just say so in your query! The complaint seems to be that of someone in their first week of SQL training (or starting a logic course). Yeah, it may not make 'common' sense, but only because commonly people don't face the concept of null, which is in fact very important in either procedural or SQL programming.
As for application portability...well, I used to really aim for DB portability. And my guess is that well over 95% of my queries are portable (the remainder would be easy to hunt down if necessary). But frankly, sometimes you have to plant your flag and say 'this is what language I'm programming in' or 'we use this database because it works, dammit!' I'm proud to do so with Postgres.
But this just checks the presence of the one known overlooked character, and performs one 'smell-test' check on the path. What about unicode variations? What about dot-dot variations? How often will this need to be tweaked before a patch comes out?
I agree, it's no re-write...it's a PITA production workaround.
The fact that this affects ASP.NET but not ASP would seem to indicate that they're using different parsing methods. That seems sort of dumb.
Oh, and to be petty--directory traversal is so late-nineties.
If you don't like either candidate or think they're too close to each other politically, vote for someone you do like. That will send a real message, not some sort of knee-jerk reaction to the fact that--gasp--some people express themselves in ways you don't like.
So unless Teresa Heinz personally gives me a blowjob
Right, everyone else is being immature.
And there's no guarantee that calling the authorities will exempt you from investigation. They'll only do that if they can't prosecute the criminals without your help. Just because you pick up the phone doesn't mean they're going to be grateful to you.
So regardless of whether you blow the whistle...don't do anything you morally or legally feel will be a problem.
Whether they are directly accessible from the Internet is important, but still limiting access from a local net hardly makes it safe. They would be vulnerable to any trojan, virus or other malware that runs on any workstation on that local network and performs network discovery (which most worms and such do). This is why so many 'secure' (firewalled or NATted) networks get infected with all kinds of crap. If a machine on the network actively/passively gets infected, the network is infected.
Furthermore it's easy to island-hop, so even directed attacks can be made against a device that doesn't have its own public IP address.
I'm not really saying you're wrong, or that having IP-enabled devices is a bad idea, it's just that this notion that direct Internet connections to boxes are needed to spread malware is sort of bogus. One should always keep in mind the risks of networking a device.
If either the copyright owner, or as you suggest someone else, tries to apply a new license using the clause you cited, you have effectively a fork. Not a code fork, a license fork. The reason this isn't a problem is because presumably code without the more restrictive license is already distributed, so people will simply continue to use the less restrictive code and license. No one would be forced to use that license, as long as other copies with the 'old' GPL still are out there. The owner has already granted the rights of redistribution of both current and derived code under the GPL, so their capacity to limit its distribution after using the 'old' GPL is nil as long as people perpetuate the use of the old license. That's the magic. The idiot who applied the more restrictive license, whether the owner or someone else, would see their code/license fork die.
Yep, placeholders/parameterized queries (usually putting a literal '?' in the SQL) has worked best for me visually and security-wise. What I like about it from a strong typing perspective is that when using placeholders, you're actually using two different systems of checking the parameter at the same time. e.g. in Java, PreparedStatement.setInt() [setDouble...] force the correct data type within Java, and generally the database's statement evaluator (or driver) also performs checks on the parameter. Having two independent checks on the parameter type is better than none, or even one (in case, for instance, the database's placeholder implementation is really just a poor string substitution...which some are).
I have never looked at OPENROWSET. Sounds nasty.
Other problems in the past have also been with basic overflow problems within the database itself, such as bad functions that could be abused to execute code on the server. That could be a problem with many databases, if function implementation is poor. I think that most databases are more up to snuff, but custom functions (esp. those written in C or other low-level languages, not so much in the DB's native scripting language) can be a source for problems.
Most likely, ALL DATA FROM DB CAN BE STOLEN
Worse yet, with such extended stored procedures as xp_cmdshell() (in MS SQL Server) you can execute code right on the server. You can launch island-hopping attacks this way (get beyond the DMZ and into the internal network, to launch further in). FYI xp_cmdshell() is only available to some logins, such as 'sa', but I see many people with their production sites running as sa.
Other databases and serving environments are just as vulnerable to general SQL injection unless you do strong typing at the parameter retrieval (ASP/JSP/PHP) and data query level (MSSQL/Postgres,etc.). However most DBs don't have as scary a function as xp_cmdshell().
The sad thing is that all environments have really good mechanisms for locking down this access, and NONE of them affect performance in any significant way. Generally I check values at each tier for validity, and when appropriate, for authority as well...in terms of speed, these checks do not generally affect performance and keep your code safer as well as better structured.
Well...sorry, I'm in a nitpicky mood...but how do you pass params from one page to another (usually you have to pass some sort of ID)? e.g. if you click to see article ID #123, that gets passed somehow...(whether it's POST or GET doesn't matter).
In other words, it's not so much 'don't pass ids in the querystring' as much as:
- Check parameters on the server for proper type (integer, double, string...)
- Abstract database access through methods that ensure proper types are used (e.g. to construct parameterized statements, or other strongly-typed access to data, not just raw SQL)
- If access to the resource is limited by ID (e.g. I can read #123 but someone else can't) then both strong session management and server-side validation of the request (checking to make sure that mborland should have access to article #123) are required.
If you do that, it's perfectly fine to pass ids through the querystring/POST parameters.OK, sceptic [sic], hold the judgment...I agree that it probably wasn't really a server-side error, but the Acrobat Reader plugin to IE is a piece of crap.
I've had to set up quite a number of sites that serve either static or streamed PDF content, and IE has problems with handling content in SSL in some inappropriate cases (Pragma/Cache headers cause IE to 'lose' a download file in SSL). The Reader plugin, like I said above, is a piece of crap and doesn't always render correctly, and can't always handle streamed content properly (probably related to IE's problems). The errors produced at this time are usually very misleading and often indicate a server problem (because Reader thinks it never got a file/stream).
Making Reader launch the actual app rather than the plugin helps with rendering and stream content, but again will have problems if IE can't find the file it just downloaded.
Mozilla/Firefox/Netscape do not have this particular problem, both because they don't use a plugin, but also because they present the app with a complete file (is that really so hard?).
But anyway, in about 1992 I had to look at one of the more expensive laser printers on campus (thousands of dollars?) because it was acting flaky. It was pretty heavy and sat on a small shelf about 4 feet off the ground. I inched it toward me so I could unplug and check the connections in back and make sure everything was set up OK.
Suddenly I look down because the printer is falling to the ground. I swear, I saw it falling in slow motion (I was a film minor). I must have pushed it just too far...
Now, this is all happening in plain sight of one of my supervisors in a moderately well populated computer lab. In those brief moments, I could see my job ending pretty quick.
But then right as it's about to hit the floor...it just stops!
Security cable caught it in the nick of time. I think maybe a tray fell out, but no harm was done.
I looked at a supervisor and sheepishly placed the printer back on the shelf.
I never knew if it was related, but they transferred me to software support from hardware support the next year.
I agree...but almost MORE of a problem is the same thing with UPDATE. e.g. 'UPDATE foo set bar = 1' will set all table foo's rows' 'bar' values to 1.
Why is this more annoying? Well, sometimes it's not so obvious as a delete. The rows are all still there. Also, if you use foreign keys against the target table, an overly destructive delete may just carp at you. But a blanket UPDATE to a table may very well keep referential integrity, or otherwise only affect a field that doesn't crop up in public scrutiny frequently. So if you execute such a destructive UPDATE...it may be weeks before someone notices, and you may not be sure exactly when to recover to, or if it's really recoverable at all.
I have been lucky to only have done that once, my first year (working in Access) and in a none-too-critical database--and noticed it immediately, but about ten years later I'm still paranoid and run most my modifying statements thru a gauntlet of tests on shadow/test servers. Oh, and yes, turning off auto-commit helps, although I like doing the testing anyway. :-)
That's partly because Moore is a member of the NRA and stands behind the second amendment. He's a midwest, blue-collar/union-oriented liberal, not an liberal.
Right, but if they are doing it because the government will place restrictions on Disney based on this incident, then we're taking another step toward Facism, a union of state and corporations.
OK, I agree with much of your post. However, it's my experience that people are not such simple programmable devices as you make them out to be. When you take your general Joe User who is my age, it's very likely that they had Commodore 64s and Apple ][s in their grade schools, used DOS in high school, used Macs in college, and Windows at their jobs out of college.
For those who make decisions about what technoogy their enterprises are going to use, I'm quite certain that (though it may produce some nostalgia) they're not likely to suggest a vendor simply because that's what they grew up with. This is software, not Coke.
I think in the short term, yes, users like to stick with what they have. But outside of the space of a year or so, people basically adopt what works better at that time.
I'll actually take the opportunity to congratulate you.
Lots of people say this is vigilantism. What they don't understand is that vigilantism is 'taking the law into ones own hands,' and specifically doing so by breaking the law (trespassing, illegal intimidation, murder, etc.). Putting together a blacklist does not make you a vigilante, by any stretch of the imagination.
It's more like losing a very small, temporary battle to help win the war. Think of it as a tough-love way to help the conditions in Spain. Got clients there? Get them mad about all that spam being sent through their ISPs--it's better for them in the long run. Screwed? Hardly. This is a temporary measure...if the Spanish ISPs know what is good for them and act.
Sort of like the situation where now many places block .zip files to counteract trojans. Overkill? Yes. Effective against dumb users? Pretty much. Is anyone screwed because of this? Hardly. Sysadmins would be much more screwed if every user on their network opened/ran these trojans, and the admins were left to pick up the pieces. These are both temporary inconveniences that hedge against a greater threat.
I generally agreed with your other comments, but actually the Wall Street Journal very frequently complains about the 1960 election (and that was over 40 years ago). They usually do so to imply that Democrats have always and will always commit massive voter fraud. (There was pretty well-documented fraud in Chicago in that year which favored the Democrats.)
Hey feller, your post reminds me of this song from the Fatima Mansions...'Only Losers Take the Bus.' I appreciate the luxuries of the car, too, but people need alternatives for any number of reasons. Your comment reflects the bold ignorance of the person in the song:
I mean, like X-server has been around for 20 yrs, can't I assume that it pretty much is safe from an external network attack?
Why do you need to expose it (or cups) to an external network?
What makes you assume it's an external network attack? These days you're likely (if you are not the only computer on the network) to get just as much a barrage of scanning/attacks from the inside as the outside.
True, and the 'troops' here are not only the programmers, but also the MS marketers and MS development community. XML features? .NET stuff? I am all in favor of having options, but I cannot imagine that each and every feature will be well-optimized or secure. MS SQL, which is and has been one of MS' best products, is going the way of Word by incorporating a bajillion features. All in all, this approach isn't bad (we all like features), except that this is a core element to businesses and you can't afford to put too much monkey s**t in it.
I suppose the crux is that databases like Postgres now features pretty robust, standard database functionality and so now MS thinks that they need to keep 'ahead' by putting all sorts of wonky stuff on top. I know I'm old-fashioned, but XML and .NET stuff...isn't that what middleware is for? Otherwise you're starting to embed way too much stuff too deep in your DB and not making it abstract/flexible...what DBs are supposed to be.
I'm with you on that one. Once I installed Postgres I haven't looked back. What I admire about the Postgres team is that they focus on standards first and speed second. Smart, because eventually speed catches up (through code optimization or just over time through hardware); whereas MySQL has to add in features afterwards, and do so without slowing it down (and thus pissing off its following). Please MySQL fans, no flaming.
Postgres vs. MS SQL is sort of a different issue. MS SQL has all kinds of features Postgres doesn't have, e.g. lots of replication features (I believe, though I've never had to use them) and its optimizer seems more intelligent than Postgres'. That said, very few dataservers actually use the extended features, and my casual complaints about Postgres' optimizer are quelled by a) fixing my query b) VACUUMing the database as instructed or c) realizing that it was only a few ms slower anyway. Cons on the MS SQL Server side are that a) it ties to you one platform, b) tends to have large gaping security holes and c) tends more often to be implemented by those without a clue of DBAing or security.
Whoops, I ranted.