You use middleware in between the printer and the end user tools.
This was being done by Linux in the 90s and SunOS in the 80s.
I.e., you have a PostScript interpreter on the host, and have it emit rasters or PCL or whatever and send it to the printer? If so, it still needs to find out what you can send to the printer, so it knows what to generate - and that's one thing the patent application talks about.
I don't know offhand - go on back to 1995 and ask someone?;-)
Why not ask them now? There were non-PostScript printers then, and there are non-PostScript printers now (i.e., "everybody uses it", where "everybody" includes "printer vendors", is a false statement).
Serious mode: Apple printers still exist; they're just discontinued.
Yes, I know about the LaserWriter, etc., so "there are no Apple printers any more", then. The point is that you can't rationally argue that Apple can solve this problem because the printers they design have limited capabilities, and thus need no drivers, as they haven't designed printers in ages (and the first one they designed was a PostScript printer, so you could send it arbitrary programs - hardly "very locked-down and limited to a small set of functionality".
Actually, CUPS was developed before, and was open source before, Apple hired its creator (who is, BTW, the first inventor in the list in the patent application).
Option 4: let printers say what formats they accept (PostScript, PDF, JPEG, rasters, etc.) and send them the most appropriate format for the particular print job. Read The Fine Patent Application (for which I'll post a link in a comment).
so like a standard Printer Control Language or maybe some sort of Script for Posting thins to a printer... I wish someone would have thought of that sooner.
No, nothing like that. As noted in this comment, there are a lot of cheap non-PostScript printers out there; in the scheme described in the patent, a printer could say "hey, I do PostScript" and the print system could send PostScript to the printer, just as it could say "hey, I do JPEG" and, if what's being printed is a JPEG image, the print system could send the JPEG to the printer, or it could say "hey, I do PDF" and the print system could send a PDF to the printer, or it could say "hey, I only do raster images" and the print system could generate raster images and send them to the printer.
No, they're not. They might be networked printers; the patent makes references to IPP.
So the reasons for eliminating "drivers" are satisfied by doing it this way.
The reasons for eliminating drivers as listed in the patent are
In practice, the wireless computing device may not be configured with the requisite driver software. In this case, installing the appropriate printer driver can be bothersome, especially if the user of the mobile computing device only intends to use the nearby printer once or twice. Also, mobile computing devices have limited storage space, which makes it impractical for them to store a large number of printer drivers.
which I don't see addressed by this. (I'm not sure I believe the "limited storage space" bit, even for "mobile devices" that are "smart phones" rather than laptops.)
Nearly all consumers want CHEAP printers. That means that the translation from text/image to printer imaging codes is done in the computer, not the printer, which saves CPU power and memory in the printer.
Which means that, to quote the patent, "the information indicates the printer can only support RF", where "RF" means "Raster Format", and therefore that "the system uses RF to send data to the printer".
Printer drivers are necessary in many cases because non-Apple printer vendors support a very wide and differing feature set.
You are aware that the sets "non-Apple printer vendors", at least in the sense of "printer vendors other than Apple", and "printer vendors" are the same? I.e., there are no Apple printers.
I honestly believe this is the direction the Mac AppStore is heading. I truly believe Lion +1 will not allow software to be installed that isn't in the AppStore. With the removal of the optical drive, it's going to make it that much harder to get around that kind of lock-down.
Jesus H. Fucking Christ on a unicycle, go look up the terms "Internet" and "dmg" (or "disk image"), and then explain to me what the fuck the removal of the optical drive has to do with any of this. Yeah, mounting a dmg requires that the disk image stuff be in the OS, but mounting an optical drive requires that the driver for the optical drive be in the OS. Maybe removing the optical drive is just "gee, this takes up space, and more and more people just download software from the Intertubes these days, dating back even before the Mac App Store; maybe we can save money, weight, and size by not building an optical drive into the machine, and offering a USB optical drive for the subset of MacBook Air buyers who need one"? (Alas, saying that makes it harder to play the Poor Man's Computing Pundit, but, given that what computing pundits say is generally worth what you paid for it, less any charge for wasting your time with advertising in the magazine/Web page, being the Poor Man's Computing Pundit is hardly something to which to aspire.)
(BTW, this doesn't apply to you, as you avoided using that phrase, but, at this point, I'm inclined to take any prediction that says "mark my words" less seriously; if you're talking from the upper orifice rather than the lower one, you don't need to talk like some cranky old man lecturing the damn punks on your lawn to get people's attention.)
To continue the analogy, some companies' products don't even let you do that. You have to use the company's own brand of fluid, or the reservoir won't refill.
If you're talking about Apple, it's more like "you have to use a manufacturer-approved brand of fluid, or the reservoir won't refill".
And if the people responsible for iCal and Address Book get to influence other Apple software, you'll see those in TextEdit in 10.8 and in future Pages releases both for iOS and Mac OS X.
There's no reason it has to, and no reason it cannot.
I.e., there's no reason to assume that a rumored MacBook Air with an ARM processor will be running iOS and there's no need for a hypothetical Mac-running-iOS to have an ARM processor.
The reasons for replacing Mac OS X with iOS would probably be partly political (iOS is Steve's 'next big thing') and partly financial (maintaining two separate but similar operating systems takes up double the resources
There's no reason to assume it truly takes double the resources, given that much of the "core OS" code, and many of the frameworks, are shared, perhaps with some #ifdefs, so it's not as if there's double the code. Additional drivers are needed, but that's because there's additional hardware, not because there's a completely separate OS. There is additional code, but some of that may just be because, for example, the UI of a small handheld touch-screen computer that has only an on-screen keyboard by default (i.e., whilst the iPhone supports Bluetooth keyboards, the UI can't assume there is one) is different from the UI of a larger computer without a touch screen and with a keyboard and pointing device (and both are different from the UI of a tablet touch-screen computer that has only an on-screen keyboard by default, although the differences between the iPhone/iPod touch and iPad aren't as big as the differences between those machines and a Mac).
None of us knows of course what will happen, but it is not beyond the realm of possibility that iOS will replace Mac OS X
...and it's also not beyond the realm of possibility that both will continue to exist, or that some newer OS will replace both of them, or....
and certainly lots of the design decisions in iOS make no sense whatsoever if they are planning running the two in parallel indefinitely (why set up an entirely separate but substantially similar view hierarchy like UIView with a different coordinate system etc etc when NSView could have been adapted?).
Because they wanted to make incompatible changes to the API, which they considered improvements, for an OS that didn't have to support old applications at the source or binary level, and couldn't make those changes in an OS that has to support apps written to NSView?
If Apple were to try and implement a similar dependency in OSX, there would be a shitstorm overnight even if they tried it a few years from now. People expect OSX to allow them to install apps from whatever source, to tweak the system to some extent, and to generally own it. But if they attack the problem from the other end, by replacing OSX with iOS, not many people will even notice, let alone complain because they are used to the iPhone or iPad being locked in.
Because adding those restrictions to OS X, without making any other changes to, for example, the UI, would be Very Noticeable, while selling a Mac running iOS with the iOS UI would not be noticeable at all. Ah, I see.
Same as Mac OS is used to produce apps for Mac OS X, iOS could be used to produce apps for iOS, so long as some decent hardware like the purported ARM MacBook Air was available.
And the reason why an ARM-based MacBook Air would run iOS rather than Mac OS X is?
A port of Xcode to iOS would not be particularly difficult, it is already a thin skin over command line tools which would run fine on iOS.
A thin skin over command-line tools that can chew up a lot of virtual memory; that works fine if you have enough physical memory, or an OS that pushes anonymous pages out to secondary storage, which iOS currently isn't. They could probably add dynamic_pager to iOS, I guess.... (Fun facts to know and tell: not only will dynamic_pager add new swap files if you fill up the existing ones, it'll also garbage-collect them by moving pages to other swap files if more recently-created swap files are no longer needed.)
Anyone who thinks that an iPad is a replacement for a computer - try making a few hundred spreadsheets in Numbers on the iPad and then later go and open the one you want.
Try installing a few tens of applications and then later go and open the one you want. But they fixed that by introducing this exciting new concept called "folders" into which you can put applications. Maybe they'll introduce that concept for documents as well. If so, they'll probably backport that "folder" idea to Mac OS X at some point, too....:-)
I hear the server tools got downsized for Lion, since they downsided the pricing model radically, whether you want it or not. I heard that this meant NFS and unlimited FTP clients were also removed.
Did the NFS server ever limit the number of clients? The server's still there in Lion, even if you have to use the nfsd command to enable, disable, and configure it (well, actually, creating an/etc/exports command should suffice to enable it). I suspect it's more likely that limits on FTP clients would be removed than that support for unlimited FTP clients would be removed, if Apple aren't selling the server version as an expensive product with different prices for different numbers of clients.
All they would have to do would be to disable installs from USB drives and that would be that.
Yeah, because God know OS X doesn't have an app called the "Installer" to install package files or the "Finder" to let you drag app bundles to/Applications or a "compiler" and "make" to let you compile source code and do "sudo make install" or.... They'd have to remove a lot more than just the ability to install from USB drives.
(I presume you're not making an assertion that optical drives were removed as part of an Ultimate Plan to keep people from installing apps except from the App Store, as there's no evidence whatsoever to support that assertion. The last time I tried to use the optical drive on my MacBook Pro was a few weeks ago, when I wanted to look at the Snow Leopard disc to see what packages were there - not to install them, BTW - and I can't even remember when I tried to use it before then, so I wouldn't personally miss a built-in optical drive. I might miss one if we got a Mac mini as a media box, as we have a bunch of CDs that we might want to play or burn to disk, but that's about it. Dropping them from computers where people rarely use them, and offering the option of an add-on USB optical drive for those who do need them, makes perfect sense.)
Slashdot Mirror
So, the printer manufacturer's choice is:
1. License PostScript from Adobe.
2. License this new protocol from Apple.
So where in the patent application do they mention a new protocol? They do mention an existing protocol....
So, rather than have a "driver" the computer has to know a new means of interrogating the capabilities of the printer
Or an existing means of interrogating the capabilities of the printer (which they call out by name in the patent application).
and then convert files to a format that the printer can handle... Right?
Yup, or ask some server "in the cloud" to do it, as the patent application says.
You use middleware in between the printer and the end user tools.
This was being done by Linux in the 90s and SunOS in the 80s.
I.e., you have a PostScript interpreter on the host, and have it emit rasters or PCL or whatever and send it to the printer? If so, it still needs to find out what you can send to the printer, so it knows what to generate - and that's one thing the patent application talks about.
I don't know offhand - go on back to 1995 and ask someone? ;-)
Why not ask them now? There were non-PostScript printers then, and there are non-PostScript printers now (i.e., "everybody uses it", where "everybody" includes "printer vendors", is a false statement).
Serious mode: Apple printers still exist; they're just discontinued.
Yes, I know about the LaserWriter, etc., so "there are no Apple printers any more", then. The point is that you can't rationally argue that Apple can solve this problem because the printers they design have limited capabilities, and thus need no drivers, as they haven't designed printers in ages (and the first one they designed was a PostScript printer, so you could send it arbitrary programs - hardly "very locked-down and limited to a small set of functionality".
Printers do have different capabilities and you must make allowance for that, but postscript handled that very nicely.
How does it handle "the ability to interpret PostScript is not one of this printer's capabilities"? :-)
Given that they already open sourced CUPS,
Actually, CUPS was developed before, and was open source before, Apple hired its creator (who is, BTW, the first inventor in the list in the patent application).
Michael Sweet, who owns Easy Software Products,
...and works for Apple Inc. on printing and has his name as the first inventor on the patent in question.
It's Patent Application 20110194140 ; here's the application.
And, yes, that's Michael "Mr. CUPS" Sweet in the Inventors list.
Option 4: let printers say what formats they accept (PostScript, PDF, JPEG, rasters, etc.) and send them the most appropriate format for the particular print job. Read The Fine Patent Application (for which I'll post a link in a comment).
so like a standard Printer Control Language or maybe some sort of Script for Posting thins to a printer... I wish someone would have thought of that sooner.
No, nothing like that. As noted in this comment, there are a lot of cheap non-PostScript printers out there; in the scheme described in the patent, a printer could say "hey, I do PostScript" and the print system could send PostScript to the printer, just as it could say "hey, I do JPEG" and, if what's being printed is a JPEG image, the print system could send the JPEG to the printer, or it could say "hey, I do PDF" and the print system could send a PDF to the printer, or it could say "hey, I only do raster images" and the print system could generate raster images and send them to the printer.
Printers are all USB
No, they're not. They might be networked printers; the patent makes references to IPP.
So the reasons for eliminating "drivers" are satisfied by doing it this way.
The reasons for eliminating drivers as listed in the patent are
which I don't see addressed by this. (I'm not sure I believe the "limited storage space" bit, even for "mobile devices" that are "smart phones" rather than laptops.)
Nearly all consumers want CHEAP printers. That means that the translation from text/image to printer imaging codes is done in the computer, not the printer, which saves CPU power and memory in the printer.
Which means that, to quote the patent, "the information indicates the printer can only support RF", where "RF" means "Raster Format", and therefore that "the system uses RF to send data to the printer".
Printer drivers are necessary in many cases because non-Apple printer vendors support a very wide and differing feature set.
You are aware that the sets "non-Apple printer vendors", at least in the sense of "printer vendors other than Apple", and "printer vendors" are the same? I.e., there are no Apple printers.
I honestly believe this is the direction the Mac AppStore is heading. I truly believe Lion +1 will not allow software to be installed that isn't in the AppStore. With the removal of the optical drive, it's going to make it that much harder to get around that kind of lock-down.
Jesus H. Fucking Christ on a unicycle, go look up the terms "Internet" and "dmg" (or "disk image"), and then explain to me what the fuck the removal of the optical drive has to do with any of this. Yeah, mounting a dmg requires that the disk image stuff be in the OS, but mounting an optical drive requires that the driver for the optical drive be in the OS. Maybe removing the optical drive is just "gee, this takes up space, and more and more people just download software from the Intertubes these days, dating back even before the Mac App Store; maybe we can save money, weight, and size by not building an optical drive into the machine, and offering a USB optical drive for the subset of MacBook Air buyers who need one"? (Alas, saying that makes it harder to play the Poor Man's Computing Pundit, but, given that what computing pundits say is generally worth what you paid for it, less any charge for wasting your time with advertising in the magazine/Web page, being the Poor Man's Computing Pundit is hardly something to which to aspire.)
(BTW, this doesn't apply to you, as you avoided using that phrase, but, at this point, I'm inclined to take any prediction that says "mark my words" less seriously; if you're talking from the upper orifice rather than the lower one, you don't need to talk like some cranky old man lecturing the damn punks on your lawn to get people's attention.)
To continue the analogy, some companies' products don't even let you do that. You have to use the company's own brand of fluid, or the reservoir won't refill.
If you're talking about Apple, it's more like "you have to use a manufacturer-approved brand of fluid, or the reservoir won't refill".
Now, *these* are *real* scroll bars:
http://www.earlychurchofjesus.org/images2/torah%20book%202.jpg
And if the people responsible for iCal and Address Book get to influence other Apple software, you'll see those in TextEdit in 10.8 and in future Pages releases both for iOS and Mac OS X.
There's no reason it has to, and no reason it cannot.
I.e., there's no reason to assume that a rumored MacBook Air with an ARM processor will be running iOS and there's no need for a hypothetical Mac-running-iOS to have an ARM processor.
The reasons for replacing Mac OS X with iOS would probably be partly political (iOS is Steve's 'next big thing') and partly financial (maintaining two separate but similar operating systems takes up double the resources
There's no reason to assume it truly takes double the resources, given that much of the "core OS" code, and many of the frameworks, are shared, perhaps with some #ifdefs, so it's not as if there's double the code. Additional drivers are needed, but that's because there's additional hardware, not because there's a completely separate OS. There is additional code, but some of that may just be because, for example, the UI of a small handheld touch-screen computer that has only an on-screen keyboard by default (i.e., whilst the iPhone supports Bluetooth keyboards, the UI can't assume there is one) is different from the UI of a larger computer without a touch screen and with a keyboard and pointing device (and both are different from the UI of a tablet touch-screen computer that has only an on-screen keyboard by default, although the differences between the iPhone/iPod touch and iPad aren't as big as the differences between those machines and a Mac).
None of us knows of course what will happen, but it is not beyond the realm of possibility that iOS will replace Mac OS X
...and it's also not beyond the realm of possibility that both will continue to exist, or that some newer OS will replace both of them, or....
and certainly lots of the design decisions in iOS make no sense whatsoever if they are planning running the two in parallel indefinitely (why set up an entirely separate but substantially similar view hierarchy like UIView with a different coordinate system etc etc when NSView could have been adapted?).
Because they wanted to make incompatible changes to the API, which they considered improvements, for an OS that didn't have to support old applications at the source or binary level, and couldn't make those changes in an OS that has to support apps written to NSView?
If Apple were to try and implement a similar dependency in OSX, there would be a shitstorm overnight even if they tried it a few years from now. People expect OSX to allow them to install apps from whatever source, to tweak the system to some extent, and to generally own it. But if they attack the problem from the other end, by replacing OSX with iOS, not many people will even notice, let alone complain because they are used to the iPhone or iPad being locked in.
Because adding those restrictions to OS X, without making any other changes to, for example, the UI, would be Very Noticeable, while selling a Mac running iOS with the iOS UI would not be noticeable at all. Ah, I see.
Why else would they revert jailbroken devices with every single OS update?
Because it's easier not to bother to construct iOS in a way that OS updates preserve the jailbroken state than to do so?
Same as Mac OS is used to produce apps for Mac OS X, iOS could be used to produce apps for iOS, so long as some decent hardware like the purported ARM MacBook Air was available.
And the reason why an ARM-based MacBook Air would run iOS rather than Mac OS X is?
A port of Xcode to iOS would not be particularly difficult, it is already a thin skin over command line tools which would run fine on iOS.
A thin skin over command-line tools that can chew up a lot of virtual memory; that works fine if you have enough physical memory, or an OS that pushes anonymous pages out to secondary storage, which iOS currently isn't. They could probably add dynamic_pager to iOS, I guess.... (Fun facts to know and tell: not only will dynamic_pager add new swap files if you fill up the existing ones, it'll also garbage-collect them by moving pages to other swap files if more recently-created swap files are no longer needed.)
and what's the 5250 emulation like these days?
It's like this.
Anyone who thinks that an iPad is a replacement for a computer - try making a few hundred spreadsheets in Numbers on the iPad and then later go and open the one you want.
Try installing a few tens of applications and then later go and open the one you want. But they fixed that by introducing this exciting new concept called "folders" into which you can put applications. Maybe they'll introduce that concept for documents as well. If so, they'll probably backport that "folder" idea to Mac OS X at some point, too.... :-)
I hear the server tools got downsized for Lion, since they downsided the pricing model radically, whether you want it or not. I heard that this meant NFS and unlimited FTP clients were also removed.
Did the NFS server ever limit the number of clients? The server's still there in Lion, even if you have to use the nfsd command to enable, disable, and configure it (well, actually, creating an /etc/exports command should suffice to enable it). I suspect it's more likely that limits on FTP clients would be removed than that support for unlimited FTP clients would be removed, if Apple aren't selling the server version as an expensive product with different prices for different numbers of clients.
All they would have to do would be to disable installs from USB drives and that would be that.
Yeah, because God know OS X doesn't have an app called the "Installer" to install package files or the "Finder" to let you drag app bundles to /Applications or a "compiler" and "make" to let you compile source code and do "sudo make install" or.... They'd have to remove a lot more than just the ability to install from USB drives.
(I presume you're not making an assertion that optical drives were removed as part of an Ultimate Plan to keep people from installing apps except from the App Store, as there's no evidence whatsoever to support that assertion. The last time I tried to use the optical drive on my MacBook Pro was a few weeks ago, when I wanted to look at the Snow Leopard disc to see what packages were there - not to install them, BTW - and I can't even remember when I tried to use it before then, so I wouldn't personally miss a built-in optical drive. I might miss one if we got a Mac mini as a media box, as we have a bunch of CDs that we might want to play or burn to disk, but that's about it. Dropping them from computers where people rarely use them, and offering the option of an add-on USB optical drive for those who do need them, makes perfect sense.)