hackslash dot org

50 Years in Filesystems: 1984

Posted: 2025-03-06 18:34:11

1984 saw the rise of networked filesystems like NFS, which offered performance comparable to local filesystems, and the introduction of the Andrew File System (AFS), designed for large-scale distributed environments with client-side caching and whole-file serving. Research focused on improving performance and reliability, with log-structured filesystems like LFS emerging to optimize write operations. Additionally, the standardization of file systems continued, with work on the ISO 9660 standard for CD-ROMs solidifying the format's widespread adoption. This year highlighted the increasing importance of networking and the evolving demands placed upon file systems for both performance and portability.

The year 1984 marked a significant period in the evolution of file systems, witnessing the emergence and refinement of several key concepts that continue to influence modern systems. This blog post, "50 Years in Filesystems: 1984," delves into the notable advancements of that year, focusing primarily on the introduction of log-structured file systems (LFS) and the advancements made in distributed file systems, particularly with the Andrew File System (AFS).

The post begins by highlighting the groundbreaking concept of LFS, introduced by Butler Lampson and Howard Sturgis. It meticulously explains the core principle behind LFS: treating the entire disk as a circular log, sequentially writing all changes—including file data and metadata—to this log. This method offered potential performance benefits, especially for write-intensive workloads, by eliminating the need for seeks common in traditional file systems. The post emphasizes the innovative nature of LFS and its influence on future file system designs, even though its practical implementation faced initial challenges due to limitations in contemporary hardware. The specifics of garbage collection within LFS are also touched upon, describing how obsolete data segments are reclaimed to free up space in the log.

Further elaborating on the performance aspects, the post discusses how LFS capitalized on the sequential nature of disk writes, aligning with the then-emerging trend of larger disk caches. This alignment allowed for efficient buffering and writing of data. Moreover, the post acknowledges the initial complexities associated with LFS, including the intricacies of crash recovery and the overhead of garbage collection.

Shifting its focus, the post then explores the advancements in distributed file systems exemplified by the Andrew File System (AFS), developed at Carnegie Mellon University. It details how AFS tackled the challenges of data sharing and consistency across networks, employing caching mechanisms and client-server architecture. The post emphasizes the scalability and performance improvements offered by AFS in network environments, paving the way for future distributed file system architectures. The specific mechanisms used by AFS for managing concurrency and ensuring data integrity are briefly mentioned, highlighting the system's robustness in handling shared access to files.

Finally, the post briefly mentions the introduction of the Sun Network File System (NFS), acknowledging its significance in the landscape of networked file systems while primarily focusing on the advancements brought forth by AFS during the same period. The overall tone of the post reflects an appreciation for the innovative strides made in file system design during 1984, emphasizing the long-term impact of LFS and AFS on subsequent generations of file systems. The post positions these advancements within the larger historical context of file system development, underscoring their pivotal role in shaping the modern file systems we use today.

Summary of Comments ( 7 )
https://news.ycombinator.com/item?id=43283498

The Hacker News comments discuss the blog post's focus on the early days of networked filesystems, particularly NFS. Several commenters share their own experiences with early NFS, highlighting its initial slow performance and eventual improvements. Some discuss the influence of Sun Microsystems and the rise of distributed systems. Others delve into technical details like caching, consistency models, and the challenges of implementing distributed locks. A few comments compare NFS to other contemporary filesystems and contemplate the enduring relevance of some of the challenges faced in the 1980s. There's a general appreciation for the historical perspective offered by the blog post.

The Hacker News post titled "50 Years in Filesystems: 1984" has generated several comments discussing various aspects of historical filesystem design and the author's experiences.

Several commenters focused on the challenges and limitations of early filesystem technology. One commenter highlighted the difficulty of managing disk space efficiently with limited resources, noting the painstaking process of optimizing file placement to minimize wasted space. Another recounted the complexities of dealing with bad sectors on floppy disks and the creative solutions employed to work around them. The discussion also touched upon the evolution of error handling and data recovery techniques, with one user recalling the prevalence of data loss due to hardware failures and the lack of robust recovery mechanisms.

The conversation also delved into the specific filesystems mentioned in the original blog post, such as RT-11 and VMS. Commenters shared their personal experiences with these systems, offering insights into their strengths and weaknesses. One user praised the elegance and simplicity of RT-11, while another pointed out the limitations of its flat file structure. VMS, on the other hand, was lauded for its advanced features, such as journaling and access control lists, but also criticized for its complexity.

