Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny.
"Internally" doesn't count from the programmer's point of view; you don't get to write uop code for the particular x86 processor you're running on.
More to the point, the issue with the transition wasn't that it was "RISC to CISC", it that it was "instruction set architecture A to instruction set architecture B". If it were a transition from PowerPC to another RISC instruction set architecture, it would only be easier if the other RISC ISA were big-endian (so that you didn't have to deal with code that's explicitly or implicitly expecting to run on a big-endian ISA).
These are completely different architectures, and I highly doubt portability will be easier between the two, just because one makes the jump to being native 64bit.
Yeah, just as it was extremely difficult to move apps from RISC Macs to CISC Macs. Oh, wait....
(And that transition involved going from big-endian PPC to little-endian x86; I think iOS runs ARM little-endian.)
The difficulty is not the instruction set architecture, the difficulty is the UI toolkit (Cocoa vs. Cocoa Touch) and the different UI choices made due to screen size and touch-screen-vs-{mouse,touchpad} differences in the hardware.
You're an idiot. Debian doesn't distribute source to users.
WTF? Somebody had better tell Richard Stallman.
What he should have said is "Debian doesn't distribute packages as source so that installing them involves recompiling them, they distribute binaries (you can get the source for them, but you don't have to get the source in order to run the code); it's not Gentoo, after all...."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
The same way Apple and OS X developers got code running on both PPC and x86 Macs - it's the Same Operating System. iOS and OS X aren't the same OS; they share a lot of lower-level code and a lot of frameworks but the UI APIs are different - and, despite Kingsley-Hughes's apparent misreading of the Apple document on 64-bit iOS, they remain different OSes in 64-bit mode, even if the lower-level code and frameworks look the same in 64-bit iOS and 64-bit OS X so that non-UI code can largely be the same in iOS and OS X versions of apps.
It would be a big mess to take the existing apps over to OSX.
...because you'd have to replace the UIKit calls (Cocoa Touch) with AppKit calls (Cocoa). 64-bit iOS does not get rid of the Cocoa vs. Cocoa Touch split, even if Kingsley-Hughes misread some Apple documentation and concluded that it might.
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI.
To what are you referring when you speak of "the article"? There are several things linked in the posting. There's Adrian Kingsley-Hughes's ZDNet article, in which he says:
Unifying the iOS/OS X app codebase
Apple openly acknowledges that moving iOS up to 64-bit brings iOS and OS X apps much closer. Take this line from Apple's 64-bit iOS 7 documentation:
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems.
This could be huge.
which does not seem to indicate anything about common backend data-handling code; that's not "unifying the iOS/OS X app codebase", it's "sharing part of the codebase between iOS and OS X, at least if it doesn't depend on a large address space or fast handling of 64-bit integers etc. (in which case 64-bitness isn't that relevant) or if you don't care whether the app runs on anything other than an iPhone 5S and maybe the upcoming iPad 5 and maybe maybe the iPad mini 2 if it's 64-bit", which is a lot less "huge" than "you can just recompile your app for x86 and it'll run on OS X".
And then there's the Apple document, also linked in the original post, which says
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
which, with its explicit mentions of Cocoa and Cocoa Touch, makes it much clearer that you ain't going to "unify the iOS/OS X app codebase", you'll just continue to be able to share some code between iOS and OS X versions of your app.
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X. Pointers and some common C types change from 32 bits to 64 bits. Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
which explicitly speaks of both "Cocoa" and "Cocoa Touch", so there are limits to the extent of the "common code base" - it doesn't include UI code.
The stuff about "Unifying the iOS/OS X app codebase" is, however, just Mr. Kingsley-Hughes trying to score points by Yet Again bringing up the damn "iOS/OS X unification" meme up to show how Forward Thinking he is; perhaps developers might understand what "common code base" meant (having as much of the non-UI parts of the app as possible common between 32-bit iOS, 64-bit iOS, 32-bit OS X if they still care about it, and 64-bit OS X, with the UI built atop Cocoa on OS X and atop Cocoa Touch on iOS), but technology journalists might not.
Anything you read in the tech press immediately after an Apple product announcement is suspect, to me, since there is absolutely no original reporting in any of it.
But what about original bloviating, which is what we have in Mr. Kingsley-Hughes's column? That, unlike original reporting, doesn't require real work.
Or the PDP-11 (no, the original 11/20 and 11/15 couldn't, nor could the 11/10 and 11/05, but the 11/45 could, as could most of the later ones - I forget whether the LSI-11 could). The PDP-11 had a number of obscure OSes that ran on it, none of which left behind any legacy whatsoever in present-day computing.
(Yes, I'm being snarky here. And, yes, I'm thinking of more than one OS, although the legacy of the other one is more indirect.)
I haven't seen any references anywhere about a 64-bit iOS
You haven't been looking in the rightplaces (although "built specifically for 64bit architecture" probably lies somewhere between hyperbole and bullshit, given that it runs Just Fine on 32-bit machines).
more likely this has been done so when Apple releases a 64-bit version of iOS in 2-3 years
I get the technical reasons why this would allow the flexibility of easily porting/running iOS apps on OS X Macs...
Except that there aren't any such reasons; 64-bit iOS does not appear to be any more like 64-bit OS X than 32-bit iOS is like 32-bit OS X.
and...
The vast majority of apps developed for iOS are designed to work better with the limitations of a very portable device (small screen, limited memory and disk storage, etc.). In most cases, they already have more full-featured and capable counterparts that run on regular computer operating systems.
...that's the case. Maybe the "core" of the apps can be shared by the iOS and OS X apps, but the UI's going to be different because 1) Cocoa and Cocoa Touch are different and 2) the machine characteristics are different (which is why Cocoa and Cocoa Touch are different).
Many times, the only reason an "app" exists for iOS (or Android) is to improve an experience that's just fine with a web browser on a Mac or PC, but winds up sub-par on a small touchscreen device.
After all, the core OS is essentially the same between iOS and OSX right now (both Mach kernels with a unix userland).
(Well, to be a bit more accurate, Mach+BSD kernels with a (BSD-flavored) Unix userland; it's not as if section 2 of the manual is implemented atop some non-Unixy Mach system call layer - the lowest layers of the kernel are Mach-based (the osfmk source directory), but the networking stack and VFS layer are largely BSDish, and the process management is BSDish processes, and pthreads (and threads as used by GCD), implemented atop Mach tasks and threads (all the bsd source directory), and the hardware device driver layer is I/O Kit (the iokit source directory). Yes, you also get Mach system calls, of which by far the most important ones are the ones to send and receive Mach messages, and those are used fairly extensively.)
The architecture for 64-bit apps on iOS is almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. Converting a Cocoa Touch app to 64-bit follows a similar transition process as the one for Cocoa apps on OS X.
That sounds more like "we 64-bitified iOS in a fashion almost identical to the way we 64-bitified OS X", not "64-bit iOS and 64-bit OS X are closer to each other than are 32-bit iOS and 32-bit OS X". You still have to go from Cocoa to Cocoa Touch....
Go to the Apple Store, configure a 15" Retina MBP and find this greeting:
Storage
Your MacBook Pro comes standard with 256GB or 512GB of flash storage. Please note that the flash storage is built into the computer, so if you think you may need more storage capacity in the future, it is important to upgrade at the time of purchase.
What that means is that Apple won't upgrade it after you buy the machine. "Built into the computer" does not, as the pictures on the iFixit pages indicate, mean "soldered onto the motherboard".
Government utilities are good at things that have very mature and long proven technologies that are not likely to change much. There's few breakthroughs in road building, or delivering water. Power was taken over a bit too early, and stifled innovation. Internet would be a terrible idea as we'd be stuck at the current state pretty much for ever.
Not that the person to whom you were responding was advocating making Internet service into a government utility; as the introductory sentence of their post said, "In many countries public utilities are run by a commercial company, for profit.", and they then gave Internet service in the Netherlands as an example:
Telephone/internet (ADSL) infrastructure, like in The Netherlands, is owned almost entirely by KPN, the former state-owned telephone company. They have the job to provide the infrastructure, and accept other ISPs on that same infrastructure at a fixed price. All ISPs pay the same for access to the homes. And KPN makes profits by keepking their cost lower than the set price they may charge for access. Currently there are dozens of ISPs available for end users, competing with one another, keeping their price low and their service quality high.
(emphasis mine - former state-owned, not state-owned).
Who was Snowden aiding and comforting when he published his materials?
There are probably people who would manage to find somebody they believe he aided. I'm not one of them; the point is that no country's constitution is a Magic Talisman that has only one interpretation so that it will never be interpreted in ways that people who believe it's a Magic Talisman against <whatever> won't like.
Nothing. The subject line says "FreeBSD", not "OS X" or "Xcode".
What I want to know is if I'll still need to download Xcode from the App Store to get a copy of GCC.
Then ask Apple whether 1) the only way to get a compiler from Apple will continue to be to download Xcode and 2) whether Apple will continue to provide GCC.
Microsoft will give you a "single pane of glass" for "future stars" to view all the "innovations" and "mentorship" in a "major paradigm shift" to "foster success"
But only if you proactively leverage your synergies.
Apple is the bully who took your 3 lunch sandwiches, added ketchup to one of them and gave it back to you and made you say "thank you sir for the ketchup".
If you're talking about KHTML, and the original complaints about how Apple treated it, I think it's more like "made copies of the recipes for your 3 lunch sandwiches, changed one of the recipes to include ketchup, and handed you back the raw new recipes without change bars". It's not as if they "took" KHTML in such a way that it immediately ceased to work in KDE.
They're too busy chasing after precocious people with libertarian ideals that could threaten the establishment and bullying them into suicide.
As well as going after Aaron Swartz and bullying him into suicide. (Or by "libertarian ideals" do you mean "ideals supportive of civil liberties" rather than "free-market ideals"?)
Slashdot Mirror
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny.
"Internally" doesn't count from the programmer's point of view; you don't get to write uop code for the particular x86 processor you're running on.
More to the point, the issue with the transition wasn't that it was "RISC to CISC", it that it was "instruction set architecture A to instruction set architecture B". If it were a transition from PowerPC to another RISC instruction set architecture, it would only be easier if the other RISC ISA were big-endian (so that you didn't have to deal with code that's explicitly or implicitly expecting to run on a big-endian ISA).
These are completely different architectures, and I highly doubt portability will be easier between the two, just because one makes the jump to being native 64bit.
Yeah, just as it was extremely difficult to move apps from RISC Macs to CISC Macs. Oh, wait....
(And that transition involved going from big-endian PPC to little-endian x86; I think iOS runs ARM little-endian.)
The difficulty is not the instruction set architecture, the difficulty is the UI toolkit (Cocoa vs. Cocoa Touch) and the different UI choices made due to screen size and touch-screen-vs-{mouse,touchpad} differences in the hardware.
You're an idiot. Debian doesn't distribute source to users.
WTF? Somebody had better tell Richard Stallman.
What he should have said is "Debian doesn't distribute packages as source so that installing them involves recompiling them, they distribute binaries (you can get the source for them, but you don't have to get the source in order to run the code); it's not Gentoo, after all...."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
The same way Apple and OS X developers got code running on both PPC and x86 Macs - it's the Same Operating System. iOS and OS X aren't the same OS; they share a lot of lower-level code and a lot of frameworks but the UI APIs are different - and, despite Kingsley-Hughes's apparent misreading of the Apple document on 64-bit iOS, they remain different OSes in 64-bit mode, even if the lower-level code and frameworks look the same in 64-bit iOS and 64-bit OS X so that non-UI code can largely be the same in iOS and OS X versions of apps.
It would be a big mess to take the existing apps over to OSX.
...because you'd have to replace the UIKit calls (Cocoa Touch) with AppKit calls (Cocoa). 64-bit iOS does not get rid of the Cocoa vs. Cocoa Touch split, even if Kingsley-Hughes misread some Apple documentation and concluded that it might.
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI.
To what are you referring when you speak of "the article"? There are several things linked in the posting. There's Adrian Kingsley-Hughes's ZDNet article, in which he says:
which does not seem to indicate anything about common backend data-handling code; that's not "unifying the iOS/OS X app codebase", it's "sharing part of the codebase between iOS and OS X, at least if it doesn't depend on a large address space or fast handling of 64-bit integers etc. (in which case 64-bitness isn't that relevant) or if you don't care whether the app runs on anything other than an iPhone 5S and maybe the upcoming iPad 5 and maybe maybe the iPad mini 2 if it's 64-bit", which is a lot less "huge" than "you can just recompile your app for x86 and it'll run on OS X".
And then there's the Apple document, also linked in the original post, which says
which, with its explicit mentions of Cocoa and Cocoa Touch, makes it much clearer that you ain't going to "unify the iOS/OS X app codebase", you'll just continue to be able to share some code between iOS and OS X versions of your app.
So, you believe that this is something other than an Apple marketing press release. I don't.
What Apple said in their document was
which explicitly speaks of both "Cocoa" and "Cocoa Touch", so there are limits to the extent of the "common code base" - it doesn't include UI code.
The stuff about "Unifying the iOS/OS X app codebase" is, however, just Mr. Kingsley-Hughes trying to score points by Yet Again bringing up the damn "iOS/OS X unification" meme up to show how Forward Thinking he is; perhaps developers might understand what "common code base" meant (having as much of the non-UI parts of the app as possible common between 32-bit iOS, 64-bit iOS, 32-bit OS X if they still care about it, and 64-bit OS X, with the UI built atop Cocoa on OS X and atop Cocoa Touch on iOS), but technology journalists might not.
Anything you read in the tech press immediately after an Apple product announcement is suspect, to me, since there is absolutely no original reporting in any of it.
But what about original bloviating, which is what we have in Mr. Kingsley-Hughes's column? That, unlike original reporting, doesn't require real work.
It was called the IBM PC.
Or the PDP-11 (no, the original 11/20 and 11/15 couldn't, nor could the 11/10 and 11/05, but the 11/45 could, as could most of the later ones - I forget whether the LSI-11 could). The PDP-11 had a number of obscure OSes that ran on it, none of which left behind any legacy whatsoever in present-day computing.
(Yes, I'm being snarky here. And, yes, I'm thinking of more than one OS, although the legacy of the other one is more indirect.)
I haven't seen any references anywhere about a 64-bit iOS
You haven't been looking in the right places (although "built specifically for 64bit architecture" probably lies somewhere between hyperbole and bullshit, given that it runs Just Fine on 32-bit machines).
more likely this has been done so when Apple releases a 64-bit version of iOS in 2-3 years
Make that "in 4 to 5 days" instead.
I get the technical reasons why this would allow the flexibility of easily porting/running iOS apps on OS X Macs ...
Except that there aren't any such reasons; 64-bit iOS does not appear to be any more like 64-bit OS X than 32-bit iOS is like 32-bit OS X.
and...
The vast majority of apps developed for iOS are designed to work better with the limitations of a very portable device (small screen, limited memory and disk storage, etc.). In most cases, they already have more full-featured and capable counterparts that run on regular computer operating systems.
...that's the case. Maybe the "core" of the apps can be shared by the iOS and OS X apps, but the UI's going to be different because 1) Cocoa and Cocoa Touch are different and 2) the machine characteristics are different (which is why Cocoa and Cocoa Touch are different).
Many times, the only reason an "app" exists for iOS (or Android) is to improve an experience that's just fine with a web browser on a Mac or PC, but winds up sub-par on a small touchscreen device.
Well, hopefully it's an improvement.
After all, the core OS is essentially the same between iOS and OSX right now (both Mach kernels with a unix userland).
(Well, to be a bit more accurate, Mach+BSD kernels with a (BSD-flavored) Unix userland; it's not as if section 2 of the manual is implemented atop some non-Unixy Mach system call layer - the lowest layers of the kernel are Mach-based (the osfmk source directory), but the networking stack and VFS layer are largely BSDish, and the process management is BSDish processes, and pthreads (and threads as used by GCD), implemented atop Mach tasks and threads (all the bsd source directory), and the hardware device driver layer is I/O Kit (the iokit source directory). Yes, you also get Mach system calls, of which by far the most important ones are the ones to send and receive Mach messages, and those are used fairly extensively.)
The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps
Well, if you read the full quote from the Apple document in question, it says:
That sounds more like "we 64-bitified iOS in a fashion almost identical to the way we 64-bitified OS X", not "64-bit iOS and 64-bit OS X are closer to each other than are 32-bit iOS and 32-bit OS X". You still have to go from Cocoa to Cocoa Touch....
Go to the Apple Store, configure a 15" Retina MBP and find this greeting:
Storage Your MacBook Pro comes standard with 256GB or 512GB of flash storage. Please note that the flash storage is built into the computer, so if you think you may need more storage capacity in the future, it is important to upgrade at the time of purchase.
What that means is that Apple won't upgrade it after you buy the machine. "Built into the computer" does not, as the pictures on the iFixit pages indicate, mean "soldered onto the motherboard".
They sell several amounts of already soldered chips on the main board.
Not soldered to the motherboard for the 15" Retina MBP and not soldered to the motherboard for the 13" Retina MBP. On which Macs is the SSD soldered to the motherboard?
Government utilities are good at things that have very mature and long proven technologies that are not likely to change much. There's few breakthroughs in road building, or delivering water. Power was taken over a bit too early, and stifled innovation. Internet would be a terrible idea as we'd be stuck at the current state pretty much for ever.
Not that the person to whom you were responding was advocating making Internet service into a government utility; as the introductory sentence of their post said, "In many countries public utilities are run by a commercial company, for profit.", and they then gave Internet service in the Netherlands as an example:
(emphasis mine - former state-owned, not state-owned).
Who was Snowden aiding and comforting when he published his materials?
There are probably people who would manage to find somebody they believe he aided. I'm not one of them; the point is that no country's constitution is a Magic Talisman that has only one interpretation so that it will never be interpreted in ways that people who believe it's a Magic Talisman against <whatever> won't like.
We don't have to "define treason". The Constitution does that quite nicely in Article 3, Section 3.
And who defines "Aid and Comfort"?
Let's see how he handles the 3rd coming financial crisis when he is about to get re-elected.
Re-elected to the US Senate, or re-elected to the Illinois Senate? And would going back after 8 years as president count as being "re-elected"?
Or did you mean "how he handled ... when he was about to get re-elected"?
What does this mean for OSX and Xcode?
Nothing. The subject line says "FreeBSD", not "OS X" or "Xcode".
What I want to know is if I'll still need to download Xcode from the App Store to get a copy of GCC.
Then ask Apple whether 1) the only way to get a compiler from Apple will continue to be to download Xcode and 2) whether Apple will continue to provide GCC.
Microsoft will give you a "single pane of glass" for "future stars" to view all the "innovations" and "mentorship" in a "major paradigm shift" to "foster success"
But only if you proactively leverage your synergies.
How much did apple make?
During the same quarter (Q2 2010)? Assuming ExxonMobil and Apple mean the same thing when they say "Q2", it's 3.07 billion dollars.
Apple is the bully who took your 3 lunch sandwiches, added ketchup to one of them and gave it back to you and made you say "thank you sir for the ketchup".
If you're talking about KHTML, and the original complaints about how Apple treated it, I think it's more like "made copies of the recipes for your 3 lunch sandwiches, changed one of the recipes to include ketchup, and handed you back the raw new recipes without change bars". It's not as if they "took" KHTML in such a way that it immediately ceased to work in KDE.
They're too busy chasing after precocious people with libertarian ideals that could threaten the establishment and bullying them into suicide.
As well as going after Aaron Swartz and bullying him into suicide. (Or by "libertarian ideals" do you mean "ideals supportive of civil liberties" rather than "free-market ideals"?)
ask yourself what it takes to make plastic:
BIG OIL
Making more sense now?
No.
However, some of the other replies, saying "it's cheaper and easier to form plastic shells than to make metal shells", do make it make more sense.
Between them Google, Yahoo and Facebook pretty much own the American Government.
...because, of course, there are no other large US corporations that might have their own desires, not always aligned with those three corporations.