Stories with Tag OS

• InitWare, a portable systemd fork running on BSDs and Linux

  permalink

  Posted: 2025-04-03 12:11:51

  Verbose tl;dr

  InitWare is a portable init system inspired by systemd, designed to function across multiple operating systems, including Linux, FreeBSD, NetBSD, and OpenBSD. It aims to provide a familiar systemd-like experience and API on these platforms while remaining lightweight and configurable. The project utilizes a combination of C and POSIX sh for portability and reimplements core systemd functionalities like service management, device management, and login management. InitWare seeks to offer a viable alternative to traditional init systems on BSDs and a more streamlined and potentially faster option compared to full systemd on Linux.

  InitWare presents itself as a portable and lightweight reimplementation of systemd, designed to operate on a wider range of operating systems, specifically including various BSDs (FreeBSD, OpenBSD, NetBSD, and potentially DragonFly BSD) and Linux. The project aims to provide the core functionality and perceived benefits of systemd without being tightly coupled to the Linux kernel or GNU userland tools.

  Key features and goals of InitWare include:

  • Cross-platform Compatibility: A primary focus is on operating seamlessly across multiple operating systems, offering a unified init system experience regardless of the underlying kernel or userland. This allows users familiar with systemd on Linux to leverage their knowledge on BSD systems.
  • Reimplementation, Not a Port: InitWare is built from the ground up, drawing inspiration from systemd's architecture and functionality but not directly porting its existing codebase. This approach allows for greater flexibility in adapting to the specific requirements of different operating systems.
  • Lightweight Design: InitWare strives to maintain a smaller footprint than systemd, potentially resulting in faster boot times and reduced resource consumption, especially on resource-constrained systems. This is achieved by focusing on core functionalities and avoiding unnecessary dependencies.
  • systemd Feature Parity (Eventual Goal): While still under active development, the project aims to eventually achieve feature parity with a significant subset of systemd's functionality, including service management, socket activation, device management, and logging. This allows for consistent management of system resources and services across different platforms.
  • BSD Integration: On BSD systems, InitWare integrates with the base system’s utilities and conventions wherever possible, minimizing friction and ensuring a smoother user experience within the BSD ecosystem.
  • Written in C: The project utilizes C as its primary programming language, prioritizing performance, portability, and close-to-the-metal control.
  • Open Source: InitWare is released under a permissive open-source license (ISC), encouraging community contributions and further development.

  The project is currently in active development, meaning not all planned features are fully implemented or stable. The degree of compatibility and feature completeness across different operating systems may also vary. Despite its early stage, InitWare represents an ambitious undertaking to bring a systemd-like init system experience to a wider audience, potentially bridging the gap between Linux and BSD systems.

  • systemd
  • init
  • BSD
  • Linux
  • portable
  • init system
  • OS
  • Operating System
  • unix
  • fork
  • InitWare
  • Open Source
  • Software

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

  Verbose tl;dr

  Hacker News users discussed InitWare, a portable systemd fork, with a mix of skepticism and curiosity. Some questioned the value proposition, given the maturity and ubiquity of systemd, wondering if the project addressed a real need or was a solution in search of a problem. Others expressed concerns about maintaining compatibility across different operating systems and the potential for fragmentation. However, some commenters were intrigued by the possibility of a more lightweight and portable init system, particularly for embedded systems or specialized use cases where systemd might be overkill. Several users also inquired about specific technical details, like the handling of cgroups and service management, demonstrating a genuine interest in the project's approach. The overall sentiment leaned towards cautious observation, with many waiting to see if InitWare could carve out a niche or offer tangible benefits over existing solutions.

  The Hacker News post discussing InitWare, a portable systemd fork running on BSDs and Linux, has generated a number of comments, primarily focusing on the motivations behind the project and its potential implications.

  Several commenters express skepticism about the value proposition of InitWare. They question the need for another init system, especially one derived from systemd, given the existing options and the controversies surrounding systemd's design philosophy. Some argue that the resources invested in InitWare could be better directed towards improving existing init systems or addressing other needs within the BSD ecosystem. The complexity of systemd is also raised as a concern, with some suggesting that a simpler init system would be more suitable for BSDs.

  A recurring theme is the perception of systemd as overly complex and monolithic. Commenters express concern about replicating these perceived flaws in a new project. They suggest that a more modular approach, focusing on interoperability and leveraging existing BSD tools, would be a better strategy.

  Some commenters discuss the technical challenges involved in porting systemd to different operating systems, highlighting the potential for inconsistencies and unexpected behavior. They also raise concerns about the long-term maintenance burden of such a project.

  There's a discussion about the licensing implications of forking systemd, given its LGPL license. Commenters clarify the requirements of the LGPL and how they apply to InitWare.

  A few commenters express interest in the project, appreciating the effort to bring systemd's features to other platforms. They suggest potential use cases and benefits, such as improved containerization support. However, even those expressing interest also voice reservations about the project's overall direction and potential drawbacks.

  One commenter questions the naming of the project, suggesting that it might be confused with existing software.

  The overall sentiment appears to be predominantly cautious and skeptical, with many commenters expressing concerns about the project's goals and feasibility. While there's some interest in the technical aspects of the porting effort, the majority of comments question the necessity and wisdom of recreating systemd on other operating systems.

