Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Agent Centric Operating System -- a Comprehensive Review and Outlook for Operating System

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper proposes ACOS, an operating-system architecture that abstracts every component—kernel modules, drivers, and applications—into autonomous agents that cooperate through a flat communication interface.

desk verdict Solid survey, but the ACOS proposal is a position with an internal contradiction and no overhead analysis. read the letter →

arxiv 2411.17710 v1 pith:J44C44BD submitted 2024-11-15 cs.DC cs.OS

Shian Jia , Xinbo Wang , Mingli Song , Gang Chen This is my paper · ORCID
classification cs.DCcs.OS
keywords operatingsystemagentabstractionAgent-CentricACOScross-platformadaptationmulti-agentcollaborationAIagentsresourcemanagement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This review traces operating systems from embedded to desktop, mobile, and server platforms, then argues that the next generation should be built around a single abstraction: the agent. The paper's central proposal, ACOS (Agent-Centric Operating System), treats every system component as an autonomous, communicating agent, guided by the motto 'Agent for OS, OS for Agent.' If the proposal is right, one OS design could adapt to devices ranging from data-center servers to constrained IoT sensors, simplifying maintenance, updates, and cross-platform porting. The paper also sketches manager agents for compute, memory, storage, network, security, and environment sensing, plus mechanisms for agent collaboration, user interaction, and permission control. The authors acknowledge open challenges in scaling agent communication, security, and edge-device constraints.

What carries the argument

The central mechanism is the agent abstraction together with the Agent Communication Interface (ACI). The ACI is an intermediary that connects different types of agents so they communicate on equal structural footing, eliminating the overhead of hierarchical designs. The agent abstraction carries the argument: by making every module, driver, and application an agent with the four properties of composability, instrumentality, collaborativeness, and scalability, ACOS turns cross-platform adaptation into a matter of composing and replacing agents rather than rewriting the OS.

What would settle it

A minimum viable ACOS prototype on an 8-bit microcontroller and a multi-core server would falsify the cross-platform claim if inter-agent communication overhead or memory footprint makes the small device unusable. Alternatively, measuring agent-to-agent message latency against a traditional syscall or IPC on the same hardware would falsify the flat-architecture efficiency premise if the agent path is consistently slower.

Watch

Extended reading notes

Core claim

The paper's discovery is a design paradigm: abstract all operating-system components into agents of equal structural status, connected by an Agent Communication Interface (ACI) that avoids hierarchical overhead. An agent is an intelligent entity that perceives its environment, makes decisions, and acts to reach goals; in ACOS, app/shell, kernel, and hardware components all become agents. Agents are required to be composable (able to merge and split), instrumental (usable as tools by other agents), collaborative (forming teams), and scalable (accepting new agents). This flat, agent-based architecture is what ACOS claims will deliver modularity, adaptability, cross-platform compatibility, and easier function expansion, with the OS as the foundation that lets agents cooperate and the agents' cooperation in turn keeping the OS efficient.

Load-bearing premise

The load-bearing premise is that a flat network of autonomous agents can communicate, coordinate, and stay secure with acceptable overhead on devices ranging from tiny IoT sensors to high-performance servers, and that the four required agent properties are realizable in practice.

Editorial extensions

If this is right

  • A single ACOS design could run across servers, desktops, mobiles, and embedded devices without per-platform rewrites of core OS modules.
  • Adding or upgrading functionality becomes introducing, replacing, or composing agents rather than modifying the whole system.
  • Distributed collaboration becomes native: agents on different devices coordinate through the physical-link-extended ACI, enabling resource sharing and redundant computation avoidance.
  • User interfaces can be generated adaptively from knowledge of agent input/output forms, user habits, and device characteristics, reducing cross-device UI development cost.
  • Fine-grained permission management and security-capability matching let the system route sensitive data through trustworthy devices and agents.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: if the flat-agent premise holds, ACOS would be a generalization of microkernel and service-oriented designs, applying multi-agent-system ideas to the OS core; the practical test is whether ACI overhead stays below traditional kernel call overhead.
  • Editorial inference: a minimal prototype on two very different devices, such as a microcontroller and a server, would reveal whether the agent abstraction truly lowers porting cost or just relocates complexity into communication and coordination protocols.
  • Editorial inference: the paper's reliance on AI agents suggests the proposal's feasibility is coupled to the maturity of lightweight machine-learning agents; if such agents remain too heavy for small devices, a hybrid of rule-based and agent-based components would be a natural fallback.
  • Editorial inference: a concrete benchmark comparing agent-to-agent message latency against syscall and IPC latency on identical hardware would settle whether the flat architecture's promised efficiency gain is real.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper is a two-part work. The first part (Sections 2–3) is a review of existing operating systems across embedded, mobile, desktop, and server categories, followed by a survey of recent advances in OS scheduling, memory management, I/O, security, structure optimization, and OS-for-AI systems. The second part (Section 4) proposes a new architecture, ACOS (Agent Centric Operating System), whose central idea is to abstract all system components — kernel modules, drivers, and user applications — into agents communicating through an Agent Communication Interface (ACI). The authors claim that this abstraction yields modularity, adaptability, cross-platform compatibility, and efficiency, and they describe a flat, equal-status agent architecture, a set of example agents (knowledge and memory manager, compute scheduler, memory, storage, network, security, and environment-sensing agents), and mechanisms for user interaction, security and permission management, task scheduling, and agent collaboration. The paper concludes by asserting these benefits and by acknowledging future challenges, including the scaling of agent communication networks.

