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.
You can run niri from within other DEs, but I'm unsure whether it works well for your use-case. From the docs[0]:
"You can also run niri inside an existing desktop session. Then it will open as a window, where you can give it a try. Note that this windowed mode is mainly meant for development, so it is a bit buggy (in particular, there are issues with hotkeys)."
IIRC in this case the Mod key is by default Alt instead of Super.
My understanding is that asymmetric fields provide a migration path in case that happens, as stated in the docs:
> Unlike optional fields, an asymmetric field can safely be promoted to required and vice versa.
> [...]
> Suppose we now want to remove a required field. It may be unsafe to delete the field directly, since then clients might stop setting it before servers can handle its absence. But we can demote it to asymmetric, which forces servers to consider it optional and handle its potential absence, even though clients are still required to set it. Once that change has been rolled out (at least to servers), we can confidently delete the field (or demote it to optional), as the servers no longer rely on it.
> My understanding is that asymmetric fields provide a migration path in case that happens, as stated in the docs:
If you can assume you can churn a generation of fresh data soonish, and never again read the old data. For RPC sure, but someone like Google has petabytes of stored protobufs, so they don't pretend they can upgrade all the writers.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good.
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything.
All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.
> All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
Also an underrated chance to be forced to learn about Arenas, most of the time.
Simple data structures are easy to handle though, KISS rulez. You need rust when you write something comically complex like servo, that's when you need all the checks.
See the edit history here: https://news.ycombinator.com/item?id=46133179
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/
reply