Slashdot Mirror

with the IE api hooks into the kernel

1. The Object Manager provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to /dev/hda1.
2. The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
3. Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
4. Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
5. I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.

Not "new technology" at all. VMS is, what, two years younger than the original Bell Labs UNIX? Please.

The Windows registry on NT is provided by the Configuration Manager, a kernel mode executive subsystem. The CM exports its own type of object, the Key object, which is handled like any other type of kernel object. A registry key consists of an ACL, a set of values, and a set of subkeys arragned in a hierarchy. Each non-volaitle key is backed by a file, known as a registry hive; subkeys can be stored in the same hive as the parent or be mounted from a different one. Hives are opened and locked by the kernel and are journalled to prevent corruption.

/etc uses the filesystem database to store configuration groups directly and different formats for each type of file to store entries. Security is provided for each file.
The registry uses a specialized database that is aware of each line of data; it provides enough metadata to distinguish between strings and integers and binary data, providing a string label for each item. Security is provided for each key.
Although you can arrange keys and values any way you like, key level security usually provides a lot more granularity than file level. The standard config consumer on UNIX has one file for config, even if there are many entries. The standard on Windows is to give each app a base key which can contain as many securable subkeys as needed.

Both are databases. Given the choice between a general purpose format that leaves the details up to each client to re-invent and a specialized database designed specifically for configuration, which one sounds better? Which one is easier to use in a standardized way?

buying PowerQuest (Norton Ghost)

Norton bought powerquest recently for Partition Magic, not for PowerQuest DriveImage. They already had a drive imaging product (Norton Ghost) from their purchase of Innovative Software sometime in the late 90s.

You can log in as many times as you want, remote or local. This has been true since the very first version of NT; NT has always been multi-user. See AT, telnet, any one of the many SSH servers, etc. Oh, you meant GUI sessions? Does UNIX require X to be multi-user?

One of the core kernel subsystems is the Object Manager. It handles all kernel objects accessible from user mode, handles to them and security on them; everything from files to events to mutexes to processes to memory sections. It has existed since the first version of NT and provides object security integrated in the system.
A token object represents a process or thread's security identity and priviliges. TCB components can add whatever privilieges they want to them; elevate them to whatever level. Perhaps you just don't know how.

relevant studies universally show this is not true.

Time to market was simply not a factor in the design and implementation of Linux

and security was focused on starting at line 1 of the code for the Linux kernel.

Don't become too attached to M$ operating systems.

with the IE api hooks into the kernel

Technically, in a really literal minded sense, that's correct. Technically, any Win32 component or control can be replaced. In practice, the way that Microsoft has built the system too much depends on the HTML control and Windows Explorer.

For the latter, instead of mounting devices like my Jornada in the file system, they're shown on the desktop but are only there via a plugin for Windows Explorer, so without it I can't browse my Pocket PC.

I can't have a great deal of faith in that design. There's just too much shared state between components of Windows, and too little control over the implementation of security boundaries: every component seems to have its own call gates, with multiple independent implementations of the same security and sanity checks on arguments and objects.

The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.

So do I. Maybe Reactos?

The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS.

Yes, Win32 IS insecure, to a point. Window station, desktop and job objects are securable objects that NT adds that can be used to partition Win32 into sandboxes. They just aren't used much.

Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.

Most built in services are written for the Win32 subsystem since the user mode service control manager's interface is part of win32, but several have only superficial dependencies. The SMB client and server come to mind.

I thought that the NT had more, not less things running in kernel mode. Nothing in kernel mode depends on win32, ever. The only thing related to win32 that runs in kernel mode is win32k.sys, the server part of win32. Nothing in the kernel depends on win32, or can even use win32. Moving win32 into kernel mode didn't change that.

What, specifically, in Windows is implemented as a user-mode win32 dependent service that would normally be a kernel module in UNIX?

Also, there is no such thing as THE UNIX kernel. There are UNIX kernels such as Linux or OpenBSD's kernel, but no one 'true' UNIX kernel.
Compared to Linux, the NT kernel and executive services (ntoskrnl.exe) do a couple of things that Linux doesn't: the Configuration Manager AKA the Registry; a database for configuration info, the extensible Object Manager (althought the VFS comes close), and a dedicated local proceduce call facility (you can use pipes under either, but only NT has LPC) If you include all the modules that run in kernel mode (besides win32), there is more: SMB: the client is in mrxsmb.sys and the server is in srv.sys, MUP (mup.sys), CD burning support (as a filesystem), audio processing, the mailslot filesystem (msfs.sys), the named pipe filesystem (npfs.sys), plus all the things you'd expect: filesystems, bus drivers, USB drivers, and network stuff.

