LXDE and Calculate Snub GNOME 3

A little GUI toolkit news, courtesy of some links from a reader…

PCMan has created what looks like a qt fork of PCManFM, and there are some indications there and elsewhere that other LXDE components may be moving in that direction.

PCMan does great work in the lightweight FM area – you can thank him for SpaceFM, as it was built from the legacy PCManFM as a base. However, it should be noted that the current incarnation of PCManFM is based on gvfs/udisks, with all their incumbent issues and GNOME dependencies. This is something which PCMan never liked, and likes even less now that he sees how they perform, so I wonder what he has in store. I know he’s already working on a fuse-based udisks replacement. Yet the rewrite probably got the code in better shape for a qt transition. Will be interesting to see what comes out of that camp.

Also, the Gentoo-derived Calculate distro has announced for their latest 13.4 release:

GNOME3 is no longer supported, as CLDG now features GNOME 2. We’ll not be supporting Gnome in next versions.

This seems like a mass lightweight (if I may combine those) migration away from GNOME3/GTK3, which is clearly being developed in a corporate/hostile-to-free way these days (background). Good for them! Hopefully this spells longer-range support or a viable fork of GNOME2 & GTK2. I’m of the opinion that GNOME3 should have been a fork, not a new major release version of GNOME, as they covered a great public park with concrete.

I’m personally watching these GUI toolkit directions carefully. qt doesn’t excite me much more than GTK3, but its probably somewhat better than what Red Hat has planned. I’ve been toying with the idea of a flexible GUI engine of sorts, perhaps to gradually and eventually replace SpaceFM’s GUI, and take it to the next level. But I’ve been stopped because I don’t like the toolkits available, and things seems so volatile. (It’s not pleasant to invest hundreds of hours on a toolkit, and base software on it, only to have it turn to sand under you.) Perhaps at this point a multiple toolkit framework is best, but that still represents an investment in a particular API.

Linux is really hurting in this area – hard to develop anything decent without wasting your time rewriting the GUI every other day. I’m glad I did SpaceFM as a prototype rather than investing a full design in GTK, but in some areas it’s ready for some new components to allow it to grow, yet I’ve been hesitant to write them in GTK. Overall I would like to break away from Red Hat/GNOME now that they’re poisoning the GTK well, but not sure that qt is for me either.

The Dangers of Software Evangelism

From The Sporkbox Blog, a review of the dangers of software evangelism and how it applies to the current situation with systemd adoption, with some devel mailing list quotes.

In May 2011 Lennart Poettering proposed systemd as a dependency for further releases of GNOME. As systemd is available only on Linux, the proposal led to the discussion of possibly dropping support for other platforms in future GNOME releases. While some people responded to the proposal with criticism others suggested the idea of a GNOME Operating System on top of the Linux kernel.

Basically this comes down to: Are Linux users going to allow corporations to take over their OS and change it in unfriendly ways? Because that’s what’s happening.

One of my concerns on this is how poorly these developers maintain these projects. I just came across an easily reproduced GTK3 bug affecting SpaceFM which was reported almost a year ago – with no response yet. That’s one thing you can look forward to when these corporate developers control everything: Microsoft-quality responsiveness and attention to detail.

Upcoming Magazine Article

I’m pleased to announce that an article I wrote will be appearing in the upcoming print issue of Linux User & Developer™ magazine. The article, A Linux Conspiracy Theory, is originally based on my November blog article GNOME (et al): Rotting In Threes, trimming down some of the quoted materials there, and integrating some of the discussions and bug reports which followed. In addition, related issues affecting kernel development and other areas of Linux are analyzed in this context, bringing together a larger picture of what is happening in Linux.

Much thanks to their editor, Russell Barnes, for working with me on this and helping to bring these issues to greater attention.

Linux User & Developer magazine is available worldwide in printed, online and digital forms, including iPad, Android tablets, and PCs. This 6-page feature article will go live in Issue #122 on sale January 17th (in the US, look for it in stores 2-3 weeks later). Look for this cover:

Thanks for picking up a copy and checking it out!

Ubuntu Spyware

Richard Stallman, creator of the GNU Project and author of several pivotal free software licenses (GPL, etc), yesterday published an article on the Free Software Foundation website exploring the fact that Ubuntu is adding really obnoxious spyware which sends your local file searches to advertisers, et al. For background, I covered this in my GNOME (et al): Rotting In Threes: Ubuntu Spyware article section, and the EFF published Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks.

Stallman writes:

One of the major advantages of free software is that the community protects users from malicious software. Now Ubuntu GNU/Linux has become a counterexample. What should we do?
[...]
Most free software developers would abandon such a plan given the prospect of a mass switch to someone else’s corrected version. But Canonical has not abandoned the Ubuntu spyware. Perhaps Canonical figures that the name “Ubuntu” has so much momentum and influence that it can avoid the usual consequences and get away with surveillance.

See his full article for details and how you can impact their decisions.

