Anyone thinking that ARM isn't going to pass up x86 within the next 5 years is lying to themselves.
ARM is going to catch up speedwise, and you will start seeing more ARM laptops and low-end Facebook PCs. Which are most of the desktop sales. Normies just need the Internet and Office, which has been developed for iOS and Android.
Android & Apple TV boxes are just starting to become popular. The newest Tegra platform is already at Xbox 360/PS3 levels of power at a $200 price point. It's only a matter of time before they deprecate consoles.
I'm not even going to MENTION the fact that ARM is completely dominating the mobile market.
x86 will just be a legacy platform. Kind of like PowerPC.
Whats wrong with core m?
ARMv8 based cores already have caught up to mobile X86. Surpassing high performance X86 is an entirely different matter.
>>51264665
Real TDP is significantly higher than intel lists, and it throttles extremely hard under even moderate workloads. 1ghz or 1.1ghz base clock for a lot of parts, burst turbo on some can reach around 2.7ghz, but for fractions of a second. Under heavy workloads they can drop down to 800mhz. CPU+GPU workloads are a disaster.
Isn't ARM basically a follow-up of PowerPC? Also it's all up to Apple, Windows and Intel if ARM is going to make it as a mainstream PC architecture. Not to mention Adobe and Autodesk.
>>51264741
>Isn't ARM basically a follow-up of PowerPC?
No.
>Also it's all up to Apple, Windows and Intel if ARM is going to make it as a mainstream PC architecture.
Its probably not going to happen, but Microsoft already has a build of Windows 10 for ARM. If they get more serious about supporting that then it could become common and cheap laptops.
Bottom line is that X86 is never going anywhere unless the thing that replaces it has total software compatibility.
>>51264665
You can get an octa-core ARM box with 2GB of RAM for less than $100, with less than half of the power consumption.
>>51264776
>Windows 10 iot
>Beeing anywhere near a mainstream Windows
It may happen tho, since it's a step forwards from noth having ARM based systems at all. Do you think Apple will go ARM too? I mean it would make sense for them, last I heard is that they don't like Intel.
>>51264741
Linux is supported on ARM. Android and iOS are also designed for ARM, but they aren't really desktop-centric. Yet.
>>51264630
ARM has technically already surpassed x86.
ARM processors already dominate the mobile market, which is the vast majority of products.
>>51264833
Apple has enough clout in the industry that they could drag software vendors kicking and screaming if they really wanted to make the transition. They could come out with a 2016 or 2017 Macbook powered by a quad core A10X chip as a successor to their current Broadwell CoreM Macbooks.
A move like that would inevitably force big vendors like Adobe to port their software over, then Apple could unify software across all their mainstream devices. They've already showed interest in expanding functionality of iPads with their video editing software. The hardware is getting progressively more powerful so its capable of handling it.
iPhones
iPads
Macbooks
Apple TV
all running their internally designed ARM chips
I wouldn't bet on it, but its well within their power to make it happen.
I hope so. One problem, though, is that much of ARM land is SoCs, and most SoCs are proprietary and unique.
>>51264885
Yes I know, but Linux isn't exactly mainstream is it? Android and iOS are designed for mobile devices and no professional programs run on them as far as I know.
Which begs the question, could programs like photoshop run on ARM if Windows would or would Adobe have to fundamentally change the program to work?
>>51264921
You partially answered my question, I guess Microsoft would follow if Apple was to do that?
>>51264950
Linux is mainstream.
>Which begs the question, could programs like photoshop run on ARM if Windows would or would Adobe have to fundamentally change the program to work?
They would require a recompile.
>>51264950
Why is Windows (and to an extent, OSX) popular? I can see gaming being popular because the Linux drivers are dogshit, but mostly because of Office.
When Office gets an ARM port then there's literally no reason for normies to use Windows anymore. If you want to game, most prefer a console.
>>51264941
It's a step in the right direction though, since ARMs don't have microcode.
>>51265040
>Office
>Adobe Creative Cloud
>A fucton of Autodesk software
It's gonna take a while anon. It's popular since it's what normies know how to use, I mean you can barely force someone who has used XP to a newer OS, let alone a Linux distro.
>>51265068
What kind of BIOS do ARM mobos have? Can they support any ARM CPU if there is no microcode, I am very uneducated in the ARM market.
>>51265106
>What kind of BIOS do ARM mobos have?
As far as I know, it's chipset dependent.
>>51265106
>What kind of BIOS do ARM mobos have?
Like this >>51265154 anon said, it depends on the ship.
That's why making mobile OS ports/roms is such a pain the ass - you don't have the "common ground" of BIOS, and what low-level code works when booting one chipset is not guaranteed to work on the other.
>>51265154
>>51265198
I have an essay to make about modern CPUs, what should I include in the description of ARM. (And other instruction sets if you are up for helping me a bit)
x86 is shit
>>51265040
>Why is Windows (and to an extent, OSX) popular?
Because they have users, and people who want to sell their programs see this information, so they target the OSes with their programs, because they have the most users. I could make some comment about the Linux community being stretched too thin, but truthfully, it can't get software support from big-name companies until it has more users, and the users won't install it until it can run this software they want, so the cycle goes both ways. Some people just don't care, though. For many, they'd feel better if Linux was not popular or widely-supported by proprietary software, because they want it to be pure to their principles.
>>51264630
ARM just needs to offer PCIE lanes and a board with an ATX form factor and Intel will be an ARM company soon enough.
>>51265304
No, Intel standards need to die.
>>51264630
Yeah but who cares? The market dictates the product. The important thing is not what's in the computer, rather what it does.
Never going to happen.
Windows is x86. For x86 to die you have to kill windows.
And there is literally nothing in the market than can ever do that.
>>51264885
Interesting to think of things becoming more desktop centric at a time when people are bleating that the desktop is dead.
>>51264630
>not even going to MENTION the fact that ARM is completely dominating the mobile market
but you just did
you fucking dipshit.
2 words.
Intel atom.
>>51265414
Windows has been distributed for ARM since 7.
>>51264741
>Also it's all up to Apple, Windows and Intel if ARM is going to make it as a mainstream PC architecture.
PCs are dead. If you're doing video editing or Photoshop then you're probably using OSX on a Mac. Facebook machines are phones and tablets, and students use Chromebooks or Macbooks.
The enthusiast PC market is pathetically small, smaller than the PS4 market. That crowd will not be going to ARM anytime soon, since those chips won't beat high end x86-64 for quite some time.
There are already ARM Chromebooks I think, so there's that. But I really don't think Apple will ever push the next MacOS to ARM.
You better hope ARM doesn't become popular for desktops and laptops. Most ARM devices come with locked boot loaders. Microsoft requires that Secure Boot can't be disabled for ARM devices that ship with Windows installed.
>>51264630
I just got a bus error because of unaligned address, fuck arm
>2015
>sigbus
>>51265494
Pardon?
>>51265510
All it takes is one open firmware.
>>51265531
>2015
>addr % 2 != 0
>>51264630
>ARM is going to catch up speedwise
.......... how?
ARM has shit per-core performance. And you literally can't improve it save for building a parallelization system similar to what x86 has. The only use for app is facebook machines, which already use it.
>>51265554
>ARM has shit per-core performance.
HAHAHAHAHAHAAAAAAAA
>>51265554
What.
>>51264630
You do realize consoles were PREVIOUSLY ARM/MIPS/etc... The newest gen is when they switched to x86. x86 is easier to develop on and actually is more capable. If ARM is to match the capabilities, it will consume the same amount of power as x86.
tl;dr Consoles WERE ARM. x86 has universal application whereas ARM is limited in capabilities because it is a *reduced* instruction set or RISC.
>>51265573
Nothing to hahaha about.
>>51265573
You realize the ARM octa in several phones is only about as powerful as a core2 duo, right? Check the numbers.
How would a 95W ARM compare to a 95W x86 counterpart?
>>51265414
But Windows has ARM ports like Windows RT, and it has all the killer programs people want, like... And...
ITT: we spew bullshit
There is a fucking reason the MS surface failed hard
RETARD COMING THOUGH
If ARM really does take over, would it be possible to write an emulator to run x86 programs?
>>51265573
>>51265585
here
In addition, the intel celeron J1900 is as powerful as a core2 duo and consumes about 15w. It has additional capabilities because it is a full instruction set rather than reduced (hence the extra power usage).
>>51264886
He means in performance, you retard.
There are more ARM devices than x86 devices because those ARM devices are phones and tablets that can only be used for basic content consumption. You don't do actual work on phones and tablets.
It will be at least another decade until ARM devices catch up to my E3-1231 V3 in performance, and that's a rather mainstream x86 chip. By then, there will be much better x86 mainstream chips, and even better high-end ones.
>>51265585
No, a c2d is still significantly more powerful than a shitty ARM SoC
>>51265575
There has never been a mainstream console that employs an ARM processor.
>x86 is easier to develop on
Explain how, then. Bearing in mind that all console developers use exclusively high-level languages now, and that x86 is legendary for being a byzantine and unpleasant architecture anyway.
>ARM is limited in capabilities because it is a *reduced* instruction set or RISC
Haha, you must be technologically illiterate.
>>51265553
>addr % 2 != 0
it's not only odd address issue, you can't dereference 4 byte if the address is not multiple of 4, it can still be even.
>>51265595
ARM would lose, instruction sets don't scale against each other in wattage. Now if you had a specific task that ARM is great at, then it would win. Just like how SPARC is great for databases, it's explicitly designed to be.
>>51265601
x86 is already being run on a RISC architecture. It definitely is possible. It also seems practical, because current x86 android phones and tablets actually emulate programs compiled for ARM, and it works very well.
But I don't really see how ARM is going to take over at all, considering there would be none advantages over x86.
>>51265585
Well it would, wouldn't it? It's in a phone. No one wants a phone that causes third-degree burns.
>>51264961
>less than 2% usage share
>l-linux is mainstream, I s-swear!
>>51265601
Not at acceptable speeds
>>51265611
3DO
Various nintendo and some sony handhelds
>>51265610
http://cpuboss.com/cpus/Nvidia-Tegra-4-vs-Intel-Core2-Duo-E7200
Check the geekbench score.
>>51264630
>almost 2016
>not using elbrus
>>51265554
There hasn't been much of a performance jump in x86 since Sandy Bridge in 2011.
ARM has improved significantly since then.
>>51265575
>You do realize consoles were PREVIOUSLY ARM/MIPS/etc...
The 360 has a PPC processor
The PS3 has a PPC processor
The Wii has a PPC processor
The PS2 has an MIPS processor
The Gamecube has a PPC processor
The Xbox has an X86 processor
The PS1 has a MIPS processor
The N64 has a MIPS processor
The Dreamcast has some custom RISC processor
The Sega Saturn also has some custom RISC processor
The SNES, Genesis, 32X, NES and as far back as I can remember, not a single one has an ARM CPU. Stop talking out of you ass and stay in fucking /v/ where you belong.
>>51265641
>does not know the difference between servers and desktops
>>51265646
>geekbench
>>51265640
Celeron J1900 is comparable and requires minimal cooling (if any).
>>51265494
>PCs are dead.
>If you're doing video editing or Photoshop then you're probably using OSX on a Mac
Your statement contradicts itself. Macs are PCs.
>>51265575
>ARM is limited in capabilities because it is a *reduced* instruction set
good bloody lord
>>51265656
>ARM has improved significantly since then
But still nowhere near x86.
With x86 you have a room for improvement because instruction set is complex and you can parallelize some instructions safely. With ARM and its simple instruction set, this does not seem possible.
>>51265611
>There has never been a mainstream console that employs an ARM processor.
Oh?
http://www.macnn.com/articles/10/03/01/sony.urges.players.to.avoid.using.ps3.until.fix/
>>51265658
>The Dreamcast has some custom RISC processor
Hitachi SH4
>The Sega Saturn also has some custom RISC processor
Hitachi SH2 x2
>>51264630
is this a 90's thread?
>>51265658
I think Gameboy Advance was ARM.
Don't forget the most significant problem of ARM: compatibility is shit between generations
>>51265658
3DO was ARM
As are mos recent handheld consoles
>>51265611
>>Explain how, then. Bearing in mind that all console developers use exclusively high-level languages now, and that x86 is legendary for being a byzantine and unpleasant architecture anyway.
High-level? You still have to have customized libraries for ARM asshat.
Byzantine? Try continuously improved to where it looks little like the original 8086 arch.
>Haha, you must be technologically illiterate.
You don't understand how RISC works, do you? Lemme guess, you took Intro to Computer Science and believe you now know everything about computer architectures.
http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Fucktard...
>>51265585
The ARM Cortex A72 and the custom CPU cores in Apple's latest SoC's have single core performance that rivals or significantly outperformance Broadwell CoreM inside of lower TDPs.
Stop talking out of your ass.
>>51265707
Yup ARM7.
>>51265659
>walks into bestbuy
>"I would like one server, please"
Are you fucking retarded? How are servers going to have any influence in ARM surpassing x86 in the consumer market, you idiot?
>>51265660
>Celeron J1900 requires minimal cooling
It requires a chunky enough heatsink to make it useless for any application that requires portability.
>>51265660
Provide statistics. I can't find any. Which Core 2 Duo is it equivalent to?
>>51265642
Handhelds.
The real reason behind the major console companies going with x86 is that they were looking at current offerings rather than paying to produce an ARM chip with the performance point that they desired, which is very expensive and assumes some risk of failure. It's a path-of-least-resistance thing.
>>51265724
Interesting. PS Vita actually has ARM. Even though they used MIPS for their previous console.
>>51265283
more interestingly driver support is one of those things that might never go away but for 90% of use cases hardware vendors dragging their feet has resulted in Linux not really needing those drivers to work (it just provides FOSS drivers and that's that).
The only real frontier for it is graphics, mostly because non of the dedicated hardware makers do things that make sense (or good hardware)
If you saw the stability and compatibility issues people will put up with on a phone you would laugh and laugh
>>51265681
Employs an ARM chip as its CPU. Do stop moving the goalposts.
>>51265707
yea, so is the DS
>>51265724
if the 3DO was ARM then that'd be 1 point for arm on a mainstream console, though the 3DO was hardly a successful console (not because of the hardware though, but because it was expensive as shit, which was due to being licensed out for others' to manufacturer, meaning more middlemen to pay)
>>51265641
2% usage is pretty mainstream. It is not a majority, but it's popular and growing fast.
And it is dominant in the server market.
>>51265676
are you retard? anything you do with x86, you can do it with arm.
arm has simpler instructions, but they run on cpu directly, x86 has complex instructions, but lot's of microcode runs in cpu for each of them, they are simply interface functions-instructions.
>>51265727
>You still have to have customized libraries for ARM asshat.
What?
>Fucktard...
"Reduced instruction set" is not a synonym for "less capable", particularly when programmers never touch the instruction set.
>>51265636
iirc x86 atoms don't *emulate* ARM architecture or instruction sets in apps it actually runs it natively
I could be wrong and probably am
The problem is compatibility between ARM SoCs
There are no standards for additional hardware so each manufacturer does it's own proprietary shit
>>51265749
https://www.cpubenchmark.net/compare.php?cmp[]=2131&cmp[]=950
>>51265040
>what is libreoffice
>>51265795
they can, but they don't
android has a native x86 port, and many android programs have native x86 versions, not to mention a lot are java, which aren't tied to a specific architecture
>>51265795
Modern amd64 and x86 CPUs translate instructions to RISC ones before execution, which simplifies the on-die logic.
>>51265790
>"Reduced instruction set" is not a synonym for "less capable", particularly when programmers never touch the instruction set.
http://stackoverflow.com/questions/14794460/how-does-the-arm-architecture-differ-from-x86
>>51265778
This is what I am talking about: https://en.wikipedia.org/wiki/Superscalar_processor
>are you retard?
Why do you people always do this? You know your knowledge on the subject is sub-par, and you still call everyone who does not accept your uneducated opinion a retard.
When ARM is on a socket based platform and can do powerful computation it may. But until then no one wants to use a workstation where everything is embedded and must be tossed out if something breaks.
Also
>nogaems
>>51265575
>consoles were ARM
>>51265795
There is no emulation. Android applications are compiled to bytecode, which is later compiled to native code at install time (previously, this was runtime, but ART has changed a few things). If native ARM code was used (i.e. through the JNI), it simply will not run on x86 or MIPS. If one wishes to provide native code for multiple architectures, recompiling for each architecture is necessary.
>>51265764
As it's CPU, what the hell do you think ARM is? SoCs include addins by other manufacturers.
>>51265795
>>51265828
The fact that you can run any android app (and you can) on x86 tablet means x86 does run android binary code. It could be recompiled instead of emulated, though. The only time I know for sure recompiling was used successfully is PS1 emulation.
>>51265790
Are you a web developer? C++ requires different/additional libraries for coding to ARM if you're doing anything other than dicking around.
>>51265641
>97% of supercomputers
>99% of phones
>98% of tablets
>....
>not mainstream
>>51265835
Don't just dump links. "Reduced instruction set" is not a synonym for "less capable".
>>51265845
>>nogaemsbethesda!nigger % make -j8 TARGARCH=arm64 TARGOS=linux
Correct rest of post.
>>51265819
as someone who went to the trouble of introducing people to libreoffice i can tell you that it's not substitute...
...
Because microsoft don't even keep to their own rendering standards for office docs never mind anyone else's, so unless you are sending it TO someone also using office it looks like someone fucking on a keyboard with word open.
>mfw it turns out abandoning open standards is good if you can convince everyone that it's not your fault
>>51265575
Console != Handheld.
Its like saying your Phone and your Tablet are the same than a desktop.
>>51265795
You're right, they don't emulate, apps are compiled for various architectures now.
>>51265601
Some emulators already exist, but the speed is seriously shit, recent arm v7 SOCs perform like an intel 386 system
>>51265881
>linux
>98% of phones
Even if you're persisting with the delusion that Android hasn't forked sufficiently from Linux to be a distinct OS now, iOS accounts for more than 2% market share.
>>51265880
If you are compiling from source, save for libraries that actually generate code on the fly or use inline assembly, there is almost nothing you need to do in order to get code written for x86 compile for ARM.
>>51265885
I posted the link explaining the technical differences, feel free to read it.
>>51265868
The PS3's CPU is the Cell, which is PowerPC. The ARM that lives in the PS3 seems to be a heavyweight microcontroller. Stop moving the goalposts.
>>51265880
>requires different/additional libraries for coding to ARM
Beyond SIMD instrinsics, what?
>>51265893
It was in response to the console comment.
>>51265901
as /g/sus would be happy to copypasta at you linux is a kernel (included in it's entirety in android).
The real question becomes why can't we get better fucking drivers for that stuff and more easily run a FOSS stack if we want to.
>>51265925
Linus himself considers Linux an OS.
>>51265908
I'm getting tired of looking shit up for you, google it yourself.
>>51265905
I'm well aware of the technical differences between CISC architectures and RISC architectures. Wikipedia tears your suggestion of less capability to shreds quite nicely:
>The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced—at most a single data memory cycle—compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction.
>A common misunderstanding of the phrase "reduced instruction set computer" is the mistaken idea that instructions are simply eliminated, resulting in a smaller set of instructions.[21] In fact, over the years, RISC instruction sets have grown in size, and today many of them have a larger set of instructions than many CISC CPUs.[22][23]
>>51265940
Why yes, let me just link libarm.
>>51265940
>i know but i won't tell you
That anon is not asking for your help. You are in the middle of an argument. And by making a post like that you effectively admit defeat.
>Android and apple TV boxes are starting to become popular
>they are dying because of affordable smart tvs
>>51265940
>signed, a dillettante who has never targeted ARM
>>51265901
IOS is based on Unix, the OS Linux is based upon.
Other than that, Android has not sufficiently deviated to be considered something other than a fork of Linux. At the core there is still the Linux kernel.
>>51265957
>>51265959
>>51265971
Items required for different types of ARM development:
http://wiki.call-cc.org/man/4/Cross%20development
(aka a cross-compiler for converting code because no, you cannot do this natively)
An arm-explicit compiler, you cannot compile anything on arm using an x86 compiler:
http://ds.arm.com/ds-5/build/
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/BABIDFFF.html
"Hurr durr, ARM and x86 have become essentially the same thing:"
>>51265938
what linus considers an OS is provided in it's entirety in any android install, when most people think of linux (or any OS) they may be thinking of the userland and the stack that supports it but Linus has never ascribed to that notion (i mean fuck could you imagine a kernel release with a built in userland, people would shit themselves)
>>51266051
Are you saying I didn't imply cross-compilation before? You've changed your tune since "you need special libraries". You are grasping at straws now.
>>51265959
By the same logic, refusing to argue with a retard because they cannot understand what you're saying is losing the argument.
>>51266051
>C++ requires different/additional libraries for coding to ARM if you're doing anything other than dicking around.
>C++ requires different/additional libraries for coding to ARM if you're doing anything other than dicking around.
>C++ requires different/additional libraries for coding to ARM if you're doing anything other than dicking around.
>>51266051
Is this a joke post? Compiling scheme to C and then using a C compiler to target your platform? This is your difference?
GCC compiles any code, includes its own, being able to target both x86 and ARM.
>>51266071
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0475c/index.html
>>ARM® Compiler toolchain Using ARM® C and C++ Libraries and Floating-Point Support
Arm-specific libraries. Why is this so hard to understand?
>>51266091
GCC for ARM is a different compiler than GCC for x86.
>>51266092
Meaning SIMD intrinsics, which you are under no obligation to use (just as most people don't use SSE intrinsics either). Why is this so hard to understand?
>>51266092
This is documentation for compiler. Compiler for every platforms provides speciofic libraries. What you need to compile code for ARM is a compiler (with its bundled specific libraries).
>>51266106
It's built from literally the same code.
>>51266107
When you say "most people" what do you figure they're programming?
>>51266106
GCC for ARM(ver) is simply GCC compiled with its target set to ARM(ver), much like GCC for amd64 is simply GCC compiled with its target set to amd64.
Reminder ARM was designed by a tranny
>>51265730
The Broadwell CPU still trounces A72 when there's plenty of power on tap. But when you constrain the power and/or thermal envelope, as in the case of Core M, the Cortex A72 just about catches up.
Meaning when the Core M is constrained to the same power limits as the new arm chip they perform similarly. This is a great feat, but the core-m is made to be able to consume a lot more power and therefore can do a lot more when unconstrained. So you'll have core-m efficiency but not core-m performance
>>51266116
>(with its bundled specific libraries)
>>51266135
Yes, like libc with ARM-optimized routines. libc is not a special platform-exclusive library.
>>51264630
>I'm not even going to MENTION the fact that ARM is completely dominating the mobile market.
You just did, autist.
>>51266135
It is not different from any other platform, including x86. You don't need anything special to write code, and you only need a compiler to build code. You don't need to refer to those libraries in any way in your code. Same code compiles for all platforms.
>>51266130
Perf/watt with A72 based SoCs, and the Apple A9 is higher than CoreM.
We don't have modern ARM SoCs routinely drawing over 6w by themselves in handheld devices, yet CoreM does this in thin tablets and ultrabooks. Its been measured at pulling in excess of 10w by a large margin.
>>51265972
Unix is not Linux though.
iOS is not Linux.
Linux therefore does not power 98% of smartphones.
>all oses trace their origins back to Charles Babbage's first mechanical MS-DOS punch card generator so really they are all the same
>>51265972
>Other than that, Android has not sufficiently deviated to be considered something other than a fork of Linux
Completely different userland from all other linux distros? Don't you think that should be enough?
>>51266201
An operating system is defined by its core, not by user interface. This is why Windows and DOS are considered the same platform.
>>51266051
I have console A, ARM.
I have console P, PowerPC.
I have a game G, 200,000 lines of ISO C in total.
G was originally written for P. I wish to port G to A.
I have written the OS-specific bits that A requires, and I have written a renderer that uses A's 3D rendering API.
I have Ken Thompson's PowerPC compiler, qc.
I have Ken Thompson's ARM compiler, 5c.
I attempt to compile G with 5c and link it with the standard C library of A's OS.
What, according to you, is missing?
>>51266223
Userland is not user interface.
>Windows and DOS are considered the same platform.
By who? By you and your buddies?
>>51266201
That's like saying the earth revolves around the sun. It's accurate and correct for all practical purposes but it's technically wrong since they orbit around a common center of mass so autists will jump on you the minute you say it in a vain effort to give meaning to their pointless lives.
>>51264630
>x86 will just be a legacy platform
Are you a fucking retard? Even the most hardcore normie needs an actual PC for video/photo editing. And I don't see you being able to run CAD on ARM anytime soon.
>>51266258
Why do you think CAD software is platform-specific?
>>51264630
>within the next 5 years
Promising, but I'd give it at least snother 5 before it's really surpassed all of the current x86 limitations. If a top end gaming rig ends up being less than 2 grand, I can die happy.
>>51266283
Probably not as much platform-specific as it relies on high performance, which ARM lacks.
>>51266314
You retarded? The whole thread is about how ARM will surpass x86 in performance.
>>51266357
Just because you keep talking about it does not mean it will happen. Superscalar architecture is a practical way to reach improved performance with x86's complex instruction set. What are your plans for improving performance for ARM?
>You retarded
Are you the same person who called me retard the previous time for making the same statement and then failed to respond to my next post?
>>51266357
And all your evidence has been a case of ARM taking over market share because most people just want a facebook machine. That's great but why try muscling in on x86 with inferior architecture? ARM is for low power computing, where is the sense is trying to make one processor that can do everything? Different processors for different jobs. ARM is popular because it's cheap because it's low power. If it's high power then it won't be cheap and it won't be popular.
>>51266314
Given that ARM has lower power consumption per FLOP, it is by definition already surpassing x86 in performance if we measure performance as milliwatt-per-FLOP rather than as an absolute comparison of performance benchmarks of currently manufactured CPUs.
>>51266401
>Superscalar architecture is a practical way to reach improved performance with x86's complex instruction set
x86 has had superscalar extensions since before Pentium 4. They're seldom used except in a scalar context.
>>51266456
>Given that ARM has lower power consumption per FLOP, it is by definition already surpassing x86 in performance if we measure performance as milliwatt-per-FLOP rather than as an absolute comparison of performance benchmarks of currently manufactured CPUs.
It's nowhere near in per-core performance, and no one cares about per-watt save for mobile devices.
> x86 has had superscalar extensions since before Pentium 4. They're seldom used except in a scalar context.
Superscalar architecture is not what you think it is.
>>51266401
ARM already is superscalar, retard.
>>51266401
>What are your plans for improving performance for ARM
More cores, obviously.
>>51266235
By anyone in higher level computer science.
>>51266484
Per-watt performance = "per-core performance". Just crank it right up.
The reason we don't see ARM CPUs that rival top-end i7s (but have somewhat higher power efficiency) is that there is no practically no demand for them. ARM's present niche is obvious.
>>51266567
Gonna need them references.
>>51266230
You're using custom libraries. Nothing is missing because you downloaded them.
>>51266572
Crank what up? You are not making sense. Per-watt performance has little to do with per-core performance.
>>51266590
No I'm not, the game is written in portable ISO C. There are no ARM-exclusive libraries in use.
If arm is so good how come I cant even multi-task properly on my phone?
>>51266596
mate all you need to do is crank it right up
>>51266401
>Superscalar architecture is a practical way to reach improved performance with x86's complex instruction set. What are your plans for improving performance for ARM?
You retarded? Both x86 and ARM are superscalar. Superscalar architecture isn't some hypothetical way to improve performance. It is standard NOW.
>>51266235
>Userland is not user interface.
Ok, then let's discuss older versions of Red Hat vs newer debian ones that use systemd. They are still both linux even though userland is very different.
>>51266576
Here's a thought, you give me references on why you think Windows is not the same platform as DOS. Windows may have been changed to where the core is built on GUI but it's still DOS arch.
>>51264630
>x86 will just be a legacy platform. Kind of like PowerPC.
Jesus Christ this faggot is a first term CS major aren't you?
>>51264961
>They would require a recompile.
A littttttle bit more complicated than that dipshit.
>>51266666
No. It's your claim. It's your unrealistic outlandish claim. You give references.
>>51265596
>But Windows has ARM ports like Windows RT
The original surface flopped because it had no software
A certain number of flops is cheaper to be obtained on arm than x86. Production cost AND power consuption wise. Arm is more efficient by any standarts.
Since both of them are basically using the same strategy(parallelisation) for performance improvements, there is no software engineering advantage.
Arm just needs time to catch up.
>>51266612
>ARM-exclusive libraries
When did I say anything about exclusive. The libraries are available for x86 but have to be compiled for ARM.
In the end of all the argument, my point is at most nullified for a tie. I originally said it was easier to program for x86. If the libraries are identical in availability (built into the core compiler) and there is no change in how one handles pointers then there is no difference between the two and therefore no benefit to ARM with regard to programming.
>>51266645
But most of userland is still shared. As opposed to Android which has none of userland from your usual Linux distro.
>>51266696
Go on then. A program written portably in a high-level language against the win32 API. Go on, explain how it requires more than a recompile.
>>51266699
You made the first claim.
>Completely different userland from all other linux distros? Don't you think that should be enough?
>>51266666
Are you retard? Literally everyone makes a difference between dos and NT.
>>51266721
Assuming the Win32 API required no porting (which it does, but whatever dongus) there is always going to be some very specific quirks in how code executes on different operating systems, even between different versions of the Linux kernel this can exist. Because Adobe makes high-powered programs, you can bet your ass they had to do this.
>>51266756
So you honestly believe that the operating systems are as follows:
Windows
DOS
Linux
Unix
Apple's OSes
>>51266736
I am talking about what you said about Windows and DOS. notice that I never claimed anything directly in that post of mine and instead asked you if you think completely different userland should or should not be enough to consider two operating systems different.
You on the other hand outright said Windows and DOS are considered the same platform by anyone in higher level computer science.
>>51264630
>Apple TV boxes are just starting to become popular
Haven't they literally been trying for 10 years tho? It's clearly apple's least successful main product.
>>51266775
He said nothing among almost all the stuff you wrote in his post. Can you read?
>>51266709
>If the libraries are identical in availability (built into the core compiler)
Libraries are not built into the compiler. What's a "core compiler", mate?
>and there is no change in how one handles pointers
C's memory model is flat.
>The libraries are available for x86 but have to be compiled for ARM.
In your very first post you said CPU-specific libraries, i.e., a library that used some capability of a CPU not present on others. This was to supplement your assertion that RISC architecture are "less capable" than x86. If what you meant was normal portable libraries that are available as part of the cross-compilation process (and it does seem like it now), then I don't know why you see this as a hurdle. Using (e.g.) libc compiled for your architecture is, err, standard practice, and its presence can be assumed.
>>51266775
That's a gross simplification, but yes, Windows NT and MS DOS are COMPLETELY distinct.
NT has multi-user, DOS is single user.
There. Simple as recognizing that basic fucking fact.
>>51266787
People caught on that you can get "free" TV using XBMC/kodi.
>>51266775
What are you talking about? I'm not the guy you were first talking to. Dos and Windows NT ARE NOT the same architecture just because of software compatibility. NT and DOS are not the same OS. Userland does not define OS. Android is as much linux as any other distro you retard. The other distros are GNU/Linux, android is not.
>>51264718
>and it throttles extremely hard under even moderate workloads. 1ghz or 1.1ghz base clock for a lot of parts, burst turbo on some can reach around 2.7ghz, but for fractions of a second. Under heavy workloads they can drop down to 800mhz. CPU+GPU workloads are a disaster.
That's only when it's using no active cooling and even when running near base frequency it's as fast as an a72 core.
>>51266825
You're combining posts in your response. I recommend reading back to separate out opinions. I was actually arguing that Android IS linux.
Not to mention: no.
https://en.wikipedia.org/wiki/Multiuser_DOS
>>51266825
>Userland does not define OS
I'd very much say it does. It's a matter of opinion so I can't do much to convince you, but Stallman puts the name of his userland software collection in front of kernel name. Wouldn't that mean he considers userland more important for defining OS than a kernel?
>>51266705
/thread
>>51266825
Also get off the GNU thing. Linux is not GNU.
>>51266773
>Win32 API required no porting (which it does, but whatever dongus)
The win32 API is obviously available on Windows for ARM. When cross-compiling with a toolchain that both targets ARM and offers support for Windows targets, you simply link your software with the copy of the win32 stub library that is compiled for Windows-ARM.
>there is always going to be some very specific quirks in how code executes on different operating systems
Competent developers do not write software that relies on undefined behaviour. When we talk about software, we assume that it does not rely on platform-specific undefined behaviour. See Steam (still unavailable on amd64, a 13-year-old architecture!) for an example of incompetently written software that exhibits just this sort of problem.
>Because Adobe makes high-powered programs, you can bet your ass they had to do this.
No, you can bet your ass because Adobe are shit at writing software. Just see the PSD file format for confirmation: Adobe programmers didn't even understand endianness, and it used to be impossible to load PSD files created on Macs on PCs and vice versa. And just see Flash for more confirmation.
>>51266929
>Competent developers do not write software that relies on undefined behaviour.
not the person you're arguing with (and I support your point mostly), but often you just have to use platform-specific functionality for performance.
>>51266884
No way I'm reading that mountain of shit.
To male clear, I think the guy who said "high level computer science" is retarded.
>>51266889
It's not a opinion matter. if userland defined a OS then you could have the same OS with different kernels and you could have a software that runs and does not run on a same os at same time.
>>51266901
Linux is the kernel and GNU the userland. Linux is not the entire software stack,
>>51266972
http://www.linuxuser.co.uk/features/whatever-happened-to-the-hurd-the-story-of-the-gnu-os
>Unlike the Linux kernel, which is monolithic, the Hurd uses a microkernel, and functionality is moved out of kernel space and into userland. The microkernel sits between the hardware and most of the activities that are normally assumed by a monolithic kernel.
Linux is a monolithic kernel which all of the modern Linux distros are. GNU is a microkernel.
>>51266960
If it's "often" (and that you "have to") then you'll have no trouble providing proof that most programs are relying on platform-specific functionality or undefined behaviour.
>>51267011
There you go.
https://github.com/search?q=pcmpgtb&ref=reposearch&type=Code
>>51266991
GNU is not a kernel. Hurd is.
A micro kernel does not put functionality on the userland. Things still run as part of the kernel, they run on user space - cpu unprevileged mode.
The imbecile that wrote that does not know the diference between kernel space, users space, userland and kernel.
>>51266929
>The win32 API is obviously available on Windows for ARM. When cross-compiling with a toolchain that both targets ARM and offers support for Windows targets, you simply link your software with the copy of the win32 stub library that is compiled for Windows-ARM.
Win32 is incomplete on ARM; Microsoft is pushing .NET
>Competent developers do not write software that relies on undefined behaviour. When we talk about software, we assume that it does not rely on platform-specific undefined behaviour. See Steam (still unavailable on amd64, a 13-year-old architecture!) for an example of incompetently written software that exhibits just this sort of problem.
Simple if-else statements using pointer arithmetic can execute differently on the same processor running different Linux distros
If you can't realize that is not the fault of Adobe (for all the shit they deserve), then you are quite simply thick
>>51266972
>if userland defined a OS then you could have the same OS with different kernels
Nothing stopping you from that. As long as kernels are binary compatible, it will work.
>you could have a software that runs and does not run on a same os at same time
Already a reality. If software uses x86 platfom specific code, it will run on x86 Linux and will not run on ARM linux.
>>51267119
>Simple if-else statements using pointer arithmetic can execute differently
Such as? And again, competent developers avoid undefined behaviour.
>>51267154
Not gonna respond to >>51267079, eh?
>>51267167
>some OS
>a billion Linux mirrors
>some specialized compression software
>>51267093
>>When Linus Torvalds was asked in the documentary Revolution OS whether the name "GNU/Linux" was justified, he replied:
>>Well, I think it's justified, but it's justified if you actually make a GNU distribution of Linux ... the same way that I think that "Red Hat Linux" is fine, or "SuSE Linux" or "Debian Linux", because if you actually make your own distribution of Linux, you get to name the thing, but calling Linux in general "GNU Linux" I think is just ridiculous.
-Linus Torvalds
Ok, even if the components are usable in Linux that doesn't mean they are. Kernel aside, Red Hat is Red Hat, not GNU/Red Hat.
>>51267186
>where are examples
>here
>that doesn't count!
Saw that coming for a mile away.
>>51267146
>>if userland defined a OS then you could have the same OS with different kernels
>Nothing stopping you from that. As long as kernels are binary compatible, it will work.
To argue this is to argue that a Linux distro migrated to Unix would be neither Linux nor Unix.
>>51264630
>Anyone thinking that ARM isn't going to pass up x86 within the next 5 years is lying to themselves.
That's what people said 5 years ago.
>>51267207
Yeah I don't know about you, but when I'm writing a program I reach straight for inline assembly.
You said "most" projects "have to" use arch-specific functionality. Linux is not most projects. The compression one is not most projects.
>>51267119
>if-else statements using pointer arithmetic can execute differently on the same processor running different Linux distros
How?
It is adobe fault for not making endian aware software.
>>51267146
>Nothing stopping you from that. As long as kernels are binary compatible, it will work.
Not binary compatible you insanelly deep shit. All API and interfaces have to be the same. Every available resource has to be the same.
Also this is a logic statement that only makes sense with the following one.
>Already a reality. If software uses x86 platfom specific code, it will run on x86 Linux and will not run on ARM linux.
No. Drivers apart you only need to recompile the software. A software is not a fucking binaty you immense retard.
>>51267198
For those that have trouble with english:
>>Ok, even if the components are usable in Linux that doesn't mean they are.
Would mean that even if GNU components are usable in Linux, this doesn't mean that Linux is GNU.
>>51267235
Big, serious projects do. Most of them are not on github of course. 100 pages of opensource projects should be a good example.
I never said most. I said often. Do not put words in my mouth.
>>51267267
>software uses x86 platfom specific code
>you only need to recompile the software
It does not compile. Now what?
>>51267154
>Such as? And again, competent developers avoid undefined behaviour.
https://stackoverflow.com/questions/31016660/why-does-this-for-loop-exit-on-some-platforms-and-not-on-others?utm_medium=social&utm_source=facebook.com&utm_campaign=so-facebook
>>51265658
Megadrive used a Motorola 68000 + Zilog Z80, most consoles and computers before that also used either 68k or z80 (including Apples stuff), or they used a MOS 6502 variant or derivative (including the NES, while the SNES used a 16bit version of it).
The 3DO was the only console I can think of that used ARM.
GBA, DS and 3DS also use ARM but they are handhelds (which is where ARM is the best due to low power usage).
>>51267267
>>if-else statements using pointer arithmetic can execute differently on the same processor running different Linux distros
>How?
>It is adobe fault for not making endian aware software.
See >>51267296
This is a universal concept that has NOTHING to do with adobe or Endianness.
>>51267295
>Big, serious projects do.
Yeah relying on undefined behaviour and almost certainly pointless (nowadays) handwritten assembly is the hallmark of a serious project.
>>51267296
>buffer overrun
How stupid.
fuck off with your smartphone tier trash processor. go die in hell
>>51267198
And what you mean by that?
He said that you can name your shit as you pleasse. That does not mean SuSe linux does not include gnu software and that saying it is basically a stack of the linux kernel and gnu software is wrong.
I never said linux is gnu you monron. Linux is the fucking kernel. The only thing named "linux" is the kernel. The entire os might be "SuSe Linux", calling it "linux" is wrong, the name is "SuSe linux".
On the other hand saying that SuSe Linux is GNU/Linux would be correct. Gnu linux describes accurately what the os is, a stack of the kernel + userland(most part) software.
>>51267345
>Yeah relying on undefined behaviour and almost certainly pointless (nowadays) handwritten assembly is the hallmark of a serious project.
I never said anything about undefined behavior so don't attribute it to me please.
And assembly is widely used.
>>51267296
competent developers don't write past the end of arrays, let alone expect it not to crash
>>51267345
>>buffer overrun
>How stupid.
Yes. But it might not be buffer overflow depending on the OS. How fucking dense are you faggots?
>>51267357
>die in hell
made me smile
>>51267360
>And assembly is widely used.
Not in application software it ain't, which is what we're talking about.
>>51267386
Writing past 10 elements in array with 10 elements is always buffer overrun and always a mistake.
>>51267295
Changing this piece garbage you call code is part of the recompiling process. If your code doesn't compile, it is wrong.
>>51267386
It's a buffer overrun whatever the architecture. A bug. An error. Something that must not be done. Why are you complaining that undefined behaviour acts like undefined behaviour?
>>51267412
>If your code doesn't compile, it is wrong.
are you baiting or do you actually believe that
>>51267434
Why are you trying to compile inline x86 assembly with an ARM compiler? Why do you have inline x86 assembly in your program?
>>51267318
see
>>51267371
It is bad code and has nothing to do with computer architecture. That's a undefined behaviour and how it affects different OS differentely.
>>51267465
>Why do you have inline x86 assembly in your program?
To improve performance.
>Why are you trying to compile inline x86 assembly with an ARM compiler?
You told me to compile my program using ARM compiler in >>51267267.
>>51267434
If you try to compile a code and the compiler throws a error, your code has a error.
Wrong assembly code is a error. You didn't port the code well.
Software is not just binary.
>>51267519
> You didn't port the code well.
I did not port it at all. I only recompiled it from source code, going by your suggestion:
>you only need to recompile the software
>>51267503
It is to be assumed that software written in a portable programming language is actually written in that portable programming language, not in that language plus 1,000 lines of assembly language. "What about my x86 code" is a red herring, as arch-specific code is the exception and not the rule. For portably written software, which is what we assume with our common sense, a recompile targeting ARM is all that is necessary to produce a program that runs on ARM.
Please stay on topic and stop pretending that a majority of the pieces of software you come across are full of arch-specific code.
>>51267503
>You told me to compile my program using ARM compiler in >>51267267 (You).
You replyied to two different people, I'm the second.
I obviously meant "compile the code for the correct architecure" or port your code to the correct architecture.
A ported code is still the same software. a software, you ignorant shit, is not a statically compiled binary file.
>>51267544
If it did not compile, the code is wrong.
>>51267571
The software is not ported. The port simply does not exist. It is not my software. I can't port it. Its owner won't port it. Hence, software works on x86 linux and does not work on arm linux.
>>51267602
And whose fault is that, and in what way does that make the ARM architecture unviable?
>>51267602
THE FUCKING SOFTWARE IS NOT THE BINARY YOU HAVE UP YOUR ASS.
Stop avoiding the problem. What you said "userland defines the os" is wrong. You fucking deep shit.
>>51267632
I am not talking about whether ARM is viable or not at all. Please learn to follow the discussion.
>>51267645
>>THE FUCKING SOFTWARE IS NOT THE BINARY YOU HAVE UP YOUR ASS.
It's not the binary. It's software. The fact is that software does run on x86 linux and does not run on arm-linux. Software. Not just some binary. Software. For example, Steam (the software -not just a binary) does run on x86 linux and Steam does not run on arm-linux.
>>51267632
I'm the person he/she was debating with.
It has basically nothing to do with the thread sibject because 4chan is a piece of shit that a bunch of weebs and retarded childs think is useful for something that not porn.
The guy you replied to said that Windows NT and DOS are the same os because they run the some of the same software and taht the userland defines a os.
There are much more shit in this thread that might have been said by the same individual while trying to avoid the fact that he/she doesn't know shit about computer architecture.
>>51267712
>Windows NT and DOS are the same os
I did not say that.
>they run the some of the same software
They don't.
>the userland defines a os
And that is my opinion. Your opinion is otherwise, and you consider your opinion to be a fact - which is wrong.
>>51267688
>For example, Steam (the software -not just a binary) does run on x86 linux and Steam does not run on arm-linux.
Because it was not ported. If it was ported would still be the same software. Also, that is just you being a mentally handicaped child denying the obvious.
In my argument, your definition of OS would allow a software to run on and not run on the same os at the same time. Making the term OS basically unuseful.
If you really want to be a retarded child about it, fine. Consider the same architecture, your definition still allows the casse to happen.
>>51267761
>the userland defines a os
>And that is my opinion.
kill yourself gnu fag. userland defines my ass, kernel and low level architecture defines the OS, userland tries to be as generic as possible.
>>51267798
>If it was ported would still be the same software
But it's not ported so it does not run. It would be same software but it does not exist and hence can't run.
>your definition of OS would allow a software to run on and not run on the same os at the same time
Which already happens so I don't see a problem at all.
Calling me child doesn't help you prove your point. It only shows you're desperate and have to refer to name-calling.
>>51267761
>They don't.
It litereally has a compatibility mode.
>And that is my opinion. Your opinion is otherwise, and you consider your opinion to be a fact - which is wrong.
No. You are trying to push "it's a opinion matter and a final conclusion can not be obtained" as a fact.
The fact is, userland does not define a OS. By the definition of OS.
>>51267810
You are also retarded. The person he/she is disagreeing with is the "gnu fag" - me. Userland by itself does not define a os and i've been trying to ecplain that for the past hour.
>>51267810
An OS is a collection of fundamental software that forms the basis of the rest of the system - the GNU OS which includes tar, GNUcash and Octave.
>>51267883
I'm not exactly saying userland alone defines OS. The
>the userland defines a os
was just a quote by another person which is roughly similar to my views. But, just as I wrote originally, if the userland is different completely between two operating systems with the same kernel, I think this is good enough reason to consider those operating systems different. I'm not a GNU fag. I support Linus's opinion.
Imagine some corporation releases a phone running all android userland but on a NetBSD kernel. The OS will still be called Android. So operating system named Android is defined by its userland - not by its kernel.
>>51267883
>>It litereally has a compatibility mode.
Not on my x64 Win7. Just refuses to run DOS binaries.
>>51267867
You cannot possibly be that retarded.
READ IT ALL
In my argument, your definition of OS would allow a software to run on and not run on the same os at the same time. Making the term OS basically unuseful.
If you really want to be a retarded child about it, fine. Consider the same architecture, your definition still allows the casse to happen.
IT DOES NOT HAPPEN. THERE IS NO SOFTWARE THAT IS COMPATIBLE AND INCOMPATIBLE WITH A OS AT THE SAME TIME.
In your fucking brain dead example it is a hardware incompatibility not a OS incompatibility.
"An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs."
That's the definition of OS, wikipedia, dictionary, operating system literature, whatever.
It's not a opinion matter and the userland does nto define a OS. YOU COMPLETE AND UTTER IMBECILE
>>51267998
It would be another os, by the definition of os.
They would call it android for maketing purposes, so any retard would know it runs android apps. Which basically any os can run, since its a static linked java applet.
>>51268067
Congratulations, because DOS and NT are different OSes.
>>51268112
>Which basically any os can run, since its a static linked java applet.
Why are you in this argument? Why are you talking about Android? No, android apps can run ARM code compiled directly for processor, and a lot of them do. Open almost any commercial APK. You'll find ELF executable compiled for ARM processor inside.
You can't base your arguments on ignorance, anon.
>>51268067
Shit, I'm sorry. That post had a typo, I meant dos and NT are not the same os.
My argument is: dos and nt are not the same os.
In reply to a person that said they are, since some of the same user software run on both. The compatibility thing was to explain why some of the software run on both even though they are not the same.
>>51264630
shitty bait
Why the fuck does /g/ jerk themselves off over the death of x86 so much, and why do they choose literally the plebbest, most god awful locked down platform to do it with?
Desktop RISC is dead for a reason. It's slow, shitty and ineffective.
>>51268157
>My argument is: dos and nt are not the same os.
The only person who claimed otherwise left long ago.
I consider userland to be one of defining factors of what makes an OS, and the person I'm arguing with considers it not to be.
>>51265435
Is atom as fast as arm?
I remember getting an old netbook for hs 5 years ago and it was dogshit.
>>51268067
64-bit Windows operating systems lack the 16-bit subsystem.
Windows 8.1 x86, for example, will happily run Windows 1.01 preload software if you really want to. NTDVM has always been kind of useless, though.
>>51268147
>and a lot of them do.
They don't.
>You'll find ELF executable compiled for ARM processor inside
Automatically generated by the sdk.
As I said, the fucking name would be for maketing purposes by a company that doesn't care if something is technically wrong. If they change the kernel, BY TEH DEFINITION OF OS, IN ANY DICTIONARY OR THE FUCKING WIKIPEDIA, it would be a different os. No matter your fucking opinion.
If you use some shit a company does for defining things, you ignorant cunt, any company could create a anything that runs android apps, call ir android and it would be android. Making the term operating system unuseful.
Google woudn't actually let a company do this.
>>51265575
They only did this to make pc ports easier.
>>51268204
>I consider userland to be one of defining factors of what makes an OS, and the person I'm arguing with considers it not to be.
I'm this person. But I didin't say userland doesn't matter. I said that the definition of OS is not opinion matter and that the userland alone does not define a OS.
There are more than one person arguing that the userland itself defines a os. There is even a individual saying that, if someone names a os android, it necessarily is android and all androids are the same.
It's not a opinion matter. Look the definition .
>>51268265
You keep talking about definition of OS, but there isn't one. There's no authoritative definition that's going to be accepted by anyone, and RMS/Linus stupidity is a perfect example of that.
>Automatically generated by the sdk.
It is a binary blob generated by compiler. Designed to run on one processor. Go ahead, download an APK and open it in 7-zip. See for yourself.
>>51265658
Not a console, but there was one SNES (well, Super Famicom) game with an ARM core on the cartridge as a coprocessor.
>>51268356
It's not part of the sofware you develop, its a some internal stuff made by the sdk.
>You keep talking about definition of OS, but there isn't one. There's no authoritative definition that's going to be accepted by anyone, and RMS/Linus stupidity is a perfect example of that.
The discussion between linus and rms is not about the definition of OS.
Linus says you can name your OS anything, even if it doesn't represent the entirety of the software stack.
Stallman says two things:
- It's unffair not to recognise the presence of gnu software by omiting the term "gnu" from the name.
- the term "GNU/Linux" defines more accurately the software stack commonly found in a certain group of OSs than just "linux" - which is correct.
Yes, there is a definition for OS, It's very clear and can be find on wikipedia, dictionaries and technical literature. It's not a opinion matter. If there wasn't all of this sources would say that the definition is subjective or vague and give a general explanation, like is done in many other matters.
The definition os OS as you can see anywhere includes userland and kernel. It also does not leave space for anything subjective.
i think what apple is doing will be positive overall. switching to arm will diminish jewtel's advantage, linux already works decently there and many of the base libraries and middlewares will have to be rewritten, making
apple's oses (and linux) better candidates for multiplatform software (even games)
microsoft and jewtel will be the biggest losers tbqh. everyone else wins
>>51267093
Hurd isn't a microkernel, it's a replacement to the traditional monolithic kernel. GNU's microkernel is called GNU Mach.
>>51268555
True, my mistake. Thanks.
Checked.
