
Snakeware – Linux distro with Python userspace inspired by Commodore 64 - AnIdiotOnTheNet
https://github.com/joshiemoore/snakeware
======
snazz
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)

~~~
bityard
> 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.

~~~
franga2000
Piping data from one command to the next is one of those things that I love
showing to new users and it gets them all excited, only to then have to
disappoint them when they think of a cool idea because they'd need to learn
regex, sed and awk first to do anything non-trivial.

It's a shame Powershell is a disaster, because having a structured-by-default
pipeline would've really bridged the gap between power users and programmers.

~~~
majkinetor
> It's a shame Powershell is a disaster

Yeah, lets get back to bash forever :S

~~~
franga2000
Bash is a good shell with a fairly unimpressive pipeline. Powershell is bad
shell with a good pipeline.

For me, as a programmer, the shell part of a shell is more important, as I can
do the rest in a more powerful language. Powershell is too verbose for shell
usage (see New-Item), brings nothing new to the table in terms of scripting
and is ultimately not worth using just for the better pipeline.

(another commenter pointed me to Nushell, which seems to be a very good middle
ground, and I've heard of a few more similar efforts, so we hopefully won't be
stuck with just bash for too long)

~~~
majkinetor
Oh, here we go again with verbosity like aliases are non existent. For realz,
New-Item is ni for example or mkdir or whatever...

> as I can do the rest in a more powerful language

Powershell is like repl for dotNet. You can't really get more powerfull.

> brings nothing new to the table in terms of scripting

Are you serious ? I guess somebody has a lot of learning to do.

> (another commenter pointed me to Nushell, which seems to be a very good
> middle ground, and I've heard of a few more similar efforts, so we hopefully
> won't be stuck with just bash for too long)

We were on that road number of times before...

~~~
franga2000
> Oh, here we go again with verbosity like aliases are non existent

Aliases would have to be standardised (and I don't mean the crap they pulled
with aliasing wget) and regardless, only provide an illusion of simplicity
that breaks down the moment you try to do anything more advanced.

> Powershell is like repl for dotNet.

The only place dotNet actually matters on Windows. Everywhere else it's just
unnecessary bloat.

> You can't really get more powerfull.

I mean, yeah, technically anything Turing-complete is as powerful as it gets.
But things like generators, coroutines, easy multi{thread,process}ing, good
support for object-oriented and functional patterns... are what I'm looking
for in a powerful language.

> Are you serious ? I guess somebody has a lot of learning to do.

Besides structured data, which was the entire point of this discussion, I
don't know of anything Powershell can do that other scripting languages can't.
I am, of course, not counting the many system and application hooks, as those
are usually 1) not part of Powershell itself, 2) Windows-only and 3) were
already possible on Linux (unlike on Windows, basically everything has CLI
support here).

In all of this, btw, I was not considering Python a scripting language, which
I easily could have (there are even a few neat shells for it). Once you have
Python, it's barely even a contest.

~~~
majkinetor
> Aliases would have to be standardised (and I don't mean the crap they pulled
> with aliasing wget) and regardless, only provide an illusion of simplicity
> that breaks down the moment you try to do anything more advanced.

OK, wget/curl was bad idea, but lets not overreact here about one bad
judgement. Illusion of simplicity ? That breaks ? Cmon... never had a single
problem with aliases until pwsh, and I am using Powershell 24x7 almost
exclusivelly in aliased form. Also, powershell does standardize aliases, once
they are in, they never change (except when it went x-plat, but everything
changed, so that is moot point).

> The only place dotNet actually matters on Windows. Everywhere else it's just
> unnecessary bloat.

Let me just say here that entire sentence is crap :) I do not work for MS but
life became good when it was x-platformed. MS reputation was bad in linux
world but its a social construct that now starts to fade away. I am into
technology, not into that social mumbo jubmo bs.

> I mean, yeah, technically anything Turing-complete is as powerful as it
> gets.

You cant really compare PowerShell with mainstream langauges, since its made
for shell context. Regardless, you can do all those fancy stuff in C# and
compile it inline. Native powershell has all the things you mention tho, seems
you need to take a good look into it (except coroutines but who cares for that
in shell ?)