This is not exactly a new behavioral trend for Canonical, merely the latest growth. Several years ago when I dumped Ubuntu they were starting to modify Firefox in their repos so that the online search box redirected to their servers. Their escalation into sharing local search data is a gross betrayal of their users. I think anyone who supports Linux should seriously question why they’re using Ubuntu at this point. In free software, we don’t vote much with our dollars, but we do vote by using and giving attention to software and distros. Nothing says ‘I do not support this’ like users moving en masse away from their offerings. Addiction to any one distro or software solution allows these corporations to keep moving Linux in anti-user directions.

Kudos to a community leader such as Richard Stallman for taking a firm stance against these practices. Much of the valuable qualities we find today in Linux are there because of his work and the work of similar activists, as well as Linux users who stay aware of and involved in these issues. Also see Richard’s personal activist site where he gives excellent reasons for Don’t do business with Amazon, Don’t use Skype, and Don’t do business with Apple, among important others.

What this comes down to: Do you want Linux to survive and grow as a viable alternative to closed, user-limiting systems?

A Crack In The Monolith

It would seem that Red Hat’s GNOME devs have had a meeting and a change of heart:

while we certainly hope that many users will find the new ways comfortable and refreshing after a short learning phase, we should not fault people who prefer the old way. After all, these features were a selling point of GNOME 2 for ten years!

Why, these people are just so darn heart-warming, aren’t they? I love it when they call alt-tab “the old way”. :) Not standard or even different or alternate, but “old”. Why do I feel that in his mind he’s making some minor concessions to senior citizens?

we’ve decided that we will compile a list of supported gnome-shell extensions. This will be a small list, focused on just bringing back some central ‘classic’ UX elements: classic alt tab, task bar, min/max buttons, main menu…

We haven’t made a final decision yet on how to let users turn on this ‘classic mode’ – it may be a switch in gnome-tweak-tool or something else.

As in, “oops, we forgot that we have users and they like to actually do stuff, so now we have to figure out how to hack flexibility into our rigidly designed system”. This is sure to be done well.

Yet the good news is they finally responded on this one issue in some form, at least in theory. Perhaps.

 
Earlier reading: GNOME (et al): Rotting In Threes

You’re fired, Red Hat

Nice to see the energy for this udev fork building – will be interesting to see the method that Red Hat uses to try to kill it and maintain unilateral control. Where do these mysterious political influences in Linux come from anyway? Have they drugged and kidnapped Linus and switched him with a (characteristically poorly developed) Red Hat robot imposter? (If he starts crashing and refusing to grant access to his own brain, we’ll know it’s Red Hat devs at work again.)
gmane discussion thread
slashdot coverage

And if you want to see complete debian stupidity in action…
debian mailing list discussion

They don’t have the sense to support this – they’d rather argue about how debian is better than gentoo. So once again another choice by debian to use broken tools for political reasons. See cdrtools vs cdrkit for another example of mindless debian inertia and witless maintainers making unilateral choices for their users. And lest you think that’s old news, a debian packager recently contacted Jorg on his mailing list with ideas of packaging cdrtools, but someone in the upper echelons (lowest muck) of debian killed it again for no given reason.

Anyway, in every way you can let Linus and distros know that it’s time to bring some quality back to udev by supporting this fork. This is a small window in which to make a significant change.

I think they should simply steal the name ‘udev’ just like Red Hat does. As in You’re fired!

GNOME (et al): Rotting In Threes

Since SpaceFM is entering the GTK3 realm (SpaceFM can now be built on anything from GTK 2.18 “I won’t give up my lenny!” thru GTK 3.6.x), I’m starting to hear more feedback about GTK3 and experiencing a few things for myself. While SpaceFM’s GTK3 port has been running very well with the few non-broken themes I could find, there are some intrinsic problems with any GTK3 app due to GTK’s poor maintenance, as well as a growing culture of enforced conformity from GNOME devs. Some of the things you’re about to read should make your hair curl and your blood boil.

On the surface of it, it seems that with every minor update to GTK3, themes get broken. I experienced this myself trying find a GTK3 theme that worked well with SpaceFM – most of the themes are broken in GTK 3.4 thru 3.6 (you can see the warnings when running SpaceFM in a terminal, and functions will be broken in the app). Thus the better-maintained themes (such as Clearlooks-Phenix and DarkMint) will have different versions for every minor version of GTK. The less well-maintained ones will simply remain broken.

Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems, and deliberately breaking the work of others so that your ‘brand’ is the best. Anytime I hear the word ‘brand’ being used in Linux, I know something valuable is being poisoned. Just as a sample of what is to come, GNOME dev Allan Day writes:

I’m particularly surprised by the inclusion of themes. It seems bizarre…

Oh it’s bizarre alright!

I have never gotten into the KDE vs GNOME debates, so this is not GNOME bashing, nor, as you’ll soon see, are these systemic development problems limited to GNOME. Yet what I’m hearing is that with GNOME v3 the goal is to promote their “brand” and make it dominant, in part by greatly limiting what users can change on their own systems, and partly by breaking or simply removing whatever support they’re no longer promoting as ‘The Way’. The reach of this selfish and narrow-sighted development goes beyond GNOME and affects GTK apps in general.

In the rush for Linux to become ‘popular’ and ‘make it into the desktop market’, maybe there is an unintended consequence. Not only are Windows users moving to Linux, but Windows devs seem to be arriving as well, bringing their diseases with them – corporate ‘kill off the competition’ mentalities that don’t serve Linux, merely exploit it.

