Re:How does this reduce spam in any shape or form?
on
SPF Design Frozen
·
· Score: 1
Right, I should have said "domain owner and/or DNS server operator and/or mail server administrator" whereever I said "everyone" since that's kind of a mouthful.:-)
Right, and these miniscule hard drives don't spin at anywhere close to the 7200 RPM you probably have in your desktop. Sure, if you pick one of those up you're in for a shock at how much gyroscopic reaction there is, but that's because of multiple platters, much larger radius, and faster angular velocity (rpm).
Re:Unfortunate that the test system wasn't newer
on
SCO UnixWare 7.1.3 Review
·
· Score: 4, Insightful
That's easy to say, but if you have critical infrastructure built around SCO it's not like you can just wake up one day and say "Hmmm, this doesn't look good, how about we abandon all those production servers and build something completely different." In business, things that work and are supported don't get touched without good reason, especially if megabucks have been spent getting to that point. It doesn't matter if SCO doesn't have shit for features or doesn't support the latest doodads. It's in production in a number of places and you can't just yank the rug out from under a business like that.
It's one thing to denounce SCO for being the assholes that they are, but it's another completely different thing to actually move away from something that critical without a LOT of planning and testing. Sure, you get started on that as soon as possible, but it takes time. YOu can't just say "SCO's irrelevant now" because to some businesses, it's very relevant -- for better or worse.
How does this reduce spam in any shape or form?
on
SPF Design Frozen
·
· Score: 3, Insightful
Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.
But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.
Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)
Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.
So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.
So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.
Here's something for you to consider: Unless your email services use closed-loop a.k.a. confirmed opt-in then you're a spammer. Why? Consider the case of some random party entering my email address in your handy little web form. Unless your system first confirms my email address (with a unique token that must be acknowledged) then I'll eventually be receiving crap from you that I do not wish to receive, and you are thus a spammer. It is not a question of IF this will ever happen, but when. People mistype email addresses, or make up ones they think are invalid. Or, they maliciously sign up some third party on every web form they can find. It happens. If your system does not deal with it properly by confirming every email address then you're a spammer, plain and simple, and you deserve to be blacklisted when it happens. It doesn't matter if you had the best of intentions, or if your messages contain removal instructions in 23 languages. Spam is not about content, it's about consent.
From the article and replies on here, it seems that this program simply detects if you are running Kazaa (and likely others.) So, they're being selective in that they're looking at the traffic to see what port it's on and whether it matches a Kazaa signature. But they're not looking at the payload and saying "Oh gee, this looks like Metallica, better cut off access." I don't think such a thing is even possible, as it would require either a huge database of file IDs or hashes, or some unobtainably advanced AI.
Now, the debate about how there are non-infringing uses of Kazaa is certainly valid. But that's another matter entirely. My point is that a school enforcing a policy of "You cannot use this application because we get many complaints from people regarding violations when you do" does not even come close to censorship. It's a policy decision regarding their facilities, much like "We're closing off this road, you can no longer drive here" or "These basketball courts are closed after 10pm, go away."
Oh fucking please, that is the most tired argument I've ever heard. By that logic if I choose not to use the school's gym (say, because I don't approve of their rules of the basketball court) then I shouldn't have to pay that part of the fees. And if I never set foot on the school's track, why am I paying for its upkeep anyway? Damn the bus system, I have a car, why should I pay for that?
The answer is simple, everybody pays the same fees. The facilities would not exist if they were only paid for by the specific people that use it. By splitting the cost evenly it means that EVERYONE as a COMMUNITY benefits, as opposed to the alternative which is having NO FACILITIES at all, but every student $60 richer.
I suppose you're also going to tell me that if you decide not to use the public library that you shouldn't have to pay for it with my tax dollars? That you don't have kids and so your tax dollars shouldn't be supporting children's programs or schools? Puh-lease.
If you don't agree with the network usage policy, fine, don't use the system. But don't get some high and mighty "I'm paying for it therefore I can do any fucking thing I want" attitude.
"Censoring my computer"?? WTF are you smoking. Go look up that word in the dictionary some time.
This is just the University enforcing its terms of service as well as THE LAW. There is nothing shady about it, and it's certainly not censorship. If you don't like it then use some other form of internet access.
With this plan you've managed to combine all the negative aspects of both digital music distribution and real life/brick & mortar shopping.
* People like to download mp3's from their computer because they can do it whenever they want, it's faster and more convenient. Your plan requires them to actually get up and go to a store.
* When people do actually go into a store to buy something, they want a quality CD that will last for a long time and that comes with decent artwork. Instead they're getting a shitty CD-R, possibly with crap color inkjet artwork or something.
Why should they go to the trouble? They can make crap CDRs on their own time from stuff they downloaded from Kazaa. In short your plan doesn't offer any benefits over the current status quo, and it has all the drawbacks of both.
People are willing to pay for digital mp3s now because it's quick and convenient from their PC, and they have a sense that the money might actually make it to the artist... Or at least, not as much is going to pay cashiers and mall space rent. If you take these things away they will balk. And if you do actually buy CDs currently you get a relatively high quality product, which your plan would eliminate, so you'd lose interest on that end as well.
I would love to be able to go into a store and have an entire catalog available. That would rock. But I just don't see it as very realistic.
No shit. What does that have to do with anything? The original poster was moaning about the perceived lack of a unencumbered codec that could be easily used to encode things without having to pay royalties.
The point is that everyone is getting their panties ruffled saying "How can SCO say that the GPL is invalid? That's insane! Impossible!" or "If this goes to court there's a chance the GPL would be struck down and invalidated!" With some consideration you realize that the scenario of copyright law trumping the GPL is really not all that far fetched; and that at worst a ruling in SCOs favor would simply establish that the GPL does not apply _in this case_, not that's it's unequivocally and thoroughly invalidated, throwing open source development into the dark ages (as some would fear.)
Here's a little blurb that ran on the AP wire Feb 17 2003 that puts this all into perspective:
Feb. 17 - AP: DVD Player Sales Hit All-Time Record
In only six years, the DVD player has found a place in half the United States' 100 million households as its price has shrunk tenfold to less than $100.
Analysts say the frenetic rate of consumer adoption has set an all-time record - outpacing sales of the transistor radio, the home computer, the CD player and the television.
Research from the DVD Entertainment Group, an industry association, says that DVD manufacturers had sold 54 million players in the United States by the end of 2002. The pace is 10 times faster than that of CD players and four times as fast as videocassette recorders.
It took 13 years for VCRs to hit 30 million units, eight years for CD players and five years for DVD players, according to the group's research.
No free video compression formats? Not true at all. Give XviD a try some time. It's 100% open-source, and it is very high quality; much better than mpeg2 for the same file size. For example, you can transcode a full length DVD movie to a much smaller 700MB XviD file that fits on a single data CD, with a relatively minor loss in quality.
Plus, since DivX and XviD and 3ivx are all based roughly on mpeg-4, it means that they are approximately the same in terms of requirements for playback. The same decoder will play them all, more or less (unless the encoder used some quirky options.) Thus we're starting to see standalone DVD players that also support all the various XviD/DivX flavours in addition to SVCD et al.
I don't care that mpeg-2 is patent-encumbered, there are much more advanced codecs these days.
That's all true, and I'm not arguing with it. My point wasn't really that I think SCO's viewpoint is correct in any form. What I was trying to convey was that it is not all that outlandish at all to have a scenario where some source was released under the GPL but later it is claimed that this is invalid and that copyright law trumps the GPL. This would be the case if indeed the owner was not the one that released it to the GPL.
Whether that applies to THIS is doubtful, since as you point out SCO's contracts stated that derivative works must only be nondisclosed, not that they gained ownership of the copyrights. Additionally, the argument that SCO had previously distributed the questionable work under the GPL is a good one. I'm sure in their warped mind they will contend that since they didn't know that there was precious UNIX code tucked away in there, that their offer of code under the GPL is no longer valid. However, I don't see any legal basis for the premise of, "We were negligent in our research and we'd like to take it all back now." Naturally, a copyright owner always has the option of revoking whatever license the source is under and placing it under a more restrictive one, but the older copies of the code floating around still remain under the GPL. So theoretically SCO could somehow claim that that magical 20% of the linux kernel is no longer under the GPL and everyone must negotiate a SCO license. Even if this were the case it wouldn't matter as all the previously distributed copies would still be under the same GNU license, life would go on as normal, yadda yadda yadda. But this is getting away from the point...
So the point I was trying to make was that there exist perfectly legitimate circumstances where the kinds of things SCO are claiming about copyright law overriding and invalidating the GPL would be true. And in their warped mind, indeed, this IS one of those such cases, and they are persuing it as such. Naturally everyone else seems to have a different opinion on that matter, so in truth it's probably not a great argument, _for this case_.
Regarding SCO and their assertion that the "GPL is trying to override copyright law and is therefore invalid":
I think most of the discussion here on slashdot about this issue is without the proper context. Most people seem to interpret SCOs actions as saying "The GPL is completely and totally invalid and cannot possibly be legitimate." However, their assertion is in the context of their claim that IBM released something that they did not have the right to release. In other words, SCO is saying "The GPL cannot be used to magically make code free. You have to be the legitmate copyright holder of a piece of code in order to dictate its use under the GPL."
In this sense they are very much correct, and I think everyone with half a brain would have to agree. Suppose some company somehow came across code that they did not hold the copyright to. This company removed all the prior copyright claims and replaced them with a claim that this work was licensed under the GPL, and then released it into wide distribution. Clearly, this code is not magically freed forever just because someone claimed that it was GNU-licensed. In this fictional example, all that code that had been spread would be illegal to copy and distribute, if it were shown that its rightful copyright holder did not in fact release it under the GPL. You have have to be the owner of the copyright of something before you can declare that it is in the GPL. And in this specific case, the GPL is in fact overridden by copyright law, because copyright law states that the holder of the copyright has the exclusive right to determine the rules of how something is copied. The GPL acts in a way that builds upon that and augments it, giving the licensee more rights. But in order for it to be valid the person that owns the copyright must declare it to be GNU-licensed. That is the critical point here.
Now, the question as to whether the code in the linux source was indeed "freed by its rightful master" so to speak is another matter entirely. This is where SCO is full of shit, and I'm sure the evidence will eventually show that all of the code in there was indeed GNU-licensed by its rightful owner.
But the important point I'm trying to convey here is that it's very possible for the GPL to be overridden by copyright law. This says NOTHING about the fundamental validity of the GPL however. Even if such as case as the fictional example above were to come to light and it was shown that the code in question did not fall under the GPL, that does not mean that the GPL invalidated. It simply means that in this case the GPL cannot apply because the person claiming that it does is not the copyright holder. It does not mean that suddently the GPL is flawed, invalidated, or that the GPL has been "struck down" or any other doomsday thing like that.
This is not a test of the actual meat of the GPL. SCO is just claiming that the GPL cannot possibly be valid in this case because the copyright holder did not authorize it. That doesn't mean the GPL itself is flawed in any way, it just means that it simply does not apply, because copyright law always trumps.
Most of the responders have hit on the major points, but I'll add a few.
A properly implemented SMTP server for outbound mail is nontrivial. There are zillions of different cases you have to be ready to deal with: the destination host is unreachable, temporarily unavailable, etc. To do this properly your mail program would have to be always running so that it could manage the outbound queue. Not to mention that I would be willing to bet that the people that write email applications have neither the skill nor the inclination to delve into the arcane world of proper SMTP semantics and best practices.
Except for home users, the majority of people that are using mail are doing so from some sort of corporate or university LAN, or some other organizational structure. It just makes sense to have a central server that handles all the sending and receiving of email, instead of making EVERY device or node that wants to send email have to have a full SMTP engine. And for home users there is the organizational unit of the ISP, which acts in a similar way.
Not to mention that this is traditionally how email has been handled, and there's really no good reason to change.
That said, it's entirely possible to run exim, sendmail, qmail, or postfix on your local workstation and send directly rather than relaying. But be prepared for some degree of learning curve as you set those programs up as they can be large and complex (especially in the case of sendmail.)
You demonstrate a massive lack of understanding about how DDoS attacks actually work.
It doesn't matter what you do with the packets. You can analyze them all you want. You can discard every single packet. The result would be the same. Once you've received them the damage is already done, it's pointless to even bother looking at their contents. When someone DDoSes you, it completely and totally saturates your network connection. Legitimate packets are dropped before they can possibly reach you. No amount of analysis of the packets will change anything. Even if you could distinguish with 100% accuracy which packets were bogus and which were legit, it would not help you, as the majority of legitimate packets will never see your equipment -- they will be dropped at some point upstream of your connection.
"Making sure you can reply to the source first"? Are you joking? When this happens your network connection is COMPLETELY AND TOTALLY USELESS. DEAD. You might as well shut everything off until the flood stops.
As far as determining which ISPs these packets come from, good luck. If it is truly distributed, they come from all over the world. And the source is almost always spoofed so it's not like you can just look at the packets and determine where they're coming from... Yes, in theory this shouldn't be possible. If every ISP insituted egress filtering, it would make things like this a lot harder. But most ISPs refuse to do this. Sometimes it's out of complete incompetance, other times it's justified by "we don't have enough CPU in our routers to do egress filtering." But essentially, it boils down to the fact that doing egress filtering will cost them money and it has zero effect on potential customers (nobody knows or cares about this), so it's not likely to be done any time soon. Sad, but true. There was recently a discussion of this matter on the DShield mailing list, if you want more background.
And, even if you could somehow identify which ISP the packets were coming from, good luck doing anything about it. Take the case of spam. We've been trying to get all these open anonymous proxies taken down for years, but yet there are still thousands of nets across the globe that just don't listen to or don't have an abuse desk. It's a completely futile endeavor. In the case of spam there's no question as to the IP addresses of these open proxies, and I'm sure countless pissed off postmasters have sent email to the abuse@ address responsible for these machines, only to be routinely ignored.
So, in summary: - When a DDoS strikes you it knocks you off the net completely - It's usually impossible to tell the true source of the traffic - If done well the traffic will appear to come from thousands of different sources and so it can't be easily filtered upstream - ISPs have shown zero desire to implement egress filtering, which if done univerally would make spoofing impossible or very difficult
The best you can hope for is that the traffic has some identifying pattern, such as every packet having the same source or destination port. If this is the case AND you have a competant and cooperative upstream, you can make some headway with filtering, but expect to have a massive amount of dropped legitimate packets because of the sheer volume. And if done correctly the flood packets cannot be easily filtered.
Silicon's melting point is NOT the problem. The problem is the metal interconnects, and the increased rate of diffusion under high temperature. Microchips depend on there being gradients of impurities to create P and N regions, and as the temperature increases the natural diffusion of these impurities causes them to move, to redistribute themselves.
Aside from that, you have to remember that modern chips these days are like huge tall deli sandwiches, with a stack of 15 or more layers of various compositions. All of them have to maintain their form, shape, and alignment for things to work. As you heat things they expand and contract at different rates, and the thermal stresses involved will cause havok. This is why the processing steps involved have a "thermal bugdet". You cannot perform high temperature operations on the chip in its later stages of life on the production line because it becomes more and more susceptible to these thermal gradients. You have to schedule the steps so that you do all the high-temp things at the beginning of the processing. Remember that the various materials in use for microchips are all extremely brittle, and when they're all bonded together it doesn't take much sheer force at all to cause fracture.
1- In CMOS technology (or any other logic type used in the last 20 years) there is absolutely no resistive path to ground. (except for gate leakage) Two complementary (the C in cmos) PMOS and NMOS transistors are used to eliminate the need for any resistive branch.
Yeah, no shit sherlock. Just because there are no explicit resistors drawn in the circuit doesn't mean that the stored charge isn't dumped to ground through a resistive path. When the NMOS gates turn on, they're effectively shorting the stored charge in the load capacitance to ground through the ON resistance of the gate. And similarly, when the PMOS gates turn on, they charge the load capacitance through the supply rails in an analogous manner.
So just because there aren't explicit resistors (thanks to complimentary logic) doesn't mean that the charge isn't effectively being just supplied to a temporary store and then dumped to ground though resistive paths, which is what the original poster was saying.
Oh, and I should add that the presense of those special water-based "CD marking pens" should in no way be seen as proof that regular permanent markers have any risks. Just because a manufacturer makes something doesn't mean there's a need for it. I can almost visualize a market exec board meeting along the lines of, "Hey, our guys down in research tell us that if we position these special pens next to the blank CDRs and tell them that they need one, they'll buy it. But do our other pens pose a risk? Who cares, it's another sale." How many times do you think a company has made a "Special" version of a product that costs more and is targeted at a specific purpose just to trick people into buying it, when generic alternatives are equally effective?
I call FUD on this. The alcohol solvent used with permanent markers evaporates quickly into the air. It's mostly gone after 30 seconds or so and it is surely almost completely gone after a few hours. I cannot fathom how this residual solvent could possibly do anything to the CD. ALso consider that if this solvent DID have the ability to decompose polycarbonate, then wouldn't you expect it to manifest IMMEDIATELY after writing on the disc, when the concentration is highest? That it would somehow remain there for months or years, slowly eating away at the plastic just doesn't make sense when you consider that the solvent concentration is probably thousands of times higher when you initially write on the surface.
And as a poster below has mentioned, Sanford states that in all of the testing they have done they cannot reproduce a case of the solvent attacking polycarbonate. Sure, you probably shouldn't trust the manufacturer as a completely unbiased source but I've been unable to find a definitive, scientific study that shows any link whatsoever between the alcohol solvent and the polycarbonate CD substrate.
Slashdot Mirror
Right, I should have said "domain owner and/or DNS server operator and/or mail server administrator" whereever I said "everyone" since that's kind of a mouthful. :-)
Right, and these miniscule hard drives don't spin at anywhere close to the 7200 RPM you probably have in your desktop. Sure, if you pick one of those up you're in for a shock at how much gyroscopic reaction there is, but that's because of multiple platters, much larger radius, and faster angular velocity (rpm).
That's easy to say, but if you have critical infrastructure built around SCO it's not like you can just wake up one day and say "Hmmm, this doesn't look good, how about we abandon all those production servers and build something completely different." In business, things that work and are supported don't get touched without good reason, especially if megabucks have been spent getting to that point. It doesn't matter if SCO doesn't have shit for features or doesn't support the latest doodads. It's in production in a number of places and you can't just yank the rug out from under a business like that.
It's one thing to denounce SCO for being the assholes that they are, but it's another completely different thing to actually move away from something that critical without a LOT of planning and testing. Sure, you get started on that as soon as possible, but it takes time. YOu can't just say "SCO's irrelevant now" because to some businesses, it's very relevant -- for better or worse.
Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.
But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.
Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)
Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.
So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.
So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.
Here's something for you to consider: Unless your email services use closed-loop a.k.a. confirmed opt-in then you're a spammer. Why? Consider the case of some random party entering my email address in your handy little web form. Unless your system first confirms my email address (with a unique token that must be acknowledged) then I'll eventually be receiving crap from you that I do not wish to receive, and you are thus a spammer. It is not a question of IF this will ever happen, but when. People mistype email addresses, or make up ones they think are invalid. Or, they maliciously sign up some third party on every web form they can find. It happens. If your system does not deal with it properly by confirming every email address then you're a spammer, plain and simple, and you deserve to be blacklisted when it happens. It doesn't matter if you had the best of intentions, or if your messages contain removal instructions in 23 languages. Spam is not about content, it's about consent.
Since when was ming qualify as histrionics? SWF has its faults but there are ways to work with it nonpainfully and dynamically.
By the time Longhorn actually ships, we'll all have 20 TeraHertz processors to go with our moon colonies and personal rocket packs. Problem solved.
From the article and replies on here, it seems that this program simply detects if you are running Kazaa (and likely others.) So, they're being selective in that they're looking at the traffic to see what port it's on and whether it matches a Kazaa signature. But they're not looking at the payload and saying "Oh gee, this looks like Metallica, better cut off access." I don't think such a thing is even possible, as it would require either a huge database of file IDs or hashes, or some unobtainably advanced AI.
Now, the debate about how there are non-infringing uses of Kazaa is certainly valid. But that's another matter entirely. My point is that a school enforcing a policy of "You cannot use this application because we get many complaints from people regarding violations when you do" does not even come close to censorship. It's a policy decision regarding their facilities, much like "We're closing off this road, you can no longer drive here" or "These basketball courts are closed after 10pm, go away."
Oh fucking please, that is the most tired argument I've ever heard. By that logic if I choose not to use the school's gym (say, because I don't approve of their rules of the basketball court) then I shouldn't have to pay that part of the fees. And if I never set foot on the school's track, why am I paying for its upkeep anyway? Damn the bus system, I have a car, why should I pay for that?
The answer is simple, everybody pays the same fees. The facilities would not exist if they were only paid for by the specific people that use it. By splitting the cost evenly it means that EVERYONE as a COMMUNITY benefits, as opposed to the alternative which is having NO FACILITIES at all, but every student $60 richer.
I suppose you're also going to tell me that if you decide not to use the public library that you shouldn't have to pay for it with my tax dollars? That you don't have kids and so your tax dollars shouldn't be supporting children's programs or schools? Puh-lease.
If you don't agree with the network usage policy, fine, don't use the system. But don't get some high and mighty "I'm paying for it therefore I can do any fucking thing I want" attitude.
"Censoring my computer"?? WTF are you smoking. Go look up that word in the dictionary some time.
This is just the University enforcing its terms of service as well as THE LAW. There is nothing shady about it, and it's certainly not censorship. If you don't like it then use some other form of internet access.
Holy jeebus. I can just see some new tech that they just hired to do some server maintenance...
Boss: "Okay Fred, you'll be working right over here." (beep! Door opens.)
Fred: (pauses for 3 sec and looks around) "I quit."
With this plan you've managed to combine all the negative aspects of both digital music distribution and real life/brick & mortar shopping.
* People like to download mp3's from their computer because they can do it whenever they want, it's faster and more convenient. Your plan requires them to actually get up and go to a store.
* When people do actually go into a store to buy something, they want a quality CD that will last for a long time and that comes with decent artwork. Instead they're getting a shitty CD-R, possibly with crap color inkjet artwork or something.
Why should they go to the trouble? They can make crap CDRs on their own time from stuff they downloaded from Kazaa. In short your plan doesn't offer any benefits over the current status quo, and it has all the drawbacks of both.
People are willing to pay for digital mp3s now because it's quick and convenient from their PC, and they have a sense that the money might actually make it to the artist... Or at least, not as much is going to pay cashiers and mall space rent. If you take these things away they will balk. And if you do actually buy CDs currently you get a relatively high quality product, which your plan would eliminate, so you'd lose interest on that end as well.
I would love to be able to go into a store and have an entire catalog available. That would rock. But I just don't see it as very realistic.
No shit. What does that have to do with anything? The original poster was moaning about the perceived lack of a unencumbered codec that could be easily used to encode things without having to pay royalties.
The point is that everyone is getting their panties ruffled saying "How can SCO say that the GPL is invalid? That's insane! Impossible!" or "If this goes to court there's a chance the GPL would be struck down and invalidated!" With some consideration you realize that the scenario of copyright law trumping the GPL is really not all that far fetched; and that at worst a ruling in SCOs favor would simply establish that the GPL does not apply _in this case_, not that's it's unequivocally and thoroughly invalidated, throwing open source development into the dark ages (as some would fear.)
No free video compression formats? Not true at all. Give XviD a try some time. It's 100% open-source, and it is very high quality; much better than mpeg2 for the same file size. For example, you can transcode a full length DVD movie to a much smaller 700MB XviD file that fits on a single data CD, with a relatively minor loss in quality.
Plus, since DivX and XviD and 3ivx are all based roughly on mpeg-4, it means that they are approximately the same in terms of requirements for playback. The same decoder will play them all, more or less (unless the encoder used some quirky options.) Thus we're starting to see standalone DVD players that also support all the various XviD/DivX flavours in addition to SVCD et al.
I don't care that mpeg-2 is patent-encumbered, there are much more advanced codecs these days.
That's all true, and I'm not arguing with it. My point wasn't really that I think SCO's viewpoint is correct in any form. What I was trying to convey was that it is not all that outlandish at all to have a scenario where some source was released under the GPL but later it is claimed that this is invalid and that copyright law trumps the GPL. This would be the case if indeed the owner was not the one that released it to the GPL.
Whether that applies to THIS is doubtful, since as you point out SCO's contracts stated that derivative works must only be nondisclosed, not that they gained ownership of the copyrights. Additionally, the argument that SCO had previously distributed the questionable work under the GPL is a good one. I'm sure in their warped mind they will contend that since they didn't know that there was precious UNIX code tucked away in there, that their offer of code under the GPL is no longer valid. However, I don't see any legal basis for the premise of, "We were negligent in our research and we'd like to take it all back now." Naturally, a copyright owner always has the option of revoking whatever license the source is under and placing it under a more restrictive one, but the older copies of the code floating around still remain under the GPL. So theoretically SCO could somehow claim that that magical 20% of the linux kernel is no longer under the GPL and everyone must negotiate a SCO license. Even if this were the case it wouldn't matter as all the previously distributed copies would still be under the same GNU license, life would go on as normal, yadda yadda yadda. But this is getting away from the point...
So the point I was trying to make was that there exist perfectly legitimate circumstances where the kinds of things SCO are claiming about copyright law overriding and invalidating the GPL would be true. And in their warped mind, indeed, this IS one of those such cases, and they are persuing it as such. Naturally everyone else seems to have a different opinion on that matter, so in truth it's probably not a great argument, _for this case_.
...yeah, that or we could just stop posting them, given that they're old and trite by now. HINT. HINT.
Regarding SCO and their assertion that the "GPL is trying to override copyright law and is therefore invalid":
I think most of the discussion here on slashdot about this issue is without the proper context. Most people seem to interpret SCOs actions as saying "The GPL is completely and totally invalid and cannot possibly be legitimate." However, their assertion is in the context of their claim that IBM released something that they did not have the right to release. In other words, SCO is saying "The GPL cannot be used to magically make code free. You have to be the legitmate copyright holder of a piece of code in order to dictate its use under the GPL."
In this sense they are very much correct, and I think everyone with half a brain would have to agree. Suppose some company somehow came across code that they did not hold the copyright to. This company removed all the prior copyright claims and replaced them with a claim that this work was licensed under the GPL, and then released it into wide distribution. Clearly, this code is not magically freed forever just because someone claimed that it was GNU-licensed. In this fictional example, all that code that had been spread would be illegal to copy and distribute, if it were shown that its rightful copyright holder did not in fact release it under the GPL. You have have to be the owner of the copyright of something before you can declare that it is in the GPL. And in this specific case, the GPL is in fact overridden by copyright law, because copyright law states that the holder of the copyright has the exclusive right to determine the rules of how something is copied. The GPL acts in a way that builds upon that and augments it, giving the licensee more rights. But in order for it to be valid the person that owns the copyright must declare it to be GNU-licensed. That is the critical point here.
Now, the question as to whether the code in the linux source was indeed "freed by its rightful master" so to speak is another matter entirely. This is where SCO is full of shit, and I'm sure the evidence will eventually show that all of the code in there was indeed GNU-licensed by its rightful owner.
But the important point I'm trying to convey here is that it's very possible for the GPL to be overridden by copyright law. This says NOTHING about the fundamental validity of the GPL however. Even if such as case as the fictional example above were to come to light and it was shown that the code in question did not fall under the GPL, that does not mean that the GPL invalidated. It simply means that in this case the GPL cannot apply because the person claiming that it does is not the copyright holder. It does not mean that suddently the GPL is flawed, invalidated, or that the GPL has been "struck down" or any other doomsday thing like that.
This is not a test of the actual meat of the GPL. SCO is just claiming that the GPL cannot possibly be valid in this case because the copyright holder did not authorize it. That doesn't mean the GPL itself is flawed in any way, it just means that it simply does not apply, because copyright law always trumps.
Most of the responders have hit on the major points, but I'll add a few.
A properly implemented SMTP server for outbound mail is nontrivial. There are zillions of different cases you have to be ready to deal with: the destination host is unreachable, temporarily unavailable, etc. To do this properly your mail program would have to be always running so that it could manage the outbound queue. Not to mention that I would be willing to bet that the people that write email applications have neither the skill nor the inclination to delve into the arcane world of proper SMTP semantics and best practices.
Except for home users, the majority of people that are using mail are doing so from some sort of corporate or university LAN, or some other organizational structure. It just makes sense to have a central server that handles all the sending and receiving of email, instead of making EVERY device or node that wants to send email have to have a full SMTP engine. And for home users there is the organizational unit of the ISP, which acts in a similar way.
Not to mention that this is traditionally how email has been handled, and there's really no good reason to change.
That said, it's entirely possible to run exim, sendmail, qmail, or postfix on your local workstation and send directly rather than relaying. But be prepared for some degree of learning curve as you set those programs up as they can be large and complex (especially in the case of sendmail.)
You demonstrate a massive lack of understanding about how DDoS attacks actually work.
It doesn't matter what you do with the packets. You can analyze them all you want. You can discard every single packet. The result would be the same. Once you've received them the damage is already done, it's pointless to even bother looking at their contents. When someone DDoSes you, it completely and totally saturates your network connection. Legitimate packets are dropped before they can possibly reach you. No amount of analysis of the packets will change anything. Even if you could distinguish with 100% accuracy which packets were bogus and which were legit, it would not help you, as the majority of legitimate packets will never see your equipment -- they will be dropped at some point upstream of your connection.
"Making sure you can reply to the source first"? Are you joking? When this happens your network connection is COMPLETELY AND TOTALLY USELESS. DEAD. You might as well shut everything off until the flood stops.
As far as determining which ISPs these packets come from, good luck. If it is truly distributed, they come from all over the world. And the source is almost always spoofed so it's not like you can just look at the packets and determine where they're coming from... Yes, in theory this shouldn't be possible. If every ISP insituted egress filtering, it would make things like this a lot harder. But most ISPs refuse to do this. Sometimes it's out of complete incompetance, other times it's justified by "we don't have enough CPU in our routers to do egress filtering." But essentially, it boils down to the fact that doing egress filtering will cost them money and it has zero effect on potential customers (nobody knows or cares about this), so it's not likely to be done any time soon. Sad, but true. There was recently a discussion of this matter on the DShield mailing list, if you want more background.
And, even if you could somehow identify which ISP the packets were coming from, good luck doing anything about it. Take the case of spam. We've been trying to get all these open anonymous proxies taken down for years, but yet there are still thousands of nets across the globe that just don't listen to or don't have an abuse desk. It's a completely futile endeavor. In the case of spam there's no question as to the IP addresses of these open proxies, and I'm sure countless pissed off postmasters have sent email to the abuse@ address responsible for these machines, only to be routinely ignored.
So, in summary:
- When a DDoS strikes you it knocks you off the net completely
- It's usually impossible to tell the true source of the traffic
- If done well the traffic will appear to come from thousands of different sources and so it can't be easily filtered upstream
- ISPs have shown zero desire to implement egress filtering, which if done univerally would make spoofing impossible or very difficult
The best you can hope for is that the traffic has some identifying pattern, such as every packet having the same source or destination port. If this is the case AND you have a competant and cooperative upstream, you can make some headway with filtering, but expect to have a massive amount of dropped legitimate packets because of the sheer volume. And if done correctly the flood packets cannot be easily filtered.
Silicon melts at approx 1400C (2600F)
Aluminum melts at approx 660C (1200F)
Copper melts at approx 1100C (2000F)
Silicon's melting point is NOT the problem. The problem is the metal interconnects, and the increased rate of diffusion under high temperature. Microchips depend on there being gradients of impurities to create P and N regions, and as the temperature increases the natural diffusion of these impurities causes them to move, to redistribute themselves.
Aside from that, you have to remember that modern chips these days are like huge tall deli sandwiches, with a stack of 15 or more layers of various compositions. All of them have to maintain their form, shape, and alignment for things to work. As you heat things they expand and contract at different rates, and the thermal stresses involved will cause havok. This is why the processing steps involved have a "thermal bugdet". You cannot perform high temperature operations on the chip in its later stages of life on the production line because it becomes more and more susceptible to these thermal gradients. You have to schedule the steps so that you do all the high-temp things at the beginning of the processing. Remember that the various materials in use for microchips are all extremely brittle, and when they're all bonded together it doesn't take much sheer force at all to cause fracture.
1- In CMOS technology (or any other logic type used in the last 20 years) there is absolutely no resistive path to ground. (except for gate leakage) Two complementary (the C in cmos) PMOS and NMOS transistors are used to eliminate the need for any resistive branch.
Yeah, no shit sherlock. Just because there are no explicit resistors drawn in the circuit doesn't mean that the stored charge isn't dumped to ground through a resistive path. When the NMOS gates turn on, they're effectively shorting the stored charge in the load capacitance to ground through the ON resistance of the gate. And similarly, when the PMOS gates turn on, they charge the load capacitance through the supply rails in an analogous manner.
So just because there aren't explicit resistors (thanks to complimentary logic) doesn't mean that the charge isn't effectively being just supplied to a temporary store and then dumped to ground though resistive paths, which is what the original poster was saying.
Oh, and I should add that the presense of those special water-based "CD marking pens" should in no way be seen as proof that regular permanent markers have any risks. Just because a manufacturer makes something doesn't mean there's a need for it. I can almost visualize a market exec board meeting along the lines of, "Hey, our guys down in research tell us that if we position these special pens next to the blank CDRs and tell them that they need one, they'll buy it. But do our other pens pose a risk? Who cares, it's another sale." How many times do you think a company has made a "Special" version of a product that costs more and is targeted at a specific purpose just to trick people into buying it, when generic alternatives are equally effective?
I call FUD on this. The alcohol solvent used with permanent markers evaporates quickly into the air. It's mostly gone after 30 seconds or so and it is surely almost completely gone after a few hours. I cannot fathom how this residual solvent could possibly do anything to the CD. ALso consider that if this solvent DID have the ability to decompose polycarbonate, then wouldn't you expect it to manifest IMMEDIATELY after writing on the disc, when the concentration is highest? That it would somehow remain there for months or years, slowly eating away at the plastic just doesn't make sense when you consider that the solvent concentration is probably thousands of times higher when you initially write on the surface.
And as a poster below has mentioned, Sanford states that in all of the testing they have done they cannot reproduce a case of the solvent attacking polycarbonate. Sure, you probably shouldn't trust the manufacturer as a completely unbiased source but I've been unable to find a definitive, scientific study that shows any link whatsoever between the alcohol solvent and the polycarbonate CD substrate.