You saw the car commercial because the uploader of the cute cat video requested that adverts be displayed before their video.
Youtube does sell advertising - and normally does it via not-too-indiscreet overlays. They do have an option for pre-video commercials. However, this is NOT the default, the video uploader must explicitly request this type of ad. The exception is where the video uploader has used 3rd party copyright content (either by using it from the youtube material library, where mandatory ads are the price video producers pay for using it; or the youtube CMS has detected content that matches reference material supplied by a copyright holder, and where that copyright holder has requested advertising income for that material's reuse).
Hospitals are often quite badly prepared for this sort of thing. A big problem is the number of computerised "medical devices" where the vendor insists on a very specific update policy (or very specific restrictions on 3rd party software).
I worked at one hospital where Confiker took the whole IT system down. A big problem in repairing the damage was that there were a lot of PACS (digital X-ray/CT/MRI viewing/storage) workstations where the PACS vendor would not permit the relevant windows updates or a 3rd party anti-virus to be installed on the servers/workstations. They relented after a 24 hour stand-off, after they realised that they was nothing they could do to keep the system happy enough to meet the SLA without the updates and a suitable anti-malware.
I work at another hospital now, where similar lack of updates due to comparability with old business apps prevents updates. E.g. The PCs still run XP SP1 (even the brand-new quad core xeons). There also doesn't appear to be funding for updating anti-malware - the hospital use Sophos 7 (which became unsupported last year).
This hospital has chronic problems with virus/malware infestation on a number of office machines - but while IT can clean the computers manually, there seems to be a reservoir if infection on file-servers, USB drives, etc. So the infections come straight back after a manual deletion. This hasn't caused a catastrophe locally, so management don't seem to care, but it is a major annoyance, as infected documents frequently end-up getting e-mailed out to other hospitals/doctors and destroyed without trace by the recipient's e-mail system. Docs have been known to put the files on a USB stick, take it home, clean it with an up-to-date virus scanner and then e-mail it out.
I don't understand the "brute force" claim. In the article, they later explain:
"Note how the 'root' user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. "
This makes no sense to me. 2 attempts at a login, and then the 3rd succeeds? How is that brute force? Or is it just extraordinary luck (or an inept password policy).
While I don't regularly perform penetration testing, my current understanding of brute-forcing SSH passwords, is that it requires thousand or millions of attempts, with the hope that an IDS doesn't spot the attempted ingress and lock-down firewalls, etc.
To me, this looks more like a 0-day. A few probes with potentially exploitative malformed logins, until they find one that works on the specific kernel/SSH version.
I'm guessing that you don't make stuff with an MTBF of 10 years. An MTBF of 10 years means that each year 10% of the items are breaking down and requiring repair/replacement due to some form of break down. In most industries, with products that unreliable you'd be out of business pretty quick.
MTBF is a completely different measure to expected lifetime. The expected lifetime is just that - how long the device is expected to work for, before its performance becomes unacceptable (i.e. when the device becomes worn out).
MTBF measures how reliable a device is *during* its expected lifetime (i.e. before the device becomes completely worn out).
But MTBF isn't a useful measure for a single drive. It's a measure for a population of drives.
If I have 10,000 hard drives in my datacenter, then an MTBF of 1,500,000 hours means that I need to plan for replacing approximately 60 drives each year (with some allowance for bad years and good years), whereas an MTBF of 2,000,000 hours means I only need to plan for an expected 45 replacements.
The technical issues behind this fracas are even more banal, and so trivial that it's already been reverse engineered. In effect, the "DRM" was purely a closed specification, and not a technological measure such as encryption.
Unsurprisingly, the specification has already been deployed in popular open-source projects.
For those interested, the technical extent of the "DRM" and "encryption" was the use of a pre-calculated Huffman table, which must be embedded in the receiver firmware, in order to obtain the programme guide.
It's not the processing of the images that is slow - it is the collection of the raw data. In an MRI scan, the machine performs performs a series of experiments with the following basic format; transmit a high-power RF pulse, distort the magnetic field in a complex manner, and then capture the "echo" of the RF pulse. Each "echo" contributes some information about the image. In the most basic form, each "echo" can contribute an information equivalent to one row of pixels.
So if you wish to acquire a 256x256 image, the scanner needs 256 echoes to have enough data to reconstruct an image, and therefore needs to run the experiment 256 times with different parameters to acquire all the data needed for "developing". The problem, is that each experiment takes a finite time to run (which can be several seconds for many types of diagnostic image). If each experiment requires 3 seconds (typical for a standard brain scan), this means 768 seconds to capture enough data for 1 image.
In practice, there are lots of tricks that can be done: 1. interleaving scans - so the machine runs an scan looking at the top of the head, then 100 ms later runs a scan looking 1 cm lower, then 100 ms later, runs a scan 1 cm lower still, etc.). As the echoes come back at different times, and the experiments do not overlap in space, the images can, in effect, be captured in parallel. 2. Multiple "echoes " can be generated in a single experiment. Adding more echoes , increases speed, but degrades image quality, and may be limited by the performance of the magnetic field (gradient) distortion capability of the scanner hardware, by electrical induction (from the rapidly distored magnetic field) in the patient's body (causing electric shock sensations), or by the need for increased RF energy (and therefore total RF energy deposition in the patient's body). 3. Adding multiple receive-antennas and radio receiver hardware; by using 2 receive antennas at different positions, it becomes possible to extract more information from an "echo" by taking 2 recordings from different positions. Current top-of-the-range MRI scanners take this to the extreme with 128 sets of radio receiver/ADC hardware, with the ability to connect antenna modules with up to 96 antennas per body part.
In a medical setting, multiple entire sets of images will be captured using radically different scan parameters, in order to detect different types of abnormality. So, a typical brain MRI will usually have 5 sets of images of the brain, but with different appearances, where the scan parameters are set to bring out different features of interest - e.g. one scan will be very sensitive for water (giving good overall anatomical detail of the brain, and good sensitivity for many abnormalities), one will be more sensitive for fat (and so maximize anatomical detail of the brain, which contains lots of lipid), one will be sensitive for iron deposits (and so be very good at detecting blood/bleeding, but will show virtually no anatomical detail), one will have improved sensitivity for water within the brain tissue (but reduced sensitivity for the water around the brain, allowing surface abnormalities to be detected) and one will have sensitivity for the pattern of Brownian motion of water molecules (and so detect disturbed physiological processes, but shows no anatomical detail).
What is novel about the algorithm described here, is that it allows information from one set of images to be used during the "development" of a different set (e.g. by finding the edge of the head, and then using the fact that the space outside the head is known to be empty space, during the development process of the next set of images). By applying this additional constraint, it becomes possible to reconstruct any subsequent images with less than a "full quota" of data, allowing the scanner to skip part of the time consuming data acquisition.
The difficulty with this technique, is that the different scan parameters utilise different physical processes to build up the images - hence basin
Nice post. Just one correction, at the beam energies used in these devices (50 kVp - 120 kVp), most X-ray photons certainly do not go straight through you. At about 120 kVp, about 75% will get absorbed through the torso - and in the case of 50 kVp, essentially 100% will be absorbed (with only a fraction of a percent getting scattered, as 50 kVp is below the optimal range for Compton scattering in body tissues).
In fact, it was widely stated in the marketing information and propaganda for these scanners that the X-ray beam does not penetrate skin. This statement is patently false at all energies in commercial use. If they can get away with deliberate lies as basic as that, how can you reasonably believe any more difficult claims?
Kevlar doesn't offer much protection against rodent knawing. It's mainly for longitudinal strength - allowing the cable to be winched through ducts (like electric cable) without putting stress on the delicate glass fibers.
Rodent resistant cables are armored with a hard material which is hard enough to resist gnawing, preventing the rodent from penetrating the underlying cable - e.g. epoxy embedded glass fibers (for cables judged "low-risk" of rodent attack), or steel (for high-risk cables).
The UK requires (under the Digital Economy Act) that any internet service provider (which the law defines in an exceedingly broad way) keeps logs of all customer connections and retain them for a minimum period of 6 months. They are not required to log the contents of the connection, merely the IP.
This includes an individual or small business offering wi-fi to customers on their premises. Under the DEA, they are an ISP and must keep the relevant logs (which include positive identity of the customer) for the required period. Failure to keep the logs is an offence, and may mean that the operator of the network is personally liable for any offences that were alleged to have been committed.
Shouldn't the victim's family just be able to sue the guy?
Harassment and making malicious communications are crimes.
In the UK, there would be little to be gained from suing. With a few exceptions (notably libel), there is no principle of "damages" in UK law. Broadly speaking, if you sue someone, you can only claim for demonstrable financial loss directly arising from the act or omission. You cannot sue for "compensation" or "damages".
In this case, the postings were distressing and offensive, but no financial loss was suffered, and therefore there is no claim to be sued for.
Even if they can prove a particular machine was used to commit the offence, how will they prove who used it? That isn't even taking into account things such as TOR. I'd go as far as to say he is downright lying.
Why would they do that?
The UK has a law called the "Digital Economy Act" which requires all ISPs to log all communications (at the IP address/connection level, rather than the contents) together with the identity details of the person on whose behalf they were made.
This means that if you provide internet services to other people (e.g. you are a coffee shop and provide wifi for customers) you are acting as an ISP and must ensure that you verify the identity of all users for the purposes of complying with the DEA. If you fail to do this, then you commit an offence under the DEA, and may additionally be automatically liable for any communications offences committed via your connection (This is in the same way that the CEO of a company is personally responsible for any driving offences committed with a company vehicle, unless they provide details of the identity of the driver at the time. Failure to keep adequate records is not a defence.)
There is no loophole for running a completely open network. It is a requirement that you take all reasonable steps to protect yourself. Running a totally open public network could be regarded as negligence, and therefore may not be accepted as a defence if a crime was committed via your network.
While it is a grey area at present, it seems likely that running a TOR exit node would cause you to be acting as ISP, and therefore obligated to log all connections, hold them for a period of 6 months, and to provide those logs to law-enforcement immediately upon request.
Yes. The power levels given are correct. A large subway train can draw around 3 MW during acceleration, potentially up to 4 MW if it is a modern 'all wheel driven' type train with high acceleration capability. This is very dependent on the size and speed of train - but taking something like the http://en.wikipedia.org/wiki/London_Underground_S_Stock as an example, the trains can be about 150 meters long, with acceleration of 1.3 m/s2.
The typical electrical energy cost of accelerating such a subway train, up to 'operating' speed is around 20-30 kWh.
Exactly right. The problem is that most 3rd rail/4 rail/short-range overhead systems run on DC power - usually around 700 V DC, but with a wide variation. Regenerative braking is widely used on may railways. However, the problem is that when the train's inverters inject DC power back into the rail, the voltage rises on the rail. Hopefully, there will be a nearby accelerating train which can absorb the energy. However, if there isn't the voltage on the rail will continue to rise until the train's inverters redirect the energy into on-board resistors, to permit continued dynamic braking.
Lowering the resistance of the 3rd rail, and making longer interconnected 3rd rail segments can all improve the efficiency of this system. But installing bigger rails, or upgrading to copper/aluminium is very expensive. Additionally, lower resistances increase the severity of potential short-circuit scenarios. Finally, short separated segments of power infrastructure is preferred for reasons of fault isolation. E.g. originally the whole London underground network used fully interconnected power rails, but in such a scenario, the system was unreliable, as a faulty train would degrade the entire network. After a couple of fault induced fires, the system was sectionalised into 1-2 mile segments.
Flywheels are already used on subway systems (for example New York and London Underground) in order to provide another method of capturing regenerated energy before the trains need to dump it into resistors. At strategic points, flywheels are connected to the rails. If the voltage on the rails rises above the normal grid supply voltage, the flywheel controller will accelerate the flywheel keeping the rail voltage controlled. Similarly, under severe acceleration conditions, where the rail voltage falls under load, the flywheel controller will draw energy from the flywheel and inject it into the rails. This allows subway operators to upgrade to faster accelerating trains, or run more trains, without upgrading their grid supply which may be very expensive, or impractical in power constrained cities
You are correct. I had mistaken the UK's "Digital Economy Act" for a European directive. It is not an EU directive, it is a piece of UK specific legislation.
The DEA places specific requirements on ISPs (for example, a coffee shop offering a wi-fi service to its customers would be considered an ISP under the legislation) to keep a log of all users of the network, and all the network destinations that they contact. To avoid prosecution in the event of a copyright claim traced to their premises, they will need to provide the name and address of the person making the access. If an ISP fails to keep a log of internet accesses and a real ID associated with them, then they must take responsibility personally for the offence.
Someone providing a totally free Wifi service (for which no fee is taken, and which is not provided as a 'bonus' to another transction) e.g. a home user, keeping a wifi router open for friends and neighbours, is not classed as an ISP. In their case, they are legally responsible for any offence committed using their network.
Does anyone know what the legal issues about TOR are in Europe?
European law makes the last 'named' user of an internet connection responsible for any transmissions via it. So, if running a TOR exit node from your home, your name would be the last name on the list (after your ISP, etc.). As a result, if a offence is committed via your connection, then you as the last named party are the person responsible for it.
The only defences are: 1. That you can provide proof of identity of the person who did commit the offence, or other strong evidence that you were not responsible. 2. You can prove that the use of your connection was unauthorized (and that you were not negligent in securing access to your equipment).
'Cloud' security has already been used extensively in the NHS. It was mandated for the 'standard' installations of PACS (X-ray viewing) and a number of other results reporting systems. It has been a catastrophic failure.
Some of the bugs that I've seen: 1. No caching of user credentials. If the WAN link, or remote server is unavailable - no login is possible. Result: total inability to access critical systems. 2. Caching of user credentials added to system. Result: doesn't work. Catastrophic regression bugs leave login near impossible even when WAN link available. 3. Barely tested 'pre-alpha' quality software. Constant crashes of the login client software. Usually requiring a hard reboot (power off), as several system services hang and block a clean shutdown. 4. Very slow authentication. Up to 2 minutes for a login to be authenticated. Result: Unusable in busy environments e.g. ER. 4b. Consequence of 4: Shared logins condoned by IT and explicitly recommended by senior management. 4c. Consequence of 4b: Medical notes are attributed to the wrong doctor/nurse and feedback of medical errors is given to the wrong person. 4d. Further consequence of 4b: Abuse of records systems to access confidential medical records of 'celebrities'. Random people ended up disciplined, but no formal action was taken as 4b had been officially sanctioned at senior level. 5. No local information about login failure. If there was a credential problem, there was no way for local staff to investigate the reason for login failure. Faulty credentials could take days or weeks to rectify. 6. No local administration of user permissions. If the national policy did not explicity allow a particular staff group to use a function, they could not use it, and there was no possible way to override it. E.g. only system administrators were permitted to change the brightness contrast with which an X-ray image could be displayed. If a doctor wanted to brighten an X-ray because it was too dark; or wanted to examine the lungs on an X-ray taken for the spine; they could not do it. Local administrators couldn't fix this. National administrators stuck to policy, which was for annual reviews of role permissions. Numerous (too many for me to count) mandatory, and medically essential features, were locked out in this way for 12 months, until the next annual review. 6b. Similar draconian restrictions remained in place for local administrators, and vendor tech support. Local administrators had no way of 'hiding' or 'deleting' an X-ray, mistakenly saved in the wrong patient file. If someone made a mistake and put the wrong name on, the local admin had to raise a support ticket with a national administrator who would authorize the vendor to rename the image - in the meantime (several days) the image would be visible in the wrong patient's file, causing substantial confusion. Similarly, vendor tech support were denied access to debug logs and other key features - as a result, bugs and misconfigurations were near impossible for them to fix. 7. Local administrators had no ability to authorize new users to the system. Temporary staff (to cover sickness), or new hires would have no access to the system, until they could get an appointment to visit the regional office for the national administration (many miles away, and appointments could take a week or more). The national admin staff insisted on sight of passport and 2 other forms of ID, national insurance number, 3 proofs of address, application forms countersigned by employee, immediate manager, IT manager and HR. If any one of these documents was missing - result, no login credentials. 7b. When login credentials expired after 12 months - guess what. Same thing again. Appointment for a week's time. Trip across the city, briefcase full of valuable ID documents.
These were just a few of the problems that users of the NHS 'cloud' security system faced. It was absolute chaos.
I'm now a member of an IT users group, and together we have developed recommendations for template tenders and contracts for individual NHS hospitals/doctors surgeries to use for procuring new IT systems. One of the key recommendations we make is that 'All security and authentication services must be provided locally, with full local administration.'
The CANDU reactor while an elegant design suffers from 2 problems which have limited its uptake outside of Canada.
1) It is incredibly expensive - $400-$500 million worth of heavy water are required to commission each reactor. As a result, CANDU designs are 20-30% more than conventional BWR/PWRs.
2) It doesn't meet minimum safety requirements for licensing in many countries (including the U.S.). The problem with CANDU is 'void coefficient'. Most countries require a negative void coefficient for a reactor to be licensed - this means overheating, or loss of coolant pressure, exerts a braking effect on the nuclear reaction via basic physical principles. CANDU has a Positive coefficient - and overheating reactor, or one losing coolant, will tend to accelerate the reaction.
Some countries have approved CANDU, because the void coefficient was designed around - big safety margins, and oversized safety systems. The Chernobyl accident was caused in part by having positive void coefficient - although in the RBMK design, little attention to avoiding run-away was given.
Looks funny to have a 1207 pin LGA socket in the foreground, with lots of ancillary tiny SMT discretes and TQFP or BGA ICs.
But what's that hiding in the background? A DIP packaged IC? Look at the size of it in comparison to everything else? I don't recall the last time I saw a DIP IC in a PC component.
I think MS is adding this technology to Longhorn, for the simple reason that this may be the only way they could licence HDTV playback technology.
One of the 'features' of HD-DVD and/or blu-ray is likely to be the ability to restrict the HD output. So, if a disc is tagged as 'protected content' then, output will only be possible via an encyrpted digital channel. If such a secure digital channel is not available, then the output should be downsampled to standard resolution.
Building a consumer media based OS which cannot play the industry standard media, would be shooting themselves in the foot.
It's worth pointing out, that similar features are already present in Windows, and in some video cards. If you want to play back DVD, and your video board does not support DRM (macrovision encoding) then windows will block DVD playing software for accessing that card.
I get regular e-mail newsletters from my bank. And have, on occasion been e-mailed by them with account issues.
In the case of the account queries, the e-mail simply read something like 'Please can you contact Jennifer Bloggs on 0800 1234567 ext 123'
So I call, and wait for them to ask me my personal security question (none of this, 'what's your mother's maiden name stuff') - I'm expecting to hear something like, 'Of what strain was your first specimen of Felis domesticus?'
It looks like next year will see the release of Serial-attached SCSI (SAS) to the masses.
It uses the same type of cable as SATA, but offers double the bandwidth (300 MB/s per port).
However, it's not just about getting a fancy new cable with the same old high-reliability, heavy-duty, high performance drives of old. There are some interesting new features:
You'll be able to get SAS hubs - plug 8 or 12 drives into a single controller port.
Optional dual-channel connections - connect 1 drive to 2 controllers, or to 2 ports on the same controller. Get double bandwidth, or improved reliability - if the cable or controller malfunctions, the drive just disconnects the faulty port and keeps on running.
Backwards compatible with SATA - need to upgrade capacity on your server but don't need high performance - just plug some cheap SATA drives into your SAS card (or hub).
The IR laser from a CD-ROM drive is relatively harmless. Power is typically about 0.1 mW which is not enough to cause signficant injury without a very high quality focus.
OTOH, the (visible) red laser from a new DVD-RW drive is powerful enough to be a fire risk, let alone a health risk. The latest 16x writing drives need 0.2 - 0.3 W output.
Wear and tear? What, if you push too many electrons through the logic gates they wear a little groove? Most servers use the same amount of power heavily loaded or just sitting there doing nothing.
All modern CPUs draw significantly more power when loaded than when idle. Some CPUs increase this difference still further by reducing clock speed and power supply voltage when idle.
A dual Xeon server could potentially draw 100 W more under load than when idle. For more powerful servers, this could be even higher.
Slashdot Mirror
You saw the car commercial because the uploader of the cute cat video requested that adverts be displayed before their video.
Youtube does sell advertising - and normally does it via not-too-indiscreet overlays. They do have an option for pre-video commercials. However, this is NOT the default, the video uploader must explicitly request this type of ad. The exception is where the video uploader has used 3rd party copyright content (either by using it from the youtube material library, where mandatory ads are the price video producers pay for using it; or the youtube CMS has detected content that matches reference material supplied by a copyright holder, and where that copyright holder has requested advertising income for that material's reuse).
Hospitals are often quite badly prepared for this sort of thing. A big problem is the number of computerised "medical devices" where the vendor insists on a very specific update policy (or very specific restrictions on 3rd party software).
I worked at one hospital where Confiker took the whole IT system down. A big problem in repairing the damage was that there were a lot of PACS (digital X-ray/CT/MRI viewing/storage) workstations where the PACS vendor would not permit the relevant windows updates or a 3rd party anti-virus to be installed on the servers/workstations. They relented after a 24 hour stand-off, after they realised that they was nothing they could do to keep the system happy enough to meet the SLA without the updates and a suitable anti-malware.
I work at another hospital now, where similar lack of updates due to comparability with old business apps prevents updates. E.g. The PCs still run XP SP1 (even the brand-new quad core xeons). There also doesn't appear to be funding for updating anti-malware - the hospital use Sophos 7 (which became unsupported last year).
This hospital has chronic problems with virus/malware infestation on a number of office machines - but while IT can clean the computers manually, there seems to be a reservoir if infection on file-servers, USB drives, etc. So the infections come straight back after a manual deletion. This hasn't caused a catastrophe locally, so management don't seem to care, but it is a major annoyance, as infected documents frequently end-up getting e-mailed out to other hospitals/doctors and destroyed without trace by the recipient's e-mail system. Docs have been known to put the files on a USB stick, take it home, clean it with an up-to-date virus scanner and then e-mail it out.
I don't understand the "brute force" claim. In the article, they later explain:
"Note how the 'root' user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. "
This makes no sense to me. 2 attempts at a login, and then the 3rd succeeds? How is that brute force? Or is it just extraordinary luck (or an inept password policy).
While I don't regularly perform penetration testing, my current understanding of brute-forcing SSH passwords, is that it requires thousand or millions of attempts, with the hope that an IDS doesn't spot the attempted ingress and lock-down firewalls, etc.
To me, this looks more like a 0-day. A few probes with potentially exploitative malformed logins, until they find one that works on the specific kernel/SSH version.
I'm guessing that you don't make stuff with an MTBF of 10 years. An MTBF of 10 years means that each year 10% of the items are breaking down and requiring repair/replacement due to some form of break down. In most industries, with products that unreliable you'd be out of business pretty quick.
MTBF is a completely different measure to expected lifetime. The expected lifetime is just that - how long the device is expected to work for, before its performance becomes unacceptable (i.e. when the device becomes worn out).
MTBF measures how reliable a device is *during* its expected lifetime (i.e. before the device becomes completely worn out).
But MTBF isn't a useful measure for a single drive. It's a measure for a population of drives.
If I have 10,000 hard drives in my datacenter, then an MTBF of 1,500,000 hours means that I need to plan for replacing approximately 60 drives each year (with some allowance for bad years and good years), whereas an MTBF of 2,000,000 hours means I only need to plan for an expected 45 replacements.
The technical issues behind this fracas are even more banal, and so trivial that it's already been reverse engineered. In effect, the "DRM" was purely a closed specification, and not a technological measure such as encryption.
Unsurprisingly, the specification has already been deployed in popular open-source projects.
For those interested, the technical extent of the "DRM" and "encryption" was the use of a pre-calculated Huffman table, which must be embedded in the receiver firmware, in order to obtain the programme guide.
It's not the processing of the images that is slow - it is the collection of the raw data. In an MRI scan, the machine performs performs a series of experiments with the following basic format; transmit a high-power RF pulse, distort the magnetic field in a complex manner, and then capture the "echo" of the RF pulse. Each "echo" contributes some information about the image. In the most basic form, each "echo" can contribute an information equivalent to one row of pixels.
So if you wish to acquire a 256x256 image, the scanner needs 256 echoes to have enough data to reconstruct an image, and therefore needs to run the experiment 256 times with different parameters to acquire all the data needed for "developing". The problem, is that each experiment takes a finite time to run (which can be several seconds for many types of diagnostic image). If each experiment requires 3 seconds (typical for a standard brain scan), this means 768 seconds to capture enough data for 1 image.
In practice, there are lots of tricks that can be done:
1. interleaving scans - so the machine runs an scan looking at the top of the head, then 100 ms later runs a scan looking 1 cm lower, then 100 ms later, runs a scan 1 cm lower still, etc.). As the echoes come back at different times, and the experiments do not overlap in space, the images can, in effect, be captured in parallel.
2. Multiple "echoes " can be generated in a single experiment. Adding more echoes , increases speed, but degrades image quality, and may be limited by the performance of the magnetic field (gradient) distortion capability of the scanner hardware, by electrical induction (from the rapidly distored magnetic field) in the patient's body (causing electric shock sensations), or by the need for increased RF energy (and therefore total RF energy deposition in the patient's body).
3. Adding multiple receive-antennas and radio receiver hardware; by using 2 receive antennas at different positions, it becomes possible to extract more information from an "echo" by taking 2 recordings from different positions. Current top-of-the-range MRI scanners take this to the extreme with 128 sets of radio receiver/ADC hardware, with the ability to connect antenna modules with up to 96 antennas per body part.
In a medical setting, multiple entire sets of images will be captured using radically different scan parameters, in order to detect different types of abnormality. So, a typical brain MRI will usually have 5 sets of images of the brain, but with different appearances, where the scan parameters are set to bring out different features of interest - e.g. one scan will be very sensitive for water (giving good overall anatomical detail of the brain, and good sensitivity for many abnormalities), one will be more sensitive for fat (and so maximize anatomical detail of the brain, which contains lots of lipid), one will be sensitive for iron deposits (and so be very good at detecting blood/bleeding, but will show virtually no anatomical detail), one will have improved sensitivity for water within the brain tissue (but reduced sensitivity for the water around the brain, allowing surface abnormalities to be detected) and one will have sensitivity for the pattern of Brownian motion of water molecules (and so detect disturbed physiological processes, but shows no anatomical detail).
What is novel about the algorithm described here, is that it allows information from one set of images to be used during the "development" of a different set (e.g. by finding the edge of the head, and then using the fact that the space outside the head is known to be empty space, during the development process of the next set of images). By applying this additional constraint, it becomes possible to reconstruct any subsequent images with less than a "full quota" of data, allowing the scanner to skip part of the time consuming data acquisition.
The difficulty with this technique, is that the different scan parameters utilise different physical processes to build up the images - hence basin
Nice post. Just one correction, at the beam energies used in these devices (50 kVp - 120 kVp), most X-ray photons certainly do not go straight through you. At about 120 kVp, about 75% will get absorbed through the torso - and in the case of 50 kVp, essentially 100% will be absorbed (with only a fraction of a percent getting scattered, as 50 kVp is below the optimal range for Compton scattering in body tissues).
In fact, it was widely stated in the marketing information and propaganda for these scanners that the X-ray beam does not penetrate skin. This statement is patently false at all energies in commercial use. If they can get away with deliberate lies as basic as that, how can you reasonably believe any more difficult claims?
Kevlar doesn't offer much protection against rodent knawing. It's mainly for longitudinal strength - allowing the cable to be winched through ducts (like electric cable) without putting stress on the delicate glass fibers.
Rodent resistant cables are armored with a hard material which is hard enough to resist gnawing, preventing the rodent from penetrating the underlying cable - e.g. epoxy embedded glass fibers (for cables judged "low-risk" of rodent attack), or steel (for high-risk cables).
The UK requires (under the Digital Economy Act) that any internet service provider (which the law defines in an exceedingly broad way) keeps logs of all customer connections and retain them for a minimum period of 6 months. They are not required to log the contents of the connection, merely the IP.
This includes an individual or small business offering wi-fi to customers on their premises. Under the DEA, they are an ISP and must keep the relevant logs (which include positive identity of the customer) for the required period. Failure to keep the logs is an offence, and may mean that the operator of the network is personally liable for any offences that were alleged to have been committed.
Shouldn't the victim's family just be able to sue the guy?
Harassment and making malicious communications are crimes.
In the UK, there would be little to be gained from suing. With a few exceptions (notably libel), there is no principle of "damages" in UK law. Broadly speaking, if you sue someone, you can only claim for demonstrable financial loss directly arising from the act or omission. You cannot sue for "compensation" or "damages".
In this case, the postings were distressing and offensive, but no financial loss was suffered, and therefore there is no claim to be sued for.
Even if they can prove a particular machine was used to commit the offence, how will they prove who used it? That isn't even taking into account things such as TOR. I'd go as far as to say he is downright lying.
Why would they do that?
The UK has a law called the "Digital Economy Act" which requires all ISPs to log all communications (at the IP address/connection level, rather than the contents) together with the identity details of the person on whose behalf they were made.
This means that if you provide internet services to other people (e.g. you are a coffee shop and provide wifi for customers) you are acting as an ISP and must ensure that you verify the identity of all users for the purposes of complying with the DEA. If you fail to do this, then you commit an offence under the DEA, and may additionally be automatically liable for any communications offences committed via your connection (This is in the same way that the CEO of a company is personally responsible for any driving offences committed with a company vehicle, unless they provide details of the identity of the driver at the time. Failure to keep adequate records is not a defence.)
There is no loophole for running a completely open network. It is a requirement that you take all reasonable steps to protect yourself. Running a totally open public network could be regarded as negligence, and therefore may not be accepted as a defence if a crime was committed via your network.
While it is a grey area at present, it seems likely that running a TOR exit node would cause you to be acting as ISP, and therefore obligated to log all connections, hold them for a period of 6 months, and to provide those logs to law-enforcement immediately upon request.
Yes. The power levels given are correct. A large subway train can draw around 3 MW during acceleration, potentially up to 4 MW if it is a modern 'all wheel driven' type train with high acceleration capability. This is very dependent on the size and speed of train - but taking something like the http://en.wikipedia.org/wiki/London_Underground_S_Stock as an example, the trains can be about 150 meters long, with acceleration of 1.3 m/s2.
The typical electrical energy cost of accelerating such a subway train, up to 'operating' speed is around 20-30 kWh.
Exactly right. The problem is that most 3rd rail/4 rail/short-range overhead systems run on DC power - usually around 700 V DC, but with a wide variation. Regenerative braking is widely used on may railways. However, the problem is that when the train's inverters inject DC power back into the rail, the voltage rises on the rail. Hopefully, there will be a nearby accelerating train which can absorb the energy. However, if there isn't the voltage on the rail will continue to rise until the train's inverters redirect the energy into on-board resistors, to permit continued dynamic braking.
Lowering the resistance of the 3rd rail, and making longer interconnected 3rd rail segments can all improve the efficiency of this system. But installing bigger rails, or upgrading to copper/aluminium is very expensive. Additionally, lower resistances increase the severity of potential short-circuit scenarios. Finally, short separated segments of power infrastructure is preferred for reasons of fault isolation. E.g. originally the whole London underground network used fully interconnected power rails, but in such a scenario, the system was unreliable, as a faulty train would degrade the entire network. After a couple of fault induced fires, the system was sectionalised into 1-2 mile segments.
Flywheels are already used on subway systems (for example New York and London Underground) in order to provide another method of capturing regenerated energy before the trains need to dump it into resistors. At strategic points, flywheels are connected to the rails. If the voltage on the rails rises above the normal grid supply voltage, the flywheel controller will accelerate the flywheel keeping the rail voltage controlled. Similarly, under severe acceleration conditions, where the rail voltage falls under load, the flywheel controller will draw energy from the flywheel and inject it into the rails. This allows subway operators to upgrade to faster accelerating trains, or run more trains, without upgrading their grid supply which may be very expensive, or impractical in power constrained cities
You are correct. I had mistaken the UK's "Digital Economy Act" for a European directive. It is not an EU directive, it is a piece of UK specific legislation.
The DEA places specific requirements on ISPs (for example, a coffee shop offering a wi-fi service to its customers would be considered an ISP under the legislation) to keep a log of all users of the network, and all the network destinations that they contact. To avoid prosecution in the event of a copyright claim traced to their premises, they will need to provide the name and address of the person making the access. If an ISP fails to keep a log of internet accesses and a real ID associated with them, then they must take responsibility personally for the offence.
Someone providing a totally free Wifi service (for which no fee is taken, and which is not provided as a 'bonus' to another transction) e.g. a home user, keeping a wifi router open for friends and neighbours, is not classed as an ISP. In their case, they are legally responsible for any offence committed using their network.
Does anyone know what the legal issues about TOR are in Europe?
European law makes the last 'named' user of an internet connection responsible for any transmissions via it. So, if running a TOR exit node from your home, your name would be the last name on the list (after your ISP, etc.). As a result, if a offence is committed via your connection, then you as the last named party are the person responsible for it.
The only defences are:
1. That you can provide proof of identity of the person who did commit the offence, or other strong evidence that you were not responsible.
2. You can prove that the use of your connection was unauthorized (and that you were not negligent in securing access to your equipment).
I tried this once on some old 100Base-SX stuff because, well, it was crap.
So, I spliced a power cord onto a patch cable, and plugged it in.
Goddam thing survived. It was like nothing happened. I guess they don't make things like they used to. :)
'Cloud' security has already been used extensively in the NHS. It was mandated for the 'standard' installations of PACS (X-ray viewing) and a number of other results reporting systems. It has been a catastrophic failure.
Some of the bugs that I've seen:
1. No caching of user credentials. If the WAN link, or remote server is unavailable - no login is possible. Result: total inability to access critical systems.
2. Caching of user credentials added to system. Result: doesn't work. Catastrophic regression bugs leave login near impossible even when WAN link available.
3. Barely tested 'pre-alpha' quality software. Constant crashes of the login client software. Usually requiring a hard reboot (power off), as several system services hang and block a clean shutdown.
4. Very slow authentication. Up to 2 minutes for a login to be authenticated. Result: Unusable in busy environments e.g. ER.
4b. Consequence of 4: Shared logins condoned by IT and explicitly recommended by senior management.
4c. Consequence of 4b: Medical notes are attributed to the wrong doctor/nurse and feedback of medical errors is given to the wrong person.
4d. Further consequence of 4b: Abuse of records systems to access confidential medical records of 'celebrities'. Random people ended up disciplined, but no formal action was taken as 4b had been officially sanctioned at senior level.
5. No local information about login failure. If there was a credential problem, there was no way for local staff to investigate the reason for login failure. Faulty credentials could take days or weeks to rectify.
6. No local administration of user permissions. If the national policy did not explicity allow a particular staff group to use a function, they could not use it, and there was no possible way to override it. E.g. only system administrators were permitted to change the brightness contrast with which an X-ray image could be displayed. If a doctor wanted to brighten an X-ray because it was too dark; or wanted to examine the lungs on an X-ray taken for the spine; they could not do it. Local administrators couldn't fix this. National administrators stuck to policy, which was for annual reviews of role permissions. Numerous (too many for me to count) mandatory, and medically essential features, were locked out in this way for 12 months, until the next annual review.
6b. Similar draconian restrictions remained in place for local administrators, and vendor tech support. Local administrators had no way of 'hiding' or 'deleting' an X-ray, mistakenly saved in the wrong patient file. If someone made a mistake and put the wrong name on, the local admin had to raise a support ticket with a national administrator who would authorize the vendor to rename the image - in the meantime (several days) the image would be visible in the wrong patient's file, causing substantial confusion. Similarly, vendor tech support were denied access to debug logs and other key features - as a result, bugs and misconfigurations were near impossible for them to fix.
7. Local administrators had no ability to authorize new users to the system. Temporary staff (to cover sickness), or new hires would have no access to the system, until they could get an appointment to visit the regional office for the national administration (many miles away, and appointments could take a week or more). The national admin staff insisted on sight of passport and 2 other forms of ID, national insurance number, 3 proofs of address, application forms countersigned by employee, immediate manager, IT manager and HR. If any one of these documents was missing - result, no login credentials.
7b. When login credentials expired after 12 months - guess what. Same thing again. Appointment for a week's time. Trip across the city, briefcase full of valuable ID documents.
These were just a few of the problems that users of the NHS 'cloud' security system faced. It was absolute chaos.
I'm now a member of an IT users group, and together we have developed recommendations for template tenders and contracts for individual NHS hospitals/doctors surgeries to use for procuring new IT systems. One of the key recommendations we make is that 'All security and authentication services must be provided locally, with full local administration.'
The CANDU reactor while an elegant design suffers from 2 problems which have limited its uptake outside of Canada.
1) It is incredibly expensive - $400-$500 million worth of heavy water are required to commission each reactor. As a result, CANDU designs are 20-30% more than conventional BWR/PWRs.
2) It doesn't meet minimum safety requirements for licensing in many countries (including the U.S.). The problem with CANDU is 'void coefficient'. Most countries require a negative void coefficient for a reactor to be licensed - this means overheating, or loss of coolant pressure, exerts a braking effect on the nuclear reaction via basic physical principles. CANDU has a Positive coefficient - and overheating reactor, or one losing coolant, will tend to accelerate the reaction.
Some countries have approved CANDU, because the void coefficient was designed around - big safety margins, and oversized safety systems. The Chernobyl accident was caused in part by having positive void coefficient - although in the RBMK design, little attention to avoiding run-away was given.
Looks funny to have a 1207 pin LGA socket in the foreground, with lots of ancillary tiny SMT discretes and TQFP or BGA ICs.
But what's that hiding in the background? A DIP packaged IC? Look at the size of it in comparison to everything else? I don't recall the last time I saw a DIP IC in a PC component.
I think MS is adding this technology to Longhorn, for the simple reason that this may be the only way they could licence HDTV playback technology.
One of the 'features' of HD-DVD and/or blu-ray is likely to be the ability to restrict the HD output. So, if a disc is tagged as 'protected content' then, output will only be possible via an encyrpted digital channel. If such a secure digital channel is not available, then the output should be downsampled to standard resolution.
Building a consumer media based OS which cannot play the industry standard media, would be shooting themselves in the foot.
It's worth pointing out, that similar features are already present in Windows, and in some video cards. If you want to play back DVD, and your video board does not support DRM (macrovision encoding) then windows will block DVD playing software for accessing that card.
I get regular e-mail newsletters from my bank. And have, on occasion been e-mailed by them with account issues.
In the case of the account queries, the e-mail simply read something like 'Please can you contact Jennifer Bloggs on 0800 1234567 ext 123'
So I call, and wait for them to ask me my personal security question (none of this, 'what's your mother's maiden name stuff') - I'm expecting to hear something like, 'Of what strain was your first specimen of Felis domesticus?'
It uses the same type of cable as SATA, but offers double the bandwidth (300 MB/s per port).
However, it's not just about getting a fancy new cable with the same old high-reliability, heavy-duty, high performance drives of old. There are some interesting new features:
You'll be able to get SAS hubs - plug 8 or 12 drives into a single controller port.
Optional dual-channel connections - connect 1 drive to 2 controllers, or to 2 ports on the same controller. Get double bandwidth, or improved reliability - if the cable or controller malfunctions, the drive just disconnects the faulty port and keeps on running.
Backwards compatible with SATA - need to upgrade capacity on your server but don't need high performance - just plug some cheap SATA drives into your SAS card (or hub).
The IR laser from a CD-ROM drive is relatively harmless. Power is typically about 0.1 mW which is not enough to cause signficant injury without a very high quality focus. OTOH, the (visible) red laser from a new DVD-RW drive is powerful enough to be a fire risk, let alone a health risk. The latest 16x writing drives need 0.2 - 0.3 W output.
All modern CPUs draw significantly more power when loaded than when idle. Some CPUs increase this difference still further by reducing clock speed and power supply voltage when idle.
A dual Xeon server could potentially draw 100 W more under load than when idle. For more powerful servers, this could be even higher.