Stories with Tag fork

• 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.

• Show HN: Fork of Claude-code working with local and other LLM providers

  permalink

  Posted: 2025-03-04 13:35:12

  Verbose tl;dr

  anon-kode is an open-source fork of Claude-code, a large language model designed for coding tasks. This project allows users to run the model locally or connect to various other LLM providers, offering more flexibility and control over model access and usage. It aims to provide a convenient and adaptable interface for utilizing different language models for code generation and related tasks, without being tied to a specific provider.

  Dimitar Nakov has introduced "anon-kode," a significant fork of the Claude-code codebase, designed to expand its functionality beyond reliance on Anthropic's Claude model. This new iteration aims to democratize access to powerful code generation capabilities by enabling users to leverage a variety of Large Language Models (LLMs), including locally hosted models, instead of being restricted to a single proprietary provider. Anon-kode achieves this expanded compatibility through a flexible architecture that allows for seamless integration with different LLM providers. This adaptability is crucial for users who may prefer or require utilizing specific models due to factors such as cost, data privacy concerns, performance characteristics on particular tasks, or access restrictions. The project leverages the robust foundation of the original Claude-code project, inheriting its existing features and interface, while adding this critical layer of provider agnosticism. By accommodating both locally hosted models and a broader range of external LLMs, anon-kode empowers users to harness the power of code generation with a level of control and choice not previously available. This opens doors for experimentation with diverse models and potentially allows for optimization of performance based on specific needs and resources. The project represents a substantial step towards making advanced code generation tools more accessible and adaptable to individual user preferences and constraints. Furthermore, by supporting local models, anon-kode potentially mitigates data privacy concerns associated with transmitting sensitive code to external servers.

  • Large Language Models
  • LLMs
  • Claude
  • Code Generation
  • Local Deployment
  • Open Source
  • fork
  • Alternative Providers
  • API
  • programming
  • Software Development
  • AI
  • artificial intelligence
  • Coding Assistant

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

  Verbose tl;dr

  Hacker News users discussed the potential of anon-kode, a fork of Claude-code allowing local and diverse LLM usage. Some praised its flexibility, highlighting the benefits of using local models for privacy and cost control. Others questioned the practicality and performance compared to hosted solutions, particularly for resource-intensive tasks. The licensing of certain models like CodeLlama was also a point of concern. Several commenters expressed interest in contributing or using anon-kode for specific applications like code analysis or documentation generation. There was a general sense of excitement around the project's potential to democratize access to powerful coding LLMs.

  The Hacker News post "Show HN: Fork of Claude-code working with local and other LLM providers" (https://news.ycombinator.com/item?id=43254351) sparked a brief but interesting discussion with a few key points raised.

  One commenter expressed skepticism about the practical usefulness of local LLMs for coding tasks, arguing that the quality difference compared to cloud-based models like GPT-4 is significant enough to negate the benefits of local processing, especially given the increasing availability of cheaper cloud alternatives. They specifically mentioned that even if local models eventually catch up in performance, the convenience and speed of cloud-based models might still be preferable.

  Another commenter highlighted the licensing issue, pointing out that closed-source models can't be used commercially. They argued that this is a major drawback, especially for companies, and that this restriction limits the utility of projects like this one. They implied that open-source models are essential for broader adoption in commercial settings.

  A third commenter explored the potential advantages of local models for specific niche use cases, suggesting that even with lower quality, they could be valuable for tasks like code suggestion or autocompletion within a local IDE, particularly if the codebase being worked on is sensitive and cannot be shared with external cloud services. They mentioned that speed and privacy are the primary drivers for such use cases.

  Finally, the original poster (OP) responded to some of the comments, acknowledging the current limitations of local LLMs compared to cloud-based options but expressing optimism about the rapid pace of improvement in open-source LLMs. They also clarified the project's aim, emphasizing that it’s focused on providing a framework for using different LLMs locally rather than promoting any specific local model. They seem hopeful that this approach will become more compelling as local LLM technology matures.

  In summary, the discussion revolved around the trade-offs between cloud-based and local LLMs for coding, with commenters highlighting the current performance gap, licensing restrictions, and potential niche applications of local models. The OP defended the project by focusing on its flexibility and the future potential of local LLMs.

• Process Creation in Io_uring

  permalink

  Posted: 2024-12-20 15:23:05

  Verbose tl;dr

  The article explores a new method for process creation using io_uring, aiming to improve efficiency and reduce overhead compared to traditional fork() and execve(). This new approach uses a "registered executable" within io_uring, allowing asynchronous process launching without the performance penalties of copying memory pages between parent and child processes. The proposed solution involves two new system calls: pidfd_spawn() and pidfd_wait(). pidfd_spawn() creates a new process from the registered executable and returns a process file descriptor, while pidfd_wait() provides an asynchronous wait mechanism using io_uring. This approach offers a streamlined process-creation pathway within the io_uring framework, potentially boosting performance for applications that frequently spawn processes, like containers or web servers.

  This LWN article delves into a significant enhancement proposed for the Linux kernel's io_uring subsystem: the ability to directly create processes using a new operation type. Currently, io_uring excels at asynchronous I/O operations, allowing applications to submit batches of I/O requests without blocking. However, tasks requiring process creation, like launching a helper process to handle a specific part of a workload, necessitate a context switch back to the main kernel, disrupting the efficient asynchronous flow. This proposal aims to remedy this by introducing a dedicated IORING_OP_PROCESS operation.

  The proposed mechanism allows applications to specify all necessary parameters for process creation within the io_uring submission queue entry (SQE). This includes details like the executable path, command-line arguments, environment variables, user and group IDs, and various other process attributes. Critically, this eliminates the need for a system call like fork() or execve(), thereby maintaining the asynchronous nature of the operation within the io_uring context. Upon completion, the kernel places the process ID (PID) of the newly created process in the completion queue entry (CQE), enabling the application to monitor and manage the spawned process.

  The article highlights the intricate details of how this process creation within io_uring is implemented. It explains how the necessary data structures are populated within the kernel, how the new process is forked and executed within the context of the io_uring kernel threads, and how signal handling and other process-related intricacies are addressed. Specifically, the IORING_OP_PROCESS operation utilizes a dedicated structure called io_uring_process, embedded within the SQE, which mirrors the arguments of the traditional execveat() system call. This allows for a familiar and comprehensive interface for developers already accustomed to process creation in Linux.

  Furthermore, the article discusses the security implications and design choices made to mitigate potential vulnerabilities. Given the asynchronous nature of io_uring, ensuring proper isolation and preventing unauthorized process creation are paramount. The article emphasizes how the proposal adheres to existing security mechanisms and leverages existing kernel infrastructure for process management, thereby minimizing the introduction of new security risks. This involves careful handling of file descriptor inheritance, namespace management, and other security-sensitive aspects of process creation.

  Finally, the article touches upon the performance benefits of this proposed feature. By avoiding the context switch overhead associated with traditional process creation system calls, applications leveraging io_uring can achieve greater efficiency, particularly in scenarios involving frequent process spawning. This streamlines workflows involving parallel processing and asynchronous task execution, ultimately boosting overall system performance.

  • io_uring
  • Linux
  • Kernel
  • asynchronous I/O
  • process creation
  • system calls
  • performance
  • scalability
  • networking
  • file I/O
  • user space
  • ring buffer
  • efficient I/O
  • concurrency
  • fork
  • execve
  • clone3

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

  Verbose tl;dr

  Hacker News users discuss the implications of io_uring's new process creation capabilities. Several express excitement about the potential performance improvements, particularly for applications that frequently spawn processes, like web servers. Some highlight the security benefits of avoiding execve, while others raise concerns about the complexity introduced by this new feature and the potential for misuse. A few commenters delve into the technical details, comparing the approach to other process creation methods and discussing the trade-offs involved. Several anticipate interesting use cases, including containerization and sandboxing. One user questions if io_uring is becoming overly complex and straying from its original purpose.

  The Hacker News post titled "Process Creation in Io_uring" sparked a discussion with several insightful comments. Many commenters focused on the potential performance benefits and use cases of this new functionality.

  One commenter highlighted the significance of io_uring evolving from asynchronous I/O to encompassing process creation, viewing it as a step towards a more unified and efficient system interface. They expressed excitement about the possibilities this opens up for streamlining complex operations.

  Another commenter delved into the technical details, explaining how CLONE_PIDFD could be leveraged within io_uring to manage child processes more effectively. They pointed out the potential to avoid race conditions and simplify error handling compared to traditional methods. This commenter also discussed the benefits of integrating process management into the same asynchronous framework used for I/O.

  The discussion also touched upon the security implications of using io_uring for process creation. One commenter raised concerns about the potential for vulnerabilities if this powerful functionality isn't implemented and used carefully. This concern spurred further discussion about the importance of proper sandboxing and security audits.

  Several commenters expressed interest in using this feature for specific applications, such as containerization and serverless computing. They speculated on how the performance improvements could lead to more efficient and responsive systems.

  A recurring theme throughout the comments was the innovative nature of io_uring and its potential to reshape system programming. Commenters praised the ongoing development and expressed anticipation for future advancements.

  Finally, some commenters discussed the complexities of using io_uring and the need for better documentation and examples. They suggested that wider adoption would depend on making this powerful technology more accessible to developers.