32 ms·

Snakeware – Linux distro with Python userspace inspired by Commodore 64

css 6y ago
FYI, The audio in the demo video only plays in the left channel.
snazz 6y ago
This is exceedingly cool. It could be a modern-day Lisp Machine that takes advantage of the Linux kernel's great hardware support. Since Python is such a dynamic language, I'd be interested in how they plan to allow the Python processes to communicate. This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere; a structured data format like S-expressions could be passed around instead. Edit: Other languages I'm thinking of for this idea: * Lua or LuaJIT (even more dynamic and really great performance; smaller and somewhat fragmented ecosystem) * Scheme (potentially also fast and good S-expression support, also very dynamic; small and very fragmented ecosystem)
- 0xdeadbeefbabe 6y ago
  > a structured data format like S-expressions could be passed around instead. Why would a structured format be a better lowest common denominator than an unstructured one like text files? Or is it files that are the issue?
  - snazz 6y ago
    Unix pipes are great, but having to parse plain-text streams is inefficient and error-prone. Imagine how much more powerful it would be if commands returned data in structures that could be used by other applications without parsing an ad-hoc text format. The filesystem can be used to approximate this, like it is in Plan 9, but I think that using text as the lowest common denominator leaves a lot of potential power on the table.
    - zozbot234 6y ago
      Unix-like pipes are not restricted to sending text, they may send general bytestreams. Modern data serialization formats (flatbuffers, capnproto, msgpack, etc.) are highly efficient, and using serialization makes it easier to deploy applications in a distributed setting.
      - snazz 6y ago
        Sure, but the standard GNU or BSD userland doesn't do that, does it? If you're going to the trouble of implementing your own userspace, then you might as well use a consistent, proper data serialization format (either text or binary, but text is more accessible).
      - throwaway894345 6y ago
        The value is in having everything speak a common standard. In unix, that 'standard' is lines of text, which is inherently linear and lacks the ability to idiomatically represent hierarchy. Conceivably, one could use modern serialization formats or we could do something a bit more interesting, like supporting some notion of "objects" directly in the operating system or runtime (in the case of powershell, the "runtime" is the .net vm; in unix it's the OS).
        brutt 6y ago
        Format: * Field type: S - 16 bytes, D - 32, L - 64, Q - 128, B - 256, P - 512, T - 1024. * Field ID - 3 bytes ASCII Letters, numbers, '_'; * Field-value separator - 2 bytes: ':' and field value terminator, e.g. ': ' or ':"' or ':[' or ':{' or ':(' ; * Field value 9 bytes ASCII for S, 27 for D, and so on, padded with ' '; * Field separator: 1 byte '\n'; SOBJ: X23456789\n SFN_:"Length" \n SFV_: 23 \n SEND: \n Such text can be parsed by both human and computer, because computer can just jump from field to field without parsing everything in between, like humans do.
    - d0mine 6y ago
      You don't need to send text (but you should by default for 99%+ cases when the performance is good enough and use the advantages of a human-readable format) The simplicity of a pipe is a feature.
- bityard 6y ago
  > This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere There are a great many who do not consider this to be a mistake. The fact that after half a century, Unix-like operating systems and programming environments are de rigueur is plain enough evidence of this. I can't think of much else in the whole field of computing that has had this kind of staying power over such a long period of time, excepting perhaps the idea of binary digital computers themselves. Fun history note: Part of the reason the Unix userspace and development chain lean so heavily on text processing is because its inventors were tasked with designing a system for more powerful tools for the writing and production of technical documentation. But they were dyed-in-the-wool systems and programming nerds so stand-alone documentation tools were not very interesting. So their solution was to invent a new OS, borrowing the features they liked from other OSes they had been exposed to, under the guise of delivering a documentation production system. If it turned out that this Unix thing they came up with happened to be an excellent programming environment as well, that was just a nice bonus as far as management was to be informed. One of the greatest hacks of computing history, if you ask me. Edit to add: As others have pointed out, you are hardly restricted to piping around text. And if you do, the power of text is that you can impose arbitrary structure on top of it, e.g. tabular data, shell scripts, XML, YAML, JSON, etc. Saying it's too bad Unix abstracts everything as text files is like saying it's too bad microprocessors abstract everything down to either a one or a zero when far more interesting number exist.
  - deleted 6y ago
    [deleted]
  - pwdisswordfish2 6y ago
    Wasn't UNIX originally used to format patent applications at Bell Labs/AT&T? That was purportedly the selling point of UNIX to the business people. When someone suggests using something other than "text" (usually it's some binary format, I consider S-Expressions to be text), I always wonder, why is this person writing their suggestion using text? Then we have the suggestions that "everything is a file" is also a "mistake". That's great but if a "file" is not a good enough abstraction then what is?
- matheusmoreira 6y ago
  Linux is the best operating system for a project like this. The system call binary interface is stable at the processor architecture level: https://www.kernel.org/doc/Documentation/ABI/stable/syscalls https://www.kernel.org/doc/Documentation/ABI/stable/syscalls http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscall.2.html http://man7.org/linux/man-pages/man2/syscall.2.html Any Linux process can perform Linux system calls, no matter what language the software is written in. Instead of relying on C libraries to do everything, a compiler could emit system call code when necessary. The entire Linux user space could be rewritten in a higher level language that way. Rust would be the likely candidate but there's no reason a Lisp or Scheme couldn't do it. The language would need full support for features of binary interfaces such as function calling conventions, pointers, structures with padding and alignment, etc.
  - heavyset_go 6y ago
    Do you know of any projects exploring this space?
    - anton96 6y ago
      In matter of scheme you have the guile project. https://www.gnu.org/software/guile/guile.html https://www.gnu.org/software/guile/guile.html
      - slim 6y ago
        so maybe guixsd ?
    - yencabulator 6y ago
      Go does syscalls directly on Linux. Libc is only needed if you use a thing that only exists in libc (e.g. NSS).
      - AnIdiotOnTheNet 6y ago
        In that vein, Zig also uses syscalls directly on Linux in its standard library so as to avoid linking with C unless desired. This is not possible on the various BSDs.
- lifeisstillgood 6y ago
  > This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere Text files are just a binary format that happens to be easily readable by humans, thus making the hurdle of parsing or generating something to use that format much lower. It usually is this hurdle that is most important to longevity and wide spread success than close to metal sympathies- cf JSON and Protocol Buffers
  - ken 6y ago
    Text files are easily readable on a Teletype or a VT100. That was a solid design decision back in the day when you had to say "screen editor" to distinguish them from the ordinary line editors. We didn't have interactive debuggers and inspectors and loggers, so we did everything we could to make systems naturally debuggable. It's like how the Model T engine cover just lifted off with a big door handle. When a technology is new, people using it are expected to be mechanics, too. But today, even amateur wrote-it-over-the-weekend programs have realtime visual editing of rich data. There are countless free libraries for serialization of every format, and GUI (and TUI) libraries for every toolkit/language/style. Developers enjoy using JSON because it lowers the "hurdle of parsing or generating". It's not 1970 any more.
