Password Compat VS fresh

> Same for WordPress.

Not as much - WP favours backwards compatibility (or is it laziness?) even when doing so impacts security.

Another problem is that the environments Wordpress targets are inherently vulnerable - while it's not WP's fault directly, they do nothing to warn people against using them nor outright stop supporting broken, insecure configurations.

> There are multitudes of comments that specifically single out WP in the post's comment thread. Including this very thread that you are on.

I was talking about publicized data breaches in general. But if we specifically talk about CMSes, I'm not sure anything else beats Wordpress and similar PHP-based CMSes of that era when it comes to not just the amount of vulnerabilities, but especially the nature of them - the same, dumb, basic problems resolved in every other language (including modern PHP with a framework such as Laravel) repeated over and over again.

> WHERE is that objective study that compares WordPress with other software in regard to vulnerabilities

Someone posted the following excerpt of the Wordpress codebase, which appears to be some custom attempt at simulating SQL query parameterization instead of using the actual, database-driver-provided function. If this is indeed the purpose of that function and it is indeed used, then I'm not sure there is any valid excuse for this in today's day and age.

Someone else mentioned password hashing still relying on MD5 - if that is actually true, I'm not sure that is excusable either? I haven't done PHP for many years now, but surely even if the native functions aren't available, couldn't they use a "polyfill" such as https://github.com/ircmaxell/password_compat ?

I'm sure there are many other issues but frankly the first one should be enough for any competent developer to run away.

> No it doesnt. Dont make up falsities. PHP executes files how you configure it to.

I was with you until this, but now I think you're arguing in bad faith.

Yes, if you want to be pedantic, PHP and your web server execute files like how you configure them to. In practice, the environment where the vast majority of Wordpress sites are deployed (your typical shared hosting environment) will execute anything that ends with .php and is in the web root.

This is inherently a legacy PHP problem (which WP encourages by supporting it) - no other language that I know of does this by default. If I accidentally store a malicious file in Python, Ruby, Node.js, etc applications, the worst that will happen is that I serve it back. At no point what so ever the server itself will execute that file.

Yet in the PHP environments Wordpress targets, this is a massive issue which means every single feature handling file uploads (both in WP core and any plugins) should anticipate your server's misconfiguration (maybe it's not limited to .php files, but .html files too?) and try to protect against it, eventually failing and then you get yet another Wordpress vulnerability.

Deno: Deno with one of it's frameworks (like Fresh

The road to Fresh 2.0 (https://github.com/denoland/fresh/issues/2363) by Marvin Hagemeister Can't wait for seeing the end of the road! All in all great changes ahead.

Because I have secret magical powers that you probably don't, it's basically free for me. Here's the breakdown though:

The application server uses Deno and Fresh (https://fresh.deno.dev) and requires a shared-1x CPU at 512 MB of ram. That's $3.19 per month as-is. It also uses 2GB of disk volume, which would cost $0.30 per month.

As far as post generation goes: when I first set it up it used GPT-3.5 Turbo to generate prose. That cost me rounding error per month (maybe like $0.05?). At some point I upgraded it to GPT-4 Turbo for free-because-I-got-OpenAI-credits-on-the-drama-day reasons. The prose level increase wasn't significant.

With the GPU it has now, a cold load of the model and prose generation run takes about 1.5 minutes. If I didn't have reasons to keep that machine pinned to a GPU (involving other ridiculous ventures), it would probably cost about 5 minutes per day (increased the time to make the math easier) of GPU time with a 40 GB volume (I now use Nous Hermes Mixtral at Q5_K_M precision, so about 32 GB of weights), so something like $6 per month for the volume and 2.5 hours of GPU time, or about $6.25 per month on an L40s.

In total it's probably something like $15.75 per month. That's a fair bit on paper, but I have certain arrangements that make it significantly less cheap for me. I could re-architect Arsène to not have to be online 24/7, but it's frankly not worth it when the big cost is the GPU time and weights volume. I don't know of a way to make that better without sacrificing model quality more than I have to.

For a shitpost though, I think it'd totally worth it to pay that much. It's kinda hilarious and I feel like it makes for a decent display of how bad things could get if we go full "AI replaces writers" like some people seem to want for some reason I can't even begin to understand.

I still think it's funny that I have to explicitly tell people to not take financial advice from it, because if I didn't then they will.

Deno has also created a Next.js competitor, Fresh. I found it a few weeks ago and am starting to go through the docs, looks like a good overall concept. https://fresh.deno.dev/

https://fresh.deno.dev/ - Fresh embraces the tried and true design of server side rendering and progressive enhancement on the client side.

Along the way, I not only got the oppurtunity to revise old concepts that had blurred in my memory, but also learnt about new technologies like Fresh.js, a framework from Deno (a js runtime engine) that uses Preact, a React Routing library and used Chakra UI for the first time.

A whole project might be released as a server or framework. Frameworks like fresh, and astro) both have had things deep within them that I've wanted to reuse, within fresh it's the esbuild configuration, and islands functionality, and within astro it's the rendering of astro files themselves.

The Fresh framework by Deno cited an improved developer experience due to tighter feedback loops.