It's not about making the learning curve steep. It's about getting the fundamentals learned before moving on. If this means a student needs 4 years to learn what others pick up in 2 or 3, then courses need to be designed to take things at that speed.
I personally learned my multiplication tables in elementary school, and I still use them today. Being able to do simple math in your head in a fraction of a second saves a ton of time in the long run. Similarly, understanding (in your head) the fundamentals of a particular concept (math or otherwise) can save you a ton of time that someone else might spend doing trial-and-error approaches trying to figure out how to solve the problem.
Once you get into the real world, even armed with that same calculator, in many cases you won't even remember how to use it unless you understood the concepts in the first place.
I'll have to disagree with you too (to an extent). Without an inherent understanding of core concepts, in any field, you will find that it's difficult to understand related but unfamiliar concepts in the same field.
One of the things I thought was interesting about my introductory computer science courses in college was that they didn't let you use computers initially. You had to understand the concepts, design your approach and then prototype your program within class and without a computer. The instructor would then approve your plan and you would write the program during a lab session.
This approach is fairly analogous to using a calculator in math class. It forces you to learn and understand the basic concepts, and instead of being a VBscript c0d3r that learns through borrowing and trial-and-error, you develop a deep understanding of algorithms. Combine this with engineering courses that teach you details about the inner-workings of a computer, writing an operating system and the like (none of which you'd likely find in a trade school), you are now armed with an assortment of skills and knowledge that will allow you to adapt and learn on the job.
Anyone can learn to program by hacking away on a computer. Those people will (in most cases) never be anything but programmers, though. Take away the computer and force them to understand underlying concepts, though, and they can take that knowledge and apply it to a variety of jobs that don't even have to be programming-related. These people typically are the ones designing the work that the lesser "programmers" then hammer out.
Granted, we're straying away somewhat from the original calculator topic, but I'm trying to draw an analogy. Thorough knowledge of the fundamentals is necessary if you want to be remotely flexible in that field. Learning from the top-down instead of the bottom-up may make you an expert in that specific task, but you will find it difficult to become equally proficient in a related task without understanding how they work.
And going off on an additional tangent, where you say, "colleges don't teach anything you can't learn in the real world," I disagree. One of the biggest things I got out of my engineering courses was abstract problem-solving. I apply many of those rules even today in my job to solve problems when others around me can only scratch their head. It's not because I may understand the system or application better than they do, but I know how to approach the problem and what questions to ask. I do agree that most of the "high-level" stuff I already knew or could have easily learned outside of college, but it was the abstract stuff, the fundamentals that I attribute most of my success outside of college to. The rest of this stuff you're supposed to learn in the real world, and having a complete background in the fundamentals is what allows you to do that effectively.
I think what's happening is the system is trying to get the memory allocated, which may start swapping (maybe causing things to appear to freeze). The kernel eventually sees that there's no more memory so it starts killing off processes, one of which tends to be X. Depending on the system, I wouldn't be surprised if killing off X can cause some unexpected behavior with respects to the display.
I think the perception issue revolving around IIS is that there's a higher barrier to getting Apache installed, configured and running. You typically have to be more skilled to understand how to do that. With IIS, it's like Windows: pointy-clicky. While you and your team can probably move beyond, most people that have adopted Windows/IIS have done so because they don't have the skills to do anything else. This group is dangerous because they also will frequently avoid installing patches.
The whole CodeRed thing speaks volumes about the state of the world with respects to IIS administration. Even today my sites get probed by CodeRed-based viruses.
So basically, if there's an IIS hole, even though you may be smart enough to get your systems secured, it's still going to end up being a very serious problem as a large percentage of IIS servers won't end up getting secured. With Apache (for example), you have to be a more capable administrator in the first place, which means a larger percentage of these will get an update applied.
The whole reason the US Gov't created ICANN was to get domain name administration out of the US and into an international body. They started this with a sort of a trial, and so far, ICANN has failed in that trial. Once the US is satisfied there is an organization out there that can do what it's supposed to effectively and reliably (some might read that as "according to US interests"), the US will (presumably) wash its hands of the mess.
To be honest, I really fail to see how ICANN has these enormous expenses and little actual output. Something needs to be re-done here, in my opinion.
You only have to give the code to the people who are recieveing the software, in this case, the control towers.
Even this may not be necesary. The GPL's definition of distribution could be interpreted in such a way that, since the software is never leaving the FAA, the FAA isn't "distributing" it and would thus not be obligated to release its modifications.
If the FAA decided to sell this or give it away to private entities or foreign governments, it would only then be obligated to release their source code.
This key point seems to be missed pretty frequently by critics of the GPL. If an entity maintains ownership and control of GPL'd software and does not release it, they are not bound to tell anyone about the modifications they've performed. Their code can be just as closed and proprietary as they like.
http://www.ipnsig.org/ has some interesting content if you're curious about how a network might work between "internets" on Mars and Earth. A squid proxy is probably a good solution on the Mars side, but you'll probably have to set up site "subscriptions" to keep the proxy up to date in a push fashion, or be prepared to wait an hour or more to queue a request for a web page "special delivery"-style. Bandwidth is precious!
This project is probably one of the most interesting ones I've ever come across.
One way around this is to supplement the hash with, say, the last 4 digits of the card number. These can be used as a confidential label and could be made available to service reps looking at the account so they can verify with the customer that the card number is the one they're talking about. Otherwise we have to ask them what their card number is and generate a hash for comparison.
I once read an article about how much of this was going to be solved by the use of a real deep-space communications network. The idea was to have them launch some relay satellites at some stable orbital points in the solar system, and instead of having ground stations here dedicated to communicating over these great distances, you'd ideally have a relay near your probe relay its transmissions back to earth. Once you get into deep space, you can start using more efficient optical methods for communicating between relays, and communication from earth basically just relies on your ability to get the message to the nearest relay satellite and let it route your message appropriately.
All of this has the added benefit of allowing all of the various probes and interplanetary craft to be in communication at the same time.
Unfortunately, aside from the original paper I read, I haven't heard of anything more about these ideas. It's possible they've been tabled as too expensive for now..:/
It's a shame because I think this project would be really fascinating and could probably save a ton of money in the long run.
I still have to disagree.. Both of your analogies discuss more sinister things going on, with somebody violating your home. I would have no problem with a neighbor parking his car in my driveway while I was gone, provided there was a 0% risk that if I came home at some strange hour, he wouldn't be there.
If we're going to use analogies, I'd say this is more akin to my set-top box dialing in at night to retrieve a guide update. Yes, it's using my telephone line, but it would not use it if I was on it, and it doesn't dial a toll number. It does not impact me. It does not ask for my permission before it does this, but I don't really care.
But if it's simply a permission issue, keep in mind that you gave your permission when you signed up with service. If you wish to revoke that permission, by all means cancel your service. If there's a specific concern you have, maybe you could try getting Tivo to address that concern.
Because it's zero-impact? If a service like Kazaa downloaded stuff "on the side" and stored it without my permission, that's two observable drains on my resources: the bandwidth needed to make that download and the space that download is using on my hard drive. The bandwidth loss would annoy me because it could slow down other transfers, and the disk space used would annoy me because I can't store as much stuff as I could otherwise.
This issue is totally different -- the "download" is happening when you are not actively using the Tivo: when nothing is set to record and when you're not watching live TV. The space it's storing the recording is reserved for this purpose and is not part of the space you would normally store your own video, so you don't lose anything there either.
This is exactly a ZERO impact issue, unless you wish to activate that selection to view the promo later.
So the Tivo people are lying? Do you have any numbers or figures showing this? I'm sure lots of people would like to expose this easily provable lie if so.
Generally, most UPS's today don't do anything to condition the line. While you have AC power that falls within "normal" ranges, you're literally getting line power just as if you were plugged into the wall. The UPS isn't doing anything to filter noise here. Now, if the voltage were to drop or rise outside of the normal range, the UPS should generally kick in and get you onto battery, but I don't think that would be happening here (you'd notice).
Similarly, power strips generally do nothing to protect you from anything except too much current. Voltage can drop way below or rise way above normal and the power strip would keep supplying this power. If your power strip doubles as a surge suppressor, you might get some protection from voltage spikes in addition to too much current, but don't confuse this with a real line conditioner, which would remove noise from the power as well and guarantee you a clean power source.
Lay off the caffeine, yah?
on
Review: U-571
·
· Score: 2
I did not find this movie DVD-purchase-worthy, but I found it to be DVD-rental-worthy.
Yes, there are a few obvious historical issues as the reviewer points out, and much of it feels recycled somewhat, but a significant portion of the reviewer's comments show that he did not fully understand what was going on through many parts of the movie.
Token black guy? That's how it was back then.
Why did the agent photograph and not steal the Enigma? Because then the Germans would know the Enigma was stolen and react. One could have made this huge logic leap if one paid attention to the dialog.
I also thought that the sinking to 250+ meters made perfect sense. It was all explained pretty clearly in the dialog. I knew what was going on, at least. Maybe you have to have an elementary-school education of submarines to get the terminology.
Gratuitous stereotyping via the electrician? Would you do anything different if you were in his place?
The scene with the crewman in the bilge fixing the air line had nothing to do with the engines. They have to have air to launch anything out of the torpedo tubes, and the line supplying this air was broken. I thought this was sufficiently documented in the dialog as well. How did the reviewer conclude that he was trying to start diesel engines underwater with an air starter?
I would invite those reading this review to do so with a grain of salt. I found the movie was exactly as I was expecting it to be: entertaining. The sound is great, and despite what the reviewer would have you think, many of the "quirks" he sees are actually due to historical accuracy, though other parts suffer in the same area. If you're looking for a deep movie, this isn't it. If you're looking for a piece of historical fiction, this probably isn't it. If you're looking for an entertaining submarine movie, I'd consider it.
And please lay off the coffee before watching and trying to review older movies. Your understanding of the events will suffer and what you write will not earn you any job in journalism. I can't believe this is what Slashdot is publishing nowadays..
The deteriorating state of the middle east and growing tensions elsewhere are precisely why I think we should be looking toward getting some of our species off this rock. Nuclear and biological weapon proliferation is unavoidable, and given the agenda of many nuclear-seeking nations and factions out there, I'd say our species needs to get a foothold on a few other worlds while we still can.
It boils down to what is realistic. Yahoo says they get thousands of search warrants a year. Is it really realistic that every one of those warrants means some law enforcement department somewhere gets to come in, load up a few boxes full of hard drives, and truck it back to his office for a forensic investigation? How many of these warrants do you think Yahoo would survive through?
It's FAR more efficient and less costly for the ISP to look this information up and give it to the requesting office in a nice, easy-to-read format.
I might see your scenario played out where the ISP itself was being investigated, being uncooperative, or where there was a risk that the ISP might destroy or tamper with the data, but these are special cases, not the general case people are really concerned about here.
In order to properly supervise it, the cops are going to need to know what they're supervising. Who's going to pay to train the cops on every proprietary information system that any possible provider of any electronic data will use? If they aren't trained to know what they're looking at, they serve no practical purpose and might as well enjoy the donuts.
You assume that all Internet providers, web hosting providers, web content providers and the like all share a common mechanism for storing data that a court would be interested in gathering. Obviously they don't. The only practical way to collect information like this is to ask the provider to collect it. To require the police to come into a provider's offices, sit down at a terminal, and pull up the information he's looking for isn't very realistic, when that information could be in a million places in any number of proprietary formats.
I agree with all of your points. (I was lumping non-profits into the "business" category for simplicity, sorry for the confusion.) I also now feel that the RFC is sufficiently vague to lend its authority to either approach for handling the Organization header.
I have always agreed that given the choice, I would rather a provider allow the user's Organizational header through. I dislike RR's practice here. I have only just realized that no matter how a provider approaches its handling of this header, the header itself is really meaningless. It can't be relied upon to identify the organization responsible for getting that message sent, since some providers allow the user to put whatever they want into it, and users cannot rely on it to identify the organization the user is speaking on behalf of for the same reason. A better solution is to have a decent signature in a signed message.
For a news provider mandating an Organizational header at the provider-level:
Pros: Clearly identifies the organization responsible for injecting that message into the USENET network. Allows for fast identification of the sending party, and a path (albeit sometimes a crooked one) to contact them for abuse or transmission issues.
Cons: Does not necessarily identify the sender with his or her employer or other organization they choose to be affiliated with.
For a provider honoring client-provided organization headers (which I feel is a better approach):
Pros: Users can affiliate him/herself with whatever organization they need to (employer, club, self)
Cons: No guarantee that the content of this header will be truthful or meaningful. Users can affiliate him/herself with whatever organization they want to. No longer useful for identifying the organization responsible for injecting the message into the USENET network, can never be relied upon for abuse issues.
If a user wishes to express his or her affiliation with an employer or other organization, they should do so in the signature of the message. For the paranoid especially, a signed message with a signature identifying the organization the user represents is the only guarantee of identity.
The trouble is trying to define legally "not realistically" what an ISP provides.
And for that, we have to refer to the RFC. Unfortunately, I'm starting to think that the RFC is sufficiently vague for the purposes of this header that either way (co-opted or ignored) would be in the spirit of the specification. If the spec isn't helpful, you have to go on general consumer expectation. Given that a large number of providers use this header as Road Runner has chosen to use it, I do not believe one can make a case against it as "general consumer expectation" (whatever the legal term is).
So it all comes back to one's response to their provider's business decision. If someone doesn't like it, they should complain or use someone else's news services.
Conceded. The stated intent of the Organization header is to provide a better mechanism for identifying the organization where the message is originating, because "site names" are often too cryptic. I was originally looking at this from the operational end, where "site names" would appear in the headers as the message bounced from news server to news server, but I see that "site names" could potentially mean the e-mail address of the sender himself, which makes the intent vague and ambiguous.
I am of the opinion now that either use (broadly identifying the news service at the provider level or singularly at the user level) is fine.
I am also of the opinion that strictly honoring client headers alone makes the Organization header nearly useless for making it clear what organization is responsible for sending the message. It's simply a vanity tagline at that point which cannot be relied upon in the least, unless you already know the person.
To be honest, I don't think this header really has a significant amount of value at all, no matter which way it's meant to be used. If the providers force their Organizational header on all content they introduce into USENET, it doesn't really reflect the organization of the user himself, and any user trying to track down the sender for abuse purposes would presumably know how to read USENET headers to find the site name itself, which would be authoritative anyway. If you let users put whatever they want in there, it just becomes a vanity header for whatever they want to put. Either way, useless in my book.
But thanks for pointing this out. I see now that I was perhaps reading things too narrowly and trying too hard to figure out the intents of the original authors.
I do not recall using the word "employees" or ever implying that. The RFC seems to use the term "organization" in an "early Internet" sense, back when Internet providers and corporations were the established presences on the 'Net, and these presences included news servers. These news servers would have an Organization header identifying the organization in question for reasons related to the confusing nature of network addresses present elsewhere in the header. It's meant to help people identify the organization responsible for getting that message inserted into the USENET network, not to identify where every joe@hotmail.com is employed.
I also don't appreciate the name-calling. Is that why you are posting as an AC? Because you need the language to help you make your case?
Slashdot Mirror
It's not about making the learning curve steep. It's about getting the fundamentals learned before moving on. If this means a student needs 4 years to learn what others pick up in 2 or 3, then courses need to be designed to take things at that speed.
I personally learned my multiplication tables in elementary school, and I still use them today. Being able to do simple math in your head in a fraction of a second saves a ton of time in the long run. Similarly, understanding (in your head) the fundamentals of a particular concept (math or otherwise) can save you a ton of time that someone else might spend doing trial-and-error approaches trying to figure out how to solve the problem.
Once you get into the real world, even armed with that same calculator, in many cases you won't even remember how to use it unless you understood the concepts in the first place.
I'll have to disagree with you too (to an extent). Without an inherent understanding of core concepts, in any field, you will find that it's difficult to understand related but unfamiliar concepts in the same field.
One of the things I thought was interesting about my introductory computer science courses in college was that they didn't let you use computers initially. You had to understand the concepts, design your approach and then prototype your program within class and without a computer. The instructor would then approve your plan and you would write the program during a lab session.
This approach is fairly analogous to using a calculator in math class. It forces you to learn and understand the basic concepts, and instead of being a VBscript c0d3r that learns through borrowing and trial-and-error, you develop a deep understanding of algorithms. Combine this with engineering courses that teach you details about the inner-workings of a computer, writing an operating system and the like (none of which you'd likely find in a trade school), you are now armed with an assortment of skills and knowledge that will allow you to adapt and learn on the job.
Anyone can learn to program by hacking away on a computer. Those people will (in most cases) never be anything but programmers, though. Take away the computer and force them to understand underlying concepts, though, and they can take that knowledge and apply it to a variety of jobs that don't even have to be programming-related. These people typically are the ones designing the work that the lesser "programmers" then hammer out.
Granted, we're straying away somewhat from the original calculator topic, but I'm trying to draw an analogy. Thorough knowledge of the fundamentals is necessary if you want to be remotely flexible in that field. Learning from the top-down instead of the bottom-up may make you an expert in that specific task, but you will find it difficult to become equally proficient in a related task without understanding how they work.
And going off on an additional tangent, where you say, "colleges don't teach anything you can't learn in the real world," I disagree. One of the biggest things I got out of my engineering courses was abstract problem-solving. I apply many of those rules even today in my job to solve problems when others around me can only scratch their head. It's not because I may understand the system or application better than they do, but I know how to approach the problem and what questions to ask. I do agree that most of the "high-level" stuff I already knew or could have easily learned outside of college, but it was the abstract stuff, the fundamentals that I attribute most of my success outside of college to. The rest of this stuff you're supposed to learn in the real world, and having a complete background in the fundamentals is what allows you to do that effectively.
My US$0.02.
I think what's happening is the system is trying to get the memory allocated, which may start swapping (maybe causing things to appear to freeze). The kernel eventually sees that there's no more memory so it starts killing off processes, one of which tends to be X. Depending on the system, I wouldn't be surprised if killing off X can cause some unexpected behavior with respects to the display.
I think the perception issue revolving around IIS is that there's a higher barrier to getting Apache installed, configured and running. You typically have to be more skilled to understand how to do that. With IIS, it's like Windows: pointy-clicky. While you and your team can probably move beyond, most people that have adopted Windows/IIS have done so because they don't have the skills to do anything else. This group is dangerous because they also will frequently avoid installing patches.
The whole CodeRed thing speaks volumes about the state of the world with respects to IIS administration. Even today my sites get probed by CodeRed-based viruses.
So basically, if there's an IIS hole, even though you may be smart enough to get your systems secured, it's still going to end up being a very serious problem as a large percentage of IIS servers won't end up getting secured. With Apache (for example), you have to be a more capable administrator in the first place, which means a larger percentage of these will get an update applied.
The whole reason the US Gov't created ICANN was to get domain name administration out of the US and into an international body. They started this with a sort of a trial, and so far, ICANN has failed in that trial. Once the US is satisfied there is an organization out there that can do what it's supposed to effectively and reliably (some might read that as "according to US interests"), the US will (presumably) wash its hands of the mess.
To be honest, I really fail to see how ICANN has these enormous expenses and little actual output. Something needs to be re-done here, in my opinion.
You only have to give the code to the people who are recieveing the software, in this case, the control towers.
Even this may not be necesary. The GPL's definition of distribution could be interpreted in such a way that, since the software is never leaving the FAA, the FAA isn't "distributing" it and would thus not be obligated to release its modifications.
If the FAA decided to sell this or give it away to private entities or foreign governments, it would only then be obligated to release their source code.
This key point seems to be missed pretty frequently by critics of the GPL. If an entity maintains ownership and control of GPL'd software and does not release it, they are not bound to tell anyone about the modifications they've performed. Their code can be just as closed and proprietary as they like.
http://www.ipnsig.org/ has some interesting content if you're curious about how a network might work between "internets" on Mars and Earth. A squid proxy is probably a good solution on the Mars side, but you'll probably have to set up site "subscriptions" to keep the proxy up to date in a push fashion, or be prepared to wait an hour or more to queue a request for a web page "special delivery"-style. Bandwidth is precious!
This project is probably one of the most interesting ones I've ever come across.
One way around this is to supplement the hash with, say, the last 4 digits of the card number. These can be used as a confidential label and could be made available to service reps looking at the account so they can verify with the customer that the card number is the one they're talking about. Otherwise we have to ask them what their card number is and generate a hash for comparison.
I once read an article about how much of this was going to be solved by the use of a real deep-space communications network. The idea was to have them launch some relay satellites at some stable orbital points in the solar system, and instead of having ground stations here dedicated to communicating over these great distances, you'd ideally have a relay near your probe relay its transmissions back to earth. Once you get into deep space, you can start using more efficient optical methods for communicating between relays, and communication from earth basically just relies on your ability to get the message to the nearest relay satellite and let it route your message appropriately.
:/
All of this has the added benefit of allowing all of the various probes and interplanetary craft to be in communication at the same time.
Unfortunately, aside from the original paper I read, I haven't heard of anything more about these ideas. It's possible they've been tabled as too expensive for now..
It's a shame because I think this project would be really fascinating and could probably save a ton of money in the long run.
I still have to disagree.. Both of your analogies discuss more sinister things going on, with somebody violating your home. I would have no problem with a neighbor parking his car in my driveway while I was gone, provided there was a 0% risk that if I came home at some strange hour, he wouldn't be there.
If we're going to use analogies, I'd say this is more akin to my set-top box dialing in at night to retrieve a guide update. Yes, it's using my telephone line, but it would not use it if I was on it, and it doesn't dial a toll number. It does not impact me. It does not ask for my permission before it does this, but I don't really care.
But if it's simply a permission issue, keep in mind that you gave your permission when you signed up with service. If you wish to revoke that permission, by all means cancel your service. If there's a specific concern you have, maybe you could try getting Tivo to address that concern.
Because it's zero-impact? If a service like Kazaa downloaded stuff "on the side" and stored it without my permission, that's two observable drains on my resources: the bandwidth needed to make that download and the space that download is using on my hard drive. The bandwidth loss would annoy me because it could slow down other transfers, and the disk space used would annoy me because I can't store as much stuff as I could otherwise.
This issue is totally different -- the "download" is happening when you are not actively using the Tivo: when nothing is set to record and when you're not watching live TV. The space it's storing the recording is reserved for this purpose and is not part of the space you would normally store your own video, so you don't lose anything there either.
This is exactly a ZERO impact issue, unless you wish to activate that selection to view the promo later.
So the Tivo people are lying? Do you have any numbers or figures showing this? I'm sure lots of people would like to expose this easily provable lie if so.
Generally, most UPS's today don't do anything to condition the line. While you have AC power that falls within "normal" ranges, you're literally getting line power just as if you were plugged into the wall. The UPS isn't doing anything to filter noise here. Now, if the voltage were to drop or rise outside of the normal range, the UPS should generally kick in and get you onto battery, but I don't think that would be happening here (you'd notice).
Similarly, power strips generally do nothing to protect you from anything except too much current. Voltage can drop way below or rise way above normal and the power strip would keep supplying this power. If your power strip doubles as a surge suppressor, you might get some protection from voltage spikes in addition to too much current, but don't confuse this with a real line conditioner, which would remove noise from the power as well and guarantee you a clean power source.
I did not find this movie DVD-purchase-worthy, but I found it to be DVD-rental-worthy.
Yes, there are a few obvious historical issues as the reviewer points out, and much of it feels recycled somewhat, but a significant portion of the reviewer's comments show that he did not fully understand what was going on through many parts of the movie.
Token black guy? That's how it was back then.
Why did the agent photograph and not steal the Enigma? Because then the Germans would know the Enigma was stolen and react. One could have made this huge logic leap if one paid attention to the dialog.
I also thought that the sinking to 250+ meters made perfect sense. It was all explained pretty clearly in the dialog. I knew what was going on, at least. Maybe you have to have an elementary-school education of submarines to get the terminology.
Gratuitous stereotyping via the electrician? Would you do anything different if you were in his place?
The scene with the crewman in the bilge fixing the air line had nothing to do with the engines. They have to have air to launch anything out of the torpedo tubes, and the line supplying this air was broken. I thought this was sufficiently documented in the dialog as well. How did the reviewer conclude that he was trying to start diesel engines underwater with an air starter?
I would invite those reading this review to do so with a grain of salt. I found the movie was exactly as I was expecting it to be: entertaining. The sound is great, and despite what the reviewer would have you think, many of the "quirks" he sees are actually due to historical accuracy, though other parts suffer in the same area. If you're looking for a deep movie, this isn't it. If you're looking for a piece of historical fiction, this probably isn't it. If you're looking for an entertaining submarine movie, I'd consider it.
And please lay off the coffee before watching and trying to review older movies. Your understanding of the events will suffer and what you write will not earn you any job in journalism. I can't believe this is what Slashdot is publishing nowadays..
The deteriorating state of the middle east and growing tensions elsewhere are precisely why I think we should be looking toward getting some of our species off this rock. Nuclear and biological weapon proliferation is unavoidable, and given the agenda of many nuclear-seeking nations and factions out there, I'd say our species needs to get a foothold on a few other worlds while we still can.
It boils down to what is realistic. Yahoo says they get thousands of search warrants a year. Is it really realistic that every one of those warrants means some law enforcement department somewhere gets to come in, load up a few boxes full of hard drives, and truck it back to his office for a forensic investigation? How many of these warrants do you think Yahoo would survive through?
It's FAR more efficient and less costly for the ISP to look this information up and give it to the requesting office in a nice, easy-to-read format.
I might see your scenario played out where the ISP itself was being investigated, being uncooperative, or where there was a risk that the ISP might destroy or tamper with the data, but these are special cases, not the general case people are really concerned about here.
In order to properly supervise it, the cops are going to need to know what they're supervising. Who's going to pay to train the cops on every proprietary information system that any possible provider of any electronic data will use? If they aren't trained to know what they're looking at, they serve no practical purpose and might as well enjoy the donuts.
You assume that all Internet providers, web hosting providers, web content providers and the like all share a common mechanism for storing data that a court would be interested in gathering. Obviously they don't. The only practical way to collect information like this is to ask the provider to collect it. To require the police to come into a provider's offices, sit down at a terminal, and pull up the information he's looking for isn't very realistic, when that information could be in a million places in any number of proprietary formats.
I agree with all of your points. (I was lumping non-profits into the "business" category for simplicity, sorry for the confusion.) I also now feel that the RFC is sufficiently vague to lend its authority to either approach for handling the Organization header.
I have always agreed that given the choice, I would rather a provider allow the user's Organizational header through. I dislike RR's practice here. I have only just realized that no matter how a provider approaches its handling of this header, the header itself is really meaningless. It can't be relied upon to identify the organization responsible for getting that message sent, since some providers allow the user to put whatever they want into it, and users cannot rely on it to identify the organization the user is speaking on behalf of for the same reason. A better solution is to have a decent signature in a signed message.
For a news provider mandating an Organizational header at the provider-level:
Pros: Clearly identifies the organization responsible for injecting that message into the USENET network. Allows for fast identification of the sending party, and a path (albeit sometimes a crooked one) to contact them for abuse or transmission issues.
Cons: Does not necessarily identify the sender with his or her employer or other organization they choose to be affiliated with.
For a provider honoring client-provided organization headers (which I feel is a better approach):
Pros: Users can affiliate him/herself with whatever organization they need to (employer, club, self)
Cons: No guarantee that the content of this header will be truthful or meaningful. Users can affiliate him/herself with whatever organization they want to. No longer useful for identifying the organization responsible for injecting the message into the USENET network, can never be relied upon for abuse issues.
If a user wishes to express his or her affiliation with an employer or other organization, they should do so in the signature of the message. For the paranoid especially, a signed message with a signature identifying the organization the user represents is the only guarantee of identity.
I'll agree to some of your points. See my other post if you're curious.
The trouble is trying to define legally "not realistically" what an ISP provides.
And for that, we have to refer to the RFC. Unfortunately, I'm starting to think that the RFC is sufficiently vague for the purposes of this header that either way (co-opted or ignored) would be in the spirit of the specification. If the spec isn't helpful, you have to go on general consumer expectation. Given that a large number of providers use this header as Road Runner has chosen to use it, I do not believe one can make a case against it as "general consumer expectation" (whatever the legal term is).
So it all comes back to one's response to their provider's business decision. If someone doesn't like it, they should complain or use someone else's news services.
But Slashdot should not bring it to your attention so that you might know what is going on and complain?
Not under the guise of a violation of my (civil?) rights.
Your other points are addressed in my other post.
Conceded. The stated intent of the Organization header is to provide a better mechanism for identifying the organization where the message is originating, because "site names" are often too cryptic. I was originally looking at this from the operational end, where "site names" would appear in the headers as the message bounced from news server to news server, but I see that "site names" could potentially mean the e-mail address of the sender himself, which makes the intent vague and ambiguous.
I am of the opinion now that either use (broadly identifying the news service at the provider level or singularly at the user level) is fine.
I am also of the opinion that strictly honoring client headers alone makes the Organization header nearly useless for making it clear what organization is responsible for sending the message. It's simply a vanity tagline at that point which cannot be relied upon in the least, unless you already know the person.
To be honest, I don't think this header really has a significant amount of value at all, no matter which way it's meant to be used. If the providers force their Organizational header on all content they introduce into USENET, it doesn't really reflect the organization of the user himself, and any user trying to track down the sender for abuse purposes would presumably know how to read USENET headers to find the site name itself, which would be authoritative anyway. If you let users put whatever they want in there, it just becomes a vanity header for whatever they want to put. Either way, useless in my book.
But thanks for pointing this out. I see now that I was perhaps reading things too narrowly and trying too hard to figure out the intents of the original authors.
I do not recall using the word "employees" or ever implying that. The RFC seems to use the term "organization" in an "early Internet" sense, back when Internet providers and corporations were the established presences on the 'Net, and these presences included news servers. These news servers would have an Organization header identifying the organization in question for reasons related to the confusing nature of network addresses present elsewhere in the header. It's meant to help people identify the organization responsible for getting that message inserted into the USENET network, not to identify where every joe@hotmail.com is employed.
I also don't appreciate the name-calling. Is that why you are posting as an AC? Because you need the language to help you make your case?