- traverseda 6y ago
  I'd love to see something like RPYC used for interprocess-communication.
- kbr2000 6y ago
  It's been done using Tcl [0] in the nineties, in the EtLinux [1] project for embedded systems. One of the goals was to shave off memory usage by implementing tools under a single scripting interpreter (instead of each of them having their own binary). Kind of overlaps with BusyBox [2] philosophy... [0] https://www.tcl.tk/ https://www.tcl.tk/ [1] http://www.etlinux.org/ http://www.etlinux.org/ [2] https://busybox.net/FAQ.html#goals https://busybox.net/FAQ.html#goals
- amyjess 6y ago
  Thinking about structured data at the OS level makes me want to see a revival of Classic Mac OS's resource fork. Structured metadata in every file is a dream of mine.
  - Animats 6y ago
    The resource fork idea was OK, but it suffered from a implementation optimized for a floppy disk. Writes were deferred as long as possible, and if anything went wrong, the whole data structure was corrupted. "Text Edit is not a text editor, and the resource fork is not a database" - early Apple publication. Both could have been. Programs tend to need little databases, for preferences and such, and the resource fork was way ahead of doing everything with a text file. But the implementation was never toughened up to database standards after the Macintosh got a hard drive and more memory. And Text Edit was limited to 32K for a long time. Meanwhile, Unix struggled along with text files for everything. And lock files for the text files. And daemons to remove dead lock files. And a lack of file locking. And a lack of interprocess communication. Eventually the Unix/Linux world got that all fixed, but way too late.
  - AnIdiotOnTheNet 6y ago
    This could be handled by convention of treating directories as though they were a single structured "file" under certain circumstances. There is precedent in the form of Application Directories from NeXT, RiscOS, and ROX Desktop. Modern MS Office files are also basically just a zipped up directory of files and metadata.
- joyj2nd 6y ago
  "This would be a great opportunity to avoid the classic Unix mistake of using text files" Don't get it. Where is the mistake? I think it was its biggest strength. In the successor, Plan 9, everything is a file...
- linguae 6y ago
  I have a similar idea. I've been working on a design for a Common Lisp-based desktop environment that can run on top of Linux and the BSDs. It's inspired by the Lisp machines of old and OpenDoc, an API for building component-based software that was championed by Apple and IBM back in the 1990s before Steve Jobs returned. I haven't started writing any code yet, partly because I've been learning X programming and other parts of the graphics stack like Cairo and Pango. I have some more ideas at http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-flexible-composable.html http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-..., though I wrote this before I committed to using Common Lisp (I talk about using GNUstep near the end of the document, but I've since ruled it out due to the difficulty of finding modern Objective-C bindings for SBCL that work with GNUstep).
- tlavoie 6y ago
  There is Mezzano, a Common Lisp operating system. Currently designed to be run within Virtualbox. https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
kiney 6y ago
As a kid I had a Commodore plus4 as my first computer (it was already severely outdated, but I got it for free). The fact that it booted directly to an scripting language intepreter (commodore basic) brought me to programming. You HAD to learn at leas some basic to do anything useful or fun with a commodore homecomputer. With my young nephews I see that the younger generation sees computers and smartphone more like useful blackboxes that "just work" without even trying to understand how.
eythian 6y ago
Reminds me a little of Squeak Smalltalk: https://squeak.org/ https://squeak.org/ It starts up its own environment, and everything that's there can be interacted with either by writing code, or by clicking on things and inspecting/modifying their variables.
- amyjess 6y ago
  Another similar environment is Oberon. It allowed you to select any snippet of Oberon code and execute it!
edraferi 6y ago
Heh totally want to install this on a PineBook and give it to elementary school kids as their first personal computer.
- richk449 6y ago
  Agreed. I've been trying to figure out what to give my son as a first computer. This would be a neat option. If he wants to watch videos on youtube, he is going to have to code himself a browser first.
  - tomsmeding 6y ago
    If you can run youtube-dl (hint: written in python), you only need a video decoder and player. If pygame doesn't give you that, though, you're in for trouble big time, because video codecs are hard. :)
    - slim 6y ago
      also, he will need to type the whole program on the keyboard. like we did when we were kids copying tens of pages of basic from magazines.
  - divbzero 6y ago
    Any other ideas so far? I’ve mulled over this question of best first computer for children. The best I’ve come across so far is a plain Linux installation with no desktop environment and a text-based typing program.
fit2rule 6y ago
I would love one of these, but with Lua as the language instead. Its quite possible with something like LOAD81, from antirez[1] - but I guess I'd love to see a full-blown desktop OS with Lua at the core, and not much else. I guess booting directly to a tekui[2] based editor would be nice, too. Something about having a clean boot to a single-language environment which appeals to me more and more as the decades go by. [1] http://github.com/antirez/load81.git http://github.com/antirez/load81.git [2] http://tekui.neoscientists.org http://tekui.neoscientists.org
- kohtatsu 6y ago
  Seconded. Also check out ComputerCraft. I'd love a club for this kind of thing.
  - fullstop 6y ago
    I loved ComputerCraft, but was kind of sad that the source was closed. It fell off of my radar until today, but I'm happy to see that it is now open source!
- Seirdy 6y ago
  Check out the (sadly inactive) Node9 operating system [0]. > Node9 is a hosted 64-bit operating system based on Bell Lab's Inferno OS, but using the Lua scripting language instead of Limbo and the LuaJIT high performance virtual machine instead of the Dis virtual machine. It also uses the libuv I/O library for maximum portability, efficient event processing and thread management. [0]: https://github.com/jvburnes/node9 https://github.com/jvburnes/node9
  - fit2rule 6y ago
    Ah yes, that is nice - thanks for the info. So many interesting things using Lua ..
- igravious 6y ago
  Same, but with Ruby … Actually had this idea years ago and toyed with hacking a ruby user space atop of Linux From Scratch – course I never went anywhere with the idea. Delighted someone's done it for python. Be cool if there was a Ruby version of snakeware :)
outadoc 6y ago
Fun idea!
andybak 6y ago
When I was a kid other kids either had ZX Spectrum, Commodore 64 or BBC Micros. (yeah - I knew one kid with a Dragon 32 poor sod. And someone with an Atari 400 or 800 where I was jealous of the hardware palette tricks and game cartridges) Anyway - The Commodore seemed the worst option in terms of habitability. Any graphics or sound programming largely consisted of poking random locations in memory. The included BASIC had no direct support for any of the interesting stuff. The quality of the BASIC was also poor. The Beeb probably had the best implementation at the time with the Spectrum coming second. So - I guess what I'm saying is the C64 is a strange role model.
- LeoPanthera 6y ago
  Until beaten by the Raspberry Pi, the Commodore 64 was the best selling single model of computer in history, Commodore having sold between 12 and 17 million units in its lifetime. So I imagine it is inspired, at least in part, by its ubiquity.
- kiney 6y ago
  yeah, I remember typing out basic listings full of peek and poke without understanding why and what they did with those memory locations. (on commodore plus4)
