Ruby 4.0's parallel execution improvements are a game-changer for the ecosystem. The ruby::Box feature addresses one of the biggest pain points - GIL limitations - while maintaining Ruby's elegance.
What's particularly exciting is how this positions Ruby for modern workloads. With proper parallelism, Ruby apps can finally compete with Go and Node.js in concurrent scenarios without sacrificing developer happiness.
The typing improvements also can't be understated. Gradual typing strikes the right balance - it helps teams scale codebases without forcing the verbosity of Java or the complexity of TypeScript's type gymnastics.
Looking forward to seeing how the Rails ecosystem adopts these features. This could spark a Ruby renaissance in 2025.
> "With proper parallelism, Ruby apps can finally compete with Go and Node.js in concurrent scenarios without sacrificing developer happiness"
In theory, maybie. Parallelism support isn't a boolean though as there's a lot of additional factors at play. Just as one example, late stage Visual Basic also got parallelism support, but it really didn't help the overall positioning of the the language among its peers.
This approach using Sec-Fetch-* headers is elegant, but it's worth noting the browser support considerations. According to caniuse, Sec-Fetch-Site has ~95% global coverage (missing Safari < 15.4 and older browsers).
For production systems, a layered defense works best: use Sec-Fetch-Site as primary protection for modern browsers, with SameSite cookies as fallback, and traditional CSRF tokens for legacy clients. This way you get the UX benefits of tokenless CSRF for most users while maintaining security across the board.
The OWASP CSRF cheat sheet now recommends this defense-in-depth approach. It's especially valuable for APIs where token management adds significant complexity to client implementations.
98% coverage if you exclude browsers that caniuse doesn't track (which is surely appropriate, since even things like checkbox elements have only 96% coverage if you include un tracked browsers).
And you can fall back to origin header, which has universal coverage. Then block anything else.
Also, owasp doesn't recommend it as defense in depth. It is a primary, standalone defense against CSRF.
This is an excellent resource for building mathematical intuition through code. Python's combination of readable syntax and powerful libraries (NumPy, SymPy, Matplotlib) makes it ideal for exploring concepts like linear algebra, calculus, and discrete math interactively.
One approach I've found effective: start with a conjecture, visualize it with matplotlib, then prove it formally. The instant feedback loop helps develop both computational thinking and mathematical rigor. Tools like Jupyter notebooks make this workflow seamless.
For anyone interested in similar resources, "Mathematics for Machine Learning" by Deisenroth et al. and 3Blue1Brown's linear algebra series complement this beautifully by bridging theory and computation.
Exciting to see Ruby 4.0.0 released! The new conditional syntax improvements (if condition1 && condition2) are really elegant. The Ruby::Box feature for true parallelism looks particularly promising for CPU-bound workloads. This could significantly improve performance in scenarios where we've historically had to resort to external services or other languages. Looking forward to seeing real-world benchmarks and adoption patterns emerge.
We've found success using a hybrid approach with LLMs in our codebase:
1. Context-aware prompting: We maintain a .ai-context folder with architecture docs, coding standards, and common patterns. Before asking the LLM anything, we feed it relevant context from these docs.
2. Incremental changes: Rather than asking for large refactors, we break tasks into small, testable chunks. This makes code review much easier and reduces the "black box" problem.
3. Test-first development: We ask the LLM to write tests before implementation. This helps ensure it understands requirements correctly and gives us confidence in the generated code.
4. Custom linting rules: We've encoded our team's conventions into ESLint/Pylint rules. LLMs respect these better than prose guidelines.
5. Review templates: We have standardized PR templates that specifically call out "AI-generated code" sections for closer human review.
The key insight: LLMs work best as pair programmers, not autonomous developers. They're excellent at boilerplate, test generation, and refactoring suggestions, but need human oversight for architectural decisions.
One surprising benefit: junior devs learn faster by reviewing LLM-generated code with seniors, compared to just reading documentation.
This is exactly why network segmentation is critical for IoT devices. I always recommend putting all smart cameras and IoT devices on a separate VLAN with no direct internet access - only local network access through a firewall with strict egress rules.
For anyone concerned about their TP-Link cameras, consider:
1. Disable UPnP on your router
2. Use VLANs to isolate IoT devices
3. Block all outbound traffic except specific required endpoints
4. Consider replacing stock firmware with open alternatives when available
5. Regularly check for firmware updates (though as this article shows, updates can be slow)
The hardcoded keys issue is particularly troubling because it means these vulnerabilities persist across the entire product line. Thanks for the detailed writeup - this kind of research is invaluable for the security community.
A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.
When he opened his front door the conversation went something like this:
Him: "Ah hello, thanks for coming round to do this. It should be fun, come in and we can get started."
Me: "OK, but I'm already done."
Him: "What?"
Me: "I'm done. I've already got root on the machine and I left a little text file in root's home directory as proof."
Him: "What? But ... what? Wifi?"
Me: "Nope. Let me in and I'll explain how."
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.
I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.
I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.
He learned about all of the above mitigations that day.
I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.
Now we need to get an enterprise grade switch - doubt Cisco would add macsec into SOHO gear. Along with enterprise grade intercoms, cameras, doorbells...
And beloved by many Unifi is out of question - they still can't bake IPv6 support.
So looks like it's feasible but the cost wouldn't be good.
i well familiar with macsec. we use it between datacenters and for aws directlink. it de-facto standard for this kind of stuff. i even worked on hardware that provided macsec support
a couple of years ago I tried to use it inside datacenter during fedramp implementation. it crashed and burned for a couple of reasons:
- linux wpa_supplicant was crashing during session establishment
- switch had a limit on number of macsec session per port
I have my cameras connected to a N150 server running hostapd and dnsmasq and no IP forwarding. That server runs Frigate. I figured if I need a server anyway it might as well be the AP.
It's a little bit of a pain to set up the cameras because of the mobile app. I have to connect to the AP on my phone and as it doesn't have internet access my phone nags me, and this specific model doesn't have an external antenna. If it did I think it might be the ideal setup.
do you happen to have a guide on how to achieve this - I am fairly technical but still configuring Vlans and moving devices there would be good with some step by step instructions.
P. Sure the camera in question breaks in fun ways. From my observations because it can’t update it’s time, so messing with it a bit leaving to a need to update, downgrade, block from the web again.
depends on your router, but you would want to stick to onvif or rtsp and connect to the camera using some sort of tailscale. Don't fail for installing open source firmware, there is only thingino and openipc, both are hard to install if you are a beginner, even if people say it's easy for technical specialist, it's not
They're also limited to older hardware, newer 3K+ cameras aren't supporter. Different chip in use, I guess, or there manufacturers have learned to sign this firmware and burn in the keys.
What's particularly exciting is how this positions Ruby for modern workloads. With proper parallelism, Ruby apps can finally compete with Go and Node.js in concurrent scenarios without sacrificing developer happiness.
The typing improvements also can't be understated. Gradual typing strikes the right balance - it helps teams scale codebases without forcing the verbosity of Java or the complexity of TypeScript's type gymnastics.
Looking forward to seeing how the Rails ecosystem adopts these features. This could spark a Ruby renaissance in 2025.