It was signal desktop though cubeb-rs causing a startup crash that was my last straw. Bug reports were field, Miriam was very helpful.

<quote>before you know it the dependencies are so intertwined with this exclusive functionality that the downstream project can no longer support any other init system.</quote>

This is precisely what has happened with pulse audio. Sure ALSA is still around but good luck finding any project that will support it. I tried to hold out on apluse but it it just isn't feasible anymore. I suspect I will be forced into systemd at some point, but for now, openrc and friends are holding strong.

100% this. Wayland is a half baked solution to a problem no one had. Sure, X11 is old and has a lot of issues, but I don't think Wayland even thought about how it was going to succeed in its place. Instead they have fragmented the *nix desktop by forcing everyone to implement their own compositor. Basic functionality like mouse sensitivity and scaling aren't even on the roadmap and god forbid you need any accessibility features. Now the half bakers over at KDE are going to force us into this mess just like they did with Plasma 4.

Unfortunately, it's moving to TypeScript. As someone who has been a PHP engineer for 20 years, PHP outside of WordPress and a handful for Laravel shops is all but dead.

> Since 1999, I've written a huge amount of PHP code, for dozens of applications and websites. Most of it has been continually updated, and remains active and in-production, in one form or another... Is there any benefit to migrating this codebase to a more modern PHP framework, like Laravel?

Are these applications and websites maintained by anyone other than you? There is a lot of talk in the comments of just leaving it as is, and I would agree if these are relatively simple projects that doesn't need to be maintained by anyone than you. As soon as you introduce teams of people that need to generate new features for a business, this idea of building it from the ground up fails pretty quickly. You will never be able to provide the same level of flexible and robust solutions a framework can, nor will you be able to match the time take to develop a new feature because you cannot leverage any off the shelf solutions. The people that are tasked with maintaining your home built app/website are going to spend a lot of time just keeping all the duct tape and bailing wire from collapsing. I know because I've been doing just that for about half of my 25 year career.

> And is there an easy and minimally intrusive way this can be done en-masse, across dozens of applications and websites?

Not really, no. If your home grown solution just intertwines PHP with HTML like its 1999, then you're only path forward is to start porting all of it. If you have some semblance of routing and data / view separation, you can usually bootstrap the legacy app with the framework and slowly migrate the parts you need to actively touch into the new structure and gradually get to a cut-over point.

> Or at this point should I just stick with vi?

This is personal preference, but I find professional tools produce professional results. You are just not going to get the level of static analysis and debugger support from vi. JetBrains PhpStorm is pretty good but it costs a fair bit.

I wonder if these are the requirements with x64 included. I noticed that when I recompiled for amd64 on gentoo that my memory usage increased dramatically and under heavy load (Java) 1 gb was barely cutting it.