- the_af 6y ago
  The C64's BASIC was indeed very poor compared to the competition, but the hardware (and games) were pretty cool. People wrote games with assembler in all those early home computers.
  - abiogenesis 6y ago
    The BASIC v2 was horrible, but still there were plenty of great games written in BASIC (Sid Meier's Pirates was mostly BASIC, for example).
    - the_af 6y ago
      Really!? Wow. I don't see how, will read about it. Do you have any link to read? (any excuse to read about Sid Meier's Pirates! and the C64 is good). In any case, C64's BASIC "programming" meant that for graphics and audio you were mostly POKEing and PEEKing, since its instruction set was very limited. And when you're mostly peeking and pooking directly at memory, you're barely writing BASIC, are you? ;) edit: I tracked down a 2014 comment from HN saying the same as you: that Pirates! was mostly written in BASIC. I'm amazed. Now I really want to see the source code and/or read a "making of".
numpad0 6y ago
> Our window manager, snakewm, is based on pygame/pygame_gui. We do not use X11; snakewm draws directly to /dev/fb0. Whole window system written in Python, That’s hardcore!
- JonathonW 6y ago
  Well, sort of. Pygame itself is more C than Python. Everything they build on top of that should be able to be pure Python, though, which is pretty nifty.
- matheusmoreira 6y ago
  I didn't know it was possible to obtain a hardware-accelerated OpenGL context without using GLX. How does it work without X11? Can I draw to the screen without any dependencies?
  - Narishma 6y ago
    Probably the same way Wayland or the original Raspberry Pi drivers do it, using EGL.
matheusmoreira 6y ago
Interesting. The GUI is implemented on top of PyGame. The terminal is actually a Python REPL. Do you plan to write replacements for the POSIX utilities? Strict POSIX compliance is not necessary but user space needs the general functionality provided by those packages.
- edraferi 6y ago
  Any idea where I can get data on POSIX utilities ranked by use/importance?
  - woodrowbarlow 6y ago
    you could start with the list of what's included in busybox: https://busybox.net/downloads/BusyBox.html https://busybox.net/downloads/BusyBox.html the goal of busybox is to provided a stripped down posix userspace for use in embedded devices -- basically, provide enough posix utils to be able to do some useful shell scripting.
  - matheusmoreira 6y ago
    Start with file management utilities such as ls, cp, mv and rm.
  - robocat 6y ago
    Here’s a standard list of Unix commands: https://en.wikipedia.org/wiki/List_of_Unix_commands https://en.wikipedia.org/wiki/List_of_Unix_commands It is probably more comprehensive than what you were after though...
- Shorel 6y ago
  Why another set of the same old? Let the users (hopefully a new generation with new ideas) create their own paradigms.
  - matheusmoreira 6y ago
    Yes. I didn't mean to imply that POSIX utilities should be reimplemented. It's just that a new user space isn't very substantial if users can't even explore the file system. The new software could even be graphical in nature. Right now a Python REPL is the only real way to interact with the operating system.
thesuperbigfrog 6y ago
It reminds me of Perl/Linux. A Linux distribution where ALL programs are written in perl. http://perllinux.sourceforge.net/ http://perllinux.sourceforge.net/
- metalliqaz 6y ago
  puke
  - strbean 6y ago
    Imagine the efficiency of having your whole userland written in one line of code!
    - grawprog 6y ago
      This made me laugh way harder than it should. Just imagine that one line. It'd either be the greatest or most terrifying piece of code I think I'd ever be likely to witness. Probably in all existence really. But then of course, someone would have to come along and port that ultimate one line of Perl code to brainfuck and one up them and then someone else would come along and turn that one liner into an entire lisp dialect and on it'll go.
      - deleted 6y ago
        [deleted]
      - yellowapple 6y ago
        If you think about it, every compiled program is a one-liner.
        thesuperbigfrog 6y ago
        Or perhaps everything is a one-liner: https://xkcd.com/224/ https://xkcd.com/224/
nkkollaw 6y ago
This is so cool. Congrats!
boogies 6y ago
After seeing "operating systems" like JS/UIX here, it's great to see one that actually boots independently. And it looks like it has multitasking, and contributions from multiple developers, awesome!
- eternauta3k 6y ago
  To be fair, I think those features came with the Linux kernel.
  - AnIdiotOnTheNet 6y ago
    Yeah. I mean, this is still much more effort than every Ubuntu-derived "OS" out there, but it isn't like Haiku or Redox or anything.
adamredwoods 6y ago
I had this exact same idea, just no time to execute it, so very happy to see this. Now, I just have to install it to a Raspberry Pi!
nathell 6y ago
In this genre, I like: Emacs as PID 1 http://www.informatimago.com/linux/emacs-on-user-mode-linux.html http://www.informatimago.com/linux/emacs-on-user-mode-linux....
- Y_Y 6y ago
  That's really interesting, and something I've been thinking about lately too. I wonder if it would be any better with Guile Emacs, so that you have the FFI. Does anyone here run Emacs as their only environment?
desireco42 6y ago
This actually is really good idea. While I don't use Python often, I wouldn't see this as a problem. By reducing a barrier, they might actually create something fun to use. Also, having a Raspberry Pi as first/default platform would be exceedingly welcome and good. I wouldn't mind Lua as well, Ruby etc. As long as it is something easy to use.
russellbeattie 6y ago
This is funny, the other day when Microsoft released the code to GW-BASIC, I wrote this in response to someone saying their IBM PC booted into a version of BASIC rather than DOS: I've always thought that using BASIC as the default command line was really weird... Like on an Apple II or TRS-80. You could type in a command to load something from a disk or run a program, or type a line number to start programming. How did that make sense to anyone?? To my 11yo self, it was confusing and I've never changed my mind. To add to that thought, I think there's some things which are worth emulating from the good ol' days, and some which aren't. I think this is probably one of the latter.
- sjburt 6y ago
  But how different is that really than bash? Or even command.com?
  - 1bc29b36f623ba8 6y ago
    It isn't, really. The command-line is a beautiful thing!
- zozbot234 6y ago
  Those computers could not run a general purpose GUI, so a command-line interface was all you got. The nice thing about BASIC in that context is that it's a clean extension of a desk calculator: it gives you floats and math operations, functions etc. out-of-the-box, which took a non-trivial chunk of ROM code to implement on that kind of 8-bit platform.
- djaychela 6y ago
  Always made perfect sense to me - I grew up on ZX spectrum, BBC Micro and VIC-20. When I started using PCs on dos, that made sense too. I never thought either approach was wrong...
- ralphc 6y ago
  My 16 year old self found it the opposite of confusing on my TRS-80, especially with everything in ROM. Hit the power button and in seconds you can start programming and exploring. It's how thousands of kids got their start programming.
