McGrath: Proposal for a new Fedora project

First of all, it's not like these ideas need to be evangelized anymore. Every geek on this planet already knows that HTML5 is "the future". In fact, the future is already here. Studies say that people spends 50% of their time using the web browser. A web browser is most of what Joe User needs these days. In one conference, Google said there hasn't been any killer desktop application for Windows since Gmail was released, and it's true. All the new things are being developed for the web.

We have seen all this in the past. In fact, Unix was developed with the "cloud" mindset. Unix shells were the 80-90's "web services". And clients didn't going away. Yes, there were "dumb terminals", but then Linux appeared and it became fun to run a unix client on a PC. The history's wheel isn't stopping on HTML5 and Google.

The client isn't becoming irrelevant. The browser is slowly becoming the most used app development toolkit, a substitute for QT/GTK, yes, but that's not bad. Instead of QT, I suppose will use the Webkit toolkit (plus javascript libraries). But client's aren't going away. iPhone is succesful largely because it's a great _client_. Native desktop apps are becoming cool again thanks to iphone. While everybody was blogging about how the desktop was dead, Apple asked developers to write desktop. There are hundreds of thousand of mobile apps - but before iPhone's announcement everybody was swearing that the web was the only future possible. These days, the success of a mobile platform these days is not measured by how well it runs the internet (all platforms do well in that front) but by the number of native desktop apps that are developed for it. In the next years a mobile phone won't be worthwhile because of its HTML5 implementation (all them are similar). Running HTML5 will be the boring standard, it will be the _client_ side what makes a mobile phone different.

The problem for Fedora/Gnome isn't HTML5, it's Android. Android has become Google's desktop, development platform and distro. Where is my Gnome Mobile? Where is my KDE Mobile? Where is my Gnome Mobile App Store? Where is my Fedora Mobile distro for HTC devices? Yes, Gnome/KDE/Fedora are becoming irrelevant for end users, but only because end users are going mobile and there is not a KDE/Gnome/Fedora for mobile devices, only Android. That's what it needs to be fixed.

Cloud computing is just a buzzword so far and ChromeOS will likely be a stillborn child, if they even decide to release it at all to cannibalize their Android marketshare. Let's see what happens to OnLive, which is more serious attack on traditional desktop than NaCl currently is.

Maybe the Fedora project should consider mergin Android features into the next release.

Either a complete Android setup, as a desktop environment.

And/Or

The ability to run Andoid apps and widgets on my Gnome Desktop. (KDE too, of course)

I realize this is nitpicking, but this isn't true. Google V8, WebKit's JSC (which is to say, Apple's Nitro) and Mozilla's TraceMonkey all came out around the same time, and all brought huge speed improvements. It isn't Google that is soley responsible for this.

Yeah, Javascript is the language of the future on the client side, although I hope to Hell server-side Javascript never goes anywhere, because I think servers should be written in Erlang. ;-)

I believe we'd need to build it on something like ccnx.org or freenet/gnunet and bypass the whole server infrastructure/single authority/trust part. And only then blur the lines between your desktop and the internet (making your PCs just a cache for the network).

Today's Linux success was built on it's network orientation. At a time when others were still trying build some network genes (Windows) or adapt from Company/Campus network mindset to WWW mindset (legacy unixes, all the technical bits available but no turnkey solution) Linux proposed a complete pre-packaged WWW-ready solution (that became better known as LAMP). You can still install today this stack on all the major Linux systems in 5s of apt-get/yum install.

This was sufficient to make Red Hat and Suse the big Enterprise computing actors they are today.

However, it was *not* sufficient to make Linux a big consumer success. Because consumer computing demands yet another level of turnkey integration. Just like 2000-era legacy unixes demanded too much work to assemble existing bits into a turnkey solution, the 2000-era linuxes were not a consumer turnkey solution.

Thus, Red Hat and Suse looked at the consumer market, (correctly) assessed they were not ready for it, and refocused on the Enterprise, while funding the efforts of several teams to try to eventually crack the consumer Linux problem.

Those teams looked at the Linux software stacks, saw nothing that looked like the consumer software king's offerings (Windows), and decided to rebuild from scratch a new Desktop stack, modelled after Microsoft and Apple products.

