The problem is that, from an end-user's perspective (because nearly all JavaScript code is focused on improving functionality for end-users), some web sites simply don't work in all web browsers.
Explaining to end-users that it's not JavaScript, but that it's the stuff that JavaScript uses which is different, is not nearly as easy as telling the user something like "JavaScript works differently on each web browser."
I really like the idea of client-side PerlScript. That could open up some really amazing possibilities given how powerful Perl can be.
TIMESTAMPs are very useful for retaining temporal order of data. Those articles don't deal with timestamps at all. If they knew about TIMESTAMPs (like what PostgreSQL has), things could be a lot better.
Cumulative totals can be achieved as well, either within a SELECT statement (that sums from the starting date to the current date being processed) or with a stored procedure (which I'd prefer to ensure efficiency since I could just keep adding to an internal variable along the way instead of re-summing everything for each row returned).
Moving averages (with varying temporal ranges), Ranks, etc., can all be handled with a stored procedure using some fairly straight-forward "plpgsql" or other DBMS back-end language. With enough inventiveness, someone could probably figure out how to do the same with a SELECT statement (possibly needing sub-SELECTs).
Adding features such as "accreting" (see bottom of first article referenced at dbmsmag.com above) seems like a nice idea to me -- I'm certainly in favour of adding more features to an RDMBS since it will make it more useful to people. I worry, however, that those authors are expecting SQL to do more than simply return data sets (which their reporting code should be responsible for formatting for the user) since that would be missing the point of what SQL is for.
I don't agree either. JavaScript is a vague language, and partly thanks to the web browser wars. If JavaScript was actually properly standardized across web browsers, then web developers wouldn't be stuck having to write huge amounts of conditional code just to make it work in Internet Exploder, and then more when doing really complicated stuff. Take a look at any cross-browser JavaScript menu system that supports Opera, Firefox, Safari, Google Chrome, Internet Explorer, and others, and it's easy to find lots of these conditional statements to work-around various infuriating web browser incompatibilities.
SQL, on the other hand, doesn't tend to suffer from these problems because the client-side isn't choosing which database engine is being used behind the scenes, so the DBAs and other system administrators can get the consistency they need. Sure, every database vendor is tweaking the standards (or relying on outdated standards like MySQL has for a long time -- I don't know if they're still locked into the old SQL standard anymore because I use PostgreSQL for all my database needs), but generally most of the more common statements work very similarily, so moving between database engines (and adapting and testing code accordingly) is far easier than making JavaScript work consistently across multiple versions of multiple web browsers.
PostgreSQL also has specialized index algorithms for handling exotic arrangements of data. One index type that I'll be looking into in the near future [I've been told] makes it possible to efficiently take two dimensional data, and return rows that all fit within the specified radius starting from two coordinates. Although this can be done with a combination of indexes and various formulas, it's not as elegant as what PostgreSQL can do now. So, when I see statements that SQL hasn't progressed, I question the level of expertise of those making such statements.
As for "all they want is their objects," I think that's true -- just look at all the PHP newbies out there who like to create tables with hundreds of columns instead of taking advantage of one of SQL's greatest hallmarks: Relationships between tables
Java (with JDBC) and Perl/mod_perl/mod_perl2 (with DBIC, a.k.a., DBIx::Class) should make these folks happy though because they do provide slick OO interfaces to SQL that, unless you keep all your hundred or so columns in a single table, also require at least a basic understanding of SQL.
Anybody working with databases in a serious way has to have at least a basic understanding of the underlying technology. Creating an alternative to SQL seems ludicrous to me because it will eventually take away from the large pool of SQL expertise that exists today (I never knew about an anti-SQL movement until I read about it here today on SlashDot); many other alternatives do already exist too, such as BTrieve which has a totally different interface from SQL, and although it performs well it's just not as popular anymore (didn't Pervasive, the company that currently owns the BTrieve technology, switch to a customized rendition of PostgreSQL or something like that anyway? I wonder what their real reasons were for focusing on SQL in favour of BTrieve?).
As a developer, I see that performance (speed) is a very important factor, but that's not the only factor for me -- quality of code, helpful documentation, and overall system reliability (including, very importantly, the ability to always recover gracefully from a power outage that occurred while thousands of INSERTs, UPDATEs, and DELETEs are active, which I confirmed in some informal "pull-the-plug" testing many years ago that PostgreSQL and Oracle both do by issuing ROLLBACKs at database mount time after the OS recovers) because it will mean easier development with fewer potential problems for me to deal with in the future if something does fail.
You chose to use one or more of the SORBS.net RBLs for blocking (presumably without testing first), and then you were disappointed because you didn't get the results you expected? If you truly understood SORBS.net's criteria, and the purpose of RBLs in the first place, then there clearly would be no need to complain.
Responsible mail server operators often do the following prior to implementing any RBL in a blocking fashion:
- Understand the listing criteria (anyone who doesn't do this is definitely a gambler)
- Test it in tagged mode (this decision is subjective, but strongly recommended for those who aren't familiar with DNSBLs or spam fighting in general) and inspect the results periodically to verify accuracy
The reason this testing needs to be performed is that every mail server deals with different eMail traffic patterns (in part due to serving different users/purposes/etc.), and what works well in one environment could be a complete disaster in another.
One must also realize that it's not the fault of the DNSBL operator if legitimate eMail gets blocked (assuming that the criteria is being enforced without exceptions, as has always been the case with SORBS.net as far as I know), rather it's the fault of the spammer and the provider that doesn't terminate spammer accounts (I certainly don't want to receive eMail from ISPs that harbour spammers, and that's my absolutely undeniable right).
If you find that a DNSBL isn't working for you, two options that come to mind are to either combine it with a whitelist (it's entirely up to you to make exceptions to rules on your own systems) or stop using it entirely. In my experience, DNSBL operators typically don't care if you don't use their services, and often discourage relying on their databases anyway -- they're merely providing the listing service for free in the hopes that it will help to make the internet better for everyone, which is a noble attitude worthy of much respect.
I use almost a dozen DNSBLs on all my servers, and the logs consistently indicate a rejection rate of over ~95%. Users are pleased because they get a lot less spam through our systems than they do from most others. Occasionally there is a question about someone's eMail getting blocked, and we handle these on a case-by-case basis (sometimes we refuse to whitelist an ISP, typically because of their attitude or history, but this is rare because most of the time they're willing to terminate spammers to get {and remain} de-listed).
An important part of using a DNSBL is to require those who are blocked to clean up their act. It's a social responsibility that all mail server administrators have, and it's so easy to encourage clean-up on the other end simply because they're the ones who have to take the appropriate steps to get de-listed (there's no need for whitelisting if they actually do get rid of the spam problem on their end, after all). And if they just whine about their upstream provider not fixing it, then that's still their problem (they can always take their business somewhere else -- this is a very compelling way to find out how seriously the take the spam problem, since supporting a spam-friendly upstream provider is approximately as bad as harbouring spammers directly).
I assume Intel knows enough about Faraday Cages (and similar solutions) to have this potential nightmare of a problem nipped in the bud. Perhaps one possible solution might also be to build this entire farm if miniature magnets on one giant high-powered magnet to prevent lesser magnetic fields from causing problems?
Using magnetism is a fantastic alternative that will certainly give IBM a run for their money with their recent research on copper-based processors.
Really? I thought Al Gore got more votes, but the Republicans simply won in more States due to the way the electoral system works in the USA. Was the balanced Canadian Government operated news (CBC) mistaken about this?
> So lets see.... FireFox duplicates Opera features, > then IE duplicates FireFox features... > > Whoa! I must be using IE version 9 right now!
Don't worry, you're not -- Opera and FireFox don't have the infamous "security holes" features that IE does (e.g., auto-download-and-merge of.REG files).
I used to talk on a cell phone while holding it next to my head, and found that I'd get headaches (usually worse on days I was talking for longer periods of time). Now that I use a small headset that allows me to keep the cell phone at least 2 imperial feet away from my head I no longer get the headaches.
In summary, I don't care what the research says -- I'm convinced based on personal experience that cell phones aren't good for our brains (that, plus the fact that microwaves cook everything, and lower power microwaves just take longer to cook things; just consider how much longer it takes your microwave oven to cook meat or noodles when set to "low power" mode and the conclusion that "less != none" should be confirmed in this context for anyone who has doubts).
By default Opera identifies itself as "Internet Explorer" and some webmasters incorrectly use this information to determine which web browsers are more commonly used.
If you're a big fan of Opera, like we are (and it's already standard at some of the companies we regularly deal with too), you can actually cast an implied vote by setting the default to "Opera" in the settings:
1. "Tools" menu 2. "Preferences" item 3. "Advanced" tab 4. "Network" option (on the left-hand side) 5. "Browser identification" pull-down menu
And if you find a web site that lectures you on which web browser they think you should use, then send a friendly message to the sales department (don't bother the webmaster because given their attitude they'll probably just ignore you and not bother to let the sales people know) telling them that you were interested in their product but since you can't use Opera to browse their web site that you'll just have to find the needed information somewhere else.
By default Opera identifies itself as "Internet Explorer" and some webmasters incorrectly use this information to determine which web browsers are more commonly used.
If you're a big fan of Opera, like we are (and it's already standard at some of the companies we regularly deal with too), you can actually cast an implied vote by setting the default to "Opera" in the settings:
1. "Tools" menu 2. "Preferences" item 3. "Advanced" tab 4. "Network" option (on the left-hand side) 5. "Browser identification" pull-down menu
And if you find a web site that lectures you on which web browser they think you should use, then send a friendly message to the sales department (don't bother the webmaster because given their attitude they'll probably just ignore you and not bother to let the sales people know) telling them that you were interested in their product but since you can use Opera to browse their web site that you'll just have to find the needed information somewhere else.
Profanities seem to be more popular on systems that filter it thanks to the cuss-filter words you included for everyone's convenience.
When it comes to the time and effort required to built a cuss-filter into a game chat system, I've often wondered "Wouldn't it be better for the programmers to just focus on making the game better since people will just find ways around it anyway?"
What EULA? When I buy a music CD there is no contract that I'm aware of that I had to sign before opening the package and inserting it in any CD player -- I simply had to walk down to the local music store and pay for it, and that's the condition that most people who buy music CDs are aware of.
Slashdot Mirror
Those "Rules of Condct" remind me of "The Rules of Spam..."
http://www.lumbercartel.ca/glossary/rulesofspam.pl
The problem is that, from an end-user's perspective (because nearly all JavaScript code is focused on improving functionality for end-users), some web sites simply don't work in all web browsers.
Explaining to end-users that it's not JavaScript, but that it's the stuff that JavaScript uses which is different, is not nearly as easy as telling the user something like "JavaScript works differently on each web browser."
I really like the idea of client-side PerlScript. That could open up some really amazing possibilities given how powerful Perl can be.
TIMESTAMPs are very useful for retaining temporal order of data. Those articles don't deal with timestamps at all. If they knew about TIMESTAMPs (like what PostgreSQL has), things could be a lot better.
Cumulative totals can be achieved as well, either within a SELECT statement (that sums from the starting date to the current date being processed) or with a stored procedure (which I'd prefer to ensure efficiency since I could just keep adding to an internal variable along the way instead of re-summing everything for each row returned).
Moving averages (with varying temporal ranges), Ranks, etc., can all be handled with a stored procedure using some fairly straight-forward "plpgsql" or other DBMS back-end language. With enough inventiveness, someone could probably figure out how to do the same with a SELECT statement (possibly needing sub-SELECTs).
Adding features such as "accreting" (see bottom of first article referenced at dbmsmag.com above) seems like a nice idea to me -- I'm certainly in favour of adding more features to an RDMBS since it will make it more useful to people. I worry, however, that those authors are expecting SQL to do more than simply return data sets (which their reporting code should be responsible for formatting for the user) since that would be missing the point of what SQL is for.
I don't agree either. JavaScript is a vague language, and partly thanks to the web browser wars. If JavaScript was actually properly standardized across web browsers, then web developers wouldn't be stuck having to write huge amounts of conditional code just to make it work in Internet Exploder, and then more when doing really complicated stuff. Take a look at any cross-browser JavaScript menu system that supports Opera, Firefox, Safari, Google Chrome, Internet Explorer, and others, and it's easy to find lots of these conditional statements to work-around various infuriating web browser incompatibilities.
SQL, on the other hand, doesn't tend to suffer from these problems because the client-side isn't choosing which database engine is being used behind the scenes, so the DBAs and other system administrators can get the consistency they need. Sure, every database vendor is tweaking the standards (or relying on outdated standards like MySQL has for a long time -- I don't know if they're still locked into the old SQL standard anymore because I use PostgreSQL for all my database needs), but generally most of the more common statements work very similarily, so moving between database engines (and adapting and testing code accordingly) is far easier than making JavaScript work consistently across multiple versions of multiple web browsers.
PostgreSQL also has specialized index algorithms for handling exotic arrangements of data. One index type that I'll be looking into in the near future [I've been told] makes it possible to efficiently take two dimensional data, and return rows that all fit within the specified radius starting from two coordinates. Although this can be done with a combination of indexes and various formulas, it's not as elegant as what PostgreSQL can do now. So, when I see statements that SQL hasn't progressed, I question the level of expertise of those making such statements.
As for "all they want is their objects," I think that's true -- just look at all the PHP newbies out there who like to create tables with hundreds of columns instead of taking advantage of one of SQL's greatest hallmarks: Relationships between tables
Java (with JDBC) and Perl/mod_perl/mod_perl2 (with DBIC, a.k.a., DBIx::Class) should make these folks happy though because they do provide slick OO interfaces to SQL that, unless you keep all your hundred or so columns in a single table, also require at least a basic understanding of SQL.
Anybody working with databases in a serious way has to have at least a basic understanding of the underlying technology. Creating an alternative to SQL seems ludicrous to me because it will eventually take away from the large pool of SQL expertise that exists today (I never knew about an anti-SQL movement until I read about it here today on SlashDot); many other alternatives do already exist too, such as BTrieve which has a totally different interface from SQL, and although it performs well it's just not as popular anymore (didn't Pervasive, the company that currently owns the BTrieve technology, switch to a customized rendition of PostgreSQL or something like that anyway? I wonder what their real reasons were for focusing on SQL in favour of BTrieve?).
As a developer, I see that performance (speed) is a very important factor, but that's not the only factor for me -- quality of code, helpful documentation, and overall system reliability (including, very importantly, the ability to always recover gracefully from a power outage that occurred while thousands of INSERTs, UPDATEs, and DELETEs are active, which I confirmed in some informal "pull-the-plug" testing many years ago that PostgreSQL and Oracle both do by issuing ROLLBACKs at database mount time after the OS recovers) because it will mean easier development with fewer potential problems for me to deal with in the future if something does fail.
Most experienced assembler programmers know better than to assume the direction flag will be set or cleared unless this is specifically documented.
You chose to use one or more of the SORBS.net RBLs for blocking (presumably without testing first), and then you were disappointed because you didn't get the results you expected? If you truly understood SORBS.net's criteria, and the purpose of RBLs in the first place, then there clearly would be no need to complain.
Responsible mail server operators often do the following prior to implementing any RBL in a blocking fashion:
- Understand the listing criteria (anyone who doesn't do this is definitely a gambler)
- Test it in tagged mode (this decision is subjective, but strongly recommended for those who aren't familiar with DNSBLs or spam fighting in general) and inspect the results periodically to verify accuracy
The reason this testing needs to be performed is that every mail server deals with different eMail traffic patterns (in part due to serving different users/purposes/etc.), and what works well in one environment could be a complete disaster in another.
One must also realize that it's not the fault of the DNSBL operator if legitimate eMail gets blocked (assuming that the criteria is being enforced without exceptions, as has always been the case with SORBS.net as far as I know), rather it's the fault of the spammer and the provider that doesn't terminate spammer accounts (I certainly don't want to receive eMail from ISPs that harbour spammers, and that's my absolutely undeniable right).
If you find that a DNSBL isn't working for you, two options that come to mind are to either combine it with a whitelist (it's entirely up to you to make exceptions to rules on your own systems) or stop using it entirely. In my experience, DNSBL operators typically don't care if you don't use their services, and often discourage relying on their databases anyway -- they're merely providing the listing service for free in the hopes that it will help to make the internet better for everyone, which is a noble attitude worthy of much respect.
I use almost a dozen DNSBLs on all my servers, and the logs consistently indicate a rejection rate of over ~95%. Users are pleased because they get a lot less spam through our systems than they do from most others. Occasionally there is a question about someone's eMail getting blocked, and we handle these on a case-by-case basis (sometimes we refuse to whitelist an ISP, typically because of their attitude or history, but this is rare because most of the time they're willing to terminate spammers to get {and remain} de-listed).
An important part of using a DNSBL is to require those who are blocked to clean up their act. It's a social responsibility that all mail server administrators have, and it's so easy to encourage clean-up on the other end simply because they're the ones who have to take the appropriate steps to get de-listed (there's no need for whitelisting if they actually do get rid of the spam problem on their end, after all). And if they just whine about their upstream provider not fixing it, then that's still their problem (they can always take their business somewhere else -- this is a very compelling way to find out how seriously the take the spam problem, since supporting a spam-friendly upstream provider is approximately as bad as harbouring spammers directly).
I assume Intel knows enough about Faraday Cages (and similar solutions) to have this potential nightmare of a problem nipped in the bud. Perhaps one possible solution might also be to build this entire farm if miniature magnets on one giant high-powered magnet to prevent lesser magnetic fields from causing problems?
Using magnetism is a fantastic alternative that will certainly give IBM a run for their money with their recent research on copper-based processors.
> ... most of the country voted for him [Bush] ...
Really? I thought Al Gore got more votes, but the Republicans simply won in more States due to the way the electoral system works in the USA. Was the balanced Canadian Government operated news (CBC) mistaken about this?
> So lets see.... FireFox duplicates Opera features,
.REG files).
> then IE duplicates FireFox features...
>
> Whoa! I must be using IE version 9 right now!
Don't worry, you're not -- Opera and FireFox don't have the infamous "security holes" features that IE does (e.g., auto-download-and-merge of
I used to talk on a cell phone while holding it next to my head, and found that I'd get headaches (usually worse on days I was talking for longer periods of time). Now that I use a small headset that allows me to keep the cell phone at least 2 imperial feet away from my head I no longer get the headaches.
In summary, I don't care what the research says -- I'm convinced based on personal experience that cell phones aren't good for our brains (that, plus the fact that microwaves cook everything, and lower power microwaves just take longer to cook things; just consider how much longer it takes your microwave oven to cook meat or noodles when set to "low power" mode and the conclusion that "less != none" should be confirmed in this context for anyone who has doubts).
> He was late.
That's far better news than "she was late."
By default Opera identifies itself as "Internet Explorer" and some webmasters incorrectly use this information to determine which web browsers are more commonly used.
If you're a big fan of Opera, like we are (and it's already standard at some of the companies we regularly deal with too), you can actually cast an implied vote by setting the default to "Opera" in the settings:
1. "Tools" menu
2. "Preferences" item
3. "Advanced" tab
4. "Network" option (on the left-hand side)
5. "Browser identification" pull-down menu
And if you find a web site that lectures you on which web browser they think you should use, then send a friendly message to the sales department (don't bother the webmaster because given their attitude they'll probably just ignore you and not bother to let the sales people know) telling them that you were interested in their product but since you can't use Opera to browse their web site that you'll just have to find the needed information somewhere else.
By default Opera identifies itself as "Internet Explorer" and some webmasters incorrectly use this information to determine which web browsers are more commonly used.
If you're a big fan of Opera, like we are (and it's already standard at some of the companies we regularly deal with too), you can actually cast an implied vote by setting the default to "Opera" in the settings:
1. "Tools" menu
2. "Preferences" item
3. "Advanced" tab
4. "Network" option (on the left-hand side)
5. "Browser identification" pull-down menu
And if you find a web site that lectures you on which web browser they think you should use, then send a friendly message to the sales department (don't bother the webmaster because given their attitude they'll probably just ignore you and not bother to let the sales people know) telling them that you were interested in their product but since you can use Opera to browse their web site that you'll just have to find the needed information somewhere else.
Profanities seem to be more popular on systems that filter it thanks to the cuss-filter words you included for everyone's convenience.
When it comes to the time and effort required to built a cuss-filter into a game chat system, I've often wondered "Wouldn't it be better for the programmers to just focus on making the game better since people will just find ways around it anyway?"
Only for playing Sony's CDs.
That never happens to me on my Windows 3.11 computer for some strange reason. Hmm, maybe I'm doing something wrong?
> ... thought America was different than the rest of the world when I moved here ...
It is. Music and software piracy run rampant in many other countries, and those governments seem to do very little, if anything at all, to prevent it.
Perhaps the underlying message here is that the Sony Rootkit is some subtle form of a hazing ritual?
> ... with this rootkit even if you clicked on ...
> disagree it would install on your computer
Isn't that what SpyWare is infamous for?
What EULA? When I buy a music CD there is no contract that I'm aware of that I had to sign before opening the package and inserting it in any CD player -- I simply had to walk down to the local music store and pay for it, and that's the condition that most people who buy music CDs are aware of.
What fines? I want to know more! (I missed that one because I've been busy spanking spammers lately...)
Blogs are a fad right now. Let's see how they're doing again in ten years.
I guess flip-flops are only natural in the computing industry -- after all, binary is our ruling numbering system.
Sorry, I forgot to include the SARCASM tags. ;-D