GNOME 3.8 to drop fallback mode

"Mounting a file system into the root file system involves a certain degree of configuration and as such is subject to whatever preferences an user might have. gnome-mount allows the user to control the mount point location, the mount options and what file system to use for mounting a file system. The settings are read from the gconf database (which is per-user) and can also be overridden on the command line using the appropriate parameters."

If you accept that mounting a volume can (a) have user-specific preferences and (b) have specific permissions, then something has to talk to the user session to make those determinations. And a root process reading user settings usually runs afoul of security policy, hence the user-session mounting utilities.

Unfortunately, it seems that various other projects have specific support to make fallback mode work. So initially I was happy that as a side-benefit people would be able to get a GNOME 2 experience. At the moment I'm doubting if it is feasible because it involves way more than just gnome-panel and metacity.

To give a bit more concrete insight: https://bugzilla.gnome.org/show_bug.cgi?id=fallback. That is the tracker bug.

BTW: Fallback mode has been discussed during the development of 3.4 already. Only since 2-3 weeks I heard that Unity apparently depends on various fallback mode bits.

So sometimes things are not intended in a bad way, but they can easily be interpreted as such. E.g. "GNOME fallback removal to kill Unity".. while in practice we (at least me) had no idea despite having discussed this for 6+ months. For the Unity case we did ask Canonical before doing an announcement... though we work in the open so official announcement is often way later than sites reporting it as news.

"Compile a list of gnome-shell extensions that can help people who prefer the GNOME 2 UX #685744" (which points to https://bugzilla.gnome.org/show_bug.cgi?id=685744).

That is besides of people who want to take care of gnome-panel et al. However, I really doubt there will be people stepping up to help with those packages, considering the many calls for help in the last 2 years. I would like to be proven wrong, though.

I wonder… :)

Of course, in the real world, what actually happens is that old systems are never replaced, only stacked upon, which is why my local auto parts store have POS terminals running fancy web-based UI running on an in-store server which just translates everything into a console/textual terminal session, which in turn tunnels over IP (instead to replace dedicated POTS phone lines) to a decades-old inventory-management application running on an emulator running on an IBM mainframe (which itself may be emulated...)

And of course, the source code to all of those intermediate components is long gone, so no changes could be made even if they were willing to risk breaking the whole stack to improve the efficiency of even one component.

Fortunately, the Free Software Movement is braver than that. Which is how we have the likes of KDE4, Gnome3. And KDE3, Gnome2/MATE/Cinnamon, and XFCE, Enlightenment, and many, many others.

We control the entire stack by virtue of having full source code to everything, and the rights to change it however we like. It's downright stupid to cripple our primary advantage by treating any part of that stack as a sacred cow that can't be slaughtered.

Only in la-la land (and Debian) is the answer "don't decide, and just go with all of the above."

"Running optimally" on modern graphics hardware means that you still have to support obsolete graphics hardware, which means your entire decision/design tree has to incorporate that. It's double to triple the initial amount of design/coding work, and exponentially increases the support cost, and does not gain them anything significant on their strategic long-term goals of building a kick-ass *desktop* environment.

They decided to focus their effort into building a single opengl-driven path. For a fallback for completely obsolete hardware, a pure software opengl rasterizer would be used, keeping the complexity at the natural component boundaries, rather than have to have the entire stack aware of everything else. It's sound software engineering practice.

We're at the same situation with desktop 3D as we were in the earlier days of Linux-wireless, before there was solid internal infrastructure and enough common code to make things consistent. Each driver had its quirks, so all applications had to know about those quirks to ensure consistent end-user behaviour.

NetworkManager was a major disruption, because its maintainer took it upon himself to actually fix the underlying buggy drivers so they all behaved in a consistent manner. This is where the Gnome3 folks are at now; a great deal of work is going on behind the scenes to drag the 3D stack kicking and screaming into the modern era.

This means prioritizing development effort -- fix the backend bugs, and everyone benefits in the end, rather than work around the backend bugs, and do three times as much work each time something new comes along.

(and as an aside, modern hardware doesn't even have any sort of 2D engine beyond a dumb framebuffer any more; do we "emulate" the old 2D stuff via the 3D engine, or target the future, and make everything 3D which vastly reduces the overall amount of work necessary?)