You have Apple, the premium vendor providing a consistent platform... You have Android like windows, the cheaper option but runs on vastly more hardware and anyone can put it on their hardware... And then you have RIM and HP who represent the likes of Commodore and Atari, they also provide a consistent platform like Apple, but don't have the mindshare to attract third party developers.
Windows phone 7 would be a very poor choice for RIM at the moment, not only is the current version very much consumer oriented, but they would not really be able to provide much value-add on such a platform... Why buy RIM if you can go to any of the other windows phone 7 vendors? Android might be a better bet for them, as they can customise it heavily and run their own platform on top (or they could offer a pure software stack for use on other vendors phones). They could run their corporate email software in a sandbox isolated from the rest of the phone...
Addicts already commit petty crime to pay for their drug habits, plus the police wouldn't be busy trying to deal with drug dealers so they would have more resources available to deal with petty crimes.
But i do agree that penalties should be increased for anyone found to be under the influence of drugs when they commit a crime... People should have every right to do whatever they want to themselves, but any action which harms others should be clamped down on harshly.
The pharmaceutical industry would actually benefit massively from legalised drugs... They are already geared up to manufacture and sell drugs, so adding a few new ones to the list wouldn't be difficult for them.
Police and prisons are run by the government, so the government would bring in more revenue from taxes and the police would have greater resources available to deal with other crimes.
Or ditch the "war on drugs" entirely... The illegal trade in drugs costs authorities billions, and fuels organised crime such as the drug cartels in mexico and other countries.
So instead, legalise drugs but put in place controls on them:
Quality controls, drugs available from reputable suppliers rather than dodgy dealers, so drugs don't end up contaminated with other even more harmful substances. Taxes - tax drugs the same way that the currently legal tobacco and alcohol are taxed. Monitoring - know who's taking drugs.
Government saves on law enforcement costs trying to police drugs... Government further benefits from tax income from the sale of drugs. Drug users benefit from cheaper supplies, which are also safer and have a legal avenue for complaint. Drug companies can develop alternatives that provide the effects the users want, while reducing the negatives (e.g. see electronic cigarettes). Drug users need not hide their activities, and can more easily seek help to give up.
It's an obvious solution, and the only ones who stand to lose are the criminal gangs who are currently making huge profits from illegal drugs.
Patents expire long after the technology in question has been superseded by something else... Look at the patents on MPEG-1 or MPEG-2, those were considered good video formats just a few years ago but are now considered obsolete, and yet still many patents on them have not expired. By the time the patents on h.264 expire, it will be a legacy codec that noone has used for years.
Apple have often refused to license their patents.. Microsoft probably would, but the fees they demand would make it impossible to give android away for free, and would make it more expensive than windows mobile.
Your chances of already knowing bourne shell, which has been around for many years are much higher than knowing powershell which is a lot newer, and not an extension of anything existing.
You have chmod for traditional permissions, and setfacl/getfacl for advanced permissions (ACLs), you can use these same commands/functions for files, configuration (which are also files) and device drivers (which have files in/dev).
On windows you only have advanced permissions, and no simple option. You then have a set of functions for filesystem permissions, a different set for registry permissions and another set for driver permissions.
If you don't think this is a problem, take a look at digit-labs.org where there are privilege escalation exploits for a number of vulnerabilities in windows drivers where the vulnerable function never needs to be called by an unprivileged user anyway.
If unix permissions don't provide what you need, then chances are your needs are quite advanced and you are in a tiny niche, in which case you can learn how to use ACLs because modern unixes have these too. For the other 99% of users you can use a simple system instead of being forced to learn a complex one.
It's not optional in the true sense of the word, the system boots up and initialises its video drivers, a window manager and then displays a graphical login prompt. After logging in, you still have a window manager and now have a cli based interface running in a window.
A true non gui environment would have a full screen cli interface in text mode (i.e. no unnecessary loading of video drivers), and this interface would also be available over a serial console (serial consoles work much better remotely on slow links and over lights out systems, HP for instance supply CLI access for free and charge extra for video/keyboard redirection).
Because bash and by extension the bourne shell came first, and has already been the standard on pretty much every OS except windows. There are already a large number of people familiar with it, and a large number of already written scripts for it.
That's like me creating a non standard power socket carrying a non standard voltage, and then demanding that you install it in your house and replace all the existing appliances you have.
The problem is the complexity, dumping users, especially windows users who have little or no CLI experience into a powerful environment like powershell is not a good approach.. Especially when it's something completely new, rather than a logical extension of something users will already have been familiar with.
Bash is simple yet flexible, and builds on the bourne shell which has been around for many years... You don't need to learn anything new in order to get on with it, and bash is very good for the majority of people's tasks. For the small subset of people who need something more powerful, there are a large number of existing scripting or full on programming languages available.
The same can be said of ACLs, windows only provides acls while unix provides both acls and regular unix permissions... Windows also provides different APIs for adjusting registry and driver ACLs, while unix uses the same filesystem APIs for both. Unix permissions are less flexible, but provide everything that 99% of users require. The complexity of windows ACLs and the multiple different APIs for setting permissions in different places however discourage people from using them, so you get lots of users with weak permissions on their files, device drivers with weak permissions and programs that set poor permissions on their installation files or configuration.
You need simple but flexible for 99% of users by default, and an optional more powerful system for the 1% who need it.
If ReactOS becomes big enough however, then third party developers will target it... If you write code for ReactOS, then compatibility with windows comes too... If you target windows then compatibility with reactos may require extra work. If Reactos has a significant enough share of the user base, then it makes sense to target it.
Not to mention making those technologies as complex as possible so they're more difficult to clone, even if that added complexity causes them other problems (such as large numbers of security holes)...
ARM architectures are generally backwards compatible, as are the instruction sets which makes the situation not too dissimilar to x86, where you also have multiple revisions and multiple instruction set addons...
A JIT compiler is probably one of the few pieces of code that could be useful, only you would still need to modify it in order to produce efficient code for a low power x86 variant, for instance a JIT engine targeting a core2 doesn't run as well on an Atom... Also there are a whole different set of optimisation criteria in a desktop, power consumption is of minimal importance, there is usually plenty of memory available etc... On a mobile platform, you will have less memory, less backing storage, possibly slower memory etc, all of these things seriously affect compiler design.
Aside from ARM, it's also worth considering MIPS... There are plenty of low power MIPS designs which are capable of competing with ARM, but MIPS is already available in a 64bit variant and was previously available in high performance variants (in the 90s, MIPS was massively ahead of x86 for performance).
Intel cannot "solve" it, due to the shear complexity and legacy cruft of the x86 architecture...
They can try to mask it by moving to ever smaller fabbing processes, but then they will still be beaten by an ARM chip fabbed on the same process (a while ago intel were talking about trying to stay one step ahead on the fabbing front in order to retain parity with arm - thus effectively wasting their technological advances by holding them back on x86)... That's like building a more fuel efficient car, and then adding lead weights to it in order to reduce its overall efficiency to that of a normal car. If Intel were to keep one step ahead on fab process and then produce ARM, or even a new architecture specifically designed for low power use, they would have a huge advantage over the competition.
They can also try to reduce power consumption by sacrificing performance (e.g. atom removed the out of order execution capability, which both reduced performance and requires existing code to be reoptimized for the new processor), but then they lose the performance lead over ARM.
"legacy" has both negative and positive connotations, negative being the power consumption as a result of complexity, and positive being the ability to run existing code... However the fact that a lot of that existing code is also available with source code and can thus be recompiled for another architecture... And the fact that a lot of the existing code is simply not relevant in the context of a mobile phone... Means that the negative connotations of "legacy" massively outweigh any positive ones, leading to a net negative overall.
What we really need is a new architecture specifically designed for low power... Both ARM and x86 have legacy cruft holding them back, although x86 has considerably more...
An OS which is not designed for a phone would be a very poor choice for use on a phone, why would you want to run such an OS when multiple systems specifically designed for phones already exist?
Optimized multimedia libraries would become somewhat less optimal if you ran binaries designed for a full power x86 chip on a stripped down low power variant, libraries optimised specifically for the low power variant would perform considerably better and if your reoptimising anyway, why not do it for arm.
Codecs.. well what codecs do you really need on a phone? h.264, webm, divx, xvid, mpeg for video? mp3, ogg, gsm, aac for audio? those already exist for ARM, and in source code form so they can easily be ported to other architectures. Anything else would be very niche, and probably still exist in source code form anyway... Worst case for anything else you could transcode.
Encryption/decryption - multiple encryption libraries exist in source code form, e.g. OpenSSL... Any sensible algorithm you would care to use is already available for ARM, and in source code form for easy porting to any other architecture.
Device drivers - phones already have device drivers available, they generally have custom hardware in them which require specific drivers anyway, so existing drivers would be of little or no use, especially without source code.
File systems - linux already has drivers available for virtually any filesystem you're likely to encounter, and in source code form which already compile for ARM...
Network stack - a number of network stacks already exist in ARM platforms, and most come with source code so could be easily ported.
If your porting software and have the source code then underlying architecture makes little difference...
If you don't have the source, then chances are the binaries require windows or dos, and probably have interfaces that would be utterly unsuitable for use on a phone...
In a phone, lower power is more important than being able to run desktop binaries, and arm will always be lower power than x86 due to carrying around a lot less legacy cruft (although it does have some...)
Welcome to commoditization... Unless you can differentiate, then it comes down to whoever has the lowest manufacturing costs and the most well known brands. This is how mature markets end up.
That's a poor backup plan, you trade a semi open system for an entirely closed system... You are more beholden to microsoft than to google, as at least with android you have the option to fork those versions which have been released as well as modify them to any extent you see fit.
Their windows phones are even more dependent on microsoft than their android phones are on google... BREW i can't speak for, having never heard of it, but that says something about its market share...
WebOS could be good, its a mature platform and has an existing user base, especially since the recent tablet sell-off by HP. It's also linux based, so making it capable of running android apps shouldn't be difficult.
There is another option however, Meego... Having been ditched by nokia, intel might be keen to partner with the likes of htc.
This is why modularity is good, linux as a whole is very good for this (don't like gnome3? run gnome2, or xfce, or enlightenment etc etc...), and the kernel is especially good (you can compile features as modules, or turn them off entirely to build a lean mean kernel)... More software should be build like this, with modules selectable at compile time or runtime.
Kind of like the PC market, where using windows doesn't give you an edge over your competition... Which is why Apple (being the only one not dependent on windows) are the only manufacturer making any decent margin, and big players like IBM and now HP are looking to exit the market.
Such a service works well with economies of scale... A lot of p2p traffic would occur locally, and never need to touch the internet peering... Similarly mirror sites of common downloads could be stored locally.
Slashdot Mirror
If anything, it's the PC market all over again...
You have Apple, the premium vendor providing a consistent platform...
You have Android like windows, the cheaper option but runs on vastly more hardware and anyone can put it on their hardware...
And then you have RIM and HP who represent the likes of Commodore and Atari, they also provide a consistent platform like Apple, but don't have the mindshare to attract third party developers.
Windows phone 7 would be a very poor choice for RIM at the moment, not only is the current version very much consumer oriented, but they would not really be able to provide much value-add on such a platform... Why buy RIM if you can go to any of the other windows phone 7 vendors? Android might be a better bet for them, as they can customise it heavily and run their own platform on top (or they could offer a pure software stack for use on other vendors phones). They could run their corporate email software in a sandbox isolated from the rest of the phone...
Addicts already commit petty crime to pay for their drug habits, plus the police wouldn't be busy trying to deal with drug dealers so they would have more resources available to deal with petty crimes.
But i do agree that penalties should be increased for anyone found to be under the influence of drugs when they commit a crime... People should have every right to do whatever they want to themselves, but any action which harms others should be clamped down on harshly.
The pharmaceutical industry would actually benefit massively from legalised drugs... They are already geared up to manufacture and sell drugs, so adding a few new ones to the list wouldn't be difficult for them.
Police and prisons are run by the government, so the government would bring in more revenue from taxes and the police would have greater resources available to deal with other crimes.
Or ditch the "war on drugs" entirely... The illegal trade in drugs costs authorities billions, and fuels organised crime such as the drug cartels in mexico and other countries.
So instead, legalise drugs but put in place controls on them:
Quality controls, drugs available from reputable suppliers rather than dodgy dealers, so drugs don't end up contaminated with other even more harmful substances.
Taxes - tax drugs the same way that the currently legal tobacco and alcohol are taxed.
Monitoring - know who's taking drugs.
Government saves on law enforcement costs trying to police drugs...
Government further benefits from tax income from the sale of drugs.
Drug users benefit from cheaper supplies, which are also safer and have a legal avenue for complaint.
Drug companies can develop alternatives that provide the effects the users want, while reducing the negatives (e.g. see electronic cigarettes).
Drug users need not hide their activities, and can more easily seek help to give up.
It's an obvious solution, and the only ones who stand to lose are the criminal gangs who are currently making huge profits from illegal drugs.
Patents expire long after the technology in question has been superseded by something else...
Look at the patents on MPEG-1 or MPEG-2, those were considered good video formats just a few years ago but are now considered obsolete, and yet still many patents on them have not expired. By the time the patents on h.264 expire, it will be a legacy codec that noone has used for years.
Apple have often refused to license their patents..
Microsoft probably would, but the fees they demand would make it impossible to give android away for free, and would make it more expensive than windows mobile.
Your chances of already knowing bourne shell, which has been around for many years are much higher than knowing powershell which is a lot newer, and not an extension of anything existing.
You have chmod for traditional permissions, and setfacl/getfacl for advanced permissions (ACLs), you can use these same commands/functions for files, configuration (which are also files) and device drivers (which have files in /dev).
On windows you only have advanced permissions, and no simple option. You then have a set of functions for filesystem permissions, a different set for registry permissions and another set for driver permissions.
If you don't think this is a problem, take a look at digit-labs.org where there are privilege escalation exploits for a number of vulnerabilities in windows drivers where the vulnerable function never needs to be called by an unprivileged user anyway.
If unix permissions don't provide what you need, then chances are your needs are quite advanced and you are in a tiny niche, in which case you can learn how to use ACLs because modern unixes have these too. For the other 99% of users you can use a simple system instead of being forced to learn a complex one.
It's not optional in the true sense of the word, the system boots up and initialises its video drivers, a window manager and then displays a graphical login prompt. After logging in, you still have a window manager and now have a cli based interface running in a window.
A true non gui environment would have a full screen cli interface in text mode (i.e. no unnecessary loading of video drivers), and this interface would also be available over a serial console (serial consoles work much better remotely on slow links and over lights out systems, HP for instance supply CLI access for free and charge extra for video/keyboard redirection).
Because bash and by extension the bourne shell came first, and has already been the standard on pretty much every OS except windows. There are already a large number of people familiar with it, and a large number of already written scripts for it.
That's like me creating a non standard power socket carrying a non standard voltage, and then demanding that you install it in your house and replace all the existing appliances you have.
The problem is the complexity, dumping users, especially windows users who have little or no CLI experience into a powerful environment like powershell is not a good approach.. Especially when it's something completely new, rather than a logical extension of something users will already have been familiar with.
Bash is simple yet flexible, and builds on the bourne shell which has been around for many years... You don't need to learn anything new in order to get on with it, and bash is very good for the majority of people's tasks.
For the small subset of people who need something more powerful, there are a large number of existing scripting or full on programming languages available.
The same can be said of ACLs, windows only provides acls while unix provides both acls and regular unix permissions... Windows also provides different APIs for adjusting registry and driver ACLs, while unix uses the same filesystem APIs for both.
Unix permissions are less flexible, but provide everything that 99% of users require. The complexity of windows ACLs and the multiple different APIs for setting permissions in different places however discourage people from using them, so you get lots of users with weak permissions on their files, device drivers with weak permissions and programs that set poor permissions on their installation files or configuration.
You need simple but flexible for 99% of users by default, and an optional more powerful system for the 1% who need it.
If ReactOS becomes big enough however, then third party developers will target it...
If you write code for ReactOS, then compatibility with windows comes too... If you target windows then compatibility with reactos may require extra work. If Reactos has a significant enough share of the user base, then it makes sense to target it.
Not to mention making those technologies as complex as possible so they're more difficult to clone, even if that added complexity causes them other problems (such as large numbers of security holes)...
ARM architectures are generally backwards compatible, as are the instruction sets which makes the situation not too dissimilar to x86, where you also have multiple revisions and multiple instruction set addons...
A JIT compiler is probably one of the few pieces of code that could be useful, only you would still need to modify it in order to produce efficient code for a low power x86 variant, for instance a JIT engine targeting a core2 doesn't run as well on an Atom...
Also there are a whole different set of optimisation criteria in a desktop, power consumption is of minimal importance, there is usually plenty of memory available etc... On a mobile platform, you will have less memory, less backing storage, possibly slower memory etc, all of these things seriously affect compiler design.
Aside from ARM, it's also worth considering MIPS... There are plenty of low power MIPS designs which are capable of competing with ARM, but MIPS is already available in a 64bit variant and was previously available in high performance variants (in the 90s, MIPS was massively ahead of x86 for performance).
Intel cannot "solve" it, due to the shear complexity and legacy cruft of the x86 architecture...
They can try to mask it by moving to ever smaller fabbing processes, but then they will still be beaten by an ARM chip fabbed on the same process (a while ago intel were talking about trying to stay one step ahead on the fabbing front in order to retain parity with arm - thus effectively wasting their technological advances by holding them back on x86)... That's like building a more fuel efficient car, and then adding lead weights to it in order to reduce its overall efficiency to that of a normal car. If Intel were to keep one step ahead on fab process and then produce ARM, or even a new architecture specifically designed for low power use, they would have a huge advantage over the competition.
They can also try to reduce power consumption by sacrificing performance (e.g. atom removed the out of order execution capability, which both reduced performance and requires existing code to be reoptimized for the new processor), but then they lose the performance lead over ARM.
"legacy" has both negative and positive connotations, negative being the power consumption as a result of complexity, and positive being the ability to run existing code...
However the fact that a lot of that existing code is also available with source code and can thus be recompiled for another architecture...
And the fact that a lot of the existing code is simply not relevant in the context of a mobile phone...
Means that the negative connotations of "legacy" massively outweigh any positive ones, leading to a net negative overall.
What we really need is a new architecture specifically designed for low power... Both ARM and x86 have legacy cruft holding them back, although x86 has considerably more...
An OS which is not designed for a phone would be a very poor choice for use on a phone, why would you want to run such an OS when multiple systems specifically designed for phones already exist?
Optimized multimedia libraries would become somewhat less optimal if you ran binaries designed for a full power x86 chip on a stripped down low power variant, libraries optimised specifically for the low power variant would perform considerably better and if your reoptimising anyway, why not do it for arm.
Codecs.. well what codecs do you really need on a phone? h.264, webm, divx, xvid, mpeg for video? mp3, ogg, gsm, aac for audio? those already exist for ARM, and in source code form so they can easily be ported to other architectures. Anything else would be very niche, and probably still exist in source code form anyway... Worst case for anything else you could transcode.
Encryption/decryption - multiple encryption libraries exist in source code form, e.g. OpenSSL... Any sensible algorithm you would care to use is already available for ARM, and in source code form for easy porting to any other architecture.
Device drivers - phones already have device drivers available, they generally have custom hardware in them which require specific drivers anyway, so existing drivers would be of little or no use, especially without source code.
File systems - linux already has drivers available for virtually any filesystem you're likely to encounter, and in source code form which already compile for ARM...
Network stack - a number of network stacks already exist in ARM platforms, and most come with source code so could be easily ported.
If your porting software and have the source code then underlying architecture makes little difference...
If you don't have the source, then chances are the binaries require windows or dos, and probably have interfaces that would be utterly unsuitable for use on a phone...
In a phone, lower power is more important than being able to run desktop binaries, and arm will always be lower power than x86 due to carrying around a lot less legacy cruft (although it does have some...)
How is this any different to the PC market, where the entire business of every manufacturer with the exception of Apple rests upon Microsoft's whims?
A shitty app that does what you need is better than a well made app that doesn't do what you need...
Welcome to commoditization... Unless you can differentiate, then it comes down to whoever has the lowest manufacturing costs and the most well known brands. This is how mature markets end up.
That's a poor backup plan, you trade a semi open system for an entirely closed system... You are more beholden to microsoft than to google, as at least with android you have the option to fork those versions which have been released as well as modify them to any extent you see fit.
Their windows phones are even more dependent on microsoft than their android phones are on google...
BREW i can't speak for, having never heard of it, but that says something about its market share...
WebOS could be good, its a mature platform and has an existing user base, especially since the recent tablet sell-off by HP. It's also linux based, so making it capable of running android apps shouldn't be difficult.
There is another option however, Meego... Having been ditched by nokia, intel might be keen to partner with the likes of htc.
This is why modularity is good, linux as a whole is very good for this (don't like gnome3? run gnome2, or xfce, or enlightenment etc etc...), and the kernel is especially good (you can compile features as modules, or turn them off entirely to build a lean mean kernel)... More software should be build like this, with modules selectable at compile time or runtime.
Kind of like the PC market, where using windows doesn't give you an edge over your competition... Which is why Apple (being the only one not dependent on windows) are the only manufacturer making any decent margin, and big players like IBM and now HP are looking to exit the market.
Such a service works well with economies of scale...
A lot of p2p traffic would occur locally, and never need to touch the internet peering... Similarly mirror sites of common downloads could be stored locally.