Breaking Assumptions: Chapter 1.

Seems like a good moment to throw out the ideas about how to do real innovation on GNOME, while I think Andy's post was a little bit pessimistic, I think is good it has started the discussion inside the community, and I do think that I have some points into it so here's my 2 cents on the topic. I´ll do a few post with different points to not bore everyone.

The Desktop is the OS

I think it's time to break loads of assumptions and to risk some "backwards compatibility", not in terms of API/ABI, but in terms of how do we think about our desktop. We must start thinking about the desktop as something more similar to an OS rather than something on top of the OS in favor of a better user experience. I will try to show what I mean with an example.

We sometimes have a hard time developing good UIs to manage basic OS services such as sharing a folder or configuring the network. I encourage you to create a bridge interface and add your Ethernet and your Wi-Fi card into it under XP and compare then doing that on few Linux distribution. The first thing you'll notice is, typing ifconfig / brctl won't store the configuration, and modifying the text files won't change the current configuration until you restart some machine, the second thing you'll notice is that each distribution will have it's own configuration format, and in some cases its own tools.

That's why projects like NetworkManager and GNOME System Tools have a hard time to succeed, the first one tries to solve only the obvious and simple problems, but it ignores totally ignores the stored configuration and the specific services of the distribution, and the second one tries to support every distribution, which leads to a huge maintaining effort.

Instead, the GNOME community could say, see, this is how you're going to store network configuration (interfaces, proxy, vpn, gprs, ppp...) if you want an unified user experience and this is the UI and the command line tools for it. If the right tools and the right APIs are there, I don't see any reason for distributions not adopting it after a few releases. Let's stop delivering half arsed solutions.

This is just an example of what can be achieved, other examples could be the current directory layout (I can't sleep thinking about the screams of users browsing / from the file chooser), software installation (go PackageKit go!) and (put your favorite legacy weirdness here).

The landscape has changed a lot over the latest 10 years, and we have showed that we can offer a predictable release that's API/ABI stable, we're the desktop and the development platform of choice for all the major opensource desktop vendors (RedHat, Canonical, Sun Microsystems, Novell...) and they've showed they're willing to work closely with us (see the GIO port success!) to achieve reasonable goals, we have not only the power, but also the responsibility to boost changes to improve the whole situation. Yes, we can! ;-)

Stay tuned.

Comments

[fvdsn]

I like it :)

[fvdsn]

I like it :)

[Nicolas Mailhot]

You're soo right.

The *huge* problem with GNOME is a "backend does not matters" attitude. There is a lot of work to make stuff work well the first 2 hours on simple laptops with no history, but somehow the data always end up in brittle blackhole stores that rot over time, apps do not survive being run 24/24 7/7 without restarts to purge leaks, any intensive non-casual use requires workaround vodoo knowledge, multi-user and network $HOMES is not solid, desktop was moved to ~/Desktop instead of cleaning up ~ dotfile mess, complex hardware is not exploited to full potential, gconf fills in with leftover data that needs to be cleaned up manually, etc

GNOME's problem is not uninventive UI but that it's all pretty stuff built on quicksand and after a while the quicksand asserts itself and pulls everything down. (This in stark contrast with historic unix apps. GUI developpers are always quick to dismiss bind, named, apache, postfix, etc as overfeatured for simple desktop use, and then proceed to write stuff that gobbles twice as much memory, does a tenth of those apps, and can not take an hundredth of the abuse they can withstand without blinking)

A kicking ass next-gen GNOME would keep the UI, but use solid integrated fundations instead. Be the windows 95 or 2000 of the GNOME family. Or the GNOME 2 HIG revolution for the GNOME backend bits.

[z]

It will never happen. Never. Though I wish it would. But it won't. Linux distributions is a topic that is way too much "politically" involved. You can't fix it. Everyone wants to feel unique, like that fork :
http://amopage.com/blog/wp-content/uploads/2007/07/inspiration-unique-fork.jpg

Free software developers are not able to work together to polish an OS until it feels completely integrated like Apple and Microsoft do.

[Patrys]

I hope we can come up with some viable solution at freedesktop. Not by forcing distros to use our tools but by being better than their home brew ones.

[Stoffe]

Sounds like exactly what Freedesktop is trying to achieve, but maybe it needs to go both deeper and wider, sooner. Not only should it all be cleaned out all the way down, but it should be cleaned up and suitable for any DE.

[Raphael]

You are right, in a lot of ways; the GNOME experience should become more than just a thin layer on top of an operating system. GNOME should feel like a true representation of the operating system.

I don't think, however, that it would be a good idea to throw away all those nice userspace tools. But I do think that all system services (user/group management, raid/disk management, hardware management, and so on) should be exposed through message services. D-Bus would be an obvious candidate, since it has become something of a common inter-process communication service for most desktop applications anyway. Why not expose system services through an IPC framework and, hell!, make it available through policyKit? Call it systemKit or whatever.

That way, you could provide access to the whole system, in a well defined way. Writing applications to use those services will be cake.

Although I admit that it may be time to rethink the whole desktop experience anyway. I'm experimenting with the Ubuntu Netbook packages, using all my applications fullscreen all the time. It feels funny at the start. But as soon as there is a solution for drag&drop, I could get used to it.

[Carlos Garnacho]

