Let's not forget that dispersion is solely due to interaction of photons with electrons in atoms. In ideal vacuum, there's no "small" effect to observe, since there's no electrons (atom-bound or otherwise) for photons to interact with. Case closed.
Of course, back in the real world, over 3 billion years, there's no such thing as a vacuum. There's stuff in there all right. Even the best pseudo-vacuum the universe can throw at us becomes very much non-vacuumy over such distances. Since you're shooting those x- and gamma-rays through 3 billion years worth of non-vacuum, dispersion is to be expected.
I have no idea where did your suggestion for the word "impedance" come from, it makes no sense.
Wait, so there was no state machine that actually drives task lifetimes, presumably by definition not ignoring any task death? Oh boy. I'd have thought that by now everyone has realized that if there's something that can have multiple states, especially something as important as a control task, there'd be a nice FSM or a HSM taking care of it. Sigh. I mean, come on, it's quite easy to do. It will work in spite of all those bugs that cause tasks to die.
A transient bit error on a bus that constantly refreshes the value is of no consequence. You'll get a temporary upset, but so what. Suppose the pedal is sampled at 100Hz (a reasonable value). A single upset will at most "floor" it for 10ms. You may hear it, but it's not unsafe.
Toyota's drive-by-wire system's transient error behavior is not to blame for any of the problems. A "stuck" throttle effect is either a permanent and undetected failure of the pedal sensor assembly, a latch-up of the throttle plate actuator, or a software failure in one of the components in this chain (say throttle actuator computer, the ECU, whatever sits on the same bus, etc.).
Stupid question: why do blowers used in a data center need belts? These days, they should all be direct-driven by brushless motors. At most you need a coupling, although blower-duty brushless motors should have bearings sufficient to support the blower, thus you need no couplings. That way only one bearing is anywhere near being exposed to air that is blown around. I've been to a clean room facility that had all ventilation systems completely direct-driven, and the facilities people loved it.
Let's face it: over 3 billion light years, it doesn't take much dispersion for things to arrive with a 20 hour delay. We're talking parts-per-trillion here.
A gravitational collapse's release of energy doesn't need any nuclear reactions. Stuff simply falls down, so it converts gravitational potential energy into kinetic energy. Eventually it hits some other stuff hard, releasing said energy as photons.
Once you're heavy enough, you're not statically stable. Without a source of energy, you collapse, and soon thereafter release the gravitational energy as photons.
some of the highest energy photons, including the new record-holder, appeared hours after the blast
One explanation is that the star is "weird" that way. Another explanation is dispersion in the interstellar- and intergalactic medium between the star and us. I mean, come on, we don't really know much about the intergalactic medium's dispersion for such energetic photons, since the only way to observe it would be via gamma ray bursts, right? I know zilch about the subject, so I'd really like to hear from an astrophysicist or two who happen upon this. As far as I'm concerned, the star could be weird, or the medium could be weird, or maybe both. Thanks!
What I meant by "it's not about staying in practice" was that the issue with automation has to do with things that happen on a much smaller time scale. It didn't mean that staying in practice is irrelevant. Is is relevant, but you need more than that. Practice demonstrably isn't sufficient in itself.
The only difference between a plane and a car is that the time scales may happen to be two or three orders of magnitude different, if you're lucky. Autopilot disconnect-related CFIT is a classical example of what I'm talking about. By the time the pilot figures out that his idea of what's going on (we're in a safe, controlled flight on autopilot) differs from reality (CFIT-in-progress), it's too late, or there's sufficient panic that has set in that the control responses are not what you've been trained for either (stall recovery, spin recovery, etc.).
It doesn't matter that the pilot has more time to figure it out. They are unaware of their own mental model's divergence from reality. In spite of having been given all that time, they still CFIT because they think they're on autopilot. You'd think this would be pretty obvious, but there's one insidious thing. If you're unaware of it, it will eventually kill you. Your brain's sampling of the state of the environment is highly dependent on how confident one is in their own model's accuracy. If things "feel" like everything is the way you imagine it should be, you'll be tricked by your own brain into "seeing" made-up instrument readings, your sensitivity to increased wind noise will be diminished, etc. I'm dead serious. It takes awareness of this pitfall to be able to force oneself to see how it really is, to make your brain not trick you. When you don't, and you're a pilot, usually a couple hundred people perish with you. This is happening over and over, it's sickening. The reason why it happens with such regularity is that we're dealing with a basic property of our brain's visual interaction with the environment. It's not widely appreciated in nonspecialist circles, unfortunately. We're almost all "broken" like that.
Boeing has since issued a bulletin to remind pilots of all 737 series and BBJ aircraft of the importance of monitoring airspeed and altitude
The pilots were not flying the fucking plane. Aviate first. They didn't. The results are always the same. No blaming computers on that one. Good that only 9 people perished, it could have been much worse.
In case of loss of air data, the computer is actually precisely just what the doctor ordered. That's because the emergency procedure amounts to a look up of throttle settings in, well, a look-up table. Precisely what computers are great at. So far, the look-up tables come printed out in a checklist for human perusal. No reason at all why humans have to deal with such shit, if you ask me. Heck, the human-targeted look-up table is necessarily abridged, you don't want dealing with no 100-page tables in an emergency thank you so much. The one for automation's perusal could be much larger and take more factors into account (current weight, outside temperature, etc.).
It wouldn't be called an auxiliary power unit if it was a battery, it'd be called, you know, a fucking battery. An APU is usually a small gas-turbine-powered generator. That same turbine can also power a hydraulic pump. Many planes also have a wind turbine that can be deployed if you're out of fuel. This turbine IIRC usually drives a generator that can power an electric hydraulic pump, or it includes both a generator and a small hydraulic pump.
A human can get an appreciation of velocity even without working pitot tubes, in a middle of a weather system where GPS doesn't work.
Sorry buddy, you've just killed yourself in exactly the same way the AF pilots killed themselves. Oh the irony. NEXT STUDENT, PLEASE.
Seriously. Your seat-of-the-pants "feel" for a modern jet is precisely what is going to kill you. So let me be clear: if you ever end up as an untrained babbling idiot in a cockpit of a jetliner, trying to save a bunch of souls while the air data is missing, you better keep it straight and level and not mess with anything until you've read the checklists. After you do, and you better be quick about it, you'll know that what you're supposed to do is to set the throttles to a fixed position that depends solely on altitude and desired rate of climb/descent. You'll look those up in a fucking table, and as long as you do, you have a chance to make it. There's going full retard, and it's you.
It's not about staying in practice. The problem is much more immediate. In order to interact with any system when you're to be part of the control loop, your brain needs to be preset for control. That means you need to know and feel exactly in what state is the system you're going to take control over. It's very hard to maintain this awareness if you're not actually controlling the process. You need to be ahead of the plane, so to speak.
This very same problem is present in all of man-machine interaction when control tasks are involved. This is the reason, for example, that "taking over" a self-driving car while it is underway is pointless: you need to be pretty much driving the car without actually driving it - so you might as well be the driver without the self-driving brouhaha. Otherwise by the time you figure what's going on, you'll be dead. You can only take over a self-driving car when it's stopped. Even then you'll be quite likely to get lost or to execute a wrong turn/maneouver since you're unlikely to know where you are - unless you're on a road you frequent.
What it really boils down to is something else entirely: people use "common sense" to judge things that they have zero experience with. If you ask "common sense", it would be "cool" to have self-flying planes, self-driving cars, etc. But common sense is precisely the wrong one to make judgment about such things. Reality is quite far from common sense, until you had a chance to experience it just so. The common-sense widely-spread non-specialist thinking about self-controlling systems is usually wildly off-base. Reality is under no obligation to make sense to anyone, so to speak. Thus some things that should be "common-sense-easy" are very far from being so. Self-controlling systems often bring with them a whole lot of extra issues that nobody had any idea of until they've faced them. Aviation industry has only recently went out of automation-related self-denial. 20 years after it was all understood. That's the risk of relying on common sense over facts.
Your approach is a tad wrong. You won't ever know if you need to use it - how would you? You're not an oracle. What you do is you use it first, and only then you have proof that everything is peachy. My bet is that you have very poor idea as to how your circuits really perform. Just because it "works" doesn't mean it's anywhere near being properly engineered. Just look at transition times on modern micro controllers and on the discrete logic chips that you're using. If your scope won't let you see those transition times, it means you have no idea what effect all those transitions have on your circuit as a whole. For all I know your power supply is sagging every time a GPIO pin is switching, and your circuit works just because you got lucky, but it's much closer to not-working. There's a lot of analog design know-how that's needed to properly design "digital-only" electronics.
It took me 15 years to be at a point where I claim I know a bit, and I still consider myself quite dumb when it comes to analog. Well, at least I've got a multi-kW piece of power electronics to pass emissions on the first try, with a whole bunch of cables attached to it - that's kinda hard. It only happened because I was quite conservative in everything, and paid attention to a whole lot of details that don't matter at all in whether "it works". Now of course emissions and susceptibility often go hand-in-hand, so if your circuits ring all over the place, it may also mean that they'll pick up things you don't want them to pick up once someone places a cellphone nearby:)
Yes, I know that if you're on a tight budget, you simply have no option of getting more advanced test gear. If you're in the U.S., I suggest you keep good eye on eBay for used brand-name equipment. Sometimes you can get absolutely exceptional deals. A lot of older analog-style test gear is quite repairable, with free (or very affordable) service manuals available. There's a few exceptional all-transistor, no-custom-IC Tektronix and HP oscilloscopes out there, that go at least to 100MHz. They'd be still considered a baseline kind of an instrument. If you've got room for it, something is to be said for Tek 7603 mainframe. There are mailing lists / discussion groups for every brand of test gear out there, often with folks who used to design the very instruments you now get on the cheap.
If you're serious about your work, you need a scope that gets down to device parasitics. If you're putting together a tiny little app-circuit-based switching power supply that's uses 0402 and 0603 passives with their puny parasitic inductances and capacitances, you better be able to see those effects or else. I'd say that for modern mixed-signal work you need at least 1GHz bandwidth, 10GHz sampling rate oscilloscope (or an analog equivalent, but there's like two to choose from). Anything active that's not bog slow and is sold in tiny surface mount packages (say transistors in ~1mm square packages) can very happily ring at hundreds of MHz. Your 100MHz oscilloscope will very happily lie to you telling "all's peachy boss". I mean, some geniuses back in the day made nice 100MHz+ oscillators in their capacitor-decoupled transistor-using reset circuits. This still happens today, except that your oscillating tank is all made from device parasitics, and quite high-Q.
I keep a couple Tektronix 7000-series oscilloscopes and assorted plugins and probes up and running just because they let me see what's really going on.
Maybe in times of Windows 2.x, 3.x and the 3.x-driver-under-95 this could have been true due to device-specific font brouhaha. Once non-device-specific fonts entered the scene (either truetype or bitmap fonts), the device-specific driver wasn't doing any typesetting. You know that, so please, stop with the misinformation. The GDI layer was doing it all, merely consulting the device resolution. Yes, many applications did their rendering such that the device resolution mattered since the fonts were scaled to device pixels. This is still a far cry from "raw typesetting" done by the driver. I don't even know who the heck still uses device fonts. Maybe some braindead label printer people, I don't even know if modern GDI still supports this crap.
This is not quite true. There's this thing called compliance, and your device won't ever get a UL listing (or pass CE compliance testing) if it doesn't provide power limiting on low-voltage outputs. It's braindead to do anyway, as you'll be a ripe target for lawsuits. A USB port should basically protect a 3m 24AWG power wire pair from melting when shorted or otherwise overloaded. In a house, that's what the circuit breakers are for: they protect the wiring from overloads.
Heck NO! First of all, when measuring current consumption on a port that can deliver a measly 2.5W (5V at 500mA), you won't ever need a 15-20 Watt resistor, even if you used that resistor to short the power wires, much less when you use it in series with one of the wires.
Secondly, you do want as minimum of a dissipation on the current sensing resistor as your measurement amplifier will allow. There are two reasons for that.
The current sensing resistor is in line with the supply, so any voltage developed on it means less voltage to the device. Some devices consume fixed power and are thus negative resistances since they step-up the voltage using a switching converter. In those the more voltage drop your sensor develops, the higher the real current consumption since the load has said negative resistance. You definitely don't want that.
Also, whatever power the resistor is dissipating will necessarily heat it up, changing its resistance. Unless you measure that resistance (or the temperature of the resistor), you're facing an uncorrected error.
Alas, for USB use, you don't even need a discrete resistor. The resistance of the traces on your board (or a section of the cable) should be sufficient - 10mOhms is all you'd need, as it gives you a rather respectable 5mV at 0.5A. If you know your analog electronics, you should have no problem working with even 0.5mV at 0.5A, so just 1 mOhm is all you'd need. Even at 10A, such a "resistor" would dissipate a measly 0.1W, so with the currents seen in USB use, you're completely OK.
This was a planned process and it took time for a reason. They did this slowly but surely. That's the only way to do it without blowing your budget many times over. I hope you recall that big software rewrites almost universally fail. This is a big infrastructure rewrite, it'd fail too if it were done in a "let's just rip it all at once" fashion. It's the same reason you need to be wary of many a company that grows too fast - usually it's internals can't keep up, and it'll eventually fail. Many companies failed just for not artificially limiting their growth. Southwest Airlines is a shining example that sometimes just artificially clipping your growth at 8% annually is a good thing to do:)
Word itself, like many other GUI apps that handle formatted text delegates a lot of the raw typesetting to the video card and the selected printer driver.
It's amusing that you speak about it with such conviction yet it's all a fantasy, no less. Man, where did you get this "insight" from? Lest anyone be confused about it: fuck no.
Torque converter losses eventually go up with applied torque, even though they may be "funky" at lower torques. Engine friction is an issue at high RPMs, but you get better efficiency at high RPMs as well, so it really depends on a particular engine. Rich mixture is a factor as well, especially if you're not using premium gasoline. Drivetrain friction on gear pairs simply goes up with torque, so if everything else were constant, you'd want to minimize the torque, but of course everything else is quite complex so this has an effect, except when it doesn't;)
What I've noticed is that using regular gas I get worse mileage with jackrabbit starts, compared to premium gas. It's easy for me to test, since 99% of my driving is on the same road every workday. We do groceries and errands in my wife's car. For freeway driving that I do very occasionally, and is mostly on cruise control, there's no benefit to premium gasoline, other than slightly quieter engine operation (the difference is measurable, but is really meh otherwise). In my city driving, it's actually cheaper for me to use premium gas.
So, if you're using regular gasoline, you probably shouldn't be flooring it, but on my particular car there seems to be no big difference in gas consumption between aggressive starts and less-aggressive ones if I use premium gas. The biggest impact to me, it seems, is from slight "hypermiling" - letting off the accelerator way ahead of stopped traffic, coasting longer. When I do that, jackrabbit starts on premium gas seem not to matter at all.
Slashdot Mirror
Let's not forget that dispersion is solely due to interaction of photons with electrons in atoms. In ideal vacuum, there's no "small" effect to observe, since there's no electrons (atom-bound or otherwise) for photons to interact with. Case closed.
Of course, back in the real world, over 3 billion years, there's no such thing as a vacuum. There's stuff in there all right. Even the best pseudo-vacuum the universe can throw at us becomes very much non-vacuumy over such distances. Since you're shooting those x- and gamma-rays through 3 billion years worth of non-vacuum, dispersion is to be expected.
I have no idea where did your suggestion for the word "impedance" come from, it makes no sense.
Wait, so there was no state machine that actually drives task lifetimes, presumably by definition not ignoring any task death? Oh boy. I'd have thought that by now everyone has realized that if there's something that can have multiple states, especially something as important as a control task, there'd be a nice FSM or a HSM taking care of it. Sigh. I mean, come on, it's quite easy to do. It will work in spite of all those bugs that cause tasks to die.
A transient bit error on a bus that constantly refreshes the value is of no consequence. You'll get a temporary upset, but so what. Suppose the pedal is sampled at 100Hz (a reasonable value). A single upset will at most "floor" it for 10ms. You may hear it, but it's not unsafe.
Toyota's drive-by-wire system's transient error behavior is not to blame for any of the problems. A "stuck" throttle effect is either a permanent and undetected failure of the pedal sensor assembly, a latch-up of the throttle plate actuator, or a software failure in one of the components in this chain (say throttle actuator computer, the ECU, whatever sits on the same bus, etc.).
Stupid question: why do blowers used in a data center need belts? These days, they should all be direct-driven by brushless motors. At most you need a coupling, although blower-duty brushless motors should have bearings sufficient to support the blower, thus you need no couplings. That way only one bearing is anywhere near being exposed to air that is blown around. I've been to a clean room facility that had all ventilation systems completely direct-driven, and the facilities people loved it.
Let's face it: over 3 billion light years, it doesn't take much dispersion for things to arrive with a 20 hour delay. We're talking parts-per-trillion here.
A gravitational collapse's release of energy doesn't need any nuclear reactions. Stuff simply falls down, so it converts gravitational potential energy into kinetic energy. Eventually it hits some other stuff hard, releasing said energy as photons.
Once you're heavy enough, you're not statically stable. Without a source of energy, you collapse, and soon thereafter release the gravitational energy as photons.
some of the highest energy photons, including the new record-holder, appeared hours after the blast
One explanation is that the star is "weird" that way. Another explanation is dispersion in the interstellar- and intergalactic medium between the star and us. I mean, come on, we don't really know much about the intergalactic medium's dispersion for such energetic photons, since the only way to observe it would be via gamma ray bursts, right? I know zilch about the subject, so I'd really like to hear from an astrophysicist or two who happen upon this. As far as I'm concerned, the star could be weird, or the medium could be weird, or maybe both. Thanks!
What I meant by "it's not about staying in practice" was that the issue with automation has to do with things that happen on a much smaller time scale. It didn't mean that staying in practice is irrelevant. Is is relevant, but you need more than that. Practice demonstrably isn't sufficient in itself.
The only difference between a plane and a car is that the time scales may happen to be two or three orders of magnitude different, if you're lucky. Autopilot disconnect-related CFIT is a classical example of what I'm talking about. By the time the pilot figures out that his idea of what's going on (we're in a safe, controlled flight on autopilot) differs from reality (CFIT-in-progress), it's too late, or there's sufficient panic that has set in that the control responses are not what you've been trained for either (stall recovery, spin recovery, etc.).
It doesn't matter that the pilot has more time to figure it out. They are unaware of their own mental model's divergence from reality. In spite of having been given all that time, they still CFIT because they think they're on autopilot. You'd think this would be pretty obvious, but there's one insidious thing. If you're unaware of it, it will eventually kill you. Your brain's sampling of the state of the environment is highly dependent on how confident one is in their own model's accuracy. If things "feel" like everything is the way you imagine it should be, you'll be tricked by your own brain into "seeing" made-up instrument readings, your sensitivity to increased wind noise will be diminished, etc. I'm dead serious. It takes awareness of this pitfall to be able to force oneself to see how it really is, to make your brain not trick you. When you don't, and you're a pilot, usually a couple hundred people perish with you. This is happening over and over, it's sickening. The reason why it happens with such regularity is that we're dealing with a basic property of our brain's visual interaction with the environment. It's not widely appreciated in nonspecialist circles, unfortunately. We're almost all "broken" like that.
Nope.
Boeing has since issued a bulletin to remind pilots of all 737 series and BBJ aircraft of the importance of monitoring airspeed and altitude
The pilots were not flying the fucking plane. Aviate first. They didn't. The results are always the same. No blaming computers on that one. Good that only 9 people perished, it could have been much worse.
AF593: It's a classic. Aviate comes first, and they didn't, with usual results.
Pulkovo 612: Likely the same thing: aviate, dammit. Fly the plane according to its operating envelope.
In case of loss of air data, the computer is actually precisely just what the doctor ordered. That's because the emergency procedure amounts to a look up of throttle settings in, well, a look-up table. Precisely what computers are great at. So far, the look-up tables come printed out in a checklist for human perusal. No reason at all why humans have to deal with such shit, if you ask me. Heck, the human-targeted look-up table is necessarily abridged, you don't want dealing with no 100-page tables in an emergency thank you so much. The one for automation's perusal could be much larger and take more factors into account (current weight, outside temperature, etc.).
It wouldn't be called an auxiliary power unit if it was a battery, it'd be called, you know, a fucking battery. An APU is usually a small gas-turbine-powered generator. That same turbine can also power a hydraulic pump. Many planes also have a wind turbine that can be deployed if you're out of fuel. This turbine IIRC usually drives a generator that can power an electric hydraulic pump, or it includes both a generator and a small hydraulic pump.
A human can get an appreciation of velocity even without working pitot tubes, in a middle of a weather system where GPS doesn't work.
Sorry buddy, you've just killed yourself in exactly the same way the AF pilots killed themselves. Oh the irony. NEXT STUDENT, PLEASE.
Seriously. Your seat-of-the-pants "feel" for a modern jet is precisely what is going to kill you. So let me be clear: if you ever end up as an untrained babbling idiot in a cockpit of a jetliner, trying to save a bunch of souls while the air data is missing, you better keep it straight and level and not mess with anything until you've read the checklists. After you do, and you better be quick about it, you'll know that what you're supposed to do is to set the throttles to a fixed position that depends solely on altitude and desired rate of climb/descent. You'll look those up in a fucking table, and as long as you do, you have a chance to make it. There's going full retard, and it's you.
It's not about staying in practice. The problem is much more immediate. In order to interact with any system when you're to be part of the control loop, your brain needs to be preset for control. That means you need to know and feel exactly in what state is the system you're going to take control over. It's very hard to maintain this awareness if you're not actually controlling the process. You need to be ahead of the plane, so to speak.
This very same problem is present in all of man-machine interaction when control tasks are involved. This is the reason, for example, that "taking over" a self-driving car while it is underway is pointless: you need to be pretty much driving the car without actually driving it - so you might as well be the driver without the self-driving brouhaha. Otherwise by the time you figure what's going on, you'll be dead. You can only take over a self-driving car when it's stopped. Even then you'll be quite likely to get lost or to execute a wrong turn/maneouver since you're unlikely to know where you are - unless you're on a road you frequent.
What it really boils down to is something else entirely: people use "common sense" to judge things that they have zero experience with. If you ask "common sense", it would be "cool" to have self-flying planes, self-driving cars, etc. But common sense is precisely the wrong one to make judgment about such things. Reality is quite far from common sense, until you had a chance to experience it just so. The common-sense widely-spread non-specialist thinking about self-controlling systems is usually wildly off-base. Reality is under no obligation to make sense to anyone, so to speak. Thus some things that should be "common-sense-easy" are very far from being so. Self-controlling systems often bring with them a whole lot of extra issues that nobody had any idea of until they've faced them. Aviation industry has only recently went out of automation-related self-denial. 20 years after it was all understood. That's the risk of relying on common sense over facts.
Your approach is a tad wrong. You won't ever know if you need to use it - how would you? You're not an oracle. What you do is you use it first, and only then you have proof that everything is peachy. My bet is that you have very poor idea as to how your circuits really perform. Just because it "works" doesn't mean it's anywhere near being properly engineered. Just look at transition times on modern micro controllers and on the discrete logic chips that you're using. If your scope won't let you see those transition times, it means you have no idea what effect all those transitions have on your circuit as a whole. For all I know your power supply is sagging every time a GPIO pin is switching, and your circuit works just because you got lucky, but it's much closer to not-working. There's a lot of analog design know-how that's needed to properly design "digital-only" electronics.
It took me 15 years to be at a point where I claim I know a bit, and I still consider myself quite dumb when it comes to analog. Well, at least I've got a multi-kW piece of power electronics to pass emissions on the first try, with a whole bunch of cables attached to it - that's kinda hard. It only happened because I was quite conservative in everything, and paid attention to a whole lot of details that don't matter at all in whether "it works". Now of course emissions and susceptibility often go hand-in-hand, so if your circuits ring all over the place, it may also mean that they'll pick up things you don't want them to pick up once someone places a cellphone nearby :)
Yes, I know that if you're on a tight budget, you simply have no option of getting more advanced test gear. If you're in the U.S., I suggest you keep good eye on eBay for used brand-name equipment. Sometimes you can get absolutely exceptional deals. A lot of older analog-style test gear is quite repairable, with free (or very affordable) service manuals available. There's a few exceptional all-transistor, no-custom-IC Tektronix and HP oscilloscopes out there, that go at least to 100MHz. They'd be still considered a baseline kind of an instrument. If you've got room for it, something is to be said for Tek 7603 mainframe. There are mailing lists / discussion groups for every brand of test gear out there, often with folks who used to design the very instruments you now get on the cheap.
If you're serious about your work, you need a scope that gets down to device parasitics. If you're putting together a tiny little app-circuit-based switching power supply that's uses 0402 and 0603 passives with their puny parasitic inductances and capacitances, you better be able to see those effects or else. I'd say that for modern mixed-signal work you need at least 1GHz bandwidth, 10GHz sampling rate oscilloscope (or an analog equivalent, but there's like two to choose from). Anything active that's not bog slow and is sold in tiny surface mount packages (say transistors in ~1mm square packages) can very happily ring at hundreds of MHz. Your 100MHz oscilloscope will very happily lie to you telling "all's peachy boss". I mean, some geniuses back in the day made nice 100MHz+ oscillators in their capacitor-decoupled transistor-using reset circuits. This still happens today, except that your oscillating tank is all made from device parasitics, and quite high-Q.
I keep a couple Tektronix 7000-series oscilloscopes and assorted plugins and probes up and running just because they let me see what's really going on.
Maybe in times of Windows 2.x, 3.x and the 3.x-driver-under-95 this could have been true due to device-specific font brouhaha. Once non-device-specific fonts entered the scene (either truetype or bitmap fonts), the device-specific driver wasn't doing any typesetting. You know that, so please, stop with the misinformation. The GDI layer was doing it all, merely consulting the device resolution. Yes, many applications did their rendering such that the device resolution mattered since the fonts were scaled to device pixels. This is still a far cry from "raw typesetting" done by the driver. I don't even know who the heck still uses device fonts. Maybe some braindead label printer people, I don't even know if modern GDI still supports this crap.
This is not quite true. There's this thing called compliance, and your device won't ever get a UL listing (or pass CE compliance testing) if it doesn't provide power limiting on low-voltage outputs. It's braindead to do anyway, as you'll be a ripe target for lawsuits. A USB port should basically protect a 3m 24AWG power wire pair from melting when shorted or otherwise overloaded. In a house, that's what the circuit breakers are for: they protect the wiring from overloads.
Heck NO! First of all, when measuring current consumption on a port that can deliver a measly 2.5W (5V at 500mA), you won't ever need a 15-20 Watt resistor, even if you used that resistor to short the power wires, much less when you use it in series with one of the wires.
Secondly, you do want as minimum of a dissipation on the current sensing resistor as your measurement amplifier will allow. There are two reasons for that.
The current sensing resistor is in line with the supply, so any voltage developed on it means less voltage to the device. Some devices consume fixed power and are thus negative resistances since they step-up the voltage using a switching converter. In those the more voltage drop your sensor develops, the higher the real current consumption since the load has said negative resistance. You definitely don't want that.
Also, whatever power the resistor is dissipating will necessarily heat it up, changing its resistance. Unless you measure that resistance (or the temperature of the resistor), you're facing an uncorrected error.
Alas, for USB use, you don't even need a discrete resistor. The resistance of the traces on your board (or a section of the cable) should be sufficient - 10mOhms is all you'd need, as it gives you a rather respectable 5mV at 0.5A. If you know your analog electronics, you should have no problem working with even 0.5mV at 0.5A, so just 1 mOhm is all you'd need. Even at 10A, such a "resistor" would dissipate a measly 0.1W, so with the currents seen in USB use, you're completely OK.
This was a planned process and it took time for a reason. They did this slowly but surely. That's the only way to do it without blowing your budget many times over. I hope you recall that big software rewrites almost universally fail. This is a big infrastructure rewrite, it'd fail too if it were done in a "let's just rip it all at once" fashion. It's the same reason you need to be wary of many a company that grows too fast - usually it's internals can't keep up, and it'll eventually fail. Many companies failed just for not artificially limiting their growth. Southwest Airlines is a shining example that sometimes just artificially clipping your growth at 8% annually is a good thing to do :)
Word itself, like many other GUI apps that handle formatted text delegates a lot of the raw typesetting to the video card and the selected printer driver.
It's amusing that you speak about it with such conviction yet it's all a fantasy, no less. Man, where did you get this "insight" from? Lest anyone be confused about it: fuck no .
100,000 descendants alive today? It's not about how many have lived over the years, it's about them alive today.
I meant descendants, you oversensitive clod ;)
The major contributors to "waste" when flooring it, that I know of, are (in no particular order):
1. Engine friction,
2. Rich mixture,
3. Torque converter losses,
4. Drivetrain friction.
Torque converter losses eventually go up with applied torque, even though they may be "funky" at lower torques. Engine friction is an issue at high RPMs, but you get better efficiency at high RPMs as well, so it really depends on a particular engine. Rich mixture is a factor as well, especially if you're not using premium gasoline. Drivetrain friction on gear pairs simply goes up with torque, so if everything else were constant, you'd want to minimize the torque, but of course everything else is quite complex so this has an effect, except when it doesn't ;)
What I've noticed is that using regular gas I get worse mileage with jackrabbit starts, compared to premium gas. It's easy for me to test, since 99% of my driving is on the same road every workday. We do groceries and errands in my wife's car. For freeway driving that I do very occasionally, and is mostly on cruise control, there's no benefit to premium gasoline, other than slightly quieter engine operation (the difference is measurable, but is really meh otherwise). In my city driving, it's actually cheaper for me to use premium gas.
So, if you're using regular gasoline, you probably shouldn't be flooring it, but on my particular car there seems to be no big difference in gas consumption between aggressive starts and less-aggressive ones if I use premium gas. The biggest impact to me, it seems, is from slight "hypermiling" - letting off the accelerator way ahead of stopped traffic, coasting longer. When I do that, jackrabbit starts on premium gas seem not to matter at all.