GNOME Shell + Mutter See Changes For Tracking Software Rendering, VNC To Toggle Animations

[dragon321]

r/kde: 40.7k members

https://www.reddit.com/search/?q=kde

r/gnome: 33.8k members

https://www.reddit.com/search/?q=gnome

r/windows: 131k members

Are you sure reddit is good source for measuring popularity?

[Nth_man]

> Are you sure reddit is good source for measuring popularity?

In the same vein, are you sure it isn't? :-) It's sure that it's not a Windows-centric place :-). Some things depend on which values are compared.

The latest from https://www.linuxjournal.com/content...op-environment :
KDE: 35%
GNOME: 20%
Xfce: 15%
Cinnamon: 11%
MATE: 7%
Other: 7%
Unity: 3%
LXQt: 1%

[ssokolow]

Sorry, but the best part of that book was the anti-foreword, written by Dennis Ritchie himself :-P

I agree that the book is written in a "frustrated rant" style which gets people's backs up but, to be fair to it, a lot of it was true about certified UNIX implementations back in 1994 when it came out. ESR's The Art of UNIX Programming and Keith Packard's A Political History of X both agree on what a mess vendor competition on some fronts combined with vendor apathy on other made of things. (Imagine an ecosystem whever every single vendor was Canonical and, by the time they gave up on things like Upstart and Mir, Linux was coming out and irrelevance was inevitable.)

If The Art of UNIX Programming describes the beauty of the UNIX design as a goal, The Unix Hater's Handbook describes how horrendously vendors were botching the implementation of it in 1994. This snip from a quoted e-mail on the topic of platform compatibility really was fitting:

The evaluation process consisted largely of trying to get their test program, which was an early prototype of the product, to compile and run on the various *nixes. Piece of cake, sez I. But oops, one vendor changed all the argument order around on this class of system functions. And gee, look at that: A bug in the Xenix compiler pre-vents you from using byte-sized frobs here; you have to fake it out with structs and unions and things. Well, what do you know, Venix’s pseudo real-time facilities don’t work at all; you have to roll your own. Ad nauseam.

I don’t remember the details of which variants had which problems, but the result was that no two of the five that I tried were compatible for anything more than trivial programs! I was shocked. I was appalled. I was impressed that a family of operating systems that claimed to be compatible would exhibit this class of lossage. But the thing that really got me was that none of this was surprising to the other *nix hackers there! Their attitude was something to the effect of “Well, life’s like that, a few #ifdefs here, a few fake library inter-face functions there, what’s the big deal?”

Yes, there are some bits that I disagree with (eg. that the brevity of commonly-used commands like "rm" and "mv" is too cryptic to be acceptable), but, in general, it was right.

