It's worth remembering when deciding on rolling out your own engine that this is a multi-layer trade-off as well, I have an anecdote on this.
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
But it's tightly scoped, there is only really one thing that needs to be dynamic, although it worked admirably with more. We wanted big impulses so could get away from questionable cases easily and could deal with crushing cases simply by exploding the ship.
Likewise the players on the ship running around and the players when they're jetpacking about are all different sub-sets of code implementing that specific behavior.
A lot of "make a game, not an engine" is working out what the minimal thing you need to build is rather than making everything extremely generalized.
There is a very big difference between engaging with your own stream of consciousness and being spoon-fed stimuli without any effortful engagement. While I get the sentiment that the parent comment may be snarkily over-generalizing (for the record, I don't think that it does), this retort doesn't land at all.
> It's great because what we call plagiarism in academic setting, in the real world work we call collaboration, cooperation, standing on the shoulders of giants, not reinventing the wheel, getting shit done, and such.
That is absolutely not true. A much closer analogue of industry collaboration in the academic setting would be cross-university programs and peer review. The actual analogue of plagiarism is taking work of another and regurgitating it with small or no changes at all while not providing any sources. I'm sure you see what this sounds more akin to.
The corollary to this is that companies do this because they are incentivised to do so by their very fundamental goal - to make profit. Whatever pressure that does not lead to a loss on the quarterly report is, in practice, no pressure at all. If we truly want these predatory practices to stop, we have to start promoting different incentives, different priorities, and by 'we' I really mean 'each and every one of us collectively'.
I have a feeling we, collectively, glance over the question, and over the author's stance on the subject, and almost dismissively say 'yeah, sure', without the amount of thought that they deserve.
The title originally claimed 575M hours spent every year by Europeans on cookie banners. That's 12 seconds on average a day per person. Hardly anything to complain about.
All the time settings that are or were historically used in Go tournaments had their own quirks and idiosyncrasies that added charm to the time management issue. At the same time, I can understand the tediousness of Canadian being an argument not to use it anymore. Last time I played with it was at a tournament in Brussels where they were using old-school chess clocks, effectively making it the only viable solution.
Nowadays, as mentioned, Fischer trumps all with its simplicity, but some still enjoy playing with byoyomi (supported both by newer chess clocks and by old Ing clocks), since they got used to managing their thinking time in regular intervals once base time was spent. Personally, I've been advocating using Fischer for the longest time, since said management strategies were more natural to me in this case, and I'm glad DGT clocks became the common standard at tournaments now.
Fischer is "simpler" if you have a Fischer clock (and "simplicity" is basically irrelevant if you have a programmable software clock). If you have to manually add time each move it's a whole other story. A traditional analog clock (as used for chess) only knows how to count a fixed amount of time for each player, and anything else is a manual adjustment. If you have to do it mechanically, surely a single byoyomi period (reset to X if the button is pressed while the needle is between zero and X) is at least as easy to implement as Fischer (move the needle back by Y every time, limited to some Z maximum).
Fischer removes a lot of thought for the player around "oh I know what I want to play, but I better think more or the time is wasted" kind of thinking that some other systems have. It does add "oh I can play this forcing move for free extra time", but I never do those (it feels vaguely scummy) so effectively I don't need to think about it.
It's also easier to specify eg: you have 5 minutes, add 10 seconds/move. That's all of it. The specification for byoyomi or canadian are pretty detailed if you don't just assume someone knows how it works.
With the topics of ADHD and autism entering mainstream Internet conversations more often, I think it's kind of predictable that stuff like this will start showing up more regularly.
Considering how much people can struggle with these issues, even in spite of proper medical care, it's safe to assume for the time being that this falls under the magic device category.
Stop with the allegedly it was a anonymous service that was reachable from onion. There is no question at all that there was CSAM shared over it. I don't care about the rest but all this "allegedly" shit in regards of CSAM gets on my nerves. I actually thought people here either work in bigger corps or have experience in running services themselves and would know about the real size of the CSAM problem. But I guess not, ignorance is bliss.
Also it's only their hosted for profit service. Use the fsf instance if you feel violated by a user account. https://jitsi.member.fsf.org/
I personally think it was likely/almost certainly the case. That doesn’t change the fact that without sufficient actual evidence it remains “allegedly.”
Well, the announcement talks about clear-cut ToS violations. Maybe it was about illegally streamed soccer matches - that's a bit of a plague as of late.
I mean, it could also be beheadings, revenge porn, doxxing, etc. Lots of clear-cut violations that are more serious than illegally streamed soccer matches.
But the true answer is probably "all of the above".
Not all porn is CSAM... Are we just assuming it's CSAM because non-CSAM would be on OnlyFans? Is there not an appeal for the anonymity and zero-cost Jitsi offered vs. OF-like services, for consenting adults?
I've never used OF but assumed they take a cut. Through Jitsi a performer could arrange for payment via crypto, protect their identity, and not pay a cut to any middle-men beyond the crypto fees. What am I missing?
No, it isn't. Jitsi is free to offer a signup and run an LDAP directory of their own. They do not need to federate with FAANG.
If they still wish to do any sort of reporting or eavesdropping on content, something they claim to be specifically impossible, yet somehow they've unearthed, that is their perogative I suppose.
Personally, I think <insert law enforcement authority> of some sort has made rumblings or threats about them daring to run an uneavesdroppable open comms service, so once again, nice things cannot be had, and everyone is happy to torch the ability to low-frictionly connect between arbitrary people because of the CSAM boogeyman, which no evidence has been brought forth to assert the existence of. In fact, there's been no evidence brought forth that there is any sort of worthwhile reason other than "Jitsi wants in on monetizing user's contact meta info".
In every thread someone comes with "but is this the only way to tackle the problem?" Noone ever even makes a suggestion so I guess yes it's the only way.
the only people that have to identify problems and solutions are founders that are grifting for capital or customers. and that’s sad.
the rest of rational actors can see a false dilemmas from afar without knowing what the third and fourth and fifth possibilities are.
in this case its pretty obvious that “privacy for hosts, or not via FAANG Oauth and an unaccountable change in the terms of service to further distance from privacy” is a false dilemma while also not preventing anonymous CSAM rooms on their service.
It's not mentally negligent, "is this the only solution?" is a weird standard that for some reason gets brought up in the specific instance but isn't something we apply to other problems.
Is MFA the only solution to the auth problem? No.
Is having a firewall the only way to prevent unauthorized traffic on your network? No.
Is docker the only solution to how to package software in containers? No
Is git the only DVCS? No.
Is git-flow the only way to manage branching and pull-requests? No.
Is Rust/Python/Javascript the only programming language? No.
Are relational databases the only way to persist important data? No.
etc etc etc...
We normally expect for difficult problems to have a variety of solutions with different tradeoffs and in particular, for really hard problems involving adaptive human adversaries, a lot of time we rely on applying multiple levels of "solution" in order to give us defense in depth and a chance to really crack a particular problem.
personally I think its weirder how CSAM (or a mere rumor of it in this case) gets people to not question anything
when without that rumor the criticism of the change would be criticism
“is this the only solution” is actually just me being diplomatic on a topic people are emotional about, as its clearly not the only solution, but even that is met with deflection
maybe thats the reason this “weird standard” is only noticed on CSAM mitigation discussions, because people know they cant be frank to you
So you are basically saying my way or the highway without even offering a option at all. So your "diplomatic" is just another way of saying "I don't give a shit and please stfu". Why would you inject yourself in a discussion if you don't really want to participate? Yikes.
It’s only a false dilemma if there’s a third, etc. possibility. You can’t just assume that every problem has a magical happy solution that requires no tradeoffs.
3. the same signup requirements for the participants instead of just the host
4. phone number verification for the host and participants
5. a credit card for the host and participants
6. some kind of deposit for the host and participants
7. discriminating against Tor users
8. including Apple ID in the list of auth services
9. it actually not being Jitsi Meet's obligation at all and authorities continue to prosecute the criminal action of the participants by doing actual investigations
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.