Having known several U.S.-born foreigners, I'd say this isn't as uncommon as you'd think. It may be just a blip on the radar in the grand scheme of things, but there are definitely people who fall into this crack.
One of the main reasons people renounce US citizenship is because America, rather uniquely, likes to tax its citizens regardless of whether or not they are actually working and earning income in America.
(Similarly, and again somewhat uniquely, residents (from a taxation perspective, not an immigration one) have to pay tax on their worldwide income.)
Most of the evidence and speculation points to increased wear and tear but no mortal danger -- if that is the case, then Bronson is correct, the airlines should definitely decide whether to bear those costs or not.
Hindsight is always 20/20. Previous experiences with aircraft and ash clouds have typically not ended well, meaning - as already mentioned - the only sane choice is to err on the side of caution.
Now, had the airlines *already* done the testing to determine what was a safe level of ash in the air, before this happened, then they might have a leg to stand on with calls of "overreaction". However, as far as I know none of them have (and I'm willing to bet none of them do - at least until Government regulations spurred by recent even force them to).
Even if it turns out from new research that the danger was overestimated at the time, the airlines *still* won't have a reasonable claim, because no-one knew at the time.
Although the software app was different, the screen, keypad, card reader, receipt printer and money handling hardware were all the same, as was the data transfer and validation backend. Thus my assertion that the OS/2 units booted faster and were more responsive in operation doing the same job.
So, you ignore probably the single most significant component relating to interactive responsiveness ? Nice job.
Not necessarily. They might suffer damage but still be operable, and only require more maintenance. Or they might suffer damage and have to be replaced after landing.
Perhaps you missed the point I was making, that if the engines go from "operable" to "inoperable" while the plane is in the air, then that most certainly represents a "mortal" threat to the passengers.
That's the whole point. Nobody really knows.
In which case the only sane choice is to err on the side of safety.
The airlines are free to do their own research and find out exactly how much ash is dangerous - no-one is stopping them. The government is just stipulating they have to do it under controlled conditions when said testing is not endangering innocents.
If the engines are slowly destroyed by ash in the air, the danger posed is a financial one to the airline companies, not a mortal one to the passengers.
It is on the flight when the engines transition from "being destroyed" to "are destroyed".
Heh. OS/2 on 300MHz and 32Mb ram makes for a more responsive Automatic Teller Machine than the later 2GHz 512Mb burdened with XP. The rest of the whole ATM was identical so you know it was doing the same job.
The application was identical on both ? What was it written in ?
Also, it took 15 minutes to install, against the XP's 2-3 hours.
Well, that's just incompetence. There's no reason an automated install on known hardware shoudl take that long.
In addition, there are new companies that are using OS/2 for specialized apps or as servers that have gotten fed up with Windows, and find the various fragmented releases of Linux to be too daunting.
It's a struggle to understand why anyone would choose OS/2 over Windows or the two mainstream Linux distributions.
Unless, of course, they're being misled...
What compelling features for a new installation could OS/2 possibly have over Windows Server 2008, RHEL, or SuSe ?
Actually it's an excellent reason not to optimise, because you'd be optimising for an uncommon case at the expense of a common one.
And CD is used in livecd environment A LOT, you see that even strange access patterns could use optimizing.
LiveCDs are not even remotely close to a common use case, which is why the vastly superior option is to manually optimise by using things like RAM drives.
So what you are thinking is that the OS cache intentionally purges high frequency data in favor of low frequency data, for a reason that arbitrary hurts performance.
No. Nearly the exact opposite, in fact - that the OS will favour smaller, more frequently accessed data over larger, less frequently accessed data.
Dumping most of your cache contents because someone decided to rip a 4GB DVD to an ISO (to use a fairly obvious example) is nearly always going to be a dumb idea.
"Even though I am fielding requests for that big block of data all the god damned time.. like every five seconds and shit... I'm going to go ahead and dump most of it as soon as the system asks for that random burst of rarely used data that is only read once per session at most"
That's not an access pattern even remotely typical of a large sequential read or write. Large sequential reads or writes to a given dataset are - relatively - uncommon events.
I can guarantee you the typical SAN will identify and (typically) not cache large sequential disk operations. If you want that sort of behaviour you need to tune for it. OS caching is a little different, but by its nature sequential data will typically be evicted quicker
It does it even on large sequential accesses, but only for up-to the first 512KB (yes, since I posted last I read the damn specifics. The white paper is available.)
Can you point me to this whitepaper ? I searched but couldn't find anything with technical details about how ReadyBoost is implemented.
Those new Intel CPUs use PCIe to connect to "southbridge". PCIe is designed to be explicitly backwards compatible across versions (yeah, there will be less bandwith to the "southbridge" available...irrelevant in nearly all scenarios).
How about adding more lanes than are in the original spec ?
Obviously the requirement doesn't exist if its something quite opposite is followed...the question is why Intel chooses so.
Because not doing so reduces costs ?
Based on their past actions, I have my doubts that what they they do is all around optimal.
What do you mean by "optimal" ? "Optimal" for whom ?
This is a good reason for suspecting "intentional obsolescence"...Intel has already done so quite a few times (no, don't limit yourself only to cpu sockets, if you really want to have vert clear examples...)
For example ?
And please, stop with portraying like it's a solid fact that there's no demand for greater (this all I'm talking about - greater, not absolute) upgradeability.
I'm not. I'm observing that it is a "solid fact" very few people upgrade systems at all, and even fewer are only interested in upgrading the CPU.
Even multiple components doesn't have to include so many major ones as you want to believe...
It's got nothing to do with what I believe, it's got to do with what I've been observing computer enthusiasts actually doing over the last 15 years. There is very little evidence to suggest a general desire across the PC market for greater upgradeability.
Look, seriously. The whole argument here is that there's a group of people in Intel who specifically set out with each new CPU design to make it incompatible with existing hardware, because by doing this they hope to squeeze more profits out of... the fraction of 1% of users who are interested in CPU upgrades. If that doesn't make you go "WTF ?" straight off the bat, then there's absolutely nothing I'm going to be able to say that convinces you otherwise.
Uh, right. That's why flow charts remain so popular.
Flow charts (and their descendants) are *massively* easier to understand and follow than something like pages of if...then statements. That's exactly why they _are_ popular.
Some things are better expressed in text; some in figures. A set of rules -- like those for a firewall -- are better expressed in text.
Why ? Which firewall's syntax are you going to express your rules in ? How long does it take for understanding of your ruleset to transfer to those unfamiliar with that syntax ? How do you delegate access and control of specific subsets of the rules ?
Your example is 100% backwards. Consider something simple like adding a host to a standard ACL list for webservers. Why should it be any harder than simply editing a plain text file?
Because editing text files is a manual and error-prone process. There's little to no input validation, sanity checking, or ability restrict access and delegate responsibilities. Just type it in, proofread, cross your fingers and go.
Why should it involve some meaningless symbolism of dragging one shape into another shape?
In what way are icons any less meaningless symbolism than configuration syntax keywords ?
How do I grep through these shapes?
You use the organisational and search constructs in the GUI.
How do I filter them into reports?
By using the reporting in the GUI.
How do I back up old configurations? How do I copy configuration from one system to another?
At a glance, absolutely. Primarily because if there are other associated ports that could go with the rule (eg: to 443) that can then be captured in the diagram but not the table. Similarly, if there are half a dozen rules, rather than just one, the graphical representation becomes even easier to understand, because the more lines of very similar text you add, the harder it becomes to pick out particular ones (and more importantly, identify errors in them). Additionally, your tabular representation contains information that is not relevant at the design/conceptual level (port numbers).
And, how do I know "(www)" means port 80? (It could be any port, www is irrelevant).
Because you've defined it elsewhere in the interface.
What if I was running sshd on 80? What then? What if I was really sneaky and multiplexed port 80 for web and sshd via some proxy client I wrote?
Then you define those things elsewhere as well. Once, so you don't need to keep repeating relatively unimportant information.
This is where the GUI paradigm being discussed breaks down when you're talking firewalls. Honestly - you cannot make a GUI easier to understand than tabular data regarding firewalls, since firewalls are inherently tabular data. Don't try to fit square pegs into round holes.
Of course you can. That graphical representations are easier and quicker to understand than raw numbers is something that's been known for centuries. Again, this is why we use graphs to help interpret data rather than starting at lines of numbers.
Having said that - you can create a GUI/management application that allows some predefined set of configurations that might be a little easier to understand, but that would be a small subset of what we're discussing above.
All you need is the ability to define your own data definitions. Which, of course, any remotely good tool would have.
I do not believe that ReadyBoost caches frequently used files because thats not the problem that it is solving. I believe that you are thinking of SuperFetch (which itself does cooperate with ReadyBoost.)
Well, it doesn't cache files because that would be silly. It caches blocks. The _result_ is the same as what the OP is after, which is that frequently accessed _data_ is cached on the higher-speed device.
ReadyBoost is an attempt to reduce latency by leveraging devices that have very fast seek times, such as USB thumb drives and SD cards.
Yes. Otherwise known as a cache.
These same devices often have *horrible* throughput.
But that's not really important, because if throughput is a limiting factor then you're looking at long, sequential reads or writes - which typically aren't cached by most caching algorithms anyway.
Also, a few MBs a second is pretty pitiful for any modern thumbdrive. A semi-decent drive should be able to hit 15-20MB/sec reads and ~10MB/sec writes.
The bad throughput means that they cannot be used to effectively cache frequently used files, but instead only small parts of files.
Yes, that's because that's where the biggest benefits are derived - small accesses where seek time dominates. If throughput is the limiting factor, you're almost always in a long sequential read, where the data is unlikely to be cached even in RAM.
The way DragonFly's swapcache works is that VM pages [...]
I don't think it's really fair to put forth swapcache as a general case, when it's specific to only a single OS.
I'm willing to be corrected, but I struggle to believe any OS is going to swap out buffer cache as a general rule when the use cases for that actually being beneficial are vanishingly small (and better solutions - like swapcache, ZFS's ZIL and L2ARC, or Windows ReadyBoost - exist).
What? Linux, Solaris, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and swap out buffered data from disc drives to cache before discarding it outright. If you don't believe me, go peruse their source code.
I'm not going to go crawling through source code, but I find it difficult to believe any OS is going to swap out buffer cache when the corner cases that could actually be useful are vanishingly small.
hey also tend (Italy most of all) to be fussy about splitting checks and are too bothered to do so, so they make you just give it to them in cash if you're eating out together.
This is a cultural thing. In fact, it's relatively unusual to split the bill American-style pretty much anywhere outside of the US. The assumption is that if a group of people are out together, they're well enough acquainted to sort the money out between themselves.
disclaimer: we weren't interested in spending 30 euros on meals, we wanted to spend 10 euros, so that's probably why service sucked. In contrast, there are a number of places I can go in America to eat for $10 and service is great.
Well, yeah, but that's just because food (along with just about everything else) is dramatically cheaper in the US. A freakin' Big Mac meal in, say, Switzerland or Frances costs nearly US$10.
There are also significant cultural differences between what classifies as "good service" in the US vs other countries.
Coins last for decades. Every other "rich" country uses coins for something so low in value as US$1. The UK has a £2 coin (US$3), the Eurozone has 2 (US$2.6), Australia has a AU$2 (US$1.9).
Much longer than that. The oldest coin I saw while I was living in Switzerland was minted in 1904, and apparently there are still coins from the late 1800s in circulation.
The Swiss also have a CHF 5.- (about US$4.50), and those suckers can build up - I found over CHF 50.- just in coins in my pocket on more than one occasion while I was living there.
Yeah I don't buy the 'but think of the machines!' argument against changing the design of the US currency. Dozens upon dozens of other developed countries have changed currencies in the last 20 years. Australia switched from paper 100/50/20/10/5/2/1 dollar bills to polymer 100/50/20/10/5 dollar bills and $1 and $2 coins during the 90s. I don't remember any problems occurring with vending machines etc.
Vending machines that take notes are relatively uncommon in Australia, however, because - like most European countries - we have coins that are actually worth enough to be useful. Coins in the US may nearly as well not exist, their denominations are so small.
Slashdot Mirror
Having known several U.S.-born foreigners, I'd say this isn't as uncommon as you'd think. It may be just a blip on the radar in the grand scheme of things, but there are definitely people who fall into this crack.
One of the main reasons people renounce US citizenship is because America, rather uniquely, likes to tax its citizens regardless of whether or not they are actually working and earning income in America.
(Similarly, and again somewhat uniquely, residents (from a taxation perspective, not an immigration one) have to pay tax on their worldwide income.)
Try selling that to the voters, though.
It's already been sold to voters - that's how the system works today.
The trick is convincing them of that. ;)
"Driving efficiencies by leveraging our core competencies while eliminating non value add activities in new game changing markets"
That makes my head hurt...
Translation: "Completing the important tasks quicker, without wasting time on irrelevant shit, so we can attract new customers".
Most of the evidence and speculation points to increased wear and tear but no mortal danger -- if that is the case, then Bronson is correct, the airlines should definitely decide whether to bear those costs or not.
Hindsight is always 20/20. Previous experiences with aircraft and ash clouds have typically not ended well, meaning - as already mentioned - the only sane choice is to err on the side of caution.
Now, had the airlines *already* done the testing to determine what was a safe level of ash in the air, before this happened, then they might have a leg to stand on with calls of "overreaction". However, as far as I know none of them have (and I'm willing to bet none of them do - at least until Government regulations spurred by recent even force them to).
Even if it turns out from new research that the danger was overestimated at the time, the airlines *still* won't have a reasonable claim, because no-one knew at the time.
Here's my earlier post on my real world experiences on the matter:
I don't believe your anecdote, to be frank.
Though as a matter of sheer curiosity I think I'll fire up a couple of VMs and compare encoding times next week.
Although the software app was different, the screen, keypad, card reader, receipt printer and money handling hardware were all the same, as was the data transfer and validation backend. Thus my assertion that the OS/2 units booted faster and were more responsive in operation doing the same job.
So, you ignore probably the single most significant component relating to interactive responsiveness ? Nice job.
Not necessarily. They might suffer damage but still be operable, and only require more maintenance. Or they might suffer damage and have to be replaced after landing.
Perhaps you missed the point I was making, that if the engines go from "operable" to "inoperable" while the plane is in the air, then that most certainly represents a "mortal" threat to the passengers.
That's the whole point. Nobody really knows.
In which case the only sane choice is to err on the side of safety.
The airlines are free to do their own research and find out exactly how much ash is dangerous - no-one is stopping them. The government is just stipulating they have to do it under controlled conditions when said testing is not endangering innocents.
If the engines are slowly destroyed by ash in the air, the danger posed is a financial one to the airline companies, not a mortal one to the passengers.
It is on the flight when the engines transition from "being destroyed" to "are destroyed".
Heh. OS/2 on 300MHz and 32Mb ram makes for a more responsive Automatic Teller Machine than the later 2GHz 512Mb burdened with XP. The rest of the whole ATM was identical so you know it was doing the same job.
The application was identical on both ? What was it written in ?
Also, it took 15 minutes to install, against the XP's 2-3 hours.
Well, that's just incompetence. There's no reason an automated install on known hardware shoudl take that long.
In addition, there are new companies that are using OS/2 for specialized apps or as servers that have gotten fed up with Windows, and find the various fragmented releases of Linux to be too daunting.
It's a struggle to understand why anyone would choose OS/2 over Windows or the two mainstream Linux distributions.
Unless, of course, they're being misled...
What compelling features for a new installation could OS/2 possibly have over Windows Server 2008, RHEL, or SuSe ?
I would hold the idiot who believed it, if he took any action against me. (say deny a job, credit, rental) responsible.
How would you know ?
Still not a reason not to optimize.
Actually it's an excellent reason not to optimise, because you'd be optimising for an uncommon case at the expense of a common one.
And CD is used in livecd environment A LOT, you see that even strange access patterns could use optimizing.
LiveCDs are not even remotely close to a common use case, which is why the vastly superior option is to manually optimise by using things like RAM drives.
So what you are thinking is that the OS cache intentionally purges high frequency data in favor of low frequency data, for a reason that arbitrary hurts performance.
No. Nearly the exact opposite, in fact - that the OS will favour smaller, more frequently accessed data over larger, less frequently accessed data.
Dumping most of your cache contents because someone decided to rip a 4GB DVD to an ISO (to use a fairly obvious example) is nearly always going to be a dumb idea.
"Even though I am fielding requests for that big block of data all the god damned time.. like every five seconds and shit... I'm going to go ahead and dump most of it as soon as the system asks for that random burst of rarely used data that is only read once per session at most"
That's not an access pattern even remotely typical of a large sequential read or write. Large sequential reads or writes to a given dataset are - relatively - uncommon events.
Oh yes they are. Don't make things up.
I can guarantee you the typical SAN will identify and (typically) not cache large sequential disk operations. If you want that sort of behaviour you need to tune for it. OS caching is a little different, but by its nature sequential data will typically be evicted quicker
It does it even on large sequential accesses, but only for up-to the first 512KB (yes, since I posted last I read the damn specifics. The white paper is available.)
Can you point me to this whitepaper ? I searched but couldn't find anything with technical details about how ReadyBoost is implemented.
Those new Intel CPUs use PCIe to connect to "southbridge". PCIe is designed to be explicitly backwards compatible across versions (yeah, there will be less bandwith to the "southbridge" available...irrelevant in nearly all scenarios).
How about adding more lanes than are in the original spec ?
Obviously the requirement doesn't exist if its something quite opposite is followed...the question is why Intel chooses so.
Because not doing so reduces costs ?
Based on their past actions, I have my doubts that what they they do is all around optimal.
What do you mean by "optimal" ? "Optimal" for whom ?
This is a good reason for suspecting "intentional obsolescence"...Intel has already done so quite a few times (no, don't limit yourself only to cpu sockets, if you really want to have vert clear examples...)
For example ?
And please, stop with portraying like it's a solid fact that there's no demand for greater (this all I'm talking about - greater, not absolute) upgradeability.
I'm not. I'm observing that it is a "solid fact" very few people upgrade systems at all, and even fewer are only interested in upgrading the CPU.
Even multiple components doesn't have to include so many major ones as you want to believe...
It's got nothing to do with what I believe, it's got to do with what I've been observing computer enthusiasts actually doing over the last 15 years. There is very little evidence to suggest a general desire across the PC market for greater upgradeability.
Look, seriously. The whole argument here is that there's a group of people in Intel who specifically set out with each new CPU design to make it incompatible with existing hardware, because by doing this they hope to squeeze more profits out of... the fraction of 1% of users who are interested in CPU upgrades. If that doesn't make you go "WTF ?" straight off the bat, then there's absolutely nothing I'm going to be able to say that convinces you otherwise.
There you can have a big win.
Not really. Access patterns to such devices tend to be a) infrequent and b) sequential.
Uh, right. That's why flow charts remain so popular.
Flow charts (and their descendants) are *massively* easier to understand and follow than something like pages of if...then statements. That's exactly why they _are_ popular.
Some things are better expressed in text; some in figures. A set of rules -- like those for a firewall -- are better expressed in text.
Why ? Which firewall's syntax are you going to express your rules in ? How long does it take for understanding of your ruleset to transfer to those unfamiliar with that syntax ? How do you delegate access and control of specific subsets of the rules ?
Your example is 100% backwards. Consider something simple like adding a host to a standard ACL list for webservers. Why should it be any harder than simply editing a plain text file?
Because editing text files is a manual and error-prone process. There's little to no input validation, sanity checking, or ability restrict access and delegate responsibilities. Just type it in, proofread, cross your fingers and go.
Why should it involve some meaningless symbolism of dragging one shape into another shape?
In what way are icons any less meaningless symbolism than configuration syntax keywords ?
How do I grep through these shapes?
You use the organisational and search constructs in the GUI.
How do I filter them into reports?
By using the reporting in the GUI.
How do I back up old configurations? How do I copy configuration from one system to another?
By exporting them to some machine-readable file.
Hmm, that's easier to read than
At a glance, absolutely. Primarily because if there are other associated ports that could go with the rule (eg: to 443) that can then be captured in the diagram but not the table. Similarly, if there are half a dozen rules, rather than just one, the graphical representation becomes even easier to understand, because the more lines of very similar text you add, the harder it becomes to pick out particular ones (and more importantly, identify errors in them). Additionally, your tabular representation contains information that is not relevant at the design/conceptual level (port numbers).
And, how do I know "(www)" means port 80? (It could be any port, www is irrelevant).
Because you've defined it elsewhere in the interface.
What if I was running sshd on 80? What then? What if I was really sneaky and multiplexed port 80 for web and sshd via some proxy client I wrote?
Then you define those things elsewhere as well. Once, so you don't need to keep repeating relatively unimportant information.
This is where the GUI paradigm being discussed breaks down when you're talking firewalls. Honestly - you cannot make a GUI easier to understand than tabular data regarding firewalls, since firewalls are inherently tabular data. Don't try to fit square pegs into round holes.
Of course you can. That graphical representations are easier and quicker to understand than raw numbers is something that's been known for centuries. Again, this is why we use graphs to help interpret data rather than starting at lines of numbers.
Having said that - you can create a GUI/management application that allows some predefined set of configurations that might be a little easier to understand, but that would be a small subset of what we're discussing above.
All you need is the ability to define your own data definitions. Which, of course, any remotely good tool would have.
I do not believe that ReadyBoost caches frequently used files because thats not the problem that it is solving. I believe that you are thinking of SuperFetch (which itself does cooperate with ReadyBoost.)
Well, it doesn't cache files because that would be silly. It caches blocks. The _result_ is the same as what the OP is after, which is that frequently accessed _data_ is cached on the higher-speed device.
ReadyBoost is an attempt to reduce latency by leveraging devices that have very fast seek times, such as USB thumb drives and SD cards.
Yes. Otherwise known as a cache.
These same devices often have *horrible* throughput.
But that's not really important, because if throughput is a limiting factor then you're looking at long, sequential reads or writes - which typically aren't cached by most caching algorithms anyway.
Also, a few MBs a second is pretty pitiful for any modern thumbdrive. A semi-decent drive should be able to hit 15-20MB/sec reads and ~10MB/sec writes.
The bad throughput means that they cannot be used to effectively cache frequently used files, but instead only small parts of files.
Yes, that's because that's where the biggest benefits are derived - small accesses where seek time dominates. If throughput is the limiting factor, you're almost always in a long sequential read, where the data is unlikely to be cached even in RAM.
The way DragonFly's swapcache works is that VM pages [...]
I don't think it's really fair to put forth swapcache as a general case, when it's specific to only a single OS.
I'm willing to be corrected, but I struggle to believe any OS is going to swap out buffer cache as a general rule when the use cases for that actually being beneficial are vanishingly small (and better solutions - like swapcache, ZFS's ZIL and L2ARC, or Windows ReadyBoost - exist).
What? Linux, Solaris, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD and swap out buffered data from disc drives to cache before discarding it outright. If you don't believe me, go peruse their source code.
I'm not going to go crawling through source code, but I find it difficult to believe any OS is going to swap out buffer cache when the corner cases that could actually be useful are vanishingly small.
hey also tend (Italy most of all) to be fussy about splitting checks and are too bothered to do so, so they make you just give it to them in cash if you're eating out together.
This is a cultural thing. In fact, it's relatively unusual to split the bill American-style pretty much anywhere outside of the US. The assumption is that if a group of people are out together, they're well enough acquainted to sort the money out between themselves.
disclaimer: we weren't interested in spending 30 euros on meals, we wanted to spend 10 euros, so that's probably why service sucked. In contrast, there are a number of places I can go in America to eat for $10 and service is great.
Well, yeah, but that's just because food (along with just about everything else) is dramatically cheaper in the US. A freakin' Big Mac meal in, say, Switzerland or Frances costs nearly US$10.
There are also significant cultural differences between what classifies as "good service" in the US vs other countries.
Coins last for decades. Every other "rich" country uses coins for something so low in value as US$1. The UK has a £2 coin (US$3), the Eurozone has 2 (US$2.6), Australia has a AU$2 (US$1.9).
Much longer than that. The oldest coin I saw while I was living in Switzerland was minted in 1904, and apparently there are still coins from the late 1800s in circulation.
The Swiss also have a CHF 5.- (about US$4.50), and those suckers can build up - I found over CHF 50.- just in coins in my pocket on more than one occasion while I was living there.
Yeah I don't buy the 'but think of the machines!' argument against changing the design of the US currency. Dozens upon dozens of other developed countries have changed currencies in the last 20 years. Australia switched from paper 100/50/20/10/5/2/1 dollar bills to polymer 100/50/20/10/5 dollar bills and $1 and $2 coins during the 90s. I don't remember any problems occurring with vending machines etc.
Vending machines that take notes are relatively uncommon in Australia, however, because - like most European countries - we have coins that are actually worth enough to be useful. Coins in the US may nearly as well not exist, their denominations are so small.