The biggest thing he got wrong is the assumption that it’s good programmers writing libraries.

Many organizations vendor packages in the repo for a number of different reasons and languages. Not just for node.

Human made changes is likely not what caused this image to occur.

111 files with that kind of change count is most likely a dependency update. But could also be that somebody screwed up a merge step somewhere.

None of those things are required but they sure do help.

As a developer, the baby is how I see developers, too.

Fiddle was found in a thrift store. Couldn’t afford the bongos.

I see nothing wrong, here.

My furry ass isn’t sysadmin certified and I sit it on the switch without a wristband, keyboard, and laptop daily.

It’s been my experience that the .NET developer will miss the actual statement and take it as an assault on .NET being the best solution for every use case.

This works for me. So long as you have a Kindle device registered on Amazon, you should be able to download directly to a desktop. The DeDRM plugin mentioned removes the DRM during ingestion into Calibre and requires an actual token from Amazon which is linked to the Kindle device you downloaded from.

I use this to get Amazon eBooks into my Remarkable 2 which requires DRM free.

I’m going to stop. Your over confidence is preventing you from listening to anything.

Forking doesn’t imply control. A forked version of chromium would still want to keep up to date with the upstream project.

You seem to view this public option with an unrealistic view of how software development works. Especially in the public sector.

Somebody comes in with a requirement to do something in the fastest and cheapest way possible. In this case, make a public browser option. The engineers go off and fork chromium and simply reskin it because that meets the brief. They might even go so far as to set up a CI pipeline that auto pulls new features from upstream.

The public sector isn’t going to be interested in trying to make the optimal browser if they are forced to create one. They are going to be interested in meeting the brief in the fastest and easiest way possible.

I’ll get even more specific to what is likely to happen in that scenario. The governmental entity will reskin chromium. Google will own the open source project.

Your arguments are all over the place. It’s not the governments responsibility to ensure that a law suit is profitable.

And a new browser isn’t going to do what you think it is. Any attempt by a government to create a browser is just going to use Blink anyways. The reason so many browsers are using it (including browsers made by tech giants) is that rendering engines are incredibly difficult to maintain. Especially as the Web continues to evolve.

Yes, these things are inconvenient. Meaning they are achievable items but at some personal cost and effort. They are not insurmountable.

And a new browser isn’t going to change anything. I’m honestly not even sure what you’re arguing anymore.

I think you’re struggling with the difference of convenience and difficulty. Doing things without the web implies you are going to do them in the same way you’d have to pre-web. That makes the web more convenient.

I can walk in to the library of Congress and make a face to face request.

The web is a convenience for any public need in the US.

That sounds like your government has an issue. That isn’t the same as governments as a whole using the web.

In the US, we still have the option to do things in person. The online presence is a convenience. That’s how it should work everywhere.

In principle, if a government is going to distribute content to the public, they also have a duty to equip the public to be able to consume the content. Telling people to come up with their own private sector tools to reach the public sector is a bit off.

This statement is a rearrangement of events. The governments of the world didn’t create an online presence and then tell the private sector to create browsers. Governments joined in an already existing method of communication because it was convenient, popular, and browsers already existed to view the content.

This one. It’s sophisticated and easy to navigate.

I generally do conflict resolution in Jetbrains IDEs and everything else in CLI. Occasionally, I might commit from the IDE if I only want a single file.

I don’t hate PHP, but I am wary of developers who only work in it. For the same reason I’m wary of Java developers, though.

A language is a tool and should be treated as such. Trying to force every problem into a single box is skin to the “everything is a nail” idea.

That said, I’m not sure Rust was the right call for the Lemmy backend, either. I like Rust. My team is transitioning to it for a system level service. But we would have chosen a different language if our goal was a web backend.

The thing with open source projects, though, is often times they are written in the language the developer is learning or working in at the time, not because the language is the most suited for the job.