HN user
Nobody's going to run a /8 on a single LAN segment.
If you want maximum efficiency, your hosts all have RFC1918 IPs and you route the public IP addresses to them. zero wastage, everything usable.
If you want to be fully pedantic, it's Élő, not Elo - the way in which you pronounce the former is dramatically different from the latter.
For older architectures, you really want to use the BX instruction unless you can guarantee you're not switching execution mode.
as a bit of pointless trivia, MOV PC, PC does not cause an infinite loop - it skips the instruction immediately following.
`[[no_unique_address]]` in C++20 should also resolve this and permit a zero-size object.
Actually this is effectively a broadcast/multicast MAC address.
The first byte of your MAC address should always be an even number. The value of the second bit is supposed to indicate if the MAC is "burned-in" and basically doesn't matter. The LSB of the first byte, however, should always be zero.
An iterator is a class. It can contain any private data you desire and mutate in any wonderful and/or stupid ways you desire.
How it decides to compare equal to the .end() instance is also your call. Your example is not a compliant iterator (as in, wouldn't work in a range-based for loop) - yet the same behaviour would be achievable through your own operator++() and operator bool(),
"The best extra virgin olive oil I've ever tasted"
Oh shit, why was I banned?
I always used argep.hu for pricing computer bits. Dunno who's better
And it just so happens to have created the Blume logo from Watch Dogs - https://dosycorp.gitlab.io/dosylogo/?v923418754891239875624v...
Edit: OK, the link doesn't work it seems. It's #66 which, at least to me, is identical to #134
Well, there is.
Say I'm an ISP with X million subscribers.
Given a peering with Y GBit of throughput to someone like say, Twitch or Facebook; with multicast, I now only end up with a single load of data for each livestream coming over the pipe.
However, this does require direct peerings. Multicast over the Internet is just not a thing. This could technically be built out with IPv6, but nobody's realistically going to arrange for globally-unique multicast space allocations and convince every AS in the world to start peering multicast over BGP for general public use.
No, it's complete nonsense.
NAT just happens to serve as a form of firewalling in IPv4 land because usually, the stuff behind your router has a private address.
Proper firewalling is a matter of policies; it's completely orthogonal to whether your devices have a globally routable address or not.
Except in practice this is useless because you're now transmitting what is basically a corrupted packet.
For this to work, L4 protocols would need to be completely redone to consider and work with this concept.
Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size.
Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
By any combination of assigning static IPv6 addresses, organising devices into separate L2 links (VLANs) and firewalling by IP prefix, rather than the entire /128.
This makes no sense at all. The notation can basically be anything you want - you could, if you wanted, invent a new notation for IPv4 or IPv6 right now.
What actually matters is the packet format.
You cannot make it backwards compatible because it is impossible to expand the IP header's address space without it becoming unparseable to existing network equipment.
"Ah" you say, "but we could put the extra bits after the end of what is basically an IPv4 packet"
Well no, you can't do that either because it would require executing a global seizure of existing IPv4 space and reorganising the entirety of the IPv4 internet into a hierarchical manner where your "IPv7" extra bits can be processed prior to the final destination.
IPv6 works fine and is well-designed. Hardware and software implementations have been in-production for decades now; Google alone see 30% of their total traffic over v6.
Fundamentally, support of any network protocol is subject to Internet participants having compatible kit; x86-64 wasn't immune to this; if you didn't buy the chips, you couldn't use the software. The reason it actually won is that the Itanium architecture was completely different and resorted to translating x86 instructions which, unsurprisingly, ran like treacle and never made it to the consumer market either.
The idea of inventing yet another internet protocol is patently absurd when you consider it would require yet more upgrades across the globe to hardware and software in order to support it.
What use-case are you envisioning where one needs to "carefully control" the allocator for STL types?
Your idea of heavenly C++ sounds like my idea of hell.
I implemented a variety of GitFlow, but with an emphasis on automation. Normally you branch off of develop; hotfixes will be a branch off of master.
Feature branches are combined with develop before being built and tested. If it passes, it becomes mergeable in GitLab.
all builds of develop that pass are taggable; you go into the CI interface and specify a tag. Once deployed, master is updated by the CI to point to that tag.
The most valuable part of this is the CI pipeline and having a solid body of tests to ensure that changes which don't necessarily conflict in Git will most likely be caught during test, prior to it being allowed for merge.
At this point, I believe that even if the population of 90% of the planet were to legitimately oppose this, ICANN would ignore it anyway.
Not that it isn't worth a shot, but I have become highly cynical of the entire organisation.
If you are able to have the reverse zone for your subnet delegated to nameservers under your control, you can use it as a "forward" zone too.
DNS doesn't technically have the concept of forward and reverse - it's just record types and an agreed format that the PTR records should be.
Sounds like you got the reaction wrong. If you do it correctly, it should be possible to mafipulate it into powered embenzalmine nitrotamine.
Is ip6tables really necessary for this; wouldn't AnyIP work?
namely:
ip rou add local 2001:db8::/48 dev lo