That’d be frustrating, not just for this. I’d probably be looking into a solution like Tailscale to tunnel out. Or just develop a gnarled security rule list full of rich history. :)
I read the current Starlink system has a limitation where if you move outside of your assigned service "cell", you lose service. Guessing this is still the case.
Eh, really? It's due to needing ground station visibilty for the consumers as there's no intra satellite routing links, I thought and they didn't want to swamp the contention ratio whilst they were in beta? Why would the FCC be stopping this?
The FCCs mandate is to protect the airwaves from interference. Starlink uses shared bands. if the receivers move, tracking down interference is harder.
this is not really true relative to what OP said. there are fcc regulations for spectral leakage and such, but that's well known and means you can't transmit outside a service area. but that just means you're in another, adjacent service area. it has more to do with the spectral efficiency going down as you move from boresight, so they don't want a capacity loss. fcc has nothing to do with this decision.
> This indicated there was likely a problem with the ‘*.slack.com’ wildcard record since we didn’t have a wildcard record in any of the other domains where we had rolled out DNSSEC on
I'm not going to stick my hand in either camp for the sake of this discussion,
but dynamic/wildcard DNS records are exactly the type of thing I'd suspect DNSSEC to have trouble with
I, on the other hand, can speak from experience, and I say that where I work we currently have over 100 domains with DNSSEC and a wildcard record, and they all work just fine.
I wasn't implying that wildcard records are something entirely incompatible with DNSSEC, more that certain nameserver implementations could potentially have trouble with them.
Your guess was proven correct, as it was indeed a bug in Route 53 which broke Slack. But you did not write “certain DNSSEC implementations”, you wrote “DNSSEC”, which I interpreted as implying that DNSSEC itself, inherently, had problems with wildcard records. But my experience told me otherwise, hence my comment.
This is not crawling by any stretch of imagination. It’s low speed digital which is the only thing making it “easy”, other than that it’s worlds apart in complexity from a reasonable educational or DIY project.
This. Some standards bodies (arguably) made a big deal about client certificates some time ago to reliably pin client identities for client->server connections (whether it worked is a different story), and I certainly think having functionality for the reverse (pinning server identities) should exist too.
Doesn't have to be Gemini even, but I think getting buy in from browser vendors after the removal of HPKP is going to be a problem...
Except they already do. Also, AMD announced SmartShift ("shifts power inside your laptop for the optimal performance for a given task") support for Linux a couple of days ago. They're more than usable nowadays.
Probably a popular opinion here, but any display with a higher res than 1440p (1600p if it's a 16:10 display) is a waste on a laptop. I'd rather have a 1080p one over a 4K one, personally.
> Except they already do. Also, AMD announced SmartShift ("shifts power inside your laptop for the optimal performance for a given task") support for Linux a couple of days ago. They're more than usable nowadays.
Interesting, thanks!
> Probably a popular opinion here, but any display with a higher res than 1440p (1600p if it's a 16:10 display) is a waste on a laptop. I'd rather have a 1080p one over a 4K one, personally.
I don't disagree that 4k is a little nuts on a ~15" laptop LCD, but it seems until recently you're options for decent >1080p displays on laptops for the most part were a) Macbooks (2880x1800 at 15.4"), and b) 4k PC laptops