He CNAME'd www.bagley.org to point to www.slashdot.org since his network can't even handle the SYN flood from connection attempts (my guess for the reason). It's probably the guy's home LAN.
How does the German legal system handle it if multiple lawyers send similar letters for the same issue, each demanding money? How far can that go? Can every law firm in the country simultaneously do it?
Does the German legal system allow the law firms, when acting independently like this, to carry out the lawsuit (e.g. the 1.000.000 DM threat) as well? Or do they have to arrange with the owner of the allegedly infringed property to do that? And if they are allowed to, can multiple firms do that?
I guess we (outside of.DE) could accuse the lawfirm of "Nazi practices" (how would I say that in German?). I don't know if you're allowed to make references to that past there (apparently it's taboo in France). But at least we can here in the USA (even for our own evil history of slavery).
If Adobe sues this law firm, then my respect for Adobe would end up being higher than it was before all this started. If they simply pay the legal firm for the claimed costs, my respect will be slightly less than it was before. Not even Adobe should pay $2000 for a damned letter!
If they have not been retained by Adobe, then what they are doing is the equivalent of ambulance chasing. In the USA that is illegal. I don't know about Germany, but if it is not illegal there, then there is something seriously wrong with the German legal system.
If they were not retained by Adobe, then this law firm needs to be put down now. Writing a letter does NOT cost 4686 DM, and any more than that was not necessary in the first round.
If they were retained by Adobe, then the focus shifts to Adobe. If Adobe refuses to deny being a part of it, then it's full boycott time.
While I don't agree that "Killustrator" is an infringement, it is close enough that I do believe it would be appropriate for the author to change the name and just avoid the issue... had he been properly contacted about the matter. Writing a letter does NOT cost 4686 DM, and any more than that was not necessary in the first round. So whoever is responsible, it is all wrong. And if neither is willing to deny it is their decision, then they are both culprits in blowing a very simple matter way way out of proportion (and our response needs to be equally out of proportion against them).
And it is also about Adobe skipping the usual process of sending a "cease and desist" letter. I do believe that, aside from the "theft of commonality" issue, it is likely that the author would have changed the name. So this is also about a bad company with a bad attitude and a bunch of bad lawyers who really are the ones who should become fish food.
I wish I could boycott Adobe over this. The trouble is, they don't make anything worth buying in the first place.
I'd bet at least 90% of the admins out there... without even counting all the home boxes with personal firewalls and such... have neither certification (all but CCIE being worthless) nor real experience.
Right now the various MAPS/ORB* type databases are hard to get removed from. In my experience the bulk of open relaying (as opposed to direct spam, which is in a separate list now anyway) comes from places that won't even try to do anything about it, much less try to be removed from the list. My idea is to have the usual method of detecting open relays, but making it easy (an easy to use web form) to be removed from the list. The web form will use an email verification by sending the usual verification code to the provided email address, and then once verified on the web page, automatically remove the specified address. Those places that continue to relay spam are going to end up back on the list anyway, probably real soon, too. Oh, they can go through the cycle of having themselves removed again. If the web form is structured to make automated bots filling it in not viable, it should be effective. This way anyone who thinks they have been placed on the list inappropriately can just remove themselves.
Oh, and there would be an opt-out "would you like to receive our newsletter" selection for those whose email address is used more than 10 times:-)
Re:Spam is *not* free speech!
on
ORBS Forks
·
· Score: 2
Which is one of the reasons I blocked the entire country of Korea. I'm lucky that I can do this because I have no legitimate mail coming from Korea. Taiwan and China are similarly blocked, though I might have to unblock some of Taiwan since there are businesses there I might end up working with. Even Japan is a huge source of relayed SPAM, and I'd like to block it as well, but I get a lot of legitimate mail from there so it's not an option (I just block the networks that happen to send SPAM).
Then there is that guy who has 500 dots in his PTR receord (so he must be using some static IP) that causes mailers to overflow their header and hide his IP address. I had to block "9netway.com" to get rid of that guy. And he may even be forging that.
Some spam does indeed have the filtering. Some does not. In fact most does not. Most are from throw away or even non-existant accounts, usually mangled to bypass the filters. The only safe way is to have a list of everyone that can send you legitimate mail and block everyone else. But then, you'd miss out on some mail anyway.
If you want someone else to do the filtering for you, would you be satisfied by using an ISP that used MAPS/ORBL/ORBZ/ORDB to block spammers? Or would you be complaining that the ISP is "messing with your mail"?
Re:How I dealt with my spam...
on
ORBS Forks
·
· Score: 2
They added you to their list. You added them to your list. Sounds fair enough to me. They finally deleted you from their list, so you in turn deleted them from your list. Still sounds fair enough to me.
Was it criminal for you to add them to your list when they didn't want to be added? If yes, then it would be the same for them as well, right?
I think so.
Good job!
The problem is that mail gets MIXED UP
on
ORBS Forks
·
· Score: 2
If all mail servers fell precisely into one of these two categories:
sends mail that people do not want to receive
sends mail that people do want to receive
then the situation would be simply solved by not accepting mail from servers that send what you don't want.
The problem comes into play when a mail server, usually as the result of misconfiguration (which itself is usually the result of an incompetent or ignorant system administrator, or the management above them restricting what they can do), mixes up legitimate mail with the spam.
What many people who run clean mail servers then choose to do is to just not accept the whole lot.
Gilmore is certainly well intentioned. Anti-spam measures do pose a risk to true free speech, which unfortunately due to the way society and its leadership tends to react, must often be done anonymously to avoid risks of retaliation.
However, he has the mechanism all wrong.
Once unwanted mail has been accepted at a server, the damage is already done.
Now processing cycles must be used to analyze it to filter it out by other means, and storage is occupied over time to hold on to what then takes up human time to read it (usually because of a misleading subject like "oh, I forgot to mention" which could cause almost anyone to read it thinking it might be legitimate mail).
The real practical solution is to use mechanisms that are the most efficient at discovering the most accurate level of unwanted mail and separate it from the wanted mail.
And one of those mechanisms to choose from are the various lists of mail servers that are discovered to be sources of generally unwanted mail called SPAM.
Different people do vary in their belief in the benefit of losing unwanted mail like SPAM versus the cost of losing wanted mail.
One could think of it as a ratio.
How many pieces of SPAM would a scheme need to be able to get rid of to make it acceptable to lose one piece of legitimate and wanted mail?
Some people will say there is no acceptable number.
They won't be filtering SPAM at all.
Others consider it acceptable to lose some legitimate mail to reduce their costs of processing and the time taken to read the junk.
When it is realized that the senders could move on to a different network services which carries out actual and effective measures to ensure their mail server is in the 2nd category above, then for many people it is acceptable to lose some mail because they know the sender can remedy the situation.
I use the MAPS databases in blocking spam coming in to my servers from various classes of known spam sources, including open relays.
I review the logs and have found that so far it has been very effective in blocking spam while not blocking legitimate mail.
It's not as effective as desired in being comprehensive in blocking all open relays.
But I have found that if I also block mail arriving from mail servers which have no PTR record available at all (reverse DNS) for its IP address (reversed in the in-addr.arpa zone), the blocking is nearly as effective as MAPS.
In fact it blocks more SPAM than MAPS does, although there have been 3 cases of apparently legitimate mail being sent in and lost (one of those being from OSDN itself... heads up Kurt!).
In general there appears to be a very high level of correlation between servers misconfigured to allow SPAM to be relayed and servers misconfigured to not have functional reverse DNS. It's not perfectly 100%, but it is well over 99%.
Most of the open relays seem to be the rapid growth of businesses connecting to the network, especially outside of the United States (the US having done most of its initial connection growth already).
This is probably made worse by the fact that most of the documentation is in English, and English is not really universally understood.
That doesn't mean that when a new mail server comes online in China as an open relay that the administrator intended this to be so.
More likely they are not getting good documentation in their own language to explain to them the importance of making sure the server is closed for relaying, and the steps needed to do it.
Another problem that is probably contributing is a very high use of pirated software, which tends to be older versions of Microsoft Exchange server, and limits the ability to get service packs for it.
Where's there smoke there's often fire. If the server lacks reverse DNS it most likely is also an open relay (or worse, a direct spammer).
Still, the fact that an administrator would not want to relay SPAM does not in my mind mean I should go ahead and accept SPAM from them.
So I find it perfectly acceptable to use at least some of the databases of SPAM sources out there, and even additional techniques, to block the unwanted and costly mail.
It's my server.
And my customers can move on to someone that lets SPAM in if they so choose.
And I am now setting up a 2nd mail server with NO anti-SPAM measures (it won't relay, but it will take mail from all sites to be delivered here) and let customers choose which they want their incoming mail to go through.
I wonder which one they will choose.
I wonder how long it will be until they go back.
And BTW, I did test out using a context based mail filter for my own mailbox once.
It killed more legitimate mail than I found acceptable; far more than my current methods do.
Instead of trying to address the matter in good faith they are trying to pressure people for money. Were it not for that, I'd say to KDE to change the name. But instead, I'd suggest holding their stand until Adobe agrees to come to terms on this. They should have first sent a normal cease and desist letter. But this indicates a major attitude problem at Adobe, and they are certainly going to lose all potential business from me (what little there may have been).
Are you confused? If you are maybe they have a case, but then you don't. OTOH, if you are not, then they don't have a case. The word "illustrator" existed before Adobe used it just like the word "Word" existed before Microsoft used it. Of course they can add stuff on and use it as their own. But so can anyone else do the same thing. The question is whether that was done to extract on the "good" name, or if it was done to simply convey a meaning to a ubiquitous term. I'm sure the KDE people can choose a different name. But the demand for money now means it won't be that simple.
And the GPL does not undermine IT development companies. They don't have to use the software if they don't want to. Why is your business doing it if it is undermining you? I was considering using BSD licensing for my free software. But because of the unjustified attacks made on GPL, I'm considering going the other way and doing GPL. Hope you're happy.
One's choice of package management also depends on what they want to do. Clearly none of the choices is perfect for everyone.
For my desktop machines, I could perhaps go either way. For my servers, I install all exposed services and other critical functions from original source code anyway. I script up the compile config and any modifications I make so if I need to quickly upgrade to keep SKs out of BOs I'm prepared. And if the BO isn't fixed in a new version, I can go fix it myself (done that before). Besides that, I prefer to keep servers as stable as possible. My "upgrades" are more a case of migrating services from an older server to a newer server. That's done to get the least disruption in service (a few seconds to cut over instead of a few hours to upgrade the same box, leaving time to fallback in the event something might not work in the new versions).
Being as my servers are Slackware, I might as well just make my desktops the same.
Slackware isn't for everyone. It is for me, but apparently not for you, whoever you are. I'm glad you found what you like. At least you aren't doing what some people do and ask "what distro should I use?".
If upgrading OpenSSL breaks some other package, then something is wrong with the other package. In practice I found that package builders were making their dependencies too tight, and the end result was often an unsolvable equation because in many cases a newer package was even available. And as soon as you start installing from original source code, you end up with dangling dependecies in your RPM database. That's what happened with Redhat for me (I actually used Redhat for a little over a year). I used Slackware before then with no troubles, and after I went "back to Slack" my problems went away.
I think the problem is more a case of badly built packages. RPM certainly helps you to deal with those to a point. But it also serves to hide the real problem in that packages built to depend to tightly on specific versions is bad. Sure, if package A depends on package B and you have a buggy version of package B you want to upgrade package B. But if that requires also upgrading package A, or some other package C that is dependent on a specific version of package B, then there is definitely something wrong with the other package. It might be in the packaging (too specific a dependency) or in the coding (author depends on bugs in the other package).
If upgrading a package breaks another package that depends on it, I want to know what is wrong with the other package before I upgrade that one. I certainly do not want to be going around upgrading half my system just because I notched up the 2nd or even 3rd digit on a library. I shouldn't have to upgrade anything on account of that if the other packages were done right.
But that's not the biggest reason I switched "back to Slack". That reason will be revealed later.
I don't know about Debian because I never managed to get it installed (I hear they have a whole new installer now, so maybe it will work for me now). But I did try Redhat. Installing things from outside the package manager into/usr/local was not always an option. For one thing, you end up filling the system up with redundancies. And then all my truly local stuff gets buried on all the installed stuff and now I have to worry about my local development colliding with installed stuff. LHS needs to define yet another place for things like this. What I ended up having to do with RPM on Redhat was forcing the install. Things did work despite the force, but at that point I realized that the whole idea of having enforced dependecies, at least the way RPM was doing it with the way packages were made, wasn't really working right.
The only time I've ever had syskripple is when I was using Redhat during a year of insanity back in 1999. Since coming "back to Slack" the problems went away. Things do tend to work better in Slack even if the versions are a little mismatched. And I don't have to do battle with the package manager to get stuff updated the way I want. RPM tends to end up with a rigid web of package dependencies. Perhaps a lot of that is due to improperly built packages. In my last days of Redhat, I was just doing the force option on every install or upgrade to get things to work. And that made me realize that all RPM was giving me was the ability to quickly install lamely built packages without thinking about what I was doing. So I went "back to Slack".
Not only should packages have the --prefix option, but it should also be mandatory. I've decided to make it mandatory in mine. Without --prefix they will not install (but they will do a compile). So there will not be a default installation location.
The reason for this is that system administrators need to wake up and stop doing installs in a daze. They need to think about what they are doing, have a plan, and follow through with it.
One idea I was thinking of is requiring that a config file for the package must exist in/etc (or a directory in/etc if it's so complex a package that it requires many config files), before it will compile or install.
One of the things I do find disgusting is packages that do things like hard code locations other than standard ones into the executeables. If it needs to know where to find stuff that the system administrator has put somewhere else, it should get that info from a config file in/etc. Thus if the system administrator does need to move things around, there is a way to say where to find them without having to recompile.
I already do this with microATX machines. But they are 2 to 3 times more volume (mostly wasted air) than they need to be. This is why I am looking for the next step smaller. Sun used to make the Sparc IPC, IPX, and LX machines about the right size. But I need dual ethernet, IDE, and prefer an Intel CPU (but it doesn't need to be hyper fast... one of the embedded x86 CPUs would be fine... 200-300 Mhz is plenty of speed). Since it will be a firewall, fancy video is not needed and serial console would be acceptable (but one serial port for backup dialout modem would be useful, too). To keep the internal geometry in control, it all needs to be integrated on one board without requiring the use of any PCI slot cards to achieve the basic requirements.
What I really want is an in between system, smaller than a microATX desktop, but not so small as the box in this/. article. Something on the order of size of an old Sun 411 case or a "lunchbox" case at the largest, would be about right. I would be looking for 2 versions, one with and one without harddrive. The harddrive can be a smaller laptop (2.5 inch) type. I also want this to be i386 based, but it doesn't need to be the fastest processor, so the slower and smaller i386 embedded processors will probably do the job.
What I found when I went searching for this a few months ago was several companies making various SBCs, but no one making a complete system based on it. I don't want to get into the hardware building business over this. One problem was that these components were not designed to fit right into a small box with others. In most cases they were not all integrated (e.g. no ethernet ports... I need 2 since these will be firewalls) and depended on add on slots they had, which if used made for setups that would never fit in a decent box.
The configuration should be simple enough. Based on an embedded chipset and CPU, such as a 200 MHz embedded 486 class CPU, with one or two DIMM slots for RAM, one or two IDE interfaces, one or two serial ports, minimalist VGA video and keyboard (if not console over serial) and maybe even a mouse port. I do need dual ethernet and it needs to be integrated, so whoever builds this is clearly going to have to think "firewall market".
I bet I'll get several people suggesting that I check out this company or that company. I've gotten those many times before and these companies turn out to make SBCs, but none are configured right, and none come fully built in a box with power supply. So if you are temped to make such a suggestion, it probably already has been made. If you do know that they do make this box, then it hasn't been made because I have seen no such company, yet.
If you are interested in starting a businesses building hardware and doing something with SBCs, you might consider this firewall market. But do remember that the higher end "firewall" will also be a web proxy and mail (SMTP+POP3) server as well, and maybe even more than that. It's more of the next evolution of a smaller system box.
They did change the IP back. The switch over was temporary to get an announcement up... and that was outside the Exodus cage. Fortunately they did have 1 (out of 3) authority DNS servers outside of there, so they could get people over to the announcement... eventually as cache TTLs expired.
It's already bad enough to have a 24 hour expiration on the A-record. But you don't anticipate these outages, so 1D is fairly common practice (even longer in some places trying to reduce their DNS load). But the real mistake was putting 24 hours expriation on the temporary IP. Basically that says "as soon as I change this, everyone who cached this temporary IP address is going to have to wait a day from when they first say the page, before they can get their/. fix (or other OSDN stuff)". What? Did someone actually think they were going to change the IP back 24 hours BEFORE the sites were back up? The temporary A-record should have had a TTL of less than about 30 minutes. I'd have put in 10 minutes if it were me. But then, if I were there, but if I were there, I'd have also been doing the Cisco stuff and actually tested the failover configuration.
I do recommend:
Having at least 4, and maybe even 6, authority DNS servers, all diversity located (I'm sure they can get some located over at VA Linux).
Develop specific procedures to handle failures for each piece of equipment.
Print the procedures on paper and keep a copy at the cage, in the office, and at a senior manager's home at minimum.
Hire an outside consultant in each area to revied the procedures to make sure they make sense to an outsider in the event you might need to go outside to solve the issues.
Test the procedures and configurations by scheduling "failures" to see if the major points work as intended.
These are the kinds of things system and network administrators are supposed to do. Programmers tend to hate that kind of work, so that's why there are separate job descriptions. Just because a good programmer can install and configure a server doesn't mean that just doing that is all that needs to be done. Businesses run smoothly when people know what they are supposed to do. And in the exceptional circumstances, they're doing things they don't routinely do, and it is essential to not only have those things written down, but also make sure they do work, and can be found even in a power failure.
Slashdot Mirror
He CNAME'd www.bagley.org to point to www.slashdot.org since his network can't even handle the SYN flood from connection attempts (my guess for the reason). It's probably the guy's home LAN.
200,000? Damn! That would be a LOT of page hits even if they spaced each download down to once an hour.
Questions:
How does the German legal system handle it if multiple lawyers send similar letters for the same issue, each demanding money? How far can that go? Can every law firm in the country simultaneously do it?
Does the German legal system allow the law firms, when acting independently like this, to carry out the lawsuit (e.g. the 1.000.000 DM threat) as well? Or do they have to arrange with the owner of the allegedly infringed property to do that? And if they are allowed to, can multiple firms do that?
I guess we (outside of .DE) could accuse the lawfirm of "Nazi practices" (how would I say that in German?). I don't know if you're allowed to make references to that past there (apparently it's taboo in France). But at least we can here in the USA (even for our own evil history of slavery).
If Adobe sues this law firm, then my respect for Adobe would end up being higher than it was before all this started. If they simply pay the legal firm for the claimed costs, my respect will be slightly less than it was before. Not even Adobe should pay $2000 for a damned letter!
If they have not been retained by Adobe, then what they are doing is the equivalent of ambulance chasing. In the USA that is illegal. I don't know about Germany, but if it is not illegal there, then there is something seriously wrong with the German legal system.
If they were not retained by Adobe, then this law firm needs to be put down now. Writing a letter does NOT cost 4686 DM, and any more than that was not necessary in the first round.
If they were retained by Adobe, then the focus shifts to Adobe. If Adobe refuses to deny being a part of it, then it's full boycott time.
While I don't agree that "Killustrator" is an infringement, it is close enough that I do believe it would be appropriate for the author to change the name and just avoid the issue ... had he been properly contacted about the matter. Writing a letter does NOT cost 4686 DM, and any more than that was not necessary in the first round. So whoever is responsible, it is all wrong. And if neither is willing to deny it is their decision, then they are both culprits in blowing a very simple matter way way out of proportion (and our response needs to be equally out of proportion against them).
And it is also about Adobe skipping the usual process of sending a "cease and desist" letter. I do believe that, aside from the "theft of commonality" issue, it is likely that the author would have changed the name. So this is also about a bad company with a bad attitude and a bunch of bad lawyers who really are the ones who should become fish food.
I wish I could boycott Adobe over this. The trouble is, they don't make anything worth buying in the first place.
I'd bet at least 90% of the admins out there ... without even counting all the home boxes with personal firewalls and such ... have neither certification (all but CCIE being worthless) nor real experience.
Right now the various MAPS/ORB* type databases are hard to get removed from. In my experience the bulk of open relaying (as opposed to direct spam, which is in a separate list now anyway) comes from places that won't even try to do anything about it, much less try to be removed from the list. My idea is to have the usual method of detecting open relays, but making it easy (an easy to use web form) to be removed from the list. The web form will use an email verification by sending the usual verification code to the provided email address, and then once verified on the web page, automatically remove the specified address. Those places that continue to relay spam are going to end up back on the list anyway, probably real soon, too. Oh, they can go through the cycle of having themselves removed again. If the web form is structured to make automated bots filling it in not viable, it should be effective. This way anyone who thinks they have been placed on the list inappropriately can just remove themselves.
Oh, and there would be an opt-out "would you like to receive our newsletter" selection for those whose email address is used more than 10 times :-)
Which is one of the reasons I blocked the entire country of Korea. I'm lucky that I can do this because I have no legitimate mail coming from Korea. Taiwan and China are similarly blocked, though I might have to unblock some of Taiwan since there are businesses there I might end up working with. Even Japan is a huge source of relayed SPAM, and I'd like to block it as well, but I get a lot of legitimate mail from there so it's not an option (I just block the networks that happen to send SPAM).
Then there is that guy who has 500 dots in his PTR receord (so he must be using some static IP) that causes mailers to overflow their header and hide his IP address. I had to block "9netway.com" to get rid of that guy. And he may even be forging that.
Some spam does indeed have the filtering. Some does not. In fact most does not. Most are from throw away or even non-existant accounts, usually mangled to bypass the filters. The only safe way is to have a list of everyone that can send you legitimate mail and block everyone else. But then, you'd miss out on some mail anyway.
If you want someone else to do the filtering for you, would you be satisfied by using an ISP that used MAPS/ORBL/ORBZ/ORDB to block spammers? Or would you be complaining that the ISP is "messing with your mail"?
They added you to their list. You added them to your list. Sounds fair enough to me. They finally deleted you from their list, so you in turn deleted them from your list. Still sounds fair enough to me.
Was it criminal for you to add them to your list when they didn't want to be added? If yes, then it would be the same for them as well, right? I think so.
Good job!
If all mail servers fell precisely into one of these two categories:
- sends mail that people do not want to receive
- sends mail that people do want to receive
then the situation would be simply solved by not accepting mail from servers that send what you don't want. The problem comes into play when a mail server, usually as the result of misconfiguration (which itself is usually the result of an incompetent or ignorant system administrator, or the management above them restricting what they can do), mixes up legitimate mail with the spam. What many people who run clean mail servers then choose to do is to just not accept the whole lot.Gilmore is certainly well intentioned. Anti-spam measures do pose a risk to true free speech, which unfortunately due to the way society and its leadership tends to react, must often be done anonymously to avoid risks of retaliation. However, he has the mechanism all wrong. Once unwanted mail has been accepted at a server, the damage is already done. Now processing cycles must be used to analyze it to filter it out by other means, and storage is occupied over time to hold on to what then takes up human time to read it (usually because of a misleading subject like "oh, I forgot to mention" which could cause almost anyone to read it thinking it might be legitimate mail). The real practical solution is to use mechanisms that are the most efficient at discovering the most accurate level of unwanted mail and separate it from the wanted mail. And one of those mechanisms to choose from are the various lists of mail servers that are discovered to be sources of generally unwanted mail called SPAM.
Different people do vary in their belief in the benefit of losing unwanted mail like SPAM versus the cost of losing wanted mail. One could think of it as a ratio. How many pieces of SPAM would a scheme need to be able to get rid of to make it acceptable to lose one piece of legitimate and wanted mail? Some people will say there is no acceptable number. They won't be filtering SPAM at all. Others consider it acceptable to lose some legitimate mail to reduce their costs of processing and the time taken to read the junk. When it is realized that the senders could move on to a different network services which carries out actual and effective measures to ensure their mail server is in the 2nd category above, then for many people it is acceptable to lose some mail because they know the sender can remedy the situation.
I use the MAPS databases in blocking spam coming in to my servers from various classes of known spam sources, including open relays. I review the logs and have found that so far it has been very effective in blocking spam while not blocking legitimate mail. It's not as effective as desired in being comprehensive in blocking all open relays. But I have found that if I also block mail arriving from mail servers which have no PTR record available at all (reverse DNS) for its IP address (reversed in the in-addr.arpa zone), the blocking is nearly as effective as MAPS. In fact it blocks more SPAM than MAPS does, although there have been 3 cases of apparently legitimate mail being sent in and lost (one of those being from OSDN itself ... heads up Kurt!).
In general there appears to be a very high level of correlation between servers misconfigured to allow SPAM to be relayed and servers misconfigured to not have functional reverse DNS. It's not perfectly 100%, but it is well over 99%. Most of the open relays seem to be the rapid growth of businesses connecting to the network, especially outside of the United States (the US having done most of its initial connection growth already). This is probably made worse by the fact that most of the documentation is in English, and English is not really universally understood. That doesn't mean that when a new mail server comes online in China as an open relay that the administrator intended this to be so. More likely they are not getting good documentation in their own language to explain to them the importance of making sure the server is closed for relaying, and the steps needed to do it. Another problem that is probably contributing is a very high use of pirated software, which tends to be older versions of Microsoft Exchange server, and limits the ability to get service packs for it.
Where's there smoke there's often fire. If the server lacks reverse DNS it most likely is also an open relay (or worse, a direct spammer).
Still, the fact that an administrator would not want to relay SPAM does not in my mind mean I should go ahead and accept SPAM from them. So I find it perfectly acceptable to use at least some of the databases of SPAM sources out there, and even additional techniques, to block the unwanted and costly mail. It's my server. And my customers can move on to someone that lets SPAM in if they so choose. And I am now setting up a 2nd mail server with NO anti-SPAM measures (it won't relay, but it will take mail from all sites to be delivered here) and let customers choose which they want their incoming mail to go through. I wonder which one they will choose. I wonder how long it will be until they go back.
And BTW, I did test out using a context based mail filter for my own mailbox once. It killed more legitimate mail than I found acceptable; far more than my current methods do.
Instead of trying to address the matter in good faith they are trying to pressure people for money. Were it not for that, I'd say to KDE to change the name. But instead, I'd suggest holding their stand until Adobe agrees to come to terms on this. They should have first sent a normal cease and desist letter. But this indicates a major attitude problem at Adobe, and they are certainly going to lose all potential business from me (what little there may have been).
Are you confused? If you are maybe they have a case, but then you don't. OTOH, if you are not, then they don't have a case. The word "illustrator" existed before Adobe used it just like the word "Word" existed before Microsoft used it. Of course they can add stuff on and use it as their own. But so can anyone else do the same thing. The question is whether that was done to extract on the "good" name, or if it was done to simply convey a meaning to a ubiquitous term. I'm sure the KDE people can choose a different name. But the demand for money now means it won't be that simple.
And the GPL does not undermine IT development companies. They don't have to use the software if they don't want to. Why is your business doing it if it is undermining you? I was considering using BSD licensing for my free software. But because of the unjustified attacks made on GPL, I'm considering going the other way and doing GPL. Hope you're happy.
One's choice of package management also depends on what they want to do. Clearly none of the choices is perfect for everyone.
For my desktop machines, I could perhaps go either way. For my servers, I install all exposed services and other critical functions from original source code anyway. I script up the compile config and any modifications I make so if I need to quickly upgrade to keep SKs out of BOs I'm prepared. And if the BO isn't fixed in a new version, I can go fix it myself (done that before). Besides that, I prefer to keep servers as stable as possible. My "upgrades" are more a case of migrating services from an older server to a newer server. That's done to get the least disruption in service (a few seconds to cut over instead of a few hours to upgrade the same box, leaving time to fallback in the event something might not work in the new versions).
Being as my servers are Slackware, I might as well just make my desktops the same.
Slackware isn't for everyone. It is for me, but apparently not for you, whoever you are. I'm glad you found what you like. At least you aren't doing what some people do and ask "what distro should I use?".
If upgrading OpenSSL breaks some other package, then something is wrong with the other package. In practice I found that package builders were making their dependencies too tight, and the end result was often an unsolvable equation because in many cases a newer package was even available. And as soon as you start installing from original source code, you end up with dangling dependecies in your RPM database. That's what happened with Redhat for me (I actually used Redhat for a little over a year). I used Slackware before then with no troubles, and after I went "back to Slack" my problems went away.
I think the problem is more a case of badly built packages. RPM certainly helps you to deal with those to a point. But it also serves to hide the real problem in that packages built to depend to tightly on specific versions is bad. Sure, if package A depends on package B and you have a buggy version of package B you want to upgrade package B. But if that requires also upgrading package A, or some other package C that is dependent on a specific version of package B, then there is definitely something wrong with the other package. It might be in the packaging (too specific a dependency) or in the coding (author depends on bugs in the other package).
If upgrading a package breaks another package that depends on it, I want to know what is wrong with the other package before I upgrade that one. I certainly do not want to be going around upgrading half my system just because I notched up the 2nd or even 3rd digit on a library. I shouldn't have to upgrade anything on account of that if the other packages were done right.
But that's not the biggest reason I switched "back to Slack". That reason will be revealed later.
I don't know about Debian because I never managed to get it installed (I hear they have a whole new installer now, so maybe it will work for me now). But I did try Redhat. Installing things from outside the package manager into /usr/local was not always an option. For one thing, you end up filling the system up with redundancies. And then all my truly local stuff gets buried on all the installed stuff and now I have to worry about my local development colliding with installed stuff. LHS needs to define yet another place for things like this. What I ended up having to do with RPM on Redhat was forcing the install. Things did work despite the force, but at that point I realized that the whole idea of having enforced dependecies, at least the way RPM was doing it with the way packages were made, wasn't really working right.
So I am "back to Slack".
The only time I've ever had syskripple is when I was using Redhat during a year of insanity back in 1999. Since coming "back to Slack" the problems went away. Things do tend to work better in Slack even if the versions are a little mismatched. And I don't have to do battle with the package manager to get stuff updated the way I want. RPM tends to end up with a rigid web of package dependencies. Perhaps a lot of that is due to improperly built packages. In my last days of Redhat, I was just doing the force option on every install or upgrade to get things to work. And that made me realize that all RPM was giving me was the ability to quickly install lamely built packages without thinking about what I was doing. So I went "back to Slack".
Or maybe... "gigabytes for dummies"
Not only should packages have the --prefix option, but it should also be mandatory. I've decided to make it mandatory in mine. Without --prefix they will not install (but they will do a compile). So there will not be a default installation location.
The reason for this is that system administrators need to wake up and stop doing installs in a daze. They need to think about what they are doing, have a plan, and follow through with it.
One idea I was thinking of is requiring that a config file for the package must exist in /etc (or a directory in /etc if it's so complex a package that it requires many config files), before it will compile or install.
One of the things I do find disgusting is packages that do things like hard code locations other than standard ones into the executeables. If it needs to know where to find stuff that the system administrator has put somewhere else, it should get that info from a config file in /etc. Thus if the system administrator does need to move things around, there is a way to say where to find them without having to recompile.
I already do this with microATX machines. But they are 2 to 3 times more volume (mostly wasted air) than they need to be. This is why I am looking for the next step smaller. Sun used to make the Sparc IPC, IPX, and LX machines about the right size. But I need dual ethernet, IDE, and prefer an Intel CPU (but it doesn't need to be hyper fast ... one of the embedded x86 CPUs would be fine ... 200-300 Mhz is plenty of speed). Since it will be a firewall, fancy video is not needed and serial console would be acceptable (but one serial port for backup dialout modem would be useful, too). To keep the internal geometry in control, it all needs to be integrated on one board without requiring the use of any PCI slot cards to achieve the basic requirements.
What I really want is an in between system, smaller than a microATX desktop, but not so small as the box in this /. article. Something on the order of size of an old Sun 411 case or a "lunchbox" case at the largest, would be about right. I would be looking for 2 versions, one with and one without harddrive. The harddrive can be a smaller laptop (2.5 inch) type. I also want this to be i386 based, but it doesn't need to be the fastest processor, so the slower and smaller i386 embedded processors will probably do the job.
What I found when I went searching for this a few months ago was several companies making various SBCs, but no one making a complete system based on it. I don't want to get into the hardware building business over this. One problem was that these components were not designed to fit right into a small box with others. In most cases they were not all integrated (e.g. no ethernet ports ... I need 2 since these will be firewalls) and depended on add on slots they had, which if used made for setups that would never fit in a decent box.
The configuration should be simple enough. Based on an embedded chipset and CPU, such as a 200 MHz embedded 486 class CPU, with one or two DIMM slots for RAM, one or two IDE interfaces, one or two serial ports, minimalist VGA video and keyboard (if not console over serial) and maybe even a mouse port. I do need dual ethernet and it needs to be integrated, so whoever builds this is clearly going to have to think "firewall market".
I bet I'll get several people suggesting that I check out this company or that company. I've gotten those many times before and these companies turn out to make SBCs, but none are configured right, and none come fully built in a box with power supply. So if you are temped to make such a suggestion, it probably already has been made. If you do know that they do make this box, then it hasn't been made because I have seen no such company, yet.
If you are interested in starting a businesses building hardware and doing something with SBCs, you might consider this firewall market. But do remember that the higher end "firewall" will also be a web proxy and mail (SMTP+POP3) server as well, and maybe even more than that. It's more of the next evolution of a smaller system box.
They did change the IP back. The switch over was temporary to get an announcement up ... and that was outside the Exodus cage. Fortunately they did have 1 (out of 3) authority DNS servers outside of there, so they could get people over to the announcement ... eventually as cache TTLs expired.
It's already bad enough to have a 24 hour expiration on the A-record. But you don't anticipate these outages, so 1D is fairly common practice (even longer in some places trying to reduce their DNS load). But the real mistake was putting 24 hours expriation on the temporary IP. Basically that says "as soon as I change this, everyone who cached this temporary IP address is going to have to wait a day from when they first say the page, before they can get their /. fix (or other OSDN stuff)". What? Did someone actually think they were going to change the IP back 24 hours BEFORE the sites were back up? The temporary A-record should have had a TTL of less than about 30 minutes. I'd have put in 10 minutes if it were me. But then, if I were there, but if I were there, I'd have also been doing the Cisco stuff and actually tested the failover configuration.
I do recommend:
These are the kinds of things system and network administrators are supposed to do. Programmers tend to hate that kind of work, so that's why there are separate job descriptions. Just because a good programmer can install and configure a server doesn't mean that just doing that is all that needs to be done. Businesses run smoothly when people know what they are supposed to do. And in the exceptional circumstances, they're doing things they don't routinely do, and it is essential to not only have those things written down, but also make sure they do work, and can be found even in a power failure.