SoftwareDepedenciesSemantics

A program can support various output-input-interface types.

Output

text
- ascii
- unicode
sound
graphics
- pixel oriented
  - accelerated
  - not accelerated
- curves oriented
  - accel
  - not accel
- vector oriented @
a11y
- braille refresh displays @
- tactile displays
- speech synthesizers

depedencies semantics / hw,sf

So a braille program could need a special output device + display server to work. Should a distro package manager contain such depedencies ? braille-game DEPENDS on braille-display-server .

Currently depedencies have assumptions. eg: pikwm (a pixel-oriented graphic display window manager) can be installed by apt even though a user has a system with no such display or the user could have such a display but dont not have installed a server.

So apt assumes that if for example user wants to use a braille app s(he) must have already connected a suitable device and installed a suitable display type server.

It can be argued that hardware depedencies is out ot the scope of a package manager. Maybe because using a package manager means using a software thus a user has already access to a computer.) . But there are various kind or hardware. And dont forget Linux is basically a core bundled with a multidute of device drivers.. So you can use with a Linux running system only hardware that Linux supports.

Althougth there is hardware that is a system's core and peripherals. It's isnt asking to much for a system to know what type of hardware can access and thus enforce hardware depedencies. I guess plug-and-play@ had similar considerations and intentions.

A OS is software. One of the first thing you learn is that the OS have some hardware depedencies-requirements . And as Microsoft company 1) has shown recently that could mean buying a new computer!!! 2) it can check them with update validators. Video games also have specific requirements that sometimes need specific vendor's gpus!.

Does Devuan has hardware requirements? Yes. (see @) So as the linked discussion reveals in our days even stating that your OS or Linux distro needs X86-64@ architecture is not enough (for some distros like Redhat @ or Suse @).

depedencies semantics / devuan

Using apt means you have access at least to a bare minimum computer with a supported architectute (cpu , ram , storage), a display monitor and a keyboard and that Linux is installed (apt speaks to linux to do it's stuff.). Also due to Linux-Unix's history there i class of software that can function with only TextUI and dont use the pixel-addressing that a display monitor can offer from some decades ago.

This tui-class is necessary in remote vps sysadmin and disaster recovery and troubleshoot even in OS like windows. Also there are sysadmins that use the TTY as their main workspace (for example sysadm fireborn @).

Lets pause a moment. Fireborn (in the link just given) mentions a decision he made to switch to desktop. Now why is that ? I mean why (as SNL's Black Santa would claim) why cant we have both? He claims that using only TTY-TUI centric programs offered more control and speed. Why a user cant have in a single workflow a TUI a GUI a TactileUI a SoundUI centrics programs ? What if a user is tired and wants to use a workflow with voice only ? Or his getting old age and want to compement visual with tactile feedback. And thinking of it a GUI enviroment CAN integrate a TUI enviroment. So i guess the user meant additionally that for certain workflow (like emails,browsing) he switched to GUI. But again couldnt the same program support many output types ? There are programs like emacs , cdda that have both TUI and GUI version. So if EACH core program from the installer to the shell to the window manager supported a multi typed UI then that would be a step forward.

Lets connect some dots. I think that a program that can be integrated into TUI-centric or HapticUI-centric or SoundUI-centric workflows is like a person that learn for example a sign language @. Can we say that a program can not be integrated into a non visual workflows ?

But the majority of software in Devuan-Debian repos to function need to use the pixel-addressing display capabilities . That means mainly that a display server must be installed. But a Linux distro installer can allow you to install a working linux system without a display server.

So a duality in capabilities of a core display device created a dual division in ALL the packages of a release. But it's not a strict dichotomy. A TUI apps can run inside a GUI-desktop. So we can have a TUI-centric workflow inside a GUI-Desktop. Why cant we have a GUI-workflow inside a TUI-Display ? Is that a hard assymetry ? If naively we start thinking about it and say: You know .. GUI is more complex and TUI is simpler. That is the assymetry.. If we transfer a GUI app to TUI we will lose information.But wait. Fireborn said that a TUI centric workflow fealt more integrated, accessibly , maintainable ,controlable-transparent and really fast! So who is the weak here in that asymetry ? Could it be that a GUI app offers more information BUT its not as integradable in broader workflows as TUI programs ? And in that case a GUI program offering a TUI-face could be seeing as a sign of power not weakness. Could it be that a pixel addressable display suffer from exposing a infinite type space that makes integration suffer ? Read how Fireborn complains about the GUI space. Could it be that a VectorUI space could offer merits of both ? And could a VectorUI space be more easilly embedded into a TUIspace or Haptic space exactly because is more type-able ?

It's logical to assume that a distro could contain also software that contains code that is specific to certain type of hardware or tied to services and functionality that are accessible throught internet.

irc client need internet
some pixel graphic oriented apps need accelerated gpus or apus to function properly.