Tag Archives: file systems

Encrypt All Hard Drives!

Hard drive showing plattersIf you have the technical interest to read this, you probably do a lot of your finances with your personal computer. Taxes, monthly budgets, check printing (on those rare occasions), and tracking numerous accounts – computers are far better than people at handling such details. A typical personal computer, or smart phone for that matter, contains company names, account numbers, login credentials, and everything else an identity thief might need. This is reasonably safe as long as you don’t lose your device and/or its hard drive.

But when you replace your computer or hard drive, or (God forbid) someone steals it, your intimate financial details are “out there” unless your drive is encrypted.

Continue reading Encrypt All Hard Drives!

Boston University’s RAX Library

(circa 1973-8)

Boston University (BU) developed its own timesharing system in the 1970s for its IBM 360 and 370 mainframes. The system was based on the batch-oriented Remote Access Computing System (RACS) developed by IBM. McGill University also participated in RAX development, but their version was renamed “McGill University System for Interactive Computing” (MUSIC). Although many of the details are lost in the mists of time, both systems used some text processing tools developed at BU.

Continue reading Boston University’s RAX Library

Files using Classic FORTH

(circa 1970-85, maybe later)

The Forth programming system was developed in the late 1960s by Chuck Moore. It provided a very powerful, text based mechanism for controlling a computer and writing programs when RAM and hard drive space were extremely tight. Early implementations were routinely restricted to 8KB of RAM. Some early implementations relied exclusively on diskette drives that stored less than a half a megabyte of data.

Starting in the 1970s, typical Forth systems treated hard drives as consisting of a linear set of numbered blocks, each 1KB in size. The first block on the drive (block 0) contained the bootstrap program to get Forth started, and a small number of subsequent blocks might also contain binary executable code that was loaded into RAM when Forth started.

Following the blocks of executable code, the remaining hard drive blocks generally contained ASCII text and were referred to by number. If a programmer needed to modify part of a Forth program, he would edit the hard drive block that contained that program, and refer to the block by its number.

Here is an assessment of Forth’s file system in the context of the eight concepts noted above:

  • File storage – each file was essentially of a fixed, 1KB size. Other measures had to be used to link multiple blocks together into longer sequences of data.
  • Locating files – files were referred to by block number, and the number had to be remembered by the programmers.
  • Free space management – programmers had to remember what blocks had not been used, or which blocks contained obsolete text that could be erased so the block could be reused.
  • Easy to implement – Yes, yes, yes!
  • Speed – Very fast at the hardware level, since no hard drive searching had to take place
  • Direct vs. sequential – supported both
  • Storage sizes – no built-in limit, but this obviously became impractical as drives increased dramatically in size
  • Robustness – there is little on-disk structure to destroy, so the robustness becomes a social issue having to do with the reliabilty of the people using the system: will they forget, or resign, or otherwise be unavailable? Can others fill in the gaps left by missing people? Will the hard drive get too big for humans to keep track of its contents without a more conventional file system?