Electricity wise that's just plain not efficient. There was a story posted here a while back about how Hollywood studios were having the same issue.
As I wrote, it depends on the application.
Anything with larges amounts of quiescent (unchanging) data that does not to be online is going to lose big-time. Most movie footage is going to fall into that category; it never changes once shot, and most of it is rarely looked at after post-production finishes. They only keep it around for posterity and "Special Edition" edits.
But take somebody like The Wayback Machine. What I described is more-or-less how they manage their storage. (Or was, when I read about it a year or three ago.) The whole archive needs to be online at all times anyway, so it's a win for them.
A 500 GB HDD costs less than a single one of these discs, is reliable, rewritable a million times, lasts decades if properly stored, is already available, is faster, and requires no fancy hardware.
I'm curious as to on what you base your statement that a 500 GB HDD will last decades. Can you cite a study on the long-term storage reliability of modern hard disk designs? In my personal experience, disks which have sat unused for several years sometimes don't spin up. They're not designed for that.
I'll also point out that the equipment needed to read an ST-506 hard disk -- introduced circa 1980, thus "decades" -- would likely be somewhat hard to find and integrate into a modern operation. It might not be "fancy hardware", but the end result (high cost) is the same.
I'm not dismissing the use of hard disks for archiving in general; I just find some of your claims dubious.
One thing that seems to be true is that storage is getting cheaper and bigger all the time. Thus for some applications, it may actually be cost-effective to keep all your archives online (disks spinning), with redundancy, and simply upgrade to newer, larger drives as old ones fail. Capacity keeps growing for new data, and old data keeps getting copied to new media. That eliminates the concerns about keeping equipment around to read old media. As an added bonus, everything is online all the time.
One does not "shrink" a chip by taking photomasks and shrinkenating.
'course not. You use a transmogrifier. In the industry, it is known as the "Bill Watterson" process.
It can also be used to turn photomasks into elephants, which, while less profitable, is immensely entertaining if the operator didn't see you change the setting.
People said things like that about the Skunk Works back when Kelly Johnson was running the place, when they created the U-2 and SR-71. If we adhere strictly to your doctrine, those planes would be impossible. Yet they were built in those sorts of conditions, and remain incredible achievements to this day.
Turns out that if the organization has a lot of people who are truly amazingly talented, a lot of that corporate wisdom doesn't apply so much. Scaled Composites has the right combination of small size, corporate youth, and flexibility to be able to pull it off.
I'm not saying they *are* pulling it off, but I don't think you can say they aren't, either.
Of course, most organizations are not staffed that way -- there just aren't that many truly amazingly talented people out there. In any large organization, you have to plan on having some people who are merely excellent, a lot who are moderately talented, and your fair share of duds. (And that's if you're lucky.) You have design the organization itself to be fault tolerant.
There are also technical reasons why big companies and small companies can operate in different ways successfully. Take work platforms, for example. They're larger, more expensive, and less flexible. If you're building hundreds of planes, they pay off. If you're building an evolving prototype, they might actually hamper efforts.
I work for a small defense contractor. We get lots of work sub'ed to us from the big boys, precisely because we're more flexible and don't play by their rules. They keep telling us we're doing things inefficiently, but we consistently do things cheaper than their own in-house staff can.
So don't assume that just because Lockheed Martin and Boeing have to do things your way, that everyone has to.
Stop treating economics like its a theory of everything. Stop treating it like it is theory at all in fact, because it has as much in common with real science as reading tea leaves does.
That's really inaccurate. While there are lots of people who call various human sociological/political theories "economics", that doesn't invalidate the economic principles based on science and math.
In particular, this story is about one of the most solid economic principles of all: Supply and demand. As demand increases relative to supply, price goes up. That is basically built directly on top the Law of Conservation of Mass and Energy, AKA the First Law of Thermodynamics. Matter/energy can neither be created nor destroyed. Or, to use the colloguial version, "There's no such thing as a free lunch." It's probably the most fundamental principle in the physical sciences, and it leads directly to the dynamics of supply and demand. So comparing it to "reading tea leaves" is like... well, it's like calling sociological theories "economics".
Roughly 1 in 50 downloads doesn't really seem like they're ignoring the user base.
Hypothetically, if it was someone demonstrated that Firefox lost 1 in 50 users to MSIE, Opera, etc., it would cause great response (Slashdot headlines, etc.). Obviously, people aren't that upset about it, but I think it demonstrates that 2% of users is not the same as two pennies. I'd call it significant enough a number to warrant developer response beyond the current behavior. Again, the response so far has been to tell people who want an option for the old behavior that they're wrong. Especially since we're not talking about writing a lot of new code; we're talking about not removing the old code. Indeed, there used to be such an option; it was removed (along with the old code). So it actually took more developer effort (short term) to get the current situation.
While I admit, the option to turn it off should appear somewhere, if only in about:config, the development team isn't ignoring it's users.
Really? So far, it seems like we can paraphrase the response from the developers as, "We'll tell you the same thing we told the other 100,000 people who asked for it: Nobody wants the old behavior back!"
The awesomebar debate has had tons of anecdotes and personal theories, but very little hard data. So here's a real data point:
Since Firefox 3.0 went to general release, the Oldbar extension has been downloaded at least 70,000 times. (It was at roughly 15K when I downloaded it on 3.0 release day.)
Wrong. USB specifies the mechanism for obtaining a device's unique serial number through the iSerialNumber field of the standard device descriptor.
I stand corrected. Do you know if iSerialNumber was not present in an earlier version of the spec, perhaps? I tried to find the 1.0 or 1.1 USB specs, and couldn't. In the past, I was told -- by people who I thought knew what they were talking about -- that USB doesn't have unique device IDs. Or, since it's optional, maybe it is typically not implemented?
No, that is an artifact of how Windows does hardware.
When a device becomes known to Windows, it gets "enumerated". This basically means it gets a registry key somewhere (it will be under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum if you want to poke around). That yields a "device instance ID", which uniquely identifies that bit of hardware and how it's connected to the system. (Important if you've got two of something. Like, say, two identical model hard drives.) Drivers get bound to enumerated instances.
As I mentioned, USB doesn't uniquely identify individual units. Models, yes, but not units. (In other words, USB can tell a Logitech MX70 from a Logitech MX50, but it can't tell the difference between two Logitech MX70's.) This makes USB bus enumeration somewhat non-deterministic. Combined with how Windows manages hardware, and you've got the behavior you describe.
If it's just one device you're moving around, you usually see it as Windows prompting for drivers the first time you plug it into a given root hub. The more devices moving around, the more combinations there are, so the more possible device instance IDs there are.
Linux has similar but different problems. Linux doesn't normally "bind" drivers the way Windows does. Drivers auto-load and you're happy. Fine for a webcam. But if you're trying to differentiate between, say, multiple hot-swapped USB mass storage devices, things can become tricky. Linux at least has features which can be used to address this problem, by looking at other info (like reported storage element ID). With Windows, you're sunk.
Ah, but if you plugged the keyboards into two different USB ports, they would look like different devices to the host.
That isn't quite correct. USB bus topology has no concept of "ports". There are hubs and there are end-points. The OS can differentiate between devices based on the path to the hub they are connected to, but not the port on the hub.
For hosts with multiple USB ports, there is this concept of the "root hub". If you've only got two ports on your host, chances are each port is connected to the same root hub. Hosts with more ports typically gang ports together into a smaller number of root hubs. So if you've got 6 USB host ports, they might be distributed among 3 root hubs. The host OS will generally be able to differentiate between root hubs, but not ports.
Model M = The most annoying keyboard ever created....it is the loudest most obnoxious piece of computer equipment ever created.
Heretic! Like the bumper sticker says, If it's too loud, you're too old! Granted, I don't think they were talking about keyboards, but the principle stands.
(This was typed on my IBM 13H6705, which is basically a Model M with an integrated pointing-stick. Lets me manipulate the "mouse" pointer without taking my hands off the keyboard. Mmmmm... clicky.)
One problem I've noticed is that... the per keyboard mapping isn't completely effective. USB keyboards won't respect their per-keyboard mapping, from what I've seen.
USB doesn't specify a standard way for devices to have a unique identifier. The result is that all USB devices of a given model appear identical to the host. So if you have two Das Keyboards, the host cannot tell them apart (within the world of USB).
They should visit film.disney.com, kids.disney.com, and fun.disney.com. The DNS works backwards...
Indeed. One of the oldtimers at a local and old ISP -- http://www.mv.com/ -- related the story about how they got their domain name. Originally, the thinking was that domain names were a scarce resource. So rather than having everybody register a 2LD themselves, they would get one from their local ISP. So my domain name would be dragonhawk.mv.com or something like that. Could you imagine the chaos that would ensue if everyone had to register their own domain name?
My, how times have changed.
...and people should learn that just as they learn how an email address works and how to work web forms.
I've found that any plan that depends on people learning is in trouble.;-)
Explain to me why my Linux installation has no problem dealing with FAT32 and NTFS, but my Windows installation cannot handle Ext2 very well.
You'd have to ask the people writing EXT2/3 code for Windows. Filesystem drivers do not spring into existence though spontaneous generation. They actually require someone to write them. And by all accounts, writing a filesystem driver is rather difficult. If there's little interest in having working EXT2/3 code for Windows, that's not the fault of Windows. (Well, it might be an indication that few people want to go back to Windows, and that might be due to the design of Windows, but that's a human behavior issue, not a technical one.)
Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.
There are advantages to doing stuff at the filesystem layer. One of the biggest gains is that the filesystem is aware of the difference between allocated vs unallocated space. At the block layer, you can waste a lot of resources on snapshots, mirrors, encryption, etc., of unallocated space. (Copy-on-write block devices sound like a solution -- as long as you never delete anything and only do changes-in-place.) With snapshot capabilities in the filesystem, you can get more useful semantics (like the ability to easily access past versions of a given file without mounting umpteen snapshots). Similarly with encryption: People frequently only want to cipher selected files, but don't want to organize stuff between different filesystem partitions, but still want the convenience of having the cipher be transparent to the application. (Whether AdvFS in particular takes advantage of any of this, I have no idea.) I'm not saying *you* should care about any of this, but some people do.
And resizing a block device without resizing the filesystem inside it is... an interesting idea.;-)
There are advantages to the layered approach, too, as you note. Personally, I'm of the opinion that the two approaches can co-exist in the universe without causing instability in the space-time continuum. Let the user chose what to use, based on what best suits their use. One can even use them both on the same system, or even layer the many-feature filesystems on top of LVM -- for the worst of both worlds!;-)
I've often how it's possible to map memory outside what would appear to be the limit of address space Right. Each process has its own virtual address space, each of which will map different hardware pages into it. As an over-simplification, imagine you have 8 GiB of RAM, and devote 1 GiB each to eight different processes. Each process only maps 1 GiB of RAM into its 4 GiB virtual address space, but combined we're talking more than 4 GiB of RAM. That's only possible because PAE expands the hardware address size to 36 bits -- in theory, up to 64 GiB.
As I mentioned, it's also possible for a 32-bit program to make use of more than 4 GiB of memory, but not easily. Native CPU instructions, being limited to a 32-bit virtual address word, can only directly address 4 GiB of RAM. But the OS can change the mapping of hardware to virtual addresses on the fly. An application can use that to switch different "banks" of RAM into its virtual address space. (Similar to how EMS worked back in the days of the 1 MB 8086 RAM limit, if you're familiar with that.)
But doing this means the the application has to worry about doing its own memory management. That's complicated and usually way too much work. Thus, only certain applications which both need to run in 32-bit mode but also need large memories go to the trouble. Database servers running on 32-bit OSes are a common example.
there is no difference between 32-bit XP and 32-bit Vista in terms of memory addressability Correct. Both restrict hardware addresses to under the 4 GiB line. That means a maximum of 4 GiB of hardware can be addressed. Since all your peripheral hardware has to be in that 4 GiB hardware address space, it can never address a full 4 GiB of RAM. Exactly how much RAM you lose depends on your hardware. Some systems only loose a few hundred MiB. But I've heard horror stories of people with dual 512 MB video cards loosing over 1.5 GiB of RAM.
This applies to Windows Vista, Windows XP (32-bit), and all "Standard" versions of 32-bit Windows Server. Only the 64-bit versions of Windows do not suffer from this limitation. (Well, and 32-bit Enterprise/Advanced Server.)
32 bit Vista can only access 3.1GB without a hardware hack called PAE which will not work with all software. Calling PAE a "hack" is also rather misleading.
PAE is a feature of the modern x86 architecture, just like MMX or SSE. It was introduced with the Pentium Pro in 1995 (13 years ago!), and has been standard since the Pentium II (1997). PAE increases the number of address lines from 32 to 36. It also adds a new mode to the x86 MMU (Memory Management Unit) which supports 36-bit hardware addresses. The new mode adds a third level to the page table structure, in facilitate a larger page table entry size.
Both Vista and XP enable PAE, but with a major caveat. Both avoid using any hardware address above the 4 GiB mark because it turns out a lot of drivers can't handle such. That includes drivers which ship with Windows -- and Microsoft takes on part of the support burden of those. (Microsoft doesn't support third-party (non-WHQL) drivers and never has.)
The reason both OSes enable PAE mode is to get NX (No Execute bit) support. (NX is used as a defense against code injection due via buffer overrun. Microsoft calls it DEP (Data Execution Prevention).) The NX bit is only present in the larger page table entries. So they enable PAE -- and take the performance hit of the third level of page table lookup -- but don't actually use the larger hardware address word.
So anyway, because the OSes can't use hardware above 4 GiB, they (re)configure all your peripheral hardware to exist within the 4 GiB space. That includes configuration space, ROMs, buffers, video memory, the AGP aperture, memory mapped hardware I/O (DMA), etc. Any RAM at those addresses gets "shadowed" and is not accessible to the OS.
Linux doesn't have this problem -- it's been 64-bit clean for years, and will happily put your peripheral hardware above 4 GiB. (One can still run into problems with motherboards, BIOSes, and/or expansion cards which don't support hardware addresses > 32 bits, though. Some motherboards don't have the PAE lines "wired". Some BIOSes just don't support it. And some 32-bit PCI cards don't support DAC (Dual Address Cycle), which would let them accept a 64-bit address.)
But to support a hardware address > 32 bits with Windows, you either need to run the x86-64 versions of Windows, or run Advanced/Enterprise Server. (The "Standard" version of Windows Server is limited in the same way as Win XP/Vista.)
Note that all of the above is about hardware addresses -- the actual address lines coming out of the x86 chip. The virtual address space is still limited to 32 bits and 4 GiB. And all software -- including the OS kernel -- use the virtual address space for practically all operations. But with PAE, you can at least have multiple processes which total to more than 4 GiB.
(There are also techniques which let a 32-bit process make use of more than 4 GiB of RAM, such as bank switching (memory windowing). But such techniques are cumbersome at best. Ultimately, a 32-bit process can only directly access 4 GiB of memory. You need long mode (x86-64/AMD64) to get a 64-bit virtual address space.)
(Windows further limits most 32-bit user processes to 2 GiB, reserving 2 GiB for the kernel. There's a BOOT.INI switch which changes that split to 3 GiB for userland and 1 GiB for the kernel. But unless a program was specifically compiled to support that, it will still only use 2 GiB. And robbing 1 GiB from the kernel can impact performance in other ways.)
I order all of our new Business PC's with Vista licenses, however I then load them with my volume licensing copy of XP At the risk of sounding like an AOL user: Me too! We've been doing this since the day Vista started shipping. The Vista license costs us the same as the XP license, so we might as well just buy the Vista license to have it. When XP goes end-of-life (current scheduled for 2014), we'll have to switch to Vista (or off 'doze entirely, but I don't see us doing that), so the license will be handy.
From what others have said on forums like this and the NT-SYSADMIN list, a lot of people are doing this. So I suspect Vista's real-world market penetration isn't even as good as Microsoft says. Of course, Microsoft gets their money either way, so from a profit stand-point, they don't care. But it may well confuse the industry predictors at Dell and the like.
Rumor has it that when XP goes end-of-sales in a month, Dell is planning on offering this as a formal option: Sell a Vista license, but load XP as a downgrade. If so, and the price difference isn't big, I'm planning on ordering that option, just so our preference for XP shows up on somebody's radar. I encourage others to do the same. If it looks like everyone is buying and running Vista, XP support will dry up.
In general, I find most of the articles that complain about such-and-such a problem with Wikipedia stop too soon. It isn't that Wikipedia is often incorrect, or that Wikipedia articles lack verifiable sources, or that people are too quick to trust what's written in Wikipedia, or that Wikipedia is easily subverted by people with their own agenda. While those statements are all true, they're simply special cases of a far more insidious trend: People put too much trust in information.
Newspaper articles, scientific studies, engineering decisions, information in general suffers from all the same problems. How often do we see someone make a statement, claiming things are a certain way, but with no way to check on it? Just about every post on Slashdot, for starters.:) But we tend to want to accept such statements as truth, even when we know better. Humans seem to have an inherent, unconscious willingness to trust that domatic statements must be true.
For the most part, the POS's in this thread are the first choice. Actually, in my experience as an IT consultant and admin, most POS systems are also a POS.
Like a lot of vertical markets, this one seems to be infested with companies producing poorly engineered products with no mind for security, usability, interoperability, or ease of IT management. They're usually highly proprietary and overpriced, to boot.
with UAC, even root has to sudo That's not far off. What happens is that at logon, privileged users get multiple security tokens created for their session. (A security token contains all the details of a user's security identifications and privileges.) Most things run using the "filtered token", which has system privileges removed. When a system operation needs to be done, a separate process running on a separate desktop ("station") prompts for confirmation. (It takes a screenshot of the regular desktop and fades it to give you the impression that it's just another window.) The system operation then runs with a different security token.
UAC does seem to allow for some sudo-like functionality with UAC. If an unprivileged account tries to do something, they get prompted for credentials (username/password). An admin can then elevate that operation to a privileged account, without having to explicitly start a separate session with RUNAS. Too bad that's not available in XP, because I'm not moving to Vista any time soon.
Mark Russinovich, of SysInternals fame, wrote a really good article on how UAC actually works internally. Recommended for those interested. "Inside Windows Vista User Account Control", TechNet.
As far as the user experience goes, I liken it to the way Ubuntu does things: The account you use for normal operations prompts you before performing system actions. They're just implemented totally different. In Ubuntu, you run with a regular *nix user account, and it uses sudo-to-root for the system actions. The root account is nominally not used for interactive logon.
I find the *nix method cleaner. But then, Microsoft is trying to provide backwards compatibility. I'd might be willing to buy that as an excuse, except for the fact that Vista broke so much other stuff. Clearly, backwards compatibility is only sometimes important to Microsoft.
Caveat emptor is not english either. Caveat is latin for warning.
One could make the argument that it has become an English word meaning, roughly, "exception, condition".
For example, "'Caveat emptor' is Latin, with the caveat that it is frequently used as English."
We could get into the whole prescriptive vs descriptive language debate now, if you like. :)
Electricity wise that's just plain not efficient. There was a story posted here a while back about how Hollywood studios were having the same issue.
As I wrote, it depends on the application.
Anything with larges amounts of quiescent (unchanging) data that does not to be online is going to lose big-time. Most movie footage is going to fall into that category; it never changes once shot, and most of it is rarely looked at after post-production finishes. They only keep it around for posterity and "Special Edition" edits.
But take somebody like The Wayback Machine. What I described is more-or-less how they manage their storage. (Or was, when I read about it a year or three ago.) The whole archive needs to be online at all times anyway, so it's a win for them.
One size does not fit all.
A 500 GB HDD costs less than a single one of these discs, is reliable, rewritable a million times, lasts decades if properly stored, is already available, is faster, and requires no fancy hardware.
I'm curious as to on what you base your statement that a 500 GB HDD will last decades. Can you cite a study on the long-term storage reliability of modern hard disk designs? In my personal experience, disks which have sat unused for several years sometimes don't spin up. They're not designed for that.
I'll also point out that the equipment needed to read an ST-506 hard disk -- introduced circa 1980, thus "decades" -- would likely be somewhat hard to find and integrate into a modern operation. It might not be "fancy hardware", but the end result (high cost) is the same.
I'm not dismissing the use of hard disks for archiving in general; I just find some of your claims dubious.
One thing that seems to be true is that storage is getting cheaper and bigger all the time. Thus for some applications, it may actually be cost-effective to keep all your archives online (disks spinning), with redundancy, and simply upgrade to newer, larger drives as old ones fail. Capacity keeps growing for new data, and old data keeps getting copied to new media. That eliminates the concerns about keeping equipment around to read old media. As an added bonus, everything is online all the time.
One does not "shrink" a chip by taking photomasks and shrinkenating.
'course not. You use a transmogrifier. In the industry, it is known as the "Bill Watterson" process.
It can also be used to turn photomasks into elephants, which, while less profitable, is immensely entertaining if the operator didn't see you change the setting.
Those MotherShip pics are scary.
People said things like that about the Skunk Works back when Kelly Johnson was running the place, when they created the U-2 and SR-71. If we adhere strictly to your doctrine, those planes would be impossible. Yet they were built in those sorts of conditions, and remain incredible achievements to this day.
Turns out that if the organization has a lot of people who are truly amazingly talented, a lot of that corporate wisdom doesn't apply so much. Scaled Composites has the right combination of small size, corporate youth, and flexibility to be able to pull it off.
I'm not saying they *are* pulling it off, but I don't think you can say they aren't, either.
Of course, most organizations are not staffed that way -- there just aren't that many truly amazingly talented people out there. In any large organization, you have to plan on having some people who are merely excellent, a lot who are moderately talented, and your fair share of duds. (And that's if you're lucky.) You have design the organization itself to be fault tolerant.
There are also technical reasons why big companies and small companies can operate in different ways successfully. Take work platforms, for example. They're larger, more expensive, and less flexible. If you're building hundreds of planes, they pay off. If you're building an evolving prototype, they might actually hamper efforts.
I work for a small defense contractor. We get lots of work sub'ed to us from the big boys, precisely because we're more flexible and don't play by their rules. They keep telling us we're doing things inefficiently, but we consistently do things cheaper than their own in-house staff can.
So don't assume that just because Lockheed Martin and Boeing have to do things your way, that everyone has to.
Stop treating economics like its a theory of everything. Stop treating it like it is theory at all in fact, because it has as much in common with real science as reading tea leaves does.
That's really inaccurate. While there are lots of people who call various human sociological/political theories "economics", that doesn't invalidate the economic principles based on science and math.
In particular, this story is about one of the most solid economic principles of all: Supply and demand. As demand increases relative to supply, price goes up. That is basically built directly on top the Law of Conservation of Mass and Energy, AKA the First Law of Thermodynamics. Matter/energy can neither be created nor destroyed. Or, to use the colloguial version, "There's no such thing as a free lunch." It's probably the most fundamental principle in the physical sciences, and it leads directly to the dynamics of supply and demand. So comparing it to "reading tea leaves" is like... well, it's like calling sociological theories "economics".
Roughly 1 in 50 downloads doesn't really seem like they're ignoring the user base.
Hypothetically, if it was someone demonstrated that Firefox lost 1 in 50 users to MSIE, Opera, etc., it would cause great response (Slashdot headlines, etc.). Obviously, people aren't that upset about it, but I think it demonstrates that 2% of users is not the same as two pennies. I'd call it significant enough a number to warrant developer response beyond the current behavior. Again, the response so far has been to tell people who want an option for the old behavior that they're wrong. Especially since we're not talking about writing a lot of new code; we're talking about not removing the old code. Indeed, there used to be such an option; it was removed (along with the old code). So it actually took more developer effort (short term) to get the current situation.
While I admit, the option to turn it off should appear somewhere, if only in about:config, the development team isn't ignoring it's users.
Really? So far, it seems like we can paraphrase the response from the developers as, "We'll tell you the same thing we told the other 100,000 people who asked for it: Nobody wants the old behavior back!"
The awesomebar debate has had tons of anecdotes and personal theories, but very little hard data. So here's a real data point:
Since Firefox 3.0 went to general release, the Oldbar extension has been downloaded at least 70,000 times. (It was at roughly 15K when I downloaded it on 3.0 release day.)
70,000 seems non-trivial to me.
Wrong. USB specifies the mechanism for obtaining a device's unique serial number through the iSerialNumber field of the standard device descriptor.
I stand corrected. Do you know if iSerialNumber was not present in an earlier version of the spec, perhaps? I tried to find the 1.0 or 1.1 USB specs, and couldn't. In the past, I was told -- by people who I thought knew what they were talking about -- that USB doesn't have unique device IDs. Or, since it's optional, maybe it is typically not implemented?
Is that related to the way USB must be handled??
No, that is an artifact of how Windows does hardware.
When a device becomes known to Windows, it gets "enumerated". This basically means it gets a registry key somewhere (it will be under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum if you want to poke around). That yields a "device instance ID", which uniquely identifies that bit of hardware and how it's connected to the system. (Important if you've got two of something. Like, say, two identical model hard drives.) Drivers get bound to enumerated instances.
As I mentioned, USB doesn't uniquely identify individual units. Models, yes, but not units. (In other words, USB can tell a Logitech MX70 from a Logitech MX50, but it can't tell the difference between two Logitech MX70's.) This makes USB bus enumeration somewhat non-deterministic. Combined with how Windows manages hardware, and you've got the behavior you describe.
If it's just one device you're moving around, you usually see it as Windows prompting for drivers the first time you plug it into a given root hub. The more devices moving around, the more combinations there are, so the more possible device instance IDs there are.
Linux has similar but different problems. Linux doesn't normally "bind" drivers the way Windows does. Drivers auto-load and you're happy. Fine for a webcam. But if you're trying to differentiate between, say, multiple hot-swapped USB mass storage devices, things can become tricky. Linux at least has features which can be used to address this problem, by looking at other info (like reported storage element ID). With Windows, you're sunk.
Ah, but if you plugged the keyboards into two different USB ports, they would look like different devices to the host.
That isn't quite correct. USB bus topology has no concept of "ports". There are hubs and there are end-points. The OS can differentiate between devices based on the path to the hub they are connected to, but not the port on the hub.
For hosts with multiple USB ports, there is this concept of the "root hub". If you've only got two ports on your host, chances are each port is connected to the same root hub. Hosts with more ports typically gang ports together into a smaller number of root hubs. So if you've got 6 USB host ports, they might be distributed among 3 root hubs. The host OS will generally be able to differentiate between root hubs, but not ports.
Model M = The most annoying keyboard ever created. ...it is the loudest most obnoxious piece of computer equipment ever created.
Heretic! Like the bumper sticker says, If it's too loud, you're too old! Granted, I don't think they were talking about keyboards, but the principle stands.
(This was typed on my IBM 13H6705, which is basically a Model M with an integrated pointing-stick. Lets me manipulate the "mouse" pointer without taking my hands off the keyboard. Mmmmm... clicky.)
I was under the impression the dot matrix printers of the 1980's were the loudest most annoying peices of computer equipment ever created.
You obviously never saw a daisy-wheel or golf-ball printer in action. Thump thump thump thump thump thump thump click-whir thump thump thump...
My first DMP was quiet in comparison.
/me waits for someone with an ASR-33 to jump into the thread...
One problem I've noticed is that... the per keyboard mapping isn't completely effective. USB keyboards won't respect their per-keyboard mapping, from what I've seen.
USB doesn't specify a standard way for devices to have a unique identifier. The result is that all USB devices of a given model appear identical to the host. So if you have two Das Keyboards, the host cannot tell them apart (within the world of USB).
Maybe if companies didn't build applications on brain-dead, proprietary, single-vendor platforms they wouldn't run into these kinds of problems.
Please tell that to our customers, who require us to use such software to do business with them. :-(
(We're a small company working as a sub-contractor to industry giants. We do things their way, or we go out-of-business.)
They should visit film.disney.com, kids.disney.com, and fun.disney.com. The DNS works backwards ...
Indeed. One of the oldtimers at a local and old ISP -- http://www.mv.com/ -- related the story about how they got their domain name. Originally, the thinking was that domain names were a scarce resource. So rather than having everybody register a 2LD themselves, they would get one from their local ISP. So my domain name would be dragonhawk.mv.com or something like that. Could you imagine the chaos that would ensue if everyone had to register their own domain name?
My, how times have changed.
...and people should learn that just as they learn how an email address works and how to work web forms.
I've found that any plan that depends on people learning is in trouble. ;-)
You'd have to ask the people writing EXT2/3 code for Windows. Filesystem drivers do not spring into existence though spontaneous generation. They actually require someone to write them. And by all accounts, writing a filesystem driver is rather difficult. If there's little interest in having working EXT2/3 code for Windows, that's not the fault of Windows. (Well, it might be an indication that few people want to go back to Windows, and that might be due to the design of Windows, but that's a human behavior issue, not a technical one.)
There are advantages to doing stuff at the filesystem layer. One of the biggest gains is that the filesystem is aware of the difference between allocated vs unallocated space. At the block layer, you can waste a lot of resources on snapshots, mirrors, encryption, etc., of unallocated space. (Copy-on-write block devices sound like a solution -- as long as you never delete anything and only do changes-in-place.) With snapshot capabilities in the filesystem, you can get more useful semantics (like the ability to easily access past versions of a given file without mounting umpteen snapshots). Similarly with encryption: People frequently only want to cipher selected files, but don't want to organize stuff between different filesystem partitions, but still want the convenience of having the cipher be transparent to the application. (Whether AdvFS in particular takes advantage of any of this, I have no idea.) I'm not saying *you* should care about any of this, but some people do.
And resizing a block device without resizing the filesystem inside it is... an interesting idea. ;-)
There are advantages to the layered approach, too, as you note. Personally, I'm of the opinion that the two approaches can co-exist in the universe without causing instability in the space-time continuum. Let the user chose what to use, based on what best suits their use. One can even use them both on the same system, or even layer the many-feature filesystems on top of LVM -- for the worst of both worlds! ;-)
As I mentioned, it's also possible for a 32-bit program to make use of more than 4 GiB of memory, but not easily. Native CPU instructions, being limited to a 32-bit virtual address word, can only directly address 4 GiB of RAM. But the OS can change the mapping of hardware to virtual addresses on the fly. An application can use that to switch different "banks" of RAM into its virtual address space. (Similar to how EMS worked back in the days of the 1 MB 8086 RAM limit, if you're familiar with that.)
But doing this means the the application has to worry about doing its own memory management. That's complicated and usually way too much work. Thus, only certain applications which both need to run in 32-bit mode but also need large memories go to the trouble. Database servers running on 32-bit OSes are a common example. there is no difference between 32-bit XP and 32-bit Vista in terms of memory addressability Correct. Both restrict hardware addresses to under the 4 GiB line. That means a maximum of 4 GiB of hardware can be addressed. Since all your peripheral hardware has to be in that 4 GiB hardware address space, it can never address a full 4 GiB of RAM. Exactly how much RAM you lose depends on your hardware. Some systems only loose a few hundred MiB. But I've heard horror stories of people with dual 512 MB video cards loosing over 1.5 GiB of RAM.
This applies to Windows Vista, Windows XP (32-bit), and all "Standard" versions of 32-bit Windows Server. Only the 64-bit versions of Windows do not suffer from this limitation. (Well, and 32-bit Enterprise/Advanced Server.)
PAE is a feature of the modern x86 architecture, just like MMX or SSE. It was introduced with the Pentium Pro in 1995 (13 years ago!), and has been standard since the Pentium II (1997). PAE increases the number of address lines from 32 to 36. It also adds a new mode to the x86 MMU (Memory Management Unit) which supports 36-bit hardware addresses. The new mode adds a third level to the page table structure, in facilitate a larger page table entry size.
Both Vista and XP enable PAE, but with a major caveat. Both avoid using any hardware address above the 4 GiB mark because it turns out a lot of drivers can't handle such. That includes drivers which ship with Windows -- and Microsoft takes on part of the support burden of those. (Microsoft doesn't support third-party (non-WHQL) drivers and never has.)
The reason both OSes enable PAE mode is to get NX (No Execute bit) support. (NX is used as a defense against code injection due via buffer overrun. Microsoft calls it DEP (Data Execution Prevention).) The NX bit is only present in the larger page table entries. So they enable PAE -- and take the performance hit of the third level of page table lookup -- but don't actually use the larger hardware address word.
So anyway, because the OSes can't use hardware above 4 GiB, they (re)configure all your peripheral hardware to exist within the 4 GiB space. That includes configuration space, ROMs, buffers, video memory, the AGP aperture, memory mapped hardware I/O (DMA), etc. Any RAM at those addresses gets "shadowed" and is not accessible to the OS.
Linux doesn't have this problem -- it's been 64-bit clean for years, and will happily put your peripheral hardware above 4 GiB. (One can still run into problems with motherboards, BIOSes, and/or expansion cards which don't support hardware addresses > 32 bits, though. Some motherboards don't have the PAE lines "wired". Some BIOSes just don't support it. And some 32-bit PCI cards don't support DAC (Dual Address Cycle), which would let them accept a 64-bit address.)
But to support a hardware address > 32 bits with Windows, you either need to run the x86-64 versions of Windows, or run Advanced/Enterprise Server. (The "Standard" version of Windows Server is limited in the same way as Win XP/Vista.)
Note that all of the above is about hardware addresses -- the actual address lines coming out of the x86 chip. The virtual address space is still limited to 32 bits and 4 GiB. And all software -- including the OS kernel -- use the virtual address space for practically all operations. But with PAE, you can at least have multiple processes which total to more than 4 GiB.
(There are also techniques which let a 32-bit process make use of more than 4 GiB of RAM, such as bank switching (memory windowing). But such techniques are cumbersome at best. Ultimately, a 32-bit process can only directly access 4 GiB of memory. You need long mode (x86-64/AMD64) to get a 64-bit virtual address space.)
(Windows further limits most 32-bit user processes to 2 GiB, reserving 2 GiB for the kernel. There's a BOOT.INI switch which changes that split to 3 GiB for userland and 1 GiB for the kernel. But unless a program was specifically compiled to support that, it will still only use 2 GiB. And robbing 1 GiB from the kernel can impact performance in other ways.)
From what others have said on forums like this and the NT-SYSADMIN list, a lot of people are doing this. So I suspect Vista's real-world market penetration isn't even as good as Microsoft says. Of course, Microsoft gets their money either way, so from a profit stand-point, they don't care. But it may well confuse the industry predictors at Dell and the like.
Rumor has it that when XP goes end-of-sales in a month, Dell is planning on offering this as a formal option: Sell a Vista license, but load XP as a downgrade. If so, and the price difference isn't big, I'm planning on ordering that option, just so our preference for XP shows up on somebody's radar. I encourage others to do the same. If it looks like everyone is buying and running Vista, XP support will dry up.
No Text
Headline says: "Wikipedia Breeds Unwitting Trust"
:) But we tend to want to accept such statements as truth, even when we know better. Humans seem to have an inherent, unconscious willingness to trust that domatic statements must be true.
My first thought: s/Breeds/Highlights/
In general, I find most of the articles that complain about such-and-such a problem with Wikipedia stop too soon. It isn't that Wikipedia is often incorrect, or that Wikipedia articles lack verifiable sources, or that people are too quick to trust what's written in Wikipedia, or that Wikipedia is easily subverted by people with their own agenda. While those statements are all true, they're simply special cases of a far more insidious trend: People put too much trust in information.
Newspaper articles, scientific studies, engineering decisions, information in general suffers from all the same problems. How often do we see someone make a statement, claiming things are a certain way, but with no way to check on it? Just about every post on Slashdot, for starters.
Wikipedia simply highlights this problem.
Like a lot of vertical markets, this one seems to be infested with companies producing poorly engineered products with no mind for security, usability, interoperability, or ease of IT management. They're usually highly proprietary and overpriced, to boot.
UAC does seem to allow for some sudo-like functionality with UAC. If an unprivileged account tries to do something, they get prompted for credentials (username/password). An admin can then elevate that operation to a privileged account, without having to explicitly start a separate session with RUNAS. Too bad that's not available in XP, because I'm not moving to Vista any time soon.
Mark Russinovich, of SysInternals fame, wrote a really good article on how UAC actually works internally. Recommended for those interested. "Inside Windows Vista User Account Control", TechNet.
As far as the user experience goes, I liken it to the way Ubuntu does things: The account you use for normal operations prompts you before performing system actions. They're just implemented totally different. In Ubuntu, you run with a regular *nix user account, and it uses sudo-to-root for the system actions. The root account is nominally not used for interactive logon.
I find the *nix method cleaner. But then, Microsoft is trying to provide backwards compatibility. I'd might be willing to buy that as an excuse, except for the fact that Vista broke so much other stuff. Clearly, backwards compatibility is only sometimes important to Microsoft.