I’ve been downvoted enough with my comments on this blog post where I’m hesitant to add anything else, but here I agree with you. They’re trying to be everything to everyone, where does the accountability of their customers being responsible for running, you know, up-to-date packages come in? Like, you don’t take just a little bit of pride in your work that you’re continually watching CVE lists and exploits and just have a minimum of effort toward patching your own shit, rather than pawning it off on vendor? I simply can’t understand the mindset.
Core routers don't inspect that field, NAT/ISP boxes can. I believe that with two suitable dedicated linux servers it is very possible to send and receive single custom IP packet between them even using 253 or 254 (= Use for experimentation and testing [RFC3692]) as the protocol number
This is an interesting list; it makes you appreciate just how many obscure protocols have died out in practice. Evolution in networks seems to mimic evolution in nature quite well.
We're about half-way to exhausted, but a huge chunk of the ones assigned are long deprecated and/or proprietary technologies and could conceivably be reassigned. Assignment now is obviously a lot more conservative than it was in the 1980s.
There is sometimes drama with it, though. Awhile back, the OpenBSD guys created CARP as a fully open source router failover protocol, but couldn't get an official IP number and ended up using the same one as VRRP. There's also a lot of historical animosity that some companies got numbers for proprietary protocols (eg Cisco got one for its then-proprietary EIGRP).
Probably use of some type of options. Up to 320 bits, so I think there is reasonable amount of space there for good while. Ofc, this makes really messy processing, but with current hardware not impossible.
It uses them a little differently -- in IPv4, there is one protocol per packet, while in IPv6, "protocols" can be chained in a mechanism called extension headers -- but this actually makes the problem of number exhaustion more acute.
What if extension headers made it better? We could come up with a protocol consisting solely of a larger Next Header field and chain this pseudo header with the actual payload whenever the protocol number is > 255. The same idea could also be used in IPv4.
I didn't mean to imply otherwise. But, as you say, this is equally applicable to IPv4 and IPv6. There were a lot of issues solved by IPv6, but "have even more room for non-TCP/UDP transports" wasn't one of them (and didn't need to be, tbqh).
I like how SpaceX is willing to take risks. Their second launch tower is still months away from being finished, and now they're trying to catch the booster using the first one.
FAA doesn't care if they blow up the tower, as long as SpaceX can explain why it happened and show that it didn't cause undue risk to the public.
People freaked out and said the same thing after IFT-1 dug up the concrete underneath the launch mount, and yet the investigation was closed within 6 months and SpaceX conducted IFT-2 2 months later.
IFT-1 presented no danger to the public at all and it still took 6 months. That’s a long time to an actual technology company attempting to innovate. The FAA slow walks SpaceX because of Musk’s political views, it’s not even an “open secret” just a fact of life. Their only recourse is to shine a light on the FFA so the public can see the politics in display.
The time for the mishap report of IFT-1 was reasonable enough, they had a pretty serious issue in that the booster's FTS turned out to be insufficient. It also took them until the end of July to repair the pad and test the new deluge system. By mid-August they submitted their incident report to the FAA. The investigation was closed in early September. This was something even Elon admitted, saying that retesting the FTS would probably be the limiting factor for when IFT-2 could fly because it didn't destroy the vehicle as it was supposed to.
The unreasonable delay you might be thinking of, was between the FAA's closing of the investigation in early September, to the IFT-2 launch in November. That was under pretty similar circumstances to now, Fish and Wildlife Services was taking forever to do its part of the job, SpaceX went to Congress, the resulting pressure forced them to get things done faster.
Don't do that, or you'll be dragged before the greatest obnoxious and self-aggrandizing body in the world for lengthy dressing down that probably affects the stock price.
Of course, but we specifically would like to see a _technical_ postmortem that examines what kind of incremental rollout procedures they have and how this update overcame those.
I've similar experiences about Scrum. In the worst case there's one or more developers, usually junior, in the team that are very eager to improve processes. Eventually it's tenth time you are forced to discuss what's the optimal way to define story points.
Given that personnel matters affecting an individual on the board often have mandatory recusal of the affected party, that's likely a 4-0 or two 4-1 decisions, depending on how they were structured.
A single 4-0 decision would imply the bylaws allow any group of members to oust all the other members by making a single proposal to oust everyone but their group, thus automatically forcing everyone else to recuse themselves :p
Yes, this can happen, though generally the ousting party would also need to be able to point to some policy or legal transgression to do it without putting themselves at risk of a lawsuit.
