Posts by Chromatix 15 publicly visible posts • joined 9 Nov 2010
They were both due to take place in Vancouver later this month. NetDEV has been postponed by 3 months; IETF plans to convert to a virtual conference with only remote attendance on this occasion. The next in-person IETF is likely to be in Madrid, 4 months hence.
I've read the preliminary report. An executive summary of events from the FDR:
1: Shortly after takeoff, the left AOA sensor changed to an improbable reading, roughly 60° offset from the right AOA sensor, and the stall warnings on the Captain's side activated.
2: When the conditions for MCAS activation were all satisfied a couple of minutes later (flaps retracted, autopilot tripped due to speed sensor disagreements related to the underlying AOA disagreement), MCAS pushed the trim down. This caused a downward flight path deviation sufficient to activate the GPWS.
3: Several trim corrections were issued by the pilots, via the electric trim switches, to partially reverse the MCAS activation. The remainder of the necessary flight path correction was performed by pulling the yokes back. The stab trim remained in a considerably more nose-down position than when the first MCAS activation began.
4: The trim runaway checklist was performed, and consequently the electric trim was cut-out according to Boeing's instructions. A subsequent MCAS activation is recorded in the FDR which had no effect on the trim position, showing that the cut-out switch was effective.
5: The checklist then states that trim must be applied manually, meaning via the trim wheels located either side of the throttle quadrant, and with foresight since turning these wheels by hand is much slower than the electric system. The data shows that the trim position moved gradually more nose-down, not nose-up, even though the yoke position and flight path showed a need for more nose-up trim. It seems to me (not in the report) that the pilots may have inadvertently turned the wheels the wrong way.
6: The aircraft continued with little sustained climb but with the engines still at takeoff thrust; this caused the speed of the aircraft to reach and eventually exceed Vmo, the maximum safe operating speed. During this time both pilots were exerting considerable effort on the yokes, both in turn and together, to keep the nose up.
7: Towards the end of the recording, electric trim inputs and MCAS activations are again seen, this time associated with corresponding movements of the stab trim; this indicates that the cut-out switch was returned to normal. Subsequently, MCAS drove the plane into the ground.
There is much material here for the investigation to get to grips with, and it seems clear to me that the pilots had a path to recovery which was not adequately followed. The root cause, however, is a single faulty AOA sensor causing runaway nose-down trim via MCAS.
Upvoted for the Macintosh Human Interface Guidelines. Essential reading for anyone designing a desktop GUI or application thereof, even if it's not for a Mac, and even if the final result doesn't even *look* like a Mac interface - if it *behaves* like one, you won't go far wrong.
Back in the 1980s, SAAB put an awful lot of thought into making their cars - especially the classic 900 - usable and maintainable, using experience from the "human factors" department of their aircraft business. By all accounts, it worked very well - once you got used to the controls all being in different places to *other* cars whose designers weren't so forward-thinking. Unfortunately many commentators (including Top Gear) objected to the nonconformism and failed to see the engineering behind it.
The ignition key was on the centre console, when everyone else put it on the steering column. This was primarily a safety feature; in a crash, it was one less sharp implement attached to a part of the car that might intrude into the survival space, and was very close to the driver's knees. (This in the days before airbags and crumple zones became ubiquitous.)
This position also let them interlock the key with the gearshift, so that you had to put it in Reverse (or Park, for automatics) before it let you take the key out. With the handbrake acting on the rear wheels and the transmission on the front, this meant your car was secured by all four wheels when you left it. The downside? Until you developed the right habits, you would often end up starting the engine while still in Reverse - it took two distinct movements of the key, with a movement of the gearshift in between, to go from "Lock" to "Start/Run" or vice versa.
The radio was mounted right at the top of the centre dashboard, so that you didn't have to look *down* to adjust it, only glance across. It was still usable by the front-seat passenger in that position. The ventilation controls were straightforward and widely emulated by other manufacturers at the time - lessons since forgotten by the industry. Secondary controls needed by the driver, such as headlights, were logically grouped either side of the wheel.
Even the dash lighting colours were chosen to maximise visibility while minimising the effect on the driver's night vision (green flood and orange needles - yes, real needles, not fake ones on a computer screen). The tachometer had a simple arc painted on it to indicate the economical range of engine speeds, as opposed to those developing maximum torque and power - the latter being optimised for easy overtaking with minimal gear changes. The warning annunciators were large backlights giving more information than today's laconic "Service Engine Soon" - and if *any* of them were on, you would notice the fact and know to pay attention to what thy were telling you, as soon as you found a safe moment to look more closely.
Then you looked at how the engine was laid out. The battery and fusebox were both under the bonnet, but on the far side of a bulkhead from the engine bay proper, helping them stay cleaner and making them easier to work on when needed. The two dipsticks (one each for the engine and transmission) were next to each other. Everything that commonly needed changing or adjusting could be dealt with without needing a quadruple-jointed driver to reach into some obscure corner of the mechanicals. And the bonnet itself was hinged at the front, in such a way that it would never blow against the windscreen if it came unlatched, nor did it need a strut to keep it raised once deliberately opened.
What General Motors did to that company was nothing short of criminal.
I have seen the effects of mass unemployment for myself.
For centuries, Liverpool was a major port, and built an extensive dock system to serve all its traffic. Whole sections of the city were built as housing for dockworkers, within reasonable walking distance of the docks. These were not wealthy people, but they made an honest living through hard work.
Then containerisation happened, and ships were unloaded by huge cranes instead of armies of men. New, enormous docks were built to accommodate this new method of working and the larger ships it engendered. The old docks, unable to compete on equal terms, closed - putting thousands upon thousands of dockworkers out of work, all at once.
They couldn't just move to another dock or port - all the other ports were containerising too, and the containerised docks required far fewer men to handle a much larger volume of goods. In happier times, they might have gone to work for the railway instead, but British railways were in the middle of a full-scale retreat from goods traffic. Likewise, mines were closing all over the place.
There was thus no other industry that could take on a large influx of unskilled physical labourers, which is what they were if you discounted their docker experience. And besides, who would they sell their houses to in order to move - if they owned them in the first place, that is. If they didn't, they were still stuck paying rent *and* council tax (which wasn't income-linked) without a steady job to pay for them. The only viable way out was the welfare system.
The result was the Toxteth Riots of circa 1980 - Toxteth being one of the more centrally-placed docker districts. If you look in the right places, you can *still* find burned-out buildings from that event. And, even though I didn't live there, for some reason my parents sent me to school there. Several of the other children in my class regularly came in hand-made uniforms, because their families couldn't afford the official ones.
Containerisation was, of course, an overall benefit to the economy, since it greatly reduced the cost of shipping over long distances. But it was a sudden shift which caused a huge amount of localised human misery.
It's got to be Akamai. That sort of fundamental breakage of TCP congestion control can't happen client-side, not if it wants the lost packets to be retransmitted so it actually gets them.
I've seen servers that ignore ECN marking recently, but they at least still respond to the packet drops which inevitably happen when the queue overflows. They're misbehaving, but in a sort-of manageable way.
This, though - this is *evil*. It's undoing the mid-1980s work which got the Internet running again after the Great Congestion Collapse Event. It needs to be stopped - NOW.
So - why is the key-generating script using /dev/urandom (which is susceptible to this problem) instead of /dev/random (which will refuse to yield data unless and until there is sufficient entropy)?
It should be well-known that something as cryptographically sensitive as key generation *must* use /dev/random. Not only would that have avoided generating the weak keys in the first place, but the delay on first boot (until sufficient entropy was available) would have highlighted the lack of HWRNG support.
Okay let's take a step back and discuss this properly.
First of all, the First Amendment doesn't apply. This should be plainly obvious - it's about what you can *say*, not what you can *see* or *record*.
The laws that *should* apply are the ones about privacy and public decency, and the court should consider how they interact with each other here. My take on the matter is:
Public decency laws essentially require people to keep certain parts of their bodies *private*. The precise definition of which parts varies considerably over time and jurisdiction, but the typical standard in Western society is hips-to-upper-thigh for both men and women, plus most of the breasts for women.
Clothing which performs this task adequately is readily available, and (for women) usually relies on the assumption that an observer's eyes are above the subject's waist. Even short skirts are generally designed to hang down to cover the area between the thighs when the wearer sits down. Underwear is intended as a backstop, to deal with momentary malfunctions of the skirt's normal dynamics (eg. wind) and corner cases where the central assumption is invalid (small children, escalators, ladders). Some people enhance this by wearing shorts or a petticoat under their skirt.
Note that even in those corner cases, people are generally expected by society to avert their gaze. Parents of young children are to teach them that looking up skirts is wrong, and try to prevent them from doing so - in return, most people understand that small children are not malicious. Therefore, a woman wearing a skirt and normal underwear can be considered to have a "reasonable expectation of privacy" against deliberate exposure of their *underwear*, never mind what said underwear covers, to the extent that their skirt would normally keep it covered.
So now we come to the breastfeeding woman on the Tube. Here, the breast is exposed more than normal societal standards expect, although the nipple itself spends most of the time covered by the baby's head. Most sensible people would agree that this is not obscene - it does not "outrage public decency". At the same time, this woman has deliberately exposed that part of her to view, so she no longer has an expectation of privacy regarding it - until, of course, she finishes feeding her child and covers it up again. In my experience, many (not all) women try to find somewhere with fewer people to watch her - for example, near one of the shortcut passages in IKEA, rather than beside the main paths.
That is the difference between an upskirt photo and a candid photo that contains a breastfeeding mother. In one case, the photographer is violating an expectation of privacy; in the other, he is not. It is the same distinction between taking a photograph of a minor Royal on a public engagement, and taking another photo of the same person using a huge telephoto lens to penetrate the large estate she lives on.
Let's round out the discussion by illustrating two examples that *do* violate public-decency laws. The most obvious example of this would be a streaker at a sporting event, who takes off every stitch of clothing and runs out in front of a crowd of tens of thousands, specifically to cause outrage and embarrassment (not to mention disruption to the match in progress). A more nuanced example is the recent protest by a group of Finnish art students, where one of them posed as a nude model for the others - right in the middle of Tampere railway station. After a discreet interval, a policeman politely asked her to get down and get dressed - which she did, having made her point, and I understand that no charges were filed.
There is one thing that inter-"thing" comms might be good for - and that is coordinating power use so as to present a smaller peak load to the grid.
A lot of short-term generation capacity is needed simply to cover stuff like half the country turning on their electric kettles simultaneously at half-time or at the commercial break of a soap opera; if that were offset by a load of washing machines pausing their cycle, ovens and fridge-freezers biasing their thermostat by a notch and air-conditioners shutting down for a few minutes, it might reduce the overall cost of electricity measurably. And, just maybe, us consumers might just get to see that as lower prices.
Unfortunately, that's also the sort of thing that doesn't appeal to marketing types, so it never actually gets done.
I think there are two reasonable technological cutoff points for including electricity in a steampunk aesthetic:
Liberal: semiconductors are not allowed. Simply assume that the PN junction does not work, thereby disabling the LED, the silicon rectifier, transistors of all kinds, and the microchip (as we know it, anyway).
Conservative: not only do semiconductors not work, but neither do thermionics. The thermionic valve (or "vacuum tube" for Yanks) was invented in the early part of the 20th century; although cold-cathode effects were known for some time before then, it was difficult to find uses for them.
Note that even the "conservative" definition still permits "vacuum tube like" technologies which actually rely on striking an arc in a gas medium, eg. the mercury-arc rectifier, the Dekatron and the Nixie tube.
A mechanical seven- or sixteen-segment display is feasible. Here's an electromechanical type which was used nationally as railway clocks for a while: http://www.youtube.com/watch?v=djcaR1tVdVg While this example (designed for numbers only) is merely seven-segmented, a sixteen-segment version could display letters quite competently.
The obvious way to drive one without electricity is with pneumatics. You would need to build some fluidic logic to store a six-bit character code, and then decode it to drive the individual segments. It doesn't matter if the decoder is a bit slow, since you only need to latch the code into the storage before you can move on to the next display position.
Input on the bottom row could be done by mechanically actuating the storage valves with a sliding camshaft. Slide the cams under the position to be updated, then rotate the appropriate ones to "set" or "reset" the bits required. A separate "group reset" lever could be arranged to zero the storage registers in the entire row.
Additional rows above could be driven from the bottom row, and filled by scrolling. A tradeoff could be made here by sending the decoded signal up for latching directly, rather than duplicating the decoders.
The same sort of test was done in Finland - a journalist downloaded the Liberator blueprint, took it to a university which had a *high quality* 3D printer (much better than the ones the Australians used), then took the resulting parts to a professional gunsmith who assembled them and organised a safe test.
The results were much the same as well - the gun disintegrated while firing the very first shot. There is a video linked here, with subtitles:
http://yle.fi/uutiset/liberator_3d-printed_handgun_fails_after_single_shot_in_finnish_test/6643536
The questions about window washing and piano tuning are all about seeing how you approach a problem. They don't really care whether you get "the right" answer, they care whether you're good at making reasonable assumptions and estimates, and working through them to an answer that is reasonable given those assumptions. These are fundamental skills for an engineer, rather than a programmer.
For example, you might start by estimating the population of Seattle (a few million), then the number of people per household (say 4), then the number of windows per house (say a dozen). Add another window per person to account for the business and commercial districts. So that might make 10 million windows to clean. You can't do that yourself, so you outsource it to a variety of professional window cleaners, let's say they can do a window every 3 minutes on average (given they have to set up ladders and move from house to house) at minimum wage-ish of say $7.50 an hour. That's $3,750,000 in costs so charge $4M to have a little profit margin, or $5M for a bigger one.
Apple has used several CPU families in it's machines - this one is a 68K family, which is classic CISC. It was relatively powerful for it's time, though - you would often see arcade games and consoles using a Z80 to run the game logic and a 68000 for the graphics.
The RISC CPUs Apple has used are the PowerPC (from 1994 to about 2005) and the ARM (in the iPod and iPhone). The PowerPC gave the Mac performance when the 68K family eventually ran out of steam, while the ARM gives power efficiency that's needed for a handheld device.
Has anyone tried replacing the Portable's battery with a new lead-acid battery? It seems to have a custom case wrapped around it, but it shouldn't be too hard to find an electrically compatible unit, even if it requires making the machine desk-bound.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
