This only happens if the extension puts their `moz-extension://` links into the DOM. It's different to chrome case where extensions can be detected regardless of being activated on that site or not.
As I understand it, an extension could also leak its links via its own backend, e.g. to advertisers, who could then detect it even though no user-observable DOM modification is happening.
Much better than static global IDs, but still not ideal.
Yeah, anything happening in backend depends totally on the extensions. Unless I need something, I rarely use extensions that are closed-source or open-source but has some sending data in their features.
I'm hoping the meme goes away. Internet is a dark forest, crypto DEXes are a dark forest, AI is a dark forest. Add the obligatory gloss of Cixin Liu (DF is only one of many amazing concepts in TBP but apparently the only bloggable one). Hard sci-fi references sound smart but in the end don't describe society very well.
Citation needed that "the people" wanted to end tax credits on EVs. EVs were steadily increasing in popularity and capturing a growing market. In a very real sense consumers had "choice" before, in that the market supports made EVs accessible.
LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.
TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ...
But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the community's view or priorities. Even JavaFX shows very patchy support for certain very standard UI concepts, and the situation with packaging is bad as you say.
Anyway, is mill worth switching away from Gradle? (Does mill integrate at all with idea?)
Mill does work with idea (via the build server protocol), and the ideas behind it are very sound (a build tool is basically a function calling other functions - on which they depend. You just want to parallelize their running and cache their results.
But it does have a learning curve and you may sometimes end up having strange error messages. (As an implementation, it's basically Scala macros turning normal looking scala functions into a static task graph). It is getting better and better support for mainstream java build setups, and it's possibly the best tool for something very custom. In between the two extremes, you may or may not have a better time with Gradle/Maven.
> Anyway, is mill worth switching away from Gradle?
Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.
I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).
It's just that Maven doesn't have a good core abstraction and it is not a reliable build system. Like even with base plugins, let alone with additional ones you can't be sure that a build actually picked up every change, you often have to do a double take and do a clean install instead to get some stale files cleared. This should never happen in a build tool and every other feature is secondary to this error.
That's why I defaulted to Gradle, which has its own idiocities (like tending to break the syntax on every second major version, but it's much better with the kotlin DSL), which at least 100% sound.
For more experimental/hobby projects I choose mill though.
But it's IDE who picks up every change, not Maven. God forbid you run 'mvn install' for all modules on every line change while developing, that's IDEs job. Maven config just tells IDE locations and dependencies.
For release build you do want to clean up the space in CI/CD anyway.
Not sure what you mean by "doesn't have a good core abstraction". For example, Linux famously doesn't have a good core abstraction (aka "monolithic kernel").
It's not a good core abstraction for a build tool to not be able to do proper iterative builds. And thus it's not a good model for IDEs neither, while with Gradle it never gets out of sync, with Maven it can easily happen that some edits don't "show up" in behavior.
> I have described what bothers me about the writing
No you haven't, you've made an unprovable claim about how the writing was accomplished without pointing out a single feature of the writing itself.
Too long? OK, but homebrew gamedev articles often are. Skimming was a good skill before AI and still is.
Bad writing? Again -- hobbyist posts don't exactly win awards. I suspected possibly some AI myself but not to the extent you're baselessly asserting: I really doubt there was a single prompt in any case. The article is structured like any other.
If it were content-free clickbait or something, the complaint would hold water. As it is this is a reasonably interesting article that has generated a large and fun discussion on HN, so even if you _could_ prove AI use, so what?
What's tiring is a comment like this. If you don't like the article don't read it -- and don't comment.
reply