• At the time, shells didn't ask "Are you sure?" if you accidentally lifted Shift a moment too late and typed rm *>o rather than rm *.o (They blame it on programs being unable to access a raw form of the command line to implement their own "Are you sure?". I'll have to disagree with them on that when they bemoan not forcing applications to share a common preprocessing layer with termcap and curses.)
• At the time, UNIX filesystems also didn't support anything like snapshotting or journalling which might mitigate that by providing a command-line analogue to the Recycle Bin.
• This was back when people still used csh. 'nuff said.
• Unices were a horrendous mess of different argument styles before almost everyone standardized on following GNU conventions. (You can still see that in the single-dash long options used in X.org programs.) That's actually one of the areas where it'd have been interesting to see
• This was before using -- for "no more options" took off, so - could mean "stdin/stdout as a pseudo-filename", or "no more options" with no reliably consistent way to tell other than reading the man pages.
• It is a reasonable complaint that, in the absence of ubiquitous and standardized argument parsing libraries, there's no consistent way to escape filenames beginning with dashes. (./ requires you to detect absolute vs. relative paths while -- is parser dependant.)
• GNU error messages tend to be much less confusing than the examples they gave for the same situations.
• The cat - - - example they give, which hints at "Ctrl+D three times" to get your terminal back suggests that Ctrl+C was less robust back then.
• It's a legitimate complaint that not all shell bultins have manpages and it's never clear to a novice what is or isn't a shell builtin.
• Even GCC is dumb enough to blank out your source code file if you mistakenly type cc -o hello.c hello and both files exist.
• tar: Cowardly refusing to create an empty archive is a GNU invention to address one of their complaints about how easy it is to accidentally back up nothing.
• Back when people were using RCS, you could accidentally type indent when you meant ident and clobber a non-C file and, guess what. When I just installed and tested it now, the modern version of indent happily mangled an extensionless Python file even as it spat out error messages.
• GNU's info system is essentially the answer to their complaints about the limitations of man pages and remember that this came out the year before people outside academia even became aware of the Internet.
• From what I've seen, early 90s commands did have godawful equivalents to what GNU exposed as --help
• Two of their chapters are about sendmail from before it gained support for a sane config file syntax, and Usenet, which wound up withering away to a niche partly due to the shortcomings they point out. They're also from an era when UUCP was still in use... something infamously difficult to configure.
• It's perfectly reasonable to complain that termcap support had to be linked into each application rather than being an OS-level abstraction which behaves more like what GNU Screen does... especially if you've experienced such a design elsewhere on other systems. They're also talking about curses, not ncurses, in the pre-Unicode days when curses applications either couldn't or wouldn't use box-drawing characters.
• They had to fight with a bunch of different terminal hardware, while we have it easy with a handful of software terminal emulators, all VT100-compatible aside from the mechanisms for accessing more than 16 colors and, indeed, those are still a pain to get working reliably. (urxvt 88-color mode? xterm-compatible 256-color mode? True/hex color mode? I have actually had an experience like theirs where I just had to hard-override the terminal type in my GNU screen config to get things working locally.)
• Their biggest complaint about X11 is the same complaint people had about Emacs. In 1994, it wasn't reasonable to try to compete with Microsoft Windows's optimized design incorporating assembly using a network-transparent C system. (As they say "X has had its share of $5,000 toilet seats—like Sun’s Open Look clocktool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn’t have enough to tell you the time. Even the vanilla X11R4 “xclock” utility con-sumes 656K to run. And X’s memory usage is increasing.")
• They're talking about X11R4. I started using Linux with X11R6 and, coming from Windows, it was still shameful what an annoyance it was to get it configured properly.
• They're talking about a world with multiple competing proprietary X distributions, rather than everyone sharing X.org. Imagine every complaint you have about the nVidia binary driver turned up to eleven.
• This is back before GTK+ and Qt, in the era when Motif was trying to be a dog-slow clone of Windows widgetry.
• The design they propose for sanely distributing the workload between client and server is now what we use... download JavaScript and/or WebAssembly into a browser so the client/server split can be decided on a per-application basis.
• This was before ssh -X for X forwarding. Try doing it manually some time without the "example" section of the modern xauth manpage.
• This was when applications were customized using xrdb. As someone who's used things like Tk, xterm, and urxvt, I can personally attest to the complaints they have about it.
• This was before GTK+ and Qt got fed up and just started doing all their graphics primitives client-side and pushing pre-rendered pixmaps to the server for display.
• This was back before you could just assume that Python would be installed everywhere if you wanted a "shell scripting" language that was actually portable and had sane syntax. (I've tried writing shell scripts that are portable to GNU-based, busybox-based, FreeBSD, OpenBSD, and MacOS systems. It's a lot harder than it looks at first glance.)
• Again, this was back when people still used csh. 'nuff said.
• They make a good point that shell scripting locks implementation details of a command's command-line output in as part of their interface.
• Modern find has -L. Try to empathize with them for having an archaic version of find that simply will not follow symlinks no matter how many goats you sacrifice. Plus, find is a mess, interface-wise. That's why fd got written.
• If you don't think programming C without a full-blown IDE to try to patch up its deficits is an exercise in masochism, I can't help you. I just wish I could show them Rust and say "Eventually, a language will start to take off which addresses your list of complaints."
• They're people coming from languages like SmallTalk and looking at C++. What did you expect them to think of its take on object-oriented programming? It's nothing but leaking abstractions piled on leaking abstractions.
• They're talking about UNIX systems from a time when UNIX was not the uptime king but more the Windows 95.
• I vaguely remember how much manual tuning, configuring, and babysitting Linux needed around the turn of the millennium when I started playing with it, and it was still an "at least it's not proprietary UNIX" situation.
• They're from an era when backups really were that bad. Tar was useless and dump was disruptive... to the point where they quote an e-mail asking for resubmission of all 4BSD bug reports since January 1991 because they lost them. Likewise, have you ever had to work with a system so braindead that partitioning tools allows you to accidentally create overlapping partitions?
• This was before journalling filesystems. I vaguely remember what a hassle ext2 was, and that was better than what they had to deal with.
• regular vs. root, plus SUID (and nothing else) is a pretty braindead security model when you think about it.
• Canyou fault them for complaining about the lack of an LVM analogue?

