So what alternatives are to x86? A bit of OpenPOWER...

Page 4 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Exophase

Diamond Member
Apr 19, 2012
4,439
9
81
Yeah right.... As is you don't have to use Single User Mode or Terminal when a Mac gets scrambled.....

We've officially sunk to a new low on this forum.

I think it's a fair assumption that most users can't or won't resort to fixing problems on the command line.

If this happens on a Windows or Mac machine there's probably someone easily identifiable they can take it to to get it fixed. For anything else it's going to be a lot harder to deal with.
 

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Thats because Windows Store Apps is a diferent software ecosystem with mobile in mind, its not the same crap you will run on desktop, well, actually it is now since every Windows Store App that you will on a Windows 8.1/10 is coded in the same way.

I did not restrict my statement to store apps. Even the desktop part of the Surface 2 performs excellent. Of course there might be apps which are slow on such a machine however my statement was directed against the argument, that Windows itself is too slow on ARM processors.
The irony, Microsofts own mobile OS, Windows 10 mobile performs worse on faster CPU than the full fledged Windows on the Surface 2.

Linux is not based on FreeBSD.

How could it even? Linux is older than FreeBSD.
 
Last edited:

zir_blazer

Golden Member
Jun 6, 2013
1,164
406
136
FreeBSD itself might be younger than Linux, but the various BSD variants (including the one on which Apple based OS X) are much older than Linux. There's a nice picture on Wikipedia.
Just that you are forgetting that both Linux and BSD are Unix derived. And Linux is Minix inspired, which is itself Unix.
 
Last edited:

DrMrLordX

Lifer
Apr 27, 2000
21,617
10,824
136
Unless you want to run Android or iOS on a desktop I don't really see much relevance in any ARM ecosystems. And there aren't people who actually want to run Android or iOS on desktops, are there?

It's hard to say whether or not people want to support their mobile usage habits with a complementary desktop. My initial guess is that they mostly would not . . . people who buy into the cloud concept are not really going to need a desktop for syncing between devices, which is something that desktops are still good for, to an extent.

If there were some apps that ran badly even on the latest/greatest mobile devices that you could run better on an ARM desktop/laptop running one of the Linux distros aimed at Android (or really any Linux distro with ARC + Chrome), maybe it would work out. It seems that Google would probably want their Chromebooks to fulfill that niche, or . . . something along those lines.

I can't really make the case for an Android-oriented ARM desktop, though. Not without knowing what would be the primary motive(s) for an Android user to buy such a thing. What's the killer app? Better mobile gaming experience? I dunno.

To really be viable it'd have to be in a similar performance class as the usual x86 desktop processors, and POWER8 can claim that while no realistically available ARM CPU really can yet.. I think we're really going to need to see processors made with such targets in mind, or at least a lot higher targets than phones.

Do remember that your average consumer that is mostly being drawn away from the desktop/laptop world and into the phone/phablet/tablet world may have a very dismal view of what is an "x86 desktop processor". Yes, even 1P POWER8 systems can hang with some seriously beefy x86 CPUs, but it wouldn't take much more than a Seattle-based quad (for example) to match or beat something like a J1900 or an E1 (ugh).
 

jardows

Member
Oct 17, 2011
42
1
71
The key to this issue is the applications. Trying to make ARM or POWER8 do the same thing that x86 does, only "better" will not work. Why has ARM gained such a marketshare in computing devices? Because the application that ARM serves is completely different. ARM works great in phone and tablet style devices, which are used differently than a traditional x86 computer. What POWER8 really need to be a "competitor" or valid alternative to x86 is a way of computing that is different, if not superior to how we use x86 computers.

What is that? I don't know. It is going to take a great technology visionary to see the potential. On a technical side, we will likely need a unique operating system for POWER8 to harness it's full potential, rather than just a port of OS's built on the x86 paradigm.
 

NTMBK

Lifer
Nov 14, 2011
10,232
5,012
136
The key to this issue is the applications. Trying to make ARM or POWER8 do the same thing that x86 does, only "better" will not work. Why has ARM gained such a marketshare in computing devices? Because the application that ARM serves is completely different. ARM works great in phone and tablet style devices, which are used differently than a traditional x86 computer. What POWER8 really need to be a "competitor" or valid alternative to x86 is a way of computing that is different, if not superior to how we use x86 computers.

What is that? I don't know. It is going to take a great technology visionary to see the potential. On a technical side, we will likely need a unique operating system for POWER8 to harness it's full potential, rather than just a port of OS's built on the x86 paradigm.

They could always run OSX on it :awe:
 

jhu

Lifer
Oct 10, 1999
11,918
9
81
https://en.wikipedia.org/wiki/FreeBSD