What follows is a sampling of quotes from various places and assorted devs which paint a picture of a growing culture of anti-user, conformist philosophies. There’s a bit of text to review here, but I think it’s worth it to hear what GNOME devs have to say about their intentions and goals, in their own words, and what others are saying about that!

---

Editor’s Note: All emphases below are added.

To start us off, Clem, a member of the Linux Mint dev team, writes:

I’ll apologize in advance for the sarcasm here.. I need to take another cheap shot at the GTKGnome developers here. GTK3 isn’t a reliable API. Maybe it should be called libgnome instead. GTK3.4 came with Gnome3.4, and wasn’t compatible with previous GTK3 themes. This means all GTK3 applications looked really ugly not only with all the GTK2 themes which don’t support GTK3 (almost all of them), but also the few which did. With this in mind we had three options:

• Give you a desktop with poor integration and applications which look different based on the API they use (which is completely unacceptable)

• Ditch all GTK3 applications from Mint and replace them with earlier GTK2 versions, or GTK2 or QT applications (this includes Gnome apps, but also Gdebi, Transmission and a few others)
• Rant like mad, remove all themes, and waste countless hours in giving Mint-X and Mint-Z proper GTK “3.4″ support even though it’s likely to break again in 3.6…

We went for option 3 “this time”. I hope this little example was enough to convince 3rd party developers not to use GTK3. I couldn’t find any release notes or documentation explaining the regression or how to solve the issue.. I genuinely get the feeling that GTK 3.4 is developed for Gnome 3.4, that it doesn’t really matter if it breaks things and that we’re not supposed to use it outside of Gnome.

Received via my email, a long-time SpaceFM user and contributor writes:

SpaceFM Dialog features will allow me to get rid of zenity. I’m no longer interested in zenity because with Gnome 3 updates, it lost some features, and I had scripts not working as they should. I didn’t understand why. Even the zenity docs were not updated about removed features. I had to search in bug reports to find that developers removed some features that were no longer considered useful with the new Gnome Shell paradigms. Wow. So devs think that zenity is Gnome Shell only? It can’t be used in other environments? I was very frustrated.

This situation was very common during Gnome 3 updates. Lots of removed features, no dev communication, no consideration for users, etc. I was using Gnome for years, but with Gnome 3, devs have gone too far and I didn’t want to be treated this way as a user and an active bug reporter. It was clear to me that I would never use Gnome again.

I really don’t like the turn that takes the development of free software. When I discovered free software about 2004, GNU/Linux was a way to use our computers ethically, the way we wanted and on the hardware we wanted. Now, there’s clearly an adoption of a very closed-source way of functioning, more and more disconnected from users and obsessed with brand control.

Received via my email, the developer of a popular GTK3 theme writes:

I have a lot of messages from users saying that my [REDACTED] theme makes Gnome more usable again. But it’s such a pain to develop a GTK 3 theme. It’s always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6. I’m so tired of that. For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration. And almost no documentation. A lot of trial and error. Developing a GTK 3 theme is not fun at all, it’s just very frustrating. This morning, I received a message from a user that tested my theme with GTK 3.6.1 (I developed the GTK 3.6 branch of my theme on GTK 3.6.0) and I can see a lot of bug rendering in his screenshot. Is it really just because of a minor version difference (3.6.0/3.6.1)? Sometimes I wonder why I’m still using GTK.

There are many such comments. For example, GTK3 theme developer half-left writes:

I’m sorry to say this but I am abandoning any GTK3 theme making from now on. Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making. As if GNOME Shell isn’t bad enough sometimes with every version being broken, GTK3 is even worse. For those of you who wish to make GTK3 in the future, good luck, you’ll need it.

Honestly, Windows and OS X actually look more attractive to me right now.

I’m not leaving dA, just pondering what customisation to do next.

The developer of the popular Swar themes writes:

The problem therein is why should we as supporters of Gnome who gave our time for free get slapped in the face with new theme requirements and our work broken and failing to do more work at out own time to support something where the requirements could change again in another 6 months or less and again break our new work? It’s a real pickle no doubts there!

This would be a continuing ‘rat-race’ to keep up and for myself I am running my own business and am also a step-in manager of a business for the full-time managers so I can not devote months on months to develop themes.

 
How can anyone remain interested in a system developed by devs who don’t care about their users? Do you know what GNOME devs think about themes and extensions?

In the following discussion, someone suggested creating a website for Gnome Shell extensions and themes. Someone else said that he was already working on such a project. Below are some tasty answers from Gnome Shell devs, considering users only as walking billboards. From Gnome 3 Extensions/Themes Website?:

Allan Day wrote:

I knew this was on the cards but I have to say that I am surprised that it is actually being pursued in this form.

Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We’ve fought long and hard to give GNOME 3 a consistent visual appearance, to make it synonymous with a single user experience and to ensure that that experience is of a consistently high quality. A general purpose extensions and themes distribution system seems to threaten much of that.

I’m particularly surprised by the inclusion of themes. It seems bizarre that we specifically designed the GNOME 3 control center not to include theme installation/selection and then to reintroduce that very same functionality via extensions.

So, I would very much like to hear about how this web site will relate to our core design goals.