• The SeL4 Microkernel: An Introduction [pdf]

  permalink

  Posted: 2025-03-23 11:09:28

  Verbose tl;dr

  The seL4 microkernel is a highly secure and reliable operating system foundation, formally verified to guarantee functional correctness and security properties. This verification proves that the implementation adheres to its specification, encompassing properties like data integrity and control-flow integrity. Designed for high-performance and real-time embedded systems, seL4's small size and minimal interface facilitate formal analysis and predictable resource usage. Its strong isolation mechanisms enable the construction of robust systems where different components with varying levels of trust can coexist securely, preventing failures in one component from affecting others. The kernel's open-source nature and liberal licensing promote transparency and wider adoption, fostering further research and development in secure systems.

  The whitepaper, "The seL4 Microkernel: An Introduction," provides a comprehensive overview of the seL4 microkernel, emphasizing its unique characteristics, particularly its formal verification of functional correctness. The document begins by establishing the context of microkernels in operating system design, highlighting their advantages in terms of reliability, security, and performance predictability compared to monolithic kernels. It explains how microkernels minimize the trusted computing base (TCB) by delegating operating system functionalities to user-level servers, thereby reducing the impact of potential vulnerabilities.

  The paper then delves into the specific features of seL4, emphasizing its formal verification, a rigorous mathematical proof guaranteeing that the implementation adheres to its specification. This verification covers the C implementation of the kernel and its binary code, ensuring a strong connection between the high-level design and the executed code. The paper underscores the significance of this formal verification in achieving high assurance and eliminating entire classes of vulnerabilities.

  The architecture of seL4 is explored in detail, explaining its core components and their interactions. The concept of capabilities, the fundamental mechanism for access control and inter-process communication, is elucidated. seL4 employs a capability-based system, where every access right is explicitly represented by a capability. This fine-grained control over access rights allows for the construction of highly secure and reliable systems. The paper describes how capabilities are managed, transferred, and revoked, providing a clear understanding of the security model.

  Furthermore, the document highlights the performance characteristics of seL4, demonstrating its low overhead and efficient inter-process communication. This efficiency stems from the minimalist design of the kernel and the optimized implementation of the capability system. The paper presents benchmark results comparing seL4 to other microkernels and operating systems, showcasing its competitive performance.

  The flexibility and adaptability of seL4 are also addressed, demonstrating its suitability for a wide range of applications, including embedded systems, real-time systems, and high-security environments. The paper discusses various case studies and deployments of seL4, illustrating its practical applicability. It also mentions the open-source nature of the project and the active community supporting its development.

  Finally, the paper concludes by summarizing the key features and benefits of seL4, reiterating its significance as a formally verified microkernel that offers high assurance, security, and performance. It also touches upon future research directions and potential advancements in the seL4 ecosystem. The overall tone of the paper is informative and technical, aimed at providing a detailed understanding of the seL4 microkernel and its advantages in the context of modern operating system design.

  • seL4
  • microkernel
  • Operating System
  • OS
  • Kernel
  • Formal Verification
  • Security
  • Real-time
  • Embedded Systems
  • high assurance
  • L4
  • whitepaper
  • PDF

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

  Verbose tl;dr

  Hacker News users discussed the seL4 microkernel, focusing on its formal verification and practical applications. Some questioned the real-world impact of the verification, highlighting the potential for vulnerabilities outside the kernel's scope, such as in device drivers or user-space applications. Others praised the project's rigor and considered it a significant achievement in system software. Several comments mentioned the challenges of using microkernels effectively, including the performance overhead of inter-process communication (IPC). Some users also pointed out the limited adoption of microkernels in general, despite their theoretical advantages. There was also interest in seL4's use in specific applications like autonomous vehicles and aerospace.

  The Hacker News post linked, titled "The SeL4 Microkernel: An Introduction [pdf]", has a moderate number of comments discussing various aspects of seL4.

  Several commenters focus on the real-world applications and adoption of seL4. Some express interest in seeing more widespread use and question why it hasn't become more mainstream. Others point to specific niches where seL4 has found success, such as aerospace and defense, emphasizing its suitability for safety-critical systems due to its formal verification. The difficulty of porting existing software to a microkernel architecture is also mentioned as a potential barrier to wider adoption.

  A thread of discussion revolves around the performance characteristics of seL4. Commenters debate the trade-offs between the microkernel approach, often associated with overhead, and the monolithic kernel design. Some highlight seL4's impressive performance benchmarks, while others argue that these benchmarks might not reflect real-world scenarios. The efficiency of inter-process communication (IPC) in seL4 is also a topic of conversation.

  The formal verification of seL4 generates significant interest. Commenters discuss the implications of this verification for security and reliability, with some emphasizing the importance of distinguishing between the kernel's formal verification and the security of the overall system built upon it. The limitations and scope of the formal verification are also explored, including the potential for vulnerabilities outside the formally verified components.

  Several comments touch upon the development and maintenance of seL4, including its open-source nature, the community involved, and the resources required to work with it. The complexity of the microkernel design and the challenges in developing drivers and other system components are acknowledged.

  Finally, some comments compare seL4 to other microkernels and operating systems, discussing their relative strengths and weaknesses. Topics like real-time capabilities, security features, and ease of use are brought up in these comparisons.

