Author here,
In case all resources are equally owned, the QoL is bound to all of them (as opposed to none). It does take multiple purchases to increase the QoL, but it is the only way. Otherwise people would starve due to aboulomania.
The average QoL is sampled each end of day, step 73-75 depending on the random seed. At step 72 you are seeing the zeroth day average QoL ,with nearly all the intraday mutations of the first day.
Thanks, and agreed.
How ironic though, working on that fantasy is near certainly not economically viable. This blog post is merely procrastination that preempted job seeking.
Author here, simulation 16 shows that money printing, and tax have common effects. The state can replace one with another. Here the 65% tax is replaced with 10% tax plus inflation, i.e., giving new money to public servants. The new money creation decreases the value of money owned by producing workers.
We could even remove the tax entirely, and still support the 3 public servants.
To be convinced you can look at each unit transaction and see that all resource are accounted for.
Another way to look at it, is that the QoL of producing workers is lower than if there was no public servants. Every resource a public servant has, is bought from a worker at some point, whether the money for the purchase comes from taxation or inflation.
It'd go well as comparison vs. this code I've been playing around with from Phillip Rosedale (Founder of Second Life) where he's simulating economy for purposes of determining wealth distribution scenarios: https://editor.p5js.org/PhilipRosedale/sketches/odl5elMWy
I'd love to take a look too. Just a suggestion, push it to github then clean it up. It's always helpful to see not just the product but the process.
Great work.
Location: France
Remote: Yes
Willing to relocate: Yes
Technologies: Rust, Javascript, webgl/webgpu, SQL
Résumé/CV: https://github.com/Ruddle
Email: mail@thomassimon.dev
I worked in medical research, military, video games, b2b/b2c, CMS, OS dev, audio. I assumed the role of CTO, lead developer, fullstack. I built products from a to z, sales sometimes included. Co-founder of 4 startups that failed. Lots of side project, recently Fomos that was on HN front page this week.
Looking for new opportunities !
Ready to work now !
Author here. Your guess is correct.
An app is its own callback.
It might be possible to write an small app-level executor to get back those sweet language-level support for async though.
Author here, that's a neat idea. However I also like the simplicity in having only one runtime interface. If the OS has to handle every version anyway, an app in the future could just use padding to feel like it is "clean".
struct Context{
padding: [u8;256], // old stuff
ctx: ContextV42
}
Just typing that felt a bit wrong though. On the other hand the app declaring what version it is feels like what executable formats (like elf) already solve. I am trying alternatives.
Author here. Scheduling is a spectrum. Current OS are preemptive, but also a bit cooperative. An app can make the decision of yielding control.
The opposite could work: OS is cooperative, unless some threshold of resource usage is triggered (a timer interrupt of instance). It then context switch to enter a, hopefully rare, failure mode, thus turning preemptive. Kill the app, and get back into cooperative mode. Let's call it optimistically cooperative & pessimistically preemptive.
If you're serious about this: make it preemptive. Handle interrupts in the kernel and find a nice way to pass them on to user processes. Any kind of prioritization mechanism will require preemption. I've written an experimental OS myself and I know this is hard stuff but if you can't crack that this is likely to be DOA. If you just want to play around then that's fine of course, there is nothing to stop you from doing that but if you want to see any kind of external adoption it is more or less a must.
Also: this is more like a multi-threaded app itself than an actual OS, for it to be a proper operating system you'd expect at a minimum memory barriers between applications. In that sense the bar for what an OS is has been raised quite a bit since the times of CP/M where it was more of a 'handy library to do some I/O for me' (on mainframes and mini computers there were already proper operating systems back then but on micro computers we had to wait until OS/9 to have something similar).
It was called 'Unite', some of the details: QnX clone for x86/32 which at the time wasn't available (nor would Quantum commit to releasing something like that). Pre-emptive multi-tasking, multi-user micro kernel based on the QnX API calls. It worked quite well, we built a bunch of devices that used it internally as the firmware (mostly: internet bandwidth management in the context of a hosting facility). Some HN'er has been trying to revive it in a virtual environment.
You're welcome. One of these days I should try to revive it myself, it's been decades since I last worked on the code though. But I still have the installation media that I made (floppy images) so it should be possible to bring it back to life.
It could also be cooperative scheduling with a watchdog with task killing abilities (like we have for memory usage, it's effectively cooperative + OOM)