Some comments explored the broader context of computing in the 1980s, including the limitations of hardware and the challenges of software development. One commenter reflected on the scarcity of memory and processing power, which forced developers to be extremely resourceful and optimize their code for performance. Another discussed the difficulties of debugging software in an era with limited tools and resources.

A few comments also provided additional historical context, such as the origins of certain filesystem concepts and the influence of earlier operating systems. One user mentioned the influence of Multics on later systems like Unix and VMS, highlighting the lineage of filesystem design.

The comments collectively paint a picture of a time when filesystem design was a complex and challenging undertaking, constrained by limited hardware resources and evolving software development practices. The discussion offers valuable insights into the history of computing and the evolution of filesystem technology.

DOS APPEND

permalink

Posted: 2024-12-20 21:04:59

DOS APPEND, similar to the PATH command, allows you to specify directories where DOS should search for data files, not just executable files. This lets programs access data in various locations without needing full path specifications. It supports both drive letters and network paths, and offers options to search appended directories before the current directory or to treat appended directories as subdirectories of the current one. APPEND also provides commands to display the current appended directories and to remove them. This expands the functionality beyond the simple executable search of PATH, making data access more flexible.

The blog post "DOS APPEND" from the OS/2 Museum meticulously details the functionality and nuances of the APPEND command in various DOS versions, primarily focusing on its evolution and differences compared to the PATH command. APPEND, much like PATH, allows programs to access data files located in directories other than their current working directory. However, while PATH focuses on executable files, APPEND extends this capability to data files, specified by various file extensions.

The article begins by explaining the initial purpose of APPEND in DOS 3.3, highlighting its ability to search specified directories for data files when a program attempts to open a file not found in the current directory. This eliminates the need for programs to explicitly handle path information for data files. The post then traces the development of APPEND through later DOS versions, including DOS 3.31, where a significant bug related to networked drives was addressed.

A key distinction between APPEND and PATH is elaborated upon: PATH affects only the search for executable files (.COM, .EXE, and .BAT), while APPEND pertains to data files with extensions specified by the user. This difference is crucial for understanding their respective roles within the DOS environment.

The blog post further delves into the various ways APPEND can be used, outlining the command-line switches and their effects. These switches include /E, which loads the appended directories into an environment variable, /PATH:ON, which enables searching the appended directories even when a full path is provided for a file, and /PATH:OFF, which disables this behavior. The post also explains the use of /X, which extends the functionality of APPEND to affect the EXEC function calls, thus influencing child processes.

The evolution of APPEND continues to be discussed, noting the removal of the problematic /X:ON and /X:OFF switches in later versions due to their instability. The article also touches upon the differences in behavior between APPEND in MS-DOS/PC DOS and DR DOS, particularly concerning the handling of the ; delimiter in the APPEND list and the search order when multiple directories are specified.

Finally, the post concludes by briefly discussing the persistence of APPEND in later Windows versions for compatibility, even though its utility diminishes in these more advanced operating systems with their more sophisticated file management capabilities. The article thoroughly explores the intricacies and historical context of the APPEND command, offering a comprehensive understanding of its functionality and its place within the broader DOS ecosystem.

Summary of Comments ( 56 )
https://news.ycombinator.com/item?id=42475011

Hacker News users discuss the DOS APPEND command, primarily focusing on its obscure nature and surprising functionality. Several commenters recall struggling with APPEND's unexpected behavior, particularly its ability to make files appear in directories where they don't physically exist. The discussion highlights the command's similarity to environment variables like PATH and LD_LIBRARY_PATH, with one user pointing out that it effectively extends the file search path for specific programs. Some comments mention the utility of APPEND for accessing data files across drives or directories without hardcoding paths, while others express their preference for more modern solutions. The overall sentiment suggests APPEND was a powerful but complex tool, often misunderstood and potentially problematic.

The Hacker News post titled "DOS APPEND" with the link https://www.os2museum.com/wp/dos-append/ has several comments discussing the utility of the APPEND command in DOS and OS/2, as well as its quirks and comparisons to other operating systems.

One commenter recalls using APPEND frequently and finding it incredibly useful, particularly for accessing data files located in different directories without having to constantly change directories or use full paths. They highlight the convenience it offered in a time before sophisticated development environments and integrated development environments (IDEs).

