Actually, in previous years, Slashdot ran a evening and a morning (GMT-8) full of April Fools "jokes" and starting mid-afternoon, "real" stories start coming in for the day.
no, 1.4a hasn't been released yet. It's not on the release page anyway.
Speaking of that page, I'd like to know why they keep old 1.1, 1.2, and 1.3 alpha and beta releases around. Shouldn't they take those down after the final releases? I mean, who in tarnation is going to download 1.1a? Even if you want to keep them on an FTP server somewhere, at least take them off the Releases page.
That's just strange. It *hardly ever* crashes for me, and I usually have at least 5 or 6 tabs open, sometimes other windows too. It crashed once last week, but I think that's the only time in the last month or so.
I've done a little with RPG on a 400. I really like the AS/400 as a whole -- it's a nice box. Like others have said, they just work. My former boss had been using IBM minicomputers for 20-30 years and has NEVER seen one crash.
But RPG as a language? Oh, the pain! If you're used to Perl/C++/Java/VB, coding RPG is like the Chinese water torture! If anyone ever asks you to code in it, immediately run screaming from the building!
Fortunately, Perl, C++, and Java all run on the 400. Probably Python too, but I'm not sure about that.
> when there was only an 8.0. And that's been, what, 9 - 10 months?
More like 6 months. 8.0 was released in early October IIRC.
> I suppose it's also possible that Red Hat has chosen to deviate from the binary-compatibilty benchmark they've been using.
I sure hope not! Their past policy of increasing the major number on binary breakage is a VERY reasonable one. I'd be ticked if they increased it purely for marketing reasons.
However, last I checked in Rawhide (a few weeks ago), they were using glibc 2.3.1 or so, which is hopefully compatible with 8.0's 2.2.93, which is a late-beta of 2.3. gcc was at 3.2.1 or.2, which should be compatible with 8.0's 3.2.
So does anyone know for sure what broke?
Re:Why care about being hated?
on
Strike on Iraq
·
· Score: 1
Hi,
Ok -- I'm a Christian and (for the most part) a Republican. I'll bite. For the record, I myself am not particularly happy about this war.
> "Thou shall not kill"
Correct, that is one of the ten commandments, and God's condemnation of murderors is clear in the New Testament (which is important since the Ten Commandments were abolished at the Cross with the rest of the Law):
"Anyone who hates his brother is a murderer, and you know that no murderer has eternal life in him." (1 John 3:15)
But if I understand it correctly, the Bible primarily says that *murdering* is a sin. That would indicate an individual intentionally killing another. I'm not sure that it applies to governments, since Romans 13 clearly gives the government authority to protect its citizens, saying things like "But if you do wrong, be afraid, for he [the government] does not bear the sword for nothing" and "an agent of wrath to bring punishment on the wrongdoer." So if a government, along some reasonable justifiable lines, decides to kill someone for the protection of others, I don't believe anyone is sinning.
> There has not been a failure of diplomacy, there has been no diplomacy.
What do you think the UN has been doing for the last 12 years since the first Gulf War? They've given Iraq chance after chance after chance. Iraq has consistantly violated its own agreements and other UN resolutions.
> When you speak of religious hatred, it is very easy to turn the tables on the current crop of christians and their hatred of a group of religous folks who they claim are full of hate.
I for one don't believe this has anything to do with Islam. Most Muslims are nice, peaceful people (even though the Koran says some less-than-flattering things about Christians and Jews). I don't by any means want to kill Muslims. On the contrary, I want them to come to a knowledge of Christ so they can go to heaven!
No, the reason we are doing this (for right or for wrong) is because we're afraid of the terrorist threat. Maybe I'm naive, but I'm taking Bush at his word on this one. There ARE a lot of militant Muslims that really DO want to cause great damage to America. You saw that on 9/11, and you can be sure that they want to do it again. Some of those people are almost certainly harbored by Iraq.
On that basis, this war DOES have SOME validity.
> Its simply insane how one side can justify their hatred in the name of some god.
I agree completely!!!
> I simply want peace.
That will come. But not until Christ comes back to earth for his thousand year reign. Unfortunately, He indicated that there will only be more and more wars until then.
I too wish this war could be avoided. Everything would have been great had Saddam simply complied with the UN, or sought exile.
Agreed that that statement isn't 100% accurate, but more to the point....
why are they putting this FUD in the article anyway? How many business users of MySQL are going to modify it? Probably very, very few. You just install it and it works. If you need something MySQL can't do, you'll use PostgreSQL or pay for one of the big boys.
This type of FUD might just scare away legitimate potential users who have NOTHING to worry about.
Re:Separating Content from Presentation a Good Thi
on
Office 2003 and XML
·
· Score: 1
Agree in principle for the most part, but...
What if you are designing a newsletter or something, customized to a specific layout and paper size?
Shouldn't there be some kind of formatting in the XML there? (Assuming you don't want to lock yourself into one word processor, which is the whole point of this)
> Okay, now apply the concept of scale to your numbers. If you are calling 10,000 people a week you cannot support those kinds of prices.
3 Canadian cents a minute would be a LOT less than the salary they're paying the telemarketer for wages/commissions. It would almost be negligible in comparison.
Re:Move the onus from the recipient to the sender.
on
IETF to Look at Spam
·
· Score: 1
> Any alternative method must offer a similar level of performance.
MUST? Let's say a new mail protocol came out that pretty much eliminated spam, yet it took (on average) 30% longer to check your e-mail. Would you really oppose it? Considering the enormous problem of spam, I still think that would be an excellent trade-off. After all, you can do other things while mail is downloaded.:)
> Ok, one of the big problems I see with this method is that if your server gets turned into a spam box you are basically up the creek without a paddle. Full file system and a possible blacklist.
If you're a legitimate ISP, people will be able to filter by *user*, not just domain/IP. If your box isn't a legitimate ISP, you might have some trouble, but then, you're probably a spammer!
Actually I don't think the FS would fill up. It should be possible to store a mass-mailing only once on the server, and it would stay there until all the recipients picked it up. That is how listservs would work. Of course, a user might still send separate messages to each person, but that is what quotas are for...
> One technical way to stop spam at the source is to use a throttling server. Relay requests are limited to X per IP address per second (the actual number depends on the type of service you are offering).
Where is this throttling server, and who is in charge of it? For example, would it be owned and operated by a large netblock owner, just before the message gets to the Net backbone? Just trying to understand you here, so more details please...
> This can be handled by sender-side filtering where the headers are checked for sanity as the message is submitted.
Done by the throttling server? Can't really trust the spammer himself, if he has his own box, to do that.
> The recipient at the end of the chain has the option of querying the server of origin. "Did message ID from username originate from your system?"
Ok, that would help. But at that point the spam has already been sent.
> A basic issue with the peer-to-peer scheme is that it takes place on MY time. When I check my messages, I have to sit and twiddle my thumbs while the server authenticates and fetches all of the messages (and some of my mail gets pretty darn big) in addition to a hefty network load spike.
It doesn't *necessarily* have to be this way. The local server actually could do the retrieving at times you specify (or as soon as a message arrives!), then you could log in with POP or something similar to pick them up, just as you do now. Certainly, the most flexibility is offered when the client retrieves the mail, but this system could be flexible enough to offer a choice!
> If IM2000 was implemented, then you still get spam - you just have to "call back" to fetch it rather than having it dumped on you.
How much have you thought this through?
Yes, you might get SOME, but the vast majority of it, I believe, would quit. It would be MUCH easier to blacklist by rogue ISP, or by USER of a legitimate ISP. Forged headers would be impossible.
> What better way to verify that an address is valid by having them call back and fetch the mail?
I hadn't actually thought of that point before, but I believe it's well compensated for by the additional tools this would give us to control spam.
Overall, it solves far more problems than it causes, and to me that's a pretty good deal!
Re:Move the onus from the recipient to the sender.
on
IETF to Look at Spam
·
· Score: 1
> Any spam solution that offers any reduction in performance over current technology for legitimate users is not a "solution".
Of course, remember that if you're downloading 100 messages, many will likely be spam. Getting rid of most of those will automatically improve the performance some.
> In fact most of the arguments for a peer-to-peer pull solution can be rolled into existing "push" server technology.
I kind of doubt that. There are a LOT of advantages to this scheme. I'm sure you can put some band aids on the existing protocols to make them work better, but overall I think this solution has more advantages.
> Frequently I find latencies of greater than 3 seconds is not unheard of, even of fast, well-connected networks.
Right. Like I said, though, the mail client should be threaded, so many of these three second waits can happen at the same time.:)
> 1: This is based on the naive assumption that spammers would use sender-side servers that store a copy of every message sent. It would be a trivial task to create a server to send bogus notifications, then reply with to requests for messages with a dynamically generated message. All it takes is an IP number.
The other reply addressed your two points, but to add to this... it's not a problem at all that this type of thing would be allowed! In fact I believe Bernstein pointed out that listservs would behave this way.
The advantage is that there is more accountability and spam is more easily nuked or blacklisted before most recipients get it.
If you can think of a specific way to amend the current system so that it has all these advantages, please suggest it! I'm open to considering any idea, but right now I think this is one of the best!
This has been explained before, but people still don't get it, so I'll keep trying.
> doesn't really solve anything.
It solves just about *everything*. Seriously, think it through!
> i mean, with disk space at $1/gig, what's this going to do?
It's not about the cost of the disk space. It's about accountability and stopping abuse.
It will eliminate the forged header problem. Only a notification is sent to the recipient's mail server, and when the recipient connects, his mail client checks the notification and knows exactly where to go to get the message.
It would be much easier to blacklist, since there would be no more open relays. You would be able to blacklist by domain, by IP address, or down to the USER name (for domains like AOL and Yahoo).
If someone sent hundreds of thousands of spams from any reputable ISP, that ISP would be able to *cancel* the spam BEFORE it was accessed by most users. If it was through a rogue spam friendly place, like I mentioned, it would be much easier to blacklist.
This new protocol idea also has a lot of advantages for listservs. Seriously, read it!
I'm amazed that there are so many people picking nits with this idea. We've all (mostly) said that we want to find a technical solution to spam, instead of getting the government involved. Well, this is precisely the technical solution we've been looking for. Let's get off our arses and implement it!
Actually I think this is far more than a "band aid". Tactics like filtering are "band aids". This idea pretty well gets to the heart of the problem!
I agree with you though -- if we're going to redesign the e-mail protocol, let's be sure to do it right!
Re:Move the onus from the recipient to the sender.
on
IETF to Look at Spam
·
· Score: 1
> How well will it work over less robust or fast networks? The latency involved in querying and fetching 100 messages adds up pretty darn quick.
Indeed that's a minor drawback. But we're talking about stopping spam here (or at least the vast majority of it). It is WORTH a bit of pain to get this problem behind us!
Having said that, I doubt this would really be that big a deal. It would be like loading 100 web pages, except that e-mail is far smaller than a web page and hopefully the server would be optimized to respond quickly. Also, the mail client could be threaded, so the bandwidth could usually be maxed out, not just sitting around waiting for servers.
> but it also gives the sysadmin the power to nuke political content as well.
Someone's ISP already has the power to do that to web pages. I don't see how them having that power with e-mail is really that much more of a problem. And any reputable ISP won't meddle with peoples' mail until they are suspected of being spammers.
There are trade-offs to anything, but overall, I think this proposal solves far more problems than it causes, and that's a pretty good deal if you ask me.:)
> Some of my friends use hotmail.com and yahoo.com. Filtering based on servers isn't enough.
If I understand the proposal correctly...
1. If someone *did* try to send spam through hotmail/yahoo, the techies would be able to delete the spam from those servers BEFORE most recipients got to it. That alone is a huge advantage. All reputable ISPs would likely do that.
2. No forging of headers/server names. If the notice said it came from hotmail, your e-mail client would ONLY go to hotmail to pick it up!
> This solution doesn't stop spam.
Maybe not 100%, but I think it would eliminate the bulk of the spam *problem*. It's better than any other ideas I've heard. Do you have a better idea? If so let's hear it!
Back when Slashdot was first started, the Gimp was a big deal. It was the first end-user Open Source application that truly did something cool. There were many stories about it. So it was certainly logical to have its own topic.
I do web hosting for Slashcode sites, so I know that you don't generally delete a story. Stories are intended to stay in the database pretty much forever. You certainly wouldn't want to delete a topic that has stories attached to it. While you *can* change which topic is attached to a story, why would you want to?
yes, this isn't the first Christian matchmaking site. But I *do* think it's very, very different and I'm targetting a rather different audience than, say, ChristianCafe.
Check out the homepage here... http://JesusIsLife.net/singles/
Note that it is NOT live at that address yet, but it will be hopefully by the end of the month. But it will tell you what my intentions are. I think, with proper marketing, it could be successful.
I'm currently in the process of coding up a singles matchmaking site in PHP/PostgreSQL. It will have a very specific target in mind (Christian singles) but I might be interested in licensing the code to someone that wants to set up a site for a different target. I hope to have the code ready in a month or two.
Feel free to e-mail micah AT yoderdev DOT com if you might want to try it. Maybe we can work something out.:)
# Included in the unixODBC package [PostgreSQL] Description = ODBC for PostgreSQL Driver =/usr/lib/libodbcpsql.so Setup =/usr/lib/libodbcpsqlS.so FileUsage = 1
so I think I'm using the driver that comes with unixODBC.
in odbc.ini:
[Contacts] Description = HCJB Contacts Driver = PostgreSQL Trace = No TraceFile = Database = contacts Servername = localhost UserName = micah Password = Port = 5432 Protocol = 6.4 ReadOnly = No RowVersioning = No ShowSystemTables = No ShowOidColumn = No FakeOidIndex = No ConnSettings =
The main confusing thing in there is the "protocol = 6.4", since I'm using Postgres 7.2. But it was in the template I saw, and it works, so I haven't changed it.
I think the nice tihng about Access is that it lets you have SQLish access to a file. It is self contained, no server, just the application.
Right. That is something that Linux *really* needs. Access-like databases aren't for mission critical stuff, but for names and addresses and other smaller things the portability is really handy.
I remember seeing just last week a Python library that intended to do something along these lines. I don't remember the URL though.
There are many simple databases I would like to make, but having to play with some SQLd is annoying.
Well, connecting to an SQLd isn't inherently much harder than using a standalone program like Access. You just have to follow some simple setup instructions.
connecting OOo with PG via unixODBC was very, very simple. Yes, it involved editing a couple files --/etc/odbc.ini and odbcinst.ini, but you have templates and you just need to edit them. Of course, you don't even need to edit config files anymore -- use ODBCConfig. It's all there, assuming you do a full RH8 install.
However, I wouldn't be so generous as to say OOo's database capabilities are as good as Access. You can merge print from your database -- that is quite easy. You can edit table structure and data -- OK, but I find phpPgAdmin works better for that. It even has form components and the ability to navigate a database with a form, but personally I haven't mastered this yet and feel it's a bit on the ugly side. Certainly there needs to be better documentation for forms and for the Basic code you may need to put in to automate forms. It also has a visual query designer -- OK.
Overall, OOo's database tools will be useful for some people but it has a ways to go. For forms, I think GNU Enterprise has quite a bit more potential.
Slashdot Mirror
Actually, in previous years, Slashdot ran a evening and a morning (GMT-8) full of April Fools "jokes" and starting mid-afternoon, "real" stories start coming in for the day.
no, 1.4a hasn't been released yet. It's not on the release page anyway.
Speaking of that page, I'd like to know why they keep old 1.1, 1.2, and 1.3 alpha and beta releases around. Shouldn't they take those down after the final releases? I mean, who in tarnation is going to download 1.1a? Even if you want to keep them on an FTP server somewhere, at least take them off the Releases page.
That's just strange. It *hardly ever* crashes for me, and I usually have at least 5 or 6 tabs open, sometimes other windows too. It crashed once last week, but I think that's the only time in the last month or so.
I don't know what you mean by "available"
Whew. When I read that, I thought the rest of the sentence was going to say something like "I asked her out and she said no!"
I've done a little with RPG on a 400. I really like the AS/400 as a whole -- it's a nice box. Like others have said, they just work. My former boss had been using IBM minicomputers for 20-30 years and has NEVER seen one crash.
But RPG as a language? Oh, the pain! If you're used to Perl/C++/Java/VB, coding RPG is like the Chinese water torture! If anyone ever asks you to code in it, immediately run screaming from the building!
Fortunately, Perl, C++, and Java all run on the 400. Probably Python too, but I'm not sure about that.
> when there was only an 8.0. And that's been, what, 9 - 10 months?
.2, which should be compatible with 8.0's 3.2.
More like 6 months. 8.0 was released in early October IIRC.
> I suppose it's also possible that Red Hat has chosen to deviate from the binary-compatibilty benchmark they've been using.
I sure hope not! Their past policy of increasing the major number on binary breakage is a VERY reasonable one. I'd be ticked if they increased it purely for marketing reasons.
However, last I checked in Rawhide (a few weeks ago), they were using glibc 2.3.1 or so, which is hopefully compatible with 8.0's 2.2.93, which is a late-beta of 2.3. gcc was at 3.2.1 or
So does anyone know for sure what broke?
Hi,
Ok -- I'm a Christian and (for the most part) a Republican. I'll bite. For the record, I myself am not particularly happy about this war.
> "Thou shall not kill"
Correct, that is one of the ten commandments, and God's condemnation of murderors is clear in the New Testament (which is important since the Ten Commandments were abolished at the Cross with the rest of the Law):
"Anyone who hates his brother is a murderer, and you know that no murderer has eternal life in him." (1 John 3:15)
But if I understand it correctly, the Bible primarily says that *murdering* is a sin. That would indicate an individual intentionally killing another. I'm not sure that it applies to governments, since Romans 13 clearly gives the government authority to protect its citizens, saying things like "But if you do wrong, be afraid, for he [the government] does not bear the sword for nothing" and "an agent of wrath to bring punishment on the wrongdoer." So if a government, along some reasonable justifiable lines, decides to kill someone for the protection of others, I don't believe anyone is sinning.
> There has not been a failure of diplomacy, there has been no diplomacy.
What do you think the UN has been doing for the last 12 years since the first Gulf War? They've given Iraq chance after chance after chance. Iraq has consistantly violated its own agreements and other UN resolutions.
> When you speak of religious hatred, it is very easy to turn the tables on the current crop of christians and their hatred of a group of religous folks who they claim are full of hate.
I for one don't believe this has anything to do with Islam. Most Muslims are nice, peaceful people (even though the Koran says some less-than-flattering things about Christians and Jews). I don't by any means want to kill Muslims. On the contrary, I want them to come to a knowledge of Christ so they can go to heaven!
No, the reason we are doing this (for right or for wrong) is because we're afraid of the terrorist threat. Maybe I'm naive, but I'm taking Bush at his word on this one. There ARE a lot of militant Muslims that really DO want to cause great damage to America. You saw that on 9/11, and you can be sure that they want to do it again. Some of those people are almost certainly harbored by Iraq.
On that basis, this war DOES have SOME validity.
> Its simply insane how one side can justify their hatred in the name of some god.
I agree completely!!!
> I simply want peace.
That will come. But not until Christ comes back to earth for his thousand year reign. Unfortunately, He indicated that there will only be more and more wars until then.
I too wish this war could be avoided. Everything would have been great had Saddam simply complied with the UN, or sought exile.
Agreed that that statement isn't 100% accurate, but more to the point....
why are they putting this FUD in the article anyway? How many business users of MySQL are going to modify it? Probably very, very few. You just install it and it works. If you need something MySQL can't do, you'll use PostgreSQL or pay for one of the big boys.
This type of FUD might just scare away legitimate potential users who have NOTHING to worry about.
Agree in principle for the most part, but ...
What if you are designing a newsletter or something, customized to a specific layout and paper size?
Shouldn't there be some kind of formatting in the XML there? (Assuming you don't want to lock yourself into one word processor, which is the whole point of this)
> Okay, now apply the concept of scale to your numbers. If you are calling 10,000 people a week you cannot support those kinds of prices.
3 Canadian cents a minute would be a LOT less than the salary they're paying the telemarketer for wages/commissions. It would almost be negligible in comparison.
> Any alternative method must offer a similar level of performance.
:)
MUST? Let's say a new mail protocol came out that pretty much eliminated spam, yet it took (on average) 30% longer to check your e-mail. Would you really oppose it? Considering the enormous problem of spam, I still think that would be an excellent trade-off. After all, you can do other things while mail is downloaded.
> Ok, one of the big problems I see with this method is that if your server gets turned into a spam box you are basically up the creek without a paddle. Full file system and a possible blacklist.
If you're a legitimate ISP, people will be able to filter by *user*, not just domain/IP. If your box isn't a legitimate ISP, you might have some trouble, but then, you're probably a spammer!
Actually I don't think the FS would fill up. It should be possible to store a mass-mailing only once on the server, and it would stay there until all the recipients picked it up. That is how listservs would work. Of course, a user might still send separate messages to each person, but that is what quotas are for...
> One technical way to stop spam at the source is to use a throttling server. Relay requests are limited to X per IP address per second (the actual number depends on the type of service you are offering).
Where is this throttling server, and who is in charge of it? For example, would it be owned and operated by a large netblock owner, just before the message gets to the Net backbone? Just trying to understand you here, so more details please...
> This can be handled by sender-side filtering where the headers are checked for sanity as the message is submitted.
Done by the throttling server? Can't really trust the spammer himself, if he has his own box, to do that.
> The recipient at the end of the chain has the option of querying the server of origin. "Did message ID from username originate from your system?"
Ok, that would help. But at that point the spam has already been sent.
> A basic issue with the peer-to-peer scheme is that it takes place on MY time. When I check my messages, I have to sit and twiddle my thumbs while the server authenticates and fetches all of the messages (and some of my mail gets pretty darn big) in addition to a hefty network load spike.
It doesn't *necessarily* have to be this way. The local server actually could do the retrieving at times you specify (or as soon as a message arrives!), then you could log in with POP or something similar to pick them up, just as you do now. Certainly, the most flexibility is offered when the client retrieves the mail, but this system could be flexible enough to offer a choice!
Huh? 2.0 is ready for prime time? Why didn't someone tell me? I'm still using 1.2!
> If IM2000 was implemented, then you still get spam - you just have to "call back" to fetch it rather than having it dumped on you.
How much have you thought this through?
Yes, you might get SOME, but the vast majority of it, I believe, would quit. It would be MUCH easier to blacklist by rogue ISP, or by USER of a legitimate ISP. Forged headers would be impossible.
> What better way to verify that an address is valid by having them call back and fetch the mail?
I hadn't actually thought of that point before, but I believe it's well compensated for by the additional tools this would give us to control spam.
Overall, it solves far more problems than it causes, and to me that's a pretty good deal!
> Any spam solution that offers any reduction in performance over current technology for legitimate users is not a "solution".
:)
... it's not a problem at all that this type of thing would be allowed! In fact I believe Bernstein pointed out that listservs would behave this way.
Of course, remember that if you're downloading 100 messages, many will likely be spam. Getting rid of most of those will automatically improve the performance some.
> In fact most of the arguments for a peer-to-peer pull solution can be rolled into existing "push" server technology.
I kind of doubt that. There are a LOT of advantages to this scheme. I'm sure you can put some band aids on the existing protocols to make them work better, but overall I think this solution has more advantages.
> Frequently I find latencies of greater than 3 seconds is not unheard of, even of fast, well-connected networks.
Right. Like I said, though, the mail client should be threaded, so many of these three second waits can happen at the same time.
> 1: This is based on the naive assumption that spammers would use sender-side servers that store a copy of every message sent. It would be a trivial task to create a server to send bogus notifications, then reply with to requests for messages with a dynamically generated message. All it takes is an IP number.
The other reply addressed your two points, but to add to this
The advantage is that there is more accountability and spam is more easily nuked or blacklisted before most recipients get it.
If you can think of a specific way to amend the current system so that it has all these advantages, please suggest it! I'm open to considering any idea, but right now I think this is one of the best!
This has been explained before, but people still don't get it, so I'll keep trying.
> doesn't really solve anything.
It solves just about *everything*. Seriously, think it through!
> i mean, with disk space at $1/gig, what's this going to do?
It's not about the cost of the disk space. It's about accountability and stopping abuse.
It will eliminate the forged header problem. Only a notification is sent to the recipient's mail server, and when the recipient connects, his mail client checks the notification and knows exactly where to go to get the message.
It would be much easier to blacklist, since there would be no more open relays. You would be able to blacklist by domain, by IP address, or down to the USER name (for domains like AOL and Yahoo).
If someone sent hundreds of thousands of spams from any reputable ISP, that ISP would be able to *cancel* the spam BEFORE it was accessed by most users. If it was through a rogue spam friendly place, like I mentioned, it would be much easier to blacklist.
This new protocol idea also has a lot of advantages for listservs. Seriously, read it!
I'm amazed that there are so many people picking nits with this idea. We've all (mostly) said that we want to find a technical solution to spam, instead of getting the government involved. Well, this is precisely the technical solution we've been looking for. Let's get off our arses and implement it!
Actually I think this is far more than a "band aid". Tactics like filtering are "band aids". This idea pretty well gets to the heart of the problem!
I agree with you though -- if we're going to redesign the e-mail protocol, let's be sure to do it right!
> How well will it work over less robust or fast networks? The latency involved in querying and fetching 100 messages adds up pretty darn quick.
:)
Indeed that's a minor drawback. But we're talking about stopping spam here (or at least the vast majority of it). It is WORTH a bit of pain to get this problem behind us!
Having said that, I doubt this would really be that big a deal. It would be like loading 100 web pages, except that e-mail is far smaller than a web page and hopefully the server would be optimized to respond quickly. Also, the mail client could be threaded, so the bandwidth could usually be maxed out, not just sitting around waiting for servers.
> but it also gives the sysadmin the power to nuke political content as well.
Someone's ISP already has the power to do that to web pages. I don't see how them having that power with e-mail is really that much more of a problem. And any reputable ISP won't meddle with peoples' mail until they are suspected of being spammers.
There are trade-offs to anything, but overall, I think this proposal solves far more problems than it causes, and that's a pretty good deal if you ask me.
> Some of my friends use hotmail.com and yahoo.com. Filtering based on servers isn't enough.
If I understand the proposal correctly...
1. If someone *did* try to send spam through hotmail/yahoo, the techies would be able to delete the spam from those servers BEFORE most recipients got to it. That alone is a huge advantage. All reputable ISPs would likely do that.
2. No forging of headers/server names. If the notice said it came from hotmail, your e-mail client would ONLY go to hotmail to pick it up!
> This solution doesn't stop spam.
Maybe not 100%, but I think it would eliminate the bulk of the spam *problem*. It's better than any other ideas I've heard. Do you have a better idea? If so let's hear it!
So Bernstein isn't the most socially adept in the world, but his ideas are brilliant. Is anyone seriously considering implementing this?
:) )
It seems as though this could stop the spam problem overnight. (Or, at least over as many nights as it takes to get people to switch.
The reason for the GIMP topic....
Back when Slashdot was first started, the Gimp was a big deal. It was the first end-user Open Source application that truly did something cool. There were many stories about it. So it was certainly logical to have its own topic.
I do web hosting for Slashcode sites, so I know that you don't generally delete a story. Stories are intended to stay in the database pretty much forever. You certainly wouldn't want to delete a topic that has stories attached to it. While you *can* change which topic is attached to a story, why would you want to?
yes, this isn't the first Christian matchmaking site. But I *do* think it's very, very different and I'm targetting a rather different audience than, say, ChristianCafe.
... http://JesusIsLife.net/singles/
Check out the homepage here
Note that it is NOT live at that address yet, but it will be hopefully by the end of the month. But it will tell you what my intentions are. I think, with proper marketing, it could be successful.
I'm currently in the process of coding up a singles matchmaking site in PHP/PostgreSQL. It will have a very specific target in mind (Christian singles) but I might be interested in licensing the code to someone that wants to set up a site for a different target. I hope to have the code ready in a month or two.
:)
Feel free to e-mail micah AT yoderdev DOT com if you might want to try it. Maybe we can work something out.
in odbc.ini:The main confusing thing in there is the "protocol = 6.4", since I'm using Postgres 7.2. But it was in the template I saw, and it works, so I haven't changed it.
I think the nice tihng about Access is that it lets you have SQLish access to a file. It is self contained, no server, just the application.
Right. That is something that Linux *really* needs. Access-like databases aren't for mission critical stuff, but for names and addresses and other smaller things the portability is really handy.
I remember seeing just last week a Python library that intended to do something along these lines. I don't remember the URL though.
There are many simple databases I would like to make, but having to play with some SQLd is annoying.
Well, connecting to an SQLd isn't inherently much harder than using a standalone program like Access. You just have to follow some simple setup instructions.
connecting OOo with PG via unixODBC was very, very simple. Yes, it involved editing a couple files -- /etc/odbc.ini and odbcinst.ini, but you have templates and you just need to edit them. Of course, you don't even need to edit config files anymore -- use ODBCConfig. It's all there, assuming you do a full RH8 install.
However, I wouldn't be so generous as to say OOo's database capabilities are as good as Access. You can merge print from your database -- that is quite easy. You can edit table structure and data -- OK, but I find phpPgAdmin works better for that. It even has form components and the ability to navigate a database with a form, but personally I haven't mastered this yet and feel it's a bit on the ugly side. Certainly there needs to be better documentation for forms and for the Basic code you may need to put in to automate forms. It also has a visual query designer -- OK.
Overall, OOo's database tools will be useful for some people but it has a ways to go. For forms, I think GNU Enterprise has quite a bit more potential.