Slashdot Mirror
Apple Intern Spent 12 Weeks Porting Mac OS X To ARM
An anonymous reader writes "Apple hasn't released a Mac OS X device running on ARM yet, but a recently discovered thesis from a former Apple intern going by the name of Tristan Schapp details a 12-week project carried out in 2010 to port the OS to the ARMv5 architecture. The port got as far as booting to a multi-user prompt, but then hit hurdles to do with drivers and cache. The good news is that same intern now works for Apple as part of the CoreOS team. With rumors last year that a MacBook Air running on ARM could appear by 2013, could he be part of a team making that happen? If he is, I bet it will use the new ARMv8 architecture announced late last year."
If you like freedom even a little bit you need to tell Apple to fuck off. If you buy anything from Apple, even some itunes shit, then you're just a bitch.
NVIDIA is also working on high-end desktop/workstation ARM CPUs, under "Project Denver".
If something compelling emerges, perhaps ARM could be a player for sheer compute power.
Fat binaries might be useful again... ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I am Tristan Schnapp.
I am think you would like to know that if i removed the 'n' from my surname I would be Tristan Schapp.
It's always disconcerting to be on the wrong end of the power/performance curve when it means your computer will have less raw CPU in search of lower power requirements.
However, a change of platform generally means new compilers and fresh code.
I'm not convinced there will be any real-world performance difference when this is factored in.
Software engineer with proven track record seeking challenging position.
Qualifications:
C
ObjectiveC
Various build and integration tools
Job experience:
Apple 6/2011 to just recently
Internships
Apple 6/2010 to 8/2010
Education
BA - comp sci - 6/2011
*references available upon request
Its not like Apple hasn't changed CPU architectures before. 68K->ppc->intel and if you want to count the Apple II, you can also include 6502->68k
I am Slashdot. Are you Slashdot as well?
You have to click through a lot of links to get there, but the PDF of his dissertation is online at his university's website: http://repository.tudelft.nl/assets/uuid:2f66fe0c-4080-4148-a01c-acd530160797/Report_BSc_complete.pdf
You can download it here
Does it actually matter what CPU your platform is running when the OS is totally locked down?
... Telling me that the AC who wrote this is actually Tristan Schapp.
Apple learned their lesson last time with the G3/G4/G5 chips, and I find it hard to believe they would do something as stupid as introducing a third chipset (Intel, A4/A5, ARM) into the mix, especially with one of their mainstream laptops. Nobody wants to go through that - not the users, nor the developers.
A more likely scenario is a MacBook Air based upon iOS with a built-in touchscreen.
Sounds like standard intern hazing.
"Hey, Tim, take this source code (*drops huge book of source on desk*) and port it to... uh... ARM."
**12 weeks later.**
"Holy crap, he made it work."
At least it wasn't SPARC.
As how meany big apps will want to change architecture on apple yet again?
This may brake Photoshop plugins as well
Dropping X86 will take away windows dual boot as well.
Steam games and other games may also die on the mac
So, first they uesed the cheapest factory and labor from China, and now they are actually paying ZERO dollars (as it is the normal salary for any intern) to get their OS ported to ARM!!! What the...... Honestly, i think these guys don't even have ass, or even if they have, i could not imagine putting anything inside, that's how tight they are.
So he spent 12 weeks porting a kernel that had already been ported 3 years ago? iOS and Mac OS X are already the same kernel. Of is the real story that he was back porting lion advancements to the iOS version.
Assumption is its for the new mac book.
Would be funny if it turns out to be the much rumored apple tv.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
If you really like freedom a little bit, you need to be on your guard lest all manufacturers of computing devices priced for home users collude to design their products to take away the computing freedom of home users. This already happened decades ago in the video game industry.
It's no secret that one of the reasons Intel is subsidizing manufacturers over $100M for the Ultrabook project is to keep ARM at bay. This is compounded by Microsoft offering a ARM version of Windows. Apple putting out a really nice A8 MacBook Air could really shake things up.
However, the real issue Apple is going to have is MacOS or iOS. There's a lot of compelling reasons to move to iOS for Apple, but ultimately the closed nature of iOS would likely alienate the large programmer base they have built up.
Gosh, even Slashdot is with this OS X on ARM bullshit. The guy worked porting Darwin, the kernel used by OS X, to some ARM plattform.
But guess what? Darwin is also used by iOS, since the very beggining - Darwin on ARM is hardly news since 2007.
Since the various ARM SoC devices are radically different in how they boot and ennumerate devices a 12 week port time is pretty impressive but Darwin aready runs on arm v5 (and v7). iOS uses the darwin kernel. Since this was a marvell and not a samsung/apple A device a lot of work would have to be done to get the kernel to boot but the basic build system already fully supports ARM.
It's not a secret Apple keeps their options open arch-wise. After the switch the Intel it came out apple had an x86 build of darwin running for years before the switch was decided on. Keeping code portable is a good way to flush out bugs you might have otherwised missed and allows apple to try projects like iOS without a massive effort to get the basic system up and running.
iPAD and iPhone will obiovusly be getting arm v8 chips in a few generations. And I could see apple doing a hybrid macbook air that uses an arm chip to do background network access and the like but it's going to be a long time before ARM chips are playing in even Sandy Bridge territory, let alone what Intel will have in 2 years. I really don't see an arm-only apple notebook anytime soon.
I believe obarthelemy was referring to the $99 per year to run programs that you compiled on a machine that you purchased. Apple copied this from Microsoft's XNA Creators Club (now called App Hub), along with the rest of the pricing structure for the iOS developer program.
I've been hearing a great deal about ARM and it's rise in popularity throughout the Mobile world. But I have to ask: what's so great about it? I'm honestly curious. Can anyone explain it to me?
~theCzar
http://www.osnews.com/story/25588/No_Mac_OS_X_wasn_t_ported_to_ARM_by_an_intern
Some people get all the cool gigs.
MidnightBSD: The BSD for Everyone
Office mac top's out at $280 does it really cost $84 per unit to run a store?
CS 5.5 costs $1,299 - $2,599 apple store max's out at $1000 and does it really cost $390 - $780 per unit to run a store?
For big apps apple will need to have a lower cut and a much better way for site licenses and multi unit pricing systems / let app makes set a lower price per unit for say packs of 25, 50, 100 and so on.
An acadmeic thesis that was actually read!
[Industry-wide lockdown] already happened decades ago in the video game industry.
Happened decades ago with everything Apple too.
I agree with you that it happened long ago with iPod and iPhone, but how "decades ago" and how "everything Apple"? A copy of Xcode is bundled with every Mac (or at least was bundled with a Mac mini in the third quarter of 2009), and the computer's user can use it to develop Mac apps on a Mac without paying any separate annual fee.
But nothing about apple is good news..
Due to a wonderful concept called "free markets" this will almost certainly not happen.
An oligopoly isn't especially a free market. Microsoft has announced that it will require OEMs of devices running Windows 8 for ARM to configure UEFI such that it won't boot anything but Windows 8.
That is, unless perhaps the government decides that "free computing" is dangerous, and mandates that all PCs are locked down.
This almost happened with the SSSCA/CBDTPA proposal. It's also starting to happen with a patent land grab on the part of companies opposed to free computing, namely Microsoft and Apple. Microsoft in particular rakes in royalties for Android equal to those for Windows Phone 7.
Until then, someone will always offer "unlocked" computers due to market demand.
Take this scenario for example: A locked computer costs $200, and an unlocked computer costs $2,000, and you have to be an established business with a secure office to qualify to buy an unlocked computer (source: warioworld.com among others). To what extent will the market demand unlocked computers under such conditions?
One of the more interesting developments in the area of "cheap, general purpose computing" lately is the sub $50 Raspberry Pi. Now there's a hacker platform if I've ever seen one!
But will it stay sub $50, or will the price shoot up as they run out of stock and people start reselling them for a 300% premium or more on eBay, like a recently launched game console?
Nicely done. Nicely done.
This could make MIcrosoft's demand that OEM's make ARM based hardware Microsoft exclusive a bit more interesting...
http://linux.slashdot.org/story/12/01/14/0236244/microsoft-taking-aggressive-steps-against-linux-on-arm
Check your premises.
One undergraduate spending 12 weeks porting Darwin (!) to a new CPU architecture as part of their senior internship should not be used to infer anything about what Apple will be doing moving forward. Have people lost their minds? This is the biggest non-story I've ever read. He could just as easily been doing this with *BSD or Linux or OpenVMS or whatever. Honestly.
TFA says he ported Darwin - the open-source version of the OS X kernel - and got as far as a multi-user login prompt (he'd need some of the BSD toolchain to get that far, but you could run BSD on the ARM-based Acorn Archimedes in the early 90s). Not to be sneezed at as an intern project - but a long, long way from porting "OS X".
Its the difference between porting "Linux" (in the correct sense of the name - i.e. the kernel) and porting Linux + GNU tools + X.Org + KDE/Gnome + ... in order to make something resembling modern Linux distro.
Not that its remotely unfeasible to port OS X to ARM (nobody outside of Apple knows how much of iOS code is directly ported from OS X but economic common sense says "as much as possible") and I'd be unsurprised if Apple had an ARM-based Mac lashed up behind a closed door at Infinite Loop. Apple know a thing or two about supporting multiple processor architectures and It might just make sense as a stop-gap between the iPad and the Air if it offered size/weight/power savings over Intel. Feasible, but probably not likely.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
You can't necessarily run one x86 platform's applications on a different x86-based platform, yet I use plenty of Windows applications on Xubuntu (sudo apt-get install wine). If iOS didn't have the App Store lockdown, someone might probably already have cooked up a Wine-like layer to run other ARM platforms' applications.
The Mac Pro under my desk is running 3 different operating systems - two of them have nothing to do with Apple, yet Apple has not prevented me in any way from doing this.
I guess some just have an axe to grind with Apple.
Like the volunteer efforts to get Ubuntu running on the Asus Transformer series, perhaps there's a niche for a device that can run iOS and Mac OS - AT THE SAME TIME! The next-gen ARM chips support hardware virtualization.
Dock a keyboard and your iPad becomes a mobile OS X workstation for those who need to 'get real work done'. Not all of us need 'legacy' amd64 apps like Photoshop. :-) All the iApps would seamlessly share settings from a common home directory - surprising? not really, same code underneath, just reskinned.
Developing iOS apps in Xcode on the same CPU architecture via a hypervisor should be trivial. Apple would instantly double their iOS developer base, as the disincentive to have to additionally buy a $1000 Mac disappears. And yeah, these quad core CortexA15 ought to be grunty enough to run Xcode provided they're partnered with a decent amount of RAM.
I haven't owned any Apple products since the days of 68k but I'd strongly consider a device that supported seamlessly running both OSes rather than fiddle getting desktop Linux running on a tablet designed for Android (no acclerated drivers for Xorg etc.)
I guess I'm not the target market though...
And considering an intern could port a complete OS port in a mere 12 weeks, shows how portable it is. This person presumably had never touched the OS-X source before, yet manages to pull it off ...
It sounds more like Darwin that Mac OS X in a form the average user would recognize. From the summary: "The port got as far as booting to a multi-user prompt, but then hit hurdles to do with drivers and cache." If so he probably was familiar with it since Darwin is open source, http://www.apple.com/pr/library/2000/04/05Apple-Releases-Darwin-1-0-Open-Source.html.
That said, the intern did great work, I'm happy he got hired by the CoreOS team.
... I suppose portability is simply part of the demands by management ...
I would not be surprised to find that this is just an internal effort to verify portability. Replacing PowerPC as the "other" architecture since ARM represents a viable contingency. It might be wishful thinking to expect an ARM based Mac at any time in the near future.
... I don't think Microsoft will have such an easy time if they were ever to switch to another architecture.
Windows NT was portable from day one of internal development, MIPS and x86. Windows NT 4 shipped with four supported architectures on the standard retail CD: x86, MIPS, Alpha and PowerPC. While subsequent commercial versions of Windows NT only supported one architecture, well two if you count x86 and amd64 separately, Microsoft supposedly continues to build internally on some "other" architecture to maintain portability.
Twelve weeks is a specious number. Interns (i.e., no life) given an interesting project (and they're more likely to be interesting to interns) or trying to impress will often put in 80+ hours a week, so 12 weeks can easily mean 24 or 36 weeks. Granted there'll be some time wasted due to lack of knowledge, but that'll be more than compensated for in poor quality; Not necessarily in terms of errors, but quality in terms of usability by whoever takes over after the internship term ends. (Maybe Apple had to hire the intern.) As someone else posted, "Free lunch!" Indeed!
IOW, the real news has very little to do with the inaccurate, misleading title.
Lets start with being able to get source code for the OS ...
Core OS, filesystem, etc ... sure:
http://www.apple.com/pr/library/2000/04/05Apple-Releases-Darwin-1-0-Open-Source.html
http://www.apple.com/opensource/
... or any of the apps ...
Mac OS X runs the same console and X11 apps as Linux. The X11 display server is well integrated into Mac OS X.
http://docs.info.apple.com/article.html?path=Mac/10.7/en/mchlp2276.html
... Then we'll continue by discussing the DRM.
What is there to discuss? The record industry initially required audio files from the iTunes Store to include DRM but Apple eventually got them to abandon DRM. Mac OS X does not require DRM or the use of the Mac App Store. You can distribute binaries directly to users if you wish. You can distribute open source apps if you like.
While Apple does not offer you the freedom to change the hardware, why would a consumer want to anyway, Apple does not lock you in with regards to operating systems which is what we are talking about here in reality.
If Apple switched to another hardware architecture, your current Mac would still be able to run any other major operating system on the market today including Microsoft Windows, GNU/Linux, *BSD and so on. What "lock in"?
If you believe what's said over on the MacRumors website, they already hashed this possibility out pretty thoroughly and the consensus was that Apple has no real interest in trying to place iOS on a notebook form-factor piece of hardware. The iPad has plenty of room left for improvement and will probably serve as their dominant iOS platform for quite some time.
I have no doubt Apple is working on (even finished?) an ARM port of OS X, but if it's like last time (developed an Intel x86 port of OS X they kept secret and sat on for years, until they decided to leverage it), it'll be something else they keep under wraps, "just in case".
What I think you might see are new computers from Apple running OS X with a touch-screen. That's really the only sensible reason OS X Lion bothered to port over the iOS app screen/launcher. Practically everyone says that's useless/pointless on their Mac, *except* for the possibility it would make a user-friendly option if a touchscreen was present.
The only reason Apple would really be motivated to switch the Air to an ARM processor would be a scenario where Intel quit giving them "first dibs" on new or custom-designed CPUs they'd want. If, say, Toshiba or HP or Dell paid off Intel to get some special treatment Apple couldn't get until after their products were in the pipeline, and it involved making faster, slimmer, lighter notebooks than the Air -- THAT might prompt Apple to retaliate with a switch to ARM.
And how is that Apple's fault?
I agree with you that this is not Apple's fault, and it won't be until Apple itself starts promoting the iPad as a VNC terminal. I just wish some fanboys would stop making the argument that the ability to remote into an SSH/VNC/RDP application server is enough to balance out the closed business model of iOS.
I agree with you that it's not conclusive, but it raises warning flags that I can't ignore.
Windows NT was actually developed originally on MIPS - and ironically, on DECstation 3000s - a DEC MIPS based workstation that was sold w/ only Ultrix - not VMS, and not NT. It was later ported to Intel and Alpha, and when released, it was released for x86, MIPS and Alphas. Silicon Graphics was one of the first companies w/ an NT box based on the MIPS R4000 called Magnum, while DEC released an EISA based PC based on the 21064. Since then, a number of companies tried building NT boxes based on either MIPS or Alpha, but Windows on RISC failed to make any market inroads.
Problem was that while NT was a hybrid architecture to start with, more and more things were moved from user to kernel when NT went from 3.1 to 3.5 to 4.0. As a result, unlike NEXTSTEP, NT became less portable. Also unhelpful was the fact that MS never made any serious attempts to make NT/RISC successful the way they did w/ Windows 95. E.g. the only Office port they did was Word and Excel, ignoring things like Access. End result was that those platforms never took off, and finally, Microsoft canned its support for all of them, including the PowerPC. While ARM has supported Windows CE, on which Windows Phone 7 is based, ARM does not support NT, so Windows 8 on ARM will really be the first port of NT to the ARM, as opposed to the sixth port of NT to the x86. Which is another thing that ensures that Windows 8 on ARM will be a dud. Oh, and incidentally, count Itanium amongst the dead platforms that once ran any version of NT.
Which is why Microsoft doing their phone version of Windows 8 on ARM makes no sense. Anybody who gets anything that runs Windows will expect to somehow run the software they've probably paid good money for on their new tablets or even phones, which won't work if it is based on ARM. I understand that Microsoft may have finally done what they could to make Windows 8 more micro-kernel-ish in order to improve portability, but 10 years after the demise of most RISC platforms, I'd say it's rather late in the game, and it still doesn't solve the issue of ARM not running Windows. A more sensible approach would have been to take AMD's Fusion platform and make a tablet out of it, and use that as the reference platform for Windows Phone 8 or Windows 8 Compact Edition. That way, at least people can be sure that if they manage to install their PC apps on their Windows tablets, it has at least a prayer of working.
Maybe in the ultra-low end market, like smartphones and tablet. The PowerVR deffered tiled rendering architecture has been king on the ultra-low spec for ages.
But Nvidia might be targeting something bigger. Like light-wieght laptops. Device which might require a little bit more graphical power than what can be delivered by a PowerVR or a Tegra, while still benefiting from the massively reduced power consomation that an ARM can provide. (when couple with an SSD and other such low-power components).
(Some DELL Latitude did feature a hybrid ARM/x86 architecture. Same screen, same keyboard. You could either boot into x86 and run a full scale Windows. Or boot into the ARM and run an embed Linux. The ARM/Linux had an impressively better battery life. Okay that came also because the ARM mode didn't power up the harddrive nor the discrete graphic card nor the USB ports).
One could easily imagine a dual-GPU solution, with a Denver containing the next gen Tegra, for when an absolutely low power is needed, and a discrete low-end/low-power GeForce for when the netbook is plugged and needs more graphical omph.
(Somewhat like the current OPTIMUS switching mode between the embed intel graphics and the discrete GPU depending on demand. Excet that a Denver project could bring much longer battery life while in low-power mode, while the discrete GPU could give better performance than a PowerVR, smartphone oriented SoC).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
And considering an intern could port a complete OS port in a mere 12 weeks, shows how portable it is.
Not to minimize the intern's work, but it also shows that some of the iDevice work was also leveraged and recycled.
The GUI might be completely separate between iOS and OS X, but from what I've heard, some code is shared between the lower components of the OSes.
(The kernel is supposed to be the same, for example). So work for some of the component of Mac OS X has already been partly done.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Comment removed based on user account deletion
Comment removed based on user account deletion
And with the new MacOSX on ARM you'll have to buy ALL your software over again as it won't run on it, just like you had to when they switched from powerpc to x86..
Comment removed based on user account deletion
This isn't a high-end ARM chip. Apple is already using this chip in a released product:
https://www.google.com/search?q=apple+marvell+88F6281
In other words, Apple wants the Time Capsule / Airport Extreme to run Darwin instead of NetBSD as it currently does, which makes perfect sense. All the hype about the MacBook ARM is uninformed media nonsense.
If you're willing to include software that was developed, but not released, there are:
m68k (original NeXT hardware)
i386 (NEXTSTEP for Intel processors)
SPARC (NEXTSTEP for SPARC)
HPPA (NEXTSTEP for PA-RISC)
Motorola m88k (NeXT RISC Workstation - never released, but a working copy was at Apple when I worked there)
PowerPC (Mac OS X Server 1.0, later developed into Mac OS X)
Significant bits of NeXT software were also ported to Intel i860 and DEC Alpha, but not enough of the OS to actually qualify as a "NEXTSTEP port"
I'd be willing to put a reasonable amount of money at risk predicting that Apple will eventually ship something that's not an iPhone or iPad, which runs the full version of Mac OS X on the ARM architecture. Given how smooth (relatively speaking) the PPC-to-Intel transition went, it'd be a minor speed bump for most developers, not a major disaster. If you're already supporting PPC and Intel, then ARM is just a testing burden - you already need to code for big- and little-endian architectures, for example.
Given the Mac App Store, there's a lot less in the way of friction to just recompile something and put it out there, as opposed to trying to get boxes on retail shelves. Yes, third-party developers will complain, and so will users if they can't get whatever apps they depend on right away. Given that Macs already come with all the basics (email, web, music/video playback), probably 75% of typical users wouldn't even need to buy anything for an ARM Macbook Air to get plenty of use out of it.
Please read this OS News article, which explains why this does not mean "Mac OS X was ported to ARM", and the actual thesis before commenting.
tl;dr version of the OS News article - it's just a port of Darwin, using the existing ARM support, to an ARMv5 platform, that included fixing bitrot in the ARMv5 support.
His name must be Tristan Schaap. Not Schapp.
He used to work for me, but Apple made him an offer he couldn't refuse. When he left, he said he was going to work in security. Apparently they found something else for him to do :-).
As far as I know he went to apple for an internship, and after that they asked him: finish your studies and come work for us after that.
My company has run ARM9 embedded products since 2004. And since 2004 the ARM processors have always been s..l..o..w.. due to a minuscule L1 cache and no opportunity or support for L2 or L3. Moving the identical applications to Linux x86 PCs, our prior estimate was that the ARM9 processors were 25X slower, clock for clock, than then-current Xeon processors. That turns out to have been wildly optimistic. Running identical code, the Xeons were at least 100X faster than the ARM9s: adjusted for clock rate (533MHz ARM9 vs. 1.8GHz Xeon) we could easily run more than 100X simultaneous processes on the Xeon that contained the entirety of the ARM9 code, barely blipping the CPU load. We ended up being limited by the maximum number of multicast addresses Linux supports.
We were running VxWorks 5.6 on the ARM9 processors and Centos 5.4 Linux on the Xeons.
This was a really lightweight port of just the kernel and a few apps. It looks like they had an existing ARMv5 BSP that was out dated. He went back and got it working and did some work on the l2 cache code for the specific ARM chip. Presumably they have a current port for ARMv7 for the A5 CPU for iPhone & iPad, etc. This was a great project for an intern.
Unfortunately Apple management are going to have freaking kittens when they see the thesis. He outlines some of their internal OS development as well as things that could be considered very proprietary (include an internal svn: path to his code, radar id, some example code with an Apple copyright on it).
Comment removed based on user account deletion
First off, starting with its parent Next, OS X has always been designed to portable. We know they had x86 support years before the changing world of CPU price/performance meant they actually needed to ship it. We know that most of OS X's foundations already runs on ARM anyway--you know iPhone & iPad. I'd be shocked if they don't have internal versions still running on PowerPC. I wouldn't be surprised if they have internal versions running on SPARC, nor if there were an Itanic version floating around somewhere.
Now, put on your thinking cap and ask yourself this question: what does it mean that they tasked an intern with updating ARM support??? HELLOOO... It means that keeping the current version running on ARM is an extremely low priority.
Google site:slashdot.org windows 8 arm uefi gives Microsoft Taking Aggressive Steps Against Linux On ARM.
Apple has spent years and millions on research and development into LLVM which while not currently ideal as a solution for producing VM code friendly with both ARM and x86 or ARM8 and x64, is in theory supposed to be able to handle this. Apple has worked very hard to develop the LLVM project in such a way that it will sooner than later take over the role GCC currently plays on Mac OS X. LLVM and CLang have certainly reached a level of maturity where GCC can soon be the optional compiler as opposed to the main compiler on the platform.
In reality, with the exception of a small amount of code to get the LLVM virtual machine functioning on start-up, it would be possible to get the majority of the system up and running without the need for fat binaries. In fact, even if Apple simply stays with x64, this is a better option than using GCC in the long run since it would allow improvements to LLVM make improvements to how the system performs otherwise. Also by improving the kernel link loader, it would be possible to perform tracing JIT optimization across library boundaries at run-time. This could in theory improve system performance between 10 and 50% depending on how many calls across library boundaries are made.
So, fat binaries, while entertaining are of little use today. Especially when you're talking about two little-endian processors with an instruction set which, while different fundamentally, mirrors one another's capabilities quite closely.
Oh.... and in the area of "compute' power where the GPU is being used for general purpose computing, a more advanced LLVM back-end could in theory recompile certain traces of code to produce GPU specific code. This isn't "that useful" in normal every day code, but it can be extremely useful if any of the languages supported by CLang were extended to support SIMD types like float4 of float8.
> Seriously, the 30% cut just for managing the payment stuff *alone* is a bargain, as anyone who has ever had to handle a merchant account and payment processing will tell you, especially for small transactions. It is very expensive and time consuming to deal with.
Nonsense. Payment transaction charges are nothing like 30%.
I used to work for a company that handled credit card processing, hosting, bandwidth, web servers and designed web storefronts for third party companies. Our cut was nowhere near 30%. AND we warehoused, sorted, picked, packed, and dispatched real physical items. They just told us what products they wanted to sell, and we did the rest.
So, yeah, 30% is a lot for the actual services being provided. What Apple are charging you 30% for is the ability to appear in the App Store, which they have a monopoly over.
RS
I have two, hopefully three, interns coming to work for me this summer. They will develop interesting, but non-critical, add-ons to our core product. If one succeeds, we'll have a better UI. If the second succeeds, we'll have a stepping-stone towards better sound. If the third accepts && succeeds, we'll have a cool demo of a customer-controlled vertical solution.
Anyway, if Apple did release OS X on ARM, they would need to do something about all those x86 binaries. Remember, kids, Apple just barely finished dealing with all those powerPC binaries.
xoxo
Which, if alive today, would have been a perfect target for ReactOS - not dependent on Microsoft for ported apps, but which FOSS developers could have targeted for the fastest workstations available. Too bad that Alpha had to die b'cos HPaq believed in that clusterfuck called Itanic.