Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by orangemanbad
    popcon probably isn't the best source, due to how the votes are counted. Polls are a more accurate representation of what people actually like and use voluntarily:Note Reddit's relatively higher GNOME usage. It figures that Redditards would use GNOME.

    I seem to remember seeing a poll done by Fedora with similar results, but I can't find it.
    Anecdotally, whenever it is I see people using a Linux desktop in the wild, it tends to be stock Ubuntu whatever - it's very easy to recognise. People don't even bother changing the background image, adding extra apps to the dock. Let alone experiment with other desktop environments.

    Anecdote != data

    Comment


    • #12
      I don't get why you talk at all about this…
      • Ubuntu comes with Gnome, probably the biggest Linux desktop distro out there
      • Fedora and the whole RedHat tree default to Gnome, if it comes to desktop at all

      Just these 2 parts alone would make Gnome to *the* Linux desktop.

      But then you have
      • for almost every distro an "official" Gnome respin
      • the most desktops are based on Gnome in some way
      • "nonfree-app" 3rd party support mostly targets Gnome
      So if you think there is something even close, you really have to provide some good sources.

      Comment


      • #13
        He already did it. Default software doesn't mean more used software, if that were the case, Microsoft Explorer, or Edge, would be the most used web browsers.
        Last edited by Nth_man; 02-20-2020, 03:05 PM.

        Comment


        • #14
          r/kde: 40.7k members
          https://www.reddit.com/search/?q=kde

          r/gnome: 33.8k members
          https://www.reddit.com/search/?q=gnome

          Comment


          • #15
            Originally posted by orangemanbad
            GNOME is an objectively bad desktop environment, used exclusively by brainlets.
            then you should use it

            Comment


            • #16
              Originally posted by Nth_man View Post
              r/windows: 131k members

              Are you sure reddit is good source for measuring popularity?

              Comment


              • #17
                > 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%

                Comment


                • #18
                  Originally posted by rastersoft View Post

                  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.

                  Comment


                  • #19
                    Originally posted by orangemanbad
                    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
                    Last edited by pal666; 02-20-2020, 06:22 PM.

                    Comment


                    • #20
                      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...

                      Comment

                      Working...
                      X