If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in.

Invites? How's that?

Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need.

NT isn't any more vulnerable to privilege escilation than UNIX is. Just because the security model is complex, doesn't mean it is broken. It may be harder to use, but it also provides much granularity (if you use it). For the last part, I don't understand what you are trying to say; how is this different from any other security model? Define a user's permissions so that they can do everything they need to. ACLs can be changed, but you should be able to set them up once.

To top it all off, there's no hard "system call" interface between different security domains.

Sure there is. It's called the Native API. The only way to request services of the kernel is through the system call interrupt, and all those functions are exported by ntdll.dll. Win32k adds an extra function table, though; it exports the services that used to be in us

How has the architecture changed to make it insecure? Not the implementation, but the design. Be specific.
I think it has gotten MORE secure in design than it was: Active Directory with Kerberos, job objects that enforce quotas, deny-only SIDs, restricted tokens and SIDs, deleted privledges, SAM encryption, NTLMv2, group policies, a replacable GINA, Windows authentication packages (aka SSP)...

David Cutler, the main NT designer, and his staff were working on Mica, but Digital cancelled it and laid them off. Although Microsoft hired most of the VMS/Mica/Prism staff, no source code was actually copied. It's not suprising that the same team would create something very similar.

GDI and Win32 can share handles with other processes because the executive Object Manager allows you to add your own types of objects; anyone can do it. It's like Linux's VFS; would you be suprised if user programs could create files, pipes or sockets which could be shared? The difference is that NT will let you create entirely new types of objects, with new properties. The object manager handles the existance of objects and handles to them: what the objects actually do is up to the provider.

The registry is implemented in the Configuration Manager. It is an executive service, one level up from the kernel. It is this low because the device database is implemented using the registry.

First, the link is http://www.winntmag.com/Article/ArticleID/41480/41 480.html (no e in winnt).

Second, who says Cognos sublicensed from Microsoft? Cognos is in the financial reporting business (and has been in it for quite some time). So Cognos probably infringed on the patents (if they were ever valid in the first place) all on their own.

The OS (as Linux and many others do) can check why the pagefault happened and raise a segfault if it's being loaded at CS:PC and shouldn't be. Note that this is quite do-able even without NX or the like, the reason MS-Windows doesn't do more checking along those lines is because the internal structure is too chaotic (it really has degraded quite a bit since it was VMS 5.0 (AKA MICA) - or at least, spelling-error compatible with it).

NX-style bits and better have existed since at least DECsystem-10 days; their absence from the x86 architecture is mute testimony to its inherent bankruptcy. And I should add in the true spelling/grammar Nazi spirit that discussion of lesser architectural flaws is moot.

...by doing what Apple did: Build your wimpy OS on top of something strong, like BSD, Linux, or some other flavor of *NIX.

<snicker> Uh, what, something strong like VMS, perhaps?

They've munged it so much that it's taken until now to make an OS that almost doesn't suck, but that doesn't mean the foundation isn't there.

NT was planned as being a microkernel, but isn't.

Today, most of these features have been implemented in Linux (even though AFAIK there's still no equivalent of NT's completion ports). This is what Russinovich means when he says that Linux has been playing catch-up - he doesn't talk about portability, security, etc, he's only looking at one particular side of things.

But I'm particularly entertained by the fact that security is the lead-in -- "Security and the way windowing is handled remain two of the diminishing differences between Linux and Windows" -- and then isn't mentioned AT ALL until the very end of the article, with no examples whatsoever, and no indication as to which OS is playing catch-up.

Way to hide your biases, ZDNet.

If you're talking about the link between NT and VMS, this or this would be a much better read. If not, then... what the hell are you talking about?

Windows XP, for example, isn't all that great in this area, and often one process can too easily slow things down. This is even further emphasized when all the processes you're working with are actually the main "explorer.exe" process; eg, you do something in Windows Explorer that blocks (spin up a CD drive) and everything else (the "desktop", task bar, etc) all become unresponsive...

The kernel hasn't slowed down in that case; it's the GUI layer which has slowed down. It hit a bottleneck.

Interestingly, it would appear that Windows has used an O(1) scheduler in Windows NT and up since at least NT 4.0 (which came out in 1996).

It's also interesting to note that it has the same priority-boosting for IO threads that Linux has.

"Windows NT also uses additional priority adjustments based on other events, such as momentarily boosting thread priority when it returns from an I/O call"

Detailed explanation of the NT4.0 scheduler

Easier to read version of the above

Part 1 of a slightly more indepth (but in some places inaccurate)* article

Part 2 of the article

