I don't understand how this or all these magic skill bundles and methodologies get traction and why they are so popular. It's either plain worse or has serious trade offs.
At that point this who submission should be auto filtered out since there are dozen of these and they are barely distinguishable except for couple of opinioned choices.
Router has a DynDNS function. I am using a reverse proxy for multiple services, but this only sets up router IP and IPv4 NAT port forwarding to the reverse proxy.
So what would be the correct setup with IPv6 when using privacy extensions?
I don't see any benefit in allowing IPv6 traffic or using IPv6, but a couple of new problems coming up with it.
Privacy extensions are additional addresses that are used by default for outbound connections. You still have the non-privacy address, which doesn't change; put that one into DNS.
This approach prevents outbound connections from leaking the address needed to connect to your servers. On v4, it's likely that any outbound connection from your network gives the server the IP they need to do that.
> My ISP changes the prefix on a regular base (and on request)
I found this was the case (with Telus) until I reconfigured the DHCPv6-PD client on my gateway, mainly to stop it from sending DHCPv6 Release messages and to have it explicitly request the prefix I was previously assigned.
OpenWRT in particular seemed to be built not to save any dhcp client state in non-volatile memory, resulting in a lot of unnecessary address and prefix churn when rebooting the router. I've had the same stable prefix for over a year now, using systemd-networkd with the following configuration (the important parts are SendRelease=no, RequestAddress= and PrefixDelegationHint=; the rest of the options are just insurance):
So you'll never have a permanent unchanging v6 address to ID your traffic with.
Privacy extensions are orthogonal here; they only affect the suffix, not the prefix. As for dealing with a changing prefix... I'm afraid you'll just have to find some way to automate the DNS updates. You can do it with a program running on one of the servers -- I can't suggest a specific one offhand since I have a static prefix and haven't needed it, but they do exist.
Never checked. But it does change once in a while. The router has a dyndns function which updates a DNS entry, but only for the router itself. But this is sufficient for the NAT port forwarding.
Let's say when your ipv6 prefix changes it is almost the same situation. Only that ipv4 bundles all traffic of all devices on one ip which obfuscates a bit.
But having the ipv6 prefix change you get a pile of problems (DNS, firewall), you don't have with ipv4.
The IPv6 prefix changes are disruptive, I agree. My prefix has been stable for a couple years, but on another ISP it would change every few months and was certainly annoying.
I can't really talk about Ruby. But PHP is much more static and surface of things you have to care about at runtime is like magnitude smaller and there already was opache as a starting point.
And speaking of something like JIT in V8 is of the most sophisticated and complicated ever built. There hasn't been near enough man hours and funding to cpython to make it fair comparison
Even for reducing the context size it's probably worth it. If you have to go back back and forth on both problem and implementation even with these new "large" contexts if find quality degrading pretty fast.
The anxiety surrounding AI-generated "slop" mirrors the frantic warnings of late 15th-century clerics who viewed the printing press as an engine of spiritual decay. Johannes Trithemius, a prominent Benedictine abbot, famously argued that monk-scribes should not abandon their pens, fearing that printed books were ephemeral, error-ridden toys that would undermine the sanctity of scripture and the discipline of the mind. He believed that the sheer volume of cheap, mechanical texts would drown out genuine wisdom and lead to a permanent decline in the quality of human thought.
History shows he fundamentally misunderstood the human capacity for adaptation. Rather than succumbing to a sea of printed garbage, society developed sophisticated new filters. We invented the modern bibliography, the peer-review process, the concept of a "trusted publisher," and the critical literacy skills required to navigate a world where information was no longer a rare luxury. Humans have an innate drive to seek out signal over noise. Just as the chaos of the early printing era eventually gave way to the Enlightenment, our current struggle with synthetic content will likely trigger a new evolution in how we verify truth and value human insight.
Manuscript could contain handwritten errors and of course there could be misprints due to wrongly selected types but content wasn't generated out of nowhere. Unless we're talking about asemic or automatic writing due to some... "spiritual" influence.
The key here is human thought as you said. Whether these books were written by clerics or printed by the press these were still containing human produced substance. It's not a fair comparison.
"Generating slop is totally fine because we'll eventually develop anti-slop filters" isn't exactly the most convincing argument, you know.
Besides, your link between the "chaos of the early printing press" and the start of the Enlightenment is very forced. The Greek philosophers did plenty of critical thinking after all, and they had no need for a printing press. I see absolutely zero reason why the current AI bubble will inevitably result in an Enlightenment-like period, nor why AI would be a hard requirement for one.
The frontiers of mathematics is already incorporating AI and people like Terrance Tao are documenting the progress of AI. At the very least the current best mathematician in the world only does this because he has predicted an opposite conclusion to you.
So when you say zero reason, I have to tell you that your absolutist stance is blindness. There are many reasons why it can happen, and many reasons why it can’t.
Incredibly valid opinion. Many people disagree but this is an extremely possible future for AI.
There is also a darker future where AI improves to the point where it’s no longer slop. It produces quality code, texts, and books that are better and in a fraction of a second after one misspelled prompt. Given the past trajectory of AI, this is the more likely outcome.
The other outcome is AI flatlines. This is as good as it gets. In which case the future you predict may come to pass.
You are my hero. Pointing to the rules will rarely make someone change their approach and it is so myopic whenever someone leaves a comment like that. What makes HN great is the quality of discourse that can take place.
I mean, only the threaded version, which is expected. For tons of cases Python without the GIL is not just slower, but significantly slower; "somewhere from 30-50%" according to one of the people working on this: https://news.ycombinator.com/item?id=40949628
All of this is why the GIL wasn't removed 20 years ago. There are real trade-offs here.
Thanks for the link, that's an interesting read. Actually the referenced PyMutex is a good old pthread_mutex_t, the same you'd use in C or C++. But I shouldn't have written so surely. Although uncontested locks are very fast, if the loop is tight enough, adding locks will be significant.
However, PEP 703 specifically points out that performance-critical container operations (__getitem__/iteration) avoid locking, so I'm still highly skeptical that those locks are the cause of the 30-50%.
The pthread_mutex_t is focused on compatibility at any cost. So while you're right that the C++ stdlib chooses this too, it's not actually a good choice for performance.
But I think you're right be sceptical that somehow this is to blame for the Python perf leak.
One of the things this spends some time on that was already obsolete in 2011 is using a pool of locks. In 1994 locks are a limited OS resource, Python can't afford to sprinkle millions of them in the codebase. But long before 2011 Linux had the futex, so locks only need to be aligned 32-bit integers. In 2012 Windows gets a similar feature but it can do bytes instead of 32-bit integers if you want.
If a Linux process wants a million locks that's fine, that's just 4MB of RAM now.
reply