Because the lowest common denominator is much MUCH lower than you think it is.

This means it’s easy to indoctrinate and easy to maintain that for a massive number of people.

Scientific illiteracy is extremely high, and actual “6th grade reading comprehension” is the highest level of literacy for > 50% of a country like the U.S. and ~20% are low literacy or actually illiterate.

This means that half of everyone in the U.S. can read and understand what they read at or below a 6th grade level. This isn’t “reading big words”, it’s “tell us about what you read”, “what is the relationship between x & y” type questions.

This comment for example, up to this point only, would be difficult to understand & comprehend for > 50% of people in the U.S. (it demands an 11th grade reading comprehension). And may be misread, misunderstood, or not understood at all.

People are driven to religions to cults and alt conspiracy theories when they don’t understand how the world works around them. They latch onto extremely simple often misleading or incorrect ideas of how the world works because they can understand it and it “makes sense” within their sphere of ignorance (we all have one, this isn’t meant to be a disparaging term).

This means that the problem is that humans are just not smart enough to escape religion yet. It’s the simplest answer, and it appears to be correct.

I don’t think the concern over pinging 1.1.1.1 is warranted.

ICMP is pretty raw Network traffic, meaning you’re not really causing much actual load here.

You can’t even really try to DDOS with normal ICMP packets. You usually have have to max it’s size out at 64KB with an ICMP floor to even think of having an effect. Vs the, effectively inconsequential, 32 bytes of a normal ICMP packet.

You watching a short YouTube video is equivalent Network load as 180 days of pinging for Network up time.

The language it’s written in has very little, almost nothing, to do with how efficient larger applications are.

This is almost entirely up to the design and day-to-day decisions of the developers. These almost always outweigh the efficiencies of the underlying languages themselves (within reason).

A single location of poor data access patterns could negate the aggregate performance gains of your entire application, as an example. A framework that prevents you from making simple mistakes and drives you towards more efficient patterns goes much further than the language is written in.

Between Rust, C#, Java, and Go you’re essentially even on performance for large applications (with C# pushing ahead of the pack). What you are not even on is engineering efficiency, it’s going to take considerably longer to build the same set of features in rust than any of the others listed. And the performance is likely the same, potentially even worse depending on the maturity of the ecosystem.

Rust is a great systems design language and a great language to choose when developing high efficiency libraries & frameworks for I/O and data processing. It’s not really a great choice for application development due to how slow it is to actually get things done in.

I fully expect to see alternate backends written in more operationally efficient languages over the next decade that will catch up to the official Lemmy codebase, and potentially even replace it. It actually sounds like a super fun project, funding is always a problem though.

They keep giving us more reasons to sail the high seas.

This is what LGPL is for.

You can still use a library like a library freely, without restriction, but you are keeping your IP protected from being copied cloned and modified elsewhere.

I’m going to guess because of the tools that don’t use LGPL.

Which makes them quite limiting and kind of controversial since you have to adopt their license from my understanding, even if used as a library.

I try and use LGPL on all my projects since it allows others to use the Library as a library, and anyone that wants to modify or use the source has to copy left.

Naw, they’ll find some way to “incentivize” (punish you for not) viewing ads and enforce it with eye tracking.

Super glue seems appropriate 🤔

“unfortunately your In-Flight Engagement Actions ™️ did not meet the requirements to qualify you for in flight perks such as entertainment and meals”

“Please ensure you are looking directly at the screen while ads are playing to accumulate In-Flight Engagement Actions ™️”

Coming soon to an airline near you.

Ok…

So your point is that a bad logging implementation is bad. And I agree.

I’m not seeing how that’s extendable to implementations as a whole. You’re conflating your bad experience with "log aggregation is bad’.

Just because your company sucks at this doesn’t mean everyone else’s does.

Yeah, ofc it is.

I’m working in a system that generates 750 MILLION non-debug log messages a day (And this isn’t even as many as others).

Good luck grepping that, or making heads or tails of what you need.

We put a lot of work into making the process of digging through logs easier. The absolute minimum we can do it dump it into elastic so it’s available in Kibana.

Similarly, in a K8 env you need to get logs off of your pods, ASAP, because pods are transient, disposable. There is no guarantee that a particular pod will live long enough to have introspectable logs on that particular instance (of course there is some log aggregation available in your environment that you could grep. But they actually usefulness of it is questionable especially if you don’t know what you need to grep for).

These are dozens, hundreds, more problems that crop up as you scale the number of systems and people working on those systems.

Oof, this is definitely a:

Every lie incurs a debt to the truth

Sort of thing. It’s not going to be fun when your child understands that there is no school on weekends, you’ll lose a lot of trust overnight with this.

Ah, the circle of life

They usually do yes however it’s all about prioritization.

You may have hundreds or thousands or open requests and issues.

With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.

There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.

I thought I explained that pretty well no?

If you had a grain of rice that tasted unimaginably, unmitigably, good. The highest quality grain of rice ever seen in the world, in all of history.

It will not change the flavor of 30k bowls of rice.

We’re talking an absolutely tiny amount of users here. And we shouldn’t delude ourselves over it, circle jerking for being the “higher society”. Reddit didn’t change because we left, the number of users on Reddit change more on a daily basis than 5 Lemmy’s.

That said, the smaller niche subs definitely saw some hits. I won’t deny that. However, by definition, a small number of users leaving from small subs isn’t a “gotcha” moment for what I’ve stated. That’s is, almost by definition, what would be expected.

The discussions here are of higher quality for sure. But you’ll still notice that in many threads it’s almost indistinguishable from Reddit in many ways.

I last did this math a while back so let me redo it.

Lemmy != The fediverse. Lemmy is fairly small with 45k monthly active users. https://fedidb.org/software/lemmy

Reddit has 430 million monthly active users (70m daily) according to their disclosures for IPO.

So a 0.000104 multiple. Or 0.01% a little less than 2x my previous calculation. So, still a tiny number.

I think you’re grossly overestimating

Lemmy shaved off 0.0057% of reddit users. An actual inconsequential number.

This would be like you losing a grand total of 1 grain of rice, from ~35,000 rice bowls.

Even if that was the best tasting grain of rice of the whole bunch, you wouldn’t notice.

Not trying to start an argument here but I do want to point out that your argument foundations on blaming other competitors instead of looking at what can make the platform you’re passionate about more palatable.

There are many, MANY, reasons people will choose Mac and windows on their own accord.

Your argument hand waves that away to make a boogieman out of mac and windows, and erodes the true viability of Linux as a platform by not looking at how it can improve, and instead focusing on how the competition “is bad”.

Taking the ego stance that Linux “would be great if it wasn’t being held back by the bad guys” doesn’t actually help Linux desktop adoption…

It turns into a Linux problem when it holds back Linux desktop adoption by creating a difficult or even toxic environment for new, low-technical or non-technical users.

I mean if you’ve never seen or used a car before, and someone from a position of relative authority or trust gave you a very convincing argument that a particular part that you don’t understand is easy to remove and you’ll benefit from it…

Yeah it’s pretty reasonable that the average person might shoot themselves in the foot by letting them remove that part (tell them a command to run).