If you think it's somehow Christian and necessary to "meet and defeat" all other nations, then you I think you should seek help because the whole idea has seriously whooshed over your head.
That's what I meant by "busbars for power distribution":) You can of course use 48V coils to get lowest current at a safe voltage, but the dissipation will remain. And 48V small form factor relays aren't cheap. You could cheat and use optomos SSRs, but that's really aiming low;)
It could be possible, perhaps, to have the "latching" part done a-la core memory: store charge in a "cell" made up of a capacitor storing enough charge to energize the coil momentarily -- long enough to latch a relay electrically (NO contact powering the coil). Let's see if it's feasible.
Say we use TYCO's TSC series relay. 6mA @ 24V for the coil, 5ms to operate so say we need it to stay, say, on for 20ms on capacitor charge alone. Final discharge voltage could be as low as 18V per the specs. We're discharging the cap through a 4kOhm resistor (24V/6mA). So a 30uF capacitor is plenty enough if we're starting from 24V, it'd be still around 20V after 20ms. I've used this handy tool. To keep refresh rates low, you could use a much larger capacitor.
So -- I'd say that a fairly small capacitor may be all that's needed to implement memory. You'd have row/column relays to connect the cap to the coil of the sense relay, and then that relay would latch itself electrically. They did have electrolytic caps with those specs back then (tens of of uF at 35V V.W.). The reads aren't even destructive -- the sense relay latches when the coil gets a kick from the stored charge, this energizes its coil from 24V using a N.O. contact that just closed. This also recharges the capacitor if there's no isolation diode between the capacitor and the coil. As soon as the row/column relays disconnect the capacitor is out of the circuit, fully re-charged.
If you had a full column of sense relays per each plane of memory, then refresh could be very fast as well. The circuitry for refresh (apart from refresh counter etc) is simple: one isolation relay per row, one sense relay per row, that's it. Nothing else is needed. The isolation relays close connecting the row outputs to sense relays, sense relays maintain the state of their capacitor and recharge it. If you wish, you could use the column of sense relays as the readout relays as well, then the isolation relays would be on the outside of the memory plane rather than on the inside -- they'd be connecting the memory to whatever bus it feeds.
You need one capacitor per bit, so 16 kbits worth of "RAM" would cost you approx. $500 for the capacitors (assuming you'd use through hole ESH476M035AE3AA from Kemet, those go for $0.03249 US each at 16k quantity from DigiKey). If you'd want it to be a 16 bit memory, then you have 16 planes of 1kbit each, organized 32x32 bits. Column select relays can be shared between planes, so you need 32 relays for that. Each plane needs 32 row sense relays for refresh and readout, and 32 row select relays for the output. So you need 32+32+2 relays per plane, or 16*66=1056 relays. That reduces your relay cost by a factor of 16, and reduces your power consumption even further since at most about half of these relays would be on at any given time -- you only select one row at a time for output. You'd also need some relays for the refresh counter. You could of course have 8 planes of 32x64 bits for an 8 bit memory, and then you'd need 576 relays (64 per plane for rows + 8 per plane for shared column selects).
The relays go for about $1.176 in 1000+, again from DigiKey. I'm sure you could optimize the relay count further, perhaps by using diode switches. You'd need to use some diodes anyway, for things like decoding row/column selects from the address bus and from the refresh counter, etc. If you'd hook up rows to the least significant address bits you could probably forgo a refresh counter and just assume that enough straight-line code gets executed that all rows will
I dislike architectures that have a very limited bunch of pretty much specialized registers. If you think Z80 is excellent, then you should look at Z8, and its refreshed version eZ8 -- they are even better. Zilog (now IXYS) is still making those chips, they are called Encore! You have 12 bit internal SRAM address space, accessible using either 4, 8 or 12 bit addressing. 4 and 8 bit addressing is paged, of course. The access using 4 bit addresses is what they refer to as "registers", even though there isn't all that much difference between various addressing modes, the most impact it has is on how many fetch cycles are needed. Since it's a Harvard architecture, fetches and execution cycles overlap.
An even cleaner, more uniform instruction set is offered by Parallax Propeller. Every instruction can be skipped based on flags, and every instruction's effects can be bypassed (you decide if it modifies flags or not).
I'm mostly with you on that one. Latching-vs-nonlatching relays are a big trade-off. You can get SPDT non-latching relays, or even DPDT ones, for less than a dollar in large quantity. But any significant quantity of them will need busbars for power distribution...
AC is really a stepping stone, as far as power distribution technology goes. The need for it is only when you don't have electronics with enough power-handling capability to partake in power distribution. Transformers working at 50 or 60Hz are monsters, pretty much. Without those transformers, there'd be no need for AC in power distribution. You can make more efficient switching power converters that are comparably tiny. You can push a couple megawatts through a ferrite ring fitting on a sheet of letter size paper. A 200A step-down converter that could power a typical American single family house would fit in a briefcase, with radiator fins sticking out of course (no air cooling and dust mites, thankyouverymuch).
I have a system that takes a bunch of 5kVA isolation transformers. A switching power converter that stands in for one of those transformers fits mostly on your palm. The incoming AC is a pain to deal with, because at those power levels you need to have power factor correction (PFC), and that's just an extra that lowers efficiency only because you need to pretend to be a resistive load to the incoming 50/60Hz sine voltage. If we had DC power distribution, there would be no need for PFC, no need for huge transformers. DC power distribution was a good idea, but pretty much ahead of its time -- useless without fairly complex electronics know-how. Design and testing of switching power supplies needs good instrumentation (wideband differential amps and current probes, storage oscilloscopes,...). At high power levels you need to build instrumentation into your product, because you can't really test a power converter taking 50kV at the input with the case open and sitting on your desk.
Are you saying that you know better than the entire MIT Electrical Engineering and Computer Science faculty.
An appeal to authority, I see. Well, they had a few choices, really: Pascal, C/C++, C#, Java, Python, and maybe assembly but for a sane architecture (I'd take Parallax Propeller over x86 anytime). Short of coming up with something brand new, anything they chose would have shortcomings one way or another. I would choose Pascal, but that's just me.
Java is not something you want to use to develop on an man-machine interface without a keyboard, without a big autocomplete system, and without all the documentation handy -- preferably on a second monitor, so as not to obscure your code. Development on a "small" screen with touch-based interface requires a paradigm shift. Anything less will be useless. If you can't code on it significantly faster than you would using a glass teletype, then it's not living up to its potential. The bandwidth of a multitouch input beats a teletype by an order of magnitude or more, I'd think. It must feel that way when you use it, too.
Agreed. The current state-of-the-art of graphical code builders does not utilize much of the available input. Pointer location shouldn't be only relegated to placing things on a virtual sheet of paper, just as mouse gestures shouldn't be only used to pan and zoom on that sheet.
I think that the language is a close-runner but of secondary concern. The first concern is making the development process work on a touchphone's/touchpad's man-machine interface. That's hard. It pretty much requires building the entire environment, including the language, from the bottom up. Reusing something that has been designed for keyboard entry, like BASIC, will suck, and then it doesn't matter much if it's BASIC, Python, Java, OCaml, FORTRAN, or what have you. I have yet to see real innovation in program entry. We have "block builders" like Scratch, Labview, Scade, ladder logic for PLCs, schematic entry for programmable logic, etc., but none of them leverages the two-dimensional multi-touch entry. Heck, all of those seem to be conceptually very thin and awkward front-ends to a completely textual language.
Those graphical program entry systems have been designed by people who did not have any demonstrated insight into man-machine interaction, and they have serious design shortcomings -- they all fail to leverage the 2D display efficiently. Ladder logic is like a flattened list of connections -- it uses screen real estate about as efficiently as a PDF viewer showing a netlist printout would. Labview and Scade are marginally better -- they are about as efficient as a schematic, with all of its viewing-a-big-landscape-through-a-porthole issues. Scratch is exactly like a BASIC listing using graphical wrappers around various elements of the AST. Oh, it takes many times more screen real estate than a listing would!
Most applications are UI-centric, as long as you're past the green-screen way of thinking. This means that whatever graphical language concept you come up with must be able to efficiently and safely represent UIs and their underlying logic. This pretty much kills the javascript- and similar event handler approaches right on the outset: those all sprinkle the state of the interface everywhere, and don't explicitly expose the hierarchical state machine that most UIs are. But a state machine is merely a convenient abstraction, it doesn't mean that just throwing, say, a UML statechart builder together will solve anything. Those still suffer from horribly low utilization of screen real estate, and have serious porthole shortcomings. Try doing anything of essence in the freely downloadable QM graphical modeling tool. It is, on the technical side, a rather brilliantly done piece of software (debugged to hell and back, it seems), yet suffers from horrendous usability. That's partly because UML statecharts of any significance occupy a lot of screen real estate, but also because this approach hardly uses any of the touchy-feely goodness available on a tablets/touchphones.
We need some real innovation here, and there are no canned solutions.
Redistribution applies to "here and now" -- that means that once you get some GPLd software from RedHat, you can redistribute as you please, but nowhere does it say that RedHat should provide any newer versions to you.
It is brilliant, but it's probably the only way to make GPL work commercially. You could be very easily selling some, say, specialized CAD software at $40k per seat, and have it GPLd. No one will pay that much just to exercise their GPL rights, and if they do, you still got the money, and all they have is a version that will be obsolete, sooner or later.
1. Access, as in access to a download site can be terminated without violating GPL. All that GPL requires is that, when you ask nicely (via a letter, say), they'll provide you with sources -- say via snail mail, given that you cover their reasonable costs.
2. They are under no obligation (under GPL) to provide you with updated sources indefinitely.
RedHat sometimes has SRPMS that slip through the cracks and are NOT available on their publicly accessible site. CentOS works quite hard on getting those together, because they can't just subscribe and pull them from the SRPMS section. RedHat is under no obligation to renew a subscription of those who break their terms of service.
Basically, if they terminate your subscription, they are not distributing anything newer to you, so you're stuck in time as far as access to the sources goes.
Heck, they can even do something cleverer, like Redhat does: they are free to cancel any subscription/service agreement that you may have with them if you exercise your rights to further redistribution. It does not violate GPL, for GPL is about distribution and distribution only, and they are not hindering your right to that. If you subscribe to RHEL, you are of course free to redistribute any source RPMs you downloaded from their network, but if you do so, they are free to cancel your subscription. And they will if you're a big enough fish (say, if you'd try to run your own "clone" distro based on their SRPMS).
This seems to be a sensible business model even to people who'd wish to sell their stuff for big bucks: who the heck will abandon a multi-$k subscription by exercising their right to redistribute GPL code? No one sane; in most cases, unless they have plenty of money to burn. Ah, and IIRC Redhat will not renew your subscription if so terminated: you're essentially blacklisting yourself for life.
GSM protocol is reasonably well documented, I wonder what would transpire if one wanted to implement it completely in software using something like XMOS or upcoming Parallax Propeller II architecture. Both are reasonably low-power, and the entire thing (radio modulator/demodulator, GSM compression/decompression, encryption/decryption, UI) could be done using a single CPU. Probably the radio could use very low component count, I'm sure the CPU could handle sampling 1st IF directly. It'd probably be a very simple, ultra-responsive phone... Maybe there's market for it? I'd sure want one.
The problem is that there aren't really truly dumb phones to be had new anymore. I have a Nokia 1100. Lasts 2-3 weeks on one charge, with occasional phone calls in-between recharges. I don't think it's being made anymore, or at least it doesn't seem like you can buy it new in the U.S. It has such a battery life because it has a low-power CPU that doesn't do much at all, and a monochrome LCD screen with simple LED backlight. I wish they made a better model like this -- with more modern components, it'd use even less power, and would probably last a month on a charge.
Modern "dumb" phones have color displays, web browsers, and a lot of seemingly battery-hogging dumbassery that runs in the background. My wife's dumb Motorola (don't know the exact model) lasts about 3 days on a charge, and that's with brand new battery. Oh, and the firmware's response to keypresses is delayed so much that it feels like editing line 2000 of a Basic program on a ZX Spectrum -- it had linear lookup for program editor and the further down you were, the slower it got (Schlemiel the painter).
I don't know how you did it, but I've been opening csv text files in Calc for many years. It works fine. You can select how to format the columns (numeric/text) and how are they separated (what character or where are the breaks in case of fixed format). It does exactly what you'd want it to do. How did you try to open that text file? Start up calc with a new spreadsheet, do Open, limit file types to Spreadsheet, click on your text file, and it'll pop up a text import dialog.
That's right. F-22 has avionics that are designed to be upgradeable to stay abreast of the technology march, and a lot of its capabilities rest with the processing power in the avionics cards. They have a modular system where there are three avionics bays, with only about 70% of the two of them used up by processing modules, the third one remaining at 0% utilization. The avionics cards feature programmable logic and if one fails, a spare gets reprogrammed on-line to pick up the functionality of the failed one. They only have 8 kinds of cards I think, and those cards implement everything from software-defined radio to radar to ECM, EW, threat identification, etc.
When the ECS system IVSC logic detected a manifold bleed air leak, a C BLEED HOT caution ICAW asserted. In this case, the logic commanded all bleed air regulating shutoff valves to close. This action protects against a bleed air induced aircraft fire. Closing all the valves results in the immediate loss of all ECS bleed and conditioned air flow, removing air flow to the OBOGS unit. The air bleed valves will remain closed for the duration of the flight, even if the caution ICAW clears.
Either I'm reading this wrong, or the fire prevention system closed the inlet valves on the oxygen generation system, and was designed to never reopen them after the fault (over temp) was resolved, until you landed. (maybe requiring a manual physical reset?)
That sounds like a really scary thing - if it thinks there's a fire it's going to cut off your oxygen, forever, to save you.
What it cuts off is not "inlet valves on the oxygen generation system", it cuts off the supply of VERY HOT air (up to 2000F/1000C) that has to go through two coolers (one cools it down to 400F, another to 50-60F) before it's used to feed various things, including the OBOGS -- oxygen generator.
The fire prevention system did the EXACTLY RIGHT THING. Here's what it detected: that air that is so hot that it will melt aluminum has escaped from the ducts where it's supposed to stay. Those ducts are made of high-temp alloys, nothing else is meant to survive that kind of treatment. There is no sane reset possible without figuring out where the leak was and fixing it. The bleed air is hotter than air from a general purpose heat gun -- hotter by 500-1000F, in fact. The fire protection system has multiple sensors and a detection in just one won't cut off bleed air, there has to be at least to separate sensors that detect the temperature rise.
Had the FPS not cut off the bleed air, you'd be reading about an in-flight fire instead. That means a forced bailout. Had the pilot managed to get emergency oxygen going in time, he may have made it to the airport unscathed -- that's a much less risky proposition than a bailout. Or at least he could have had time to pick up a better spot to bail out over, I don't know how long you can fly this plane without chilled air available.
Now be careful because this car analogy somewhat correct, but for different reasons that you think. Shit fails for various reasons. Training is there to survive it. When you lose all braking capability, you're likely screwed. I can't imagine that happening on a car, though, and it didn't happen in the accident F-22 either. If you lose all braking, that means your engine or transmission are dead, your hydraulic brakes are dead, and your mechanical emergency brake doesn't work either. That happening, all at once, would scare the living daylights out of me.
What happened on the F-22 was akin to having your hydraulic brakes fail. You still have the engine and the emergency brakes. The pilot still had the emergency oxygen system. Yes, its activator is an ultra stupid design, as is the latching emergency brake pedal on cars. If you have an american car with latching pedal emergency brake, you are likely to lock up two of the four wheels because you can't easily module the pressure on those brakes. Then you lose control and may be worse off than you started with. It's just as stupid as the side-mounted pull-ring thing on the ejection seat in F-22.
Sigh. None of this happened immediately, having supposedly read the report it's really dishonest to pretend otherwise. Cabin pressure warning appeared 55 seconds after C BLEED HOT. And that warning doesn't appear when the pressure is equal to the outside pressure, it appears when the cabin is above 10,000' IIRC. When you see C BLEED HOT, you initiate a descent and get emergency oxygen going. That's the training, as far as I can tell. None of this has anything to do with the real source of the problem: the fucked-up design of the activation device for emergency oxygen. The engineer who came up with that one was an idiot.
The pilot was conscious for at least 68 seconds after the C BLEED HOT caution message appeared. That is, he was conscious all the way to the ground. So while you're right, the assumptions you make did not apply in this particular incident at all.
It's a gradual failure. They have way more than 30s past the "C BLEED HOT" caution to do the right thing. The pilot does not have to wait for the "OBOGS FAIL" message -- C BLEED HOT will always be followed by OBOGS FAIL, and they know how their plane works. They are trained to decrease altitude and activate emergency oxygen when C BLEED HOT caution appears, since there's no going back from it. C BLEED HOT appearing means the isolation valves are permanently cutting off bleed air for the rest of the flight just about now. That's it.
Slashdot Mirror
If you think it's somehow Christian and necessary to "meet and defeat" all other nations, then you I think you should seek help because the whole idea has seriously whooshed over your head.
That's what I meant by "busbars for power distribution" :) You can of course use 48V coils to get lowest current at a safe voltage, but the dissipation will remain. And 48V small form factor relays aren't cheap. You could cheat and use optomos SSRs, but that's really aiming low ;)
It could be possible, perhaps, to have the "latching" part done a-la core memory: store charge in a "cell" made up of a capacitor storing enough charge to energize the coil momentarily -- long enough to latch a relay electrically (NO contact powering the coil). Let's see if it's feasible.
Say we use TYCO's TSC series relay. 6mA @ 24V for the coil, 5ms to operate so say we need it to stay, say, on for 20ms on capacitor charge alone. Final discharge voltage could be as low as 18V per the specs. We're discharging the cap through a 4kOhm resistor (24V/6mA). So a 30uF capacitor is plenty enough if we're starting from 24V, it'd be still around 20V after 20ms. I've used this handy tool. To keep refresh rates low, you could use a much larger capacitor.
So -- I'd say that a fairly small capacitor may be all that's needed to implement memory. You'd have row/column relays to connect the cap to the coil of the sense relay, and then that relay would latch itself electrically. They did have electrolytic caps with those specs back then (tens of of uF at 35V V.W.). The reads aren't even destructive -- the sense relay latches when the coil gets a kick from the stored charge, this energizes its coil from 24V using a N.O. contact that just closed. This also recharges the capacitor if there's no isolation diode between the capacitor and the coil. As soon as the row/column relays disconnect the capacitor is out of the circuit, fully re-charged.
If you had a full column of sense relays per each plane of memory, then refresh could be very fast as well. The circuitry for refresh (apart from refresh counter etc) is simple: one isolation relay per row, one sense relay per row, that's it. Nothing else is needed. The isolation relays close connecting the row outputs to sense relays, sense relays maintain the state of their capacitor and recharge it. If you wish, you could use the column of sense relays as the readout relays as well, then the isolation relays would be on the outside of the memory plane rather than on the inside -- they'd be connecting the memory to whatever bus it feeds.
You need one capacitor per bit, so 16 kbits worth of "RAM" would cost you approx. $500 for the capacitors (assuming you'd use through hole ESH476M035AE3AA from Kemet, those go for $0.03249 US each at 16k quantity from DigiKey). If you'd want it to be a 16 bit memory, then you have 16 planes of 1kbit each, organized 32x32 bits. Column select relays can be shared between planes, so you need 32 relays for that. Each plane needs 32 row sense relays for refresh and readout, and 32 row select relays for the output. So you need 32+32+2 relays per plane, or 16*66=1056 relays. That reduces your relay cost by a factor of 16, and reduces your power consumption even further since at most about half of these relays would be on at any given time -- you only select one row at a time for output. You'd also need some relays for the refresh counter. You could of course have 8 planes of 32x64 bits for an 8 bit memory, and then you'd need 576 relays (64 per plane for rows + 8 per plane for shared column selects).
The relays go for about $1.176 in 1000+, again from DigiKey. I'm sure you could optimize the relay count further, perhaps by using diode switches. You'd need to use some diodes anyway, for things like decoding row/column selects from the address bus and from the refresh counter, etc. If you'd hook up rows to the least significant address bits you could probably forgo a refresh counter and just assume that enough straight-line code gets executed that all rows will
I dislike architectures that have a very limited bunch of pretty much specialized registers. If you think Z80 is excellent, then you should look at Z8, and its refreshed version eZ8 -- they are even better. Zilog (now IXYS) is still making those chips, they are called Encore! You have 12 bit internal SRAM address space, accessible using either 4, 8 or 12 bit addressing. 4 and 8 bit addressing is paged, of course. The access using 4 bit addresses is what they refer to as "registers", even though there isn't all that much difference between various addressing modes, the most impact it has is on how many fetch cycles are needed. Since it's a Harvard architecture, fetches and execution cycles overlap.
An even cleaner, more uniform instruction set is offered by Parallax Propeller. Every instruction can be skipped based on flags, and every instruction's effects can be bypassed (you decide if it modifies flags or not).
I'm mostly with you on that one. Latching-vs-nonlatching relays are a big trade-off. You can get SPDT non-latching relays, or even DPDT ones, for less than a dollar in large quantity. But any significant quantity of them will need busbars for power distribution...
It still is being held back. Just look at how much time politicians waste on discussing abortion, same sex marriage, etc.
AC is really a stepping stone, as far as power distribution technology goes. The need for it is only when you don't have electronics with enough power-handling capability to partake in power distribution. Transformers working at 50 or 60Hz are monsters, pretty much. Without those transformers, there'd be no need for AC in power distribution. You can make more efficient switching power converters that are comparably tiny. You can push a couple megawatts through a ferrite ring fitting on a sheet of letter size paper. A 200A step-down converter that could power a typical American single family house would fit in a briefcase, with radiator fins sticking out of course (no air cooling and dust mites, thankyouverymuch).
I have a system that takes a bunch of 5kVA isolation transformers. A switching power converter that stands in for one of those transformers fits mostly on your palm. The incoming AC is a pain to deal with, because at those power levels you need to have power factor correction (PFC), and that's just an extra that lowers efficiency only because you need to pretend to be a resistive load to the incoming 50/60Hz sine voltage. If we had DC power distribution, there would be no need for PFC, no need for huge transformers. DC power distribution was a good idea, but pretty much ahead of its time -- useless without fairly complex electronics know-how. Design and testing of switching power supplies needs good instrumentation (wideband differential amps and current probes, storage oscilloscopes, ...). At high power levels you need to build instrumentation into your product, because you can't really test a power converter taking 50kV at the input with the case open and sitting on your desk.
Are you saying that you know better than the entire MIT Electrical Engineering and Computer Science faculty.
An appeal to authority, I see. Well, they had a few choices, really: Pascal, C/C++, C#, Java, Python, and maybe assembly but for a sane architecture (I'd take Parallax Propeller over x86 anytime). Short of coming up with something brand new, anything they chose would have shortcomings one way or another. I would choose Pascal, but that's just me.
Java is not something you want to use to develop on an man-machine interface without a keyboard, without a big autocomplete system, and without all the documentation handy -- preferably on a second monitor, so as not to obscure your code. Development on a "small" screen with touch-based interface requires a paradigm shift. Anything less will be useless. If you can't code on it significantly faster than you would using a glass teletype, then it's not living up to its potential. The bandwidth of a multitouch input beats a teletype by an order of magnitude or more, I'd think. It must feel that way when you use it, too.
Agreed. The current state-of-the-art of graphical code builders does not utilize much of the available input. Pointer location shouldn't be only relegated to placing things on a virtual sheet of paper, just as mouse gestures shouldn't be only used to pan and zoom on that sheet.
I think that the language is a close-runner but of secondary concern. The first concern is making the development process work on a touchphone's/touchpad's man-machine interface. That's hard. It pretty much requires building the entire environment, including the language, from the bottom up. Reusing something that has been designed for keyboard entry, like BASIC, will suck, and then it doesn't matter much if it's BASIC, Python, Java, OCaml, FORTRAN, or what have you. I have yet to see real innovation in program entry. We have "block builders" like Scratch, Labview, Scade, ladder logic for PLCs, schematic entry for programmable logic, etc., but none of them leverages the two-dimensional multi-touch entry. Heck, all of those seem to be conceptually very thin and awkward front-ends to a completely textual language.
Those graphical program entry systems have been designed by people who did not have any demonstrated insight into man-machine interaction, and they have serious design shortcomings -- they all fail to leverage the 2D display efficiently. Ladder logic is like a flattened list of connections -- it uses screen real estate about as efficiently as a PDF viewer showing a netlist printout would. Labview and Scade are marginally better -- they are about as efficient as a schematic, with all of its viewing-a-big-landscape-through-a-porthole issues. Scratch is exactly like a BASIC listing using graphical wrappers around various elements of the AST. Oh, it takes many times more screen real estate than a listing would!
Most applications are UI-centric, as long as you're past the green-screen way of thinking. This means that whatever graphical language concept you come up with must be able to efficiently and safely represent UIs and their underlying logic. This pretty much kills the javascript- and similar event handler approaches right on the outset: those all sprinkle the state of the interface everywhere, and don't explicitly expose the hierarchical state machine that most UIs are. But a state machine is merely a convenient abstraction, it doesn't mean that just throwing, say, a UML statechart builder together will solve anything. Those still suffer from horribly low utilization of screen real estate, and have serious porthole shortcomings. Try doing anything of essence in the freely downloadable QM graphical modeling tool. It is, on the technical side, a rather brilliantly done piece of software (debugged to hell and back, it seems), yet suffers from horrendous usability. That's partly because UML statecharts of any significance occupy a lot of screen real estate, but also because this approach hardly uses any of the touchy-feely goodness available on a tablets/touchphones.
We need some real innovation here, and there are no canned solutions.
Redistribution applies to "here and now" -- that means that once you get some GPLd software from RedHat, you can redistribute as you please, but nowhere does it say that RedHat should provide any newer versions to you.
It is brilliant, but it's probably the only way to make GPL work commercially. You could be very easily selling some, say, specialized CAD software at $40k per seat, and have it GPLd. No one will pay that much just to exercise their GPL rights, and if they do, you still got the money, and all they have is a version that will be obsolete, sooner or later.
1. Access, as in access to a download site can be terminated without violating GPL. All that GPL requires is that, when you ask nicely (via a letter, say), they'll provide you with sources -- say via snail mail, given that you cover their reasonable costs.
2. They are under no obligation (under GPL) to provide you with updated sources indefinitely.
RedHat sometimes has SRPMS that slip through the cracks and are NOT available on their publicly accessible site. CentOS works quite hard on getting those together, because they can't just subscribe and pull them from the SRPMS section. RedHat is under no obligation to renew a subscription of those who break their terms of service.
Basically, if they terminate your subscription, they are not distributing anything newer to you, so you're stuck in time as far as access to the sources goes.
Heck, they can even do something cleverer, like Redhat does: they are free to cancel any subscription/service agreement that you may have with them if you exercise your rights to further redistribution. It does not violate GPL, for GPL is about distribution and distribution only, and they are not hindering your right to that. If you subscribe to RHEL, you are of course free to redistribute any source RPMs you downloaded from their network, but if you do so, they are free to cancel your subscription. And they will if you're a big enough fish (say, if you'd try to run your own "clone" distro based on their SRPMS).
This seems to be a sensible business model even to people who'd wish to sell their stuff for big bucks: who the heck will abandon a multi-$k subscription by exercising their right to redistribute GPL code? No one sane; in most cases, unless they have plenty of money to burn. Ah, and IIRC Redhat will not renew your subscription if so terminated: you're essentially blacklisting yourself for life.
Sigh, have to get off my ass (or rather on it, as it were), and move the domains at work elsewhere. Where, is the question, then. Any hints?
GSM protocol is reasonably well documented, I wonder what would transpire if one wanted to implement it completely in software using something like XMOS or upcoming Parallax Propeller II architecture. Both are reasonably low-power, and the entire thing (radio modulator/demodulator, GSM compression/decompression, encryption/decryption, UI) could be done using a single CPU. Probably the radio could use very low component count, I'm sure the CPU could handle sampling 1st IF directly. It'd probably be a very simple, ultra-responsive phone... Maybe there's market for it? I'd sure want one.
The problem is that there aren't really truly dumb phones to be had new anymore. I have a Nokia 1100. Lasts 2-3 weeks on one charge, with occasional phone calls in-between recharges. I don't think it's being made anymore, or at least it doesn't seem like you can buy it new in the U.S. It has such a battery life because it has a low-power CPU that doesn't do much at all, and a monochrome LCD screen with simple LED backlight. I wish they made a better model like this -- with more modern components, it'd use even less power, and would probably last a month on a charge.
Modern "dumb" phones have color displays, web browsers, and a lot of seemingly battery-hogging dumbassery that runs in the background. My wife's dumb Motorola (don't know the exact model) lasts about 3 days on a charge, and that's with brand new battery. Oh, and the firmware's response to keypresses is delayed so much that it feels like editing line 2000 of a Basic program on a ZX Spectrum -- it had linear lookup for program editor and the further down you were, the slower it got (Schlemiel the painter).
He had a minute to get his act together. Look in the report. Don't make stuff up. The failure isn't abrupt, things fail gradually.
I don't know how you did it, but I've been opening csv text files in Calc for many years. It works fine. You can select how to format the columns (numeric/text) and how are they separated (what character or where are the breaks in case of fixed format). It does exactly what you'd want it to do. How did you try to open that text file? Start up calc with a new spreadsheet, do Open, limit file types to Spreadsheet, click on your text file, and it'll pop up a text import dialog.
That's right. F-22 has avionics that are designed to be upgradeable to stay abreast of the technology march, and a lot of its capabilities rest with the processing power in the avionics cards. They have a modular system where there are three avionics bays, with only about 70% of the two of them used up by processing modules, the third one remaining at 0% utilization. The avionics cards feature programmable logic and if one fails, a spare gets reprogrammed on-line to pick up the functionality of the failed one. They only have 8 kinds of cards I think, and those cards implement everything from software-defined radio to radar to ECM, EW, threat identification, etc.
When the ECS system IVSC logic detected a manifold bleed air leak, a C BLEED HOT caution ICAW asserted. In this case, the logic commanded all bleed air regulating shutoff valves to close. This action protects against a bleed air induced aircraft fire. Closing all the valves results in the immediate loss of all ECS bleed and conditioned air flow, removing air flow to the OBOGS unit. The air bleed valves will remain closed for the duration of the flight, even if the caution ICAW clears.
Either I'm reading this wrong, or the fire prevention system closed the inlet valves on the oxygen generation system, and was designed to never reopen them after the fault (over temp) was resolved, until you landed. (maybe requiring a manual physical reset?)
That sounds like a really scary thing - if it thinks there's a fire it's going to cut off your oxygen, forever, to save you.
What it cuts off is not "inlet valves on the oxygen generation system", it cuts off the supply of VERY HOT air (up to 2000F/1000C) that has to go through two coolers (one cools it down to 400F, another to 50-60F) before it's used to feed various things, including the OBOGS -- oxygen generator.
The fire prevention system did the EXACTLY RIGHT THING. Here's what it detected: that air that is so hot that it will melt aluminum has escaped from the ducts where it's supposed to stay. Those ducts are made of high-temp alloys, nothing else is meant to survive that kind of treatment. There is no sane reset possible without figuring out where the leak was and fixing it. The bleed air is hotter than air from a general purpose heat gun -- hotter by 500-1000F, in fact. The fire protection system has multiple sensors and a detection in just one won't cut off bleed air, there has to be at least to separate sensors that detect the temperature rise.
Had the FPS not cut off the bleed air, you'd be reading about an in-flight fire instead. That means a forced bailout. Had the pilot managed to get emergency oxygen going in time, he may have made it to the airport unscathed -- that's a much less risky proposition than a bailout. Or at least he could have had time to pick up a better spot to bail out over, I don't know how long you can fly this plane without chilled air available.
An even bigger factor is that every man in the ground support is very costly. No LOX means big cumulative savings on the ground support side.
Now be careful because this car analogy somewhat correct, but for different reasons that you think. Shit fails for various reasons. Training is there to survive it. When you lose all braking capability, you're likely screwed. I can't imagine that happening on a car, though, and it didn't happen in the accident F-22 either. If you lose all braking, that means your engine or transmission are dead, your hydraulic brakes are dead, and your mechanical emergency brake doesn't work either. That happening, all at once, would scare the living daylights out of me.
What happened on the F-22 was akin to having your hydraulic brakes fail. You still have the engine and the emergency brakes. The pilot still had the emergency oxygen system. Yes, its activator is an ultra stupid design, as is the latching emergency brake pedal on cars. If you have an american car with latching pedal emergency brake, you are likely to lock up two of the four wheels because you can't easily module the pressure on those brakes. Then you lose control and may be worse off than you started with. It's just as stupid as the side-mounted pull-ring thing on the ejection seat in F-22.
Sigh. None of this happened immediately, having supposedly read the report it's really dishonest to pretend otherwise. Cabin pressure warning appeared 55 seconds after C BLEED HOT. And that warning doesn't appear when the pressure is equal to the outside pressure, it appears when the cabin is above 10,000' IIRC. When you see C BLEED HOT, you initiate a descent and get emergency oxygen going. That's the training, as far as I can tell. None of this has anything to do with the real source of the problem: the fucked-up design of the activation device for emergency oxygen. The engineer who came up with that one was an idiot.
I entirely agree.
The pilot was conscious for at least 68 seconds after the C BLEED HOT caution message appeared. That is, he was conscious all the way to the ground. So while you're right, the assumptions you make did not apply in this particular incident at all.
It's a gradual failure. They have way more than 30s past the "C BLEED HOT" caution to do the right thing. The pilot does not have to wait for the "OBOGS FAIL" message -- C BLEED HOT will always be followed by OBOGS FAIL, and they know how their plane works. They are trained to decrease altitude and activate emergency oxygen when C BLEED HOT caution appears, since there's no going back from it. C BLEED HOT appearing means the isolation valves are permanently cutting off bleed air for the rest of the flight just about now. That's it.