If your theme engine is as simple as Raleigh, then the chances of crashing applications because of a bug in the theme are smaller. Sadly, most (if not all) theme engines were far, far more complex than Raleigh.
We have bug reports coming especially from people using the Oxygen theme, which had a tendency to (against all recommendations) poke at the widget structure behind the style contexts because what could possibly go wrong.
Given the ability to inject random C code into applications that do not expect that, people will abuse it; hence the switch to a pure declarative language like CSS to describe the aspect of widgets. Your app may look like crap, but it won't crash because of that.
> A cynic might say that they decided to scrap everything and start again
and not only this cynic would be wrong, but he would also be full of crap, because it's such a trivial thing to check in the public repositories, public mailing list archives, and public bug tracking system.
but, obviously, crapping on a bunch of volunteers trying to work on the project they like is easier.
no, it wasn't - mostly because of political bullcrap coming from the "I'm purer than thou" crowd. obviously, the biased perception that gnome was using C# exclusively was also due to the same crowd.
this also led to the C#/mono platform lagging behind, so that these days writing gnome apps in C# means using deprecated libraries, which is unfortunate.
the usual ridiculous trope that "if only we had a single $PROJECT all the people working on the current competitors would work on $PROJECT instead and everything would be great" is enough to discount this whole lot of drivel.
I use a wiki for strawman feature proposals and for the roadmap; each entry in the roadmap gets a bug in Bugzilla, and all milestones/releases get a tracking bug depending on the bugs that should go in. milestones/releases are every six months, so there's an inherent deadline in there.
it's an open source project, so this not only helps me having a clear idea of what I'm meant to be doing, but it also helps others to contribute to it, by giving a precise idea of what can be worked on at any given time.
you use that word. I don't think it means what you think it means - or that it has the implications that you think it has; I am a misanthrope, but that does not influence my reaction to the floor plan of the office I work in. actually, I'd most likely go insane in a cubicle farm. there are ways around to signal that you don't want to be disturbed in an open space.
given that you write:
> I don't trust most people. I don't expect them to trust me.
followed by:
> The social bullshit and paranoia are intolerable.
I do assume that you're referring to your own paranoia, here...
> [snip the rest of the workplace description]
... which leads me to think your problem is not the office planning, or your social issues (with or without medications): I think it's your current job. my entirely serious suggestion is to either change it, or ask to work remotely, if you still think that you'd enjoy it more (and if they don't allow remote work, I'd seriously consider changing jobs anyway).
> I don't get all this C++ hate from people that has never even used it.
wrong. I use it every day, on a fairly large code base.
obviously, for portability reasons, nobody working on the project is allowed to even think about C++11, as well as other headache-inducing features - and that includes a fair chunk of the standard library.
a three lines program generates 95 lines of error messages; let's throw a template into it, so that it goes up to 112 lines, but look: at the beginning you'll see the error we added!
coupled with the: "To be fair, this doesn't entirely replace decltype. auto doesn't perfect forward. But it seems to work as expected, most of the time" it goes a great way to instil me a sense of safety.
not.
that post should be taken as an example of why C++ has become a liability, and the day won't come too soon when this joke on the whole industry finally gets dumped like COBOL in the nearest ditch, along with the corpses of all the projects that made the mistake of actually using it.
if it were a living thing, I'd shoot C++ in the face to put it out of its misery.
the data collected from the history is not associated with the user account, only analysed; and the plugin/extension respects private/incognito mode, according to the privacy policy: https://lumi.do/about/privacy
the issue is not (only) having distasteful content; the real issue is censoring links to content that embarrasses redditors, like the Gawker outing of the reddit creep, in a shockingly hypocritical display of a double standard.
you cannot "uphold the principles of free speech" by keeping creepy content under the "it's not illegal" moniker, and at the same time censor the outing of one of the moderators of said content - another perfectly legal action.
not every video frame is encoded in RGB. actually, very few transports use that.
the in-memory layout of a YUV-encoded frame is different than the one of a RGB one. it needs conversion, which implies an intermediate copy, as well as traversing a buffer that can go up to 1080 rows.
most video players (and Flash on Windows and MacOS), these days, use shaders and multi-texturing to do that conversion on the GPU; it removes a copy, because you just push the YUV frame as it is to the GPU - and your CPU can go back to a low C state.
I think Flash on Linux does this as well, on nVidia: the blog post linked is from 2010. the way Adobe detect capabilities is, in itself, hilariously bad - instead of checking the GL required GL extensions like any normal people, they do a check on the GL vendor string. the Mesa guys pointed that out, but I doubt they ever received a response.
"enthusiasts" are not just "computer enthusiasts"; I want to excite users and make them care about Gnome - and I want to get excited, interested users, to contribute back to the community by making it dead easy to do so: create interesting apps, create documentation, create content, organize and attend events. in Gnome we have amazing outreach programs that give us new contributors every year - and most of them stick around, because we're a cool (even if sometimes too much introspective) community, where people care about people first, and software second.
I don't see Gnome as suffering from "Mac-envy" - mostly because everyone envies Apple's profits and margins, if not their user share; I mean, who wouldn't envy Apple. we don't have the resources to do multi-year usability studies involving tons of people; and we still lack the tools like Telemetry to get (consensual) user feedback. so we need to take inspiration in our designs and plans from stuff that others are doing, as well as doing our own thing. I mean, the GNOME 3 shell overview is basically Mission Control from Lion - but we designed it in 2008, well before Lion screenshots were released or leaked to the press; who copied who? ;-)
competing with Apple is also a false goal; we want to keep the keep the users free, as well as providing them tools and an environment that allows them to achieve their goals in a simple and delightful way. that will put us up against Apple, and Microsoft, and Samsung, and basically everyone. it never stopped us for the past 15 years, I don't think it will stop us now.
as one of the two people mentioned by name in Benjamin's blog post, I'd like to point out that I didn't "leave GNOME" (to work on other stuff).
I am still involved in the community, I am a director of the foundation's board, and I'm still working on Gnome projects in my spare time - which is actually easier these days since I moved from intel to mozilla.
I'm typing this from GUADEC 2012, in A Coruña; the conference is absolutely delightful, there's a lot of talks about direction and future involvement, and everyone here is really excited about moving Gnome forward, as well as regaining the enthusiasts market.
We have bug reports coming especially from people using the Oxygen theme, which had a tendency to (against all recommendations) poke at the widget structure behind the style contexts because what could possibly go wrong.
Given the ability to inject random C code into applications that do not expect that, people will abuse it; hence the switch to a pure declarative language like CSS to describe the aspect of widgets. Your app may look like crap, but it won't crash because of that.