Raphael, that's called system-tools-backends, check out http://system-tools-backends.freedesktop.org/

[harry]

GNOME already is an OS on top of GNU/Linux. With its own API, file system standard, configuration management, etc. Why not do the logical step and remove all the GNU tools, invent your own package manager and you're done. You could keep Linux, but maybe it'd be better to make your own GNOME-kernel, that has the GUI already integrated, so you'll have full point-and-click freedom

Yeah, right, I switched to GNU/Linux because I want it to become more like windows. Doing something remote? Oh, I need a GUI for doing stuff. That rules out ssh. VNC/RDP you say? Well, slow line and maybe only a sub notebook with 10" screen. Command line tools for configuration you say? A well documented text file as configuration still is the most powerful and usable interface. But you've got rid of that already with the GNOME registry (gconf its called?). I'd be happy to be proven wrong, but so far I haven't seen a point-and-click tool for configuring a complex network setup (multiple interfaces, bridges, VPNs, tunnels, special routing entries) or an MTA that is intuitive *and* as powerful as text files.

A revolution would be a GUI that is intuitive, logical, usable, simple as well as not a PITA for the advanced user.

[oliver]

Nothing against polishing Gnome, but if you want it to be the new "OS platform", this won't go well with desktops like KDE and XFCE. And while Gnome is a nice desktop, I also use KDE and XFCE where it makes sense, and also I think it's good that there are competitors to Gnome.

More freedesktop work seems like a good idea, though.

[puks]

Agree with Carlos Garnacho and harry. The "desktopification" of Linux going on these days is insane, we're gonna pay for it in the future. Everything is becoming more and more complex. *nix is not about "backwards compatibility", it is about *simplicity*, and *stability* (both in the "don't-crash" and "don't-change-everything-every-once-in-a-while" senses). I hate all the "backwards compatibility for what?" and "stable API nonsense" that has come into fashion with Linus decision to not have a stable X unstable kernel development split. FLOSS has been able to progress on the hands of volunteers due to those simplicity and stability aspects. Once things become more and more complex, you just *have* to pay people to develop/maintain it.

[puks]

Sorry, I mean I agree with harry and oliver. didn't notice the poster was at the bottom...

[Adam]

Gnome should stop trying to be all things to all people. We should stop caring about "graceful fallbacks". If you dont' have a decent video card: run gnome 2.18 until you can afford one!
Not enough memory to run Beagle / Banshee / Deskbar whatever? Fuck off and buy some more then! Stop telling everyone to develop in C.
Worried about your app relying to heavily on an always on internet connection? Who cares - develop exciting apps for the people who do.

This is the kind of GNOME which I want to see, and which I could be excited about.

Don't worry about the "thin client" people or the "cheap software for less developed countries" crowd. Other people (Sun, OLPC) are already fighting these corners.

[Jonathan]

This kind of thinking scares me a bit. The problem I've always had with MS and Apple is blending of layers. Hooks are thrown from the kernel to the window manager to even the built-in web browser etc and you end up with one huge mess of spaghetti-code that no one can touch for fear of breaking something else. I like and use Gnome because it's thin, highly customizable, and keeps things cleanly isolated between the OS and the GUI. I chose Gnome over KDE because KDE seems to have too much bloat, and too much of developers making unilateral decisions because they get too much of a God complex (ahem, KDE 4). I'm not saying Gnome is there now, but this type of pursuit seems like it will head us in that direction.

[Ze]

Honestly half the bloody problem is that nobody wants to do anything sane.

I mean what would be wrong with merging sysfs,procfs,and having a filesystem for config under /sys.

We could have it export a common file format , however the format it exports doesn't have to be the format the configs are stored in.

different configfs/etcfs could have different backends , plain files , registry , gconf , local database , remote database etc.

The whole arbitrary splitting things between the kernel and a userspace daemon , so to run hardware , you need the kernel driver + userspace hardware daemon + the program to access the device is silly because we are stuck with a monothlic kernel.

Software seperation is a bloody simple concept people and a bloody good one , there is a good reason why we want to run things in a seperate address spaces. We are already basically replicating this in a bunch of areas with different locks , queues ,threads and userspace hardware and filesystem daemons, userfs and libusb.

So why not do it properly with seperate address spaces?

Microkernels don't have to be slow if you implement IPC properly (ie in the L4 vein versus the Mach vein). Once you've gone to a microkernel , then having a video driver as a microkernel server is a nobrainer unlike the current saga where it should've been done over a decade ago.

We'll get a simpler , more reliable and easier to maintain system. The RT folks will love us because we'll make their jobs easier.

Don't get me started on the GTK/Gnome guys with their reinvent the abstraction layer in c , and hack an object oriented system on top of it.

We've got C++ now and it's been mature for a while. It's much better than bloody Gobject.

The thing is a lot of the gnome apps now aren't being written in c , lots of folks admit that gtk+ is a pain in the arse to program in and you are better off using a modern language , but rather in python/vala/c# with bindings to c.

It's time we did GTK++ using Boost , and instead had c bindings to c++ with python/c#/vala/ruby bindings to c++.

There is nothing wrong with breaking compatibility , as long as you then write a compatibility layer on top of that for obsolete stuff.

If the kernel/compiler/library is lacking then instead of writing another layer on top of it to hide it then another layer on top of that etc. Then go and fix the problem in the first place.