The main point of this discussion is not about taking developers away from KDE, Gnome or anyone else. Most of the porting would likely be done by individuals who would have only peripheral roles with the development of those platforms.
The idea is to make software available elsewhere. Once the software is available on another platform more developers are able to contribute to the project.
Take for example Apache. Suppose Apache was only made available for Linux on x86. No Solaris, no BSD, no Windows NT, nothing other than Linux on x86. How many of the developers that contribute to Apache work exclusively on x86 Linux?
I'm willing to bet that quite a few use something else and that Apache would not be where it is now had it not been for the variety of platforms it runs on and more importantly the variety of developers coming from various backgrounds.
Not really true. With a bit more cash and a little know-how PowerMacs can run Windows programs and a variety of Linux/Unix programs with LinuxPPC, Yellow Dog Linux or NetBSD. Plus, there's the Mac applications. With OS X the options will become easier to get with the Unix options more readily available.
I would imagine that compiling for PPC should be relatively easy, it's just that many haven't decided to do so yet. However, gcc is included in Apple's developer previews and is also part of the Darwin project so anything open source should have a number of people able to compile it.
On the other hand, those that distribute only in binary may have yet to compile for PPC due to not having a PPC machine available to compile on. Of course, there's something to be said for stubbornness.
QNX is supposed to be giving away the full version for non-commercial use. But so far seems to be a lot more hype than anything else. The offer started months ago at http://get.qnx.com but so far they've yet to release it.
I believe the MACE project is working on creating an alternative implementation of the original Mac Toolbox API's, now referred to as Classic in MacOS X. Since Carbon is a cleaned up subset of the original API it would be possible to use this as a foundation for a Carbon API.
The GNUStep project is making an alternative to the original NeXT API's now referred to as Cocoa so those applications could also be ported.
However, there is a lot of work to make those API's complete and stable and they're not there yet. But it is possible to do it.
The GNUStep project is working on creating an alternative implementation of the NeXT API's which became known as Cocoa in MacOS X. They are also doing a project which would bring display postscript capabilities to systems, however, Quartz is based on PDF, not DPS.
The two are very much inseparable. Mach is not a full OS, just a kernel, a microkernel at that, all of the networking and such is handled by the BSD layer.
Another layer could be ported (a linux layer, from mkLinux for example) to provide the same things, however, it would have to replace the BSD layer completely since the Mach and BSD layers are closely connected to avoid huge overhead. You'd also have to make appropriate changes in all of the various layers to make them run on the mkLinux layer.
Also, to put in the Linux layer you'd also have to change a lot of stuff in the Mach kernel, meaning, the new system is very different from the old one, so for all intents and purposes they are inseparable.
Each program should have its own config files. Part of the.app bundling. Netinfo contains certain configuration information, applications contain their own information. The format for an application is different in MacOS X.
Each program is actually a directory that can contain configurations, multiple binaries, different language information, fonts, images, icons, etc. A.app file can be moved around like a file and take all of the required information with it. A novice user need never look under the hood within the BSD layer and find out about all those files.
Essentially this can help to solve the problems of packages as well as installation. If almost all the parts that are involved in an application can be treated as a single file then that file can be moved around the system, sent by email, run over the net, or distributed in any other way.
Right now Apple is quite logically pushing Carbon as the choice API. They'll be marketing it heavily to ensure that developers will make their applications available for MacOS X. If Apple spent a lot of time pushing both Carbon and Cocoa heavily it would send mixed messages to developers.
By pushing Carbon foremost developers will see that Apple is serious about giving them a relatively easy upgrade path. Then, once OS X ships and a significant number of apps are carbonized, they can begin to tout Cocoa. The Next-based API is much better and more versatile, it's also a more robust design. That's why Cocoa is considered the future of software development. Carbon is only a necessary transitional API.
For those who are experienced Mac programmers and are updating existing products for Mac OS X Carbon is the way to go. Cocoa is the way for new programs. As new, or completely redesigned, programs begin to replace the older programs Carbon will be less important. Apple will be offering incentives in the future to ensure that developers being to transition to Cocoa (think cross-platform API).
Laptop designs involve lots of trade-offs a lot more trade-offs than desktop systems do. In a desktop you have a few varieties of case types, motherboards and drive bays. On laptops there's nowhere near as much flexibility.
For example, I might want a laptop that would last a long time on one battery charge, which would mean leaving out a lot of things and just stripping it down to the bare essentials. This kind of design would be in serious conflict with the design for those who want a desktop replacement.
So you could create several standards, one for each particular type, Power Saver, Desktop Replacement, Ultra Light, Flexible (lots of options to change). Those would just be the more expensive models, there would also have to be somewhat of an equivalent in the low-end areas, Inexpensive Lightweight, Inexpensive Desktop Companion (can't get a true replacement for those prices), Inexpensive Configurable, Inexpensive Power Saver.
Which by then you've pretty much lost the point of trying to creat a standardized system in the first place, and those are only a few of the choices that people would want.
There's also a lot of other things to consider when dealing with a laptop. Because of space concerns almost everything is built onto the mainboard and permanently fixed to it. This kind of engineering doesn't give very much flexibility. Also because of the specialization required to cram all of that stuff into such a small space mainboards would not be compatible with each other.
Basically by this point you're left with drive bays, ports and PCMCIA to make compatible. Well the PCMCIA/PC Card slots already have that compatibility, so they can be left out. The hard drives for most laptops are relatively compatible since they generally have the same form factor and interface type.
Ports could be positioned in exactly the same place on each laptop, but this wouldn't work very well either as different laptops have different kinds/numbers of ports and need to have that for flexibility in purchase options. Also, with the different sizes of laptops wouldn't actually help much anyway in creating a universal docking station.
The media bays for things like floppy, CD-Rom, DVD, Zip, etc. could be standardized. Except that different space requirements cause them to have different form factors. As it is, most media bay drives are built by the same few companies with just a couple variations between the drives made for each model/manufacturer.
In order to make a portable that offered enough flexibility to use standard parts they'd all look like a shrunken version of a desktop case, they would be a lot heavier than current systems. They really wouldn't have much more flexibility. They probably wouldn't save you that much money anyway. Basically creating standardized laptops would for the most part defeat the purpose of having a laptop. Miniaturization involves a lot of limitations currently.
Even if it were possible for manufacturers to easily standardize the systems they have no reason to. Profit margins on portables are generally higher than those on desktop systems, the profit margins on components even higher because of being not fully standard and only semi-compatible with other offerings.
The drivers for Darwin are drivers for a Mach based system which is considerably different from both standard BSD and Linux drivers.
It is feasible to use GNU/Hurd drivers with Darwin, but I'm not sure how much work would be required to adapt the two. It would be possible for GNU/Hurd users to adapt the DriverKit totheir platform, which would allow them to have access to a wider range of hardware developers creating drivers for them.
There is no form of paging or workspaces included in this, although I'm sure it would be fairly simple for a third-party to create an add-on to accomplish that. It's not being considered a high-demand feature at the present so Apple has yet to demonstrate any effort in that direction. However, there is enough interest for a third-party developer to add that feature.
That's only one possible interface. That's based on the File Browser taken from NextStep. However, it is possible to go back to a standard finder view after that. It is a simplification and it does help to polish out some of the things that confused some people or made hassles. However, it's possible to go back to using an older view.
You can create aliases on the desktop to each drive area and then have them open new windows in the same way that the finder did. This is only one option and a new consolidated interface that makes it easier for many people to learn and use. Personally it wouldn't be my choice for most work but it is well thought out in its design.
Quicktime has actually had quite a few changes that fix the most common problems that users had with it. That it no longer followed their HIG guidelines. The buttons have changed and now behave as long-time Mac users would expect. The thumbwheel styled volume control has been replaced by a slider. Note that following good design guidelines does not require everything to be rectangular.
Single-Window Mode is an option, not a default. It's useful if you wish to focus on one particular item without having others in the background. While not a desirable option for most advanced users it would come in handy for my grandmother. Or imagine while at work, keep games running in the background, all it takes is a single click on the dock to bring up something you're working on and minimize the game.
MacOS X has three API's, Classic, Carbon and Cocoa. Classic is the old API, because it is actually a way to run an older version od MacOS at the same time (almost transparently currently, it might improve some in the future). It is the API that Mac programmers have been using for quite a while. Carbon is a more modern version of the Classic API, it allows the system to take advantage of the BSD/Mach underpinnings. It also creates a greater level of hardware abstraction than the classic API does, so that the microkernel is allowed to run things instead of individual programmers, which can cause a lot of instability. It was created to smooth the transition from MacOS 9 to OS X. Cocoa is a newer version of the NextStep/OpenStep API. This is the API that's designed to look towards the future more than the past. There is also the BSD 4.4 API which is basically a console. The way the Mach microkernel works is to break things down into "emulators" or environments. Essentially by using Mach it would be possible to make an emulator for almost any type of environment. Including X and all of the subsidiaries based on it, even a Linux emulator. The BSD environment is actually an emulator, Mach isn't BSD, although they are usually related. A linux microkernel could be ported to Mach and used as an environment (Mach handles multi-processor configurations much better than Linux currently does, I believe it can also utilize more memory). I think the mkLinux project was doing just that. Anyway it gives a lot of advantages for usage. It's a real-time OS as well which puts it into situations where it is able to control things that need very accurate timing (like optical routers). Apple has only announced its intention to release the core of it. The Mach microkernel and the BSD layer. It is quite possible that they will eventually release other parts of it as well. This is something I would definitely like to see. The Carbon and Cocoa API's are very well written and provide a consistent look and feel across platforms. Cocoa exists for x86 but seems to have disappeared recently. If both the x86 and PPC versions were released as well as the old Next code it would be possible (I believe the next version was based on X anyway) which would make it accessible for Linux. It would also be nice if Apple released Carbon and Quartz as well. Quartz is a really kick-ass graphical core, and they can release it. They're not using Adobe code anymore, instead they're using something they wrote themselves. It uses the PDF standard but the code isn't borrowed. For the truly geek at heart, there has even been some work done to make it display as a webpage (there is a section of the PDF standard for PDF to HTML). Giving a remote desktop anywhere. By releasing the two main API's, the core and the graphical layer that could be ported to other POSIX platforms it would open up options for a lot more people to develop for Linux, including the traditional vendors that Linux needs to get in order to become mainstream. It'd also help Apple as it would help to bring more developers creating products for Apple platforms, if most of the porting work can be done with a recompile it opens up a lot of systems. By keeping portions of the OS proprietary they wouldn't have to worry about losing their current user base to others, it'd likely increase their user base even more than it already is. The key distinctions of the OS would remain theirs, while the core components could spread. I'm hoping that at a later presentation Jobs will be releasing more info on the open-sourcing, however, I think it will be sometime close to the release of OS X. Instead of allowing someone else to launch a port of the API's in time to steal the fanfare from OS X.
Slashdot Mirror
The main point of this discussion is not about taking developers away from KDE, Gnome or anyone else. Most of the porting would likely be done by individuals who would have only peripheral roles with the development of those platforms.
The idea is to make software available elsewhere. Once the software is available on another platform more developers are able to contribute to the project.
Take for example Apache. Suppose Apache was only made available for Linux on x86. No Solaris, no BSD, no Windows NT, nothing other than Linux on x86. How many of the developers that contribute to Apache work exclusively on x86 Linux?
I'm willing to bet that quite a few use something else and that Apache would not be where it is now had it not been for the variety of platforms it runs on and more importantly the variety of developers coming from various backgrounds.
Not really true. With a bit more cash and a little know-how PowerMacs can run Windows programs and a variety of Linux/Unix programs with LinuxPPC, Yellow Dog Linux or NetBSD. Plus, there's the Mac applications. With OS X the options will become easier to get with the Unix options more readily available.
I would imagine that compiling for PPC should be relatively easy, it's just that many haven't decided to do so yet. However, gcc is included in Apple's developer previews and is also part of the Darwin project so anything open source should have a number of people able to compile it.
On the other hand, those that distribute only in binary may have yet to compile for PPC due to not having a PPC machine available to compile on. Of course, there's something to be said for stubbornness.
QNX is supposed to be giving away the full version for non-commercial use. But so far seems to be a lot more hype than anything else. The offer started months ago at http://get.qnx.com but so far they've yet to release it.
iPaq is a name, a group of products, not one single product. There are iPaq desktops and an iPaq handheld. This question refers to the iPaq handheld.
I believe the MACE project is working on creating an alternative implementation of the original Mac Toolbox API's, now referred to as Classic in MacOS X. Since Carbon is a cleaned up subset of the original API it would be possible to use this as a foundation for a Carbon API.
The GNUStep project is making an alternative to the original NeXT API's now referred to as Cocoa so those applications could also be ported.
However, there is a lot of work to make those API's complete and stable and they're not there yet. But it is possible to do it.
The GNUStep project is working on creating an alternative implementation of the NeXT API's which became known as Cocoa in MacOS X. They are also doing a project which would bring display postscript capabilities to systems, however, Quartz is based on PDF, not DPS.
The two are very much inseparable. Mach is not a full OS, just a kernel, a microkernel at that, all of the networking and such is handled by the BSD layer.
Another layer could be ported (a linux layer, from mkLinux for example) to provide the same things, however, it would have to replace the BSD layer completely since the Mach and BSD layers are closely connected to avoid huge overhead. You'd also have to make appropriate changes in all of the various layers to make them run on the mkLinux layer.
Also, to put in the Linux layer you'd also have to change a lot of stuff in the Mach kernel, meaning, the new system is very different from the old one, so for all intents and purposes they are inseparable.
Each program should have its own config files. Part of the .app bundling. Netinfo contains certain configuration information, applications contain their own information. The format for an application is different in MacOS X.
Each program is actually a directory that can contain configurations, multiple binaries, different language information, fonts, images, icons, etc. A .app file can be moved around like a file and take all of the required information with it. A novice user need never look under the hood within the BSD layer and find out about all those files.
Essentially this can help to solve the problems of packages as well as installation. If almost all the parts that are involved in an application can be treated as a single file then that file can be moved around the system, sent by email, run over the net, or distributed in any other way.
Right now Apple is quite logically pushing Carbon as the choice API. They'll be marketing it heavily to ensure that developers will make their applications available for MacOS X. If Apple spent a lot of time pushing both Carbon and Cocoa heavily it would send mixed messages to developers.
By pushing Carbon foremost developers will see that Apple is serious about giving them a relatively easy upgrade path. Then, once OS X ships and a significant number of apps are carbonized, they can begin to tout Cocoa. The Next-based API is much better and more versatile, it's also a more robust design. That's why Cocoa is considered the future of software development. Carbon is only a necessary transitional API.
For those who are experienced Mac programmers and are updating existing products for Mac OS X Carbon is the way to go. Cocoa is the way for new programs. As new, or completely redesigned, programs begin to replace the older programs Carbon will be less important. Apple will be offering incentives in the future to ensure that developers being to transition to Cocoa (think cross-platform API).
Laptop designs involve lots of trade-offs a lot more trade-offs than desktop systems do. In a desktop you have a few varieties of case types, motherboards and drive bays. On laptops there's nowhere near as much flexibility.
For example, I might want a laptop that would last a long time on one battery charge, which would mean leaving out a lot of things and just stripping it down to the bare essentials. This kind of design would be in serious conflict with the design for those who want a desktop replacement.
So you could create several standards, one for each particular type, Power Saver, Desktop Replacement, Ultra Light, Flexible (lots of options to change). Those would just be the more expensive models, there would also have to be somewhat of an equivalent in the low-end areas, Inexpensive Lightweight, Inexpensive Desktop Companion (can't get a true replacement for those prices), Inexpensive Configurable, Inexpensive Power Saver.
Which by then you've pretty much lost the point of trying to creat a standardized system in the first place, and those are only a few of the choices that people would want.
There's also a lot of other things to consider when dealing with a laptop. Because of space concerns almost everything is built onto the mainboard and permanently fixed to it. This kind of engineering doesn't give very much flexibility. Also because of the specialization required to cram all of that stuff into such a small space mainboards would not be compatible with each other.
Basically by this point you're left with drive bays, ports and PCMCIA to make compatible. Well the PCMCIA/PC Card slots already have that compatibility, so they can be left out. The hard drives for most laptops are relatively compatible since they generally have the same form factor and interface type.
Ports could be positioned in exactly the same place on each laptop, but this wouldn't work very well either as different laptops have different kinds/numbers of ports and need to have that for flexibility in purchase options. Also, with the different sizes of laptops wouldn't actually help much anyway in creating a universal docking station.
The media bays for things like floppy, CD-Rom, DVD, Zip, etc. could be standardized. Except that different space requirements cause them to have different form factors. As it is, most media bay drives are built by the same few companies with just a couple variations between the drives made for each model/manufacturer.
In order to make a portable that offered enough flexibility to use standard parts they'd all look like a shrunken version of a desktop case, they would be a lot heavier than current systems. They really wouldn't have much more flexibility. They probably wouldn't save you that much money anyway. Basically creating standardized laptops would for the most part defeat the purpose of having a laptop. Miniaturization involves a lot of limitations currently.
Even if it were possible for manufacturers to easily standardize the systems they have no reason to. Profit margins on portables are generally higher than those on desktop systems, the profit margins on components even higher because of being not fully standard and only semi-compatible with other offerings.
The drivers for Darwin are drivers for a Mach based system which is considerably different from both standard BSD and Linux drivers.
It is feasible to use GNU/Hurd drivers with Darwin, but I'm not sure how much work would be required to adapt the two. It would be possible for GNU/Hurd users to adapt the DriverKit totheir platform, which would allow them to have access to a wider range of hardware developers creating drivers for them.
There is no form of paging or workspaces included in this, although I'm sure it would be fairly simple for a third-party to create an add-on to accomplish that. It's not being considered a high-demand feature at the present so Apple has yet to demonstrate any effort in that direction. However, there is enough interest for a third-party developer to add that feature.
That's only one possible interface. That's based on the File Browser taken from NextStep. However, it is possible to go back to a standard finder view after that. It is a simplification and it does help to polish out some of the things that confused some people or made hassles. However, it's possible to go back to using an older view.
You can create aliases on the desktop to each drive area and then have them open new windows in the same way that the finder did. This is only one option and a new consolidated interface that makes it easier for many people to learn and use. Personally it wouldn't be my choice for most work but it is well thought out in its design.
Quicktime has actually had quite a few changes that fix the most common problems that users had with it. That it no longer followed their HIG guidelines. The buttons have changed and now behave as long-time Mac users would expect. The thumbwheel styled volume control has been replaced by a slider. Note that following good design guidelines does not require everything to be rectangular.
Single-Window Mode is an option, not a default. It's useful if you wish to focus on one particular item without having others in the background. While not a desirable option for most advanced users it would come in handy for my grandmother. Or imagine while at work, keep games running in the background, all it takes is a single click on the dock to bring up something you're working on and minimize the game.
MacOS X has three API's, Classic, Carbon and Cocoa. Classic is the old API, because it is actually a way to run an older version od MacOS at the same time (almost transparently currently, it might improve some in the future). It is the API that Mac programmers have been using for quite a while. Carbon is a more modern version of the Classic API, it allows the system to take advantage of the BSD/Mach underpinnings. It also creates a greater level of hardware abstraction than the classic API does, so that the microkernel is allowed to run things instead of individual programmers, which can cause a lot of instability. It was created to smooth the transition from MacOS 9 to OS X. Cocoa is a newer version of the NextStep/OpenStep API. This is the API that's designed to look towards the future more than the past. There is also the BSD 4.4 API which is basically a console. The way the Mach microkernel works is to break things down into "emulators" or environments. Essentially by using Mach it would be possible to make an emulator for almost any type of environment. Including X and all of the subsidiaries based on it, even a Linux emulator. The BSD environment is actually an emulator, Mach isn't BSD, although they are usually related. A linux microkernel could be ported to Mach and used as an environment (Mach handles multi-processor configurations much better than Linux currently does, I believe it can also utilize more memory). I think the mkLinux project was doing just that. Anyway it gives a lot of advantages for usage. It's a real-time OS as well which puts it into situations where it is able to control things that need very accurate timing (like optical routers). Apple has only announced its intention to release the core of it. The Mach microkernel and the BSD layer. It is quite possible that they will eventually release other parts of it as well. This is something I would definitely like to see. The Carbon and Cocoa API's are very well written and provide a consistent look and feel across platforms. Cocoa exists for x86 but seems to have disappeared recently. If both the x86 and PPC versions were released as well as the old Next code it would be possible (I believe the next version was based on X anyway) which would make it accessible for Linux. It would also be nice if Apple released Carbon and Quartz as well. Quartz is a really kick-ass graphical core, and they can release it. They're not using Adobe code anymore, instead they're using something they wrote themselves. It uses the PDF standard but the code isn't borrowed. For the truly geek at heart, there has even been some work done to make it display as a webpage (there is a section of the PDF standard for PDF to HTML). Giving a remote desktop anywhere. By releasing the two main API's, the core and the graphical layer that could be ported to other POSIX platforms it would open up options for a lot more people to develop for Linux, including the traditional vendors that Linux needs to get in order to become mainstream. It'd also help Apple as it would help to bring more developers creating products for Apple platforms, if most of the porting work can be done with a recompile it opens up a lot of systems. By keeping portions of the OS proprietary they wouldn't have to worry about losing their current user base to others, it'd likely increase their user base even more than it already is. The key distinctions of the OS would remain theirs, while the core components could spread. I'm hoping that at a later presentation Jobs will be releasing more info on the open-sourcing, however, I think it will be sometime close to the release of OS X. Instead of allowing someone else to launch a port of the API's in time to steal the fanfare from OS X.