the subtle thing you're confusing, however, is that rm only would go into.. because it was explicitly specified on the command line, not because of recursion.
I think you're missing my point. Consider the following algorithm as an implementation of the -r switch:
get argument
is argument a directory?
if yes:
save inode of current directory
chdir into argument directory
start reading directory entries
if inode of this entry matches inode from 4.1, skip to 4.6
invoke 1 recursively, with entry as argument
more directory entries?
if yes, go to 4.4
chdir back to dir from 4.1
unlink or rmdir argument
more arguments?
if yes, go to 1
if no, exit
That might seem like a reasonable implementation. It will recursively descend into subdirectories and remove their contents, taking care not to walk back up to the calling parent. But if you happen to feed it.. as an explicit argument in step 1, it will eat the whole filesystem. Is that a bug? You bet! Did it ever happen that way? I have no idea. Is it plausible? I think it might be.
He types "killall find". He's very proud of himself...
Heh. The man page for killall(1) on Linux has the following remark in the "KNOWN BUGS" section. Quite possiblly the biggest understatement of all time:
Be warned that typing "killall name" may not have the desired effect on non-Linux systems, especially when done by a privileged user.
We were opening the new building for our plant expansion at the factory company. Construction wasn't finished yet, but it was mostly done. They were just doing things like painting and wiring and fixtures and equipment and stuff like that. So we had this big ceremony in the new loading dock, sort of an open house. Whole company is there, along with some suits from our biggest customer. We've got a PA and a projector going as they run a video of fighter planes (which used some of our product). The Big Boss thinks, hey, it would look a lot better without the overhead lights being on and washing out the projected image. So he sends one of the maintenance guys over to the breaker panel to shut off the lights.
Everything goes dead. No PA, no projector. Oops.
Since it was a construction site, and they hadn't finished the permanent wiring yet, everything - including the one outlet that had power - was running off one breaker. The best part was waiting for the digital projector to cool itself off enough that it would turn the bulb back on after power was restored.
Seems to me that at most, that would get rid of/home, not your entire system, unless it's all the hidden files in/root. It doesn't seem to happen anymore though, but I'm not inclined to do a live test.
Suppose that, in some implementations of rm -r, the code checked to make sure the directory recursion function didn't walk back up to the directory it was called from. Seems good, right? But in this case,/ is not the directory the "recurse into/home" part was called from - it was called from "/home/foo". So it could walk up a directory tree to the root directory, and then back down to the rest of the system. I don't know if this explanation is true, but it sounds plausible to me.
For those wondering about what we're talking about: The shell expands
rm -rf.*
to something like
rm -rf ....profile.pinerc.wgetrc
or whatever. Notice the "-r" in there. What that does is tell rm that, if it encounters a directory, to recursively chdir to that directory and process the contents of said directory. Notice the ".." in there. That's the parent directory. So go into the parent directory. Which also contains a ".." entry. Lather, rinse, repeat.
From the summary: "If whatever we do can be held... they can easily be combined into a composite picture of ourselves."
Oh my $DEITY. We wouldn't want people to actually be able to know something more than what anyone lets on at the moment./SARCASM
Here's a thought: Maybe it's not a bad thing to be able to be able to look at a person's history. If someone cannot consistently keep a cool head in public, that's valid information. If they once espoused a certain opinion, and have since changed their mind, that's valid, too. If they deny they stated something, rather than simply saying they've changed their mind, that's valid, too. People can change, opinions can change, one statement does not make a person what they are.
The real issue is that people are too quick to judge based on incomplete information. Computers make that flawed process easier, just like they make so many other things easier.
I've been using this command-line since 1988, back when it was NDOS.COM, and was much better than COMMAND.COM.
Actually, it was always 4DOS. Norton licensed the code from Rex Conn/JP Soft, tweaked it a bit, and called it NDOS.
4DOS rocked. I used to be a 4DOS junkie. There are still some things it did that I miss in 'nix today. I'd love to be able to license 4NT for work today, but sadly, the price isn't worth the benefit. Besides, these days I spend half my time in 'nix anyway...:)
My biggest complaint about PowerShell is that I don't dare adopt it. I've still got a few Windows 2000 PCs kicking around at work (as machine controllers, so upgrades are a real bear), and PowerShell already doesn't support Win 2000. And it looks like the next major release won't support XP. Microsoft will use this as a tool to drive upgrades, just like they do with everything else.
This really annoys me, too, because it looks like PowerShell might do some legitimately interesting things.:-(
First, it misleads users who expect some degree of data security.
So does data journaling or file versioning or automatic bad sector relocation (okay, that last one isn't part of the kernel, but it still effects things). Point being, it isn't 1985 anymore. You don't counter data remanence by disk wipes anymore.
The second argument is that it's better handled in user space...
I disagree with that assessment. That's the way Windoze does things, and it sucks. The problem is that any old program can and usually does just delete files. You have to have the whole world agree to rewrite their software to your undelete API, and that's just not going to happen in reality.
I suppose you could implement a shim in the userspace library implementation of the unlink() system call, but there are also efficiency reasons to implement undelete in the filesystem itself. As others have said, I pine for functionality like as found in Novell NetWare, which handled this efficiently and easily. SALVAGE saved me a lot of time restoring user files from tape, and it was doing so in 1993.
...so the OS doesn't have to make that sort of policy
"Mechanism, not policy." I'm not asking for the kernel to mandate undelete, just provide the mechanism for me to turn it on, should I so wish.
The final argument I can come up with is security problems. We can't have one global.Trash bin in a multiuser system. And quotas. And permissions.
All the more reason to implement it in the kernel, in the filesystem, and not just as bogus.Trash directory somewhere.
NetWare simply didn't count deleted files in quotas. They were purged on a LRU basis automatically, as needed, so this wasn't a problem.
Permissions were the same as anything else. If you had permission to deleted the file, you had permission to undelete it. In *nix land, this would be write permission on the containing directory.
I think we may be near a point where we agree to disagree.
I respect you for having the ability to say that. A lot of people just assume anyone that doesn't think the way they do just needs to be yelled at louder.
What's the point of the government taxing its people if it is law that we must accept the money for all debts and they have the ability to make as much of it as they wish?
If they print more money, the dollar gets devalued overall. Cash reserves everywhere -- including the government's own -- would become weaker, because one then needs more dollars per unit of anything else (commodities, goods, services, whatever). By sustaining the value of the US dollar as currency, the viability of the nation's economy is sustained, and thus the nation itself is sustained. By taking taxes in the form of US dollars we have, rather than just printing more currency, we thus protect the nation.
The point of taxation is not to decrease the wealth of the citizenry. The point is to cover the real-world costs of government operations. Goods such as food, building materials, fuel, and so on have irrefutable costs. Labor has to come from somewhere. Under some government systems, goods are simply transferred directly to the control of the government ("seized", as Mr. Rothbard puts it), and labor is in form of conscripted citizens and/or slaves (arguably just a semantic distinction anyway).
In the US, we instead pay taxes. (This paragraph describes how it should work in ideal theory; see following paragraph to get back to reality.) We work to produce good and provide services, which we trade for units of currency. We can trade currency with others to obtain our own goods and services. A certain portion of that currency is transferred to the control of the government, in the form of taxes. The government then trades that currency for goods and services, same as we do. Government operations are done to benefit the citizenry, so for wholly domestic affairs, the citizenry as a whole is no poorer. Certain individuals will be, but not the total sum. And, of course, international operations may result in decreasing the wealth of the country.
Again, the above assumes a theoretical ideal. It is far from reality. Even under a perfect government, different people are going to have different ideas about what benefits the citizenry as as whole, how much wealth should be redistributed, and so on. And of course our government is *far* from perfect. Even with the best of intentions, mistakes and bad decisions will be made. Worse, there is abuse of power and trust, which I suspect is rather more the norm than the exception these days. There are those who strive to benefit only some of the citizenry, rather than the whole. It may be their own petty interests, or it may be their "district" or "state" -- so many in Congress assume that their responsibility is to their constituents alone, rather than to the nation. I'm not sure which is worse - at least the first kind of greed is simple, easily recognized, and generally decried by others.
...the increasing money supply for the dollar is very bad...
Doesn't that assume the production of the nation's economy as a whole is constant?
For example, let's go back to chickens and chicken tokens. Let's say a nation can raise 100 chickens a year (it's a very small country). So 100 chicken tokens per year. But then someone creates a radical new chicken breed, and now the country can produce 200 chickens a year. Does that decrease the value of a chicken token? In one way, no, of course not. A chicken token is still worth one chicken. But in another way, it does decrease the value of a chicken token, because now chickens are worth less (greater supply means the value of any individual chicken is reduced).
Now, instead say they're not using chicken tokens, but tokens which represent an abstract concept of value. Sam
Read What Has Government Done to Our Money? and get back to me.
Okay, I skimmed though that nice little work of ideology.
If you're expecting that to prove some point to me, well, you failed. The work as a whole appears to proceed from a number of assumptions I consider invalid. I particularly liked "Governments need only find some method of expropriating more goods without the owner's consent" in reference to taxes. In my world-view, it's a fundamental that government is always done with consent, either explicit or implicit. As the saying goes, you cannot enslave a Free Man; you can only kill him. Likewise, by definition, a community is a group of people who agree to live by a set of rules. I do not divide the world into "the government" and "everybody else". If your arguments are centered around the kind of premise, well, I'm afraid we'll have to start from fundamentals.
Even looking at M3 vs. GDP, you can probably guess that M3 is now highest ever. Huge amount of money injected into economy to stimulate it.
My understanding of the technical side of this stuff is pretty minimal. But, according to all the links you've sent so far, M3 is not about hard currency. M3 is things like large CDs, foreign deposits, Treasury securities, and so on. M3 is money locked up tight and hard to get at -- about as far from currency as you can get. So I'm not really sure what you're trying to prove by going on about "Government *prints* money" while pointing at M3 being higher. Maybe I'm mis-understanding the terminology.
If you're just trying to say that going deeper and deeper into debt is bad, well, no argument there. Be it the national debt (gee, we, the American people, each of us owe $30K on that, great) or the trade deficit (even better, money (perceived value) pouring out of this country into other countries), debt is basically economic weakness. You don't need a degree in economics to know that spending money you don't have is bad fiscal policy.
Taxes are a hold-over from when money was a commodity instead of faith.
That's the fatal flaw in your reasoning. Taxes pay for all the stuff the government does (well, taxes and loans). The reason we still have to collect taxes is that "stuff" still uses resources - people, oil, building materials, etc. - and those resources need to be paid for. The government pays for them in dollars. When I buy gas, I also pay in dollars. We've all agreed the dollar has value.
The value can change, yes. So can the value of a barrel of oil, a gallon of milk, or a troy oz of gold.
It's certainly true that printing money without regard to other factors will cause severe inflation. As a US citizen, I do hope the conspiracy nuts are wrong and that our government isn't printing money with wild abandon, because that will certainly lead to the destruction of the US dollar as a viable currency. Fortunately, conspiracy nuts usually are just conspiracy nuts.
Regardless, money supply is increasing now faster than before. How? Gov't is printing money.
Source?
So it should be clear that money just represents a perceived value, not a real value.
Value is always perceived. Take chickens and cows. Maybe we say a cow is worth ten chickens. Cool. But what happens if, say, people start valuing cows less (maybe because of all that "Mad Cow Disease" stuff in the news). Demand for cows drops somewhat; at the same time, demand for chicken increases. Maybe now I can only get nine chickens for a cow down at the local market. If we're using tokens, that would mean I can only get nine chicken tokens for one cow token.
Same concept applies if you're using a gold standard. Say we switch to the gold standard again, and one dollar is decreed to be worth 0.0014 troy oz of gold (which is about what it is worth today), and we get all that gold together and put it in a safe. Let's also say that for one dollar, I can get one chicken. So, one dollar = one chicken = 0.0014 troy oz gold.
Now say someone invents a way to turn stone into gold (the alchemist's dream). (Or, if you prefer, maybe a giant asteroid made of pure gold fragments and then the fragments hit the Earth, causing gold to start raining from the sky. Whatever reason you like -- this is an example, not a financial plan.) Now gold is everywhere. The price - the perceived value - of gold will plummet. Now, I get like a pound of gold for a chicken, because raising chickens is a pain in the ass, but gold is everywhere. Still the same gold molecules, still the same chickens, but now gold has less value.
The fundamental concept behind modern money is that the value represented by a dollar (or whatever) does not need to be pinned to a particular physical good, because the value we ascribe to something is arbitrary anyway. So we all agree instead that a dollar represents an abstract concept of value. That concept changes, of course, just like the value we assign to cows or chickens or gold changes.
Except in your example, the government can create chickens out of thin air and you can't. Your ideas are only true if the US has a chicken for each dollar it creates, but that hasn't been the case for a long time.
Since you apparently missed it the first time, let me repeat:
But it quickly became obvious that, hey, all I really care about is the value represented by the token. I don't care about the chicken (maybe I prefer beef anyway). So let's all just agree to say the token represents an abstract concept of value.
So, bzzzt, wrong, but thanks for playing. We have a lovely consolation prize: A year's supply of Tyson chicken!
You are just supporting the perceived value of paper and ink that has no intrinsic value in and of itself.
Every word you wrote is absolutely true. From an economic theory standpoint, it's really quite a critical concept. As a philosophical statement, that was really quite deep and insightful (seriously). However, from a strictly pragmatic point-of-view, that is absolutely worthless.
Money is an abstraction which exists for convenience. It saves us from having to carry chickens to the gas station. Rather than being carrying chickens around, we say, here's an abstraction which we'll all agree to deal in. It's a lot easier and less messy than carrying chickens around. The first step was using tokens to represent chickens. Rather than carrying the chicken, we carried a token that represented a chicken. But it quickly became obvious that, hey, all I really care about is the value represented by the token. I don't care about the chicken (maybe I prefer beef anyway). So let's all just agree to say the token represents an abstract concept of value. Saves the trouble of keeping all those chickens around.
It's true that paying taxes "supports the perceived value" of the currency. So does any use of the currency. When I pay for my gas or Internet in US dollars rather than chickens, I'm supporting the currency. When I get paid in US dollars, I'm supporting the currency. When I browse Slashdot and look at the ends, that translates into resources used, which are paid for in US dollars, which supports the currency.
If you prefer, substitute some other tangible good, such as "cows", "cheese", or even "gold" for "chickens". It's all the same concept.
What's that?? *SIX* whole dimensions? Why, when I was starting out, we only had three dimensions, and we liked it that way. Length, width, and height were good enough for us, and they should be good enough for anyone. Why, we sometimes had to work in just *two* dimensions -- *and they were both length*! You didn't hear *us* complaining about relativity or quantum effects. If it can't be expressed in a Newtonian physics, it shouldn't be expressed at all, that's what we said. Pretty soon you'll be inventing time travel and creating causality paradoxes and tearing apart the entire space-time continuum, and *then* where will we be, I ask ya? You young scientists these days, why, you have no idea what proper respect is.
My main point stands that Vista (32-bit) does include NTVDM and does run DOS/Win16 apps...
I'm sorry, when you stated that "With the 64-bit OSes... Microsoft has CHOSEN to omit ntvdm.exe. They see the move to a 64-bit OS as an opportunity to weed out certain legacy support.", it seemed like you were saying something else entirely. My apologies for the misunderstanding.
the OP claimed that this wasn't so.
You're right in that I should have qualified my statement "Vista does not support running such code" as "64-bit Vista". I was assuming that from the context of the quote I provided and the thread, but I see now it could be misinterpreted.
No, it's not a hardware limitation, it's a "software thing". Windows NT, 2000, XP, and Vista do NOT execute 16-bit code in the hardware!
I'm sorry, but that's just plain wrong. In order to execute 16-bit code, Win32 puts the i386 processor into virtual 8086 mode, which provides some virtualized hardware support. It's only available when the CPU is already running in protected mode. V86 is not a full native virtualization (i.e., it doesn't provide i386 on i386 virtualization), but it's enough to provide a virtual environment to run 16-bit code. This has to be done because most 16-bit code violates the requirements needed to execute under the i386 protected mode model.
Virtual 8086 mode is not supported under long mode ("64-bit mode"), so it just isn't possible with a native 64-bit OS. You need a 32-bit OS running in i386 protected mode to get V86 mode.
Please have some idea of what you're talking about before posting.
The summary stated, "x64 Vista versions don't support legacy 16-bit code". That means Win 3.x or MS-DOS era stuff (of which there is still a depressingly large amount in use). The summary is correct in that Vista does not support running such code. But the summary is misleading in that the reason Vista doesn't support it is that nothing supports it: When in "long mode" (64-bit mode), x86-64 processors cannot execute 16-bit code. It's a hardware limitation, not a software thing.
Kernel mode also uses a 32-bit virtual address space, but often drivers have to work with physical addresses.
Ahhhh. I see, now. Even though the driver is limited to 32 bits for most things, it may still be given a 36-bit physical memory address when PAE is being used. That makes sense. Thanks for the explanation.
I think Dell knew this was coming. A few months ago, before Vista was hit general availability, we started getting a new addendum sheet in the literature kits which come with our new Dell PCs at work. It basically was a full page legal disclaimer about how the "Windows Vista Capable" sticker didn't really mean squat. This was one of those sheets they run off and stuff in the kit because they need to add an Important Note in a hurry. If think of how many PCs Dell ships, adding something like that is no small task. So I'm guessing someone somewhere complained loudly, and a Legal Department thought the complaint was legitimate enough to issue a disclaimer.
The question is: Was it Dell's Legal Department that thought it was legitimate, or Microsoft's? That is, did Microsoft issue a warning to all their big OEM customers that these "Vista Capable" stickers were a recipe for trouble?
Inquiring, tin-foil-hat-wearing minds want to know.
Hmmm, good link, thanks. Seriously, that's something I was not aware of, and I will likely encounter that limit sooner rather than later.
But at least one of us is confused (certainly me, maybe both of us).
In your post, you stated, "XP SP2 introduced a change such that only the bottom 32 bits of physical memory will ever be used, even if that means wasting memory." MSKB 929605, which you kindly linked to, states, "32-bit versions of Windows Vista limit the total available memory to 3.12 GB.". 3.12 GB is less than 32 bits worth of address space (4 GB), but more than 31 bits (2 GB). So it's not a 64-bit vs 32-bit thing. It's not even a 32-bit vs 31-bit thing. It's a something-else thing. Interesting. Stupid, but interesting.:)
Also, my understanding is that 32-bit Windows never uses anything more than a 32-bit virtual address space. Thus, 32-bit drivers will never see a 64-bit address. According to the article, it would appear many drivers cannot even handle a 32-bit address space.
Slashdot Mirror
Chris Burke (6130): "...oh wait, I'm number 5..."
I thought you were number 6130?
-- Number 21256
Given the lead-in to the article, wouldn't "How could they cut the power, man? They're animals!" be more appropriate?
I think you're missing my point. Consider the following algorithm as an implementation of the -r switch:
That might seem like a reasonable implementation. It will recursively descend into subdirectories and remove their contents, taking care not to walk back up to the calling parent. But if you happen to feed it .. as an explicit argument in step 1, it will eat the whole filesystem. Is that a bug? You bet! Did it ever happen that way? I have no idea. Is it plausible? I think it might be.
Heh. The man page for killall(1) on Linux has the following remark in the "KNOWN BUGS" section. Quite possiblly the biggest understatement of all time:
We were opening the new building for our plant expansion at the factory company. Construction wasn't finished yet, but it was mostly done. They were just doing things like painting and wiring and fixtures and equipment and stuff like that. So we had this big ceremony in the new loading dock, sort of an open house. Whole company is there, along with some suits from our biggest customer. We've got a PA and a projector going as they run a video of fighter planes (which used some of our product). The Big Boss thinks, hey, it would look a lot better without the overhead lights being on and washing out the projected image. So he sends one of the maintenance guys over to the breaker panel to shut off the lights.
Everything goes dead. No PA, no projector. Oops.
Since it was a construction site, and they hadn't finished the permanent wiring yet, everything - including the one outlet that had power - was running off one breaker. The best part was waiting for the digital projector to cool itself off enough that it would turn the bulb back on after power was restored.
Suppose that, in some implementations of rm -r, the code checked to make sure the directory recursion function didn't walk back up to the directory it was called from. Seems good, right? But in this case, / is not the directory the "recurse into /home" part was called from - it was called from "/home/foo". So it could walk up a directory tree to the root directory, and then back down to the rest of the system. I don't know if this explanation is true, but it sounds plausible to me.
For those wondering about what we're talking about: The shell expands
to something like or whatever. Notice the "-r" in there. What that does is tell rm that, if it encounters a directory, to recursively chdir to that directory and process the contents of said directory. Notice the ".." in there. That's the parent directory. So go into the parent directory. Which also contains a ".." entry. Lather, rinse, repeat.From the summary: "If whatever we do can be held ... they can easily be combined into a composite picture of ourselves."
/SARCASM
Oh my $DEITY. We wouldn't want people to actually be able to know something more than what anyone lets on at the moment.
Here's a thought: Maybe it's not a bad thing to be able to be able to look at a person's history. If someone cannot consistently keep a cool head in public, that's valid information. If they once espoused a certain opinion, and have since changed their mind, that's valid, too. If they deny they stated something, rather than simply saying they've changed their mind, that's valid, too. People can change, opinions can change, one statement does not make a person what they are.
The real issue is that people are too quick to judge based on incomplete information. Computers make that flawed process easier, just like they make so many other things easier.
"There are seldom good technological solutions to behavioral problems." -- Ed Crowley
Actually, it was always 4DOS. Norton licensed the code from Rex Conn/JP Soft, tweaked it a bit, and called it NDOS.
4DOS rocked. I used to be a 4DOS junkie. There are still some things it did that I miss in 'nix today. I'd love to be able to license 4NT for work today, but sadly, the price isn't worth the benefit. Besides, these days I spend half my time in 'nix anyway...
My biggest complaint about PowerShell is that I don't dare adopt it. I've still got a few Windows 2000 PCs kicking around at work (as machine controllers, so upgrades are a real bear), and PowerShell already doesn't support Win 2000. And it looks like the next major release won't support XP. Microsoft will use this as a tool to drive upgrades, just like they do with everything else.
:-(
This really annoys me, too, because it looks like PowerShell might do some legitimately interesting things.
Sometimes, Microsoft is their own worse enemy.
So does data journaling or file versioning or automatic bad sector relocation (okay, that last one isn't part of the kernel, but it still effects things). Point being, it isn't 1985 anymore. You don't counter data remanence by disk wipes anymore.
I disagree with that assessment. That's the way Windoze does things, and it sucks. The problem is that any old program can and usually does just delete files. You have to have the whole world agree to rewrite their software to your undelete API, and that's just not going to happen in reality.
I suppose you could implement a shim in the userspace library implementation of the unlink() system call, but there are also efficiency reasons to implement undelete in the filesystem itself. As others have said, I pine for functionality like as found in Novell NetWare, which handled this efficiently and easily. SALVAGE saved me a lot of time restoring user files from tape, and it was doing so in 1993.
"Mechanism, not policy." I'm not asking for the kernel to mandate undelete, just provide the mechanism for me to turn it on, should I so wish.
All the more reason to implement it in the kernel, in the filesystem, and not just as bogus .Trash directory somewhere.
NetWare simply didn't count deleted files in quotas. They were purged on a LRU basis automatically, as needed, so this wasn't a problem.
Permissions were the same as anything else. If you had permission to deleted the file, you had permission to undelete it. In *nix land, this would be write permission on the containing directory.
I respect you for having the ability to say that. A lot of people just assume anyone that doesn't think the way they do just needs to be yelled at louder.
If they print more money, the dollar gets devalued overall. Cash reserves everywhere -- including the government's own -- would become weaker, because one then needs more dollars per unit of anything else (commodities, goods, services, whatever). By sustaining the value of the US dollar as currency, the viability of the nation's economy is sustained, and thus the nation itself is sustained. By taking taxes in the form of US dollars we have, rather than just printing more currency, we thus protect the nation.
The point of taxation is not to decrease the wealth of the citizenry. The point is to cover the real-world costs of government operations. Goods such as food, building materials, fuel, and so on have irrefutable costs. Labor has to come from somewhere. Under some government systems, goods are simply transferred directly to the control of the government ("seized", as Mr. Rothbard puts it), and labor is in form of conscripted citizens and/or slaves (arguably just a semantic distinction anyway).
In the US, we instead pay taxes. (This paragraph describes how it should work in ideal theory; see following paragraph to get back to reality.) We work to produce good and provide services, which we trade for units of currency. We can trade currency with others to obtain our own goods and services. A certain portion of that currency is transferred to the control of the government, in the form of taxes. The government then trades that currency for goods and services, same as we do. Government operations are done to benefit the citizenry, so for wholly domestic affairs, the citizenry as a whole is no poorer. Certain individuals will be, but not the total sum. And, of course, international operations may result in decreasing the wealth of the country.
Again, the above assumes a theoretical ideal. It is far from reality. Even under a perfect government, different people are going to have different ideas about what benefits the citizenry as as whole, how much wealth should be redistributed, and so on. And of course our government is *far* from perfect. Even with the best of intentions, mistakes and bad decisions will be made. Worse, there is abuse of power and trust, which I suspect is rather more the norm than the exception these days. There are those who strive to benefit only some of the citizenry, rather than the whole. It may be their own petty interests, or it may be their "district" or "state" -- so many in Congress assume that their responsibility is to their constituents alone, rather than to the nation. I'm not sure which is worse - at least the first kind of greed is simple, easily recognized, and generally decried by others.
Doesn't that assume the production of the nation's economy as a whole is constant?
For example, let's go back to chickens and chicken tokens. Let's say a nation can raise 100 chickens a year (it's a very small country). So 100 chicken tokens per year. But then someone creates a radical new chicken breed, and now the country can produce 200 chickens a year. Does that decrease the value of a chicken token? In one way, no, of course not. A chicken token is still worth one chicken. But in another way, it does decrease the value of a chicken token, because now chickens are worth less (greater supply means the value of any individual chicken is reduced).
Now, instead say they're not using chicken tokens, but tokens which represent an abstract concept of value. Sam
Okay, I skimmed though that nice little work of ideology.
If you're expecting that to prove some point to me, well, you failed. The work as a whole appears to proceed from a number of assumptions I consider invalid. I particularly liked "Governments need only find some method of expropriating more goods without the owner's consent" in reference to taxes. In my world-view, it's a fundamental that government is always done with consent, either explicit or implicit. As the saying goes, you cannot enslave a Free Man; you can only kill him. Likewise, by definition, a community is a group of people who agree to live by a set of rules. I do not divide the world into "the government" and "everybody else". If your arguments are centered around the kind of premise, well, I'm afraid we'll have to start from fundamentals.
So, I've gotten back to you. What next?
My understanding of the technical side of this stuff is pretty minimal. But, according to all the links you've sent so far, M3 is not about hard currency. M3 is things like large CDs, foreign deposits, Treasury securities, and so on. M3 is money locked up tight and hard to get at -- about as far from currency as you can get. So I'm not really sure what you're trying to prove by going on about "Government *prints* money" while pointing at M3 being higher. Maybe I'm mis-understanding the terminology.
If you're just trying to say that going deeper and deeper into debt is bad, well, no argument there. Be it the national debt (gee, we, the American people, each of us owe $30K on that, great) or the trade deficit (even better, money (perceived value) pouring out of this country into other countries), debt is basically economic weakness. You don't need a degree in economics to know that spending money you don't have is bad fiscal policy.
That's the fatal flaw in your reasoning. Taxes pay for all the stuff the government does (well, taxes and loans). The reason we still have to collect taxes is that "stuff" still uses resources - people, oil, building materials, etc. - and those resources need to be paid for. The government pays for them in dollars. When I buy gas, I also pay in dollars. We've all agreed the dollar has value.
The value can change, yes. So can the value of a barrel of oil, a gallon of milk, or a troy oz of gold.
It's certainly true that printing money without regard to other factors will cause severe inflation. As a US citizen, I do hope the conspiracy nuts are wrong and that our government isn't printing money with wild abandon, because that will certainly lead to the destruction of the US dollar as a viable currency. Fortunately, conspiracy nuts usually are just conspiracy nuts.
Source?
Value is always perceived. Take chickens and cows. Maybe we say a cow is worth ten chickens. Cool. But what happens if, say, people start valuing cows less (maybe because of all that "Mad Cow Disease" stuff in the news). Demand for cows drops somewhat; at the same time, demand for chicken increases. Maybe now I can only get nine chickens for a cow down at the local market. If we're using tokens, that would mean I can only get nine chicken tokens for one cow token.
Same concept applies if you're using a gold standard. Say we switch to the gold standard again, and one dollar is decreed to be worth 0.0014 troy oz of gold (which is about what it is worth today), and we get all that gold together and put it in a safe. Let's also say that for one dollar, I can get one chicken. So, one dollar = one chicken = 0.0014 troy oz gold.
Now say someone invents a way to turn stone into gold (the alchemist's dream). (Or, if you prefer, maybe a giant asteroid made of pure gold fragments and then the fragments hit the Earth, causing gold to start raining from the sky. Whatever reason you like -- this is an example, not a financial plan.) Now gold is everywhere. The price - the perceived value - of gold will plummet. Now, I get like a pound of gold for a chicken, because raising chickens is a pain in the ass, but gold is everywhere. Still the same gold molecules, still the same chickens, but now gold has less value.
The fundamental concept behind modern money is that the value represented by a dollar (or whatever) does not need to be pinned to a particular physical good, because the value we ascribe to something is arbitrary anyway. So we all agree instead that a dollar represents an abstract concept of value. That concept changes, of course, just like the value we assign to cows or chickens or gold changes.
See how it works, now?
Since you apparently missed it the first time, let me repeat:
But it quickly became obvious that, hey, all I really care about is the value represented by the token. I don't care about the chicken (maybe I prefer beef anyway). So let's all just agree to say the token represents an abstract concept of value.
So, bzzzt, wrong, but thanks for playing. We have a lovely consolation prize: A year's supply of Tyson chicken!
Every word you wrote is absolutely true. From an economic theory standpoint, it's really quite a critical concept. As a philosophical statement, that was really quite deep and insightful (seriously). However, from a strictly pragmatic point-of-view, that is absolutely worthless.
Money is an abstraction which exists for convenience. It saves us from having to carry chickens to the gas station. Rather than being carrying chickens around, we say, here's an abstraction which we'll all agree to deal in. It's a lot easier and less messy than carrying chickens around. The first step was using tokens to represent chickens. Rather than carrying the chicken, we carried a token that represented a chicken. But it quickly became obvious that, hey, all I really care about is the value represented by the token. I don't care about the chicken (maybe I prefer beef anyway). So let's all just agree to say the token represents an abstract concept of value. Saves the trouble of keeping all those chickens around.
It's true that paying taxes "supports the perceived value" of the currency. So does any use of the currency. When I pay for my gas or Internet in US dollars rather than chickens, I'm supporting the currency. When I get paid in US dollars, I'm supporting the currency. When I browse Slashdot and look at the ends, that translates into resources used, which are paid for in US dollars, which supports the currency.
If you prefer, substitute some other tangible good, such as "cows", "cheese", or even "gold" for "chickens". It's all the same concept.
What's that?? *SIX* whole dimensions? Why, when I was starting out, we only had three dimensions, and we liked it that way. Length, width, and height were good enough for us, and they should be good enough for anyone. Why, we sometimes had to work in just *two* dimensions -- *and they were both length*! You didn't hear *us* complaining about relativity or quantum effects. If it can't be expressed in a Newtonian physics, it shouldn't be expressed at all, that's what we said. Pretty soon you'll be inventing time travel and creating causality paradoxes and tearing apart the entire space-time continuum, and *then* where will we be, I ask ya? You young scientists these days, why, you have no idea what proper respect is.
And get off my lawn!
I'm sorry, when you stated that "With the 64-bit OSes ... Microsoft has CHOSEN to omit ntvdm.exe. They see the move to a 64-bit OS as an opportunity to weed out certain legacy support.", it seemed like you were saying something else entirely. My apologies for the misunderstanding.
You're right in that I should have qualified my statement "Vista does not support running such code" as "64-bit Vista". I was assuming that from the context of the quote I provided and the thread, but I see now it could be misinterpreted.
I'm sorry, but that's just plain wrong. In order to execute 16-bit code, Win32 puts the i386 processor into virtual 8086 mode, which provides some virtualized hardware support. It's only available when the CPU is already running in protected mode. V86 is not a full native virtualization (i.e., it doesn't provide i386 on i386 virtualization), but it's enough to provide a virtual environment to run 16-bit code. This has to be done because most 16-bit code violates the requirements needed to execute under the i386 protected mode model.
Virtual 8086 mode is not supported under long mode ("64-bit mode"), so it just isn't possible with a native 64-bit OS. You need a 32-bit OS running in i386 protected mode to get V86 mode.
Please have some idea of what you're talking about before posting.
References:
Intel 80386 Reference Programmer's Manual
Chapter 15 - Virtual 8086 Mode
http://pdos.csail.mit.edu/6.828/2006/readings/i38
Virtual 8086 Mode
by Tim Robinson
http://osdev.berlios.de/v86.html
An Introduction to 64-bit Computing and x86-64
by Jon "Hannibal" Stokes for ArsTechnica
http://arstechnica.com/cpu/03q1/x86-64/x86-64-4.h
http://foldoc.org/index.cgi?virtual+86+mode
The summary stated, "x64 Vista versions don't support legacy 16-bit code". That means Win 3.x or MS-DOS era stuff (of which there is still a depressingly large amount in use). The summary is correct in that Vista does not support running such code. But the summary is misleading in that the reason Vista doesn't support it is that nothing supports it: When in "long mode" (64-bit mode), x86-64 processors cannot execute 16-bit code. It's a hardware limitation, not a software thing.
Ahhhh. I see, now. Even though the driver is limited to 32 bits for most things, it may still be given a 36-bit physical memory address when PAE is being used. That makes sense. Thanks for the explanation.
I think Dell knew this was coming. A few months ago, before Vista was hit general availability, we started getting a new addendum sheet in the literature kits which come with our new Dell PCs at work. It basically was a full page legal disclaimer about how the "Windows Vista Capable" sticker didn't really mean squat. This was one of those sheets they run off and stuff in the kit because they need to add an Important Note in a hurry. If think of how many PCs Dell ships, adding something like that is no small task. So I'm guessing someone somewhere complained loudly, and a Legal Department thought the complaint was legitimate enough to issue a disclaimer.
The question is: Was it Dell's Legal Department that thought it was legitimate, or Microsoft's? That is, did Microsoft issue a warning to all their big OEM customers that these "Vista Capable" stickers were a recipe for trouble?
Inquiring, tin-foil-hat-wearing minds want to know.
Hmmm, good link, thanks. Seriously, that's something I was not aware of, and I will likely encounter that limit sooner rather than later.
:)
But at least one of us is confused (certainly me, maybe both of us).
In your post, you stated, "XP SP2 introduced a change such that only the bottom 32 bits of physical memory will ever be used, even if that means wasting memory." MSKB 929605, which you kindly linked to, states, "32-bit versions of Windows Vista limit the total available memory to 3.12 GB.". 3.12 GB is less than 32 bits worth of address space (4 GB), but more than 31 bits (2 GB). So it's not a 64-bit vs 32-bit thing. It's not even a 32-bit vs 31-bit thing. It's a something-else thing. Interesting. Stupid, but interesting.
Also, my understanding is that 32-bit Windows never uses anything more than a 32-bit virtual address space. Thus, 32-bit drivers will never see a 64-bit address. According to the article, it would appear many drivers cannot even handle a 32-bit address space.
Cheers,