That would probably be why high level execs that get huge bonuses are still given options. The change was made because stock held more stable value than options, which bounce around quite a bit and are often worthless depending on the date of issue.
It's a tradeoff. Think of as a bonus which is based on the company's performance in the stock market.
It doesn't give any useful information to investors.
Options should be expensed when they are exercised. Not before.
The figure listed isn't necessarily a bad thing, and would be useful to project the outstanding value of outstanding options the copmany currently has, but it shouldn't be treated as an expense because the figure is misleading and hides the true operating costs of the company.
This is completely missing the point. There was a general statement being made that cross-platform development is complex. Of course it isn't.
And this is true why? Because you keep waving your hands and wishing it so?
However, if for political reasons, you deliberately choose not to use cross-platform tools, then of course cross-platform development is tricky! This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform.
This is why you're trolling, as you are assuming information that you are not privy to. For MS, the most likely reason is that they choose not too because there is no return on their investment for supporting additional platforms.
This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform.
On what planet do you live? Walk into a software store and see how many cross platform applications you see. Not "applications available on more than one platform", but true cross platform applications. How many businesses do you know of that develop on MS platforms using MS tools -- those things sure as hell don't make for terribly portable software.
Oh come on, there is no evidence for this. What is mediocre about widely used portable applications like Emacs, Eclipse, Apache, PHP or any of a thousand high-quality programs that run on Linux, Mac, Windows etc.?
I'll rephrase that then. All of the cross platform applications that I have personally used on multiple platforms fails one of the following tests:
1) It doesn't add complexity 2) It doesn't require more development work 3) It doesn't require more testing 4) It looks and feels like a native application on each platform
I dislike emacs with a passion, but it is generally an acquired taste so I won't comment on it further. I've never used Eclipse. I've only used Apache on Linux, so I can't say how well it fits in a windows environment -- but I'd be willing to bet it doesn't "work" like typical Win32 services (if you have to edit anything in notepad it fails test 4). PHP works well (let's throw in my favorite interpreted language, Perl). Hell, lets go and point out some more applications -- Mozilla, which is a nice piece of software but fails conditions 1, 2, 3, and 4 hands down. PVCS version manager sucks rocks and fails 4 and adds "slow and buggy" to the list which is probably a result of a combination of 1, 2, and 3. With OpenOffice, I can't speak for 1 through 3 as I haven't tracked that project much, but it certainly fails test 4. Do I really need to keep going?
So what have I established here? The only really good cross platform applications are the ones who depend on the lowest common denominator across all of the platforms. In this case, only consistent thing between all of the platforms being used is how the command line works -- and hey, what do you know, I like the way most of those ended up...
However, the article seemed to contain an attempt to justify not writing portable code for technical reasons, which don't stand up to scrutiny. [...] This is all completely irrelevant. A point was being made that cross-platform development made software complex. This is simply just not the case, and no evidence has been given to support this statement.
I certainly haven't been convinced of that. You seem keen to ignore several points against that arguement as well. The point is also that it adds complexity and cost to software development, not that it makes software complex (the latter depends on how you define complex software).
I would encourage you to demonstrate to me how testing complexity does not rise each time an addition platform is introduced. I would encourage you to demonstrate how development effort is not impacted by requiring the development of additional 'portable' libraries
This is certainly not true now, and has never really been the case. Now, you use Java: cross-platform support is almost no effort at all. Before Java became fast enough for general use, you could have used C++ (or a variety of other languages) with cross-platform libraries and APIs such as TK.
That has to be the most nieve statement I've ever seen. This is Microsoft we're talking about. "Sure, use products from your self proclaimed arch enemy Sun" and "Include so much code from 3rd parties that your per unit product cost doubles". That leaves them with the option to writing their own cross-platform toolset, which leaves us back at the original point. It's expensive.
Additionally, using cross platform tools does NOT do anything to help with the testing cost. You still need to test all of those other platforms. Initial cross platform development cost is cheap -- you just write it and hope it works. Testing is expensive as hell. Then fixing bugs on one platform without introducing another bug on a different platform is also expensive as hell. Cross platform libraries and APIs aren't a magic pill that prevents this. It makes it easier to some extent, and might even work well for a small piece of software, but it's nieve to expect everything to work with the same cost.
This also assumes that there are cross platform APIs and toolsets to do on multiple platforms everything you want to do.
And on top of that, you assume that all platforms have an equal feature set, and that using the cross platform GUI libraries allows you to create a usuable and responsive UI that does what you need it to do (you're often limited to a certain subset of functionality).
Again, this is just not true. You let other people (the suppliers of the cross-platform libraries) do the work. There may be some increase, but its nonsense to say its 'exponential'.
Again, you've forgotten the test vector. And it does increase the Unknowns, which by inference increases complexity -- the simple case goes from is "does my software work on my platform?" to "does my software work on platform x, y, and z?", "does platform z need additional work to support this feature that x and y have native support for?" etc.
Unless you are doing something highly specific (like insisting that something non-portable like COM is involved in your application), its hard to see exactly why non-portability should not be a goal - its a good investment both for the developer and customer. Of course, Microsoft has other motives.
Portability for applications gives you mediocre software. If it doesn't, then everyone who's done it has only succeeded in writing mediocre software. Customer's don't demand it. Developers don't generally care. It isn't a goal. The only reason to make it a goal would be for a bullet item on the box, and I guarantee you someone look at it will scratch their head, ignore it, and move on to the next bullet item.
And the troll peeks it's head out finally, ignoring all logic and pulling the "it's Microsoft, they do everything because it's evil" card, and it couldn't possibly be because it's the right attitude to take.
Software should be designed for the platform it's running on. Every operating system has a different UI "feel", with a different featureset available. You can't reproduce the unique feel on each platform with cross platform tools, and you are left with a least common denominator problem when using OS features. The latest version of Office for the Mac wouldn't be suck a kick ass piece of software if it were written with a cross platform toolset. The internals are also fairly easily ported over -- they just replace the UI code to make something which gives a good experience on the OSX platform.
Portability for NT was not just for the basic 'system'; it included lots of additional applications and tools....all installed with NT and making up the operating system...
This is just plain ignorant nonsense. Good cross-platform development tools have been available for decades. Cross-platform support is not 'beyond the reach' of any developer and never has been, if you pick the right libraries and tools. (I talk from experience - I was developing cross-platform GUI applications that ran on Unixes and DOS 20 years ago). Writing code that is limited to a restricted number of platforms is simply bad coding, and there is no excuse for it.
This doesn't refute the main point that cross-platform support is incredibly expensive to implement and test. Nor does it refute the point that developing in a cross platform environment is slower. It also limits design choices to a least common denominator factor (ie: you're limited to stuff available on all platforms, or you're forced to write your own), it increases complexity of a project exponentially, and it increases the number of unknowns in a project appreciably.
This doesn't mean that you don't write code that CAN be portable, it means it isn't a goal of your project. Which, by extension, says not to waste time on a non-goal.
And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
Last time I checked an OS is considered system software.
There is no such thing as "zero defects" in a large software project. There is only a concept of "zero known defects." Every time you make a change to your code, you risk introducing an unknown defect. As you approach the end of the development cycle, getting down to zero known defects is actually detrimental to the quality of the sofware, as unknown defects are introduced which may be far worse than the defects you fixed. And as you're at the end of the development cycle, test doesn't have enough time to find those defects so your product ships with poor quality.
The reason that the Xbox hasn't challenged the PlayStation 2 is that when you walk into a GameStop, there's an entire wall of PS2 games - plenty of good titles, at that - and three little rows of stuff that's either terrible (Outlaw Golf, anyone?) or available on PS2.
Right. And just WHY are there more games for the PS2 than the Xbox? While not the only reason, the fact that the PS2 was out first and all by itself for over a year probably doesn't hurt that situation much.
...until you wanted to do a document header. Or footnotes. Or you wanted to easily manipulate/modify a table. Or you want a headache inserting an image into your document. Or you wanted to take advantage of the 'track changes' feature when your document is reviewed by a peer. I could keep going on, but I won't.
For you, it makes sense, because you probably don't do anything more than basic word processing. If you start going through the laundry list of things that both applications are capable of, and then merging them so that it is easy to use and accomplishes the desired function for both DTP users and word processor users, you're going to find that they conflict significantly.
Copy protection is implemented to protect their copyright -- the act of copying copyrighted material is a voilation of copyright. It is also unlawful except in cases where fair use applies.
The grandparent quoted the summary, and the respondant said it didn't matter because any and every claim in the patent stands on it's own. The summary is a summary, not a list of claims.
That depends on how the claims are structured. Claims can stand alone or depend on another claim. Dependent claims only apply when the claim they are dependent on are also implemented.
In factory radios these days, you need to enter a "key" into the radio after it loses power before it will function again. It is a theft deterrant. The independent shop can't do anything without the key, because after they plug everything back in they'd have no way of testing it.
Your in-law should have gotten the key when he took delivery of the car from the dealership. However, the dealership should be able to look up the key if it gets lost.
You don't have to carry it with you wherever you go.
For $20 more than basic landline phone service you get a phone you can take anywhere you want (like on roadtrip where you may need to call for help if your car breaks down), has caller id, voice mail, and (the big one) free long distance.
"Young people" skip the landline because it is more cost effective to only use a cell phone.
Skipping the Linux v. Windows v. Sun debates. The main gist of the article is that there are more servers being thrown up at a significantly less cost.
You've obviously never seen how much it costs to purchase an Oracle license...
What kind of freaky troll logic is this? "Even though it didn't show an error message, I will insist that it did, because there was code that could do it if they wanted it to (even though they didn't)."
Also Microsoft wrote code in thier apps that generated false error messages in some dos replacements, giving the false illusion that the dos replacement was buggy or incompatable. FUD wasn't used because microsoft was feeling sadistic, it was used because it worked.
The message was only present in *beta* versions of Windows 3.0, and was non-fatal. It was not present in the released version.
DR-DOS 6 actually did not emulate some internal data structures Windows 3.1 used, and would cause Win3.1 to crash under certain conditions. These problems were corrected in a patch which was released ~6 weeks after Win3.1 came out.
I've seen other slide decks with these figures (http://download.microsoft.com/download/1/8/f/18f8 cee2-0b64-41f2-893d-a6f2295b40c8/388,31,Performanc e: Text Rendering Pipeline Throughput) has approximate estimates based on a dual proc 2.2ghz Xeon w/1gb of ram.
For comparison, the software estimate was 105,000 glyphs per second.
Let me get this straight...You told XP to blow away a partition you wanted to save, and that was XP's fault how? MS software is not without faults, but normally complaints do not focus on how it does what you told it to do...
Those weren't MS recommendations, nor were they based on any information from MS. Those requirements were from some reporter pulling numbers out of his ass.
Suppose spammers set up and SPF record for 0.0.0.0/0
No effect. Though I suspect you're trying to say "what if the spammers spoof the ip of a valid email server", which is an issue but not a large one due to the way sequence numbers are generated these days.
Suppose the spammer is using a DCHP IP address.
Also no effect. The spammer must send "mail" from an IP that is associated with the SPF record for the domain they are claiming to send mail from. In other words, this prevents spammers from sending mail which claims to be from domains they do not control.
Suppose the spammer is sending their spam through the corporate mail server at a major ISP (who let them, in a pink contract).
This in and of itself does not stop spam. It *does* make it one hell of a lot easier to filter it.
Suppose the spammer is using trojaned machines in Europe and China, and other parts of the world where US law doesn't apply.
This is the only real vulnerability left. This can be trumped by requring authentication before sending mail on an SMTP server (which is just a good idea period...). And if a certain domain has a problem with sending out spam, and you don't know anyone on that domain.. it's rather trivial to filter it out (per the previous point).
SPF will have zero affect on the amount of spam being sent, and will most likely increase the amount being received, until mail admins figure it out.
You seem to have a fundamental misunderstanding of what SPF is and how it works.
It is a mechanism to associate ips of valid mail senders for a domain name in the domain record. It is not a centrally managed list of ip's that are allowed to send mail for certain domains.
Slashdot Mirror
That would probably be why high level execs that get huge bonuses are still given options. The change was made because stock held more stable value than options, which bounce around quite a bit and are often worthless depending on the date of issue.
It's a tradeoff. Think of as a bonus which is based on the company's performance in the stock market.
It doesn't give any useful information to investors.
Options should be expensed when they are exercised. Not before.
The figure listed isn't necessarily a bad thing, and would be useful to project the outstanding value of outstanding options the copmany currently has, but it shouldn't be treated as an expense because the figure is misleading and hides the true operating costs of the company.
This is completely missing the point. There was a general statement being made that cross-platform development is complex. Of course it isn't.
...
And this is true why? Because you keep waving your hands and wishing it so?
However, if for political reasons, you deliberately choose not to use cross-platform tools, then of course cross-platform development is tricky! This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform.
This is why you're trolling, as you are assuming information that you are not privy to. For MS, the most likely reason is that they choose not too because there is no return on their investment for supporting additional platforms.
This is the case for Microsoft, but its certainly not the case for anyone else, and these days the majority of code that is written IS cross-platform.
On what planet do you live? Walk into a software store and see how many cross platform applications you see. Not "applications available on more than one platform", but true cross platform applications. How many businesses do you know of that develop on MS platforms using MS tools -- those things sure as hell don't make for terribly portable software.
Oh come on, there is no evidence for this. What is mediocre about widely used portable applications like Emacs, Eclipse, Apache, PHP or any of a thousand high-quality programs that run on Linux, Mac, Windows etc.?
I'll rephrase that then. All of the cross platform applications that I have personally used on multiple platforms fails one of the following tests:
1) It doesn't add complexity
2) It doesn't require more development work
3) It doesn't require more testing
4) It looks and feels like a native application on each platform
I dislike emacs with a passion, but it is generally an acquired taste so I won't comment on it further. I've never used Eclipse. I've only used Apache on Linux, so I can't say how well it fits in a windows environment -- but I'd be willing to bet it doesn't "work" like typical Win32 services (if you have to edit anything in notepad it fails test 4). PHP works well (let's throw in my favorite interpreted language, Perl). Hell, lets go and point out some more applications -- Mozilla, which is a nice piece of software but fails conditions 1, 2, 3, and 4 hands down. PVCS version manager sucks rocks and fails 4 and adds "slow and buggy" to the list which is probably a result of a combination of 1, 2, and 3. With OpenOffice, I can't speak for 1 through 3 as I haven't tracked that project much, but it certainly fails test 4. Do I really need to keep going?
So what have I established here? The only really good cross platform applications are the ones who depend on the lowest common denominator across all of the platforms. In this case, only consistent thing between all of the platforms being used is how the command line works -- and hey, what do you know, I like the way most of those ended up
However, the article seemed to contain an attempt to justify not writing portable code for technical reasons, which don't stand up to scrutiny. [...] This is all completely irrelevant. A point was being made that cross-platform development made software complex. This is simply just not the case, and no evidence has been given to support this statement.
I certainly haven't been convinced of that. You seem keen to ignore several points against that arguement as well. The point is also that it adds complexity and cost to software development, not that it makes software complex (the latter depends on how you define complex software).
I would encourage you to demonstrate to me how testing complexity does not rise each time an addition platform is introduced. I would encourage you to demonstrate how development effort is not impacted by requiring the development of additional 'portable' libraries
This is certainly not true now, and has never really been the case. Now, you use Java: cross-platform support is almost no effort at all. Before Java became fast enough for general use, you could have used C++ (or a variety of other languages) with cross-platform libraries and APIs such as TK.
That has to be the most nieve statement I've ever seen. This is Microsoft we're talking about. "Sure, use products from your self proclaimed arch enemy Sun" and "Include so much code from 3rd parties that your per unit product cost doubles". That leaves them with the option to writing their own cross-platform toolset, which leaves us back at the original point. It's expensive.
Additionally, using cross platform tools does NOT do anything to help with the testing cost. You still need to test all of those other platforms. Initial cross platform development cost is cheap -- you just write it and hope it works. Testing is expensive as hell. Then fixing bugs on one platform without introducing another bug on a different platform is also expensive as hell. Cross platform libraries and APIs aren't a magic pill that prevents this. It makes it easier to some extent, and might even work well for a small piece of software, but it's nieve to expect everything to work with the same cost.
This also assumes that there are cross platform APIs and toolsets to do on multiple platforms everything you want to do.
And on top of that, you assume that all platforms have an equal feature set, and that using the cross platform GUI libraries allows you to create a usuable and responsive UI that does what you need it to do (you're often limited to a certain subset of functionality).
Again, this is just not true. You let other people (the suppliers of the cross-platform libraries) do the work. There may be some increase, but its nonsense to say its 'exponential'.
Again, you've forgotten the test vector. And it does increase the Unknowns, which by inference increases complexity -- the simple case goes from is "does my software work on my platform?" to "does my software work on platform x, y, and z?", "does platform z need additional work to support this feature that x and y have native support for?" etc.
Unless you are doing something highly specific (like insisting that something non-portable like COM is involved in your application), its hard to see exactly why non-portability should not be a goal - its a good investment both for the developer and customer. Of course, Microsoft has other motives.
Portability for applications gives you mediocre software. If it doesn't, then everyone who's done it has only succeeded in writing mediocre software. Customer's don't demand it. Developers don't generally care. It isn't a goal. The only reason to make it a goal would be for a bullet item on the box, and I guarantee you someone look at it will scratch their head, ignore it, and move on to the next bullet item.
And the troll peeks it's head out finally, ignoring all logic and pulling the "it's Microsoft, they do everything because it's evil" card, and it couldn't possibly be because it's the right attitude to take.
Software should be designed for the platform it's running on. Every operating system has a different UI "feel", with a different featureset available. You can't reproduce the unique feel on each platform with cross platform tools, and you are left with a least common denominator problem when using OS features. The latest version of Office for the Mac wouldn't be suck a kick ass piece of software if it were written with a cross platform toolset. The internals are also fairly easily ported over -- they just replace the UI code to make something which gives a good experience on the OSX platform.
Portability for NT was not just for the basic 'system'; it included lots of additional applications and tools. ...all installed with NT and making up the operating system...
This is just plain ignorant nonsense. Good cross-platform development tools have been available for decades. Cross-platform support is not 'beyond the reach' of any developer and never has been, if you pick the right libraries and tools. (I talk from experience - I was developing cross-platform GUI applications that ran on Unixes and DOS 20 years ago). Writing code that is limited to a restricted number of platforms is simply bad coding, and there is no excuse for it.
This doesn't refute the main point that cross-platform support is incredibly expensive to implement and test. Nor does it refute the point that developing in a cross platform environment is slower. It also limits design choices to a least common denominator factor (ie: you're limited to stuff available on all platforms, or you're forced to write your own), it increases complexity of a project exponentially, and it increases the number of unknowns in a project appreciably.
This doesn't mean that you don't write code that CAN be portable, it means it isn't a goal of your project. Which, by extension, says not to waste time on a non-goal.
12. Portability is for canoes.
And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
Last time I checked an OS is considered system software.
There is no such thing as "zero defects" in a large software project. There is only a concept of "zero known defects." Every time you make a change to your code, you risk introducing an unknown defect. As you approach the end of the development cycle, getting down to zero known defects is actually detrimental to the quality of the sofware, as unknown defects are introduced which may be far worse than the defects you fixed. And as you're at the end of the development cycle, test doesn't have enough time to find those defects so your product ships with poor quality.
The reason that the Xbox hasn't challenged the PlayStation 2 is that when you walk into a GameStop, there's an entire wall of PS2 games - plenty of good titles, at that - and three little rows of stuff that's either terrible (Outlaw Golf, anyone?) or available on PS2.
Right. And just WHY are there more games for the PS2 than the Xbox? While not the only reason, the fact that the PS2 was out first and all by itself for over a year probably doesn't hurt that situation much.
...until you wanted to do a document header. Or footnotes. Or you wanted to easily manipulate/modify a table. Or you want a headache inserting an image into your document. Or you wanted to take advantage of the 'track changes' feature when your document is reviewed by a peer. I could keep going on, but I won't.
For you, it makes sense, because you probably don't do anything more than basic word processing. If you start going through the laundry list of things that both applications are capable of, and then merging them so that it is easy to use and accomplishes the desired function for both DTP users and word processor users, you're going to find that they conflict significantly.
Because a good DTP program doesn't make a good word processor and vice versa.
Think about it: Do you want to do page layout crap when you're writing a letter to grandma?
Copy protection is implemented to protect their copyright -- the act of copying copyrighted material is a voilation of copyright. It is also unlawful except in cases where fair use applies.
The Nokia series 60 phones run Symbian OS.
The grandparent quoted the summary, and the respondant said it didn't matter because any and every claim in the patent stands on it's own. The summary is a summary, not a list of claims.
That depends on how the claims are structured. Claims can stand alone or depend on another claim. Dependent claims only apply when the claim they are dependent on are also implemented.
In factory radios these days, you need to enter a "key" into the radio after it loses power before it will function again. It is a theft deterrant. The independent shop can't do anything without the key, because after they plug everything back in they'd have no way of testing it.
Your in-law should have gotten the key when he took delivery of the car from the dealership. However, the dealership should be able to look up the key if it gets lost.
You don't have to carry it with you wherever you go.
For $20 more than basic landline phone service you get a phone you can take anywhere you want (like on roadtrip where you may need to call for help if your car breaks down), has caller id, voice mail, and (the big one) free long distance.
"Young people" skip the landline because it is more cost effective to only use a cell phone.
Skipping the Linux v. Windows v. Sun debates. The main gist of the article is that there are more servers being thrown up at a significantly less cost.
You've obviously never seen how much it costs to purchase an Oracle license...
What kind of freaky troll logic is this? "Even though it didn't show an error message, I will insist that it did, because there was code that could do it if they wanted it to (even though they didn't)."
You might want to read your own article.
"[...] the retail version of Windows 3.1 doesn't produce it, [...]"
Also Microsoft wrote code in thier apps that generated false error messages in some dos replacements, giving the false illusion that the dos replacement was buggy or incompatable. FUD wasn't used because microsoft was feeling sadistic, it was used because it worked.
The message was only present in *beta* versions of Windows 3.0, and was non-fatal. It was not present in the released version.
DR-DOS 6 actually did not emulate some internal data structures Windows 3.1 used, and would cause Win3.1 to crash under certain conditions. These problems were corrected in a patch which was released ~6 weeks after Win3.1 came out.
If Apple continues to patent its UI elements Microsoft is going to be in a lot of trouble and will be doing a lot of redesign or groveling at Apple.
Right, as if MS doesn't hold any patents that they could hold over Apple...
I've seen other slide decks with these figures (http://download.microsoft.com/download/1/8/f/18f8 cee2-0b64-41f2-893d-a6f2295b40c8/388,31,Performanc e: Text Rendering Pipeline Throughput) has approximate estimates based on a dual proc 2.2ghz Xeon w/1gb of ram.
For comparison, the software estimate was 105,000 glyphs per second.
Let me get this straight...You told XP to blow away a partition you wanted to save, and that was XP's fault how? MS software is not without faults, but normally complaints do not focus on how it does what you told it to do ...
Luser.
Those weren't MS recommendations, nor were they based on any information from MS. Those requirements were from some reporter pulling numbers out of his ass.
Suppose spammers set up and SPF record for 0.0.0.0/0
.. it's rather trivial to filter it out (per the previous point).
No effect. Though I suspect you're trying to say "what if the spammers spoof the ip of a valid email server", which is an issue but not a large one due to the way sequence numbers are generated these days.
Suppose the spammer is using a DCHP IP address.
Also no effect. The spammer must send "mail" from an IP that is associated with the SPF record for the domain they are claiming to send mail from. In other words, this prevents spammers from sending mail which claims to be from domains they do not control.
Suppose the spammer is sending their spam through the corporate mail server at a major ISP (who let them, in a pink contract).
This in and of itself does not stop spam. It *does* make it one hell of a lot easier to filter it.
Suppose the spammer is using trojaned machines in Europe and China, and other parts of the world where US law doesn't apply.
This is the only real vulnerability left. This can be trumped by requring authentication before sending mail on an SMTP server (which is just a good idea period...). And if a certain domain has a problem with sending out spam, and you don't know anyone on that domain
SPF will have zero affect on the amount of spam being sent, and will most likely increase the amount being received, until mail admins figure it out.
You seem to have a fundamental misunderstanding of what SPF is and how it works.
It is a mechanism to associate ips of valid mail senders for a domain name in the domain record. It is not a centrally managed list of ip's that are allowed to send mail for certain domains.