Allan Day wrote:

One particular issue is the ability for users to modify the top bar via extensions. This part of the UI is vital for giving GNOME 3 a distinctive visual appearance. If we do have extensions, I would very much like to see the top bar made out of bounds for extension writers, therefore. We have to have at least *something* that remains consistent.

Allan Day wrote:

> Milan Bouchet-Valat wrote:
> I think the main reference here is the way Firefox manages
> extensions. Many people use stock Firefox, and it works very well,
> but many others like to play with appearance (personas, equivalent to
> our themes), or need a specific feature (extensions, in both
> terminologies). This example is quite positive. The fact that people
> can easily extend their desktop encourages them to support it and
> hack on it. IMHO, the available stock of extensions is one of the
> reasons why many GNOME fans use Firefox rather than Epiphany.

Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn’t a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. The visual appearance of a desktop/OS might be far more important to its marketing than a browser might be, for example.

[...]
> At the end of the day, people who use them know that they aren’t
> stock GNOME, and how to disable them if they want to get the default
> experience.

The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?

> Finally, extensions makes it easier to enforce a common design that
> works for 95% of users, while allowing the remaining 5% to do what
> they like. This is a good way for designers to turn down complaints
> and keep hackers happy.

We’ve always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?

William Jon McCann wrote:

I agree with Allan. I am really concerned about this effort to encourage and sanction themes and extensions.

In addition to the things Allan mentioned in the preceding mails, I think there are a few other issues to consider.

1. We rely on enthusiasts for testing
2. We rely on enthusiasts for building our brand

I think it is clearly detrimental to both to have more fragmentation and reshaping, recoloring, and replacing the user experience – especially in this critically important group of early adopters.

The issue is not whether extensions may be useful. The issue is whether they will be harmful to our larger goals.

If we aren’t careful they will be. I agree with Allan that, if we insist on going through with this idea, we at least have a few places in the design that remain unchanged. I think that themes should notbe included, that the top bar should not be changed, and that the overview should not be fundamentally altered.

 
Nothing Like Competing With Yourself
Even some of GNOME’s own software is seen as a competitor, like Gnome fallback mode vs Gnome Shell:

“the presence of fallback mode is having a negative impact on the quality of the primary GNOME 3 user experience” – link

See also this report: (fallback) [meta] Remove fallback support code

We could also suppose that non-default options are seen as competitors (of default options), as suggested by the following report:

tekstr1der wrote on 2012-03-22 15:04:34 UTC:

Still experiencing this bug (7 years old now) of desktop icons stacking/overlapping on the latest daily build of Ubuntu Precise 12.04.

Is the nautilus desktop abandoned?

