Walnut Creek sold a Sprite CD-ROM back in the day. I got Sprite to boot on a Sun SPARCStation IPC. It was kind of unstable. I really wanted to try process migration and the log structured file system.
You really don't want to run Sprite on a single host, unfortunately -- the local filesystem path is buggy, and there are some major bugs in the system as preserved on the CD-ROM, e.g. vfork() is totally borked, at least for software which expects a BSD-style vfork.
With some fixes, it can be pretty stable. Here's a web server running on Sprite on an IPC: https://ember.shockfox.net/
Or, well, it is running right now. I don't leave it online 24/7, so caveat emptor to future visitors.
At the moment, no. Beyond just fixing problems I've found, for the last year I've been doing a lot of haphazard development inside of Sprite itself, so "fixes to bugs in released Sprite" are intermingled with "features I've added". The bigger problem is that getting data in/out of Sprite is ... harder than you'd imagine.
I am hoping to make a big writeup "soon", since there's a lot of interesting information about Sprite that's mostly been lost to time, where Sprite is mostly remembered as having "process migration" and "LFS". Meanwhile, it's mostly forgotten that Sprite was (apparently) one of the first OSes to adopt a mostly-GNU userland, had a modern event-loop style abstraction in C for handling I/O and timers (Fs_Dispatch), had a userspace filesystem abstraction akin to FUSE (PFS), implemented a PTY-like system entirely in userspace (the Td* functions in libc), and overcommitted memory by default.
I feel like if you have a single system image, process migration is easy (or at least tractible), but without that, it's going to be pretty challenging. Live migration of VMs across hypervisors is more approachable than migrating a process between two individual systems... You've got all that I/O that needs to be proxied, etc.
Single system image across multiple nodes doesn't seem to be getting much mindshare either.
I did a research SSI in the early 2000s. After getting it largely to work, we kind of put it aside. Why would we aspire to using 'ps' and 'ls' and 'mount' and such to manage our large scale systems? surely there was a better model.
20 years later people are still sshing into nodes to fuss around, and treating cluster nodes like pets. it still could be done pretty easily, I guess its not really in anyone's interest to invest the 2 years it would take. there is a lot more money to be made nibbling around the edges of the problem.
I've used systems with bits and pieces of this and IMHO, it feels pretty tempting to build this... But yeah, the real question is what application do you or will you run that requires it and is it worth the cost to build?
Especially if you can do similarish stuff in other ways. There's several distributed filesytems available now. There's lots of process orchestration tools. Single nodes today can be enormous compared to single nodes and even some clusters from the 2000s.
Walnut Creek sold a Sprite CD-ROM back in the day. I got Sprite to boot on a Sun SPARCStation IPC. It was kind of unstable. I really wanted to try process migration and the log structured file system.
You really don't want to run Sprite on a single host, unfortunately -- the local filesystem path is buggy, and there are some major bugs in the system as preserved on the CD-ROM, e.g. vfork() is totally borked, at least for software which expects a BSD-style vfork.
With some fixes, it can be pretty stable. Here's a web server running on Sprite on an IPC: https://ember.shockfox.net/
Or, well, it is running right now. I don't leave it online 24/7, so caveat emptor to future visitors.
Is there anything I can read about the fixes to make it more stable? Or just a place to check out recent developments?
At the moment, no. Beyond just fixing problems I've found, for the last year I've been doing a lot of haphazard development inside of Sprite itself, so "fixes to bugs in released Sprite" are intermingled with "features I've added". The bigger problem is that getting data in/out of Sprite is ... harder than you'd imagine.
I am hoping to make a big writeup "soon", since there's a lot of interesting information about Sprite that's mostly been lost to time, where Sprite is mostly remembered as having "process migration" and "LFS". Meanwhile, it's mostly forgotten that Sprite was (apparently) one of the first OSes to adopt a mostly-GNU userland, had a modern event-loop style abstraction in C for handling I/O and timers (Fs_Dispatch), had a userspace filesystem abstraction akin to FUSE (PFS), implemented a PTY-like system entirely in userspace (the Td* functions in libc), and overcommitted memory by default.
Process migration seems like something that should be commonplace today. It would be an amazingly handy feature.
I feel like if you have a single system image, process migration is easy (or at least tractible), but without that, it's going to be pretty challenging. Live migration of VMs across hypervisors is more approachable than migrating a process between two individual systems... You've got all that I/O that needs to be proxied, etc.
Single system image across multiple nodes doesn't seem to be getting much mindshare either.
I did a research SSI in the early 2000s. After getting it largely to work, we kind of put it aside. Why would we aspire to using 'ps' and 'ls' and 'mount' and such to manage our large scale systems? surely there was a better model.
20 years later people are still sshing into nodes to fuss around, and treating cluster nodes like pets. it still could be done pretty easily, I guess its not really in anyone's interest to invest the 2 years it would take. there is a lot more money to be made nibbling around the edges of the problem.
I've used systems with bits and pieces of this and IMHO, it feels pretty tempting to build this... But yeah, the real question is what application do you or will you run that requires it and is it worth the cost to build?
Especially if you can do similarish stuff in other ways. There's several distributed filesytems available now. There's lots of process orchestration tools. Single nodes today can be enormous compared to single nodes and even some clusters from the 2000s.