> I don't know of anything Powershell can do that other scripting languages
> can't.

Let me cite another well known person to you - I mean, yeah, technically
anything Turing-complete is as powerful as it gets. The point is to do it in
easy to understand and concise manner, without reinventing the entire universe
in the process.

> In all of this, btw, I was not considering Python a scripting language,
> which I easily could have (there are even a few neat shells for it). Once
> you have Python, it's barely even a contest.

I was waiting for this: lets get python (or ruby or <insert-non-shell-
language-here>. Lets be serious about this.

~~~
franga2000
> aliases, etc.

Aliases only hide verbosity in base commands. If the parameters and switches
are overly verbose too, they can't help you there.

> dotNet

I'm not saying it's not good and certainly not just because it's from
Microsoft. I've done Windows and Linux development and while it's the way to
go on Windows, I've never missed it on Linux.

> You cant really compare PowerShell with mainstream langauges

I never intended to, but you called it as powerful as it gets, which really
isn't true. I was just giving you examples of why it isn't.

> reinventing the universe

See, to me, the reason I can't switch to powershell is because it seems to
reinvent too much - both from a shell and a scripting perspective.

> Python

The whole reason why I brought it up was to continue my original point of
"unimpressive for scripting". While I appreciate the convenience of using the
same language for shell and scripting, I have no problem using a non-shell
language to do more complex things.

Either way, you have successfully convinced me to give Powershell a try one
more time once I get some free time to experiment.

~~~
majkinetor
> If the parameters and switches are overly verbose too, they can't help you
> there.

There are parameter aliases too, proxy vars and you can shorten their name to
unique subset which gets you as far as you can get anywhere

> Either way, you have successfully convinced me to give Powershell a try one
> more time once I get some free time to experiment.

Thats good to know :) Do it right, and you wont regret it, I can promise that.

------
andybak
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.

~~~
the_af
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
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
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".

~~~
abiogenesis
I don't remember if it was compiled BASIC or if you could actually freeze the
game and print the listing. I do remember that it was _mostly_ BASIC as I
mentioned though, meaning that it resorted to ML routines when needed.

Just found out that it wasn't even compiled BASIC:
[https://www.c64-wiki.com/wiki/Pirates!#Miscellaneous](https://www.c64-wiki.com/wiki/Pirates!#Miscellaneous)

It is debatable if using PEEKs and POKEs for audio and video functions changes
the fact that it is actually BASIC. You are only imitating LDA and STA
opcodes, the rest is still BASIC.

~~~
the_af
Awesome. Thanks for the info! I'm really surprised by this. I didn't know you
could do anything useful with C64's BASIC. I know _I_ didn't. I waited till I
had GW-BASIC on a PC XT to really learn how to program.

If Pirates! was mostly high level BASIC, I wish the source code was available
somewhere to read. Kind of like Broderbund, which released the assembly
language code for some of its old games...

~~~
abiogenesis
It should be pretty straightforward to extract it from the image file using
the modern emulator/debuggers. I believe the comments (if any) will be scarce,
but still...

------
muxxa
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
> 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.

------
zelon88
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
> _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
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/)

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

~~~
Y_Y
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?

------
thesuperbigfrog
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
_puke_

~~~
strbean
Imagine the efficiency of having your whole userland written in one line of
code!

~~~
grawprog
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.

~~~
yellowapple
If you think about it, every compiled program is a one-liner.

~~~
thesuperbigfrog
Or perhaps everything is a one-liner:

[https://xkcd.com/224/](https://xkcd.com/224/)

------
kiney
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.

------
numpad0
> 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!

~~~
matheusmoreira
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
Probably the same way Wayland or the original Raspberry Pi drivers do it,
using EGL.

------
fit2rule
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)

~~~
Seirdy
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
Ah yes, that is nice - thanks for the info. So many interesting things using
Lua ..

------
eythian
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
Another similar environment is Oberon. It allowed you to select any snippet of
Oberon code and execute it!

