Where it ends "how do we calculate the weights ?" is fairly simple.
Start completely randomly and compare output to known truth. When it's incorrect, you beat the model up pretty badly and repeat again. Eventually you get the correct answer pretty consistently.
... and by "beat it up" I mean tweak the weights - totally randomly will work but will take a long time (brute force), so we add a bit of intelligence to see which direction to tweak via some algorithms (backpropagation, gradient descent).
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
Entirely unrelated to the topic, but my mind was blown when I recently learnt that clamp() can be implemented via .median(val, low, high), and the param order doesn't matter!
Hiring software engineers across different locations and teams:
-
Tel Aviv:
Back End (Go) developer: High-performance edge ad auction systems
Data Scientist: Multiple ML and AI initiatives (internal systems as well as client-facing)
-
Montreal:
Data Engineer: Advertising (big data, for real!) data processing systems
Back End (Python) developer: Working on a (tastefully-designed) set of python transactional microservices serving the core business web application and APIs
-
If you see yourself as a good fit for the roles in the above locations, please browse the job descriptions on our web site ( https://perion.com/careers/ ) and reach out to me directly - my contact info is in my HN profile bio.
Agreed with you.
I've always told people all code "rusts" (not a language reference) - in multiple ways: the original author's mental model, the contributors, institutional knowledge, and the supporting ecosystem and dependencies.
All code atrophies towards being legacy and debt. The more the worse.
AI Vibe coding simply creates much more of it, much faster.
OP: the readme could really benefit from a section describing the underlying methodology, and comparing it to other approaches (Go channels, LMAX, etc...)
For the frontend for this I used Vue.JS as a learning experience. Overall it was straightforward and quite pleasant.
The hardest part was the mental process of giving up on server-side business logic enforcement (such as anti-cheating). At the end of the day ... "it's just a game" :)
I have a decade's worth of guess statistics per word.
Unfortunately, I just converted it to a frontend-only app to eliminate hosting costs, so I have no good location to keep tracking these stats.
Theoretically, "Oxford English Dictionary estimates that there are around 171,476 words currently in use in the English language", the log2() of which is around 17.38 - I have no historical data for 'volatile'
In _this_ particular case, you could just tell curl to internally timeout the request (via `-m`) instead of trying to manage the timeout on the process level
As someone who has been designing, writing, and operating high-performance systems for decades, I can guarantee you that it does not boil down to "laziness".
Everyone starts with the best of intentions. malloc() and free() pairs. Then inevitable complexity comes in - the function gets split to multiple, then across modules, and maybe even across systems/services (for other shareable resources).
The mental overhead of ensuring the releases grows. It _is_ hard, and that's most definitely not a lie beyond any trivial implementation.
Surprisingly "just design systems that manage their memory correctly", as you said, is a very legitimate solution. It just so happens that those systems need good language support, to offload a good chunk of the complexity from the programmer's brain to the machine.