As part of the bootstrap process, the computer loads bootstrap programs with an ever-increasing ability to manipulate the hardware and access files from the UNIX filesystem. In 386BSD, the ROM BIOS starts the process by reading the first block of disk storage off the disk, and then executes its contents as an ordinary program. This tiny program has the sole responsibility of reading in a program 15 times its size and located on the next successive blocks on the disk drive. In turn, this larger program has the responsibility of deciphering the UNIX filesystem located adjacent to it on this disk drive, and extracting the next bootstrap program from the file "/boot" in the filesystem. This final bootstrap program can be arbitrarily large (bounded by physical memory) and can load programs from all possible devices on the computer. This bootstrap can also determine which device to load the operating system from, the configuration of the processor prior to boot, and power-fail or crash-recovery steps. It can also decide whether the system should automatically reboot itself or pause and await manual intervention to remove an obstacle inhibiting automatic reboot; it can be interrupted by an operator if he wishes to change his mind and insist on alternative actions. Thus, the bootstrap can be used to load other standalone programs that might be used for disk formatting, recovery, or installation, as well as loading the operating system itself (the file /vmunix). In a sense, when the bootstrap is loading, you might call the filesystem it is using the "boot filesystem"!
A similar chicken-and-egg problem occurs when we decide to run the initialization process (/sbin/init) to initialize the subsequent user program operation of the system. Because UNIX systems only know how to execute a program from a file in a filesystem, we need a filesystem from which to execute files. Thus, the root filesystem is the first filesystem accessible, via a kind of "virgin birth." All other filesystems will be explicitly attached to it via the UNIX mount command, which tapes the base (or root) of the filesystem to be mounted onto an existing directory in the root (the "mount" point).
Non-UNIX systems have an entirely different perspective regarding bootstrapping. Usually, the given system is kept on a special, dedicated location on the disk, frequently adjacent to bootstrap code. Sometimes, the equivalent of the UNIX /sbin/init program is also found in this special location. Therefore, these programs require special installation onto the disk, and the system does not require the concept of a "root" filesystem, because it does not require a filesystem to become active.
Note also that we have one file-naming convention in UNIX, so that even devices are named just like ordinary UNIX files (/dev/wd0a or /dev/console, for example). This is different from MS-DOS or VMS, where two namespaces are present at any time: the device namespace (A: or DKOA:) and the file pathname (\foo\bar\bletch or [foo] bar,bletch;2). With UNIX, the filesystem is a central concept, along with the global way in which it is used and reused to provide a sole namespace for file objects. In a sense, the originators of UNIX felt this concept to be so important, that in follow-on-work (such as Plan 9, see DDJ January 1991), the filesystem is even more central to the system, by becoming a way of expressing interprocessor, window system, and program communications metaphors.