GNOME: Possible Recovery Strategies

An anonymous reader tips an article from Datamation about several suggestions for the GNOME project to answer user complaints and boost developer morale. From the article: "... with very few changes, GNOME 3 could be much more acceptable to most users. A moveable panel, panel applets, desktop launchers, user control of virtual desktops, menu alternatives that would remove the need for the overview -- all of these could be added easily as options. Together, they would reduce at least ninety percent of the complaints against GNOME 3. ... If GNOME is having trouble as a desktop environment, one obvious solution is to find new niches. Lopez and Sanchez suggested following KDE's lead and producing a tablet, while Lionel Dricot recently suggested a suite of cloud-based services. ... The one strategy that GNOME has never tried is asking users what they want. Instead, the project has preferred to rely on usability theory, treating it as an exact science instead of a collection of competing ideas supported by usually inconclusive studies that could be mustered to support almost any design. In GNOME 3, testing with actual users did not occur until near the end of the development cycle, when the chances of any major changes were remote."

Extensions

[macemoneta]

The requested functions are already mostly available via gnome shell extensions, allowing users to customize gnome to their preference.

Re:Staying with gnome2

[Derek Pomery]

According to the MATE developers (the guys maintaining a fork of Gnome2) there is one technical reason you can't have both.
Gnome is not designed for multiple versions to be installed simultaneously. There are name collisions.

You can have multiple versions of KDE installed. Not Gnome.

According to the MATE devs ( irc://irc.freenode.net/mate ), that's why they had to rename pretty much everything.

I can attest that MATE and Gnome3 *can* be run on the same machine, although MATE is still getting on its feet.

And some distros are offering both.

Re:What Gnome 3 Needs

[epyT-R]

Unity keeps things simple the same way an etchasketch keeps image editing simple...

Re:Not just Gnome

[UnknownSoldier]

Sure.

The classic paper every programmer (IMHO) should read is one by Danny Cohen who introduced the terms big-endian and little-endian is:
    ON HOLY WARS AND A PLEA FOR PEACE
http://www.networksorcery.com/enp/ien/ien137.txt [networksorcery.com]

Here is a "abridged" summary:

Like most things, there are 2 (diametrically opposing) way of doing things. You can do it either A xor B; that is A, or B but not both. Neither is right; they are just (competing) standards. Oblg. http://xkcd.com/927/ [xkcd.com]

Agin, neither is technically "right" - they both are; we may chose one or the other *simply* for convenience. As long as we pick one standard, and are consistent in our use, everything works. The problem arises when somebody picks a different "standard" and we need to interface with them. (i.e. share data.) :-)

Here is practical example that shows up all the time in computer graphics. Let's say we wish to define the world coordinate system. To the right we can call that positive X, we can call up positive Y, and for stuff off in the distance we have a choice:
a) call positive Z for things further away from us, (DirectX uses this) OR
b) call negative Zfor things further away from us (OpenGL uses this.)

Getting back to the function originally mentioned:

When we have the integer number 0x12345678 in a CPU register how the bytes are stored in memory / disk / "network" can be done either in:
a) Little Endian format:
i.e.
    unsigned char LE[] = { 0x78, 0x56, 0x34, 0x12 };
or
b) Big Endian format:
i.e.
  unsigned char BE[] = { 0x12, 0x34, 0x56, 0x78 };

How did this come about? Notice that we write bits from right-to-left
    bit31 bit30 ... bit 3 bit2 bit1 bit0
the same as we write the Aramaic numbers. Now which bit should we send first over a wire? bit31 or bit0? The hardware guys wanted it one way (because they could use a simple barrel shifter/latch), the software guys wanted it the opposite way.

Let's say you have this number stored on disk that was generated by a program running on a little endian CPU. If you have a big endian CPU try to naively read this data it will interpret it as the wrong value.
i.e.
  Little endian 0x12345678 (305,419,896) on disk is: 0x78563412
  Big endian will interpret it as: 0x78563412 (2,018,915,346)

Hence you need to "fix up" the bytes, that is byte swap them. The CPU instructions of shift-and-mask is the standard way to shuffle bits around.

It helps to label all 32 bits with unique names:
    ABCDEFGH IJKLMNOP QRSTUVWY abcdefgh

We want a function that, given the above, will generate this:
  abcdefgh QRSTUVWY IJKLMNOP ABCDEFGH

Or expressed in bytes:
    b3 b2 b1 b0
We want:
  b0 b1 b2 b3

Notice that the hex mask 0xFF (called a "byte mask") is a way to treat 8 consecutive bits (one byte) as one "logical number".

By inspection:
  b0 should be shifted Left 24 bits
  b1 should be shifted Left 8 bits
  b2 should be shifted Right 8 bits
  b3 should be shifted Right 24 bits

When you are talking about numbers in base 16, the idiom << 8 of shifting the bits by one byte, or multiplying by 256, is equivalent to a multiplying a decimal number by 10 because we want to shift all the digits over to make room for another "tens" unit place.
i.e.
  0x12 8 = 12 times 2^8 = 12 times 256 = 0x1200
  12 * 10 = 120

Does that answer your question sufficiently?