Of this type? Two. The APU and the main battery. They are identical and thus interchangeable such that if the main battery is not charged or otherwise not functioning before a flight, you can swap the APU battery in its place. There are, IIRC, other batteries scattered throughout the plane. Unsure if they're Li-Ion or not.
One of the planes was about a year old, the other a couple weeks. The older plane had seen its Li-Ion batteries replaced in more recent times, and the two suspect batteries were within 30 serial numbers of each other. If they're wearing out *that* quickly I'd be worried.
Except that Boeing ran into problems with the batteries before production. I've got exactly zero idea how accurate this piece is, but it's an interesting (if rambling) read:
The worrying part of the "thermal issues" is not how the battery containment box looks, it's that (according to some reports) electrolyte got splashed outside of the box.
Sure.
Alcatel/Thales wrote the train control software for the San Francisco Municipal Railway (SF had to sue Thales to get their shit working even half-way decently), the in-flight entertainment for some (all?) of Air Canada's planes the last time I flew them (the whole system had to be rebooted repeatedly), and they designed the chipsets for the early popular DSL modems. I can't say I've got fond memories of any of these products.
Boeing shares are up too (1.24%) as of 15:34 Eastern time.
How does this get modded up? The batteries are Japanese (Yuasa) in origin, sourced by a French company (Alcatel/Thales).
There have been a lot of lessons learned since SW111. The biggest lesson is, IMO, that of a quick response. One of the big problems with SW111 (and AC797) was that delays (a matter of seconds in the case of AC797) made the difference between life and death. The ANA pilot declared an emergency, got the plane on the ground, and got the passengers off ASAP.
It hasn't been clarified which battery was problematic in the most recent 787 incident. If it was the APU (the one that caught fire in Boston) or the main battery, Boeing designed for the "one of those batteries catches fire" case. Both are enclosed in a fire resistant enclosure, and both are designed so that smoke from such a fire is vented away from the cabin. That's a gigantic difference from SW111 and AC797 where the fires occurred in an area that was not designed to contain fire.
There are conflicting reports of smoke, and conflicting reports as to which battery was at fault in the latest instance... but barring smoke in the cabin, it likely wouldn't have ended up much worse (a couple of injuries from using the emergency slides).
Not necessarily. See also the Hostess bankruptcy.
Yeah, we use ZTE modems (embedded stuff) at work. It's a tossup between the support and the product as to which is actually worse. None of our vendors enjoy selling ZTE products. Our standard policy is to ship the modems from the vendor to ZTE to ensure proper configuration. We've had one batch that was provisioned for a Chinese telecom, so we ended up "roaming" on our carrier and were assigned IP addresses owned by a Chinese company. All of the ZTE documentation for this particular modem is for the latest version of the firmware (which is not backwards compatible with the previous version of the firmware). Well, despite sending all of these things back to ZTE, only a handful of the modems have the current, documented version of the firmware. Despite asking for documentation for the older version of the firmware, ZTE has refused to provide any. Their solution is to recall hundreds of modems, ship them to ZTE and hope for the best. The firmware is not user updatable.
No. Thanks.
I feel for any carrier that things hawking ZTE phones will be a reasonable experience.
Why? There are definitely instances where an optimization like that may be appropriate. It's not a wrong, bad, or particularly smart ass answer.
The value here, IMO, is the insight into the candidate's thought process. I certainly wouldn't have one correct solution in mind If they give up or can't come up with an answer, I'd move on pretty quickly. If someone gave an answer like you did, I'd probably see what it would take to steer them towards a more flexible answer.
I am aware that portversion (part of the portupgrade suite) is much faster. I was using it until portupgrade broke. I did just check and it appears as if portupgrade is suddenly working again. Definitely not predictable enough for me to want to keep using.
I am/was using portmaster because portupgrade is broken on my system (it chokes on the pciids package). Portmaster is fast(er), but is unbelievably verbose, and its default settings are frustrating. Portupgrade defaults to saving old libraries, saving the need to recompile EVERYTHING. Portmaster does not. Portupgrade will keep distfiles around. Portmaster will sporadically prompt you to delete all of the associated distfiles. Portupgrade will show you the progress of the files it's downloading. Portmaster will show you that it's blocked, waiting for something to download (it will keep spamming your console with this rather useless message until the file has finished downloading... given how unreliable some of the default mirrors are this can add quite a bit of time to installs/upgrades unless you're paying attention to bandwidth usage elsewhere).
Yes, I'm sure portng is going to be a step up. I'm sure that I could learn how to use portmaster. But in the end, the Debian tools are far, far more intuitive and expedient for me. Maybe it's time to test out Debian/FreeBSD.
The ports system is an absolute nightmare. Sure you've got things like portmaster and portupgrade (the latter is currently broken with no fix in sight). I spend far more time mangling ports than I do dealing with package management on any Debian based system. It took over forty seconds(!!) on an otherwise idle system (Ivy Bridge i5 w/ SSD) to list all the installed ports and their versions (pkg_version). Using the ports system is akin to pulling teeth as far as I can tell.
The problems with X, for me, have mainly been lack of driver support (Ivy Bridge support is pants). But that's a whole 'nother ball of wax.
Yeah, well, having to go out of your way to disable stuff is great motivation to move to another distro that actually respects its users.
What the gods would destroy they first submit to an IEEE standards committee.
