It is not a generic term for source-available software, and never was.

The problem with that reasoning is that precedence and origin do not necessarily define language use after it. Language evolves. Society and communities make up new or change definitions.

Misuse of the term is evidence that it's not universally understood to be one way.

I think it's mainly because "open source" can be understood as accessible, readable source. And many people seem to intuitively understand it as such. The "free" terminology on the other hand has a more ambiguous meaning between freedom and no cost. And early on, the "freeware" terminology was established as a differentiation to "free software". "Open source" does not have such an equivalent established differentiation (like "source-available", which seems to be just not as prevalent, maybe because there have been much fewer products with that alone).

I understand the desire to correct, specifically with the established OSD. But I have to wonder if it will ever bear fruit, given these circumstances. And in consequence, whether it's even worth to point out.

I learned of those files outside the context of programming. When program or file zip packages contained these random ds store files and I looked up what they are.

Turns out, it's metadata ~~caching~~ for macOS. Irrelevant and does not belong into [distributed or shared] packages.

/edit: It's been a long time ago. Looking at it again, I guess it adds folder metadata, so it could be useful when distributing to other macOS. But for other OS, it's noise. Either way, usually it's not intentionally included.

Case insensitive handling protects end-users from doing "bad" things and confusion.

Who has age authority? A state agency or service. Like the state issues an ID with age.

Preferable, we want the user to interact with a website, that website request age authentication, but not the website to talk to the government, but through the user.

Thus, something/somewhat like

1. State agency issues a certificate to the user
2. User assigns a password to encrypt the user certificate
3. User connects to random website A
4. Random website A creates an age verification request signed to only be resolveable by state agency but sends it to the user
5. User sends the request to a state service with their user certificate for authentication
6. State agency confirms-signs the response
7. User passes the responds along to the random website A

There may be alternative, simpler, or less verbose/complicated alternatives. But I'm sure it would be possible, and I think it lays out how "double-blind"(?) could work.

The random website A does not know the identity or age of the user - only to the degree they requested to verify - and the state agency knows only of a request, not its origin or application - to the degree the request and user pass-along includes.

blenderdumbass.org

What a domain

Presentation/Lecture; bad software quality due to software stack complexity with increased separation of layers and participants

SoC (System on a Chip) hardware for embedded/smaller use cases is very common and successful.

Suggests "Direct Coding" with direct hardware access as a possible alternative approach to PC hardware interfacing. Implementing that is more about commitment than difficulty. Depends more on hardware producers than software developers. A lack of drivers could give a fairer playing field between manufacturers.

Seems like a Ruby issue and suggested improvement? Using keyword arguments does feel like introducing a type of typing.

In C# I use records for simple, naturally behaving types, I can define explicit and implicit cast operators, so I have to choice between requiring explicit casts or not (because they make sense to require or are not necessary). I can use var to define a variable without specifying a type, and it is deducted from what it gets assigned - but is still that specific type and gives me type safety.

In Rust, as far as I understand anyway, traits define shared behavior. In Go interface implementations are implicit rather than explicit. With these, there's even less of a need of elaborate explicit typing like the post argues/gives an example of.

In general, I've never had considerable effort or annoyance implementing or using typing. And I know what it's good for; explicitness, and in consequence, predictability, certainty, increased maintainability, and reduced issues and confusions. If following references or refactoring becomes unpredictable or high effort, it'd be quite annoying.

When I'm coding JavaScript adding JSDoc so the typing information gets passed along is quite cumbersome. Without it, the IDE does not give intellisense/auto-completion or argument type matching. JavaScript is better with it, I consider it worth it with IDE support, but it is quite cumbersome. (I try to evade TypeScript compiler/tooling overhead.)

A programming language can offer extensive auto-deduction while using strong typing. With appropriate conversions in place, it will only report conflicts and where it was intended to.

I'm thinking of where I enjoyed dynamic natures, which I certainly have. But I don't think that's a matter of typing. It's a matter of programming language interfacing to typing. If in PHP or JS I make a change, hit F5, and get an error, that's not any better than the IDE already showing it beforehand. And for the most part, I can program the same way with or without typing.

Man, this became a long text.

A strength of the GPL is that the community can fork projects, and "take them over" that way.

At the same time, and this instance is such a case, on a centralized platform, projects can be taken over instead of be forked.

They developed and published a plugin. Now it's been taken over by someone else, on the primary distribution and discovery platform, and they have no control over it. Worse than that, the takeover now offers their sold functionalities for free.

This makes the "open source but not free, but after two years true FOSS licensed" licenses look very useful if not necessary for businesses and developers that want to monetize. At the very least when they [have to] use centralized platforms.

I did a bunch of other experiments, which didn't make things faster:

Also particularly interesting what didn't work.

I would have expected that at least all the frameworks were using the same database, but no. Some frameworks use MySQL, others use PostgreSQL. Some framework implementations are ultra-optimized and others are what you would expect in your average web application. Some frameworks are using proper templating libraries, others are using Sprintf.

I think the guideline should be: future software should be written on a whim

OCI does the platform hosting and development. OCF does the non-profit org work. OCF pays the OCI.

At least that's what I read from it.

I wouldn't be surprised if only weeks from now involved people announced a competing/new platform without this setup.