------
bonestormii_
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
> 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_
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
> . 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_
You are mistaken. Pygame depends on CPython, as it is a C extension. Under the
hood, even this window manager is mostly C.

~~~
pjmlp
And? Who says that Pygame is the only way of implementing this?

~~~
bonestormii_
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'.

~~~
pjmlp
Sure you can, that is the whole goal of PyPy, IronPython, Jython, Python on
GraalVM, Python on OpenJ9, CircuitPython and plenty of other attempts.

Anyone that understands compilers knows one can write language X in X.

In fact, "Writing Interpreters and Compilers for the Raspberry Pi Using
Python" does exactly that.

We can nuke CPython and there is plenty of Python code that would still run
without problems.

~~~
bonestormii_
I'm sorry man, but you sound incoherent to me.

You can write a compiler for python in python--but it still needs the original
cpython (or jython, or ironpython, or pypy, etc.) to run, because there is no
compiled binary produced by your python code.

You can write a compiler for any language using python, but you need one of
the interpreters you mentioned, and you can't throw it away unless it produces
a binary. Maybe Cython can do this. But if it needs an interpreter to run,
you'll have to keep the interpreter around as a non-python dependency.

But who cares? Unless you rewrite a Pygame from scratch, or replace it with
another graphics library, in which case you need to rewrite snakeware from
scratch, none of this is relevant here.

It's just insane. You are proposing rewriting entire language runtimes and/or
graphics engines to preserve 1400 lines of python code (mostly a menu, a
calculator, and a game of snake), with the supposed goal of creating an all
python user space, and dismissing it as "Who says you can't do it?". I'm not
saying it's impossible, but it makes no sense. You'd be better off starting
over and taking this on with a different strategy. If your end goal is an all
Python user space linux distro that actually works like linux, this project is
a non-starter without being totally reimagined with virtually 0 reuse of the
code that's there even at a conceptual level. You wanna rewrite pygame or
python's compiler? Be my guest! It has nothing to do with your supposed
objective though.

At the very least, you would need to get out of the pygame window simulation,
start using a standard graphics compositor, and replacing existing utilities
with python alternatives to make this work. But again, even CPython, Jython,
PyPy, etc. will need to remain. Maybe Pygame can be made to work with PyPy, in
which case you get close to what you want--but it's still a C extension, not
python. And that's your graphics renderer. So why not just use Wayland or
something then?

I think the quest for language purity at the OS level is a fun dream to
pursue, but you need to decide where to cut it off in terms of scope and how
to implement the scope you choose.

------
matheusmoreira
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
Any idea where I can get data on POSIX utilities ranked by use/importance?

~~~
woodrowbarlow
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.

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

~~~
richk449
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
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
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.

------
yencabulator
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/snakewa...](https://github.com/joshiemoore/snakeware/blob/master/snakeware/overlay/etc/init.d/S30startpy)

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

------
askvictor
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)

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

------
russellbeattie
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
But how different is that really than bash? Or even command.com?

~~~
1bc29b36f623ba8
It isn't, really. The command-line is a beautiful thing!

------
boogies
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
To be fair, I think those features came with the Linux kernel.

~~~
AnIdiotOnTheNet
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.

------
desireco42
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.

------
giancarlostoro
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/)

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

~~~
smabie
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
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/9ab25536b01d903539bd...](https://gist.github.com/cellularmitosis/9ab25536b01d903539bd3d161cb7e3ed)

------
musicale
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.

------
Shorel
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.

------
adamredwoods
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!

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

------
salgernon
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-
temp...](http://www.codersnotes.com/notes/a-constructive-look-at-templeos/)

------
amitport
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

------
ralphc
This needs to be on a Raspberry Pi.

~~~
the_af
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
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
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
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.

------
artifact_44
I want this but for v8/js!

~~~
lioeters
This may float your boat:
[https://github.com/NodeOS/NodeOS](https://github.com/NodeOS/NodeOS)

------
nkkollaw
This is so cool.

Congrats!

------
outadoc
Fun idea!

