They think it has to be that way, because, well, they're across the network. As if there were some physical property of 100-base-T cables that made them intrinsically different from SATA cables. You do of course realize that it could be because the remote filesystem doesnt support the same functionality as your local one?
For example, the remote file system may be an old version of Samba that doesnt support ADS, or proper ACLs, or maybe wont give up write locks.
So yes, its entirely possible that you have to treat your remote file system differently.
Does your CD file system support all the features of NTFS. I'll give you a hint, the answer is no.
Your DECnet example is only relevant when the exact same type of system was on both sides of the network. What happened when it was SMB or NFS or some other crazy thing on the other side of the wire? The world is just much more heterogenous and not as simple as it was back in the good/bad old days of DEC.
Everyone else uses/, so of course MS has to try and be different. You mean that Unix and Unix-alikes use/. VMS doesnt, the IBM mainframes dont (or at least didnt last time I was in one. I cant speak back any farther than that... but I think it is pretty much just a unix thing.
In both cases, you have to mount a partition in order to access it. Hiding the idea of mounting is another stupid move from MS -- the assumption that you always mount something that's plugged in. The problem comes up with removable drives, which need to be unmounted before ejecting. There are various workarounds now, but it was worse with floppy drives. Basically Windows would try to write a disk as soon as possible, disabling all multitasking, so that you could see when it was done. Now wait a minute... for like a decade one of the most highly requested thing on Linux systems was to automount everything. No one wanted to have to remember to manually mount the optical drive before using it, or the same for the thumb-drive.
Nowadays, most linuxes I've used automount everything, precisely as Windows does. They've even got the little 'click to safely remove thumb drive' or whatever, to make sure it doesnt get dismounted while a file write is happening.
Your experiences seem to be stuck back in the windows 3.1 days.
A third, related stupidity is blurring the lines between formatting a partition and creating a filesystem. Yet a case where someome may want to do just one of them, but MS assumes you want to do both at once. Yet again I'm not sure what you mean, but what you're describing is not accurate in the windows world.
I can trivially create, shrink, grow, delete partitions with no formatted file systems on them in windows. I can do this through the GUI, via the command line, or via a number of well documented APIs.
I'm not the poster you were responding too, but I think you may have gotten a little over caught up in his choice of words.
I'd say that the stuff we're talking about here 'just works' on windows when done by a reasonably experienced tech (intellimirror is not high-end windows stuff).
Just as one example, when Microsoft is advertising the concept of "access your e-mail from anywhere in the world" as if it's a brand new thing in 2007, something is very wrong indeed. What in the heck are you talking about?
If this is something to do with Exchange, exchange has had OWA all the way back since 5.5, iirc. It's had RPC over HTTP (to avoid using the vpn) since exchange 2003. Even before that, if you wanted to leave your firewalls open, Outlook/Exchange functionality worked great from one side of the world to another. Most shops just put firewalls up and required you to vpn first before checking email.
What is it that's new in the MS email world in 2007 that has caught your eye here?
This has never been true in the MS world. MS requires you to have *your computer* and to always use *your computer* if you want to have any semblance of a familiar desktop/files. Have you never been in a large corporate shop with competent windows admins?
It behaves exactly as you describe... any box you sit down in, you log in with your domain creds, and you get your exact desktop, your exact (networked) MyDocuments and/or your networked home drive.
What's so complicated about that? These technologies have existed on Windows since NT4, though they've gotten much more polished since then.
In fact, for most Windows users, the idea that one can sit down at another machine and access one's files, just the same as if one were logged into one's primary machine is totally alien. It is amazing how much MS has trained people to accept poor features. This is only true for non-clued home users. At any reasonably managed corporate shop, what you describe is _precisely_ how it works for windows.
It's possible that you've only dealt with poorly managed shops up till now, so have never seen this in action.
RAID 1 requires 2 drives, RAID 5 requires 3 or more drives. Sometimes people only want to pay for 2 drives, not 3+.
RAID 5 is also slow on writes, and under high volume, can provide a significant load on the machine's processor if the RAID5 is done in software. RAID 5 hardware controllers that do the parity calcs in hardware (not using drivers to have the system processor do the parity calcs) cost ~$300+.
Mind you, RAID 5 is fast on reads, but is slower on writes than RAID 1.
Exchange doesnt use access for its database. Nor does it use Jet (what you really mean).
It uses something called ESDB, which for a brief period of time in its history shared a name and some toolsets with a very early version of what we know now as access/jet.
Go read wikipedia, they've got some fine coverage on the subject.
Was in a situation recently where I was running Oracle 10g enterprise, Eclipse, Tomcat, and 2 separate apps running under that tomcat that I was working on.
Sooner or later, the OEMs will start offering 64-bit Vista on these machines (as a higher-cost option), and limiting the included bloatware to 64-bit versions. OEMs already offer 64-bit versions of vista. It costs no extra. You get to decide which to use at first boot time.
I'm typing this on an HP Compaq 8710w, running Vista Business x64.
There is no requirement or reason to switch most desktop apps to 64-bit at this time. It would just make them unusable on the 32-bit OS's.
Running 32-bit apps with WoW compatibility is simply painful. Currently, I'm running Outlook 2007 in Vista x64(Dell D830 laptop) at work and that bloated POS doubles its already awful memory footprint. Running just a few 32-bit apps in a 64 bit OS pretty much negates the additional memory you get with 4 gigs of memory. I think that either you've got something wrong with your machine, or you're mis-reading your task manager, or you're just making that up.
There was a myth floating about a bit ago that claimed that 32-bit apps running on 64 bit windows would consume twice the memory (or something), but its just nonsense.
You may see some very minor incremental memory increase, but its not going to be material.
All the NT based operating systems from windows 2000 onwards supported PAE.
When SP2 for XP Pro came out, MS decided to disable support for memory use greater than 4GB.
They claimed it was because many 32-bit drivers didnt behave well in that environment, and it was causing support issues. This seems reasonable given that their 64-bit version of windows xp supported far greater than 4GB of memory.
This information was in the article you're responding to, btw.
But, in the business and development world, there's a real need to move to 64-bit, like.. yesterday. Many types of apps, such as CAD (our drawings are typically addressing very near the 2GB mark, and are growing all the time, leading to software crashes with "Out of Memory" errors becoming increasingly common), gaming, image/video processing, etc. take up HUGE amounts of memory, and current limitations are hitting a brick wall on performance. Rather than needing more processors, we're left needing more RAM with software that can't address it, even though the hardware can support it. Thats why companies doing this kind of work moved to XP x64 years ago. You still have problems like Pro-E and other engineering apps not supporting SMP systems on windows, or being properly optimized for large systems.
Partly to blame is Microsoft's implementation of 64-bit. They've taken away support for 16-bit apps completely, and required that all drivers go through a certification process in order to function with the new OS. Software vendors that require drivers to be installed in the system, such as VMware, Antivirus vendors, etc. must pony up for the certification process. Incorrect, insofar as the 'certification process' you describe goes.
Only kernel drivers must be signed (not certified). A code-signing cert costs about $200, and requires zero involvement of Microsoft, in any way, shape or form.
This virtually insures a lockout of certain open source software projects, which often don't have financial backing (or incentive) to pony up to get Microsoft's blessing. Only the very smallest. We're only talking $200 per year.
And it doesnt require Microsoft's blessing. It requires paying a third party for a code-signing cert.
Confusing to customers, too, who expect things will be like the 16-bit to 32-bit upgrade, where 16-bit binaries run side by side seamlessly, Windows has a totally separate space for 32-bit and 64-bit versions of all of their apps. The Windows install ends up with a Program Files and Program Files (x86) directories, with two versions of Internet Explorer, two versions of Notepad, two versions of... well -- you get the the point. Not really visible to customers (ie, end-users). End users dont look in the program files directory, or care whether there are separate memory addressing spaces.
It's a really complicated, delicate, and frustrating rollout for IT departments, who are left struggling to work around the implementation. We're currently beta testing 64-bit environments of both Vista and XP-64. To say the least, it's been a huge headache. I have no doubt we'll eventually be able to find workarounds for our problems, but this is definitely going to be a time consuming, costly, training intensive, and very difficult rollout. And, trust me, if there were no need to move to 64-bit platforms at this time, it wouldn't even be on the table for discussion. All the companies I talked to started this years ago, and are comfortably using XP x64 for the folks who need large memory configurations (ie, engineers).
XP x64 is easy. Just by hardware that ships with certified drivers, and vet your software. The vast, vast majority of it will work just fine (excepting system software).
Vista x64 is harder, but not because of the x64 part. Its because so many 3rd party software apps are written by people who have no concept of how to do proper software development, and produce shoddy software.
Slashdot Mirror
For example, the remote file system may be an old version of Samba that doesnt support ADS, or proper ACLs, or maybe wont give up write locks.
So yes, its entirely possible that you have to treat your remote file system differently.
Does your CD file system support all the features of NTFS. I'll give you a hint, the answer is no.
Your DECnet example is only relevant when the exact same type of system was on both sides of the network. What happened when it was SMB or NFS or some other crazy thing on the other side of the wire? The world is just much more heterogenous and not as simple as it was back in the good/bad old days of DEC.
Nowadays, most linuxes I've used automount everything, precisely as Windows does. They've even got the little 'click to safely remove thumb drive' or whatever, to make sure it doesnt get dismounted while a file write is happening.
Your experiences seem to be stuck back in the windows 3.1 days. A third, related stupidity is blurring the lines between formatting a partition and creating a filesystem. Yet a case where someome may want to do just one of them, but MS assumes you want to do both at once. Yet again I'm not sure what you mean, but what you're describing is not accurate in the windows world.
I can trivially create, shrink, grow, delete partitions with no formatted file systems on them in windows. I can do this through the GUI, via the command line, or via a number of well documented APIs.
I'd say that the stuff we're talking about here 'just works' on windows when done by a reasonably experienced tech (intellimirror is not high-end windows stuff). Just as one example, when Microsoft is advertising the concept of "access your e-mail from anywhere in the world" as if it's a brand new thing in 2007, something is very wrong indeed. What in the heck are you talking about?
If this is something to do with Exchange, exchange has had OWA all the way back since 5.5, iirc. It's had RPC over HTTP (to avoid using the vpn) since exchange 2003. Even before that, if you wanted to leave your firewalls open, Outlook/Exchange functionality worked great from one side of the world to another. Most shops just put firewalls up and required you to vpn first before checking email.
What is it that's new in the MS email world in 2007 that has caught your eye here?
It behaves exactly as you describe
What's so complicated about that? These technologies have existed on Windows since NT4, though they've gotten much more polished since then. In fact, for most Windows users, the idea that one can sit down at another machine and access one's files, just the same as if one were logged into one's primary machine is totally alien. It is amazing how much MS has trained people to accept poor features. This is only true for non-clued home users. At any reasonably managed corporate shop, what you describe is _precisely_ how it works for windows.
It's possible that you've only dealt with poorly managed shops up till now, so have never seen this in action.
Holy mackeral, how can you be the only person that caught this!
... here's the direct KB article on this, linked from the parent's article.
Could be wrong, but I'd bet that these apps use alternate data streams for certain data.
This is fantastically informative
http://support.microsoft.com/kb/943393/
Good find, and thank you for posting that!
Cost and performance.
RAID 1 requires 2 drives, RAID 5 requires 3 or more drives. Sometimes people only want to pay for 2 drives, not 3+.
RAID 5 is also slow on writes, and under high volume, can provide a significant load on the machine's processor if the RAID5 is done in software. RAID 5 hardware controllers that do the parity calcs in hardware (not using drivers to have the system processor do the parity calcs) cost ~$300+.
Mind you, RAID 5 is fast on reads, but is slower on writes than RAID 1.
Exchange doesnt use access for its database. Nor does it use Jet (what you really mean).
It uses something called ESDB, which for a brief period of time in its history shared a name and some toolsets with a very early version of what we know now as access/jet.
Go read wikipedia, they've got some fine coverage on the subject.
Basically saying that because MS didnt do partition labels and path separators like Unix, that they suck.
/.
/swap.
/swap for swap, etc are better than C:\ and so forth, and likewise for path separators.
MS uses \ (the backslash) for path separators, unix-a-likes use forward slash
MS uses drive letters (C:, D:, etc) for partition labels, wherease unix-likes just use regular labels, like / or
It's fairly arguable that / for root,
The Unix approach is arguable a little cleaner/simpler, but they're both fairly arbitrary.
App development.
Was in a situation recently where I was running Oracle 10g enterprise, Eclipse, Tomcat, and 2 separate apps running under that tomcat that I was working on.
Very easy to go over 2GB there.
Do you mean PAE?
PAE has been supported in all NT versions of Windows since 2000.
This is how 32-bit versions of windows can use up to 64GB of RAM.
The only exception to this was XP SP2 where this was for all intents and purposes disabled.
This information is in the article you're replying to.
Many of us have been using 64-bit versions of windows for years, in both XP pro and 2003 server form.
I'm typing this on an HP Compaq 8710w, running Vista Business x64.
Well thats interesting. Last time I grabbed a copy of OpenSUSE I had to choose between a 32-bit version of the OS and a 64-bit version.
To be clear, 4GB is the maximum that 32-bit versions of Vista can use.
64-bit versions of Vista can use much, much more.
There was a myth floating about a bit ago that claimed that 32-bit apps running on 64 bit windows would consume twice the memory (or something), but its just nonsense.
You may see some very minor incremental memory increase, but its not going to be material.
You are incorrect.
All the NT based operating systems from windows 2000 onwards supported PAE.
When SP2 for XP Pro came out, MS decided to disable support for memory use greater than 4GB.
They claimed it was because many 32-bit drivers didnt behave well in that environment, and it was causing support issues. This seems reasonable given that their 64-bit version of windows xp supported far greater than 4GB of memory.
This information was in the article you're responding to, btw.
I believe you're confusing two programs.
Microsoft doesnt sign drivers, you do, with a 3rd party code-signing certificate.
To use that has no requirement (that I'm aware of) to produce both 32-bit and 64-bit drivers.
However, there is also the 'Designed for Vista' and 'Compatible for Vista', or whatever the hell they're actually called.
These programs are managed by microsoft and do, I believe, require you to produce both sets of drivers.
Only kernel drivers must be signed (not certified). A code-signing cert costs about $200, and requires zero involvement of Microsoft, in any way, shape or form. This virtually insures a lockout of certain open source software projects, which often don't have financial backing (or incentive) to pony up to get Microsoft's blessing. Only the very smallest. We're only talking $200 per year.
And it doesnt require Microsoft's blessing. It requires paying a third party for a code-signing cert. Confusing to customers, too, who expect things will be like the 16-bit to 32-bit upgrade, where 16-bit binaries run side by side seamlessly, Windows has a totally separate space for 32-bit and 64-bit versions of all of their apps. The Windows install ends up with a Program Files and Program Files (x86) directories, with two versions of Internet Explorer, two versions of Notepad, two versions of... well -- you get the the point. Not really visible to customers (ie, end-users). End users dont look in the program files directory, or care whether there are separate memory addressing spaces. It's a really complicated, delicate, and frustrating rollout for IT departments, who are left struggling to work around the implementation. We're currently beta testing 64-bit environments of both Vista and XP-64. To say the least, it's been a huge headache. I have no doubt we'll eventually be able to find workarounds for our problems, but this is definitely going to be a time consuming, costly, training intensive, and very difficult rollout. And, trust me, if there were no need to move to 64-bit platforms at this time, it wouldn't even be on the table for discussion. All the companies I talked to started this years ago, and are comfortably using XP x64 for the folks who need large memory configurations (ie, engineers).
XP x64 is easy. Just by hardware that ships with certified drivers, and vet your software. The vast, vast majority of it will work just fine (excepting system software).
Vista x64 is harder, but not because of the x64 part. Its because so many 3rd party software apps are written by people who have no concept of how to do proper software development, and produce shoddy software.
I'm not sure why you seem to be addressing your complaint to MS here.
You do know that 64-bit versions of the OS have been available for years now, right?
Granted, xp x64 required you mostly to buy from tier-1 who provided good drivers (hp, etc).
The problem is not a Microsoft problem.
Be careful with this.
... but it does happen. That exact issue is (theoretically) why MS chose to force the 32-bit versions not to use PAE.
Many drivers for consumer-level hardware dont function well in an environment where their memory space may be above the 4gb mark.
It's not always a problem
x64 versions of windows deal with high memory amounts just fine.
Give me a break.
Code signing certs can be had for $200 or less.
So in a 50-per-year quantity, that adds $4 per unit.
You can get code-signing certs for much cheaper, under $200, last time I looked.
Or you can convince the recipients to add your self-signed cert to the enterprise CA, which costs you nothing.
Really?
I see several ways.
F8 on boot and disable the feature.
Attach a kernel debugger (automatically disables the feature).
Use a self-signed cert.
Use a commercial test-cert.
Use a WHQL test-cert.
Use a self-signed cert and then configure the domain CA to trust and distribute the cert.
Signed drivers really arent this big bad evil that you seem to be setting it up as.
It's trivial and cheap to get a cert for distribution, and trivial to use a self-signed cert when you dont need to distribute publicly.
So what?
Do you actually know anything about the subject you're so cavalierly making judgements about?
Have you ever acquired a code-signing cert such that your product can be installed in this way?
Do you realize that Microsoft plays no part in the acquiring of such a cert, or the signing of your drivers?
Do you realize that these certs can be had for ~$200?
Do you realize that your Windows Vista x64 can be configured to NOT require signed certs?
Sounds like a good reason not to buy laptops from Asus.
... and stick to corporate or engineering laptops. Driver support is better and the quality is much higher.
I'm writing this from an HP Compaq 8710w that shipped with Vista Business. On first install, it asked whether to install x86 or x64 version of the OS.
I chose x64 and have full driver support. And the laptop also has full XP x64 driver support.
The key is to avoid consumer level garbage