There is distinction between seeing when events happened, and when they really happened. The latter can be reconstructed by an observer.
In special relativity, time is relative and when things actually happened can be different in different frames. Casually linked events are always really in the same order. But disconnected events can be seen in different orders depending on speed of observer.
> But disconnected events can be seen in different orders depending on speed of observer.
What are "disconnected events"? In a subtle but still real sense, are not all events causally linked? e.g. gravitationally, magnetically, subatomically or quantumly?
I can understand that our simple minds and computational abilities lead us to consider events "far away" from each other as "disconnected" for practical reasons. But are they really not causally connected in a subtle way?
There are pieces of space time that are clearly, obviously causally connected to each other. And there are far away regions of the universe that are, practically speaking, causally disconnected from things "around here". But wouldn't these causally disjoint regions overlap with each other, stringing together a chain of causality from anywhere to anywhere?
Or is there a complete vacuum of insulation between some truly disconnected events that don't overlap with any other observational light cone or frame of reference at all?
We now know that gravity moves at the speed of light. Imagie that you aretwo supernovas that for some unknown reason, explode at essentially the same time. Just before you die from radiation exposure, you will see the light pulse from each supernova before each supernova can 'see' the gravitational disruption caused by the other. Maybe a gravity wave can push a chain reaction on the verge of happening into either a) happening or b) being delayed for a brief time, but the second explosion happened before the pulse from the first could have arrived. So you're pretty sure they aren't causally linked.
However if they were both triggered by a binary black hole merger, then they're dependent events but not on each other.
But I think the general discussion is more of a 'Han shot first' sort. One intelligent system reacting to an action of another intelligent system, and not being able to discern as a person from a different reference frame as to who started it and who reacted. So I suppose when we have relativistic duels we will have to preserve the role of the 'second' as a witness to the events. Or we will have to just shrug and find something else to worry about.
Causality moves at the speed of light. Events that are farther apart are called spacelike and aren't causally connected.
I think you might be confusing events that have some history between them, and those are influence each other. Like say right now, Martian rover sends message to Earth and Earth sends message to them, those aren't causally connected cause don't know about the other message until light speed delay has passed.
> But wouldn't these causally disjoint regions overlap with each other
Yes.
> stringing together a chain of causality from anywhere to anywhere?
No? Causality reaching one edge of a sphere doesn't mean it instantaneously teleports to every point in that same sphere. This isn't a transitive relationship.
> What are "disconnected events"?
The sentence you're responding to seems like a decent definition. Disconnected events are events which might be observed in either order depending on the position of an observer.
One thing is that you need to tell the insulin pump when you eat food so it can deliver insulin to cover the food. I bet that is a lot easier in an app than some separate controller device.
Insulin pumps are paired with glucose monitor. I bet it is handy to check glucose levels to make things are stable and correct if off.
Passkeys work well with password manager. The password manager also stores the long random password to get in without passkey. The advantage is that passkeys are immune to phishing. Sites also turn off 2FA for passkeys which reduces the hassle.
I think it's more than fair to document that some implementations lie about their intentional violation of the spec, even if that violation is done to make the login process smoother.
Still, I've never seen a website try to block Bitwarden's passkey management (though I've had plenty of issues because of its partial implementation of the API, especially in early versions) despite its spec violations.
For some of the implementations, user verification is a massive pain (as browser extensions often only have long and complicated passwords to authenticate) but for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
> Still, I've never seen a website try to block Bitwarden's passkey management
Ideally it shouldn't be possible, or at least it should clearly be an ugly hack for a website to be doing something like this. Instead the spec authors explicitly endorse blocking clients that they feel are non-compliant. I'm not going to use a login spec that encourages websites to ban me because of the software I choose to use.
> for KeepassXC a quick and simple fingerprint/facial scan is an option, as it already offers integration into the native OS biometrics anyway.
Man don't get me started on the passkey environment's bizarre obsession with biometrics. My desktop computer doesn't have a fingerprint reader or a camera, and if my OS (Arch Linux) supports that junk I've certainly got no interest in doing the work to set it up just so I can log in to a website.
Documenting is fine, but the passkey spec author has been recommending blacklisting these so they don't work. It will end in a situation where only the Apple, Google and Microsoft passkey managers are the only way to log into any website.
Most places that need accurate time get it from GPS. That is 10-100 ns.
Also, you can use multiple NIST servers. They have ones in Fort Collins, CO and Gaithersburg, MD. Most places shouldn't use NIST directly but Stratum 1 name servers.
Finally, NTP isn't accurate enough, 10-100 ms, for microsecond error to matter.
Why are you setting up anything? You turn on IPv6, the router figures out its prefix from the upstream router, and then router broadcasts the network to devices.
The netmask for IPv6 is nearly always /64. ISPs give out /60 to allow multiple subnets, but router makes /64 subnets from that.
Not OP, but when I first tried to learn IPv6 for my home internet, I found that it's very important that you get the DHCP-PD prefix size right when configuring your router, or it would just not work at all.
I have Comcast, and they do give me a /56, but you can't ask for a /56 in the DHCP-PD request, because they don't support a single request grabbing all of your prefix space. You have to ask for /60's, which I had to find out through trial and error.
But it may have been even worse (my memory is fuzzy) because I think at one point I did successfully get a /56, but that then exhausted my DHCP allocation, and then after I rebooted my router I couldn't get anything any more. It didn't help that the router I had been using (Unifi security gateway) didn't seem to keep a static DUID that comcast was happy with, so I kept getting new prefixes every time it rebooted.
Comcast probably has so few customers that bring their own cable modem/router at this point that they basically don't have any support for this, you won't get anything from them over the phone, they just push you to pay them to rent their equipment (where they configure all these parts the way their network expects.) You have to be adventurous to run your own equipment with IPv6.
Nah. There are lots of things you’ll need to know.
Does it use SLAAC on the WAN side or DHCPv6? How do I get a range for my lan then, DHCPv6 prefix-delegation? Or maybe it’s statically assigned somehow. Some carrier’s just use link-local ok the WAN, with no public v6 just RAs for the link-local, and a GUA block via IA_PD.
Regardless there are too many ways this is done, and this hampers adoption as it’s not just the “switch it on” operation you suggest.
All of those are handled automatically. The only people who have problems are ones who want to configure manually. More importantly, this is no different than IPv4 where have DHCP or manual.
Nearly every ISP uses DHCPv6-PD cause harder for manual configuration. The range is in the DHCP-PD, your router picks a subnet. The WAN address is automatic, and don't care about it cause never see it. Mine is link-local and hadn't known until I checked.
You find out the addresses after it is configured automatically. This is no different than IPv4 and DHCP.
If you don't want to use the public addresses internally, then you can assign ULA addresses. If you don't want to use MAC derived addresses, assign them static host addresses.
For names, I use mDNS. I don't know the IPv6 address for my server. If I did need it, I would get it from the router.
Receivers are big because of the amplifiers. AV receivers have to drive lots of channels. They are all 5.1 or 7.1. But stereo receivers are also huge.
I suspect that some of this is tradition because there are small solid state amplifiers. I'm surprised no one has made a small receiver for 2.1 system cause would be pretty common.
If you open a standard sized receiver up, you'll probably see that 50% the space is empty for airflow, 25% of the space is for a large heatsink because they're passively cooled to minimize noise (thus the need for airflow), and 20% of the space is really big capacitors.
They do make half size receivers, but they typically only have half the power output. The space savings comes from removing space for airflow and the heatsink, and using smaller capacitors for less heat and smaller power output.
If you only need 2.1 output and a quarter of the power, there are offerings that are basically the size of the minimum amount of ports: 2 pairs of speaker terminals, a pair of RCA terminals for subwoofer out, a HDMI port, a optical port, and power. But then it's not really a receiver and more just of an amplifier+DAC because they only have one HDMI input/output, having space for multiple HDMI ports or speaker terminals basically increases the size to the offering above.
They're big mostly because consumers demand a lot of big connectors on them.
Sometimes I see cheap "amplifier only" designs that are about the size of a small 2U rackmount, but then you usually give up a lot of inputs and controls; they seem to be used either as PA amplifiers or as "extra room" units in the weird whole-house audio systems that apparently thousands of people had at one point and all dumped in the Goodwill.
They do have multiple clocks and sites. The primary clock is in Boulder. Only the Maryland time servers are affected, the Colorado ones should be fine. They mention switching to another atomic clock, but that probably has to be setup.
The email explains why they haven't shut down, cause haven't hit the threshold. And talks about maybe shutting them down manually.
reply