By dropping SerenityOS as a target, Ladybird is free to make use of 3rd party libraries that don't currently work on SerenityOS. And keep in mind, SerenityOS would be unable to integrate Ladybird in this new state anyway, since SerenityOS has a strict "no 3rd party code" policy.
(Also nice: it stops being necessary to wait 30+ minutes for multiple CI runs on SerenityOS every time you post a browser engine pull request!)
In time, I'd love to see Ladybird come back as a port on SerenityOS.
Wondering about that too, but to be fair, he probably doesn't use it as his primary OS (none of the developers does I think), so with Serenty mostly being a development project and the interest shifting (back to) developing web browsers it seems logical to focus on these targets.
I've been working on projects myself where the primary target switched, because I noticed it's a bit draining to keep supporting something "just" because I love it. Dropping a target usually doesn't mean it cannot be used there anymore, but simply that you don't feel comfortable guaranteeing support.
I don't know if that's the case here, only that it doesn't necessitate bad feelings.
Given that it was also stated that it won't be self-contained anymore that's also a very good technical reason. And I totally get that if you want to create a new browser with a new layout engine not wanting to re-invent every audio, video, image decoder, not wanting to reinvent all the wheels makes it already a huge project and I'd assume it's hard to guarantee all of these things will also work and compile on Serenity, which despite doing an amazing job at porting might get stuck here and there. I mean, see the OpenBSD and Rust(up) story.
Possibly that for Ladybird to move forwards more quickly, it needs access to OS API's or Graphics stuff that Serenity can't yet provide? (I'm just spitballing here, I don't know much about OS development)
To take it a step further, due to the fact that Andreas is being sponsored to work on Ladybird full time by a few companies, if it's inherently also tied to the development of Serenity (since its a primary target) that might make him concerned that there's a clash of responsibilities there - he might not want any sponsors pulling out or arguing that he's spending their money on Serenity instead of Ladybird.
This is all just assumptions however, and regardless of the reasons I think he's doing the right thing.
There really isn't anything more to it. :)
By dropping SerenityOS as a target, Ladybird is free to make use of 3rd party libraries that don't currently work on SerenityOS. And keep in mind, SerenityOS would be unable to integrate Ladybird in this new state anyway, since SerenityOS has a strict "no 3rd party code" policy.
(Also nice: it stops being necessary to wait 30+ minutes for multiple CI runs on SerenityOS every time you post a browser engine pull request!)
In time, I'd love to see Ladybird come back as a port on SerenityOS.
It does have ports though, so for people who want ladybird there is a route to running it.
Is there something in the way of keeping 3rd party code optional in Ladybird?
Which libraries are you looking to adopt first? WebRTC? ANGLE?
Wondering about that too, but to be fair, he probably doesn't use it as his primary OS (none of the developers does I think), so with Serenty mostly being a development project and the interest shifting (back to) developing web browsers it seems logical to focus on these targets.
I've been working on projects myself where the primary target switched, because I noticed it's a bit draining to keep supporting something "just" because I love it. Dropping a target usually doesn't mean it cannot be used there anymore, but simply that you don't feel comfortable guaranteeing support.
I don't know if that's the case here, only that it doesn't necessitate bad feelings.
Given that it was also stated that it won't be self-contained anymore that's also a very good technical reason. And I totally get that if you want to create a new browser with a new layout engine not wanting to re-invent every audio, video, image decoder, not wanting to reinvent all the wheels makes it already a huge project and I'd assume it's hard to guarantee all of these things will also work and compile on Serenity, which despite doing an amazing job at porting might get stuck here and there. I mean, see the OpenBSD and Rust(up) story.
Unlike SerenityOS, Ladybird will have a relaxed NIH policy (instead of "no 3rd party code!")
This requires that it becomes a Port rather than a core part of Serenity.
Possibly that for Ladybird to move forwards more quickly, it needs access to OS API's or Graphics stuff that Serenity can't yet provide? (I'm just spitballing here, I don't know much about OS development)
To take it a step further, due to the fact that Andreas is being sponsored to work on Ladybird full time by a few companies, if it's inherently also tied to the development of Serenity (since its a primary target) that might make him concerned that there's a clash of responsibilities there - he might not want any sponsors pulling out or arguing that he's spending their money on Serenity instead of Ladybird.
This is all just assumptions however, and regardless of the reasons I think he's doing the right thing.