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

[johannesburgel]

On the surface this sounds good. It is just the realization that AMD drivers “need work” that has me a bit worried. The best out come here is that we have more developers working on AMD drivers than before.

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.

[gmturner]

I really like how this article opted not to sensationalize or sex up its subject matter with military or crime metaphors, click-bait headlines, and/or superfluous normative language. Just the facts, man!

[wizard69]

I've never found Python that easy to get or I've just looked at the wrong code examples, but something about the way it handles variables and the self.something stuff never quite jived with me. Every time I've ever tried to learn Python I get to around a chapter 3 or 4 in a guide and get discouraged by thoughts of "I feel like this variable system is fighting against me." and "Shouldn't I focus on something "better" like C or Rust?".

Python has its issues but it really hasn’t had any decent competition thus many are indoctrinated into its use. However I see real potential in the likes of Swift and maybe even Rust to replace Python as a scripting tool .

it will take awhile for the entire community to see it but I think Python has peaked. The only things holding up Swift or Rust is the large body of software that Python offers , all nicely packaged.

[Naquatis]

Please Red Hat / IBM can you fix Mesa OpenCL >= 1.2 for us simple AMD GFX users? =)

[Marc Driftmeyer]

Hopefully for him that job comes with some IBM stock options

Hopefully for me Red Hat is interested in GPU control panels

I first wrote that as Rad Het and thought y'all'd get a laugh out of my dyslexic vowels

Does anyone know if the book "Bash and QT for GUIs for Artards" exists? I'd like to read that.

AMD stock options have far more upside than IBM.

[geearf]

No problem. You may also want to check out two other tools usually already installed on systems with KDE stuff installed:

