Roman @rtsisyk revoked Github owner permissions from Alexander @biodranik and Viktor @vng and granted such permissions to the community contributor @pastk. This triggered Github's automatic "sanctions" check and the whole Github OM organization was automatically archived and admin access was blocked until OM's appeal was reviewed. It was unknown whether and when Github would review Organic Maps' appeal and unblock the repositories, so 2 weeks later the project migrated to the self-hosted git.omaps.dev/organicmaps instance, using the free and open source software forge Forgejo.

What the fuck? GitHub blocking the account because of automated security evaluation triggering (probably a good thing) but no review over two weeks (obviously a very bad thing)?

I think they were always on a smaller scale. With this one, I'm somewhat hopeful that it'll stick, and be a long term effort.

committee consisting of representatives of Germany’s federal government and the state governments

Even just being able to view the source code without cloning is very valuable. A bare repo does not provide that.

Very interesting. A trove of experience and practical knowledge.

They were able to anticipate most of the loss scenarios in advance because they saw that logical arguments were not prevailing; when that happens, ""there's only one explanation and that's an alternative motive"". His ""number one recommendation"" is to ensure, even before the project gets started, that it has the right champion and backing inside the agency or organization; that is the real determiner for whether a project will succeed or fail.

Not very surprising, but still tragic and sad.

I can understand the reasoning, but I would have weighed the significant benefit over the little "complexity"/content increase.

The color inversion is a significant effect. It doesn't change anything for those that use their own error pages, but significantly improves the situation for people who land on these pages and are bothered by light mode.

/edit: Their PR close comment was super short (non-telling), but they later commented with some reasonable reasoning that better describes their point of view and considerations.

those who’ve coded C for twenty years might not understand the issue

or the opposite because they have that experience

I always pronounced it engine-x (fluent as one word) but never thought of it meaning engine lol

n gin x -> en gin ex -> "enginex" spoken, nginx thought

There are two very distinct ways of developing software:

I read this as a claim that there is only two. Which seems to match the overall flow of the document, describing only two, and then arguing between those two as if only those two exist.

No, that's wrong. Especially those two bleak, described extremes. They're not the only ways to develop software.

The thing is, most humans are laughably bad at architecting software without actually writing it first. […] Agile development "fixes" this. You get to discover your spec on your user's time and end up releasing faster. In the end (and oddly so if this were the 90s), fast food is indeed faster to make. But is it worth it?

What the heck are they even talking about anymore. Now one is the only feasible one. But then neither are.

Now, by the end, I have no idea what this was even trying to argue. Meant as entertainment, following two theoretical development process extremes? Formulating in the extreme to make a point? None of it seems to apply. No conclusion is made at the end, instead falling further into anecdotes and unrelated, far away equivalences that make the whole thing even more confusing.

Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.

I'm not in (or into) the JS ecosystem. I'm glad I didn't have to dive into that at work yet. But I've used deno and bun in the past to evade installing NodeJS.

Just now I used deno v2 to build a static website I contributed a fix to, and it worked. I'm very glad to see I don't have to juggle different npm alternatives or be stuck without when I want to contribute but definitely do not want to install NodeJS.

The deno install was hilariously slow downloading and installing the JS libs into the node_modules folder. 150 MB of JS source code. For a simple static website generator.

Comparing it to the hugo.exe binary (go, single binary static website generator): That one is 80 MB. Not having to juggle many files makes it a lot faster and compact of course.

The deno.exe is 107 MB. Which is a chunky size; but man it provides a lot. When you contrast that to the node_modules folder… lol

The announcement also mentions and links to JSR for TypeScript module publishing platform, also with backwards compatibility and automatic stuff generating. Which also seems like a good effort.

TOML instead of YAML or JSON for configuration.

YAML is complex and has security concerns most people are not aware of.

JSON works, but the block quoting and indenting is a lot of noise for a simple category key value format.

Dada data structures

giggle