error503

Depends on the access technology and environment. But usually there is not much choice to be made, by design. The cable or equivalent from the customer prem will go to exactly one aggregation location, and in that location, the choice of port generally doesn't matter. Among the potentially multiple cables or ports, they're all meant to be functionally the same. Maybe something is wrong with a cable or port, and that will hopefully come out in post-install testing, but there's not meant to be much of a decision to be made for commodity service like DSL or GPON (anything that'd use BNG). It's typically just going to be up to the last metre installer.

Metro ethernet services will be designed by an engineering team on a case-by-case basis, but they very rarely if ever use BNG.

> - Currently, the circuit where the user connects is arbitrarily decided by the demo user. In a real system with thousands of circuits, it'd be very difficult to properly assess which circuit the customer might connect to. When adding a new customer to a service, how does the operator decide, based on customer's location, which circuit to provide the service to ?

I'm not exactly sure what you're asking, but port allocation is, depending on the ISP's deployment model, either going to be fixed at the time the infrastructure was built, or whoever is doing the last metre install will choose a random available port on the switch. The subscriber will be assigned to that port in the RADIUS or equivalent database, and the BNG will query the subscriber based on DHCP Option 82 port information added by the switch. You could also map the subscriber based on MAC address, but this doesn't really work unless you don't support customer provided equipment on their end.

Why would it be non-standard? USB-PD is almost completely decoupled from the rest of USB, and USB-C connector doesn't imply 'super speed' lanes are available. The only thing it really changes from an implementation perspective is that you don't have to route high speed lanes to the port, and don't need them to be available on your USB controller.

Doesn't seem to be very Apple-like to have two identical looking ports with different function, though.

And when Android follows Apple's lead, then what?

The consumer harm is obvious. Whether you call it a "monopoly" or something else, it is a problem that needs to be addressed.

They don't even need to know it is a thing that exists. The defaults (ie. the status quo of implied trust in the OS vendor) are fine for this type of user.

So you think it's okay for manufacturers to take advantage of users as long as they continue buying the locked-down devices? I disagree, and I think this argument is incredibly disingenuous. You could make the same specious argument about nearly any consumer protection or antitrust case. Just because consumers will put up with it, or because they are manipulated into believing it's good for them, doesn't mean they shouldn't be protected.

Furthermore, if you fundamentally allow this behaviour, the market forces are sure to push us to an end state where users simply have no control, and there are no viable alternatives. We are most of the way there already when it comes to smartphones. The cost of entry to this market (many $billions over many years, if you can even manage to gain meaningful marketshare at all), and the amount of money that is on the table (30% of the $billions transacted on a successful platform today, but who knows how far they push with a real stranglehold) means that it is virtually impossible for competition to solve this problem.

That was intended to be a generic 'device manufacturer', not calling out Google and Apple specifically. It's my device. I should control it, full stop. It should simply not be legal for a device manufacturer to lock me out of a device I own, post sale. In the past it wasn't _possible_, so we didn't need to worry about it. But now the tech is at the point where manufacturers can create digital locks which simply cannot be broken, and give them full control of devices they sell (ie. which they no longer own), which are being used in anti-consumer ways.

Considering market forces are against it, I believe the only practical way to accomplish this in the long term is for this to be a right that is enforced by legislation. I don't think it is even far from precedent surrounding first sale doctrine and things like Magnuson-Moss, that the user should be the ultimate one in control post-purchase, it just takes a different shape when we're talking about computing technology.

Ultimate control over devices you own should be a basic right. Apple's wanton abuse of users and developers via the control they have over their platform, and Google's nipping at their heels, should be evidence enough of that.

