41–50 of 199 posts
Earlier quoted context omitted.
What's the benefit of DHCPv6 over SLAAC (genuine question, never looked into DHCPv6 at all)
You can do finer-grained subnets with DHCP than SLAAC will give you.
(they say my or most ISP can enable ipv6 on reuest; country : Slovenia, year : 2023)
Earlier quoted context omitted.
You don't need to merge upstream! Its your source, your build, your rules.
Maintaining your own patchset for your personal use is usually not a good use of your time and expertise. Every time someone runs a linter over upstream, you're going to have to remake that patch. Sure, it's only 20 mins... But that multiplied by every bit of software you patch and every release, and you quickly realise that a huge chunk of your life was wasted doing what is effectively busywork. Instead, contribute…
Earlier quoted context omitted.
You don't need to merge upstream! Its your source, your build, your rules.
Maintaining your own patchset for your personal use is usually not a good use of your time and expertise. Every time someone runs a linter over upstream, you're going to have to remake that patch. Sure, it's only 20 mins... But that multiplied by every bit of software you patch and every release, and you quickly realise that a huge chunk of your life was wasted doing what is effectively busywork. Instead, contribute…
Offering changes back to upstream is always encouraged, but whether or not it is accepted is largely irrelevant to the patch author.
The main advantage of Linux over other systems is that its available from source and thus can be patched and recompiled easily. Here we see someone using LD_PRELOAD to patch the behavior of a binary, because they rely on distributions pre-compiled packages without means to change the source code themselves. This sort of negates that advantage, right?
Super cool! I tried doing a pure IPv6 network a little over a decade ago; Maybe I’ll try it again. Though, my cheap IoT devices likely still need IPv4… but perhaps not internet connectivity. It might be fun to explore just how much IPv4 continues to be ingrained into cheap Things (eg: Arduino WiFI?) There always seems to be a long tail of small places where IPv4 pops straight back into the equation.
plus these individual devices will live for a long time. I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS. IPv4 on local networks will probably exist for a very long time.
That sounds like they haven't been updated for TLS>1.1 – if that is the case then rather than going all the way down the HTTP you could enable TLS1.1 (and maybe 1.0). It is open to POODLE/BEAST/others that way, but still have some protection and the site's configuration differs less from the rest of your infrastructure.
Unless the site is completely internal only of course, in which case just sticking with HTTP may be less faf.
> To prove that IPv6 is ready for production use No one is debating it's not ready for production use. It's just that it's a lot easier to configure clients in dual stack than do a 6 to 4 translation.
Earlier quoted context omitted.
plus these individual devices will live for a long time. I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS. IPv4 on local networks will probably exist for a very long time.
> I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS. That sounds like they haven't been updated for TLS>1.1 – if that is the case then rather than going all the way down the HTTP you could enable TLS1.1 (and maybe 1.0). It is open to POODLE/BEAST/others that way, but still have some protection and the site's configuration differs less from the rest of your in…