It's still a good idea to abstract away these services behind a standardized interface. This way switching from one service to another is just a matter of providing an alternative implementation to said interface.
Granted this approach requires a little foresight...something many companies seem to not have nowadays.
Abstractions are not free either, so if you are creating this "standardized interface", the complexity price you pay is better be worth it.
Often it's less effort to lean in and use all features of the service than to limit yourself to a least common denominator between all competing services.
Wow, this is fascinating stuff. Just a side question (and please understand I am not a low-level hardware expert, so pardon me if this is a stupid question): does this arch support any sort of speculative execution, and if so do you have any sort of concerns and/or protections in place against the sort of vulnerabilities that seem to come inherent with that?
Right now, PyXL runs fully in-order with no speculative execution.
This is intentional for a couple of reasons:
First, determinism is really important for real-time and embedded systems — avoiding speculative behavior makes timing predictable and eliminates a whole class of side-channel vulnerabilities.
Second, PyXL is still at an early stage — the focus right now is on building a clean, efficient architecture that makes sense structurally, without adding complex optimizations like speculation just for the sake of performance.
In the future, if there's a clear real-world need, limited forms of prediction could be considered — but always very carefully to avoid breaking predictability or simplicity.
You're bringing back memories. I ran WindowMaker on my Sun desktop (Solaris 2.6, I think?), back in the late 90's. I spent days customizing that system, compiling everything from source.
reply