LWN: Comments on "Questioning corporate involvement in GNOME development"

Irrelevant is the word, unfortunately

hitmark — Wed, 09 Jul 2014 02:31:29 +0000

Linking udev and systemd at the hip probably helped quite a bit...

Irrelevant is the word, unfortunately

hitmark — Wed, 09 Jul 2014 02:20:31 +0000

Udev?

Seems like a unrelated thing to me, but still joined at the him thanks to forced surgery...

Irrelevant is the word, unfortunately

hitmark — Wed, 09 Jul 2014 02:17:19 +0000

Anot just Gnome, but Linux in general. In large part because you can walk into any number of stores with a fruit on them to get things sorted.

If Canonical was really about getting on the desktop, they should have grabbed System76 and set up a retail chain of their own.

This because trying to get the big brands to offer Linux options are futile, MS have too deep pockets for that to happen (the sales margins are razor thin, so they companies need the bulk discounts).

Those who do the work, chose the direction.

hitmark — Wed, 09 Jul 2014 01:59:34 +0000

In all honesty i don't think it is limited to Gnome.

Multiple projects ("coincidentally" ones where RH pays the major developers) seems to have this "air" about them right now.

and many of them seems to be tied to rapid booting of limited systems. Perhaps aimed at aiding the rapid deployment of cloud computing instances as found in Amazon's EC2.

Even Gnome could tie into that, in the sense of remote desktops.

Irrelevant is the word, unfortunately

Cyberax — Wed, 18 Jun 2014 13:40:58 +0000

Sure. And Free Software also doesn't need users. And hardware to run. And developers.

Irrelevant is the word, unfortunately

mathstuf — Wed, 18 Jun 2014 12:36:39 +0000

> Packaging proprietary software is not a use-case that Free Software should be supporting to begin with.

I think you need to read the four freedoms again. As opinionated as RMS is, he still allowed proprietary software use in there (even if he doesn't agree with it, he didn't blacklist it at that level).

As bad as some RPMs are, they're better (on the whole) than those installable tarball-in-a-shell-script things.

Irrelevant is the word, unfortunately

Arker — Wed, 18 Jun 2014 04:17:59 +0000

"As someone who packages a proprietary software for multiple distros"

Well there's the problem! ;)

Packaging proprietary software is not a use-case that Free Software should be supporting to begin with.

Questioning corporate involvement in GNOME development

nix — Tue, 17 Jun 2014 22:50:16 +0000

You don't get the No True Scotsman argument here. If they cooperate, they're acting as individuals: everyone who doesn't cooperate is by definition acting as a tentacle of the RH monster.

Nonfalsifiability is fun...

Questioning corporate involvement in GNOME development

nye — Tue, 17 Jun 2014 15:09:03 +0000

> https://bugzilla.gnome.org/show_bug.cgi?id=705177

Ah, another bug in which reasonable people attempt to interact with William Jon McCann. I think it's fairly obvious that's not going to get very far.

Irrelevant is the word, unfortunately

rahulsundaram — Mon, 16 Jun 2014 22:09:48 +0000

It's perfectly fine to use systemd without any of the optional features. If you want to claim otherwise cite your concrete evidence to back that up.

Irrelevant is the word, unfortunately

Cyberax — Mon, 16 Jun 2014 21:05:08 +0000

> Each distribution might use their own init but these are still inits - they do that one job, not everything else, and you CAN easily swap them in and out to replace each other - on slack for instance we have a custom sysV init (but with BSD syntax) but that can be swapped out for e.g. runit, or OpenRC relatively easily.

With all the correct dependency resolution and handling of corner cases. Yeah, sure.

About the only thing you can do somewhat portably are simple daemons with no non-trivial dependencies.

> So the way I see it, we have a great big *nix ecosystem that includes the BSDs and the Linuces and anything else that wants to be compatible, but the bigger players (Redhat and Canonical) do not want to be compatible with it anymore.
There is too much difference for the sake of difference alone. As someone who packages a proprietary software for multiple distros I can only say 'kill them all with fire'. Or may be "nuke them from orbit, it's the only way to be sure".

There's a reason why distributions are switching to systemd in droves. And it's not because RedHat forces them to do this at gunpoint - it's because systemd is so damn useful. I've just switched my servers from Debian to RHEL7 and it's like day and night - systemd is so helpful that switching back to SysV is like descending into a stone age.

So 'hobbyists' can continue to slide into irrelevance or they can adapt. Either by creating something that can rival systemd or by working to make systemd acceptable for their use-cases.

Irrelevant is the word, unfortunately

Arker — Mon, 16 Jun 2014 20:50:51 +0000

