1. Fedora is not RHEL, nor is Fedora intended as a stable OS. Yes, some people have success with Fedora, but then some do with Windows. YMMV. If someone is running production, critical services on Fedora, well, have fun with that.
2. Redhat certainly did alienate folks with the Fedora/RHE for money thing. They took an entire segement of their market and said "We don't want you". That segment was the folks who used and recommended Redhat Linux, but were expert enough to not need support. Redhat failed here by not realizing those "penny freeloaders" were in fact driving the adoption of their products left and right.
"If you are lucky then www.slashdot.org is in the name server's RAM cache, and you get a fast response in just a little over 150ms. If not (and for the majority of websites, its not)"
All the more reason to run your own local DNS cache: it will have cached answers YOU are most likely interested in and be a faster link than your ISPs.
An even better reason to run your own cache (not just forwarding to your ISPs nameservers) would be trust. Do you trust your ISPs cache to be secure and free from DNS poison? I sure don't.
The only thing good I can say about the puck was that it taught me how to mouse left handed. Mainly due to the intense pain caused when using my dominant mouse hand.
They dare? They DARE?!? They dare to disparage the Timex Datalink?!?!?
Heathens!
I wore the crap out of my Datalink until it finally died in a pool in Arkansas of H2O exposure. Show me another watch that could sync up phone lists, memos and TIME to a PC and under linux no less (yes sir!). Not too bulky and had all the needed features. I'm talking the blinkly light version here, not the USB.
Consider today's watchscape, the best that's out there are the "atomic" (*cough* radio sync) watches and for the most part none of them work quite as well or have the anywhere near the feature set of the Good Old Ironman Datalink.
The best part was holding your breath long enough for the watch to finish the transfer without crapping out. Good times, good times.
Again, I refuse to allow you to assert that specific services should be paid for by the specific consumer. Hence, your question has no merit and is not worth answering.
You've moved way beyond your initial argument, but I'll give my personal opinion: Taxes. The federal tax system is a huge, stupid, overly complicated mess. Ditch the whole thing and implement flat tax. Ditch breaks for corps.
Overly simple? Probably, but that's the best ONE person can suggest with the current state of the mess.
I refuse to fall in to the trap your question frames.
Fact: Consumers of specific services don't necessarily pay in any form for those specific services. Example: Out of state travelers using state highways. They don't pay for those highways in any form.
I do not support the assumption that services used by telecommuters SHOULD be paid for by those telecommuters.
"I asked how the NYC services consumed by the telecommuter should be paid."
Who said the services should be paid by the consumer specifically? I'd love that to be the case, because then I wouldn't have to pay for all the crap of which I don't take advantage or support all the free loaders.
The real state of affairs does not equate all whom consume pay for the services consumed, not by a long shot. So why pick on telecommuters?
Speaking as someone who us a simple end user of java software, I don't give a crap about JVMs. What I care about is does the app work? And so far, the typical answer for anything beyond simple toys is "No".
Note, I'm not a Java developer. I just want the apps to work in an efficient manner. Open Source would be nice, but works like it is supposed to would be good enough.
To say that Java at this moment is an example of good, community developed software is just wrong. Sure, it might be better than a traditionally developed piece, but the picture of software goodnes it ain't.
Notice that, as I mentioned in the DNS story, causing such collateral damage serves to bring much unwanted attention to the attacker. Would we be discussing this if only Blue Security had been affected?
"If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
Ah, not necessarily. Especially in the IMAP world, see IMAP over SSL.
[insert story about linux box and IMAP/SSL/MUTT]
Here's the real problem: You tried to scare your audience with concepts that your target audience doesn't understand. You can't scare ignorant people, see low limit Texas Hold'em.
You disregard that as the number of servers increases, the exploit value of each server is less. Meaning, with more servers it is more work to get the same exploit value.
While more servers may increase the number of exploits (I question this), that does not mean suddenly the attacker can get more overall exploit value out of those servers.
I suppose you would argue all the DNS eggs should be in one basket?
So the point would be to eliminate cuts, yes? I'm assuming the definition of "cut" is a single point of failure in the DNS dependency tree. To eliminate cuts, introduce more nameserver paths. But wait, that means a larger TCB!
From the talk: "It is a well-accepted axiom of computer security that a small trusted computing base is highly desirable: it is easier to secure, audit and manage."
The followup would be that a small TCB is also at more risk for failure.
I disagree that a larger trust pool is always a bad thing. While the attack exposure is larger, true, there is also more work for an attacker to do for the same payoff.
Meaning, if I as an attacker need to choose between two domains to attack, I would prefer the one that would give the biggest payoff for the least work. More namerservers means the attacker has to do more work for the same number of victims (redirected queries).
Reflecting, I also question that having more nameservers is bad.
Having more nameservers in the DNS chain means more of those servers need to be compromised to redirect the same number of requesters. Even better if those nameservers are diverse, so that one exploit wouldn't work on all of them.
There are a number of assumptions in the paper that are questionable:
1. Nameservers give correct version information. This is not correct, some intentionally mislead. 2. Nameservers of a certain version string all have certain vulnerabilities. This is not correct, there are dependencies on platform/OS. Also see 1. 3. DNS Clients are dumb. What I mean here is that no credit is given to the DNS client for discarding incorrect information. Some clients will bypass certain cache poisoning.
I appreciate what the paper is trying to say. Security vs usability is always a direct tradeoff. In the case of DNS, its biggest strength (massively distributed) is also its biggest security weakness.
Slashdot Mirror
1. Fedora is not RHEL, nor is Fedora intended as a stable OS. Yes, some people have success with Fedora, but then some do with Windows. YMMV. If someone is running production, critical services on Fedora, well, have fun with that.
2. Redhat certainly did alienate folks with the Fedora/RHE for money thing. They took an entire segement of their market and said "We don't want you". That segment was the folks who used and recommended Redhat Linux, but were expert enough to not need support. Redhat failed here by not realizing those "penny freeloaders" were in fact driving the adoption of their products left and right.
You actually made the article's point. You don't use Redhat (CentOS != Redhat).
"If you are lucky then www.slashdot.org is in the name server's RAM cache, and you get a fast response in just a little over 150ms. If not (and for the majority of websites, its not)"
All the more reason to run your own local DNS cache: it will have cached answers YOU are most likely interested in and be a faster link than your ISPs.
An even better reason to run your own cache (not just forwarding to your ISPs nameservers) would be trust. Do you trust your ISPs cache to be secure and free from DNS poison? I sure don't.
Shameless plug: http://lifewithdjbdns.org/
Yeah, I'd like to see those guys take their USB key and plug it into an ancient XT.
I did with ye olde parallel ZIP, worked just fine.
I lost count of how many PCs I upgraded to Win95 with a ZIP drive back in the day.
The ZIP fit a niche, but then the niche went away. Thanks ZIP!
The only thing good I can say about the puck was that it taught me how to mouse left handed. Mainly due to the intense pain caused when using my dominant mouse hand.
Thank you puck mouse!
They dare? They DARE?!? They dare to disparage the Timex Datalink?!?!?
Heathens!
I wore the crap out of my Datalink until it finally died in a pool in Arkansas of H2O exposure. Show me another watch that could sync up phone lists, memos and TIME to a PC and under linux no less (yes sir!). Not too bulky and had all the needed features. I'm talking the blinkly light version here, not the USB.
Consider today's watchscape, the best that's out there are the "atomic" (*cough* radio sync) watches and for the most part none of them work quite as well or have the anywhere near the feature set of the Good Old Ironman Datalink.
The best part was holding your breath long enough for the watch to finish the transfer without crapping out. Good times, good times.
Who said life was fair?
Fact: People free load off others.
Arguing the rightness of that serves no purpose. Talking about changing the state of things, that has purpose.
All done here.
Again, I refuse to allow you to assert that specific services should be paid for by the specific consumer. Hence, your question has no merit and is not worth answering.
Whoops, unreality shields have been engaged.
You've moved way beyond your initial argument, but I'll give my personal opinion:
Taxes. The federal tax system is a huge, stupid, overly complicated mess. Ditch the whole thing and implement flat tax.
Ditch breaks for corps.
Overly simple? Probably, but that's the best ONE person can suggest with the current state of the mess.
I refuse to fall in to the trap your question frames.
Fact: Consumers of specific services don't necessarily pay in any form for those specific services.
Example: Out of state travelers using state highways. They don't pay for those highways in any form.
I do not support the assumption that services used by telecommuters SHOULD be paid for by those telecommuters.
"I asked how the NYC services consumed by the telecommuter should be paid."
Who said the services should be paid by the consumer specifically? I'd love that to be the case, because then I wouldn't have to pay for all the crap of which I don't take advantage or support all the free loaders.
The real state of affairs does not equate all whom consume pay for the services consumed, not by a long shot. So why pick on telecommuters?
Speaking as someone who us a simple end user of java software, I don't give a crap about JVMs. What I care about is does the app work? And so far, the typical answer for anything beyond simple toys is "No".
Note, I'm not a Java developer. I just want the apps to work in an efficient manner. Open Source would be nice, but works like it is supposed to would be good enough.
To say that Java at this moment is an example of good, community developed software is just wrong. Sure, it might be better than a traditionally developed piece, but the picture of software goodnes it ain't.
Dear CongressCritter,
Stop trying to protect my children for me, that's my job.
Please see Constitution of the United States and read for content.
Note: Ignorance is not protection.
Notice that, as I mentioned in the DNS story, causing such collateral damage serves to bring much unwanted attention to the attacker. Would we be discussing this if only Blue Security had been affected?
"If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
Ah, not necessarily. Especially in the IMAP world, see IMAP over SSL.
[insert story about linux box and IMAP/SSL/MUTT]
Here's the real problem: You tried to scare your audience with concepts that your target audience doesn't understand. You can't scare ignorant people, see low limit Texas Hold'em.
*grin*
I consider a DOS'ed DNS server the same as exploited.
Further, DOSing sends up a red flag, the last thing an attacker wants is more attention.
You disregard that as the number of servers increases, the exploit value of each server is less. Meaning, with more servers it is more work to get the same exploit value.
While more servers may increase the number of exploits (I question this), that does not mean suddenly the attacker can get more overall exploit value out of those servers.
I suppose you would argue all the DNS eggs should be in one basket?
So the point would be to eliminate cuts, yes? I'm assuming the definition of "cut" is a single point of failure in the DNS dependency tree. To eliminate cuts, introduce more nameserver paths. But wait, that means a larger TCB!
From the talk: "It is a well-accepted axiom of computer security that a small trusted computing base is highly desirable: it is easier to secure, audit and manage."
The followup would be that a small TCB is also at more risk for failure.
Security, resilience or usability, pick two.
I disagree that a larger trust pool is always a bad thing. While the attack exposure is larger, true, there is also more work for an attacker to do for the same payoff.
Meaning, if I as an attacker need to choose between two domains to attack, I would prefer the one that would give the biggest payoff for the least work. More namerservers means the attacker has to do more work for the same number of victims (redirected queries).
Reflecting, I also question that having more nameservers is bad.
Having more nameservers in the DNS chain means more of those servers need to be compromised to redirect the same number of requesters. Even better if those nameservers are diverse, so that one exploit wouldn't work on all of them.
Oh, that was a joke?
Well, we can't ALL be funny, can we?
There are a number of assumptions in the paper that are questionable:
1. Nameservers give correct version information. This is not correct, some intentionally mislead.
2. Nameservers of a certain version string all have certain vulnerabilities. This is not correct, there are dependencies on platform/OS. Also see 1.
3. DNS Clients are dumb. What I mean here is that no credit is given to the DNS client for discarding incorrect information. Some clients will bypass certain cache poisoning.
I appreciate what the paper is trying to say. Security vs usability is always a direct tradeoff. In the case of DNS, its biggest strength (massively distributed) is also its biggest security weakness.
No, what the parent meant was configuring the nameserver to lie about its version.
1. I would expect the FBI to have a completely seperate infrastructure for their computing needs that have nothing to do with fbi.gov.
2. You really think the FBI is going to depend on Sprint for anything?
No, the real reason is that eventually someone will figure out a way to run Linux anyway, so they might as well get marketing value out front.
See Xbox.
"The only person's "privacy" that is being invaded is the guy who broke the law in this case."
WRONG. The person who's SUSPECTED of breaking the law has been invaded. I guess you prefer Guilty Until Proven Innocent, eh?