My point? Shame on Dell for posting results from 2 wildly different studies on the traffic any
given hardware can support. Shame on Dell for trying to pose NT as the "high-traffic"
solution and Red Hat as the low-traffic solution when you have the same hardware. If they
start complaining about not selling any Linux servers, then ads like this will be to blame
(I've seen the advertisement, and it's completely nuts).
Nuts. Shame on any CIO who believes it. The ad is no more or less than I'd expect from Dell's marketing department. They are desperately trying to hold their lead in hardware sales. Dell has made pacts with Intel and Microsoft and is very afraid of their market right now.
1) Dell printed an ad that said Linux/Apache tops out at 20k-100k requests per day.
2) Your CIO saw the ad.
3) Your CIO believes Dell without questioning or thinking about their claims.
The issue here isn't Linux vs. Win2k, nor is it Apache vs. IIS. Dell isn't the problem either. If Dell can make idiotic claims like this and people believe it, they win.
If I were GM and published an ad saying "don't buy that Ford car, it won't go faster than 20 mph" would anybody believe me? Or would common sense prevail?
Once people stop thinking, the marketdroids are in control. Let's not let that happen.
Say my Apache box serves 100k pages a day. That's over 4k per hour. Suppose my peak traffic is during the business day, OK, that's still not more than 12k per hour, or 200 a minute.
The truth is, Apache can serve over 200 _dynamic_ requests per _second_ on an SMP box. I've done it.
It's very possible somebody has a website that tops out at 20k per day. That site would be annoyingly slow under light traffic, and useless with heavy traffic. The problem also would have nothing to do with choice of web server, OS or even hardware (my '486 can do better).
I have Apache running on WinNT (don't ask) serving far more than that, on a fully dynamic, database-driven site. Yet the box shows only a slight load most of the time. It would do no worse running Linux. And BTW this is the public site for a Fortune 500 company.
Yet instead of laughing at this ad, as he should, your CIO wastes your time (and slashdot's time) with it. That's pathetic. I don't know whether to laugh or cry.
I wish Compaq would commit to keeping the line running, at least for a few years.
What kind of commitment do you want? They haven't exactlly announced its cancellation (like they did for NT). Compaq has plans for EV7 and EV8, at least. If they had any intention to pull the plug they would've quit engineering these by now.
Compaq isn't the only player... there's Samsung, API (who would cease to exist without Alpha, it's their sole business).
Compaq has a comparatively small but fiercely loyal VMS customer base. The VAX is EOL and they have no hardware option but (you guessed it) Alpha.
And so on. I don't know how these things start, but folks, Alpha is not going away. Sheesh.
If either the Alpha or MIPs were viable processors, one of them would have ended up
owning the server marketplace.
Wrong. Viability doesn't produce or imply mindshare, which is prerequisite to "owning" the marketplace (if that's even possible).
And the industry is getting psyched up for the Itanium.
The industry is also preparing for a letdown. Why do you suppose it isn't shipping in volume? Why have SGI and HP backpedaled on their plans for IA-64? The success of IA-64 rides on some revolutions in compiler technology that simply haven't happened.
Sparc: Possible contender
Sure, Sun has good marketshare... but where is the OEM market? How much of their volume is Sun branded hardware?
Show me evidence that Alpha is dying. Compaq unleashed their GS series (Wildfire), the OEM business is growing, many niche markets depend on Alpha (Himalaya, VMS, NetApp Filer, scientific/technical computing). They don't appear to lead in any MAJOR market (e.g. desktop, web server), but overall they are strong.
MIPS: Out of production, Also Ran
Again, show me proof. If MIPS is out of production, what is SGI selling these days???
HPPA: Possible contender if anyone knew about 'em.
They have no market outside of HP.
Once again, you've left out PPC, and failed to convince that Itanium will win anything based on hearsay.
Let me get this straight... you have doubts about the viability of Alpha and MIPS, both of which pioneered RISC computing but you include IA-64 and Sledgehammer, one of which is struggling to get to market and the other that doesn't exist yet.
The trouble with Athlon is that system/board makers have cut too many corners on cost.
If Athlon systems had cache/bus performance similar to current Alpha or SPARC, sure, it would be comparable to those in throughput. (It would also be comparable in price.)
Well, the "masses" buy PCs anyway, they'd never be interested in a Sun.
Alphas are a fair comparison, but I'd like to see where you can get an ev6 for less than Sun hardware. The lowest I've seen for a reasonable configuration is around $3000 USD.
There'll be no Microsoft.NET in 20 years
on
A Letter from 2020
·
· Score: 1
Has Microsoft ever stuck to a platform for five years, let alone 20, without changing their game plan?
Q: What are these same companies contributing to these "core values" of Linux?
A: With the partial exception of IBM, nothing.
That's not completely true. The future of Compaq's Alpha processor is tied to Linux, to which they've contributed substantial code (don't know if they've done anything for Linux/x86 though).
Sun however is likely more interested in Gnome on Solaris than Linux.
Interesting counterargument. Just to add another data point... I haven't noticed any general incompetence among our NT admins, but our NT and Unix admins are hired by the same people, so we've likely applied more consistent criteria than this guy's HR.
One trend I have noticed is a sort of tunnel vision among the NT admins. They don't really know anything but Microsoft technologies, and while they can log into a Linux box and get around, it's a bit painful to watch. On the other hand, our Unix staff, which is largely self-taught, can handle NT just fine (though they prefer not to).
I also noticed the NT staff being far busier than the rest. All of our mission-critical NT servers require a substantial degree of hand holding, unfortunately... we are transitioning them to gradually Solaris and Linux machines, but our personnel is often too overworked just keeping the machines up so they cannot even plan for the migration!
So you want a microkernel. Mach provides much of what you ask for, except the fine-grained security perhaps.
It might be constructive to look at past Mach implementations and other microkernels... there maybe good reasons these architectures didn't dominate the market. They solve some problems all right, but not without introducing others.
Absolute performance is portrayed as vital by the media, and this just might have killed the microkernel. Isolating components in their own address space and passing messages doesn't come cheap. Context switching can be fast but not free. And processor design seems to be evolving in another direction, e.g. VLIW chips will benefit long blocks of straightline execution and a style of code that is becoming extinct as OOP becomes more refined.
Intel segmentation hasn't been utilized much, that's true, but it is probably impractical for **ix systems. How do you write an efficient C compiler that doesn't share one segment for stack and data? Besides, x86 has a limited number of segment registers, and writing to a segment register is not cheap.
Look for the ongoing thread "programming for segmented systems" on comp.arch if you're interested.
GCC has targets for just about all well known processor families (and some lesser known) but AMD is conspicuously absent. They are supported as x86 clones only. We have code generation options for i386, i486, pentium and pentiumpro, but no k6 or k7.
Surely the k7 has unique scheduling and timing characterstics that GCC could benefit from. Apparently nobody has bothered to include these in GCC, and AMD isn't doing it.
Maybe the 64-bit sledgehammer will be enough of an innovation to warrant a new backend target for GCC.
So if there ever was a time to throw out cruft it is now, before the next wave of innovation
starts. Go to a faster architecture now, get back-compat by emulation/translation. Everyone wins; server users dump money into native JVMs and get speedups soon. Consumers wait and by the time the next wave of power hungry apps comes along,
everyone has "gone native".
We have that faster architecture. It's called Alpha. It's already 64-bit. Is there really a sound technical reason to invent something totally new all over again?
I get the impression users don't want Alpha precisely because it isn't x86-compatible. Throwing out the cruft sounds great, but I think it worked for Apple mainly because m68k was really a lot cruftier then than x86 is now.
Why do you read Slashdot? Contributors and readers here aren't exactly Microsoft sympathizers... there are plenty of other sites for that.
It may have missed everyones attention here but 99% of all major companies USE Microsoft products.
Exclusively? For desktops or servers? Please qualify. The larger a company, the more likely it is to use Microsoft products, true, but it is also more likely to use alternatives.
They use then because we are safe in the knowledge that they have been strenuosly tested for deployment in large scale organisations.
Are you kidding? Do you make that statement based on your own comparitive testing, or do you really have that much faith in a software company?
Commercial software quality has been deplorable, and I'm not just talking about MS. Vendors are motivated to increase shareholder value, not help their customers.
We've tested MS products extensively in house. I've personally witnessed a staggering number of product failures, some reproducible, some not... many a complete mystery. The time I spend searching for workarounds would better be spent debugging an open source product, I am finding.
I for one, would not even consider using Linux at work
Then don't. That's your choice. It doesn't invalidate the reasons anybody else runs GNU/Linux at work.
Users : Most office people are stupid with computers.
Were you talking about using Linux yourself, or for your users? Or are you one of the "users"? I'm confused now...
It is difficult enough to set up a printer with Windows and I know what I am doing. It would be a nightmare with RedHat.
You can't figure out printtool? Really? Have you tried?
Support : Most people do not have RedHat skills, it would be more difficult to find them.
Hint 1: Most admins with BSD/Solaris/AIX/whatever experience (e.g. almost anything BUT Windows) are sufficiently qualified.
Hint 2: Many CS grads these days are quite familiar with GNU/Linux or BSD.
Qualifications : How would I be able to determine the suitability of an applicant if they do not have something like an MCSE ?
Interview them, perhaps?
I have never considered an MCSE sufficient or necessary for employment. Really, it doesn't carry much weight with me. (Nor would a Red Hat certification for that matter.)
Before you dismiss my comments... I am a technical manager for a large public company, I interview and hire my own staff, I evaluate products including commercial and free software, and we do use GNU/Linux, among Windows and other systems. I'm not religious about it, I'm just pragmatic.
Would you care to tell me how Java implements String pooling?
What is string pooling? Do you mean interning?
I imagine you'll find that it keeps reference counts.
No. Much more likely you'll find a hashtable of weakly-referenced string objects.
Referencing counting is a bad idea. Besides what the other poster said, they require atomic updates and add size to each object. It sure doesn't come cheap. Even conservative mark/sweep GC is often faster than simple ref counts.
A good JIT will perform optimizations that C will never attempt, like code inlining. Inline functions are not standard C, but they are part of C++.
I modified the life source for C++, adding `inline' in a few strategic places... compiled with g++ it runs up to 50% faster than gcc.
Add garbage collection for C++ and I doubt if the HotSpot VM will do much better, if at all. At a certain level (i.e. machine instructions) they work about the same, anyway.
it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls.
Perhaps, but that is not how Alpha/Linux does it. Linux on Alpha implements most of the Tru64 system calls natively. It also can load ECOFF images, permitting it to run Tru64 static binaries with no emulation code.
This system call compatibility was convenient: Linus deliberately made Linux system call compatible with OSF/1 during its early development, as a porting aid before Alpha/Linux was self-hosting.
Note that Tru64 still cannot execute Linux binaries simply because it lacks ELF support.
It's a well-kept secret that the NT Executive has a single-rooted hierarchy, containing device nodes, named pipes, and filesystem roots. It even supports mount points, sort of, via a concept called reparse points.
Of course none of this does us any good, because the Win32 subsystem does its best to hide whatever elegance lives in the NT kernel. You can get glimpses of it... for example, try opening the file \\.\PhysicalDrive0 for reading (don't write to it, that's your raw disk sectors!).
You get the feeling that NT could have been something better if they didn't have to make it compatible with Win9x.
...though some (including Microsoft) have tried. It may pass POSIX compliance tests, it may run UNIX software, but there are certain differences that will be difficult or impossible to overcome.
First is the security issue. Unix has the concept of a superuser (root). NT has role-based security. "Administrator" is not special other than having more rights than user accounts, including the right to manager user rights.
The key differences are that an NT Administrator cannot open any NTFS file regardless of modes, as a Unix superuser can. Also the Administrator account cannot arbitrarily pose as other users. There is no working setuid() call. (POSIX requires setuid to exist, but it doesn't have to work... it may return EPERM unconditionally. That is just what Microsoft's POSIX subsystem does.)
Second is the executable file format. Most modern OSes have standardized on ELF. NT is one of the holdouts, still using PE (a variant of COFF). Shared libraries on NT (i.e. DLLs) are loaded and relocated by the OS, not in user space as ELF shared objects are. And DLLs have annoying limitations, like requiring data symbols to be imported/exported.
Third, file semantics on NT are tailored for Win32. Ever try to remove/rename a NTFS file while it is open in some process? You can't. On Unix, linking and unlinking of open files is permitted, and many utilities depend on that behavior.
While it may be possible to certify NT as "POSIX-compliant" (or even get Unix branding, I don't know), it will never work truly like a Unix system. There are just too many core differences.
The only emulator that ships with AlphaNT is the NTVDM, which emulates real-mode x86 for 16-bit Windows and DOS apps.
You can download FX!32 for AlphaNT, which emulates 32-bit x86 Windows apps. It's an optional part of the system however.
Perhaps you are referring to the fact that most ISV's didn't port their x86 apps to Alpha, so an emulator was needed for most packages (e.g. MS Office). Too bad the ISV's don't think anything but x86 exists... that I suspect is the real downfall of AlphaNT, and Microsoft's whole "NT portability" strategy.
Windows NT already runs on alphas (no comment on "runs"), albeit not as well as on comparable X86 hardware, since it has to go through a translator first.
No, it doesn't. NT runs on Alpha in its native instruction set, though they had to bastardize the 64-bit address space to do it. The VC++ compiler for Alpha was really written by Digital, and is quite good. But AlphaNT has been abandoned, so none of that matters anymore.
It's probably true that Microsoft used Alphas extensively for their 64-bit development. (Win2k certainly existed for Alpha, but it's not 64-bit yet.)
But, I still have not had any luck compiling a kernel for my Alpha other than the standard RH kernels. Either that, or they would be remarkably unstable. Not sure if anyone else has had this problem.
I haven't. But I haven't tried a 2.3.x kernel either. 2.2.14 has worked very well for me. Are you trying to build a generic kernel, or one tailored for your machine?
As far as SRM goes, I didn't realize that Compaq dropped the support for it.
You mean they dropped AlphaBIOS...
Maybe I should look at SRM again. It might be worth checking out. I believe I read somewhere that you could not switch back from AlphaBIOS->SRM.
Nonsense. I don't have the SRM info offhand, but you can probably find out from www.alphalinux.org. Changing your console firmware means simply flashing the new version in. Some systems (Multias) have the capacity for both in ROM, most don't. You don't want to flash too often though, the flash ROM has a certain lifetime. Also you probably will not be able to run NT once SRM is installed.
Slashdot Mirror
My point? Shame on Dell for posting results from 2 wildly different studies on the traffic any given hardware can support. Shame on Dell for trying to pose NT as the "high-traffic" solution and Red Hat as the low-traffic solution when you have the same hardware. If they start complaining about not selling any Linux servers, then ads like this will be to blame (I've seen the advertisement, and it's completely nuts).
Nuts. Shame on any CIO who believes it. The ad is no more or less than I'd expect from Dell's marketing department. They are desperately trying to hold their lead in hardware sales. Dell has made pacts with Intel and Microsoft and is very afraid of their market right now.
The truth is, Apache can serve over 200 _dynamic_ requests per _second_ on an SMP box. I've done it.
ugh... I meant uniprocessor of course.
1) Dell printed an ad that said Linux/Apache tops out at 20k-100k requests per day.
2) Your CIO saw the ad.
3) Your CIO believes Dell without questioning or thinking about their claims.
The issue here isn't Linux vs. Win2k, nor is it Apache vs. IIS. Dell isn't the problem either. If Dell can make idiotic claims like this and people believe it, they win.
If I were GM and published an ad saying "don't buy that Ford car, it won't go faster than 20 mph" would anybody believe me? Or would common sense prevail?
Once people stop thinking, the marketdroids are in control. Let's not let that happen.
Say my Apache box serves 100k pages a day. That's over 4k per hour. Suppose my peak traffic is during the business day, OK, that's still not more than 12k per hour, or 200 a minute.
The truth is, Apache can serve over 200 _dynamic_ requests per _second_ on an SMP box. I've done it.
It's very possible somebody has a website that tops out at 20k per day. That site would be annoyingly slow under light traffic, and useless with heavy traffic. The problem also would have nothing to do with choice of web server, OS or even hardware (my '486 can do better).
I have Apache running on WinNT (don't ask) serving far more than that, on a fully dynamic, database-driven site. Yet the box shows only a slight load most of the time. It would do no worse running Linux. And BTW this is the public site for a Fortune 500 company.
Yet instead of laughing at this ad, as he should, your CIO wastes your time (and slashdot's time) with it. That's pathetic. I don't know whether to laugh or cry.
Yes, Compaq seems to be quite happy with Intel chips, no make competition inhouse. ;-)
Come again? The Compaq sitting next to my Alpha has AMD inside. Compaq seems to have their eggs in plenty of baskets.
I wish Compaq would commit to keeping the line running, at least for a few years.
And so on. I don't know how these things start, but folks, Alpha is not going away. Sheesh.
If either the Alpha or MIPs were viable processors, one of them would have ended up owning the server marketplace.
Wrong. Viability doesn't produce or imply mindshare, which is prerequisite to "owning" the marketplace (if that's even possible).
And the industry is getting psyched up for the Itanium.
The industry is also preparing for a letdown. Why do you suppose it isn't shipping in volume? Why have SGI and HP backpedaled on their plans for IA-64? The success of IA-64 rides on some revolutions in compiler technology that simply haven't happened.
Sparc: Possible contender
Sure, Sun has good marketshare... but where is the OEM market? How much of their volume is Sun branded hardware?
Itanium: Probable winner
Sledgehammer: Expected no-show
Don't count your chickens before they hatch.
Alpha: Dying, Also Ran
Show me evidence that Alpha is dying. Compaq unleashed their GS series (Wildfire), the OEM business is growing, many niche markets depend on Alpha (Himalaya, VMS, NetApp Filer, scientific/technical computing). They don't appear to lead in any MAJOR market (e.g. desktop, web server), but overall they are strong.
MIPS: Out of production, Also Ran
Again, show me proof. If MIPS is out of production, what is SGI selling these days???
HPPA: Possible contender if anyone knew about 'em.
They have no market outside of HP.
Once again, you've left out PPC, and failed to convince that Itanium will win anything based on hearsay.
Let me get this straight... you have doubts about the viability of Alpha and MIPS, both of which pioneered RISC computing but you include IA-64 and Sledgehammer, one of which is struggling to get to market and the other that doesn't exist yet.
(yawn) Bring me real news, please.
The trouble with Athlon is that system/board makers have cut too many corners on cost.
If Athlon systems had cache/bus performance similar to current Alpha or SPARC, sure, it would be comparable to those in throughput. (It would also be comparable in price.)
Well, the "masses" buy PCs anyway, they'd never be interested in a Sun.
Alphas are a fair comparison, but I'd like to see where you can get an ev6 for less than Sun hardware. The lowest I've seen for a reasonable configuration is around $3000 USD.
Has Microsoft ever stuck to a platform for five years, let alone 20, without changing their game plan?
A: With the partial exception of IBM, nothing.
That's not completely true. The future of Compaq's Alpha processor is tied to Linux, to which they've contributed substantial code (don't know if they've done anything for Linux/x86 though).
Sun however is likely more interested in Gnome on Solaris than Linux.
Interesting counterargument. Just to add another data point... I haven't noticed any general incompetence among our NT admins, but our NT and Unix admins are hired by the same people, so we've likely applied more consistent criteria than this guy's HR.
One trend I have noticed is a sort of tunnel vision among the NT admins. They don't really know anything but Microsoft technologies, and while they can log into a Linux box and get around, it's a bit painful to watch. On the other hand, our Unix staff, which is largely self-taught, can handle NT just fine (though they prefer not to).
I also noticed the NT staff being far busier than the rest. All of our mission-critical NT servers require a substantial degree of hand holding, unfortunately... we are transitioning them to gradually Solaris and Linux machines, but our personnel is often too overworked just keeping the machines up so they cannot even plan for the migration!
So you want a microkernel. Mach provides much of what you ask for, except the fine-grained security perhaps.
It might be constructive to look at past Mach implementations and other microkernels... there maybe good reasons these architectures didn't dominate the market. They solve some problems all right, but not without introducing others.
Absolute performance is portrayed as vital by the media, and this just might have killed the microkernel. Isolating components in their own address space and passing messages doesn't come cheap. Context switching can be fast but not free. And processor design seems to be evolving in another direction, e.g. VLIW chips will benefit long blocks of straightline execution and a style of code that is becoming extinct as OOP becomes more refined.
Intel segmentation hasn't been utilized much, that's true, but it is probably impractical for **ix systems. How do you write an efficient C compiler that doesn't share one segment for stack and data? Besides, x86 has a limited number of segment registers, and writing to a segment register is not cheap.
Look for the ongoing thread "programming for segmented systems" on comp.arch if you're interested.
Because the first chips will be obsolete before the need comes. More bits can be added later without changing the ISA.
GCC has targets for just about all well known processor families (and some lesser known) but AMD is conspicuously absent. They are supported as x86 clones only. We have code generation options for i386, i486, pentium and pentiumpro, but no k6 or k7.
Surely the k7 has unique scheduling and timing characterstics that GCC could benefit from. Apparently nobody has bothered to include these in GCC, and AMD isn't doing it.
Maybe the 64-bit sledgehammer will be enough of an innovation to warrant a new backend target for GCC.
We have that faster architecture. It's called Alpha. It's already 64-bit. Is there really a sound technical reason to invent something totally new all over again?
I get the impression users don't want Alpha precisely because it isn't x86-compatible. Throwing out the cruft sounds great, but I think it worked for Apple mainly because m68k was really a lot cruftier then than x86 is now.
Why do you read Slashdot? Contributors and readers here aren't exactly Microsoft sympathizers... there are plenty of other sites for that.
It may have missed everyones attention here but 99% of all major companies USE Microsoft products.Exclusively? For desktops or servers? Please qualify. The larger a company, the more likely it is to use Microsoft products, true, but it is also more likely to use alternatives.
They use then because we are safe in the knowledge that they have been strenuosly tested for deployment in large scale organisations.Are you kidding? Do you make that statement based on your own comparitive testing, or do you really have that much faith in a software company?
Commercial software quality has been deplorable, and I'm not just talking about MS. Vendors are motivated to increase shareholder value, not help their customers.
We've tested MS products extensively in house. I've personally witnessed a staggering number of product failures, some reproducible, some not... many a complete mystery. The time I spend searching for workarounds would better be spent debugging an open source product, I am finding.
I for one, would not even consider using Linux at workThen don't. That's your choice. It doesn't invalidate the reasons anybody else runs GNU/Linux at work.
Users : Most office people are stupid with computers.Were you talking about using Linux yourself, or for your users? Or are you one of the "users"? I'm confused now...
It is difficult enough to set up a printer with Windows and I know what I am doing. It would be a nightmare with RedHat.You can't figure out printtool? Really? Have you tried?
Support : Most people do not have RedHat skills, it would be more difficult to find them.Hint 1: Most admins with BSD/Solaris/AIX/whatever experience (e.g. almost anything BUT Windows) are sufficiently qualified.
Hint 2: Many CS grads these days are quite familiar with GNU/Linux or BSD.
Qualifications : How would I be able to determine the suitability of an applicant if they do not have something like an MCSE ?Interview them, perhaps?
I have never considered an MCSE sufficient or necessary for employment. Really, it doesn't carry much weight with me. (Nor would a Red Hat certification for that matter.)
Before you dismiss my comments... I am a technical manager for a large public company, I interview and hire my own staff, I evaluate products including commercial and free software, and we do use GNU/Linux, among Windows and other systems. I'm not religious about it, I'm just pragmatic.
Would you care to tell me how Java implements String pooling?
What is string pooling? Do you mean interning?
I imagine you'll find that it keeps reference counts.
No. Much more likely you'll find a hashtable of weakly-referenced string objects.
Referencing counting is a bad idea. Besides what the other poster said, they require atomic updates and add size to each object. It sure doesn't come cheap. Even conservative mark/sweep GC is often faster than simple ref counts.
A good JIT will perform optimizations that C will never attempt, like code inlining. Inline functions are not standard C, but they are part of C++.
I modified the life source for C++, adding `inline' in a few strategic places... compiled with g++ it runs up to 50% faster than gcc.
Add garbage collection for C++ and I doubt if the HotSpot VM will do much better, if at all. At a certain level (i.e. machine instructions) they work about the same, anyway.
it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls.
Perhaps, but that is not how Alpha/Linux does it. Linux on Alpha implements most of the Tru64 system calls natively. It also can load ECOFF images, permitting it to run Tru64 static binaries with no emulation code.
This system call compatibility was convenient: Linus deliberately made Linux system call compatible with OSF/1 during its early development, as a porting aid before Alpha/Linux was self-hosting.
Note that Tru64 still cannot execute Linux binaries simply because it lacks ELF support.
It's a well-kept secret that the NT Executive has a single-rooted hierarchy, containing device nodes, named pipes, and filesystem roots. It even supports mount points, sort of, via a concept called reparse points.
Of course none of this does us any good, because the Win32 subsystem does its best to hide whatever elegance lives in the NT kernel. You can get glimpses of it... for example, try opening the file \\.\PhysicalDrive0 for reading (don't write to it, that's your raw disk sectors!).
You get the feeling that NT could have been something better if they didn't have to make it compatible with Win9x.
Oh, and BTW, NTFS on Win2k does symlinks too.
...though some (including Microsoft) have tried. It may pass POSIX compliance tests, it may run UNIX software, but there are certain differences that will be difficult or impossible to overcome.
First is the security issue. Unix has the concept of a superuser (root). NT has role-based security. "Administrator" is not special other than having more rights than user accounts, including the right to manager user rights.
The key differences are that an NT Administrator cannot open any NTFS file regardless of modes, as a Unix superuser can. Also the Administrator account cannot arbitrarily pose as other users. There is no working setuid() call. (POSIX requires setuid to exist, but it doesn't have to work... it may return EPERM unconditionally. That is just what Microsoft's POSIX subsystem does.)
Second is the executable file format. Most modern OSes have standardized on ELF. NT is one of the holdouts, still using PE (a variant of COFF). Shared libraries on NT (i.e. DLLs) are loaded and relocated by the OS, not in user space as ELF shared objects are. And DLLs have annoying limitations, like requiring data symbols to be imported/exported.
Third, file semantics on NT are tailored for Win32. Ever try to remove/rename a NTFS file while it is open in some process? You can't. On Unix, linking and unlinking of open files is permitted, and many utilities depend on that behavior.
While it may be possible to certify NT as "POSIX-compliant" (or even get Unix branding, I don't know), it will never work truly like a Unix system. There are just too many core differences.
The only emulator that ships with AlphaNT is the NTVDM, which emulates real-mode x86 for 16-bit Windows and DOS apps.
You can download FX!32 for AlphaNT, which emulates 32-bit x86 Windows apps. It's an optional part of the system however.
Perhaps you are referring to the fact that most ISV's didn't port their x86 apps to Alpha, so an emulator was needed for most packages (e.g. MS Office). Too bad the ISV's don't think anything but x86 exists... that I suspect is the real downfall of AlphaNT, and Microsoft's whole "NT portability" strategy.
Windows NT already runs on alphas (no comment on "runs"), albeit not as well as on comparable X86 hardware, since it has to go through a translator first.
No, it doesn't. NT runs on Alpha in its native instruction set, though they had to bastardize the 64-bit address space to do it. The VC++ compiler for Alpha was really written by Digital, and is quite good. But AlphaNT has been abandoned, so none of that matters anymore.
It's probably true that Microsoft used Alphas extensively for their 64-bit development. (Win2k certainly existed for Alpha, but it's not 64-bit yet.)
But, I still have not had any luck compiling a kernel for my Alpha other than the standard RH kernels. Either that, or they would be remarkably unstable. Not sure if anyone else has had this problem.
I haven't. But I haven't tried a 2.3.x kernel either. 2.2.14 has worked very well for me. Are you trying to build a generic kernel, or one tailored for your machine?
As far as SRM goes, I didn't realize that Compaq dropped the support for it.
You mean they dropped AlphaBIOS...
Maybe I should look at SRM again. It might be worth checking out. I believe I read somewhere that you could not switch back from AlphaBIOS->SRM.
Nonsense. I don't have the SRM info offhand, but you can probably find out from www.alphalinux.org. Changing your console firmware means simply flashing the new version in. Some systems (Multias) have the capacity for both in ROM, most don't. You don't want to flash too often though, the flash ROM has a certain lifetime. Also you probably will not be able to run NT once SRM is installed.