"Sure, you can. The so called unrelated things are all optional. That is how distributions were able to move to systemd incrementally."

Moving to it incrementally has the support of the development team. A stable state where systemd is expected to play nice with traditional components it prefers to replace is rather obviously not the same.

Of course it's always technically possible with some developers and time, if you dont mind to spend the time you can make just about anything work, but that's really not the point. It's all designed to be used as one big unit and if you use it otherwise and find a bug expect it to be marked Wont Fix because they... well 'do not care' actually appears to understate it, Poettering quotes I have seen indicate he is actively antagonistic on the point.

Irrelevant is the word, unfortunately

rahulsundaram — Mon, 16 Jun 2014 19:48:10 +0000

"Systemd does not work in that paradigm, you cannot pull out a standard init and replace it with systemd without replacing a lot of unrelated items as well, nor can you replace systemd with a standard init"

Sure, you can. The so called unrelated things are all optional. That is how distributions were able to move to systemd incrementally.

Irrelevant is the word, unfortunately

Arker — Mon, 16 Jun 2014 18:52:16 +0000

"At the level of systemd/etc, there is no such thing as "wider *nix compatibility" -- every Unix, BSD, and even Linuxes were already incompatible."

That's simply not true.

Each distribution might use their own init but these are still inits - they do that one job, not everything else, and you CAN easily swap them in and out to replace each other - on slack for instance we have a custom sysV init (but with BSD syntax) but that can be swapped out for e.g. runit, or OpenRC relatively easily. Each of these init systems is different but each performs the same role, and can fit in the same spot in the system.

Systemd does not work in that paradigm, you cannot pull out a standard init and replace it with systemd without replacing a lot of unrelated items as well, nor can you replace systemd with a standard init. A large section of the architecture of the system has simply been replaced en masse, by something with a different structure, a fundamentally different design from the mature design we are familiar with.

And of course personal experience is not statistical data, but I dont see you producing statistical data either and I know a great many programs will compile just fine on various linuces and unices with no more effort than ./configure, and I think the first program I ever ran into that broke that expectation was Gnome. Certainly Gnome and systemd/CoreOS is the first major project I remember taking such an openly contemptuous view towards anyone not eating the exact same dog food they prefer.

So the way I see it, we have a great big *nix ecosystem that includes the BSDs and the Linuces and anything else that wants to be compatible, but the bigger players (Redhat and Canonical) do not want to be compatible with it anymore. So what we are moving towards is a three-way schism. Slackware, Gentoo, and OpenBSD at least, along with some hobbyist projects, will continue to be *nix. Redhat and Debian will become CoreOS, a mostly incompatible fork that will continue to consciously move in the direction of less compatibility every release, while Ubuntu will continue to flog their own versions of the same idea creating yet another mostly incompatible fork, also likely to evolve in the direction of less compatible each iteration.

If that's what they really want to do fine, but I prefer *nix and I suspect most of their users would as well, at least if they understood the question.

Irrelevant is the word, unfortunately

pizza — Mon, 16 Jun 2014 15:57:24 +0000

> Now at the same time they openly scoff at wider *nix compatibility and feel it would 'hold them back'

At the level of systemd/etc, there is no such thing as "wider *nix compatibility" -- every Unix, BSD, and even Linuxes were already incompatible.

Even at a higher level, often the only way to get any sort of compatibility between those environments was to install the GNU tools everywhere.

But anyway.

Irrelevant is the word, unfortunately

Arker — Mon, 16 Jun 2014 14:53:03 +0000

Irrelevant is a silly word here.

It's perfectly relevant to those of us that use it.

You demand 'relevance' in a form that is, really, irrelevant. Making it 'relevant' in the sense you mean would only make it worthless to the people who actually use and value it already.

I dont mean to call you out personally and would not have even commented but this same lousy logic over and over again, it's a common meme, and it's harmful.

Redhat has clearly staked out their own space, they want a vendor-specific OS that does things their way, and so they have ripped out a lot of components and replaced them with their own, incompatible ones. With systemd and CoreOS stuff they do not just, e.g. replace the init system with one more to their tastes, they actually make it a system that does a lot more than just init, takes over a dozen or more roles, and where before you had a dozen different roles each of which might have several compatible options, so they could be chosen individually and work together - now if you choose their option, your whole ecosystem of compatible alternatives is mooted, there is no more choice; CoreOS is the only way. (I am not saying it really *is* the only way but it seems designed to give that impression, and to discourage anything else.)