Significance. The ACOS vision is a recognizable research direction: if the claimed properties were realized, the all-agent abstraction would be a genuinely new OS paradigm, distinct from the microkernel, unikernel, and kernel-bypass families surveyed in Section 3 and adjacent to recent LLM-agent proposals (AIOS, OS-Copilot, DBOS) that the authors cite. The paper is a useful, broad, and well-referenced survey; its structured tables and timelines give a quick map of the OS landscape, and Section 4.1 articulates real, concrete gaps (cross-platform adaptation, static strategy adaptability, cross-domain collaboration, user interaction) that motivate the proposal. The authors also deserve credit for candidly listing open challenges in Section 5 — scaling agent communication networks, robust security frameworks, and edge-device computational constraints — rather than claiming the problems are solved. What the paper does not provide is any implementation, simulation, formal model, or protocol specification, so the benefits are asserted, not demonstrated; the contribution is a position statement whose value depends on the subsequent work it provokes.

major comments (4)
  1. [§4.2.3, §4.4.4, Fig. 7] Section 4.2.3 states that ACOS 'adopts a flat architectural design' in which all agents have 'equal structural status,' and that the Agent Communication Interface (ACI) achieves 'higher communication efficiency by eliminating the overhead associated with hierarchical designs.' This is contradicted within the same section by the agent taxonomy of APP/Shell, Kernel, and Hardware Agents, which is a stratification of roles and privileges; it is contradicted by Figure 7's caption, which explicitly describes a 'layered design'; and it is contradicted by Section 4.4.4, which introduces a star logical control topology centered on key nodes, with Figure 12 depicting 'a central node controlling multiple terminal devices' data transmission processes.' Since the paper's efficiency argument rests on the flatness claim, the reader cannot determine whether agents are true peers, whether Kernel Agents mediate access to Hardware Agents, or whether central nodes carry special control responsibility. The authors should specify the agent topology, the interposition and privilege relations among agent classes, and the logical control structure consistently; as written, the central architectural claim is internally inconsistent.
  2. [§4.2.3, §5] The claim that ACI communication is more efficient than hierarchical designs is never supported. No message format, interaction protocol, serialization model, or latency bound is given, and no comparison is made against the kernel-call or IPC baselines that the paper itself surveys in Section 3.3 (microkernel IPC, kernel-bypass stacks). The manuscript's own closing section concedes that 'scaling agent communication networks' remains a future challenge, which further undermines the asserted efficiency benefit. The authors should either supply a concrete cost model for ACI traffic (even a qualitative complexity argument relating message-passing cost to the number and size of agents) or explicitly relabel the efficiency claim as an unverified hypothesis.
  3. [§4.2.2, §5] The claimed benefits of ACOS are largely restated from the definitions of the agent properties in Section 4.2.2 rather than derived from a specific design. Composability is defined as the ability of agents to combine and decompose, and the paper then concludes the system is flexible; scalability is defined as the ability to add agents, and the paper then concludes the system is scalable; instrumentality and collaborativeness similarly entail the cooperation benefits asserted in the conclusion. Because the architecture is defined as 'anything anywhere all as agent,' these conclusions hold by construction and are unfalsifiable. To make the central claim load-bearing, the authors should derive the benefits from concrete interface contracts (for example, the ACI semantics, agent lifecycle rules, or scheduling policy) or state testable predictions that an implementation could confirm or refute.
  4. [Table 1, Table 2] The survey portion's reliability is weakened by factual errors and unclear classifications in the comparison tables. Table 1 classifies Zephyr as 'Open Sourced: No,' although Zephyr is an open-source project released under the Apache 2.0 license; Table 2 lists Android's kernel architecture as 'Monolithic CFS,' conflating the Completely Fair Scheduler with a kernel-architecture taxonomy; and entries such as µC/OS ('Partial'), ThreadX ('Microkernel'), and TockOS ('Monolithic') would benefit from footnotes or citations to be auditable. For a paper whose title promises a comprehensive review, these tables should be verified against the cited sources.
minor comments (6)
  1. [§1, §5] Section 1 promises 'a critical analysis of the challenges and opportunities associated with developing next-generation operating systems,' but Section 5 delivers only a short paragraph of future challenges; the promised critical analysis should either be written or the scope statement adjusted.
  2. [Fig. 11] The caption of Figure 11 repeats the same two sentences verbatim; the duplication should be removed.
  3. [References] Several references lack proper bibliographic attribution, including [17], whose author is given as 'wiki,' and [29], whose author is given as 'A. Co.'; the reference list should be standardized.
  4. [§4.4.4] The relationship between the physical-layer mesh network and the logical star control topology is not explained; a sentence or two describing how the two topologies map onto each other and how central nodes are selected would clarify the design.
  5. [§3.2.1] The 'Living-off-the-land command detection using active learning' work is described in detail but has no corresponding bracketed reference number; a citation should be added.
  6. [§4.3.7] The Environment Sensing Agent is described as coordinating 'Sensor Agents,' but the relationship of these Sensor Agents to the Hardware Agents and APP/Shell agents defined in §4.2.3 is not stated; the taxonomy should clarify whether these are subclasses of the existing categories or an orthogonal dimension.

Circularity Check

1 steps flagged · score 5.0 of 10

