isn't this more of a "we are the true professional spammers, get the amateurs out of there" because the smaller players, by having less means, are diluting the market for the big guys?
at&t sold the trademark... and the ip got transfered to a lot of people sco's "SCO Unix" is the closest descendant left of SysV... but the trademark got sold to X/Open. You're right to say AT&T owned the Unix OS at one point, you just forgot that "ownership" is transferrable(let's not go into the argument whether this holds of ip or not however...) if you can own something, you can sell it
I might offer a suggestion...
Because a developer who already knows the field will need less training
Also the relationships between the data will be more obvious to a developer already familiar with the background... And usually never happen to show up during training... Nobody ever thinks about them until problem X occurs, this client already seems to know that, and wants a solution where developer A writes something, and BANG they don't have to see him again... instead of the ongoing relationship a solution that gets gradually defined would be(this approach might yield a superior product in the long run, but would be much more expensive)
actually you're confusing the record companies with the musicians...
Most artists DON'T receive more than say a dollar per 30$ album...
The RIAA, as I understand, is a membership organisation, whose sole point is to lobby for tighter copyright rules for the "Majors"(the members) while allowing them to point to "Indeps" (non-members) as proof that they don't have an illegal monopoly, despite the fact that each "artist", their product, signs an exclusive contract with a member...
If you can only buy a (insert artist name here) from one vendor, does that make it a monopoly? Now for a boy's band, I'd say no... but for a truly original artist?... that remains to be seen.
On another "note" (pun intented) is it normal that the "pressing and advetising" costs of each CD manage to be so much higher than the cost of producing the music? I don't think so...
But of course, the RIAA doesn't have much of a business the minute we decide music is an idea... and can be seperated from the medium...
owing to the fact almost no product will fit everyone's needs
here are aspects where you can compare what you will find
aspects of monitoring: -availability -uptime(subtly different from availability) -performance -security -capacity -log or otherwise event-based monitoring
nature of tools: -web based -daemon with web based front end -daemon without web based front end -other
language tool is written in, license and source -closed source, nuff said, available in licensed per cpu, licensed per target/service, etc... -open source, but with paid-for license that includes support(shameless plug... I do support for this kinda thing) -open source, roll your own support -perl -php -java -python -c/c++
integration with other products -by snmp traps -by snmp agent extensibility(smux/agentx/proxysnmp,etc...) -by proprietary methods -by sharing a RDBMS with another monitoring tool(usually used for things like remedy ARS)
measure of performance/capacity/throughput/usage -by the exec family of functions -by the language of choice's own internal library conventions -by snmp -by proprietary methods to a Manager of Manager or NMS system -by ciscoflow/other hardware vendor's protocol -by parsing logs -by exec-over-ssh-connexion
examples that don't fit neatly into any category that comes to mind is monitoring of backups(were they performed, how much, which files were skipped, etc, location in jukebox of which tape for which file...
Hope this helps you even draw the lines towards evaluating the product that meets YOUR needs
With the.com crash(mostly affecting webhosters, asp and other outsourcers), do you still believe in growth for linux on the server side.
As far as I know, everyone seems to take that as an article of faith, despite the fact that more of the "bricks and mortars" prefer iis because they have the personnel for it(MCSE, MCDA, MCSA, MCP). Further, do you believe certification can help fight this trend? As Linux would be fighting on equal ground, with certified personnel, and such?
Does the ibm/suse alliance help Suse sell lots of copies, or does it sell more hardware, or is it more of a 50/50 deal?
Does the trend towards virtualizing hardware help sell copies? What about using IBM OS/390 hardware, has that strategy panned out for Suse, as opposed to say I386 or IA-64 ?
Considering how hard spammers make it to track who I gave permission to(hint... it doesn't matter how little permission you give, people are going to take a lot) I'm saying that unless audiogalaxy SENDS all those emails for all those people, how can I know who they gave it to? Unless they PROVE they got my permission from audiogalaxy(in the original spam of course, so if it's false, into the spam bin BOTH go) then they are misrepresenting their commercial intent, which was a felony in most countries last I checked... I'm not saying audiogalaxy can't get funding that way, I'm saying the burden of proving that email is spam shouldn't be on the receiver, because the receiver pays the connectivity, and therefore the bill. The spammers are sending me a bill to pay, which I can only contest by generating an activity that makes me pay more... Talk about a circular loop.
As for complicity in a crime for agreeing to sell it... if it's illegal to sell a "permission based marketing target" then it's also illegal to sollicit permission to resell an address.
Hence, we go back to I gave my permission to audiogalaxy, if anyone wants to use that permission, they have to use audiogalaxy's mail server, and clearly state that is how the spam got to me.
But doesn't that "SCREAM" that selling "email-based permission" lists illegal? After all, if business A sells your email address for 2.95, and business B sells it to C for 5.95 and business C does something illegal with it, how would business A sue business C for illegal use? It can't, and that places the burden on the customer. But since you can't limit WHO they sell your "permission to" (obstruction of commerce) that means you're writing them a blank check, with little to zero chance of ever having your rights respected. (the amount of spam makes prosecution for a single spam unlikely in the extreme) YET each spam is an individual crime, that must be investigated seperately. There is also the question of just how "valid" the permission you gave to A for purpose X be translated to C for any purposes other than X... And with X usually being "promotions related to a product I bought" X is of little sale value to C... purpose Y is however, very valuable... Hence C wants to buy address "blue" from business A, for purpose Y, now if purpose Y wasn't known at the time permission was given, how can permission be considered to have been given(say permission to advertise an invention that didn't exist when blue gave permission to A)? Doesn't the burden it places on the victim(the person whose rights have been abused, by receiving mail whom in most other contexts would be considered illegal) signify to legislators that
1) to properly track when a permission is given, when most spammers close up shop within a few days and just reappear with the same list, under a different company, require an independant registry of permissions? 2) to be able to correlate permission with origins of spam, you require to be able to track the origin of any single email message. By that reasoning wouldn't sending a message with forged header be considered illegal until proven otherwise(a bit like how a radar detector or any other device that allows one to bypass enforcement of a law illegal)? 3) Since permission would have to be tracked by purpose and by sender, shouldn't access to that single registry be paid for to cover administration costs? And once headers are fully considered thrustworthy again, shouldn't it be possible to bill per spam sent?
I think those are all valid questions, that the legislators should consider
you got that backwords internships "stages" in french are "usually" not paid(basically the company can choose not to pay you) cooperative education programs are usually paid partly because in the coop situation, you work AND you go to school at the same time... so the work is not academically creditable... the classes are...
Considering the variety of bandwidth providers, acceptable terms of service(TOS) and all that, eventually, it will become a matter of taste, preference and terms that can be agreed with. How many subscribers want traffic shaping, inbound or outbound on their interface? Wouldn't customers PAY for making sure that the only traffic spikes they can get are mail or http related? I'm sure a lot of my hosting clients would love a system where they pay for the bandwidth they use, but that limits are in place to make sure excessive bandwidth usage is actually the usage they pay for.
Since DiffServ and other standards based solutions are ready to be implemented, perhaps you should consider talking to your most whiney clients about it?
Yes I know it doesn't apply to all clients, and not every provider has the extra router/switch cpu power to implement them on all links...
But wouldn't such a solution be a good way to keep the more demanding clients(increasing the value they get: bandwidth for the right traffic) and decreasing the tax hackers and Distributed DOS and misconfigured systems make them pay (for undesirable traffic). Maybe you should suggest this as a customer retention measure, for those clients where it makes business sense.
An API is a set of specifications programmers use in code(hence app. prog...) directly(which gets compiled to binary instructions LATER) The ABI is a set of binary instructions third party code can call directly... hence in the old DOS 2.1 and directly derivative, running on 8086 chips, the software interrupts could be considered part of an ABI to the OS and the hardware interrupts part of the ABI to the 8086 platform.
Ancient hardware used as an example to keep the number of API/ABI sets low... The newer the chips, the more "sets" of API/ABI's and individual API's and ABI's seem to appear
Too easy to advertise for your enemies then... And without a law that prevents forged headers, and smtp servers that make it IMPOSSIBLE to forge headers, you're condemning the innocent to benefit the guilty
isn't it more like they fear being sued under the current law, with the amount of opt-in mailing lists they have... with that number of users, I just shudder at the number of people who would say they didn't opt in, but actually did
Of course, if they got exempt, that would give them a competitive advantage against aol and almost all other isps, beyond that provided by having such a large and visible "front door" as hotmail...
Makes me think we should make verbs of more things, to combat the overproliferation of "hostile" trademarks and patents.
It's one of the few things were IP holders seem to have no defense against.
It's interesting that "you cannot make a trademark from a verb" seems to be because such a trademark would leave consumers with no defense against the limited monopoly of that trademark...
With bayesian filters strongly suggesting per-user preferences and smtp having a less-than-optimal way of dealing with such, do you see a future protocol emerging to replace smtp that would be less spam-friendly?
I know qmtp was proposed some time back, but that one's actually more spam-friendly(as it LOWERS smtp's latency).
Such a SUMTP (Spam-Unfriendly-Mail-Transfer Protocol) would probably clarify some headers like how to encode pgp/ s/mime keys and suchs ideas as the habeas swe headers in a less easy to prge manner...
Perhaps even supplying key-signed headers? So forged headers could be trivial to trace? What do you think of such an idea, or any ideas to use technology, on a server-wide base, to reduce spam or otherwise make it harder to send spam, without limiting the individual user's freedom ?
Well depending on the implementation, they could. It depends if they can even "key" it so the user himself can read it... Or they could even bombard your mailbox with emails you cannot read(and your isp either) A new tack on mailbombing... What scares me is if they could key it so you only have 15 seconds from the time you open the email, to the time it gets to the abuse box at your isp, before it becomes unreadable...
I guess there are more new perfectly good reasons to use non-MS mail clients
Where do we write the DOJ to order Microsoft to share source code with star office so they can write a DRM compliant-version(to minimise damage)
p.s. the only fair settlement to the microsoft monopoly trial would have been to give office or otherwise reimburse to everyone who bought a microsoft windows license... They made money from owning both the os and the application, it's only fair they have to lose money for doing both...
where does it say it's YOU and not Microsoft/RIAA
nowhere...
Nor will you find any...
With the complaints that people are too clueless/sysadmins are too overworked to secure their own systems... it's an excuse waiting to happen that DRM/trusted computing be used to remove control from the machine owners and give it to *ahem* "content providers"
PGP isn't DRM... it's not time sensitive.
If someone sells you a pgp key, it's your forever...
Microsoft's idea of DRM is if microsoft goes out of business, all DRM-protected materials become useless, so the DOC has to legislate to prevent Microsoft from ever doing so...
Slashdot Mirror
isn't this more of a "we are the true professional spammers, get the amateurs out of there" because the smaller players, by having less means, are diluting the market for the big guys?
at&t sold the trademark... and the ip got transfered to a lot of people
sco's "SCO Unix" is the closest descendant left of SysV...
but the trademark got sold to X/Open. You're right to say AT&T owned the Unix OS at one point, you just forgot that "ownership" is transferrable(let's not go into the argument whether this holds of ip or not however...) if you can own something, you can sell it
I might offer a suggestion... Because a developer who already knows the field will need less training
Also the relationships between the data will be more obvious to a developer already familiar with the background... And usually never happen to show up during training... Nobody ever thinks about them until problem X occurs, this client already seems to know that, and wants a solution where developer A writes something, and BANG they don't have to see him again... instead of the ongoing relationship a solution that gets gradually defined would be(this approach might yield a superior product in the long run, but would be much more expensive)
actually you're confusing the record companies with the musicians... Most artists DON'T receive more than say a dollar per 30$ album... The RIAA, as I understand, is a membership organisation, whose sole point is to lobby for tighter copyright rules for the "Majors"(the members) while allowing them to point to "Indeps" (non-members) as proof that they don't have an illegal monopoly, despite the fact that each "artist", their product, signs an exclusive contract with a member... If you can only buy a (insert artist name here) from one vendor, does that make it a monopoly? Now for a boy's band, I'd say no... but for a truly original artist?... that remains to be seen. On another "note" (pun intented) is it normal that the "pressing and advetising" costs of each CD manage to be so much higher than the cost of producing the music? I don't think so... But of course, the RIAA doesn't have much of a business the minute we decide music is an idea... and can be seperated from the medium...
Now to come out with a single "web server accelerator card"
.jsp pages etc...)
that does both ssl/cram-md5/AES/etc.. and gzip/zlib/other compression
I can see my clients salivating already(saving the processors for those
well except for the IO-bound jobs...
owing to the fact almost no product will fit everyone's needs
here are aspects where you can compare what you will find
aspects of monitoring:
-availability
-uptime(subtly different from availability)
-performance
-security
-capacity
-log or otherwise event-based monitoring
nature of tools:
-web based
-daemon with web based front end
-daemon without web based front end
-other
language tool is written in, license and source
-closed source, nuff said, available in licensed per cpu, licensed per target/service, etc...
-open source, but with paid-for license that includes support(shameless plug... I do support for this kinda thing)
-open source, roll your own support
-perl
-php
-java
-python
-c/c++
integration with other products
-by snmp traps
-by snmp agent extensibility(smux/agentx/proxysnmp,etc...)
-by proprietary methods
-by sharing a RDBMS with another monitoring tool(usually used for things like remedy ARS)
measure of performance/capacity/throughput/usage
-by the exec family of functions
-by the language of choice's own internal library conventions
-by snmp
-by proprietary methods to a Manager of Manager or NMS system
-by ciscoflow/other hardware vendor's protocol
-by parsing logs
-by exec-over-ssh-connexion
examples that don't fit neatly into any category that comes to mind is monitoring of backups(were they performed, how much, which files were skipped, etc, location in jukebox of which tape for which file...
Hope this helps you even draw the lines towards evaluating the product that meets YOUR needs
With the .com crash(mostly affecting webhosters, asp and other outsourcers), do you still believe in growth for linux on the server side.
As far as I know, everyone seems to take that as an article of faith, despite the fact that more of the "bricks and mortars" prefer iis because they have the personnel for it(MCSE, MCDA, MCSA, MCP).
Further, do you believe certification can help fight this trend? As Linux would be fighting on equal ground, with certified personnel, and such?
Does the ibm/suse alliance help Suse sell lots of copies, or does it sell more hardware, or is it more of a 50/50 deal?
Does the trend towards virtualizing hardware help sell copies? What about using IBM OS/390 hardware, has that strategy panned out for Suse, as opposed to say I386 or IA-64 ?
Considering how hard spammers make it to track who I gave permission to(hint... it doesn't matter how little permission you give, people are going to take a lot) I'm saying that unless audiogalaxy SENDS all those emails for all those people, how can I know who they gave it to? Unless they PROVE they got my permission from audiogalaxy(in the original spam of course, so if it's false, into the spam bin BOTH go)
then they are misrepresenting their commercial intent, which was a felony in most countries last I checked... I'm not saying audiogalaxy can't get funding that way, I'm saying the burden of proving that email is spam shouldn't be on the receiver, because the receiver pays the connectivity, and therefore the bill.
The spammers are sending me a bill to pay, which I can only contest by generating an activity that makes me pay more...
Talk about a circular loop.
As for complicity in a crime for agreeing to sell it... if it's illegal to sell a "permission based marketing target" then it's also illegal to sollicit permission to resell an address.
Hence, we go back to I gave my permission to audiogalaxy, if anyone wants to use that permission, they have to use audiogalaxy's mail server, and clearly state that is how the spam got to me.
But doesn't that "SCREAM" that selling "email-based permission" lists illegal?
After all, if business A sells your email address for 2.95, and business B sells it to C for 5.95 and business C does something illegal with it, how would business A sue business C for illegal use? It can't, and that places the burden on the customer. But since you can't limit WHO they sell your "permission to" (obstruction of commerce) that means you're writing them a blank check, with little to zero chance of ever having your rights respected. (the amount of spam makes prosecution for a single spam unlikely in the extreme) YET each spam is an individual crime, that must be investigated seperately.
There is also the question of just how "valid" the permission you gave to A for purpose X be translated to C for any purposes other than X... And with X usually being "promotions related to a product I bought" X is of little sale value to C... purpose Y is however, very valuable... Hence C wants to buy address "blue" from business A, for purpose Y, now if purpose Y wasn't known at the time permission was given, how can permission be considered to have been given(say permission to advertise an invention that didn't exist when blue gave permission to A)?
Doesn't the burden it places on the victim(the person whose rights have been abused, by receiving mail whom in most other contexts would be considered illegal) signify to legislators that
1) to properly track when a permission is given, when most spammers close up shop within a few days and just reappear with the same list, under a different company, require an independant registry of permissions?
2) to be able to correlate permission with origins of spam, you require to be able to track the origin of any single email message. By that reasoning wouldn't sending a message with forged header be considered illegal until proven otherwise(a bit like how a radar detector or any other device that allows one to bypass enforcement of a law illegal)?
3) Since permission would have to be tracked by purpose and by sender, shouldn't access to that single registry be paid for to cover administration costs? And once headers are fully considered thrustworthy again, shouldn't it be possible to bill per spam sent?
I think those are all valid questions, that the legislators should consider
you got that backwords
internships "stages" in french are "usually" not paid(basically the company can choose not to pay you)
cooperative education programs are usually paid
partly because in the coop situation, you work AND you go to school at the same time...
so the work is not academically creditable...
the classes are...
My old history books had
small computer standard interface
but the only place where it was standard was on a mac
Nice to see someone actually explain how "cyberturf" works, at least in the colo world. Right on!
Mod parent up!
Considering the variety of bandwidth providers, acceptable terms of service(TOS) and all that, eventually, it will become a matter of taste, preference and terms that can be agreed with. How many subscribers want traffic shaping, inbound or outbound on their interface? Wouldn't customers PAY for making sure that the only traffic spikes they can get are mail or http related? I'm sure a lot of my hosting clients would love a system where they pay for the bandwidth they use, but that limits are in place to make sure excessive bandwidth usage is actually the usage they pay for.
Since DiffServ and other standards based solutions are ready to be implemented, perhaps you should consider talking to your most whiney clients about it?
Yes I know it doesn't apply to all clients, and not every provider has the extra router/switch cpu power to implement them on all links...
But wouldn't such a solution be a good way to keep the more demanding clients(increasing the value they get: bandwidth for the right traffic) and decreasing the tax hackers and Distributed DOS and misconfigured systems make them pay (for undesirable traffic). Maybe you should suggest this as a customer retention measure, for those clients where it makes business sense.
An API is a set of specifications programmers use in code(hence app. prog...) directly(which gets compiled to binary instructions LATER)
The ABI is a set of binary instructions third party code can call directly...
hence in the old DOS 2.1 and directly derivative, running on 8086 chips, the software interrupts could be considered part of an ABI to the OS and the hardware interrupts part of the ABI to the 8086 platform.
Ancient hardware used as an example to keep the number of API/ABI sets low... The newer the chips, the more "sets" of API/ABI's and individual API's and ABI's seem to appear
Too easy to advertise for your enemies then...
And without a law that prevents forged headers, and smtp servers that make it IMPOSSIBLE to forge headers, you're condemning the innocent to benefit the guilty
isn't it more like they fear being sued under the current law, with the amount of opt-in mailing lists they have... with that number of users, I just shudder at the number of people who would say they didn't opt in, but actually did
Of course, if they got exempt, that would give them a competitive advantage against aol and almost all other isps, beyond that provided by having such a large and visible "front door" as hotmail...
Interesting distinction.
Makes me think we should make verbs of more things, to combat the overproliferation of "hostile" trademarks and patents.
It's one of the few things were IP holders seem to have no defense against.
It's interesting that "you cannot make a trademark from a verb" seems to be because such a trademark would leave consumers with no defense against the limited monopoly of that trademark...
With bayesian filters strongly suggesting per-user preferences and smtp having a less-than-optimal way of dealing with such, do you see a future protocol emerging to replace smtp that would be less spam-friendly?
I know qmtp was proposed some time back, but that one's actually more spam-friendly(as it LOWERS smtp's latency).
Such a SUMTP (Spam-Unfriendly-Mail-Transfer Protocol) would probably clarify some headers like how to encode pgp/ s/mime keys and suchs ideas as the habeas swe headers in a less easy to prge manner...
Perhaps even supplying key-signed headers? So forged headers could be trivial to trace? What do you think of such an idea, or any ideas to use technology, on a server-wide base, to reduce spam or otherwise make it harder to send spam, without limiting the individual user's freedom ?
Well depending on the implementation, they could. It depends if they can even "key" it so the user himself can read it...
Or they could even bombard your mailbox with emails you cannot read(and your isp either)
A new tack on mailbombing...
What scares me is if they could key it so you only have 15 seconds from the time you open the email, to the time it gets to the abuse box at your isp, before it becomes unreadable...
I guess there are more new perfectly good reasons to use non-MS mail clients
Errr well if they did SAY it... wouldn't the cat be out of the bag, so to speak?
Where do we write the DOJ to order Microsoft to share source code with star office so they can write a DRM compliant-version(to minimise damage)
p.s. the only fair settlement to the microsoft monopoly trial would have been to give office or otherwise reimburse to everyone who bought a microsoft windows license... They made money from owning both the os and the application, it's only fair they have to lose money for doing both...
where does it say it's YOU and not Microsoft/RIAA nowhere... Nor will you find any... With the complaints that people are too clueless/sysadmins are too overworked to secure their own systems... it's an excuse waiting to happen that DRM/trusted computing be used to remove control from the machine owners and give it to *ahem* "content providers"
PGP isn't DRM... it's not time sensitive. If someone sells you a pgp key, it's your forever... Microsoft's idea of DRM is if microsoft goes out of business, all DRM-protected materials become useless, so the DOC has to legislate to prevent Microsoft from ever doing so...
With the readership of the crypto-gram, why isn't it just in the "known mailing list" list?
I'm sure it would save a lot of trouble to everyone.
Of special Irony is that Microsoft produced a patch for the vulnerability months before the worm, and still they got caught by it...
Makes you wonder if even microsoft is on its own security mailing list for patches...