zelon88 6y ago
I'm just now falling down this rabbit hole of working with frame buffers as a result of this project and now I'm curious. Did you develop your own window manager? This is really fascinating stuff and makes it really simple to create low-level things with a high-level language. [1] [2] Also, does OpenGL work? [1] http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/ http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/ [2] https://www.kernel.org/doc/Documentation/fb/framebuffer.txt https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
- kelnos 6y ago
  > Also, does OpenGL work? There's no reason why it can't; OpenGL doesn't require X11 (or Wayland), and EGL (a library/interface that binds the OGL implementation to a windowing/display system) could certainly be implemented for linuxfb (if it hasn't been already). Either way, I'd expect the current state of snakeware's graphical environment is that it won't work without some (possibly large) modifications.
  - cycloptic 6y ago
    Fbdev is a legacy interface and is probably not what you want if you're developing something beyond a simple demo. Check kmscube for a modern example of how to use EGL with DRI/KMS/GBM: https://gitlab.freedesktop.org/mesa/kmscube/ https://gitlab.freedesktop.org/mesa/kmscube/
- aduitsis 6y ago
  Tangentially, Plan9 extends the notion of /dev/tty to something called the draw device. Meaning that a process can just map and use /dev/draw to provide graphics. Those graphics are rendered into the window of the process.
ralphc 6y ago
This needs to be on a Raspberry Pi.
- the_af 6y ago
  Semi-related, I recently installed the BMC64 distro on my unused Raspberry Pi. It boots directly to VICE, no "Linux" to be seen. It's like booting a C64. You turn it off by unplugging, just like the real thing. The only thing that tells you this is not a real C64 (besides lacking the keyboard/case) is that you can bring up a menu with lots of options with F12 (necessary to mount disk images, at the very least). Wow, does it take me back to my childhood!
  - 1bc29b36f623ba8 6y ago
    Semi-semi-related, there was a commercial distro named Amithlon that booted straight into AmigaOS 3.9. Alas, it was discontinued, but it had a really nice AmigaOS feel to it.
    - the_af 6y ago
      Cool! I missed the boat back then and never did own an Amiga. It was too expensive for my parents to buy. Later I heard it was an incredible machine and young me would have loved to toy with it.
      - 1bc29b36f623ba8 6y ago
        It was a cool machine, and AmigaOS was simply awesome compared to contemporary consumer operating systems, but alas Commodore went belly-up before they managed to modernize the platform.
muxxa 6y ago
This is wonderful. I’ve often fantasised about unifying the command line and the desktop into a single UI paradigm and this project could just give me a realistic shot at trying it out. Anyone who is interested, much of this classic has yet to be tried properly afaik: https://en.wikipedia.org/wiki/The_Humane_Interface https://en.wikipedia.org/wiki/The_Humane_Interface Another idea: instead of having Photoshop/Excel etc. clones, have a document centric rather than application centric UI and allow features to be installable when they are needed (micro-apps?). E.g. Gaussian blur or spellchecking could be things you’d add from a microapp directory which would add an extra button to your interface for images and documents respectively.. you’ll build up a personalised interface and ‘own’ it, rather than being presented with a sea of unknown buttons/menu-items.
- schwartzworld 6y ago
  > unifying the command line and the desktop into a single UI This is how computers used to be. I had an Apple II which was exactly this. if you booted without a disk in, you just got a BASIC prompt.
Shorel 6y ago
This is great. I think a laptop with this, along with a Python book is one of the greatest gifts for someone to learn about computers and programming. All exploration and few distractions.
giancarlostoro 6y ago
Nobody seems to have mentioned it, but I would love to see how this grows and whether or not if they'll eventually adopt Cython, which would bring a lot of performance boosts, but also be good for Cython in general. Cython: https://cython.org/ https://cython.org/
Anka33 6y ago
Python is crap
salgernon 6y ago
There are a lot "See also" - so I'd like to shout out to the late Terry Davis' "TempleOS" and his ... strange take on an interactive boot-to-command line system based on C++ and x86_64. [*] https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS [Edit]: See also http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ http://www.codersnotes.com/notes/a-constructive-look-at-temp...
Animats 6y ago
Sounds like the One Laptop Per Child environment. That had a Python user space. Can you still run it?
- smabie 6y ago
  I was thinking the same thing. I actually own the original OLPC, and unfortunately, that thing is a pile of garbage. The entire UI and all apps are programmed in Python, which while good for getting children into programming I guess, is bad for actual use. The system is so unimaginably slow that doing really anything at all is unusable. Like every other adult who bought one, I installed Debian on it and a lightweight tiling window manager.
  - cellularmitosis 6y ago
    I keep my OLPC (running Debian) around for precisely the reason of having a low-spec touchstone to keep me grounded. Heck I even test some programs on an NSLU2! https://gist.github.com/cellularmitosis/9ab25536b01d903539bd3d161cb7e3ed https://gist.github.com/cellularmitosis/9ab25536b01d903539bd...
deleted 6y ago
[deleted]
askvictor 6y ago
Nice; I had been thinking of building something similar aimed at the raspberry pi, to make it easier to just get python scripts running, without having to learn about the OS. But never found the time. Was going to be called PyOS (pun on BIOS): https://github.com/askvictor/pyos https://github.com/askvictor/pyos
logicprog 6y ago
I kind of really want to contribute to this now. I've contributed to SerenityOS, too. But do I have time? No.
artifact_44 6y ago
I want this but for v8/js!
- lioeters 6y ago
  This may float your boat: https://github.com/NodeOS/NodeOS https://github.com/NodeOS/NodeOS
musicale 6y ago
Wasn't Python basically invented as the scripting language for the Amoeba OS? I often imagine an alternate reality where much of the non-performance-critical Unix/Linux userland such as login is written in Python.
bonestormii_ 6y ago
This is a very fun-looking project. However, in the GNU/Linux world, "user space" is a very broad term referring to everything running outside of the kernel. 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. In the README, you say you want to get it to boot without Busybox. Busybox is currently the thing filling this void for you now. It is providing your actual user space, including it's systemV-inspired init system. What you have here is basically a very simple pygame template with an embedded application build tool chain. Which is totally cool, and potentially fun and productive. But it isn't replacing the GNU/Linux user space, which is C heavy, but very language diverse. I would focus not on replacing the user space, but interfacing with it where reasonable. To that end, you may even want to consider shedding pygame and interfacing with X11/wayland. Identify the surfaces you want to control with python and implement that. It will perform better, and be more true to what makes Linux "Linux".
- bibabaloo 6y ago
  > 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.
deleted 6y ago
[deleted]
yencabulator 6y ago
It claims to be "fully Python-based Linux distro" but it seems to be just a buildroot config with an init.d script that runs the python repl in a loop. There's still /bin/sh, C tools, etc. https://github.com/joshiemoore/snakeware/blob/master/snakeware/overlay/etc/init.d/S30startpy https://github.com/joshiemoore/snakeware/blob/master/snakewa...
- corgihamlet 6y ago
  Same thing with a C64 - you have a simplified BASIC-environment but still can use the underlying Assembler.
amitport 6y ago
it's just 'buildroot' (which is a minimalist distro that happens to include python). I mean the python window manager is interesting but also mostly delegates to pygame. Calling it a distro is a "bit" over-selling it IMO