ACOS's central flexibility/scalability claim restates its own agent-property definitions; the rest of the paper is a non-circular survey and design proposal.

  1. self definitional [Section 4.2.2 (Agent Abstrcation) and Section 5 (Conclusion and Outlook)]
    "Scalability refers to the ability of a multi-agent system to expand its capabilities and performance by incorporating new agents or functional modules. ... By abstracting functional modules into agents, ACOS achieves a highly modular system architecture. This simplifies replacing and combining components, promotes loose coupling between different components, and enhances the system’s scalability and maintainability. ... By abstracting system components into autonomous agents, ACOS achieves a flexible and scalable architecture that can adapt to various resource platforms."

    The system-level property is derived directly from its own stipulated definition. 'Scalability' is defined as the ability of a multi-agent system to incorporate new agents or modules, and the paper then concludes that ACOS is flexible and scalable because it abstracts components into agents. No implementation, measurement, or independent argument establishes that the abstraction actually delivers the defined capability; the conclusion restates the definitional property as an achieved result.

full rationale

The paper is primarily a literature review, and the review sections (Sections 2-3) contain no fitted-parameter predictions, no self-citation chains, and no imported uniqueness theorems; those portions are not circular. The circularity is confined to the ACOS proposal: the claimed outcomes 'flexible and scalable architecture' and 'enhanced scalability' are restatements of the agent-property definitions in Section 4.2.2, not consequences of any measured or externally supported mechanism. The paper acknowledges unresolved feasibility issues in Section 5 ('scaling agent communication networks, developing robust security frameworks, and addressing computational constraints in edge devices'), which further indicates the benefit claims are stipulated rather than derived. I do not flag the flat-versus-layered architectural inconsistency (Section 4.2.3 flat design versus Figure 7 'layered design' and Section 4.4.4 star logical topology) as circularity, because it is a coherence/correctness concern rather than an input-output equivalence. A score of 5 reflects partial circularity: the central flexibility/scalability claim reduces to definition, while the remainder of the paper's review content and detailed agent taxonomy have independent descriptive content.

Assumptions & free parameters 0 free parameters · 4 assumptions · 5 invented entities

The paper introduces many conceptual entities that are not implemented or empirically tested. The axioms are domain assumptions about the feasibility of the agent abstraction and its performance characteristics. There are no free parameters because no data fitting is performed.

assumptions (4)
  • domain assumption All operating system components can be effectively abstracted as autonomous agents without loss of essential functionality.
    The entire ACOS concept in Section 4.2.2 rests on this premise, but the paper provides no evidence that low-level hardware drivers or real-time scheduling can be modeled as agents with acceptable overhead.
  • domain assumption The communication and coordination overhead of a flat agent architecture is manageable across heterogeneous devices.
    Section 4.2.3 proposes a flat design with a communication interface, but Section 5 lists scaling agent communication networks as a challenge, indicating this is not established.
  • domain assumption AI agents can provide the required intelligent adaptation (scheduling, memory, security) in real time on resource-constrained devices.
    Sections 4.3.2 and 4.3.6 assume that ML/DL models can make scheduling and security decisions efficiently, but no performance constraints are analyzed.
  • ad hoc to paper Agents can be defined with the specified properties of composability, instrumentality, collaborativeness, and scalability.
    These properties are introduced in Section 4.2.2 and are used to justify the architecture, but they are defined by the authors and not demonstrated to be simultaneously achievable.
invented entities (5)
  • ACOS architecture
    purpose: A proposed operating system design where all components are agents.
    No implementation or independent validation is provided.
  • Agent Communication Interface (ACI)
    purpose: A flat interface enabling communication between all agents without hierarchy.
    Only described conceptually in Section 4.2.3.
  • Knowledge and Memory Manager Agent
    purpose: Manages and schedules knowledge and memory formats across agents.
    Described in Section 4.3.1, no implementation.
  • Compute Scheduler Agent
    purpose: Schedules heterogeneous compute resources (CPU, GPU, NPU, DPU) as a unified pool.
    Described in Section 4.3.2, no prototype.
  • Security Agent
    purpose: Provides ML-based threat detection and collaborative defense.
    Described in Section 4.3.6, no validation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Agent Centric Operating System -- a Comprehensive Review and Outlook for Operating System." pith.science (2026). https://pith.science/paper/J44C44BD

@misc{pith2026241117710,
  author       = {Pith},
  title        = {Pith review of: Agent Centric Operating System -- a Comprehensive Review and Outlook for Operating System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/J44C44BD}},
  note         = {Machine review of arXiv:2411.17710}
}
read the original abstract

The operating system (OS) is the backbone of modern computing, providing essential services and managing resources for computer hardware and software. This review paper offers an in-depth analysis of operating systems' evolution, current state, and prospects. We begin with an overview of the concept and significance of operating systems in the digital era. In the second section, we delve into the existing released operating systems, examining their architectures, functionalities, and the ecosystems they support. We then explore recent advances in OS evolution, highlighting innovations in real-time processing, distributed computing, and security. The third section focuses on the new era of operating systems, discussing emerging trends like the Internet of Things (IoT), cloud computing, and artificial intelligence (AI) integration. We also consider the challenges and opportunities presented by these developments. This review concludes with a synthesis of the current landscape and a forward-looking discussion on the future trajectories of operating systems, including open issues and areas ripe for further research and innovation. Finally, we put forward a new OS architecture.

Figures

Figures reproduced from arXiv: 2411.17710 by the authors.