Another commenter draws a parallel between APPEND and the modern concept of environment variables like $PATH in Unix-like systems, which serve a similar purpose of specifying locations where the system should search for executables. They also touch on how APPEND differed slightly in OS/2, specifically regarding the handling of data files versus executables.

Further discussion revolves around the intricacies of APPEND's behavior. One comment explains how APPEND didn't just search the appended directories but actually made them appear as if they were part of the current directory, creating a virtualized directory structure. This led to some confusion and unexpected behavior in certain situations, especially with programs that relied on obtaining the current working directory.

One user recounts experiences with the complexities of managing multiple directories and files in early versions of Turbo Pascal, illustrating the context where a tool like APPEND would have been valuable. This comment also highlights the limited tooling available at the time, emphasizing the appeal of features like APPEND for streamlining development workflows.

Someone points out the potential for conflicts and unexpected results when using APPEND with programs that create files in the current directory. They suggest that APPEND's behavior could lead to files being inadvertently created in a directory different from the intended one, depending on how the program handled relative paths.

The security implications of APPEND are also addressed, with a comment mentioning the risks associated with accidentally executing programs from untrusted directories added to the APPEND path. This highlights the potential security vulnerabilities that could arise from misuse or improper configuration of the command.

Finally, there's a mention of a similar feature called apppath in the REXX language, further illustrating the cross-platform desire for this kind of directory management functionality.

Overall, the comments paint a picture of APPEND as a powerful but somewhat quirky tool that provided a valuable solution to directory management challenges in the DOS/OS/2 era, while also introducing potential pitfalls that required careful consideration. The discussion showcases how APPEND reflected the computing landscape of the time and how its functionality foreshadowed concepts that are commonplace in modern operating systems.

Ascending Mount FujiNet

permalink

Posted: 2024-12-18 02:27:24

This blog post details the author's successful implementation of a FujiNet network adapter for a Tandy Color Computer 3. After encountering initial difficulties with a pre-assembled device, they opted to build their own using a kit. This involved careful soldering and troubleshooting, particularly with the SD card interface. Ultimately, they achieved a stable connection, enabling them to access a virtual floppy drive and remotely transfer files to the CoCo 3 via a local network, significantly enhancing its capabilities. The author emphasizes the improved speed and convenience compared to traditional floppy disks and expresses satisfaction with the FujiNet's performance.

This meticulously detailed blog post, "Ascending Mount FujiNet," chronicles the author's multifaceted journey to achieve robust and reliable networking capabilities for their Tandy Color Computer 3. The narrative begins by outlining the existing limitations of networking solutions for this vintage hardware, primarily focusing on the speed constraints of the serial port. The author then introduces the FujiNet project, an ambitious endeavor to implement a modern network interface for the CoCo 3 utilizing an ESP32 microcontroller. This endeavor isn't merely about connecting the machine to the internet; it involves crafting a sophisticated system that emulates legacy peripherals like hard drives and floppy drives, streamlining the process of transferring files and interacting with the retro hardware.

The author meticulously documents their methodical exploration of various hardware and software components required for the FujiNet implementation. They delve into the specifics of setting up the ESP32, configuring the necessary software, and integrating it with the CoCo 3. The challenges encountered are described in detail, including addressing conflicts with memory addresses and navigating the complexities of interrupt handling. The narrative emphasizes the iterative nature of the process, highlighting the adjustments made to hardware configurations and software parameters to overcome obstacles and optimize performance.

A significant portion of the post is dedicated to elucidating the intricacies of network booting. The author explains the process of configuring the CoCo 3 to boot from the network, leveraging the capabilities of the FujiNet system. They discuss the importance of network boot ROMs and the modifications required to accommodate the enhanced functionality offered by FujiNet. The post also delves into the mechanisms of loading different operating systems and disk images remotely, showcasing the versatility of the network booting setup.

Furthermore, the author explores the integration of specific software, such as the RS-DOS operating system, demonstrating how FujiNet seamlessly bridges the gap between the vintage hardware and modern network resources. The ability to access files stored on a network share as if they were local drives is highlighted, underscoring the practical benefits of the FujiNet system for everyday use with the CoCo 3. The overall tone conveys the author's enthusiasm for retro computing and their meticulous approach to problem-solving, resulting in a comprehensive guide for others seeking to enhance their CoCo 3 experience with modern network connectivity. The post concludes with a sense of accomplishment and a glimpse into the future possibilities of the FujiNet project.

