I don't really understand the point you're trying to make, I don't see anywhere in the post nor the title claiming the purpose changed and the title is directly related to the content. In fact, it seems like you are just agreeing with the post.
I think people can get frustrated at CI when it fails, so they're explaining that that's the whole purpose of it and why it's is a actually good thing.
I would personally actually frame it slightly different than the author. Non-flaky CI errors: your code failed CI. Flaky CI errors: CI failed. Just to be clear, that's more precise but would never catch on because people would simplify "your code failed CI" to "CI failed" over time, but I don't thing that changes it from being an interesting way to frame.
Even if the false-positive rate is very small (e.g. 0.01%), you probably won't be affected, but more than a hundred thousand of websites would be and that would still be an issue. I have no idea how big is the false-positive rate.
There are many of reports of the same happening to other sites, some of the top ones (you can find many more by searching HN for "google safe browsing"):
Are you saying that the author engaging in online activism and presenting very common criticisms of SUVs in a sarcastic way somehow implies they're bad neighbors?
I'd argue it's more like "looking at your keys while you're picking them". Selecting text is also known as highlighting and some people highlight text while reading / thinking.
You don't need primary selection to avoid the keyboard, you can also hold right-click on your selection and release it on "copy" (or right-click on your selection then left-click on copy, more intuitive but slightly more cumbersome)
I agree it's less convenient (there's an extra step: explicitly copying the text), but in my experience it's also more reliable as you don't lose it by just selecting anything.
I mostly agree, but a generalized attack at the remaining GitHub workers by calling them "losers" and then "rookies" is unwarranted and leaves a bad taste IMO.
Edit: 1. just to be clear, it's very good that they have accepted the feedback and removed that part, but there's no apology (as far as I know) and it still makes you wonder about the culture. On the other side, people make mistakes under stress. 2. /s/not warranted/unwarranted/
A structural engineer will not sign off on bad designs no matter how much pressure the company applies to them. They will resign and/or report the incident to their local regulator as a safety issue.
We don't have that for developers. Maybe shame/offense is our next best bet. You are free to work for a terrible company accepting and/or encouraging terrible design decisions, but you need to take into account the potential of being laughed at for said decisions.
I think you are correct, but you probably misunderstood the parent.
My understanding of what they meant by "retroactively apply a restrictive license" is to apply a restrictive license to previous commits that were already distributed using a FOSS license (the FOSS part being implied by the new license being "restrictive" and because these discussions are usually around license changes for previously FOSS projects such as Terraform).
As allowing redistribution under at least the same license is usually a requirement for a license to be considered FOSS, you can't really change the license of an existing version as anyone who has acquired the version under the previous license can still redistribute it under the same terms.
Edit: s/commit/version/, added "under the same terms" at the end, add that the new license being "restrictive" contributes to the implication that the previous license was FOSS
It's probable that licenses that explicitly allows revocation at will would not be approved by OSI or the FSF.
Copyright law is also a complex matter which differs by country and I am not a lawyer so take this with a grain of salt, but there seem to be "edge cases" where the license can be revoked as seen in the stackexchange page below.
Yeah that's annoying. Maybe you could add a disclaimer on your blog saying you do not use AI to write and then just write however you like the most? I think it would help both yourself and those who want to avoid AI content.
The 'no AI used' disclaimer is a nice idea, however, how long is that going to last?
We could all have disclaimers or identifiable 'stickers' such as what we had in the olden days of IE6, to send people over to Firefox/Chrome/whatever.
However, next time the tech bros scrape the web, their AI beasts could learn the trick, to decorate their piffling output with similar disclaimers.
In the olden days, 'the camera never lied', however, nowadays, 'the camera always lies'. Even if it is not AI, you know it has been staged and Photoshopped to within an inch of its pixels.
So, what to do?
One way would be to have 'guilds'. Maybe tie it into academic institutions, where teaching staff are at the sharp end of AI use and exacting penalties for AI abuse. Imagine if there was a 'guild of human writers' and being in it meant better SEO with the consequence of abusing AI meaning getting kicked out of the guild.
Ultimately though, without any 'guild system', it all comes down to quality content.
Your whole comment assumes language identification is both trivial and fail-safe. It is neither and it can get worse if you consider e.g. cases where the page has different elements in different languages, different languages that are similar.
Even if language identification was very simple, you're still putting the burden on the user's tools to identify something the writer already knew.
Language detection (where “language”== one of the 200 languages that are actually used), IS trivial, given a paragraph of text.
And the fact is that the author of the web page doesn’t know the language of the content, if there’s anything user contributed. Should you have to label every comment on HN as “English”? That’s a huge burden on literally every internet user. Other written language has never specified its language. Imposing data-entry requirements on humans to satisfy a computer is never the ideal solution.
Do you have any reference of that or are you implying we shouldn't support the other thousands[0] of languages in use just because they don't have a big enough user base?
> And the fact is that the author of the web page doesn’t know the language of the content, if there’s anything user contributed. Should you have to label every comment on HN as “English”? That’s a huge burden on literally every internet user.
In the case of Hacker News or other pages with user submitted and multi-language content, you can just mark the comments' lang attribute to the empty string, which means unknown and falls back to detection. Alternatively, it's possible to let the user select the language (defaulting to their last used or an auto-detected one), Mastodon and BlueSky do that. For single language forums and sites with no user-generated content, it's fine to leave everything as the site language.
> Other written language has never specified its language. Imposing data-entry requirements on humans to satisfy a computer is never the ideal solution.
There's also no "screen reader" nor "auto translation" in other written language. Setting the content language helps to improve accessibility features that do not exist without computers.
I wish this comment was true, but due to a foolish attempt to squish all human charactets to 2 bytes as UCS (that failed and turned into the ugly UTF-16 mess), a disaster called Han Unification was unleashed upon the world, and now out-of-band communication is required to render the correct Han characters in a page and not offend people.
I think people can get frustrated at CI when it fails, so they're explaining that that's the whole purpose of it and why it's is a actually good thing.
I would personally actually frame it slightly different than the author. Non-flaky CI errors: your code failed CI. Flaky CI errors: CI failed. Just to be clear, that's more precise but would never catch on because people would simplify "your code failed CI" to "CI failed" over time, but I don't thing that changes it from being an interesting way to frame.