LedgeDrop

@LedgeDrop@lemm.ee

This is a remote user, information on this page may be incomplete. View at Source ↗

⁨Comment⁩ on ⁨Internet forums are disappearing because now everything is Reddit and Discord. And that's worrying.⁩ ⁨⁨2⁩ ⁨weeks⁩ ago⁩:
Yeah, bring back Usenet! (rabble, rabble, rabble) /s
⁨Comment⁩ on ⁨Microsoft Outlook servers down, reports say⁩ ⁨⁨5⁩ ⁨weeks⁩ ago⁩:

I just laughed and said oh well that’s what you get when you moved from on prem to cloud.

Our Techs said that you couldn’t buy on-perm exchange anymore. You needed to go with the cloud subscription, which “includes” all the crap you don’t want: like Teams.

Atleast, they said didn’t make financial sense to pay for Google Workspace + Slack + Cloud Exchange, when MS offered their (lesser) services as a bundle (but the human suffering is real) :(
⁨Comment⁩ on ⁨Linux royalty backs adoption of Rust for kernel code⁩ ⁨⁨1⁩ ⁨month⁩ ago⁩:
What?!? Actually, read the article? What is this, Reddit? /s

Seriously, though - let me spin the question around: what, in your mind, overlaps with what Greg said?

(plus, OP was just interested in people opinions - not whether they align/contradict with Greg, Linus, etc)
⁨Comment⁩ on ⁨Linux royalty backs adoption of Rust for kernel code⁩ ⁨⁨1⁩ ⁨month⁩ ago⁩:
Oh absolutely, but you could argue the same for learning lisp or mastering any functional programming language (list comprehensions, etc). It will improve your design patterns when you go back to an object oriented language with some elements of functional programming.
⁨Comment⁩ on ⁨Linux royalty backs adoption of Rust for kernel code⁩ ⁨⁨1⁩ ⁨month⁩ ago⁩:
In my mind, introducing Rust would only make sense if:
1. There was a serious lack of current kernel developers (which I don’t think there is)
2. New hardware and tech was evolving at a rate that the Linux Kernel could not keep up (again, I don’t think this is am issue)
3. The end goal is to migrate the entire Kernel to Rust.
Regarding point 3, having both C and Rust really only makes sense as a transition phase (measured in years) - as it would require kernel developers to be savvy in both C and Rust, or would force developers to stay within whatever domains were implemented in C or Rust.
⁨Comment⁩ on ⁨LemmyLink - A Reddit to Lemmy Bridge Bot⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:
How about have the bot detect community posts and try to funnel the conversations into one post.

I fear, this “to be created” “sync feature” is going to create a lot of noise.
⁨Comment⁩ on ⁨Let's Encrypt Ending Support for Expiration Notification Emails⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:
It’s more than needing a reminder: Let’s Encrypt Certs are valid for a maximum of 90 days before they need to be reissued. Doing this 4 times (or more) a year, for years on end will be tedious and error prone.

Most tools that request and install Let’s Encrypt Certs automatically do this without the need for human interaction (30 days prior to the expiration) . Actually, they work so well you don’t notice the “behind the scenes work” that’s happening.

The problem is when this renewal process “stop working”. I’d been using Let’s Encrypt for years w/o problems, but eventually the client I was using wasn’t updating and it was using a deprecated Let’s Encrypt API. Ultimately, the cert stopped updating, but I got the email reminder from Let’s Encrypt and I was able to fix it w/o a disruption.

Now, this was just a server for personal use. So if the SSL cert expired, it would not be the end of the world. Plus, I would have gotten a bunch of SSL errors the next time my client was trying to sync data, and I probably would have dropped everything to fix it. But the email reminder was a convenient feature, which allowed me to fix it whenever I had time.

That said, if Let’s Encrypt wants to save some money for their free service, I’m certainly not going to complain (although I will miss it).
⁨Comment⁩ on ⁨Making a Blocklist to Remove Spam from Search Engines⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:
Fantastic! Thank you for sharing this.

I have it installed, I’m curious how effective it will be.

Lately, I’ve been reporting AI generated cruft as “spam” to duckduckgo. In fact, it’s not really spam - as there are some nuggets of useful information, but so sparse, I’d rather of skipped the article/website entirely. I hope these kind of Blocklists will evolve to include this kind of quasi-spam.
⁨Comment⁩ on ⁨Half-Life 2 is currently 100% off for its 20th anniversary, plus a major update⁩ ⁨⁨4⁩ ⁨months⁩ ago⁩:
There’s also the “Unofficial Half Life 2 VR - unleashed”, which looks really exciting (I haven’t tried it yet).
⁨Comment⁩ on ⁨Broken thumbnails in lemm.ee?⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
I think it’s related to this issue (re: lemm.ee is fetching and caching images (to improve performance) , but often get is throttled (because the Lemmy’s cache implementation was not designed to work with larger Lemmy instances ), which results users seeing broken images).
⁨Comment⁩ on ⁨Google Will Pause Ads Related To Elections After Polls Close On November 5th.⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
Facebook, now it’s your turn…
⁨Comment⁩ on ⁨Concerns Raised Over Bitwarden Moving Further Away From Open-Source⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
It’s the “stringing it all together” that could be problematic.

If you have multiple clients (desktop/cellphone) modifying the same entry (or even different entries in the same “database” ). You need something smart enough to gracefully handle this or atleast tell you about it.

I did the whole “syncing” KeePass and it was functional, but it also meant I needed to handle conflicts - which was annoying. I switched and really appreciate the whole “it just works” with self-hosted bitwarden.
⁨Comment⁩ on ⁨Seeking feedback: how should lemm.ee move forward with external images? (related to frequent broken images)⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
It’s sad, but I think you’re right.

I assumed/hoped that Lemmy’s architecture was more decoupled.

According to the ChangeLog, it hints that the image reverse proxy is built-in, maybe using Pict-rs.

Which certainly reeks of Not Invented Here Syndrome, as image uploading/storing, reverse proxies, and caching is a well understood problem.
⁨Comment⁩ on ⁨Seeking feedback: how should lemm.ee move forward with external images? (related to frequent broken images)⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:
Wow, thanks for the full transparency. You are awesome!

My opinion would be option 2 (proxy requests) , but with a higher cache TTL or simple a LRU (Least Recently Used) Cache.

If you’re getting throttled, it could be mitigated by increasing the cache retention period (or improving the cache hits).

Another improvement : Would it be possible to change the proxy, so that if the proxied requests are throttled, it simply sends the user a http-302 to the origin (instead of a broken image)?

Regarding option 1 (full cache) : I greatly appreciate your desire to hide/protect your users ip, but it is outside the scope of what I expect from a Lemmy server. Maybe you could market and upsell this increased privacy as a subscription based feature. However, if I want privacy - I’ll use a VPN.

Regarding option 3 (User fetches content from origin) : From a users perspective, I really don’t want my Lemmy experience to be based on hitting a bunch of (potentially) unreliable services. When I, as a lemm.ee User, request a post from Lemmy.world (for example), lemm.ee will proxy and cache that post and the comments. This is the distributed nature of Lemmy (as far as I understand). Why restrict this caching to just posts/threads/comments and not include images (which, let’s face it, are as meaningful as pure text - especially wrt memes).