css 6y ago

FYI, The audio in the demo video only plays in the left channel.

This is exceedingly cool. It could be a modern-day Lisp Machine that takes advantage of the Linux kernel's great hardware support. Since Python is such a dynamic language, I'd be interested in how they plan to allow the Python processes to communicate. This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere; a structured data format like S-expressions could be passed around instead. Edit: Other languages I'm thinking of for this idea: * Lua or LuaJIT (even more dynamic and really great performance; smaller and somewhat fragmented ecosystem) * Scheme (potentially also fast and good S-expression support, also very dynamic; small and very fragmented ecosystem)

0xdeadbeefbabe 6y ago
> a structured data format like S-expressions could be passed around instead. Why would a structured format be a better lowest common denominator than an unstructured one like text files? Or is it files that are the issue?
- snazz 6y ago
  Unix pipes are great, but having to parse plain-text streams is inefficient and error-prone. Imagine how much more powerful it would be if commands returned data in structures that could be used by other applications without parsing an ad-hoc text format. The filesystem can be used to approximate this, like it is in Plan 9, but I think that using text as the lowest common denominator leaves a lot of potential power on the table.
  - zozbot234 6y ago
    Unix-like pipes are not restricted to sending text, they may send general bytestreams. Modern data serialization formats (flatbuffers, capnproto, msgpack, etc.) are highly efficient, and using serialization makes it easier to deploy applications in a distributed setting.
    - snazz 6y ago
      Sure, but the standard GNU or BSD userland doesn't do that, does it? If you're going to the trouble of implementing your own userspace, then you might as well use a consistent, proper data serialization format (either text or binary, but text is more accessible).
    - throwaway894345 6y ago
      The value is in having everything speak a common standard. In unix, that 'standard' is lines of text, which is inherently linear and lacks the ability to idiomatically represent hierarchy. Conceivably, one could use modern serialization formats or we could do something a bit more interesting, like supporting some notion of "objects" directly in the operating system or runtime (in the case of powershell, the "runtime" is the .net vm; in unix it's the OS).
      - brutt 6y ago
        Format: * Field type: S - 16 bytes, D - 32, L - 64, Q - 128, B - 256, P - 512, T - 1024. * Field ID - 3 bytes ASCII Letters, numbers, '_'; * Field-value separator - 2 bytes: ':' and field value terminator, e.g. ': ' or ':"' or ':[' or ':{' or ':(' ; * Field value 9 bytes ASCII for S, 27 for D, and so on, padded with ' '; * Field separator: 1 byte '\n'; SOBJ: X23456789\n SFN_:"Length" \n SFV_: 23 \n SEND: \n Such text can be parsed by both human and computer, because computer can just jump from field to field without parsing everything in between, like humans do.
  - d0mine 6y ago
    You don't need to send text (but you should by default for 99%+ cases when the performance is good enough and use the advantages of a human-readable format) The simplicity of a pipe is a feature.
bityard 6y ago
> This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere There are a great many who do not consider this to be a mistake. The fact that after half a century, Unix-like operating systems and programming environments are de rigueur is plain enough evidence of this. I can't think of much else in the whole field of computing that has had this kind of staying power over such a long period of time, excepting perhaps the idea of binary digital computers themselves. Fun history note: Part of the reason the Unix userspace and development chain lean so heavily on text processing is because its inventors were tasked with designing a system for more powerful tools for the writing and production of technical documentation. But they were dyed-in-the-wool systems and programming nerds so stand-alone documentation tools were not very interesting. So their solution was to invent a new OS, borrowing the features they liked from other OSes they had been exposed to, under the guise of delivering a documentation production system. If it turned out that this Unix thing they came up with happened to be an excellent programming environment as well, that was just a nice bonus as far as management was to be informed. One of the greatest hacks of computing history, if you ask me. Edit to add: As others have pointed out, you are hardly restricted to piping around text. And if you do, the power of text is that you can impose arbitrary structure on top of it, e.g. tabular data, shell scripts, XML, YAML, JSON, etc. Saying it's too bad Unix abstracts everything as text files is like saying it's too bad microprocessors abstract everything down to either a one or a zero when far more interesting number exist.
- deleted 6y ago
  [deleted]
- pwdisswordfish2 6y ago
  Wasn't UNIX originally used to format patent applications at Bell Labs/AT&T? That was purportedly the selling point of UNIX to the business people. When someone suggests using something other than "text" (usually it's some binary format, I consider S-Expressions to be text), I always wonder, why is this person writing their suggestion using text? Then we have the suggestions that "everything is a file" is also a "mistake". That's great but if a "file" is not a good enough abstraction then what is?
matheusmoreira 6y ago
Linux is the best operating system for a project like this. The system call binary interface is stable at the processor architecture level: https://www.kernel.org/doc/Documentation/ABI/stable/syscalls https://www.kernel.org/doc/Documentation/ABI/stable/syscalls http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscall.2.html http://man7.org/linux/man-pages/man2/syscall.2.html Any Linux process can perform Linux system calls, no matter what language the software is written in. Instead of relying on C libraries to do everything, a compiler could emit system call code when necessary. The entire Linux user space could be rewritten in a higher level language that way. Rust would be the likely candidate but there's no reason a Lisp or Scheme couldn't do it. The language would need full support for features of binary interfaces such as function calling conventions, pointers, structures with padding and alignment, etc.
- heavyset_go 6y ago
  Do you know of any projects exploring this space?
  - anton96 6y ago
    In matter of scheme you have the guile project. https://www.gnu.org/software/guile/guile.html https://www.gnu.org/software/guile/guile.html
    - slim 6y ago
      so maybe guixsd ?
  - yencabulator 6y ago
    Go does syscalls directly on Linux. Libc is only needed if you use a thing that only exists in libc (e.g. NSS).
    - AnIdiotOnTheNet 6y ago
      In that vein, Zig also uses syscalls directly on Linux in its standard library so as to avoid linking with C unless desired. This is not possible on the various BSDs.
lifeisstillgood 6y ago
> This would be a great opportunity to avoid the classic Unix mistake of using text files as the lowest common denominator everywhere Text files are just a binary format that happens to be easily readable by humans, thus making the hurdle of parsing or generating something to use that format much lower. It usually is this hurdle that is most important to longevity and wide spread success than close to metal sympathies- cf JSON and Protocol Buffers
- ken 6y ago
  Text files are easily readable on a Teletype or a VT100. That was a solid design decision back in the day when you had to say "screen editor" to distinguish them from the ordinary line editors. We didn't have interactive debuggers and inspectors and loggers, so we did everything we could to make systems naturally debuggable. It's like how the Model T engine cover just lifted off with a big door handle. When a technology is new, people using it are expected to be mechanics, too. But today, even amateur wrote-it-over-the-weekend programs have realtime visual editing of rich data. There are countless free libraries for serialization of every format, and GUI (and TUI) libraries for every toolkit/language/style. Developers enjoy using JSON because it lowers the "hurdle of parsing or generating". It's not 1970 any more.
