Google's adding requirements that apps need to be targeted to the last major release (e.g., as of October (?) this year they need to target Oreo). It's just for updates and new apps for now but they know this problem and are working on it.
If I understand things correctly that change does not really address this problem. Many of those phones cannot upgrade, this includes phones currently sold. Last I checked a few months ago an inexpensive pay-as-you-go phone at Walmart could be stuck at Android 4.4 KitKat. Plus this change is only addressing the lazy developers that just targeted 4.4 KitKat and use an ancient SDK and libraries and rely on that running everywhere. While google may require that apps target the current major release and use a current SDK and libraries they will still allow compatibility with the old versions. The developer will have to target Android 8 Oreo and add conditionals as necessary to support deprecated and other 4.4 targeting code. Google is not making anyone drop support for old versions. If they did that many phones would become unreachable to developers. I believe google is just requiring that developers use current SDKs and libraries, and at least indirectly have better "native" support for the current Android version. Yes "native" is a somewhat overloaded term here but I hope you get my meaning, current SDK/libs better support for current Android. And I'm sure that google also hopes developers will be a little less lazy and perhaps support some feature only offered in the current OS. There are probably also newer things that developers will be forced to support, for example newer security models.
Around 85% of smartphones worldwide are Android. THAT is why you're not making any more. Maybe follow the lead of most PC software manufacterer's and ignore Apple and their tiny market share. They're not worth the time and hassle.
Research from a few years ago showed that iOS apps had over 5x the revenue per download as Android apps. I believe the methodology was to compare Apple's and Google's published data for number of apps downloads over the year and the amount paid to 3rd party app developers over that same year.
Now consider the nature of many of those phones. According to Apple's and Google's current statistics to reach 90% of the current visitors to their respective app stores an Android app has to target the last 4 major version of Android and an iOS app the last 2 major versions, the preceding includes the current version. This increases development and testing costs for Android apps.
Its quite naive to think things are as simple as the number of phones on each platform. Perhaps you aren't qualified to call others idiots.
I'm kind of fuzzy on whether Linux or NT came first. As a developer I started using Linux and NT about the same time, 1993 IIRC, configuring the PC to multi-boot DOS/Win31, WinNT or Linux.
I started noting Linux displacing traditional *nix at the university. Professors who could not explain why they had to have a Sun/SGI box got a commodity PC running Linux. Student labs also got PCs running Linux, however an interesting thing happened there. Linux was the gateway to Windows for the student labs. Linux replaced the traditional *nix workstations with commodity PCs and students asked that these PCs also be able to run Windows. So the lab's PCs could dual boot Linux or Windows. Linux opened the CS lab doors to Windows. Before that it was all *nix, either terminals to VAX or traditional workstations.
Tell that to people who have several million dollars in bitcoin because they happened to get on board early.
The fact remains that they would have even more by buying on an exchange rather than mining at a loss. Holding does not change this simple fact. If you want to hold and mining is unprofitable buy on the exchange and hold, only mine and hold if you will get more coins than buying.
Microsoft crushed big iron UNIX with Windows NT. They got companies to abandon their own OS variants and use Windows NT instead.
Actually that was Linux. People running *nix tended to stay with *nix. Microsoft's OS was brand named "workstation" but it was not displacing traditional *nix workstations. *nix never really made it to the desktop of average workers, *nix users tended to be high end and specialized and remained so. DOS, OS/2 and Windows 3.x were what Windows NT displaced on the desktop.
Servers were a similar story. traditional *nix servers were largely displaced by Linux or FreeBSD. Windows server users tended to be those new to servers. Microsoft captured a large chunk of new users, of the growth, but not much displacing of existing *nix. And *nix captured a large chunk of the new users / growth too.
My point was that with cryptocurrencies whose value might rise over time, it may eventually exceed the value of electricity usage consumed when it was initially mined.
My point is that this is a "losing" strategy. If mining is not profitable today if a person takes the money they would have spent on electricity and uses it to buy coins directly on an exchange they will have more coins. In the future, after a rise, more coins (buying) will have more value than less coins (mining at a loss). A person motivated by profit should only mine today if it is profitable today, i.e. they get more coins buying electricity today than by buying coins directly.
Yes, technically the rise can get one from the red to the black. However that is suboptimal if the person's motivation are profit related. I wanted readers considering holding to understand this.
Anyone using any GPU will lose money mining cryptocurrency unless one is willing to wait until the currency rises significantly in value some amount of time after mining it.
No, holding is an illusion. If you cannot mine economically today its better to just buy the coins directly rather than buy electricity. You'll have more coins for that significant rise (if it occurs).
Gamers that are angry about miners are weird. Why don't they just mine at night and make a few bucks on the side?
Because
(1) You have to buy the card in the first place and they were difficult to find and insanely expensive. Basically many were priced out of buying.
(2) You will likely never mine enough to cover the difference between suggested retail and the 50% premiums we are now seeing, let alone the 100-200% premiums of a month or two ago.
Basically its not worth it to mine in your spare time unless you bought a card last summer before the price premiums.
Thinking you can make it up by holding coins for years doesn't work. You will likely have more if you just buys the coins directly after you consider retail electrical costs and the inflated GPU price.
Now once GPU prices return to MSRP and if you are careful about your power costs then yeah, maybe you can mine in your spare time. But if over a year 25% of your GPU is subsidized consider yourself fortunate.
Is personal responsibility really that foreign of a concept?
Yes, yes it is. Its never the person's fault. Its never their bad decisions. Its never a lack of self-control. Society made than instant gratification addicts.
To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
Forcing users to 64-bit might better prepare the user base for ARM CPU based Macs. It gets rid of a bit of the unsupported legacy software. More modern and/or currently supported software building on current tools is also software that is more likely to be rebuilt to support ARM, should such Macs appear. Such rebuilt software consisting of a fat binary with both 64-bit Intel and 64-bit ARM code. Sure the fat binary could also include 32-bit Intel but that would complicate developer, Apple and App Store testing for a possibly small benefit. And as other have mentioned the unsupported legacy software may also be an increasing security risk.
Tangent: I'm not expecting Apple to go all ARM. But perhaps an ARM version of a MacBook Air. Longer battery endurance, users more likely to use just the Apple supplied apps, web apps and only a small number of 3rd party apps if any?
My recollection from those days was "twice the performance for half the price", that CISC designs like x86 were peaking and that only RISC could continue on with performance increases. Maybe they were correct, x86 went RISC behind the scenes with its x86 to micro-ops scheme.
If I remember correctly CHRP was the "holy grail" that would finally let us natively run MacOS and Windows on the same box. Something we didn't really get until Apple went Intel. Microsoft was ready, supported PREP but Apple failed to deliver their CHRP box. I was eagerly awaiting the ability to have it all (native Windows, Linux, MacOS). However Apple did not undermine PowerPC and cause low volume. High volume required Windows users to migrate from Intel to PowerPC. The WinNT4 retail CD offered Intel and PowerPC binaries, dual PowerPC Windows boxes were reviewed and compared against dual Intel (P6 ?) Windows boxes in Byte magazine and found to be better performing in general (not media creation specific), better at multitasking. But consumers chose Intel, price and compatibility won. Would there be more interest had MacOS been available, sure, but that "more interest" was still minor in the grand scheme of things. The post-Intel doubling of Mac sales still only took Apple from 3%'ish to 6%'ish overall, not enough for high volume.
Media creation moved from Mac to Windows long before the modern Mac Pro. Intel nullified PowerPC's general performance advantage with high clock rates and as Intel offered improved SIMD functionality over the years the performance gap in specialized media creation operations narrowed.
Yes, computers have far greater longevity these days, even low end PCs offering vastly more power than average users require. Double the factory installed RAM and 8 years is plausible even with keeping your OS and apps updated. OK, maybe a GPU upgrade around year 4 would help. Yes Apple does not offer serious performance to consumers, the Pro is ridiculously expensive, but few consumers need serious performance. Where I have seen performance issues on friend and family Macs its generally been due to the modest amount of RAM installed at the factory, not the CPU. To be fair no one was trying to run video games on these Macs, the gamers knew to have a Windows box. My 7 year old MacBook Pro (i5 2.4GHz) is doing fine running macOS and Windows 10 natively since I upgraded RAM to 8GB back when I initially purchased it. Other than native execution of ARM iOS binaries I see no performance advantage for an ARM CPU in a Mac; and to avoid performance problems with legacy Intel apps that ARM would likely need to be a coprocessor, the Mac having both Intel and ARM (isn't the MacBook Pro Touch Bar driven by an ARM?). Again, I could see a specialized MacBook Air with ARM only, running mostly Apple apps which would have native ARM binaries, for consumers with modest needs. But for MacBook and especially MacBook Pro I think native Intel execution will be needed for a while yet.
macOS and iOS have always shared a bit of code, various frameworks. iOS has some frameworks that are derivatives of macOS. Were these derivatives inherently necessary or the result of scheduling pressure to release some version of iOS? If the latter it would make sense to refactor this code and have a common framework between the two OS.
Or the additions are to support running iOS apps on macOS. These seems far more likely than some sort of unified desktop and mobile OS.
Regarding Apple outperforming Intel on 64-bit x86, doubtful. Been there, done that, with PowerPC. PowerPC had all the advantages, should have outperformed Intel, but Intel worked f'n miracles and got x86 to performance levels that no one ever expected. Apple is doing great things with ARM designs, but the competitors they face there aren't exactly in Intel's league. No one, not even Apple, has the resources to throw at x86 performance that Intel has. I think a more likely option would be that Apple wants their GPU integrated into the package rather than Intel's GPU.
Being their own tertiary source for x86 CPUs (Intel and AMD being sources 1 and 2) might make sense. However is getting x86 fab'ed as "easy" as getting A11's fab'ed? How much capacity of the necessary process level is there outside of Intel and AMD (Global Foundries in recent years)?
Chromebooks are partly the inspiration for this macOS-only Mac Air notion. Although an important distinction between the two is that users would still have the flexibility of macOS and installable native apps from the Mac App Store, fat-binaries with Intel and ARM support of course. I'm sort of thinking an education market focus. Schools possibly being more OK with Apple's productivity apps (word processor, spreadsheet, presentation, etc) or Microsoft's and Google's online web-based counterparts.
two holes in an install with zero packages that can do nothing but ssh
yay?
Actually a common use for OpenBSD is a firewall and/or router. Built-in packages accomplish these and other infrastructure roles. Thus making the internet a safer place to tread for Linux boxes with whatever is the fad-of-the-moment development stack.;-)
Going Intel doubled Mac sales, going back to non-Intel may cut it in half. Intel CPUs removed a huge barrier to Mac purchases, needing Windows support. Windows emulation was available with non-Intel but not practical due to having to emulate the CPU architecture. Going Intel made dual boot and effective emulation possible. Consumers no longer had to chose Mac or Windows, they could have both on the same box.
I'm going with the theory that Apple routinely builds macOS on non-Intel just to ensure the code base is portable. It also helps with debugging, a hard to manifest bug on one architecture/compiler pair can sometimes be easy to manifest on another.
Or maybe its a specialized version of the MacBook Air without support for Windows? The MacBook (non-Pro) and MacBook Air are getting a bit too similar. Perhaps the Air will be dropped or morph into a specialized high endurance machine (long battery life) for people who only want macOS?
Or maybe its Intel GPUs they are abandoning, not CPUs.
So? And why would I assume you know what you are talking about? And how would you know what exactly I am using this for?
Your "I highly doubt that" suggests you have not used both, I have. I have also used Linux since '93'ish (Yggdrasil Plug-and-play Linux) and have used cygwin for years.
MS did an excellent job with their OS/2 subsystem for Windows back in the day, it seems as if the Linux subsystem for Windows is also getting similar serious attention. Cygwin has always been kinda kludgy, they did a fine job given their circumstances but it can't compete with an integrated supported subsystem.
Some of the largest cryptocurrency trading platforms, like Coinbase's GDAX, aren't registered as a national exchange with the SEC, and instead have money transmission licenses with separate states.
In other words its largely a non-issue for various US based exchanges. These exchanges are already trying to operate in a reasonable manner with governmental oversight and reporting.
There are ways to get the best of both worlds with Linux and Virtualization windows, or Wine. It really depends on which system you do your pirmary work, and which system, you are good with running in a slower mode.
Its likely neither will be perceivably slower. For years hardware has been so overpowered for most users that upgrades yield little perceived speedup, effective lives for machines going from 3 years to 7+ years. Hell even gamers can get 5+ years out of a system by loading up on RAM on day 1 and maybe upgrading a video card every couple of years.
A Linux subsystem for Windows is just as feasible as Wine. In practical terms most users would probably have fewer problems, gamers definitely would.
Virtualization, that's a tossup for me at least. If going virtualization the native OS would be a Linux server and both Desktop Linux and Windows would be hosted VMs. But that's my preference. And its only Desktop Linux that is under threat, not server Linux.
Linux is way too fucking big and popular to be squashed. It isn't just used by the unwashed IT professional, but too many corporations depend on it for Microsoft to be able to hurt the project.
It is not Linux on the server that is threatened. It is Linux on the Desktop that is threatened.
Some people find that some tasks are better performed under *nix. Linux as a Windows subsystem, as OS/2 once was, could work quite nicely. For software development this would also be quite convenient.
To see how this would help Windows and hinder Desktop Linux look to Mac OS X including a BSD environment and console and some *nix users finding this a better option than Linux. It will likely be a stronger trend under Windows given that the productivity apps and games that many want are native to Windows.
A Linux app running natively on the Windows desktop is a quite compelling user case.
So how does converting a US dollar tax bill amount to bitcoin in real time and providing a payment address, monitoring that payment address for confirmation, and then immediately converting those bitcoins to US dollars make a region a blockchain and cryptocurrencies tech hub? Especially when much of the preceding will likely be outsourced to an existing bitcoin payment processor.
Falcon Heavy has a much smaller payload capacity than Saturn V.
Good thing they can send 2 or 3 for less money.
As Airbus is learning quite painfully, larger payload isn't the ultimate metric.
The Saturn V was an amazing thing for its day. But needs and the optimal equipment changes. In the era of a few big missions, that Saturn V made sense. But now we are in the era of lots of small to medium sized missions, the Falcon Heavy makes more sense.
Reusable launch systems aren't new. Nothing about it is particularly remarkable.
Except the boosters that fly themselves back to the launch site and land on their tail. That, until Space X, was sci fi movie stuff.
Slashdot Mirror
has to target the last 4 major version of Android
Google's adding requirements that apps need to be targeted to the last major release (e.g., as of October (?) this year they need to target Oreo). It's just for updates and new apps for now but they know this problem and are working on it.
If I understand things correctly that change does not really address this problem. Many of those phones cannot upgrade, this includes phones currently sold. Last I checked a few months ago an inexpensive pay-as-you-go phone at Walmart could be stuck at Android 4.4 KitKat. Plus this change is only addressing the lazy developers that just targeted 4.4 KitKat and use an ancient SDK and libraries and rely on that running everywhere. While google may require that apps target the current major release and use a current SDK and libraries they will still allow compatibility with the old versions. The developer will have to target Android 8 Oreo and add conditionals as necessary to support deprecated and other 4.4 targeting code. Google is not making anyone drop support for old versions. If they did that many phones would become unreachable to developers. I believe google is just requiring that developers use current SDKs and libraries, and at least indirectly have better "native" support for the current Android version. Yes "native" is a somewhat overloaded term here but I hope you get my meaning, current SDK/libs better support for current Android. And I'm sure that google also hopes developers will be a little less lazy and perhaps support some feature only offered in the current OS. There are probably also newer things that developers will be forced to support, for example newer security models.
Around 85% of smartphones worldwide are Android. THAT is why you're not making any more. Maybe follow the lead of most PC software manufacterer's and ignore Apple and their tiny market share. They're not worth the time and hassle.
Research from a few years ago showed that iOS apps had over 5x the revenue per download as Android apps. I believe the methodology was to compare Apple's and Google's published data for number of apps downloads over the year and the amount paid to 3rd party app developers over that same year.
Now consider the nature of many of those phones. According to Apple's and Google's current statistics to reach 90% of the current visitors to their respective app stores an Android app has to target the last 4 major version of Android and an iOS app the last 2 major versions, the preceding includes the current version. This increases development and testing costs for Android apps.
Its quite naive to think things are as simple as the number of phones on each platform. Perhaps you aren't qualified to call others idiots.
I'm kind of fuzzy on whether Linux or NT came first. As a developer I started using Linux and NT about the same time, 1993 IIRC, configuring the PC to multi-boot DOS/Win31, WinNT or Linux.
I started noting Linux displacing traditional *nix at the university. Professors who could not explain why they had to have a Sun/SGI box got a commodity PC running Linux. Student labs also got PCs running Linux, however an interesting thing happened there. Linux was the gateway to Windows for the student labs. Linux replaced the traditional *nix workstations with commodity PCs and students asked that these PCs also be able to run Windows. So the lab's PCs could dual boot Linux or Windows. Linux opened the CS lab doors to Windows. Before that it was all *nix, either terminals to VAX or traditional workstations.
Tell that to people who have several million dollars in bitcoin because they happened to get on board early.
The fact remains that they would have even more by buying on an exchange rather than mining at a loss. Holding does not change this simple fact. If you want to hold and mining is unprofitable buy on the exchange and hold, only mine and hold if you will get more coins than buying.
Microsoft crushed big iron UNIX with Windows NT. They got companies to abandon their own OS variants and use Windows NT instead.
Actually that was Linux. People running *nix tended to stay with *nix. Microsoft's OS was brand named "workstation" but it was not displacing traditional *nix workstations. *nix never really made it to the desktop of average workers, *nix users tended to be high end and specialized and remained so. DOS, OS/2 and Windows 3.x were what Windows NT displaced on the desktop.
Servers were a similar story. traditional *nix servers were largely displaced by Linux or FreeBSD. Windows server users tended to be those new to servers. Microsoft captured a large chunk of new users, of the growth, but not much displacing of existing *nix. And *nix captured a large chunk of the new users / growth too.
My point was that with cryptocurrencies whose value might rise over time, it may eventually exceed the value of electricity usage consumed when it was initially mined.
My point is that this is a "losing" strategy. If mining is not profitable today if a person takes the money they would have spent on electricity and uses it to buy coins directly on an exchange they will have more coins. In the future, after a rise, more coins (buying) will have more value than less coins (mining at a loss). A person motivated by profit should only mine today if it is profitable today, i.e. they get more coins buying electricity today than by buying coins directly.
Yes, technically the rise can get one from the red to the black. However that is suboptimal if the person's motivation are profit related. I wanted readers considering holding to understand this.
Anyone using any GPU will lose money mining cryptocurrency unless one is willing to wait until the currency rises significantly in value some amount of time after mining it.
No, holding is an illusion. If you cannot mine economically today its better to just buy the coins directly rather than buy electricity. You'll have more coins for that significant rise (if it occurs).
GPU mining is sort of a hobbyist thing, the clusters tend to be pros with ASIC hardware. Can't reprogram them.
Gamers that are angry about miners are weird. Why don't they just mine at night and make a few bucks on the side?
Because
(1) You have to buy the card in the first place and they were difficult to find and insanely expensive. Basically many were priced out of buying.
(2) You will likely never mine enough to cover the difference between suggested retail and the 50% premiums we are now seeing, let alone the 100-200% premiums of a month or two ago.
Basically its not worth it to mine in your spare time unless you bought a card last summer before the price premiums.
Thinking you can make it up by holding coins for years doesn't work. You will likely have more if you just buys the coins directly after you consider retail electrical costs and the inflated GPU price.
Now once GPU prices return to MSRP and if you are careful about your power costs then yeah, maybe you can mine in your spare time. But if over a year 25% of your GPU is subsidized consider yourself fortunate.
Is personal responsibility really that foreign of a concept?
Yes, yes it is. Its never the person's fault. Its never their bad decisions. Its never a lack of self-control. Society made than instant gratification addicts.
To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
Forcing users to 64-bit might better prepare the user base for ARM CPU based Macs. It gets rid of a bit of the unsupported legacy software. More modern and/or currently supported software building on current tools is also software that is more likely to be rebuilt to support ARM, should such Macs appear. Such rebuilt software consisting of a fat binary with both 64-bit Intel and 64-bit ARM code. Sure the fat binary could also include 32-bit Intel but that would complicate developer, Apple and App Store testing for a possibly small benefit. And as other have mentioned the unsupported legacy software may also be an increasing security risk.
Tangent: I'm not expecting Apple to go all ARM. But perhaps an ARM version of a MacBook Air. Longer battery endurance, users more likely to use just the Apple supplied apps, web apps and only a small number of 3rd party apps if any?
My recollection from those days was "twice the performance for half the price", that CISC designs like x86 were peaking and that only RISC could continue on with performance increases. Maybe they were correct, x86 went RISC behind the scenes with its x86 to micro-ops scheme.
If I remember correctly CHRP was the "holy grail" that would finally let us natively run MacOS and Windows on the same box. Something we didn't really get until Apple went Intel. Microsoft was ready, supported PREP but Apple failed to deliver their CHRP box. I was eagerly awaiting the ability to have it all (native Windows, Linux, MacOS). However Apple did not undermine PowerPC and cause low volume. High volume required Windows users to migrate from Intel to PowerPC. The WinNT4 retail CD offered Intel and PowerPC binaries, dual PowerPC Windows boxes were reviewed and compared against dual Intel (P6 ?) Windows boxes in Byte magazine and found to be better performing in general (not media creation specific), better at multitasking. But consumers chose Intel, price and compatibility won. Would there be more interest had MacOS been available, sure, but that "more interest" was still minor in the grand scheme of things. The post-Intel doubling of Mac sales still only took Apple from 3%'ish to 6%'ish overall, not enough for high volume.
Media creation moved from Mac to Windows long before the modern Mac Pro. Intel nullified PowerPC's general performance advantage with high clock rates and as Intel offered improved SIMD functionality over the years the performance gap in specialized media creation operations narrowed.
Yes, computers have far greater longevity these days, even low end PCs offering vastly more power than average users require. Double the factory installed RAM and 8 years is plausible even with keeping your OS and apps updated. OK, maybe a GPU upgrade around year 4 would help. Yes Apple does not offer serious performance to consumers, the Pro is ridiculously expensive, but few consumers need serious performance. Where I have seen performance issues on friend and family Macs its generally been due to the modest amount of RAM installed at the factory, not the CPU. To be fair no one was trying to run video games on these Macs, the gamers knew to have a Windows box. My 7 year old MacBook Pro (i5 2.4GHz) is doing fine running macOS and Windows 10 natively since I upgraded RAM to 8GB back when I initially purchased it. Other than native execution of ARM iOS binaries I see no performance advantage for an ARM CPU in a Mac; and to avoid performance problems with legacy Intel apps that ARM would likely need to be a coprocessor, the Mac having both Intel and ARM (isn't the MacBook Pro Touch Bar driven by an ARM?). Again, I could see a specialized MacBook Air with ARM only, running mostly Apple apps which would have native ARM binaries, for consumers with modest needs. But for MacBook and especially MacBook Pro I think native Intel execution will be needed for a while yet.
macOS and iOS have always shared a bit of code, various frameworks. iOS has some frameworks that are derivatives of macOS. Were these derivatives inherently necessary or the result of scheduling pressure to release some version of iOS? If the latter it would make sense to refactor this code and have a common framework between the two OS.
Or the additions are to support running iOS apps on macOS. These seems far more likely than some sort of unified desktop and mobile OS.
Regarding Apple outperforming Intel on 64-bit x86, doubtful. Been there, done that, with PowerPC. PowerPC had all the advantages, should have outperformed Intel, but Intel worked f'n miracles and got x86 to performance levels that no one ever expected. Apple is doing great things with ARM designs, but the competitors they face there aren't exactly in Intel's league. No one, not even Apple, has the resources to throw at x86 performance that Intel has. I think a more likely option would be that Apple wants their GPU integrated into the package rather than Intel's GPU.
Being their own tertiary source for x86 CPUs (Intel and AMD being sources 1 and 2) might make sense. However is getting x86 fab'ed as "easy" as getting A11's fab'ed? How much capacity of the necessary process level is there outside of Intel and AMD (Global Foundries in recent years)?
Chromebooks are partly the inspiration for this macOS-only Mac Air notion. Although an important distinction between the two is that users would still have the flexibility of macOS and installable native apps from the Mac App Store, fat-binaries with Intel and ARM support of course. I'm sort of thinking an education market focus. Schools possibly being more OK with Apple's productivity apps (word processor, spreadsheet, presentation, etc) or Microsoft's and Google's online web-based counterparts.
two holes in an install with zero packages that can do nothing but ssh yay?
Actually a common use for OpenBSD is a firewall and/or router. Built-in packages accomplish these and other infrastructure roles. Thus making the internet a safer place to tread for Linux boxes with whatever is the fad-of-the-moment development stack. ;-)
Going Intel doubled Mac sales, going back to non-Intel may cut it in half. Intel CPUs removed a huge barrier to Mac purchases, needing Windows support. Windows emulation was available with non-Intel but not practical due to having to emulate the CPU architecture. Going Intel made dual boot and effective emulation possible. Consumers no longer had to chose Mac or Windows, they could have both on the same box.
I'm going with the theory that Apple routinely builds macOS on non-Intel just to ensure the code base is portable. It also helps with debugging, a hard to manifest bug on one architecture/compiler pair can sometimes be easy to manifest on another.
Or maybe its a specialized version of the MacBook Air without support for Windows? The MacBook (non-Pro) and MacBook Air are getting a bit too similar. Perhaps the Air will be dropped or morph into a specialized high endurance machine (long battery life) for people who only want macOS?
Or maybe its Intel GPUs they are abandoning, not CPUs.
So? And why would I assume you know what you are talking about? And how would you know what exactly I am using this for?
Your "I highly doubt that" suggests you have not used both, I have. I have also used Linux since '93'ish (Yggdrasil Plug-and-play Linux) and have used cygwin for years.
MS did an excellent job with their OS/2 subsystem for Windows back in the day, it seems as if the Linux subsystem for Windows is also getting similar serious attention. Cygwin has always been kinda kludgy, they did a fine job given their circumstances but it can't compete with an integrated supported subsystem.
I highly doubt that.
I've used both.
Some of the largest cryptocurrency trading platforms, like Coinbase's GDAX, aren't registered as a national exchange with the SEC, and instead have money transmission licenses with separate states.
In other words its largely a non-issue for various US based exchanges. These exchanges are already trying to operate in a reasonable manner with governmental oversight and reporting.
The Linux subsystem for windows is much better than cygwin.
There are ways to get the best of both worlds with Linux and Virtualization windows, or Wine. It really depends on which system you do your pirmary work, and which system, you are good with running in a slower mode.
Its likely neither will be perceivably slower. For years hardware has been so overpowered for most users that upgrades yield little perceived speedup, effective lives for machines going from 3 years to 7+ years. Hell even gamers can get 5+ years out of a system by loading up on RAM on day 1 and maybe upgrading a video card every couple of years.
A Linux subsystem for Windows is just as feasible as Wine. In practical terms most users would probably have fewer problems, gamers definitely would.
Virtualization, that's a tossup for me at least. If going virtualization the native OS would be a Linux server and both Desktop Linux and Windows would be hosted VMs. But that's my preference. And its only Desktop Linux that is under threat, not server Linux.
Linux is way too fucking big and popular to be squashed. It isn't just used by the unwashed IT professional, but too many corporations depend on it for Microsoft to be able to hurt the project.
It is not Linux on the server that is threatened. It is Linux on the Desktop that is threatened.
Some people find that some tasks are better performed under *nix. Linux as a Windows subsystem, as OS/2 once was, could work quite nicely. For software development this would also be quite convenient.
To see how this would help Windows and hinder Desktop Linux look to Mac OS X including a BSD environment and console and some *nix users finding this a better option than Linux. It will likely be a stronger trend under Windows given that the productivity apps and games that many want are native to Windows.
A Linux app running natively on the Windows desktop is a quite compelling user case.
So how does converting a US dollar tax bill amount to bitcoin in real time and providing a payment address, monitoring that payment address for confirmation, and then immediately converting those bitcoins to US dollars make a region a blockchain and cryptocurrencies tech hub? Especially when much of the preceding will likely be outsourced to an existing bitcoin payment processor.
Yes, anyone can see that. But do they understand it?
But how many get the parallels to the animated movie "Heavy Metal"?
https://www.youtube.com/watch?...
Falcon Heavy has a much smaller payload capacity than Saturn V.
Good thing they can send 2 or 3 for less money.
As Airbus is learning quite painfully, larger payload isn't the ultimate metric.
The Saturn V was an amazing thing for its day. But needs and the optimal equipment changes. In the era of a few big missions, that Saturn V made sense. But now we are in the era of lots of small to medium sized missions, the Falcon Heavy makes more sense.
Reusable launch systems aren't new. Nothing about it is particularly remarkable.
Except the boosters that fly themselves back to the launch site and land on their tail. That, until Space X, was sci fi movie stuff.