Figure 1
Figure 1. Evolution of Computing Eras and Corresponding Growth in Connected Devices. This diagram illustrates the progression through various computing eras, highlighting the exponential increase in con￾nected devices from tens of thousands during the Mainframe Era to an estimated 100 billion in the Internet of Things era. Each era represents significant technological advancements leading to greater connectivity and device pr… view at source ↗
Figure 2
Figure 2. Historical Timeline of Operating Systems Across Different Device Categories. This figure provides a comprehensive overview of operating systems across server, desktop, mobile, and embedded categories over time, spanning from the early days of computing in the mid-20th century up until recent years. and enhances the efficiency and responsiveness of operating systems across a wide array of devices. In this paper, we a… view at source ↗
Figure 3
Figure 3. Chronological Development of Embedded Operating Systems and Associated Technological Milestones. This figure chronicles the evolution of embedded operating systems from their origins in the late 20th century to contemporary platforms, alongside pivotal technological advancements that have driven innovation in this domain. Many embedded devices, constrained by cost, size, or power consumption, are equipped with low-p… view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Historical Timeline of Mobile Operating System Evolution and Key Technological Advancements. This figure presents a chronological timeline of the development of mobile operating systems from 1991 to 2019, along with significant technological milestones that contributed…
Figure 5
Figure 5. Figure 5: Chronological Development of Desktop Operating Systems and Associated Technological Milestones. This timeline traces the historical progression of desktop operating systems from their inception to modern times, alongside significant technological advancements that infl…
Figure 6
Figure 6. Figure 6: Timeline of Key Developments in Server Operating Systems and Related Technologies. This timeline illustrates the chronological sequence of pivotal events and innovations in the realm of server operating systems and associated technologies, spanning from the introductio…
Figure 7
Figure 7. Figure 7: ACOS Architecture. The figure depicts the modular architecture of the ACOS. It showcases a layered design where the User Agent Framework interacts with various applications and services, while the Agent Communication Interface (ACI) facilitates inter-agent communicatio…
Figure 8
Figure 8. Figure 8: ACOS Knowledge & Memory Management. This figure illustrates the knowledge and memory management framework within the ACOS. It demonstrates the process of unifying intermediate formats, evaluating and dispatching knowledge, and optimizing collaborative performance. The …
Figure 9
Figure 9. Figure 9: ACOS Resource Managing Manicheism. Figure illustrating the concept of Agent Centric Resource Scheduling in an operating system environment, demonstrating how resources from computing pools (CPU, NPU, GPU and so on) and storage pools (NVM, SSD, HDD and so on) are alloca…
Figure 10
Figure 10. Figure 10: ACOS Agent UI/UX. This figure presents an overview of the User Interface/User Experience (UI/UX) design considerations for ACOS Agents within the context of an ACOS. It highlights key aspects such as input/output forms and types, user interface construction including …
Figure 11
Figure 11. Figure 11: ACOS Secure Datapath. This diagram illustrates the secure data path within an ACOS, highlighting its ability to ensure user data security across all stages of the process. It begins with verifying users before allowing them access to specific agents tailored to their …
Figure 12
Figure 12. Figure 12: Agent Topology Structure. The figure illustrates the ACOS topology, divided into two parts: Mesh Physical Data Link and Star Logical Control Link. The left side depicts the physical data link, where dashed lines represent wireless channels while solid ones indicate wi…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Composable OS Kernel Architectures for Autonomous Intelligence

    cs.OS 2025-08 reject novelty 3.0 of 10

    A vision paper proposing AI-aware and neurosymbolic kernel architectures without implementation, empirical validation, or formal derivation.

Reference graph

Works this paper leans on

88 extracted references · 71 canonical work pages · cited by 1 Pith paper

  1. [1]

    An architectural overview of qnx

    D. Hildebrand, “An architectural overview of qnx.” in USENIX Workshop on Microkernels and Other Kernel Architectures . Citeseer, 1992, pp. 113–126

    1992

  2. [2]

    Vxworks,

    windriver, “Vxworks,” 2024. [Online]. Available: https://www. windriver.com/resource/vxworks-product-overview

    2024

  3. [3]

    Lynxos: Unix rewritten for real-time,

    I. M. Singh and M. Bunnell, “Lynxos: Unix rewritten for real-time,” Ik , p. 27, 1990

    1990

  4. [4]

    Torvalds, “Linux,” 2024

    L. Torvalds, “Linux,” 2024. [Online]. Available: https://www. linux.org/

    2024

  5. [5]

    Windows ce

    M. Levy, “Windows ce.” EDN, vol. 42, no. 15, pp. 38–44, 1997

    1997

  6. [6]

    Threadx,

    W. Lamie, “Threadx,” 2024. [Online]. Available: https://threadx. io/

    2024

  7. [7]

    Ecos: An socp solver for embedded systems,

    A. Domahidi, E. Chu, and S. Boyd, “Ecos: An socp solver for embedded systems,” in 2013 European control conference (ECC) . IEEE, 2013, pp. 3071–3076

    2013

  8. [8]

    Freertos,

    R. Barry et al., “Freertos,” Internet, Oct, vol. 4, p. 18, 2008

    2008