André Klapper [developer] wrote on 2012-03-22 15:29:14 UTC (In reply to
comment #25):

> Is the nautilus desktop abandoned?

Sure [it is], as gnome-shell has been the default GNOME desktop interface for a year now and having Nautilus render the desktop is disabled by default.

Getting in deeper, not only are GNOME devs content to break their own desktop, but they want features removed from apps simply because GNOME no longer supports them!

For example, Gnome Shell doesn’t support status icons, so GNOME dev ‘mccann’ filed a bug report to a Transmission (BitTorrent client) dev to say that this option should be removed. Why should it be removed? Because Gnome Shell doesn’t support it anymore! Apparently in GNOMEland there are no other desktop environments (remind anyone of Microsoft?) From Don’t use a notification area icon in GNOME 3:

mccann writes:

In the upcoming GNOME 3 we won’t be supporting notification area icons (status icons)…

Transmission has an option in the Desktop tab of the preferences to “Show Transmission icon in the notification area”. This should probably be removed.

charles (developer of Transmission) writes:

So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator, GtkStatusIcon, or nothing at all, over such a stupid feature?

Removing it altogether, as you suggest, will hurt XFCE users.

I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

In order for this ticket to move forward, I’d like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.

mccann replies:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I’m sorry that this is the case but it wasn’t GNOME’s fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

It is my hope that you are a GNOME app…

We must choose our side. Is this a war? And can we really and seriously believe that one of the main GNOME devs doesn’t know what XFCE is?

Also, we see an indication of how decisions are made on GNOME:

mccann writes:

FWIW, I don’t think Transmission is at all impaired by removing all of above – app indicator and status icon. I have never used it with the status icon myself.

Mr. GNOME Developer doesn’t use this feature, so it must be the case for all the world. So why keep it? It’s unneeded by GNOME!

 
As for those creative little panel applets…

William Jon McCann wrote:

I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see “Remove from panel” when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful.

Let’s say that we are trying to define either a product or a product platform. I don’t think it is possible to do this without some “brand” coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity.

Even those of us in the developer community would have a difficult time identifying a GNOME desktop in 3-5 steps. Let’s try this with Windows: “Start” or Windows symbol menu, (usually) bar at the bottom. This works from Windows Server products all the way to embedded Windows on smartphones.

With OS X: Apple logo menu, menu bar at the top, (usually) a dock. Even though the iPhone doesn’t have the same software identification experience it retains the platform design branding on the hardware and uses familiar themes in the software visual design. There is usually no doubt that it is an Apple platform.

With Android: who knows…

So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.

That’s what excites him, but likely not what excites users.

Apparently in the view of these devs, users are merely walking billboards for their ‘brand presence’, to hell with what the users actually want. You’re expected to change your way of working every 6 months just because these devs want to impose their way of working on all their users. Developers decide what is Good (with a big G), without any possible customization by the user.

The screensaver was removed from Gnome 3 “by design”: What is the status of the screensaver in GNOME3?

The request for the ability to customize the Nautilus menu bar was closed as WONTFIX, with this beautiful explanation:

Cosimo Cecchi wrote:

We decided to streamline the nautilus design for 3.0, and we finally decided there’s no use for an editable toolbar in Nautilus.

Meanwhile, a user request: please add a way to customize the toolbar

The report asking to reintroduce the location/path toggle button was closed as WONTFIX. The sacrosanct Nautilus interface is more important than users’ needs:

André Klapper wrote:

There are currently no plans to reintroduce the location bar by default or to provide a toggle button as the cluttered interface has been simplified for 3.0.

Meanwhile, a user request: Reintroduce location/path bar toggle button

 
Same for gnome-power-manager…

Richard Hughes wrote:

Sorry, but the whole point of gnome-power-manager is to save power without getting in the way of what the user wants to do. It’s not going to let you set the “performance” governor any more than it lets you increase the brightness on battery.

Meanwhile: brightness_dim_battery missing from gnome-power-preferences

The Power Off option was removed from the Gnome Shell menu. Devs know what users want to do, more than users themselves:

Owen Taylor wrote:

The Power Off option is hidden because we don’t believe it’s necessary in that menu [...]. The primary way that a user would shut down (if they, say, need to disconnect power) would be to log out and shut down through GDM.

Meanwhile: Removal of the power button is inconvenient for desktop use and wastes energy

 
Features you ask? Let’s remove some:

Remove “Create Launcher” entry from desktop nautilus

A really nice quote, Bastien Nocera writes:

we’re not designing a desktop for people who like to choose their own terminal emulators

And in the last version of Nautilus (3.6), features are really a has-been concept. From TechRepublic:

The latest bit of crazy to come from the GNOME camp is the list of features being removed from the Nautilus file manager (as of 3.6). This short list looks like:

- Compact View gone
- ‘Type Ahead Find’ gone
- ‘New file’ templates gone
- Application Menu gone
- ‘Go’ menu gone
- F3 split screen gone
- ‘Tree’ view gone
- Bookmark menu items gone
- Backspace shortcut to return to parent folder gone

 
Nor is this pattern limited to GNOME. With Ubuntu, it’s all the same. There is a request for the ability to move the Unity dashboard, which is to the left of the screen. Mark Shuttleworth himself came to close (WONTFIX) this report the next day with this beautiful explanation:

Mark Shuttleworth wrote:

I’m afraid that won’t work with our broader design goals, so we won’t implement that. We want the launcher always close to the Ubuntu button.

status wontfix

And notify configuration? Mark doesn’t want settings (and neither do you):

Mark Shuttleworth wrote:

The design of Notify-OSD is specifically not clickable, and we would NOT accept patches to change that.

Another prime example of this behavior in Ubuntu devs is the Launchpad example. After years of criticism because it was closed source, Ubuntu eventually released the code, but just for its own benefit. It’s so complicated that no other webforge uses it. It is coded only with the website Launchpad.net in mind. They really don’t want ‘competition’.

Even Launchpad icons are not free:

The images/icons are still copyrighted traditionally, to protect Launchpad’s visual identity. [...] From our point of view, we have open-sourced Launchpad to improve our hosted service.

And were you thinking of actually USING it?!

Building and running Launchpad requires a computer running Ubuntu.… Running a stable production instance would be much harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at Launchpad.net. Note: the changes introduced by the install script may break your current web development setup, so it is advisable to try Launchpad in a virtual machine or an LXC container, as described above.

The following bug report is instructive: Launchpad wiki contains zero information regarding running launchpad on your own domain

The reply? WONTFIX, with this explanation:

Launchpad’s code was opened to permit the Launchpad community to contributor [sic] to the project. The information provided is the same information used by Launchpad developers. Artwork in the project may only be used for development, so instructions to run a public instance of would put the contributor in violation of the license. The launchpad team dos [sic] not maintain the production configurations of Launchpad, they do not know exactly how to setup an other instance.

Does this sound like Linux to you? It’s surreal, like this FAQ entry, Can I run Launchpad on my own server:

Yes, you can, but keep the following things in mind:

As per https://dev.launchpad.net/LaunchpadLicense, please replace the images and icons with your own.

Also, Launchpad’s production configuration information and some configuration-specific admin scripts are not part of the Launchpad code base; you’d have to reinvent those in a way appropriate for your setup.

Finally, keep in mind that Launchpad’s code is under very active development, with hundreds of changes released each month. Syncing your private instance with the upstream code base may be risky because your private instance won’t necessarily get the same data migration treatment that the main instance gets. Essentially, there’s a risk of a private instance becoming an unintentional fork, where its code cannot be safely updated due to the data in the local instance being incompatible with the latest database schema or code assumptions.

[...]

So the answer is “Yes, you can run your own instance”… but please be aware of the risks and the lack of support before doing so. We don’t recommend it; we’d much rather have you using this Launchpad instance and contributing to its improvement.

Some comments from people trying to actually use Launchpad:

I wanted to have my own instance a while ago, mostly for the bugs and maybe the answers and blueprints parts, but in its current form, installing and maintaining up-to-date such a beast is a nightmare. The install guide is oriented toward lp.net developers and contributors, not toward sysadmins wanting their own instance. The code is nowhere near a packageable state (at least it wasn’t last time i looked). I guess the latter has been made on purpose – or should i say, no effort has been made in that direction… – link

You might be saddened to know that the guys working on launchpad in #launchpad on freenode officially suggested I _not_ setup another launchpad instance. Some of these people were Canonical employees.

I wanted to play with mirroring the gnome bugzilla in a dev launchpad instance just to see how the software worked. I was primarily told that launchpad (as software) is unable to sync with another launchpad instance and would be strongly discouraged from doing what I’d envisioned. I was also told that while they were very interested in any improvements that I might make, they did not want another big launchpad instance. They promote launchpad.net as a service vs launchpad as an open source bugtracker.

So… my official opinion on this is that Launchpad is dumped code that is not really a community effort. Canonical is against any competing big launchpad installs and is very uninterested in splitting parts of it off such as Malone so that someone can use it as a stand alone bugtracker… – link

I highly doubt it. I’ve been trying to set it up in a VM at work for a few weeks now, and it is very much impossible. The lack of / incomplete / incorrect documentation, bizarre deployment process, and hidden / unavailable components makes for way too high of a secret sauce to normalcy ratio for any human to figure out. We’d *like* to use it for a group of projects (both FLOSS and proprietary, both public and internal), but so far my attempts to give it a trial run have been an utter failure. – link

Brand, brand, and brand. Even such a simple and basic question like the following becomes “complex” and can’t be answered by Launchpad devs because of their brand obsession. From What license is used for bug icon in Launchpad?:

Asked by Andrey Cherepanov on 2009-04-20:

I like nice bugs icon in Launchpad. On what license I can use they in my project?

Karl Fogel (kfogel) said on 2009-04-28:

We’re discussing internally; more soon! It’s a complex question, because some images, like the logo, identify strongly with Launchpad.net, whereas other images might not identify so strongly (not sure if the bug icon is in that category, we have to figure that out). Because of the “recognizeability” issue, this is not just about copyright license but also about trademark policy. So, we’ll get back to you as soon as we can. Thanks for asking.

No answers followed – apparently the decision was made to traditionally copyright all icons and images.

A user writes in email:

I was very happy when I knew that [Launchpad] was open sourced in 2009, but I quickly disenchanted. And Launchpad is not even translated after almost 9 years of existence. Wow. You know that the community is not really involved when a software is not translated after 9 years, including last 3 years as open source software.

Look also at Ubuntu One: Server-side is closed source.

 
Then there are the Amazon-affiliated advertisements in the recent Ubuntu 12.10. Now, when you search something on your local computer (applications, files, etc.) with the Unity dash board, your search for local files is also sent online to display Amazon-affiliated advertisements. The Electronic Frontier Foundation wrote an article about this,
Privacy in Ubuntu 12.10: Amazon Ads and Data Leaks:

Technically, when you search for something in Dash, your computer makes a secure HTTPS connection to productsearch.ubuntu.com, sending along your search query and your IP address. If it returns Amazon products to display, your computer then insecurely loads the product images from Amazon’s server over HTTP. This means that a passive eavesdropper, such as someone sharing a wireless network with you, will be able to get a good idea of what you’re searching for on your own computer based on Amazon product images.

[...]

It’s Not Just Amazon

The new version of Dash that comes with Ubuntu 12.10 introduces more than just Amazon ads. It includes a new legal notice that you can see by clicking the “i” in the corner of Dash that states that by using Dash, you automatically agree to send your search term and IP address to a number of third parties:

> Unless you have opted out, we will also send your keystrokes as a
> search term to productsearch.ubuntu.com and selected third parties so
> that we may complement your search results with online search results
> from such third parties including: Facebook, Twitter, BBC and Amazon.
> Canonical and these selected third parties will collect your search
> terms and use them to provide you with search results while using
> Ubuntu.

Ubuntu’s Third Party Privacy Policies page lists all of the third parties that they may send your search term and IP address to, and states: “For information on how our selected third parties may use your information, please see their privacy policies.” In other words, once they give your data away, it’s no longer their problem.

So Ubuntu doesn’t even care about what third-parties will do with their users’ data. Microsoft, anyone?

You feel that something is changing when your local searches are accompanied by corporate advertisements.

 
Time to use KDE 4? It has the same trends. A user writes:

When Gnome 3 was released, I tried KDE 4.x, but some easy and basic settings with KDE 3 were no longer possible, for example just changing the bottom panel color. Now it’s so complicated. You must create a theme with special SVG format files…

Also, the order of windows in the windows list was changed, without any possibility to customize it or to set it the way it was with previous versions. Now it’s so unergonomic, because when you open a new window, instead of putting it in the end of the list, it moves all already opened windows in the windows list of the panel, so the order is always changing. See this report: Task Manager setting “Force row settings” changes button sort order from row-major to column-major

It was opened in 2009 and closed as WONTFIX, even if there are proposed patches, a lot of user activity, 120 votes and even a user proposing a package rebuilt with patches.

KDE3 was an immense field of options, but I suppose that now, KDE 4 adopts this kind of reasoning. See rekonq: rekonq should show a menubar / make menubar switchable

This report asks to add in rekonq, the default KDE web browser, an option to have a real main menu bar (like most software) instead of an icon that we must click to display a drop-down list menu. Very good dev’s answer, Andrea Diamantini wrote “We decided this way, sorry. And we really like it. No plans to reintroduce it.”

OK, so devs don’t care anymore about users, even in KDE.

I could write about Firefox, removing features, like the “named separators” feature, just because devs don’t use it, and even if a lot of users complain about data loss because they were relying a lot on named separators to classify their bookmarks and they lost all that during Firefox updates.

What’s the problem? Is free software now just a market for devs working for very big tech enterprises and wanting to feel power and fame as if they were a big boss?

---

 

I think the lesson here is that as long as users put up with such nonsense, perhaps for the sake of the latest (non-configurable) bells and whistles, this is what they’ll get – dwindling options in Linux.

What is or isn’t done in GNOME is up to its devs, but nothing says you have to use it, or continue to use it as it devolves into Microsoft Windows.

And reading those dev comments, it’s so clear that most of their thought and energy is devoted to their marketing and ‘brand presence’, and so very little to making quality, innovative software. By some strange coincidence, that’s just what has been largely lacking in the field of Linux apps.

I hope you’ll pass this article along to help raise awareness of what these devs have planned for Linux and YOU.

Many thanks to additional unnamed (by request) contributors to this report!

UPDATE: A print article based on the above article and covering wider impacts in Linux will be appearing in Issue #122 on January 17, 2012 in Linux User & Developer magazine – be sure to pick up a copy:

Earlier reading:

• Gentoo On systemd, Torvalds On Bullshit, udev Forked
• Red Hat Flag (Or, What Is Red Hat Doing To Linux?)
• Udisks2: Another Loss For Linux

Gentoo On systemd, Torvalds On Bullshit, udev Forked

As a followup to my previous reservations about systemd and the means of its introduction, there is a very informative discussion happening on Gentoo Forums, including design flaws of systemd, the consolekit problem, and the expenses of policykit. I think the Gentoo community and philosophy really shines there:

“…it’s because everything he comes out with wants to take over our machines, with a mess of so-called “integration” requiring changes across the board. Til he finally realises what everyone was on about, and drops the project for his next shiny adventure, leaving everyone else to pick up the pieces.” – steveL

Elsewhere, Linus Torvalds is heard to “call bullshit” (and more!) on Kay Sievers’s excuses and poor maintenance. It’s nice to see Linus is aware of what’s going on.

Further, a udev fork is already underway and gaining popularity, which is good due to the aforementioned problems with udev maintenance and mission creep. Hopefully this will grow into a strong and independent replacement.

At the very least, it’s great to see there is a population of Linux users, admins and devs who are aware of the implications of these changes, and that they’re already exploring alternatives.

Earlier reading:

• Red Hat Flag (Or, What Is Red Hat Doing To Linux?)
• Udisks2: Another Loss For Linux

Red Hat Flag

Or, What Is Red Hat Doing To Linux?

I’ve seen what to me are disturbing patterns in what’s happening with Red Hat’s influence on core components used by Linux distributions. The latest came just after I discovered that some Flash-based DRM schemes are now using HAL for enforcement. As consolekit has always behaved like a broken DRM scheme, denying the user permission to use their own system, I wondered what was next now that HAL is deprecated – consolekit?

Then I read that udev is now being added to the systemd code, and Red Hat is sounding like they won’t support it unless you integrate it with systemd. Next, I read that systemd is now being expanded to replace consolekit/policykit!

It makes me wonder, now that a few Red Hat employees seem to be in control of the core components used by most distributions, what is their game?

I can’t answer that at present – it’s a question. I keep thinking I need to look into all this and write about it, but I’m loaded with projects right now. I dropped a few links to the above issues in this reply to a poor unsuspecting reader who unknowingly opened the subject with me. ;) So for now, I just wanted to point out that discussion and some of the links there – at least make yourself aware of these changes so you can give your distro feedback, and also make careful choices.