• LINUX is obsolete (1992)

  permalink

  Posted: 2025-02-08 04:05:28

  Verbose tl;dr

  Andrew Tanenbaum, creator of MINIX, argued in 1992 that Linux, being a monolithic kernel, represented an outdated design compared to the microkernel approach of MINIX. He believed that microkernels, with their modularity and message-passing architecture, offered superior portability, maintainability, and reliability, especially as technology moved towards distributed systems and multicore processors. Tanenbaum predicted that Linux, tied to the aging Intel 386 architecture, would soon become obsolete and fade away as more advanced hardware and software paradigms emerged. He emphasized the conceptual superiority of MINIX's design, portraying Linux as a step backwards in operating system development.

  In a Usenet post from 1992 titled "LINUX is obsolete," Andrew S. Tanenbaum, a professor and creator of the MINIX operating system, argues that the monolithic kernel architecture of Linux, then a nascent operating system, is inherently inferior to the microkernel architecture championed by MINIX and predicted to be the future of operating system design. Tanenbaum asserts that Linux, being tied to the Intel 386 architecture, is already outdated, while microkernel-based systems like MINIX are portable and thus more future-proof. He points to the rapidly evolving hardware landscape, expecting the 386 to be superseded soon, rendering Linux's specific design choices obsolete.

  Tanenbaum elaborates on the technical reasons behind his assertion, claiming that monolithic kernels, where all operating system services run in kernel space, become increasingly difficult to manage and port as they grow in complexity. He contrasts this with the microkernel approach, where only essential services reside in the kernel and other functionalities operate in user space, leading to a more modular, flexible, and therefore maintainable system. He argues that this modularity simplifies debugging and allows for easier adaptation to new hardware platforms.

  Further emphasizing the perceived backwardness of Linux, Tanenbaum criticizes its reliance on segmented memory management, a feature of the 386 architecture, which he deems outdated compared to the paging-based memory management found in more modern processors. He predicts that future operating systems will invariably adopt paging, making Linux's segmented memory approach a technological dead end. Tanenbaum also highlights the perceived advantage of microkernels in distributed systems, suggesting that their inherent modularity lends itself more readily to networked environments. He suggests that the future of computing lies in distributed and networked systems, implying that Linux, with its monolithic kernel, is ill-equipped for this future.

  Finally, Tanenbaum offers MINIX as a practical example of a modern, microkernel-based operating system and invites readers to explore its advantages over Linux. He concludes with a somewhat dismissive tone, implying that Linux is a temporary phenomenon bound for obsolescence while microkernels represent the direction of operating system evolution. He subtly suggests that continuing to develop Linux is a wasted effort given its architectural limitations.

  • Linux
  • Minix
  • Operating System
  • OS
  • Obsolete
  • 1992
  • History
  • Usenet
  • comp.os.minix
  • Tanenbaum
  • Torvalds
  • Kernel
  • unix

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

  Verbose tl;dr

  HN commenters largely dismiss the linked 1992 post arguing for Minix over Linux. Many point out that the author's predictions about Linux's limitations due to its monolithic kernel and lack of microkernel structure were inaccurate, given Linux's widespread success and ongoing development. Some acknowledge that microkernels have certain advantages, but suggest that Linux's approach has proven more practical and adaptable. A few commenters find the historical perspective interesting, noting how the computing landscape has changed significantly since 1992, rendering the arguments largely irrelevant in the modern context. One commenter sarcastically celebrates Tanenbaum's foresight.

  The Hacker News post titled "LINUX is obsolete (1992)" links to a 1992 Usenet post within the comp.os.minix group where Andrew S. Tanenbaum, the creator of MINIX, criticizes the monolithic kernel architecture of Linux, predicting its imminent obsolescence in favor of microkernel systems. The Hacker News thread contains several comments discussing Tanenbaum's arguments and their historical context.

  A compelling line of discussion revolves around the accuracy of Tanenbaum's predictions. Many commenters point out that Linux's success ultimately proved Tanenbaum wrong, with Linux becoming the dominant operating system in many domains while microkernels remained a niche technology. They discuss the reasons for this outcome, citing factors like the rapid pace of hardware development making portability less critical, the performance advantages of monolithic kernels at the time, and the open-source nature of Linux fostering a larger community and faster development.

  Some commenters delve into the technical details of Tanenbaum's arguments, discussing the perceived advantages of microkernels in terms of security, reliability, and portability. They acknowledge that these advantages are theoretically sound, but that practical implementation challenges and the performance overhead associated with microkernels hindered their widespread adoption.

  Several comments also touch upon the historical context of the debate. They highlight the "Tanenbaum-Torvalds debate," a famous online exchange between Tanenbaum and Linus Torvalds, the creator of Linux, where they argued about the merits of their respective kernel architectures. These comments often provide links or references to the original debate, allowing readers to explore the arguments in more detail.

  Some commenters express a degree of sympathy for Tanenbaum's perspective, acknowledging that his arguments were based on the prevailing understanding of operating system design at the time. They suggest that in 1992, given the state of hardware and software, microkernels seemed like a more promising approach, and that Linux's success was not necessarily foreseeable.

  Finally, a few comments offer personal anecdotes or reflections on the impact of the Tanenbaum-Torvalds debate. They discuss how the debate shaped their understanding of operating systems and contributed to the development of the open-source movement.

  In summary, the Hacker News comments provide a retrospective analysis of Tanenbaum's 1992 critique of Linux, examining the technical arguments, historical context, and ultimate outcome of the debate. They largely agree that Tanenbaum's predictions were incorrect, but acknowledge the validity of his concerns based on the knowledge available at the time. The comments offer valuable insights into the evolution of operating system design and the factors that contributed to Linux's dominance.