*The article makes it sound like it's O(N) in places; it's not. The scheduler is using a set of priority lists, which are kept in-order at insertion time when a thread exits its context, by the thread inserting itself at the end of the list for its priority.

Windows XP, for example, isn't all that great in this area, and often one process can too easily slow things down. This is even further emphasized when all the processes you're working with are actually the main "explorer.exe" process; eg, you do something in Windows Explorer that blocks (spin up a CD drive) and everything else (the "desktop", task bar, etc) all become unresponsive...

The kernel hasn't slowed down in that case; it's the GUI layer which has slowed down. It hit a bottleneck.

Interestingly, it would appear that Windows has used an O(1) scheduler in Windows NT and up since at least NT 4.0 (which came out in 1996).

It's also interesting to note that it has the same priority-boosting for IO threads that Linux has.

"Windows NT also uses additional priority adjustments based on other events, such as momentarily boosting thread priority when it returns from an I/O call"

Detailed explanation of the NT4.0 scheduler

Easier to read version of the above

Part 1 of a slightly more indepth (but in some places inaccurate)* article

Part 2 of the article

*The article makes it sound like it's O(N) in places; it's not. The scheduler is using a set of priority lists, which are kept in-order at insertion time when a thread exits its context, by the thread inserting itself at the end of the list for its priority.

Actually, they do own a lot of DOS and sued microsoft over it not that long ago...

http://www.winntmag.com/Articles/Index.cfm?Article ID=8045

... as shown several times when their updates causes 3rd software to break ...

It's even worse when done by design. Once a scoundrel - always a scoundrel.

what would you have me do? Post the entire source of NT and VMS and then some sort of algorithm (vetted by you?) that proves that the code is different?

What you could do is e.g. post a URL that discusses the VMS vs NT differences, rather than continuing to make flat assertions based on your (anonymous) authority...That's what m_pll did (thanks m_pll!), and isn't this interesting, the Win NT magazine article highlights the zillion ways that NT is based on VMS. Some highlights:

- "[the VMS] kernel and Executive subsystems are clear predecessors to NT's"
- "In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went...
Nevertheless, the migration of VMS internals to NT was so thorough that within a few weeks of NT's release, Digital engineers noticed the striking similarities."
- "Those similarities could fill a book. In fact, you can read sections of VAX/VMS Internals and Data Structures (Digital Press) as an accurate description of NT internals simply by translating VMS terms to NT terms."
- "NT's processes are virtually the same as VMS's processes."
- "Microsoft added lightweight user-mode threads support to NT 4.0 in 1996, which it copied from the VMS implementation of threads."
- "NT's I/O Manager is closely based on VMS's I/O Manager. Both OS's I/O Manager support a layered-driver model throughout the device driver stacks for different device types and implements asynchronous packet-based I/O commands, and its device drivers dynamically load and unload."
- "As you can see by comparing Figure 2 and Figure 3, page 117, the Executive subsystems exhibit the most significant resemblance between VMS and NT. But many minor similarities exist in which it is clear that Microsoft derived NT's capabilities from VMS."
- "...Therefore, VMS's security implementation is the predecessor to NT's. Microsoft even included systems tools similar to VMS's in NT, including the Performance Monitor, which is based on MONITOR, the extensible VMS performance monitor. VMS included a utility called BACKUP long before Microsoft developed NT's backup utility."
- "...Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."

So, before I was just asking, not making an assertion. But NOW I will make the assertion: NT is clearly derived from VMS, based on the above facts.

And for this I get slammed by a bunch of anonymous cowards and anonymous supposed NT developers? Give me a break.

All I did before was ask for facts rather than assertions. What I got were some angry but empty words. Rather telling.

Google for nt+vms. On the first page there is this link:

Windows NT and VMS: The Rest of the Story .

... and a microkernel does the job perfectly.

It certainly makes it easier to protect against buggy software, but I wouldn't say that a microkernel makes it impossible for a buggy program to take out the system, or for a buggy program to be rendered useless by the "right" kind of attack. And of course there's the whole issue of making your microkernel itself defect-free, but that's a whole other issue.

To make any one piece of software reliable, you need to be sure that it, in and of itself, has no major defects. Over-engineering doesn't help. Modularisation, privilege separation, chrooting, etc certainly help if your only concern is ensuring that the system's hard to break into - they don't do a heck of a lot to assure the system's availability. These things - and all the other techniques to help make software systems reliable - do not in and of themselves, or when all combined, make for software which can be considered reliable.

