The point is evaluating your stack once in a while. Eventually, you may need to switch or it may be worthwhile, even if you can stick with your current stack at a disadvantage.

For an extreme example, WordPress with crap page builders. It may not have been “that bad” when you started with it. But by now its very much worthwhile to switch. You don’t “need to”, but you should.

Back to this post, maybe they really are at that point that slowly switching is worthwhile. At least partially, where it makes the most sense (they mention using some microservices written in Go).

Personally I doubt I’ll ever reach the switching point. But the trend for PHP devs seems to be switching to Go (when they do switch).

I don’t have a favourite new feature, but I’m just learning about the Compound constraint which I’ll definitely put to use in the near future.

I do have a favourite deprecation, of Removing the Default Garbage Collector Probability option. I’ve had weird and spaced out crashes when developing before I knew about this. Apparently this is to remove stale sessions once in a while. According to this comment, Debian based distros already handle it cleanly with a cron job, so I just unset that Symfony setting

As long as optional parameters are placed last, I don’t see why not.

PHP8’s named parameters lessen the pain of using a function with optional parameters spread around, but I still stick to that rule.

This one in South Korea is pretty recent (October 2022).

A special police team conducted an investigation of the disaster within a few days of it occurring, and concluded on 13 January 2023 that the police and governments’ failure to adequately prepare for the crowds, despite a number of ignored warnings, was the cause of the incident.

Ok, I understand what you meant, thanks.

Basically, after I’ve read all of that, it’s clear as day that security is not a priority on Testing. And while band-aid solutions do exist, it’s simply not designed to be secure.

Yeah, I wouldn’t run it in a production environment.

Sure, but even in those “few cases” Testing will get them soon.

I did read at some point that Testing may receive security updates later than stable, might be in those cases in which backports come straight from unstable.

I don’t recommend going for (Debian’s/Devuan’s) testing (branch) as it targets a peculiar niche that I fail to understand; e.g. it doesn’t receive the security backports like Stable does nor does it receive them as soon as Unstable/Sid does. Unstable/Sid could work, but I would definitely setup (GRUB-)Btrfs + Timeshift/Snapper to retain my sanity.

From https://backports.debian.org/ :

Backports are packages taken from the next Debian release (called “testing”), adjusted and recompiled for usage on Debian stable

So by definition, security backports in stable are present in Testing in the form of regular packages, right?

I remember having some issue like that, but I’m not sure if this was the fix.

Try unchecking “Show desktop notifications when the song changes” on Spotify’s settings (right now it’s under the Display section).

Makes sense, thanks.

New to Linux: in which case would you stick with an “old-old-stable” release?

Software incompatibility?

At first glance the difference in width comes from the front wings, which protruded beyond the wheels in the '22 cars.

So hopefully the wings last longer in wheel to wheel action.

restricting the total amount used and basically anything else makes more sense

Oh you meant eliminate the flow limit, I thought you meant eliminate the fuel itself. And I agree (with the caveat you said, also limiting the total amount).

That won’t happen for 15 years at least, only Formula E can be fully electric.

With an FIA exclusivity deal through 2039 to be the sole EV single-seat series on the FIA menu, Formula E has plenty of time to grow.

https://www.autoweek.com/racing/more-racing/a44319865/formula-e-ceo-jeff-dodds-sees-sustainable-future-for-electric-racing-series/

I particularly like the new Mapped Route Parameters.

❌ /show/{id}/

✔ /show/{id:document}/

For multiple entities, it’s cleaner and more beginner-friendly than using the #[MapEntity] attribute (which is still an option).

And imo it’s a good move to deprecate “not passing the mapping” even for single entities. With the mapping the behaviour is more intuitive and “feels” less magic.

That’s a valid opinion. And I admit that at some point you must move to some form of client-side rendering.

I still haven’t (for some admin panels too, and websites), so I don’t feel the need to switch.

Aren’t you only saying, indirectly, that server-side rendering is “antiquated”?

Unless you mean that mixing logic with templates is bad, in which case I agree.

Funny story. 50 years ago, to this very day, a revolution occurred in which Portugal took down its dictatorship.

The following day some public administrator/manager sent a letter complaining about people missing work!

Translation after the letter

Your Excellency Director General

I inform Your Excellency that yesterday, April 25, 1974, several employees were absent from work, claiming that a revolution had occurred in the country.

I clarify that this revolution was not authorized by superiors, and no justification was seen for the absences, especially as the service was considerably delayed.

As the current legislation does not provide for absences due to the occurrence of revolutions, I submit the matter to your high discretion, in the certainty that it will deserve due attention.

The band played 2 early albums + their latest one in sequence. Listening to whole albums in one go was great for many reasons.

Fellow PT-PT ISO user here. And although I use PT-PT in the OS, both my mechanical keyboards’ physical layout is DE ISO, which has most special symbols in the same place. (finding DE keyboards is easier)

I’ve considered switching to UK ISO before. Typing brackets “[] {}” and a semicolon “;” is harder in PT-PT. Especially the curly brackets {}, which are really awkward to type with my small hands.