stevecrox

Engineering is tradeoffs.

A command shell is focused on file operations and starting/stopping applications. So it makes it easy to do those things.

You can use scripting languages (e.g. Node.js/Python) to do everything bash does but they are for general purpose computing and so what and how you perform a task becomes more complicated.

This is why its important to know multiple languages, since each one will make specific tasks easier and a community forms around them as a result.

If I want to mess with the file system/configuration I will use Bash, if I want to build a website I will use Typescript, if I want to train a machine learning model I will use Python, if I am data engineering I will use Java, etc .

I noticed it has RabbitMQ in "the caddy".

I used to have a problem with an infrasture team, they would alter a managed switch or restart the DNS server I used and RabbitMQ would start running slow.

The solution was to restart RabbitMQ, everything else deployed was fine.

The other issue I used to have was resource related, if you hit the peak connection limit on a box the erlang processes could become disconnected from the erlang runtime.

The results here are abit random, it might refuse all incoming connections, it might run slow. You can tell thishas happened because restarting the application fails. It will stop but processes persist and prevent a start.

#rabbitmq

There is a 2.5% currency conversion fee (e.g. £ to €), then depending on the plan Ernest chose Patreon take 5/8/12%.

So worst case Patreon take 14.5%

You've just moved the packaging problem from distributions to app developers.

The reason you have issues is historically app developers weren't interested in packaging their application so distributions would figure it out.

If app developers want to package deb, rpm, etc.. packages it would also solve the problem.

Nice out of date dependencies with those lovely security vulnerabilities!

For anyone too lazy to read the blog, there are 10 shortcuts on the sidebar of nautilus. The author can't remember the last time they used "Documents" and picture/music links are rarely used. In their experience they only need "Downloads". So they suggest its worth pruning the list.

Ahh Gnome dev's continuing trend of removing things they personally don't find useful.

KBin/Lemmy should provide a combined local view for duplicated magazines/communities across the fediverse. Treating the concept like a hashtag.

The point of the fediverse is to distribute content so no one has a monopoly. People squatting on communities/magazines don't understand there is nothing stopping people creating one on a hundred other instances.

Each kbin/lemmy instance decides to follow magazines/communities from others through activity pub and stores it locally for the instance.

Having the UI retrieve all local posts with the same magazine/community name (e.g. m/star_trek@kbin.social c/star_trek@lemmy.world). Wouldn't be hugely difficult, I believe Kbin uses postgres database as the local store and suspect it would be a tweak to the SQL query it runs.

Even if that wasn't an option, there is a means to get all of the magazines/communities from the kbin UI/lemmy REST API. As well as retrieve all posts for a specific magazine/community. So you could do it entirely in a web client, for KBin it would be more work.

The combined view wouldn't change how you comment on specific posts. The issue is where do you post and what view would take dominance (e.g. if a magazine had themed itself).

The solution here would be to default your local instance if it exists or the instance providing the most posts/comments. Perhaps with a drop down so users can choose.

I would also configure things so instances can select a site wide default if they can't moderate it effectively. For example pushing all posts to the star trek instance rather than local magazine with a mod who is MIA.

This would remove most of the concerns users have about the fediverse, since they wouldn't be confronted by different instances. To them the fediverse is <insert instance> it would also encourage distribution of content.

What is your goal?

There are 3 main distributions

• Arch which aims to take the latest cut of everything. If you have time to keep your desktop updated and need that extra 1fps in a game, its a great choice.
• Debian aims for stability, this means your drivers and text editor might be .. 2 years old! But if it works on install it will stay working
• Red Hat Enterprise Linux aims for stability but will try to backport drivers. I honestly believe its packaged to always pull in gtk. It aims to provide tools to encourage people into support contracts.

Almost everything else is downstream of those with a twist. For example

• Ubuntu is downstream Debian with 6 month release schedule, non-free enabled by default and other deviations to encourage people into support contracts.
• Mint is downstream Ubuntu with the deviations removed.

Stuff that isn't downstream tends to have a highly specific purpose. Fedora started life as upstream RHEL, now it seems to be Red Hat's research plaything (e.g. immutable sounds cool, lets try it in Fedora).

My advice is go to one of the big 3, try them and only bother with one of the million down stream distributions if there is a Unique Selling Point for something you actually care about.

Have they told you protocol compatibility is the reason?

I ask because when you assume, you make an ASS out of U and ME. Which is a fun way of saying, while you have found an issue which should be resolved, you might complete the work and discover they had a different issue.

Secondly its important to remember while software engineers like to think they are super rational. They are people and people can have myopic views and giant egos.

Both of which can allow people to rationalize all sorts of weird and counter productive behaviour.

The code for mastodon, lemmy and kbin is open source and has been forked hundreds of times.

Admins can do whatever they like and people can build and deploy their own instance and enforce their own rules.

This is one of the key strengths of open source, people have forked projects took them in their own direction and had success.

Similarly ActivityPub is documented as a W3 standard, having read the standard the biggest weakness is the number of instances, not the size of the instances.

Also @mod I meant to hit reply and hit report and can't see how to revoke

If I was Ernest I would configure Kbin to use a key/value map. Of instance name and a bot user id.

If instance request failures reach a threshold it which switch out the user agent to something new for that instance.

Perhaps you randomise it a little, perhaps use the lemmy id, etc..

My goal wouldn't be malicious, more to mess with the lemmy devs. They can be honest an defederate from all kbin instances or spend lots of time quietly blocking them.

Why would KBin be unsafe?

Federation works by instances (e.g. kbin.social) registering an interest (subscribe/follow) in a specific magazine or person on other instances.

That means content is only brought into an instance that members of that instance are interested in (its the same with lemmy instances, we don't see everything).

Similarly on kbin users can block individuals, magazines or whole domains. So even if kbin.social does federate with meta you don't have to see/interact with it.

For instance I respect kbin users might want content from lemmy.ml, as the people who run it are tankies I have no interest in anything from that instance and block the domain.

I have no issues with part of the fediverse walling itself off from meta but remaining in contact with other instances. Similar to how beehaw defederated from lemmy.world but kbin could see beehaw and lemmy.world.

I would treat meta like any other instance, if its a source of headache then deferate.

The Embrace, Extend Extinguish argument makes no sense.

Take C#, many years ago Microsoft wanted to build its own Java JDK. As part of that they added Microsoft specific extensions. Sun said that wasn't acceptable. Microsoft didn't just stop, the renamed it C# and launched the product.

Everyone agreeing to defederate from meta won't mean they stop. It won't prevent EEE.

The best way to prevent EEE is given in our example. Java had a huge userbase who simply weren't interested in migrating.

So you need to encourage organisations to deploy KBin/Lemmy instances which integrate with the fediverse. That gives them reach and when Meta tries EEE they cut off content their users want. So it forces them to be a good citizen.