But wait - when the Iphone lacked these features, we had no end of "But the Iphone is better off without copy/paste and MMS, it has better paradigms to do these things (but I can't explain what), and what makes Apple so great is that they remove the clutter of items it thinks you don't want".
From Apple, or from idiot fanboys? (Wait, isn't "idiot fanboys" redundant?)
The point still stands though - when copy/paste and MMS came out, the fact that people queued in line for them doesn't show Apple are great, it shows that people wanted the "new" (for the Iphone) features.
If people queued in line for a new iPhone, when they already had an iPhone, when copy/paste and MMS came out, either they wanted something the new hardware offered (3G and/or GPS), or they were apparently completely unaware that they could just do a software update on their existing iPhone to get copy/paste and do a software update on their existing iPhone 3G (although, if their carrier was AT&T, they'd have to do a software update and wait for AT&T to get its act together) to get MMS.
If they queued in line for their first iPhone when copy/paste and MMS came out, that might, or might not, have been because they didn't want the iPhone before its OS supported those features because those features were a requirement. It could also have been, for example, because they wanted 3G and/or GPS, and the earlier iPhone had neither.
However, the poster to whom you replied said people queued up for iPhones before copy/paste or MMS were available, not that they queued up when they were made available. Perhaps that shows that there are people for whom those features might be nice, but not necessary (I'm glad I can do copy-and-paste now, but I wasn't suffering intolerably without it, and I've never been tempted to use MMS - which is good, considering I have a Boring Old 2G iPhone which doesn't do MMS even with the latest release and carrier settings; the only 3.0 feature that really made a difference to me was access to CalDAV servers, as it gave me access to the corporate calendar server).
If this new version supports copy and paste finally
iPhone OS 3.1 supports copy-and-paste. Heck, iPhone OS 3.0 supports copy-and-paste. Presumably iPhone 3,1 will run iPhone OS 3.x or a future release, and will support copy-and-paste, just as every other damn iPhone on the planet running iPhone OS 3.x supports it, even my old iPhone 1,0 or whatever the first one was.
(I.e.: 1) "supports copy and paste" is a function of the OS rather than the device and 2) the OS has supported it since the 3.0 release. 3.x also supports MMS on 3G iPhones if the phone company allows it.)
Apple invented SCSI? News to me. FireWire, yes, but SCSI, no. They may have adopted it to a greater extent than other personal computer makers, but they didn't invent it.
"Does not" support multitasking for third-party apps through the official app store? Correct.
"Does not" support multitasking for bundled apps? Incorrect, although even those apps are subject to being suddenly terminated if a foreground app needs more memory.
"Does not" support multitasking for third-party apps on jailbroken phones? Incorrect, modulo the previous comment about sudden termination.
You are cxomparing Multics (1970 hardware and software)
OK (started in the late 1960's, but mostly 70's)...
with Unix (1980 hardware and software)
Well, I guess the flurry of "1) pick a microprocessor 2) build/buy a UNIX port 3) ??? 4) Profit!" machines was mainly in the 1980's, kicked off by AT&T's binary licensing of V7, but UNIX dates back to the 1970's as well, on the originated-in-the-1970's PDP-11.
and VMS (1990 hardware and software)
Erm, try "VMS (late 1970's hardware and software)" - the VAX, and VMS, came out in the late '70's.
The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.
Explorer is a cross between your shell and your window manager, its like the Gnome or KDE window managers
Actually, it's a file manager, hence like GNOME's Nautilus or KDE's Konqueror (the file manager part) or Dolphin. It might also provide functionality of various bars on the edges of the screen (task bar, etc.) and the desktop; I'm not sure which parts of GNOME and KDE implement those.
You can not kill the X11 client
...by which you mean the process/program that the X11 developers call "the X server" (because, with the model of "clients connect to a server and ask it to do things for them", that's the role it serves, confusing though that terminology might be for those who have a model of "a client is something like your desktop machine, a server is a machine in the machine room" nonwithstanding).
Except that 10.6 runs on any intel Mac including the first MacBooks and Mac Minis and MacBook Pros and iMacs which weren't core 2 duo, which means they are not 64-bit.
Yup. The person to whom you responded was massively confused. What 10.6 does is
build almost all of the userland programs 2-way fat (32-bit x86 and and x86-64);
provide a 2-way fat kernel, so that on some machines the kernel runs 64-bit.
It does not, in any way, shape, or form, require a 64-bit processor to run at all.
On-board devices that let the passenger use them even when the car's moving will snuff out standalone GPS far quicker than Android with google maps ever will.
There, fixed that for you. (I can't remember the time we last used the nav system in my car. We frequently use Google Maps on our iPhones, however - the fact that we don't have nav systems in both our cars helps, and the fact that the UI of the nav system in my car sucks donkey dicks helps, but the fact that if I'm driving the nav system won't let the passenger use it even though they're not behind the wheel also helps encourage use of the iPhone as a nav system.)
Is that merely a software thing? As in, the navigation software infers your current position from:...
To some extent it is, but the car GPS units recover much quicker when they go astray (I have a Garmin). The iPhone at least behaves somewhat similarly when moving, but just doesn't get a valid fix as soon after a turn.
Is that merely a software thing? (Yes, that's a serious question, the fact that it's the question you were trying to answer nonwithstanding. Is that a result of your Garmin having a better receiver (possibly not capable of being worked around in software), or is it a consequence of Garmin's software currently being better than Apple's (possibly fixable in a software update)?
It's not a variant. It is the same code that runs on an iMac or MacBook, just trimmed back (e.g., no FireWire or SATA drivers).
...and no AppKit (or Carbon; AppKit is replaced by UIKit, and Carbon is replaced by nothing). Perhaps you don't consider the GUI toolkit as part of "the code" to which you're referring, but it's certainly relevant to application developers (you can't just recompile a Mac OS X app for iPhone OS, and you can't just recompile an iPhone OS app for Mac OS X - and I'm not sure you should, given that a UI design for a computer with a 13"+ screen, full keyboard, and mouse/trackpad might not be very good for a computer with a 6" touchscreen with the keyboard popping up on the touchscreen - and vice versa).
What "RISC bottlenecks" (other than "RISC chip developers don't have the money that Intel does") are there that aren't also bottlenecks for x86?
x86 can simply gun for greater clock speed.
...and the RISC vendors can't? (Not that Intel is exactly "simply [gunning] for greater clock speed" - I don't think they've yet come out with a post-NetBurst processor that has a clock speed as fast as the fastest NetBurst had. That suggests that clock speed isn't everything....)
IMO Transmeta had it right: very long instruction words (which ultimately do 'everything').
...devoted to implementing x86, so that you never actually saw the native instruction sets ("sets", plural, as I think their first processor and second processor had different underlying instruction sets).
If you know what you're doing, you can actually extract the Mach-O binaries from the fat binary and distribute them separately (I've done it with a hex editor, but I'm sure there are plenty of other ways to do it).
Yes, if you know what you're doing, you know how to use the lipo command to do it.:-)
You are confusing NeXT and Apple's approaches, I think.
You should think differently. NeXTStEP introduced a fat binary scheme to allow a single executable file to contain binaries for 68k NeXT boxes and x86 PC's running NeXTStEP. OS X picked up that scheme from NeXTStEP, so NeXT's and Apple's approaches are the same.
Your code is compiled twice, but it's only linked once.
No, it's compiled N times, and linked N times, once for each instruction set architecture.
The PowerPC {32,64} and x86 {32,64} code all goes in different segments in the binary, but data is shared between all of them, so it takes less space than having 2-4 independent binary files.
If by "data" you mean data in files under, say, Resources in the app bundle, yes, it can be shared. If by "data" you mean the data segments in the executable, no, it's not shared - a fat binary is just a bunch of Mach-O binaries with a special header wrapped around them, and each Mach-O binary has a full set of text/data/etc. segments.
To support this on Linux would not require any changes to the kernel, only to the loader (which is a GNU project, and not actually part of Linux).
If by "this" you mean something that looks like OS X fat binaries, you would have to change the kernel to understand fat binary files, running the appropriate executable within that file.
Considering how few PPC apps in use now days, it seems logical.
I've only been a mac user for a few months, but I've never seen a PPC binary, with the exception of the one 'hello world' universal binary I made just to see what would happen.
Never run Quicken for Mac, I guess (except perhaps for a pre-release of Quicken Life for Mac^W^W^W^WQuicken 2010 for Mac):
It's also theoretically possible to include ARM support too, to make a binary that would also run on an iphone...
...as long as you don't use such minor unimportant frameworks as AppKit (no AppKit on iPhone OS; it's UIKit instead). You could make a fat command-line binary, I guess....
Apple's CoreOS team includes several of the lead engineers from the ZFS project (who fled the remnants of Sun in the Schwartz melt-down), and the architect of the BeFS.
If this (potentially) verifiable information is accurate,
The bit about the architect of BeFS is verifiable if you believe his home page (I do).
Slashdot Mirror
But wait - when the Iphone lacked these features, we had no end of "But the Iphone is better off without copy/paste and MMS, it has better paradigms to do these things (but I can't explain what), and what makes Apple so great is that they remove the clutter of items it thinks you don't want".
From Apple, or from idiot fanboys? (Wait, isn't "idiot fanboys" redundant?)
The point still stands though - when copy/paste and MMS came out, the fact that people queued in line for them doesn't show Apple are great, it shows that people wanted the "new" (for the Iphone) features.
If people queued in line for a new iPhone, when they already had an iPhone, when copy/paste and MMS came out, either they wanted something the new hardware offered (3G and/or GPS), or they were apparently completely unaware that they could just do a software update on their existing iPhone to get copy/paste and do a software update on their existing iPhone 3G (although, if their carrier was AT&T, they'd have to do a software update and wait for AT&T to get its act together) to get MMS.
If they queued in line for their first iPhone when copy/paste and MMS came out, that might, or might not, have been because they didn't want the iPhone before its OS supported those features because those features were a requirement. It could also have been, for example, because they wanted 3G and/or GPS, and the earlier iPhone had neither.
However, the poster to whom you replied said people queued up for iPhones before copy/paste or MMS were available, not that they queued up when they were made available. Perhaps that shows that there are people for whom those features might be nice, but not necessary (I'm glad I can do copy-and-paste now, but I wasn't suffering intolerably without it, and I've never been tempted to use MMS - which is good, considering I have a Boring Old 2G iPhone which doesn't do MMS even with the latest release and carrier settings; the only 3.0 feature that really made a difference to me was access to CalDAV servers, as it gave me access to the corporate calendar server).
If this new version supports copy and paste finally
iPhone OS 3.1 supports copy-and-paste. Heck, iPhone OS 3.0 supports copy-and-paste. Presumably iPhone 3,1 will run iPhone OS 3.x or a future release, and will support copy-and-paste, just as every other damn iPhone on the planet running iPhone OS 3.x supports it, even my old iPhone 1,0 or whatever the first one was.
(I.e.: 1) "supports copy and paste" is a function of the OS rather than the device and 2) the OS has supported it since the 3.0 release. 3.x also supports MMS on 3G iPhones if the phone company allows it.)
1. Mention how you can access the Apple Store website On Your Iphone. That's a guaranteed way to get a story.
So where's the place on the Apple Store where you can buy your way out of a parking ticket?
And SCSI. And FireWire.
Apple invented SCSI? News to me. FireWire, yes, but SCSI, no. They may have adopted it to a greater extent than other personal computer makers, but they didn't invent it.
I suggest thinking of the Newton as the Iphone 1G
It supports various analog cell phone technologies such as AMPS? :-)
No. It does not.
"Does not" support multitasking for third-party apps through the official app store? Correct.
"Does not" support multitasking for bundled apps? Incorrect, although even those apps are subject to being suddenly terminated if a foreground app needs more memory.
"Does not" support multitasking for third-party apps on jailbroken phones? Incorrect, modulo the previous comment about sudden termination.
Of course the iphone is innovative. Who else but apple would think it's a good idea to blindly execute whatever program it receives by SMS?
Android? (They hadn't finished testing Windows Mobile as of when they published that paper.)
Got $2 million in assets? Then you can join BillionaireXchange
So the "Billionaire" "Xchange" only requires $2M in assets? Somebody's off by almost 3 orders of magnitude, base 10....
You are cxomparing Multics (1970 hardware and software)
OK (started in the late 1960's, but mostly 70's)...
with Unix (1980 hardware and software)
Well, I guess the flurry of "1) pick a microprocessor 2) build/buy a UNIX port 3) ??? 4) Profit!" machines was mainly in the 1980's, kicked off by AT&T's binary licensing of V7, but UNIX dates back to the 1970's as well, on the originated-in-the-1970's PDP-11.
and VMS (1990 hardware and software)
Erm, try "VMS (late 1970's hardware and software)" - the VAX, and VMS, came out in the late '70's.
Ever eat beans and then take a shit and see some intact beans in your shit, sorta like corn? That's Netbeans.
Those are gross beans, not net beans.
You want a browser to be a file manager?
No, he wants it to be a browser that supports NTLM Authentication for HTTP. The "LM" in "NTLM" nonwithstanding, it's used for more than just SMB.
The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.
So what are some of those awesome features?
Us losers? Are you implying that somehow you are exempt from being a loser while still posting to slashdot just because you are anonymous?
An anonymous coward who knows what he or she is talking about is far more valuable than a poster with an account who doesn't.
Explorer is a cross between your shell and your window manager, its like the Gnome or KDE window managers
Actually, it's a file manager, hence like GNOME's Nautilus or KDE's Konqueror (the file manager part) or Dolphin. It might also provide functionality of various bars on the edges of the screen (task bar, etc.) and the desktop; I'm not sure which parts of GNOME and KDE implement those.
You can not kill the X11 client
...by which you mean the process/program that the X11 developers call "the X server" (because, with the model of "clients connect to a server and ask it to do things for them", that's the role it serves, confusing though that terminology might be for those who have a model of "a client is something like your desktop machine, a server is a machine in the machine room" nonwithstanding).
Except that 10.6 runs on any intel Mac including the first MacBooks and Mac Minis and MacBook Pros and iMacs which weren't core 2 duo, which means they are not 64-bit.
Yup. The person to whom you responded was massively confused. What 10.6 does is
It does not, in any way, shape, or form, require a 64-bit processor to run at all.
Maybe this will apply some pressure on Garmin and/or TomTom to not gouge quite so heavily for updated maps.
Mr. ZFS agrees with you on that.
On-board devices that let the passenger use them even when the car's moving will snuff out standalone GPS far quicker than Android with google maps ever will.
There, fixed that for you. (I can't remember the time we last used the nav system in my car. We frequently use Google Maps on our iPhones, however - the fact that we don't have nav systems in both our cars helps, and the fact that the UI of the nav system in my car sucks donkey dicks helps, but the fact that if I'm driving the nav system won't let the passenger use it even though they're not behind the wheel also helps encourage use of the iPhone as a nav system.)
Is that merely a software thing? As in, the navigation software infers your current position from:...
To some extent it is, but the car GPS units recover much quicker when they go astray (I have a Garmin). The iPhone at least behaves somewhat similarly when moving, but just doesn't get a valid fix as soon after a turn.
Is that merely a software thing? (Yes, that's a serious question, the fact that it's the question you were trying to answer nonwithstanding. Is that a result of your Garmin having a better receiver (possibly not capable of being worked around in software), or is it a consequence of Garmin's software currently being better than Apple's (possibly fixable in a software update)?
It's not a variant. It is the same code that runs on an iMac or MacBook, just trimmed back (e.g., no FireWire or SATA drivers).
...and no AppKit (or Carbon; AppKit is replaced by UIKit, and Carbon is replaced by nothing). Perhaps you don't consider the GUI toolkit as part of "the code" to which you're referring, but it's certainly relevant to application developers (you can't just recompile a Mac OS X app for iPhone OS, and you can't just recompile an iPhone OS app for Mac OS X - and I'm not sure you should, given that a UI design for a computer with a 13"+ screen, full keyboard, and mouse/trackpad might not be very good for a computer with a 6" touchscreen with the keyboard popping up on the touchscreen - and vice versa).
RISC bottlenecks will always be bottlenecks;
What "RISC bottlenecks" (other than "RISC chip developers don't have the money that Intel does") are there that aren't also bottlenecks for x86?
x86 can simply gun for greater clock speed.
...and the RISC vendors can't? (Not that Intel is exactly "simply [gunning] for greater clock speed" - I don't think they've yet come out with a post-NetBurst processor that has a clock speed as fast as the fastest NetBurst had. That suggests that clock speed isn't everything....)
IMO Transmeta had it right: very long instruction words (which ultimately do 'everything').
...devoted to implementing x86, so that you never actually saw the native instruction sets ("sets", plural, as I think their first processor and second processor had different underlying instruction sets).
If you know what you're doing, you can actually extract the Mach-O binaries from the fat binary and distribute them separately (I've done it with a hex editor, but I'm sure there are plenty of other ways to do it).
Yes, if you know what you're doing, you know how to use the lipo command to do it. :-)
You are confusing NeXT and Apple's approaches, I think.
You should think differently. NeXTStEP introduced a fat binary scheme to allow a single executable file to contain binaries for 68k NeXT boxes and x86 PC's running NeXTStEP. OS X picked up that scheme from NeXTStEP, so NeXT's and Apple's approaches are the same.
Your code is compiled twice, but it's only linked once.
No, it's compiled N times, and linked N times, once for each instruction set architecture.
The PowerPC {32,64} and x86 {32,64} code all goes in different segments in the binary, but data is shared between all of them, so it takes less space than having 2-4 independent binary files.
If by "data" you mean data in files under, say, Resources in the app bundle, yes, it can be shared. If by "data" you mean the data segments in the executable, no, it's not shared - a fat binary is just a bunch of Mach-O binaries with a special header wrapped around them, and each Mach-O binary has a full set of text/data/etc. segments.
To support this on Linux would not require any changes to the kernel, only to the loader (which is a GNU project, and not actually part of Linux).
If by "this" you mean something that looks like OS X fat binaries, you would have to change the kernel to understand fat binary files, running the appropriate executable within that file.
Considering how few PPC apps in use now days, it seems logical.
I've only been a mac user for a few months, but I've never seen a PPC binary, with the exception of the one 'hello world' universal binary I made just to see what would happen.
Never run Quicken for Mac, I guess (except perhaps for a pre-release of Quicken Life for Mac^W^W^W^WQuicken 2010 for Mac):
Not only is it not fat, it's not even Mach-O....
It's also theoretically possible to include ARM support too, to make a binary that would also run on an iphone...
...as long as you don't use such minor unimportant frameworks as AppKit (no AppKit on iPhone OS; it's UIKit instead). You could make a fat command-line binary, I guess....
Apple's CoreOS team includes several of the lead engineers from the ZFS project (who fled the remnants of Sun in the Schwartz melt-down), and the architect of the BeFS.
If this (potentially) verifiable information is accurate,
The bit about the architect of BeFS is verifiable if you believe his home page (I do).