HN user

yusyusyus

186 karma

ask me about why your packets suck.

Posts0
Comments91
View on HN
No posts found.

wat? thats submillisecond. im not an etcd expert by any means, but nothing ive seen has given submillisecond as a performance criteria.

do you have a point of reference? this would definitely change some architecture items i’ve got on my list.

a bit disappointed this only points to ethernet as its answer. it does help to understand why ethernet requires addressing versus some others that do not.

I have really strong opinions against the device-secured biometric stuff. On my own devices, I will never use it as it dramatically lowers my security posture.

Further, the development of this ecosystem is to the exclusion of alternative OSes. Windows Hello and whatever apple wants to call their suite of biometric goo is elevating them to a place in my life that is unacceptable by virtue of the unwarranted trust granted to them.

met him in prague. had his guitar. played a song for me and this other dude hanging out in the smoking area.

have a video of it if there is a good place to send it to.

RIP to a real one.

Back in the day, during the short-lived reign of Communications Decency Act's provisions for dealing with pornographic material and minors, there emerged a site called sexkey.com that would provide a sort of SSO experience for doing age verification. That is, one would verify their age with sexkey.com and then, at participating sites, one would do a lil SSO bounce to verify age.

When the CDA's porn provisions were struck down, the sort of industry argument was that they'd use the PICS site ratings and the content could be blocked in proxy/client side. This made a lot of sense in the context of the V-chip mandates of the 90's. AFAIK browsers stopped supporting this a long time back.

after having some direct awareness of how traffic shows up in netflow and the nature of global routing, i am not convinced that it requires a global visibility per se, but certainly is dependent on where traffic lands in a global sense. it’s a small world on the big ol internet.

Saw an Arista presentation about the increase in SFP capacity, it's Moore law style stuff.

SFP itself isnt much the issue. Serdes is, and then secondarily the operating power envelope for the things (especially for the kinds of optics that run hot). Many tradeoffs available.

I can't see traditional DVB/ATSC surviging much beyond 2040 even accounting for the long tail.

Tend to agree in well-developed infra, but rural and poorly-developed are well served with more traditional broadcast. Just saying “starlink!” 5 times in a dark bathroom won’t fix that part.

Personally I don't think the latency is solved yet -- TV is slow enough (about 10 seconds from camera to TV), but IP streaming tends to add another 20-40 seconds on top of that.

I dont think it will get better. Probably worse, but with net better service quality. HLS/DASH are designed for doing the bursty networking thing. Among good reasons for this, mobile works much better in bursts than strict linear streams, segment caching is highly effective, etc.

But I think this makes sense: its a server-side buffering thing that has to happen. So assuming transmuxing (no transcoding lol) and wire latency are 0, we’re hitting the 1-5 seconds for the segment, probably waiting for a fill of 10 seconds to produce the manifest, then buffering client-side another 10 or so. Throw in more cache boxes and it’ll tick up more. It is quite high, but aside from bookies, i dont know how much people will actually care vs complain.

I wrote an analysis on doing this kind of unicast streaming in cable networks a decade ago. For edge networks with reasonable 100gig distribution as their standard, these would see some of the minor buffering issues.

There is a reason that cable doesn’t stream unicast and uses multicast and QAM on a wire. We’ve just about hit the point where this kind of scale unicast streaming is feasible for a live event without introducing a lot of latency. Some edge networks (especially without local cache nodes) just simply would not have enough capacity, whether in the core or peering edge, to do the trick.

ehh.. LI on routers has been (at least on one major vendor) designed to not be visible to end operators in the course of normal operation. there are ways to see it, but it involves either the actual LI mechanism or some esoteric debugs. And it probably wouldn't be obvious to SOCs if the implemented LI was legit or not.

So, the question of competence or otherwise may be mooted by virtue of simply not having proper visibility.

as a predominantly wave-purchaser than builder, it matters when it matters and it doesn’t when it doesn’t.

we get by fairly well assuming l1 is working as designed when the light is on and not throwing errors.. at least on day-to-day ops. planning/sourcing is a bit of a different thing.

one note to your point though, back when people were still regularly picking up OC3s or doing frame relay or whatever, it was certainly more day-to-day to understand these things, but cant really fault anyone since most of that junk has gone away and we’re left with the happy ethernet handoff. especially in small scale DC/enterprise. cloud, too, made us care less.