Show all 88 references
  1. [9]

    Contiki-a lightweight and flexible operating system for tiny networked sensors,

    A. Dunkels, B. Gronvall, and T. Voigt, “Contiki-a lightweight and flexible operating system for tiny networked sensors,” in 29th annual IEEE international conference on local computer networks . IEEE, 2004, pp. 455–462

    2004

  2. [10]

    Nutt, “Nuttx,” 2024

    G. Nutt, “Nuttx,” 2024. [Online]. Available: https://nuttx.apache. org/

    2024

  3. [11]

    Mbed os,

    Arm, “Mbed os,” 2024. [Online]. Available: https://os.mbed. com/mbed-os/

    2024

  4. [12]

    Fuchsia,

    Google, “Fuchsia,” 2024. [Online]. Available: https://fuchsia.dev/

    2024

  5. [13]

    Harmonyos,

    Huawei, “Harmonyos,” 2024. [Online]. Available: https://www. harmonyos.com/en/

    2024

  6. [14]

    The tock embedded operating system,

    A. Levy, B. Campbell, B. Ghena, D. B. Giffin, S. Leonard, P . Pan- nuto, P . Dutta, and P . Levis, “The tock embedded operating system,” in Proceedings of the 15th ACM Conference on Embedded Network Sensor Systems, 2017, pp. 1–2

    2017

  7. [15]

    Symbian,

    S. Ltd, “Symbian,” 2024. [Online]. Available: https://licensing. symbian.org/

    2024

  8. [16]

    Palm os,

    C. Jones, “Palm os,” 1995

    1995

  9. [17]

    Blackberry os,

    wiki, “Blackberry os,” 2024. [Online]. Available: https://en. wikipedia.org/wiki/BlackBerry OS

    2024

  10. [18]

    Windows mobile,

    Microsoft, “Windows mobile,” 2024. [Online]. Available: https: //en.wikipedia.org/wiki/Windows Mobile

    2024

  11. [19]

    [Online]

    Apple, “ios,” 2024. [Online]. Available: https://www.apple.com/ ios/ios-18/

    2024

  12. [20]

    Android os: A review,

    P . Gilski and J. Stefanski, “Android os: A review,” Tem Journal, vol. 4, no. 1, p. 116, 2015

    2015

  13. [21]

    A study on the tizen operating system,

    G. Vashisht and R. Vashisht, “A study on the tizen operating system,” International Journal of Computer Trends and Technology , vol. 12, no. 1, pp. 14–15, 2014

    2014

  14. [22]

    The unix time-sharing system,

    D. M. Ritchie and K. Thompson, “The unix time-sharing system,” Communications of the ACM, vol. 17, no. 7, pp. 365–375, 1974

    1974

  15. [23]

    4.2 bsd and 4.3 bsd as examples of the unix system,

    J. S. Quarterman, A. Silberschatz, and J. L. Peterson, “4.2 bsd and 4.3 bsd as examples of the unix system,” ACM Computing Surveys (CSUR), vol. 17, no. 4, pp. 379–418, 1985

    1985

  16. [24]

    An inside look at ms-dos

    T. Paterson, “An inside look at ms-dos.” Byte, vol. 8, no. 6, p. 230, 1983

    1983

  17. [25]

    [Online]

    Apple, “macos,” 2024. [Online]. Available: https://www.apple. com/macos/macos-sequoia/

    2024

  18. [26]

    Microsoft windows,

    Microsoft, “Microsoft windows,” 2024. [Online]. Available: https://www.microsoft.com/en-us/windows

    2024

  19. [27]

    A brief history of the windows nt operating system,

    ——, “A brief history of the windows nt operating system,” 2024. [Online]. Avail- able: https://web.archive.org/web/20000817031621/http:// www.microsoft.com/PressPass/features/1998/winntfs.asp

    2024

  20. [28]

    Amigaos–internal structure of operating system,

    F. i Chemii, “Amigaos–internal structure of operating system,” 2004

    2004

  21. [29]

    The be book,

    A. Co., “The be book,” 2024. [Online]. Available: https: //www.haiku-os.org/legacy-docs/bebook/index.html

    2024

  22. [30]

    Redox os,

    ReDox, “Redox os,” 2024. [Online]. Available: https://www. redox-os.org/

    2024

  23. [31]

    Os/360 and successors,

    M. II, “Os/360 and successors,” Marketing, vol. 21, 1972

    1972

  24. [32]

    Vms software documentation,

    I. VMS Software, “Vms software documentation,” 2024. [Online]. Available: https://docs.vmssoftware.com/

    2024

  25. [33]

    An overview of the netware operating system

    D. Major, G. Minshall, and K. Powell, “An overview of the netware operating system.” in USENIX Winter, 1994, pp. 355–372

    1994

  26. [34]

    Oracle solaris documentation,

    Oracle, “Oracle solaris documentation,” 2024. [Online]. Available: https://docs.oracle.com/en/operating-systems/solaris.html

    2024

  27. [35]

    Windows server,

    Microsoft, “Windows server,” 2024. [Online]. Available: https: //www.microsoft.com/en-us/windows-server

    2024

  28. [36]

    Comparative analysis of process scheduling algorithm using ai models,

    M. M. A. Moni, M. Niloy, A. H. Chowdhury, F. J. Khan, M. F.-U.- A. Juboraj, and A. Chakrabarty, “Comparative analysis of process scheduling algorithm using ai models,” in 2022 25th International Conference on Computer and Information Technology (ICCIT) . IEEE, 2022, pp. 587–592

    2022

  29. [37]

    Improvement of lottery scheduling algorithm based on machine learning algorithm,

    X. Yang and Z. Bai, “Improvement of lottery scheduling algorithm based on machine learning algorithm,” in Proceedings of the 2022 2nd International Conference on Control and Intelligent Robotics, 2022, pp. 894–897

    2022

  30. [38]

    A deep reinforcement learning-based preemptive approach for cost-aware cloud job scheduling,

    L. Cheng, Y. Wang, F. Cheng, C. Liu, Z. Zhao, and Y. Wang, “A deep reinforcement learning-based preemptive approach for cost-aware cloud job scheduling,” IEEE Transactions on Sustainable Computing, 2023

    2023

  31. [39]

    Drlbtsa: Deep reinforcement learning based task-scheduling algorithm in cloud computing,

    S. Mangalampalli, G. R. Karri, M. Kumar, O. I. Khalaf, C. A. T. Romero, and G. A. Sahib, “Drlbtsa: Deep reinforcement learning based task-scheduling algorithm in cloud computing,” Multimedia Tools and Applications, vol. 83, no. 3, pp. 8359–8387, 2024. 30

    2024

  32. [40]

    A reinforcement learning based job scheduling algorithm for heterogeneous computing environment,

    Y. Song, C. Li, L. Tian, and H. Song, “A reinforcement learning based job scheduling algorithm for heterogeneous computing environment,” Computers and Electrical Engineering , vol. 107, p. 108653, 2023

    2023

  33. [41]

    Smartos: Towards automated learning and user-adaptive resource alloca- tion in operating systems,

    S. Goodarzy, M. Nazari, R. Han, E. Keller, and E. Rozner, “Smartos: Towards automated learning and user-adaptive resource alloca- tion in operating systems,” in Proceedings of the 12th ACM SIGOPS Asia-Pacific Workshop on Systems, 2021, pp. 48–55

    2021

  34. [42]

    µconadapter: Reinforcement learning-based fast concurrency adaptation for microservices in cloud,

    J. Liu, S. Zhang, and Q. Wang, “ µconadapter: Reinforcement learning-based fast concurrency adaptation for microservices in cloud,” in Proceedings of the 2023 ACM Symposium on Cloud Com- puting, 2023, pp. 427–442

    2023

  35. [43]

    Using machine learning techniques to analyze the performance of concurrent kernel execution on gpus,

    P . Carvalho, E. Clua, A. Paes, C. Bentes, B. Lopes, and L. M. d. A. Drummond, “Using machine learning techniques to analyze the performance of concurrent kernel execution on gpus,” Future Generation Computer Systems, vol. 113, pp. 528–540, 2020

    2020

  36. [44]

    Operating systems for resource-adaptive intelligent software: Challenges and opportunities,

    X. Liu, S. Wang, Y. Ma, Y. Zhang, Q. Mei, Y. Liu, and G. Huang, “Operating systems for resource-adaptive intelligent software: Challenges and opportunities,” ACM Transactions on Internet Tech- nology (TOIT), vol. 21, no. 2, pp. 1–19, 2021

    2021

  37. [45]

    Machine learning for load balancing in the linux kernel,

    J. Chen, S. S. Banerjee, Z. T. Kalbarczyk, and R. K. Iyer, “Machine learning for load balancing in the linux kernel,” in Proceedings of the 11th ACM SIGOPS Asia-Pacific Workshop on Systems , 2020, pp. 67–74

    2020

  38. [46]

    Batch jobs load balancing scheduling in cloud computing using distributional reinforcement learning,

    T. Li, S. Ying, Y. Zhao, and J. Shang, “Batch jobs load balancing scheduling in cloud computing using distributional reinforcement learning,” IEEE Transactions on Parallel and Distributed Systems , vol. 35, no. 1, pp. 169–185, 2023

    2023

  39. [47]

    A machine learning-based resource-efficient task scheduler for het- erogeneous computer systems,

    A. Hayat, Y. N. Khalid, M. S. Rathore, and M. N. Nadir, “A machine learning-based resource-efficient task scheduler for het- erogeneous computer systems,” The Journal of Supercomputing , vol. 79, no. 14, pp. 15 700–15 728, 2023

    2023

  40. [48]

    Auto- matic energy-efficient job scheduling in hpc: A novel slurm plugin approach,

    A. Aaen Springborg, M. Albano, and S. Xavier-de Souza, “Auto- matic energy-efficient job scheduling in hpc: A novel slurm plugin approach,” in Proceedings of the SC’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis, 2023...

    2023

  41. [49]

    Scheduling algorithms for federated learning with minimal energy consumption,

    L. L. Pilla, “Scheduling algorithms for federated learning with minimal energy consumption,” IEEE Transactions on Parallel and Distributed Systems, vol. 34, no. 4, pp. 1215–1226, 2023

    2023

  42. [50]

    Heterogeneous energy-aware load balancing for industry 4.0 and iot environ- ments,

    U. Ahmed, J. C.-W. Lin, and G. Srivastava, “Heterogeneous energy-aware load balancing for industry 4.0 and iot environ- ments,” ACM Transactions on Management Information Systems (TMIS), vol. 13, no. 4, pp. 1–23, 2022

    2022

  43. [51]

    Software-defined address mapping: a case on 3d memory,

    J. Zhang, M. Swift, and J. Li, “Software-defined address mapping: a case on 3d memory,” in Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2022, pp. 70–83

    2022

  44. [52]

    Software-defined far memory in warehouse-scale computers,

    A. Lagar-Cavilla, J. Ahn, S. Souhlal, N. Agarwal, R. Burny, S. Butt, J. Chang, A. Chaugule, N. Deng, J. Shahid et al., “Software-defined far memory in warehouse-scale computers,” in Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programm...

    2019

  45. [53]

    Kleio: A hybrid memory page scheduler with machine intelligence,

    T. D. Doudali, S. Blagodurov, A. Vishnu, S. Gurumurthi, and A. Gavrilovska, “Kleio: A hybrid memory page scheduler with machine intelligence,” in Proceedings of the 28th International Sympo- sium on High-Performance Parallel and Distributed Computing , 2019, pp. 37–48

    2019

  46. [54]

    Combining machine learning and lifetime- based resource management for memory allocation and beyond,

    M. Maas, D. G. Andersen, M. Isard, M. M. Javanmard, K. S. McKin- ley, and C. Raffel, “Combining machine learning and lifetime- based resource management for memory allocation and beyond,” Communications of the ACM, vol. 67, no. 4, pp. 87–96, 2024

    2024

  47. [55]

    Adaptive huge-page subrelease for non-moving memory allocators in warehouse-scale computers,

    M. Maas, C. Kennelly, K. Nguyen, D. Gove, K. S. McKinley, and P . Turner, “Adaptive huge-page subrelease for non-moving memory allocators in warehouse-scale computers,” in Proceedings of the 2021 ACM SIGPLAN International Symposium on Memory Management, 2021, pp. 28–38

    2021

  48. [56]

    {LinnOS}: Predictability on unpredictable flash storage with a light neural network,

    M. Hao, L. Toksoz, N. Li, E. E. Halim, H. Hoffmann, and H. S. Gunawi, “{LinnOS}: Predictability on unpredictable flash storage with a light neural network,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20) , 2020, pp. 173–190

    2020

  49. [57]

    Accelerating machine learning i/o by overlapping data staging and mini-batch generations,

    K. Serizawa and O. Tatebe, “Accelerating machine learning i/o by overlapping data staging and mini-batch generations,” in Pro- ceedings of the 6th IEEE/ACM International Conference on Big Data Computing, Applications and Technologies, 2019, pp. 31–34

    2019

  50. [58]

    Characterizing network requirements for gpu api remoting in ai applications,

    T. Wang, Z. Chen, X. Wei, J. Gu, R. Chen, and H. Chen, “Characterizing network requirements for gpu api remoting in ai applications,” 2024. [Online]. Available: https://arxiv.org/abs/ 2401.13354

    2024 arXiv

  51. [59]

    Using machine learning to improve operating sys- tems’ i/o subsystems,

    I. U. Akgun, “Using machine learning to improve operating sys- tems’ i/o subsystems,” Ph.D. dissertation, State University of New York at Stony Brook, 2022

    2022

  52. [60]

    Automated program repair: a step towards software automation,

    A. Roychoudhury and Y. Xiong, “Automated program repair: a step towards software automation,” Science China. Information Sciences, vol. 62, no. 10, p. 200103, 2019

    2019

  53. [61]

    Toward actionable testing of deep learning models,

    Y. Xiong, Y. Tian, Y. Liu, and S. Cheung, “Toward actionable testing of deep learning models,” Science China, Information Sciences, 2022

    2022

  54. [62]

    A novel insider attack and machine learning based detection for the internet of things,

    M. Chowdhury, B. Ray, S. Chowdhury, and S. Rajasegarar, “A novel insider attack and machine learning based detection for the internet of things,” ACM Transactions on Internet of Things , vol. 2, no. 4, pp. 1–23, 2021

    2021

  55. [63]

    Reboot- oriented iot: Life cycle management in trusted execution environ- ment for disposable iot devices,

    K. Suzaki, A. Tsukamoto, A. Green, and M. Mannan, “Reboot- oriented iot: Life cycle management in trusted execution environ- ment for disposable iot devices,” in Proceedings of the 36th Annual Computer Security Applications Conference, 2020, pp. 428–441

    2020

  56. [64]

    Vulrepair: a t5-based automated software vulnerability repair,

    M. Fu, C. Tantithamthavorn, T. Le, V . Nguyen, and D. Phung, “Vulrepair: a t5-based automated software vulnerability repair,” in Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering , 2022, pp. 935–947

    2022

  57. [65]

    Msndroid: the android malware detector based on multi-class features and deep belief network,

    X. Qin, F. Zeng, and Y. Zhang, “Msndroid: the android malware detector based on multi-class features and deep belief network,” in Proceedings of the ACM Turing Celebration Conference-China, 2019, pp. 1–5

    2019

  58. [66]

    Dynamic detection of mobile malware using smartphone data and machine learning,

    J. Panman de Wit, D. Bucur, and J. van der Ham, “Dynamic detection of mobile malware using smartphone data and machine learning,” Digital Threats: Research and Practice (DTRAP) , vol. 3, no. 2, pp. 1–24, 2022

    2022

  59. [67]

    Patching locking bugs statically with crayons,

    J. Cruz-Carlon, M. Varshosaz, C. Le Goues, and A. Wasowski, “Patching locking bugs statically with crayons,” ACM Transactions on Software Engineering and Methodology , vol. 32, no. 3, pp. 1–28, 2023

    2023

  60. [68]

    Ppfl: Enhancing privacy in federated learning with confidential computing,

    F. Mo, H. Haddadi, K. Katevas, E. Marin, D. Perino, and N. Kourtellis, “Ppfl: Enhancing privacy in federated learning with confidential computing,” GetMobile: Mobile Computing and Communications, vol. 25, no. 4, pp. 35–38, 2022

    2022

  61. [69]

    An efficient method for analyzing widget intent of android system,

    C. Qi, S. Shao, Y. Guo, J. Peng, and G. Xu, “An efficient method for analyzing widget intent of android system,” in Proceedings of the 2021 9th International Conference on Communications and Broadband Networking, 2021, pp. 78–85

    2021

  62. [70]

    Darknetz: towards model privacy at the edge using trusted execution environments,

    F. Mo, A. S. Shamsabadi, K. Katevas, S. Demetriou, I. Leontiadis, A. Cavallaro, and H. Haddadi, “Darknetz: towards model privacy at the edge using trusted execution environments,” in Proceedings of the 18th International Conference on Mobile Systems, Applications, and Services...

    2020

  63. [71]

    Enhanced user interaction in operating systems through machine learning language models,

    C. Zhang, W. Lu, C. Ni, H. Wang, and J. Wu, “Enhanced user interaction in operating systems through machine learning language models,” 2024. [Online]. Available: https://arxiv.org/ abs/2403.00806

    2024 arXiv

  64. [72]

    Unikraft: fast, specialized unikernels the easy way,

    S. Kuenzer, V .-A. B ˘adoiu, H. Lefeuvre, S. Santhanam, A. Jung, G. Gain, C. Soldani, C. Lupu, S ¸. Teodorescu, C. R ˘aducanu et al. , “Unikraft: fast, specialized unikernels the easy way,” inProceedings of the Sixteenth European Conference on Computer Systems , 2021, pp. 376–394

    2021

  65. [73]

    A survey of kernel-bypass techniques in net- work stack,

    R. Chen and G. Sun, “A survey of kernel-bypass techniques in net- work stack,” in Proceedings of the 2018 2nd International Conference on Computer Science and Artificial Intelligence , 2018, pp. 474–477

    2018

  66. [74]

    The dark side of unikernels for machine learning,

    M. Leon, “The dark side of unikernels for machine learning,”

  67. [75]

    The restless cloud,

    N. Pemberton, J. Schleier-Smith, and J. E. Gonzalez, “The restless cloud,” in Proceedings of the Workshop on Hot Topics in Operating Systems, 2021, pp. 49–57

    2021

  68. [76]

    The demik- ernel datapath os architecture for microsecond-scale datacenter systems,

    I. Zhang, A. Raybuck, P . Patel, K. Olynyk, J. Nelson, O. S. N. Leija, A. Martinez, J. Liu, A. K. Simpson, S. Jayakar et al., “The demik- ernel datapath os architecture for microsecond-scale datacenter systems,” in Proceedings of the ACM SIGOPS 28th Symposium on Operating Syst...

    2021

  69. [77]

    Unikernel linux (ukl),

    A. Raza, T. Unger, M. Boyd, E. B. Munson, P . Sohal, U. Drepper, R. Jones, D. B. De Oliveira, L. Woodman, R. Mancuso et al. , “Unikernel linux (ukl),” in Proceedings of the Eighteenth European Conference on Computer Systems, 2023, pp. 590–605. 31

    2023

  70. [78]

    Seuss: skip redundant paths to make serverless fast,

    J. Cadden, T. Unger, Y. Awad, H. Dong, O. Krieger, and J. Ap- pavoo, “Seuss: skip redundant paths to make serverless fast,” in Proceedings of the Fifteenth European Conference on Computer Systems, 2020, pp. 1–15

    2020

  71. [79]

    Dbos: a dbms-oriented operating system,

    A. Skiadopoulos, Q. Li, P . Kraft, K. Kaffes, D. Hong, S. Mathew, D. Bestor, M. Cafarella, V . Gadepally, G. Graefe et al. , “Dbos: a dbms-oriented operating system,” 2021

    2021

  72. [80]

    Llm as os, agents as apps: Envisioning aios, agents and the aios-agent ecosystem,

    Y. Ge, Y. Ren, W. Hua, S. Xu, J. Tan, and Y. Zhang, “Llm as os, agents as apps: Envisioning aios, agents and the aios-agent ecosystem,” 2023. [Online]. Available: https: //arxiv.org/abs/2312.03815

    2023 arXiv

  73. [81]

    Aios: Llm agent operating system,

    K. Mei, Z. Li, S. Xu, R. Ye, Y. Ge, and Y. Zhang, “Aios: Llm agent operating system,” 2024. [Online]. Available: https://arxiv.org/abs/2403.16971

    2024 arXiv

  74. [82]

    Memgpt: Towards llms as operating systems,

    C. Packer, S. Wooders, K. Lin, V . Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez, “Memgpt: Towards llms as operating systems,”

  75. [83]

    Os-copilot: Towards generalist computer agents with self-improvement,

    Z. Wu, C. Han, Z. Ding, Z. Weng, Z. Liu, S. Yao, T. Yu, and L. Kong, “Os-copilot: Towards generalist computer agents with self-improvement,” 2024. [Online]. Available: https://arxiv.org/abs/2402.07456

    2024 arXiv

  76. [84]

    Prompt sapper: Llm-empowered software engineering infrastructure for ai-native services,

    Z. Xing, Q. Huang, Y. Cheng, L. Zhu, Q. Lu, and X. Xu, “Prompt sapper: Llm-empowered software engineering infrastructure for ai-native services,” 2023. [Online]. Available: https://arxiv.org/ abs/2306.02230

    2023 arXiv

  77. [85]

    Peros: Personalized self-adapting operating systems in the cloud,

    H. H `e, “Peros: Personalized self-adapting operating systems in the cloud,” 2024. [Online]. Available: https://arxiv.org/abs/2404. 00057

    2024

  78. [86]

    Metagpt: Meta programming for a multi-agent collaborative framework,

    S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, C. Zhang, J. Wang, Z. Wang, S. K. S. Yau, Z. Lin, L. Zhou, C. Ran, L. Xiao, C. Wu, and J. Schmidhuber, “Metagpt: Meta programming for a multi-agent collaborative framework,” 2023. [Online]. Available: https://arxiv.org/abs/2308.0...

    2023 arXiv

  79. [2020]

    Available: https://arxiv.org/abs/2004.13081

    [Online]. Available: https://arxiv.org/abs/2004.13081

    2004 arXiv

  80. [2024]

    Available: https://arxiv.org/abs/2310.08560

    [Online]. Available: https://arxiv.org/abs/2310.08560

    arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.