First off, you could submit patches to the projects in question (I've submitted a few that ended up in FC2). Also, you could submit a patch to Red Hat's Bugzilla. Easily done.
What I don't get is why the watermark thing works at all.
Has no one written a program to merge several films and subtract out the noise (e.g. watermarks)? I mean, comparing two videos and establishing which bits are identical IS old tech, no?
All you need is software like that and video from two theaters, and you should even be able to enhance the quality and remove motion.
Re:I'm with linus torvalds on this one
on
Browser Wars Mark II
·
· Score: 2, Insightful
When you speak of "most people", include in that the tens, if not hundreds of thousands who know nothing about computers, and so rely on the advice of a savvy techster they know or who is in the familly. Then think about the fact that those people (*wave*) are telling their parents/relatives/friends that they should avoid any browser that even looks at flash, popups, cookies, &etc. without asking first.
It's not about convinience. If it were, we'd all be using Macs. It's about dozens of things including security, market penetration, user acceptance, speed, standards compliance, developer evangelism, toolkit compatibility, desktop compatibility, pretty baubles, perception (sand or insane though it may be), anti-corporatism, pro-corporatism, various other flavors of politics, etc, etc.
Don't try to paint browser (or desktop or operating system, &etc.) selection as a simple issue which everyone approaches the same way.
You're seeing the past through rose-tinted glasses. Red Hat 7.0 was Red Hat's most reviled release and thousands swore never to use Red Hat again after it. To say that 7.3 was so good is perhaps the answer to your concerns. Don't install the.0 release... wait for the point release that addresses all of the problems people run into.
Seems like standard wisdom across the board for Red Hat, SuSE, Windows, MacOS, etc., etc.
This is as expected. Slash-trolls flamed Red Hat when they released their pre-release based gcc 2.96 (which Red Hat, or more to the point, Cygnus, was the prime mover behind in the first place) and then turned a blind eye when all of the complaints they had turned out to affect every other distribution that used gcc 3.0.... Change involves pain, and moving to a new compiler, desktop, kernel, whatever is going to cause its fair share. If you can't take that pain, wait for a point release.
Because the idea behind a community-based distro is that we're all helping to make it better. At first, that's chaotic, but we can fine-tune as we go. FC2.1 should be much more stable. If it's not then I would be concerned, but the idea that FC2 isn't rock solid doesn't shock or even concern me. I'll do my part (posting from an FC2 box now) and submit bugs when I can.
If we're unwilling to accept a release that changes and break things, how do we move forward with an OS made up of hundreds of packages that all have different timelines, goals, etc?
The bill, as I've read in other articles is agaisnt any service retaining information about the contents of people's emails. They can still scan it realtime and give ads based on keywords, but they can't store it in a database or share that information with other people.
Which is patently absurd.
Seriously, think about what it means to say, you can't store mail in a database. Ok, so hotmail is illegal in California? They certainly store mail in a database and perform searches against it...
The interesting thing about Gmail is that it applies Google searching technology to email.
What is the expected gain here? How is California protecting its citizens? To pass a law that says you can't give out information about a customer's email is one thing, but to say that you can't store it... well that certainly cripples mail technology.
Actually, code obfuscation explains a lot. I think perhaps these folks got ahold of RSA written in dc and it traumatized them so badly that they had to write a book condemning all of open source!;-)
So, indiscriminate blocking of outbound port 25 will have side-effects.
Both inbound and outbound blocking will cause problems for users like myself. In particular, it will cause those members of Comcasts user-base (like myself) who are looked at by our friends and family as an expert in such matters to not only choose a different ISP for ourselves, but to recommend that those we care about not use the service either. After all, an ISP that tries to choose which parts of the Internet you have a right to talk to is no better than a fancy BBS, and software that my mother might want to run tomorrow could be hampered by that kind of short-sitedness (e.g. if she wanted to host a mail server that I set up for her home business, which I'll be doing next month).
No, Comcast knows their customers because the people who set all of this up for them are a fair bit like me...
Besides, customers like me are gold to Comcast. We do all the right things to protect our systems from compromise, we evangelize new users, we test out new services and build future markets for them. Early adopters are exactly what Comcast wants.
That's a valuable resource, but the question was more directed at the people in the sufferer's family. There are also good support groups for them.
It can be very hard to cope with. You start asking yourself questions that you don't want to ask like, "is this person better with me in or out of their lives" and "what if they never 'get better'". It was a very difficult road for me, but I did it alone. In retrospect, I wish I'd gone to such a support group. It would have been good for me, but also for the person I cared about.
Homosexuality was in the DSM as a treatable psychological disorder up till 1973.
I knew someone would bring that up. Also remember that women and minorities had specific laws against them in the US up until the 60s, so I guess we can pick and choose which laws are real and which are not (I do anyway:).
Your metaphor escaped you there.
To render it a bit more accurate: There have been laws until recently against minorities and women, so you can't really say "it's against the law, so it's wrong" as an absolute. And guess what... you can't.
Ok, now back to the topic: the best resource is probably going to be support groups for families dealing with mental illness. I suspect your local hospital's mental health department will have such a group or at least a pointer on where to find one.
As someone who was in the union while working at UPS, I found that FedEx has same working conditions with same benefits at much greater pay
But then, for some reason you go on to say,
Why should UPS agree to the union's terms if it feels that it's not right?
Well, I guess the most obvious reasons are a) they weren't right and FedEx had demonstrated that by paying higher wages and being successful b) because being right doesn't help if your business suffers for it c) unless management and labor work together (ignoring the union for a second), the company fails and that makes responsibility to the company and to the stockholders the domain of both groups
I'm not a big fan of unions, but your logic is faulty.
First off, you cannot simply blame a union for the problems caused by a strike. The strike is a last-resort tool used in negotiating with management. When you point out that the strike hurt UPS so badly that FedEx gained ground against them, think about the fact that the company COULD have just agreed to the union's terms and ended the strike.
Now, the other side of that coin is that the union might have been unrealistic in their demands. In this case, the union kills the business either way, and it's a HUGE problem that unions have to constantly fight with -- how far can you really push? They also have to be concerned about how much productivity they are taking away from the company, and since their well being is tied to the company's, you bet they care about it!
Unions have done a lot of good in this country (US), and continue to do so. They have also concentrated power in the hands of those who would most readily abuse it, so it's not all roses. Still, I'd rather have union looking out for me than have my job shipped over-seas. Usually the people who say they don't need that because "these union people are morons who can't get good work on their own" are one lay-off away from changing their minds.
The only problem is that to check each message, you would have to connect to every server that allegedly sent a message.
While that's true, if the protocol is made light-weight enough, it's not a problem. If the cost of sending mail is that you have to serve up responses to mailack requests from the recipients, it's very much worth it, IMHO.
I read some of the flamebait in the parent dir of the bullshit you linked to
If you disagree with the points he makes, fine. However, discarding those points because you disagree with other points he has made is not useful for conversational purposes, nor for resolving any of the problems that SPF, DK, etc. attempt to solve.
"What I'd prefer is for the e-mail servers to generate a separate PGP or GPG key for each user for signing the e-mail and signing only those e-mail sent by an authenticated user on the machine."
I hate to say it, but why use crypto at this level? Crypto is available for several purposes in TLS, if you want it, what you really need is verification, which is NOT a crypto problem in this case.
I am in the very, very preliminary stages of thinking about an alternate protocol where you can contact a domain and say "did you send message X to entit(y/ies) Y from entit(y/ies) Z?". It's a short question with a simple answer. Even using something as lame as Message-IDs as the key in this scheme is acceptable, since it's just a unique cookie that you combine with envelope from / header from / header to in order to validate the message. For a spammer to fake it, they would have to send a message to joe@example.com with the same message ID and from address that was just used to send joe@example.com a legitimate message.
While this is possible (e.g. because you're on the same mailing list as the spammer), I have a solution for replays (a counter and the inclusion of envelope RCPT in the protocol, not used for validation, but used for counting purposes) that I'm going to be adding. Mail that uses replays of mailing list traffic will be marked as such (since it's either a forgery or just a duplicate, and either way filters should probably gun it).
The only big change needed to support this is a protocol to use for verification (of mail) and authentication (of remote clients which wish to "forge" mail legitimatly). Finding that service is the interesting part of mailack. The protocol uses the domain's A record addresses and MX server addresses as an entry point, and can then direct a querying system to a mailack server (probably your primary outgoing mail server), or just answer the question.
So your conversation might go like this, "hi 192.168.0.1, you're the A record address for example.com, can you verify this mail?", "nope, I'm just a dumb incoming mail server and have no clue", "hi 192.168.0.2, you're the primary MX record address for example.com, can you verify this mail?", "nope, but I can tell you that 192.168.0.3 and 192.168.0.4 are the real mailack servers for example.com", "hi 192.168.0.3, you're a designated mailack server for example.com, can you verify this mail?", "I can verify that that mail is forged. I never sent it. Burn it lest your innocent users become tainted by its lies!"
And you're all set. A database of mail sent needs to be kept, but it's fairly small, as it only requires 3 header fields per message, and can be expired after several days.
SRS is a hackish, and harmful solution to a hackish and harmful protocol kludge (SPF).
I'm sorry, it was a good attempt, but it's just not going to fly given how disruptive it is. Worse, it's disruptive at a distance, so enabling SPF and dutifully enbabling SRS to compensate still forces your users to track down their forwarders and force THEM to use SRS before the scheme works.
Broken systems thwart adoption. I don't know if DK is the solution, but I'll give it a chance. I already gave SPF a chance, and have since removed it due to the harm it caused.
While you are correct, SPF is the wrong solution. Like AOL's "we only accept mail from corporate entities" policy, SPF's solution throws out a good chunk of the baby along with 80% of the bath-water.
The road toward reliable, authentication of mail is long, and we've only just started... hopefully our few first missteps will be corrected as we go.
SPF/SRS have serious problems including the inability to hop through more that 1-2 relays before the from address becomes a problematic amount of data (multiple cryptographic hashes).
SPF is about overloading existing slots in RFC2822 and DNS in order to cram authentication data into the protocols. The link above cites an alternative that is about replacing the existing protocols with brand new ones.
Both are, IMHO, poor solutions and DomainKeys might just be the correctl long-term solution.
Personally, I was working on a proposal for a way to use existing headers by adding a slightly out-of-band channel for authenticating mail, but if DomainKeys beats me to it, sounds fine to me.
If you are fortunate enough to have a balanced connection, and your client shows that you have uploaded as at least much as you have downloaded by the time your download is complete, then you have done your fair share (although you can always be extra nice and keep it open even longer to help others out:).
It will still connect when you are behind fw/nat, however there will be many clients that you will not be able to connect to
Good point. Of course, in some situtations, I can't, but I'll keep this in mind.
You should always have your share ratio to be at least 1.0. Keep your torrent session alive till your ul/dl ratio >= 1.
I guess my question there was, why? If I've been sharing what I was downloading the whole time, and the stats on my screen say I am, why is it so important that I share longer? I'm not saying I won't or that I think it's a bad idea, just that I don't get the imperative that's implied by the web site in question and your post, since I've been giving everything I recieved as I recieved it.
Open up ports 6881-6999/tcp so other clients can contact you for bits [...]
Once your download is complete please leave your downloader running so it can help upload to the other clients. This is what makes bittorrent efficient.
This seems to be wrong on a couple of points.
First off bt is uploading from my machine even if I'm NATed and not doing port forwarding for that range (there must be some sort of push-based-transfer request that the host I'm connected to can issue in the protocol) and second, leaving it up would also seem to be unnecessary to boost efficiency (though it is extra-nice, certainly), as it's uploading during the entire download, and I benefit the community of downloaders as long as I'm downloading.
In terms of how much you can make, yeah it's worth it.
On a single broadband connection, you could easily have 8-10 "bots" gathering plat for you (the protocol was streamlined quite a bit a while back, and there are macro programs out there). The easiest and least tracable way would be by simply going out and killing creatures for it. Many of them can drop as much as 5-10 platinum each and can be killed trivially in 10-20 seconds. A good macro program can wade through enough in an hour to net many, many times the estimate above per account.
The account costs $13/month. The connection is going to be $20-$50 depending on where you are, but you only need one. That means your outlay per month is around $200 max, and you can get about 1 million plat per character per month. Even at today's conversion rates of as little as 1000:1, that's $1000/month per character.... call it about $5000/month on average due to patches, bugs, lack of sales, whatever.
If you're smart, each one of those characters is on a different server so that the economies are isolated from eachother and you are not constrained by your own farming, nor competing against your own sales.
Now, do you see why it's a huge business supporting dozens of IGE-owned Web sites?
Before you go out and try this keep these things in mind: 1) the price for plat is dropping. 2) there are experienced companies in this that you'll be competing against 3) there's no guarantee that EQ will survive the release of World of Warcraft and EQ2 4) the macro programs don't work for those games... yet 5) macro programs can get your character booted if SOE figures out what you're doing 6) it's rather rude.
SOE has taken a much less active role in preventing off-line transactions recently. In-game they have made some steps to stop obvious abuses, but they don't spend any time or effort to actually stop folks like IGE (the largest platinum seller).
EQ goes on. Most of what SOE has done in recent years revolves around high-end content that simply isn't tradable. You do it yourself, or you're out of luck.
Mind you, accounts can still be sold (against the EULA, of course, but that doesn't stop people), but that takes longer and yields less real money than farming plat, so it doesn't happen as much.
Slashdot Mirror
Of course you could submit a patch.
First off, you could submit patches to the projects in question (I've submitted a few that ended up in FC2). Also, you could submit a patch to Red Hat's Bugzilla. Easily done.
So what was the problem here?
What I don't get is why the watermark thing works at all.
Has no one written a program to merge several films and subtract out the noise (e.g. watermarks)? I mean, comparing two videos and establishing which bits are identical IS old tech, no?
All you need is software like that and video from two theaters, and you should even be able to enhance the quality and remove motion.
When you speak of "most people", include in that the tens, if not hundreds of thousands who know nothing about computers, and so rely on the advice of a savvy techster they know or who is in the familly. Then think about the fact that those people (*wave*) are telling their parents/relatives/friends that they should avoid any browser that even looks at flash, popups, cookies, &etc. without asking first.
It's not about convinience. If it were, we'd all be using Macs. It's about dozens of things including security, market penetration, user acceptance, speed, standards compliance, developer evangelism, toolkit compatibility, desktop compatibility, pretty baubles, perception (sand or insane though it may be), anti-corporatism, pro-corporatism, various other flavors of politics, etc, etc.
Don't try to paint browser (or desktop or operating system, &etc.) selection as a simple issue which everyone approaches the same way.
How did redhat fall so far since 7.3?
.0 release... wait for the point release that addresses all of the problems people run into.
You're seeing the past through rose-tinted glasses. Red Hat 7.0 was Red Hat's most reviled release and thousands swore never to use Red Hat again after it. To say that 7.3 was so good is perhaps the answer to your concerns. Don't install the
Seems like standard wisdom across the board for Red Hat, SuSE, Windows, MacOS, etc., etc.
This is as expected. Slash-trolls flamed Red Hat when they released their pre-release based gcc 2.96 (which Red Hat, or more to the point, Cygnus, was the prime mover behind in the first place) and then turned a blind eye when all of the complaints they had turned out to affect every other distribution that used gcc 3.0.... Change involves pain, and moving to a new compiler, desktop, kernel, whatever is going to cause its fair share. If you can't take that pain, wait for a point release.
Why should I give it a break?
Because the idea behind a community-based distro is that we're all helping to make it better. At first, that's chaotic, but we can fine-tune as we go. FC2.1 should be much more stable. If it's not then I would be concerned, but the idea that FC2 isn't rock solid doesn't shock or even concern me. I'll do my part (posting from an FC2 box now) and submit bugs when I can.
If we're unwilling to accept a release that changes and break things, how do we move forward with an OS made up of hundreds of packages that all have different timelines, goals, etc?
Seriously, think about what it means to say, you can't store mail in a database. Ok, so hotmail is illegal in California? They certainly store mail in a database and perform searches against it...
The interesting thing about Gmail is that it applies Google searching technology to email.
What is the expected gain here? How is California protecting its citizens? To pass a law that says you can't give out information about a customer's email is one thing, but to say that you can't store it... well that certainly cripples mail technology.
Actually, code obfuscation explains a lot. I think perhaps these folks got ahold of RSA written in dc and it traumatized them so badly that they had to write a book condemning all of open source! ;-)
So, indiscriminate blocking of outbound port 25 will have side-effects.
Both inbound and outbound blocking will cause problems for users like myself. In particular, it will cause those members of Comcasts user-base (like myself) who are looked at by our friends and family as an expert in such matters to not only choose a different ISP for ourselves, but to recommend that those we care about not use the service either. After all, an ISP that tries to choose which parts of the Internet you have a right to talk to is no better than a fancy BBS, and software that my mother might want to run tomorrow could be hampered by that kind of short-sitedness (e.g. if she wanted to host a mail server that I set up for her home business, which I'll be doing next month).
No, Comcast knows their customers because the people who set all of this up for them are a fair bit like me...
Besides, customers like me are gold to Comcast. We do all the right things to protect our systems from compromise, we evangelize new users, we test out new services and build future markets for them. Early adopters are exactly what Comcast wants.
That's a valuable resource, but the question was more directed at the people in the sufferer's family. There are also good support groups for them.
It can be very hard to cope with. You start asking yourself questions that you don't want to ask like, "is this person better with me in or out of their lives" and "what if they never 'get better'". It was a very difficult road for me, but I did it alone. In retrospect, I wish I'd gone to such a support group. It would have been good for me, but also for the person I cared about.
To render it a bit more accurate: There have been laws until recently against minorities and women, so you can't really say "it's against the law, so it's wrong" as an absolute. And guess what... you can't. Ok, now back to the topic: the best resource is probably going to be support groups for families dealing with mental illness. I suspect your local hospital's mental health department will have such a group or at least a pointer on where to find one.
You said,
As someone who was in the union while working at UPS, I found that FedEx has same working conditions with same benefits at much greater pay
But then, for some reason you go on to say,
Why should UPS agree to the union's terms if it feels that it's not right?
Well, I guess the most obvious reasons are a) they weren't right and FedEx had demonstrated that by paying higher wages and being successful b) because being right doesn't help if your business suffers for it c) unless management and labor work together (ignoring the union for a second), the company fails and that makes responsibility to the company and to the stockholders the domain of both groups
I'm not a big fan of unions, but your logic is faulty.
First off, you cannot simply blame a union for the problems caused by a strike. The strike is a last-resort tool used in negotiating with management. When you point out that the strike hurt UPS so badly that FedEx gained ground against them, think about the fact that the company COULD have just agreed to the union's terms and ended the strike.
Now, the other side of that coin is that the union might have been unrealistic in their demands. In this case, the union kills the business either way, and it's a HUGE problem that unions have to constantly fight with -- how far can you really push? They also have to be concerned about how much productivity they are taking away from the company, and since their well being is tied to the company's, you bet they care about it!
Unions have done a lot of good in this country (US), and continue to do so. They have also concentrated power in the hands of those who would most readily abuse it, so it's not all roses. Still, I'd rather have union looking out for me than have my job shipped over-seas. Usually the people who say they don't need that because "these union people are morons who can't get good work on their own" are one lay-off away from changing their minds.
The only problem is that to check each message, you would have to connect to every server that allegedly sent a message.
While that's true, if the protocol is made light-weight enough, it's not a problem. If the cost of sending mail is that you have to serve up responses to mailack requests from the recipients, it's very much worth it, IMHO.
I read some of the flamebait in the parent dir of the bullshit you linked to
If you disagree with the points he makes, fine. However, discarding those points because you disagree with other points he has made is not useful for conversational purposes, nor for resolving any of the problems that SPF, DK, etc. attempt to solve.
"What I'd prefer is for the e-mail servers to generate a separate PGP or GPG key for each user for signing the e-mail and signing only those e-mail sent by an authenticated user on the machine."
I hate to say it, but why use crypto at this level? Crypto is available for several purposes in TLS, if you want it, what you really need is verification, which is NOT a crypto problem in this case.
I am in the very, very preliminary stages of thinking about an alternate protocol where you can contact a domain and say "did you send message X to entit(y/ies) Y from entit(y/ies) Z?". It's a short question with a simple answer. Even using something as lame as Message-IDs as the key in this scheme is acceptable, since it's just a unique cookie that you combine with envelope from / header from / header to in order to validate the message. For a spammer to fake it, they would have to send a message to joe@example.com with the same message ID and from address that was just used to send joe@example.com a legitimate message.
While this is possible (e.g. because you're on the same mailing list as the spammer), I have a solution for replays (a counter and the inclusion of envelope RCPT in the protocol, not used for validation, but used for counting purposes) that I'm going to be adding. Mail that uses replays of mailing list traffic will be marked as such (since it's either a forgery or just a duplicate, and either way filters should probably gun it).
The only big change needed to support this is a protocol to use for verification (of mail) and authentication (of remote clients which wish to "forge" mail legitimatly). Finding that service is the interesting part of mailack. The protocol uses the domain's A record addresses and MX server addresses as an entry point, and can then direct a querying system to a mailack server (probably your primary outgoing mail server), or just answer the question.
So your conversation might go like this, "hi 192.168.0.1, you're the A record address for example.com, can you verify this mail?", "nope, I'm just a dumb incoming mail server and have no clue", "hi 192.168.0.2, you're the primary MX record address for example.com, can you verify this mail?", "nope, but I can tell you that 192.168.0.3 and 192.168.0.4 are the real mailack servers for example.com", "hi 192.168.0.3, you're a designated mailack server for example.com, can you verify this mail?", "I can verify that that mail is forged. I never sent it. Burn it lest your innocent users become tainted by its lies!"
And you're all set. A database of mail sent needs to be kept, but it's fairly small, as it only requires 3 header fields per message, and can be expired after several days.
SRS is a hackish, and harmful solution to a hackish and harmful protocol kludge (SPF).
I'm sorry, it was a good attempt, but it's just not going to fly given how disruptive it is. Worse, it's disruptive at a distance, so enabling SPF and dutifully enbabling SRS to compensate still forces your users to track down their forwarders and force THEM to use SRS before the scheme works.
Broken systems thwart adoption. I don't know if DK is the solution, but I'll give it a chance. I already gave SPF a chance, and have since removed it due to the harm it caused.
While you are correct, SPF is the wrong solution. Like AOL's "we only accept mail from corporate entities" policy, SPF's solution throws out a good chunk of the baby along with 80% of the bath-water.
The road toward reliable, authentication of mail is long, and we've only just started... hopefully our few first missteps will be corrected as we go.
The first link seems to have been dropped. Probably a typo on my part.
s mtp-spf-is-harmful.html
It is:
http://homepages.tesco.net/~J.deBoynePollard/FGA/
I disagree with the conclusions, but the basic refutation of SPF and SRS seems to be quite sound.
SPF/SRS have serious problems including the inability to hop through more that 1-2 relays before the from address becomes a problematic amount of data (multiple cryptographic hashes).
SPF is about overloading existing slots in RFC2822 and DNS in order to cram authentication data into the protocols. The link above cites an alternative that is about replacing the existing protocols with brand new ones.
Both are, IMHO, poor solutions and DomainKeys might just be the correctl long-term solution.
Personally, I was working on a proposal for a way to use existing headers by adding a slightly out-of-band channel for authenticating mail, but if DomainKeys beats me to it, sounds fine to me.
If you are fortunate enough to have a balanced connection, and your client shows that you have uploaded as at least much as you have downloaded by the time your download is complete, then you have done your fair share (although you can always be extra nice and keep it open even longer to help others out :).
;-)
I was, and I did
Thanks!
It will still connect when you are behind fw/nat, however there will be many clients that you will not be able to connect to
Good point. Of course, in some situtations, I can't, but I'll keep this in mind.
You should always have your share ratio to be at least 1.0. Keep your torrent session alive till your ul/dl ratio >= 1.
I guess my question there was, why? If I've been sharing what I was downloading the whole time, and the stats on my screen say I am, why is it so important that I share longer? I'm not saying I won't or that I think it's a bad idea, just that I don't get the imperative that's implied by the web site in question and your post, since I've been giving everything I recieved as I recieved it.
- Open up ports 6881-6999/tcp so other clients can contact you for bits [...]
- Once your download is complete please leave your downloader running so it can help upload to the other clients. This is what makes bittorrent efficient.
This seems to be wrong on a couple of points.First off bt is uploading from my machine even if I'm NATed and not doing port forwarding for that range (there must be some sort of push-based-transfer request that the host I'm connected to can issue in the protocol) and second, leaving it up would also seem to be unnecessary to boost efficiency (though it is extra-nice, certainly), as it's uploading during the entire download, and I benefit the community of downloaders as long as I'm downloading.
So what's the deal here?
In terms of how much you can make, yeah it's worth it.
On a single broadband connection, you could easily have 8-10 "bots" gathering plat for you (the protocol was streamlined quite a bit a while back, and there are macro programs out there). The easiest and least tracable way would be by simply going out and killing creatures for it. Many of them can drop as much as 5-10 platinum each and can be killed trivially in 10-20 seconds. A good macro program can wade through enough in an hour to net many, many times the estimate above per account.
The account costs $13/month. The connection is going to be $20-$50 depending on where you are, but you only need one. That means your outlay per month is around $200 max, and you can get about 1 million plat per character per month. Even at today's conversion rates of as little as 1000:1, that's $1000/month per character.... call it about $5000/month on average due to patches, bugs, lack of sales, whatever.
If you're smart, each one of those characters is on a different server so that the economies are isolated from eachother and you are not constrained by your own farming, nor competing against your own sales.
Now, do you see why it's a huge business supporting dozens of IGE-owned Web sites?
Before you go out and try this keep these things in mind: 1) the price for plat is dropping. 2) there are experienced companies in this that you'll be competing against 3) there's no guarantee that EQ will survive the release of World of Warcraft and EQ2 4) the macro programs don't work for those games... yet 5) macro programs can get your character booted if SOE figures out what you're doing 6) it's rather rude.
SOE has taken a much less active role in preventing off-line transactions recently. In-game they have made some steps to stop obvious abuses, but they don't spend any time or effort to actually stop folks like IGE (the largest platinum seller).
EQ goes on. Most of what SOE has done in recent years revolves around high-end content that simply isn't tradable. You do it yourself, or you're out of luck.
Mind you, accounts can still be sold (against the EULA, of course, but that doesn't stop people), but that takes longer and yields less real money than farming plat, so it doesn't happen as much.