traverseda 6y ago
I'd love to see something like RPYC used for interprocess-communication.
kbr2000 6y ago
It's been done using Tcl [0] in the nineties, in the EtLinux [1] project for embedded systems. One of the goals was to shave off memory usage by implementing tools under a single scripting interpreter (instead of each of them having their own binary). Kind of overlaps with BusyBox [2] philosophy... [0] https://www.tcl.tk/ https://www.tcl.tk/ [1] http://www.etlinux.org/ http://www.etlinux.org/ [2] https://busybox.net/FAQ.html#goals https://busybox.net/FAQ.html#goals
amyjess 6y ago
Thinking about structured data at the OS level makes me want to see a revival of Classic Mac OS's resource fork. Structured metadata in every file is a dream of mine.
- Animats 6y ago
  The resource fork idea was OK, but it suffered from a implementation optimized for a floppy disk. Writes were deferred as long as possible, and if anything went wrong, the whole data structure was corrupted. "Text Edit is not a text editor, and the resource fork is not a database" - early Apple publication. Both could have been. Programs tend to need little databases, for preferences and such, and the resource fork was way ahead of doing everything with a text file. But the implementation was never toughened up to database standards after the Macintosh got a hard drive and more memory. And Text Edit was limited to 32K for a long time. Meanwhile, Unix struggled along with text files for everything. And lock files for the text files. And daemons to remove dead lock files. And a lack of file locking. And a lack of interprocess communication. Eventually the Unix/Linux world got that all fixed, but way too late.
- AnIdiotOnTheNet 6y ago
  This could be handled by convention of treating directories as though they were a single structured "file" under certain circumstances. There is precedent in the form of Application Directories from NeXT, RiscOS, and ROX Desktop. Modern MS Office files are also basically just a zipped up directory of files and metadata.
joyj2nd 6y ago
"This would be a great opportunity to avoid the classic Unix mistake of using text files" Don't get it. Where is the mistake? I think it was its biggest strength. In the successor, Plan 9, everything is a file...
linguae 6y ago
I have a similar idea. I've been working on a design for a Common Lisp-based desktop environment that can run on top of Linux and the BSDs. It's inspired by the Lisp machines of old and OpenDoc, an API for building component-based software that was championed by Apple and IBM back in the 1990s before Steve Jobs returned. I haven't started writing any code yet, partly because I've been learning X programming and other parts of the graphics stack like Cairo and Pango. I have some more ideas at http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-flexible-composable.html http://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for-..., though I wrote this before I committed to using Common Lisp (I talk about using GNUstep near the end of the document, but I've since ruled it out due to the difficulty of finding modern Objective-C bindings for SBCL that work with GNUstep).
tlavoie 6y ago
There is Mezzano, a Common Lisp operating system. Currently designed to be run within Virtualbox. https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano

kiney 6y ago

As a kid I had a Commodore plus4 as my first computer (it was already severely outdated, but I got it for free). The fact that it booted directly to an scripting language intepreter (commodore basic) brought me to programming. You HAD to learn at leas some basic to do anything useful or fun with a commodore homecomputer. With my young nephews I see that the younger generation sees computers and smartphone more like useful blackboxes that "just work" without even trying to understand how.

eythian 6y ago

Reminds me a little of Squeak Smalltalk: https://squeak.org/ https://squeak.org/ It starts up its own environment, and everything that's there can be interacted with either by writing code, or by clicking on things and inspecting/modifying their variables.

amyjess 6y ago
Another similar environment is Oberon. It allowed you to select any snippet of Oberon code and execute it!

edraferi 6y ago

Heh totally want to install this on a PineBook and give it to elementary school kids as their first personal computer.

richk449 6y ago
Agreed. I've been trying to figure out what to give my son as a first computer. This would be a neat option. If he wants to watch videos on youtube, he is going to have to code himself a browser first.
- tomsmeding 6y ago
  If you can run youtube-dl (hint: written in python), you only need a video decoder and player. If pygame doesn't give you that, though, you're in for trouble big time, because video codecs are hard. :)
  - slim 6y ago
    also, he will need to type the whole program on the keyboard. like we did when we were kids copying tens of pages of basic from magazines.
- divbzero 6y ago
  Any other ideas so far? I’ve mulled over this question of best first computer for children. The best I’ve come across so far is a plain Linux installation with no desktop environment and a text-based typing program.

fit2rule 6y ago

I would love one of these, but with Lua as the language instead. Its quite possible with something like LOAD81, from antirez[1] - but I guess I'd love to see a full-blown desktop OS with Lua at the core, and not much else. I guess booting directly to a tekui[2] based editor would be nice, too. Something about having a clean boot to a single-language environment which appeals to me more and more as the decades go by. [1] http://github.com/antirez/load81.git http://github.com/antirez/load81.git [2] http://tekui.neoscientists.org http://tekui.neoscientists.org

kohtatsu 6y ago
Seconded. Also check out ComputerCraft. I'd love a club for this kind of thing.
- fullstop 6y ago
  I loved ComputerCraft, but was kind of sad that the source was closed. It fell off of my radar until today, but I'm happy to see that it is now open source!
Seirdy 6y ago
Check out the (sadly inactive) Node9 operating system [0]. > Node9 is a hosted 64-bit operating system based on Bell Lab's Inferno OS, but using the Lua scripting language instead of Limbo and the LuaJIT high performance virtual machine instead of the Dis virtual machine. It also uses the libuv I/O library for maximum portability, efficient event processing and thread management. [0]: https://github.com/jvburnes/node9 https://github.com/jvburnes/node9
- fit2rule 6y ago
  Ah yes, that is nice - thanks for the info. So many interesting things using Lua ..
igravious 6y ago
Same, but with Ruby … Actually had this idea years ago and toyed with hacking a ruby user space atop of Linux From Scratch – course I never went anywhere with the idea. Delighted someone's done it for python. Be cool if there was a Ruby version of snakeware :)

outadoc 6y ago

Fun idea!

andybak 6y ago

When I was a kid other kids either had ZX Spectrum, Commodore 64 or BBC Micros. (yeah - I knew one kid with a Dragon 32 poor sod. And someone with an Atari 400 or 800 where I was jealous of the hardware palette tricks and game cartridges) Anyway - The Commodore seemed the worst option in terms of habitability. Any graphics or sound programming largely consisted of poking random locations in memory. The included BASIC had no direct support for any of the interesting stuff. The quality of the BASIC was also poor. The Beeb probably had the best implementation at the time with the Spectrum coming second. So - I guess what I'm saying is the C64 is a strange role model.

