That's correct, but the same system also has lots of other complex behaviours which could cause confusion.
How do you turn the car off but leave the radio on for the passenger - e.g. at a gas station? A: Come to a stop. Put the transmission in neutral. Press start/stop button. Engine turns off, and the power system is switched to "accessories" mode.
Q: How do you turn the power off completely? A: Put transmission in Park. Then press start/stop button
Q: What if I want to turn the power off and leave the car in neutral e.g. for maintenance? A: You have to switch into Park first. The press start/stop. Then use the transmission shift override to select Neutral.
Q: How do you turn the car off in an emergency - e.g. stuck accelerator pedal? A: You can't just press start/stop, as the vehicle speed sensor inhibits the button, so you can't turn off the ignition whilie the vehicle is moving. This isn't even in the manual. However, pressing and holding start/stop for 10 seconds will cause the ignition to turn off completely. This is a surprisingly long time in an emergency. In fact, in several "unintended acceleration" episodes, the drivers said they tried to turn off the push-button ignition, but couldn't turn it off.
Q: How do you give a prolonged crank, if the car fails to start (e.g. poor fuel, or cold weather)? A: You have to let the computer attempt 3 failed starts. After that, the behaviour of the start/stop sequence changes. After the 3rd attempt, a momentary push of the button, will make the computer crank the engine for up to 30 seconds, for as long as the brake pedal remains depressed.
The summary is quite clear. Blender produced the video, Sintel, and publish it to Youtube under the creative commons license. Sony reuses the video as part of their 4k marketing material. Sony provides youtube with a "reference" copy of their marketing material, and tells youtube to find copies of the material and to exercise Sony's rights over it. Youtube finds the original Sintel video and matches it to a "reference" copyrighted work (Sony's marketing material). Youtube arranges for forced commercial licensing of the Blender video with proceeds going to Sony.
Which is more or less exactly what happens with the DMCA.
The accuser sends a notice to the hosting company saying they believe they are publishing infringing material. Hosting company informs customer, and will remove content if no reply is received within 24 hours. Customer responds, that they own the copyright, and once done hosting company restores the content, if removed, or does not remove it if the time period has not elapsed.
Once that stage is reached, the accuser must pay all costs and the video stays up until the case is closed.
The issue is that most providers will remove the material fist, and ask questions later - even though, they are permitted to leave the material for 24 hours to allow the accused to respond. The other issue is that there is no penalty or cost for an accuser to make false claims under the DMCA. A malicious accuser can easily cause huge administrative headaches for hosting companies and content creators, and face no penalty or cost for it. Things get a lot more expensive and risky for the accuser at the 2nd phase once, and the number of copyright cases that progress after a DMCA counter-claim is very small indeed.
I was last month negotiating over the purchase of a results reporting and communication system. I spoke to one of the biggest suppliers and asked what platforms they supported: "We support Windows 7 with IE 8." "We're increasing moving to mobile devices, what support do you have for Windows 8, IE9, Mac OS, Android, iOS and other browsers such as Safari, Chrome and firefox". "We will be adding Windows 8 support in our next annual update, which will be available for the standard version upgrade fee. There are no plans to support any other browsers or OSs".
There are a variety of other products in this field, but they all have widely different features, integration capability (can it integrate with neighbouring hospitals systems, or primary care physician systems), etc.
If the only product which can provide your "core specification" is restricted like this, then you can't just go elsewhere.
Actually, they often do care about open-source, but in the wrong way.
I was recently purchasing some specialist medical software, and one of the key terms in the contract specified by senior management, was "the software should not contain any open-source components, except where no close-source alternative exists, and the vendor must ensure that appropriate restrictions over access to the source code are maintained at all times during the duration of the contract".
I managed to get that one negotiated to something less unrealistic (i.e. open source 3rd party libraries permitted), as the only realistic product choice made heavy use of technologies such as xuggler, libpng, openjpeg, etc.
The reason for this, "security". The management were adamant that "open source" was a catastrophic security risk, because "it exposed vulnerabilities in the software". They could/would not be educated on this matter.
This is exactly it. I know one hospital that recently "refreshed" their hardware to new Quad core 4th generation i5 desktops. The OS - Windows XP SP1. Why?
The specialist medical applications that they run are too expensive to upgrade, and the version they run doesn't support XP SP2. Medical software is not cheap - something like a "results reporting system" which aggregates test results from multiple departments (e.g. blood chemistry, hematology, MRI, ultrasound, physiology, cardiology, etc.) and presents them to a physician - can cost $1million for the license. For a PACS (X-ray viewing and archiving) software, the license could easily cost $10 million for a large hospital (or group of hospitals).
If it would cost you $2 million to replace a specialist app, then you may be stuck with having to use an older OS - especially, if the app developer has gone out of business and you no longer have any support (very, very common in the medical industry).
Some of the more forward thinking IT departments have started rolling out Windows 7, and using some sort of virtualization service, to run the specialist apps under the appropriate OS/IE version/Java runtime/.NET runtime that each one needs. The difficulty with this, is that you essentially have not just your Win7 environment to manage, but also all the individual virtualized run time environments. The administrative burden that this requires can be substantial.
Yes. It is practical, and if you have a bitcoin client (with knowledge of your public key) running, it will show your balance in real time.
This type of setup is often called a "watch wallet" and a number of bitcoin exchanges have these set up as a method of auditing their transactions against their deposit/withdrawal database (to detect intrusions, database bugs, and to detect insider thefts).
That is correct. There is no such thing as "a bitcoin" - instead, all you have are balances in a distributed public ledger.
Each balance has an associated public key pair. A payment instruction in bitcoin simply consists of a digitally signed message effectively saying "1Alice56789 pays 1.234 BTC to 1Bob12345 ". This message propagates around the network, and if Alice has sufficent funds to cover the transaction, and the signature is genuine, then the network will, in due course, add it to the ledger. If Alice doesn't have sufficient funds or the signature is invalid, then it will not be added to the ledger and the transaction will fail.
If you possess the private key associated with a particular "account", then you effectively control its spending power. All you need is the private key to the relevant "address" to control all the bitcoin held in it, or that may arrive in it, for all time.
It is not possible to transfer BTC without someone knowing. As soon as the transfer is confirmed, it appears in the public ledger. Similarly, because the ledger is public, if you know who holds the private key to a particular address, you know how many BTC they control.
In fact, on the day that Mt Gox claimed to have lost all their BTC, the general public knew that this was BS. Mt Gox had a couple of years ago, revealed the identity of some of their "cold" addresses. On the day of their bankruptcy, the bitcoin community had identified 200k BTC still held within these addresses, hence why the announcement was widely disbelieved. A competeing hypothesis to "transaction malleability theft" was that Mt Gox had simply lost their private keys to the BTC effectively resulting the in those BTC being forever lost. The fact that Mt Gox had started reorganising and moving these BTC to new addresses a couple of weeks ago, also had not gone unnoticed.
This is true. However, you cannot install grid-connected solar in the UK without permission from your local electricity distribution network operator (DNO).
There are now significant parts of the county where the DNOs routinely deny permission because the grid is saturated.
The issue is that of voltage tolerance. The grid is designed to supply power form central to peripheral. The central voltage is held higher than peripheral, so that the expected voltage drop through supply impedance will result in a voltage at the customer premises which is within tolerance.
If current flow is reversed through the high impedance "last mile", then you can get severe voltage elevation at the point of connection of the generation. This can result in equipment damage (usually the customers) and legal problems for the electricity network operator.
The only way to deal with this problem is to increase the "prospective fault current" of the customer circuit by reducing the system impedance. This isn't something simple like replacing transformers, it is extremely expensive and requires repalcement of cabling with heavier gauge wire, upgrade of safety equipment to withstand the higher fault currents, and may require uprating of transformers and switchgear to handle the magnetic and thermal forces of a fault on the now upgraded circuit.
There are other issues too. Grid transformers are often not designed to operate in reverse power - the tappings are designed for voltage drop in the direction of HV to LV. Under reverse power, there may be insufficient tap range to get satisfactory voltages. Only way around this is to replace the transformer.
Finally, there are second order effects, such as reduced efficiency of transformers when operated in reverse power, due to higher levels of flux leakage from the secondary (primary windings usually go nearest the core, so that stray flux cuts through the secondary and transfers power).
Actually, as cereals/grains make up a large part of the modern diet, the fact that they are poor sources of certain vitamins becomes relevant. For example, breakfast cereal commonly has folic acid added, not because it was lost during process (although some is), but because it is an important public health measure. Same for flour for bread making.
Additionally, some nutrients will be lost from processing - usually cooking, as most breakfast cereals are baked. Many vitamins are heat unstable and are therefore added back by the manufacturers.
Ethanol can be a big problem with certain modern cars.
Toyota and its luxury devision, Lexus, have this problem with models up to 2008. For example, the 2008 Lexus IS (built during calendar year 2007) is not E10 compatible. In areas where E10 fuel was legally mandated, lexus noticed a high rate of warranty replacements of the fuel injection pump and fuel injector failure, as well as fuel leaks from the fuel injection manifold. This was found to be ethanol induced corrosion of the metal alloys used in the injection pump and manifolds. Oxidation and debris from the corrosion would also clog injectors or cause them to leak.
These cars were recalled in the US, but were not recalled outside of the US. Customers with these cars who are now out of warranty are potentially SOL, if they live in an area where E10 is expected to be mandated shortly.
It's not just recent Japanese cars that have problems with E10. Recent european cars also have major problems with E10. Mercedes-Benz vehicles built between 2002 and 2005 are not E10 compatible, as are numerous post 2000 Fiat vehicles, Audi/Volkswagen/Seat/Skoda vehicles with direct injection systems built before 2006, etc. The list of non-compatible cars is very long.
I sense some exaggeration here. In the US CFLs never got that cheap in any size that I've ever seen, even at the mass discount stores. That must have been some massive government subsidy.
Not an exaggeration. Many stores would sell subsidised CFLs for about that price. Same with other energy saving products (I'd seen rolls of thermal insulation material - 10 yards, 6" thick on the shelves at hardware stores for about $2-3 each; but there were big warnings on the shelves which read something similar to the followion - warning! for personal domestic use only. Commercial use of this product is illegal. By purchasing this product, you certify that it will not be resold, used in the course of business or in the construction of a new building)
In fact, the energy suppliers had "energy reduction" targets to meet, and huge fines were levied if they didn't spend $x per year on assisting customers to use less energy. A common way for the energy companies to do this, was to buy massively cheap CFLs from China, claim the cost as a "green expense" and then just mail out unsolicited boxes full of CFLs to every customer. That really did happen, and the bulbs were the lowest possible grade available. The best bit, was that the energy companies could claim the cost of the CFLs as a "green expense", and the government would fund them. Where did the govt get the money from, it came from a surcharge on energy bills. It was even better for the energy company, if they could get a kick-back from the CFL vendor as part of a big order at list-price.
The cost of these "green projects" added to domestic energy bills comes to about $250 per household per year, accounting for about 15% of the total cost.
I've had the same LED light interference problem. At work, at the exit to the car park, they have flashing warning lights. They recently switched from incandescent to LED. Now when you drive past, you lose FM reception when the lights are in the on phase.
Maybe it's a bad batch of lights, but the flashing isn't synchronised between all the bulbs, and you can hear different interference sounds on the radio and work out which bulb they relate to.
I've also had CFLs do the same thing, but those were super cheap junk ones.
That said, incandescents can also produce RF interference that in certain instances can be troublesome. I've certainly seen an incandescent bulb with a failing filament produce enough RF to render an MRI scanner unusable (this is actually a common fault found on MRI scanners with an "excessive image noise" service call). The mechanism is that a tiny develops at a weak point in the filament, but strikes an arc between filament ends. It is the arc (disturbed by vibrations in the filament, convection currents, etc.) that modulates the current in the MHz range.
The main concern with MRI and pacemakers is not so much the magnetic field but the RF field. The magnetic field is not without problems as most pacemakers contain a reed switch which is used to activate "safe mode", where the pacemaker enters a special diagnostic mode. This is largely for historical purposes, as early pacemakers used this for battery level testing. The doctor would hold a magnet to the patient's chest. The pacemaker would enter diagnostic mode and would stimulate the heart to beat a rate dependent on battery voltage. The doc would feel the patient's pulse and could look up the estimated battery level in a table.
Modern pacemakers contain rather more sophisticated NFC capability, so much more useful readouts are available with a proper scan tool (battery voltage, stimulation mode, inputs from various sensors, lead impedances, stimulation voltages and currents, etc.) as well the ability to reconfigure various modes (e.g. vibration response - where the pacemaker increases rate in response to exercise induced vibration), whether the pacemaker can sense other heart parameters (so that different chambers of the heart contract synchronously), etc. In general, however, a magnet will switch the pacemaker into a basic mode of operation. (Defibrillators are different, as basic stimulation can be very dangerous in people with severe heart disease, as it can trigger ventricular fibrillation; therefore magnet mode in implantable defibrillators usually only just tweaks some parameters, rather than anything more dramatic).
The major issue with MRI is the RF field. MRI requires a very powerful RF pulse. A typical MRI power amplifier will take up 6U of rack space, and about 5 gallons per minute of cooling water and need a 3phase 480V power supply, while providing a peak RF power output of 35-70 kW.
A modern pacemaker will typically sense the ECG as well as stimulating. It will include a watchdog timer, and if a beat is not detected before the timer expires, it will trigger a stimulation pulse. One risk with the MRI environment is that the capability of the pacemaker to sense the 1 mV ECG signal may be degraded by the pulsed transmission from the 70 kW RF transmitter 6 inches away.
There are other issues with conventional pacemakers. Being implanted near the shoulder, the pacemaker connects to the heart muscle via leads approx 8-12 inches long. These typically form an arc in shape due to the anatomy. It just so happens that this wire loop forms quite a nice 1/4 wave loop antenna tuned to the scanner's RF frequency; it can absorb the RF energy and channel RF into the tissues around the pacemaker "box" and at the electrode tips. In minor cases, the RF pulses can act as pacemaker pulses on the cardiac muscle. Fine at 1 Hz scan rate. Not so good at 5 Hz scan rate. In extreme cases, the voltage build up across the pacemaker leads can cause RF burns to the cardiac muscle or damage the pacemaker circuitry. (There are MRI compatible pacemakers around which use various tricks - upgrading from normal coax cables to coax with heavy copper screens so rigid that they actually have to be articulated in order to bend + a liberal helping of ferrite beads; or dividing the leads up into 1" segments interconnected by small ferrite transformers)
The nanostim device doesn't have any exposed leads, so it is likely to be much less susceptible to RF problems. Due to size and location, it's also likely that it doesn't feature a conventional magnet mode, relying instead completely on NFC for control and communication. It also has the option of being completely removable. Conventional pacemakers often aren't, as the leads are generally not retrievable from where they screw into the heart muscle. Because it is RF pick-up in the leads that is the No 1 hazard with MRI, simply removing the pacemaker device, but leaving the leads isn't a safe option (it may actually make it worse, as the pacemaker itself often contains clamping and termination circuits to protect itself from EMI, and
Correct. On this type of hybrid vehicle, there is a regenerative braking system.
Under normal driving conditions, while the vehicle is in motion, the motor/generator will be used to retard the vehicle. The brake pedal is connected to a electronic pressure sensor, and also mechanically to a hydraulic master cylinder.
Unlike on conventional vehicles, there is no vacuum powered booster, instead the master cylinder hydraulics are used to operate an electro-hydraulic servo, with electronic override. This way, under emergency braking, you get full hydraulic force applied to the wheel cylinders with minimal pedal effort. The electronic hydraulic control will also apply hydraulic pressure when the vehicle is stationary and the brake pedal depressed, and also periodically applies hydraulic pressure when the vehicle is stopped and the transmission in P (for self-test purposes) and when the vehicle is powered on.
The hydraulic servo mechanism can be disabled in order to permit brake maintenance (this releases hydraulic pressure in the booster and prevents automatic application of pressure to the wheel cylinders), permitting access to maintain the friction surfaces. It appears that this hack, merely consisted of transmitting the CAN bus command to put the hydraulic servo system into maintenance mode.
At low speeds, when the electrical regen isn't operative, this will result in the brake pedal travelling further than expected and loss of power assistance. However, with sufficient pedal pressure, it should be possible to slow the car using unboosted pressure.
There is commercial software available and certified by the government for destruction of sensitive data and "confidential" classified data.
The use of free software is not an approved method of data destruction for bulk personal data in the UK, and its use could technically lead to legal problems. In practice, if it was used correctly, then no one would ever know.
The problem is that the legal onus is on the person in possession of the data to provide documentary proof that the data has been destroyed in an approved manner. If you can't provide proof of the use of an authorized method and validation of success, then you could be prosecuted. For this reason, normal practice is to hire an independent contractor who will provide a certificate stating the method used.
In a previous case where a certifed contractor was hired to destroy the data, but sold theequipment on ebay, the NHS hospital was fined, not the contractor. The reason given by the information commissioner's office, was that the NHS staff should have supervised the contractor and independently verified the destruction.
It was left for the NHS hospital to sue the contractor for breach of contract.
This type of scanning key cutting machine has been around for ages - the storing of the key bitting is new.
In general, this type of machine designed for public use, is only loaded with blanks for "unrestricted" keys.
"Do not duplicate" keys are not protected by just being labelled, they are physically a different shape (often with patented curves and bends), and genuine blanks can only be bought by registered locksmiths who have signed an agreement with the manufacturer not to duplicate keys without proof that the customer is authorised to duplicate that key.
Manufacturers do cut off supply to locksmiths that engage in unauthorized duplication (if they find out). Similarly, the manufacturers will use patent laws to block sale of 3rd party key blanks.
You can still get unauthorized copies made, but it's more difficult. The higher end manufacturers part-key the key blanks to a locksmith's unique code (using difficult to copy modifications - e.g. holes drilled to a specific depth along the length of the key, or curves engraved on the side of the key); a locksmith can only obtain blanks to duplicate keys that he himself sold, making it much easier to trace unauthorized duplication.
The problem with implantable devices is that they are severely power constrained, as typically a battery life of less than 5 years is considered unacceptable, with 10 years wanted for something like a cardiac pacemaker.
This leaves very little power for CPU/communications/encryption functions. Any kind of crypto hardware, or any kind of unnecessary complexity in the firmware (e.g. duplicated bound checking, etc.) is likely to increase energy consumption and shorten battery life.
This is becoming less of a problem with modern silicon which is more power efficient, and the use of NFC and induction coils can support the energy required for communication; so there is less excuse for including some form of well designed security on the device.
I have managed to reboot an implanted nerve stimulator once, by scanning the patient it was implanted in, in a top-end 3 Tesla MRI scanner. Interestingly, everything other than program code, was stored in RAM, rather than flash (including stuff like serial numbers, electronically readable model number!!, as well as treatment parameters). After the device rebooted all these settings were lost. The manufacturer had anticipated this, and the MRI instructions for the device, specifically said that these must be read-out of the device and a hard copy made, with instructions to how reprogram the device if it did reboot.
There are different constrants with non-implanted devices (e.g. laboratory equipment, scanners, servers, etc.) Traditionally, all the specifications for these devices were made at the time when they would be connected a clean, isolated network. As a result, security has been a very, very late arrival to these specifications. TLS support was ratified into the DICOM specification a few years ago (storage and transmission of X-ray/CT/MRI,etc) - but I've never come across a DICOM TLS installation in the field. So little installed software supports it, and the replacement cycle is so long (many hospitals are signing 10 year contracts for a particular version of the software) that it is, at present, completely useless. Even basic level network security is made difficult by certain aspects of the protocol - e.g. DICOM network connections cannot traverse NAT (due to a classic-FTP-like protocol for initiating file transfers, and due to the fact that both client and server nodes must be on pre-configured static IPs) and has enough tricks up its sleeve that it will catch out unwary net admins when they try and configure firewall permissions, or unwary sysadmins who try and set up clustered servers
This adds a number of significant additional risks: It adds a delay. It adds the risk that the human will mix records, or will fail to do the job without reporting back. It generates confidential waste that needs to be managed.
I work a specialist hospital, which gets patients from over a wide region, including neighbouring states. The normal way of transferring X-ray/MRI/CT records is by file transfer from one hospital's server to the other. However, for hospitals which are not common "feeders", which haven't gone to the expense of setting up the particular VPN connections required to connect into our site, a different approach was required.
So, when a patient is transferred to have their brain haemorrhage removed, the scanning hospital must first prepare a CD (using a proprietary encryption tool, to meet local regulations regarding confidentiality - a standard encryption format (including public key encryption to simplify key management) for medical image files has finally been introduced in the 2013 update to the specification, but is useless due to zero support in existing devices, and a typical device replacement period of 8-15 years), the CD has to be labelled, sent with the patient, taken to an admin office, the password has to be obtained by phone call, the proprietary encryption decrypted, the clear files burned to a new CD, and the clear CD loaded into the server (which has a specification conforming medical device is not permitted to load files except from a specification-conforming medium - i.e. an unencrypted CD or single layer DVD-R (with the files recorded in clear in a specific directory structure).
This adds substantial time, and frequently goes wrong. I've had blank (unrecorded CDs) sent with patients; CDs for the wrong patient; CDs labelled correcly, but with some other patient's images on; Some where the password has been lost, and a new disc has to be burned and couriered over; I've had episodes where the technologist on a 3 am, doesn't know how to burn a CD, or doesn't know how to the work the new proprietary encryption package that they're now seeing for the first time; we've had problems with permissions, where the technologist on-call cannot burn a clear CD, because their group policy has blocked CD burning under their user profile, etc. I'm aware of a number of cases, where patient's have gone for emergency brain surgery, where the only scan the surgeon has to guide the surgery, is a photo of a computer monitor taken with a cameraphone and sent by MMS (let's not even start on the privacy aspects of that).
Of course, with care, this procedure work, and we use it during network downtime (planned and unplanned). Similarly, we have backup plans when out CT scanner can't connect to the regional patient registry to verify identities, etc. However, in audits of data quality problems and data mix-up incidents, pretty much 100% can be traced to the use of a manual intervention.
Slashdot Mirror
That's correct, but the same system also has lots of other complex behaviours which could cause confusion.
How do you turn the car off but leave the radio on for the passenger - e.g. at a gas station?
A: Come to a stop. Put the transmission in neutral. Press start/stop button. Engine turns off, and the power system is switched to "accessories" mode.
Q: How do you turn the power off completely?
A: Put transmission in Park. Then press start/stop button
Q: What if I want to turn the power off and leave the car in neutral e.g. for maintenance?
A: You have to switch into Park first. The press start/stop. Then use the transmission shift override to select Neutral.
Q: How do you turn the car off in an emergency - e.g. stuck accelerator pedal?
A: You can't just press start/stop, as the vehicle speed sensor inhibits the button, so you can't turn off the ignition whilie the vehicle is moving. This isn't even in the manual. However, pressing and holding start/stop for 10 seconds will cause the ignition to turn off completely. This is a surprisingly long time in an emergency. In fact, in several "unintended acceleration" episodes, the drivers said they tried to turn off the push-button ignition, but couldn't turn it off.
Q: How do you give a prolonged crank, if the car fails to start (e.g. poor fuel, or cold weather)?
A: You have to let the computer attempt 3 failed starts. After that, the behaviour of the start/stop sequence changes. After the 3rd attempt, a momentary push of the button, will make the computer crank the engine for up to 30 seconds, for as long as the brake pedal remains depressed.
That's almost right. Nuclear fission reactions have a mass -> energey conversion of ~ 0.1%.
The summary is quite clear.
Blender produced the video, Sintel, and publish it to Youtube under the creative commons license.
Sony reuses the video as part of their 4k marketing material.
Sony provides youtube with a "reference" copy of their marketing material, and tells youtube to find copies of the material and to exercise Sony's rights over it.
Youtube finds the original Sintel video and matches it to a "reference" copyrighted work (Sony's marketing material).
Youtube arranges for forced commercial licensing of the Blender video with proceeds going to Sony.
Which is more or less exactly what happens with the DMCA.
The accuser sends a notice to the hosting company saying they believe they are publishing infringing material.
Hosting company informs customer, and will remove content if no reply is received within 24 hours.
Customer responds, that they own the copyright, and once done hosting company restores the content, if removed, or does not remove it if the time period has not elapsed.
Once that stage is reached, the accuser must pay all costs and the video stays up until the case is closed.
The issue is that most providers will remove the material fist, and ask questions later - even though, they are permitted to leave the material for 24 hours to allow the accused to respond.
The other issue is that there is no penalty or cost for an accuser to make false claims under the DMCA. A malicious accuser can easily cause huge administrative headaches for hosting companies and content creators, and face no penalty or cost for it. Things get a lot more expensive and risky for the accuser at the 2nd phase once, and the number of copyright cases that progress after a DMCA counter-claim is very small indeed.
There may not be a satisfactory alternative.
I was last month negotiating over the purchase of a results reporting and communication system. I spoke to one of the biggest suppliers and asked what platforms they supported: "We support Windows 7 with IE 8." "We're increasing moving to mobile devices, what support do you have for Windows 8, IE9, Mac OS, Android, iOS and other browsers such as Safari, Chrome and firefox". "We will be adding Windows 8 support in our next annual update, which will be available for the standard version upgrade fee. There are no plans to support any other browsers or OSs".
There are a variety of other products in this field, but they all have widely different features, integration capability (can it integrate with neighbouring hospitals systems, or primary care physician systems), etc.
If the only product which can provide your "core specification" is restricted like this, then you can't just go elsewhere.
Actually, they often do care about open-source, but in the wrong way.
I was recently purchasing some specialist medical software, and one of the key terms in the contract specified by senior management, was "the software should not contain any open-source components, except where no close-source alternative exists, and the vendor must ensure that appropriate restrictions over access to the source code are maintained at all times during the duration of the contract".
I managed to get that one negotiated to something less unrealistic (i.e. open source 3rd party libraries permitted), as the only realistic product choice made heavy use of technologies such as xuggler, libpng, openjpeg, etc.
The reason for this, "security". The management were adamant that "open source" was a catastrophic security risk, because "it exposed vulnerabilities in the software". They could/would not be educated on this matter.
This is exactly it. I know one hospital that recently "refreshed" their hardware to new Quad core 4th generation i5 desktops. The OS - Windows XP SP1. Why?
The specialist medical applications that they run are too expensive to upgrade, and the version they run doesn't support XP SP2. Medical software is not cheap - something like a "results reporting system" which aggregates test results from multiple departments (e.g. blood chemistry, hematology, MRI, ultrasound, physiology, cardiology, etc.) and presents them to a physician - can cost $1million for the license. For a PACS (X-ray viewing and archiving) software, the license could easily cost $10 million for a large hospital (or group of hospitals).
If it would cost you $2 million to replace a specialist app, then you may be stuck with having to use an older OS - especially, if the app developer has gone out of business and you no longer have any support (very, very common in the medical industry).
Some of the more forward thinking IT departments have started rolling out Windows 7, and using some sort of virtualization service, to run the specialist apps under the appropriate OS/IE version/Java runtime/.NET runtime that each one needs. The difficulty with this, is that you essentially have not just your Win7 environment to manage, but also all the individual virtualized run time environments. The administrative burden that this requires can be substantial.
Yes. It is practical, and if you have a bitcoin client (with knowledge of your public key) running, it will show your balance in real time.
This type of setup is often called a "watch wallet" and a number of bitcoin exchanges have these set up as a method of auditing their transactions against their deposit/withdrawal database (to detect intrusions, database bugs, and to detect insider thefts).
That is correct. There is no such thing as "a bitcoin" - instead, all you have are balances in a distributed public ledger.
Each balance has an associated public key pair. A payment instruction in bitcoin simply consists of a digitally signed message effectively saying "1Alice56789 pays 1.234 BTC to 1Bob12345 ". This message propagates around the network, and if Alice has sufficent funds to cover the transaction, and the signature is genuine, then the network will, in due course, add it to the ledger. If Alice doesn't have sufficient funds or the signature is invalid, then it will not be added to the ledger and the transaction will fail.
If you possess the private key associated with a particular "account", then you effectively control its spending power. All you need is the private key to the relevant "address" to control all the bitcoin held in it, or that may arrive in it, for all time.
It is not possible to transfer BTC without someone knowing. As soon as the transfer is confirmed, it appears in the public ledger. Similarly, because the ledger is public, if you know who holds the private key to a particular address, you know how many BTC they control.
In fact, on the day that Mt Gox claimed to have lost all their BTC, the general public knew that this was BS. Mt Gox had a couple of years ago, revealed the identity of some of their "cold" addresses. On the day of their bankruptcy, the bitcoin community had identified 200k BTC still held within these addresses, hence why the announcement was widely disbelieved. A competeing hypothesis to "transaction malleability theft" was that Mt Gox had simply lost their private keys to the BTC effectively resulting the in those BTC being forever lost. The fact that Mt Gox had started reorganising and moving these BTC to new addresses a couple of weeks ago, also had not gone unnoticed.
This is true. However, you cannot install grid-connected solar in the UK without permission from your local electricity distribution network operator (DNO).
There are now significant parts of the county where the DNOs routinely deny permission because the grid is saturated.
Because it is exceedingly expensive to do so.
The issue is that of voltage tolerance. The grid is designed to supply power form central to peripheral. The central voltage is held higher than peripheral, so that the expected voltage drop through supply impedance will result in a voltage at the customer premises which is within tolerance.
If current flow is reversed through the high impedance "last mile", then you can get severe voltage elevation at the point of connection of the generation. This can result in equipment damage (usually the customers) and legal problems for the electricity network operator.
The only way to deal with this problem is to increase the "prospective fault current" of the customer circuit by reducing the system impedance. This isn't something simple like replacing transformers, it is extremely expensive and requires repalcement of cabling with heavier gauge wire, upgrade of safety equipment to withstand the higher fault currents, and may require uprating of transformers and switchgear to handle the magnetic and thermal forces of a fault on the now upgraded circuit.
There are other issues too. Grid transformers are often not designed to operate in reverse power - the tappings are designed for voltage drop in the direction of HV to LV. Under reverse power, there may be insufficient tap range to get satisfactory voltages. Only way around this is to replace the transformer.
Finally, there are second order effects, such as reduced efficiency of transformers when operated in reverse power, due to higher levels of flux leakage from the secondary (primary windings usually go nearest the core, so that stray flux cuts through the secondary and transfers power).
Actually, as cereals/grains make up a large part of the modern diet, the fact that they are poor sources of certain vitamins becomes relevant. For example, breakfast cereal commonly has folic acid added, not because it was lost during process (although some is), but because it is an important public health measure. Same for flour for bread making.
Additionally, some nutrients will be lost from processing - usually cooking, as most breakfast cereals are baked. Many vitamins are heat unstable and are therefore added back by the manufacturers.
Ethanol can be a big problem with certain modern cars.
Toyota and its luxury devision, Lexus, have this problem with models up to 2008. For example, the 2008 Lexus IS (built during calendar year 2007) is not E10 compatible. In areas where E10 fuel was legally mandated, lexus noticed a high rate of warranty replacements of the fuel injection pump and fuel injector failure, as well as fuel leaks from the fuel injection manifold. This was found to be ethanol induced corrosion of the metal alloys used in the injection pump and manifolds. Oxidation and debris from the corrosion would also clog injectors or cause them to leak.
These cars were recalled in the US, but were not recalled outside of the US. Customers with these cars who are now out of warranty are potentially SOL, if they live in an area where E10 is expected to be mandated shortly.
It's not just recent Japanese cars that have problems with E10. Recent european cars also have major problems with E10. Mercedes-Benz vehicles built between 2002 and 2005 are not E10 compatible, as are numerous post 2000 Fiat vehicles, Audi/Volkswagen/Seat/Skoda vehicles with direct injection systems built before 2006, etc. The list of non-compatible cars is very long.
Not an exaggeration. Many stores would sell subsidised CFLs for about that price. Same with other energy saving products (I'd seen rolls of thermal insulation material - 10 yards, 6" thick on the shelves at hardware stores for about $2-3 each; but there were big warnings on the shelves which read something similar to the followion - warning! for personal domestic use only. Commercial use of this product is illegal. By purchasing this product, you certify that it will not be resold, used in the course of business or in the construction of a new building)
In fact, the energy suppliers had "energy reduction" targets to meet, and huge fines were levied if they didn't spend $x per year on assisting customers to use less energy. A common way for the energy companies to do this, was to buy massively cheap CFLs from China, claim the cost as a "green expense" and then just mail out unsolicited boxes full of CFLs to every customer. That really did happen, and the bulbs were the lowest possible grade available. The best bit, was that the energy companies could claim the cost of the CFLs as a "green expense", and the government would fund them. Where did the govt get the money from, it came from a surcharge on energy bills. It was even better for the energy company, if they could get a kick-back from the CFL vendor as part of a big order at list-price.
The cost of these "green projects" added to domestic energy bills comes to about $250 per household per year, accounting for about 15% of the total cost.
I've had the same LED light interference problem. At work, at the exit to the car park, they have flashing warning lights. They recently switched from incandescent to LED. Now when you drive past, you lose FM reception when the lights are in the on phase.
Maybe it's a bad batch of lights, but the flashing isn't synchronised between all the bulbs, and you can hear different interference sounds on the radio and work out which bulb they relate to.
I've also had CFLs do the same thing, but those were super cheap junk ones.
That said, incandescents can also produce RF interference that in certain instances can be troublesome. I've certainly seen an incandescent bulb with a failing filament produce enough RF to render an MRI scanner unusable (this is actually a common fault found on MRI scanners with an "excessive image noise" service call). The mechanism is that a tiny develops at a weak point in the filament, but strikes an arc between filament ends. It is the arc (disturbed by vibrations in the filament, convection currents, etc.) that modulates the current in the MHz range.
Probably a lot less susceptible.
The main concern with MRI and pacemakers is not so much the magnetic field but the RF field. The magnetic field is not without problems as most pacemakers contain a reed switch which is used to activate "safe mode", where the pacemaker enters a special diagnostic mode. This is largely for historical purposes, as early pacemakers used this for battery level testing. The doctor would hold a magnet to the patient's chest. The pacemaker would enter diagnostic mode and would stimulate the heart to beat a rate dependent on battery voltage. The doc would feel the patient's pulse and could look up the estimated battery level in a table.
Modern pacemakers contain rather more sophisticated NFC capability, so much more useful readouts are available with a proper scan tool (battery voltage, stimulation mode, inputs from various sensors, lead impedances, stimulation voltages and currents, etc.) as well the ability to reconfigure various modes (e.g. vibration response - where the pacemaker increases rate in response to exercise induced vibration), whether the pacemaker can sense other heart parameters (so that different chambers of the heart contract synchronously), etc. In general, however, a magnet will switch the pacemaker into a basic mode of operation. (Defibrillators are different, as basic stimulation can be very dangerous in people with severe heart disease, as it can trigger ventricular fibrillation; therefore magnet mode in implantable defibrillators usually only just tweaks some parameters, rather than anything more dramatic).
The major issue with MRI is the RF field. MRI requires a very powerful RF pulse. A typical MRI power amplifier will take up 6U of rack space, and about 5 gallons per minute of cooling water and need a 3phase 480V power supply, while providing a peak RF power output of 35-70 kW.
A modern pacemaker will typically sense the ECG as well as stimulating. It will include a watchdog timer, and if a beat is not detected before the timer expires, it will trigger a stimulation pulse. One risk with the MRI environment is that the capability of the pacemaker to sense the 1 mV ECG signal may be degraded by the pulsed transmission from the 70 kW RF transmitter 6 inches away.
There are other issues with conventional pacemakers. Being implanted near the shoulder, the pacemaker connects to the heart muscle via leads approx 8-12 inches long. These typically form an arc in shape due to the anatomy. It just so happens that this wire loop forms quite a nice 1/4 wave loop antenna tuned to the scanner's RF frequency; it can absorb the RF energy and channel RF into the tissues around the pacemaker "box" and at the electrode tips. In minor cases, the RF pulses can act as pacemaker pulses on the cardiac muscle. Fine at 1 Hz scan rate. Not so good at 5 Hz scan rate. In extreme cases, the voltage build up across the pacemaker leads can cause RF burns to the cardiac muscle or damage the pacemaker circuitry. (There are MRI compatible pacemakers around which use various tricks - upgrading from normal coax cables to coax with heavy copper screens so rigid that they actually have to be articulated in order to bend + a liberal helping of ferrite beads; or dividing the leads up into 1" segments interconnected by small ferrite transformers)
The nanostim device doesn't have any exposed leads, so it is likely to be much less susceptible to RF problems. Due to size and location, it's also likely that it doesn't feature a conventional magnet mode, relying instead completely on NFC for control and communication. It also has the option of being completely removable. Conventional pacemakers often aren't, as the leads are generally not retrievable from where they screw into the heart muscle. Because it is RF pick-up in the leads that is the No 1 hazard with MRI, simply removing the pacemaker device, but leaving the leads isn't a safe option (it may actually make it worse, as the pacemaker itself often contains clamping and termination circuits to protect itself from EMI, and
Correct. On this type of hybrid vehicle, there is a regenerative braking system.
Under normal driving conditions, while the vehicle is in motion, the motor/generator will be used to retard the vehicle. The brake pedal is connected to a electronic pressure sensor, and also mechanically to a hydraulic master cylinder.
Unlike on conventional vehicles, there is no vacuum powered booster, instead the master cylinder hydraulics are used to operate an electro-hydraulic servo, with electronic override. This way, under emergency braking, you get full hydraulic force applied to the wheel cylinders with minimal pedal effort. The electronic hydraulic control will also apply hydraulic pressure when the vehicle is stationary and the brake pedal depressed, and also periodically applies hydraulic pressure when the vehicle is stopped and the transmission in P (for self-test purposes) and when the vehicle is powered on.
The hydraulic servo mechanism can be disabled in order to permit brake maintenance (this releases hydraulic pressure in the booster and prevents automatic application of pressure to the wheel cylinders), permitting access to maintain the friction surfaces. It appears that this hack, merely consisted of transmitting the CAN bus command to put the hydraulic servo system into maintenance mode.
At low speeds, when the electrical regen isn't operative, this will result in the brake pedal travelling further than expected and loss of power assistance. However, with sufficient pedal pressure, it should be possible to slow the car using unboosted pressure.
This also only works "in theory". The list of drives with hopelessly broken "SATA secure erase" implementations is a long one.
There is commercial software available and certified by the government for destruction of sensitive data and "confidential" classified data.
The use of free software is not an approved method of data destruction for bulk personal data in the UK, and its use could technically lead to legal problems. In practice, if it was used correctly, then no one would ever know.
The problem is that the legal onus is on the person in possession of the data to provide documentary proof that the data has been destroyed in an approved manner. If you can't provide proof of the use of an authorized method and validation of success, then you could be prosecuted. For this reason, normal practice is to hire an independent contractor who will provide a certificate stating the method used.
In a previous case where a certifed contractor was hired to destroy the data, but sold theequipment on ebay, the NHS hospital was fined, not the contractor. The reason given by the information commissioner's office, was that the NHS staff should have supervised the contractor and independently verified the destruction.
It was left for the NHS hospital to sue the contractor for breach of contract.
but leap microseconds?
Actually, I think that might be a good idea. There's likely to be money in rewriting time stacks to cope with 1000001 microsecond seconds.
This type of scanning key cutting machine has been around for ages - the storing of the key bitting is new.
In general, this type of machine designed for public use, is only loaded with blanks for "unrestricted" keys.
"Do not duplicate" keys are not protected by just being labelled, they are physically a different shape (often with patented curves and bends), and genuine blanks can only be bought by registered locksmiths who have signed an agreement with the manufacturer not to duplicate keys without proof that the customer is authorised to duplicate that key.
Manufacturers do cut off supply to locksmiths that engage in unauthorized duplication (if they find out). Similarly, the manufacturers will use patent laws to block sale of 3rd party key blanks.
You can still get unauthorized copies made, but it's more difficult. The higher end manufacturers part-key the key blanks to a locksmith's unique code (using difficult to copy modifications - e.g. holes drilled to a specific depth along the length of the key, or curves engraved on the side of the key); a locksmith can only obtain blanks to duplicate keys that he himself sold, making it much easier to trace unauthorized duplication.
Could this be the first case of public key encryption getting broken?
The problem with implantable devices is that they are severely power constrained, as typically a battery life of less than 5 years is considered unacceptable, with 10 years wanted for something like a cardiac pacemaker.
This leaves very little power for CPU/communications/encryption functions. Any kind of crypto hardware, or any kind of unnecessary complexity in the firmware (e.g. duplicated bound checking, etc.) is likely to increase energy consumption and shorten battery life.
This is becoming less of a problem with modern silicon which is more power efficient, and the use of NFC and induction coils can support the energy required for communication; so there is less excuse for including some form of well designed security on the device.
I have managed to reboot an implanted nerve stimulator once, by scanning the patient it was implanted in, in a top-end 3 Tesla MRI scanner. Interestingly, everything other than program code, was stored in RAM, rather than flash (including stuff like serial numbers, electronically readable model number!!, as well as treatment parameters). After the device rebooted all these settings were lost. The manufacturer had anticipated this, and the MRI instructions for the device, specifically said that these must be read-out of the device and a hard copy made, with instructions to how reprogram the device if it did reboot.
There are different constrants with non-implanted devices (e.g. laboratory equipment, scanners, servers, etc.) Traditionally, all the specifications for these devices were made at the time when they would be connected a clean, isolated network. As a result, security has been a very, very late arrival to these specifications. TLS support was ratified into the DICOM specification a few years ago (storage and transmission of X-ray/CT/MRI,etc) - but I've never come across a DICOM TLS installation in the field. So little installed software supports it, and the replacement cycle is so long (many hospitals are signing 10 year contracts for a particular version of the software) that it is, at present, completely useless. Even basic level network security is made difficult by certain aspects of the protocol - e.g. DICOM network connections cannot traverse NAT (due to a classic-FTP-like protocol for initiating file transfers, and due to the fact that both client and server nodes must be on pre-configured static IPs) and has enough tricks up its sleeve that it will catch out unwary net admins when they try and configure firewall permissions, or unwary sysadmins who try and set up clustered servers
This adds a number of significant additional risks:
It adds a delay.
It adds the risk that the human will mix records, or will fail to do the job without reporting back.
It generates confidential waste that needs to be managed.
I work a specialist hospital, which gets patients from over a wide region, including neighbouring states. The normal way of transferring X-ray/MRI/CT records is by file transfer from one hospital's server to the other. However, for hospitals which are not common "feeders", which haven't gone to the expense of setting up the particular VPN connections required to connect into our site, a different approach was required.
So, when a patient is transferred to have their brain haemorrhage removed, the scanning hospital must first prepare a CD (using a proprietary encryption tool, to meet local regulations regarding confidentiality - a standard encryption format (including public key encryption to simplify key management) for medical image files has finally been introduced in the 2013 update to the specification, but is useless due to zero support in existing devices, and a typical device replacement period of 8-15 years), the CD has to be labelled, sent with the patient, taken to an admin office, the password has to be obtained by phone call, the proprietary encryption decrypted, the clear files burned to a new CD, and the clear CD loaded into the server (which has a specification conforming medical device is not permitted to load files except from a specification-conforming medium - i.e. an unencrypted CD or single layer DVD-R (with the files recorded in clear in a specific directory structure).
This adds substantial time, and frequently goes wrong. I've had blank (unrecorded CDs) sent with patients; CDs for the wrong patient; CDs labelled correcly, but with some other patient's images on; Some where the password has been lost, and a new disc has to be burned and couriered over; I've had episodes where the technologist on a 3 am, doesn't know how to burn a CD, or doesn't know how to the work the new proprietary encryption package that they're now seeing for the first time; we've had problems with permissions, where the technologist on-call cannot burn a clear CD, because their group policy has blocked CD burning under their user profile, etc. I'm aware of a number of cases, where patient's have gone for emergency brain surgery, where the only scan the surgeon has to guide the surgery, is a photo of a computer monitor taken with a cameraphone and sent by MMS (let's not even start on the privacy aspects of that).
Of course, with care, this procedure work, and we use it during network downtime (planned and unplanned). Similarly, we have backup plans when out CT scanner can't connect to the regional patient registry to verify identities, etc. However, in audits of data quality problems and data mix-up incidents, pretty much 100% can be traced to the use of a manual intervention.