3 ms·
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 preser
by spijdar 20d ago
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/ 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.
- Qwuke 20d agoIs there anything I can read about the fixes to make it more stable? Or just a place to check out recent developments?
- spijdar 20d agoAt 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.
- hedgehog 20d agoThat would be very interesting to read, other systems like Plan 9 get talked about a lot but I didn't know almost anything about Sprite until today.