What an absurd double standard. The language is patterned after GitHub's own caveats about misuse of GitHub Pages:
> you may receive a polite email from GitHub Support suggesting strategies[… such as, and including] moving to a different hosting service that might better fit your needs
GitHub Pages has never been a free-for-all. The acceptable use policy makes it clear:
> the primary focus of the Content posted in or through your Account to the Service should not be advertising or promotional[…] You may include static images, links, and promotional text in the README documents or project description sections associated with your Account, but they must be related to the project you are hosting on GitHub
They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.
> There are only two ways to make money. One is to bundle; the other is to unbundle. —Jim Barksdale
The original (or just the Firefox 3-era Places revamp?) bookmarks implementation in Firefox had a multi-line field to jot down a personal note or add a description of the page. Even bookmarks folders were allowed to have descriptions—see the New Folder dialog in this screencapture at ~1 minute in <https://youtu.be/QoJXmLuGM3s?t=60>
The "Description" field was removed in 2018. <https://bugzilla.mozilla.org/show_bug.cgi?id=1463738> Being able to capture and redirect the resources that would have inevitably gone into the maintenance costs of this feature over the last 8 years is likely to be the reason Mozcorp has been able to stay afloat on their meager budget that they have to carve out of their half-a-billion-dollar revenue stream stream year after year. Giving users uninterrupted access to Descriptions over that amount of time would likely have bankrupted them.
> I don't understand why you need to switch out the VCS to fix that issue.
For some reason, when it comes to this subject, most people don't think about the problem as much as they think they've thought about it.
I recently listened to an episode on a well-liked and respected podcast featuring a guest there to talk about version control systems—including their own new one they were there to promote—and what factors make their industry different from other subfields of software development, and why a new approach to version control was needed. They came across as thoughtful but exasperated with the status quo and brought up issues worthy of consideration while mostly sticking to high-level claims. But after something like a half hour or 45 minutes into the episode, as they were preparing to descend from the high level and get into the nitty gritty of their new VCS, they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over.
For someone to be in that position and not have done even a cursory amount of research before embarking on a months (years) long project to design, implement, and then go on the talk circuit to present their VCS really highlighted that the familiar strain of NIH is still alive, even in the current era where it's become a norm for people to be downright resistant to writing a couple dozen lines of code themselves if there is no existing package to import from NPM/Cargo/PyPI/whatever that purports to solve the problem.
> they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over.
It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting.
> It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why.
Yeah, I'm not sure why it seems that way to you, either.
> the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting
We're not discussing some fragment of some historical artifact, one part of a larger manuscript that has been lost or destroyed, with us left at best trying to guess what they meant based on the little that we do have, which amounts to nothing more than the words that you're focusing on here.
Their remarks were situated within a context, and they went on to speak for another hour and a half about the topic. The fullness of that context—which was the basis of my decision to comment—involved that person's very real and very evident overriding familiarity with non-DVCS systems that predate Git and that familiarity being treated as a substitute for being knowledgeable about how Git itself works when discussing it in a conversation about the tradeoffs that different version control systems force you to make.
A common misconception is that git works with diffs as a primary representation of patches, and that's the implied reading of "stores diffs". Yes, git uses diffs as an optimisation for storage but the underlying model is always that of storing whole trees (DAGs of trees, even), so someone talking about it storing diffs is missing something fundamental. Even renames are rederived regularly and not stored as such.
However, context would matter and wasn't provided - without it, we're just guessing.
The problem with comments like these is that guessing what "better language" a commentator has in mind is always an exercise left up to the reader. And that tends to be by design—it's great for potshots and punditry, because it means not having make a concrete commitment to anything that might similarly be confronted and torn apart in the replies—like if the "better language" alluded to is C (and it generally is)—the language where the standard library "steers" you towards quadratic string operations because the default/natural way to refer to a string's length is O(n).
Maybe if the Jolla folks were serious about making inroads in the market for personal mobile devices that they're ostensibly trying to compete in. But they're just as deluded and as doomed as their Meego/Maemo/Moblin predecessors about the value proposition that the SDKs and system software they ship has with the market segment they're targeting.
It sounds like you're not grasping the meaning of the linguistic construction being used by the person you're quoting. (Or you're being deliberately deceptive about your understanding of their intent. But it's probably just the former. I'm guessing you're ESL.)
"Ruining Android for everyone" ("to try to maybe help some") does not mean, "Android is now ruined for X, for all X." It means, perhaps confusingly, pretty much the opposite.
It means: "There exists some X for which Android is now ruined (because Google is trying to protect Y, for all Y)." (Yes, really. The way the other person phrased it is the right way way to phrase it—or, at least, it's a valid way to phrase it.)
> you may receive a polite email from GitHub Support suggesting strategies[… such as, and including] moving to a different hosting service that might better fit your needs
GitHub Pages has never been a free-for-all. The acceptable use policy makes it clear:
> the primary focus of the Content posted in or through your Account to the Service should not be advertising or promotional[…] You may include static images, links, and promotional text in the README documents or project description sections associated with your Account, but they must be related to the project you are hosting on GitHub
reply