I find it very unfortunate that browsers (or rather, the spec) do not support some kind of versioning. If we could declare which version of HTML, JS and CSS to use, it would allow for breaking changes without breaking the entire web.
There are so many (in hindsight bad) design choices and implementation accidents that currently exist in perpetuity because of backwards compatibility; the web would really benefit if every now and then we could shed old baggage.
It would also force browsers to implement multiple slightly different engine modes, vastly complicating the browser code.
There are already a few cases, eg quirks mode vs standards mode and “use strict” mode, which was considered necessary for moving forward, but clearly it also complicates things for browsers. We dont want more modes than what is necessary.
Probably not too popular of an opinion on HN but email in my opinion would be a great example of a service that could be run by the government. Just like postal service (at least in some parts of the world)
There was something like that in Germany called de-mail. It was official and receiving and reading a mail was considered legally binding (invoices, etc.)
It could have been great but the implementation lacked encryption and had wild security issues. So nobody used it and it was shut down
But you can detect serverside (at least probabilistically) if a user is abusing it to their advantage.
Some Valve guy gave a great talk about their cheating detection a while back; I found it incredibly impressive: https://youtu.be/ObhK8lUfIlc (can't comment on their effectiveness these days, haven't played CS in a long time)
The problem with building a secret profile on players based on undisclosed metrics is that could be flagging legitimate programming tools as "risk". What if a programmer who likes to hack and mod other games decides to play a Valve game? You don't know how their "risk" score is calculated.
For example, I've seen other programs refuse to run if you had Sysinternals Procmon running, or various standalone debuggers. Would you be deemed a "risky" user if you used tools like that?
Having watched that video, their newer ML-based anti-cheat does not seem to rely on inspecting running processes. It is based on data surrounding when a gun is fired in the game (a certain number of ticks before and after), and the classifier is initially trained on human-reviewed "killcams." But the classifier probably takes into account other data too, for example new Steam accounts with only CS in it would probably be classified as "high risk." On the other hand someone who has had their account for a long time and has paid games in it is far less likely too cheat.
That video is a fraud as far as I can tell. Playing cs in high elo's is more than 50% of the matches with cheaters. I played with a team of cheaters one time that was even blackmailing the opposing team for real money, and they got it, and blackmailed again, than they disabled cheats. This is a whole industry. That was one of the last times I played. I actually encountered the same cheaters a few days later.
Shameless self-plug and probably not what you're looking for, but anyway: I've created https://github.com/abuob/yanice for that sort of monorepo-size; too many applications/libraries to be able to always run full builds, but still not google-scale or similar.
It ultimately started as a small project because I got fed up with NX' antics a few years back (I think since then they improved quite a lot though), I don't need caching, I don't need their cloud, I don't need their highly opinionated approach on how to structure a monorepository; all I needed was decent change-detection to detect which project changed between the working-tree and a given commit. I've now since added support to enforce module-boundaries as it's definitely a must on a monorepo.
In case anyone wants to try it out - would certainly appreciate feedback!
I'm dabbling in the monorepo-tool-space for quite a while already and somehow managed to never hear about Turborepo, seems very interesting!
Just a few years back, the monorepo-tooling-landscape left much to be desired, there were a lot of opinionated 'zero-config' tools out there that always seemed to fall apart the moment you strayed from their happy path. I even went so far to create my own tool (https://github.com/abuob/yanice), in parts because it was fun and taught me a lot and in parts because I simply didn't find something fitting our usecase.
It's cool that the tooling in this area is getting better and better, monorepos solve a lot of very annoying enterprise problems but require solid tooling to make it work, even when way smaller than google-scale.
