The App store is break even and even the gross is negligible retaliative to the cost of the hardware. App stores exist to allow people to trust their apps, which allows them to freely and cheaply add functionality to their phone which makes them want to use Apple hardware. Applications sell hardware for Apple, that's it. Long term this might become profitable the way music is now.
They aren't exactly going out of their way to open up the boot loaders on iPhones and iPads to allow for alternative OS's just to sell more hardware
?? They don't have a problem with Linux for iPhone. They want support it, but they don't meaningfully object. As far as Android preinstalled, they don't have a problem with that either.
No but the hybrid thing is the standard Intel integrated which Linux supports. I don't think Linux supports the hybrid but that's not specific to Apple hardware, that would apply to any notebook with both integrated and discrete graphics.
Thank you for responding. And well yeah the GCC stuff was meant to be self serving. It turned out not to be. Right after they really got GCC working well on PPC they got into a fight with IBM over IBM refocusing the PPC line on gaming systems. They jumped to Intel processors and Sony as well as the game companies for XBox and Playstation were the ones that really benefited from the work. And in the last few years GCC on power. But that's open source you benefit from people who never meant to help you, scratch your own itch and in doing so help people you never intended to benefit.
Caldev, Webkit.. those are classic donations. Building something for the whole community.
Apple got a bad rep from the FSF not really understanding Apple culture and exaggerating.
1) Yes the rMBP stresses the video card. It doesn't bother the rest of the system. Background tasks are fine. 2) There is nothing sneaky about the rMBP's higher power usage, Apple tells you the wattage on their power supplies in their store. They call them the "70 watt power brick"... 3) The core parts of Apple software go back to NeXTStep. Some of which goes back to Apple Unix and the Lisa.
Yes because after all a company that writes their own multi OS boot loader, supports it and gives it away for free is definitely opposed to people booting other OSes on the hardware they make their money from.
There is a lot of good server software for Linux that isn't ported to OSX. Mostly I'd assume you would want to run this in stuff in a VM, to use while developing.
OTOH if you are just talking hardware. Where else do you get a laptop with: a 5 mega pixel screen 450 mb/sec hard drives 16g of ram terrific speakers that wonderful thin feel...
The programming model for OS X applications was still one that supported full-fledged, multitasking, overlapped window desktop applications. Imagine instead if Apple had introduced the restricted iOS programming model as the new model for OS X, one that simply couldn't replicate popular applications from classic MacOS like Photoshop. That's what Microsoft is now touting and pushing heavily as the new sliced bread in Windows 8.
I see good point. I don't think they want you to just replicate the applications but rather reinvent the functionality. They don't want people to just port their old application to another widget set but rather to completely rethink how the application should work. Metro takes away some features that have been standard and adds other features back in that used to only exist on very advanced windows managers (like XMonad). So they offer multiple windows but not just a simple "throw a window on the screen and let the end user resize and move it" model.
A fair analogy, to stick with OSX is what would have happened if Apple had never created the whole OS9 -> OSX Classic -> Carbon -> Cocoa migration path but instead had gone with their original plan of forcing people to jump directly from OS9 to Cocoa. (I should mention as a point of irony, Microsoft is one of the few companies that hasn't made it all the way down that path and still has lots of Carbon code in their OSX applications). Apple in 1997-2000 was just too weak to pull this off. Microsoft is strong enough to force the shift fast. And frankly they lack the time for the handholding their developers through all the intermediate steps. Apple couldn't drop classic completely until 2005-7. Microsoft developers (and customers) are not used to changing technology nearly as rapidly as Apple developers / customers are. They don't want the multiple steps. No question for Microsoft to pull this off will be rough on everyone.
I'm not holding my breath for high DPI monitors becoming popular just yet. We've regressed so far in resolution that most laptops are down at 1366x768 much less 1080p, and even at 1080p ClearType is a significant gain. Apple's push with the Retina display is much needed and will help a lot but I still think it will be years before the baseline resolution for laptops improves enough. The new Surface is still only going to be 1366x768.
Part of the new Microsoft is to stop focusing on the lowest common denominator. You go back to what computing was like in the 1980s and 1990s (or phones today) where new applications and new OSes were focused on newer equipment. There is no reason that by 2014 or so, every laptop shouldn't be high DPI. And new software shouldn't target the baseline but rather the newest generation of hardware. Old software for old systems, new software for new systems. Software targets the future hardware because hardware changes so fast you can't possible target the base. That's a real change for the stagnant market of the last decade but it was a much better world technically.
Regardless if it happens in 2015 or 2020 Metro can't support ClearType once it is clear that high DPI is the eventual direction. The Windows community is not going to react as quickly to fixing the font problem as the Apple community has (after all no developer doubts that Apple users will switch applications over ugly fonts) and Microsoft can't afford years of their fonts looking terrible during a slow transition. So planning in advance makes sense.
Metro does not allow dynamically generated code, including JITted code (direct or Reflection.Emit), downloaded code, or runtime compiled shaders. You can dynamically load modules but they must have been pre-packaged. This prohibits use of a number of scripting languages that would be performant and efficient and do not have or cannot have an ahead-of-time compilation component.
I'm not following. Python 2.7 and 3.2 run fine on Windows 8. Perl does. Which scripting languages are having problems?
GDI was and is still a lot more flexible than these playskool single focus interfaces microsoft/apple/gnome et al are pushing us to use.
I don't know what you mean by "a lot more flexible". Try changing the parameters under which GDI applications operate, like drastically changing the PPI. As for playskool single focus interfaces... that's simply not true. Both Apple and Microsoft are integrating virtual desktops into window management and more or less automatically tiling window managers. In other words bringing to the masses something like XMonad's approach to window management. I'm not sure how something that in 2011 was cool but too far advanced for most Linux users is now meant for babies.
OK good so we agree that you aren't really interested in network transparency what you want is good remote applications. That's a lot of progress because network transparency is impossible with Wayland while it is entirely possible that the Linux community 2015-2020 creates a good remote system like RDB. It more or less comes down to how much they care.
Let me open up by saying a good deal of your response is based on the assumption that it is possible for Wayland to implement their solution (i.e. RDB for KDE and RDB for Gnome) at the compositor level. It isn't. At least it isn't meaningfully possible. In some theoretical sense you could do it with a GTK version specific Wayland that also knew a great about Gnome and QT version specific Wayland that also knew a great deal about KDE and a XUL version specific Wayland that also knew a great deal about Firefox/Gecko... Part of abandoning network transparency is abandoning this is something the compositor should be doing. Rather the success of RDB proves it is better done at the GUI level. In other words do it at the rendering level . Now the good thing is both KDE and Gnome support the shift to Wayland and both of them have indicated they agree it should be done by the GUI level, so as much as open source projects can meaningfully commit to stuff, they've committed to doing it.
Now in terms of pervasive. That really is a choice the Linux community makes after KDE and Gnome develop remote rendering and after (if they ever do) create the equivalent of DBUS. At that point other widget sets have to decide whether they want to adopt the standard. For example wxWidgets are based on GTK they could use huge chunks of the Gnome code... but it is going to be up to wxWidgets to decide. Mozilla will have to decide whether it is worth it for XUL. In 2007 I'd say they would likely want to be one of the first to implement it and be on the committee. Right now in 2012 they are in a trim the fat mood desperately trying to keep up with Apple, Google and Microsoft now those 3 are spending a lot on browser development. In 2020 maybe they've fallen so far behind that they are comfortable being a niche browser, or being a Linux only solution and are like they were in 2020. But maybe they aren't and they have fallen behind but consider catching up their #1 priority now that Apple, Microsoft and Google have slowed down browser improvements; or whatever the future holds.
The other issue is of course whether Wayland goes in the direction of Microsoft or Apple. Both roads exist once X11 is abandoned. Apple implements pervasive integrated video and integrated animation. The Clutter project wants to bring this to X11 but its hard so they are failing. GNUStep while being essentially Linux only always (more or less) follows Apple standards so they are one that I can see being resistant to a Linux standard for application portability regardless but this would be a moment for them to shine. And we don't know how Linux users feel about video and animation once they offered these things being silky smooth and available at all levels of their GUI. They may very well become like Apple users who consider it a vital part of their computing experience and won't give it up for better remote access. Wayland creates this fork in the road between the Microsoft and Apple way of handling the desktop that doesn't exist today. The Wayland guys like Microsoft's approach but once you create the choice, we don't know which door Linux picks. In 2001 when I switched to Apple, I never would have thought how much I love integrated video. I'm not a visual guy but by about 2004 my taste has definitely changed. When I'm on Windows or Linux and don't have it, everything feels so 1995 and clunky to me. I'm fully functional on those alternate desktops but never comfortable.
So lets assume as a thought experiment that the Linux community does consider remote important and that Linux application tastes more or less don't change. So I propose for the purpose of argument
The difference is that it was clear with the OSX transition that the new APIs would be viable replacements for the old
I hope you check back. This was a good comment. You should get an account.
Before 10.0 was released. No it wasn't clear at all. And wouldn't be for a while. 10.0 was much rougher than Windows 8 is today and was being met with far more hostility. For example http://www.asktog.com/columns/044top10docksucks.html
Some of that stuff like multiple monitors I'm sure will be added with service packs. Clear type is going to be replaced by high dpi monitors. I own a macbook retina you don't want this sort of rendering it looks horrible. Metro's approach is better for high dpi. As far as "simultaneously running applications" I don't see that. Snap works fine. Possibly I'm missing what you mean? As far as dynamic loads there are 3 methods already supported and likely more to come.
If you use OSX consider what OSX was like with regard to the Classic box. You are, using your metaphor, upset that your workflow with classic works worse on OSX than it did on OS9. Well yeah, of course.
And I would suspect for GDI applications Windows 9 is going to be even more uncomfortable. Where it will shine is Metro applications. And that's the point to start shifting the development community over to the new interface. Apple hit tremendous resistance as they moved people from Classic to Carbon to Cocoa every step of the way. But by constantly advantaging Carbon over Classic and Cocoa over Carbon they achieved the migration.
Huh? Calligra is much older than Libre Office. KDE office was around when Libre was still Star Office. Neither one of them is new kid on the block unless you want to go back 15 years. If you do back 15 years...
the goal of KDE was to create a GUI for Linux. The Office suite has to follow the GUI standards. Star Office was a port of a pre-existing 2nd tier office suite to Linux. They didn't follow the GUI standards but they were the furthest along when Sun acquired them.
I think you are missing the point of the comments below.
CSV is a data format. Test attributes like bold aren't considered part of data. If on the other hand you define the field to be "HTML block" and not "text" then CSV could have formatting.
In general though people who are using CSV are OK with losing formatting. So the culture around CSV is not to do what you want. That's not a failure of KDE so much as it is a desire for an independent format that doesn't preserve formatting. ODF does preserver formatting and data.
KDE and OpenOffice (Star Office) were never designed to fill the same the niche. KDE integrates with the GUI while LO/OO/NO is GUI independent. I can easily break apart KDE Office functionality and widgets and use them in other KDE applications. I did this myself about a decade ago where I took many of the row and column management functions from KDE's spreadsheet and moved them to a thick client.
I think this situation is good. Long term Open Office should be conservative offering something like Microsoft Office. KDE Office (Calligra) should be aggressive moving into new areas and designs for Office applications and tightly integrate with KDE.
No way they do an air by Christmas. They don't have a video card that can drive that screen effectively at that price, heat or battery point. Nvidia is working hard on retina support so fall-winter 2013 is possible
I think it is fair to say we don't know anything. Gruber along with everyone else is just guessing. His point about this not shipping in September but being announced in September is a good one, we don't know enough so this isn't a few weeks from going on sale. October/November sale date seems more likely.
Here are the resolutions: iPad 1/2: 1024 x 768 iPad 3: 2048 x 1536 (doubled) iPhone 4S: 640 x 960 iPhone 5 (rumor): 640 x 1136 earlier iPhone: 320 x 480
I'm going with a bigger version of the iPhone 5 resolution. 1136x640 is close to what the original iPad had, allows for a cheap screen, doesn't require developers to support yet another resolution... But no one really knows.
The other big question for September is whether there will be a 13" inch retina macbook pro.
The claim above was much broader. Far more accurate would be: "Microsoft is a OS vendor-lock-in company" because Microsoft is incredibly open in the areas of: application software, hardware, parts, accessories, web services....
any major multinational corporation in drafting a standard is preposterous. none of the largest technology companies in the world mentioned in the summary have a vested interest in ensuring interoperability between competing products at any level
Of course they do. They often have a strong interest in interoperability everywhere but where their core profits come from. So for example the entire success of the PC platform is based on the Intel / Microsoft / Western Digital Standard for x86 which has allowed hardware interoperability. It was a standard which parts manufacturers like Intel and Western Digital benefit from, and software producers like Microsoft benefited from that was however devastating to the box producers like IBM, Osborne, DEC...
Similarly Microsoft has a tremendous interest in coding standards and API standards for software to run against Windows and for programs to interoperate with one another. That's why they've spent a fortune laying the infrastructure for things like drag and drop and OLE to work as well as they do.
I think we are going to get both. Obvious VNC already exists. After that Gnome is going to implement a solution for Gnome applications, KDE a solution for KDE apps. The freedesktop group will probably create a standard so that the two desktops, Firefox, OpenOffice... can use either the Gnome or KDE standard to some extent. But yeah I can easily see that Linux's RDB ends up being GUI specific and KDE's only really works right for KDE/QT apps and Gnomes really only works right for Gnome / GTK apps.
But what you were suggesting for OpenGL would still require a protocol to make work. And the apps need to know about it at the messaging level which requires the event handler and... This isn't an easy problem in practice. You are getting 80% of what you want, not 100%.
I think: VNC = 100% computable lousy performance GUI specific = 50% compatible good performance client server = specific to the client excellent performance
is a rather nice lineup.
I'm not sure what adding X11 = 95% compatible lousy performance under most situations but for a few good performance.
really adds. Obviously the perfect world is the performance of frame buffer with ubiquitousness and compatibility of X11 but that's not possible to achieve.
Slashdot Mirror
The App Store model is very profitable.
The App store is break even and even the gross is negligible retaliative to the cost of the hardware. App stores exist to allow people to trust their apps, which allows them to freely and cheaply add functionality to their phone which makes them want to use Apple hardware. Applications sell hardware for Apple, that's it. Long term this might become profitable the way music is now.
They aren't exactly going out of their way to open up the boot loaders on iPhones and iPads to allow for alternative OS's just to sell more hardware
?? They don't have a problem with Linux for iPhone. They want support it, but they don't meaningfully object. As far as Android preinstalled, they don't have a problem with that either.
No but the hybrid thing is the standard Intel integrated which Linux supports. I don't think Linux supports the hybrid but that's not specific to Apple hardware, that would apply to any notebook with both integrated and discrete graphics.
Thank you for responding. And well yeah the GCC stuff was meant to be self serving. It turned out not to be. Right after they really got GCC working well on PPC they got into a fight with IBM over IBM refocusing the PPC line on gaming systems. They jumped to Intel processors and Sony as well as the game companies for XBox and Playstation were the ones that really benefited from the work. And in the last few years GCC on power. But that's open source you benefit from people who never meant to help you, scratch your own itch and in doing so help people you never intended to benefit.
Caldev, Webkit.. those are classic donations. Building something for the whole community.
Apple got a bad rep from the FSF not really understanding Apple culture and exaggerating.
Should Mac OS X ever top the desktop OS market (unlikely as it may be), it is pretty much a given that they would do it
Why? Assume that everyone in the world bought nothing but Apple computers and they all ran Linux on them. Why would Apple be unhappy with that?
Apple does not sell OSes, the OS is a way to sell their hardware. They see themselves as being in the same business as Dell more than Microsoft.
It would be nice if Apple contributed to Linux.
They do. Their most notable contribution was all the work on the PPC version of gcc which is the reason Linux runs so well on XBox.
Most of their major open source projects do run on Linux today though: http://www.macosforge.org/
The video driver for Linux is out: http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html
Drivers are not the problem.
This has nothing to do with closed source. Here is the driver for the retina's video card: http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html
This is a crazy rant.
1) Yes the rMBP stresses the video card. It doesn't bother the rest of the system. Background tasks are fine.
2) There is nothing sneaky about the rMBP's higher power usage, Apple tells you the wattage on their power supplies in their store. They call them the "70 watt power brick"...
3) The core parts of Apple software go back to NeXTStep. Some of which goes back to Apple Unix and the Lisa.
Yes because after all a company that writes their own multi OS boot loader, supports it and gives it away for free is definitely opposed to people booting other OSes on the hardware they make their money from.
There is a lot of good server software for Linux that isn't ported to OSX. Mostly I'd assume you would want to run this in stuff in a VM, to use while developing.
OTOH if you are just talking hardware. Where else do you get a laptop with: ...
a 5 mega pixel screen
450 mb/sec hard drives
16g of ram
terrific speakers
that wonderful thin feel
The programming model for OS X applications was still one that supported full-fledged, multitasking, overlapped window desktop applications. Imagine instead if Apple had introduced the restricted iOS programming model as the new model for OS X, one that simply couldn't replicate popular applications from classic MacOS like Photoshop. That's what Microsoft is now touting and pushing heavily as the new sliced bread in Windows 8.
I see good point. I don't think they want you to just replicate the applications but rather reinvent the functionality. They don't want people to just port their old application to another widget set but rather to completely rethink how the application should work. Metro takes away some features that have been standard and adds other features back in that used to only exist on very advanced windows managers (like XMonad). So they offer multiple windows but not just a simple "throw a window on the screen and let the end user resize and move it" model.
A fair analogy, to stick with OSX is what would have happened if Apple had never created the whole OS9 -> OSX Classic -> Carbon -> Cocoa migration path but instead had gone with their original plan of forcing people to jump directly from OS9 to Cocoa. (I should mention as a point of irony, Microsoft is one of the few companies that hasn't made it all the way down that path and still has lots of Carbon code in their OSX applications). Apple in 1997-2000 was just too weak to pull this off. Microsoft is strong enough to force the shift fast. And frankly they lack the time for the handholding their developers through all the intermediate steps. Apple couldn't drop classic completely until 2005-7. Microsoft developers (and customers) are not used to changing technology nearly as rapidly as Apple developers / customers are. They don't want the multiple steps. No question for Microsoft to pull this off will be rough on everyone.
I'm not holding my breath for high DPI monitors becoming popular just yet. We've regressed so far in resolution that most laptops are down at 1366x768 much less 1080p, and even at 1080p ClearType is a significant gain. Apple's push with the Retina display is much needed and will help a lot but I still think it will be years before the baseline resolution for laptops improves enough. The new Surface is still only going to be 1366x768.
Part of the new Microsoft is to stop focusing on the lowest common denominator. You go back to what computing was like in the 1980s and 1990s (or phones today) where new applications and new OSes were focused on newer equipment. There is no reason that by 2014 or so, every laptop shouldn't be high DPI. And new software shouldn't target the baseline but rather the newest generation of hardware. Old software for old systems, new software for new systems. Software targets the future hardware because hardware changes so fast you can't possible target the base. That's a real change for the stagnant market of the last decade but it was a much better world technically.
Regardless if it happens in 2015 or 2020 Metro can't support ClearType once it is clear that high DPI is the eventual direction. The Windows community is not going to react as quickly to fixing the font problem as the Apple community has (after all no developer doubts that Apple users will switch applications over ugly fonts) and Microsoft can't afford years of their fonts looking terrible during a slow transition. So planning in advance makes sense.
Metro does not allow dynamically generated code, including JITted code (direct or Reflection.Emit), downloaded code, or runtime compiled shaders. You can dynamically load modules but they must have been pre-packaged. This prohibits use of a number of scripting languages that would be performant and efficient and do not have or cannot have an ahead-of-time compilation component.
I'm not following. Python 2.7 and 3.2 run fine on Windows 8. Perl does. Which scripting languages are having problems?
I don't follow. How does the font rendering method have anything to do with desktop space?
GDI was and is still a lot more flexible than these playskool single focus interfaces microsoft/apple/gnome et al are pushing us to use.
I don't know what you mean by "a lot more flexible". Try changing the parameters under which GDI applications operate, like drastically changing the PPI. As for playskool single focus interfaces... that's simply not true. Both Apple and Microsoft are integrating virtual desktops into window management and more or less automatically tiling window managers. In other words bringing to the masses something like XMonad's approach to window management. I'm not sure how something that in 2011 was cool but too far advanced for most Linux users is now meant for babies.
OK good so we agree that you aren't really interested in network transparency what you want is good remote applications. That's a lot of progress because network transparency is impossible with Wayland while it is entirely possible that the Linux community 2015-2020 creates a good remote system like RDB. It more or less comes down to how much they care.
Let me open up by saying a good deal of your response is based on the assumption that it is possible for Wayland to implement their solution (i.e. RDB for KDE and RDB for Gnome) at the compositor level. It isn't. At least it isn't meaningfully possible. In some theoretical sense you could do it with a GTK version specific Wayland that also knew a great about Gnome and QT version specific Wayland that also knew a great deal about KDE and a XUL version specific Wayland that also knew a great deal about Firefox/Gecko... Part of abandoning network transparency is abandoning this is something the compositor should be doing. Rather the success of RDB proves it is better done at the GUI level. In other words do it at the rendering level . Now the good thing is both KDE and Gnome support the shift to Wayland and both of them have indicated they agree it should be done by the GUI level, so as much as open source projects can meaningfully commit to stuff, they've committed to doing it.
Now in terms of pervasive. That really is a choice the Linux community makes after KDE and Gnome develop remote rendering and after (if they ever do) create the equivalent of DBUS. At that point other widget sets have to decide whether they want to adopt the standard. For example wxWidgets are based on GTK they could use huge chunks of the Gnome code... but it is going to be up to wxWidgets to decide. Mozilla will have to decide whether it is worth it for XUL. In 2007 I'd say they would likely want to be one of the first to implement it and be on the committee. Right now in 2012 they are in a trim the fat mood desperately trying to keep up with Apple, Google and Microsoft now those 3 are spending a lot on browser development. In 2020 maybe they've fallen so far behind that they are comfortable being a niche browser, or being a Linux only solution and are like they were in 2020. But maybe they aren't and they have fallen behind but consider catching up their #1 priority now that Apple, Microsoft and Google have slowed down browser improvements; or whatever the future holds.
The other issue is of course whether Wayland goes in the direction of Microsoft or Apple. Both roads exist once X11 is abandoned. Apple implements pervasive integrated video and integrated animation. The Clutter project wants to bring this to X11 but its hard so they are failing. GNUStep while being essentially Linux only always (more or less) follows Apple standards so they are one that I can see being resistant to a Linux standard for application portability regardless but this would be a moment for them to shine. And we don't know how Linux users feel about video and animation once they offered these things being silky smooth and available at all levels of their GUI. They may very well become like Apple users who consider it a vital part of their computing experience and won't give it up for better remote access. Wayland creates this fork in the road between the Microsoft and Apple way of handling the desktop that doesn't exist today. The Wayland guys like Microsoft's approach but once you create the choice, we don't know which door Linux picks. In 2001 when I switched to Apple, I never would have thought how much I love integrated video. I'm not a visual guy but by about 2004 my taste has definitely changed. When I'm on Windows or Linux and don't have it, everything feels so 1995 and clunky to me. I'm fully functional on those alternate desktops but never comfortable.
So lets assume as a thought experiment that the Linux community does consider remote important and that Linux application tastes more or less don't change. So I propose for the purpose of argument
The difference is that it was clear with the OSX transition that the new APIs would be viable replacements for the old
I hope you check back. This was a good comment. You should get an account.
Before 10.0 was released. No it wasn't clear at all. And wouldn't be for a while. 10.0 was much rougher than Windows 8 is today and was being met with far more hostility. For example http://www.asktog.com/columns/044top10docksucks.html
Some of that stuff like multiple monitors I'm sure will be added with service packs.
Clear type is going to be replaced by high dpi monitors. I own a macbook retina you don't want this sort of rendering it looks horrible. Metro's approach is better for high dpi.
As far as "simultaneously running applications" I don't see that. Snap works fine. Possibly I'm missing what you mean?
As far as dynamic loads there are 3 methods already supported and likely more to come.
If you use OSX consider what OSX was like with regard to the Classic box. You are, using your metaphor, upset that your workflow with classic works worse on OSX than it did on OS9. Well yeah, of course.
And I would suspect for GDI applications Windows 9 is going to be even more uncomfortable. Where it will shine is Metro applications. And that's the point to start shifting the development community over to the new interface. Apple hit tremendous resistance as they moved people from Classic to Carbon to Cocoa every step of the way. But by constantly advantaging Carbon over Classic and Cocoa over Carbon they achieved the migration.
Huh? Calligra is much older than Libre Office. KDE office was around when Libre was still Star Office. Neither one of them is new kid on the block unless you want to go back 15 years. If you do back 15 years...
the goal of KDE was to create a GUI for Linux. The Office suite has to follow the GUI standards.
Star Office was a port of a pre-existing 2nd tier office suite to Linux. They didn't follow the GUI standards but they were the furthest along when Sun acquired them.
I think you are missing the point of the comments below.
CSV is a data format. Test attributes like bold aren't considered part of data. If on the other hand you define the field to be "HTML block" and not "text" then CSV could have formatting.
In general though people who are using CSV are OK with losing formatting. So the culture around CSV is not to do what you want. That's not a failure of KDE so much as it is a desire for an independent format that doesn't preserve formatting. ODF does preserver formatting and data.
In that case they should be on Open / Libre / Neo Office not Calligra.
KDE and OpenOffice (Star Office) were never designed to fill the same the niche. KDE integrates with the GUI while LO/OO/NO is GUI independent. I can easily break apart KDE Office functionality and widgets and use them in other KDE applications. I did this myself about a decade ago where I took many of the row and column management functions from KDE's spreadsheet and moved them to a thick client.
I think this situation is good. Long term Open Office should be conservative offering something like Microsoft Office.
KDE Office (Calligra) should be aggressive moving into new areas and designs for Office applications and tightly integrate with KDE.
Responding to correction below (request for air)
No way they do an air by Christmas. They don't have a video card that can drive that screen effectively at that price, heat or battery point. Nvidia is working hard on retina support so fall-winter 2013 is possible
I think it is fair to say we don't know anything. Gruber along with everyone else is just guessing. His point about this not shipping in September but being announced in September is a good one, we don't know enough so this isn't a few weeks from going on sale. October/November sale date seems more likely.
Here are the resolutions:
iPad 1/2: 1024 x 768
iPad 3: 2048 x 1536 (doubled)
iPhone 4S: 640 x 960
iPhone 5 (rumor): 640 x 1136
earlier iPhone: 320 x 480
I'm going with a bigger version of the iPhone 5 resolution. 1136x640 is close to what the original iPad had, allows for a cheap screen, doesn't require developers to support yet another resolution... But no one really knows.
The other big question for September is whether there will be a 13" inch retina macbook pro.
Microsoft is a vendor-lock-in company.
The claim above was much broader. Far more accurate would be: "Microsoft is a OS vendor-lock-in company" because Microsoft is incredibly open in the areas of: application software, hardware, parts, accessories, web services....
any major multinational corporation in drafting a standard is preposterous. none of the largest technology companies in the world mentioned in the summary have a vested interest in ensuring interoperability between competing products at any level
Of course they do. They often have a strong interest in interoperability everywhere but where their core profits come from. So for example the entire success of the PC platform is based on the Intel / Microsoft / Western Digital Standard for x86 which has allowed hardware interoperability. It was a standard which parts manufacturers like Intel and Western Digital benefit from, and software producers like Microsoft benefited from that was however devastating to the box producers like IBM, Osborne, DEC...
Similarly Microsoft has a tremendous interest in coding standards and API standards for software to run against Windows and for programs to interoperate with one another. That's why they've spent a fortune laying the infrastructure for things like drag and drop and OLE to work as well as they do.
I think we are going to get both. Obvious VNC already exists. After that Gnome is going to implement a solution for Gnome applications, KDE a solution for KDE apps. The freedesktop group will probably create a standard so that the two desktops, Firefox, OpenOffice... can use either the Gnome or KDE standard to some extent. But yeah I can easily see that Linux's RDB ends up being GUI specific and KDE's only really works right for KDE/QT apps and Gnomes really only works right for Gnome / GTK apps.
But what you were suggesting for OpenGL would still require a protocol to make work. And the apps need to know about it at the messaging level which requires the event handler and... This isn't an easy problem in practice. You are getting 80% of what you want, not 100%.
I think:
VNC = 100% computable lousy performance
GUI specific = 50% compatible good performance
client server = specific to the client excellent performance
is a rather nice lineup.
I'm not sure what adding
X11 = 95% compatible lousy performance under most situations but for a few good performance.
really adds. Obviously the perfect world is the performance of frame buffer with ubiquitousness and compatibility of X11 but that's not possible to achieve.