Now at the same time they openly scoff at wider *nix compatibility and feel it would 'hold them back' if they cared for it, so they dont. It's clear they think this is a winning strategy for them for some reason, I disagree, but it's their right to pursue it and I would not dispute that. But why anyone else is willing to play along is I will confess more of a mystery to me. As an end-user of Free Software and specifically of Free *nix I certainly dont see any of this as being in my best interest.

I dont think we can blame Gnomes problems on Redhat, Gnomes problems go too far back for that, but I think that they have a certain shared view of things between the projects, similar attitudes towards compatibility with the larger *nix ecosystem (both dislike it and prefer to fork "their" community rather than make any accommodation there) and towards users (welcome only if they know their place and avoid questioning sacred design decisions) and so on and that they wind up closely associated because of this, because they have similar viewpoints, values and desires, not because of any subterfuge.

Although at this point Redhat probably does have a lot of control, by virtue of being by far the largest contributor, there's nothing I have seen to suggest anything nefarious from that - it's more of a default claim that develops automatically because no one else cares.

Questioning corporate involvement in GNOME development

eduperez — Mon, 16 Jun 2014 07:12:50 +0000

> Interesting, seeing as it seems to be the opinion of some Gnome devs that full-screen should be the *default* for *all* apps ...

Perhaps you are confusing *full-screen* with *maximized*?

Questioning corporate involvement in GNOME development

russell — Sun, 15 Jun 2014 05:07:39 +0000

Did I say remove the coders. No. What I'm saying is that if you don't want to "fork" the users, then consult more generally. I don't have the time or inclination to fork anything. I have in the past bought GNOME into several companies, donated money, provided numberous bug reports, and even some fixes. Since GNOME 3 no longer meets my needs, I don't get involve anymore.

Questioning corporate involvement in GNOME development

N0NB — Sun, 15 Jun 2014 03:57:51 +0000

Seems that this is an upstream problem, not a distribution problem. If an upstream package isn't capable of providing a good user experience out of the box, then I find it difficult to fault any given distribution that does not go out of its way to do the work that upstream should have already done. However, it is a distribution's problem if their package is demonstrably worse than building from upstream's source release.

Do the Debian packagers make GNOME demonstrably worse, or are they not hiding the warts?

Questioning corporate involvement in GNOME development

vonbrand — Fri, 13 Jun 2014 15:55:12 +0000

Could you please point out the people Red Hat has hired specifically to scream louder than dissenters from the community?

Questioning corporate involvement in GNOME development

vonbrand — Fri, 13 Jun 2014 15:53:12 +0000

