using different implementation of a major subsystem (eg a whole kernel in this case) – is an excellent way to check/test your implementation and design assumptions about separation of concerns/adherence to API standards and so on.
Certainly good demonstration of SerenityOS ‘separation of concerns’ decisions through out the architecture.
In the past, I often used different compilers (for same language), different OS (for same POSIX APIs) , different SQL engines, to run our solutions on – not because those need to be supported for production releases.
But because these ‘substitutes’ helped us to confirm that we use standards, that we implemented ‘separation-of-concerns’ well, and … it also gave us some confidence that we would not get into a ‘vendor lockup’ situation.
Supporting multiple SQL engine vendors, was probably the most time consuming (due to stored procs languages and so on), but it helped us to create meaningful wrappers around vendor specific functionality, that helped us later on in various maintenance/support activities (eg migrations to newer versions of same SQL vendor engine, supporting different SQL engine, performance tuning and so on).
using different implementation of a major subsystem (eg a whole kernel in this case) – is an excellent way to check/test your implementation and design assumptions about separation of concerns/adherence to API standards and so on.
Certainly good demonstration of SerenityOS ‘separation of concerns’ decisions through out the architecture.
In the past, I often used different compilers (for same language), different OS (for same POSIX APIs) , different SQL engines, to run our solutions on – not because those need to be supported for production releases.
But because these ‘substitutes’ helped us to confirm that we use standards, that we implemented ‘separation-of-concerns’ well, and … it also gave us some confidence that we would not get into a ‘vendor lockup’ situation.
Supporting multiple SQL engine vendors, was probably the most time consuming (due to stored procs languages and so on), but it helped us to create meaningful wrappers around vendor specific functionality, that helped us later on in various maintenance/support activities (eg migrations to newer versions of same SQL vendor engine, supporting different SQL engine, performance tuning and so on).
That’s really cool. Next step: someone get Sway/wlroots running on the Serenity kernel!
Sort of “official” response from Andreas Kling on that. Worth listening (YT “vlog”, but video is just him driving the car).
Is this running on top of X?
SerenityOS has its own compositing window server.
https://github.com/SerenityOS/serenity/tree/master/Servers/WindowServer
The replies mention running efifb, so I guess not (?)
Yeah confirmed. He is making direct calls to the frambuffer:
https://github.com/jcs/serenity/blob/hosted/Libraries/LibSerenity/fb.cpp
88