Give GNOME 3 time [LWN.net]

Give GNOME 3 time

Posted Aug 18, 2012 22:48 UTC (Sat) by hp (subscriber, #5220)
In reply to: Give GNOME 3 time by akeane
Parent article: The GNOME project at 15

> Sorry GNOME people

Note that there have been few if any active gnome 3 developers on this thread. (I hedge that because I don't know for sure who everyone is.) I had nothing to do with gnome 3 for example. The current developers aren't getting involved. Probably wise.

> mechanism over policy, i;e; pushing policy decisions up to the end user.

Been meaning for years to write a blog post about the bogosity of that old thing ;-) (I've normally seen it used to explain separation of X11 from toolkit/WM/desktop, not separation of desktop from user, though...)

The problem is that "policy" and "mechanism" are relative rather than absolute terms. Every hunk of code is policy for stuff "below" it in the stack and mechanism for stuff "above" it. So the real question about a piece of code is its role (what is it policy for, and what is it mechanism for). "What does this bit of code define, and what does it leave alone, and what does it have nothing to do with"

Since they are relative terms they don't mean anything without filling in "policy for ____" and "mechanism for ____" and then it isn't a principle that tells you what to do anymore, it's just a judgment about what you want in the "____"

It can be used to justify anything because you can always claim _accurately_ that a given hunk of code is a mechanism AND a policy, you just have to put the right thing in the "for ____" to prove it. X11 is mechanism for the window manager. X11 is policy for the graphics driver.

If you take "mechanism not policy" more abstractly you could say it just means "everything should be as flexible as possible to allow the policy above it to do what it wants" and to that I'd say YAGNI. Bloat bloat bloat.

(Log in to post comments)

Give GNOME 3 time

Posted Aug 18, 2012 23:46 UTC (Sat) by akeane (subscriber, #85436) [Link]

>The problem is that "policy" and "mechanism" are relative

<cheeky banter>
Quite right, for example somebody might decide that the routine which draws the desktop background a certain color would be the "mechanism", whilst the choice of color to draw would be the "policy".

What a fool they would be because they have failed to appreciate your assertion that policy and mechanism are relative and can not be neatly
divided, which is why the problem of "how to decide what color to set the desktop background" is that age-old computer science puzzle yet to be solved by *any* desktop for over 200 years!
</cheeky banter>

However, your innovative "relative mechanism", could at least foster a spirit of compromise between the hard pressed developer and the unreasonable end user: The developer gets to pick R and G values and the end user is allowed to set the B value and finally there is peace to one and all...

>X11 is policy for the graphics driver.

Yes, thats true, I could use framebuffers if I wished instead of the X protocol, that's not "for" the graphics driver however, the graphics driver doesn't care either way what comes above it. In the same way X doesn't care what widget libary or window manager I use.

See how much choice that gives me, the end user, so far, it's _my_ policy to pick whether to use X or something else. I can choose the mechanisms I use according to my policy.

That's good, it means freedom of choice, if I want I can code something directly with X if I wanted and have it display on my desktop regardless of GNOME/KDE, etc, etc or on another destop on my desktop running either, the thing that lets me have that freedom is the clear distinction between mechanism and policy, and whilst I have sympathy with the viewpoint that finding that distinction is _sometimes_ not that obvious but most experienced unix devs can make that call pretty well.

If you use gitub do you honestly think that Linus has some hardcoded values for github's html layout in the git backend, no, that would be mad!

>If you take "mechanism not policy" more abstractly you could say it just means "everything should be as flexible as possible to allow the policy above it to do what it wants" and to that I'd say YAGNI. Bloat bloat bloat.

<more cheek>
Yes, good god, imagine the gigabtyes of code required to code window that asks "what fontsize do you want?", and then the terabytes of diskspace required to store 255,255,6 in a file somewhere, think of the inodes, please won't someone think of the inodes!!!
<less cheek>

Seriously, I do take your point that defining the boundary in some cases is not obvious, and in some cases you see that boundary only after having written a lot of code, and it can be a bit dispiriting having to rewite a lot of code (trust me I've done it more than once ;-) especially if you have external pressures like deadlines, politics etc. etc. that would be involved in having to make that decision.

Have a nice weekend!

P.S. Someone mentioned flamewars, I see nothing but a set of intelligent people arguing a conflict of interest in a calm, rational way, at least we can all agree that GNOME 3 is the emacs of desktops (ducks for cover ;-)

Give GNOME 3 time

Posted Aug 19, 2012 0:17 UTC (Sun) by akeane (subscriber, #85436) [Link]

Sorry for another reply hp, but couldn't resist...

>Note that there have been few if any active gnome 3 developers on this thread.

I think both of them are busy...

>bogosity of that old thing ;-)

"old thing", how dare you!?!! Get off my lawn ;-)