oh god how did this get here i am not good with computer

 


 

Background music:
Click here because I can't put an audio widget in the profile

 

The scenes with the shark are usually very intense and disturbing.

 

I use Arch BTW

 

Fun fact: Neo-Nazi dipshit cartoonist Stonetoss is in fact Hans Kristian Graebener of Spring, Texas


This post got me thinking about what a modern desktop OS should actually look like so I'm opening this for brainstorming


Requirements

  • Highly portable, core system written in modern language(s)
  • Targeted at desktop use
    • GUI and command-line both available, system boots directly to graphics mode except possibly for rescue/safe mode cases
  • Pervasive case-insensitivity
  • Pervasive hooks for extension points throughout the system (see below for some examples)
  • Versioning FS
    • Full ACL permissions in FS
    • Extension points for FUSE-style userland filesystem implementations
  • System configurations all in plain text files
    • All configurations are available both through hand-hacking config files and through UI
  • Async and memory-mapped IO as OS-level IO models
    • Network IO available through all standard file functions as well as through socket interface, ie you can open a URL as a file transparently
    • Modern encryption as part of base system with extension points for adding new algorithms, etc
  • Shared memory pages as primary IPC mechanism
  • Message-driven by default
  • Modern VM hypervisor in base system
    • First-class emulation framework hooks integrated with the hypervisor system so that system emulators can be built that can be treated transparently as VMMs
  • High-quality support for printers, plotters, scanners, tablets and cameras
  • Low-latency audio in base system
  • UI built around user affordances: Traditional menus, button bars, scroll bars, etc.
  • Three graphics APIs in core:
    • Vulkan as low-level graphics library
      • Low-level low-latency frame capture hooks at this layer for supporting eg screen recording, OBS capture, Sunshine, etc
    • 2D acceleration built on top of Vulkan
      • Hooks for network transparency at this layer for eg RDP support
    • High-level graphics library built on top of 2D library, used for normal window drawing
  • ANSI terminal library in core
  • Versioned release model for production releases, rolling for dev branch
  • Core utils include all compilers required to rebuild the world
  • Extensive help system available both from the command line and GUI
    • Help files are written in a restricted subset of standard HTML
  • AGPLv3 for all kernel and new system utilities

Anti-requirements

  • No DRM, phone home nonsense, user tracking or ads in the base OS
  • POSIX compliance in the base OS (supported via compatibility library)
  • Windows compatibility in the base OS (as above, via Wine port)
  • Microkernel
  • Any C or C++ code in the base system
  • Suitability for use as a server or embedded/device OS
  • Hamburger menus or any other interface hiding in any core tools

You must log in to comment.

in reply to @DecayWTF's post:

UI built around user affordances: Traditional menus, button bars, scroll bars, etc.

I'm just going to throw this out there because why not even if a lot of the user-facing design is going to be arbitrary anyway but: a reprioritization of one-button mouse design. Between touchscreens and shitty trackpads assuming that a user can reliably right-click is starting to feel user hostile.

I feel like the major underlying thread here is "give the user control of their computer without forcing them into the depths of Unix hell" and basic things like "hey, tell me how you want to operate this thing" are definitely in line with that. Like we're kind of in a situation right now where you have to earn the right to have a computer that works for you instead of for Microsoft or Apple or Google and that is deeply fucked

Yes, you're right, and accessibility hooks should be built in at every layer. Ideally you'd be able to interface at every user-visible IO layer so that we'd have orthogonal frameworks for all sorts of assistive technologies and clean APIs to support any/all external assistive devices as well.

I dunno, there's a number of ways to approach that, the most obvious one being that every configuration key and section should have their names translated to every supported language, which is not an especially huge demand given the extent that translations have to cover in any modern software anyway, and that each translation should be interchangeable. Just as a trivial example (and assuming some version of .ini as the configuration language), let's say a blob talking about graphics settings:

[Display.Defaults]
Resolution=1920x1080
Depth=32
Monitor=HDMI-1

Would be held equivalent to:

[Écran.Défaut]
Résolution=1920x1080
Profondeur=32
Écran=HDMI-1

and could even be intermixed:

[Écran.Défaut]
रिज्योलूशन=1920x1080
Depth=32
モニター=HDMI-1

Actually, thinking about this, this has a lot of really good consequences because:

a) You can copy elements into any localized config file from any other localized config file without translating. This avoids the problem of people seeing information in another language and having to decipher it before being able to use it (viz. a Chinese person finding an English StackOverflow question on "How do I manually set the default screen resolution?").
b) Proper support forces programmers to use the system library for config file parsing instead of rolling their own which enforces consistency.
c) Since the translations are machine-encoded anyway and have to be parsed, configuration files could be automatically localized. The person in a) getting the English configs for setting the screen settings would be able to let the computer fix it up for them; they load the Display controls and it pops a message saying "Your configuration file has foreign language elements in it. Should I translate them? >YES >NO >NO AND NEVER ASK ME AGAIN". As long as devs follow b) correctly there's no extra burden on them and there's no long-term pain for the user either.

You'd have to be careful to avoid false friends in config keys but I don't think that's a huge problem, and for values that are some form of enum you could even do the same for those, true and false having localized versions for instance.