4 ms·

> In order for this to be a "Python user space", you would need to implement or include a lot python equivalents of standard user space tooling. Python grep, py

> In order for this to be a "Python user space", you would need to implement or include a lot python equivalents of standard user space tooling. Python grep, python awk, python top, python vi, python gcc (lolz), and even python CPython (lolololz), etc. Who says you need those particular utilities to make a user space? You could have a user space without a shell, much less gcc, vi or awk.

bonestormii_ 6y ago
I mean, okay, you don't need vi or awk to call it Linux. But surely you agree that CPython is needed to run Python, yes? Its interpreter is written in C. To build it, you need a shell, make, gcc, and a text editor would be most helpful. It's all part of the user space. You can hide it within the snakeware application (why?), but don't deny it exists in the Linux user space. And C Python needs C extensions (pygame, for example), so GCC is at the very least a very-very-nice-to-have, is it not? What is the goal here? You want to run Python without a shell? A huge number of python scripts depend on the shell. You are increasing barriers to using Python to code interesting apps in this system. Should the shell be implemented in Python, too? It could be, but why? Why not just integrate a standard shell, and present some nice-ish way of interfacing with it via Python? I don't think that this application itself can even work in such an environment (no shell, no init system, etc). Currently this project is depending on a shell provided by Busybox. It uses these underlying tools to initialize and configure the operating system. It's all there in the user space, just hidden beneath this application. Look, there are no laws about this sort of thing. You can do what you want and call it what you will, and I'm not some tech lingo fascist trying to impose my idea of "user space" on anyone (even though it's really a term with a specific meaning of 'anything outside of the kernel', for which making an all-python version sounds highly difficult). I'm merely pointing out that a great deal of this user space is actually already non-python, and user space carries with it a lot of linux's essential functionality, largely via the GNU core utils and other common utilities which are written in a wide variety of languages. You can choose to hide all of that functionality to make a python-only sandbox... but.... then... ...Couldn't I just use pygame to make standard applications that run on all distros outside of this isolated "window manager" program? All this achieves right now is isolating your apps in this kind of simulated window environment, and preventing the user from ever doing anything meaningful unless they have a specially coded snakeware(tm) python app. It can never run a standard installation of something like Firefox; utilize any standard Linux CLI software; utilize an existing package management system or the packages from it; etc. because it has no shell, and doesn't make use of the standard Linux graphics compositors (X11/Wayland). So having said all of that, my goal isn't to tear down the project, but to ask the hard question for the benefit of this project: What is the goal? What I see here is mainly a simulated window manager written in pygame which can only ever run specially-created GUI apps, which is booted into directly. This design can never become a viable distro as it stands. This is a cool project. A fun project. But first and foremost, this is about 1400 lines total of Python and shell script. It's not really all that much yet, and it's not going to get there by pretending this design is sustainable to become some robust user environment where everything is Python. Sometimes, complying with standards and specifications are what make a thing the thing it is. And this is not a Python-only user space Linux distro. It is a simulated window manager written in Python that runs on a Linux kernel in a standard shell using a compact subset of standard tools written in other languages, and conceals the rest of user space on which it itself depends. But maybe it's just easier to pretend the whole thing isn't a single process running on a single core, non-Posix compliant, incapable of running standard Linux GUI or CLI apps; and that all of that sacrifice in functionality hasn't been specifically engineered to cater to some misguided aesthetic notion that this all makes the system more hackable because it is a written in Python. Maybe it's easier to simply pretend that you can't build a python window manager that works with native linux graphics compositing systems, and that the whole design would be better off targeting certain configuration processes using Python.
- pjmlp 6y ago
  > . But surely you agree that CPython is needed to run Python, yes? No, it just happens to be the reference implementation, there are others to chose from. One can even go crazy and bootstrap a Python environment, basic compiler development stuff.
  - bonestormii_ 6y ago
    You are mistaken. Pygame depends on CPython, as it is a C extension. Under the hood, even this window manager is mostly C.
    - pjmlp 6y ago
      And? Who says that Pygame is the only way of implementing this?
      - bonestormii_ 6y ago
        Pygame is all this is. I'm not saying that it's the only way. It's probably one of the worst ways in my humble opinion, though I can't really say that without understanding their vision for the project tbh. Should I assume they are looking at scratching every single line of code they've written for this and restarted? Why would I make that assumption? I don't want to quibble with you. My only point here is that an all-python user space is a significant undertaking if you are willing to acknowledge the scope of what the user space actually entails. It's totally doable, but this project isn't even a step in the direction of solving those problems. It's a totally different thing. Depending on the objective in a "python only" operating system, I may be inclined to strongly advise not trying to reimplement everything in python. The nature of C is such that you can write a C compiler in C, compile it, throw away the source code, and use the compiled binary for the new compiler to start developing a new compiler for C. But you can't like, make a python interpreter for python, in python, delete CPython, and then use the python version. It is dependent on CPython. And so, to build it, it's dependent on GCC, make, a shell, etc. These are great tools. I think you should keep them, and define a specific surface area that python interfaces with. That's all I'm sayin'.

bonestormii_ 6y ago

I mean, okay, you don't need vi or awk to call it Linux. But surely you agree that CPython is needed to run Python, yes? Its interpreter is written in C. To build it, you need a shell, make, gcc, and a text editor would be most helpful. It's all part of the user space. You can hide it within the snakeware application (why?), but don't deny it exists in the Linux user space. And C Python needs C extensions (pygame, for example), so GCC is at the very least a very-very-nice-to-have, is it not? What is the goal here? You want to run Python without a shell? A huge number of python scripts depend on the shell. You are increasing barriers to using Python to code interesting apps in this system. Should the shell be implemented in Python, too? It could be, but why? Why not just integrate a standard shell, and present some nice-ish way of interfacing with it via Python? I don't think that this application itself can even work in such an environment (no shell, no init system, etc). Currently this project is depending on a shell provided by Busybox. It uses these underlying tools to initialize and configure the operating system. It's all there in the user space, just hidden beneath this application. Look, there are no laws about this sort of thing. You can do what you want and call it what you will, and I'm not some tech lingo fascist trying to impose my idea of "user space" on anyone (even though it's really a term with a specific meaning of 'anything outside of the kernel', for which making an all-python version sounds highly difficult). I'm merely pointing out that a great deal of this user space is actually already non-python, and user space carries with it a lot of linux's essential functionality, largely via the GNU core utils and other common utilities which are written in a wide variety of languages. You can choose to hide all of that functionality to make a python-only sandbox... but.... then... ...Couldn't I just use pygame to make standard applications that run on all distros outside of this isolated "window manager" program? All this achieves right now is isolating your apps in this kind of simulated window environment, and preventing the user from ever doing anything meaningful unless they have a specially coded snakeware(tm) python app. It can never run a standard installation of something like Firefox; utilize any standard Linux CLI software; utilize an existing package management system or the packages from it; etc. because it has no shell, and doesn't make use of the standard Linux graphics compositors (X11/Wayland). So having said all of that, my goal isn't to tear down the project, but to ask the hard question for the benefit of this project: What is the goal? What I see here is mainly a simulated window manager written in pygame which can only ever run specially-created GUI apps, which is booted into directly. This design can never become a viable distro as it stands. This is a cool project. A fun project. But first and foremost, this is about 1400 lines total of Python and shell script. It's not really all that much yet, and it's not going to get there by pretending this design is sustainable to become some robust user environment where everything is Python. Sometimes, complying with standards and specifications are what make a thing the thing it is. And this is not a Python-only user space Linux distro. It is a simulated window manager written in Python that runs on a Linux kernel in a standard shell using a compact subset of standard tools written in other languages, and conceals the rest of user space on which it itself depends. But maybe it's just easier to pretend the whole thing isn't a single process running on a single core, non-Posix compliant, incapable of running standard Linux GUI or CLI apps; and that all of that sacrifice in functionality hasn't been specifically engineered to cater to some misguided aesthetic notion that this all makes the system more hackable because it is a written in Python. Maybe it's easier to simply pretend that you can't build a python window manager that works with native linux graphics compositing systems, and that the whole design would be better off targeting certain configuration processes using Python.

pjmlp 6y ago
> . But surely you agree that CPython is needed to run Python, yes? No, it just happens to be the reference implementation, there are others to chose from. One can even go crazy and bootstrap a Python environment, basic compiler development stuff.
- bonestormii_ 6y ago
  You are mistaken. Pygame depends on CPython, as it is a C extension. Under the hood, even this window manager is mostly C.
  - pjmlp 6y ago
    And? Who says that Pygame is the only way of implementing this?
    - bonestormii_ 6y ago
      Pygame is all this is. I'm not saying that it's the only way. It's probably one of the worst ways in my humble opinion, though I can't really say that without understanding their vision for the project tbh. Should I assume they are looking at scratching every single line of code they've written for this and restarted? Why would I make that assumption? I don't want to quibble with you. My only point here is that an all-python user space is a significant undertaking if you are willing to acknowledge the scope of what the user space actually entails. It's totally doable, but this project isn't even a step in the direction of solving those problems. It's a totally different thing. Depending on the objective in a "python only" operating system, I may be inclined to strongly advise not trying to reimplement everything in python. The nature of C is such that you can write a C compiler in C, compile it, throw away the source code, and use the compiled binary for the new compiler to start developing a new compiler for C. But you can't like, make a python interpreter for python, in python, delete CPython, and then use the python version. It is dependent on CPython. And so, to build it, it's dependent on GCC, make, a shell, etc. These are great tools. I think you should keep them, and define a specific surface area that python interfaces with. That's all I'm sayin'.