95 and 98 use a graphical installer that ran under windows for the early stages of install. You could either run the first part of the installer under your existing version of windows (if upgrading) or if you ran it from dos it would load "mini windows" which afacit is a very stripped down win3.x. IIRC the installer required the hard drive to be already paritioned and formatted as it would use it for temporary storage space. After the first reboot the system was then running windows 9x as it sorted out the final details. The boot floppies included with some copies of windows 9x and the later bootable CDs loaded the corresponding version of DOS (win9x came with it's own version of DOS)
2K and XP use a textmode installer for the early stages of install which I'm pretty sure is based on the NT kernel but without any of the win32 stuff loaded. This can be seen in things like the fact it needs a windows driver to see your hard drive (rather than being able to see any hard drive the BIOS can see). It would then reboot into the system it had partially installed to finish things off.
Vista and later use a graphical installer, which is based on winPE which is a stripped down version of modern windows.
For webmail, what would be wrong with: encrypt/decrypt via client side javascript,
The big problem is that the website can change the client side javascript that it sends to a version designed to send the key to the server. If the version designed to grab the key is only sent once per user and only to users of interest it is unlikely that users will notice this behaviour.
Find me a bank or online retailer that allows financial accounting data to be submitted over insecure connections instead of SSL. I can wait.
It doesn't matter what the bank or retailer gets the data over, it matters what your phone sends it over. All too often people start browsing from an insecure entry point and only later move to a secure part of a site. This allows the MITM to change links or redirects in the insecure part and hence get the user to either enter their authentication details unencrypted or get them to enter them encrypted but to a domain the attacker controls (and therefore has a "legitimate" certificate for).
Plus ssl isn't as secure as people might like to think, for example apparently there were CAs out there who would still sign certs using md5 after md5 collision attacks became feasible allowing attackers to get themselves a cert with CA powers that was trusted by browsers*. There have also been recent attacks on SSL itself, and attacks on the way browsers combine compression with ssl.
Having a service hosted in one country but with admins from another seems like the worst of both worlds since either the government of the country the admins reside in or the government of the country the servers reside in could attack things.
Apple is strongly pushing locked down "curated computing" devices where you have little choice* but to buy all your apps from their appstore
Google is providing devices where there are officially allowed (i.e. unlikely to dissapear) ways to unlock the bootloader and do whatever you like to the device and are releasing the sourcecode for their OS (minus a handful of third party blobs). OTOH they are also pushing software as a service and all the crap that brings with it (features you need can dissapear at any time and you have no recourse, your data is far more readilly available to the spooks than it would be on your own machines). Then there is the whole fiasco of replacing talk (open federated platform) with hangouts (closed platform).
* You can register as a developer for an annual fee or you can hack the device in ways that are unsupported and may become unusable at any time.
The reason it wouldn't happen is because there's no motivation to do it, not because it's impossible. No one cares about hopelessly obsolete media.
Another problem is that PC hardware is so diverse, In the last debian release to support floppy initiated installs (etch) it had a floppy for loading the kernel, a second floppy for the core of the installer and then another two floppies for network drivers (there was also a floppy of CD drivers but generally you wouldn't use both the CD drivers and the network drivers floppies). IIRC in testing/unstable immediately before support was dropped they were up to three floppies of network drivers.
Nothing on what CPU they actually plan to use, this is a fairly low volume device so it won't be something specific for them and it will have to fit within the power envelope of a phone. So expect whatever CPU it ends up with to be at best comparable to the best other phones available at the time it launches.
The ram is nice but there are already phones shipping with 2GB, I doubt it will be all that long before we see phones with 4GB on the market anyway. Same can probablly be said for storage. Predicted screen resoloution is actually lower than one of the CURRENT phones they are comparing it to.
The software innovations may or may not be cool but I see no reason they can't be done on an existing hardware platform.
Overall it's a fair chunk of cash to pay in advance for something that is likely to be at best marginally better and quite possiblly worse than other phones available in early-mid 2014.
I see several advantages to flash on the drive over system ram for this application.
Firstly flash has a lower cost per gigabyte than ram does by quite a substantial margin
Secondly laptops are quite limited in ram. It's only recently that 16GB has become possible at anything like a reasonable price and beyond that is just out of the question in normal sized laptops at the momemnt. If you have an older laptop or want an ultraportable then your ram options are likely to be even more limited.
Thirdly system ram based caches are volatile, reboot your system or have an app run away with memory allocation and boom goes your system ram based cache whereas a cache built into the drive
Fourthly a flash based cache can store newly written data even when the power fails meaning that flushes don't need to hit the platter. However this advantage may be dificult to realise in practice because of flash wear concerns.
1: After a new build or reimage (remember they are talking about office users here and offices do reimage from time to time) how long will it take the system to settle down and work out what should be on hdd and what should be on flash. There is obviously a compromise here between speed of adapting to a changed usage pattern and wear on the flash. 2: what will happen with writes? large SSDs spread them over a large area of flash to get decent life. Will writes be forced to the hard drive or will they rapidly wear the small ammount of flash. 3: for the ammount of storage a typical office user needs will they really be all that much cheaper than just fitting a SSD and avoiding the fragility of a mechanical hard drive and the unpredictability of a caching soloution.
Have you read kickstarter's or indigogo's terms lately? both obligate those running campaigns to provide or refund any rewards if the campaign is funded.
Now of course there is still some risk for the consumers, for example there is the risk that the legal entity running the campaign could go bankrupt. There is also the risk that you will get a reward that technically fits the promise but is actually a peice of shit. Is that risk worth it? it depends on the campaign (personally i'm going to say no in this case but I can see how others could have other opinions).
The computing power in the bitcoin pool today is 8 times [qz.com] the computing power of the top 500 fastest super computers in the world combined.
That article stinks of BS. It claims "The bitcoin network also qualifies as the world’s first exascale computer, meaning it’s capable of a quintillion floating point calculations per second.". The source seems to trace back to http://www.bitcoinwatch.com/ who quote a "Network Hashrate PetaFLOPS" but don't seem to indicate how they come up with that number.
AIUI bitcoin mining is a purely integer process. My guess is they looked at the performance of a typica GPU at a floating point benchmark and at bitcoin mining and came up with a scale factor. That may have made sense when mining was GPU dominated but it makes a lot less sense with FPGAs and ASICs coming in quickly.
If you are serious about doing a 51% attack you certainly wouldn't be doing it on general purpose CPUs nowadays and probablly wouldn't be doing it on GPUs. ASICs would be the way to go but you'd need a way to get a lot of them quickly.
Probablly the most effective approach for a government trying to do the "51% attack" would be to seize the designs from one of the major bitcoin asic vendors and then use their own contractors to mass produce them.
Lets run some numbers, current total network hashrate is 307.67 terahashes per second. Butterflylabs is a US company who retail asic miners at $22484 for 500GH/s. Lets assume the US governement can get butterflylabs plans and find a contractor who will produce them for the same ammount that butterflylabs retail them for. Based on that assumption it would cost about 14 million dollars to match the current total network hashrate.
Of course it would take time to build the hashing setup so lets say they shoot for ten times the current total network hashrate to give themselves some breathing room. That would be 140 million dollars.
The motivation behind Bitcoin wasn't to create a currency that government would choose not to regulate; it was to create one that government could not regulate.
Unfortunately while bitcoins design makes it difficult to regulate there are still a few options governments have.
One option is the."51% attack". If a party has control of more hashing power than the rest of the network put together then they can arbitrarily block transactions they don't like from properly confirming. I'm quite sure if the US goverment chose to do so they could do this, it's a question of whether they would consider it worth committing those resources.
Another option is to go after the exchanges and/or regard handling large ammounts of bitcoin or large transfers to/from foreign bitcoin exchanges as being suspicious behaviour just as they regard handling large amounts of cash as being suspicious behaviour.
Yet another option would be to simply pass a law making bitcoin illegal to posess.
I've never personally had one "fail" as such but i've seen mysterious corruption where files are no longer accessible or no longer contain what they should contain far more often than i've seen such things on hard drives.
My feeling is that the wear leveling algorithms are not handling some corner cases (such as powerloss) correctly.
Suppose I as a brit use a service in australia. My packets will either go via the US or via mainland europe and the far east. The return packets may or may not come back by the same route.
If I use an encryption system that is resistant to MITM then anyone wanting to steal the data will have to be in either britan (targetting me) or australia (targetting the service). If I don't use encryption then the person wanting to steal the data can pick it up anywhere along the line.
While it's possible for governments to send agents to go and beat people up outside of their territory it's politically expensive to do so. So it's usually only done in extreme cases.
The problem is that most people only read the manual when they discover something is wrong and there is no immediately obvious problem with the results of these scans. The problem only gets noticed much later when someone tries to work with the scanned information and discovers that it is readable but doesn't make sense.
I also notice that the manual says that the other options give larger files with better image quality but does not state clearly whether compression algorithms that can cause character substitution are disabled in those modes or whether substitution is just less likely due to higher quality settings.
When a development of a technology introduces new failure modes great care needs to be taken to inform users of those modes. Just burying it deep in a manual that people only read when things go wrong is not sufficient.
That helps to a point but if it becomes too common spammers will just design their spambots to work with whatever delays are commonly used. It means keeping a little more state in the spambot.
and also cache submitted forms from an IP address to prevent duplicates.
That helps to a point but if it becomes too common website spammers will just add message mangling just like email spammers do today.
You can also implement a 50 message per day limit, and reduce as needed to stop spammers.
50 messages per what per day?
50 messages per IP per day would cause a lot of pain to users stuck behind large scale NATs and probablly wouldn't impede the spammers too much, they often have an army of IPs under their control. 50 messages per user account per day would just cause the spammers to register lots of user accounts.
The problem with a lot of "clever" soloutions to spam is they work fine as long as their userbase is too small for the spammers to care. Once their userbase becomes big enough though the spammers will start putting real effort into attacking them.
While that is true in a sense it is a gross oversimplification.
Oil is expensive compared to coal and natural gas. So oil based fuels are mostly used where the advantages of an easilly portable liquid fuel outweighs the higher cost, e.g. transportation and some industrial uses. Afaict most electricity in the US comes from coal, nuclear and natural gas. So new nuclear power plants would be mostly displacing coal and gas not oil.
Does this mater? it depends on what you consider important. If your aim is to reduce greenhouse gas emmisions then switching electricity generation from coal and gas to nuclear is a big win.
OTOH If you aim is to get away from relying on imported oil oil then building nuclear power plants won't help much by itself, you also need to either develop coal to liquids and gas to liquids conversion facilities or convince current users of liquid fuels to switch to electricity.
Indeed, I'd like to submit that the only thing that actually needs a static-for-ever address is a DNS server. And that for everything else, we have DNS.
Just switching an IP address without warning or providing a period of paralell running will cause downtime at best and people getting sent to the wrong server at worst (which for mail could well result in a rather confusing bounce).
Is that tolerable? it depends on various factors including how often the IP changes, what services you are running, what the expectations for those services are and what proporition of other people on the IP block are also running the same service.
The problem is that because there are a limited number of operators available and because operators make code less verbose there is a temptation to misuse operators that doesn't exist to anything like the same extent with function names. C++ even institutionalises such misuse by doing it in the standard library. So in one place might mean a shift operation, in another place it might mean writing something to a stream.
The attitude of java's language designers seems to have been "if it can be misused it should be left out". The standard library desginers didn't seem to get the memo though. Personally I don't think this is a good attitude for a language designer to have.
OTOH I don't think institutionalising misuse by doing it in the standard library is a good idea either.
What bugs me about operator overloading is how tediously verbose it can get. For example, say you define operator functions for < and ==. You still have to do <=. Even when all the <= function is is: return this < that || this == that;, you still have to write it. It's so tempting to skip writing the code for an unused operator that many programmers do so.
That isn't really specific to operator overloading though. If you want your users to be able to do "less than or equal to" in one step then you have to provide an implementation of that regardless of whether you are using conventional functions or operator overloading.
Slashdot Mirror
What is even more amusing is that wine can quite happilly run win16 applications on a 64-bit linux system.
Afaict the only reason 64-bit windows can't run win16 applications is that MS couldn't be bothered to implement/debug support for it.
95 and 98 use a graphical installer that ran under windows for the early stages of install. You could either run the first part of the installer under your existing version of windows (if upgrading) or if you ran it from dos it would load "mini windows" which afacit is a very stripped down win3.x. IIRC the installer required the hard drive to be already paritioned and formatted as it would use it for temporary storage space. After the first reboot the system was then running windows 9x as it sorted out the final details. The boot floppies included with some copies of windows 9x and the later bootable CDs loaded the corresponding version of DOS (win9x came with it's own version of DOS)
2K and XP use a textmode installer for the early stages of install which I'm pretty sure is based on the NT kernel but without any of the win32 stuff loaded. This can be seen in things like the fact it needs a windows driver to see your hard drive (rather than being able to see any hard drive the BIOS can see). It would then reboot into the system it had partially installed to finish things off.
Vista and later use a graphical installer, which is based on winPE which is a stripped down version of modern windows.
I dunno what other versions do.
For webmail, what would be wrong with: encrypt/decrypt via client side javascript,
The big problem is that the website can change the client side javascript that it sends to a version designed to send the key to the server. If the version designed to grab the key is only sent once per user and only to users of interest it is unlikely that users will notice this behaviour.
Find me a bank or online retailer that allows financial accounting data to be submitted over insecure connections instead of SSL. I can wait.
It doesn't matter what the bank or retailer gets the data over, it matters what your phone sends it over. All too often people start browsing from an insecure entry point and only later move to a secure part of a site. This allows the MITM to change links or redirects in the insecure part and hence get the user to either enter their authentication details unencrypted or get them to enter them encrypted but to a domain the attacker controls (and therefore has a "legitimate" certificate for).
Plus ssl isn't as secure as people might like to think, for example apparently there were CAs out there who would still sign certs using md5 after md5 collision attacks became feasible allowing attackers to get themselves a cert with CA powers that was trusted by browsers*. There have also been recent attacks on SSL itself, and attacks on the way browsers combine compression with ssl.
* http://www.win.tue.nl/hashclash/rogue-ca/
Having a service hosted in one country but with admins from another seems like the worst of both worlds since either the government of the country the admins reside in or the government of the country the servers reside in could attack things.
They are "evil" in different ways.
Apple is strongly pushing locked down "curated computing" devices where you have little choice* but to buy all your apps from their appstore
Google is providing devices where there are officially allowed (i.e. unlikely to dissapear) ways to unlock the bootloader and do whatever you like to the device and are releasing the sourcecode for their OS (minus a handful of third party blobs). OTOH they are also pushing software as a service and all the crap that brings with it (features you need can dissapear at any time and you have no recourse, your data is far more readilly available to the spooks than it would be on your own machines). Then there is the whole fiasco of replacing talk (open federated platform) with hangouts (closed platform).
* You can register as a developer for an annual fee or you can hack the device in ways that are unsupported and may become unusable at any time.
The reason it wouldn't happen is because there's no motivation to do it, not because it's impossible. No one cares about hopelessly obsolete media.
Another problem is that PC hardware is so diverse, In the last debian release to support floppy initiated installs (etch) it had a floppy for loading the kernel, a second floppy for the core of the installer and then another two floppies for network drivers (there was also a floppy of CD drivers but generally you wouldn't use both the CD drivers and the network drivers floppies). IIRC in testing/unstable immediately before support was dropped they were up to three floppies of network drivers.
The specs they have given are basically
"Fastest multi-core CPU, 4GB RAM, 128GB storage"
Nothing on what CPU they actually plan to use, this is a fairly low volume device so it won't be something specific for them and it will have to fit within the power envelope of a phone. So expect whatever CPU it ends up with to be at best comparable to the best other phones available at the time it launches.
The ram is nice but there are already phones shipping with 2GB, I doubt it will be all that long before we see phones with 4GB on the market anyway. Same can probablly be said for storage. Predicted screen resoloution is actually lower than one of the CURRENT phones they are comparing it to.
The software innovations may or may not be cool but I see no reason they can't be done on an existing hardware platform.
Overall it's a fair chunk of cash to pay in advance for something that is likely to be at best marginally better and quite possiblly worse than other phones available in early-mid 2014.
I see several advantages to flash on the drive over system ram for this application.
Firstly flash has a lower cost per gigabyte than ram does by quite a substantial margin
Secondly laptops are quite limited in ram. It's only recently that 16GB has become possible at anything like a reasonable price and beyond that is just out of the question in normal sized laptops at the momemnt. If you have an older laptop or want an ultraportable then your ram options are likely to be even more limited.
Thirdly system ram based caches are volatile, reboot your system or have an app run away with memory allocation and boom goes your system ram based cache whereas a cache built into the drive
Fourthly a flash based cache can store newly written data even when the power fails meaning that flushes don't need to hit the platter. However this advantage may be dificult to realise in practice because of flash wear concerns.
I have the following concerns with hybrid drives.
1: After a new build or reimage (remember they are talking about office users here and offices do reimage from time to time) how long will it take the system to settle down and work out what should be on hdd and what should be on flash. There is obviously a compromise here between speed of adapting to a changed usage pattern and wear on the flash.
2: what will happen with writes? large SSDs spread them over a large area of flash to get decent life. Will writes be forced to the hard drive or will they rapidly wear the small ammount of flash.
3: for the ammount of storage a typical office user needs will they really be all that much cheaper than just fitting a SSD and avoiding the fragility of a mechanical hard drive and the unpredictability of a caching soloution.
Have you read kickstarter's or indigogo's terms lately? both obligate those running campaigns to provide or refund any rewards if the campaign is funded.
Now of course there is still some risk for the consumers, for example there is the risk that the legal entity running the campaign could go bankrupt. There is also the risk that you will get a reward that technically fits the promise but is actually a peice of shit. Is that risk worth it? it depends on the campaign (personally i'm going to say no in this case but I can see how others could have other opinions).
The computing power in the bitcoin pool today is 8 times [qz.com] the computing power of the top 500 fastest super computers in the world combined.
That article stinks of BS. It claims "The bitcoin network also qualifies as the world’s first exascale computer, meaning it’s capable of a quintillion floating point calculations per second.". The source seems to trace back to http://www.bitcoinwatch.com/ who quote a "Network Hashrate PetaFLOPS" but don't seem to indicate how they come up with that number.
AIUI bitcoin mining is a purely integer process. My guess is they looked at the performance of a typica GPU at a floating point benchmark and at bitcoin mining and came up with a scale factor. That may have made sense when mining was GPU dominated but it makes a lot less sense with FPGAs and ASICs coming in quickly.
If you are serious about doing a 51% attack you certainly wouldn't be doing it on general purpose CPUs nowadays and probablly wouldn't be doing it on GPUs. ASICs would be the way to go but you'd need a way to get a lot of them quickly.
Probablly the most effective approach for a government trying to do the "51% attack" would be to seize the designs from one of the major bitcoin asic vendors and then use their own contractors to mass produce them.
Lets run some numbers, current total network hashrate is 307.67 terahashes per second. Butterflylabs is a US company who retail asic miners at
$22484 for 500GH/s. Lets assume the US governement can get butterflylabs plans and find a contractor who will produce them for the same ammount that butterflylabs retail them for. Based on that assumption it would cost about 14 million dollars to match the current total network hashrate.
Of course it would take time to build the hashing setup so lets say they shoot for ten times the current total network hashrate to give themselves some breathing room. That would be 140 million dollars.
The motivation behind Bitcoin wasn't to create a currency that government would choose not to regulate; it was to create one that government could not regulate.
Unfortunately while bitcoins design makes it difficult to regulate there are still a few options governments have.
One option is the ."51% attack". If a party has control of more hashing power than the rest of the network put together then they can arbitrarily block transactions they don't like from properly confirming. I'm quite sure if the US goverment chose to do so they could do this, it's a question of whether they would consider it worth committing those resources.
Another option is to go after the exchanges and/or regard handling large ammounts of bitcoin or large transfers to/from foreign bitcoin exchanges as being suspicious behaviour just as they regard handling large amounts of cash as being suspicious behaviour.
Yet another option would be to simply pass a law making bitcoin illegal to posess.
And what alternatives can you suggest for sourcing phones and phone-like tablets that are more open.
I've never personally had one "fail" as such but i've seen mysterious corruption where files are no longer accessible or no longer contain what they should contain far more often than i've seen such things on hard drives.
My feeling is that the wear leveling algorithms are not handling some corner cases (such as powerloss) correctly.
Suppose I as a brit use a service in australia. My packets will either go via the US or via mainland europe and the far east. The return packets may or may not come back by the same route.
If I use an encryption system that is resistant to MITM then anyone wanting to steal the data will have to be in either britan (targetting me) or australia (targetting the service). If I don't use encryption then the person wanting to steal the data can pick it up anywhere along the line.
While it's possible for governments to send agents to go and beat people up outside of their territory it's politically expensive to do so. So it's usually only done in extreme cases.
The problem is that most people only read the manual when they discover something is wrong and there is no immediately obvious problem with the results of these scans. The problem only gets noticed much later when someone tries to work with the scanned information and discovers that it is readable but doesn't make sense.
I also notice that the manual says that the other options give larger files with better image quality but does not state clearly whether compression algorithms that can cause character substitution are disabled in those modes or whether substitution is just less likely due to higher quality settings.
When a development of a technology introduces new failure modes great care needs to be taken to inform users of those modes. Just burying it deep in a manual that people only read when things go wrong is not sufficient.
You cannot stop a social problem with a technological measure.
Maybe you can't stop it but you can often reduce it to more manageable levels.
Prevent "5ns form posting" with a cooloff time,
That helps to a point but if it becomes too common spammers will just design their spambots to work with whatever delays are commonly used. It means keeping a little more state in the spambot.
and also cache submitted forms from an IP address to prevent duplicates.
That helps to a point but if it becomes too common website spammers will just add message mangling just like email spammers do today.
You can also implement a 50 message per day limit, and reduce as needed to stop spammers.
50 messages per what per day?
50 messages per IP per day would cause a lot of pain to users stuck behind large scale NATs and probablly wouldn't impede the spammers too much, they often have an army of IPs under their control. 50 messages per user account per day would just cause the spammers to register lots of user accounts.
The problem with a lot of "clever" soloutions to spam is they work fine as long as their userbase is too small for the spammers to care. Once their userbase becomes big enough though the spammers will start putting real effort into attacking them.
While that is true in a sense it is a gross oversimplification.
Oil is expensive compared to coal and natural gas. So oil based fuels are mostly used where the advantages of an easilly portable liquid fuel outweighs the higher cost, e.g. transportation and some industrial uses. Afaict most electricity in the US comes from coal, nuclear and natural gas. So new nuclear power plants would be mostly displacing coal and gas not oil.
Does this mater? it depends on what you consider important. If your aim is to reduce greenhouse gas emmisions then switching electricity generation from coal and gas to nuclear is a big win.
OTOH If you aim is to get away from relying on imported oil oil then building nuclear power plants won't help much by itself, you also need to either develop coal to liquids and gas to liquids conversion facilities or convince current users of liquid fuels to switch to electricity.
Indeed, I'd like to submit that the only thing that actually needs a static-for-ever address is a DNS server. And that for everything else, we have DNS.
Just switching an IP address without warning or providing a period of paralell running will cause downtime at best and people getting sent to the wrong server at worst (which for mail could well result in a rather confusing bounce).
Is that tolerable? it depends on various factors including how often the IP changes, what services you are running, what the expectations for those services are and what proporition of other people on the IP block are also running the same service.
I think you are confusing the surface RT with the surface pro.
The rt has windows rt which is a crippled version of windows 8. It also has a locked bootloader so you can't replace the OS.
The pro is a regular PC which comes with comes with an uncrippled version of windows 8 and can have other operating systems installed if you with.
SKY is also a broadband ISP nowadays.
The problem is that because there are a limited number of operators available and because operators make code less verbose there is a temptation to misuse operators that doesn't exist to anything like the same extent with function names. C++ even institutionalises such misuse by doing it in the standard library. So in one place might mean a shift operation, in another place it might mean writing something to a stream.
The attitude of java's language designers seems to have been "if it can be misused it should be left out". The standard library desginers didn't seem to get the memo though. Personally I don't think this is a good attitude for a language designer to have.
OTOH I don't think institutionalising misuse by doing it in the standard library is a good idea either.
What bugs me about operator overloading is how tediously verbose it can get. For example, say you define operator functions for < and ==. You still have to do <=. Even when all the <= function is is: return this < that || this == that;, you still have to write it. It's so tempting to skip writing the code for an unused operator that many programmers do so.
That isn't really specific to operator overloading though. If you want your users to be able to do "less than or equal to" in one step then you have to provide an implementation of that regardless of whether you are using conventional functions or operator overloading.