Summary of Comments ( 10 )
https://news.ycombinator.com/item?id=42447580

Several commenters on Hacker News express excitement about the FujiNet project, particularly its potential to simplify retro-computing networking. Some discuss their experiences with similar setups, highlighting the challenges of configuring vintage hardware for modern networks. The ability to use SD cards for virtual floppy disks and the promise of future features like BBS access and online multiplayer gaming generate considerable interest. Several users inquire about the hardware requirements and compatibility with various MSX models, demonstrating a practical interest in utilizing the technology. Some express nostalgia for older networking methods and debate the authenticity versus convenience trade-off. There's also discussion of alternative solutions like the MSX-DOS 2 TCP/IP driver, with comparisons to FujiNet's approach.

The Hacker News post "Ascending Mount FujiNet" discussing a blog post about the FujiNet networking device for 8-bit Atari systems generated several interesting comments.

One commenter expressed excitement about the project, highlighting the appeal of modernizing retro hardware without resorting to emulation. They appreciated the ability to use original hardware with modern conveniences. This sentiment was echoed by others who found the blend of old and new technology compelling.

Another commenter, identifying as the author of the blog post, clarified some technical details. They explained that while the current implementation uses ESP32 modules for Wi-Fi, the long-term goal is to develop a dedicated ASIC for a more integrated and potentially faster solution. This prompted a discussion about the feasibility and cost-effectiveness of ASIC development, with other commenters weighing in on the potential challenges and benefits.

There was also a discussion about the broader implications of the FujiNet project and its potential impact on the retro gaming community. Some commenters speculated on whether similar projects could be developed for other retro platforms, expanding the possibilities for online play and other modern features.

Several commenters shared their personal experiences with retro networking solutions, comparing FujiNet to other options and discussing the advantages and disadvantages of each. This led to a conversation about the challenges of preserving and maintaining retro hardware, and the importance of projects like FujiNet in keeping these systems accessible and enjoyable for future generations.

Finally, a few commenters focused on the technical aspects of the FujiNet implementation, discussing topics like network protocols, data transfer speeds, and the challenges of integrating modern networking technology with older hardware. These comments provided valuable insights into the complexities of the project and the ingenuity required to overcome them.

Why did Windows 95 setup use three operating systems?

permalink

Posted: 2024-11-17 19:54:24

Windows 95's setup process involved three distinct operating systems to ensure a smooth transition and maximize compatibility. It began booting from a DOS-based environment to provide basic hardware access and initiate the installation. Then, a minimal Windows 3.1-like environment took over, offering a familiar GUI for interacting with the setup program and allowing access to existing drivers. Finally, the actual Windows 95 operating system was installed and booted, completing the setup process and providing the user with the full Windows 95 experience. This multi-stage approach allowed the setup program to manage the complex transition from older systems while providing a user-friendly interface and maintaining compatibility with existing hardware and software.

Raymond Chen's blog post, "Why did Windows 95 setup use three operating systems?", delves into the intricate, multi-stage booting process employed by the Windows 95 installation procedure. Rather than a straightforward transition, installing Windows 95 involved a complex choreography of three distinct operating systems, each with a specific role in preparing the system for the final Windows 95 environment.

The initial stage utilized the existing operating system, be it DOS or Windows 3.1. This familiar environment provided a stable launching point for the installation process, allowing users to initiate the setup program from a known and functional system. Crucially, this initial OS handled the preliminary steps, such as checking system requirements, gathering user input regarding installation options, and initiating the transfer of files to the target hard drive. This ensured that the subsequent stages had the necessary foundation upon which to build.

The second operating system introduced in the Windows 95 installation was a minimalist DOS-based environment specifically designed for setup. This stripped-down DOS lacked the complexities and potential conflicts of a full-fledged DOS installation, providing a predictable and controlled environment for the core installation tasks. This specialized DOS environment executed directly from the installation media, circumventing potential issues arising from the existing operating system and allowing for low-level access to the hardware necessary for partitioning and formatting the hard drive, as well as copying the essential Windows 95 system files. It operated independently of the pre-existing operating system, ensuring a clean and controlled installation environment.

