phineyes

This isn't unique to Vodafone. Google has also been slowly withdrawing from IXes globally in favor of PNIs and "VPPs" (verified peering providers). This only makes it harder for smaller networks to establish presence on the internet and feels pretty anti-competitive.

On the flip side, IXes are becoming harder and less desirable to participate in: port fees are going up, useful networks are withdrawing, low quality network participants are joining and widening blast radius. I'm not sure what the answer to this is, but this has not been a great year for the "open" internet.

21G on tc egress is slightly surprising to me. I'd like to see the program used for the benchmark. Was GSO accounted for? If you pop/pull headers by hand, you'll often kill GSO which will result in a massive loss in throughput like this.

According to the FCC doc [1], the measurements may be conducted "between two defined points on a network, such as between a user’s interface device and the ISP’s network core or between the user interface device and the nearest internet exchange point where the ISP exchanges traffic with other networks". They require these measurements to be an average. I think this makes sense - it at least guarantees your speeds within the service provider's network.

[1] https://docs.fcc.gov/public/attachments/FCC-22-86A1.pdf

Let’s not forget that we’re also feeding in all our code into OpenAI Codex.

Parliament Hill has great views of the city - probably the most elevated viewpoint in North London. Went there yesterday - gets super quiet after 10pm unlike Primrose.

I mentioned “routed” address, e.g. an address that actually appears on the DFZ. 0.0.0.0/8 is not a range that’s assigned to any RIRs by IANA - it’s reserved for special use.

I had to add the trailing period for HN to accept it as a valid URL. However, for me (using Chrome on macOS Monterey), Chrome ignores the period and renders it as "https://16777217/". I thought it would be the same on other browsers. Interesting.

Was more pointing out the numbered hostname, not the service its-self.

16777217 is just the lowest number that corresponds with a routed IP address :)

It's not just Apple Maps either! Even with location services disabled, try opening AirDrop (even on another device you own) while running a ping and you'll see your en0 device's latency spike, while Apple tries to divide traffic between awdl0 and en0.

I don't agree. Your examples (UUID1, UUID4) are much longer strings and contain no useful information. UUID1 contains the device's MAC ID, UUID4 is just random bits.. vs a functional ID system like pika or Snowflakes which make use of those random bits by embedding a timestamp - something which might actually come in useful for some.

Yeah, pika is more of an ID system vs. prefixed-api-key which seems to be more oriented around just API keys, which makes sense. However, advantages of timestamps in IDs are that you can create unique IDs based on the current timestamp; bits which, in other ID systems, are usually just random - which feels like a waste imo. Also, knowing when a resource was created when debugging is very helpful.

Hey HN - I created this new ID system which combines Stripe-style (developer friendly) IDs with Snowflakes (proven, scalable and timestamped) IDs. I believe it combines the best of both worlds and allows for functionality to be added (e.g. secure, signed tokens) while still remaining short and identifiable. Main disadvantage (when compared to Snowflakes, for example) is that they're not sequenceable in a db, which is a trade off we were happy to make.

Let me know your thoughts. :)

I created a similar project recently! Main difference is that I use base64 to encode unique Snowflake IDs, which are timestamped: https://github.com/hopinc/pika :)

Google has to do this to comply with COPPA. They had to pay a $200m fine in '19 due to users that weren't age-checked.

We should just create a revision for RFC 2616 to extend the GET method to allow request bodies. Most HTTP frameworks already support this behaviour anyway.

Investing in promising people that are new to the industry - the easiest way to do this is through Twitter. I've found some amazing new developers which have great mindsets that I knew would do well in their careers, which I've capitalized on by following them early on and having regular chats with them about what they're working on, etc.

It allows you to maintain leverage in your field because once they're successful, you both already have a relationship and it becomes a lot easier to network and strike deals.

It has a huge upside with almost no risk - all it takes is a Twitter follow.