LeoPanthera 6y ago
Until beaten by the Raspberry Pi, the Commodore 64 was the best selling single model of computer in history, Commodore having sold between 12 and 17 million units in its lifetime. So I imagine it is inspired, at least in part, by its ubiquity.
kiney 6y ago
yeah, I remember typing out basic listings full of peek and poke without understanding why and what they did with those memory locations. (on commodore plus4)
the_af 6y ago
The C64's BASIC was indeed very poor compared to the competition, but the hardware (and games) were pretty cool. People wrote games with assembler in all those early home computers.
- abiogenesis 6y ago
  The BASIC v2 was horrible, but still there were plenty of great games written in BASIC (Sid Meier's Pirates was mostly BASIC, for example).
  - the_af 6y ago
    Really!? Wow. I don't see how, will read about it. Do you have any link to read? (any excuse to read about Sid Meier's Pirates! and the C64 is good). In any case, C64's BASIC "programming" meant that for graphics and audio you were mostly POKEing and PEEKing, since its instruction set was very limited. And when you're mostly peeking and pooking directly at memory, you're barely writing BASIC, are you? ;) edit: I tracked down a 2014 comment from HN saying the same as you: that Pirates! was mostly written in BASIC. I'm amazed. Now I really want to see the source code and/or read a "making of".

numpad0 6y ago

> Our window manager, snakewm, is based on pygame/pygame_gui. We do not use X11; snakewm draws directly to /dev/fb0. Whole window system written in Python, That’s hardcore!

JonathonW 6y ago
Well, sort of. Pygame itself is more C than Python. Everything they build on top of that should be able to be pure Python, though, which is pretty nifty.
matheusmoreira 6y ago
I didn't know it was possible to obtain a hardware-accelerated OpenGL context without using GLX. How does it work without X11? Can I draw to the screen without any dependencies?
- Narishma 6y ago
  Probably the same way Wayland or the original Raspberry Pi drivers do it, using EGL.

matheusmoreira 6y ago

Interesting. The GUI is implemented on top of PyGame. The terminal is actually a Python REPL. Do you plan to write replacements for the POSIX utilities? Strict POSIX compliance is not necessary but user space needs the general functionality provided by those packages.

edraferi 6y ago
Any idea where I can get data on POSIX utilities ranked by use/importance?
- woodrowbarlow 6y ago
  you could start with the list of what's included in busybox: https://busybox.net/downloads/BusyBox.html https://busybox.net/downloads/BusyBox.html the goal of busybox is to provided a stripped down posix userspace for use in embedded devices -- basically, provide enough posix utils to be able to do some useful shell scripting.
- matheusmoreira 6y ago
  Start with file management utilities such as ls, cp, mv and rm.
- robocat 6y ago
  Here’s a standard list of Unix commands: https://en.wikipedia.org/wiki/List_of_Unix_commands https://en.wikipedia.org/wiki/List_of_Unix_commands It is probably more comprehensive than what you were after though...
Shorel 6y ago
Why another set of the same old? Let the users (hopefully a new generation with new ideas) create their own paradigms.
- matheusmoreira 6y ago
  Yes. I didn't mean to imply that POSIX utilities should be reimplemented. It's just that a new user space isn't very substantial if users can't even explore the file system. The new software could even be graphical in nature. Right now a Python REPL is the only real way to interact with the operating system.

thesuperbigfrog 6y ago

It reminds me of Perl/Linux. A Linux distribution where ALL programs are written in perl. http://perllinux.sourceforge.net/ http://perllinux.sourceforge.net/

metalliqaz 6y ago
puke
- strbean 6y ago
  Imagine the efficiency of having your whole userland written in one line of code!
  - grawprog 6y ago
    This made me laugh way harder than it should. Just imagine that one line. It'd either be the greatest or most terrifying piece of code I think I'd ever be likely to witness. Probably in all existence really. But then of course, someone would have to come along and port that ultimate one line of Perl code to brainfuck and one up them and then someone else would come along and turn that one liner into an entire lisp dialect and on it'll go.
    - deleted 6y ago
      [deleted]
    - yellowapple 6y ago
      If you think about it, every compiled program is a one-liner.
      - thesuperbigfrog 6y ago
        Or perhaps everything is a one-liner: https://xkcd.com/224/ https://xkcd.com/224/

nkkollaw 6y ago

This is so cool. Congrats!

boogies 6y ago

After seeing "operating systems" like JS/UIX here, it's great to see one that actually boots independently. And it looks like it has multitasking, and contributions from multiple developers, awesome!

eternauta3k 6y ago
To be fair, I think those features came with the Linux kernel.
- AnIdiotOnTheNet 6y ago
  Yeah. I mean, this is still much more effort than every Ubuntu-derived "OS" out there, but it isn't like Haiku or Redox or anything.

adamredwoods 6y ago

I had this exact same idea, just no time to execute it, so very happy to see this. Now, I just have to install it to a Raspberry Pi!

nathell 6y ago

In this genre, I like: Emacs as PID 1 http://www.informatimago.com/linux/emacs-on-user-mode-linux.html http://www.informatimago.com/linux/emacs-on-user-mode-linux....

Y_Y 6y ago
That's really interesting, and something I've been thinking about lately too. I wonder if it would be any better with Guile Emacs, so that you have the FFI. Does anyone here run Emacs as their only environment?

desireco42 6y ago

This actually is really good idea. While I don't use Python often, I wouldn't see this as a problem. By reducing a barrier, they might actually create something fun to use. Also, having a Raspberry Pi as first/default platform would be exceedingly welcome and good. I wouldn't mind Lua as well, Ruby etc. As long as it is something easy to use.

russellbeattie 6y ago

This is funny, the other day when Microsoft released the code to GW-BASIC, I wrote this in response to someone saying their IBM PC booted into a version of BASIC rather than DOS: I've always thought that using BASIC as the default command line was really weird... Like on an Apple II or TRS-80. You could type in a command to load something from a disk or run a program, or type a line number to start programming. How did that make sense to anyone?? To my 11yo self, it was confusing and I've never changed my mind. To add to that thought, I think there's some things which are worth emulating from the good ol' days, and some which aren't. I think this is probably one of the latter.

sjburt 6y ago
But how different is that really than bash? Or even command.com?
- 1bc29b36f623ba8 6y ago
  It isn't, really. The command-line is a beautiful thing!
zozbot234 6y ago
Those computers could not run a general purpose GUI, so a command-line interface was all you got. The nice thing about BASIC in that context is that it's a clean extension of a desk calculator: it gives you floats and math operations, functions etc. out-of-the-box, which took a non-trivial chunk of ROM code to implement on that kind of 8-bit platform.
djaychela 6y ago
Always made perfect sense to me - I grew up on ZX spectrum, BBC Micro and VIC-20. When I started using PCs on dos, that made sense too. I never thought either approach was wrong...
ralphc 6y ago
My 16 year old self found it the opposite of confusing on my TRS-80, especially with everything in ROM. Hit the power button and in seconds you can start programming and exploring. It's how thousands of kids got their start programming.

zelon88 6y ago

I'm just now falling down this rabbit hole of working with frame buffers as a result of this project and now I'm curious. Did you develop your own window manager? This is really fascinating stuff and makes it really simple to create low-level things with a high-level language. [1] [2] Also, does OpenGL work? [1] http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/ http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/ [2] https://www.kernel.org/doc/Documentation/fb/framebuffer.txt https://www.kernel.org/doc/Documentation/fb/framebuffer.txt