• The missing cross-platform OS API for timers

  permalink

  Posted: 2025-02-03 06:07:10

  Verbose tl;dr

  The blog post argues for a standardized, cross-platform OS API specifically designed for timers. Existing timer mechanisms, like POSIX's timerfd and Windows' CreateWaitableTimer, while useful, differ significantly across operating systems, complicating cross-platform development. The author proposes a new API with a consistent interface that abstracts away these platform-specific details. This ideal API would allow developers to create, arm, and disarm timers, specifying absolute or relative deadlines with optional periodic behavior, all while handling potential issues like early wake-ups gracefully. This would simplify codebases and improve portability for applications relying on precise timing across different operating systems.

  The blog post "The missing cross-platform OS API for timers" by Gaultier.github.io explores the challenges and complexities of implementing timers across different operating systems, arguing for a standardized, cross-platform OS-level API. The author begins by highlighting the ubiquitous need for timers in software development, from simple delays to complex scheduling tasks, and emphasizes the performance implications of timer accuracy and efficiency, especially in latency-sensitive applications like games and high-frequency trading.

  The post then dives into the intricacies of existing timer mechanisms on various operating systems. It describes how POSIX timers, while offering a relatively consistent interface on Unix-like systems, have limitations related to signal handling and potential issues with signal coalescing, where multiple timer expirations might be delivered as a single signal. On Windows, the author explains the different timer APIs available, such as CreateTimerQueueTimer and SetWaitableTimer, pointing out their specific strengths and weaknesses regarding precision, resource management, and complexity. The disparities between these platforms, the post argues, necessitate developers to write platform-specific code, increasing development time and introducing potential inconsistencies in behavior.

  The core proposal of the blog post is to introduce a new, unified OS-level API for timers that would abstract away the underlying platform differences. This proposed API should ideally offer features like high resolution, support for both one-shot and periodic timers, efficient callback mechanisms, and the ability to associate timers with specific threads or processes for better control and organization. The author suggests that this API could be implemented as a thin abstraction layer on top of existing OS mechanisms, allowing for efficient utilization of underlying hardware capabilities while presenting a consistent interface to developers. This would significantly simplify cross-platform development by eliminating the need for custom timer implementations and ensuring predictable behavior across different environments.

  Furthermore, the blog post discusses the potential benefits of such a standardized API, including improved code portability, reduced development costs, and enhanced performance. The author emphasizes how a well-designed API could facilitate the creation of more robust and efficient applications by providing developers with a reliable and easy-to-use timer mechanism. The post concludes with a call to action, encouraging operating system developers to consider the benefits of a unified timer API and collaborate on its design and implementation. The ultimate goal, the author states, is to empower developers with a powerful and versatile tool for managing time-related operations across various platforms, ultimately leading to better software.

  • Cross-Platform
  • Operating System
  • OS
  • API
  • timers
  • programming
  • Software Development
  • System Programming
  • portability
  • native code
  • C++
  • Rust
  • C
  • Low-Level Programming
  • concurrency
  • Asynchronous Programming
  • scheduling

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

  Verbose tl;dr

  The Hacker News comments discuss the complexities of cross-platform timer APIs, largely agreeing with the article's premise. Several commenters highlight the difficulties introduced by different operating systems' power management features, impacting timer accuracy and reliability. Specific challenges like signal coalescing and the lack of a unified interface for monotonic timers are mentioned. Some propose workarounds like busy-waiting for short durations or using platform-specific code for optimal performance. The need for a standardized API is reiterated, with suggestions for what such an API should offer, including considerations for power efficiency and different timer resolutions. One commenter points to the challenges of abstracting away hardware differences completely, suggesting the ideal solution may involve a combination of OS-level improvements and application-specific strategies.

  The Hacker News post "The missing cross-platform OS API for timers" generated several comments discussing the challenges and nuances of timer implementations across different operating systems.

  Several commenters highlighted the inherent difficulties in creating a truly cross-platform timer API due to the varying underlying mechanisms and priorities of each OS. One user pointed out the complexities introduced by power management, specifically how different systems handle timers during sleep or low-power states. This difference in behavior makes it difficult to abstract away the platform-specific details into a unified API. Another commenter echoed this sentiment, emphasizing that timers are often deeply integrated with the OS scheduler and power management, making a universal solution challenging. They also pointed to the trade-off between accuracy and power efficiency, which further complicates a cross-platform approach.

  The discussion also touched on the existing solutions and their limitations. One comment mentioned kqueue on macOS/BSD platforms and epoll on Linux, acknowledging their suitability for event-driven programming but also their lack of a direct cross-platform equivalent. The lack of a unified interface across these different mechanisms was reiterated by another commenter who emphasized the need to deal with distinct APIs and behaviors on each platform.

  Some commenters delved into specific use cases and challenges, such as dealing with high-resolution timers and the limitations imposed by system clock granularity. One commenter discussed the difficulties in achieving precise timing in JavaScript, citing the impact of browser event loops and garbage collection.

  The complexities of timer coalescing were also brought up. One commenter explained how operating systems might group timer events to reduce CPU wakeups and improve power efficiency, which can affect the precision of timer execution. Another commenter noted that this behavior can be unpredictable and difficult to account for in a cross-platform API.

  Finally, a few comments explored alternative approaches, like using a dedicated thread for timer management, although this was acknowledged as potentially resource-intensive. The discussion ultimately highlighted the significant challenges in designing a truly cross-platform timer API, with the conclusion being that a "one-size-fits-all" solution might not be feasible due to the inherent differences in OS architectures and priorities.