Fundamentally, it is a trust issue. Why should I be forced to trust Google or Apple has my best interests in mind (they don't)? That is not ensuring 'device integrity', it's ensuring that I am at the whims of a corporation which doesn't care about me and will leverage what it can to extract as much blood as it can from me. You can ensure 'device integrity' without putting any permanent trust in Google or Apple.

If they're injecting targeted ads in the stream, then the stream producer must be 'smart'. It's not much of a stretch for it to enforce playing out the segments at approximately realtime (or whatever speedup they want to allow), and to force the advert segments to play out before anything past them. Some sidechannel could be used to inform the client about what's going on and produce a sensible playhead position.

It seems inevitable that this is the end game, and I don't really see viable ways around it for realtime playback. For offline playback, yeah, presumably that sidechannel includes enough information to cut out the ads.

Recovery codes is an option, for one.

Since we're talking about a legacy bank here, going to a branch and proving your identity is an option.

Worst case, you could always call and speak to a human who will do whatever verification they do if you forgot your password, which is functionally equivalent.

Try Aegis https://getaegis.app/

There is a distinction between the variable itself and its name. Const (and Rust's immutability-by-default) ensures that the variable does not change after assignment. This holds true even as references to it are passed to other functions or stored for later use. You "can't" accidentally pass a reference to that variable which will then be unexpectedly mutated a dozen calls deep into a library function you didn't write.

If you have shadowing, it simply means you can have a different variable with the same name later in the same (or child) scope, this usually must be explicit. The same name now refers to a different variable, but the original variable still exists and remains valid.

It's quite a useful pattern, particularly where the old value is no longer useful (for example transforming input), especially when using the old value might be valid code but would be a mistake.

It's a bit ironic that this page doesn't include a usage of the icon or any localization at all.

Did you even watch the video? He walks directly beside it several times.

The 'fan' in this very video is pretty dangerous, even ignoring its cobbled-together nature.

It's an old anecdote, but years ago Samsung refused a warranty claim for a _failed USB port_ that would no longer charge the phone _because I had rooted it_ and the fuses were burnt. I think this was unreasonable of them, but it's not like I had any recourse. If vendors were really worried about this aspect, they would/could implement such draconian policies.

> I hadn't even imagined this constituting "brute force". Is my phone using "brute force" to find the WiFi router? At some point it's not really "Brute force" it's "There are a handful of options, try all of them" and GPS seems past that point especially on modern hardware.

Your phone only needs to listen to the WiFi router on one channel at a time in operation, and the signal parameters are well enough defined that they can be scanned quickly. A GPS receiver requires at least 4 parallel channels to achieve a position solution, and there are up to 32 possible codes the satellites could be at. Scanning 6 channels across 32 codes, and then also sweeping phase and doppler shift to lock them , just to 'discover' if there is a valid signal there takes time, and this is what older receivers had to do. Modern receivers tend to just 'brute force' this by having an entire receive pipeline dedicated to every possible PRN all the time, and possibly even correlate multiple doppler shifts simultaneously as well, so they effectively have 32 (or more) receive channels, despite only ever expecting a maximum of 12 birds being visible. The extra channels are necessary more or less exclusively to reduce acquisition time, so I think it's fair to call them 'brute force'.

No, the fact that all of these ships show the same false location strongly suggests that they are being spoofed from a single terrestrial source; this effect is not practical to achieve by modifying the signals transmitted by the satellites, even if the US wanted to for some reason.

There's a report on very similar jamming happening during the Syria conflict that will hopefully be enlightening as the methods and actors are presumably similar https://c4ads.org/wp-content/uploads/2022/05/AboveUsOnlyStar...

> making everyone appear at exactly the same location would be nigh-impossible, though.

I don't think this is actually the case. In a spoofing scenario, all of the rogue signals would typically be generated by a single terrestrial station. The time of flight of all of the generated signals will be the same, so all that matters is the position solution reflected in the transmitted signals, as the fundamental principle of GPS based on TOF is no longer in play. So I'd think that in a typical spoofing scenario, all receivers thinking they're in more or less an identical location is what you'd expect.

It might be possible in a borderline case for the receiver to receive some spoofed signals and some real signals simultaneously, in which case you'd expect weird results, but I think you'd definitely see a correlation around the position being broadcast by the spoofer.

You're more or less inside a Faraday cage. I find you'll generally get a strong lock just holding your phone near the window, though TTFF can be relatively slow compared to normal due to the lack of AGPS.

Nobody remotely versed in this stuff would expect SMS to be end-to-end encrypted, though to be honest the more notable fact to me here is that Apple can read any plaintext in your backups. iMessage is an over the top messaging service more akin to WhatsApp or Signal than it is to SMS, so that is a more relevant comparison. I don't know if any of the clients store plaintext messages that would be backed up to Apple in a similar manner or not, but I'd hope at least the more security focused ones do not.

Apple makes privacy claims about iMessage including 'Apple can’t decrypt the data.', which is notably false in this (common) scenario, and requires a large asterisk on those claims, IMO bordering on making them unethical, period.

Yes, this was the root of the miscommunication. The AoA indicator (ie. an instrument that gives a numeric value of AoA to the pilots) was optional. The AoA disagree alert (ie. an indication that the two AoA sensors do not agree) was not intended to be optional, and I believe it's required equipment, but it ended up tied to the indicator option. What is worth noting about this is that Boeing knew about it for a long time (I forget the timeline, but at least a year, I believe), without telling airlines or releasing a fix.

I'm not sure where the NYT information comes form that AOA DISAGREE was an option. The congressional report https://democrats-transportation.house.gov/imo/media/doc/202... is pretty clear on this aspect:

> Boeing has publicly blamed its software supplier, a company now known as Collins Aerospace Systems, for tying the AOA Disagree alert, which was supposed to be a standard feature on all 737 MAX aircraft, to an optional AOA Indicator display714—the result of which rendered the AOA Disagree alert inoperable on more than 80 percent of the MAX aircraft.

> At the end of the day, if the person who wrote that software had written it differently, then those planes would not have crashed and hundreds of people would not have died.

You can't really blame the software engineers. This was all thought out and tightly specified by Boeing to their avionics subcontractor (Collins, IIRC). This is how it was designed and engineered to work at a systems level - it is a design hack. As far as I know there weren't any software bugs or 'hacks' involved, and the avionics operated as designed (aside from the AoA DISAGREE alert, which was due to a requirements miscommunication, not a bug). It was broken by design, which happened long before implementation, at Boeing.

> When the flight computer trims the airplane to descend, because the MCAS system thinks it’s about to stall, a set of motors and jacks push the pilot’s control columns forward. It turns out that the Elevator Feel Computer can put a lot of force into that column—indeed, so much force that a human pilot can quickly become exhausted trying to pull the column back, trying to tell the computer that this really, really should not be happening.

The Elevator Feel Computer is a part of the 737NG as well, and would behave the same way in those airplanes when receiving such erroneous AoA data; it's nothing new in the MAX. It certainly did not help the crews during the fatal MAX incidents, and is clearly not an ideal design, but it's also barely a footnote in the root cause analysis, along with the stick shaker and stall warnings blaring at them constantly. The pilots would easily be able to overcome it long enough to get safely on the ground. What was a bigger problem for those crews was that the MCAS has enough trim authority to make it impossible, with any amount of elevator input, to restore level flight - limiting its trim authority was part of the 'fixes' required to get them airborne again.

I don't think it's reasonable to blame the implementation of MCAS for the accidents, its existence is to blame, and really highlights how nothing about the 737 platform has been designed holistically - it is a patchwork of hacks on hacks dating from the 1970s, which is difficult to reason about as a whole, and has dark corners. To truly 'fix' MCAS, you need to consider AoA as critical air data (which the 737 does not), and you need to integrate it holistically with the rest of the flight controls (which the 737 cannot, since it is not fly-by-wire), and you need to consider it critical equipment (it's an 'augmentation' and not considered critical on the 737, 'justifying' the lack of redundancy). Once you've done those things, you've basically got the bones of a proper envelope protection system in place, and you've obviated the need for MCAS in the first place. Of course the 737 team couldn't do this, because the business decided that it was more important to avoid (and hide) any differences than to bring the aircraft in line with modern standards.

Realistically, this should have been trapped by the safety analysis of the flawed design, which should have considered its effect on the whole flight control system when evaluating it, but Boeing again only considered MCAS to be an 'augmentation' and it got an abbreviated safety review as a result. Some engineers did express concern about some of these factors, but given the environment outlined in TFA, those concerns did not go anywhere, because they would have basically scuttled the idea and sent everyone back to the drawing board, which Boeing was desperate to avoid having already been caught flat-footed with the launch of the A320neo.

The 737 airframe needs to be put to rest, it is simply not safe or sane to keep stacking more hacks onto it. But there's no indication Boeing's working on a successor so it's probably going to be on the market for another 20+ years. Hard to imagine folks will probably be flying on an airframe with a 100 year old design (2024 + 20 years before a new revision + 20 years life span = 2064, around 100 years from the 737 launch before they start retiring)!

There've been so many issues it's definitely getting confusing, but the thing blocking the MAX10 certification is a problem with the engine anti-ice system.

You're correct that this problem exists on all MAX variants, but those other variants are already certified (the issue was discovered post certification), and it's deemed to be not severe enough / with a good enough mitigation that they are allowing Boeing some time to come up with a fix for the already-certified design, and continue producing it. The expectation is that once Boeing has a proper fix and retrofit plan, it will be required by an AD on all aircraft. However it's unlikely the FAA will certify the new MAX10 variant with this known issue, and so far Boeing doesn't have a fix.

It shouldn't be that bad, CloudFlare's anycast should direct you to a nearby resolver, and doing your GeoDNS on that resolver IP instead of ECS is probably not that much worse than doing it on the actual client IP. Both approaches aren't great at picking an ideal CDN node, GeoIP is notoriously unreliable, and it tells you nothing about network topology.

Breaking DNS entirely is much worse behaviour, especially because GeoDNS itself is arguably not in the spirit of DNS which is distributing a consistent database, not making it up on the fly based on the client's info. The archive.is admin is being ridiculous, the least they could do is block anyone not using a resolver supporting ECS to be consistent, but no they have something personal against Cloudflare.

I occasionally click on Sponsored search results, if they're what I'm looking for and I don't much care for the company on the other end of the link. Take that, Big Corporate!

Really? It doesn't seem to me like it gets any more trivial than 'hit DNS for the domain to find federation server, send a GET request' to me. You could even do the whole thing with DNS, though that has privacy implications. What am I missing?

It can't be mutual because the receivers don't broadcast, so the sender doesn't know which contacts are in range.

I was also thinking you might be able to use asymmetric crypto for this, and encrypt the hash + a nonce using your private key, and anyone with your public key can decrypt it and check the hash against the contact list. But this means the potential receiver needs to decrypt with every public key it knows, which for large contact lists might be prohibitively expensive.

Someone has probably devised a more clever way, though.

Fundamentally this verification is based on your contact list, which is formed from people you already know and have added to your contacts, so there's not really any need for a centralized trust. Presumably you trust the e-mail address of the contact you added, and the federation protocol could easily define how the authoritative hash/key for each user would be shared based on their e-mail.

In most cases this could also be resolved at first contact in meatspace, directly between the devices when establishing contact via the typical ways users share contact information - QR code or some form of short range networking, or even with an SMS challenge.

> My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.

What a way to twist things around. Apple (or the app developer, who chooses Apple to distribute their software) doesn't have the right to distribute the code without abiding by the terms of the license. Copyright applies by default unless those terms are met.

TiVo's code wasn't subject to the GPL, so obviously they can have it do whatever they want, it's not remotely analogous to distributing copyrighted works outside the terms of the license that is the only thing allowing you to distribute them at all.

Cryptographic controls might be an end-run around this (as they are being abused for many other anti-consumer purposes today). The license tries to account for this, but it looks like it only applies if the code is included with the device. Unfortunately. The law really needs to catch up with this, it's clearly a hack and not respecting the intent of this or other areas of law such as first-sale doctrine.