Furthermore, FTP allows for features such as resume, etc...
So does HTTP. With the 'Range' header, you can retrieve only a portion of a resource.
I agree that it really depends on the application, but for most practical "view directory, download file" purposes, there's no significant difference.
If you wanted to interact with a directory structure, change ownerships, create directories, remove files, etc., it's generally easier to do this with FTP.
You are of the opinion that the engineers had no hand in the design of the orbiter's heat shield, how the tiles were manufactured or how the tiles were to be used? You are further of the opinion that somehow the engineers and scientists that review the shuttle's missions and its components just blindly "trusted" some non-engineer's assertion that the shuttle ought to have a bunch of non-uniform tiles instead of uniform identical tiles?
And lastly, the guys at NASA that actually do the budgets and look at the costs of every shuttle re-use are somehow comfortable with a decision like this that did NOT come from one of its own engineers?
No offense, but I don't really think you have a very good grasp of how NASA operates. A lot can be said of budget overruns and the cliche of overcharging the government, but in areas where a considerable amount of design and engineering occurs, it's rather silly to think that the contractors actually doing the work have anything to do with design decisions of this type.
Do you really think you're the first person to wonder if there might be some cost and efficiency gains from identical, mass-produced tiles?
Again, please concede the possibility that NASA knows what they're doing here. If you really think you can run things better, by all means send them a resume.
To clarify, the inclination is still a huge obstacle to overcome (and more significant than the altitude). I wasn't meaning to say altitude was more significant. Basically the orbits of the two bodies were totally different and it would have been impractical (impossible) to get them to meet up without planning for that in advance.
I believe NASA indicated a trip to ISS would not have been possible. It's not just the inclination, it's the altitude. Columbia's trip was at a significantly lower altitude than the IIS. The shuttle does not carry enough fuel to change its altitude much.
I recall the article you're referring to. Are you trying to say that moving DNS queries from TLD-level name servers to the root name servers will not impact the root servers because 98% of the queries to the root servers are unnecessary? I'm having trouble following that line of thought.
A TLD that was run incompetently or which had insufficent pipes would not get used.
I thought we were talking about giving TLD's up to anyone and everyone that wanted them. An example was "pepsi". Pepsi does not currently offer hosts under "pepsi.com" to anyone that wants to pay/register one, so they're under no obligation to have a beefy infrastructure in place to accomodate a million hosts under their domain. Absolutely they will run name services for their domain, just like they do today for pepsi.com. The difference is that now they're hanging right off the root zone instead of the com zone.
I think you're making the assumption that TLD's will primarily be used by companies wanting to sell domains ending in that TLD. I submit that if anyone and everyone can register their own TLD, they will do so for personal, vanity purposes. There may be companies out there wanting to sell/give out domains under their TLD, but they will be in the minority for precisely the reason that second-level domains aren't marketable for this purpose today. Why buy a domain under someone else's when you can just get your own at the same level?
Why in the world would I want to register (and maintain name servers for) "david-nesting.com" when I can register (and maintain name servers for) "david-nesting".
DNS is designed to be an extensible and multi-functional lookup service, and was never intended to be limited to a single record type.
This is correct, but I really don't see how you could ever hope to use DNS effectively as a proper name and trademark locator service, which was what I was talking about. Please explain to me how any of the hundred companies with names based on the word "Apple" can make their online presence obvious using DNS. Apple Computer has "apple.com" and nobody else can.
Perhaps I was leaning too heavily on DNS's original function in my last post, but it has very serious, fundamental flaws when you try to apply it to real-world names. The very fact that we even have litigation and arbitration over DNS names tells me that something could be done better. This does not solve that problem.
If you are trying to suggest that it's OK for DNS to be used as a locator service for real-world names and marks, how does allowing any arbitrary TLD help it do that? If anything, it hinders it, since a company's domain could exist under a hundred different TLD's now.
I don't know, maybe this isn't a bad thing after all, but without a good directory stepping up to fill this locator function, this is going to do nothing but reduce the usefulness of an Internet naming system.
Right, but those are not ROOT name servers! Assuming no caching occurs, a lookup for www.example.com goes through three steps:
1. Query root servers for 'com' 2. Query 'com' servers for 'example' 3. Query 'example' servers for 'www'
Since DNS servers cache data, step #1 is almost certainly cached, since a significant amount of queries end in 'com'. Likewise for 'net' and 'org'.
This means the 'bulk' of DNS requests don't hit the root servers, they hit the servers responsible for the TLD in question. And even this is because the DNS namespace for the GTLD's is more or less flat as well (most major entities have dozens of second-level domains in use, instead of just 1, which is all they really need). A good hierarchy (e.g. the old geographically-based.us domain) is very good at distributing traffic only to those servers that need it. A flat namespace prevents that distribution and reduces robustness.
The root servers are designed to be independent from registrar input, etc. They serve up responses for a very fixed and rarely changing set of names and can optimize themselves to that end. The servers handling the top-level domains are a bit beefier and more plentiful.
In a world where anyone and everyone can start allocating their own top-level domain, though, you're effectively folding the traffic from both of today's 'com' and 'net' and 'org' servers into the root servers.
This is a fairly significant thing.
And again, what is the benefit here? "No TLD mess"? Why is there a perceived "TLD mess" to begin with? FIX THE REAL PROBLEM here.
Why would anyone want to register a second-level domain when they can register a top-level one? The only way you're going to keep people out is to charge an exorbitant fee to register there.
And who decides who gets the "apple" TLD? This solution doesn't fix any of the problems that exist with today's DNS infrastructure and serves only to send more traffic to the root servers than before.
The only issue this seems to solve is "what to do about TLD's?" which is an artificial problem to begin with brought about by the general public's stupid need to use DNS as a commercialized locator service.
What "potential" do you feel that DNS isn't reaching? DNS is there to provide alphanumeric labels to Internet hosts, **NOT** to link company names and trade marks to web sites. DNS does what it was originally designed to do very well. It reached its full potential years ago, and is only now starting to suffer because its purpose is being twisted into something it was not designed to do.
Fix the real problem here, don't warp Internet technologies even further than lawyers and marketroids have already warped it.
Re:Now I have to pay attention to TLDS - agggh
on
.NAME at a Crossroads
·
· Score: 2, Insightful
There are two schools of thought here.
The first advocates a "lowest common denominator", where hostnames are explicitly restricted to a subset of the world's scripts. Some will have little or no problems with this (e.g. Americas and most of Europe) while others may have to transliterate significantly.
The second advocates a full internationalization of DNS, allowing hostnames to be represented in any and every script imaginable. Nobody would need to adapt to any lowest common denominator, since they can just use names in their native scripts.
The first approach encourages interoperability at the expense of those furthest away from the standard (e.g. asian scripts). The second approach encourages expanding language barriers into the area of Internet hostnames.
With multiple scripts in DNS hostnames, it's now difficult for me to correspond with an abuse contact at a provider in an asian nation, because I can't type their e-mail address. This is a very bad thing.
I might not have a problem with this approach if the world didn't have this immense reliance on DNS hostnames. If we had another directory sitting atop DNS, mapping real-world names to DNS domains, and a more integrated database of contacts and Internet resources, I shouldn't have to type or cut-and-paste much of anything in the future, and this wouldn't be much of a problem. By the same token, however, users will be abstracted away from DNS hostnames for the large part, reducing this perceived need for hostnames in multiple scripts. We can then go back to technically-oriented reasons for why this is or is not a good approach, and these seem to strongly favor interoperability, which, at the moment, favors a lowest-common-denominator approach.
The DNS software isn't the problem here. What you're recommending is basically a flat DNS namespace, where 90% or more of the present-day DNS traffic is moved directly to the root servers. You're going to need to beef up those root servers several orders of magnitude in order for this scheme to work. This has another order of magnitude impact on the survivability of DNS in the event of network problems. You've just increased your reliance on the root servers significantly, since it's unlikely your local caching DNS server will have names cached for every DNS request you make.
DNS is hierarchial for a reason, and the number of TLD's was small for a reason. The root servers should just need to be probed for a limited set of names, and from that set, it delegates to another set of servers, which delegates to yet another set.
Changing this primarily hierarchial arrangement to a primarily flat one (with some hierarchial vestiges left over, since you'll probably want www.pepsi to work "just in case") would require a fundamental restructuring of DNS and would impact reliability and performance in a very noticable fashion.
A more extensible, future-friendly option might be to put DNS back the way it was 10 years ago and build another distributed database designed to map real-world names to Internet domains.
I should be able to use this database to look up the name "Pepsi" in a business context, and have it return "pepsico.com" or something. A DNS SRV lookup on pepsico.com for the 'http' service might return "www12.web-farm.public-facing.pepsico.com" or some other company-specific hostname representing their web servers (it doesn't have to be a vanity "www.pepsi.com" since users don't need to see this anymore). My browser would then connect and I'd get "Pepsi"'s home page, not the home page of "pepsi.com". We need to start breaking this huge reliance on DNS names as a locator service and put DNS back to work at what it was designed to do: to put an alphanumeric label on Internet hosts.
I've lived in Texas for most of my life with a *listed* number and never received even a tenth of this volume.
But hey, maybe you're just an extraordinarily unlucky individual, or maybe the previous holder of your number signed up to lots of those contests in the mall. Please consider alternative explanations for where this hugely excessive volume of telemarketing calls came from.
My phone was unusable, because they sold my number to telemarketers.
Oh, please. It's not like you get as many calls as you do pieces of e-mail spam. While I hate telemarketing calls as much as the next guy, to call your phone service "unusable" as a result seems pretty silly.
Get your state to pass legislation for a no-call list. They do this in Missouri and I receive no telemarketing calls.
There are many perfectly reasonable reasons why you would want to provide an alternative to the default value for many SMTP headers. It's when you lie and mislead by using values that *other* ISP's use in their own headers that you are said to have "forged" them. Bogus "Received" headers can be considered "forged headers" as well, as they are not added by the MTA per the SMTP specification, they are crafted by hand to make it *look* like they were added by an MTA.
These are forgeries. Providing alternative (but still "correct") values for some SMTP headers are not.
(Technically, instead of mucking with the From header, you might want to consider adding a Reply-To and/or Errors-To header instead.)
...or if you do, write in a clause in your contract requiring that the company be liable for any damages incurred by company factors that influence your personal credit rating. So if you're later given a higher interest rate on a car loan, for example, make the company pay for the difference.
I just said things shrink, not consume fewer pixels. When you increase your display resolution, things appear to your eye to get smaller (and free space, from your eye's perspective, appears to get larger).
What you're basically advocating is changing the "standard icon size" every few years, as display resolutions go up. You also suggest that for print, vector graphics are better. What happens when display resolutions catch up to today's printer resolutions? Will you only advocate a switch to vector graphics when that day arrives? Or by that time will we be using 1024x1024 icons?
The reason you get more room isn't because you've changed resolutions, it's because at higher resolutions, your display elements (GUI, fonts, etc.) shrink in size, thus making room for more stuff.
In a vector world, if you wanted more space on your desktop, you wouldn't change resolutions (ideally, you'd already be at the highest resolution your hardware supported), you would explicitly shrink your display elements (GUI, fonts, etc.) so they consumed less space. (Or get another monitor.)
And who knows, once everything's done with vectors, your GUI might grow and shrink the size of active/active windows ("zoom") to give you all the room you need. MacOS X already does something similar with its task bar.
Most UI elements today make one horrible assumption: that the pixel resolution the user is using allows a 64x64-pixel icon to be viewed comfortably.
We already have displays today where this assumption fails, and where fixed-pixel-size icons are far too small to be usable. In the not-too-distant future, our computer displays won't be measured in pixel dimensions, but by real-world dimensions and a DPI value.
We already have vectored text today, and we need it, especially in the print business. A 12pt font should look exactly the same size on every monitor, regardless of what resolution you're running at. It should just be clearer and sharper at higher resolutions. Graphics should be the same way. Today, they're not. On high-resolution displays, the text may appear about the same size, but now you have all of these graphical elements that are disproportional. SVG fixes that, and icons are a great place to start.
it's that people are allowed to send these messages to anybody they want without any real challenges as to their authenticity.
You go through a lot of work to get your friends "authenticated" in this fashion.
A better solution might be to simply require that every unsolicited e-mail you get be authenticated with a certificate. Set your mail system up to only accept messages to your "real" e-mail address that have either valid PGP or X.509 signatures. Reject everything else with instructions on how to get the tools/certificates to do it.
I do something similar with unique e-mail addresses when signing up on sites. I've also found that it's generally easier to go with username+tag@example.com, where the 'tag' can vary. This is functionally equivalent to username@example.com, but it lets you do some additional filtering without having to set up a new e-mail address. The disadvantage is that there are a lot of sites out there with brain-dead e-mail validation routines that don't permit plus signs.:/
Whatever you do, though, please leave your postmaster@example.com address working and unfiltered. Yes, you will get spam, but if your mail filtering system ends up malfunctioning one day, this address may be the only way someone can let you know.
While it's true that for many people, some of the spam they receive was inadvertantly "opted in", the vast majority is not.
I have a few e-mail addresses that have only shown up on sites like Slashdot, or in a newsgroup. These invariably get the most spam, and most messages contain that "You signed up at one of our partner sites" disclaimer swearing that what I'm reading isn't spam. Whatever. They're hoping that the confusion this causes is sufficient to cast doubt on your complaint, since it's hard to prove that you were or were not "subscribed" by going to some anonymous 3rd party site and providing them with your details.
A lot of these uneducated comments in here are really bugging me. I see a lot of people saying this is a stupid idea, it'll be too expensive, it'll never work, etc. What is with all of the negativity?
First of all, this is an experiment. Experiments never usually make money in the short term.
Secondly, here's a quote from the article (which several posters need to actually read):
If it works, they say the system could save them around 5 million Euro a year in labour costs, and speed ships' average turnaround times by 40 minutes.
Could we please concede the possibility that someone has done a marginal amount of research into this and backed these figures up on some real numbers? Maybe it won't save them that much, or maybe the whole thing will end up costing too much. That's the point of an experiment, after all: to determine if something is going to work.
And for all of the couch port authorities inhabiting Slashdot, please remember that this is probably going to be done with the blessing (and financial support) of a large ocean port. I know that perhaps many of you think you know more about docking ships, managing large ocean-going vessels and the expenses associated with these activities than those in charge of these ports, but please take a deep breath, relax for a minute, and consider the possibility that maybe they're supporting this experiment for a reason, and that reason probably has less to do with a mad scientist trying to dupe someone into buying them a lot of expensive magnets and more to do with a convincing argument that this experiment could save them money in the long run.
Slashdot Mirror
Furthermore, FTP allows for features such as resume, etc...
So does HTTP. With the 'Range' header, you can retrieve only a portion of a resource.
I agree that it really depends on the application, but for most practical "view directory, download file" purposes, there's no significant difference.
If you wanted to interact with a directory structure, change ownerships, create directories, remove files, etc., it's generally easier to do this with FTP.
You are of the opinion that the engineers had no hand in the design of the orbiter's heat shield, how the tiles were manufactured or how the tiles were to be used? You are further of the opinion that somehow the engineers and scientists that review the shuttle's missions and its components just blindly "trusted" some non-engineer's assertion that the shuttle ought to have a bunch of non-uniform tiles instead of uniform identical tiles?
And lastly, the guys at NASA that actually do the budgets and look at the costs of every shuttle re-use are somehow comfortable with a decision like this that did NOT come from one of its own engineers?
No offense, but I don't really think you have a very good grasp of how NASA operates. A lot can be said of budget overruns and the cliche of overcharging the government, but in areas where a considerable amount of design and engineering occurs, it's rather silly to think that the contractors actually doing the work have anything to do with design decisions of this type.
Do you really think you're the first person to wonder if there might be some cost and efficiency gains from identical, mass-produced tiles?
Again, please concede the possibility that NASA knows what they're doing here. If you really think you can run things better, by all means send them a resume.
To clarify, the inclination is still a huge obstacle to overcome (and more significant than the altitude). I wasn't meaning to say altitude was more significant. Basically the orbits of the two bodies were totally different and it would have been impractical (impossible) to get them to meet up without planning for that in advance.
I believe NASA indicated a trip to ISS would not have been possible. It's not just the inclination, it's the altitude. Columbia's trip was at a significantly lower altitude than the IIS. The shuttle does not carry enough fuel to change its altitude much.
Whose bright idea was that?
Please concede the possibility that the people with PhD's and 20 years of experience might actually know what they are doing here.
I recall the article you're referring to. Are you trying to say that moving DNS queries from TLD-level name servers to the root name servers will not impact the root servers because 98% of the queries to the root servers are unnecessary? I'm having trouble following that line of thought.
A TLD that was run incompetently or which had insufficent pipes would not get used.
I thought we were talking about giving TLD's up to anyone and everyone that wanted them. An example was "pepsi". Pepsi does not currently offer hosts under "pepsi.com" to anyone that wants to pay/register one, so they're under no obligation to have a beefy infrastructure in place to accomodate a million hosts under their domain. Absolutely they will run name services for their domain, just like they do today for pepsi.com. The difference is that now they're hanging right off the root zone instead of the com zone.
I think you're making the assumption that TLD's will primarily be used by companies wanting to sell domains ending in that TLD. I submit that if anyone and everyone can register their own TLD, they will do so for personal, vanity purposes. There may be companies out there wanting to sell/give out domains under their TLD, but they will be in the minority for precisely the reason that second-level domains aren't marketable for this purpose today. Why buy a domain under someone else's when you can just get your own at the same level?
Why in the world would I want to register (and maintain name servers for) "david-nesting.com" when I can register (and maintain name servers for) "david-nesting".
DNS is designed to be an extensible and multi-functional lookup service, and was never intended to be limited to a single record type.
This is correct, but I really don't see how you could ever hope to use DNS effectively as a proper name and trademark locator service, which was what I was talking about. Please explain to me how any of the hundred companies with names based on the word "Apple" can make their online presence obvious using DNS. Apple Computer has "apple.com" and nobody else can.
Perhaps I was leaning too heavily on DNS's original function in my last post, but it has very serious, fundamental flaws when you try to apply it to real-world names. The very fact that we even have litigation and arbitration over DNS names tells me that something could be done better. This does not solve that problem.
If you are trying to suggest that it's OK for DNS to be used as a locator service for real-world names and marks, how does allowing any arbitrary TLD help it do that? If anything, it hinders it, since a company's domain could exist under a hundred different TLD's now.
I don't know, maybe this isn't a bad thing after all, but without a good directory stepping up to fill this locator function, this is going to do nothing but reduce the usefulness of an Internet naming system.
Right, but those are not ROOT name servers! Assuming no caching occurs, a lookup for www.example.com goes through three steps:
.us domain) is very good at distributing traffic only to those servers that need it. A flat namespace prevents that distribution and reduces robustness.
1. Query root servers for 'com'
2. Query 'com' servers for 'example'
3. Query 'example' servers for 'www'
Since DNS servers cache data, step #1 is almost certainly cached, since a significant amount of queries end in 'com'. Likewise for 'net' and 'org'.
This means the 'bulk' of DNS requests don't hit the root servers, they hit the servers responsible for the TLD in question. And even this is because the DNS namespace for the GTLD's is more or less flat as well (most major entities have dozens of second-level domains in use, instead of just 1, which is all they really need). A good hierarchy (e.g. the old geographically-based
The root servers are designed to be independent from registrar input, etc. They serve up responses for a very fixed and rarely changing set of names and can optimize themselves to that end. The servers handling the top-level domains are a bit beefier and more plentiful.
In a world where anyone and everyone can start allocating their own top-level domain, though, you're effectively folding the traffic from both of today's 'com' and 'net' and 'org' servers into the root servers.
This is a fairly significant thing.
And again, what is the benefit here? "No TLD mess"? Why is there a perceived "TLD mess" to begin with? FIX THE REAL PROBLEM here.
Why would anyone want to register a second-level domain when they can register a top-level one? The only way you're going to keep people out is to charge an exorbitant fee to register there.
And who decides who gets the "apple" TLD? This solution doesn't fix any of the problems that exist with today's DNS infrastructure and serves only to send more traffic to the root servers than before.
The only issue this seems to solve is "what to do about TLD's?" which is an artificial problem to begin with brought about by the general public's stupid need to use DNS as a commercialized locator service.
What "potential" do you feel that DNS isn't reaching? DNS is there to provide alphanumeric labels to Internet hosts, **NOT** to link company names and trade marks to web sites. DNS does what it was originally designed to do very well. It reached its full potential years ago, and is only now starting to suffer because its purpose is being twisted into something it was not designed to do.
Fix the real problem here, don't warp Internet technologies even further than lawyers and marketroids have already warped it.
There are two schools of thought here.
The first advocates a "lowest common denominator", where hostnames are explicitly restricted to a subset of the world's scripts. Some will have little or no problems with this (e.g. Americas and most of Europe) while others may have to transliterate significantly.
The second advocates a full internationalization of DNS, allowing hostnames to be represented in any and every script imaginable. Nobody would need to adapt to any lowest common denominator, since they can just use names in their native scripts.
The first approach encourages interoperability at the expense of those furthest away from the standard (e.g. asian scripts). The second approach encourages expanding language barriers into the area of Internet hostnames.
With multiple scripts in DNS hostnames, it's now difficult for me to correspond with an abuse contact at a provider in an asian nation, because I can't type their e-mail address. This is a very bad thing.
I might not have a problem with this approach if the world didn't have this immense reliance on DNS hostnames. If we had another directory sitting atop DNS, mapping real-world names to DNS domains, and a more integrated database of contacts and Internet resources, I shouldn't have to type or cut-and-paste much of anything in the future, and this wouldn't be much of a problem. By the same token, however, users will be abstracted away from DNS hostnames for the large part, reducing this perceived need for hostnames in multiple scripts. We can then go back to technically-oriented reasons for why this is or is not a good approach, and these seem to strongly favor interoperability, which, at the moment, favors a lowest-common-denominator approach.
The DNS software isn't the problem here. What you're recommending is basically a flat DNS namespace, where 90% or more of the present-day DNS traffic is moved directly to the root servers. You're going to need to beef up those root servers several orders of magnitude in order for this scheme to work. This has another order of magnitude impact on the survivability of DNS in the event of network problems. You've just increased your reliance on the root servers significantly, since it's unlikely your local caching DNS server will have names cached for every DNS request you make.
DNS is hierarchial for a reason, and the number of TLD's was small for a reason. The root servers should just need to be probed for a limited set of names, and from that set, it delegates to another set of servers, which delegates to yet another set.
Changing this primarily hierarchial arrangement to a primarily flat one (with some hierarchial vestiges left over, since you'll probably want www.pepsi to work "just in case") would require a fundamental restructuring of DNS and would impact reliability and performance in a very noticable fashion.
A more extensible, future-friendly option might be to put DNS back the way it was 10 years ago and build another distributed database designed to map real-world names to Internet domains.
I should be able to use this database to look up the name "Pepsi" in a business context, and have it return "pepsico.com" or something. A DNS SRV lookup on pepsico.com for the 'http' service might return "www12.web-farm.public-facing.pepsico.com" or some other company-specific hostname representing their web servers (it doesn't have to be a vanity "www.pepsi.com" since users don't need to see this anymore). My browser would then connect and I'd get "Pepsi"'s home page, not the home page of "pepsi.com". We need to start breaking this huge reliance on DNS names as a locator service and put DNS back to work at what it was designed to do: to put an alphanumeric label on Internet hosts.
I find this very hard to believe.
I've lived in Texas for most of my life with a *listed* number and never received even a tenth of this volume.
But hey, maybe you're just an extraordinarily unlucky individual, or maybe the previous holder of your number signed up to lots of those contests in the mall. Please consider alternative explanations for where this hugely excessive volume of telemarketing calls came from.
My phone was unusable, because they sold my number to telemarketers.
Oh, please. It's not like you get as many calls as you do pieces of e-mail spam. While I hate telemarketing calls as much as the next guy, to call your phone service "unusable" as a result seems pretty silly.
Get your state to pass legislation for a no-call list. They do this in Missouri and I receive no telemarketing calls.
even though I have been a long suffering DSL customer for over three years.
Does this strike anyone else as hillarious?
There are many perfectly reasonable reasons why you would want to provide an alternative to the default value for many SMTP headers. It's when you lie and mislead by using values that *other* ISP's use in their own headers that you are said to have "forged" them. Bogus "Received" headers can be considered "forged headers" as well, as they are not added by the MTA per the SMTP specification, they are crafted by hand to make it *look* like they were added by an MTA.
These are forgeries. Providing alternative (but still "correct") values for some SMTP headers are not.
(Technically, instead of mucking with the From header, you might want to consider adding a Reply-To and/or Errors-To header instead.)
Neither was Sphere, but I thought Sphere did fairly well and was pretty good to the book.
...or if you do, write in a clause in your contract requiring that the company be liable for any damages incurred by company factors that influence your personal credit rating. So if you're later given a higher interest rate on a car loan, for example, make the company pay for the difference.
I just said things shrink, not consume fewer pixels. When you increase your display resolution, things appear to your eye to get smaller (and free space, from your eye's perspective, appears to get larger).
...is going to be big enough for a while.
What you're basically advocating is changing the "standard icon size" every few years, as display resolutions go up. You also suggest that for print, vector graphics are better. What happens when display resolutions catch up to today's printer resolutions? Will you only advocate a switch to vector graphics when that day arrives? Or by that time will we be using 1024x1024 icons?
The reason you get more room isn't because you've changed resolutions, it's because at higher resolutions, your display elements (GUI, fonts, etc.) shrink in size, thus making room for more stuff.
In a vector world, if you wanted more space on your desktop, you wouldn't change resolutions (ideally, you'd already be at the highest resolution your hardware supported), you would explicitly shrink your display elements (GUI, fonts, etc.) so they consumed less space. (Or get another monitor.)
And who knows, once everything's done with vectors, your GUI might grow and shrink the size of active/active windows ("zoom") to give you all the room you need. MacOS X already does something similar with its task bar.
Most UI elements today make one horrible assumption: that the pixel resolution the user is using allows a 64x64-pixel icon to be viewed comfortably.
We already have displays today where this assumption fails, and where fixed-pixel-size icons are far too small to be usable. In the not-too-distant future, our computer displays won't be measured in pixel dimensions, but by real-world dimensions and a DPI value.
We already have vectored text today, and we need it, especially in the print business. A 12pt font should look exactly the same size on every monitor, regardless of what resolution you're running at. It should just be clearer and sharper at higher resolutions. Graphics should be the same way. Today, they're not. On high-resolution displays, the text may appear about the same size, but now you have all of these graphical elements that are disproportional. SVG fixes that, and icons are a great place to start.
it's that people are allowed to send these messages to anybody they want without any real challenges as to their authenticity.
:/
You go through a lot of work to get your friends "authenticated" in this fashion.
A better solution might be to simply require that every unsolicited e-mail you get be authenticated with a certificate. Set your mail system up to only accept messages to your "real" e-mail address that have either valid PGP or X.509 signatures. Reject everything else with instructions on how to get the tools/certificates to do it.
I do something similar with unique e-mail addresses when signing up on sites. I've also found that it's generally easier to go with username+tag@example.com, where the 'tag' can vary. This is functionally equivalent to username@example.com, but it lets you do some additional filtering without having to set up a new e-mail address. The disadvantage is that there are a lot of sites out there with brain-dead e-mail validation routines that don't permit plus signs.
Whatever you do, though, please leave your postmaster@example.com address working and unfiltered. Yes, you will get spam, but if your mail filtering system ends up malfunctioning one day, this address may be the only way someone can let you know.
While it's true that for many people, some of the spam they receive was inadvertantly "opted in", the vast majority is not.
I have a few e-mail addresses that have only shown up on sites like Slashdot, or in a newsgroup. These invariably get the most spam, and most messages contain that "You signed up at one of our partner sites" disclaimer swearing that what I'm reading isn't spam. Whatever. They're hoping that the confusion this causes is sufficient to cast doubt on your complaint, since it's hard to prove that you were or were not "subscribed" by going to some anonymous 3rd party site and providing them with your details.
Thank God this attitude doesn't prevail.. else we'd still be throwing rocks or shooting arrows at each other and living in adobe huts and caves.
First of all, this is an experiment. Experiments never usually make money in the short term.
Secondly, here's a quote from the article (which several posters need to actually read):Could we please concede the possibility that someone has done a marginal amount of research into this and backed these figures up on some real numbers? Maybe it won't save them that much, or maybe the whole thing will end up costing too much. That's the point of an experiment, after all: to determine if something is going to work.
And for all of the couch port authorities inhabiting Slashdot, please remember that this is probably going to be done with the blessing (and financial support) of a large ocean port. I know that perhaps many of you think you know more about docking ships, managing large ocean-going vessels and the expenses associated with these activities than those in charge of these ports, but please take a deep breath, relax for a minute, and consider the possibility that maybe they're supporting this experiment for a reason, and that reason probably has less to do with a mad scientist trying to dupe someone into buying them a lot of expensive magnets and more to do with a convincing argument that this experiment could save them money in the long run.