Er, my Linksys router DISABLES the web interface from "outside" the local network, by default.
Also, it can spoof any MAC address I chose on it's WAN port. (Yes, the MAC address can get sent over the DSL Modem, if it does ethernet encapsulation over ATM, and the ISP might care what it is).
FWIW, my ISP doesn't have this kind of "no NAT, no servers, no pinging" bullshit in their AUP -- they just don't want me to generate a disproportionate amount of outbound traffic.
That's a problem... sometimes you want to call for help, but the situation is not quite urgent. Of course, most police departments have non-emergency numbers for situations like this, but they differ from city to city (because they are ordinary local numbers).
Naturally, a local number is useless, unless you are willing to have your computer try to make a long distance call to your local PD.
It would be nice if there were a common set of geographically-independent numbers that mapped to common services (fire, police, general emergency, medical, etc.)
lost me karma, too, being modded off-topic, even though my top-level response was topic, and I self-modded down to 1 -- I wish I could sometimes self-mod down to 0 and not post anon.
That is, try to model the interfaces to the implementations that you don't yet have a handle on.
This won't be perfect, but it should fit within the amount of churn that youyr development model already accomodates.
Re:How many of these new domains?
on
VeriSign Buys .tv
·
· Score: 4, Interesting
I couldn't believe people would buy that line of crap.
"There's a sucker born every minute" -- P. T. Barnum, I believe.
Sometimes I think the reason most smart people don't get rich selling, as you say, crap, to the dummies, is that most smart people can't imagine anyone that stupid. Sadly, such people exist. Frighteningly, they vote.
Latency is generally overwhelmingly caused by buffering of bits and far less by medium propagation delay. Of course, wire-speed latency matters in the design of CSMA/CD networks with regard to their maximum radius. However, as data rates go up, capacitive effects on NeXT and FeXT (near and far end cross-talk, basically not hearing the weak attentuated signal because your local transmission is so much STRONGER) appear to be the primary distance limiter.
.tv became a "hot" TLD because of the television tie-in, hence the desire to have a.tv domain. This just means that Verisign paid for the right to handle DNS for the domain so they can charge to register.tv subdomains, so do the math.
Re:How many of these new domains?
on
VeriSign Buys .tv
·
· Score: 3, Interesting
Each country has it's own top-level two character domain name. Then there are the historical non-national (but generally US-centric).com,.org,.gov,.mil,.arpa,.int.
.int is interesting, as it is designed for multi- and inter-national organizations. The best known.int subdomain is tpc.int. which is used to map domain names to phones (typically, with fax machines).
The painful reassembly part is generally a higher-level protocol function, done by IP, as in "fragment reassembly". Of course, even these reassembled packets may need further aggregation as part of a stream of data... enter TCP (which provides retransmission for lost packets as well).
It's built into ethernet as in 10BaseT and 100BaseT, but not GigE (1000baseT).
As for "killing performance", random transmissions with a truncated exponential random backoff time (collsision? wait a random time within an interval, try again... collision? wait a random time within double the interval, try again...) approaches 67% line utilization as the number of transmitters grows to infinity. Without collision detection, you get half that.
So, yeah, it kills performance, but only in the sense that you're trying to saturate the pipe anyway.
All this is really moot today, because so much ethernet, even 100BaseT, is switched and not just
"hubbed".
While the prospect of a single universal physical network layer is appealing, here are some realities that interfere with this.
1) Applications. Ethernet was designed as a shared medium to support arbitrary contentious traffic framed in a simple data link layer, sent between relatively distinct systems. It is intentionally a small, simple spec. Firewire was designed to provide connectivity to high-bandwidth, real-time traffic in a local environmment. Firewire therefore supports notions of bandwidth reservation, and was initially geared to short-haul distances (i.e. on the desktop, or in a small equipment rack). It is a more detailed and involved spec because of an intended techno-ignorant consumer audience -- plug things in and they work.
2) Power. While PoE (Power over Ethernet) is gaining steam, driven mostly by the notions of IP telephones and other networked devices without local power, ethernet generally does not carry power. Firewire can, to simplify cabling.
3) Bleedingedgeedness. Firewire was bleeding edge. In order to be cost-effective at some level, compromises were made. Initial distance limitations (on copper) were severe. It was bandwidth at all costs. Even today, firewire does not strike me as effective for long distances (need for fibre vs. copper). GigE took longer to develop because of the need to work at extended distances (100m being the traditional ethernet radius), with a copper physical plant, and the lack of comsumer device pull. It also had legacy inertia to deal with.
In my mind, the biggest difference, though, is the nature of the intended traffic: Firewire addresses bandwidth reservation, and ethernet doesn't. To be sure, one can layer the necessary protocols over ethernet to do this, but then ALL the traffic has to be managed outside the ethernet spec. to honour those protocols. Firewire has the promise to be a micro-local, cheap, real-time networking solution. Ethernet addresses longer distance needs with a diversity of traffic types.
That is good news, though I'd think that the obvious way to try to shut down traffic to a public service would be to attack it through it's open ports.
For an H1-B, the employer must simply attest that they could not find an American for the job, the job must be in a prescribed catagory, and a minimum wage must be paid. There are other requirements such as no on-going labour disputes, lockouts, etc.
A green card (lawful permanent resident) is an entirely different thing, and generally requires employers to hire the least qualified American, over any foriegner, regardless of qualifications. The first step is obtaining a Labor Certification, LC (not to be confused with the similar sounding Labor Certification Attestation, LCA, required for an H1-B visa).
The LC is where the local state department of labour determines whether any Americans are available for the job. Generally, you have to post the job nationwide, in recognized trade mags, interview all applicants, and demonstrate how all Americans fail to meet the minimum job requirements. This can take YEARS.
There is a short circuit provision, of course: "reduction in recruitment", or RIR, and any immigration lawyer worth their salt will petition for this on the LC application. Basically, if an employer has been trying, on an ongoing basis, to fill a position, without success, and can demonstrate this, the dept. of labor will usually accept this as evidence of no Americans being available to fill the position. Of course, the employer must be in good standing with the INS and not recently (within the past 6 months) not layed off any Americans doing related work.
Certainly there are those employers that break the law, but, as an H1-B holder awaiting a green card, I wish the INS would have the resources to crack down on those that break immigration laws, and reduce the time it takes me to jump through the necessary hoops.
As for taking money out of the economy, I think you'll find that far more gets spent locally than leaves the country. In my case, if I sent money to Canada, I'd likely be taxed in Canada as a resident, and could not afford to live in the U.S.A. paying Canadian income tax rates.
Since you did some math on this, I am compelled to respond.
Lesse: I can't post at 0 and have this be a problem, because I wouldn't be close to the cap if I'm posting at 0 (and I can't post at 0 and not be anon).
I can post at +1 (because I select "No Score +1 Bonus"), get 4 positive mods to +5, and 6 overrated mods to -1 (say, can a post at 0 be overrated?). That results in a drop in karma to 44.
I can post at +2, get three positive mods to +5, and 6 overrated mods to -1. That again results in a drop in karma to 44.
Clearly, it doen't matter what I post at: I can lose as much karma as the max score minus the min score (from overrateds).
It isn't a big deal, of course, but I still think the principle is flawed: losing karma because some people think the opinions of other people are overrated?
"...as far as I can tell there is no legitimate use for a tool designed specifically for DoS attack.
Of course there is: to test the robustness of a piece of equipment against such attacks.
There are ways to deal with DDOS attacks, but, unfortunately, they require the cooperation of most parties involved in the aggregation of "hostile" traffic toward a given target. It does no good for the target to simply drop "hostile" packets, because upstream "friendly" traffic might still get congested. The upstream routers need to be told to stop forwarding the "hostile" traffic.
And this raises two problems: 1) How do you deploy the software to an existing router infrastructure to allow this back-propagation of "stop forwarding hostile traffic to me" messages. 2) How do you identify traffic as "hostile"?
There are techniques for guessing what traffic is actually hostile, based on packet signatures (often the source address is spoofed, the attack is distributed, or otherwise useless), without dropping too much friendly traffic. It is better, though, to lose some friendly traffic, rather than all of it -- failing gracefully, as it were.
But retrofitting a standard DDOS defense will prove to be difficult, given the diversity of players involved (and this is one area where IP carrier consolidation would be a good rather than a bad thing) -- just look at the difficulty in bootstrapping IPv6 in the network.
I suppose that this is not necessarily unreasonable, but I wonder if it is a bug or a feature?
I take that back... it is definitely a bug, at least in the overrated case. Here's why:
A post can be overrated for one of two reasons: "shouting" by someone with a +2 default score, being moded down, or excessive upward moderation by others. I don't think that the poster should be penalized karma because of positive opinions that others have.
Thus, overrated mods should only lower karma when the score is at or below the original posting score.
The other case, that is losing karma on an otherwise upward modded comment, is not as clear. It stands to reason that the greater one's karma the more vulnerable it is due to what one says -- this keeps karma in check, even with a cap. But one's karma should never be affected downward because of positive upward modding by others.
Sounds expensive in terms of disk I/O (reading all those directories). I suppose you could do a similar thing with symlinks (find all links that point to the same cannonical file, assuming a single level link to keep it simple), thus removing the single-partition limit, and cache the results for rapid access. A cron job could do this.
I've been thinking of something similar for my music collection. Artist/Album/Track seems like a reasonable cannonical starting point, though I have resorted to -Various/Album/Artist-Track for some compilation albums.
I've found that the cannonical starting point usually reflects existing mechanical hierarchies -- in my case, how I've organized my CDs.
Besides, what you're really doing in that scenario is hand-creating a relational database.
Yes, a poor-man's solution: quick and dirty.
Why on earth would you want to go through that mess when there are industrial strength database packages out there that do it all for you?
Hmm, "industrial strenght" strikes me as expensive, in this context (someone wanting to manage their personal digital photos).
I'd probably start with a symlink method, and if the catagorization really started to get out of hand, consider automated tools to generate the links based on a KWIK indexing technique, or move to a proper meta-data database.
But, the symlink technique does not preclude eventual migration to a more powerful beast, like a bona-fide database. In fact, it should be a simple matter to populate the latter with the metadata represented by the former. Thus, it seams like a decent intermediate step before going all out.
Frankly, I just can't imagine the number of keys per item being all that large. It strikes me that you're arguing for a "mod-foo" solution when I'm suggesting trying "foo cgi-bin" first. They both have their place.
Perhaps creative use of symlinks wasn't considered? That would relieve the limitation of a single hierarchical key for a given image. Careful renaming and relinking when off-line migration takes place would take care of on-line vs. off-line issues. However, there are still some problems with this:
While it leverages filesystem tools, it isn't user friendly: one still needs some kind of app to tie it all together (and answer questions like, "Under what other keys is this image also indexed?"). I call this the "reverse-symlink" problem: what are the symlinks to a given cannonical file name?
Also, symlinks to symlinks (keys to on-line version to possibly off-line nfs-mountable media) tend to add inefficiency, although I don't reall see two levels as all that problematic.
Still, it does look like a quick and dirty poor-man's hack. Don't give up on the simple and obvious just yet.
Slashdot Mirror
Also, it can spoof any MAC address I chose on it's WAN port. (Yes, the MAC address can get sent over the DSL Modem, if it does ethernet encapsulation over ATM, and the ISP might care what it is).
FWIW, my ISP doesn't have this kind of "no NAT, no servers, no pinging" bullshit in their AUP -- they just don't want me to generate a disproportionate amount of outbound traffic.
Naturally, a local number is useless, unless you are willing to have your computer try to make a long distance call to your local PD.
It would be nice if there were a common set of geographically-independent numbers that mapped to common services (fire, police, general emergency, medical, etc.)
lost me karma, too, being modded off-topic, even though my top-level response was topic, and I self-modded down to 1 -- I wish I could sometimes self-mod down to 0 and not post anon.
The ironic thing is that I am not Jewish.
This won't be perfect, but it should fit within the amount of churn that youyr development model already accomodates.
"There's a sucker born every minute" -- P. T. Barnum, I believe.
Sometimes I think the reason most smart people don't get rich selling, as you say, crap, to the dummies, is that most smart people can't imagine anyone that stupid. Sadly, such people exist. Frighteningly, they vote.
Mine involved encoding it in white space between words and having the words describe the encoding.
Oh! No! Gotta ban spaces now!!
Latency is generally overwhelmingly caused by buffering of bits and far less by medium propagation delay. Of course, wire-speed latency matters in the design of CSMA/CD networks with regard to their maximum radius. However, as data rates go up, capacitive effects on NeXT and FeXT (near and far end cross-talk, basically not hearing the weak attentuated signal because your local transmission is so much STRONGER) appear to be the primary distance limiter.
.tv became a "hot" TLD because of the television tie-in, hence the desire to have a .tv domain. This just means that Verisign paid for the right to handle DNS for the domain so they can charge to register .tv subdomains, so do the math.
The painful reassembly part is generally a higher-level protocol function, done by IP, as in "fragment reassembly". Of course, even these reassembled packets may need further aggregation as part of a stream of data... enter TCP (which provides retransmission for lost packets as well).
As for "killing performance", random transmissions with a truncated exponential random backoff time (collsision? wait a random time within an interval, try again... collision? wait a random time within double the interval, try again...) approaches 67% line utilization as the number of transmitters grows to infinity. Without collision detection, you get half that.
So, yeah, it kills performance, but only in the sense that you're trying to saturate the pipe anyway.
All this is really moot today, because so much ethernet, even 100BaseT, is switched and not just "hubbed".
1) Applications. Ethernet was designed as a shared medium to support arbitrary contentious traffic framed in a simple data link layer, sent between relatively distinct systems. It is intentionally a small, simple spec. Firewire was designed to provide connectivity to high-bandwidth, real-time traffic in a local environmment. Firewire therefore supports notions of bandwidth reservation, and was initially geared to short-haul distances (i.e. on the desktop, or in a small equipment rack). It is a more detailed and involved spec because of an intended techno-ignorant consumer audience -- plug things in and they work.
2) Power. While PoE (Power over Ethernet) is gaining steam, driven mostly by the notions of IP telephones and other networked devices without local power, ethernet generally does not carry power. Firewire can, to simplify cabling.
3) Bleedingedgeedness. Firewire was bleeding edge. In order to be cost-effective at some level, compromises were made. Initial distance limitations (on copper) were severe. It was bandwidth at all costs. Even today, firewire does not strike me as effective for long distances (need for fibre vs. copper). GigE took longer to develop because of the need to work at extended distances (100m being the traditional ethernet radius), with a copper physical plant, and the lack of comsumer device pull. It also had legacy inertia to deal with.
In my mind, the biggest difference, though, is the nature of the intended traffic: Firewire addresses bandwidth reservation, and ethernet doesn't. To be sure, one can layer the necessary protocols over ethernet to do this, but then ALL the traffic has to be managed outside the ethernet spec. to honour those protocols. Firewire has the promise to be a micro-local, cheap, real-time networking solution. Ethernet addresses longer distance needs with a diversity of traffic types.
Obviously, such a scheme requires some form of authentication, yes.
That is good news, though I'd think that the obvious way to try to shut down traffic to a public service would be to attack it through it's open ports.
Item 6 is actually hard to do, whether manually, or automatically, given a DDoS and spoofed source addresses.
For an H1-B, the employer must simply attest that they could not find an American for the job, the job must be in a prescribed catagory, and a minimum wage must be paid. There are other requirements such as no on-going labour disputes, lockouts, etc.
A green card (lawful permanent resident) is an entirely different thing, and generally requires employers to hire the least qualified American, over any foriegner, regardless of qualifications. The first step is obtaining a Labor Certification, LC (not to be confused with the similar sounding Labor Certification Attestation, LCA, required for an H1-B visa).
The LC is where the local state department of labour determines whether any Americans are available for the job. Generally, you have to post the job nationwide, in recognized trade mags, interview all applicants, and demonstrate how all Americans fail to meet the minimum job requirements. This can take YEARS.
There is a short circuit provision, of course: "reduction in recruitment", or RIR, and any immigration lawyer worth their salt will petition for this on the LC application. Basically, if an employer has been trying, on an ongoing basis, to fill a position, without success, and can demonstrate this, the dept. of labor will usually accept this as evidence of no Americans being available to fill the position. Of course, the employer must be in good standing with the INS and not recently (within the past 6 months) not layed off any Americans doing related work.
Certainly there are those employers that break the law, but, as an H1-B holder awaiting a green card, I wish the INS would have the resources to crack down on those that break immigration laws, and reduce the time it takes me to jump through the necessary hoops.
As for taking money out of the economy, I think you'll find that far more gets spent locally than leaves the country. In my case, if I sent money to Canada, I'd likely be taxed in Canada as a resident, and could not afford to live in the U.S.A. paying Canadian income tax rates.
The idea is to avoid intimidation by the threat of groundless prosecution that would nevertheless be expensive to defend against.
Of course, IANAL.
I can post at +1 (because I select "No Score +1 Bonus"), get 4 positive mods to +5, and 6 overrated mods to -1 (say, can a post at 0 be overrated?). That results in a drop in karma to 44.
I can post at +2, get three positive mods to +5, and 6 overrated mods to -1. That again results in a drop in karma to 44.
Clearly, it doen't matter what I post at: I can lose as much karma as the max score minus the min score (from overrateds).
It isn't a big deal, of course, but I still think the principle is flawed: losing karma because some people think the opinions of other people are overrated?
Of course there is: to test the robustness of a piece of equipment against such attacks.
There are ways to deal with DDOS attacks, but, unfortunately, they require the cooperation of most parties involved in the aggregation of "hostile" traffic toward a given target. It does no good for the target to simply drop "hostile" packets, because upstream "friendly" traffic might still get congested. The upstream routers need to be told to stop forwarding the "hostile" traffic.
And this raises two problems: 1) How do you deploy the software to an existing router infrastructure to allow this back-propagation of "stop forwarding hostile traffic to me" messages. 2) How do you identify traffic as "hostile"?
There are techniques for guessing what traffic is actually hostile, based on packet signatures (often the source address is spoofed, the attack is distributed, or otherwise useless), without dropping too much friendly traffic. It is better, though, to lose some friendly traffic, rather than all of it -- failing gracefully, as it were.
But retrofitting a standard DDOS defense will prove to be difficult, given the diversity of players involved (and this is one area where IP carrier consolidation would be a good rather than a bad thing) -- just look at the difficulty in bootstrapping IPv6 in the network.
I suppose that this is not necessarily unreasonable, but I wonder if it is a bug or a feature?
I take that back... it is definitely a bug, at least in the overrated case. Here's why:
A post can be overrated for one of two reasons: "shouting" by someone with a +2 default score, being moded down, or excessive upward moderation by others. I don't think that the poster should be penalized karma because of positive opinions that others have.
Thus, overrated mods should only lower karma when the score is at or below the original posting score.
The other case, that is losing karma on an otherwise upward modded comment, is not as clear. It stands to reason that the greater one's karma the more vulnerable it is due to what one says -- this keeps karma in check, even with a cap. But one's karma should never be affected downward because of positive upward modding by others.
Sounds expensive in terms of disk I/O (reading all those directories). I suppose you could do a similar thing with symlinks (find all links that point to the same cannonical file, assuming a single level link to keep it simple), thus removing the single-partition limit, and cache the results for rapid access. A cron job could do this.
I've found that the cannonical starting point usually reflects existing mechanical hierarchies -- in my case, how I've organized my CDs.
Yes, a poor-man's solution: quick and dirty.
Why on earth would you want to go through that mess when there are industrial strength database packages out there that do it all for you?
Hmm, "industrial strenght" strikes me as expensive, in this context (someone wanting to manage their personal digital photos).
I'd probably start with a symlink method, and if the catagorization really started to get out of hand, consider automated tools to generate the links based on a KWIK indexing technique, or move to a proper meta-data database.
But, the symlink technique does not preclude eventual migration to a more powerful beast, like a bona-fide database. In fact, it should be a simple matter to populate the latter with the metadata represented by the former. Thus, it seams like a decent intermediate step before going all out.
Frankly, I just can't imagine the number of keys per item being all that large. It strikes me that you're arguing for a "mod-foo" solution when I'm suggesting trying "foo cgi-bin" first. They both have their place.
While it leverages filesystem tools, it isn't user friendly: one still needs some kind of app to tie it all together (and answer questions like, "Under what other keys is this image also indexed?"). I call this the "reverse-symlink" problem: what are the symlinks to a given cannonical file name?
Also, symlinks to symlinks (keys to on-line version to possibly off-line nfs-mountable media) tend to add inefficiency, although I don't reall see two levels as all that problematic.
Still, it does look like a quick and dirty poor-man's hack. Don't give up on the simple and obvious just yet.