47 ms·

> I think you're overoptimistic regarding what you can do with the source code Suppose you have a Java function. If you remove the file-system class at a syste

> I think you're overoptimistic regarding what you can do with the source code Suppose you have a Java function. If you remove the file-system class at a system level, what can that code do? It's pretty easy to isolate it so that it cannot compile to any kind of malicious code, only conduct computations to produce values. That's why you can open a website running JavaScript without as much worry for the security of your computer as you would have downloading a blob and running it. > I have no idea why you think either of those things? Well most of the software on your computer has the following api: int main(int argc, char **argv) This is because it needs to run as an executable. Without this requirement, software might have much more interesting APIs which are much more useful. But instead there is a requirement that all software is mashed into blobs and has all of the useful information removed from it. Additionally, just compiling the software from source does nothing to guarantee that it isn't malware. You can compile malware from source just as easily as anything else. The system I'm proposing does not allow for malicious programs to be compiled.

EraYaN 3y ago
You know that a main function is not really the only way to do programs right? Like shell integrations and other such things are exactly what you talk about. Those are software with "interesting APIs". It just does not make a lot of sense for a foreground application or at least some application that needs control. And besides if you have a look at Apple platforms and how they do communication with running applications, "interesting APIs" right there. And finally there is no requirement at all that ELF binaries are stripped of useful info (symbols, debug info etc), there is a desire though to save disk space and make reverse engineering harder. All of this has nothing to do with the executable code format (native vs byte code or what have you).
- James_K 3y ago
  > You know that a main function is not really the only way to do programs right? > there is no requirement at all that ELF binaries are stripped of useful info Yes, you can add useful information to a program. This is what I'm advocating for. The issue is that most people don't do this, which is what I'm complaining about. Consider the difference between distributing executable files vs. Python libraries for instance. > All of this has nothing to do with the executable code format I don't see how you can write an entire comment about the format in which code is distributed and come to this conclusion.
  - EraYaN 3y ago
    The actual binary format will be the same regardless of extra info shared together with the actual code. That was my point, so it honestly does not matter for any sufficiently complicated product how it's shipped. The problem is the incentives, people don't WANT to share that data with you. And there are very good reasons to not ship an application as plain python, the biggest problem is all the dependencies that that requires. And the impact that has on the user.
    - James_K 3y ago
      The binary format is always the same, you need to get to machine code at some point. The difference is how you get there. > it honestly does not matter for any sufficiently complicated product how it's shipped. I think this opinion is in deep disagreement with the facts. Among the most popular and influential computing technologies, you have Java and WWW. Both are entirely based around shipping code in better format than binary.

EraYaN 3y ago

You know that a main function is not really the only way to do programs right? Like shell integrations and other such things are exactly what you talk about. Those are software with "interesting APIs". It just does not make a lot of sense for a foreground application or at least some application that needs control. And besides if you have a look at Apple platforms and how they do communication with running applications, "interesting APIs" right there. And finally there is no requirement at all that ELF binaries are stripped of useful info (symbols, debug info etc), there is a desire though to save disk space and make reverse engineering harder. All of this has nothing to do with the executable code format (native vs byte code or what have you).

James_K 3y ago
> You know that a main function is not really the only way to do programs right? > there is no requirement at all that ELF binaries are stripped of useful info Yes, you can add useful information to a program. This is what I'm advocating for. The issue is that most people don't do this, which is what I'm complaining about. Consider the difference between distributing executable files vs. Python libraries for instance. > All of this has nothing to do with the executable code format I don't see how you can write an entire comment about the format in which code is distributed and come to this conclusion.
- EraYaN 3y ago
  The actual binary format will be the same regardless of extra info shared together with the actual code. That was my point, so it honestly does not matter for any sufficiently complicated product how it's shipped. The problem is the incentives, people don't WANT to share that data with you. And there are very good reasons to not ship an application as plain python, the biggest problem is all the dependencies that that requires. And the impact that has on the user.
  - James_K 3y ago
    The binary format is always the same, you need to get to machine code at some point. The difference is how you get there. > it honestly does not matter for any sufficiently complicated product how it's shipped. I think this opinion is in deep disagreement with the facts. Among the most popular and influential computing technologies, you have Java and WWW. Both are entirely based around shipping code in better format than binary.