Olissipo

joined 1 year ago
[–] Olissipo 1 points 3 days ago

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).

[–] Olissipo 4 points 5 days ago (1 children)

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).

12
submitted 5 days ago* (last edited 4 days ago) by Olissipo to c/php
 

My TLDR is:

  • Their team was using PHP

  • Before doing a complete re-write they evaluated other languages

  • Rust ruled out due to cost/benefit, being the fastest in the list, but also the most complex

  • PHP kept as the main language because:

    • The ecosystem is mature
    • The PHP/Symfony (and Roadrunner) stack meets their high-performance needs
  • Inertia: their team "already had extensive experience" in it

  • They already integrated Go in some microservices

  • They aren't locked to PHP, and will continue to evaluate these programming languages and others

3
submitted 6 days ago* (last edited 4 days ago) by Olissipo to c/symfony
 

Twig 3.15 was released a few weeks ago and includes an impressive list of new features and improvements. This two-part blog post highlights the most important ones.

Edit: Part 2

[–] Olissipo 1 points 3 weeks ago

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

19
submitted 1 month ago by Olissipo to c/php
[–] Olissipo 2 points 2 months ago

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.

[–] Olissipo 6 points 2 months ago* (last edited 2 months ago)

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.

[–] Olissipo 3 points 5 months ago (1 children)

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.

[–] Olissipo 1 points 5 months ago (3 children)

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.

[–] Olissipo 1 points 5 months ago (5 children)

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?

[–] Olissipo 3 points 6 months ago* (last edited 6 months ago) (1 children)

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).

[–] Olissipo 2 points 6 months ago

Makes sense, thanks.

[–] Olissipo 5 points 6 months ago* (last edited 6 months ago) (6 children)

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

Software incompatibility?

54
submitted 6 months ago* (last edited 6 months ago) by Olissipo to c/linux
 

The Debian Long Term Support (LTS) Team hereby announces that Debian 10 "buster" support will reach its end-of-life on June 30, 2024, nearly five years after its initial release on July 6th, 2019.

Starting in July, Debian will not provide further security updates for Debian 10. A subset of "buster" packages will be supported by external parties. Detailed information can be found at Extended LTS.

The Debian LTS Team will prepare afterwards the transition to Debian 11 "bullseye", the current oldstable release. Thanks to the combined effort of different teams including the Security Team, the Release Team, and the LTS Team, the Debian 11 life cycle will also encompass five years. To make the life cycle of Debian releases easier to follow, the related Debian teams have agreed on the following schedule: three years of regular support plus two years of Long Term Support. The LTS Team will take over support from the Security and the Release Teams on August 14, 2024, three years after the initial release on August 14, 2021. The final point update release for "bullseye" will be published soon after the final Debian 11 Security Advisory (DSA) will be issued.

Debian 11 will receive Long Term Support until August 31, 2026. The supported architectures remain amd64, i386, arm64 and armhf.

[–] Olissipo 15 points 6 months ago* (last edited 6 months ago) (1 children)

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.

6
submitted 8 months ago* (last edited 8 months ago) by Olissipo to c/[email protected]
 

This might not be new, I hadn't dealt with WordPress/WooCommerce in a while.

Currently (v8.8.2) in a new WooCommerce installation the "Checkout" page is created using blocks, like so:

<!-- wp:woocommerce/checkout-payment-block -->
<div class="wp-block-woocommerce-checkout-payment-block"></div>
<!-- /wp:woocommerce/checkout-payment-block -->

(...)

The problem

This might introduce breaking changes to the plugins and themes you normally use. For example, I couldn't add a new field - programatically or using a plugin.

The fix

Remove the blocks and revert to using the shortcode:

[woocommerce_checkout]

view more: next ›