If I were able to block 100% of spam and let through 100% of legitimate mail, then I have still failed because of the fact that I still need to do blocking. My mail server still gets pounded by spam. And if was able to do that, and everyone else copied from me to do so, too, then spammers would figure out how to make their spam look like legitimate mail, and then we'd be back to square zero.
See... the goal is not (entirely) about preventing spam from getting into my mailbox. The goal is to not have the costs of spam imposed on me, my network, my servers, my users, and my customers.
Those who choose to use providers that let spammers (actually, they are taking a pink commission to do this) cause me to lose computer and network resources are not really all that legtimate, IMHO. So while they are not necessarily directly responsible, they are indeed indirectly responsible. So I have no qualms about forcing them to go through hoops, like getting whitelisted in advance, to be able to have their email accepted. At least I'm allowing almost every network to make an SMTP connection so I can see if the email is from a known (whitelisted) legitimate sender.
Much of this issue is about knowing in advance if the email is legitimate. If I whitelist your email address, then I am considering you to be a legitimate sender. Even still, it's a weak form of identity, since a spammer might discovered that you are whitelisted and start forging your identity by using your email address as the sender on spam.
You are responsible for making your email rise above all the spam in terms of legitimacy (while spammers are trying to make theirs rise above yours). Only if I known it to be legitimate can I consider it to be so.
If all the legitimate customers of some ISP that harbors spammers were to leave it, then that ISP would be nothing but illegitimate, and then everyone could block them solidly, right at the border routers. Some of those ISPs might not be able to survive without some legitimate customers. In part legitimate customers are the hostages used to prevent being totally blocked. Are you a hostage for your ISP's partnership in crime with spammers?
If every ISP feared total loss of all legitimate customers (which will lead to total blockage of their network and in turn loss of their spammer customers, too), they would not host spammers.
I do block the masses of cable and DSL connections. Does that mean your home mail server on such a connection gets affected? Probably so. I do that blocking by (sub)domain name, so if by chance you have one of the few clueful ISPs that do this, and get static IP, you can have your address identified in reverse DNS with a name different than the ISP's generic identity (such as by using your own domain name). Then you can get through. Or use an outside mail forwarder / smarthost (in many cases the provider of those cable or DSL lines does not have their own mail servers blocked, so try using those).
I probably would get lots of zombie spam from US DSL links, too, were it not for the fact that I block all those. I'm working on blocking all the Chinese networks, now. I think I have most of China-Telecom blocked. But there is definitely a lot of spam coming in from spamware driven servers in China.
I run some open spamtraps that don't block anything. They get lots of spam from all places. But lots of the zombie spam from US DSL links does indeed point back to Chinese web servers. But who knows where the control of those zombies is coming from, since the DSL providers won't help. So if my blocking of DSL "accidentally" also blocks their mail servers, do I care? No.
Certifications tend to test relatively benign stuff for the weak minded people who have no clue (but at least known they don't have a clue). It tests to make sure it indeed works under Linux or whatever. It tests to make sure it conforms to standards (doesn't install components in strange places, etc). It makes sure things like security protocols are correctly chosen (don't use MD4 when SHA1 is called for).
One thing certifications lack, however, is testing for bugs. And this not easy to do because the location of bugs are not documented in advance of discovering them. It would be nice to have a certification that there are no buffer overflows, for example. The OpenBSD developers are certainly working hard to eliminate exploitable bugs like that, but it can never be 100% certain.
The real problem with certification isn't exactly that it can't check for bugs like that, but rather, that it is a lengthy process and holds up replacement versions that correct such bugs that are discovered. This is especially so with government certifications which can sometimes take two years or more to complete, and applies only to single specific versions. The end result of requiring software be certified is to slow down your ability to respond to and deal with security exposures and critical malfunctions that are discovered after the fact.
Maybe what we really need is a certification of certification processes to help us choose a good certification process. And then we need a certification of the certification of the certification process. And so on. And so on. Yeah right.
Whether there is gain or not is not for them to really decide. Standards are not about making usability decisions. Standards are about making things work in expected ways. Once the feature is in there, the fact that many people do use it shows their perspective is actually wrong. But target does NOT have to mean a new window. It can be a new tab. It can be whatever the user/browser wants it to be, since it's just a name. The fact that a browser makes a new window when a target with that name does not yet exist is really an implementation or configuration choice.
Would they have really depricated these features if there was no Javascript?
Had it never been there in the first place, and had browser developers been smart enough to make a configure option to "always open new window for inter-host hyperlinks", perhaps we would not be in this mess. Maybe if W3C were to define some mandatory browser features to get browser developers to do things like this, it might be better.
The biggest problem with the standards isn't that Javascript is included as a standard. I do think it should be standardized. Instead, the biggest problem is that the rest of the standards are presuming that Javascript will be available, will not be disabled, and will not be filtered out at the proxy. Things like depricating useful features in HTML and making them only available via Javascript is where the W3C has gone mad. IMHO, the whole web standard needs to just start all over from scratch (viable because browsers can be made to deal with more than one standard).
Making it so that the DOM for any one host:port (or host:port/~user if the URI begins with ~) is 100% isolated from the DOM for any other host:port could fix the problem posed by this article. But if a browser chooses to hack that in without it being defined in the standard, things can break in ways unexpected by the designers (they might be trying to do cross-host DOM stuff). So the standards people need to deal with this.
But since Javascript, or any other client side programming, is fundamentally flawed, standards should be designed to work, and work as well as they can, even if all client side programming is unavailable. That means things like target= in the <a> tag need to stay in. There's no valid reason it has to be done via client side programming.
Netscape 4.77 (an old browser) is immune. Of course, one of the reasons is this browser came out before the W3C start doing so much of the nonsense with "web standards". I use "web standards"; I just use the last version that worked right, not the latest version which should be marked as "still in beta test".
This is why latest web standards are broken. These standards should be marked as being "in beta test" or maybe even "in alpha test". I'll stick with the versions that work securely. Being able to manipulate the DOM (see, the problem is there is one) via Javascript is why things are insecure. The standards need fixing. And it might not happen until the entire W3C is replaced by people who are more security conscious.
As long as you keep your workflow computer off the net and don't try to surf the web or even read email with it, then you should be fine with Windows. You certainly don't want spyware, pop-ups, and zombies to interfere with your workflow. Although I am a big time Linux/BSD advocate, even I still use Windows to run the Visio application because there is nothing for Linux that comes even close (it's not on the net, doesn't get email, and can only web surf on my LAN web server). And unlike Photoshop or other Adobe tools where there is a remote chance that some day Adobe might port it to Linux, this is unlikely with Visio since Microsoft bought out Visio.
You are right that in the specific purpose applications arena, Linux (as a platform) does have to play catch-up. In the office arena, it is catching up. There's enough of a user base for office tools that a sufficient number of experts are contributing to the development to allow that to happen. The photo and graphical user base is much smaller than the office (word processing, spread sheet, etc) user base, and that's not giving Linux a sufficient base to develop from. But if enough people who do this work do come over to Linux (and they might as other reasons to avoid Linux fall, when their own needs are not as demanding in the photo and graphical areas), it can be possible for Linux to play catch-up, and perhaps succeed in doing so.
One thing that does hinder Linux is the fact that it has the perception that everything is free. But there are specialized kinds of software that just can't do this. So much purpose specific technology goes into it that software development costs are very high. You won't see free software succeeding at this (too few people and not enough resources). Free software is (and should) head in the direction of commodity software. Graphical software straddles these arenas... high end software serves the professional, while there are low end uses for the masses (like myself). Photoshop serves one and The GIMP serves the other (for now). Could things change in the future? Maybe. But it is still a few years off at best.
FYI, I was helping a friend of mine try to clean up his Windows computer he uses at work. It was majorly infested (at least one ad pops up every time he opens anything). Three different cleanup tools did put a dent in the troubles, but nothing could eliminate them. So we just backed up his important documents, wiped the disk clean, and re-installed XP. Now it was clean as a whistle. Two weeks later it was as bad as before. Unfortunately, this guy is too much of a Windows bigot to give even commercial Linux-based office desktop systems, just Sun's JDS, a try. So I just told him he'd have to live with re-installing every week (I'm going to build a Linux based CD to try to speed that up for him).
If a good programmer who also knew all the practices and specifications of what you describe in #3 were around, he/she could probably develop an add-on for this. While I do computers/networks for a living (which often includes programming, which I've done for 32 years, as well as a few open source projects), photography is only a hobby for me (2 film SLRs, 6 lenses, and since given up developing) so I really don't know these concepts in #3 besides what CMYK means, but little more than that. The point is probably what you are trying to say, anyway: how many professional photographers are also involved with Linux beyond being a hobby? The answer is probably above zero, but isn't going to be large enough for projects like The GIMP to have these things worked out any time soon.
You save up the money by starting out with the cobbled hacks. Eventually you've done enough work and brought in enough money (probably slowly) that you can afford to buy the more expensive tools. It's like a beginner photographer might be stuck with a cheap used camera like an old manual SLR. But eventually, as you make and save money, you can get that Hasselblad or Sinar.
I would agree with your assessment. However, if Linux is to ever become equally viable, there has to be a start to work up to this. Linux certainly is further along today than where Windows and Mac based applications were many years ago; it simply has more catching up to do. That won't happen if everyone avoid Linux. What you'll see, if Linux is to progress to be an equal, is those who really have a big preference for Linux over the others will be the first to go, and provide the feedback to improve it. Later, those with lesser preference will join in. And if all goes well, everyone will have an equal choice. Then there is always the possibility that Linux could pull ahead (it is ahead in some areas, now, which may be important to some photographers).
I've always wondered if maybe there was something to cold fusion, and that because it seemed absurd, that may this was a self-fulfilling prophecy. But in my case, it is something that has to be done by someone big enough to make it work, and I don't want to jeopardize it by announcing it before I convince someone to do it, since it is something that if 2 or more do it before the world hears about it, it won't work. I'm already approaching someone big enough to do it. But these things take time. I suppose I shouldn't have even mentioned this to begin with. And even this is not a magic cure; but hopefully it will make spam blocking much more effective with far less collateral damage.
The anti-spam idea I have is a totally different concept that what goes on SourceForge. It's not software. It's not something you install. More later if further study and arrangements show it to be viable.
This system (the one the/. article referred to) is more than just a C/R system. It does other lookups first to avoid sending the challenge. That could make C/R more palatable to some despite the general attitude that C/R is bad. However, the logic it uses could, instead, be used without the C/R part, and do a better job of quarantining email, or reducing the load applied to higher cost content analysis.
The camram system you refer to looks like yet another postage system. Anyone using mailing lists can't use that. The postage model is really unworkable. A workable solution must allow bulk email. The aspect of spam that needs to be addressed is the unsolicited part and even that's very hard to do.
I do have an idea that may work. It doesn't do any of the already tried methods. And it doesn't require any software to be installed on either end. But I'll hold back on announcing it until I am sure that it will work and can be deployed.
Implementing such a switch is not hard to do. And it certainly makes it hard (impossible) to block such spam sources by domain name. That's why blocking by IP address will still be around for the hard core spam houses. It's a little slower process to get new IPs. You either have to get your own portable space or use someone else's. That's why some spammers have resorted to using zombies (and thus, in turn, why end user IP pools are blocked). Blocking by domain name will still be used on the many cases of some bad ISPs and small businesses (for example a real estate agent I know of that was hopping around ISPs with his domain, and doing small scale spamming of around 25,000 emails).
This package just isn't going to get very popular. It is restricted to non-commercial use (perhaps you can buy a license for commercial use). And you have to sign up with IBM to get a download just to see if it's any good. And then there's a lot of extra stuff you have to have to run it. Maybe I should work on my own GPL open source version of this and do it as a pure TCP proxy front end so it works on any mail server (even for Exchange on Windows if on a different machine or under some emulator).
I have a generally very high success rate for reverse DNS lookups... at least where reverse DNS is actually set up. But there is an occiasional ISP that has such poor service that DNS lookups often fail. And I've even seen ISPs that, for some reason, only have random selections of their IP space set up with reverse DNS (out of a block of 32 there might be 25 with reverse DNS and repeated queries show consistency). One fundamental problem is ISPs hiring the bottom of the barrel in tech talent, especially at the manager level.
Reverse DNS should be a part of the service included with statically assigned IP addresses. Any provider doing any less is providing shoddy service. Reverse DNS is not dead. But being that it is based on a domain name system where spammers own tens of thousands of throw-away domains, it is getting to be of less value.
The reverse DNS for email is NOT for determining a match between the sender email address domain, and the server itself. All that needs to match is the hostname of the mail server itself, thus identifying who administers it (not necessarily who gets to use it). If the ISP administers the mail server, then the hostname in the PTR record of the appropriate in-addr.arpa zone will be a unique name in an ISP domain. The forward lookup then prevents forged PTR records by making sure the domain owner acknowledges that name belongs to that IP address.
While most ISPs do have reverse DNS on their mail servers, when you focus on just the servers that spam houses run from, this changes over to most do not. But what would really happen if everyone blocked on lack of matching rDNS is that the spammers would adapt and use it. Then we'd know what domain they are using. But many of them are now registering bulk volumes of domain names (if you're making a million dollars a month abusing other people's networks, registering 100 randomly generated domains a month is just a tiny cost of business).
Here's why - when you develop a piece of packaged software, sometimes you only have a short amount of time to establish your product as a viable entity in the marketplace. If your competitors could just look inside your source code to see how you accomplished a certain feature that their product doesn't provide, then your fledgling product would be neutralized almost instantly.
If you're talking about a sophisticated and innovative algorithm, maybe this will be the case. But it can be reverse engineered quite easily by simply following the basic flow of the machine instructions and producing work-alike high level code. Of course you lose valuable comments... maybe. Too often this rush-job commercial code doesn't even have such comments.
I did reverse engineering of a competitor's product once and succeeded in easily reproducing their proprietary compression algorithm (I needed to decompress it to build an import module for their data files to allow customers who switched to our software to use their old data). A few months later, the company I worked for bought out that competitor. When their software team found out we had an import program for their data files, their first question was how we did the decompression. It turns out they had lost the original source code when they were porting it from the mainframe to the PC, and were trying to figure out how to change to a new data format instead of reverse engineering their own code.
Now imagine that you're the one competing with somebody like Macromedia, or Adobe, or IBM. You have a great idea for a product, you've done your market research, and you want to make a go of it. Now imagine telling potential investors and customers that yes, because your product is Open Source, anybody can read the code and see how you solved a particularly prickly problem that up until now nobody else has tackled well. How much investment capital do you think you'll get? How many customers?
Under the GPL, I can give it away for free, but my competitors still can't integrate my code into their code (unless they want to GPL their own code). They'd have to understand the solution in a clean room scenario, and re-implement it (something they can do with the binary, anyway). So it is not actually an instant handover to your competitor. Then my business model will be free code, and paid for technical support. In the mean time, my competitors are struggling to debug their re-implementation, and making only one time sales. I'll be taking in incremental revenues from support.
Not every product is going to be able to benefit from this model. But more and more products will, and many do already. Some very specialized software will still be best kept closed source for now. But once it has been developed as open source, the days are numbered for the closed source version. Making the open source business model work depends on understanding that developmental thinking (e.g. intellectual property) is no longer the value commodity it once was. Just look at all the effort so many big software developers are making to get lower development costs by hiring people in lower cost of living countries. Thinking is cheap, and getting cheaper. Working for your customer or client is where the value is, and that's support.
The intellectual advantage does work, only when your competitor is using the same business model and doesn't have that particular innovation in their product. But when you are comparing business models, between one time software sales with mediocre support, vs. free software and paid for support from a vendor that gets its revenue only if it does the support job right, we will be finding that the latter model has more business advantage to business customers, and this in turn means a better market for the free software paid support model.
There is a type called "mixed". It allows anything. Arrays and mappings normally consist of mixed unless you specify otherwise (like "array(string)" for an array of strings). There are also tools for checking the types. And prototypes can specify more than one allowed type (for example you can get either an integer or a string). And you can prototype for any object class, or specific ones.
Having the flexibility of creating new classes and methods that can easily handle anything thrown at it I think is what is good.
Then maybe you should have prototyped the argument types so they would be checked or converted as appropriate. Dynamic typing does work (in some languages better than others); you just have to learn to use it right.
And how many people can search the tens of thousands of corporate web sites for job listings every day or week? What's needed is a central place for them all to go to (and the big commercial job boards are not accomplishing that).
Slashdot Mirror
If I were able to block 100% of spam and let through 100% of legitimate mail, then I have still failed because of the fact that I still need to do blocking. My mail server still gets pounded by spam. And if was able to do that, and everyone else copied from me to do so, too, then spammers would figure out how to make their spam look like legitimate mail, and then we'd be back to square zero.
See ... the goal is not (entirely) about preventing spam from getting into my mailbox. The goal is to not have the costs of spam imposed on me, my network, my servers, my users, and my customers.
Those who choose to use providers that let spammers (actually, they are taking a pink commission to do this) cause me to lose computer and network resources are not really all that legtimate, IMHO. So while they are not necessarily directly responsible, they are indeed indirectly responsible. So I have no qualms about forcing them to go through hoops, like getting whitelisted in advance, to be able to have their email accepted. At least I'm allowing almost every network to make an SMTP connection so I can see if the email is from a known (whitelisted) legitimate sender.
Much of this issue is about knowing in advance if the email is legitimate. If I whitelist your email address, then I am considering you to be a legitimate sender. Even still, it's a weak form of identity, since a spammer might discovered that you are whitelisted and start forging your identity by using your email address as the sender on spam.
You are responsible for making your email rise above all the spam in terms of legitimacy (while spammers are trying to make theirs rise above yours). Only if I known it to be legitimate can I consider it to be so.
If all the legitimate customers of some ISP that harbors spammers were to leave it, then that ISP would be nothing but illegitimate, and then everyone could block them solidly, right at the border routers. Some of those ISPs might not be able to survive without some legitimate customers. In part legitimate customers are the hostages used to prevent being totally blocked. Are you a hostage for your ISP's partnership in crime with spammers?
If every ISP feared total loss of all legitimate customers (which will lead to total blockage of their network and in turn loss of their spammer customers, too), they would not host spammers.
I do block the masses of cable and DSL connections. Does that mean your home mail server on such a connection gets affected? Probably so. I do that blocking by (sub)domain name, so if by chance you have one of the few clueful ISPs that do this, and get static IP, you can have your address identified in reverse DNS with a name different than the ISP's generic identity (such as by using your own domain name). Then you can get through. Or use an outside mail forwarder / smarthost (in many cases the provider of those cable or DSL lines does not have their own mail servers blocked, so try using those).
I probably would get lots of zombie spam from US DSL links, too, were it not for the fact that I block all those. I'm working on blocking all the Chinese networks, now. I think I have most of China-Telecom blocked. But there is definitely a lot of spam coming in from spamware driven servers in China.
I run some open spamtraps that don't block anything. They get lots of spam from all places. But lots of the zombie spam from US DSL links does indeed point back to Chinese web servers. But who knows where the control of those zombies is coming from, since the DSL providers won't help. So if my blocking of DSL "accidentally" also blocks their mail servers, do I care? No.
That almost makes me want to switch back to Sendmail from Postfix (which can't seem to handle something like that very well).
Certifications tend to test relatively benign stuff for the weak minded people who have no clue (but at least known they don't have a clue). It tests to make sure it indeed works under Linux or whatever. It tests to make sure it conforms to standards (doesn't install components in strange places, etc). It makes sure things like security protocols are correctly chosen (don't use MD4 when SHA1 is called for).
One thing certifications lack, however, is testing for bugs. And this not easy to do because the location of bugs are not documented in advance of discovering them. It would be nice to have a certification that there are no buffer overflows, for example. The OpenBSD developers are certainly working hard to eliminate exploitable bugs like that, but it can never be 100% certain.
The real problem with certification isn't exactly that it can't check for bugs like that, but rather, that it is a lengthy process and holds up replacement versions that correct such bugs that are discovered. This is especially so with government certifications which can sometimes take two years or more to complete, and applies only to single specific versions. The end result of requiring software be certified is to slow down your ability to respond to and deal with security exposures and critical malfunctions that are discovered after the fact.
Maybe what we really need is a certification of certification processes to help us choose a good certification process. And then we need a certification of the certification of the certification process. And so on. And so on. Yeah right.
Whether there is gain or not is not for them to really decide. Standards are not about making usability decisions. Standards are about making things work in expected ways. Once the feature is in there, the fact that many people do use it shows their perspective is actually wrong. But target does NOT have to mean a new window. It can be a new tab. It can be whatever the user/browser wants it to be, since it's just a name. The fact that a browser makes a new window when a target with that name does not yet exist is really an implementation or configuration choice.
Would they have really depricated these features if there was no Javascript?
Had it never been there in the first place, and had browser developers been smart enough to make a configure option to "always open new window for inter-host hyperlinks", perhaps we would not be in this mess. Maybe if W3C were to define some mandatory browser features to get browser developers to do things like this, it might be better.
You say:
I say:
The biggest problem with the standards isn't that Javascript is included as a standard. I do think it should be standardized. Instead, the biggest problem is that the rest of the standards are presuming that Javascript will be available, will not be disabled, and will not be filtered out at the proxy. Things like depricating useful features in HTML and making them only available via Javascript is where the W3C has gone mad. IMHO, the whole web standard needs to just start all over from scratch (viable because browsers can be made to deal with more than one standard).
Making it so that the DOM for any one host:port (or host:port/~user if the URI begins with ~) is 100% isolated from the DOM for any other host:port could fix the problem posed by this article. But if a browser chooses to hack that in without it being defined in the standard, things can break in ways unexpected by the designers (they might be trying to do cross-host DOM stuff). So the standards people need to deal with this.
But since Javascript, or any other client side programming, is fundamentally flawed, standards should be designed to work, and work as well as they can, even if all client side programming is unavailable. That means things like target= in the <a> tag need to stay in. There's no valid reason it has to be done via client side programming.
Netscape 4.77 (an old browser) is immune. Of course, one of the reasons is this browser came out before the W3C start doing so much of the nonsense with "web standards". I use "web standards"; I just use the last version that worked right, not the latest version which should be marked as "still in beta test".
This is why latest web standards are broken. These standards should be marked as being "in beta test" or maybe even "in alpha test". I'll stick with the versions that work securely. Being able to manipulate the DOM (see, the problem is there is one) via Javascript is why things are insecure. The standards need fixing. And it might not happen until the entire W3C is replaced by people who are more security conscious.
As long as you keep your workflow computer off the net and don't try to surf the web or even read email with it, then you should be fine with Windows. You certainly don't want spyware, pop-ups, and zombies to interfere with your workflow. Although I am a big time Linux/BSD advocate, even I still use Windows to run the Visio application because there is nothing for Linux that comes even close (it's not on the net, doesn't get email, and can only web surf on my LAN web server). And unlike Photoshop or other Adobe tools where there is a remote chance that some day Adobe might port it to Linux, this is unlikely with Visio since Microsoft bought out Visio.
You are right that in the specific purpose applications arena, Linux (as a platform) does have to play catch-up. In the office arena, it is catching up. There's enough of a user base for office tools that a sufficient number of experts are contributing to the development to allow that to happen. The photo and graphical user base is much smaller than the office (word processing, spread sheet, etc) user base, and that's not giving Linux a sufficient base to develop from. But if enough people who do this work do come over to Linux (and they might as other reasons to avoid Linux fall, when their own needs are not as demanding in the photo and graphical areas), it can be possible for Linux to play catch-up, and perhaps succeed in doing so.
One thing that does hinder Linux is the fact that it has the perception that everything is free. But there are specialized kinds of software that just can't do this. So much purpose specific technology goes into it that software development costs are very high. You won't see free software succeeding at this (too few people and not enough resources). Free software is (and should) head in the direction of commodity software. Graphical software straddles these arenas ... high end software serves the professional, while there are low end uses for the masses (like myself). Photoshop serves one and The GIMP serves the other (for now). Could things change in the future? Maybe. But it is still a few years off at best.
FYI, I was helping a friend of mine try to clean up his Windows computer he uses at work. It was majorly infested (at least one ad pops up every time he opens anything). Three different cleanup tools did put a dent in the troubles, but nothing could eliminate them. So we just backed up his important documents, wiped the disk clean, and re-installed XP. Now it was clean as a whistle. Two weeks later it was as bad as before. Unfortunately, this guy is too much of a Windows bigot to give even commercial Linux-based office desktop systems, just Sun's JDS, a try. So I just told him he'd have to live with re-installing every week (I'm going to build a Linux based CD to try to speed that up for him).
If a good programmer who also knew all the practices and specifications of what you describe in #3 were around, he/she could probably develop an add-on for this. While I do computers/networks for a living (which often includes programming, which I've done for 32 years, as well as a few open source projects), photography is only a hobby for me (2 film SLRs, 6 lenses, and since given up developing) so I really don't know these concepts in #3 besides what CMYK means, but little more than that. The point is probably what you are trying to say, anyway: how many professional photographers are also involved with Linux beyond being a hobby? The answer is probably above zero, but isn't going to be large enough for projects like The GIMP to have these things worked out any time soon.
You save up the money by starting out with the cobbled hacks. Eventually you've done enough work and brought in enough money (probably slowly) that you can afford to buy the more expensive tools. It's like a beginner photographer might be stuck with a cheap used camera like an old manual SLR. But eventually, as you make and save money, you can get that Hasselblad or Sinar.
I would agree with your assessment. However, if Linux is to ever become equally viable, there has to be a start to work up to this. Linux certainly is further along today than where Windows and Mac based applications were many years ago; it simply has more catching up to do. That won't happen if everyone avoid Linux. What you'll see, if Linux is to progress to be an equal, is those who really have a big preference for Linux over the others will be the first to go, and provide the feedback to improve it. Later, those with lesser preference will join in. And if all goes well, everyone will have an equal choice. Then there is always the possibility that Linux could pull ahead (it is ahead in some areas, now, which may be important to some photographers).
I've always wondered if maybe there was something to cold fusion, and that because it seemed absurd, that may this was a self-fulfilling prophecy. But in my case, it is something that has to be done by someone big enough to make it work, and I don't want to jeopardize it by announcing it before I convince someone to do it, since it is something that if 2 or more do it before the world hears about it, it won't work. I'm already approaching someone big enough to do it. But these things take time. I suppose I shouldn't have even mentioned this to begin with. And even this is not a magic cure; but hopefully it will make spam blocking much more effective with far less collateral damage.
The anti-spam idea I have is a totally different concept that what goes on SourceForge. It's not software. It's not something you install. More later if further study and arrangements show it to be viable.
This system (the one the /. article referred to) is more than just a C/R system. It does other lookups first to avoid sending the challenge. That could make C/R more palatable to some despite the general attitude that C/R is bad. However, the logic it uses could, instead, be used without the C/R part, and do a better job of quarantining email, or reducing the load applied to higher cost content analysis.
The camram system you refer to looks like yet another postage system. Anyone using mailing lists can't use that. The postage model is really unworkable. A workable solution must allow bulk email. The aspect of spam that needs to be addressed is the unsolicited part and even that's very hard to do.
I do have an idea that may work. It doesn't do any of the already tried methods. And it doesn't require any software to be installed on either end. But I'll hold back on announcing it until I am sure that it will work and can be deployed.
Implementing such a switch is not hard to do. And it certainly makes it hard (impossible) to block such spam sources by domain name. That's why blocking by IP address will still be around for the hard core spam houses. It's a little slower process to get new IPs. You either have to get your own portable space or use someone else's. That's why some spammers have resorted to using zombies (and thus, in turn, why end user IP pools are blocked). Blocking by domain name will still be used on the many cases of some bad ISPs and small businesses (for example a real estate agent I know of that was hopping around ISPs with his domain, and doing small scale spamming of around 25,000 emails).
This package just isn't going to get very popular. It is restricted to non-commercial use (perhaps you can buy a license for commercial use). And you have to sign up with IBM to get a download just to see if it's any good. And then there's a lot of extra stuff you have to have to run it. Maybe I should work on my own GPL open source version of this and do it as a pure TCP proxy front end so it works on any mail server (even for Exchange on Windows if on a different machine or under some emulator).
And the license sucks, too. It is restricted to non-commercial use.
I have a generally very high success rate for reverse DNS lookups ... at least where reverse DNS is actually set up. But there is an occiasional ISP that has such poor service that DNS lookups often fail. And I've even seen ISPs that, for some reason, only have random selections of their IP space set up with reverse DNS (out of a block of 32 there might be 25 with reverse DNS and repeated queries show consistency). One fundamental problem is ISPs hiring the bottom of the barrel in tech talent, especially at the manager level.
Reverse DNS should be a part of the service included with statically assigned IP addresses. Any provider doing any less is providing shoddy service. Reverse DNS is not dead. But being that it is based on a domain name system where spammers own tens of thousands of throw-away domains, it is getting to be of less value.
The reverse DNS for email is NOT for determining a match between the sender email address domain, and the server itself. All that needs to match is the hostname of the mail server itself, thus identifying who administers it (not necessarily who gets to use it). If the ISP administers the mail server, then the hostname in the PTR record of the appropriate in-addr.arpa zone will be a unique name in an ISP domain. The forward lookup then prevents forged PTR records by making sure the domain owner acknowledges that name belongs to that IP address.
While most ISPs do have reverse DNS on their mail servers, when you focus on just the servers that spam houses run from, this changes over to most do not. But what would really happen if everyone blocked on lack of matching rDNS is that the spammers would adapt and use it. Then we'd know what domain they are using. But many of them are now registering bulk volumes of domain names (if you're making a million dollars a month abusing other people's networks, registering 100 randomly generated domains a month is just a tiny cost of business).
Joe Marini said:
If you're talking about a sophisticated and innovative algorithm, maybe this will be the case. But it can be reverse engineered quite easily by simply following the basic flow of the machine instructions and producing work-alike high level code. Of course you lose valuable comments ... maybe. Too often this rush-job commercial code doesn't even have such comments.
I did reverse engineering of a competitor's product once and succeeded in easily reproducing their proprietary compression algorithm (I needed to decompress it to build an import module for their data files to allow customers who switched to our software to use their old data). A few months later, the company I worked for bought out that competitor. When their software team found out we had an import program for their data files, their first question was how we did the decompression. It turns out they had lost the original source code when they were porting it from the mainframe to the PC, and were trying to figure out how to change to a new data format instead of reverse engineering their own code.
Under the GPL, I can give it away for free, but my competitors still can't integrate my code into their code (unless they want to GPL their own code). They'd have to understand the solution in a clean room scenario, and re-implement it (something they can do with the binary, anyway). So it is not actually an instant handover to your competitor. Then my business model will be free code, and paid for technical support. In the mean time, my competitors are struggling to debug their re-implementation, and making only one time sales. I'll be taking in incremental revenues from support.
Not every product is going to be able to benefit from this model. But more and more products will, and many do already. Some very specialized software will still be best kept closed source for now. But once it has been developed as open source, the days are numbered for the closed source version. Making the open source business model work depends on understanding that developmental thinking (e.g. intellectual property) is no longer the value commodity it once was. Just look at all the effort so many big software developers are making to get lower development costs by hiring people in lower cost of living countries. Thinking is cheap, and getting cheaper. Working for your customer or client is where the value is, and that's support.
The intellectual advantage does work, only when your competitor is using the same business model and doesn't have that particular innovation in their product. But when you are comparing business models, between one time software sales with mediocre support, vs. free software and paid for support from a vendor that gets its revenue only if it does the support job right, we will be finding that the latter model has more business advantage to business customers, and this in turn means a better market for the free software paid support model.
There is a type called "mixed". It allows anything. Arrays and mappings normally consist of mixed unless you specify otherwise (like "array(string)" for an array of strings). There are also tools for checking the types. And prototypes can specify more than one allowed type (for example you can get either an integer or a string). And you can prototype for any object class, or specific ones.
Having the flexibility of creating new classes and methods that can easily handle anything thrown at it I think is what is good.
Then maybe you should have prototyped the argument types so they would be checked or converted as appropriate. Dynamic typing does work (in some languages better than others); you just have to learn to use it right.
And how many people can search the tens of thousands of corporate web sites for job listings every day or week? What's needed is a central place for them all to go to (and the big commercial job boards are not accomplishing that).