They are still at it today.
It has been a massive failure.
Somehow, along the way, people forgot the point was to reach the consumer, not clone Windows and OS X.

Interestingly, Google targeted the same consumer market, but chose a radically different strategy. They didn't expend resources on building a Desktop clone. They took the traditional Linux enterprise/network stack and pushed it another level, making it consumer-ready. The Android gadgets that are flooding the consumer market now are succeeding where other Linux-based efforts failed, and they do so without trying to clone Windows/OSX.

It is not incidental that Oracle is suing Google now. Google took the good points of Java (huge software library, lots of developers), dumped the bad parts (terrible system integration) and managed to commodise it, making it a hit.

At the same time Linux consumer people frowned at Java (Enterprise stuff not fit for the desktop, not interesting) and Linux enterprise people ignored its problems (what if it needs hours of J2EE server setup before anyone can use it, other Enterprise OSes have the same problems) and completely missed the boat.

But it is not too late.

Linux consumer people need to re-assess all the Enterprise/Network heritage of Linux, and think of ways to re-purpose anything which can be of consumer use in the consumer space (for example, NetworkManager people finally realized that ISP DNSes sucked big ways, and that they've been sitting for years on perfectly fine DNS implementations which could be used to short-circuit the ISP DNSes and make Linux a better consumer system). You can't afford to put a blind eye to what Enterprise people do. You "simplified" your problem by ignoring non-desktop computing for years, and that's why you were not the ones who released Android.

Linux Enterprise people need to work harder at streamlining their components, and not stop at the "good enough for the Enterprise" level. In 2000 one could install a state-of-the art LAMP stack on Linux. Since then many new elements were added in Enterprise computing. Most of them can still not be installed natively in Linux systems (mostly, because they've been written in Java and Linux people have been complacent about Java integration). That was the thinking of the legacy unix vendors before Linux people ate a lot of their lunch.

A streamlined Enterprise stack will make Linux once again the natural platform for writing Enterprise apps (and not just a "as bad as others, but on cheaper hardware" solution, others can release x86 solutions and Google most definitely will eventually).

A streamlined Enterprise stack will make it easier for consumer Linux people to pick the good bits for their own needs. A lot of thought has been extended in the Enterprise space to make multi-server computing work, the natural Linux answer to the cloud should be to make multi-desktop system work together without depending on huge system farms controlled by more or less "evil" entities. Those farms do not exist because they are a requirement to fulfil consumer needs. They exist because they are a requirement for the data-mining the builders of those farms engage on.

Linux consumer people need to stop thinking in 2000-era client/server terms, with their part limited to the client one (consuming web services and web apps hosted gods know where), but start producing internet-exposed apps that can be consumed by desktop peers. Yes a network service makes your system a "server". No it does not need to be a "server" in Enterprise computing terms. Please invent consumer network services. Please invent network services people can apt-get/yum install on their systems, sharing computing with friends, instead of continuing to focus on the client part, with the smarts moving the other side of the network link. Especially when this other side is slowly but steadily reducing the Linux part to basic platform needs.

The object embedded desktop is the future! Apple and Microsoft bets a lot of money on this. Those who do not adapt will perish. (1996).

IA64 is the future. It is completely backed by Intel and will rule from the PC all the way to the supercomputers and mainframes. Other players will be run over so drop your own efforts and join while you can. (1998).

Thin clients are the future! Since everything will be written i Java anyway nobody will want a PC. (2000).

Desktop search is the future. Any desktop will need to implement metadata indexing this year or the users will abandon them completely. (2002)

These predictions come and go every few years and from the perspective of those who conceive them they are always completely inevitable. Only in a static world would their logic hold. But the world is complex and constantly changing so most predictions do not materialize.

The few that are proven to be correct creates new markets and leaves very little room for the original players to actually benefit. UNIX sort of won, with Windows as a new contender nobody expected, but none of the big players are still around to cash in. The IBM PC sort of won, but it is a market where IBM is irrelevant.

Those who survive these predictions are always the ones who solve real problems for real customers. And there are plenty of those. Pick the low hanging fruit first. Make Linux a fast and easy to use desktop. Those will be required even when web browsers are the only thing that run on them. By all means, do cool things with HTML and Javascript on the side, but don't ever let it take resources from what's important for your users.

Between the folks who are still fighting valiantly to win 1995's future for Linux on the desktop, and the loud (if spectacularly uniformed, and occasionally paranoid) minority opposition to "computing in the cloud" or "software as a service"—not to mention Javascript—led by folks who don't even actually use the web, I expect more time will be spent in bickering over what it all means, and how free it is, than in actually getting much useful work done.

Good suggestion, though!

What I would like to see in a similarly corporate distruptive vein, is the fruition of the decentralized cloud. It often seems to me that ipv4 and nat are the major blockades to a world where everyones desktops and other devices can act as a replacement for the current corporate provided 'cloud'. That, it seems to me, implemented well, would be how free software could really make an impact against the big $$ corporations that pose the most severe threat to a higher level of computing freedom in the future.

What it would take it seems to me, is perhaps lots of similar groups like the Diaspora project. On top of a foundation of presumably ipv6 where there is no blockade to all of our devices giving 1% of their resources to the decentralized cloud.

But again, this vision is also nothing new, just a different flavor of the koolaid. And again, something that would be a project/movement outside of fedora, utilizing fedora as long as fedora is the right tool for the job.

Really, I think it will be very interesting to see where CentOS-6 takes us. It seems that will be the validation or invalidation of what fedora has been for the last few years. I'm actually pretty optimistic on that front, and see C6 quite possibly providing a solid platform for many radically different, and all disruptive computing stacks.

Dude, Fedora is a free software distribution that serves as the proving ground for RHEL. It does (or better to say RH does) sponsor original new code, mostly in the system integration and infrastructure areas but it's mandate isn't to boldly explore radical and experimental new frontiers in information technology. Most of what they ship is slightly customized packages of the same software everyone else is shipping. More bluntly, do you see RH trying to pitch your new notion to corporate RHEL customers anytime soon? If not why are you expecting Fedora to reorient itself to the mission of implementing your vision?

Get your new reimagining of the the software stack up, at least to the prove the idea has merit level, and let several distros eventually package it and distribute it to a wider audience, perhaps someday as the default.

But don't bet the rent money on it. You aren't the first to propose a totally new computing model based on a pet theory. Just for starters you could ask the Sugar guys how their attempt to take over the world worked out. And in another year or two ask the Meego crew how their far less ambitious project ended up. Or if you can find one willing to cop to the charge, find someone with the Bob project.... that one sure redefined the user experience forever... NOT! Sudden leaps in evolution do happen in IT as in nature. But they are very rare, slow improvement is the norm. Most of the really strange mutants just die a quick death after everyone gets done laughing.

(1) Drawing of GTK Objects. Each element in GTK knows how it is drawn. I would like that so that each element simply outputs is HTML equivalent (or just a HTML5 canvas and a special drawing routine for more complex ones).

(2) I would like to replace the GTK main() loop to a simple HTTP server.

(3) I would like to implement all events in JS.

But the main point should be, that all those changes are only done in the alternative GTK library and not in the application. After that, I could decide if I start any GTK program with the original GTK library to get a desktop application or to modify the LD_LIBRARY_PATH so, that the webgtk library is loaded, which then starts an HTTP server in it's main loop. After that I can access the application with any browser (even remote).

This way, nearly all applications will be runnable as web application too (ok, some custom widgets might not work directly and the application might leak memory which isn't a trouble for a desktop application, but fatal for web applications...) but still most of the apps will work (hopefully). Later, an alternative cairo library based on the HTML5 canvas and so on might follow.

After that, we might be able to integrate such web applications back in the desktop, e.g. by automating the task of starting the application as web application and open a window with the right URL automatically, which looks like the native window before.

And then the last step would be to provide additional features for the web application by adding additional scripts and additional callbacks between GTK and the HTML5 application and to tune the HTML5 application a bit (e.g. by adding more caching with the localstorage and things like that).

The benefit of this approach would be that existing GTK applications won't be lost, and that we don't have to re-implement everything...

I am neither a GTK ninja nor I've any time to become one. In fact I am just dreaming loudly... So feel free to implement something like that if you are optimistic enough :)

Regards,
Christoph