No offense to you personally, but I'm seeing a lot of the same comments from a lot of different people.
First of all, this is an experiment.
Second of all, they seem to have convinced a lot of people in positions they probably got by knowing what they're doing that this has the potential to save a lot of time and money. Please concede at least the possibility that this might actually happen or at the very least, your uneducated concerns might have already been addressed by the educated.
Stop for a minute and repeat to yourself: I do not run a major ocean port. I do not run a major ocean port.
Re:SVG not (yet?) for presentation
on
SVG On the Rise
·
· Score: 5, Informative
SVG is not intended to do synchronized multimedia. The G in SVG stands for "Graphics". If you want to build an all-out presentation with animation and audio, use SMIL in conjunction with SVG (or whatever you want for the graphics/animation side).
Sadly, yes. We do not use SMS or any similar text messaging service for reliable messaging as a result. E-mail to a pager gateway is far more reliable (99.99% or better, in my experience), and if you have a method for delivering directly to the paging provider, that's even better still.
Keep in mind through all of this that it is not illegal for you to download and store music you didn't purchase. So if the RIAA is attacking people that have downloaded MP3's, they are wrong on more than one level. The people that are breaking the law are those that share those MP3's in the first place.
The RFC (actually the HTTP/1.1 specification) discusses "HTTP caching". It's quite explicit. Caching at the user-agent and proxy level are discussed, but not to the exclusion of all other uses.
However, what people are proposing is to set up a mirror.
You're picking nits. An HTTP proxy can take a variety of forms. Here is the definition quoted in the HTTP/1.1 specification (emphasis mine):
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to
provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
It does not say how this proxy should be built or implemented, it just describes some device that acts as a server from the user's perspective and a client from the origin server's perspective.
What I'm describing is just another form--albeit an unusual one--of a standard caching HTTP proxy. You're arguing technical definitions here that aren't really relevant.
Have you never visited a page using Google's cache?
It's a grey area of the copyright law -- automatically-generated headers do not necessarily constitute the permission of the content owner, especially since the content owner can't always control the headers generated by his server (i.e. in a shared environment).
Huh? It's absolutely not a gray area. In the case of the Google cache, it might be, because Google is indeed preserving the contents of the pages it spiders well beyond the norm for any HTTP cache.
But in the case of a "content owner" and the cache control functions of HTTP, there is no "gray area" whatsoever:
By default, most HTTP servers only send a Last-Modified header along with the content. If this were the extent of the "HTTP caching universe", it alone would be more than sufficient, since a caching proxy would just have to go back to the server and make a conditional GET request, where the origin server would respond with a "304" if nothing changed. This alone would significantly reduce the amount of load/traffic on a site without the possibility of the proxy delivering stale information to the user. Content owners don't need to know or care about any of this, and they certainly couldn't put up a legal case saying that their web servers were delivering a "304 Not Modified" response and that response facilitated copyright infringement. That is completely absurd.
So right up front, with extreme HTTP basics, we have enough to build our HTTP caching proxy (which appears to the user as a mirror, even though it isn't really one, since we never cache/duplicate content that is dynamic, changing for each request, or where the origin server has specified HTTP headers disallowing caching).
If we wanted to go a step further, this requires additional help from the origin server. In other words, to make proper use of the more advanced HTTP caching techniques discussed in the standard, the origin server has to explicitly be modified to give us additional cache-control headers, or the content needs to provide additional cache-control headers (perhaps in the <meta> tags, or configured through a.htaccess file).
So at this point, if a page is delivering an Expires or Cache-Control header that is explicitly offering information that allows us to cache the resulting document for a certain period of time (seconds? hours? weeks?), someone had to make the very conscious and explicit decision to do that, which means any form of caching or proxying that we wish to do on that is fair game.
Keep in mind also that it is highly unusual for sites to have "volatile" content with cache-control information suggesting it can be cached for any extended period. Even having this information cached for just a few minutes, or an hour, would be completely sufficient to mitigate the effects of a Slashdot posting, since it would mean the caching proxy would only have to make a single request once every few minutes, or every hour, for the entire Slashdot community.
The bottom line is that if there is a web site out there that is lying as part of its HTTP implementation, you cannot remotely fault the users, user agents or proxies for acting in good faith on that information. Again, by default, servers do not provide any information on how long a resource may be cached (if at all), though it does allow validation through the use of conditional GETs, which can significantly reduce the volume involved in the responses, even if it won't reduce the number of hits. If a server expresses more advanced cache-control headers, it's doing so as part of an explicit request. If whoever performed that configuration was not authorized to do so, the content authors need to take that up with the owner of the server (much as an author would need to take up distribution issues over a physical book up with their publisher).
Keep in mind that at no time does this "mirror" or caching proxy ever keep a copy of this data that is truly independent from the data on the origin server. It only keeps this data around as long as the origin server said it could (as expressed through the Expires header or Cache-Control parameters). The proxy is still required to validate against the origin server as needed (by default, unless the web server was explicitly configured otherwise, this means it has to validate each and every request using a conditional or complete GET request). If the origin server disappears or removes the content, as soon as their cache-control values expire, the content disappears from the proxy as well. Yes, this appears to the user as a mirror, but functions more like a proxy.
If you have a quota, it's your responsibility not to exceed it -- not Slashdot's or anyone else's.
I completely agree. Nothing I have ever said in this thread has once indicated that Slashdot is in any way obligated to configure a mirroring service. I have repeatedly stated, however, that Slashdot is effectively being one giant asshole towards those smaller sites it does link to without giving them a head's up when it knows the site probably won't handle it. In most parts of the world, it's perfectly legal to be an asshole, and in many places, one's right to be an asshole is even protected. But that doesn't make the person any less of an asshole.
Do you understand that caching websites without the author's permission is illegal?
I apparently know a little more about HTTP than you seem to, my friend. If it were illegal to cache HTTP resources, then most HTTP proxies are illegal as well.
copying the page and giving it off as yours would surely spark many lawsuits.
If a site is expressing a future date in an HTTP "Expires" header, or a max-age Cache-Control header, they're saying something very specific about how that data can be used by browsers and HTTP proxies alike. Read the document above to what it is.
At the very least, this is lazy
What?? Just because I choose to post some data online does not mean that I must automatically spend the money to create an environment and supply a network connection capable of withstanding a post on Slashdot. This reasoning is flawed. Most people with smaller web sites (e.g. academic) do not have the funds to do this. You seem to be under the flawed impression that any server with any form of network connection should be capable, with proper administration, of handling the traffic that a post on Slashdot generates.
This is like saying that people who are victims of distributed denial-of-service attacks get what they deserve for not having a fast enough network connection or a router that can do a better job of filtering packets. This is a totally unreasonable expectation. Sure, they "deserved" network traffic by placing their servers and networks on the Internet, but they're not lazy just because they choose not to spend the money for an enterprise-quality network when it's horribly out of scale for their requirements.
If you don't lock your front door, you shouldn't complain about burglars.
I can't even begin to touch this analogy.
I would be glad for the extra publicity, not bitchy about the traffic.
I'm sure that somewhere, deep down under his annoyance, he is.
Are you going to sit there and honestly say that if a web site you operated were brought to its knees and made totally unavailable due to a post on Slashdot, it would not have irritated you? "Aww shucks, I should have planned ahead better and gone with that Sun E5500 instead of this P133 after all! How stupid of me for not spending a half a million on infrastructure for my personal home page instead of this extra PC." Get real.
I do concede, though (as I have in previous posts), that he should not have been surprised this would have happened one day. And maybe he was aware that it could happen one day, and maybe he even planned ahead in the sense that there might have been some people willing and able to mirror his site's content at his request. If only he had some advance notice.
If, on the other hand, Slashdot mirrored my site without asking permission, I would be somewhat pissed.
If you are expressing the cacheability of resources on your web site incorrectly, then you are to blame here. Set up your cache control headers in your web server to more accurately describe how each resource could be cached. If you seem to think that every request should go back to the server and get re-retrieved, and that HTTP 304 responses are the devil, then by all means, just configure your web server so that it won't allow it. The point is, the site owner can make this decision (and should already be making it).
Please don't assume that everything you read on Slashdot is factual. Concede the possibility that the stuff in the FAQ is written by human beings who are fallible.
Your point of view here is totally absurd (which I guess is why you're posting as an AC).
I completely agree that people posting information to the web should not be surprised if that generates more activity than they would have wanted. In that respect, yes, it is "their own fault" and they "deserve" what they get.
But your comment suggesting that every web server and network be configured to survive a Slashdotting is idiotic. A "properly configured 333Mhz crap machine" most certainly will not survive any but the most mild Slashdotting, even assuming the network does. The fact that you make this statement shows me that you have no idea what you are talking about. Please post some numbers.
Your lack of sympathy for those people just trying to get something interesting/useful posted to the web astounds me. Someone that can afford to put information online for the benefit of all but cannot afford to do so using high-end hardware and high-capacity network links should not be punished for doing so. Not everyone is a professional web provider. Not everyone needs to be one. For most sites, with most content, Slashdot-levels of traffic will never happen. Why spend money building an environment that will handle it? In addition, some environments can handle it, so long as they have sufficient notice. What's wrong with a policy of giving people a few days notice before posting their link on Slashdot when it's clear their site probably won't survive it? Maybe the site owners can take some steps to ensure their site would stay up, or maybe temporarily mirror the content in question somewhere else? There's a lot that can be done here to prepare for a Slashdotting, but nobody has the decency to allow that to happen.
I agree that 'michael' can't be directly blamed for this, but Slashdot's policies on the matter most certainly can. It's just a matter of common sense and not being an ass. You're right: there's nothing requiring Slashdot to do this, and anything with a URL is fair game to be linked (with the traffic that that causes), but come on, there is a human factor here, and Slashdot could be a bit more courteous here.
Re:Slashdot effect (the good, bad, and the FAQ)
on
Barcode-Controlled Home?
·
· Score: 2, Offtopic
I agree with the fact that Slashdot shouldn't have to mirror sites. I think most of their excuses as to why they don't are fairly absurd, though. This problem can be solved in a site-friendly, banner-ad-friendly and legal-friendly way through the use of run-of-the-mill HTTP proxies.
But however that goes, Slashdot really does need to be a little friendlier towards site operators when it's fairly clear up front that their site probably won't handle the traffic.
For the record, I've had news sites (e.g. MSNBC) do a story that involved some piece of content on my site, and generally, they ask my permission first, checking that I'm OK with it and that my servers can handle it. If they can take a few moments to do this, surely Slashdot can as well.
Re:Slashdot effect (the good, bad, and the FAQ)
on
Barcode-Controlled Home?
·
· Score: 1, Offtopic
What if they have banners they rely on for $$$? What if their site is based on php and some of the important information is pulled from a database?
Standard HTTP headers reflect the "cachability" of every HTTP resource available on the web. Static pages that never change and don't carry personalized information do not have to be served up by the same server for every request. An HTTP proxy detects this based on HTTP headers that come with the page and will cache these pages for the benefit of those downstream.
Further, 'iframe's or dynamic content should be expressing appropriate cache control headers to prevent only those resources from being cached, or for those pieces of dynamic content that may only change every few minutes, that those resources be cached until the next update is scheduled.
A mirror still isn't out of the question here, despite the excuses in the FAQ. Take an HTTP caching proxy, put a "mirrors.slashdot.org" face on it, and this problem is solved.
Setting a password, or installing mod_throttle and setting it up right would be a start.
Most sites are small. By small I mean someone has decided they want to set up a quick-and-easy web site, throws it up on some personal web server software, and lets people at it.
Do they "deserve" the flood of traffic Slashdot might generate to it? Perhaps. Is it "their own fault" that their network connection and/or server is brought to its knees by the visits generated by Slashdot? Perhaps.
That doesn't mean they can't be annoyed, frustrated and a little bitter at Slashdot. Wouldn't you be?
For your challenge that someone come up with a "legally sound" solution to the problem, keep in mind the responses in the FAQ are an utter joke. Slashdot programmers are lazy.
All someone needs to do is set up a mirroring front-end that just hooks into an HTTP caching back-end. An image is a static resource. Most web servers will specify a 'max-age' for that resource, or at the very least they express a Last-Modified header that a proxy can use to compute an acceptable expiration date before trying to revalidate it. This simple HTTP caching behavior could very simply drive a mirroring site.
Sites that have certain areas or iframes or images or whatever that they want to be requested for every visit or every request can express (and should already be expressing) these requirements through proper use of Expires or Cache-Control headers.
Caching HTTP proxies have been around for years. All they'd need to do is put a different face on one and this problem is solved.
he seems to have forgotten that one of the original ideas of the WWW was to have people link back and forth to each other
I think you're reading too much into things.
He's annoyed and frustrated that his server was brought down due to the traffic created by this article. Wouldn't you be?
Most servers cannot handle the traffic Slashdot generates. This is an unfortunate fact, but it needs to be a fact that Slashdot admits to and tries to mitigate. They don't. The FAQ gives a few excuses that don't hold any water and that's the end of the discussion as far as they're concerned.
I think you're looking at it from the wrong angle. A guy puts up some information on a site using meager resources. He hopes that information will be useful and interesting to those that happen upon it. The hardware turns out to be perfectly adequate for his needs. Then someone posts a link on a popular site and the traffic increases by a factor of 10,000. The site goes down.
Frustrated, he pulls the content down in an attempt at restoring at least some semblence of service to the site.
Wouldn't you share his emotions? Sure, he "asked" for it and "deserved" it by posting that data online, but it's still annoying and frustrating that you can't make that information available due to its inflated popularity by being reported on by a site.
Slashdot needs to be a little more cautious with this type of thing. At the very least, use standard HTTP caching mechanisms to set up a form of mirror for those sites that do express a willingness to be cached through HTTP.
I don't buy it; use a caching proxy if nothing els
on
Barcode-Controlled Home?
·
· Score: 5, Insightful
I don't buy the FAQ's explanation. I think they're deliberately oversimplifying or just saying "it'll be too complicated and annoying for everyone" because they're lazy.
At a very minimum, use a caching HTTP proxy to feed a "mirrors.slashdot.org" site. Links would be set up under their own, unique path on this site (e.g. mirrors.slashdot.org/some.site/path/document or even mirrors.slashdot.org/50449) and this would funnel into a caching HTTP proxy. So long as the other site set up reasonable cache headers, there is no reason why the sites would object to their pages being cached in this fashion. This is built into HTTP, for fuck's sake. Wherever they have advertising being done, they're probably doing that in an iframe with its own caching policy. HTTP would handle all of this perfectly fine. Set an artificially low max-age value (overriding the site's) if you're really worried about things getting stale, but even this is unnecessary.
This is all fairly trivial to do. Slashdot authors/programmers have just gotten lazy in the last few years. They don't innovate or improve, they just watch over the slashcode "open source" project and occasionally toss out a few minor releases.
From your quote of the FAQ:
I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?
Why don't you use some fucking common sense, ask yourself, "Do I think this site will survive linking?" And if the answer is "probably not," then e-mail them or call them, give them a head's up, and only if you fail to get a response in a reasonable amount of time would I ever think it's OK to link to them anyway.
They do have the information posted online, so any link and any amount of traffic is fair, but at least have the goddamn courtesy to mitigate the amount of damage you're knowingly causing. That's all that's being asked for: courtesy. Slashdot authors are lazy, that's all there is to it.
I find myself routinely investigating problems with applications where I don't have immediate access to the source code, or where it's difficult to replicate the problem and we find that we have to correct it (restart, etc.) without getting an adequate opportunity to investigate.
I would love to be able to grab a snapshot of a process and identify exactly what it was doing. In some respects, this can be satisfied by getting a process to core dump and analyzing the core, but to date this has always been an annoying and time-consuming process, requiring source code to see anything useful.
Re:What about appliances and rack-mount?
on
Computer Room Hot?
·
· Score: 2
So you're saying that regardless of the amount of equipment we put into an enclosure, the temperature of the air at the exhaust will be the same temperature as the air at the intake?
You do realize this equipment is turned on, yes? And that we aren't using jet engines for our fans?
What about appliances and rack-mount?
on
Computer Room Hot?
·
· Score: 4, Informative
90% of my excessive volume and heat generation comes from various rack-mount appliances (like Cisco switches), not pee-cees. It doesn't look like these things are very friendly towards that type of environment.
The basic concept might still be sound, though. Turn your rack into an enclosure, add some intake fans, and vent the entire rack's exhaust somewhere else. (I wonder what the exhaust temperature for an entire rack would reach?)
Re:Do not pass go, do not collect $200
on
Dow vs. Parody
·
· Score: 2
I agree.. the parody site and press release were a little too convincing. They either needed to go a little further with the site and the release so that it was obvious, or add a disclaimer.
While some (most?) of us could probably tell that it was a parody anyway (or at least be suspicious that it was), we're in the minority here. It needs to be obvious to the layperson.
One of the things that I tend to tell people is that your degree should be a solid foundation for what you want to be doing in 5 or 15 years. Yah, if all someone wants to do is code HTML for the rest of their life, any computer-related degree is probably unnecessary.
But usually when someone says they want to code HTML for the rest of their life, what they really mean is maybe one of:
a) code online user interfaces for the rest of their life. To this person I might suggest a degree in art or psychology;
b) write and format/typeset online content for the rest of their life. To this person I might suggest a degree in english, or some other solid foundation that a journalist might take; or
c) develop online markup languages and data representations for the rest of their life. Here you might really want a good solid computer science degree, with a thorough understanding how how everything works together (since that's what a markup language is, really: glue)
So you're right, not every computer-related job necessarily needs a "computer science" degree. But instead of recommending that they just go out and get a job, and rely on work experience to carry them forward, I would suggest that they at least consider a good, solid foundation in a related field so that when HTML becomes obsolete, they don't go obsolete with it.
Re:gravity effects are instantaneous
on
E ~ mc^2
·
· Score: 2
This is incorrect. Gravitational and magnetic fields are most certainly limited by the speed of light.
This is how we have things like electro-magnetic waves and gravitational waves. If time (speed) did not factor in to magnetism or gravity, there would be no such thing as a wave based on either of these things.
If a modification like this is proved to be needed, it won't make much more of a difference than relativity did to Newton's equations: for most purposes, what we've been using to date is going to be perfectly adequate. Only at extreme velocities, scales and energy states do we see conditions where the modified equations make a difference.
And I can entirely see the city's point about why reporters going around rummaging through peoples' garbage is a bad idea. Reporters are not answerable to anybody - government is.
While this is a very good point (and I'll elaborate in a second), it's also outside of the scope of the problem.
The issue here is that the courts ruled that nabbing someone's garbage without a warrant was legal because the act of leaving your garbage on the curb means you've given up ownership and surrendered it to the public. They were not saying that the police could take the garbage because they should just be able to, given the nature of their job. The sole justification for allowing them to take it was that the owner surrendered theit trash by leaving it for pick-up.
Based on that, there should be nothing wrong or illegal about any other person coming up and taking that same trash.
Now, if we want to say that the police should be allowed to pick up someone's garbage while still protecting it against any random person, that's an entirely separate (though noble) issue. Personally, though, if we're going to start protecting everyone's trash from public snooping, with the exception of those "lawfully authorized" to snoop, I would prefer to see some sort of check in place to ensure that those "lawful" snoops aren't abusing their powers. How would we do that? With a search warrant.
People frequently leave things on their curb when they want to give them away. I'd say the Taker of the Weed Whacker has a perfectly plausible defense.
The issue is that some "web" technologies (e.g. HTML) can easily find themselves in other areas (e.g. HTML e-mail). With the licensing phrased the way it is now, a "web" standard can be made free and beautiful, get entrenched as a de facto standard, but then everyone wanting to extend that into other related technologies would suddenly have to pay out the nose for patent royalties, which neatly excludes most all free software. This is the situation we are trying to avoid.
Wouldn't it suck to have to pay out royalties for technologies like SOAP because HTTP had patent encumberences that were only ignorable when dealing with the web?
The Internet is not the Interweb, and though the W3C is a "web" pseudo-standards body, they need to realize that their recommendations tend to extend well beyond the web and need to plan accordingly. A standard that's deliberately crippled so as not to be extensible is generally a bad standard.
Slashdot Mirror
No offense to you personally, but I'm seeing a lot of the same comments from a lot of different people.
First of all, this is an experiment.
Second of all, they seem to have convinced a lot of people in positions they probably got by knowing what they're doing that this has the potential to save a lot of time and money. Please concede at least the possibility that this might actually happen or at the very least, your uneducated concerns might have already been addressed by the educated.
Stop for a minute and repeat to yourself: I do not run a major ocean port. I do not run a major ocean port.
SVG is not intended to do synchronized multimedia. The G in SVG stands for "Graphics". If you want to build an all-out presentation with animation and audio, use SMIL in conjunction with SVG (or whatever you want for the graphics/animation side).
Sadly, yes. We do not use SMS or any similar text messaging service for reliable messaging as a result. E-mail to a pager gateway is far more reliable (99.99% or better, in my experience), and if you have a method for delivering directly to the paging provider, that's even better still.
Keep in mind through all of this that it is not illegal for you to download and store music you didn't purchase. So if the RIAA is attacking people that have downloaded MP3's, they are wrong on more than one level. The people that are breaking the law are those that share those MP3's in the first place.
The RFC (actually the HTTP/1.1 specification) discusses "HTTP caching". It's quite explicit. Caching at the user-agent and proxy level are discussed, but not to the exclusion of all other uses.
However, what people are proposing is to set up a mirror.
You're picking nits. An HTTP proxy can take a variety of forms. Here is the definition quoted in the HTTP/1.1 specification (emphasis mine):It does not say how this proxy should be built or implemented, it just describes some device that acts as a server from the user's perspective and a client from the origin server's perspective.
What I'm describing is just another form--albeit an unusual one--of a standard caching HTTP proxy. You're arguing technical definitions here that aren't really relevant.
Have you never visited a page using Google's cache?
It's a grey area of the copyright law -- automatically-generated headers do not necessarily constitute the permission of the content owner, especially since the content owner can't always control the headers generated by his server (i.e. in a shared environment).
Huh? It's absolutely not a gray area. In the case of the Google cache, it might be, because Google is indeed preserving the contents of the pages it spiders well beyond the norm for any HTTP cache.
But in the case of a "content owner" and the cache control functions of HTTP, there is no "gray area" whatsoever:
By default, most HTTP servers only send a Last-Modified header along with the content. If this were the extent of the "HTTP caching universe", it alone would be more than sufficient, since a caching proxy would just have to go back to the server and make a conditional GET request, where the origin server would respond with a "304" if nothing changed. This alone would significantly reduce the amount of load/traffic on a site without the possibility of the proxy delivering stale information to the user. Content owners don't need to know or care about any of this, and they certainly couldn't put up a legal case saying that their web servers were delivering a "304 Not Modified" response and that response facilitated copyright infringement. That is completely absurd.
So right up front, with extreme HTTP basics, we have enough to build our HTTP caching proxy (which appears to the user as a mirror, even though it isn't really one, since we never cache/duplicate content that is dynamic, changing for each request, or where the origin server has specified HTTP headers disallowing caching).
If we wanted to go a step further, this requires additional help from the origin server. In other words, to make proper use of the more advanced HTTP caching techniques discussed in the standard, the origin server has to explicitly be modified to give us additional cache-control headers, or the content needs to provide additional cache-control headers (perhaps in the <meta> tags, or configured through a
So at this point, if a page is delivering an Expires or Cache-Control header that is explicitly offering information that allows us to cache the resulting document for a certain period of time (seconds? hours? weeks?), someone had to make the very conscious and explicit decision to do that, which means any form of caching or proxying that we wish to do on that is fair game.
Keep in mind also that it is highly unusual for sites to have "volatile" content with cache-control information suggesting it can be cached for any extended period. Even having this information cached for just a few minutes, or an hour, would be completely sufficient to mitigate the effects of a Slashdot posting, since it would mean the caching proxy would only have to make a single request once every few minutes, or every hour, for the entire Slashdot community.
The bottom line is that if there is a web site out there that is lying as part of its HTTP implementation, you cannot remotely fault the users, user agents or proxies for acting in good faith on that information. Again, by default, servers do not provide any information on how long a resource may be cached (if at all), though it does allow validation through the use of conditional GETs, which can significantly reduce the volume involved in the responses, even if it won't reduce the number of hits. If a server expresses more advanced cache-control headers, it's doing so as part of an explicit request. If whoever performed that configuration was not authorized to do so, the content authors need to take that up with the owner of the server (much as an author would need to take up distribution issues over a physical book up with their publisher).
Keep in mind that at no time does this "mirror" or caching proxy ever keep a copy of this data that is truly independent from the data on the origin server. It only keeps this data around as long as the origin server said it could (as expressed through the Expires header or Cache-Control parameters). The proxy is still required to validate against the origin server as needed (by default, unless the web server was explicitly configured otherwise, this means it has to validate each and every request using a conditional or complete GET request). If the origin server disappears or removes the content, as soon as their cache-control values expire, the content disappears from the proxy as well. Yes, this appears to the user as a mirror, but functions more like a proxy.
If you have a quota, it's your responsibility not to exceed it -- not Slashdot's or anyone else's.
I completely agree. Nothing I have ever said in this thread has once indicated that Slashdot is in any way obligated to configure a mirroring service. I have repeatedly stated, however, that Slashdot is effectively being one giant asshole towards those smaller sites it does link to without giving them a head's up when it knows the site probably won't handle it. In most parts of the world, it's perfectly legal to be an asshole, and in many places, one's right to be an asshole is even protected. But that doesn't make the person any less of an asshole.
Do you understand that caching websites without the author's permission is illegal?
I apparently know a little more about HTTP than you seem to, my friend. If it were illegal to cache HTTP resources, then most HTTP proxies are illegal as well.
There is no standard HTTP mechanism for caching
Uhh, OK. RFC2616 section 13 seems to disagree with you.
copying the page and giving it off as yours would surely spark many lawsuits.
If a site is expressing a future date in an HTTP "Expires" header, or a max-age Cache-Control header, they're saying something very specific about how that data can be used by browsers and HTTP proxies alike. Read the document above to what it is.
At the very least, this is lazy
What?? Just because I choose to post some data online does not mean that I must automatically spend the money to create an environment and supply a network connection capable of withstanding a post on Slashdot. This reasoning is flawed. Most people with smaller web sites (e.g. academic) do not have the funds to do this. You seem to be under the flawed impression that any server with any form of network connection should be capable, with proper administration, of handling the traffic that a post on Slashdot generates.
This is like saying that people who are victims of distributed denial-of-service attacks get what they deserve for not having a fast enough network connection or a router that can do a better job of filtering packets. This is a totally unreasonable expectation. Sure, they "deserved" network traffic by placing their servers and networks on the Internet, but they're not lazy just because they choose not to spend the money for an enterprise-quality network when it's horribly out of scale for their requirements.
If you don't lock your front door, you shouldn't complain about burglars.
I can't even begin to touch this analogy.
I would be glad for the extra publicity, not bitchy about the traffic.
I'm sure that somewhere, deep down under his annoyance, he is.
Are you going to sit there and honestly say that if a web site you operated were brought to its knees and made totally unavailable due to a post on Slashdot, it would not have irritated you? "Aww shucks, I should have planned ahead better and gone with that Sun E5500 instead of this P133 after all! How stupid of me for not spending a half a million on infrastructure for my personal home page instead of this extra PC." Get real.
I do concede, though (as I have in previous posts), that he should not have been surprised this would have happened one day. And maybe he was aware that it could happen one day, and maybe he even planned ahead in the sense that there might have been some people willing and able to mirror his site's content at his request. If only he had some advance notice.
If, on the other hand, Slashdot mirrored my site without asking permission, I would be somewhat pissed.
If you are expressing the cacheability of resources on your web site incorrectly, then you are to blame here. Set up your cache control headers in your web server to more accurately describe how each resource could be cached. If you seem to think that every request should go back to the server and get re-retrieved, and that HTTP 304 responses are the devil, then by all means, just configure your web server so that it won't allow it. The point is, the site owner can make this decision (and should already be making it).
Please don't assume that everything you read on Slashdot is factual. Concede the possibility that the stuff in the FAQ is written by human beings who are fallible.
Your point of view here is totally absurd (which I guess is why you're posting as an AC).
I completely agree that people posting information to the web should not be surprised if that generates more activity than they would have wanted. In that respect, yes, it is "their own fault" and they "deserve" what they get.
But your comment suggesting that every web server and network be configured to survive a Slashdotting is idiotic. A "properly configured 333Mhz crap machine" most certainly will not survive any but the most mild Slashdotting, even assuming the network does. The fact that you make this statement shows me that you have no idea what you are talking about. Please post some numbers.
Your lack of sympathy for those people just trying to get something interesting/useful posted to the web astounds me. Someone that can afford to put information online for the benefit of all but cannot afford to do so using high-end hardware and high-capacity network links should not be punished for doing so. Not everyone is a professional web provider. Not everyone needs to be one. For most sites, with most content, Slashdot-levels of traffic will never happen. Why spend money building an environment that will handle it? In addition, some environments can handle it, so long as they have sufficient notice. What's wrong with a policy of giving people a few days notice before posting their link on Slashdot when it's clear their site probably won't survive it? Maybe the site owners can take some steps to ensure their site would stay up, or maybe temporarily mirror the content in question somewhere else? There's a lot that can be done here to prepare for a Slashdotting, but nobody has the decency to allow that to happen.
I agree that 'michael' can't be directly blamed for this, but Slashdot's policies on the matter most certainly can. It's just a matter of common sense and not being an ass. You're right: there's nothing requiring Slashdot to do this, and anything with a URL is fair game to be linked (with the traffic that that causes), but come on, there is a human factor here, and Slashdot could be a bit more courteous here.
I agree with the fact that Slashdot shouldn't have to mirror sites. I think most of their excuses as to why they don't are fairly absurd, though. This problem can be solved in a site-friendly, banner-ad-friendly and legal-friendly way through the use of run-of-the-mill HTTP proxies.
But however that goes, Slashdot really does need to be a little friendlier towards site operators when it's fairly clear up front that their site probably won't handle the traffic.
For the record, I've had news sites (e.g. MSNBC) do a story that involved some piece of content on my site, and generally, they ask my permission first, checking that I'm OK with it and that my servers can handle it. If they can take a few moments to do this, surely Slashdot can as well.
What if they have banners they rely on for $$$? What if their site is based on php and some of the important information is pulled from a database?
Standard HTTP headers reflect the "cachability" of every HTTP resource available on the web. Static pages that never change and don't carry personalized information do not have to be served up by the same server for every request. An HTTP proxy detects this based on HTTP headers that come with the page and will cache these pages for the benefit of those downstream.
Further, 'iframe's or dynamic content should be expressing appropriate cache control headers to prevent only those resources from being cached, or for those pieces of dynamic content that may only change every few minutes, that those resources be cached until the next update is scheduled.
A mirror still isn't out of the question here, despite the excuses in the FAQ. Take an HTTP caching proxy, put a "mirrors.slashdot.org" face on it, and this problem is solved.
Setting a password, or installing mod_throttle and setting it up right would be a start.
Most sites are small. By small I mean someone has decided they want to set up a quick-and-easy web site, throws it up on some personal web server software, and lets people at it.
Do they "deserve" the flood of traffic Slashdot might generate to it? Perhaps. Is it "their own fault" that their network connection and/or server is brought to its knees by the visits generated by Slashdot? Perhaps.
That doesn't mean they can't be annoyed, frustrated and a little bitter at Slashdot. Wouldn't you be?
For your challenge that someone come up with a "legally sound" solution to the problem, keep in mind the responses in the FAQ are an utter joke. Slashdot programmers are lazy.
All someone needs to do is set up a mirroring front-end that just hooks into an HTTP caching back-end. An image is a static resource. Most web servers will specify a 'max-age' for that resource, or at the very least they express a Last-Modified header that a proxy can use to compute an acceptable expiration date before trying to revalidate it. This simple HTTP caching behavior could very simply drive a mirroring site.
Sites that have certain areas or iframes or images or whatever that they want to be requested for every visit or every request can express (and should already be expressing) these requirements through proper use of Expires or Cache-Control headers.
Caching HTTP proxies have been around for years. All they'd need to do is put a different face on one and this problem is solved.
he seems to have forgotten that one of the original ideas of the WWW was to have people link back and forth to each other
I think you're reading too much into things.
He's annoyed and frustrated that his server was brought down due to the traffic created by this article. Wouldn't you be?
Most servers cannot handle the traffic Slashdot generates. This is an unfortunate fact, but it needs to be a fact that Slashdot admits to and tries to mitigate. They don't. The FAQ gives a few excuses that don't hold any water and that's the end of the discussion as far as they're concerned.
I think you're looking at it from the wrong angle. A guy puts up some information on a site using meager resources. He hopes that information will be useful and interesting to those that happen upon it. The hardware turns out to be perfectly adequate for his needs. Then someone posts a link on a popular site and the traffic increases by a factor of 10,000. The site goes down.
Frustrated, he pulls the content down in an attempt at restoring at least some semblence of service to the site.
Wouldn't you share his emotions? Sure, he "asked" for it and "deserved" it by posting that data online, but it's still annoying and frustrating that you can't make that information available due to its inflated popularity by being reported on by a site.
Slashdot needs to be a little more cautious with this type of thing. At the very least, use standard HTTP caching mechanisms to set up a form of mirror for those sites that do express a willingness to be cached through HTTP.
I don't buy the FAQ's explanation. I think they're deliberately oversimplifying or just saying "it'll be too complicated and annoying for everyone" because they're lazy.
At a very minimum, use a caching HTTP proxy to feed a "mirrors.slashdot.org" site. Links would be set up under their own, unique path on this site (e.g. mirrors.slashdot.org/some.site/path/document or even mirrors.slashdot.org/50449) and this would funnel into a caching HTTP proxy. So long as the other site set up reasonable cache headers, there is no reason why the sites would object to their pages being cached in this fashion. This is built into HTTP, for fuck's sake. Wherever they have advertising being done, they're probably doing that in an iframe with its own caching policy. HTTP would handle all of this perfectly fine. Set an artificially low max-age value (overriding the site's) if you're really worried about things getting stale, but even this is unnecessary.
This is all fairly trivial to do. Slashdot authors/programmers have just gotten lazy in the last few years. They don't innovate or improve, they just watch over the slashcode "open source" project and occasionally toss out a few minor releases.
From your quote of the FAQ:
I could try asking permission, but do you want to wait 6 hours for a cool breaking story while we wait for permission to link someone?
Why don't you use some fucking common sense, ask yourself, "Do I think this site will survive linking?" And if the answer is "probably not," then e-mail them or call them, give them a head's up, and only if you fail to get a response in a reasonable amount of time would I ever think it's OK to link to them anyway.
They do have the information posted online, so any link and any amount of traffic is fair, but at least have the goddamn courtesy to mitigate the amount of damage you're knowingly causing. That's all that's being asked for: courtesy. Slashdot authors are lazy, that's all there is to it.
I find myself routinely investigating problems with applications where I don't have immediate access to the source code, or where it's difficult to replicate the problem and we find that we have to correct it (restart, etc.) without getting an adequate opportunity to investigate.
I would love to be able to grab a snapshot of a process and identify exactly what it was doing. In some respects, this can be satisfied by getting a process to core dump and analyzing the core, but to date this has always been an annoying and time-consuming process, requiring source code to see anything useful.
So you're saying that regardless of the amount of equipment we put into an enclosure, the temperature of the air at the exhaust will be the same temperature as the air at the intake?
You do realize this equipment is turned on, yes? And that we aren't using jet engines for our fans?
90% of my excessive volume and heat generation comes from various rack-mount appliances (like Cisco switches), not pee-cees. It doesn't look like these things are very friendly towards that type of environment.
The basic concept might still be sound, though. Turn your rack into an enclosure, add some intake fans, and vent the entire rack's exhaust somewhere else. (I wonder what the exhaust temperature for an entire rack would reach?)
I agree.. the parody site and press release were a little too convincing. They either needed to go a little further with the site and the release so that it was obvious, or add a disclaimer.
While some (most?) of us could probably tell that it was a parody anyway (or at least be suspicious that it was), we're in the minority here. It needs to be obvious to the layperson.
One of the things that I tend to tell people is that your degree should be a solid foundation for what you want to be doing in 5 or 15 years. Yah, if all someone wants to do is code HTML for the rest of their life, any computer-related degree is probably unnecessary.
But usually when someone says they want to code HTML for the rest of their life, what they really mean is maybe one of:
a) code online user interfaces for the rest of their life. To this person I might suggest a degree in art or psychology;
b) write and format/typeset online content for the rest of their life. To this person I might suggest a degree in english, or some other solid foundation that a journalist might take; or
c) develop online markup languages and data representations for the rest of their life. Here you might really want a good solid computer science degree, with a thorough understanding how how everything works together (since that's what a markup language is, really: glue)
So you're right, not every computer-related job necessarily needs a "computer science" degree. But instead of recommending that they just go out and get a job, and rely on work experience to carry them forward, I would suggest that they at least consider a good, solid foundation in a related field so that when HTML becomes obsolete, they don't go obsolete with it.
This is incorrect. Gravitational and magnetic fields are most certainly limited by the speed of light.
This is how we have things like electro-magnetic waves and gravitational waves. If time (speed) did not factor in to magnetism or gravity, there would be no such thing as a wave based on either of these things.
If a modification like this is proved to be needed, it won't make much more of a difference than relativity did to Newton's equations: for most purposes, what we've been using to date is going to be perfectly adequate. Only at extreme velocities, scales and energy states do we see conditions where the modified equations make a difference.
And I can entirely see the city's point about why reporters going around rummaging through peoples' garbage is a bad idea. Reporters are not answerable to anybody - government is.
While this is a very good point (and I'll elaborate in a second), it's also outside of the scope of the problem.
The issue here is that the courts ruled that nabbing someone's garbage without a warrant was legal because the act of leaving your garbage on the curb means you've given up ownership and surrendered it to the public. They were not saying that the police could take the garbage because they should just be able to, given the nature of their job. The sole justification for allowing them to take it was that the owner surrendered theit trash by leaving it for pick-up.
Based on that, there should be nothing wrong or illegal about any other person coming up and taking that same trash.
Now, if we want to say that the police should be allowed to pick up someone's garbage while still protecting it against any random person, that's an entirely separate (though noble) issue. Personally, though, if we're going to start protecting everyone's trash from public snooping, with the exception of those "lawfully authorized" to snoop, I would prefer to see some sort of check in place to ensure that those "lawful" snoops aren't abusing their powers. How would we do that? With a search warrant.
The police can arrest people
Citizens can arrest people.
beat people, shoot people if neccesary
Citizens can beat or shoot people in self-defense. In what situations can police beat or shoot people where ordinary citizens can't?
Police frequently have little (if any) additional rights or privileges over ordinary citizens.
People frequently leave things on their curb when they want to give them away. I'd say the Taker of the Weed Whacker has a perfectly plausible defense.
The issue is that some "web" technologies (e.g. HTML) can easily find themselves in other areas (e.g. HTML e-mail). With the licensing phrased the way it is now, a "web" standard can be made free and beautiful, get entrenched as a de facto standard, but then everyone wanting to extend that into other related technologies would suddenly have to pay out the nose for patent royalties, which neatly excludes most all free software. This is the situation we are trying to avoid.
Wouldn't it suck to have to pay out royalties for technologies like SOAP because HTTP had patent encumberences that were only ignorable when dealing with the web?
The Internet is not the Interweb, and though the W3C is a "web" pseudo-standards body, they need to realize that their recommendations tend to extend well beyond the web and need to plan accordingly. A standard that's deliberately crippled so as not to be extensible is generally a bad standard.
There are some really freakin' cool rack-mount LCD displays on the market... Very pricey, though.