"Data indicates that I... err... AI could get smarter by copying portions of a human brain. Please take a set and hold still while the probes are inserted into your cranial cavity."
In which case, the power consumption excuse for not running encryption (it needs too much processing horsepower) doesn't cut the mustard.
Using encryption uses more power than not using encryption. And the more power the device uses, the more often you need to cut holes in the patient to replace it. Most patients don't like that part. And encryption doesn't just use power through CPU usage, it also requires more RAM and possibly flash than no encryption, and both memories also draw power.
Also, consider the fact that you may have a large base of older "physician programmers" and "home monitoring devices" out there that don't support encryption. Doctors and patients would have to buy newer versions of these things to support your new encryption-ready pacemakers, for quite a chunk of money. Neither group likes that.
No, it's more like the same engineer(s) that designed and built the hardware find writing software "really fun" and decided they should have no problem writing the software too.
They don't find software/firmware fun. But companies want universal geniuses that do medical device HW design (not an easy task) and, well, write the FW as well, because they don't want to pay additional people to do it.
Companies used to building medical hardware have discovered microcontrollers and hired the cheapest programmer or two they could find to program it.
This isn't how it works.
Firstly, they discovered microcontrollers about thirty years ago, so that's not really new.
Secondly, they just make the same mistake many other companies do - they want one person that does hardware and firmware development (check some job postings), because that saves money (haha). Which is bad. Someone who's excellent at analog and digital HW design will have no time to fiddle with firmware. Good HW people are too valuable to let them waste their time trying to put together firmware, digital signal processing, etc.
I mean, in a hospital, you wouldn't want the same person doing anesthesia and surgery during an operation, would you?
Are debugging interfaces (e.g., JTAG and UART) present on home monitoring devices or physician programmers? Are the interfaces or functionality disabled prior to distribution?
So how is the manufacturer supposed to diagnose devices that malfunctioned out in the field? If you lock the debugging interfaces, they can usually only be reactivated by completely clearing the devices flash memory - or even not at all.
Are third-party libraries used in software development?
What kind of question is that?
Ok, I've seen code without any third party libraries. It was all assembly, only available in hardcopy, written for an 8051 and about 30 years old.
Is the firmware image for the implantable cardiac device mapped into protected memory to prevent arbitrary writing to memory addresses?
I would guess the implantable device doesn't use a microcontroller beefy enough to have an MPU. That would reduce battery lifetime.
Honestly, if you have 8000 bugs in your system then you haven't just done a bad job of securing your code,
May I suggest you read the paper first before heading off on a rant?
Basically all of the 8000 vulnerabilities (not bugs) are due to third-party libraries used in one of the components examined, which include "home monitoring devices" and "physician programmers", both systems that probably run Linux/Windows and hence inherit a lot of vulnerabilities from there.
What makes you assume that you *need* electricity in the first place?
Because it's a fairly universal way to power a wide range of processes, from chemical to motor to computing. Sometimes, it provides a more efficient or lower temperatur way to power these processes compared to other forms of energy.
And a colony - as opposed to a research outpost - will have many energy-intensive operations like resource extraction, refining, construction, manufacturing, recycling, etc.
RTGs are what we have already been using in space, for years, and plutonium-based
Yes. And plutonium is basically immobile in the environment. If a chunk of it drops from the sky, most of it will stay in that chunk.
Carbon, on the other hand, will basically disperse completely.
Also, this type of battery is suitable for low-power applications only. Maybe nice for powering a probe, but not for running a colony with resource extraction/manufacturing operations that may require megawatts of electrical power.
Technically he's right, because nuclear processes are not 'sustainable', in that they use up fuel.
Considering that reserves would last for thousands of years, sustainability is not the issue in this case. It's setting up the complex fuel cycle. The colony needs to find minable deposits of thorium/uranium, mine them, process them into reactor fuel, and then keep reprocessing the fuel. It's a whole separate production chain just for power.
Deuterium could be extracted while mining water. It's an add-on to something that's already vital to the colony.
We have recently found that 14C makes a good, long-running "nuclear battery" for applications like this. When China gets its liquid fuel reactor design going, the moderator will be solid rods of 12C. Over time, these will be irradiated into 14C and will be replaced. That's your source of space power.
Riiiight. Launch a payload of intensely radioactive stuff with high environmental/biological mobility into space. What could possibly go wrong?
Also, RTGs can power a probe, a vehicle, or maybe a research outpost. A colony, requiring power for things like resource extraction, manufacturing, etc., needs something with more output.
It could take them a few years, hell it could take them decades to scrounge up enough to build a greenhouse they can plant seeds in... but what if it takes 50 years to get to the point where humans can go. So what ?
Problem is that the robots will also suffer from wear and breakdowns. So there is a minimum power generation, resource extraction and manufacturing rate that the robot colony starter needs to achieve - enough to make up for maintenance, repair, replacements. If this does not happen, the colony seed will break down.
It boils down to an exponential function. colony_viability=(stuff_generation_rate/stuff_breakdown_rate)^time. If the colony generates more stuff than breaks down, it will thrive and expand; if it doesn't, it will shrink and eventuall vanish.
Non-sequitur. Creating a colony on Mars also wouldn't protect versus gamma-ray burst.
Yes it would, since most parts of the colony need to be shielded from radiation (e.g. underground). And the Martian atmosphere is not necessary for the colony's survival, so a GRB messing up the atmospheric composition would not affect life in the colony much.
FFT even an audio signal of the beat, or light-level through the finger or whatever.
Produce some simple stat on the regularity and speed of the heartbeat from that data.
You'll probably want to analyze a pulse signal in the time domain (e.g. autocorrelation, slope/maximum search or similar), as the beat to beat pulse rate of even a healthy person is too irregular to be easily analyzed in the frequency domain. Also, it's harder to extract beat-to-beat variations in the frequency domain, as they happen on short time scales which reduces the frequency resolution of the (F)FT.
If it got WORSE than 97% accuracy, I'd be surprised.
Yes, if you can ignore either specificity or sensitivity, you can jack up the respective other parameter as far as you like, even with simple threshold analysis.
> Instead they are installing solar panels in the world's second cloudiest location (the Bering Sea is first).
Forget the clouds and just look at the geographic latitude. Germany is closer to the arctic circle than to the nearest tropic.
I bet that a much simpler algorithm could produce similar results. But nowadays it seems to be the latest fad to throw machine learning at fairly plain signal/data processing problems.
Slashdot Mirror
That's not how visas work. You can still get sent back despite having a perfectly valid visa.
"Data indicates that I ... err ... AI could get smarter by copying portions of a human brain. Please take a set and hold still while the probes are inserted into your cranial cavity."
If this is about Texas, can't you just, you know, shoot them when they try anything funny?
... it wants its idea back.
Using encryption uses more power than not using encryption. And the more power the device uses, the more often you need to cut holes in the patient to replace it. Most patients don't like that part. And encryption doesn't just use power through CPU usage, it also requires more RAM and possibly flash than no encryption, and both memories also draw power.
Also, consider the fact that you may have a large base of older "physician programmers" and "home monitoring devices" out there that don't support encryption. Doctors and patients would have to buy newer versions of these things to support your new encryption-ready pacemakers, for quite a chunk of money. Neither group likes that.
They don't find software/firmware fun. But companies want universal geniuses that do medical device HW design (not an easy task) and, well, write the FW as well, because they don't want to pay additional people to do it.
This isn't how it works.
Firstly, they discovered microcontrollers about thirty years ago, so that's not really new.
Secondly, they just make the same mistake many other companies do - they want one person that does hardware and firmware development (check some job postings), because that saves money (haha). Which is bad. Someone who's excellent at analog and digital HW design will have no time to fiddle with firmware. Good HW people are too valuable to let them waste their time trying to put together firmware, digital signal processing, etc.
I mean, in a hospital, you wouldn't want the same person doing anesthesia and surgery during an operation, would you?
So how is the manufacturer supposed to diagnose devices that malfunctioned out in the field? If you lock the debugging interfaces, they can usually only be reactivated by completely clearing the devices flash memory - or even not at all.
Are third-party libraries used in software development?
What kind of question is that?
Ok, I've seen code without any third party libraries. It was all assembly, only available in hardcopy, written for an 8051 and about 30 years old.
Is the firmware image for the implantable cardiac device mapped into protected memory to prevent arbitrary writing to memory addresses?
I would guess the implantable device doesn't use a microcontroller beefy enough to have an MPU. That would reduce battery lifetime.
That's an issue with your creativity
How do you even connect to it?
The same way the doctor connects to it for things like status queries, configuration changes, etc.
And you're right, not wifi.
May I suggest you read the paper first before heading off on a rant?
Basically all of the 8000 vulnerabilities (not bugs) are due to third-party libraries used in one of the components examined, which include "home monitoring devices" and "physician programmers", both systems that probably run Linux/Windows and hence inherit a lot of vulnerabilities from there.
Oh, and a botched diagnosis should also go in the pool of training cases for future AIs.
The project sounds like throwing "researchers" at it is a bit of an overkill. But just a little.
Young people can't afford them. New cars are expensive.
Because it's a fairly universal way to power a wide range of processes, from chemical to motor to computing. Sometimes, it provides a more efficient or lower temperatur way to power these processes compared to other forms of energy.
And a colony - as opposed to a research outpost - will have many energy-intensive operations like resource extraction, refining, construction, manufacturing, recycling, etc.
Yes. And plutonium is basically immobile in the environment. If a chunk of it drops from the sky, most of it will stay in that chunk.
Carbon, on the other hand, will basically disperse completely.
Also, this type of battery is suitable for low-power applications only. Maybe nice for powering a probe, but not for running a colony with resource extraction/manufacturing operations that may require megawatts of electrical power.
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
Considering that reserves would last for thousands of years, sustainability is not the issue in this case. It's setting up the complex fuel cycle. The colony needs to find minable deposits of thorium/uranium, mine them, process them into reactor fuel, and then keep reprocessing the fuel. It's a whole separate production chain just for power.
Deuterium could be extracted while mining water. It's an add-on to something that's already vital to the colony.
We have recently found that 14C makes a good, long-running "nuclear battery" for applications like this. When China gets its liquid fuel reactor design going, the moderator will be solid rods of 12C. Over time, these will be irradiated into 14C and will be replaced. That's your source of space power.
Riiiight. Launch a payload of intensely radioactive stuff with high environmental/biological mobility into space. What could possibly go wrong?
Also, RTGs can power a probe, a vehicle, or maybe a research outpost. A colony, requiring power for things like resource extraction, manufacturing, etc., needs something with more output.
Problem is that the robots will also suffer from wear and breakdowns. So there is a minimum power generation, resource extraction and manufacturing rate that the robot colony starter needs to achieve - enough to make up for maintenance, repair, replacements. If this does not happen, the colony seed will break down.
It boils down to an exponential function. colony_viability=(stuff_generation_rate/stuff_breakdown_rate)^time. If the colony generates more stuff than breaks down, it will thrive and expand; if it doesn't, it will shrink and eventuall vanish.
Yes it would, since most parts of the colony need to be shielded from radiation (e.g. underground). And the Martian atmosphere is not necessary for the colony's survival, so a GRB messing up the atmospheric composition would not affect life in the colony much.
Err ... seriously?
You have to spend time and money to go to the doctor.
Your doctor has to spend time to examine an actually healthy patient, reassure him or her that nothing it wrong.
Alarm fatigue. After the third false alarm, you'll stop listening to them.
Just to name a few points.
Produce some simple stat on the regularity and speed of the heartbeat from that data.
You'll probably want to analyze a pulse signal in the time domain (e.g. autocorrelation, slope/maximum search or similar), as the beat to beat pulse rate of even a healthy person is too irregular to be easily analyzed in the frequency domain. Also, it's harder to extract beat-to-beat variations in the frequency domain, as they happen on short time scales which reduces the frequency resolution of the (F)FT.
If it got WORSE than 97% accuracy, I'd be surprised.
Yes, if you can ignore either specificity or sensitivity, you can jack up the respective other parameter as far as you like, even with simple threshold analysis.
> Instead they are installing solar panels in the world's second cloudiest location (the Bering Sea is first). Forget the clouds and just look at the geographic latitude. Germany is closer to the arctic circle than to the nearest tropic.
Yes, Mars kind of sucks in this regard. Gravity is too high for powered descent; atmosphere is too thin for effective parachuting.
I wonder if atmospheric entry with an ultrasonic flight/wing-borne lift phase would be an option.
No, it wouldn't. A few hundred km of rock are pretty good radiation shielding.
However, a GRB would mess up the atmosphere so thoroughly that it wouldn't be fun even for those on the far side of the planet.
I bet that a much simpler algorithm could produce similar results. But nowadays it seems to be the latest fad to throw machine learning at fairly plain signal/data processing problems.
As far as I understand the cardiogram app, it doesn't to an ECG. It measures the pulse.
Measuring an ECG would involve at least sticking an electrode on two out of RA, LL and LA.