you might end up with the typical Windows "we know what it is better than you do" plug-n-pray hell.
So how common are scenarios in which plug-n-play fails? Are they truly "typical", or are they sufficiently uncommon that, on the whole, users are better off with plug-and-play rather than (the also potentially error-prone) plug-and-tell-the-computer?
Joe User is not being asked to answer those questions.
So who does answer those questions when installing a TV tuner card on a Linux system?
Guy Harris seemed to think it was a trivial matter of querying the card.
Seemed to some, perhaps, but I wasn't, in fact, saying it was a trivial matter of querying the card, I was asking whether it was a trivial matter of querying the card and, then, noting that if it was, that's what the driver should be doing, rather than obliging the user to tell the computer something it already knows.
So, if, in fact, the tuner type is at an undiscoverable i2c address, yes, I do have another question - the question already asked in another followup, namely "how do the vendor's Windows drivers tell the difference?"
Does the Windows driver, by virtue of (presumably) having been written by the vendor of the card, include code that knows where to look on the i2c bus to get the tuner type, so that the ultimate problem is that the vendor isn't being helpful to developers of drivers for other OSes?
Or does the Windows driver also require the user to configure it with the tuner type information, so the ultimate problem is that the vendor is being stupid?
my tv card also works great with the bttv and I only need to seelect the tuner type in a config file
Can a driver determine the tuner type by querying the card?
If so, then requiring the user to select the tuner type in a config file is completely stupid; the user shouldn't have to tell the computer something about a peripheral if the computer can determine that information itself without the user having to get involved.
However, Apples developer documentation (Universal Binary pdf) explicitly states IA32 support, not IA64 support
(Presumably you meant "x86-64 support", not "IA-64 support" - IA-64 is completely unlike IA-32, the "IA" nonwithstanding; it's the instruction set architecture the Itanium series uses.)
A truly universal OS X binary can't make full use of x86-64, for one simple reason:
Making full use of x86-64 means "building for LP64", and there are plenty of Macs Apple is selling now that aren't LP64-capable (PowerBooks, iBooks, Mac Minis). A truly universal binary would be a 32-bit binary on PowerPC, and thus presumably a 32-bit binary on x86. I don't know whether any such binary can use any other x86-64 features, e.g. the 8 other registers.
You may be right, but, he has a cooler nick name than you!
The person TheKidWho's calling a "fucking idiot" has the nickname "Robert X. Cringley", not "Drakonian" - TheKidWho appears to be violently agreeing with Drakonian on this.
The current guidelines don't mean that it's certain that there won't ever be x86-64 Macs.
...not that guidelines for universal binaries would suggest that you do anything that requires a 64-bit address space in any case, at least as I'd define "universal", as I'd kind of like to have "universal" OS X binaries run on my PowerBook.
If Apple were to announce that some future Macs will have x86-64 processors, the guidelines might be updated to give rules for 64-bit apps (which wouldn't be "universal", although one might build versions that run on both 64-bit PowerPC and on x86-64).
"If your Mac Tiger app is 64 bits, you're screwed. Won't even run in the emulator."
Note: that was me quoting the person to whom I was responding, so you're presumably directing these comments at him, not me.
First, there aren't any Mac app's that I know of that _require_ 64-bit CPU's, because they won't run on G3's and G4's, which means most Mac's, all laptops, etc. So app's that take advantage of 64-bit instructions also have a 32-bit version of the code.
There might not yet be any commercial apps that require 64-bit CPUs, but, until Tiger was released, there wasn't any generally-available OS X that supported a 64-bit address space, so the commercial app developers might have been waiting until then - those apps might show up later (if they haven't shown up already, but in places you might not know about - they aren't GUI apps, unless they have separate front-end and back-end programs, as the GUI frameworks in Tiger are all 32-bit-only).
Also, there might not be commercial 64-bit apps, but there might be internal apps, e.g. scientific apps.
Second, while the Universal Binary Programming Guidelines do only talk about the IA-32 instruction set, but it clearly supports 64-bit data types
OS X's in the BSD family, complete with 64-bit off_t, so it's supported 64-bit data types, even on 32-bit machines, for ages (and so have GCC and a number of other compilers, and so have many other OSes).
When people say "64-bit", however, the data types they're thinking of are often pointer data types, and OS X (and most if not all other OSes) don't give you those on 32-bit processors. If future x86-based Macs don't have x86-64 processors, you don't get 64-bit pointers, and if your data doesn't fit in a 32-bit address space, you'll have to use tricks such as mmapping the data in and out of your address space to access it.
and I'd be stunned if it weren't possible to run 64-bit code on 64-bit x86's
It's obviously possible to run "64-bit code", in the sense of code that uses x86-64 instructions, on 64-bit x86's. Whether Apple will make any Macs with x86-64 processors, however, is another matter.
Admittedly the 64-bit picture on Intel is a bit more complicated than on PPC (since the various x86 chip companies had different 64-bit stragies)
(Presumably you meant "the 64-bit picture on x86", if you're referring to "the various x86 chip companies" rather than just to Intel.)
As far as I know, there aren't major differences between 64-bit x86 from AMD and 64-bit x86 from Intel, and most of them are, I think, visible only to OS kernel code.
but Apple's got a year to work it out
Well, two years - the press release says "Apple® announced plans to deliver models of its Macintosh® computers using Intel® microprocessors by this time next year, and to transition all of its Macs to using Intel microprocessors by the end of 2007", so if Apple plans to make x86-64 Macs, that won't necessarily happen until the end of 2007.
And, for what it's worth, rumor has it that Apple got MacOS X to compile on the Alpha at one point, which should have cleared up the dependencies on 32-bit code.
I've also heard some vague rumors that Apple have gotten it to work on 64-bitPowerPC; if so, that also should have cleared up non-64-bit-clean parts of, at least, the parts they built in 64-bit mode.
(Note that another company ran their operating system in 32-bit mode on Alpha.)
If your Mac Tiger app is 64 bits, you're screwed. Won't even run in the emulator.
Won't run on PowerBooks, either.:-) (Or on iBooks or Mac Minis, but those are, I suspect, less likely to be of interest to people wanting to run 64-bit apps.)
The current guidelines don't mean that it's certain that there won't ever be x86-64 Macs. (They obviously also mean it's not certain that there will be. I've no idea whether there will be or not.)
...but why would apple NOT just use openfirmware like on the PPC Apple hardware?
One could speculate on why they didn't, but they didn't, as the Universal Binary Programming Guidelines document (which anybody who wants to speculate on whether Apple's switching to x86 or, to use a favorite wrong guess of many folk, licensing Intel to make PowerPC chips, or on whether they're using OpenFirmware in the x86 machines, or..., should read before they speculate in public) says.
the Rosetta emulation will allow for PPC software to run on Intel
The original poster seemed to be talking about new (x86) software not running on current or near-future machines, not old (PPC) software not running on the new x86 machines.
However, Rosetta - at least if it's Transitive's QuickTransit works both ways - their product family includes both QuickTransit for x86, to allow non-x86 programs, including POWER, to run on x86, and QuickTransit for Power/PowerPC, to allow non-Power/PowerPC programs, including x86, to run on PowerPC-based Macs.
Re:Jobs vision: multiple cores!! let's get them to
on
Apple Switching to Intel
·
· Score: 2, Interesting
hackers will unlock the x86 Macs, and it will run linux, windows or even solaris
Unless by "unlock" you mean "reverse-engineer non-standard support chips", there's nothing to unlock:
After Jobs' presentation, Apple Senior Vice President Phil Schiller addressed the issue of running Windows on Macs, saying there are no plans to sell or support Windows on an Intel-based Mac. "That doesn't preclude someone from running it on a Mac. They probably will," he said. "We won't do anything to preclude that."
As for
And The MACOSX WILL RUN ON BEIGE BOXES, DELL, HP, ETC
Schiller doesn't like that:
However, Schiller said the company does not plan to let people run Mac OS X on other computer makers' hardware. "We will not allow running Mac OS X on anything other than an Apple Mac," he said.
(with no indication of whether that's legal, technical, or both).
Perhaps Tiger's libraries (other than the BSD-layer ones) aren't 64-bit clean yet, so that they'd need to be updated to handle 64-bit PPC or x86-64? (They're not shipping as 64-bit libraries.)
Perhaps x86-64 will also be supported in the future.
It's because x86 allows execution of anything in memory, while the Power architecture keeps data and executable code separate.
Newer x86 processors have (or will have) the Execute Disable bit (or whatever AMD calls it), allowing data/stack regions to make marked "not executable", which the POWER-family machines already allow.
I wonder is the IA-64 part of their eventual game plan...
That's a much bigger effort than AMD64^H^H^H^H^HEM64T, so I'd suspect the latter, not IA-64, would be at least the short-term to medium-term 64bitness for non-PPC Macs.
Is there going to be Yet Another migration right after this, where "fat binaries" contain code compiled for 68k, PPC, i386, and AMD64
The Universal Binary Programming Guidelines mention only IA-32, so maybe there will be both IA-32 and AMD64 targets. Note that, above the BSD level, Tiger is 32-bit only, so it's not as if Tiger on the x86 Macs would be 64-bit throughout. Note also that going 64-bit for an app isn't a no-brainer - if you don't need the extra address space, 32-bit pointers take less memory/cache than do 64-bit pointers, so you might be better off with 32-bit binaries.
The problems that the change is going to cause... developer relations (ie- they just had to rewrite all their software to work properly in OSX, now they're gonna have to rewrite it again for, possibly, a completely new processor) namely.
Presumably by "rewrite" you mean "rewrite the parts that read from and write to files or sockets, if they weren't already written to be byte-order-insensitive, and rewrite any assembler code or inner loops tuned for PowerPC". They "[rewrote it] to work properly in OS X" because OS X was significantly different from earlier versions of Mac OS. If there were an x86 version of OS X, there wouldn't be API changes required - recompilation, yes, and perhaps retuning of critical loops, and making the I/O code byte-order insensitive if it's not byte-order insensitive already, but not a complete rewrite for C/C++/Objective-C applications.
Unless you've developed software for x86 AND PPC (who cares about the OS), you would have no idea about what problems are involved, especially when reading and writing long integers to files and over a network. (read: endianness)
I've written SunOS 4.x code that ran on 68K, SPARC, and x86 (some of which probably ran on PowerPC, in the PPC Solaris port), and NFS and SMB server code that ran on NetApp's little-endian boxes *and* the "simulator" (ONTAP running in a UN*X process, using files as simulated small disks and the OS's raw packet mechanism as simulated Ethernet) running on big-endian SPARC/Solaris, as well as Ethereal capture-file reading code, running on a pile of big-endian and little-endian boxes, reading files that are in formats using little-endian numbers, with my development platform being SPARC/Solaris.
I.e., yes, I've written software that has to deal with different byte orders, so I do know what's involved. It is NOT rocket science, although perhaps Sturgeon's Law applies to programmers, in which case for that 90% maybe it really is hard.
sure, you've got ntohl() and htonl() functions, but they don't help when your source data is little-endian (goddamn PSP!).
It's not that hard to write little-endian-to-native and native-to-little-endian routines/macros, and it's probably not that much harder to create asms, or whatever, in case "pick the bytes up and shift and OR them into place" isn't fast enough.
The "HEADACHES" will come from code not written to be byte-order-insensitive.
And if you're dealing with little-endian data on a Mac, you've already done that - the problems you'd have moving an app (presumably using big-endian formats in files and packets) to x86 would be the ones that ntoh{s,l}() and hton{s,l}() can handle (modulo types bigger than 32 bits, but those aren't too hard to swap portably).
The problems that would affect the biggest group of developers would probably be the overhead of supporting (building for, testing on, etc.) multiple platforms (even though both platforms would be running the same OS).
for one was looking forward to the G5 64 bit on a portable machine (a powerbook or even ibook) in the near future. I have been doing some intital development with Linux distributions on a AMD64 system and most recently with a PowerMac G5 and have been impressed with the results so far. It looks like this announcement of using Intel chipsets
"Announcement"? Did I miss something? Where's the press release on the Apple Web site for this announcement? (If Apple haven't announced it, it's only an "announcement" to the extent that C|Net are "announcing" that they have what they're claiming is a reason to believe Apple will announce this.)
will kill this option and leave Apple with 32 bit chipsets for their laptop line for at least the next 2 or 3 years.
Presumably by "32 bit chipsets" you're indicating that the support chips for the 64-bit Pentium 4's from Intel aren't fully 64-bit, because you can buy 64-bit Intel x86 boxes from Dell, so it's not as if you can't get 64-bit x86's from Intel.
The article doesn't state exactly which Intel chips they'd be using... Is X86 a foregone conclusion, or is it possible Apple could be migrating to Itanium? Or is it possible that they want Intel to manufacture a PowerPC clone chip?
You forgot Poland^H^H^H^H^H^Hthe i960. Apple's probably going to come out with a completely new line of computers, with 960's in them, just to surprise the hell out of people. Maybe it'll be a revival of the BiiN machines?
Either that, or - again, just to surprise the hell out of people - Intel will be licensing MIPS, and it'll be MIPS-based. An OS X port with an IRIX compatibility layer should let it run a bunch of SGI graphical apps.
Or maybe they'll be using some of the single-chip z/Architecture processors, so you can run all your creative apps and CICS transaction processing at the same time, with OS X and z/OS running on z/VM.
Slashdot Mirror
So how common are scenarios in which plug-n-play fails? Are they truly "typical", or are they sufficiently uncommon that, on the whole, users are better off with plug-and-play rather than (the also potentially error-prone) plug-and-tell-the-computer?
So who does answer those questions when installing a TV tuner card on a Linux system?
Seemed to some, perhaps, but I wasn't, in fact, saying it was a trivial matter of querying the card, I was asking whether it was a trivial matter of querying the card and, then, noting that if it was, that's what the driver should be doing, rather than obliging the user to tell the computer something it already knows.
So, if, in fact, the tuner type is at an undiscoverable i2c address, yes, I do have another question - the question already asked in another followup, namely "how do the vendor's Windows drivers tell the difference?"
Does the Windows driver, by virtue of (presumably) having been written by the vendor of the card, include code that knows where to look on the i2c bus to get the tuner type, so that the ultimate problem is that the vendor isn't being helpful to developers of drivers for other OSes?
Or does the Windows driver also require the user to configure it with the tuner type information, so the ultimate problem is that the vendor is being stupid?
Can a driver determine the tuner type by querying the card?
If so, then requiring the user to select the tuner type in a config file is completely stupid; the user shouldn't have to tell the computer something about a peripheral if the computer can determine that information itself without the user having to get involved.
(Presumably you meant "x86-64 support", not "IA-64 support" - IA-64 is completely unlike IA-32, the "IA" nonwithstanding; it's the instruction set architecture the Itanium series uses.)
A truly universal OS X binary can't make full use of x86-64, for one simple reason:
Making full use of x86-64 means "building for LP64", and there are plenty of Macs Apple is selling now that aren't LP64-capable (PowerBooks, iBooks, Mac Minis). A truly universal binary would be a 32-bit binary on PowerPC, and thus presumably a 32-bit binary on x86. I don't know whether any such binary can use any other x86-64 features, e.g. the 8 other registers.
The person TheKidWho's calling a "fucking idiot" has the nickname "Robert X. Cringley", not "Drakonian" - TheKidWho appears to be violently agreeing with Drakonian on this.
...not that guidelines for universal binaries would suggest that you do anything that requires a 64-bit address space in any case, at least as I'd define "universal", as I'd kind of like to have "universal" OS X binaries run on my PowerBook.
If Apple were to announce that some future Macs will have x86-64 processors, the guidelines might be updated to give rules for 64-bit apps (which wouldn't be "universal", although one might build versions that run on both 64-bit PowerPC and on x86-64).
Note: that was me quoting the person to whom I was responding, so you're presumably directing these comments at him, not me.
There might not yet be any commercial apps that require 64-bit CPUs, but, until Tiger was released, there wasn't any generally-available OS X that supported a 64-bit address space, so the commercial app developers might have been waiting until then - those apps might show up later (if they haven't shown up already, but in places you might not know about - they aren't GUI apps, unless they have separate front-end and back-end programs, as the GUI frameworks in Tiger are all 32-bit-only).
Also, there might not be commercial 64-bit apps, but there might be internal apps, e.g. scientific apps.
OS X's in the BSD family, complete with 64-bit off_t, so it's supported 64-bit data types, even on 32-bit machines, for ages (and so have GCC and a number of other compilers, and so have many other OSes).
When people say "64-bit", however, the data types they're thinking of are often pointer data types, and OS X (and most if not all other OSes) don't give you those on 32-bit processors. If future x86-based Macs don't have x86-64 processors, you don't get 64-bit pointers, and if your data doesn't fit in a 32-bit address space, you'll have to use tricks such as mmapping the data in and out of your address space to access it.
It's obviously possible to run "64-bit code", in the sense of code that uses x86-64 instructions, on 64-bit x86's. Whether Apple will make any Macs with x86-64 processors, however, is another matter.
(Presumably you meant "the 64-bit picture on x86", if you're referring to "the various x86 chip companies" rather than just to Intel.)
As far as I know, there aren't major differences between 64-bit x86 from AMD and 64-bit x86 from Intel, and most of them are, I think, visible only to OS kernel code.
Well, two years - the press release says "Apple® announced plans to deliver models of its Macintosh® computers using Intel® microprocessors by this time next year, and to transition all of its Macs to using Intel microprocessors by the end of 2007", so if Apple plans to make x86-64 Macs, that won't necessarily happen until the end of 2007.
I've also heard some vague rumors that Apple have gotten it to work on 64-bit PowerPC; if so, that also should have cleared up non-64-bit-clean parts of, at least, the parts they built in 64-bit mode.
(Note that another company ran their operating system in 32-bit mode on Alpha.)
Won't run on PowerBooks, either. :-) (Or on iBooks or Mac Minis, but those are, I suspect, less likely to be of interest to people wanting to run 64-bit apps.)
The current guidelines don't mean that it's certain that there won't ever be x86-64 Macs. (They obviously also mean it's not certain that there will be. I've no idea whether there will be or not.)
One could speculate on why they didn't, but they didn't, as the Universal Binary Programming Guidelines document (which anybody who wants to speculate on whether Apple's switching to x86 or, to use a favorite wrong guess of many folk, licensing Intel to make PowerPC chips, or on whether they're using OpenFirmware in the x86 machines, or..., should read before they speculate in public) says.
Do you have a link to that? I'd be interested in comparing it with the old MIT thing about SGI and Compaq throwing away their innovative technologies and betting the farm on IA-64.
Because Apple said so.
Co-owns, at best; IBM invented POWER, upon which PowerPC is based, so they presumably have some ownership.
Virtual PC for Mac. :-)
(I guess I was surprised it ran as fast as it did, but, at least when running XP, it can be noticeably slow....)
Unless they offer a reverse-Rosetta; if Rosetta's based on Transitive's QuickTransit, it could do x86-on-PowerPC just as it does PowerPC-on-x86.
In page 2 of the C|Net story; look at the end.
The original poster seemed to be talking about new (x86) software not running on current or near-future machines, not old (PPC) software not running on the new x86 machines.
However, Rosetta - at least if it's Transitive's QuickTransit works both ways - their product family includes both QuickTransit for x86, to allow non-x86 programs, including POWER, to run on x86, and QuickTransit for Power/PowerPC, to allow non-Power/PowerPC programs, including x86, to run on PowerPC-based Macs.
Unless by "unlock" you mean "reverse-engineer non-standard support chips", there's nothing to unlock:
As for
Schiller doesn't like that:
(with no indication of whether that's legal, technical, or both).
Perhaps Tiger's libraries (other than the BSD-layer ones) aren't 64-bit clean yet, so that they'd need to be updated to handle 64-bit PPC or x86-64? (They're not shipping as 64-bit libraries.)
Perhaps x86-64 will also be supported in the future.
Newer x86 processors have (or will have) the Execute Disable bit (or whatever AMD calls it), allowing data/stack regions to make marked "not executable", which the POWER-family machines already allow.
That's a much bigger effort than AMD64^H^H^H^H^HEM64T, so I'd suspect the latter, not IA-64, would be at least the short-term to medium-term 64bitness for non-PPC Macs.
Apple.
I think it's interesting that people are STILL speculating about IA-64 or Intel-made PowerPCs.
Read the Universal Binary Programming Guidelines - it's x86, period, end of discussion.
The Universal Binary Programming Guidelines mention only IA-32, so maybe there will be both IA-32 and AMD64 targets. Note that, above the BSD level, Tiger is 32-bit only, so it's not as if Tiger on the x86 Macs would be 64-bit throughout. Note also that going 64-bit for an app isn't a no-brainer - if you don't need the extra address space, 32-bit pointers take less memory/cache than do 64-bit pointers, so you might be better off with 32-bit binaries.
Presumably by "rewrite" you mean "rewrite the parts that read from and write to files or sockets, if they weren't already written to be byte-order-insensitive, and rewrite any assembler code or inner loops tuned for PowerPC". They "[rewrote it] to work properly in OS X" because OS X was significantly different from earlier versions of Mac OS. If there were an x86 version of OS X, there wouldn't be API changes required - recompilation, yes, and perhaps retuning of critical loops, and making the I/O code byte-order insensitive if it's not byte-order insensitive already, but not a complete rewrite for C/C++/Objective-C applications.
I've written SunOS 4.x code that ran on 68K, SPARC, and x86 (some of which probably ran on PowerPC, in the PPC Solaris port), and NFS and SMB server code that ran on NetApp's little-endian boxes *and* the "simulator" (ONTAP running in a UN*X process, using files as simulated small disks and the OS's raw packet mechanism as simulated Ethernet) running on big-endian SPARC/Solaris, as well as Ethereal capture-file reading code, running on a pile of big-endian and little-endian boxes, reading files that are in formats using little-endian numbers, with my development platform being SPARC/Solaris.
I.e., yes, I've written software that has to deal with different byte orders, so I do know what's involved. It is NOT rocket science, although perhaps Sturgeon's Law applies to programmers, in which case for that 90% maybe it really is hard.
It's not that hard to write little-endian-to-native and native-to-little-endian routines/macros, and it's probably not that much harder to create asms, or whatever, in case "pick the bytes up and shift and OR them into place" isn't fast enough.
The "HEADACHES" will come from code not written to be byte-order-insensitive.
And if you're dealing with little-endian data on a Mac, you've already done that - the problems you'd have moving an app (presumably using big-endian formats in files and packets) to x86 would be the ones that ntoh{s,l}() and hton{s,l}() can handle (modulo types bigger than 32 bits, but those aren't too hard to swap portably).
The problems that would affect the biggest group of developers would probably be the overhead of supporting (building for, testing on, etc.) multiple platforms (even though both platforms would be running the same OS).
ASOT's not an AC.
"Announcement"? Did I miss something? Where's the press release on the Apple Web site for this announcement? (If Apple haven't announced it, it's only an "announcement" to the extent that C|Net are "announcing" that they have what they're claiming is a reason to believe Apple will announce this.)
Presumably by "32 bit chipsets" you're indicating that the support chips for the 64-bit Pentium 4's from Intel aren't fully 64-bit, because you can buy 64-bit Intel x86 boxes from Dell, so it's not as if you can't get 64-bit x86's from Intel.
You forgot Poland^H^H^H^H^H^Hthe i960. Apple's probably going to come out with a completely new line of computers, with 960's in them, just to surprise the hell out of people. Maybe it'll be a revival of the BiiN machines?
Either that, or - again, just to surprise the hell out of people - Intel will be licensing MIPS, and it'll be MIPS-based. An OS X port with an IRIX compatibility layer should let it run a bunch of SGI graphical apps.
Or maybe they'll be using some of the single-chip z/Architecture processors, so you can run all your creative apps and CICS transaction processing at the same time, with OS X and z/OS running on z/VM.