True, although in general, ADSL2+ gear is fairly common.
Yeah, unfortunately it only provides much benefit on good lines. From the charts i've seen if ADSL1 is only giving someone 3MBps ADSL2+ will barely make a difference and even READSL2 won't be earth shattering.
VDSL(2) is starting to become common.
Afaict VDSL only really makes sense as part of a FTTC installation and FTTC only makes economic sense for cabinets with high user counts. So if for whatever reason you are stuck on a low utilisation cabinet with a long or otherwise crappy line back to the exchange then you are SOL. You are also SOL if you have a long or crappy line from your house to the cabinet.
Don't get me wrong, overall things are improving but afaict the gap between the "haves" and the "have nots" is also widening and I feel it will continue to do so unless regulatory action is taken to stop it happening (whether such regulatory action should or should not be taken is of course a matter of opinion).
I also have my suspiscions that even if and when nearly everyone gets a connection that can handle "blueray quality" the providers will still pinch the pennies and make their HD product only "broadcast HD quality"
"terrible" it may be but for some people even in the "first world" it's still the reality. Particulally in the countryside but also in some urban and suburban areas that happened to get stuck with poor infrastructure for whatever reason.
The slowest subscription I can find here is 8Mbps (~USD 22/month).
What exactly do you mean when you say "8Mbps"?
At least here in the UK traditional exchange based ADSL is usually advertised "up to 8Mbps" (or sometimes more if the provider uses ADSL2+ gear) but what speed you actually get depends on the condition of your phone line and you don't get any discount if your line sucks. You can order multiple phone lines and run bonded ADSL services but the monthly costs of doing that stack up pretty quick since not only do you have to pay for all the lines, at least round here you either have to use a botique ISP that offers bonding or use a third party bonding service..
Many places get cable or some form of fiber based service (here in the UK it's usually FTTC, from what I read on/. the american telcos seem to be skipping FTTC and going straight to FTTH) but such things are still far from universal.
"fuses and breakers" normally only protect against overcurrent and maybe overvoltage BETWEEN conductors of the power supply. They can't protect against dangerous voltages between BOTH sides of the power supply and mains ground.
They could use an isolating power converter (and in the case of a USB charge port a USB isolator) inside the device but they aren't going to take the cost and efficiency hit of that when they've already put the required isolation measures in the power supply.
I cannot see how they possibly could get TUV and UL certification
Because the power supply is considered the safety isolation barrier.
If you have a phone from apple, samsung, htc, lenovo or another major global brand i'd think it's reasonable to assume the OEM charger is safe. It's not worth the risk of lawsuits and reputational damage for those companies to skimp on specifications and inspections to ensure that product from subcontractors meets those specifications. Sure they may have their HQ in the east but they have significant buisness assets in the west that can be targetted and they also have a reputation to think about.
The producers of the counterfiets and the sellers selling direct from china to gullible customers, market traders etc have no reputation to protect. So they can violate safety standards with impunity.
It's not at all uncommon in electronic devices to have the "ground" of electronics connected to the case or at least to touchable metal parts. If that "ground" becomes live due to a power supply fault then you have a live case.
Depending on power supply design the "ground" of the electronics may or may not be intentionally connected to mains ground. Generally in desktop PC power supplies it is connected while in laptop, phone and AV equipment supplies it generally isn't.
People like to dismiss syntactic sugar as unimportant but IMO it's the difference between code that is pleasant to read and write and code that is a PITA to read and write.
I wish some fork of java would happen and take off that adds back in the basic features sun left out. Stuff like properties*, user defined types without an implicit reference, unsigned numeric types, operator overloading, parameter pass by reference etc. Some of that is syntactic sugar, other parts not so much. Ideally these features would be done in a way that could somewhat work on existing VMs though some features would likely require VM enhancements to operate efficiently.
Every USB power brick i've seen has a floating output. That is in normal operation neither side of the output is connected to "mains ground".
So it's quite feasible in a failure scenario for one side of the output to be connected to mains live while the two sides of the output remain at 5V relative to each other. The phone would probablly be fine with this, someone holding the phone not so much.
This is even more true for modern "switching" supply designs which don't make use of a transformer to step down the voltage.
Actually they do. While you can design switchers without a transformer they provide basically no isolation at all and afaict are not used in mains power supply applications. Your typical switched mode mains power supply uses a high frequency transformer both as the reactive component in the switcher and an isolation device.
Still there are cetainly more components crossing the "safety boundary" than in a traditional transformer based power supply. If any of those components are skimped on you have a potentially dangerous device.
This means that a specific design may be totally safe in the US, but be a death trap elsewhere, or be totally safe overseas but totally unsafe in North America.
I don't really buy your argument there.
In the case of phone chargers, their mains connections are generally ungrounded (supposedly class 2 though the knockoffs certainly don't meet class 2 requirements) and unpolarised anyway so there is little the supply system can do to make them less safe. In the case of larger power supplies that are class 1 then you need to make sure there is a good ground but agin that applies wherever the power supply was originally sold. They still sell class 1 appliances in places that don't have proper grounding:(
The biggest issue is probablly that sometimes people fail to use the proper adaptor and hence that doesn't actually connect the earth even though one is available and required by the appliance.
I guess the higher voltage in some parts of the world may make a bit of a difference but I doubt it's significant overall with PSUs sold by a reputable vendor as universal voltage input.
I mean the cables aren't generally thick enough to carry enough 220V current to kill someone before they melt
BS it only takes relatively tiny ammounts of current (iirc tens to hundreds of milliamps depending on route through the body) to kill someone, far less than the currents used to charge a phone (~1A). The insulation may or may not hold out at 240V (I bet in most cases it would) but it doesn't really matter since the most plausable electrocution scenario is not current flowing down one charger wire and back through the other, it's current flowing through one charger wire, then through the persons body, then through some other return path (grounded metalwork of some sort).
So if the isolation barriers inside the charger (transformer, RFI suppression capacitors, general layout of stuff in the case) fail then it is very plausable to get an electric shock. Properly designed chargers are very carefully designed to minimise this risk. Counterfiets and cheap tat not so much.
5.5V DC certainly isn't going to kill someone.
Mostly true. The skin resistance is too high to let a dangerous current flow at such low voltages. With sub-skin electrodes though even voltages normally regarded as safe can become leathal.
Just looking for certification marks is not enough. A supplier who is prepared to ignore safety standards is probablly also prepared to fraudulantly apply certification marks.
If you wanted hundreds of chargers you might add a handful of extra to each batch and then subject them to destructive inspection and testing. If you wanted even larger quantities you might even send your own staff to inspect the factory. But none of that is really practical if you just want one charger for your own use.
About the best you can do is to stick to vendors who have a large presense in your country and therefore have a lot to lose if they get caught shipping dangerous products. Even then it's no gaurantee
USB is a standard that has grown over time both through additions to the core standard and through the introduction of side standards such as "on the go", "battery charging, power delivery " etc. According to the revision history in version 1.1 of the battery charging specification) the first version of the "battery charging" standard was released in 2007.
You could build a device that charged over USB before the "battery charging" standard but there was no official way to do a dumb charger (you could in theory build a charger with a full USB host in it but I don't think anyone did). USB devices are not supposed to draw any significant power pre-enumeration and there was no standard way to indicate a dumb charging port. So vendors who wanted to charge over USB did one of two things, either they made their devices ignore the USB power rules and just charge whenever they saw 5V or they invented vendor specific ways of indicating a dumb charging port.
Then the USB battery charging spec came along and standardised how to indicate a dumb charging port, how to indicate a downstream port with extra power available for charging etc.
More recently there has been another new spec "USB power delivery" which allows delivery of much higher ammounts of power (enough to power/charge a laptop) down a "USB" connection but afaict it's rarely used..
Not really, the fact is with bitcoin having climed so fast there isn't really much you could invest it in that would have performed better than just holding the bitcoins. I guess you could make bitcoin denominated loans but the combination of lack of effective regulation and the aforementioned rise in bitcoins value would probablly lead to an extremely high default rate on such loans.
The question is whether placing a "pledge" in a crowdfunding campain and then having the campaign succeed is a pre-order or a donation.
Kickstarter now have the following in their terms (iirc they didn't initially)
"Project Creators are required to fulfill all rewards of their successful fundraising campaigns or refund any Backer whose reward they do not or cannot fulfill."
Indigogo has a similar statement
"You agree:
1. All Perks must be lawful and otherwise comply with this Agreement.
2. To fulfill all Perks and to respond promptly to all questions and comments regarding Perks. If you are unable to fulfill a Perk, you will work with the Contributor(s) to reach a mutually satisfactory resolution which may include, without limitation, issuing a refund promptly."
So it seems pretty clear to me that on the major crowdfunding sites making a pledge, selecting a reward and having that pledge accepted into a successful campaign is a pre-order not a donation.
There are two different surface tables the rt and the pro
IMO the surface pro is quite an attractive device for some uses. It's a regular Intel PC running proper windows so you can run whatever windows apps you like, you can join it to a domain and so-on (heck you can even run linux on it if you want) and while it's thicker than most arm tablets it's very thin by tablet PC standards.
OTOH with windows RT and the surface RT (which seems to be the only windows rt device to actually make it to market) MS went to all that effort of porting windows to arm only to cripple it. No ability to join domains, no approved way* to run third party non-metro apps (even if the third party can be bothered to recompile them). Pushed intp to using an appstore to get apps (AIUI the only way to install apps outside of the appstore is to register as a developer). Parts off office ported but others not. Uncommon enough platform that it's long term future is far from assured. Locked bootloader to prevent you installing an alternate OS. If you are really one of those users who really needs word/excel and yet you doesn't need any other windows apps and doesn't need domain functionality it may appeal but I think that is a fairly small niche.
I do think it's quite likely that the bad PR for the RT is rubbing off on the pro. That is inevitable when a company chooses to market two very different products under very similar names.
* There is a hack to enable running third party non-metro apps on RT but noone knows how long that hack will keep working in the face of updates.
Afaict "cloud" services can be divided into roughly three categories.
1: infrastructure as a service 2: software as a service with publically available software (e.g. exchange, mysql, apache, whatever). 3: software as a service with vendor specific software (e.g. google apps for your domain).
Each has different risks and benefits
With the first category the cloud provider provides you with the ability to quickly and easilly spool up instances (effectively temporary VMs), networks, storage etc but it's still your problem to deal with what happens when an instance dies and to make sure your VMs and storage are geographically spread (amazon handles this through "availability zones") or better still spread among multiple providers. With the second two categories you would expect the provider to handle disaster recovery but it's difficult to know for sure whether they are really doing what they say they are.
All types have the risk of something bad happening to the provider. This risk is particually bad with the third category because it's hard to diversify or keep useful backups.
The difference is I can download the source for most Linux apps.
The other difference is that MS crippled their arm port of windows so that all non-ms apps had to use the UI/libraries formally known as metro rather than the traditional windows UI and APIs. So rather than simply recompiling for arm developers (whether open or closed source) have to reegineer their apps for metro and then distribute them through microsofts store (where MS takes a cut of course).
Yes I'm aware there is a hack to bypass the crippling but a hack that could go away at any time is not something to base a product on.
Afaict there are basically two real problems with overwriting.
1: drives remap sectors that are detected as troublesome (often before they go completely unreadable). This makes it very hard to ensure that you really hit every sector with your overwrite pass. Some drives have a built in secure erase feature that should solve this but then you are relying on the drive vendor to have implemented it correctly. 2: Even if you have decided that the risk from remapped sectors is tolerable you have to be EXTREMELY careful to make sure only successfully wiped drives get released and that drives which cannot be cleanly wiped get diverted to physical destruction.
Even assming wiping carefully costs the same as physical destruction if a failure to wipe costs you $200000 and the value of a wiped hard drive is $20 then one leak in TEN THOUSAND drives processed is potentially enough to destory the benefits.
You would have to define how the TCP checksum (which covers network level source and destination so that packages whose source/destination get corrupted don't get accidently accepted on another connection) should be done when running TCP over your alternate protocol.
From a security perspective send encrypted data between two endpoints at a rate independent of what you were using the connection for in fixed size chunks. That way the attacker would have no way to know when and how much data you were sending without cracking the encryption. In this context compressing before encyrpting would not cause any security problems.
In the real world though this doesn't work for most people. They want to be able to use whatever bandwidth they have to communicate with who they want without having to set up a fixed bandwith link first or waste bandwidth during idle time. So In reality we mostly encrypt variable sized chunks provided at a varying rate. The encryption hides the content of the chunks but not the size of the chunks.
Compressing the content of the chunk before encrypting* causes the content of the chunk to affect it's size and in certain contexts that dependence of size on content can allow the attacker to infer things about the communication that they would not have been able to infer in the absense of compression. An AC has already posted one example of this (causing the client to generate chunks that contain a mixture of secret data and attacker supplied data). Another example is VOIP where the size of compressed packets are often strongly correlated with what sylable is being said.
They are both endurance races. The name 24 hours of lemons is clearly a play on the name 24 hours of le-mans (which is prounounced le mons).
Other than that there is no relation between them. They are basically opposite ends of the endurance racing scale. The 24 hours of Le Mons is a race where you get the top endurance cars on which big teams have spent lots of money compete with each other. The 24 hours of Lemons is a race where people with a bit of cash and some time to spare can have some fun and maybe even win.
Usually in such systems the password is optional. Even if one is present it may not be strong enough to present much of a barrier to brute force and even if it is strong enough to stand up to brute force it may be possible to obtain it through either coercion (make him sit in a cell till he reveals the password) or subterfuge (put a keylogger on his machine).
If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, and the browser defaulted into plain text view (no ssl icon or indication of security) then the user does not need any extra warning.
When I make a request to a https url I expect the information contained within that request (parts of the url other than the hostname, post data if any, cookies if any) to be sent over an encrypted and authenticated link. By the time I can "look for the padlock" the potentially private information has already been sent. So if the connection cannot be authenticated the browser MUST warn me* BEFORE it continues with the request.
I support systems that allow encrypted but unauthenticated connections to be presented to the user in the same way as unencrypted connections but to maintain current security the https url scheme MUST NOT be used for such connections. Either a new url scheme should be allocated for such connections or a protocol should be used that can share the http url scheme.
This is already the default behavior if you try to use https on a website that does not support it like slashdot - the browser defaults to plain text view without any warning, any error.
If you try to go to a website that doesn't support https with a https url then your request will just time out . An attacker can't simply block secure connections to force you to unknowingly use unsecure ones.
slashdot DOES support https, it just happens to serve up a redirect to plain http. Blindly serving up redirects from https to plain htttp is risky as it can reveal potentially private information in the url but as far as the protocol is concerned it's/.'s call to make that descision (just as it's/.'s call to take the information you posted over https and post it for the public to see) and/.'s identity was verified** before they got the chance to make that descision.
* Of course I can ignore the warning, there is only so much you can do to protect a careless or incompetant user from theselves. ** To the extent that the CA model can verify certificate ownership.
You need them _regardless_ how you generate your power. The amount of reserves you need is determined by a) your total energy production, typically roughly 7% - 10% b) the amount of energy you like to sell dynamically at the market
c) the size of your largest individual power plant compared to the size of your grid d) how much correlation you expect between downtime of different power plants. e) how well connected your grid is.
If you put a large power plant on a small grid then your reserves need to be big enough to cover it's failure but the european and american grids are so big it's really not an issue for them.
If you have a source where downtime between different plants is likely to be strongly correlated due to where their power is coming from (e.g. wind stops generating if the wind stops blowing, solar stops generating significant power if there are thick clouds) then you need to consider the affects of that corrolation which will increase your reserve requirements. One proposed soloution to this is to spread solar/wind over a massive grid on the grounds that it's usually sunny/windy somewhere but this requires that your grid is well connected enough to actually take the power where it is needed.
Slashdot Mirror
Most of this I think goes back to me not really seeing "primitive" as mattering much once you aren't going for mimicking the CPU anyway.
"primitive" wouldn't matter so much if java had operator overloading and user defined value types.
But it doesn't, so any custom type you create will be more painful to use and will create more load on the memory manager.
True, although in general, ADSL2+ gear is fairly common.
Yeah, unfortunately it only provides much benefit on good lines. From the charts i've seen if ADSL1 is only giving someone 3MBps ADSL2+ will barely make a difference and even READSL2 won't be earth shattering.
VDSL(2) is starting to become common.
Afaict VDSL only really makes sense as part of a FTTC installation and FTTC only makes economic sense for cabinets with high user counts. So if for whatever reason you are stuck on a low utilisation cabinet with a long or otherwise crappy line back to the exchange then you are SOL. You are also SOL if you have a long or crappy line from your house to the cabinet.
Don't get me wrong, overall things are improving but afaict the gap between the "haves" and the "have nots" is also widening and I feel it will continue to do so unless regulatory action is taken to stop it happening (whether such regulatory action should or should not be taken is of course a matter of opinion).
I also have my suspiscions that even if and when nearly everyone gets a connection that can handle "blueray quality" the providers will still pinch the pennies and make their HD product only "broadcast HD quality"
That is absolutely terrible.
"terrible" it may be but for some people even in the "first world" it's still the reality. Particulally in the countryside but also in some urban and suburban areas that happened to get stuck with poor infrastructure for whatever reason.
The slowest subscription I can find here is 8Mbps (~USD 22/month).
What exactly do you mean when you say "8Mbps"?
At least here in the UK traditional exchange based ADSL is usually advertised "up to 8Mbps" (or sometimes more if the provider uses ADSL2+ gear) but what speed you actually get depends on the condition of your phone line and you don't get any discount if your line sucks. You can order multiple phone lines and run bonded ADSL services but the monthly costs of doing that stack up pretty quick since not only do you have to pay for all the lines, at least round here you either have to use a botique ISP that offers bonding or use a third party bonding service..
Many places get cable or some form of fiber based service (here in the UK it's usually FTTC, from what I read on /. the american telcos seem to be skipping FTTC and going straight to FTTH) but such things are still far from universal.
Heard about fuses and breakers?
"fuses and breakers" normally only protect against overcurrent and maybe overvoltage BETWEEN conductors of the power supply. They can't protect against dangerous voltages between BOTH sides of the power supply and mains ground.
They could use an isolating power converter (and in the case of a USB charge port a USB isolator) inside the device but they aren't going to take the cost and efficiency hit of that when they've already put the required isolation measures in the power supply.
I cannot see how they possibly could get TUV and UL certification
Because the power supply is considered the safety isolation barrier.
If you have a phone from apple, samsung, htc, lenovo or another major global brand i'd think it's reasonable to assume the OEM charger is safe. It's not worth the risk of lawsuits and reputational damage for those companies to skimp on specifications and inspections to ensure that product from subcontractors meets those specifications. Sure they may have their HQ in the east but they have significant buisness assets in the west that can be targetted and they also have a reputation to think about.
The producers of the counterfiets and the sellers selling direct from china to gullible customers, market traders etc have no reputation to protect. So they can violate safety standards with impunity.
It's not at all uncommon in electronic devices to have the "ground" of electronics connected to the case or at least to touchable metal parts. If that "ground" becomes live due to a power supply fault then you have a live case.
Depending on power supply design the "ground" of the electronics may or may not be intentionally connected to mains ground. Generally in desktop PC power supplies it is connected while in laptop, phone and AV equipment supplies it generally isn't.
People like to dismiss syntactic sugar as unimportant but IMO it's the difference between code that is pleasant to read and write and code that is a PITA to read and write.
I wish some fork of java would happen and take off that adds back in the basic features sun left out. Stuff like properties*, user defined types without an implicit reference, unsigned numeric types, operator overloading, parameter pass by reference etc. Some of that is syntactic sugar, other parts not so much. Ideally these features would be done in a way that could somewhat work on existing VMs though some features would likely require VM enhancements to operate efficiently.
Unfortunately MS has already taken the name J++ :(
* No that javabeans shit doesn't count.
Every USB power brick i've seen has a floating output. That is in normal operation neither side of the output is connected to "mains ground".
So it's quite feasible in a failure scenario for one side of the output to be connected to mains live while the two sides of the output remain at 5V relative to each other. The phone would probablly be fine with this, someone holding the phone not so much.
This is even more true for modern "switching" supply designs which don't make use of a transformer to step down the voltage.
Actually they do. While you can design switchers without a transformer they provide basically no isolation at all and afaict are not used in mains power supply applications. Your typical switched mode mains power supply uses a high frequency transformer both as the reactive component in the switcher and an isolation device.
Still there are cetainly more components crossing the "safety boundary" than in a traditional transformer based power supply. If any of those components are skimped on you have a potentially dangerous device.
This means that a specific design may be totally safe in the US, but be a death trap elsewhere, or be totally safe overseas but totally unsafe in North America.
I don't really buy your argument there.
In the case of phone chargers, their mains connections are generally ungrounded (supposedly class 2 though the knockoffs certainly don't meet class 2 requirements) and unpolarised anyway so there is little the supply system can do to make them less safe. In the case of larger power supplies that are class 1 then you need to make sure there is a good ground but agin that applies wherever the power supply was originally sold. They still sell class 1 appliances in places that don't have proper grounding :(
The biggest issue is probablly that sometimes people fail to use the proper adaptor and hence that doesn't actually connect the earth even though one is available and required by the appliance.
I guess the higher voltage in some parts of the world may make a bit of a difference but I doubt it's significant overall with PSUs sold by a reputable vendor as universal voltage input.
I mean the cables aren't generally thick enough to carry enough 220V current to kill someone before they melt
BS it only takes relatively tiny ammounts of current (iirc tens to hundreds of milliamps depending on route through the body) to kill someone, far less than the currents used to charge a phone (~1A). The insulation may or may not hold out at 240V (I bet in most cases it would) but it doesn't really matter since the most plausable electrocution scenario is not current flowing down one charger wire and back through the other, it's current flowing through one charger wire, then through the persons body, then through some other return path (grounded metalwork of some sort).
So if the isolation barriers inside the charger (transformer, RFI suppression capacitors, general layout of stuff in the case) fail then it is very plausable to get an electric shock. Properly designed chargers are very carefully designed to minimise this risk. Counterfiets and cheap tat not so much.
5.5V DC certainly isn't going to kill someone.
Mostly true. The skin resistance is too high to let a dangerous current flow at such low voltages. With sub-skin electrodes though even voltages normally regarded as safe can become leathal.
Just looking for certification marks is not enough. A supplier who is prepared to ignore safety standards is probablly also prepared to fraudulantly apply certification marks.
If you wanted hundreds of chargers you might add a handful of extra to each batch and then subject them to destructive inspection and testing. If you wanted even larger quantities you might even send your own staff to inspect the factory. But none of that is really practical if you just want one charger for your own use.
About the best you can do is to stick to vendors who have a large presense in your country and therefore have a lot to lose if they get caught shipping dangerous products. Even then it's no gaurantee
USB is a standard that has grown over time both through additions to the core standard and through the introduction of side standards such as "on the go", "battery charging, power delivery " etc. According to the revision history in version 1.1 of the battery charging specification) the first version of the "battery charging" standard was released in 2007.
You could build a device that charged over USB before the "battery charging" standard but there was no official way to do a dumb charger (you could in theory build a charger with a full USB host in it but I don't think anyone did). USB devices are not supposed to draw any significant power pre-enumeration and there was no standard way to indicate a dumb charging port. So vendors who wanted to charge over USB did one of two things, either they made their devices ignore the USB power rules and just charge whenever they saw 5V or they invented vendor specific ways of indicating a dumb charging port.
Then the USB battery charging spec came along and standardised how to indicate a dumb charging port, how to indicate a downstream port with extra power available for charging etc.
More recently there has been another new spec "USB power delivery" which allows delivery of much higher ammounts of power (enough to power/charge a laptop) down a "USB" connection but afaict it's rarely used..
Not really, the fact is with bitcoin having climed so fast there isn't really much you could invest it in that would have performed better than just holding the bitcoins. I guess you could make bitcoin denominated loans but the combination of lack of effective regulation and the aforementioned rise in bitcoins value would probablly lead to an extremely high default rate on such loans.
The question is whether placing a "pledge" in a crowdfunding campain and then having the campaign succeed is a pre-order or a donation.
Kickstarter now have the following in their terms (iirc they didn't initially)
"Project Creators are required to fulfill all rewards of their successful fundraising campaigns or refund any Backer whose reward they do not or cannot fulfill."
Indigogo has a similar statement
"You agree:
1. All Perks must be lawful and otherwise comply with this Agreement.
2. To fulfill all Perks and to respond promptly to all questions and comments regarding Perks. If you are unable to fulfill a Perk, you will work with the Contributor(s) to reach a mutually satisfactory resolution which may include, without limitation, issuing a refund promptly."
So it seems pretty clear to me that on the major crowdfunding sites making a pledge, selecting a reward and having that pledge accepted into a successful campaign is a pre-order not a donation.
There are two different surface tables the rt and the pro
IMO the surface pro is quite an attractive device for some uses. It's a regular Intel PC running proper windows so you can run whatever windows apps you like, you can join it to a domain and so-on (heck you can even run linux on it if you want) and while it's thicker than most arm tablets it's very thin by tablet PC standards.
OTOH with windows RT and the surface RT (which seems to be the only windows rt device to actually make it to market) MS went to all that effort of porting windows to arm only to cripple it. No ability to join domains, no approved way* to run third party non-metro apps (even if the third party can be bothered to recompile them). Pushed intp to using an appstore to get apps (AIUI the only way to install apps outside of the appstore is to register as a developer). Parts off office ported but others not. Uncommon enough platform that it's long term future is far from assured. Locked bootloader to prevent you installing an alternate OS. If you are really one of those users who really needs word/excel and yet you doesn't need any other windows apps and doesn't need domain functionality it may appeal but I think that is a fairly small niche.
I do think it's quite likely that the bad PR for the RT is rubbing off on the pro. That is inevitable when a company chooses to market two very different products under very similar names.
* There is a hack to enable running third party non-metro apps on RT but noone knows how long that hack will keep working in the face of updates.
Afaict "cloud" services can be divided into roughly three categories.
1: infrastructure as a service
2: software as a service with publically available software (e.g. exchange, mysql, apache, whatever).
3: software as a service with vendor specific software (e.g. google apps for your domain).
Each has different risks and benefits
With the first category the cloud provider provides you with the ability to quickly and easilly spool up instances (effectively temporary VMs), networks, storage etc but it's still your problem to deal with what happens when an instance dies and to make sure your VMs and storage are geographically spread (amazon handles this through "availability zones") or better still spread among multiple providers. With the second two categories you would expect the provider to handle disaster recovery but it's difficult to know for sure whether they are really doing what they say they are.
All types have the risk of something bad happening to the provider. This risk is particually bad with the third category because it's hard to diversify or keep useful backups.
The difference is I can download the source for most Linux apps.
The other difference is that MS crippled their arm port of windows so that all non-ms apps had to use the UI/libraries formally known as metro rather than the traditional windows UI and APIs. So rather than simply recompiling for arm developers (whether open or closed source) have to reegineer their apps for metro and then distribute them through microsofts store (where MS takes a cut of course).
Yes I'm aware there is a hack to bypass the crippling but a hack that could go away at any time is not something to base a product on.
Afaict there are basically two real problems with overwriting.
1: drives remap sectors that are detected as troublesome (often before they go completely unreadable). This makes it very hard to ensure that you really hit every sector with your overwrite pass. Some drives have a built in secure erase feature that should solve this but then you are relying on the drive vendor to have implemented it correctly.
2: Even if you have decided that the risk from remapped sectors is tolerable you have to be EXTREMELY careful to make sure only successfully wiped drives get released and that drives which cannot be cleanly wiped get diverted to physical destruction.
Even assming wiping carefully costs the same as physical destruction if a failure to wipe costs you $200000 and the value of a wiped hard drive is $20 then one leak in TEN THOUSAND drives processed is potentially enough to destory the benefits.
IIRC the NES CPU lacks some features that the regular 6502 has (BCD mode comes to mind).
You would have to define how the TCP checksum (which covers network level source and destination so that packages whose source/destination get corrupted don't get accidently accepted on another connection) should be done when running TCP over your alternate protocol.
But other than that minor detail yes.
From a security perspective send encrypted data between two endpoints at a rate independent of what you were using the connection for in fixed size chunks. That way the attacker would have no way to know when and how much data you were sending without cracking the encryption. In this context compressing before encyrpting would not cause any security problems.
In the real world though this doesn't work for most people. They want to be able to use whatever bandwidth they have to communicate with who they want without having to set up a fixed bandwith link first or waste bandwidth during idle time. So In reality we mostly encrypt variable sized chunks provided at a varying rate. The encryption hides the content of the chunks but not the size of the chunks.
Compressing the content of the chunk before encrypting* causes the content of the chunk to affect it's size and in certain contexts that dependence of size on content can allow the attacker to infer things about the communication that they would not have been able to infer in the absense of compression. An AC has already posted one example of this (causing the client to generate chunks that contain a mixture of secret data and attacker supplied data). Another example is VOIP where the size of compressed packets are often strongly correlated with what sylable is being said.
* Compressing after encyrping would be pointless.
is it related to 24 Hours of Le Mans?
They are both endurance races.
The name 24 hours of lemons is clearly a play on the name 24 hours of le-mans (which is prounounced le mons).
Other than that there is no relation between them. They are basically opposite ends of the endurance racing scale. The 24 hours of Le Mons is a race where you get the top endurance cars on which big teams have spent lots of money compete with each other. The 24 hours of Lemons is a race where people with a bit of cash and some time to spare can have some fun and maybe even win.
Usually in such systems the password is optional. Even if one is present it may not be strong enough to present much of a barrier to brute force and even if it is strong enough to stand up to brute force it may be possible to obtain it through either coercion (make him sit in a cell till he reveals the password) or subterfuge (put a keylogger on his machine).
If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, and the browser defaulted into plain text view (no ssl icon or indication of security) then the user does not need any extra warning.
When I make a request to a https url I expect the information contained within that request (parts of the url other than the hostname, post data if any, cookies if any) to be sent over an encrypted and authenticated link. By the time I can "look for the padlock" the potentially private information has already been sent. So if the connection cannot be authenticated the browser MUST warn me* BEFORE it continues with the request.
I support systems that allow encrypted but unauthenticated connections to be presented to the user in the same way as unencrypted connections but to maintain current security the https url scheme MUST NOT be used for such connections. Either a new url scheme should be allocated for such connections or a protocol should be used that can share the http url scheme.
This is already the default behavior if you try to use https on a website that does not support it like slashdot - the browser defaults to plain text view without any warning, any error.
If you try to go to a website that doesn't support https with a https url then your request will just time out . An attacker can't simply block secure connections to force you to unknowingly use unsecure ones.
slashdot DOES support https, it just happens to serve up a redirect to plain http. Blindly serving up redirects from https to plain htttp is risky as it can reveal potentially private information in the url but as far as the protocol is concerned it's /.'s call to make that descision (just as it's /.'s call to take the information you posted over https and post it for the public to see) and /.'s identity was verified** before they got the chance to make that descision.
* Of course I can ignore the warning, there is only so much you can do to protect a careless or incompetant user from theselves.
** To the extent that the CA model can verify certificate ownership.
You need them _regardless_ how you generate your power. The amount of reserves you need is determined by
a) your total energy production, typically roughly 7% - 10%
b) the amount of energy you like to sell dynamically at the market
c) the size of your largest individual power plant compared to the size of your grid
d) how much correlation you expect between downtime of different power plants.
e) how well connected your grid is.
If you put a large power plant on a small grid then your reserves need to be big enough to cover it's failure but the european and american grids are so big it's really not an issue for them.
If you have a source where downtime between different plants is likely to be strongly correlated due to where their power is coming from (e.g. wind stops generating if the wind stops blowing, solar stops generating significant power if there are thick clouds) then you need to consider the affects of that corrolation which will increase your reserve requirements. One proposed soloution to this is to spread solar/wind over a massive grid on the grounds that it's usually sunny/windy somewhere but this requires that your grid is well connected enough to actually take the power where it is needed.