The mantra of open source has always been "she who does the work decides where we go," it is a fact that "corporate entities" are doing most of the work (i.e., look at LWM's kernel development statistics), so they get to call the shots. If you don't like this, get more involved.

History repeats itself

vonbrand — Fri, 13 Jun 2014 15:49:37 +0000

The funny thing is that the very same people railing against Gnome 3 were those who screamed bloody murder when Gnome 2 came out, and for mostly the same kind of reasons.

Yes, it did take me quite a while to become comfortable with Gnome 3 (no big GUI user though, mostly use it to handle my command-line-style utilities windows). But now when I start my netbook (can only run the fallback classic Gnome) it feels somehow archaic...

Questioning corporate involvement in GNOME development

pizza — Fri, 13 Jun 2014 12:55:53 +0000

> 1. Those who produce the code, control the direction, even if no one else likes it. Try swimming against that tide as a volunteer.

You are absolutely correct in that "those who produce the code, control the direction" -- but your solution to "I don't like the direction" is "eliminate the folks producing the code".

I have a very hard understanding how that can be considered progress.

If you don't like the direction the ship is sailing, fork the code and produce something better; But complaining about how you're swimming against the tide when you deliberately chose to do so...

Questioning corporate involvement in GNOME development

mathstuf — Fri, 13 Jun 2014 11:39:16 +0000

> Collaborate with volunteers

Check out the KDE SIG. There are Red Hat employees that work with volunteers very well there (at least).

Questioning corporate involvement in GNOME development

russell — Fri, 13 Jun 2014 04:31:04 +0000

Two things Redhat does to control GNOME and Fedora:

1. Those who produce the code, control the direction, even if no one else likes it. Try swimming against that tide as a volunteer.

2. Redhat also hires vocal people from the community to ride rough shot over any descenting opinions.

One thing Redhat does NOT do:

1. Collaborate with volunteers

Questioning corporate involvement in GNOME development

rahulsundaram — Thu, 12 Jun 2014 12:24:12 +0000

... which is why I noted earlier that this only seems that way if one leaves out all the nuaunces

Questioning corporate involvement in GNOME development

Wol — Thu, 12 Jun 2014 12:12:35 +0000

> those applications should not use full-screen at all,

Interesting, seeing as it seems to be the opinion of some Gnome devs that full-screen should be the *default* for *all* apps ...

Cheers,
Wol

Questioning corporate involvement in GNOME development

Wol — Thu, 12 Jun 2014 12:10:39 +0000

The problem with "working as designed" is that, in the opinion of many, it's the design that's broken ...

Cheers,
Wol

Questioning corporate involvement in GNOME development

eduperez — Thu, 12 Jun 2014 05:59:47 +0000

>> Once the GNOME developer community demonstrates that they actually know and what the users' preferences are

>How do you know? The basic responses you got are because we have not a good idea to figure that out. You take this directness and see it as arrogance, while that is not the case.

Well, could you please have a look at this bug:

https://bugzilla.gnome.org/show_bug.cgi?id=705177

You where told that a certain change broke full-screen for a number of applications (GIMP being one of them), and the immediate response was that those applications should not use full-screen at all, because that use case did not match GNOME's vision). A change, by the way, that tried to solve a cosmetic issue, and did not fix it but made it even worse, in my humble opinion.

Questioning corporate involvement in GNOME development

pizza — Tue, 10 Jun 2014 18:37:27 +0000

> Gnome-shell is pretty much the opposite of what I want my desktop environment to do - and I'm pretty sure I'm not alone.

And oddly enough, it's pretty much exactly what I want my desktop environment to do -- and I *know* I'm not alone in that.

For me, it was light-years beyond what G2 offered, even in its original 3.0 release.

Questioning corporate involvement in GNOME development

rriggs — Tue, 10 Jun 2014 17:32:52 +0000

Gnome-shell is pretty much the opposite of what I want my desktop environment to do - and I'm pretty sure I'm not alone.

No... far from it. But the GNOME developers choose not to see or hear the complaints. GNOME3 still pisses me off on a daily basis. It always seemed to me that the misguided designers that brought us the Gnome Shell disaster worked for Red Hat.

Those who do the work, chose the direction.

Tet — Tue, 10 Jun 2014 13:59:24 +0000

That's probably part of the reason why I run fvwm.

Questioning corporate involvement in GNOME development

johannbg — Tue, 10 Jun 2014 00:44:45 +0000

Interesting that you assumed I had already not considered that, based on one of our talks and what we both know so you should give me a bit more credit than that, but the fact is in the end of the day it's irrelevant since you don't put people with characteristics like Matt has shown into leadership positions so he never should have been on that list to begin with.

The possibility I did not take into account was that people that are behind this process within Red Hat did, since up to this point they have been smarter than this ( which indicates they might have been replaced ) so one can only speculate what went through Denise mind when she signed this off for the project and who managed to cloud her judgment since she should have stopped this nonsense from happening in the first place.

Questioning corporate involvement in GNOME development

AdamW — Mon, 09 Jun 2014 23:38:38 +0000

You could consider the possibility that any one or more of those folks was offered the FPL job but declined. It's not a job everyone wants to do. I know for certain that several people have been offered it and declined at various of the handover points.

(Note that I am speaking in generalities here; I have no specific information as regards any of those particular people. I'm just pointing out a possibility you seem to be overlooking.)

Questioning corporate involvement in GNOME development

jwarnica — Thu, 05 Jun 2014 20:26:31 +0000

Maybe "self fulfilling prophecy".

Fedora is, unquestionably, moving quite fast, and its base install thus has more bleeding edge packages not directly of interest to Gnome developers, but necessary for them. You *could* build the latest systemd on Debain, or just use Fedora. You *could* build the latest, I dunno, glibc on Debain, or just use Fedora. And working the other direction, if you just have (the latest) systemd, you just use it.

Questioning corporate involvement in GNOME development

johannbg — Thu, 05 Jun 2014 16:57:03 +0000

Since you've decided to try to back this up with the current election process in the project you might want to explain to the audience how large number of Fedora contributors actually participate in the election and how many of those are Red Hat employees backing up the next RHEL 8 vision which they themselves are working on so people can actually see how representing for the community those elections are ( which in turn will invalidate what you or anyone else that matter tries to justify anything based on the outcome of the project election process as well as highlight the fact that there is something seriously wrong with our election process since people from the community aren't participating enough in it )

And when it comes to FESCo and election, on numerous occasion while participating in the community I heard from several individuals that did not want to run for FESCo due to the fact there where always they same Red Hat employees hogging every seat ( Kyle cropping up to hold that pattern true these days ) preventing fresh perspective from the community or just even within Red Hat from taking place because people where afraid going against the stone age fractiont. ( which again just highlight the fact there there is something significantly wrong with the election process since there is not enough diversity in individuals nominating themselves to participates in various governing entities within the project. )

Alot of good thing he did you say like backstabbing Lennart or when he tries to force me to adjust my cron to time feature migration to accommodates his cloud /container vision then hijack my cron to time migration feature proposal which does not even make sense since to be able to implement what he suggested we would have had to create several new targets and at that point you are forced to write new proposal and we could just as well migrate everything to timer units, which we technically cant at this point and probably never will since cronie and timer units aren't interchangeable components. They complement each others shortcoming.

Every time I was going to confront him on certain things he said on that ticket or even trying to understand why he was so obsessed with this he conveniently was absent from the FESCo meeting.

The fact is that anyone that does not have shit for brains has spotted far greater leadership material in Stephen Gallagher who has been part of the new future vision from the get go while showing true leadership skills while doing so, If the underlying political move for Matt's choosing boiled down to support the RHEL 8 next release as in the.next and wg proposal.

If that was not the reason for Matt being chosen you have much more capable people leading the project both within Red Hat and outside it with women candidates taking precedence over male once ( With Máirín probably top on that list after years of dedication to the project or Ruth ) .

In the end of the day what Matt has demonstrated is that he cant be trusted for anything else than leading his left foot in front of the right.

Questioning corporate involvement in GNOME development

rahulsundaram — Thu, 05 Jun 2014 16:30:18 +0000

You might find this post from today interesting

http://afaikblog.wordpress.com/2014/06/05/notify-me/

Questioning corporate involvement in GNOME development

Felix — Thu, 05 Jun 2014 16:09:54 +0000

> Honestly, as a GNOME developer, I admit search in Nautilus is really bad.
> I'm not sure we need to go back to type-ahead find, but I think that was
> far better than what we have now.

I totally agree. Advanced search (e.g. full-text search, additional filters) is nice but the whole use case of quick keyboard-assisted navigation just went away.

> Dealing with lots of user feedback is difficult, particularly when it
> conflicts with the design vision, but I've seen many cases where it has
> influenced the direction of GNOME software (e.g. the wired status
> indicator, or the ongoing push to restore terminal transparency). The
> biggest limiting factor is often developer resources: if I want to fix
> Bug A or implement Feature B and a user wants me to fix Bug C and
> implement Feature D, I'm probably going to fix Bug A and implement
> Feature B.

I can sympathize with that opinion. However when you're changing something in major ways (and criticism is already voiced in blog comments when the change was presented) I think a developer should be prepared to deal with fallout instead of just moving on.

> I wonder what you dislike about notifications, though: I find them
> informative yet unobtrusive.

First of all I think they are too small (just being centered at the bottom). I didn't see a way to see multiple notificatons at once - some things might be more urgent than others but I don't want to "loose" the one on "top". So a kind of history would be good.

Then I have issues with the kind of notifications which are provided. To me this tied into the "systray" problem. I'd like to have some "notifications" which never expire (e.g. new IM message) - similar to jumping icons in the MacOS dock. And some notifications just bother me and I want to ignore them ("maybe your printer is not connected" - when I just started it and I already know it'll need a few more minutes until it configured it's network interface).

Questioning corporate involvement in GNOME development

pjones — Thu, 05 Jun 2014 15:33:27 +0000

If you think it was for a huge of luck that he was put by Red Hat in the project leader chair you are wrong.
...
The project is changing direction from a generic distribution to a targeted distribution without the people behind it thinking things thoroughly through, leaving contributors scratching their heads trying to figure out how it affects them.

The directional change in Fedora has been led almost exclusively by people on FESCo, and everybody involved was elected in a reasonably free and fair way. Everybody involved has also been elected or re-elected since we've started going down the current path.

mattdm has been a large and incredibly positive part of that. It's completely unfair to him to to suggest this is somehow wrongdoing; clearly he was elected to FESCo by other Fedora contributors that liked what he was doing, and the same is true of the rest of FESCo.

While I'm in no position to know the decision making process to choose the FPL, it wasn't surprising (or "huge of luck") that he was chosen — he's done a great job, and people who take leadership roles and work well with others are the people who get selected for other leadership roles. Aside from that, the role of FPL has little direct impact on technical direction of Fedora. That's chosen by FESCo, in coordination with the Board.

Questioning corporate involvement in GNOME development

mcatanzaro — Thu, 05 Jun 2014 13:29:46 +0000

You'll probably be using Classic Mode, the default in RHEL 7, which is intended to cater to users who preferred GNOME 2, with a menu for selecting applications, minimize buttons, etc. (I'm pretty sure Classic Mode is an example of development driven by Red Hat's corporate interests. I don't think that's a bad thing.)