Me, I’m already looking to take whatever road systemd is not on.

Update: A well deserved rant on this from a (now former) Arch Linux user who describes how these changes are affecting that distro, with links to some mailing list discussions and related material.

Followup: Gentoo On systemd, Torvalds On Bullshit, udev Forked

SpaceFM & Udev

Below is an update on what’s happening with SpaceFM (and devmon) with regard to udev, udisks2, and related matters. None of this has hit release yet, but some of it is currently available on github for those who would like to help with early testing, or just give it a try.

Udisks is a layer that sits between udev and applications – it is supposed to make it easier for applications and user scripts to manipulate disks, detect device changes, mount removable devices without a root password, etc. Unfortunately this component is developed almost exclusively by Red Hat Gnome developers who are increasingly making it less than helpful. I’ve made no secret of what I think of udisks2. As soon as I saw it, I started exploring ways to remove it.

The next release of SpaceFM, which is currently available on github in the ‘next’ branch, replaces udisks with internal support for libudev, thus allowing SpaceFM to go directly to udev for its device manager needs. This includes three new custom components:

• A custom udev monitor has been added which connects to a udev socket. This monitor lets SpaceFM know when a device has a been added or removed, and when device properties have changed. Previously, SpaceFM used the udisks monitor function for this.
   

• A custom mount monitor has been added which monitors the system’s mount points and alerts SpaceFM to changes. This lets SpaceFM know when a device has been mounted or unmounted, even if it didn’t initiate the action. Because udev does not report these events, a separate monitor is needed which ties into /proc. Previously, SpaceFM used udisks for this – udisks included mount changes in its monitor function.
   

