styx takes a pro-"Program", anti-"App" stance to its own software. We won't forbid "apps", that's silly, but we won't be making our stuff an "app" for sure.
But on the flip side - I want styx and its own software to be approachable to the common person - as if it were an "app", where possible, excluding fine technical tunings and things like that.
Ideally, styx does what Mac OS X Server tried to do, when it comes to services and plug-in functionality - making it manageable, visible, and workable from a familiar and discoverable frontend.
styx being a consent-first OS1, means that the way apps update is a process you have control over. We want to ensure good forward- and roll-back compatibility for user configurations, too, but I think a better spot for that would be snapshotting and differential/transactional configuration management and access through styx's etcfs2 management.
In our repos, we will keep differential history for app sources perpetually, if possible; and for binaries, as long as is reasonable. This also owes to the importance of software freedom3 - as a means to present to the user a better promise of consent and autonomy over their own systems.
(If you're reading this from the website: see the parent post on Cohost for more opinion on this matter.)
-
[TODO: a post on etcfs!] We are planning on managing /etc/ in styx as a virtual filesystem backed by a database, more akin to the Windows Registry than a true filesystem. /etc/ remains where it is, for compatibility, in a virtual directory mount; but styx-aware programs and dconf interfaces can directly handle setting entries through our configuration management API.
