Snakeware – Linux distro with Python userspace inspired by Commodore 64(github.com)
github.com
Snakeware – Linux distro with Python userspace inspired by Commodore 64
https://github.com/joshiemoore/snakeware
10 comments
Smalltalk also did this. These days my impression is the most active tendril is https://pharo.org/.
What I find especially interesting about that relative to this Python distro is that the Pharo executable runs in a host OS (e.g. whatever your daily driver is) and can maintain different image files for different Pharo system states. So not only do you have the integrated language/OS (which is very cool on its own), but you also have something that feels like Docker containers.
And it even goes beyond containers because those image files really are the state of the system at the time they're saved, which means you can ask for that file in a bug report and get guaranteed bug reproduction, which is pretty incredible.
What I find especially interesting about that relative to this Python distro is that the Pharo executable runs in a host OS (e.g. whatever your daily driver is) and can maintain different image files for different Pharo system states. So not only do you have the integrated language/OS (which is very cool on its own), but you also have something that feels like Docker containers.
And it even goes beyond containers because those image files really are the state of the system at the time they're saved, which means you can ask for that file in a bug report and get guaranteed bug reproduction, which is pretty incredible.
Sounds like maybe they took inspiration from the old Lisp machines and session saving, like this: http://www.lispworks.com/documentation/lw61/IDE-M/html/ide-m...
No -- the old Lisp machines were inspired by Smalltalk! A complete environment with persistent heap images was one of the innovations brought by Xerox PARC's Smalltalk research.
Actually Smalltalk was earlier inspired by Lisp. Lisp already had persistent heap images in 1960 in the first implementation.
A development environment with persistent heap images was already provided by BBN Lisp in the late 60s. The in-image structure editor for BBN Lisp came in 1968. A "make" like feature came in 1971.
Xerox then took BBN Lisp and developed it as Xerox Interlisp from 1972 onwards. Masterscope then was a source code management system in 1973. 1974 it ran on the Alto with a microcoded implementation. 1976 Interlisp got a window system and a virtual machine specification.
Xerox Interlisp-D then ran on the same hardware (the D-machines) as Smalltalk -> it was another operating system option. It basically appeared at same time as Smalltalk 80. Smalltalk and Interlisp were developed by different teams (with some overlap), in the same company and also for the same hardware.
See the history&timeline of Interlisp: https://interlisp.org/doc/info/history.html
Interlisp has been open sourced: https://interlisp.org/
The MIT Lisp Machines were inspired by the Xerox systems, but were different hardware with a slightly different target audience and different approaches in software development. Xerox was a commercial company with PARC as a research lab. The MIT AI lab was a well funded research lab at an university (MIT). Their more powerful systems were mainly developed for their AI researchers.
A development environment with persistent heap images was already provided by BBN Lisp in the late 60s. The in-image structure editor for BBN Lisp came in 1968. A "make" like feature came in 1971.
Xerox then took BBN Lisp and developed it as Xerox Interlisp from 1972 onwards. Masterscope then was a source code management system in 1973. 1974 it ran on the Alto with a microcoded implementation. 1976 Interlisp got a window system and a virtual machine specification.
Xerox Interlisp-D then ran on the same hardware (the D-machines) as Smalltalk -> it was another operating system option. It basically appeared at same time as Smalltalk 80. Smalltalk and Interlisp were developed by different teams (with some overlap), in the same company and also for the same hardware.
See the history&timeline of Interlisp: https://interlisp.org/doc/info/history.html
Interlisp has been open sourced: https://interlisp.org/
The MIT Lisp Machines were inspired by the Xerox systems, but were different hardware with a slightly different target audience and different approaches in software development. Xerox was a commercial company with PARC as a research lab. The MIT AI lab was a well funded research lab at an university (MIT). Their more powerful systems were mainly developed for their AI researchers.
For those interested in experiencing this developing experience firsthand, there is a Pharo MOOC: https://mooc.pharo.org/
I started playing with that one the last week. Sadly Kaspersky AV decided it was malware and deleted it without prompting me first.
Cool!
Antirez built one for Lua: https://github.com/antirez/load81
Antirez built one for Lua: https://github.com/antirez/load81
For the last month or so I was thinking it would be awesome to have a desktop with a lot of the most common GUI utilities written in python so that average programmers could have a stab at customizing it for their needs. But this is too much work for me and I'm kind of following a different dream right now.
An easy modified Desktop Environment written in Python was one of the goals of the "One Laptop per Child" project. They succeeded[1], it's now separate from the hardware and can run on anything from your phone, raspberry pi, regular computer and the OLPC-machines.
(Another goal was better sandboxing bitween apps. Their project was called Bitfrost and was in many ways the first step towards flatpak that we use today)
[1]: https://www.sugarlabs.org/
(Another goal was better sandboxing bitween apps. Their project was called Bitfrost and was in many ways the first step towards flatpak that we use today)
[1]: https://www.sugarlabs.org/
Nobody seriously goes into things intentionally making them obtuse.
The current complexity is a product of poor design from a sincere effort for simplicity.
Trying to be easy, lightweight, simple, is the silver bullet way to create a mess and it's why when you see those words in software names it's always just a sprawling stochastic tangle.
The easiest way to avoid the mess is to make things dumb.
The current complexity is a product of poor design from a sincere effort for simplicity.
Trying to be easy, lightweight, simple, is the silver bullet way to create a mess and it's why when you see those words in software names it's always just a sprawling stochastic tangle.
The easiest way to avoid the mess is to make things dumb.
I think a few of us thought about that. It seems the "Hello" System[1] wants to got that way. Write most applications in PyQt, have the source somewhat accesible (I would think a direct menu item or button in the "About" dialog would improve on the UX of that, though)
Not sure whether I'd personally go with PyQt. (Or a post-1.x Python feature set in general). What would be neat is some kind of "My first Github" social coding platform, where you could push your homegrown new features, discuss & share them.
[1]: https://hellosystem.github.io/docs/user/components/applicati...
Not sure whether I'd personally go with PyQt. (Or a post-1.x Python feature set in general). What would be neat is some kind of "My first Github" social coding platform, where you could push your homegrown new features, discuss & share them.
[1]: https://hellosystem.github.io/docs/user/components/applicati...
[deleted]
Did xonsh ever take off?
I was using it briefly a while back, and I kinda sorta enjoyed being able to write python code directly in the shell.
I was using it briefly a while back, and I kinda sorta enjoyed being able to write python code directly in the shell.
I don't think it has "taken off" but last time I looked it was very usable and feature rich and I found no reason not to use it.
I'm going to look at it again. It looks like they weren't forwarding keyboard interrupts to executables gracefully. But instead capturing them themselves.
I haven't needed to intercept ctrl-c and forward it on in a program ever, but it seems like that should be a basic thing a shell should do easily enough.
I haven't needed to intercept ctrl-c and forward it on in a program ever, but it seems like that should be a basic thing a shell should do easily enough.
Previously, Jun 2020, 158 comments: https://news.ycombinator.com/item?id=23391380
I've always wanted to take antirez' LOAD81 and turn it into a full-blown user execution environment/desktop:
http://github.com/antirez/load81.git
It also has a C64-inspired interface to a REPL (Lua, yay!) - and it wouldn't need a lot of effort to expose more services to the VM for programmers to use in building better apps.
Would be cool to have a sophisticated desktop environment entirely based on Lua scripting .. especially with a built-in editor. The fulfillment of a lot of dreams.
http://github.com/antirez/load81.git
It also has a C64-inspired interface to a REPL (Lua, yay!) - and it wouldn't need a lot of effort to expose more services to the VM for programmers to use in building better apps.
Would be cool to have a sophisticated desktop environment entirely based on Lua scripting .. especially with a built-in editor. The fulfillment of a lot of dreams.
I love this concept. I've always wanted to see this, but in Scheme.
GuixSD and Emacs as shell or EXWM for window manager achieve a similar result.
[deleted]
Ooh, nice; I had half a mind to do something like this a few years ago (called PyOS), but never had the time. My rationale was that getting python code running on boot on a raspberry pi required learning about Linux sysadmin, rather than just coding (which, for high-school students, is important to make it quick and easy to see results). Micropython does this - drop a main.py and/or boot.py and it runs on boot; or you have a repl. Why not on a fully fledged computer?
Nice. I think a RasaperryPI 4 version would be nice...
See also https://news.ycombinator.com/item?id=28289506
It already works on RPi4, they provide an image for RPi and the demo video from the linked page was recorded on RPi4.
Nice
More "authentic" (but also way less useful) if it booted to "bare metal" with no OS, just a Python (or similar) unikernel.
So one could do peek/poke, right to the hardware etc.
More "authentic" (but also way less useful) if it booted to "bare metal" with no OS, just a Python (or similar) unikernel.
So one could do peek/poke, right to the hardware etc.
Like MicroPython [0]? I use that for a few hobby projects.
It works fairly well for all the little things, like the weather station I built with it. Being able to drop to REPL and rewrite functions on the fly is a little magic, too.
[0] https://micropython.org/
It works fairly well for all the little things, like the weather station I built with it. Being able to drop to REPL and rewrite functions on the fly is a little magic, too.
[0] https://micropython.org/
They should integrate Portage from Gentoo as it’s written in Python. Then they could have a precompiled package manager based off it.
The same way FreeBSD had Pkg and Ports systems.
The same way FreeBSD had Pkg and Ports systems.
I don't think that aligns with their goals.
There were similar ones done with Perl:
https://www.foo.be/docs/tpj/issues/vol5_2/tpj0502-0009.html
https://blog.sudobits.com/2012/08/18/perl-linux-a-linux-dist...
All of these projects seem to be reaching for an integrated programming language / operating system like the Lisp machines of yore. It was before my time, so I never got to use one, but from what I have read, they were quite amazing to use.