As far as electrolytic balance goes, usually if you can't taste it, it's not there. Minerals != electrolytes. Crazy tasty mineral water won't help you in a marathon, you need to add sodium and potassium to the water. As far as bioavailable sodium and potassium is concerned, mineral waters, tap water, and ultrapure spectroscopy-grade water are all equally bad.
In general, you don't get sufficient trace minerals from water unless you select your drinking water to be rich in them all, and that's not that trivial. If you go to a random "mineral" water source, even with pretty "full" taste, you'll find it's probably loaded with a couple minerals and whatever else is there is most likely insufficient anyway. You need solid foods, end of story. Cataracts are not due to mineral deficiencies, they are due to denaturation of lens protein. UV exposure and ionizing radiation will do that to you; airline pilots get them more often than general population, for example.
Purified water is pretty much same as tap water as far as very young infants are concerned: it will give them electrolyte imbalance, and that will kill an infant much faster than it'd kill an adult. Purified water and tap water are equivalently devoid of sodium and potassium, and that's what counts, not some nebulous minerals that give water a pleasant taste and are omnipresent in marketing (supposed health benefits, my ass).
There's no way, I don't think, to have liquid water with things merely dissolved in it and it being ever sufficient nutritionally. So even if you got water saturated with whatever you can saturate it, it wouldn't help you. So this whole idea is just silly. You need to be taking in some solids, or at least emulsions (breast milk, duh).
Saying that something is "healthier" because it's got some minerals dissolved in it is just repeating marketing speak. It means zilch. It's what the marketing departments the world over want you to believe, but it's pure, unadulterated fantasy.
So, let's repeat: if you had only water with dissolved stuff to drink, you'd die probably within a couple months at best. Just check what human nutritional needs are, and how much of that stuff is water soluble (and what the solubilities are!). Let's be clear: I'm talking about a solution, perhaps even a saturated one, but not about an emulsion, and that IIRC implies that using soap-like action to smuggle lipids is out of question, as I don't think that soap in water is technically a solution anymore -- someone please correct me if I'm wrong, though.
This being out of the way, it's only sane to assume we're getting most of the nutrients via solid foods, and those contain really the minerals that we need. The water can be completely pure. It won't strip you from anything, because as soon as it mixes with solid foods being digested in your stomach, it becomes loaded chock full of those minerals that it just leeched out from the food, not from your freakin' body for crying out loud. The body won't be getting a chance to truly get rid of any minerals in the net -- whatever it loses gets quite promptly replaced.
So please, stop with the silliness of it all, because this whole "stripping minerals from your body" by drinking pure water is a notion that's completely meaningless in real life. It would only be meaningful if you drank that water and had nothing else to eat or drink, and I think we're both satisfied that this is no good no matter what's dissolved in the water.
Water intoxication has nothing to do with minerals, it's about electrolytic imbalance -- you pee out sodium and potassium, and since peeing is the only way you'll get rid of the water (short of having diarrhea or puking it out), you will eventually run out, usually first of sodium. And that will be lethal.
Free electrons are exactly equivalent, talking about getting a "different" electron is meaningless. That's the problem you get with the quantum world: common sense terms simply don't apply to it in certain cases. Just because you can conjure up some adjective and stick it to an electron doesn't have to mean anything.
There's no way, in general, experimentally, to "mark" electrons to figure out if at some later time someone hands you those electrons back, you're still looking at same ones or not. Same applies to atoms in ground energy states: there's no way to mark them. Heck, this applies to molecules, too. Standard disclaimer: someone more clued in please chime in if I'm talking BS.
I think that industrial grade desalination is done using flash vaporization where the salt water vaporizes while not being in contact with anything solid (nothing to clog). The saltwater is pressurized and overheated, still a liquid. It's then directed via nozzles into a large container. It leaves a nozzle at a very high pressure, the pressure drops as you get away from the nozzle, eventually it's low enough that the water vaporizes. The salt becomes a solid powder, suspended in water vapor -- it's akin to what you'd have in a sandstorm, only much hotter, and the gas is different. You then separate the two, condense the water vapor into fresh water (and recover some heat while doing so), and that's it.
In case of FF, it doesn't have that kind of memory leaks, or at least they'd be easy to fix. Those leaks are internal to FF and you couldn't control them from javascript. The problem it has is that it's very easy to inadvertently hold a reference that's not needed anymore -- said reference can easily hold up tens of megabytes of memory. A reference to anything within a DOM of a webpage requires holding up a whole compartment for that webpage. So you may think you're "just" holding a reference to a tiny part of a DOM, but it's really referencing everything else in that DOM due to the way a DOM is structured (a big tree). Heck, I haven't checked it but it may be that you only need a reference to a string within the DOM, not to any DOM node proper. A string itself doesn't reference anything else, but since it's within a compartment, the whole compartment will be held nevertheless. Someone who knows FF internals please correct me on that if I'm talking out of my ass.
You do care about memory usage, for a nefarious reason: garbage collection pauses scale with memory usage. Pretty much all Firefox "freezes" are garbage collection pauses. The cycle collector seems to be the worst offender, IIRC, it can take tens of seconds in pathological cases. Unfortunately we're not running Firefox on Azul Vega processors, it'd be a whole different ballgame then as the latter have hardware assist for garbage collection.
I completely agree with TFA. We're in an age where computers are so ubiquitous that it's ridiculous not to use them to the fullest extent: and that means programming things specifically to automate the routine in your life, but also knowing programming to understand public policy as it relates to computing! This is, at this day and age, a civic requirement IMHO. Recent events, such as bastardized IP protection measures, varied, unpredictable and often overreaching punishment for even victimless and damage-less "hacking", indicate that the society is turning into a medieval system.
We have those who understand and those who do not, and those who do understand (or pretend to!) often wield political and fiscal power over general computer-illiterate society. This is why so many IT projects fail: people don't apply common sense to these projects, because computing is almost ingrained as a magical black box in our culture. Otherwise "successful" managers and executives waste billions because they just can't reconcile their pre-computing education and experience with this newfangled magic. There is no immediate backlash for things like SOPA or PIPA because it's all foreign concepts to most people!
I believe that it's a basic civic requirement to have computer literacy that encompasses basics of programming, networking but also social engineering as internet gave us orders of magnitude bigger exposure to the latter. One must understand what vulnerabilities are and how they come to be, what are exploits (and "hacking"), what really happens on internet (and how messing with it may make things pretty miserable for the most of us), etc. I believe, in fact, that such computer literacy is more of a civic requirement than most of history, the latter mostly taught in abstract and without clear link to current events.
You don't do it for general applications, you do it for very specific niche things where if you want decently performing code you better be on top of the architecture you code for. I have a scope display application that is exactly like you say: it's timed to utilize every clock cycle for DDR3 access. The DRAM runs at 100% theoretically possible utilization, and the code is written around it.
To me, a lecture is something that you do in an auditorium with a couple hundred students -- think of general undergraduate courses. I don't think there's much use for asking students questions in such a setting: at best it will give you feedback from a couple % of students. You can't have a discussion with 200 people, not without a moderator within the audience, and even then: what would be the point? You're learning very little about majority of the students, my experience is that you'll get a couple who are comfortable speaking out in public, and they may not necessarily the ones who bring the most to the discussion.
Of course if you're teaching a graduate course with 15 people enrolled, it can be very interactive, but that's not what I'd consider a general lecture.
I think that brick is particularly expensive in the U.S., while in Europe you'll find that lumber may be more expensive I'd think. That was my experience, at least.
If a video of a lecture is as useful as the live lecture, it's a bad lecture.
I'd be careful with that statement. If you claim there must be some interaction, then let's get real: you don't want to be interrupted by questions every 15 seconds. So live questioning as a feedback from students to the lecturer is out. Then the most interaction you'll get is the lecturer looking at faces and body language of students.
But what does that tell the lecturer? Nothing that's very applicable when the medium is video!! In a video lecture, if you feel like falling asleep, you pause it, get up, walk around, come back refreshed, start watching again a few minutes back into the recording to get back on topic. If you need to look something up, you can pause, google for it, look in a book, look in previous lectures, then resume when you're ready. Those two situations cover most of the realtime feedback a lecturer would use, I'd presume. So, failing to show particular examples of how the reverse channel helps in a prerecorded lecture, I call your claim an gross exaggeration at best. Audience feedback is important in a live lecture setting, recorded lectures are really quite different because the student controls the playback. Good luck pausing the professor when you feel like dozing off for 45 minutes in the auditorium:)
It's not about how much die area the microcode takes, it's about how much die area everything else needed to run this microcode efficiently is taking! Properly designed opcodes would obviate trace generator, branch predictor, register reallocator, parts of northbridge, etc. Now that takes a lot of space. In case of x86 ISA it's not about legacy opcodes really, it's about all the missing opcodes (and registers) that a well performing architecture should have. That's what I mean by it being 30 years behind. Even fairly aged DSPs like 2100 architecture from Analog Devices have dedicated address generators and loop generators that are fully controlled by the code -- this alone means you don't need prediction logic, and this could be exploited by the northridge (were it in a general purpose CPU) to optimally schedule DRAM cycles.
It seems to be fairly useless for things other than very limited specialized tasks. 128 words of memory per core? What the heck? Even with 512 words per core on Parallax Propeller, people are fighting to get things going without having to access the shared and slow hub memory. Fitting everything in 512 words (2 kbytes) is hard, 128 words makes it more than 4 times harder. Their architecture basically implements a very simple dialect of FORTH in hardware. It's very hard to design systems of any considerable complexity using such simple CPUs without proper support from software development tools. It seems to me that this is the eventual undoing of all small-but-potentially-fast architectures: the development tools suck and do not help you in partitioning, simulating and validating your problem. XMOS seems to be going the right way about it -- they at least provide decent (high bandwidth) realtime debugging and they have a static timing verifier that's a must in real-time applications those chips are good for. I'd love to use F18 if only the damn thing had modern tools to support development on it, not something that feels like a trip back to the 70s. So far, it seems like a decent, perhaps more flexible, low-power replacement for small programmable logic, but it requires a lot of effort to get anything done on it. Their hardware, albeit fairly pretty, is useless without decent tools. Their disdain for common terms and introduction of their own terminology in their literature doesn't help. If they don't get their act together with a proper development environment, they will sink, they must understand that.
The ideas from inmos are alive and well at XMOS. I use their two core chip and I'm fairly happy -- it's plenty fast for what I use it for (industrial data collection). If only they documented the darn thing better.
Intel instruction set architecture requires a lot of hardware to execute efficiently. That's the price we all pay for using an instruction set that is 3 decades behind the hardware it runs on.
There's plenty of perhaps specialized but still fairly common digital signal processing that doesn't care at all about those "advances" in processor design. All it needs to do is plenty of multiplies-and-adds, saturated operations, test-and-modifies, etc. It doesn't require branch predictors, virtual memory, memory protection, layered caches, cache coherency, speculative execution, and plenty of other stuff that's needed to make x86 perform decently. The x86 instruction set is just very bad at extracting useful performance from CPU hardware without a lot of pre-processing. Even in the 80s you had DSP processors that had memory addressing units that would do circular buffers and strided access, as well as hardware loop generators. That way operands and data were always fetched from where they were supposed to come from, there was no speculation, loops had no overhead, and interleaving or parallelizing execution and fetches was easy to do, with no worry about data dependencies (whoever wrote the software would have already taken care of it), etc.
A lot of digital signal processing, that those chips would seem useful for, requires sequential access at very high bandwidths. When used that way, modern DRAM has no latency to speak of.
Agreed. I'm working on a digital oscilloscope display system and that thing might be very useful in this application -- where you need lots of bandwith, but also plenty of storage. Say, zooming, filtering, scaling of one second long acquisition done at 2Gs/s, using a 12 bit digitizer. You tweak the knobs, it updates, all in real time. In the worst case, you need about 120 Gbytes/s memory bandwidth to make it real time on a 30FPS display. And that's assuming the filter coefficients don't take up any bandwidth, because if they do you've just upped the bandwidth to terabytes/s.
Yeah, they're deliberately fucking up on a car that they spent few billion on to get out to market in near record time.
You haven't seen much corporate stupidity from on-high if you think they wouldn't be capable of doing precisely that. I'm not saying they are doing it at all, just that no one should be putting it besides them.
Are you sure that NiMH drained to, say, 10% of normal cell voltage, is ruined? I've had plenty of NiMH cells that self-discharged to less than that and they still had full capacity after two subsequent charge-discharge cycles. So something is fishy in your post, unless you claim that NiMH is not suitable for use in an electric vehicle...
I don't see a big deal here: you want it on the network, you put a gateway that encrypts the connection, verifies the certificates of the accessing party, etc. Like any tiny linux-running internet-enabler gizmo would do, when properly configured, even using nothing more than ssh. There's nothing inherently bad about those PLCs, it's the dumb implementers who have no clue. If you integrate solutions that involve networking, get someone with a clue in that area. Most industry "specialists" who deal with PLC have little clue about internet, network safety, etc. They have a different skillset: they know the quirks of various PLCs, I/Os, they know various industrial networking protocols (those have nothing to do with internet, many don't even use ethernet), and so on.
Slashdot Mirror
As far as electrolytic balance goes, usually if you can't taste it, it's not there. Minerals != electrolytes. Crazy tasty mineral water won't help you in a marathon, you need to add sodium and potassium to the water. As far as bioavailable sodium and potassium is concerned, mineral waters, tap water, and ultrapure spectroscopy-grade water are all equally bad.
In general, you don't get sufficient trace minerals from water unless you select your drinking water to be rich in them all, and that's not that trivial. If you go to a random "mineral" water source, even with pretty "full" taste, you'll find it's probably loaded with a couple minerals and whatever else is there is most likely insufficient anyway. You need solid foods, end of story. Cataracts are not due to mineral deficiencies, they are due to denaturation of lens protein. UV exposure and ionizing radiation will do that to you; airline pilots get them more often than general population, for example.
Are you trying to replace Dr. Bob?
Purified water is pretty much same as tap water as far as very young infants are concerned: it will give them electrolyte imbalance, and that will kill an infant much faster than it'd kill an adult. Purified water and tap water are equivalently devoid of sodium and potassium, and that's what counts, not some nebulous minerals that give water a pleasant taste and are omnipresent in marketing (supposed health benefits, my ass).
There's no way, I don't think, to have liquid water with things merely dissolved in it and it being ever sufficient nutritionally. So even if you got water saturated with whatever you can saturate it, it wouldn't help you. So this whole idea is just silly. You need to be taking in some solids, or at least emulsions (breast milk, duh).
Saying that something is "healthier" because it's got some minerals dissolved in it is just repeating marketing speak. It means zilch. It's what the marketing departments the world over want you to believe, but it's pure, unadulterated fantasy.
So, let's repeat: if you had only water with dissolved stuff to drink, you'd die probably within a couple months at best. Just check what human nutritional needs are, and how much of that stuff is water soluble (and what the solubilities are!). Let's be clear: I'm talking about a solution, perhaps even a saturated one, but not about an emulsion, and that IIRC implies that using soap-like action to smuggle lipids is out of question, as I don't think that soap in water is technically a solution anymore -- someone please correct me if I'm wrong, though.
This being out of the way, it's only sane to assume we're getting most of the nutrients via solid foods, and those contain really the minerals that we need. The water can be completely pure. It won't strip you from anything, because as soon as it mixes with solid foods being digested in your stomach, it becomes loaded chock full of those minerals that it just leeched out from the food, not from your freakin' body for crying out loud. The body won't be getting a chance to truly get rid of any minerals in the net -- whatever it loses gets quite promptly replaced.
So please, stop with the silliness of it all, because this whole "stripping minerals from your body" by drinking pure water is a notion that's completely meaningless in real life. It would only be meaningful if you drank that water and had nothing else to eat or drink, and I think we're both satisfied that this is no good no matter what's dissolved in the water.
Water intoxication has nothing to do with minerals, it's about electrolytic imbalance -- you pee out sodium and potassium, and since peeing is the only way you'll get rid of the water (short of having diarrhea or puking it out), you will eventually run out, usually first of sodium. And that will be lethal.
Free electrons are exactly equivalent, talking about getting a "different" electron is meaningless. That's the problem you get with the quantum world: common sense terms simply don't apply to it in certain cases. Just because you can conjure up some adjective and stick it to an electron doesn't have to mean anything.
There's no way, in general, experimentally, to "mark" electrons to figure out if at some later time someone hands you those electrons back, you're still looking at same ones or not. Same applies to atoms in ground energy states: there's no way to mark them. Heck, this applies to molecules, too. Standard disclaimer: someone more clued in please chime in if I'm talking BS.
I think that industrial grade desalination is done using flash vaporization where the salt water vaporizes while not being in contact with anything solid (nothing to clog). The saltwater is pressurized and overheated, still a liquid. It's then directed via nozzles into a large container. It leaves a nozzle at a very high pressure, the pressure drops as you get away from the nozzle, eventually it's low enough that the water vaporizes. The salt becomes a solid powder, suspended in water vapor -- it's akin to what you'd have in a sandstorm, only much hotter, and the gas is different. You then separate the two, condense the water vapor into fresh water (and recover some heat while doing so), and that's it.
Second that. Helium will happily go through glass, even inch thick glass.
In case of FF, it doesn't have that kind of memory leaks, or at least they'd be easy to fix. Those leaks are internal to FF and you couldn't control them from javascript. The problem it has is that it's very easy to inadvertently hold a reference that's not needed anymore -- said reference can easily hold up tens of megabytes of memory. A reference to anything within a DOM of a webpage requires holding up a whole compartment for that webpage. So you may think you're "just" holding a reference to a tiny part of a DOM, but it's really referencing everything else in that DOM due to the way a DOM is structured (a big tree). Heck, I haven't checked it but it may be that you only need a reference to a string within the DOM, not to any DOM node proper. A string itself doesn't reference anything else, but since it's within a compartment, the whole compartment will be held nevertheless. Someone who knows FF internals please correct me on that if I'm talking out of my ass.
You do care about memory usage, for a nefarious reason: garbage collection pauses scale with memory usage. Pretty much all Firefox "freezes" are garbage collection pauses. The cycle collector seems to be the worst offender, IIRC, it can take tens of seconds in pathological cases. Unfortunately we're not running Firefox on Azul Vega processors, it'd be a whole different ballgame then as the latter have hardware assist for garbage collection.
I completely agree with TFA. We're in an age where computers are so ubiquitous that it's ridiculous not to use them to the fullest extent: and that means programming things specifically to automate the routine in your life, but also knowing programming to understand public policy as it relates to computing! This is, at this day and age, a civic requirement IMHO. Recent events, such as bastardized IP protection measures, varied, unpredictable and often overreaching punishment for even victimless and damage-less "hacking", indicate that the society is turning into a medieval system.
We have those who understand and those who do not, and those who do understand (or pretend to!) often wield political and fiscal power over general computer-illiterate society. This is why so many IT projects fail: people don't apply common sense to these projects, because computing is almost ingrained as a magical black box in our culture. Otherwise "successful" managers and executives waste billions because they just can't reconcile their pre-computing education and experience with this newfangled magic. There is no immediate backlash for things like SOPA or PIPA because it's all foreign concepts to most people!
I believe that it's a basic civic requirement to have computer literacy that encompasses basics of programming, networking but also social engineering as internet gave us orders of magnitude bigger exposure to the latter. One must understand what vulnerabilities are and how they come to be, what are exploits (and "hacking"), what really happens on internet (and how messing with it may make things pretty miserable for the most of us), etc. I believe, in fact, that such computer literacy is more of a civic requirement than most of history, the latter mostly taught in abstract and without clear link to current events.
You don't do it for general applications, you do it for very specific niche things where if you want decently performing code you better be on top of the architecture you code for. I have a scope display application that is exactly like you say: it's timed to utilize every clock cycle for DDR3 access. The DRAM runs at 100% theoretically possible utilization, and the code is written around it.
To me, a lecture is something that you do in an auditorium with a couple hundred students -- think of general undergraduate courses. I don't think there's much use for asking students questions in such a setting: at best it will give you feedback from a couple % of students. You can't have a discussion with 200 people, not without a moderator within the audience, and even then: what would be the point? You're learning very little about majority of the students, my experience is that you'll get a couple who are comfortable speaking out in public, and they may not necessarily the ones who bring the most to the discussion.
Of course if you're teaching a graduate course with 15 people enrolled, it can be very interactive, but that's not what I'd consider a general lecture.
I think that brick is particularly expensive in the U.S., while in Europe you'll find that lumber may be more expensive I'd think. That was my experience, at least.
If a video of a lecture is as useful as the live lecture, it's a bad lecture.
I'd be careful with that statement. If you claim there must be some interaction, then let's get real: you don't want to be interrupted by questions every 15 seconds. So live questioning as a feedback from students to the lecturer is out. Then the most interaction you'll get is the lecturer looking at faces and body language of students.
But what does that tell the lecturer? Nothing that's very applicable when the medium is video!! In a video lecture, if you feel like falling asleep, you pause it, get up, walk around, come back refreshed, start watching again a few minutes back into the recording to get back on topic. If you need to look something up, you can pause, google for it, look in a book, look in previous lectures, then resume when you're ready. Those two situations cover most of the realtime feedback a lecturer would use, I'd presume. So, failing to show particular examples of how the reverse channel helps in a prerecorded lecture, I call your claim an gross exaggeration at best. Audience feedback is important in a live lecture setting, recorded lectures are really quite different because the student controls the playback. Good luck pausing the professor when you feel like dozing off for 45 minutes in the auditorium :)
It's not about how much die area the microcode takes, it's about how much die area everything else needed to run this microcode efficiently is taking! Properly designed opcodes would obviate trace generator, branch predictor, register reallocator, parts of northbridge, etc. Now that takes a lot of space. In case of x86 ISA it's not about legacy opcodes really, it's about all the missing opcodes (and registers) that a well performing architecture should have. That's what I mean by it being 30 years behind. Even fairly aged DSPs like 2100 architecture from Analog Devices have dedicated address generators and loop generators that are fully controlled by the code -- this alone means you don't need prediction logic, and this could be exploited by the northridge (were it in a general purpose CPU) to optimally schedule DRAM cycles.
It seems to be fairly useless for things other than very limited specialized tasks. 128 words of memory per core? What the heck? Even with 512 words per core on Parallax Propeller, people are fighting to get things going without having to access the shared and slow hub memory. Fitting everything in 512 words (2 kbytes) is hard, 128 words makes it more than 4 times harder. Their architecture basically implements a very simple dialect of FORTH in hardware. It's very hard to design systems of any considerable complexity using such simple CPUs without proper support from software development tools. It seems to me that this is the eventual undoing of all small-but-potentially-fast architectures: the development tools suck and do not help you in partitioning, simulating and validating your problem. XMOS seems to be going the right way about it -- they at least provide decent (high bandwidth) realtime debugging and they have a static timing verifier that's a must in real-time applications those chips are good for. I'd love to use F18 if only the damn thing had modern tools to support development on it, not something that feels like a trip back to the 70s. So far, it seems like a decent, perhaps more flexible, low-power replacement for small programmable logic, but it requires a lot of effort to get anything done on it. Their hardware, albeit fairly pretty, is useless without decent tools. Their disdain for common terms and introduction of their own terminology in their literature doesn't help. If they don't get their act together with a proper development environment, they will sink, they must understand that.
The ideas from inmos are alive and well at XMOS. I use their two core chip and I'm fairly happy -- it's plenty fast for what I use it for (industrial data collection). If only they documented the darn thing better.
Intel instruction set architecture requires a lot of hardware to execute efficiently. That's the price we all pay for using an instruction set that is 3 decades behind the hardware it runs on.
There's plenty of perhaps specialized but still fairly common digital signal processing that doesn't care at all about those "advances" in processor design. All it needs to do is plenty of multiplies-and-adds, saturated operations, test-and-modifies, etc. It doesn't require branch predictors, virtual memory, memory protection, layered caches, cache coherency, speculative execution, and plenty of other stuff that's needed to make x86 perform decently. The x86 instruction set is just very bad at extracting useful performance from CPU hardware without a lot of pre-processing. Even in the 80s you had DSP processors that had memory addressing units that would do circular buffers and strided access, as well as hardware loop generators. That way operands and data were always fetched from where they were supposed to come from, there was no speculation, loops had no overhead, and interleaving or parallelizing execution and fetches was easy to do, with no worry about data dependencies (whoever wrote the software would have already taken care of it), etc.
A lot of digital signal processing, that those chips would seem useful for, requires sequential access at very high bandwidths. When used that way, modern DRAM has no latency to speak of.
Perfect for networking -- switching, routing, ... Think of content addressable memory, etc.
Agreed. I'm working on a digital oscilloscope display system and that thing might be very useful in this application -- where you need lots of bandwith, but also plenty of storage. Say, zooming, filtering, scaling of one second long acquisition done at 2Gs/s, using a 12 bit digitizer. You tweak the knobs, it updates, all in real time. In the worst case, you need about 120 Gbytes/s memory bandwidth to make it real time on a 30FPS display. And that's assuming the filter coefficients don't take up any bandwidth, because if they do you've just upped the bandwidth to terabytes/s.
Yeah, they're deliberately fucking up on a car that they spent few billion on to get out to market in near record time.
You haven't seen much corporate stupidity from on-high if you think they wouldn't be capable of doing precisely that. I'm not saying they are doing it at all, just that no one should be putting it besides them.
Are you sure that NiMH drained to, say, 10% of normal cell voltage, is ruined? I've had plenty of NiMH cells that self-discharged to less than that and they still had full capacity after two subsequent charge-discharge cycles. So something is fishy in your post, unless you claim that NiMH is not suitable for use in an electric vehicle...
I don't see a big deal here: you want it on the network, you put a gateway that encrypts the connection, verifies the certificates of the accessing party, etc. Like any tiny linux-running internet-enabler gizmo would do, when properly configured, even using nothing more than ssh. There's nothing inherently bad about those PLCs, it's the dumb implementers who have no clue. If you integrate solutions that involve networking, get someone with a clue in that area. Most industry "specialists" who deal with PLC have little clue about internet, network safety, etc. They have a different skillset: they know the quirks of various PLCs, I/Os, they know various industrial networking protocols (those have nothing to do with internet, many don't even use ethernet), and so on.