• Snowdrop OS – a homebrew operating system from scratch, in assembly language

  permalink

  Posted: 2025-01-24 16:40:11

  Verbose tl;dr

  Snowdrop OS is a hobby operating system written entirely in assembly language for x86-64 processors. The project aims to be a minimal, educational platform showcasing fundamental OS concepts. Currently, it supports booting into 32-bit protected mode, basic memory management with paging, printing to the screen, and keyboard input. The author's goal is to progressively implement more advanced features like multitasking, a filesystem, and eventually user mode, while keeping the code clean and understandable.

  Sebastian Mihai's blog post details his ambitious personal project: building an operating system from the ground up, named Snowdrop OS. He emphasizes that this is a learning exercise, focusing on understanding the fundamental principles of operating system design and low-level programming. The core of Snowdrop OS is written entirely in assembly language, targeting x86-64 architecture, reflecting his desire for deep control and intimate interaction with the hardware.

  The blog post outlines the initial stages of development, starting with the bootloader, which is the very first piece of code executed upon system startup. Mihai explains his bootloader's function, which involves setting up the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT), crucial components for protected mode operation and interrupt handling, respectively. He details the painstaking process of manually crafting these tables in assembly, highlighting the challenges and intricacies of working at such a low level. He further elaborates on the process of switching the processor from real mode to protected mode, a critical step in setting up a modern operating system environment. This includes setting up segmentation, a memory management scheme used by x86 processors.

  Mihai then describes implementing a basic keyboard driver, enabling the operating system to receive input from the user. He meticulously explains the mechanism behind keyboard interrupts and how his code intercepts and processes these signals to display typed characters on the screen. This involves interfacing directly with the hardware and understanding the intricacies of scan codes generated by the keyboard.

  The post showcases screenshots of Snowdrop OS in its nascent state, displaying characters typed on the keyboard. This visually demonstrates the functionality achieved thus far. While acknowledging the project's early stage, Mihai outlines his long-term vision for Snowdrop OS. He aspires to gradually add more features, including a more advanced memory manager, support for multiple processes, and eventually a file system. He envisions Snowdrop OS as a platform for continuous learning and exploration of operating system concepts. The blog post concludes with an invitation for others interested in similar endeavors to connect and share their experiences, fostering a sense of community among like-minded individuals. He provides a link to the project's GitHub repository, making the source code openly available for inspection and collaboration.

  • Operating System
  • OS
  • Homebrew
  • Assembly Language
  • Low-Level Programming
  • Kernel Development
  • x86
  • Bootloader
  • Bare Metal
  • Snowdrop OS
  • Custom OS
  • Hobby OS

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

  Verbose tl;dr

  HN commenters express admiration for the author's dedication and technical achievement in creating an OS from scratch in assembly. Several discuss the challenges and steep learning curve involved in such a project, with some sharing their own experiences with OS development. Some question the practical applications of the OS, given its limited functionality, while others see value in it as a learning exercise. The use of assembly language is a significant point of discussion, with some praising the low-level control it provides and others suggesting higher-level languages would be more efficient for development. The minimalist nature of the OS and its focus on core functionalities are also highlighted. A few commenters offer suggestions for improvements, such as implementing a simple filesystem or exploring different architectures. Overall, the comments reflect a mix of appreciation for the technical feat, curiosity about its purpose, and discussion of the trade-offs involved in such a project.

  The Hacker News post titled "Snowdrop OS – a homebrew operating system from scratch, in assembly language" generated several comments discussing various aspects of the project.

  Many commenters expressed admiration for the author's dedication and the technical achievement of building an OS from scratch, particularly using assembly language. They acknowledged the significant effort and learning involved in such an undertaking. Some saw it as a valuable learning experience, even if the resulting OS isn't practically useful.

  Several comments focused on the choice of assembly language. Some questioned its practicality for a larger project, citing the increased development time and complexity compared to higher-level languages. They discussed the trade-offs between performance and development speed, with some suggesting that C might be a more suitable choice for a project of this scale. However, others defended the use of assembly, emphasizing the low-level control and understanding it provides, which aligns with the author's stated learning goals.

  There was a discussion about the educational value of such projects. Some commenters shared their own experiences with similar endeavors, highlighting the insights gained into computer architecture and operating system principles. They emphasized the importance of hands-on experience for deepening understanding.

  A few commenters delved into technical details, discussing specific aspects of the OS's implementation, such as memory management, interrupt handling, and the choice of bootloader. They offered suggestions for improvements and pointed out potential issues.

  Some comments touched upon the project's potential future development. While acknowledging the current limitations, some commenters expressed interest in seeing the project evolve and gain more features.

  There was a brief discussion about the licensing of the code, with a suggestion to choose a license explicitly.

  Overall, the comments reflect a positive reception to the project, with an appreciation for the effort involved and the educational value of building an OS from scratch. While some questioned the practical implications and the choice of assembly language, the general sentiment was one of encouragement and interest in the author's learning journey.