• Device information functions have been added to SpaceFM so it can use udev functions to lookup information about a device, such as whether the device is internal, removable, or optical, what media it contains or supports, what filesystem is on the device, the size of the device, etc. These functions were added using code excerpts from the udisks 1.0.4 sources, with a few fixes and improvements, and also some simplification. Previously, SpaceFM ran the udisks command line tool to obtain device information. However, the udisks2 command line tool is crippled – for example, you can no longer use it to determine if a drive is optical or not, what media it contains, as well as other deficiencies.

In initial tests, this code has been running well. There aren’t many noticeable changes – the new code duplicates most of what udisks used to provide. There is a little less information provided about special devices like encrypted drives, but SpaceFM did not use this information internally, it only displayed it in the device properties, and even then it was minimal. Another difference is that SpaceFM does not poll devices as udisks sometimes did. Some polling could be added if necessary, but thus far this hasn’t been an issue, even with my less-than-new hardware.

With these changes, SpaceFM doesn’t use udisks for anything except mounting and unmounting devices without a root password needed. As before, it runs the udisks command line tool to do so, and it now supports both udisks v1 and v2 for this. Also, two new options have been added to allow the user to set custom mount and unmount commands:

Thus, any use of udisks is optional, although still somewhat required if you want to mount without root. Mounting and unmounting without root cannot be handled internally by SpaceFM because something needs to run as root to do so (in udisks’s case, it runs a root daemon).

