error503

Good, I don't know why I should have a problem with that?

Though I disagree that a phone is not a 'general computing device' moreso than a gaming console is, it is hard to come up with a legally-clear definition of one.

>Of course, for GPL code, their customers could redistribute the source code.

The fact that the subscription agreement does not allow this is exactly what we're discussing here.

In what ways can a purely electronic, no moving parts, switch fail?

There are so many different mechanical things that can break, jam, get gummed up...

Surely is a very strong statement here. I see no reason that a properly designed electronic timer wouldn't have effectively infinite lifetime, which is not possible with a practical mechanical timer. It has no moving parts (other than switches, which can be substituted for capacitive touch). A mechanical timer has many small mechanical parts and wear points, and can get gummed up over time if it doesn't outright stop functioning.

In practice, cost engineering is going to mean neither is completely reliable, but it should be cheaper to make an electronic timer reliable enough. Especially today, where the cost of a functioning mechanical timer is probably an order of magnitude more than an equivalent electronic timer.

Probably depends on which body you are using. In mine it both flashes a tiny LED and does an extra little buzz-buzz buzz-buzz signal with the ultrasonics when you turn it on (or off, can't recall which) when the head has 'expired'. Continues to work fine, though.

You might be interested in this YouTube video from Applied Science with electron micrographs of 'new' and 'worn' toothbrush bristles - there is a very marked invisible change that happens: https://www.youtube.com/watch?v=cwN983PnJoA

Since the thread is about YVR, it's actually pretty easy and safe to walk all the way to Richmond (or a shorter distance to the east side of Sea Island which has normal businesses / residences). Sidewalks all the way from the terminal, and no crazy crossings are required. I'm sure this isn't typical, but if you don't mind the walk it's perfectly viable in this case.

You can also take the SkyTrain for free within Sea Island (which is not well known, I feel) - 2 stops to Templeton, and there are probably plenty of Ubers around there, since there is an outlet mall near that station, or at least a much shorter walk into Richmond.

It's been fully independent for like 10 years, and existed as a commercial product for over 20, so I think it is pretty safe from 'startup' risk.

What evidence do you have to blame the cable for the blue smoke escaping? It isn't really plausible for a bad USB-C cable to cause a device to fail in that way, at least unless the device itself was incredibly poorly engineered.

There is a reasonable argument that standards should be more stringently validated and adhered to (in many areas, not just charging cables), but giving Apple the keys to the market and the ability to charge whatever they want is not the answer.

No, they didn't vote for headphone jacks to be removed, they were forced to decide whether it was a dealbreaker for them. This kind of incremental erosion of the user experience is a very different thing than consumers making a binary choice about what they would prefer. They 'get away' with it, then it becomes the new normal, and the previous experience becomes niche and expensive or comes with other compromises.

d) write to a temp file and atomically move it onto the read path. you will miss counts, but nothing will break.

Should they is arguable.

But I think in this case it's pretty much required for good UX with the way file syncing works on mobile and in the browser, especially dealing with conflicts. I've done it both ways and there is a lot less friction with vaultwarden than my old 'synced KeePass file' approach.

It was just a suggestion, there are other ways to skin the cat.

How do you propose to sync a file without a server? What do you do about conflicts? Sure you can do this, but IMO the experience sucks in comparison.

Self-host vaultwarden at the cloud provider of your choice?

It doesn't look like (from TFA or the collected spreadsheets) there's enough information collected (2nd choices) at the polls to support an instant runoff. So they'd need to go back to the polls for a traditional runoff if that were the case.

I collected all the _crosschecked CSVs and got:

  LP       PDP      APC      NNPP
  4731127  4555334  5928825  1019045

Obi seems to make second place here, but far from first.

https://i.imgur.com/UaZbXz6.png

You keep saying that, but you have yet to provide any evidence. What essential drivers were reverse engineered, exactly. As far as I can tell, everything required to boot to a working graphical desktop is well documented.

I'm not giving credit to Lenovo, I'm saying that the platform is mostly open because it is based on mostly open components. In contrast to Apple's devices, where the platform is closed because it is based on undocumented components. You could say the same about pretty much any standard PC, Lenovo is just one of many vendors, I have no idea why they got singled out here.

But they do sell boxes explicitly qualified and supported to run Linux, and they do contribute to the Linux kernel development process.

The fact remains that claiming any of Apple's hardware platforms are remotely open is laughable.

> False. Lenovo hardware contains a lot of proprietary undocumented parts that required reverse engineering to get working on Linux/BSD. The parts that didn't require reverse engineering (Intel GPU) were not made by Lenovo.

How is it false? Whether the parts were made by Lenovo or not is irrelevant. It may not be 100% open (and this is probably not due to parts that Lenovo themselves created), but it is substantially open, which is far more than can be said about the Macs, which are virtually undocumented system-architecture wise, and who knows what Apple will do in the future to hamstring efforts to use them outside the walled garden.

> Apple hardware is "open" as far as they don't try to prevent other operating systems to be installed. Apparently they made it reasonably straightforward for the Asahi team.

That is not "open", it's just "not openly hostile to reverse engineering...yet".