kelnos 6y ago
> Also, does OpenGL work? There's no reason why it can't; OpenGL doesn't require X11 (or Wayland), and EGL (a library/interface that binds the OGL implementation to a windowing/display system) could certainly be implemented for linuxfb (if it hasn't been already). Either way, I'd expect the current state of snakeware's graphical environment is that it won't work without some (possibly large) modifications.
- cycloptic 6y ago
  Fbdev is a legacy interface and is probably not what you want if you're developing something beyond a simple demo. Check kmscube for a modern example of how to use EGL with DRI/KMS/GBM: https://gitlab.freedesktop.org/mesa/kmscube/ https://gitlab.freedesktop.org/mesa/kmscube/
aduitsis 6y ago
Tangentially, Plan9 extends the notion of /dev/tty to something called the draw device. Meaning that a process can just map and use /dev/draw to provide graphics. Those graphics are rendered into the window of the process.

ralphc 6y ago

This needs to be on a Raspberry Pi.

the_af 6y ago
Semi-related, I recently installed the BMC64 distro on my unused Raspberry Pi. It boots directly to VICE, no "Linux" to be seen. It's like booting a C64. You turn it off by unplugging, just like the real thing. The only thing that tells you this is not a real C64 (besides lacking the keyboard/case) is that you can bring up a menu with lots of options with F12 (necessary to mount disk images, at the very least). Wow, does it take me back to my childhood!
- 1bc29b36f623ba8 6y ago
  Semi-semi-related, there was a commercial distro named Amithlon that booted straight into AmigaOS 3.9. Alas, it was discontinued, but it had a really nice AmigaOS feel to it.
  - the_af 6y ago
    Cool! I missed the boat back then and never did own an Amiga. It was too expensive for my parents to buy. Later I heard it was an incredible machine and young me would have loved to toy with it.
    - 1bc29b36f623ba8 6y ago
      It was a cool machine, and AmigaOS was simply awesome compared to contemporary consumer operating systems, but alas Commodore went belly-up before they managed to modernize the platform.

muxxa 6y ago

This is wonderful. I’ve often fantasised about unifying the command line and the desktop into a single UI paradigm and this project could just give me a realistic shot at trying it out. Anyone who is interested, much of this classic has yet to be tried properly afaik: https://en.wikipedia.org/wiki/The_Humane_Interface https://en.wikipedia.org/wiki/The_Humane_Interface Another idea: instead of having Photoshop/Excel etc. clones, have a document centric rather than application centric UI and allow features to be installable when they are needed (micro-apps?). E.g. Gaussian blur or spellchecking could be things you’d add from a microapp directory which would add an extra button to your interface for images and documents respectively.. you’ll build up a personalised interface and ‘own’ it, rather than being presented with a sea of unknown buttons/menu-items.

schwartzworld 6y ago
> unifying the command line and the desktop into a single UI This is how computers used to be. I had an Apple II which was exactly this. if you booted without a disk in, you just got a BASIC prompt.

Shorel 6y ago

This is great. I think a laptop with this, along with a Python book is one of the greatest gifts for someone to learn about computers and programming. All exploration and few distractions.

giancarlostoro 6y ago

Nobody seems to have mentioned it, but I would love to see how this grows and whether or not if they'll eventually adopt Cython, which would bring a lot of performance boosts, but also be good for Cython in general. Cython: https://cython.org/ https://cython.org/

Anka33 6y ago

Python is crap

salgernon 6y ago

There are a lot "See also" - so I'd like to shout out to the late Terry Davis' "TempleOS" and his ... strange take on an interactive boot-to-command line system based on C++ and x86_64. [*] https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS [Edit]: See also http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ http://www.codersnotes.com/notes/a-constructive-look-at-temp...

Animats 6y ago

Sounds like the One Laptop Per Child environment. That had a Python user space. Can you still run it?

smabie 6y ago
I was thinking the same thing. I actually own the original OLPC, and unfortunately, that thing is a pile of garbage. The entire UI and all apps are programmed in Python, which while good for getting children into programming I guess, is bad for actual use. The system is so unimaginably slow that doing really anything at all is unusable. Like every other adult who bought one, I installed Debian on it and a lightweight tiling window manager.
- cellularmitosis 6y ago
  I keep my OLPC (running Debian) around for precisely the reason of having a low-spec touchstone to keep me grounded. Heck I even test some programs on an NSLU2! https://gist.github.com/cellularmitosis/9ab25536b01d903539bd3d161cb7e3ed https://gist.github.com/cellularmitosis/9ab25536b01d903539bd...

deleted 6y ago

[deleted]

askvictor 6y ago

Nice; I had been thinking of building something similar aimed at the raspberry pi, to make it easier to just get python scripts running, without having to learn about the OS. But never found the time. Was going to be called PyOS (pun on BIOS): https://github.com/askvictor/pyos https://github.com/askvictor/pyos

logicprog 6y ago

I kind of really want to contribute to this now. I've contributed to SerenityOS, too. But do I have time? No.

artifact_44 6y ago

I want this but for v8/js!

lioeters 6y ago
This may float your boat: https://github.com/NodeOS/NodeOS https://github.com/NodeOS/NodeOS

musicale 6y ago

Wasn't Python basically invented as the scripting language for the Amoeba OS? I often imagine an alternate reality where much of the non-performance-critical Unix/Linux userland such as login is written in Python.

bonestormii_ 6y ago

This is a very fun-looking project. However, in the GNU/Linux world, "user space" is a very broad term referring to everything running outside of the kernel. 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. In the README, you say you want to get it to boot without Busybox. Busybox is currently the thing filling this void for you now. It is providing your actual user space, including it's systemV-inspired init system. What you have here is basically a very simple pygame template with an embedded application build tool chain. Which is totally cool, and potentially fun and productive. But it isn't replacing the GNU/Linux user space, which is C heavy, but very language diverse. I would focus not on replacing the user space, but interfacing with it where reasonable. To that end, you may even want to consider shedding pygame and interfacing with X11/wayland. Identify the surfaces you want to control with python and implement that. It will perform better, and be more true to what makes Linux "Linux".

bibabaloo 6y ago
> 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.

deleted 6y ago

[deleted]

yencabulator 6y ago

It claims to be "fully Python-based Linux distro" but it seems to be just a buildroot config with an init.d script that runs the python repl in a loop. There's still /bin/sh, C tools, etc. https://github.com/joshiemoore/snakeware/blob/master/snakeware/overlay/etc/init.d/S30startpy https://github.com/joshiemoore/snakeware/blob/master/snakewa...

corgihamlet 6y ago
Same thing with a C64 - you have a simplified BASIC-environment but still can use the underlying Assembler.

amitport 6y ago

it's just 'buildroot' (which is a minimalist distro that happens to include python). I mean the python window manager is interesting but also mostly delegates to pygame. Calling it a distro is a "bit" over-selling it IMO