I don't know why you would need a tensor whatever. Dump the state of the router (which peers are connected and for how long what routes are they advertising and for how long) as well as the computed routing table and what routes are advertised to peers.
Set a simulation router to have the same state but a new config, and compute the routing table and what routes would he advertised to peers.
Confirm the diff in routing table and advertised routes is reasonable.
This change seemed to mostly be about a single location. Other BGP config changes leading to problems are often global changes, but you can check diffs and apply the config change one host at a time. You can't really make a simultaneous change anyway. Maybe one host changing is ok, but the Nth one causes a problem... CF has a lot of BGP routers, so maybe checking every diff is too much, but at least check a few.
Is that something out of the box on routers? I don't know, people with BGP routers never let me play with them. But given the BGP haiku, I'd want something like that before I messed around with things. For the price you pay for these fancy routers, you should be able to buy an extra few to run sandboxed config testing on. You could also simulate with open source bgp software, but the proprietary BGP daemon on the router might not act like the open source one does.
I have a 2014 car that's connectable but no driver assistance; I had a 2017 (delivered mid 2016) with lane keeping and emergency braking which seemed pretty new and exciting, and it's connectable, all I would need to do is pay a big annual fee and also setup a 3g CDMA network. Couldn't do much with either if it's connected; I pulled the 3g modem from the 2014 when it was convenient cause I was worried it was using power while off.
Not that lane keeping needs a connection, just that I'm surprised they put it on a car without a modem.
To my knowledge it is completely offline. The fanciest version of it (Honda Civic) has wifi and will connect to your house wifi when in range (and also do wireless Android Auto) but mine doesn't have it. This one has no cloud features and if there's a SIM card lurking deeply in there somehwere, it certainly isn't going to facilitate reaching down to monitor me in the car (the hardware isn't there, aside from the microphone for bluetooth) or change features on me.
I won't claim to know for certain but want to point out that if there's a SIM card in the head unit then it can upload anything it can see on the CAN bus which is literally every sensor in the vehicle. I guess the only thing likely to be missing is a cockpit video feed.
Even if it doesn't offer the user an option to connect AFAIK approximately all vehicles from the past 15 years or so are part of the internet of shit. They send telemetry back to the manufacturer.
My 2016 Corolla has zero advertised connectivity features. It could secretly be sending data somehow, but far as I've been able to tell there's no modem.
Do you need a guarantee or is enough that it's painful enough for the BSD maintainers when they remove syscalls that they rarely do it? It's even worse if they renumber them so that really doesn't happen outside of syscalls that were only briefly available in a development branch.
Varies a bit by flavor: OpenBSD values security more than stability, so they are willing to break old binaries more often; FreeBSD does require compat modules/etc for some things, but those are available for a long time and sometimes something slips through.
If they break old syscalls, it breaks your code that skips libc, but it also breaks running an old userland with a new kernel and that needs to work for upgrade scenarios. It also breaks binaries that were statically linked with an older libc. When a new kernel breaks old binaries, people stop upgrading the kernel and that's not what maintainers want.
> There's also nothing to prevent bad actors from destroying ballots in large quantities.
Around here (WA state), you can check to see if your ballot was received and accepted. If a bad actor destroys ballots in large quantities on their way to voters, many voters will notice and complain. If a bad actor destroys ballots in large quantities on their way to to the counting facility, some voters are likely to notice and complain.
Same goes if you return ballots for other people. Either the actual voter notices their ballot is missing or the vote counters notice they got two ballots from the same voter or a larger than usual number of bad signatures.
Is it foolproof? No. And there's usually no established procedure to cure a tampered election, either. But large scale tampering is likely to leave signs. And small scale tampering would only rarely make a difference in results.
In person voting might be more secure, but it takes a lot more people, and if you want an ID requirement, you need to figure out how to make ID acheivable for all the voters or it's really just a tool to disenfranchise people who have trouble getting ID. In the US, there is no blanket ID requirement, so there are a lot of eligible voters without ID.
No one has trouble getting an ID. You need an ID to drive, to work, to open a bank account, to buy liquor or tobacco, etc. The idea that someone can’t get an ID is absolute nonsense.
Not a problem. We should pay for them to get proper identification. This is likely an infinitesimally small percentage of the population qualified to vote. As the other commenter said, you need identification for most important things in life. Yet, again, if someone does not have ID and they want to vote, it should be easy and free. If they can't drive, we pay for an Uber. If they don't understand the process, we pay for a coach. Etc. This is the kind of process that reduces to zero over time. If you process 100K people on year one, there might only be a couple of thousand people the following year...and down to zero it goes.
> There is no force acting on it to bring it back down.
Gravity?
But also orbital dynamics (at least as I understand it) means debris that debris that is flung up is going to have a more oval orbit, so the high point (apogee) increases and the low point (perigee) decreases. And a lower perigee means more atmospheric drag, which will help deorbit the debris.
>means debris that debris that is flung up is going to have a more oval orbit, so the high point (apogee) increases and the low point (perigee) decreases. And a lower perigee means more atmospheric drag, which will help deorbit the debris.
Not quite.
If you are at apogee and accelerate, your perigee will be raised. If you are at perigee and accelerate, your apogee will be raised. You can't increase your apogee and perigee at the same time.
If the impulse is in the direction of orbit, then the altitude of your orbit 180 degrees from your current position will raise. If the impulse is against your orbital direction, your height 180 deg away will be lowered. Once you complete an entire orbit (360 degrees) you will pass through your current position again.
If you wish to move to a higher, circular orbit two impulses are required, 180 deg apart.
If you divest US bonds, you would probably put them into bonds from other nations (and corporate bonds from non-US companies), easiest thing is to try to find a index to track; Vanguard's BNDX tracks the Bloomberg Global Aggregate ex-USD Float Adjusted RIC Capped Index (Hedged).
In a mark to market world, the value of a bond is its acquisition cost, so buying bonds enough to raise prices increases their value, but not their coupons or their face value. It's hard to make sense of the value of a sequence of payments, it's reasonable to consider the present value and the market price is an easily justified present value for a bond.
Selling bonds and buying stocks is a different thing altogether. Selling US stocks and buying EU stocks wouldn't change the value of the underlying assets, however, having an increased stock price does have benefits for the company when issuing new shares or bonds.
You would presumably supply usb floppy drives on the way back in time, and then you'd be alright. And an ethernet NIC with 10base2 and AUI for thicknet, cause twisted pair wasn't typical that early.
Network booting PCs happened a lot later, but if the booter used bios calls to access the disk, you could probably netboot that too.
I got a similar deal; the phone was locked to tracfone (or one of the other verizon owned mvnos), no contract, just had to activate it and pay the first month's service. When the month was up, put it in a drawer. 60 days from activation, pull it from the drawer, connect to wifi, and it would unlock.
> Why is anyone even tolerating a carrier selling them a phone locked for a single day (unless it is free with plan or something in which case there's nothing wrong)?
I sometimes buy carrier locked phones when the unlock period is reasonable and the locked phone + the required service is a good deal compared to buying unlocked.
I don't think a 1 year locked period is reasonable though, unless it was locked to the carrier I actually intend to use.
Verizon around the Nexus 5 still had a lot of CDMA and you needed to have a phone activated.
Now that networks are pretty much LTE and 5G only, if your phone takes a SIM, take the SIM out of the old phone and put it in the new phone. Some carriers still play games with allowlists for VoLTE though.
But you might have better luck (and better pricing) with a MVNO or the prepaid side of your preferred carrier.
Allowlists for VoLTE are a perfectly reasonable (if extremely unfortunate) safety measure.
Because of the special handling that emergency calls must get in cellular networks, many older phones will use circuit-switched fallback (AKA 3g or 2G) for those calls, even if they are otherwise VoLTE capable.
This was pretty much fine back in the day, as 2g and 3g networks were just as (if not more) widespread as VoLTE, but those networks are now being shut down. If you have one of these phones and an LTE-only carrier allows it onto their network, you will be able to make any normal call, but emergency calls will not work.
To add insult to injury, there's no way for the carrier to tell whether any specific phone does emergency calls over VoLTE or not, especially if they don't have a contract with that vendor. Some phones may only do it in certain configurations, E.G. when branded for that specific carrier and configured with their preferred modem settings.
Set a simulation router to have the same state but a new config, and compute the routing table and what routes would he advertised to peers.
Confirm the diff in routing table and advertised routes is reasonable.
This change seemed to mostly be about a single location. Other BGP config changes leading to problems are often global changes, but you can check diffs and apply the config change one host at a time. You can't really make a simultaneous change anyway. Maybe one host changing is ok, but the Nth one causes a problem... CF has a lot of BGP routers, so maybe checking every diff is too much, but at least check a few.
Is that something out of the box on routers? I don't know, people with BGP routers never let me play with them. But given the BGP haiku, I'd want something like that before I messed around with things. For the price you pay for these fancy routers, you should be able to buy an extra few to run sandboxed config testing on. You could also simulate with open source bgp software, but the proprietary BGP daemon on the router might not act like the open source one does.
reply