The list goes on and on. Don't judge UNIX back then by Linux now... or even Linux around the turn of the millennium.

I will admit that I disagree with them on the matter of how cd and symlinks interact. It would make no sense for .. to take you down a route you didn't come up, just because you crossed a symlink somewhere along the way.

[pal666]

Polls are a more accurate representation of what people actually like and use voluntarily:

sure, poll on site for imbeciles will show what imbeciles do. most users do not take part in polls and do not change default distro desktop

[Nth_man]

Linux users are not typical users, as we know. When Linux users find that something seriously gets in their way (even if it's the default), hindering them, most of them try to get rid of it; otherwise most of them would be suffering e.g. Windows 8. Someone used to e.g. Gnome 2 finds Gnome 3 and...

[rastersoft]

I agree that the book is written in a "frustrated rant" style which gets people's backs up but, to be fair to it, a lot of it was true about certified UNIX implementations back in 1994 when it came out. ESR's The Art of UNIX Programming and Keith Packard's
[...]
I will admit that I disagree with them on the matter of how cd and symlinks interact. It would make no sense for .. to take you down a route you didn't come up, just because you crossed a symlink somewhere along the way.

Wow, an excelent comment. Yes, I never worked with any Unix, only Linux since 1999. Now I can put all the book in perspective. Thanks!

[Almindor]

So um... what is this discussion about and what does it have to do with the article?

To put something on topic here, I think the soft/hw rendering tracking is a nice addition. There...

[ssokolow]

Yeah that's so "dumb" isn't it. GCC should totally have built-in mind reading.

Just like if you take a pair of scissors and put the blades on either side of your ballsack and smash the handles together, you don't actually expect it to cut your balls off. That would be a design flaw in the scissors, obviously.

Yes, it is dumb. GCC should handle overwriting like that atomically, like most sane applications do today.

If you run cc -o hello.c hello, then hello.c should contain either the compiled form of the C source code that was found inside hello or, if the process errors out, hello.c should be left unchanged. We're decades beyond being so pressed for space that we need to wipe the contents of hello.c before writing into it rather than writing to a randomly named temporary file and renaming it over top of hello.c on success as is considered best practice for Linux apps these days.

GCC's current behaviour of emptying hello.c on error with a command like that is pathological.

Hell, if hello doesn't exist, then GCC will leave hello.c unchanged!

[cybertraveler]

I wonder if that GameMode library thing that Michael has mentioned could use the DBUS interface to disable fancy Gnome effects when games are running. It might make a difference in some cases. e.g. imagine a program signals it has activity (e.g. a mail app which received new mail). If there is some kind of animation triggered for highlighting that app in some way (On Ubuntu it was to light up the app icon in the Unity taskbar), that could use some resources. Notifications could also use resources. There's nothing being rendered to the screen when these would be happening, but there may be frames being built in the background and put in buffers so that they could be rendered if the user alt tabbed.

[Guest]

So um... what is this discussion about and what does it have to do with the article?

To put something on topic here, I think the soft/hw rendering tracking is a nice addition. There...

The article had the word GNOME in it; this triggers certain people to post about how GNOME killed their family and their utter disdain for it. Or alternatively "DAE dislike GNOME and love KDE?!1".

Someone point me at a sane distro with great defaults with KDE, and I might be interested in it. Fedora with GNOME is the only distro I know of that comes with good enough defaults, followed by Ubuntu with GNOME.