Linux is a relative.... Just licensed differently. They both share similar commands from its Unix origins. Most of the difference is based on how the code is contributed -- with FreeBSD coming from a single source and Linux having many different sources/distros.

Linux is not a relative. FreeBSD/OpenBSD/NetBSD are all direct source code descendant of the original AT&T Unix. Linux is completely new code that shared nothing with those. The GNU userland that is usually associated as "Linux" also shares no original code from Unix/*BSD. They're all more or less functionally equivalent, but they're not related at all.
 

MarkizSchnitzel

Senior member
Nov 10, 2013
401
31
91
Do you think ARM plans on regressing their IPC? :D

You are 100% correct though, OEM support is the sticking point.

Surely dev support as well?

Ok, not that important in consumer space, at least until MS really develops Windows on ARM, or Android somehow beat Windows on desktop.
 

MiddleOfTheRoad

Golden Member
Aug 6, 2014
1,123
5
0
Linux is not a relative. FreeBSD/OpenBSD/NetBSD are all direct source code descendant of the original AT&T Unix. Linux is completely new code that shared nothing with those. The GNU userland that is usually associated as "Linux" also shares no original code from Unix/*BSD. They're all more or less functionally equivalent, but they're not related at all.

Sorry, but no...

As the term relative refers to family / lineage -- and since they both had the same father in Unix. You are grasping the meaning of family/relative.

You don't need to have identical code to be part of the same Unix-like OS family:
That would be like saying Android has nothing to do with Linux. That would also be incorrect. They both trace back to Unix even before the fork.

Another example is ReactOS which is a clean sheet OS.... Yet at the end of the day, it still belongs to the Windows family. Different code/programmers doesn't change its family.
 
Last edited:

jhu

Lifer
Oct 10, 1999
11,918
9
81
Sorry, but no...

As the term relative refers to family / lineage -- and since they both had the same father in Unix. You are grasping the meaning of family/relative.

You don't need to have identical code to be part of the same Unix-like OS family:
That would be like saying Android has nothing to do with Linux. That would also be incorrect. They both trace back to Unix even before the fork.

Another example is ReactOS which is a clean sheet OS.... Yet at the end of the day, it still belongs to the Windows family. Different code/programmers doesn't change its family.

If you want to go that way, Windows and ReactOS are actually part of the VMS family.
 

Nothingness

Platinum Member
Jul 3, 2013
2,400
733
136
If you want to go that way, Windows and ReactOS are actually part of the VMS family.
Come on, Windows is a UNIX relative: with MinGW/MSYS or Cygwin I have all UNIX commands!!!!!!!!1111111! The only difference is the license... Sorry, couldn't resist.
 

Essence_of_War

Platinum Member
Feb 21, 2013
2,650
4
81
Sorry, but no...

As the term relative refers to family / lineage -- and since they both had the same father in Unix. You are grasping the meaning of family/relative.

MiddleOfTheRoad said:
Linux is a relative.... Just licensed differently. They both share similar commands from its Unix origins. Most of the difference is based on how the code is contributed -- with FreeBSD coming from a single source and Linux having many different sources/distros.

jhu said:
Linux is not a relative. FreeBSD/OpenBSD/NetBSD are all direct source code descendant of the original AT&T Unix. Linux is completely new code that shared nothing with those. The GNU userland that is usually associated as "Linux" also shares no original code from Unix/*BSD. They're all more or less functionally equivalent, but they're not related at all.

jhu is absolutely correct and while it may be correct to say that BSD and Gnu+Linux are related in the sense that they share a "unix philosophy", saying that they're related in any deeper way is quite misleading, and the claim that the differences are principally "just licensed differently" and "how the code is contributed" is disturbing and indicates to me that you're not really familiar with the differences.

One of the reasons why this point of source-code relation is sort of important is that some sort of GNU-userland OS very nearly existed that would have been extremely closely related to BSD

http://www.groklaw.net/article.php?story=20050727225542530
The GNU Hurd is the GNU project's replacement for the UNIX kernel. The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the UNIX kernel or similar kernels (such as Linux). Thomas told me:
RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today. RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.
So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint.
This was all way before Linux; we're talking 1991 or so.
As a result of the userland being built first and the kernel being sort of slotted in later, linux distro development is very different from BSD development. BSD has a notion of a "Base System" where the kernel and the core utilities are developed together and you don't get to grab random kernel versions and combine them with random versions of core utilities. They are built up and packaged only as a unit. By contrast, the linux kernel comes with just the kernel and a distro maker walks up to the software buffet and picks whatever pieces they want from there. This is not simply a difference in code licensing and code contribution. A BSD base system is much more like a minimal installation of a linux distro (like say ubuntu or debian minimal) than it is like either the linux kernel or the gnu userland.