Finally, the third operating system involved was the actual Windows 95 operating system itself. Once the setup-specific DOS environment completed the file transfer and preliminary configuration, the system rebooted, this time loading the newly installed Windows 95. This first boot of Windows 95 was not merely a functional test, but an integral part of the installation process. During this initial boot, Windows 95 performed crucial configuration tasks, including detecting and installing hardware drivers, finalizing registry settings, and completing any remaining setup procedures. This final stage transitioned the system from the installation environment to a fully operational Windows 95 system ready for user interaction.

In essence, the Windows 95 installation process leveraged a tiered approach, employing the existing OS for initial setup, a specialized DOS environment for core file transfer and low-level configuration, and finally the Windows 95 OS itself for final configuration and driver installation. This multi-stage process ensured a robust and reliable installation, mitigating potential conflicts and providing a clean transition to the new operating system. This complexity, while perhaps not immediately apparent to the end user, was a key factor in the successful deployment of Windows 95.

Summary of Comments ( 192 )
https://news.ycombinator.com/item?id=42166606

Hacker News commenters discuss the complexities of Windows 95's setup process and the reasons behind its use of MS-DOS, a minimal DOS-based environment, and a pre-installation environment. Several commenters highlight the challenges of booting and managing hardware in the early 90s, necessitating the layered approach. Some discuss the memory limitations of the era, explaining the need to unload the DOS environment to free up resources for the graphical installer. Others point out the backward compatibility requirements with existing MS-DOS systems and applications as another driving factor. The fragility of the process is also mentioned, with one commenter recalling the frequency of setup failures. The discussion touches upon the evolution of operating system installation, contrasting the Windows 95 method with more modern approaches. A few commenters share personal anecdotes of their experiences with Windows 95 setup, recalling the excitement and challenges of the time.

The Hacker News post "Why did Windows 95 setup use three operating systems?" generated several comments discussing the complexities of the Windows 95 installation process and the technical reasons behind using MS-DOS, a 16-bit preinstallation environment, and the 32-bit Windows 95 itself.

Several commenters focused on the bootstrapping problem inherent in installing a new operating system. They pointed out that a simpler OS is required to launch the installation of a more complex one. MS-DOS served this purpose in the Windows 95 setup, providing a familiar and readily available platform to begin the process. The discussion included how the initial boot from floppy disk would load a basic DOS environment, which would then launch the next stage of the installation.

The role of the 16-bit preinstallation environment was also discussed. Commenters explained that this environment, distinct from both MS-DOS and the final Windows 95 system, was crucial for tasks that couldn't be handled by the limited DOS environment, such as accessing CD-ROM drives and managing more complex hardware configurations. This intermediary step allowed the setup to gather information about the system, prepare the hard drive, and begin copying the necessary Windows 95 files.

Some commenters delved into the technical limitations of MS-DOS, highlighting its 16-bit architecture and inability to directly handle the 32-bit components of Windows 95. The preinstallation environment bridged this gap, providing the necessary functionality to transition to the 32-bit world. This discussion touched upon the complexities of real-mode and protected-mode memory addressing, which were relevant to the transition between these different environments.

The specific use of three separate systems was a point of interest. Some commenters speculated about alternative approaches, but acknowledged the practical constraints of the time. The existing familiarity with MS-DOS made it a logical starting point. The distinct preinstallation environment provided a dedicated space for setup-specific tasks without interfering with the final Windows 95 installation.

A few comments also touched on the nostalgia associated with the Windows 95 installation process and the challenges of managing hardware configurations in that era. The need to manually configure drivers and settings was highlighted, contrasting sharply with the more automated installation processes of modern operating systems.

Stories with Tag MS-DOS

50 Years in Filesystems: 1984

Summary of Comments ( 7 ) https://news.ycombinator.com/item?id=43283498

DOS APPEND

Summary of Comments ( 56 ) https://news.ycombinator.com/item?id=42475011

Ascending Mount FujiNet

Summary of Comments ( 10 ) https://news.ycombinator.com/item?id=42447580

Why did Windows 95 setup use three operating systems?

Summary of Comments ( 192 ) https://news.ycombinator.com/item?id=42166606

Summary of Comments ( 7 )
https://news.ycombinator.com/item?id=43283498

Summary of Comments ( 56 )
https://news.ycombinator.com/item?id=42475011

Summary of Comments ( 10 )
https://news.ycombinator.com/item?id=42447580

Summary of Comments ( 192 )
https://news.ycombinator.com/item?id=42166606