The fact remains that security of the bitcoin proof-of-work blockchain has been compromised by a lack of diversity and decentralization.
Note that I did not refer to proof-of-stake exclusively. That is just one example mentioned by name. The fact remains that a non-proof-of-work system that does not waste enormous amounts of energy is needed.
Problems related to the initial distribution of a proof-of-stake coin is mitigated by hybrid approaches. Such as etherium's plan to start with proof-of-work and migrate to proof-of-stake. The temporary "work" based phase helps with that early distribution. Bitcoin fits this pattern as well, making your initial staking arguments somewhat moot. We're not discussing a situation where a coin is "stake" based from day one.
Speculation deterring usage is already a problem. Bitcoin has been and continues to be primarily a speculative vehicle.
Its not that centralization is "evil". It is that the bitcoin security model is founded upon decentralization. Remove decentralization and the security model is non-existent. The only thing that prevents a government from forcing its will upon the blockchain, for example reversing transactions it disapproves of -- say someone transferring wealth overseas, is that the government has not chosen to do so. That is the problem with centralization of bitcoin mining.
Bitcoin has a way to vote for changes to the protocol but that voting is done by miners. The interests of miners are not the same as those of holders of the currency which are also different from the interests of users of the currency.
A fork gets around this problem.
People holding the currency are mostly doing it for speculation, their interest is the currency appreciating.
Moving to non-proof-of-work does not remove the element of speculation.
It might be. It could force bitcoin to move from proof-of-work to proof-of-stake or some other scheme that distributes maintenance of the blockchain (and does not waste energy). Right now mining is not decentralizing.
Bitcoin is not decentralized and has not been for years. The underlying theory of bitcoin is that a diverse and decentralized population of users maintain the blockchain via their ordinary computers. Bitcoin has neither diversity nor decentralization. Bitcoin is not diverse as it is dominated by the manufacturers and owners of expensive and specialized mining hardware, ASICs. Bitcoin is not decentralized as 70%+ of the miners are in a single country, China, and low cost government controlled power. Bitcoin has deviated from its core design that was supposed to ensure security. Bitcoin is vulnerable to government manipulation as it exists at the moment.
If China follow through with a mining ban and bitcoin evolves, moves back towards its design, they yeah, that would be good. If not and it dies and some other blockchain based non-proof-of-work coin becomes dominant that too is good.
The entire purpose of cryptocurrency is to undermine the state. There is literally no other value add to the blockchainist (pseudo) decentralization model of electronic currency.
Actually, bitcoin has undermine itself.
Bitcoin is not decentralized and has not been for years. The underlying theory of bitcoin is that a diverse and decentralized population of users maintain the blockchain. Bitcoin has neither diversity nor decentralization. Bitcoin is not diverse as it is dominated by the manufacturers and owners of expensive and specialized mining hardware, ASICs. Bitcoin is not decentralized as 70%+ of the ASIC miners are in a single country, China, dependent upon inexpensive government control power. Bitcoin has deviated from its core design that was supposed to ensure security.
Speaking as someone who has dual booted since around 1993 (Yggdrail plug and play Linux)...
Primarily, there are a lot of people that need an app or utility that is only available for Windows.
Some will argue that there are FOSS replacements for the functionality provided by these apps but most of these FOSS replacements are not Linux specific and run under Windows too. Someone wanting to save money by using Gimp does not need Linux.
Secondarily there is the network effect. As the dominant OS Windows just has more people you can ask questions, ask for help. Same for those dominant non-FOSS apps.
Related to this is virtually any hardware gizmo you might want to buy will be supported by Windows. Linux, maybe not.
In short there is a cost from switching to Linux, software availability, what others are using, compatibility,... These costs must be offset by something that is specific to Linux, and the things that Linux advocates speak of when talking to Windows users are often not meaningful or interesting to the latter. So the typical Windows user sees no gain.
Regarding things specific to Linux... the Windows Subsystem for Linux (WSL) reduces the number of such things. Various *nix tools or utilities that fit a particular task better than their Windows counterparts are now conveniently available from the Microsoft Store for free. Note that some long time Linux users are finding that WSL lets them have their *nix toolchain under Windows, that's pretty convenient for cross platform development. Kind of a repeat of what we saw with Mac OS X and the BSD console and posix API being available. Such things just make Linux less special than it used to be. In 1993 when I started using Linux it seemed a godsend, I wished I had it for undergraduate CS studies. Fortunately I had it for grad school. But today, its just less special.
To be VERY VERY clear, the above is strictly discussing the typical user desktop. If you want to discuss embedded or server environment, of *nix based workstation use, things are quite different than the consumer desktop.
Although all the companies talk a good game about how safe their storage is, in reality archiving your old stuff is really hard
A past employer contracted out to a reputable off-site backup service company, circa late 1990s. Anything over one year old was moved off-site freeing up local server storage. In addition the off-site was supposed to have tape backup. When requesting something from the off-site there was about a 25% chance you would not get it, about a quarter of the time you were told it was missing or damaged and unrecoverable.
Personally I am grateful for the previous lesson regarding "cloud" storage. I have local backups for the important stuff. "Cloud" is for convenience, and a plan "C" incase your building burns down. Its not plan "A".
Most of their profit comes from the iPhone, which is much less expensive than their other hardware.
But they make up for it in volume.:-) Seriously, they do. Its not the cost of the product, its the profit margin. A very large number of less expensive but higher margin products wins the game.
What really made them profitable was having a highly streamlined product line which makes their costs lower than other companies.
I'm not sure this is true. After all the company they outsource their manufacturing to also manufactures for their competitors.
"The research confirms something many internet pundits have long instinctively believed to be true: piracy isn't driven by law-breakers, it's driven by people who can't easily or affordably get the content they want," she said.
No, the pundits are misunderstanding. Piracy is driven by the convenience of the piracy. Its merely the inconvenience necessary to get them to go legit is proportional to the affordability. However if piracy is convenient enough affordability offers little prevention.
Once upon a time I had some software bundled with a university textbook, molecular modeling and visualization software. Think a digital version of the plastic ball and stick kits, now add geometry cleanup and various 3D renderings. Not wanting to deal with the hassle of copy protection I did not use any. The textbook included a coupon that let the student buy the software at the university bookstore for US$30. The software was required for the class, software sales were 10% that of the textbook. The publisher said to add copy protection. I selected the simplest, crudest, least like to generate customer support problems copy protection that I could find. Cracks were quickly produced and widely distributed for other software using this copy protection. I didn't care, I wanted to minimize customer support calls. This copy protections software worked. Sale increased to 80% that of the textbook despite cracks being immediately and readily available. This was in a university environment, where many are technically competent or can find someone who is quite easily. Yet the simplest crudest easily defeatable barrier to piracy caused the piracy rate to drop from 90% to 20%.
People will pirate if it easy to do so, regardless of how low cost a software product is. In other words people will break the law if it is easy enough to do so. Traffic laws, piracy... similar thing. Nearly anyone will do it if easy enough and the consequences low enough.
Bitcoin is doing just fine. After three previous exponential runs up there was a 75% pull back and then a plateau for years. This exponential run had an 80-85% pullback but it is still at around 7x to 10x the previous multi-year plateau. It only looks bad for the speculators who bought during the exponential rise. People who bought on the previous plateau are doing quite well on the current plateau.
At least so far, bitcoin will likely be replaced by some other coin someday. Blockchain based technology may be with us for a long time, but bitcoin is just a user of blockchain and completely replaceable. What we need here is a car analogy.:-) Blockchain is like internal combustion engine technology, Bitcoin is like the Ford Model T car, the first popular large scale user of the technology.
It barely works today where it does *not* have to emulate the CPU architecture.
I'd say it more than barely works, I run quite a few Windows apps with Parallels and it works great! Maybe not perfect, but far better than barely works. But I am concerned about this switch; being able to easily run Windows apps when I need to has been a huge benefit for me...
Personally I can only tolerate emulation for shorter tasks. Things taking minutes rather than hours. For the latter I will reboot into Windows. I'm often overly annoyed by the sluggishness.
Regarding emulation, it worked but was not practical. It barely works today where it does *not* have to emulate the CPU architecture. A switch to ARM would impose a huge burden on emulators and seriously and negatively impact performance.
First off, Boot Camp has NOTHING to do with Emulation.
Agreed, mostly. I address dual boot and emulation as two separate things. Apologies if I was not clear about that. Although to be overly technical one's Boot Camp partition can be natively booted at startup or run via an emulator after having booted macOS.
And as for losing x86 Windows Application access, Microsoft has already solved that with Windows 10 for ARM 64. It CALLS it "Emulation", but it actually provides x86 Windows Application Support through the use of a JIT Compiler, much like Apple did when transitioning from 68k to PPC. And that worked well enough that Apple was able to put-off rewriting/recompiling lots of pieces of MacOS (Classic) itself for a long time. That's because the "new host" CPU runs NATIVE CODE.
I mentioned such binary to binary translation in another post, better than emulation, not quite as good as recompiling but often "good enough". The problem with Windows on ARM and translation of x86 code is that not all users will be able to move to that version of Windows.They may have a legacy version of Windows, they may not want to spend the money to buy a second version of Windows. Genuine emulation will be necessary for some.
More so for emulation, less so for binary to binary translation, I found such things to largely be practical only for short tasks. Minutes not hours. After about 15 minutes the sluggishness would annoy me. I prefer dual booting to Windows for tasks taking hours. And natively recompiled apps seemed an improvement over running the translations. Generating a binary from source code rather than another binary has many advantages. But unlike emulations, translation is more likely to be "good enough" to be tolerable.
"Blockchain" was the buzzword last year with VC and Angel investors. At trade shows / conferences / etc where entrepreneurs were demoing products / services many investors could not help themselves, they had to ask about and ponder if "blockchain" could somehow be "incorporated" into the product / service in order to make it a more viable investment.
Using the word "blockchain" in 2018 was like using the word "internet" in 1999. It made every business venture "better". Lets see how 2019 goes.
That said, blockchain is useful, just like the internet. Useful as a public ledger, but not everything needs a public ledger.
That's still an iPad not a Mac. In the comment, by "computer" I was referring to a Mac. As indicated by the subject line.
If you want to argue about a "computer" in general I'm fine with that. I hate that smart phones are called "phones", I think of them as handheld computers given that phone is a relatively minor feature and they are really a more general purpose device. A computer with lots of built-in sensors. But Macs becoming iOS devices, all Macs only getting software from the Mac App Store, all Macs going ARM, no, these things are highly unlikely.
Plus Apple doesn't consider an iPad Pro with a keyboard to be a "computer", haven't you seen the TV commercial?:-)
They are not going to turn computers into giant iOS devices.
They are not going to lock out 3rd party software distribution for computers.
They are probably not going to to switch all Macs to ARM.
What they are probably going to do is launch a MacBook Air that is ARM. macOS, its built-in applications and Apple's optional apps on the Mac App Store will be recompiled for ARM. Some people need nothing more than a mail client, a browser and a productivity suite like Apple's Pages, Numbers and Keynote. Such people will get along quite nicely on such a system. The MacBook Pro will remain Intel based for Windows support and legacy software support with full performance. Apple will encourage 3rd party developers to recompile for ARM but they will also probably offer an x86 binary to ARM binary conversion tool for legacy software that is not recompiled. This converted code will run better than x86 in an emulator but not as well as recompiled, in short it will probably be "good enough". Over time an ARM based Mac will become more capable for people that do not need Windows. However for the huge segment of Mac users that do need Windows some Macs will remain Intel based. Again, when Apple went Intel their marketshare doubled as people no longer had to choose PC or Mac, when people could get both on the same machine. Apple will continue to offer such machines however perhaps not at the entry level, MacBook Air, etc.
What about Boot Camp? Presumably it goes away. I wonder how many people will find running Windows in a VM (especially one that has to emulate the CPU) will find have problems with that solution?
Look to the PowerPC era, emulation worked but it was not really practical to use. When Apple switched to Intel their marketshare doubled. With Boot Camp people no longer had to chooser Mac or PC, they could have both on the same computer. Switch to ARM and we are back having to make that choice.
In theory apps will need to be recompiled by the developers. That is probably the best solution.
However another solution is to have software translate an x86 binary into an ARM binary. You still get native architecture speed but perhaps there is inefficiency since you started with an x86 binary, Source code would have provided more information and more opportunities to optimize the code. I'd lean towards this binary translation solution. Universal and likely good enough. To be clear I expect macOS, its bundled application and Apple's productivity applications will be recompiled and fully native. This binary translation is more for the 3rd party mac apps.
Then there is emulation. Doable but there is a big performance hit when you have to emulate the CPU architecture. When Apple switched to Intel and PC emulators no longer had to emulate the x86 architecture emulation the Windows environment became practical for some users.
The folks suggesting that iOS will replace macOS are almost certainly guessing wrong. macOS and iOS share some core operating system code and various APIs, but where their respective libraries and APIs begin to differ tends to be related to the user experience and the mobile user experience isn't going to work on a laptop or desktop. I think Apple has already made comments along these lines.
Additionally, until MS Windows on ARM is a common office and household operating system I doubt Apple will completely abandon Intel. Apple's marketshare doubled when users no longer had to choose PC or Mac, when they could run both macOS and MS Windows on the same computer. Boot into either operating system as required by the software they needed to run. Since Windows on ARM is not a common operating system, since Windows on x86 is what people overwhelmingly have and will need to be able to run... switching to a non-x86 CPU would be a return to the bad old days where people had to chooser Mac or PC. Presumably bringing back that choice would cut Apple's sales in half.
What people *might* be grossly exaggerating is a chromebook competitor. An ARM based Mac where macOS and its bundled applications and Apple's productivity software (word processor, spreadsheet, slideshow, etc) have all been recompiled for ARM. There are many users who would use nothing beyond these apps and a web browser. For them MS Windows and 3rd party Mac software are irrelevant and an ARM based Mac that has much better battery endurance would be great. Think of something like the MacBook Air moving to the ARM CPU but the MacBook Pro staying Intel.
Torvalds is mistaken, price dictated x86 Linux replacing traditional *nix RISC vendors. The argument regarding developers wanting the same hardware in the field as in their desktop PC is erroneous. Most *nix software does not care what the underlying hardware is. They may want the same operating system and software stack but that is something quite different than the underlying hardware. If RedHat and Ubuntu offered their respective Linux distributions on ARM and the ARM servers were less expensive to buy and operate they would be used by many and their server side software would not know or care if its Intel or ARM under the hood.
Apple's market share literally doubled after switching to Intel and allowing Windows to dual boot. One of the biggest stumbling blocks to get people to switch to Mac was their need to use Windows (and before that MS-DOS) software. Once you could dual boot MacOS or Windows you no longer had to choose PC or Mac, you could have one computer that could run either software family.
Regarding emulation, it worked but was not practical. It barely works today where it does *not* have to emulate the CPU architecture. A switch to ARM would impose a huge burden on emulators and seriously and negatively impact performance.
While Microsoft might offer Windows on ARM you would have a lot of PC software that will not be recompiled for ARM. So dual booting ARM MacOS or ARM Windows gets you back to the bad old days of having the choose PC (ie x86) or something-not-PC. Good news for Dell, HP, etc... bad news for Apple.
If someone had told you in 1978 that in 30 years you would be able to run your Unix programs on a device that fits in your pocket, would you have dismissed it as a fucking toy?
No we would have complained that it can't possibly take 30 years.
The proprietary *nix RISC based boxes were displaced before 64-bit AMD. It didn't matter if Linux was slower, very few needed the additional performance of Sun, SGI, etc. Linux on commodity PC displaced these traditional *nix vendors both in workstation and server environments. MS Windows Server was also having some success against them due to cost but Linux thwarted MS' ambitions here as well. By the time 64-bit was available Linux was already the "winner" server side.
"Develop at home" is really a proxy for "develop/deploy on cheapest". What applications, what software stacks, care about the underlying hardware architecture? If cloud based servers ran non-x86 hardware few would notice or care. If cloud server costs for non-x86 hardware were cheaper and performed adequately they would get used. x86 Linux won because it was cheaper than the traditional Unix vendors with their proprietary *nix RISC based platforms. Similar on the workstation side. The shift from RISC *nix boxes to x86 Linux was overwhelmingly about cost, almost no software cared which it ran on.
Linux x86 to Linux ARM would be a virtually unnoticeable transition for nearly all. Again assuming adequate performance for the money. It was about price in RISC *nix days, it will be about price in ARM days.
x86 won on price, on the desktop, on the server. That is the simple truth.
As for stability and bugs, cross platform is superior. Bugs that are hard to manifest on one hardware architecture may manifest quite readily on a different architecture. Having worked on various cross-platform projects I've seen the main x86 based dev teams visit the alternative architecture teams (ex PPC) when they are stumped debugging, they eventually appreciated the alternative architectures. A single architecture target allows for longer lived quirky bugs. The simple truth is that cost is more important to many.
This is not to say ARM will be successful in server space, just that it will be about cost and little else.
From a conversation among the grownups. Something modeled on the Coast Guard rather than the Air Force since we have regulatory compliance, defense and force projection.
Did you mean WinNT 3.1? Win 3.x was 16-bit. We didn't get a clean 32-bit environment until WinNT. Win9x was a 16/32-bit hybrid environment, I'm not sure if drivers were 32-bit.
Slashdot Mirror
The fact remains that security of the bitcoin proof-of-work blockchain has been compromised by a lack of diversity and decentralization.
Note that I did not refer to proof-of-stake exclusively. That is just one example mentioned by name. The fact remains that a non-proof-of-work system that does not waste enormous amounts of energy is needed.
Problems related to the initial distribution of a proof-of-stake coin is mitigated by hybrid approaches. Such as etherium's plan to start with proof-of-work and migrate to proof-of-stake. The temporary "work" based phase helps with that early distribution. Bitcoin fits this pattern as well, making your initial staking arguments somewhat moot. We're not discussing a situation where a coin is "stake" based from day one.
Speculation deterring usage is already a problem. Bitcoin has been and continues to be primarily a speculative vehicle.
Its not that centralization is "evil". It is that the bitcoin security model is founded upon decentralization. Remove decentralization and the security model is non-existent. The only thing that prevents a government from forcing its will upon the blockchain, for example reversing transactions it disapproves of -- say someone transferring wealth overseas, is that the government has not chosen to do so. That is the problem with centralization of bitcoin mining.
A fork of bitcoin isn't bitcoin.
That's semantics. That your coins now have a different acronym and name is irrelevant.
Bitcoin can't move to proof-of-stake.
Of course it can, it software based.
Bitcoin has a way to vote for changes to the protocol but that voting is done by miners. The interests of miners are not the same as those of holders of the currency which are also different from the interests of users of the currency.
A fork gets around this problem.
People holding the currency are mostly doing it for speculation, their interest is the currency appreciating.
Moving to non-proof-of-work does not remove the element of speculation.
This is good for Bitcoin
It might be. It could force bitcoin to move from proof-of-work to proof-of-stake or some other scheme that distributes maintenance of the blockchain (and does not waste energy). Right now mining is not decentralizing.
Bitcoin is not decentralized and has not been for years. The underlying theory of bitcoin is that a diverse and decentralized population of users maintain the blockchain via their ordinary computers. Bitcoin has neither diversity nor decentralization. Bitcoin is not diverse as it is dominated by the manufacturers and owners of expensive and specialized mining hardware, ASICs. Bitcoin is not decentralized as 70%+ of the miners are in a single country, China, and low cost government controlled power. Bitcoin has deviated from its core design that was supposed to ensure security. Bitcoin is vulnerable to government manipulation as it exists at the moment.
If China follow through with a mining ban and bitcoin evolves, moves back towards its design, they yeah, that would be good. If not and it dies and some other blockchain based non-proof-of-work coin becomes dominant that too is good.
The entire purpose of cryptocurrency is to undermine the state. There is literally no other value add to the blockchainist (pseudo) decentralization model of electronic currency.
Actually, bitcoin has undermine itself.
Bitcoin is not decentralized and has not been for years. The underlying theory of bitcoin is that a diverse and decentralized population of users maintain the blockchain. Bitcoin has neither diversity nor decentralization. Bitcoin is not diverse as it is dominated by the manufacturers and owners of expensive and specialized mining hardware, ASICs. Bitcoin is not decentralized as 70%+ of the ASIC miners are in a single country, China, dependent upon inexpensive government control power. Bitcoin has deviated from its core design that was supposed to ensure security.
Speaking as someone who has dual booted since around 1993 (Yggdrail plug and play Linux) ...
... These costs must be offset by something that is specific to Linux, and the things that Linux advocates speak of when talking to Windows users are often not meaningful or interesting to the latter. So the typical Windows user sees no gain.
... the Windows Subsystem for Linux (WSL) reduces the number of such things. Various *nix tools or utilities that fit a particular task better than their Windows counterparts are now conveniently available from the Microsoft Store for free. Note that some long time Linux users are finding that WSL lets them have their *nix toolchain under Windows, that's pretty convenient for cross platform development. Kind of a repeat of what we saw with Mac OS X and the BSD console and posix API being available. Such things just make Linux less special than it used to be. In 1993 when I started using Linux it seemed a godsend, I wished I had it for undergraduate CS studies. Fortunately I had it for grad school. But today, its just less special.
Primarily, there are a lot of people that need an app or utility that is only available for Windows.
Some will argue that there are FOSS replacements for the functionality provided by these apps but most of these FOSS replacements are not Linux specific and run under Windows too. Someone wanting to save money by using Gimp does not need Linux.
Secondarily there is the network effect. As the dominant OS Windows just has more people you can ask questions, ask for help. Same for those dominant non-FOSS apps.
Related to this is virtually any hardware gizmo you might want to buy will be supported by Windows. Linux, maybe not.
In short there is a cost from switching to Linux, software availability, what others are using, compatibility,
Regarding things specific to Linux
To be VERY VERY clear, the above is strictly discussing the typical user desktop. If you want to discuss embedded or server environment, of *nix based workstation use, things are quite different than the consumer desktop.
Although all the companies talk a good game about how safe their storage is, in reality archiving your old stuff is really hard
A past employer contracted out to a reputable off-site backup service company, circa late 1990s. Anything over one year old was moved off-site freeing up local server storage. In addition the off-site was supposed to have tape backup. When requesting something from the off-site there was about a 25% chance you would not get it, about a quarter of the time you were told it was missing or damaged and unrecoverable.
Personally I am grateful for the previous lesson regarding "cloud" storage. I have local backups for the important stuff. "Cloud" is for convenience, and a plan "C" incase your building burns down. Its not plan "A".
Most of their profit comes from the iPhone, which is much less expensive than their other hardware.
But they make up for it in volume. :-) Seriously, they do. Its not the cost of the product, its the profit margin. A very large number of less expensive but higher margin products wins the game.
What really made them profitable was having a highly streamlined product line which makes their costs lower than other companies.
I'm not sure this is true. After all the company they outsource their manufacturing to also manufactures for their competitors.
"The research confirms something many internet pundits have long instinctively believed to be true: piracy isn't driven by law-breakers, it's driven by people who can't easily or affordably get the content they want," she said.
No, the pundits are misunderstanding. Piracy is driven by the convenience of the piracy. Its merely the inconvenience necessary to get them to go legit is proportional to the affordability. However if piracy is convenient enough affordability offers little prevention.
... similar thing. Nearly anyone will do it if easy enough and the consequences low enough.
Once upon a time I had some software bundled with a university textbook, molecular modeling and visualization software. Think a digital version of the plastic ball and stick kits, now add geometry cleanup and various 3D renderings. Not wanting to deal with the hassle of copy protection I did not use any. The textbook included a coupon that let the student buy the software at the university bookstore for US$30. The software was required for the class, software sales were 10% that of the textbook. The publisher said to add copy protection. I selected the simplest, crudest, least like to generate customer support problems copy protection that I could find. Cracks were quickly produced and widely distributed for other software using this copy protection. I didn't care, I wanted to minimize customer support calls. This copy protections software worked. Sale increased to 80% that of the textbook despite cracks being immediately and readily available. This was in a university environment, where many are technically competent or can find someone who is quite easily. Yet the simplest crudest easily defeatable barrier to piracy caused the piracy rate to drop from 90% to 20%.
People will pirate if it easy to do so, regardless of how low cost a software product is. In other words people will break the law if it is easy enough to do so. Traffic laws, piracy
Bitcoin is doing just fine. After three previous exponential runs up there was a 75% pull back and then a plateau for years. This exponential run had an 80-85% pullback but it is still at around 7x to 10x the previous multi-year plateau. It only looks bad for the speculators who bought during the exponential rise. People who bought on the previous plateau are doing quite well on the current plateau.
:-) Blockchain is like internal combustion engine technology, Bitcoin is like the Ford Model T car, the first popular large scale user of the technology.
At least so far, bitcoin will likely be replaced by some other coin someday. Blockchain based technology may be with us for a long time, but bitcoin is just a user of blockchain and completely replaceable. What we need here is a car analogy.
It barely works today where it does *not* have to emulate the CPU architecture.
I'd say it more than barely works, I run quite a few Windows apps with Parallels and it works great! Maybe not perfect, but far better than barely works. But I am concerned about this switch; being able to easily run Windows apps when I need to has been a huge benefit for me...
Personally I can only tolerate emulation for shorter tasks. Things taking minutes rather than hours. For the latter I will reboot into Windows. I'm often overly annoyed by the sluggishness.
Regarding emulation, it worked but was not practical. It barely works today where it does *not* have to emulate the CPU architecture. A switch to ARM would impose a huge burden on emulators and seriously and negatively impact performance.
First off, Boot Camp has NOTHING to do with Emulation.
Agreed, mostly. I address dual boot and emulation as two separate things. Apologies if I was not clear about that. Although to be overly technical one's Boot Camp partition can be natively booted at startup or run via an emulator after having booted macOS.
And as for losing x86 Windows Application access, Microsoft has already solved that with Windows 10 for ARM 64. It CALLS it "Emulation", but it actually provides x86 Windows Application Support through the use of a JIT Compiler, much like Apple did when transitioning from 68k to PPC. And that worked well enough that Apple was able to put-off rewriting/recompiling lots of pieces of MacOS (Classic) itself for a long time. That's because the "new host" CPU runs NATIVE CODE.
I mentioned such binary to binary translation in another post, better than emulation, not quite as good as recompiling but often "good enough". The problem with Windows on ARM and translation of x86 code is that not all users will be able to move to that version of Windows.They may have a legacy version of Windows, they may not want to spend the money to buy a second version of Windows. Genuine emulation will be necessary for some.
More so for emulation, less so for binary to binary translation, I found such things to largely be practical only for short tasks. Minutes not hours. After about 15 minutes the sluggishness would annoy me. I prefer dual booting to Windows for tasks taking hours. And natively recompiled apps seemed an improvement over running the translations. Generating a binary from source code rather than another binary has many advantages. But unlike emulations, translation is more likely to be "good enough" to be tolerable.
"Blockchain" was the buzzword last year with VC and Angel investors. At trade shows / conferences / etc where entrepreneurs were demoing products / services many investors could not help themselves, they had to ask about and ponder if "blockchain" could somehow be "incorporated" into the product / service in order to make it a more viable investment.
Using the word "blockchain" in 2018 was like using the word "internet" in 1999. It made every business venture "better". Lets see how 2019 goes.
That said, blockchain is useful, just like the internet. Useful as a public ledger, but not everything needs a public ledger.
That's still an iPad not a Mac. In the comment, by "computer" I was referring to a Mac. As indicated by the subject line.
:-)
If you want to argue about a "computer" in general I'm fine with that. I hate that smart phones are called "phones", I think of them as handheld computers given that phone is a relatively minor feature and they are really a more general purpose device. A computer with lots of built-in sensors. But Macs becoming iOS devices, all Macs only getting software from the Mac App Store, all Macs going ARM, no, these things are highly unlikely.
Plus Apple doesn't consider an iPad Pro with a keyboard to be a "computer", haven't you seen the TV commercial?
They are not going to turn computers into giant iOS devices.
They are not going to lock out 3rd party software distribution for computers.
They are probably not going to to switch all Macs to ARM.
What they are probably going to do is launch a MacBook Air that is ARM. macOS, its built-in applications and Apple's optional apps on the Mac App Store will be recompiled for ARM. Some people need nothing more than a mail client, a browser and a productivity suite like Apple's Pages, Numbers and Keynote. Such people will get along quite nicely on such a system. The MacBook Pro will remain Intel based for Windows support and legacy software support with full performance. Apple will encourage 3rd party developers to recompile for ARM but they will also probably offer an x86 binary to ARM binary conversion tool for legacy software that is not recompiled. This converted code will run better than x86 in an emulator but not as well as recompiled, in short it will probably be "good enough". Over time an ARM based Mac will become more capable for people that do not need Windows. However for the huge segment of Mac users that do need Windows some Macs will remain Intel based. Again, when Apple went Intel their marketshare doubled as people no longer had to choose PC or Mac, when people could get both on the same machine. Apple will continue to offer such machines however perhaps not at the entry level, MacBook Air, etc.
What about Boot Camp? Presumably it goes away. I wonder how many people will find running Windows in a VM (especially one that has to emulate the CPU) will find have problems with that solution?
Look to the PowerPC era, emulation worked but it was not really practical to use. When Apple switched to Intel their marketshare doubled. With Boot Camp people no longer had to chooser Mac or PC, they could have both on the same computer. Switch to ARM and we are back having to make that choice.
Similar background :-)
... switching to a non-x86 CPU would be a return to the bad old days where people had to chooser Mac or PC. Presumably bringing back that choice would cut Apple's sales in half.
In theory apps will need to be recompiled by the developers. That is probably the best solution.
However another solution is to have software translate an x86 binary into an ARM binary. You still get native architecture speed but perhaps there is inefficiency since you started with an x86 binary, Source code would have provided more information and more opportunities to optimize the code. I'd lean towards this binary translation solution. Universal and likely good enough. To be clear I expect macOS, its bundled application and Apple's productivity applications will be recompiled and fully native. This binary translation is more for the 3rd party mac apps.
Then there is emulation. Doable but there is a big performance hit when you have to emulate the CPU architecture. When Apple switched to Intel and PC emulators no longer had to emulate the x86 architecture emulation the Windows environment became practical for some users.
The folks suggesting that iOS will replace macOS are almost certainly guessing wrong. macOS and iOS share some core operating system code and various APIs, but where their respective libraries and APIs begin to differ tends to be related to the user experience and the mobile user experience isn't going to work on a laptop or desktop. I think Apple has already made comments along these lines.
Additionally, until MS Windows on ARM is a common office and household operating system I doubt Apple will completely abandon Intel. Apple's marketshare doubled when users no longer had to choose PC or Mac, when they could run both macOS and MS Windows on the same computer. Boot into either operating system as required by the software they needed to run. Since Windows on ARM is not a common operating system, since Windows on x86 is what people overwhelmingly have and will need to be able to run
What people *might* be grossly exaggerating is a chromebook competitor. An ARM based Mac where macOS and its bundled applications and Apple's productivity software (word processor, spreadsheet, slideshow, etc) have all been recompiled for ARM. There are many users who would use nothing beyond these apps and a web browser. For them MS Windows and 3rd party Mac software are irrelevant and an ARM based Mac that has much better battery endurance would be great. Think of something like the MacBook Air moving to the ARM CPU but the MacBook Pro staying Intel.
Torvalds is mistaken, price dictated x86 Linux replacing traditional *nix RISC vendors. The argument regarding developers wanting the same hardware in the field as in their desktop PC is erroneous. Most *nix software does not care what the underlying hardware is. They may want the same operating system and software stack but that is something quite different than the underlying hardware. If RedHat and Ubuntu offered their respective Linux distributions on ARM and the ARM servers were less expensive to buy and operate they would be used by many and their server side software would not know or care if its Intel or ARM under the hood.
So this means no more boot camp as well?
Sure, but who wants that
Apple's market share literally doubled after switching to Intel and allowing Windows to dual boot. One of the biggest stumbling blocks to get people to switch to Mac was their need to use Windows (and before that MS-DOS) software. Once you could dual boot MacOS or Windows you no longer had to choose PC or Mac, you could have one computer that could run either software family.
... bad news for Apple.
Regarding emulation, it worked but was not practical. It barely works today where it does *not* have to emulate the CPU architecture. A switch to ARM would impose a huge burden on emulators and seriously and negatively impact performance.
While Microsoft might offer Windows on ARM you would have a lot of PC software that will not be recompiled for ARM. So dual booting ARM MacOS or ARM Windows gets you back to the bad old days of having the choose PC (ie x86) or something-not-PC. Good news for Dell, HP, etc
If someone had told you in 1978 that in 30 years you would be able to run your Unix programs on a device that fits in your pocket, would you have dismissed it as a fucking toy?
No we would have complained that it can't possibly take 30 years.
The proprietary *nix RISC based boxes were displaced before 64-bit AMD. It didn't matter if Linux was slower, very few needed the additional performance of Sun, SGI, etc. Linux on commodity PC displaced these traditional *nix vendors both in workstation and server environments. MS Windows Server was also having some success against them due to cost but Linux thwarted MS' ambitions here as well. By the time 64-bit was available Linux was already the "winner" server side.
"Develop at home" is really a proxy for "develop/deploy on cheapest". What applications, what software stacks, care about the underlying hardware architecture? If cloud based servers ran non-x86 hardware few would notice or care. If cloud server costs for non-x86 hardware were cheaper and performed adequately they would get used. x86 Linux won because it was cheaper than the traditional Unix vendors with their proprietary *nix RISC based platforms. Similar on the workstation side. The shift from RISC *nix boxes to x86 Linux was overwhelmingly about cost, almost no software cared which it ran on.
Linux x86 to Linux ARM would be a virtually unnoticeable transition for nearly all. Again assuming adequate performance for the money. It was about price in RISC *nix days, it will be about price in ARM days.
x86 won on price, on the desktop, on the server. That is the simple truth.
As for stability and bugs, cross platform is superior. Bugs that are hard to manifest on one hardware architecture may manifest quite readily on a different architecture. Having worked on various cross-platform projects I've seen the main x86 based dev teams visit the alternative architecture teams (ex PPC) when they are stumped debugging, they eventually appreciated the alternative architectures. A single architecture target allows for longer lived quirky bugs. The simple truth is that cost is more important to many.
This is not to say ARM will be successful in server space, just that it will be about cost and little else.
From a conversation among the grownups. Something modeled on the Coast Guard rather than the Air Force since we have regulatory compliance, defense and force projection.
https://spacenews.com/space-fo...
Did you mean WinNT 3.1? Win 3.x was 16-bit. We didn't get a clean 32-bit environment until WinNT. Win9x was a 16/32-bit hybrid environment, I'm not sure if drivers were 32-bit.