The client obtains the network prefix from the RA, and then the client tries to generate unique host address.
""
The IPv6 stateless autoconfiguration mechanism requires no manual
configuration of hosts, minimal (if any) configuration of routers,
and no additional servers. The stateless mechanism allows a host to
generate its own addresses using a combination of locally available
information and information advertised by routers. Routers advertise
prefixes that identify the subnet(s) associated with a link, while
hosts generate an "interface identifier" that uniquely identifies an
interface on a subnet. An address is formed by combining the two.
In the absence of routers, a host can only generate link-local
addresses. However, link-local addresses are sufficient for allowing
communication among nodes attached to the same link.
""
Basically it explains that SLAAC RFC itself does not define the /64 limitation, but other RFCs that are relevant to network operation do.
"""
The addressing architecture [RFC4291] [RFC7136] sets the IID length
at 64 bits for all unicast addresses and therefore for all media
supporting SLAAC. An immediate effect of fixing the IID length at 64
bits is, of course, that it fixes the subnet prefix length also at 64
bits, regardless of the aggregate prefix assigned to the site
concerned, which in accordance with [RFC6177] should be /56 or
shorter.
"""
While having a long uptime sounds cool it is a signal that you don't patch that often. Maybe you patch your other stuff, but I would bet on even odds that you don't. So then that is the rest of the stack, eg systemd which has some mega flaws IIRC.
You're leaving yourself open to having something exploited. Have a look at your ssh logs where "people" are constantly trying to get in.
As someone who does full patches every couple of weeks on my servers and reboots every several months, I agree, however there's stuff that can live patch the kernel these days like kernelcare and livepatch by Canonical and more.
Another reason though to reboot every so often is for the server to do filesystem checks on the root partition(s).
I understand, and my uptime was just to show how reliable Hetzner has been. By “talk me into it” I meant please point out a real kernel security flaw that be exploited without already having access to the system. There very well might be some! I’m not well up on all of this.
Yes, I check my logs and see the constant stream of breakin attempts. Basic security precautions seem to keep them out.
I would counter that this software was created and maintained on your own time, in which case that at the very least you are entitled for consideration for your work and efforts.
Employment tribunals and courts take a dim view of wage theft, and that is exactly what this is if your employer is trying to enforce that clause.
>> We could remove all duplication by grouping the code like this instead:
1. It seems to me that you refactored the code in the wrong dimension. I would have abstracted out a template shape object.
2. Are you not using a pull request/peer review process to accept changes into the prod branch?
3. I don't think you quite arrived at the right conclusion. While you conceed that your original conclusion was incorrect, I do think your original criticism has merit, and while your solution may provide a different set of problems, that doesn't mean that a different solution based upon the collaboration between yourself and your colleague might have been yet even better.
It seems to me that many of the problems associated with spaces in filenames are due the OS assuming that a space signals the end of a command or filename.
Maybe we ought have to a different character signify the end of a name? Or signfiy a option section, or the next option section of a command?
>> It reminds me of British customer service. If you haven't lived in the UK you might not be familiar with the phenomenon of a checkout person being surly. They clearly don't want to be scanning your groceries or engaging in inane chit-chat with you. And they have almost no pretence about that fact.
How have you arrived at this conclusion?
I'm guessing by "British" you mean English. I've lived in Scotland for almost 15 years, and I can certainly tell you that "British" customer service is not Scots customer service. For a starter, most Scots do not identify as "British", so then to use your broad brush is a bad look.
If your experience was in England, please just say so.
In anycase, my experience shopping in Scotland is vastly different from shopping in the home counties.
Or will IPv8 go straight to 1024 bits?
;)