Even Tandem - who were, in their time, reknowned for making reliable computing software and systems, and did "all the right things" - have had their fair share of system-crippling software-induced failures. It doesn't take a security bug to bring down a system into an unusable state, and one software-reliability-related lawsuit can always be used as a precedent in any future software-reliability-related lawsuit.

Actually, they did just that when they aquired DR-DOS from Novell a few years back.

see?

But back then when Caldera sued M$, we (well most of us, including myself) were on the side of Caldera.

Noone seems to remember the details, you can read one account here. Basically, they were suing because there was explicit code in windows that said that DR-DOS would not work, but DR-DOS was "DOSy" enought to do the job.

Althought, M$ settled for a cool $150mil, I believe (and apparently they did too) that they would have lost in trial.

Here are a few links about it->
1
2
3

During the 80s, the UNIX with the biggest user base was... XENIX (made by none other than Microsoft), which was later sold to SCO, and which was one of the systems used as a basis for the POSIX standard. NT (and, subsequently, W2K and XP) does comply with a big chunk of the POSIX standard (I suspect one of the reasons was to make it easier to port software from Xenix to NT - Microsoft didn't want to lose market share to the other UNIXes). In some ways, though, NT is closer to VMS than to XENIX.

Two old but interesting articles about the evolution of NT:

http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=4500

http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=449

NTFS has other nice features such as symbolic links, named streams, non-continuous files, etc.. I learned a few tricks a couple of years ago in a newsgroup discussion from a guy working at Microsoft. Some of these features appear to be completely undocumented (or at least the documentation is very well hidden).

RMN
~~~

During the 80s, the UNIX with the biggest user base was... XENIX (made by none other than Microsoft), which was later sold to SCO, and which was one of the systems used as a basis for the POSIX standard. NT (and, subsequently, W2K and XP) does comply with a big chunk of the POSIX standard (I suspect one of the reasons was to make it easier to port software from Xenix to NT - Microsoft didn't want to lose market share to the other UNIXes). In some ways, though, NT is closer to VMS than to XENIX.

Two old but interesting articles about the evolution of NT:

http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=4500

http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=449

NTFS has other nice features such as symbolic links, named streams, non-continuous files, etc.. I learned a few tricks a couple of years ago in a newsgroup discussion from a guy working at Microsoft. Some of these features appear to be completely undocumented (or at least the documentation is very well hidden).

RMN
~~~

Mark Russinovich's article doesn't seem to agree with you. According to that article they are *very* close. No...not clones but they apparently share a lot of similarities.

Quoth Ballmer:Linux itself is a clone of an operating system that is 20-plus years old. That's what it is. That is what you can get today, a clone of a 20-year-old system.

Hmmm... Perhaps he should read this article, wherein the similarities between NT and VMS are brought to light. VMS 1.0 came out in 1977, according to the article.

In summary, glass houses, stones, etc.

If we're going to use a OS derived from the 1970s, let's at least pick our favourite and be grateful Linus wasn't a VMS fan :-)

One can't deny that NT was "based" on VMS.

In fact I recall reading somehere that MS was initially promoting NT as VMS on the desktop, or something along those lines.

GameTab - Game Reviews Database

Have to disagree. I dislike the NT user interface and to do anything complex with the administration is a nightmare, but the NT architecture itself is fairly solid. The kernel was designed and implemented by a large chunk of Digital's VMS development team based on their experiences writing VMS (the first commercially successful "enterprise level" multitasking OS). This article gives a few details of the features in the original NT 3 kernel and goes into some detail about the similarities between NT and VMS.

some articles:

• Windows NT Architecture (2 parts)
• Windows 2000 Architecture
• The Foundations of Microsoft Windows NT System Architecture
• Windows NT 4.0 Workstation Architecture
• UNIX and Windows Compared

I think that Microsoft did develop NT themselves, but with much help from some of the same guy that did VMS (basic googleing turned up this.

Yep, but now that is irrevelent. Microsoft has combined their code bases for home and business OS's into XP (or so they claim). The Windows95 track is dead, NT is dead. The hybrid OS that would serve both business server needs and home user gaming needs that was promised to us in MS timelines in 1993 is finally here with XP. Or so they say. Apparently not?

You got that right! :)

The problem is, although Windows 95/98 and Windows NT (as an add-in for NT 3.51, and integral in NT 4) share a similar UI, the Win32 API that each platform supported was markedly different. Windows 9x lacked the security APIs and (for a long time) OpenGL, whilst NT did not have the direct hardware access that Windows 9x could fall back on. Also, the hardware driver architechture was completely different between the two.

This was one of the problems that caused the release of what would become Windows 2000 to be pushed back - the new Windows needed to support the features and idiocyncrasies of both platforms, in order to support the *applications* that were being used on either platform. This was the crucial part - it didn't matter how technically superior the new Windows was, if the customer's existing applications wouldn't run properly then it would sink, and quite possibly take Microsoft with it. (Remember, Windows 2000 was the *only* option at this point, there was no Plan B waiting in the wings).

Some links for your further enlightenment :

Microsoft Windows History
Another potted history of Windows (warning - pop-ups lurking here!)
The official word on the name-change to Windows 2000, from Microsoft PressPass
An article on the historical links between Windows NT and VMS (They're more related than you think!)
'Why Windows NT 5.0 Will Make the World a Better Place', written in September 1997(!) by Jesse Berst for ZDNet Anchordesk. Gives a run-down of the feature list at that time, and also gives a figure of how long NT 5.0 had been in development at that point.
'New Windows could solve age-old puzzle', courtesy of News.com - a write-up of the (in)famous Cairo project, and where it fits into the Windows story.

Food for thought, I thing you'll agree.

No I mean NT.

For details see Windows NT and VMS: The Rest of the Story

Could it be for the same reason people who have "high speed internet connections" still place charge by the minute long distance calls instead of using voice over IP, or crawl to a company like Yahoo to be a middleman? Look to Redmond, there you will see the answer. Anti-competitive, greedy stupid shit. Remember the 64 bit Alpha? You would think it would be cheap to make by now, no? Sorry, that might hurt someone's bottom line.

In short, I'd love to use one but I'm not going to get my hopes up.

Spare me the smoke and vapor. Don't you remember the sad story of Mica, errr, NT on Alpha? Loudly proclaimed, quietly killed, that's why I think they are not there. If you consider the number of bugs and holes in 32bit M$ work, you might conclude they never arived anywhere.

In the mean time, you can get Linux and BSD on Alpha and other 64 bit platoforms:

• Debian
  
• Red Hat
  
• BSDs, free, net, open
  
• and plenty of others less well known.
  

Oh, it hurts so much to remember and think!

Uh, sorry, but this is just plain wrong. Microsoft took the code they had from OS/2 and made it into Windows NT.

Uh, sorry, but this is just plain wrong. NT is the product of VMS engineers bringing their talents and experience into a different product.

Ever wonder why the first release of Windows NT was called '3.1'?

No, actually. It was to avoid maturity confusion between NT and Windows 3.1. Releasing Windows NT as 1.0 would have made marketing less effective. Given it had the same UI as Windows 3.1 was another reason.

While your last paragraph is true, it hardly constitutes receiving a score of 5. Moderators need less crack.

Linux is closer to UNIS than NT is to VMS, but not much, and not very much at all in the lower levels of the OS..

I ran VMS systems for years and it's a lot less friendly the *nix, but it's a hugely stable and coherent OS. In four years of running VAXes I had *two* occassions where the thing crashed unexpectedly, and both times Digital took away the dump tapes for analysis because they treated system crashes seriously.

In the business I work in, we use OpenVMS on Alphas to run our warehouse system. It's a solid, reliable and very dull OS which is exactly what we want.

And for security, OpenVMS is a DoD certified C2 product, with a variant (called SEVMS) which is certified B1. I have a list here which includes current-ish product links.

Look, the VMS vs Unix argument has been raging since 1978 when the VAX-11/780 came out. The fact that both these OSes are decades old means that they're both strong OSes and have a lot of life in them yet.

NT was based on VMS, not Unix. You may be thinking of the TCP/IP stack that was sourced from BSD.

NT 4 had time synchronization, but it came front and center with Windows 2000 (which automatically time sync with your domain controller, which itself should be configured to sync with a master authority) because of Kerberos as implemented in Windows 2000 and beyond : Time is one of the parameters, so if Bob's PC is 20 minutes ahead and his kerberos keys are by a different clock, security conflicts will arise (namely, his keys will be refused). Of course, anyone with XP can bring up the clock applet (double clicking on the clock in the system tray) and choose the Internet Time tab that allows them to change the server to a different one if they so desired (or disable it all together).

MS has roots in Linux, just like almost every other software shop that's still alive.

I think you mean Unix, they had their own flavor of Unix once, XENIX. But NT/2000/XP aren't derived from this, they get their Unix like properties via their VMS heritage.

The software raid [tldp.org] driver in linux makes these large arrays easy with a trivial amount of hardware behind it.


Windows 2000, I might add, has dynamic disks, which allows, in addition to software RAID, resizing partitions on the fly without even a logoff, and other cool stuff, like partition table replication. Partition table corrupted? No problem! Just replicate the database from another dynamic disc in the system [click, click] and you're set!