The resilience of Minnesotans is unmatched. Day and night, in snow and freezing cold, they keep showing up and standing their ground. That’s people power. That’s BlueCrew strength.💙
Drop a ✊💙 for the Minnesotans holding the line in the cold and refusing to be silenced.
#BlueCrew #ProudBlue #PeoplePower #JusticeForRenee #ICE #AbolishICE



A upřímně, všímám si, že nejhlučnější je TČ v teplotách okolo nuly, asi jak je "hustší" vzduk plný vody a ten to protlačuje lamelami a i ventilátor běhá na vyšší otáčky. Jakmile je mráz a klesne vlhkost, tak je to paradoxně daleko tišší, protože ventilátor sníží otáčky. Sice se více namáhá kompresor, ale ten je u dnešních TČ tak kvalitně hlukově zaizolován, že není skoro vůbec slyšet a to ani při 17 pod nulou.
feld
in reply to feld • • •lain
in reply to feld • • •feld
in reply to lain • • •@lain yes, this is where it unlocks so much potential. Like, I don't want to become an expert in Dtrace. I don't want to become an expert in Postgres stored procedures, or PL/pgSQL. It will take too long and I don't have a job that demands that I do it all day every day.
Life is too short to become such an expert in something that you can do by memory that you will rarely need to use anyway
NonPlayableClown
in reply to feld • • •> I don't want to become an expert in Postgres stored procedures, or PL/pgSQL.
I know a expert that works with postgres, what do you need to know for SPs?
feld
in reply to NonPlayableClown • • •@NonPlayableClown @lain it's more about knowing best practices so you don't kill your database with terrible inefficient procedures. SPs, triggers, etc. They can be immensely powerful tools that turns your database into an absolute powerhouse but also you can cause really stupid side effects
(see also: pleroma restoring from backup right now causes expensive triggers to execute on inserts)
:blank:
in reply to feld • • •feld
in reply to :blank: • • •@i @lain @NonPlayableClown this is very likely caused by non-deterministic collation on your Pleroma database
from the mouth God (Claude):
2. ORDER BY (The Key Issue):
This is where you'll see different results on repeated executions:
- When values are considered equal by the collation, PostgreSQL has no stable way to order them
- The sort order between "equal" values is undefined and unstable
- Multiple executions may return rows in different orders
- If you use LIMIT, you might get completely different result sets each time
feld
in reply to feld • • •Ludovic :Firefox: :FreeBSD:
in reply to feld • • •feld
in reply to Ludovic :Firefox: :FreeBSD: • • •@usul here you go. It works with both IPv4 and IPv6
dpaste.com/9VLZEXZ2E
feld
in reply to Ludovic :Firefox: :FreeBSD: • • •@usul example output of the script after letting it run for a minute. tail end of logs, and then the summary:
2026 Jan 18 10:20:30 20657 1001 UDP firefox 10.255.255.53:53
Command: /usr/local/lib/firefox/firefox --sm-client-id 101d024c23819c000176843403200000687830009
Local: 10.27.3.4:46950
2026 Jan 18 10:20:30 20657 1001 TCP firefox 15.204.35.21:443
Command: /usr/local/lib/firefox/firefox --sm-client-id 101d024c23819c000176843403200000687830009
Local: 10.27.3.4:26279
2026 Jan 18 10:20:30 20657 1001 UDP firefox 10.255.255.53:53
Command: /usr/local/lib/firefox/firefox --sm-client-id 101d024c23819c000176843403200000687830009
Local: 10.27.3.4:46653
^C
PID PROCESS UID PROTO COUNT
67162 unison 1001 UDP 3
95715 quasselclient 1001 TCP 8
20657 firefox 1001 UDP 12
21846 thunderbird 1001 TCP 15
2 clock 0 TCP 16
67162 unison 1001 TCP 27
20657 firefox 1001 TCP 261
0 kernel 0 TCP 4218