Get best of the week

Sivelkiriya OS：任务和发射表

哈Ha

这是有关当前正在设计的Sivelkiriya OS的一系列出版物中的第二篇文章。第一篇文章在这里，下一篇文章在这里。由于对它的评论反复询问了整个事业的目的，以及为了使其“腾飞”而必须在开发中投入的劳动力数量，因此，该出版物将主要关注这些问题。

首先，将描述此开发的任务（在以下文章中，将在摘要中添加对拟在此开发框架内解决的现有软件的那些系统性问题的详细概述）。其次，以启动建议的操作系统的可能方式为例，将显示即使在关键数量的可用软件被征用或完成向新系统的完全迁移之前，也有可能开始从开发中受益。

本文中提到的技术和组织方面将在以下出版物中详细描述。

OS Sivelkiriya的任务


Sivelkiriya操作系统的任务是基于保证任何软件解决方案兼容性的平台，将完全不同的数字产品集成到一个和谐的整体中。

最好将此原则表述为利益相关方的基本权利，并在操作系统Sivelkiriya的框架内实施这些权利，这要由交互的组织和操作系统本身的结构来保证。以下是此类条款的完整列表，并对Sivelkiriya操作系统对实现此权利的贡献做出了一些解释。

  1. 用户有权选择最适合其需求的软件解决方案。
    • 所使用的任何模块都可以替换为另一个更合适的模块，而无需重建或丢失解决方案的整体功能。
    • 可以轻松访问有关模块提供的功能的信息（在API级别及其目的描述上，最终用户可以理解）。
    • 在存储库（商店）级别执行的功能和性能测试，使开发人员和用户可以监视所提出解决方案的质量。也可以使用常规的召回系统。
  2. 用户有权为所使用的每种服务选择付款方式。
    • 可以免费提供模块或内容，也可以付费（一次性或通过订阅）提供模块或内容，也可以交换观看广告的方式。
    • , , ( ), . , , , , .
  3. .
    • — . , ( ).
    • . , .
    • , (, , ), , . (web, , , , ).
    • , . .
  4. .
    • . , .
    • . ; , .
    • . .
  5. .
    • , .
    • . , . .
    • , .
  6. .
    • .
    • , (, , , ) .
  7. .
    • .
    • .
  8. , .
    • , .
    • .
    • , , , .
    • , , , , — , , .
  9. .
    • , , , , .
    • , .
    • «» (, ) .
  10. / .
    • .
    • , , , , , .
    • , , , .
  11. .
    • . , , .
  12. .
    • , , , , .
    • , , .
    • , ( -), , .
    • (. ) .
  13. .
    • , .
  14. .
    • , «» . ( ).
  15. .
    • , , , .
    • 与软件一样，中央存储库支持团队为所有者和知识产权提供者提供支持，包括阻止海盗。
  16. 企业用户有权以封闭模式开发软件。
    • 可以创建封闭的存储库，这些存储库不能从基础架构之外传输软件。
    • 为满足自己的需要而开发软件的公司有机会在必要时脱离由OS开发团队规定的接口和模块的结构，但是此类软件的可用性受到其组织的限制。


平台覆盖



Sivelkiriya操作系统设计为在以下模式下运行：

  1. 作为x86和ARM平台上的主要操作系统；
  2. 作为主操作系统下的一组图形应用程序；
  3. / .


下面我们将说明为什么需要这样的机会。

作为主要操作系统启动，Sivelkiriya可以直接控制可用设备。一方面，这允许对系统资源（例如，处理器时间和RAM）的开销进行最佳控制。另一方面，它为用户带来了艰难的选择：完全切换到新的操作系统，在该操作系统下，最初可能没有足够的软件来舒适地工作，或者根本不使用它。可以说很多年轻的操作系统不能克服这个里程碑是不可能的错误：缺乏程序会吓跑用户，而缺乏用户会吓跑开发人员。

为了解决这种不愉快的情况，Sivelkiriya OS提供了第二种启动方法-作为针对某些基本操作系统（例如Windows，Linux或Android）编译的一组应用程序。从其中启动的模块的角度来看，第一种选择没有什么区别，因为它们仍通过同一API与其他模块和内核进行交互。从用户的角度来看，不同之处在于，他现在继续使用其主要操作系统，仅使用Sivelkiriya来解决其中最方便解决的那些任务。

最后，Sivelkiriya程序集的第三个版本是使其中存在的对象接口对某些外部上下文可见。结果，第三方软件将能够以与使用普通共享库相同的方式来使用Sivelkiriya模块，尽管内部实现可能意味着模块之间的交互以及它们在不同库或进程中的分布，但这些细节将在调用上下文中隐藏。从Sivelkiriya本身的功能的角度来看，第二个和第三个启动选项之间的区别仅在于，在第二种情况下，用户与其图形界面进行交互，而在第三种情况下，API被其他系统调用。

提议的选项使您可以尽可能地用程序填充新操作系统，因为完全迁移的决定可能会被延迟或完全拒绝，从而仅继续使用特定用户所需的功能。因此，将以最小的成本实现Sivelkiriya面临的主要目标-确保兼容性和可访问性。

在其他操作系统下启动时，是否应该将Sivelkiria称为操作系统的问题留给了理论家，因为出于我们的目的，这不是原则问题。

该周期的第一个出版物在这里，下一个在这里。文章的全文可在项目网站上找到。

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles