> On the flip side, it's super similar to those video poker machines in bars and restaurants.
Other than playing cards being shown on screen, it's not.
> If you allowed the option to increase the bet
There is no betting in Balatro.
> and got rid of the special joker abilities, it's basically the same thing.
So completely change how the game works completely then it's "basically the same" as video poker? Do you hear yourself?
> People claiming otherwise are being willfully ignorant.
People claiming otherwise can tell the difference between 2 games using playing cards.
> I love Balatro, but it's definitely gambling adjacent
Again, there is no gambling in Balatro.
> and depending on how rules/laws around children gambling are defined, it probably should be age gated, or those rules/laws should be updated to reflect reality, you can't have it both ways.
Gonna ignore this because you haven't explained in any way how Balatro is in anyway "gambling adjacent" other than your made up situation where if you completely change the way the game works it becomes gambling, which of course is nonsense.
Looks like they're not all working that great: [1], [2]
I don't think all assistants are that bad in general, but I'm not sure that taking all capabilities and responsibilities (well that point is a bit of an open question with these systems) away from the driver is the right approach.
If you drive like a decent human being (and as required by law in most places), it can be quite safe already, adding complexity may actually cause issues. That some people don't drive that way shouldn't be the reason to force these systems on to everyone, better to do a good job in teaching driving (driving schools in my country are expensive, but otherwise mostly worthless except for the safety training which strangely enough is done after getting the license), etc.
I remember my first linux admin gig and mistyping my password when using sudo then getting an email about it a few seconds later. After years of home linux use this amused me and was like "oh, so that's what happens when things are configured properly".
I don't like them and won't contribute to projects with them but isn't this the exact point of a CLA[1]? A textfile in the repo seems a lot easier to track and audit than PR comments and a bot to chase people.
No. The purpose of a CLA is so that the owner of the project can use the code in a commercial product that might not comply with the OSS license (particularly if that license is a copyleft licence such as GPL, AGPL, or MPL) and/or they can change the license more easily.
Legally speaking, once they own the copyright, is there anything stopping the PSF from selling out and changing their policy to permit proprietary licensing?
I have this same concern with GNU. I can imagine a future where some key figures have died or retired and the new org sells out and changes the license to something RMS never would have agreed to.
To go along with the other response, they don't own your copyright -- but I don't know if the language in the Python CLA actually holds them to the "we can only relicense to open source licenses" if challenged in a court.
But that's not really a risk I care about. The PSF is a nonprofit that's clearly aimed at being a nonprofit, and a Future Evil Board is beyond what I'm going to worry about.
That's more the risk than the purpose. Some people do CLA's for that purpose, but sometimes it really is about having a paper trail that the software is open source, or to make it easier to sue people who violate the license.
A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because that is what other projects do, but there are other ways of insuring everything is open source that don't require the contributor to give you unlimited rights.
Keep in mind that a DCO is not the same thing as a CLA; kemitchell has written about the subject[0]. In short - the DCO is specifically written to meet the needs of the Kernel and some of it's expectations assume the workflow of the LKML and the code style of the kernel. He lists 6 conditions that you'd need to meet before the DCO is useful for your project. The most notable ones are that or-later licenses aren't a good idea with a DCO, that you must put the license text in a file header and that there's a Signed-Off-By element in your commits.
The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.)
Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity.
> rather than existing to unify the copyright of the Kernel behind one entity
Unifying the copyright behind one entity is the problem with a CLA. Especially if that entity is a company that might have pressures to change the license to a proprietary license.
...and that's why the Free Software Foundation requires signing CLAs[0], those evil commercial, proprietary product making rapscallions!
The reality is that without a CLA, copyright enforcement tends to turn into a complete mess. To be clear - that can absolutely be the point; a completely unenforceable copyright that's still enough of a mess to scare off violators can have it's uses; the Kernel jumps to mind. Linus and Greg have both been open about the fact that the license is there to encourage people to contribute as a carrot, not there as a stick to beat them over the head with. Explaining how the license works and why they'd really appreciate cooperation is much more useful for the LKML than it would be to keep a bunch of lawyers on standby and the fractured license helps achieve that goal.
They're often used by corporations to rugpull a license change, but the original purpose of a CLA is just to ensure that there's one entity in control of the licenses, which is more useful if an entity prefers the stick approach to compliance. (Which the FSF I would say absolutely lands under by-the-by.)
> What horrors lurk in the depths of those lovelessly constructed TV OSs that call out to servers and will cause mayhem when those servers are decommissioned?
My Sony TVs all work without an internet connection, so I'd guess nothing?
TFA is literally marketing for them. HN is their target audience and a good way to capture that audience is to show them something technically interesting.
