In order to be able to perform its function swift is registered in nearly all countries around the globe. Quite a few of them have considerably more strict privacy laws combined with considerably more strict banking regulations. In addition to that in some of them the possibility for political intervention in favour of the defendant will be very slim. Frankly, I am surprised it is not being sued in Switherland.
In this case it is not Linux it is one of the DHCP server software varieties which by coincidence runs on linux. Which of course does not make a nice flamewar subject for Slashdot...
Go a couple of posts up the chain. There is a post by me that says how to do it in the simplest form using a kernel ondemand governor (no need to repeat it) including actual commands.
This is good enough for 99% of typical enterprise server loads including nearly any file serving, webserving, etc. The only area where you may find this approach problematic are cases where the rampup from 0 to 100% load is not stepwise, but nearly instantaneous and the latency of the rampump time is critical. There are a few applications like this out there (not many).
The reason for this limitation is that the latency for changing CPU frequency is in the ms range. It is not by any means instantaneous (and the governor may also introduce extra latency to avoid oscillating between frequencies). This usually does not matter for file serving requests or simple webserving request. In that case the load is proportional to the number of connections and these do not rampup from 0 to max nearly instantaneously even if you are getting slashdotted. This also does not matter if you have complex CPU intensive requests like a very complex web-front-ended transaction or a CPU intensive SQL query. It takes ms (if not s) to complete it so ramping up the frequency in the meantime is more or less OK and the overall transaction time with and without the rampup ends up being comparable.
You can further improve on this using userspace daemons like cpufrqeqd which can run complex policies. Frankly, I used to use them only before the ondemand governor became stable enough and have not needed them since. They provide better use of the interim frequency steps between minimum and maximum they will provide a more smooth rampup curve.
While the tools are out there and they are part of the OS nowdays there is no one-size-fits all here. It is a good idea to start with the kernel ondemand governor and benchmark. If you do not like the results try to write a policy for one of the userland daemons and benchmark.
Personally, I would recommend using this interface on any P4 or Core based CPU. There it rocks. Pentium M is a bit special case as most of them usually come on motherboards that also support voltage frequency alteration. While the drivers will whinge that you can achieve better results with those the latency of the change is much bigger so I would stay away from those. From the non-Intel CPUs Via has a similar interface. At least at some point it f***ed it up very badly by having to reprogram half of the PCI bus to change the frequencies and there are kernels where it is outright disabled. Transmeta often has bad frequency tables with only one frequency in them so there it is quite useless. AMD also has its dose of bugs. There is a significant amount of errata especially for SMP motherboards. In many motherboards the interface is outright disabled and cannot be reenabled (Tyan Thunder comes to mind). And so on. Your mileage can vary, you have to try.
1. They claim to be showing power vs performance statistics including for idle. If you do so, you need to know the factors affecting this for the OS used. They have shown to know only the ones relevant under Winhoze.
2. They have not configured the system for optimum power vs performance neither for idle, nor for IO load, nor for varied load. In all of these cases you can improve power consumption and heat produced by anything from 30% to 70%. Instead of that they are scratching their testicles by tweaking settings that yield a couple of percent. Further to this, by keeping the power dissipation in a server much lower, using this also allows to improve MTBF by several times. Knowing this and knowing how to do this is an essential skill for a server admin (I used to start interviews with this and march people out if they claimed to _know_ and _understand_ x86 hardware without knowing this).
Overall, classic example of lack of clue. For the reference - the difference in power consumption at lowest frequency compared to highest in some server designs (Intel OEM boards come to mind here) may be as much as 10 times. Compared to that all other system settings yield crumbs that are not worth picking.
The cold war is in its prime and the military complex and the army on both sides yield tremendous influence. Simultaneously, a number of planning groups on both sides of the iron curtain come to the same conclusion "The Oil is about to run out". And they start to develop plans:
The Russians look at their oil utilisation situation and notice that "their cars are at least 30% heavier and less fuel efficient than the rest of the world. They have to redesign all of their vehicles for fuel efficiency and retool all of their manufacturing industry for better efficiency. This requires a lot of money which can be best found in dropping the cold war confrontation altogether and redirecting money from the military to fuel efficiency and renewable energy projects. They look at it and decide to prepare to invade a country in the Gulf instead to secure their oil supply for the close future.
Does this ring any bells? Written in 1990 by the way. Pre-SUV era novel.
They still ran it like Windoze. They did not use a single of the linux power control options and tunables leaving everything at defaults. This is not how you run a power efficient installation. There are plenty of tunables under the cpufreq and some less relevant ACPI stuff that make up to 70% power consumption difference on a 1U server. They touched none of them.
Uh, the lowest frequency of the Xeon 5160 is 2GHz.
Utter bullshit. That is the base frequency. The lowest frequency adjustable through the cpufreq standard P4 runtime frequency interface is 200MHz or 256MHz. If the base is 2GHz it is 256 (it is usually in 8 equal steps).
To see the frequencies:
modprobe p4_clockmod
modprobe cpufreq_ondemand
To enable dynamic scaling (via kernel)
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_gover nor
Watch either/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_f req or the cpu MHz part of/proc/cpuinfo change as the system load changes. For Xeon at the lowest frequency in the table the power consumption is under 10W. AMD currently cannot beat that. Their power vs frequency curve is not that steep. This is if the motherboard manufacturer have not turned off the interface in the first place which is quite common for AMD SMP motherboards.
I just saw the article. While they did not run Winhoze, they still did not know how to run a power efficient server installation under Linux (or BSD for that matter). They ran it like Winhoze. They installed with the belief that the OS itself has no power control and all you need to tweak is BIOS. They tweaked all kinds of shit which has very little bearing on the system power consumption and performance. Classic case of pseudotweakers that have no clue whatsoever in how to set up a server.
Amazingly skimpy article. No effing data whatsoever.
I can bet a case of beer that this was run in a standard server config under Winhoze Server 2003. These are the results you more or less expect in that case.
If that is the case neither Opteron, nor Xeon utilise CPU frequency scaling as there is no OS support. If you use CPU frequency scaling under let's say current RHEL or Debian, the idle and IO efficiency picture tends to reverse because AMD is still not as good at this as Intel. In fact it not even supported on many server BIOSes/Motherboards.
As a result even if supported (and it usually isn't) AMD power utilisation with reduced frequency in idle is higher than that of a Xeon system which consumes nearly nothing when you slam it down to 250MHz. If the OS drops and ramps up the CPU frequency correctly Intel should win on idle and IO-only benchmarks.
Not that it matters in the slightest as AMD will cream it on most real life loads anyway due to better memory and IO bandwidth.
1. AFAIK someone in Seattle was looking into this more than 2 years ago. So there is nothing particularly innovative about it.
2. You do not need GPS. In fact you do not want GPS, because this makes the data individually identifiable and you have to prove that you are not doing something nefarious with it. Paging stats and handover stats from cells located near trunk routes will be a perfectly good replacement for this. All you need is to play correlation analysis vs actual traffic stats for a couple of days. You can make them more precise by looking at how the timing advance in GSM or power level in CDMA changes, but this is the same can of worms as GPS. You have to prove that privacy is not affected.
You are overestimating the amount of EM noise emitted by a motherboard outside the case. Very few computer components are noisy. The ones that are like some modems, wireless cards, etc feature additional individual shielding.
Designwise it is not very different from my first office computer back in 1993. That one had all of its components spread around screwed to a desk so you can easily unplug or plug any one of them and replace with the component you are testing (we ran a small hardware design shop that also did computer repairs). This was long before the days of windowed cases and was quite unusual for the time. I have seen all kinds of reactions: fascination, fear (will it spark), interest, etc.
I agree with your main point though. While you are no longer executed summarily on the spot for running with a backpack with cables sticking from it, that is not far off. If you run with such a backpack on the Tube any nearby dog unit officers hand will go straight towards the release latch (this has made me drop the speed and miss my train from Kings X on more than one occasion).
One comment: The webpage is dynamic. The.exe you see when clicking on the link is the final choice after exploits failed (and they did). If you we Joe Average who did not bother to pay for AV and did not update his machine since he bought it from Best Buy you would have been infected straight away long before that. No prompts.
Exactly. If MSFT bough these votes under the table it would have been graft and USA has specific laws and some fairly serious sanctions regarding its own companies doing graft abroad. In this case everything is aboveboard and as correctly noted by many people this while despicable is legally allowed. While at it, it will be worthwhile to look if MSFT did this somewhere under the table. This will allow applying USA laws on graft abroad.
Even if it does not, putting load on an a muscle that is suffering from severe inflammation will most likely damage it beyond repair. If you take the load off and let the inflammation subside the muscle has a fair chance of recovery in at least some cases. AFAIK, so far the pump bypass has shown to work in cases like this.
Her heart just needed a rest until it heals. There were a few cases here in the UK as well and implanting a parallel pump to assist is now considered a standard procedure in many cases where the transplant was the only option. Especially in kids and especially in cases where the heart has been damaged by inflammation. It is a safe bet really - if it heals good, if it does not the patient has a much better chance to survive until a suitable transplant is found. It is a pity that most pumps can take load only off some portions of the heart and not all of it (too much blood in the coffee subsystem to remember which).
First was outsourcing IT, then came SAAS to compensate for the failures of outsourced IT. Most shops that have retained their IT in house through the whole outsourcing boom of the last 8 years are not looking at SAAS. The reason is that if an inhouse IT department is still around, it is usually delivering on time and on target.
Now shops which have outsourced are a different matter. While most large IT outsourcing contracts have failed to deliver on all of their targets, the few that were delivered brought with them standard interfaces. These are much easier to rip out and replace with SAAS. And much more tempting.
I have had to migrate users off Outlook 2003 to Mozilla due to mailbox corruption so unfortunately MSFT has not fixed all bugs. No idea about 2007. In most cases, based on my extremely unscientific observations a user which has a 2G+ mailbox does not want Outlook anyway.
The entire sync/remote fs approach is fundamentally wrong for any place that has more than 2 people working on the same project/material.
What if you DO NOT WANT to resolve the conflict right away? What if the document that has been changed by two people is 200 pages long and the changes are substantial and you have 10 minutes to get the data and run? Even if you have the time there are plenty of other reasons why you may want to postpone the merge and review.
The only real solution is to keep documents in a revision control system. It has all that is necessary for this purpose - conflict resolution, versioning, branching, authentication, per-object authorisation, etc. Unfortunately, I have yet to see one that is capable of invoking application specific merge utilities (you cannot use bare diff on most document formats). This is what may be worth scripting though. It is not that hard to check the MIME type of the conflict file and invoke the correct editor based on MIME type and nearly all revision control systems have the hooks to do that.
There is no point implementing laptop backups before implementing a no-quota IMAP mail server. Exchange in its native mode does not count due to a number of corruption bugs which hit you once your inbox exceeds 2G (it should be OK as an IMAP server, bugs are mostly in Outlook). As far as the user is concerned his primary concern for laptop data loss is email. So you have to back it up as a part of any backup solution. If you are storing email locally on the laptop and backing it up the backup will nearly always be corrupt due to file locking. Further to this, the financial, network and storage resource required to implement a laptop backup solution exceeds by far the cost of extra storage on the mail server. In addition to that if the email is stored centrally the backup size per laptop decreases straight away to become on the order of MBs instead of GBs for most users.
Offline most likely derives its origins from Coda which was designed to work for 100MB at most. It seems to inherit all of its problems when the data volumes become big. I have had to support an environment where people casually offlined 3-4GB documentation trees and it was falling over on regular basis.
Further to this, offline files has a number of fairly fundamental bugs in the actual implementation. It records both the IP and the name of the server somewhere when doing the offlining. As a result if the name (but not the drive) or the IP changes your entire offline tree goes south and stays offline. You can neither delete it nor reconnect it and the only way of dealing with this is either surgery to the network (aliasing IP addresses) until you reconnect. The only alternative is to rebuild the affected laptops from scratch.
It is not just Sony it is the technology itself. It is inherently dangerous and all manufacturers so far have had recalls and safety incidents. Sony is simply the biggest manufacturer of Li-polymer cells so we get to hear about it most.
They do not have to, but they do after they ended up being a total laughing stock in a courtroom 10+ years ago when the defence lawyer measured the judge travelling at 9mph while sitting on the bench. As a result the case got thrown out with prejudice.
From there on the staff which processes offences got trained not to try to prosecute if the offence is within the camera precision limit (which for classic Gatso with double photo verification is around 5%). This is where the 5% comes from. The new cameras have considerably better measurements. The speed averaging ones can probably measure better than a car speedo.
Coming back onto the Comcast topic I do not see what Comcast problem is. Their AUP are a classic case of tehcnical incompetence being compensated via admin measures.
1. Downstream they can police at the CMTS. I have yet to see one that cannot do QoS. Even the "Dear Cretins" wankers over here have shown capable of doing that.
2. Upstream - DOCSIS past 1.0 allows the CMTS to tell which station can speak at which particular moment. As a result any station can be throttled and controlled and made to comply to the policy. All it takes is to program the CMTS to start filling the MAPs with some meaningfull information and decrease the part which is "free for all".
3. On top of that they provision the modems and what they do not want to do on the CMTS can be done by simply tftping a new config onto the modem which is something the management system should be able to do in bulk per product category (you do not even need to click on individual stations).
So this is a classic case of "cable and brains do not mix".
Current legal calibration requirements for EU (and AFAIK USA) are +0%/-7% (note the big fat zero for the + error). Manufacturing errors, calibration errors, etc all tend to follow a Gauss bell curve so manufacturers tend to calibrate to -3% and allow +/-3% error around that.
As far as the precision of measurement equipment if police is given high precision measurement equipment like the new speed averaging cameras in the UK they use it without any second doubt. These have sub-1% error because they measure the time it takes your car (recognised by number plate) to traverse 2-5 miles. As a result many drivers who expected the 10%/5 mph leeway usually applied to radar and laser cases where very unpleasantly surprised last winter during the roadworks on the M25 and M4 around london (not me, but I know a number of people who clocked 6+ points on their license in a matter of days).
This is not crippling admin accounts, it is making apps behave in an administrative manner when run by an admin.
Staroffice 3.x was a brilliant example. When you ran its setup as root it automatically went into global per-machine setup mode, while running it as Joe Average User made it run a workstation setup. In fact Office 6.x for Windows 95/NT behaved in a similar manner as well. If you ran it from a network install it behaved differently when run as admin vs when run as an average user.
I have no idea why developers stopped doing that. IMO, that was the right behaviour.
Slashdot Mirror
Why just Belgium?
In order to be able to perform its function swift is registered in nearly all countries around the globe. Quite a few of them have considerably more strict privacy laws combined with considerably more strict banking regulations. In addition to that in some of them the possibility for political intervention in favour of the defendant will be very slim. Frankly, I am surprised it is not being sued in Switherland.
In this case it is not Linux it is one of the DHCP server software varieties which by coincidence runs on linux. Which of course does not make a nice flamewar subject for Slashdot...
Go a couple of posts up the chain. There is a post by me that says how to do it in the simplest form using a kernel ondemand governor (no need to repeat it) including actual commands.
This is good enough for 99% of typical enterprise server loads including nearly any file serving, webserving, etc. The only area where you may find this approach problematic are cases where the rampup from 0 to 100% load is not stepwise, but nearly instantaneous and the latency of the rampump time is critical. There are a few applications like this out there (not many).
The reason for this limitation is that the latency for changing CPU frequency is in the ms range. It is not by any means instantaneous (and the governor may also introduce extra latency to avoid oscillating between frequencies). This usually does not matter for file serving requests or simple webserving request. In that case the load is proportional to the number of connections and these do not rampup from 0 to max nearly instantaneously even if you are getting slashdotted. This also does not matter if you have complex CPU intensive requests like a very complex web-front-ended transaction or a CPU intensive SQL query. It takes ms (if not s) to complete it so ramping up the frequency in the meantime is more or less OK and the overall transaction time with and without the rampup ends up being comparable.
You can further improve on this using userspace daemons like cpufrqeqd which can run complex policies. Frankly, I used to use them only before the ondemand governor became stable enough and have not needed them since. They provide better use of the interim frequency steps between minimum and maximum they will provide a more smooth rampup curve.
While the tools are out there and they are part of the OS nowdays there is no one-size-fits all here. It is a good idea to start with the kernel ondemand governor and benchmark. If you do not like the results try to write a policy for one of the userland daemons and benchmark.
Personally, I would recommend using this interface on any P4 or Core based CPU. There it rocks. Pentium M is a bit special case as most of them usually come on motherboards that also support voltage frequency alteration. While the drivers will whinge that you can achieve better results with those the latency of the change is much bigger so I would stay away from those. From the non-Intel CPUs Via has a similar interface. At least at some point it f***ed it up very badly by having to reprogram half of the PCI bus to change the frequencies and there are kernels where it is outright disabled. Transmeta often has bad frequency tables with only one frequency in them so there it is quite useless. AMD also has its dose of bugs. There is a significant amount of errata especially for SMP motherboards. In many motherboards the interface is outright disabled and cannot be reenabled (Tyan Thunder comes to mind). And so on. Your mileage can vary, you have to try.
1. They claim to be showing power vs performance statistics including for idle. If you do so, you need to know the factors affecting this for the OS used. They have shown to know only the ones relevant under Winhoze.
2. They have not configured the system for optimum power vs performance neither for idle, nor for IO load, nor for varied load. In all of these cases you can improve power consumption and heat produced by anything from 30% to 70%. Instead of that they are scratching their testicles by tweaking settings that yield a couple of percent. Further to this, by keeping the power dissipation in a server much lower, using this also allows to improve MTBF by several times. Knowing this and knowing how to do this is an essential skill for a server admin (I used to start interviews with this and march people out if they claimed to _know_ and _understand_ x86 hardware without knowing this).
Overall, classic example of lack of clue. For the reference - the difference in power consumption at lowest frequency compared to highest in some server designs (Intel OEM boards come to mind here) may be as much as 10 times. Compared to that all other system settings yield crumbs that are not worth picking.
Yep. I suggest going to the library and renting "The Negotiator" by F. Forsyth http://www.amazon.co.uk/Negotiator-Frederick-Forsy th/dp/0552134759/ref=pd_bbs_sr_4/203-8884289-89535 21?ie=UTF8&s=books&qid=1188637076&sr=8-4. The book itself is nothing much compared to many of his other writings like "Dogs of War", "The Veteran" or "The Day of the Jackal". It is the basic plotline of the book that is really scary (it was written in 1988-1990 when the wall crumbled):
The cold war is in its prime and the military complex and the army on both sides yield tremendous influence. Simultaneously, a number of planning groups on both sides of the iron curtain come to the same conclusion "The Oil is about to run out". And they start to develop plans:
The Russians look at their oil utilisation situation and notice that "their cars are at least 30% heavier and less fuel efficient than the rest of the world. They have to redesign all of their vehicles for fuel efficiency and retool all of their manufacturing industry for better efficiency. This requires a lot of money which can be best found in dropping the cold war confrontation altogether and redirecting money from the military to fuel efficiency and renewable energy projects. They look at it and decide to prepare to invade a country in the Gulf instead to secure their oil supply for the close future.
Does this ring any bells? Written in 1990 by the way. Pre-SUV era novel.
They still ran it like Windoze. They did not use a single of the linux power control options and tunables leaving everything at defaults. This is not how you run a power efficient installation. There are plenty of tunables under the cpufreq and some less relevant ACPI stuff that make up to 70% power consumption difference on a 1U server. They touched none of them.
Utter bullshit. That is the base frequency. The lowest frequency adjustable through the cpufreq standard P4 runtime frequency interface is 200MHz or 256MHz. If the base is 2GHz it is 256 (it is usually in 8 equal steps).
To see the frequencies:
- modprobe p4_clockmod
To enable dynamic scaling (via kernel)modprobe cpufreq_ondemand
- echo ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_gover nor
Watch eitherI just saw the article. While they did not run Winhoze, they still did not know how to run a power efficient server installation under Linux (or BSD for that matter). They ran it like Winhoze. They installed with the belief that the OS itself has no power control and all you need to tweak is BIOS. They tweaked all kinds of shit which has very little bearing on the system power consumption and performance. Classic case of pseudotweakers that have no clue whatsoever in how to set up a server.
Amazingly skimpy article. No effing data whatsoever.
I can bet a case of beer that this was run in a standard server config under Winhoze Server 2003. These are the results you more or less expect in that case.
If that is the case neither Opteron, nor Xeon utilise CPU frequency scaling as there is no OS support. If you use CPU frequency scaling under let's say current RHEL or Debian, the idle and IO efficiency picture tends to reverse because AMD is still not as good at this as Intel. In fact it not even supported on many server BIOSes/Motherboards.
As a result even if supported (and it usually isn't) AMD power utilisation with reduced frequency in idle is higher than that of a Xeon system which consumes nearly nothing when you slam it down to 250MHz. If the OS drops and ramps up the CPU frequency correctly Intel should win on idle and IO-only benchmarks.
Not that it matters in the slightest as AMD will cream it on most real life loads anyway due to better memory and IO bandwidth.
1. AFAIK someone in Seattle was looking into this more than 2 years ago. So there is nothing particularly innovative about it.
2. You do not need GPS. In fact you do not want GPS, because this makes the data individually identifiable and you have to prove that you are not doing something nefarious with it. Paging stats and handover stats from cells located near trunk routes will be a perfectly good replacement for this. All you need is to play correlation analysis vs actual traffic stats for a couple of days. You can make them more precise by looking at how the timing advance in GSM or power level in CDMA changes, but this is the same can of worms as GPS. You have to prove that privacy is not affected.
You are overestimating the amount of EM noise emitted by a motherboard outside the case. Very few computer components are noisy. The ones that are like some modems, wireless cards, etc feature additional individual shielding.
Designwise it is not very different from my first office computer back in 1993. That one had all of its components spread around screwed to a desk so you can easily unplug or plug any one of them and replace with the component you are testing (we ran a small hardware design shop that also did computer repairs). This was long before the days of windowed cases and was quite unusual for the time. I have seen all kinds of reactions: fascination, fear (will it spark), interest, etc.
I agree with your main point though. While you are no longer executed summarily on the spot for running with a backpack with cables sticking from it, that is not far off. If you run with such a backpack on the Tube any nearby dog unit officers hand will go straight towards the release latch (this has made me drop the speed and miss my train from Kings X on more than one occasion).
One comment: The webpage is dynamic. The .exe you see when clicking on the link is the final choice after exploits failed (and they did). If you we Joe Average who did not bother to pay for AV and did not update his machine since he bought it from Best Buy you would have been infected straight away long before that. No prompts.
All in all it will be a very fancy fuel bill is probably a more accurate description.
Exactly. If MSFT bough these votes under the table it would have been graft and USA has specific laws and some fairly serious sanctions regarding its own companies doing graft abroad. In this case everything is aboveboard and as correctly noted by many people this while despicable is legally allowed.
While at it, it will be worthwhile to look if MSFT did this somewhere under the table. This will allow applying USA laws on graft abroad.
Even if it does not, putting load on an a muscle that is suffering from severe inflammation will most likely damage it beyond repair. If you take the load off and let the inflammation subside the muscle has a fair chance of recovery in at least some cases. AFAIK, so far the pump bypass has shown to work in cases like this.
Her heart just needed a rest until it heals. There were a few cases here in the UK as well and implanting a parallel pump to assist is now considered a standard procedure in many cases where the transplant was the only option. Especially in kids and especially in cases where the heart has been damaged by inflammation. It is a safe bet really - if it heals good, if it does not the patient has a much better chance to survive until a suitable transplant is found. It is a pity that most pumps can take load only off some portions of the heart and not all of it (too much blood in the coffee subsystem to remember which).
You are almost correct.
First was outsourcing IT, then came SAAS to compensate for the failures of outsourced IT. Most shops that have retained their IT in house through the whole outsourcing boom of the last 8 years are not looking at SAAS. The reason is that if an inhouse IT department is still around, it is usually delivering on time and on target.
Now shops which have outsourced are a different matter. While most large IT outsourcing contracts have failed to deliver on all of their targets, the few that were delivered brought with them standard interfaces. These are much easier to rip out and replace with SAAS. And much more tempting.
I have had to migrate users off Outlook 2003 to Mozilla due to mailbox corruption so unfortunately MSFT has not fixed all bugs. No idea about 2007. In most cases, based on my extremely unscientific observations a user which has a 2G+ mailbox does not want Outlook anyway.
The entire sync/remote fs approach is fundamentally wrong for any place that has more than 2 people working on the same project/material.
What if you DO NOT WANT to resolve the conflict right away? What if the document that has been changed by two people is 200 pages long and the changes are substantial and you have 10 minutes to get the data and run? Even if you have the time there are plenty of other reasons why you may want to postpone the merge and review.
The only real solution is to keep documents in a revision control system. It has all that is necessary for this purpose - conflict resolution, versioning, branching, authentication, per-object authorisation, etc. Unfortunately, I have yet to see one that is capable of invoking application specific merge utilities (you cannot use bare diff on most document formats). This is what may be worth scripting though. It is not that hard to check the MIME type of the conflict file and invoke the correct editor based on MIME type and nearly all revision control systems have the hooks to do that.
There is no point implementing laptop backups before implementing a no-quota IMAP mail server. Exchange in its native mode does not count due to a number of corruption bugs which hit you once your inbox exceeds 2G (it should be OK as an IMAP server, bugs are mostly in Outlook).
As far as the user is concerned his primary concern for laptop data loss is email. So you have to back it up as a part of any backup solution. If you are storing email locally on the laptop and backing it up the backup will nearly always be corrupt due to file locking. Further to this, the financial, network and storage resource required to implement a laptop backup solution exceeds by far the cost of extra storage on the mail server. In addition to that if the email is stored centrally the backup size per laptop decreases straight away to become on the order of MBs instead of GBs for most users.
Offline most likely derives its origins from Coda which was designed to work for 100MB at most. It seems to inherit all of its problems when the data volumes become big. I have had to support an environment where people casually offlined 3-4GB documentation trees and it was falling over on regular basis.
Further to this, offline files has a number of fairly fundamental bugs in the actual implementation. It records both the IP and the name of the server somewhere when doing the offlining. As a result if the name (but not the drive) or the IP changes your entire offline tree goes south and stays offline. You can neither delete it nor reconnect it and the only way of dealing with this is either surgery to the network (aliasing IP addresses) until you reconnect. The only alternative is to rebuild the affected laptops from scratch.
It is not just Sony it is the technology itself. It is inherently dangerous and all manufacturers so far have had recalls and safety incidents. Sony is simply the biggest manufacturer of Li-polymer cells so we get to hear about it most.
They do not have to, but they do after they ended up being a total laughing stock in a courtroom 10+ years ago when the defence lawyer measured the judge travelling at 9mph while sitting on the bench. As a result the case got thrown out with prejudice.
From there on the staff which processes offences got trained not to try to prosecute if the offence is within the camera precision limit (which for classic Gatso with double photo verification is around 5%). This is where the 5% comes from. The new cameras have considerably better measurements. The speed averaging ones can probably measure better than a car speedo.
Coming back onto the Comcast topic I do not see what Comcast problem is. Their AUP are a classic case of tehcnical incompetence being compensated via admin measures.
1. Downstream they can police at the CMTS. I have yet to see one that cannot do QoS. Even the "Dear Cretins" wankers over here have shown capable of doing that.
2. Upstream - DOCSIS past 1.0 allows the CMTS to tell which station can speak at which particular moment. As a result any station can be throttled and controlled and made to comply to the policy. All it takes is to program the CMTS to start filling the MAPs with some meaningfull information and decrease the part which is "free for all".
3. On top of that they provision the modems and what they do not want to do on the CMTS can be done by simply tftping a new config onto the modem which is something the management system should be able to do in bulk per product category (you do not even need to click on individual stations).
So this is a classic case of "cable and brains do not mix".
Nope.
Current legal calibration requirements for EU (and AFAIK USA) are +0%/-7% (note the big fat zero for the + error). Manufacturing errors, calibration errors, etc all tend to follow a Gauss bell curve so manufacturers tend to calibrate to -3% and allow +/-3% error around that.
As far as the precision of measurement equipment if police is given high precision measurement equipment like the new speed averaging cameras in the UK they use it without any second doubt. These have sub-1% error because they measure the time it takes your car (recognised by number plate) to traverse 2-5 miles. As a result many drivers who expected the 10%/5 mph leeway usually applied to radar and laser cases where very unpleasantly surprised last winter during the roadworks on the M25 and M4 around london (not me, but I know a number of people who clocked 6+ points on their license in a matter of days).
This is not crippling admin accounts, it is making apps behave in an administrative manner when run by an admin.
Staroffice 3.x was a brilliant example. When you ran its setup as root it automatically went into global per-machine setup mode, while running it as Joe Average User made it run a workstation setup. In fact Office 6.x for Windows 95/NT behaved in a similar manner as well. If you ran it from a network install it behaved differently when run as admin vs when run as an average user.
I have no idea why developers stopped doing that. IMO, that was the right behaviour.