dpc_01234 (u/dpc_01234)

dpc_01234 commented on European Commission Trials Matrix to Replace Teams euractiv.com/news/commiss... · Posted by u/Arathorn

JuniperMesos · 3 days ago

The experience of using Matrix involves a lot of sluggishness at various points in the client - waiting to decrypt messages or properly sync keys, waiting to join a room or for room search to load - these are the things that have been salient to me using multiple matrix clients with a freshly-spun-up server within the past month.

dpc_01234 · 2 days ago

I more mindfully played a bit with my Element (web UI), and Element X (Android), and while there might something to it, and I suspect the e2e encrypted data model will always lead to some extra work required. Element seems a bit sluggish. However Element X on my Android seems butter smooth.

And event the slower Element seems far better than Discord that I'm forced to use, where I can't even scroll history without the whole thing stuttering.

dpc_01234 commented on European Commission Trials Matrix to Replace Teams euractiv.com/news/commiss... · Posted by u/Arathorn

pm3003 · 3 days ago

Federation can feel like "just a feature" but the E2E encryption (also in group chats) is a reason for Matrix to exist and a big reason why it's so slow.

dpc_01234 · 3 days ago

"Slow" in what sense? Development? Because I self host a Conduit server and I don't ever notice messages being slow. It would be hard to notice anyway, as in a group chat people usually take some time to type in their responses.

The sync between large groups used to be slow because of amount of data, but Element X and "sliding windows" were rolled out to help with it.

AFAIK, the public Matrix server used to be slow because of a heavy load (I think), but on my self-hosted instance that's not a problem at all.

dpc_01234 commented on European Commission Trials Matrix to Replace Teams euractiv.com/news/commiss... · Posted by u/Arathorn

Ylpertnodi · 3 days ago

Genuinely surprised at this - I've never heard of signal desktop not being fast, or good. Works a1 for me.

dpc_01234 · 3 days ago

Signal Desktop is having its db corrupted every other time I launch it, and wants me to reconnect to the phone. The UX is OKish.

dpc_01234 commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust github.com/j178/prek... · Posted by u/fortuitous-frog

paulsmith · 5 days ago

I like this approach. Something related I've been tinkering with are "protected bookmarks" - you declare what bookmarks (main, etc) are protected in your config.toml and the normal `jj bookmark` commands that change the bookmark pointer will fail, unless you pass a flag. So in your local "CI" script you can do `jj bookmark set main -r@ --allow-protected` iff the tests/lints pass. Pairs well with workspaces and something that runs a local CI (like a watcher/other automated process).

I haven't yet submitted it to upstream for design discussion, but I pushed up my branch[1]. You can also declare a revset that the target revision must match, for extra belts and suspenders (eg., '~conflicts()')

[1] https://github.com/paulsmith/jj/tree/protected-bookmarks

dpc_01234 · 5 days ago

Cool! That would pair well with SelfCI's MQ daemon, preventing accidentally forgetting about merging in stuff without running the local CI.

dpc_01234 commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust github.com/j178/prek... · Posted by u/fortuitous-frog

paddy_m · 5 days ago

That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type.

Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was pointed at, if tests start passing, you probably never need to revisit the failure.

I want to know about local test failures before I push to remote with full CI.

automatic branching and workflow stuff is optional. the core idea is great.

dpc_01234 · 5 days ago

> automatic branching and workflow stuff is optional. the core idea is great.

I'm not sure if I fully understood. But SelfCI's Merge-Queue (mq) daemon has a built-in hook system, so it's possible to do custom stuff at certain points. So probably you should be able to implement it already, or it might require couple of minor tweaks (should be easy to do on SelfCI side after some discussion).

dpc_01234 commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust github.com/j178/prek... · Posted by u/fortuitous-frog

digdugdirk · 5 days ago

That looks really cool! I've been looking for a more thought-out approach to hooks on JJ, I'll dig into this. Do you have any other higher level architecture/overview documentation other than what is in that repo? It has a sense of "you should already know what this does" from the documentation as is.

Also, how do you like Radicle?

dpc_01234 · 5 days ago

> Do you have any other higher level architecture/overview documentation other than what is in that repo?

SelfCI is _very_ minimal by design. There isn't really all that much to document other than what is described in the README.

> Also, how do you like Radicle?

I enjoy that it's p2p, and it works for me in this respect. Personally I disagree with it attempt to duplicate other features of GitHub-like forge, instead of the original collaborate model of Linux kernel that git was built for. I think it should try to replicate something more like SourceHut, mailinglist thread, communication that includes patches, etc. But I did not really _collaborated_ much using Radicle yet, I just push and pull stuff from it and it works for that just fine.

dpc_01234 commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust github.com/j178/prek... · Posted by u/fortuitous-frog

dpc_01234 · 5 days ago

BTW. Pre-commit hooks are the wrong way to go about this stuff.

I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do anything special.

I have something a bit like that implemented in SelfCI (a minimalistic local-first Unix-philosophy-abiding CI) https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX... and it replaced my use of pre-commit hooks entirely. And users already told me that it does feel like commit hooks done right.

dpc_01234 commented on Apple to soon take up to 30% cut from all Patreon creators in iOS app macrumors.com/2026/01/28/... · Posted by u/pier25

dpc_01234 · 10 days ago

Should be 50% at least.

dpc_01234 commented on Apple to soon take up to 30% cut from all Patreon creators in iOS app macrumors.com/2026/01/28/... · Posted by u/pier25

dymk · 11 days ago

Victim blaming

dpc_01234 · 10 days ago

Oh, now ios users are an oppressed group. How cute.

dpc_01234 commented on Common misunderstandings about large software companies philipotoole.com/common-m... · Posted by u/otoolep

dpc_01234 · 21 days ago

I don't get it. Article titled "Common misunderstanding". OK. “There are too many meetings”. How is this a misunderstanding? "...bunch of excuses confirming there are too many meetings...". Yyy... so it's not a misunderstanding?