But… That would force them to provide a great user experience in order to retain users!! That’s an unacceptable burden on the largest companies in the world!!

Yeah. Honestly. For platforms like Instagram, Facebook, TikTok, mandate chronological feeds of only people you have followed, paginated at like 30.

I feel like one could legitimately run on this platform at this point.

They saved lifes.

Glad to have cleared that up for you 👍

It’s just a helper. It’s a way for your calendar to ask “uhhh… Should I already know of any calendars…?” and the service going “oh actually yeah, the user configured their email account, hold on, here’s the corresponding calendar”.

That’s just basic functionality. Maybe what’s tripping you up is that it’s a separate service? Because I assume you have nothing against inputting your email into a mail client and a calendar separately.

If so, then for one, it’s not really a difference if the mail app stores this into or the service does; and second, it’s a good thing to have this standardized into a single purpose built service, rather than having each app reimplement this stuff.

CPU and RAM usage is so negligible it’s laughable.

IDK.

It seems like you read something about personal data in the service description and just jumped to the conclusion that this is something nefarious.

How exactly is it bloatware though? Not a KDE user myself, just had a look at the wiki. Seems it’s just a convenience utility to allow you to not have to enter the same things into multiple applications?

This is VERY different from pre-installed apps in your start menu that collect and sell info about you…

Yeah, thinking more about it, I don’t think the term “bloatware” (as it is commonly used) applies here at all.

How do I completely disable it forever?

To answer your question: sudo systemctl mask <servicename>.service

The much more common disable just disables autostart; masking will point the service file at /dev/null, which makes it impossible to load or start the service, even when other services or apps (like the clock widget someone mentioned in the comments) request it.

This started off as a single file in my private nix config, to see if I could get it working at all. In that initial part, some parts were indeed LLM generated (esp. testcases based on my existing intents and failures).

When I noticed that this might actually work and be useful not just for myself though, I moved everything out manually, refactored and cleaned it up, and everything since has just been myself. I guess you’re still right though. I’ll see about adding a disclaimer to the README until I’ve gotten the chance to properly rewrite everything.

Huh, interesting. Does that work with wildcards like “put x on my shopping list”? Also, what are you using for that, if I may ask?

Sorry, I don’t quite follow 😅

What’s the problematic response?

Yay, that’s fantastic to hear!

Also, how’s your experience been with the PE? Getting a readymade device in a nice shell is appealing for sure 😅

Oh, in the demo gif, that’s via a shortcut (holding power for half a second). Sorry, can’t help with wakeword there 😅

Very cool. I’ll definitely look into that, and let you know back here :D

Glad to be of service… 😄

did you consider metaphone matching?

I did not even know about this. Sounds super interesting. Though it seems to be very language specific?

My original intent was to not rely on language specifics. But maybe we could just define additional steps in the pipeline for specific languages. Hm. I’ll have to think about this some more, but it might definitely be a great idea for a future version, so thanks for telling me about it!!

Have fun, hope this works out for you! FYI: you can also use an LLM as an additional fallback (first closest-intent, then on failure, LLM). README mentions it further down on Github.

Yeah. I think this is one of the best examples of letting nix do the hard stuff for you.

Neovim, configured entirely through nixvim. I always liked neovim, but it’s never been as incredibly stable as now with nixvim.

Main/only IDE both in private and at work. Can’t ever go back, muscle memory has ensured that.

I think the text is somewhat dubious in its arguments, but this (and the arguments built on this assertion) is just plain wrong:

[Signals servers have] a few important pieces of data;

Message dates and times Message senders and recipients (via phone number identifiers)

Signal clients implement the Pond protocol. As a result, Signals servers know who a message is for (obviously, how else do you get the message) but cannot know who it is FROM.

I’ve been playing around with implementing a secure/private messenger demo for myself, and have been consistently impressed with how privacy preserving Signal is when reading their papers and code. I wish it was selfhostable, but apart from that, it’s great.

The server would be NICE to be OSS, but ultimately, privacy breaches are prevented client/protocol side.

That ks for sharing this, this is fascinating.

Maybe the underlying rule is: the more you know about something, the more you are aware of its flaws, making the alternatives you know less about more attractive?

I don’t really know, sorry :(

If you want to migrate, is going conduit - conduwuit - continuwuity (first version) - continuwuity (current version) maybe an option?

I went with continuwuity and am happy with it. Development happens at a steady pace, with sane priorities. The server is stable and I haven’t had any issues to speak of, despite one minor bug that got resolved very quickly after creating an issue.