• 4 Posts
  • 83 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle




  • 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.




  • 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.



  • What a mess.

    URL is still advanced-custom-fields, but then named Secure Custom Fields. Translations and source repo still map to the old name. It definitely is a takeover, not a “fork” in the classic, established sense.

    The problem with the takeover is, of course, that the original publisher still develops, publishes, and sells their original plugin. Their official website now serves their own version with their own update source.

    So you kinda don’t but also have to rename it to avoid confusion.

    I think a rename to something different is wrong and confusing though. It should add a disclosing addition, like “(Taken Over)” or “Adjusted” or “WPorg edition”.

    A supposed, partial rename is confusing. No information in the README is confusing, intransparent, and disingenuous. No clarity in the release notes is confusing.

    Simply freeing previously and still sold pro features, without disclosing that fact, is very questionable. Not fair to the developers and certainly not transparent to the community.

    Clearing the changelog and release log documentation, removing previously available information, is questionable as well.


    I see in the readme.txt file that the plugin is licensed under GPL.

    So the changes are permissible. And being able to do so is certainly a strength of the FOSS license.


    My biggest issue is that they remove information, and rename without indication. It should be transparent and, within context and concerns, fair. Not like this.


    Looking at the commit log:

    6 days ago, 6.3.6.1 was tagged with

    Security - ACF defined Post Type and Taxonomy metabox callbacks no longer have access to $_POST data. (Thanks to the Automattic Security Team for the disclosure)

    14 hours ago, 6.3.6.2 and rename

    • Security - Harden fix in 6.3.6.1 to cover $_REQUEST as well.
    • Fork - Change name of plugin to Secure Custom Fields.

    It also removes is-pro and pro-license-active checks, but fails to disclose so in the release notes.

    Effectively, it frees pro functionalities.

    It also removes all previous change log and release information.



  • I am very proficient in my primary language, C#.

    Writing more context out feels like boasting, so I think I will skip that and go to a summation/conclusion directly.

    Knowledge and expertise comes from more than the language. Which you hinted at. The language is only our interface. How is the language represented, how will it transform the code, how will it be run. There’s a lot of depth in there - much more than there is in the language itself.

    I learned a lot, through my own studies and reading, studying, projects, and experience. I’m a strong systematic thinker. It all helps me in interpreting and thinking about wide- and depth- context and concerns. I also think my strengths come at the cost of other things, at least in my particular case.

    You’re not alone. Most developers do not have the depth or wide knowledge. And most [consequently] struggle to or are oblivious to many concerns and opportunities, and to intuitively or quickly understand and follow such information.

    Which does not necessarily mean they’re not productive or useful.







  • If Firefox was a better funded and more competent alternative to Chrome we wouldn’t even have this whole Manifest v3 mess since Chrome would just lose all their users.

    I don’t think that’s an issue of competency - which I understand as functionality/feature parity in this wording.

    Chrome gained and became this popular likely entirely due to Marketing and big-corp ecosystem network effect through pushing it - through Google, Google Docs, and related Alphabet services.

    I don’t think Firefox was every really inferior. I’ve always preferred the dev tools and a few other things over Chrome. There was merely a time where performance was worse, but that likely only mattered in benchmarks - and marketing.