• kioclient allows your scripts to perform operations like ls, cat, copy, move, and remove on URLs in a network-transparent manner via the kioslaves system. (Wanna write scripts that work just as well over SSH or Samba as locally? Pair it with kdialog's --getopenurl and --getsaveurl)
• qdbus is a command-line D-Bus client built around Qt's D-Bus client abstraction that has the best support for complex data types of any shell script helper I've tried so far. (Not perfect, but pretty good.) It's also second only to qdbusviewer for interactively exploring your system's available D-Bus APIs using introspection.

kioclient and the precursor to qdbus (the equivalent tool for DCOP, KDE 3's ancestor to D-Bus) are two of the big reasons I chose KDE 3 when I came to Linux from Windows XP.

While not KDE-specific, another good little-known shell-script helper is the xdg-user-dir command for querying ~/.config/user-dirs.dirs which defines where those equivalents to things like "My Documents" actually live. (eg. MEDIA_ROOT="$(xdg-user-dir MUSIC)")

I know about qdbus, I use it to log out when I am unable to do so by the menu
I've used it for more complex things in the past, but I am not sure which anymore.

I did not know about kioclient that looks indeed interesting!

I don't remember why I used KDE 3 when I switched, I don't think it had anything to do with any of this, it probably just looked good to me and I've stuck with it since.

Thank you for this detailed post!

[ssokolow]

bullshit

neither one supports this bullshit argument. in fact, both of them contradict it

The LWN article literally contains this quote (emphasis mine, to show the connection):

For example, he said, should a GTK+ app running on KDE be expected to look like a native KDE app? His answer was that GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second. The project has tried to keep cross-platform compatibility, he said. For example, the same menus will work in GNOME, Unity, and KDE, but the primary target platform is GNOME.

GTK+ 2.x and Qt can feel very harmonious together. The direction GNOME is taking GTK+ 3.x makes it feel more and more alien in a Qt-based desktop, so it makes all the sense in the world to start replacing GTK+ bits and bobs like Zenity with Qt ones to ensure everything feels consistent on a Qt-based desktop.

Hence my "Be careful what you wish for". If you say "Do it our way or leave", don't be surprised when people start pouring effort into leaving. It's my understanding that the newest version of OpenMandriva Lx has Qarma packaged as the default provides: zenity and their Qarma package produces a zenity symlink to complete the process of making it a drop-in replacement. (A name that's a play on the word "karma" indeed.)

[ssokolow]

I don't remember why I used KDE 3 when I switched, I don't think it had anything to do with any of this, it probably just looked good to me and I've stuck with it since.

I did initially choose KDE 3 because it looked and felt more appealing, but I quickly got sucked into the question of "Why are there two of these things and what's the difference?" which led me to things like kioclient.

Thank you for this detailed post!

No problem.

[ssokolow]

Like how x=20 can be used for one thing and then changed to x=steve for another thing and if you miss the one or two lines where that change happens it just makes it confusing to read a random snippet of code. I know that shell can be done that way, but that style just isn't anywhere near as common like it seems to be with Python. One variable for one thing is how I like to roll whereas Python likes variable variables and it seems that a lot of guides teach around that coding style.

Probably because they want unused memory to be freed as quickly as possible to keep memory use down and foo = open(foo) is more concise than this:

foo_path = "string"
foo = open(foo_path)
del foo_path

(CPython, the most common implementation of Python, uses reference-counting for memory management, which means that detecting that "nothing's using this anymore" doesn't have to wait for a garbage collector pass to run to be detected.)

Anyway, I can respect "Python programmers are too eager to take advantage of dynamic typing" as an issue... though Rust does allow that kind of variable shadowing despite its static type system and iteration via recursion in pure functional languages like Haskell could be said to have the same problem.

    let foo = "Hello";
    let foo = foo.len();
    // The second "let" signifies pointing the name "foo" at new
    // memory, rather than changing what's in the existing memory.
    // If nothing else has a reference to the first "foo", it'll be freed.

I've always been drawn towards trying to learn functional languages like Rust and Haskell due to how static typing isn't as confusing to me.

Rust is a multi-paradigm language, just like Python, and good modern Python encourages a more functional style. That's why I found it easier to learn Rust than a lot of people coming from OOP-heavy languages like Java.

You're X, you currently mean 20, you're an unsigned 8bit integer because my fan speed is calculated with 0-255, you'll always be that way, and you will never be the value steve because steve is not an unsigned 8bit integer nor will you, X, be used for anything else because you're the f'n fan speed. That I get. That makes sense to me. I feel that Godot's statically typed script would be better and easier for me to pick up over Python even though they look and behave similar enough.

Again, something I can respect. The whole reason I'm interested in Rust is that it's easier to get a high degree of confidence in the correctness of your code via a powerful type system than via automated testing.

At the moment, I don't have time to continue polishing it, but here's my attempt at a starting point for using Rust in place of Python for writing shell script-y things that need stronger guarantees.

Python's still a good thing to know for stuff too quick-and-dirty to use Rust though. I have my Vim set up so I can open a fresh .py file and type "boiler\c" to get this starting point. (Feel free to use it under whatever license you want. GPLv3 is just my default.)

As far as the self stuff, I've always liked to use functions in scripts when possible which seems to be similar to how classes behave in higher level languages...lower...I'm confusing myself there and probably completely wrong about that assessment, but that seemingly liberal use of self.something combined with the above about variables just never made me just "get" it.

I normally use functions too. I only really use classes with member functions when the alternative would be to pass around an unwieldy number arguments.

Also, higher vs. lower is somewhat orthogonal to the presence or absence of constructs like classes. It's a continuum based on how much the language exposes you to implementation details that are irrelevant to the domain logic. (eg. stack vs. heap and the number of bits in an integer variable.)

A low-level language gives you that power, at the expense of having to deal with it. A high-level language abstracts that away so you can better focus on your domain logic.

(The number of bits in an integer variable is an implementation detail not connected to domain logic. The domain logic countetpart is the fine-grained support for declaring new subtypes with constrained ranges that you see in languages like Pascal and Ada.)

For me, Python is designed to be so simple that it's confusing if that makes sense.

Would I be correct in framing your issue with Python as "In order to allow programs to remain simple to write as they get more complicated, Python incorporates some constructs that can be difficult to get used to."?

Again, you don't need to know everything about Python to use it as a replacement for shell scripting. Hell, I've been using it for over 15 years and I still haven't found a good reason to sit down and wrap my mind around metaclasses... but Django's database abstraction wouldn't be possible without them.

From an outside looking in perspective, comments from people who know what they're doing writing things like "Yeah, Python is fine for a simple prototype, but the second I go from prototype to program I'll pick a better language" aren't very encouraging words to read.

It's more that, for all that it's so comfortable and elegant by dynamically typed language standards, Python is still a dynamically typed language.

If you're familiar with regular expressions, think of Python like regular expressions. You'd be a fool to write a parser from scratch for a quick little one-off task that you might need to run again occasionally, but you'd also be a fool to use regular expressions for a task where a proper parser is the right answer.

Really doesn't help when the Phoronix Anti-Rust brigade makes Rust seem more appealing than Python from a beginners perspective. It's like, so you're telling me this language has a similar centralized repository of nifty stuff like pip that all the Python people love and the compiler tells me when I'm being retarded while trying to help me fix the problem and those are supposed to be bad things? Really?

Yeah. The best way I can explain it is that Rust forces you pay now to avoid pain later... but, in some cases, the pain you're paying to avoid would never have been a concern anyway.

Aside from that, Python has built up an ecosystem Rust doesn't yet match, including things like Qt bindings and Django's ecosystem... so I find it's good to know a language like Rust, a language like Python... and something like rust-cpython for when you want to combine them. (eg. having a robust, high-performance backend written in Rust with a Qt frontend written in Python.)

[ssokolow]

Paging Michael. Unapproved comment in aisle 9.