Actually, as GP said, due to CRA, banks were REQUIRED to give ARMs to people, regardless of their ability to pay them back.
The CRA laws and regulations literally mandated adjustable rate mortgages, and explicitly forbid the banks to consider creditworthiness? Do you even believe that yourself?
The CRA basically says that depositary banks have to extend credit to ethnic minorities on the same terms that they do to white people. The Clinton-era regulations encouraging "subprime" lending set credit standards for subprime loans that the GSEs would purchase. These loans did pretty good, so a bunch of non-CRA private lenders decided to get into the subprime market, made loans that didn't measure up to the GSE standards, and packaged them in the private market. The GSEs then freaked out about losing market share and got careless about what they'd buy.
And remember, this mortgage stuff is a drop in the bucket compared to the losses in the swap markets. Basically, you're skipping the biggest source of losses in the crisis, and putting blame for a secondary one on the wrong folks, by completely ignoring facts about what happened. Congratulations, you're a hack.
You're missing my point. Your post has two problems:
You're justifying the outcomes of the market just because the market produced them.
You're failing to even listen to what GP said. GP said that his or her employer wants to hire more people, but has problems finding people who will do it for the money they have to pay for them.
In this case, basically, I'd say that GP believes that the economy is not dedicating enough resources to taking care of the patients s/he has to take care of. I'm inclined to agree with GP, and I'd say that the reason this happens is because those patients don't have enough money, and can't find work that would allow them pay more to secure for the level of care they do require--and the fact that they require the care they do is precisely the reason why they can't pay for it.
The market has a systematic bias against providing services to people who can't pay for them, despite the fact that people usually require extremely expensive services precisely when they are least able to pay for them. This of the healthcare problem: if you require very expensive care, there's a very good chance that you can't work to pay for it. Thus the nightmare of the American worker: if you get sick enough not to be able to work, you may lose your employer healthcare plan, and thus have serious problems getting the treatment you need.
To put it in simpler terms: if the market's decisions are always right, then those who lack the ability to obtain money are worth nothing, are merely a drag on the economy, and don't deserve to live. This includes the disabled, people who become seriously sick, and more disturbingly, those of us who simply live long enough that (a) we can't work anymore and (b) run out of whatever savings we built up.
As long as the ethical standards used to judge the outcomes of the market are independent of the market itself, the market can produce awful results, period.
Economically speaking, there are enough. If there weren't, those places would pay more to hire more. There may not be as many as you'd like to help with your shift - and that's a perfectly valid complaint - but your employer has exactly as many as they're willing to pay for.
Dr. Pangloss, is that you? I thought you'd been hanged in Lisbon!
What's the distribution of votes for those candidates? I am guessing the problem here is that your standards for candidate registration in the municipal race are way too lax. Basically, for a candidate to be listed in the ballot, one of the following requirements must be met:
The candidate gathers a minimum number of signatures from the public at large supporting their registration.
The candidate received a minimum percentage of the votes in a prior election.
The candidate is nominated to the position by a registered political party. The requirements for registering a political party are similar to those for a non-affiliated candidate: the party must get a certain number of signatures from the public, or obtained a minimum percentage of votes in a prior election.
In addition, a write-in column should be provided for people to vote for candidates not listed in the ballot.
Do we have the basic TLDs? yes, stop...
Does pretty much every country have its own basic TLD? yes, stop...
Um, why do we need to make TLD vs. non-TLD such an important distinction? What does it really matter how many TLDs there are? The only domain level that really is "special" is the root domain. Why shouldn't TLDs be as freely purchasable as second-level domains?
The implied answers I hear to these questions tend to presuppose that the purpose of hierarchical DNS spaces is to "organize" the Internet, so that commercial sites get put in one TLD, educational institutions in another, UK sites in yet another, and so on. This really strikes me as a very unconvincing idea. Can't we organize the Internet better using a varied collection of directories and search engines, all of these more powerful than DNS?
There are other objections that have to do with things like typosquatting and phishing. I think these really point to UI problems; we've built the Internet so far so that users are exposed too much to domain names. Or, in other terms, we need more powerful and secure ways of pointing end users at Internet resources. Again, non-DNS directories and search engines would do the trick.
Basically, DNS is a pretty good distributed database that maps hierarchical, symbolic host names to IP addresses. The hierarchy of domain names corresponds to a hierarchy of authority to decide which mappings exist within a particular subtree. If you want a domain name at a given level, you should just be able to pay for it. The cost of a domain at any given level should be determined by the cost of running the DNS servers for that domain level. I.e., TLDs might perhaps be more expensive than lower level domain names because running the root DNS servers would be more expensive than running the servers for a second-level domain.
The only domain that really is special is the root domain. All of the recursive sublevels of that are basically equivalent.
OK, so this proposal basically eliminates the entire rationale behind the Domain Name System. There will no longer be any kind of rational separation of sites.
Um, why do we need to separate sites' domain names by "commercial," "network," "organization," "foreign country" and so on?
Let's grant for the sake of argument that there are good reasons to do so (and I wouldn't be terribly surprised if there are). Then, we still have to ask: sure, but why do we need to make that distinction with DNS?
DNS is a distributed database that maps hierarchical names to IP addresses. The only thing that's essential to the hierarchy is that the authority for establishing and updating the mappings under a certain subhierarchy falls to a specified person or organization.
Let's just stop pretending DNS is a good solution for "rational organization" of internet sites, and leave that function to other network services (e.g., directories, search engines).
3. nonsensical (the server is never the one who initiates the transaction)
4. nonsensical (ditto)
I don't think those are nonsensical at all; it's just push technology. It's like Blackberry mail, or for a trip down memory lane, Netscape Netcaster. The only objections I can think of have to do themselves with polysemy of the words "client" and "server" (is the "server" the big, always-on machine that provides a shared resource to a multitude of "clients," or is the server the one that opens a port and listens for connections?).
[The] ballot is as simple as it can be: big circle on the inner page where you're supposed to write the candidate number.
That's not as simple as it can be, as somebody else pointed out to you: if somebody writes their choice unclearly, it may be impossible to adjudicate their vote.
A simple ballot has some generously-sized boxes, one for each choice, and you vote by making a mark on the box that represents your choice. You include things like party emblems in the design, or even candidate photos, to help people who aren't fully literate. You also print sample ballots before the election (clearly and irreversibly marked as invalid), to use as a teaching tool on how to cast one's vote before the actual polls. You run commercials in TV, newspapers and magazines, describing how to fill in the ballot.
With an electronic ballot, we can spread long ballots across several pages, making it vastly easier to group and manage the information (all Presidential candidates on one page, all Congressional on a second, all propositions on a third, etc.)
And with paper ballots... get ready for this... you can do the same thing!
For all those wanting to go back to a paper-based system, I would merely point out that the business world has been working for the past 30 years to move away from paper records.
Financial transactions are not a valid comparison. All records of financial transactions record which account was debited and which was credited. This record can be routinely reconciled with other records to discover errors, and when the parties determine that an error has been made, it can be corrected easily.
Also, financial transactions are largely a private matter between the parties to each transaction, whereas the vote is a matter of public interest; the set of people who have standing to observe whether the vote is being handled correctly includes the whole citizenry.
Other invalid votes were maybe 5 times as common. Most of the time it's a question of whether the number is "1 or 7?" and other common problems are "6 or 0?" and "5 or 6?"
It does seem like requiring voters to express their preferences by handwriting a number is a design flaw (well, OK, except for write-in votes). Why isn't it just marks on boxes? (And make sure the boxes are generously sized!)
That's a careful, nuanced analysis, which is definitely a big credit to you, but I'm afraid you're treating the meanings of these words as being more fixed than they actually are. The way I read you, you're analyzing and classifying file transfers not only in terms of the sender and the receiver, but also in terms of protocol type (client/server vs. peer-to-peer), protocol role of each party (client, server or peer), and request role (initiator vs. responder). This seems to give us the 6 following possibilities:
Client initiates transfer of file from client to server
Client initiates transfer of data from server to client
Server initiates transfer of data from server to client
Server initiates transfer of data from client to server
Peer A initiates transfer of data from Peer A to Peer B
Peer A initiates transfer of data from Peer B to Peer A
Now, I agree with you that the terms "uploading" and "downloading" seem to fit cases (1) and (2) best. But I would seriously entertain the hypothesis that this is merely because, historically, those two were the original file transfer scenarios, and thus, are the prototypical cases.
Now, you seem to be proposing that the terms can or should only ever mean cases (1) and (2). This is just not how language works, however. Basically, faced with cases (3)-(6), with a vocabulary of words that prototypically refer to cases (1) and (2), it will be very common for people to generalize the meaning of the words to cover those new cases. Now, there are several ways the meaning can be generalized, but the one that seems to be at stake here is to drop out the client/server distinction, and making the "uploader" be a responder that sends a file to an initiator that requests said file.
This is quite a natural semantic extension, linguistically speaking. Basically, the original usage examples for "upload" all describe case (2), but nothing about the examples can possibly tell what's essential to the meaning of the word, and what's just accidental to the examples. In simpler words, if you were a computer trying to infer the meaning of the word "upload" from examples that only showed type (2), you'd have no way of knowing whether the client/server distinction was essential and exceptionless, or whether you just happened to get a data set that didn't have any examples of the word being used in another sense. And you can't expect the way people infer word meanings from usage to be any better than that.
So really, I don't think there is any absolute, authoritative answer to give in this case. The best you can do is point out (correctly, I think) that senses (1) and (2) are the "best" in some statistical or prototypical sense. The key thing to keep in mind, however, is that the extension of the meaning of the word to closely related cases is quite unsurprising, and usually follows some sort of rule.
Printers will fail at some non-trivial rate. The correct count of paper receipts, therefore, will still be at error. Will this affect all choices in a race with equal probability? That's hard to guess, but it's easy to imagine cases where it doesn't (really close race, machines go bad in districts that favor the same candidate, because they have a smaller budget for training of election workers and maintenance of the machines).
The electronic count has pretty big errors, which would be easily detected by a count of the receipts. However, the margin of the difference in votes in the electronic count is used to successfully argue against any paper recount.
Why don't they just raise the price? If there's this huge demand for the thing, just raise the price until supply = demand?
You're assuming that a scarce good that's in high demand can always be sold for a high price. The truth is that is only the case to the extent that potential buyers are unwilling or unable to purchase substitute goods, or even just forego buying the good in question. (See the concept of price elasticity of demand.)
For a game console like the Wii, there are many substitute products (competitor game consoles, games for consoles that you already own, boardgames, toys, etc.); a potential buyer might choose to spend their money differently if the price of the Wii went up.
Also, you have to remember that game consoles are usually sold as teaser products, often even at a loss, with the intention of making the profit in the games.
Secondly, a poorly calibrated device does NOT imply that the software specifically written for this task, e.g. the application - what I consider the UI in this case - is the issue.
At the end of the day, you're going to be told this: the buyer of a electronic voting machine isn't going to care whether you consider that your responsibilities end where the UI, as you define it, ends. They're going to care whether the machine solves their problem or not--and if it involves constant calibration of a touchscreen that their election workers cannot reliably do, you have two options: (a) don't sell the machine with a touchscreen, (b) provide them with a service contract that effectively takes care that the machines get calibrated and stay calibrated during election day.
In this particular case, the calibration of the touch screen with regards to the operating system is the problem. As far as the application that handles the actual voting goes, it can only do it's job to the extent that the inputs it is receiving are correct (which come from the operating system, which come from the hardware, which comes from the user).
What do you think is your job, writing applications, or solving users' problems?
The compartmentalization that you're describing here isn't relevant to the users of the voting machine, period. It's just something that makes it harder for you to solve the users' problem. You have several choices (not exclusive):
You can think of a way to avoid the problem in the first place. For example, you might not use a touchscreen at all.
You can reformulate the nature of the product. Instead of selling an "application," you would sell an appliance, where you have control over the hardware, OS, driver versions and everything
You can reformulate the product line. Instead of selling an application or appliance, you could sell a service. This could be structured in many ways, but in one version, your would own the hardware and develop the software, your service folk would install it in the location, and your folk would also do all calibration required.
Or, of course, you could continue to compartmentalize the issues into "application," "operating system" and "hardware," and when the user rightly complains that what you sold them doesn't solve their problem, you can throw a hissy fit and say that it's their fault. (And then you can tell them to fuck off, dub them cum guzzling gutter slut bitch, and threaten to scatter bits and pieces of their face across the room, too, if you like. And then they call the cops...)
Second, that you think the person (or people) in charge of writing the application are also the ones who wrote the operating system, device drivers, and calibration software. You don't know a fucking thing about this breakdown, and your arrogant assumption that a single group of people were responsible for the creation of this "solution" from beginning to end is flawed, at best.
Oh, but I know perfectly well that there is more than one person who created the various pieces to this, and I know the breakdown very well, thank you. I also know that customers like vendors who act like they want their customers to succeed, and take responsibility for making that happen. I deal all the time with failures that aren't caused by my company's software. There is always something you can do; e.g., we write test cases that reproduce Oracle bugs that our customers run into. We QA test our software on a variety of hardware, OS and driver combinations, and recommend our customers to use the same as we do. We also provide a product where the customer can buy our software as a service over the web--they pay us quarterly, and we provide all the hardware, OS, RDBMS, network hosting, etc. In that case, when any of the pieces fails to work, it's explicitly and contractually our problem.
Good luck telling your customers to fuck off when they can't get your application to solve their problem! (And good luck at the police station!)
If the votes are switched randomly, it's stupidity/incompetence. If it's always Dems switched to Repubs or the other way around, somebody needs to spend time in jail. Not only is it not rocket science, there aren't even any rockets involved.
...randomly over what population, defined in which way?
In one of the issues that's being described for these machines, because of the angle that the voters view the touchscreen, there will be a bias towards accidentally selecting boxes towards the top of the screen. (This is analogous to ATM buttons--how many times have you had to count to make sure the button you press lines up with the action that you perform?)
So basically, if you order the candidates in a race randomly, and you show all voters in that race the candidates in that order, you expect the vote-flipping to favor any given candidate over the one just below. If the population of votes you're examining is just the votes for that race, then you'll definitely see something like the "non-random" scenario you're describing. But the cause of the bias, ultimately, is that one initial random choice that biased the system.
The touchscreen is also part of the UI, and a touchscreen that is uncalibrated is an UI problem. "UI" encompasses the everything that's relevant to the user's interaction with the device. If the intended user audience can't reliably use the device, then the UI is most likely flawed.
Your attitude is one of the basic sources of usability problems: the failure to take responsibility for the end user's experience, and instead, whine with excuses when the users can't use the device. Excuses range from "this is a hardware problem, not a software problem" (when the end users just can't possibly care, because it's not relevant to them), to "the user is stupid" (when people are perfectly adept at performing all sorts of tasks that would provide the correct input).
The whole point of usability design is to solve problems, not to blame them on other people. If the possibility of an uncalibrated touchscreen is a problem, then you need to take a hard look at whether you can avoid using the touchscreen at all, and use a more reliable input device that has fewer failure modes.
What about your statement couldn't be said about an ATM?
There's a very simple, important difference. When an ATM makes an error, it can be reliably detected and corrected in nearly all cases. This is because the ATM (and electronic money transfer systems, in general) keep a detailed record of which accounts were debited and credited for each transaction, and this record can be reconciled with others: e.g., the customers' own checkbooks, online merchants' records, records of how much cash was in the ATM at any point in time, etc. When the relevant parties conclude a certain transaction was recorded incorrectly, it can be rolled back or revised.
When a voting machine makes an error, it's at best a toss-up as to whether it can be detected. No paper trails mean that, in many cases, the error can never be detected. Paper trails help A LOT in this case, but are not a panacea: you can imagine a case where, because of fraud, the electronic tabulation gives candidate A a clear win, and nobody bothers to perform a paper recount that would prove candidate B actually won.
And if you do detect an anomaly in the vote, forget about ever correcting it.
Because you can have God's own UI design that even the most moronic person in the universe could figure out, slap it onto a POS machine without enough power to run it quickly and you WILL have a response time/feedback time problem. UI design, while it CAN and SHOULD take into account the amount of system resources it is using, cannot accurately predict the power of the machines that will be running it.
You're setting up an artificial barrier software/hardware barrier here. UI design isn't just about software--it's about the whole user experience, and that requires thinking about hardware.
In this case, we're talking about a custom-built voting appliance, with non-standard hardware to support its UI (a touchscreen). There is no excuse for slow reaction times.
They can't find it because they didn't care at the time of saving to attach enough information to the file to be able to find it later. Instead, they saved it under a name like "letter5", or even worse, "asdf", and possibly left it in a random directory as well.
People in real life very often do not attach that kind of information to documents and objects, yet they don't completely suck at finding them later (even if they're far from perfect at it). Some folks are better at organizing stuff, and some are worse, but typically the creation of new paper documents and their classification and storage for later retrieval are separate activities, often performed by different people.
I really think the current UI paradigm for files is just wrong. Here's my (not thought through) ideas about it (some copied from various sources, others inferred but with no claim to originality):
The "save file" operation should not exist at all. The user's work is always automatically saved.
Documents don't need to have a name, period. The system should enable the user to identify documents by their content.
Any document that the user works on is put in the desktop. If a user was just working on a document, closed it, and decides they need to use it again, the document is going to be on their desktop.
The desktop needs to be very powerful, not just a collection of uninformative icons. It needs to display zoomable thumbnails of documents. You need to be able to recognize individual documents from their representation in the desktop. Something like a Zooming User Interface.
The UI should provide tools for "filing" documents, and for finding them later on. Filing is what removes documents from your desktop for "permanent" storage. The system can offer a variety of tools for doing this, including tags, description fields and other metadata, flat folders, hierarchical folder trees, etc., and the user can choose the ones that they think best fit, when they need them, and as they need them. (They can also choose more than one classification for a document--e.g., put the same document in two folders, or have two orthogonal hierarchical trees of the same documents classified in more than one way).
The system should provide search of the documents.
Yes, under this system, some people will spend too little time filing, and thus make a huge sprawling mess of their desktop. That's not great, but it's better than the current paradigm, because they will at least know where their recent document is (in the desktop), and at least one method for finding it (looking at the documents on their desktop). The point is to make the system easy to use, not to fix the character flaws of the user.
The point of DNS is not just that you can find what you're looking for but also that there is a unique first-come-first-served association between something simple to remember and a particular owner.
There is no reason this cannot be done as a web service. A web directory or search provider is just as capable of selling such associations as domain registration vendors. Doing it with the web also opens the whole field up to competition.
Also, hostnames are not automatically simple to remember.
It will look exactly the same, most of the people today don't type domain names, they just use a search engine and click on the first link.
Yup. DNS serves an important function: a distributed database of symbolic hostnames to IP addresses, where each domain represents an independent authority entitled to decide the mapping for a given subset of FQDNs. DNS allows you to change hosts' IP addresses without breaking references to those hosts. This function is essential, but it's also akin to plumbing, really.
The problem that DNS has been misapplied to is how to get users to access specific content on the internet, for example, by making address bars such a prominent part of browser UIs, and expecting users to access content by typing DNS names into that bar. The end user content-addressing problem (i.e., "how does an end user get to a specific site") can be solved better, and in a more flexible, decentralized manner by tools like search engines and other kinds of directory services.
Consider that users don't really have a choice but to use the DNS system. Yeah, I know about alternative roots, but most people just won't understand how to make that work, and anyway, it involves transferring power from one set of people to another. With search engines, OTOH, there is a variety of choice, and you can switch easily from one to another. You can use more than one at the same time if you wish, and specialized search engines for different purposes can coexist.
So really, we need something like DNS as part of the plumbing of the net, but it's the wrong place to address the end user content-addressing problem. The folks who control DNS have all the power they do because we're using DNS as a stopgap solution for that problem. This is precisely why we should stop doing so: if we used DNS only as part of the low-level plumbing, restructuring the TLDs would just not be a big issue.
Actually, I really hope vanity TLDs become commonplace to the point where they just increases the supply of domain names so much that they lose their non-plumbing value. I'm not holding my breath, however, because I assume the DNS authorities will try to create some kind of artificial scarcity.
If you make the Internet a place where people can isolate themselves, then it's no longer an Internet.
Um, how is it that if some people use a language that you don't speak, they are "isolating themselves"? Are one billion Mandaring speakers "isolating themselves"?
Your computer is almost certainly capable of accessing websites in dozens of scripts, using fonts to display their content correctly, and of accepting text input in those scripts; this stuff is all standardized (Unicode). There is no technical barrier at all, and the social ones aren't because of prohibitions or censorship: nobody's stopping you from learning some Mandarin or Russian if you really want to see what those sites say.
You don't even have to go all the way: I don't speak a word of Chinese, but I often successfully search Google, in Chinese, for images of Chinese cooking ingredients. If my cookbook has both the Chinese character and the romanization, I can, about 75% of the time, figure out how to enter the Chinese text into Google Images, and off I go. It's not exactly easy, but it's not rocket surgery, you know.
The real technical isolation problems are things like the Great Firewall of China, and guess what, that has nothing to do with Unicode domain name support. Chinese Internet censorship would be as much of a problem if all of the net was English-only.
The Internet works because it is all based on standards. [...] Once you make concessions for non-standard this and that, you encourage segmentation and segregation.
Yes, and we have a standard for encoding text in dozens of scripts, and standards for how to encode Unicode into domain names. But apparently, standards that you don't want to exist are not standards, but rather "concessions for non-standard this and that"; and they segment and segregate the internet, even if your computer supports them. WTF?
What are you going to argue next, that everybody should stop speaking those pesky foreign languages, because they're foreign? Because after all, why stop the fight against "segregation" and "segmentation" at just the Internet?
Slashdot Mirror
The CRA laws and regulations literally mandated adjustable rate mortgages, and explicitly forbid the banks to consider creditworthiness? Do you even believe that yourself?
The CRA basically says that depositary banks have to extend credit to ethnic minorities on the same terms that they do to white people. The Clinton-era regulations encouraging "subprime" lending set credit standards for subprime loans that the GSEs would purchase. These loans did pretty good, so a bunch of non-CRA private lenders decided to get into the subprime market, made loans that didn't measure up to the GSE standards, and packaged them in the private market. The GSEs then freaked out about losing market share and got careless about what they'd buy.
And remember, this mortgage stuff is a drop in the bucket compared to the losses in the swap markets. Basically, you're skipping the biggest source of losses in the crisis, and putting blame for a secondary one on the wrong folks, by completely ignoring facts about what happened. Congratulations, you're a hack.
You're missing my point. Your post has two problems:
In this case, basically, I'd say that GP believes that the economy is not dedicating enough resources to taking care of the patients s/he has to take care of. I'm inclined to agree with GP, and I'd say that the reason this happens is because those patients don't have enough money, and can't find work that would allow them pay more to secure for the level of care they do require--and the fact that they require the care they do is precisely the reason why they can't pay for it.
The market has a systematic bias against providing services to people who can't pay for them, despite the fact that people usually require extremely expensive services precisely when they are least able to pay for them. This of the healthcare problem: if you require very expensive care, there's a very good chance that you can't work to pay for it. Thus the nightmare of the American worker: if you get sick enough not to be able to work, you may lose your employer healthcare plan, and thus have serious problems getting the treatment you need.
To put it in simpler terms: if the market's decisions are always right, then those who lack the ability to obtain money are worth nothing, are merely a drag on the economy, and don't deserve to live. This includes the disabled, people who become seriously sick, and more disturbingly, those of us who simply live long enough that (a) we can't work anymore and (b) run out of whatever savings we built up.
As long as the ethical standards used to judge the outcomes of the market are independent of the market itself, the market can produce awful results, period.
Dr. Pangloss, is that you? I thought you'd been hanged in Lisbon!
Secretary of State blocking voter registration in California.
Making Votes Count in Florida
What's the distribution of votes for those candidates? I am guessing the problem here is that your standards for candidate registration in the municipal race are way too lax. Basically, for a candidate to be listed in the ballot, one of the following requirements must be met:
In addition, a write-in column should be provided for people to vote for candidates not listed in the ballot.
Um, why do we need to make TLD vs. non-TLD such an important distinction? What does it really matter how many TLDs there are? The only domain level that really is "special" is the root domain. Why shouldn't TLDs be as freely purchasable as second-level domains?
The implied answers I hear to these questions tend to presuppose that the purpose of hierarchical DNS spaces is to "organize" the Internet, so that commercial sites get put in one TLD, educational institutions in another, UK sites in yet another, and so on. This really strikes me as a very unconvincing idea. Can't we organize the Internet better using a varied collection of directories and search engines, all of these more powerful than DNS?
There are other objections that have to do with things like typosquatting and phishing. I think these really point to UI problems; we've built the Internet so far so that users are exposed too much to domain names. Or, in other terms, we need more powerful and secure ways of pointing end users at Internet resources. Again, non-DNS directories and search engines would do the trick.
Basically, DNS is a pretty good distributed database that maps hierarchical, symbolic host names to IP addresses. The hierarchy of domain names corresponds to a hierarchy of authority to decide which mappings exist within a particular subtree. If you want a domain name at a given level, you should just be able to pay for it. The cost of a domain at any given level should be determined by the cost of running the DNS servers for that domain level. I.e., TLDs might perhaps be more expensive than lower level domain names because running the root DNS servers would be more expensive than running the servers for a second-level domain.
The only domain that really is special is the root domain. All of the recursive sublevels of that are basically equivalent.
Um, why do we need to separate sites' domain names by "commercial," "network," "organization," "foreign country" and so on?
Let's grant for the sake of argument that there are good reasons to do so (and I wouldn't be terribly surprised if there are). Then, we still have to ask: sure, but why do we need to make that distinction with DNS?
DNS is a distributed database that maps hierarchical names to IP addresses. The only thing that's essential to the hierarchy is that the authority for establishing and updating the mappings under a certain subhierarchy falls to a specified person or organization.
Let's just stop pretending DNS is a good solution for "rational organization" of internet sites, and leave that function to other network services (e.g., directories, search engines).
I don't think those are nonsensical at all; it's just push technology. It's like Blackberry mail, or for a trip down memory lane, Netscape Netcaster. The only objections I can think of have to do themselves with polysemy of the words "client" and "server" (is the "server" the big, always-on machine that provides a shared resource to a multitude of "clients," or is the server the one that opens a port and listens for connections?).
How often do the printers have problems, and what happens to those votes?
That's not as simple as it can be, as somebody else pointed out to you: if somebody writes their choice unclearly, it may be impossible to adjudicate their vote.
A simple ballot has some generously-sized boxes, one for each choice, and you vote by making a mark on the box that represents your choice. You include things like party emblems in the design, or even candidate photos, to help people who aren't fully literate. You also print sample ballots before the election (clearly and irreversibly marked as invalid), to use as a teaching tool on how to cast one's vote before the actual polls. You run commercials in TV, newspapers and magazines, describing how to fill in the ballot.
And with paper ballots... get ready for this... you can do the same thing!
Financial transactions are not a valid comparison. All records of financial transactions record which account was debited and which was credited. This record can be routinely reconciled with other records to discover errors, and when the parties determine that an error has been made, it can be corrected easily.
Also, financial transactions are largely a private matter between the parties to each transaction, whereas the vote is a matter of public interest; the set of people who have standing to observe whether the vote is being handled correctly includes the whole citizenry.
Please stop making this completely false analogy.
It does seem like requiring voters to express their preferences by handwriting a number is a design flaw (well, OK, except for write-in votes). Why isn't it just marks on boxes? (And make sure the boxes are generously sized!)
Or maybe everybody has problems following simple instructions 2% of the time.
That's a careful, nuanced analysis, which is definitely a big credit to you, but I'm afraid you're treating the meanings of these words as being more fixed than they actually are. The way I read you, you're analyzing and classifying file transfers not only in terms of the sender and the receiver, but also in terms of protocol type (client/server vs. peer-to-peer), protocol role of each party (client, server or peer), and request role (initiator vs. responder). This seems to give us the 6 following possibilities:
Now, I agree with you that the terms "uploading" and "downloading" seem to fit cases (1) and (2) best. But I would seriously entertain the hypothesis that this is merely because, historically, those two were the original file transfer scenarios, and thus, are the prototypical cases.
Now, you seem to be proposing that the terms can or should only ever mean cases (1) and (2). This is just not how language works, however. Basically, faced with cases (3)-(6), with a vocabulary of words that prototypically refer to cases (1) and (2), it will be very common for people to generalize the meaning of the words to cover those new cases. Now, there are several ways the meaning can be generalized, but the one that seems to be at stake here is to drop out the client/server distinction, and making the "uploader" be a responder that sends a file to an initiator that requests said file.
This is quite a natural semantic extension, linguistically speaking. Basically, the original usage examples for "upload" all describe case (2), but nothing about the examples can possibly tell what's essential to the meaning of the word, and what's just accidental to the examples. In simpler words, if you were a computer trying to infer the meaning of the word "upload" from examples that only showed type (2), you'd have no way of knowing whether the client/server distinction was essential and exceptionless, or whether you just happened to get a data set that didn't have any examples of the word being used in another sense. And you can't expect the way people infer word meanings from usage to be any better than that.
So really, I don't think there is any absolute, authoritative answer to give in this case. The best you can do is point out (correctly, I think) that senses (1) and (2) are the "best" in some statistical or prototypical sense. The key thing to keep in mind, however, is that the extension of the meaning of the word to closely related cases is quite unsurprising, and usually follows some sort of rule.
You're assuming that a scarce good that's in high demand can always be sold for a high price. The truth is that is only the case to the extent that potential buyers are unwilling or unable to purchase substitute goods, or even just forego buying the good in question. (See the concept of price elasticity of demand.)
For a game console like the Wii, there are many substitute products (competitor game consoles, games for consoles that you already own, boardgames, toys, etc.); a potential buyer might choose to spend their money differently if the price of the Wii went up.
Also, you have to remember that game consoles are usually sold as teaser products, often even at a loss, with the intention of making the profit in the games.
At the end of the day, you're going to be told this: the buyer of a electronic voting machine isn't going to care whether you consider that your responsibilities end where the UI, as you define it, ends. They're going to care whether the machine solves their problem or not--and if it involves constant calibration of a touchscreen that their election workers cannot reliably do, you have two options: (a) don't sell the machine with a touchscreen, (b) provide them with a service contract that effectively takes care that the machines get calibrated and stay calibrated during election day.
What do you think is your job, writing applications, or solving users' problems?
The compartmentalization that you're describing here isn't relevant to the users of the voting machine, period. It's just something that makes it harder for you to solve the users' problem. You have several choices (not exclusive):
Oh, but I know perfectly well that there is more than one person who created the various pieces to this, and I know the breakdown very well, thank you. I also know that customers like vendors who act like they want their customers to succeed, and take responsibility for making that happen. I deal all the time with failures that aren't caused by my company's software. There is always something you can do; e.g., we write test cases that reproduce Oracle bugs that our customers run into. We QA test our software on a variety of hardware, OS and driver combinations, and recommend our customers to use the same as we do. We also provide a product where the customer can buy our software as a service over the web--they pay us quarterly, and we provide all the hardware, OS, RDBMS, network hosting, etc. In that case, when any of the pieces fails to work, it's explicitly and contractually our problem.
Good luck telling your customers to fuck off when they can't get your application to solve their problem! (And good luck at the police station!)
...randomly over what population, defined in which way?
In one of the issues that's being described for these machines, because of the angle that the voters view the touchscreen, there will be a bias towards accidentally selecting boxes towards the top of the screen. (This is analogous to ATM buttons--how many times have you had to count to make sure the button you press lines up with the action that you perform?)
So basically, if you order the candidates in a race randomly, and you show all voters in that race the candidates in that order, you expect the vote-flipping to favor any given candidate over the one just below. If the population of votes you're examining is just the votes for that race, then you'll definitely see something like the "non-random" scenario you're describing. But the cause of the bias, ultimately, is that one initial random choice that biased the system.
The touchscreen is also part of the UI, and a touchscreen that is uncalibrated is an UI problem. "UI" encompasses the everything that's relevant to the user's interaction with the device. If the intended user audience can't reliably use the device, then the UI is most likely flawed.
Your attitude is one of the basic sources of usability problems: the failure to take responsibility for the end user's experience, and instead, whine with excuses when the users can't use the device. Excuses range from "this is a hardware problem, not a software problem" (when the end users just can't possibly care, because it's not relevant to them), to "the user is stupid" (when people are perfectly adept at performing all sorts of tasks that would provide the correct input).
The whole point of usability design is to solve problems, not to blame them on other people. If the possibility of an uncalibrated touchscreen is a problem, then you need to take a hard look at whether you can avoid using the touchscreen at all, and use a more reliable input device that has fewer failure modes.
There's a very simple, important difference. When an ATM makes an error, it can be reliably detected and corrected in nearly all cases. This is because the ATM (and electronic money transfer systems, in general) keep a detailed record of which accounts were debited and credited for each transaction, and this record can be reconciled with others: e.g., the customers' own checkbooks, online merchants' records, records of how much cash was in the ATM at any point in time, etc. When the relevant parties conclude a certain transaction was recorded incorrectly, it can be rolled back or revised.
When a voting machine makes an error, it's at best a toss-up as to whether it can be detected. No paper trails mean that, in many cases, the error can never be detected. Paper trails help A LOT in this case, but are not a panacea: you can imagine a case where, because of fraud, the electronic tabulation gives candidate A a clear win, and nobody bothers to perform a paper recount that would prove candidate B actually won.
And if you do detect an anomaly in the vote, forget about ever correcting it.
You're setting up an artificial barrier software/hardware barrier here. UI design isn't just about software--it's about the whole user experience, and that requires thinking about hardware.
In this case, we're talking about a custom-built voting appliance, with non-standard hardware to support its UI (a touchscreen). There is no excuse for slow reaction times.
People in real life very often do not attach that kind of information to documents and objects, yet they don't completely suck at finding them later (even if they're far from perfect at it). Some folks are better at organizing stuff, and some are worse, but typically the creation of new paper documents and their classification and storage for later retrieval are separate activities, often performed by different people.
I really think the current UI paradigm for files is just wrong. Here's my (not thought through) ideas about it (some copied from various sources, others inferred but with no claim to originality):
Yes, under this system, some people will spend too little time filing, and thus make a huge sprawling mess of their desktop. That's not great, but it's better than the current paradigm, because they will at least know where their recent document is (in the desktop), and at least one method for finding it (looking at the documents on their desktop). The point is to make the system easy to use, not to fix the character flaws of the user.
There is no reason this cannot be done as a web service. A web directory or search provider is just as capable of selling such associations as domain registration vendors. Doing it with the web also opens the whole field up to competition.
Also, hostnames are not automatically simple to remember.
Yup. DNS serves an important function: a distributed database of symbolic hostnames to IP addresses, where each domain represents an independent authority entitled to decide the mapping for a given subset of FQDNs. DNS allows you to change hosts' IP addresses without breaking references to those hosts. This function is essential, but it's also akin to plumbing, really.
The problem that DNS has been misapplied to is how to get users to access specific content on the internet, for example, by making address bars such a prominent part of browser UIs, and expecting users to access content by typing DNS names into that bar. The end user content-addressing problem (i.e., "how does an end user get to a specific site") can be solved better, and in a more flexible, decentralized manner by tools like search engines and other kinds of directory services.
Consider that users don't really have a choice but to use the DNS system. Yeah, I know about alternative roots, but most people just won't understand how to make that work, and anyway, it involves transferring power from one set of people to another. With search engines, OTOH, there is a variety of choice, and you can switch easily from one to another. You can use more than one at the same time if you wish, and specialized search engines for different purposes can coexist.
So really, we need something like DNS as part of the plumbing of the net, but it's the wrong place to address the end user content-addressing problem. The folks who control DNS have all the power they do because we're using DNS as a stopgap solution for that problem. This is precisely why we should stop doing so: if we used DNS only as part of the low-level plumbing, restructuring the TLDs would just not be a big issue.
Actually, I really hope vanity TLDs become commonplace to the point where they just increases the supply of domain names so much that they lose their non-plumbing value. I'm not holding my breath, however, because I assume the DNS authorities will try to create some kind of artificial scarcity.
Um, how is it that if some people use a language that you don't speak, they are "isolating themselves"? Are one billion Mandaring speakers "isolating themselves"?
Your computer is almost certainly capable of accessing websites in dozens of scripts, using fonts to display their content correctly, and of accepting text input in those scripts; this stuff is all standardized (Unicode). There is no technical barrier at all, and the social ones aren't because of prohibitions or censorship: nobody's stopping you from learning some Mandarin or Russian if you really want to see what those sites say.
You don't even have to go all the way: I don't speak a word of Chinese, but I often successfully search Google, in Chinese, for images of Chinese cooking ingredients. If my cookbook has both the Chinese character and the romanization, I can, about 75% of the time, figure out how to enter the Chinese text into Google Images, and off I go. It's not exactly easy, but it's not rocket surgery, you know.
The real technical isolation problems are things like the Great Firewall of China, and guess what, that has nothing to do with Unicode domain name support. Chinese Internet censorship would be as much of a problem if all of the net was English-only.
Yes, and we have a standard for encoding text in dozens of scripts, and standards for how to encode Unicode into domain names. But apparently, standards that you don't want to exist are not standards, but rather "concessions for non-standard this and that"; and they segment and segregate the internet, even if your computer supports them. WTF?
What are you going to argue next, that everybody should stop speaking those pesky foreign languages, because they're foreign? Because after all, why stop the fight against "segregation" and "segmentation" at just the Internet?