5 ms·

I believe that the root problems are programs having direct access to environment, being compiled down to hardware instructions, and these instructions not bei

I believe that the root problems are programs having direct access to environment, being compiled down to hardware instructions, and these instructions not being easily interpretable (without having access to an already made interpreter) These problems cause software to depend on highly specific platforms [1] that prevent any hardware from being standalone-ly sustainable. * Environment access creates the opportunity for security risks, and dependencies that cannot be fulfilled on different platforms (e.g. asking for touch input on a desktop device) * Being compiled to hardware specific instructions obviously prevent the same software to run on different hardware, rendering them obsolete sooner than otherwise necessary * These instructions being hard to implement prevent individual users from creating their own interpreter, therefore creating the need for a centralized entity to provide it. In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set ("understandable" referring to the amount of time it would take for a new developer to fully implement it) and leave environment access out of the spec (How the software convert an input request to your mouse position remains platform specific). This way, all software becomes permanently available without depending on any external entity, but new devices would still be free to improve the process [1] - https://support.discord.com/hc/en-us/articles/213491697-What-are-the-OS-system-requirements-for-Discord- https://support.discord.com/hc/en-us/articles/213491697-What...

ben-schaaf 3y ago
> In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set and leave environment access out of the spec This is already the case. The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. If you take a nice small instruction set - leaving environment access out of the spec, and then attach device specific cameras, modems, displays, sensors, accelerators, etc. and then build an OS with a web browser and apps that interact with all the extra hardware. What you've invented is the modern smart phone. It runs on ARM - an easily interpretable instruction set. Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.
- TheMode 3y ago
  > The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. 100% agree, hence my suggestion to completely remove environment access from the instruction set. No syscall. > It runs on ARM - an easily interpretable instruction set. I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. > Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did. The instructions allowed them to depend on platform specific features, which is what I want to prevent. Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Then, it would be up to the OS to decide how to interpret that request, maybe that the string is part of some standardized way to retrieve a gesture input in which way automate it, but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
  - ben-schaaf 3y ago
    > I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. 2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand. > The instructions allowed them to depend on platform specific features, which is what I want to prevent. > Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility. > but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access. Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.
stjohnswarts 3y ago
All I can say is good luck with all of that. I don't see any company ever doing that.
fsflover 3y ago
Looks like you need a GNU/Linux phone like Librem 5 or Pinephone.

ben-schaaf 3y ago

> In other word, my suggestion would be to create a new target platform that compile down to a very understandable instruction set and leave environment access out of the spec This is already the case. The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. If you take a nice small instruction set - leaving environment access out of the spec, and then attach device specific cameras, modems, displays, sensors, accelerators, etc. and then build an OS with a web browser and apps that interact with all the extra hardware. What you've invented is the modern smart phone. It runs on ARM - an easily interpretable instruction set. Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did.

TheMode 3y ago
> The vast complexity of modern software and hardware comes from the ever more complex environment they interact with. 100% agree, hence my suggestion to completely remove environment access from the instruction set. No syscall. > It runs on ARM - an easily interpretable instruction set. I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. > Discord not running on older phones is entirely due to them depending on newer operating system APIs. It's not the instructions that changed, the environment did. The instructions allowed them to depend on platform specific features, which is what I want to prevent. Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Then, it would be up to the OS to decide how to interpret that request, maybe that the string is part of some standardized way to retrieve a gesture input in which way automate it, but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access.
- ben-schaaf 3y ago
  > I give you 2 hours to write a brand new fully spec compliant ARMv8 interpreter, 3 hours to write an android VM to run on my windows laptop. 2 hours is pushing it for pretty much anything. I am pretty confident I can make a 64bit risc-v interpreter that'll boot Linux in a few days. Wouldn't be fast and wouldn't have IO, but neither of those have any baring on how easy the instructions are to interpret. The spec is fairly easy to understand. > The instructions allowed them to depend on platform specific features, which is what I want to prevent. > Instead of calling some random android `external_is_switch_gesture` syscall the app should request a boolean/bit given a string "Has there been a switch gesture?" and expect the result of that syscall to be what they asked for. Ok so in order to make it fast we're not going to use strings, instead integers that we only ever increment for new syscalls (no conflicts, ever). Applications want to know whether the system has support for a syscall, so we return an error if they don't exist. This is how Linux syscalls work. Lets use your hypothetical: I'm writing a game that makes heavy use of switch geatures. I make my game call the "Has there been a switch gesture?" syscall, but whoops switch gestures were added in version 6 but this customer is using version 5. The absense of this syscall is fundamentally incompatible with my game, so I guess I'll put "requires version 6" on the website. This is the status quo. Nothing you've suggested is a fundamental change to how software/hardware works. As long as new things are being invented/written you can never have full backwards compatibility. > but if it is not you could simply prompt the user to chose what to give the application given a list of all the possible environment access. Just to be thorough this is fully possible right now - intercepting unknown syscalls and showing a prompt - but there's simply way too many and their behavior too complex for it to be of any use. Especially non-experts would have exactly zero chance.

stjohnswarts 3y ago

All I can say is good luck with all of that. I don't see any company ever doing that.

fsflover 3y ago

Looks like you need a GNU/Linux phone like Librem 5 or Pinephone.