Red Hat's New Graphics Engineer Is A Longtime AMD/ATI Linux Developer

[ssokolow]

ssokolow You can’t demand respect. You can’t demand cooperation. You have to earn it through hard work and offer something in return.

Yeah and, from what I've seen since the early 2000s when I got into Linux, the GNOME devs are the ones who have trouble understanding that.

[timofonic]

the way it handles variables: You'll have to elaborate on this. Aside from being local by default and having a global statement (basically the same as all other non-shell languages, like C and Rust), Python variables behave pretty much the same as shell script variables if you write shell-like Python code.

(Unless you mean quoting and variable substitution. That is different because, again, shell scripting is the exception and Python follows languages like C and Rust. However, if that is what you're hung up on, I can suggest some lesser-known stuff I think you'd appreciate.)

and the self.something stuff: There's no need to use classes if you're just treating Python as a better shell scripting language.

I'd be happy to discuss further if you're interested.

I'm not the original author of the post, but I'm interested on all of this.

I want to understand that, it could help me to understand programming all better.

Are there comprehensive programming language theory for even novice programmers? Why do they use certain syntax, some background history, the evolution of all these features, explain the programming language families, etc. Even better if it's in books, of course.

[ssokolow]

ssokolow Have you considered the possibility that your attitude is the problem?

Because the problem doesn’t seem to exist at Mutter.

What attitude? I'm talking about being a spectator to public interactions between the GNOME and KDE teams on places like mailing list archives and blog comments, as well as exchanges in the form of blog posts responding to other blog posts.

I just watched without interacting and I came away with a firm sense that the GNOME devs were consistently the less reasonable, more psychologically immature parties in those interactions with less of a desire to back up their design decisions with reasoned arguments.

(Note that I'm using comparatives like "less" and "more". KDE also suffers from development according to The CADT Model whenever they do a major version bump.)

[ssokolow]

ssokolow I watched the same interactions and came to the opposite conclusions. As I see it GNOME doesn’t need KDE. So why engage? If KDE really wanted cooperation then they would seek to share more code.

Where do you think things like D-Bus and the various other FreeDesktop.org projects and standards came from? FDO is a forum within which KDE, GNOME, Xfce, et al. try to find points of agreement.

Also, it takes time and effort to change a history that revolved around GNOME categorically refusing to add C++ dependencies... though I am hopeful about the prospects for Rust. Both the GNOME [1] [2] [3] and KDE people seem to be enthusiastic about incorporating Rust into their codebases.

[ssokolow]

I'm not the original author of the post, but I'm interested on all of this.

I want to understand that, it could help me to understand programming all better.

Are there comprehensive programming language theory for even novice programmers? Why do they use certain syntax, some background history, the evolution of all these features, explain the programming language families, etc. Even better if it's in books, of course.

Unfortunately, my knowledge tends to be piecemeal stuff gained over the years through lurking and googling.

For example, I know that Python uses a colon at the end of statements which begin blocks (eg. if/else/for/while/etc.) because they actually did user testing and found that it reduced confusion during the learning process. I learned that from a blog written by Guido van Rossum, The History of Python, where he's gone into detail on the genesis of various language characteristics and features.

The Old New Thing (the blog of Raymond Chen at Microsoft) is another good place to find stuff. Most recently, he wrote a post about a quirk of the Win32 API which cites a very approachable article on fibers (stackful coroutines) and the technical reasons that programming languages other than Go shy away from them as a concurrency model today.

Likewise, I hang out on /r/rust/ and sometimes, people put up things with useful insight into programming language design like:

• The story of ispc ("Auto-vectorization is not a programming model")
• From Imperative to Pure-Functional and Back Again: Monads vs. Scoped Continuations (which builds on a talk it embeds named "Please Stop Polluting our Imperative Languages with Your Pure Concepts")
• code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care
• CppCon 2014: Mike Acton "Data-Oriented Design and C++",
• (Not to mention the interesting talks that show up in YouTube's related videos sidebar when you're watching such videos.)

Also, it's not specifically about programming language design, but I'd still recommend the free non-print edition of Eric S. Raymond's The Art of UNIX Programming for understanding the mindset which informs such things. (It also cites worthwhile stuff like The Rise of "Worse Is Better" by Richard Gabriel.) ESR also maintains a fascinating FAQ named Things Every Hacker Once Knew which covers things like why the 7-bit ASCII table is laid out the way it is and why octal (base-8 numbering) was relevant enough for programming languages to support octal literals alongside hex literals.

[ssokolow]

Ping. Another unapproved reply.

[ssokolow]

ssokolow c++ is far from ideal. Qt otoh is categorically unacceptable.

CLA is unethical and Qt APIs are dictated by people outside the community. So that’s a 100% nope. So how is KDE going to solve that problem?

When did I ever talk about Qt? It's hard to craft Google keywords for stuff from that long ago, assuming it's still up, but I'm remembering a specific article/blog post written by a GNOME developer that went into exacting detail on why C++ (not Qt) was unacceptable as a basis for GNOME or its dependencies.

(Now, admittedly, some of those were reasonable-sounding arguments at the time, which more recent GCC versions have addressed, such as claims that GCC's implementation of various C++ constructs imposed an unacceptable base start-up time that they didn't want added to their applications, but the point remains that they categorically refused to consider components written with Qt-less C++ purely because they were written in C++.)

Conversely, I've read responses by GNOME developers to complaints about how the GTK+ 3.x widgets were diverging from GTK+ 2.x (often in trivially patchable ways), arguing that, with GTK+ 3.x, their primary focus is GNOME and they're not going to take responsibility for addressing the needs of the ecosystem that evolved around GTK+ 2.x. I'm not surprised that KDE developers prefer to write their own componentry and LXDE developers merged with Razor-Qt developers to make LXQt.

If the GNOME developers are convinced that KDE componentry is ideologically unacceptable and, at the same time, are unwilling to provide components that meet the KDE developers' needs, of course there's going to be an impasse... in fact, there's going to be the same impasse that has existed since the decision to start writing GNOME.

(And I don't blame the KDE developers if they would prefer to stick to their existing C++ codebases rather than familiarizing themselves with C codebases that need to be patched up to parity on the features they use and which, historically, suffer from KDE and GNOME having divergent enough use patterns that both seem crashy to each others' user bases due to lack of testing.)

[tildearrow]

can someone explain to me why 99% of all posts here in this thread are off-topic ?

Because somebody talked about Qt, and people liked the topic.

This happens often at Phoronix... The AMDGPU DC thread years ago turned into a car engines thread a few pages later, and a power management thread turned into a conversation about climate change.

[bridgman]

@IBM/RED-HAT can we please have a Open-Source GPU without Closed-Source firmware?

You know what would be an interesting benchmark... going back to really old GPUs (starting with Rage Pro, our last GPU without loadable microcode) and forward to something like RV670 (IIRC our last GPU with only CP microcode, not sure about RV740) to see where they start getting usefully faster than SW rendering on a no-loadable/patchable-microcode CPU.

EDIT - nope, looks like 5xx was the last generation with only a single CP microcode image - with 6xx we added PFP and RLC as well.

[MrCooper]

Michael just for the record, I've been working on open source graphics drivers for going on two decades. Initially as a hobby while I was studying and working on fglrx for ATI (for one year), then as a full-time job since 2006.

It literally means there are *less* developers working on AMD drivers now. He even wrote "I'm hoping that someone from my former team at AMD will step up to maintain this driver" in the announcement, indicating he won't continue to work on it at Red Hat and that this driver is now unmaintained.

That's not really what I meant, but I'll definitely be putting less effort into it than I did before.