If you’d like to give the ‘next’ branch SpaceFM a try, just check the README for instructions (see the BUILD NEXT section) – just a few simple commands. Note that there are two new build dependencies for this version: libudev0 and libudev-dev

Looking Ahead
Because I don’t want udisks to be required at all (and because I don’t even want it installed on my system), I’m working on a small replacement tool for this. Basically, this will be a functional replacement for the udisks v1 command line tool.

Here are some design goals for this new tool (which doesn’t have a name yet called udevil):

• It will use a combination of the udisks v1 and v2 command line usage, so it can emulate both. It will provide a limited set of functions, such as mount, unmount, monitor, info, and enumerate. Thus scripts like devmon will be able to use this tool rather than udisks. (The udisks APIs will not be provided, however, just the command line.)
• Its output will emulate udisks v1, so scripts designed to use udisks v1, such as devmon, will be able to use this tool instead.
• Because there is no real need for a daemon, root access will likely be done by setting the UID bit, which basically means the program can be run as root without the root password, relying on internal authentication and security checks. This allows you to control who can execute the program, and thus who can mount devices, by setting permissions and groups, rather than all the complexities (and bugs) of policykit/consolekit. Some additional security options will be available in a configuration file. Although some people have a knee-jerk reaction to setting UID, as it is sometimes used poorly, it is a legitimate method (for example, the passwd program uses it), and this is a perfect use for it. If done well, it will provide security without the overhead of a daemon. One of the biggest problems with udisks is its use of policykit and consolekit – many users disable the security rules just to get it working at all, which obviously isn’t helpful. IMO, these solutions create more problems than they solve. You can read more about suid in this article.
• It will optionally be able to use udisks v1 or v2 to perform mounting, in case a user prefers to have the udisks daemon handle root mounting, in which case the UID bit can be unset, but still wants to use this tool with a script like devmon.
• I would like this tool to extend on udisks abilities in a few areas, including the ability to specify a custom mount point when mounting, and the ability to mount ISO files as a non-root user.

Thus this small tool will replace all need for udisks, policykit, devicekit, and consolekit, for those who don’t want them installed. This tool will allow SpaceFM to be completely free of udisks and all the associated *kits, but will not be required. You will be able to use udisks v1, udisks v2, this tool, or any other program or script you want to mount and unmount devices in SpaceFM. For future versions of devmon, you will be able to use just this tool without any need for udisks and the *kits, or you can use udisks v1 alone, or use a combination of udisks v2 and this tool.

I already have a working prototype which nicely emulates udisks v1 monitor and info functions, including a mount monitor – this protoype was also part of SpaceFM’s recent changes. This prototype won’t be released, but it will be used to build a release version.

This tool aims to provide a lightweight replacement for udisks, particularly for those running lightweight desktops, and for situations where the use of the *kits is overkill and creates problems. Like anything, it will have its limitations, but I think another choice in this area will be helpful.

UPDATE May 22 2012:udevil is now available for testing