Mindey, 
Appless OS
Operating system without user-facing apps. Instead, exposes basic functionalities, high level programming language, API and data.
Today, pretty much all operating systems allow installation of apps. However, apps share basic functionalities, for example, there is a plethora of calling apps, messaging apps, payment apps, drawing apps, etc. etc. etc.
Since all that people really need is the functionality and data, not the apps per se, "Appless OS" virtualizes all the apps and runs them in virtual containers under the hood, and has drivers to emulate the user, and virtualization layers, that provides the functionality of the apps via drivers framework (like "Metadrive") that drives apps, rather than exposing user to interact with them manually, collects and organizes the data from those apps, and provides it for the user in a unified interface, that implements viewer for items with arbitrary properties as generalized:
- Lists
- Matrices
- Trees
- Graphs
The "Appless Merge OS / DB" would introduce a high level programming language and a unified API, that allows user to have true ownership of their OS. Instead of "OS" as a framework for apps, it is just an "easily programmable OS, that takes care of being a good DB of everything on it".
我歡迎更大抽象，功能優先的想法以及將整個智能手機作爲數據庫的想法。我敢肯定，當前的Android API已經允許一些接近該API的東西，但是（也許）不像查詢數據庫那樣簡單。
基本上，您想要的是使應用程序具有操作系統所有者身份（直到私有方法和應用程序存儲）的透明性，但不與未經明確許可的其他應用程序透明，而不與其他身份（例如可能安裝了操作系統的供應商的身份）透明操作系統）。
I welcome the idea of greater abstraction, and functionality first mindset, as well as having entire smart phone as a database is nice. I'm sure the current Android APIs already allow something approaching that, but (perhaps) not as simply as querying a database.
Basically, what you want is the transparency of apps with the OS owner identity up to the private methods and storage of the apps, but not with other apps without explicit permission, and not other identities (like that of vendor, who may have installed the OS).
應將應用程序提煉爲查詢計劃。有一個查詢計劃，代表應用程序進行的所有查詢以及每種查詢的相對頻率。
人們可以設計應用程序的所有交互-顯示數據或允許修改數據的所有屏幕。然後，查詢計劃者可以生成高效的應用程序，直到用於數據佈局的單個查詢爲止。
讓我們讓計算機爲我們佈置數據。
Apps should be distilled to query plans. There is a query plan that represents all the queries that an app makes and the relative frequency of each type of query.
People could design all the interactions of an app -- all the screens that show data or allow data to be modified. Then the query planner can generate an efficient app, down to the individual queries used to the layout of data.
Let's let computers layout data for us.
稱他們爲APP PLANS。
應用計劃包含UI屏幕列表.....以及在屏幕上顯示或可修改的數據字段。
應用計劃還指定要與屏幕上的數據一起使用的後端集成API。因此將有一個調用API。呼叫API會以數字字段作爲電話號碼作爲輸入，您可以將呼叫API與屏幕上的字段連接起來
Call them APP PLANS.
App plans contains a list of UI screens.....and the fields of data that is displayed or modifiable on the screen.
App plans also specify the backend integration API to be used with the data that is on the screen. So there would be a call API. and the call API takes a numeric field as input which is the phone number, you can wire up the call API with the field on the screen
數據庫中的查詢計劃者可以根據行數和需要查詢的索引來制定有效地執行查詢的方法。應用計劃確定瞭如何有效地制定實施應用程序的方法。
應用計劃者在檢索數據時將考慮以下事項：
-需要檢索以顯示界面的數據 -如何構造對服務器的查詢-發送查詢或發送查詢名稱？ -在顯示之前對數據進行轉換。
如何從數據結構生成用戶界面：
數據庫可能將數據存儲爲樹，圖或矩陣。如何以用戶易於理解的方式顯示這些信息？應用計劃者將使用一些啓發式方法來生成帶有選項卡，列表和項目豐富呈現的UI。有點像django管理員畫面。
計劃者應將各種技能捕獲到可計算的專家系統中，例如可訪問性要求，創建有效的可重複任務。
Query planners in database work out how to efficiently execute queries based on how many rows there are and the indexes that need to be consulted. App plans work out how to efficiently work out how to implement apps.
The app planner will consider the following things when retrieving data:
How to generate a UI from a data structure:
The database might store the data as a tree, graph or matrix. How to surface this information in a user understandable way? The app planner will use some heuristics to generate UIs with tabs, and lists and rich rendering of items. A bit like django admin screens.
The planner should capture various skills into a computable expert system such as accessibility requirements, create efficient repeatable tasks.
有趣的是，幾乎所有應用程序都只是帶有修改規則的類型相關對象的排列。可以想象有類似“與應用程序無關的對象”（AIRO）之類的東西，它們組合起來的行爲就像一個應用程序，但不是應用程序，而是具有獨立標識和地址空間位置的自由對象。
It is interesting to consider, that pretty much any application is just an arrangement of related objects of types with modification rules. One could imagine having something like "Application-Independent-Related Objects" (AIRO), that in combination behaves like an application, but are not an application, but rather are free objects with their independent identities and locations in address spaces.