Am I reading this incorrectly? I thought the summary said it *treated* everything as a web app, not that everything was itself a web app. By this I assume that means most of the new apps that will ship with this are written in Gears, and will exist in a sandbox. That doesn't mean every app is Gmail.
Will it be possible to load standard.deb packages of other Linux apps? Probably not anything that depends on Gnome libs and KDE libs itself, but pure GTK apps might work.
IE8 has pushed to a number of boxes where I hid the update and said, don't show again. Microsoft keeps pushing it over and over again as an automatic update. IE8 defaults to Bing. Many users don't know how to, nor care to change defaults.
I know you're joking, but Mozilla was already working on a hardware accelerated canvas system before IE. Even better, it will tie into OpenGL ES so someone could code a FPS engine into a web page.
In all fairness, you're running a beta of Chrome which has seen significant improvements. Chrome has spurred the FF team to make huge improvements, but those are in the 3.7 trunk version of FF.
Compare Chrome 4 to Firefox 3.7 and the disparity is much smaller.
This is actually vitally important for Microsoft given that their Chief Software Architect said Microsoft's future lies 100% in the cloud. If Windows Live services are the core of Microsoft's future, then performance in this regard is crucial.
Then again a Microsoft Evangelist once told me that the Outlook and Exchange developers are kept mostly seperate becase Exchange is part of the server division, where as Outlook is developed within the Office division. In big companies, consistent design goals are rarely realized.
I've heard that Chrome does have an adblocking extension that I haven't gotten around to testing.
Chrome is pretty damned fast out of the box. It has a better Javascript garbage collecting model which does help with memory. And I don't believe it keeps umpteen pages still rendered in memory the way Firefox does.
If Chrome supports adblocking and Greasemonkey, I may finally need to switch. I run nightly trunk of Firefox (3.7 currently) and it does run pretty fast itself however.
KDE 4 has official bindings for C++. Python, Ruby, and C# that are considered stable and mature. I've read developers rave about how easy development is with Python and KDE.
There are also official bindings for PHP, Lua and Basic.
KDE ships with scripting frameworks like KScript, Smoke and KCross which make it easy to develop for KDE using Lisp, Java, Javascript, etc. Then there's KDevelop, which is a fantastic IDE.
Kwin was always going to be the window manager and decorator. I thought they should have tried to support the compiz-fusion plugins for effects, but I guess the reason they didn't was because compiz-fusion doesn't have a stable API for those plugins.
I thought it was going to take forever to recreate all the functionality, but in the end, I'm fairly happy with the end results.
I prefer compiz-fusions' wobbly windows effect over the kwin one, but I'll live.
However, the issue isn't rewriting GTK in Qt to operates as GTK exists today, because GTK wasn't designed to run a full desktop initially.
The issue is taking Qt and developing a GTK replacement that better suits what a Gnome of the future would really need.
The debate over GTK 3 and Gnome 3 already suggests that you will hit that at some point. Fear of replicating the KDE 4 launch has people continuing to limp along on old conventions, but a larger rewrite probably still looms in the future.
There are much bigger differences between Gnome (such as design philosophies and primary languages) but my point is that Gnome could be developed with Qt while maintaining many of those Gnome differences.
Many Gnome apps have been utilizing Mono for newer features. Qt has Mono bindings. The language barrier isn't what it once was.
You can maintain a traditional Gnome widget appearance given that Qt ships with Clearlooks out of the box. And you still write your various Gnome libs to maintain various Gnome conventions.
RedHat, Ubuntu and the like can still ship Gnome as their default. And older GTK+ apps wouldn't be forced to jump over to Qt and newer Gnome libraries because you can still run both side-by-side.
Again, there appear to be tangible benefits. The major drawback is the time invested to make the change, but over the life of the project I think it would be easier to jump to Qt 4.x now than develop and support a GTK+ 3.x in the future.
Shuttleworth has made several comments about wanting to see a future Gnome built in Qt, and said a few times that he felt the real innovation was happening in KDE-land. I often wonder if he regrets hitching his wagon to Gnome.
I think Ubuntu is the primary reason that Gnome is still being pushed along as much as it is. However, GTK+ was not designed initially to power a desktop. Given that Qt ships out of the box with a Clearlooks engine, and that Qt is a better multi-platform framework, I don't know why there hasn't been some serious discussion to perhaps move a future Gnome to Qt.
You gain all the benefits of a modern Qt framework, yet you can still design with the concepts that Gnome is supposed to be based on (sane, simple desktop). You can follow Gnome conventions and perhaps just deliver a BETTER Gnome experience.
Why would that be a bad thing? Instead, let's continue to wrap around a kludge.
Compiz effects in kwin were ALWAYS optional, and were not turned on by default unless your hardware supported it. They could always be turned off with a single keystroke (Ctrl-F12? Can't remember) as well as within System Settings. That has been there since the very first beta releases I tested.
I've never seen an input lag, even running on an 8 year old crappy laptop. I do turn off Strigi/Nepomuk to cut down on HDD access. I'm curious what distro you were running.
Except that goes against the FOSS mentality of release early, release often.
It was necessary to get the KDE 4.0 release out and into people's hands to see the new frameworks so they could start developing around them. KDE's websites clearly labeled that 4.0 was a fresh rewrite that did not have feature parity with KDE 3.
What did KDE do that was dishonest? When distros forced the switch when it wasn't ready for everyday desktop use for most people, that was the fault of the distros.
I'm not talking about real-time processing (which cloud rendering can help with).
The new Zune HD is one of a few select devices that actually supports a decent resolution. It pisses me off because I can't use a Zune in Linux, and I won't buy a Zune, but it does have perhaps the nicest screen of any portable device on the market right now.
Most smart phones have low-resolution screens. You can't produce a photo-realistic image on a low-resolution screen, regardless of pushing rendering out to the cloud.
Slashdot Mirror
I want my email accessible from multiple locations. I can check it at work, at home, on my phone, on the moon, etc.
Do I trust my ISP? Hell, no.
Do I trust companies like Microsoft, AOL or Yahoo who hand over my data to everyone on the planet? No.
Do I trust Google, who has fought court orders to protect my privacy? Yes.
Name a better alternative.
SplashTop is a stripped down instance of Linux on a flash chip on some mobos. Chrome could do the same.
Am I reading this incorrectly? I thought the summary said it *treated* everything as a web app, not that everything was itself a web app. By this I assume that means most of the new apps that will ship with this are written in Gears, and will exist in a sandbox. That doesn't mean every app is Gmail.
Will it be possible to load standard .deb packages of other Linux apps? Probably not anything that depends on Gnome libs and KDE libs itself, but pure GTK apps might work.
Actually most netbook vendors have already said they're moving away from traditional Linux installs. Try findind a Linux netbook in Best Buy today.
However a large group of vendors has already said they will be shipping Chrome OS.
If the source is available today, what is the time until someone throws up a virtual image that I can run?
I doubt it lies 100% in the cloud as well.
However, that is supposedly what Ray Ozzie is preaching to Microsoft.
IE8 has pushed to a number of boxes where I hid the update and said, don't show again. Microsoft keeps pushing it over and over again as an automatic update. IE8 defaults to Bing. Many users don't know how to, nor care to change defaults.
I know you're joking, but Mozilla was already working on a hardware accelerated canvas system before IE. Even better, it will tie into OpenGL ES so someone could code a FPS engine into a web page.
https://wiki.mozilla.org/Canvas:3D
Xreal for instance is a pretty impressive engine coded in OpenGL ES.
http://www.xreal-project.net/
In all fairness, you're running a beta of Chrome which has seen significant improvements. Chrome has spurred the FF team to make huge improvements, but those are in the 3.7 trunk version of FF.
Compare Chrome 4 to Firefox 3.7 and the disparity is much smaller.
This is actually vitally important for Microsoft given that their Chief Software Architect said Microsoft's future lies 100% in the cloud. If Windows Live services are the core of Microsoft's future, then performance in this regard is crucial.
Then again a Microsoft Evangelist once told me that the Outlook and Exchange developers are kept mostly seperate becase Exchange is part of the server division, where as Outlook is developed within the Office division. In big companies, consistent design goals are rarely realized.
Which version of Firefox are you using, and what extensions do you have enabled?
You can also look into this.
http://www.ghacks.net/2007/02/26/firefox-memory-tweaks/
However I haven't had memory issues with Firefox in a couple of years.
I've heard that Chrome does have an adblocking extension that I haven't gotten around to testing.
Chrome is pretty damned fast out of the box. It has a better Javascript garbage collecting model which does help with memory. And I don't believe it keeps umpteen pages still rendered in memory the way Firefox does.
If Chrome supports adblocking and Greasemonkey, I may finally need to switch. I run nightly trunk of Firefox (3.7 currently) and it does run pretty fast itself however.
KDE 4 has official bindings for C++. Python, Ruby, and C# that are considered stable and mature. I've read developers rave about how easy development is with Python and KDE.
There are also official bindings for PHP, Lua and Basic.
KDE ships with scripting frameworks like KScript, Smoke and KCross which make it easy to develop for KDE using Lisp, Java, Javascript, etc. Then there's KDevelop, which is a fantastic IDE.
Kwin was always going to be the window manager and decorator. I thought they should have tried to support the compiz-fusion plugins for effects, but I guess the reason they didn't was because compiz-fusion doesn't have a stable API for those plugins.
I thought it was going to take forever to recreate all the functionality, but in the end, I'm fairly happy with the end results.
I prefer compiz-fusions' wobbly windows effect over the kwin one, but I'll live.
However, the issue isn't rewriting GTK in Qt to operates as GTK exists today, because GTK wasn't designed to run a full desktop initially.
The issue is taking Qt and developing a GTK replacement that better suits what a Gnome of the future would really need.
The debate over GTK 3 and Gnome 3 already suggests that you will hit that at some point. Fear of replicating the KDE 4 launch has people continuing to limp along on old conventions, but a larger rewrite probably still looms in the future.
There are much bigger differences between Gnome (such as design philosophies and primary languages) but my point is that Gnome could be developed with Qt while maintaining many of those Gnome differences.
Many Gnome apps have been utilizing Mono for newer features. Qt has Mono bindings. The language barrier isn't what it once was.
You can maintain a traditional Gnome widget appearance given that Qt ships with Clearlooks out of the box. And you still write your various Gnome libs to maintain various Gnome conventions.
RedHat, Ubuntu and the like can still ship Gnome as their default. And older GTK+ apps wouldn't be forced to jump over to Qt and newer Gnome libraries because you can still run both side-by-side.
Again, there appear to be tangible benefits. The major drawback is the time invested to make the change, but over the life of the project I think it would be easier to jump to Qt 4.x now than develop and support a GTK+ 3.x in the future.
The Nepomuk project has been around for over 3 years. I'm not sure when Microsoft started working on their start menu search.
However, Microsoft was working on such concepts even in the 90's.
http://en.wikipedia.org/wiki/WinFS
They just kept shelving them.
I think you could have very useful automatic tags.
For instance, I receive an attachment from you in an email titled Project Foo.
The file gets auto-tagged with your contact info from Akondi, as well as Project Foo.
Shuttleworth has made several comments about wanting to see a future Gnome built in Qt, and said a few times that he felt the real innovation was happening in KDE-land. I often wonder if he regrets hitching his wagon to Gnome.
I think Ubuntu is the primary reason that Gnome is still being pushed along as much as it is. However, GTK+ was not designed initially to power a desktop. Given that Qt ships out of the box with a Clearlooks engine, and that Qt is a better multi-platform framework, I don't know why there hasn't been some serious discussion to perhaps move a future Gnome to Qt.
You gain all the benefits of a modern Qt framework, yet you can still design with the concepts that Gnome is supposed to be based on (sane, simple desktop). You can follow Gnome conventions and perhaps just deliver a BETTER Gnome experience.
Why would that be a bad thing? Instead, let's continue to wrap around a kludge.
I can attest that openSUSE's KDE packages are considerably more stable. Kubuntu KDE packages are twelve shades of broken. I just don't understand it.
Compiz effects in kwin were ALWAYS optional, and were not turned on by default unless your hardware supported it. They could always be turned off with a single keystroke (Ctrl-F12? Can't remember) as well as within System Settings. That has been there since the very first beta releases I tested.
I've never seen an input lag, even running on an 8 year old crappy laptop. I do turn off Strigi/Nepomuk to cut down on HDD access. I'm curious what distro you were running.
Except that goes against the FOSS mentality of release early, release often.
It was necessary to get the KDE 4.0 release out and into people's hands to see the new frameworks so they could start developing around them. KDE's websites clearly labeled that 4.0 was a fresh rewrite that did not have feature parity with KDE 3.
What did KDE do that was dishonest? When distros forced the switch when it wasn't ready for everyday desktop use for most people, that was the fault of the distros.
Except in this case, training users to use OOo is simpler than training them to use newer versions of Microsoft Office.
So you save on the license, and you save on training.
If you have old, grainy, low-quality footage, there is no other way to release it other than Blu-Ray!
I'm not talking about real-time processing (which cloud rendering can help with).
The new Zune HD is one of a few select devices that actually supports a decent resolution. It pisses me off because I can't use a Zune in Linux, and I won't buy a Zune, but it does have perhaps the nicest screen of any portable device on the market right now.
Most smart phones have low-resolution screens. You can't produce a photo-realistic image on a low-resolution screen, regardless of pushing rendering out to the cloud.