Good question!

IMO a good way to help a FOSS maintainer is to actually use the software (esp pre-release) and report bugs instead of working around them. Besides helping the project quality, I’d find it very heart-warming to receive feedback from users; it means people out there are actually not only using the software but care enough for it to take their time, report bugs and test patches.

“Announcment”

It used to be quite common on mailing lists to categorise/tag threads by using subject prefixes such as “ANN”, “HELP”, “BUG” and “RESOLVED”.

It’s just an old habit but I feel my messages/posts lack some clarity if I don’t do it 😅

Done ✅

Thanks for your interest 🙏

Please do drop a line in either !lemmy_meter@lemmy.ml or #lemmy-meter:matrix.org if you’ve got feedback/ideas for a better lemmy-meter. I’d love to hear them!

Oh and feel free to link back to lemmy-meter from Blåhaj if you’d like to, in case you’d prefer the community to know about it.

I didn’t like the capitalised names so configured xdg to use all lowercase letters. That’s why ~/opt fits in pretty nicely.

You’ve got a point re ~/.local/opt but I personally like the idea of having the important bits right in my home dir. Here’s my layout (which I’m quite used to now after all these years):

$ ls ~
bin  
desktop  
doc  
downloads  
mnt  
music  
opt 
pictures  
public  
src  
templates  
tmp  
videos  
workspace

where

• bin is just a bunch of symlinks to frequently used apps from opt
• src is where i keep clones of repos (but I don’t do work in src)
• workspace is a where I do my work on git worktrees (based off src)

Thanks! So much for my reading skills/attention span 😂

Which Debian version is it based on?

Something that I’ll definitely keep an eye on. Thanks for sharing!

RE Go: Others have already mentioned the right way, thought I’d personally prefer ~/opt/go over what was suggested.

RE Perl: To instruct Perl to install to another directory, for example to ~/opt/perl5, put the following lines somewhere in your bash init files.

export PERL5LIB="$HOME/opt/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"
export PERL_LOCAL_LIB_ROOT="$HOME/opt/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"
export PERL_MB_OPT="--install_base \"$HOME/opt/perl5\""
export PERL_MM_OPT="INSTALL_BASE=$HOME/opt/perl5"
export PATH="$HOME/opt/perl5/bin${PATH:+:${PATH}}"

Though you need to re-install the Perl packages you had previously installed.

This is fantastic! 👏

I use Perl one-liners for record and text processing a lot and this will be definitely something I will keep coming back to - I’ve already learned a trick from “Context Matching” (9) 🙂

That sounds a great starting point!

🗣Thinking out loud here…

Say, if a crate implements the AutomatedContentFlagger interface it would show up on the admin page as an “Automated Filter” and the admin could dis/enable it on demand. That way we can have more filters than CSAM using the same interface.

Update 1

Thanks all for your feedback 🙏 I think everybody made a valid point that the OOTB configuration of 33 requests/min was quite useless and we can do better than that.

I reconfigured timeouts and probes and tuned it down to 4 HTTP GET requests/minute out of the box - see the configuration for details.

🌐 A pre-release version is available at lemmy-meter.info.

For the moment, it only probes the test instances

• enterprise.lemmy.ml
• ds9.lemmy.ml
• voyager.lemmy.ml

I’d very much appreciate your further thoughts and feedback.

Agreed. It was a mix of too ambitious standards for up-to-date data and poor configuration on my side.

sane defaults and a timeout period

I agree. This makes more sense.

Your name will be associated with abuse forevermore.

I was going to ignore your reply as a 🧌 given it’s an opt-in service for HTTP monitoring. But then you had a good point on the next line!

Let’s use such important labels where they actually make sense 🙂

beyond acceptable use

Since literally every aspect of lemmy-meter is configurable per instance, I’m not worried about that 😎 The admins can tell me what’s the frequency/number they’re comfortable w/ and I can reconfigure the solution.

You can hit the endpoint /api/v3/site for information about an instance including the admins list.

Exactly what I was looking for. Thanks very much 🙏

Thanks for the link. Had no idea about that.

That was my case until I discovered that GNU tar has got a pretty decent online manual - it’s way better written than the manpage. I rarely forget the options nowadays even though I dont’ use tar that frequently.

This is quite intriguing. But DHH has left so many details out (at least in that post) as pointed out by @breadsmasher@lemmy.world - it makes it difficult to relate to.

On the other hand, like DHH said, one’s mileage may vary: it’s, in many ways, a case-by-case analysis that companies should do.

I know many businesses shrink the OPs team and hire less experienced OPs people to save $$$. But just to forward those saved $$$ to cloud providers. I can only assume DDH’s team is comprised of a bunch of experienced well-payed OPs people who can pull such feats off.

Nonetheless, looking forward to, hopefully, a follow up post that lays out some more details. Pray share if you come across it 🙏

TBH I use whatever build tool is the better fit for the job, be it Gradle, SBT or Rebar.

But for some (presumably subjective) reason, I like GNU Make quite a lot. And whenever I get the chance I use it - esp since it’s somehow ubiquitous nowadays w/ all the Linux containers/VMs everywhere and Homebrew on Mac machines.

Love the attitude 💪 Let me know if you need help in your quest.

I see.

So what do you think would help w/ this particular challenge? What kinds of tools/facilities would help counter that?

Off the top of my head, do you think

• The sign up process should be more rigorous?
• The first couple of posts/comments by new users should be verified by the mods?
• Mods should be notified of posts/comments w/ poor score?

cc @PrettyFlyForAFatGuy@lemmy.ml