As a SUSE employee myself, I want to add that it is also part of our company culture for employees to contribute code upstream whenever possible. That's how many of my own Open Source contributions happened in the past few years. Most recently building an MCP Perl SDK (https://github.com/mojolicious/mojo-mcp). SUSE is giving a lot more than just money to the Perl community.
The Minion job queue is another implementation of this idea. But using the even more efficient and safe FOR UPDATE SKIP LOCKED. https://github.com/mojolicious/minion
I've not really thought about that before, but looking through the commit history it actually seems very likely that we were the first. Back then the WebSocket protocol looked very different from today. https://github.com/mojolicious/mojo/commit/a1a7060e35a6a0965...
That was the first public release. There used to be a History.md file in the repo with the January date. There was a lot of experimentation even before that - browsers started adding experimental WS support on the second half of 2009, right as node was gearing up. Some artifacts from that era:
Another thing to keep in mind is that the precursor SSJS environments like Jack/Narwhal, Helma etc probably added it even earlier. Hard to tell since GitHub itself was new and many of these sources are hard to find today.
Thank you. I've been very fortunate to have found an employer that enables me to keep contributing to open source projects this actively. So SUSE also deserves a big thank you for making Mojolicious 8.0 possible! :)
Yes, Cpanel::JSON::XS can be configured to be closer to the original Mojo::JSON behaviour. And the maintainer has historically been more cooperative with efforts to make Perl JSON modules compatible with each other.
>And the maintainer has historically been more cooperative with efforts to make Perl JSON modules compatible with each other.
Indeed, MLEHMANN's (JSON::XS maintainer) difficult personality was one of the main reasons why Cpanel::JSON::XS was created and why it has gained so much popularity despite being almost identical functionally.
I would rather point out that JSON::XS simply refused to fix its most important bugs, and rather blamed upstream. I simply fixed those bugs and kept maintaining it. I also added many new features, just streaming support not yet.
The name is a bit unfortunate though as Cpanel itself still refuses to use it for political reasons. There is a high-profile jerk there running an agenda for his own personal profit.
So I rather want to persuade Lehmann to give me his namespace and continue with it under the original name.
* Transactional updates. No interference with the deployments. You can rollback to any previous state.
* Smart separation of /, /etc and /var, using volumes and overlays properly.
* Using RPMs! I can tailor my installation with traditional RPMs, and the result will be updated at once.
* Zero maintenance. This is kind of magic for me, you create the initial deploy and the system upgrade itself, and rollback if a problem is detected. I wonder how well this works IRL
On the downside is still a bit new, but I found more information here [1]
