h a l f b a k e r yBaker Street Irregulars
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Appless Merge OS / DB
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 ton of call apps,
messaging apps, payment apps, drawing apps, etc. etc. etc.
Since all that people need is the functionality and data, not the apps,
"Appless
Merge OS" has drivers 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 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".
[link]
|
| |
the serverless approach from both AWS and Azure is kind of
going in this direction, isn't it? |
|
| |
Are you just describing a web browser? |
|
| |
In the 90's there was a lot of hullaballoo about widget based os or document workflows, where library widgets were what were sold, and you assembled them as you like to do what you wanted on the computer. |
|
| |
however i think what defeats this, is that people really are sensitive to holistic experiences, which is why a chat app, can be better then another chat app, and why one image sharing program, is better then another. Just because of some small extra feature or slicker experience. That whole experience is controlled by the app. |
|
| |
So in your system how do you encapsulate nice workflows, that you might like to share? Might you not just package them in boxes and call them apps? |
|
| |
// Are you just describing a web browser? |
|
| |
Not really. Web browser does not have generalized data model that
would abstract all apps and data in all formats, and does not work as a
generalized database. |
|
| |
// that people really are sensitive to holistic experiences |
|
| |
Yes, they are. However, we don't know how sensitive they will be about
the simplicity. Namely, imagine a "Calls" functionality, which have
"SIM Card Call", "Telegram call", "WhatsApp call", "WeChat call".
When you click it, it just makes the call, and provides you all data
about it,
from those apps, which it runs and controls itself. If the apps in
question have the public APIs, then using their APIs; if they have no
public
APIs, then through the virtualization the whole app in the background,
and providing that functionality through the UI and I/O control, that
abstracts away the need for humans to use ***apps***, returning
humans to using ***functionalities*** (+user gets data and
programmability). |
|
| |
The "Calls" functionality, then would be the generic client of these apps
for this
functionality (instead of user having to learn new interfaces),
simplifying
the overal experience, which is defeats the "sensitivity to holistic
experiences" with "simplicity of experience, and user's ability to record
and
programmatically control those resources, and get normalized,
organized data". |
|
| |
// where library widgets were what were sold |
|
| |
Being that there is just a very small set of widgets that are needed to
display lists of lists (after all, all other types of data, even bytes, even
graphs, are just lists of lists of bits), this library could easily be open
source, like Twitter Bootstrap is. |
|
| |
The OS would provide user with the functionality and data from those
apps without compromising the user's data and control. Such OS
may be of interest to power users, intelligence community, and military,
which needs that control, however, can also be of use to
communications providers, which are also credit institutions, which
want to provide extra services based on all the data from all of "apps"
abstracted away and being controlled by such drivers subsystem. |
|
| |
One benefit, it would be able to provide functionality and data from app
services in a consistent OS-level environment that can virtualize
and provide any apps designed to be run in any OS. For example,
need only the coordinates and their transformations from Autodesk
Inventor? No problems, a driver can instantiate it on virtual machine,
and provide the API to control the objects being engineered with it,
without user having to manually control Autodesk Inventor's UI. |
|
| |
This kind of OS would also be useful for simplifying the building of
artificial intelligences to achieve goals using arbitrary APIs and UIs,
which are originally designed to be used by humans "sensitive to
holistic experiences" -- when the data from all apps is aligned into OS
database, and the control operations are unified, it will make it much
easier to use the functionalities of all apps without having to learn their
new "holistic experiences", easier to understand the whole, and to
program behaviors. |
|
| |
[Mindey] You seem to describe an AS 400. |
|
| |
[Toto Anders], I guess I know an expert on AS/400s. How were they
superior to what I described? |
|
| |
"Namely, imagine a 'Calls' functionality." |
|
| |
"Namely, imagine a 'Calls' app." |
|
| |
Just make a nice icon for it. |
|
| |
// "Namely, imagine a 'Calls' functionality."
// fixed:
// "Namely, imagine a 'Calls' app." |
|
| |
Well, call it "meta-app" then, because it is the one to provide pure
functionality, extracted from apps, as a client of all apps with that
functionality, as OS-level service. |
|
| |
// people really are sensitive to holistic experiences // |
|
| |
Doesn't this offer an even bigger holistic experience, by making all apps work
and look the same? It would be like what the current OS providers have tried
to encourage app developers to do through their interface guidelines, but
successful. |
|
| |
// would abstract all apps and data in all formats // |
|
| |
I think the difficulty in creating such an OS is right there: it has to support all
conceivable data types and app features, even those not yet conceived. That
is almost certainly possible, but probably extremely difficult (unless you
cheat and achieve it by allowing apps to provide their own UIs, which defeats
the whole purpose). |
|
| |