Sure it has some undocumented subsystems, but compared to the Macs, it has a much stronger claim to openness. Apple has released virtually no information on the internals of these machines, and they aren't standard PCs like the Lenovos. Calling them 'open' is absurd, it would be hard to imagine a publicly released general-purpose computer that is less open.

I believe the amount of organophosphates has been studied on 'normal' flights, but considering these events are estimated to be 1/5000-1/50000 flights, you need a lot more than one person to capture a statistically significant sample. But considering the number of flights per day, that's a few events per day and is probably worth investigating.

There have been some post-facto blood tests trying to find if crew who noticed these fumes had detectable byproducts in their blood, which mostly found nothing, but this doesn't say much about whether the environment in the aircraft is safe when these events occur, especially since significant and acute harm seems relatively rare among these incidents.

I think the concern is generally air coming from the bleed air system (air that has been redirected from the engine core's compressor stages, prior to combustion) which is used to pressurize the plane. This can come from either the main engines or the APU, but in-flight it's almost always going to be the main engines and the APU will be shut down. During a potential fume event, if the APU is supplying bleed air the packs could generally just be turned off, the APU shut down, or the aircraft deplaned, since it's probably on the ground. Obviously you don't have any of those options in the air.

Exhaust, which is what you're smelling when the doors are open, seems like it'd be much less of a problem. Any fumes will be much more dilute from all the uncontaminated air pushed by the fan through the bypass ducts, and of course diffusion into the environment. Not to mention probably decomposed by the temps in the combustion chamber. The bleed air though comes from the engine core's compressor stages (before combustion), and it's the only source of air for the cabin, so if it's contaminated you won't have any dilution effect.

Some new designs are 'bleedless' and use electric compressors sourcing from outside air to pressurize the cabin, and these designs shouldn't have significant fume event issues.

However not all recent cleansheet designs use this methodology, for example the A350 (launched 2013, after 787) and Bombardier CSeries (now A220, also 2013) both use the traditional bleed air design, as do the modernized 777X, 737MAX and A320neo families. I think even among modern designs, only the 787 is bleedless.

So we're at least another generation away from going bleedless, and it seems that Airbus and some other Boeing design teams have decided the tradeoffs aren't worth it. Maybe the new regulatory environment will put more pressure in that direction.

Do they? Apple's seem to be the only common ones obviously wearing gloves. Windows' cursors as well as most of the common cursor sets on Linux just use a hand shape with no glove details. I assume this comes from Apple's skeumorphic phase where they may have felt the abstract 'white hand' was not good enough as a metaphor; it goes back at least as far as classic MacOS IIRC.

Not using lifelike colouring has hopefully obvious reasons: inclusivity, contrast, display compatibility

Huh? That's not how the PD protocol works, it's a multidrop bus, and the device won't respond to requests addressed to the cable.

> It seems that there is an actual problem, then.

There was, and as a result almost no vendor actually strictly followed the standards prior to USB-PD providing a way for this to be managed reasonably and deliver more than 2.5W.

The modern standards are fine. As usual, implementation quality varies.

The standard doesn't allow it, that is my point.

A baseline of USB2 connectivity is required for both cables and ports. A baseline of 5V@1.5A is required. Compliant (USB) devices are required to come up and enumerate even if they can't get the power contract they want or the speed that they want.

It is on the software to convey to the user that something the device needs is missing, the USB spec can't really speak to that, but there is not any situation allowed in the spec where you connect a USB device to a USB host and there is no working data&power interface at the end.

> BTW., as an update - I just received "USB 3.1 Gen 2" cable. It doesn't work.

It sounds like one of your devices is broken.

> Which source? The charger or the device? Because either could be at fault.

Any device acting as a power source - but you need PD for this so you can create power contracts that are compatible with the root power source, and you're not describing a PD situation, so this is not possible.

Probably your router does limit downstream power, but due to many years of devices ignoring the 500mA limit, these limits are usually very liberal so as to avoid users complaining that the USB port doesn't work with device X. PD helps with this by establishing a way for sources and sinks to negotiate a clear power delivery contract that the source can be strict about limiting.

4W is more than non-PD USB can supply, so the fact that it doesn't work is not that surprising.

> Which source? The charger or the device? Because either could be at fault.

IMO it's harder for the source to be flexible with voltage, and especially current limit, so I'd put somewhat more blame on the sink here for not being flexible enough. Generally a sink should expect to be plugged into an 'unknown' source, so should at least make an effort to support multiple voltages.

Designing a multiport power source with a shared power limit is a bit of a tricky problem.

I don't have this hardware setup, so I don't know what's wrong with it, but it has nothing to do with the USB specs. If they were followed, then the situation you describe wouldn't occur.

You don't need e-marking for 3A charging. A non e-marked cable can deliver up to 60W (3A@20V). It must route the CC pin to be able to negotiate a higher voltage (>15W 3A@5V), but this is (spec) required for all USB-C cables.

Edit: I should add that it is possible for a fully complaint combination of devices to not charge at max(sink power, source power), because not all possible combinations of voltage and current may be supported. For example a 60W charger may support 20V@3A, but if the 60W sink only supports 12V charging, it needs 5A and this combination won't support 60W charging. In practice this should be rare though, it would be terrible product design.

It certainly can. If it doesn't, this is Apple's problem to fix.