A new security/containment tool for browsers and other graphical/network applications called Firejail is available for Linux.
From the Firejail Homepage:
Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.
Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer.
So this appears to use newer kernel features and is not dependent on systemd.
I haven’t yet used or examined this project in detail, so this is not a review or recommendation. Mostly I’m just letting you know the project exists, but it does look well-documented and organized, a good first sign. Also, contrary to some comments on the sites, I am not a developer of Firejail or associated with the project.
Similar to my Sandfox bash script, which is still running strong years later, the Firejail C program limits access to the filesystem, yet it also does much more than Sandfox by making use of Linux namespaces. For the casual user, this script may provide some nice enhancements to browser use, limiting system access of the browser process and its children.
What I and others like about approaches like this is that unlike SELinux or systemd-based methods, this method does not create a huge central point of failure (if executed well). This seems like a nice KISS (Keep It Simple, Stupid) approach.
Even if it’s not perfect, I think using a script like Firejail will improve security for most users, limiting applications and their plugins. This is becoming especially true as new browser technologies endorse web binary executables, etc.
While I haven’t reviewed this project for security, here are a few questions and points I would keep in mind during such a review:
This is an SUID program, which means its command line interface must be bullet-proof. It must only allow a limited set of actions in a limited way, and reject all bad input. Even bad parsing of characters in the command line can create a root exploit. So that is an area of code to review in any SUID program. Yet if done well, SUID programs can be secure and effective solutions, contrary to much rumor on the subject.
Also, does it drop priviledges immediately and run most of its code unpriviledged? Again, this is vital in solid SUID designs. Only the final actions that require root should have it, thus limiting exposure to complex coding errors and oversights.
It’s also important to keep in mind that this project is still maturing, which is a learning process for the developers as well. Thus it is possible to find loopholes and exploits, such as this issue raised regarding ptrace whitelisting and seccomp. The good news is that even with tailored exploits possibly available, most generic malicious code is not going to be fined-tuned to break out, so will be stopped. Consider it an enhancement at least, especially if the SUID handling is done well.
Firejail is already available in Debian Testing and for other distros, with its sources on Github. There is a related forum discussion here. I see LWN.net also featured an article on it earlier this year.
GTK 3.20 is entering distros, and it looks rough. If you use GNOME 3 or GTK3 applications, be advised that upgrading to 3.20 may cause extensive breakage. The new GTK 3.20 is hitting Arch Linux users with a number of upgrade problems. Arch is a rolling release distro that tends to get new versions of packages before most other distros, so new problems tend to be revealed there first. 3.20 hasn’t yet arrived in Debian Testing, but will likely be appearing soon. You may wish to choose your upgrade time and path carefully.
The GTK 3.20 release reportedly adds a new API for themes, which in the future may help reduce GTK3’s endless theme breakage problems. While this API change may be good news for users and theme developers in the future, in the short term it means almost all third-party themes will be seriously broken by the upgrade to GTK 3.20. (GTK3’s default theme is Adwaita, which usually avoids these problems.) All third-party themes will need to be updated or rewritten by the theme developers before they can be used very successfully with GTK 3.20. [Many applications also appear to need updates, as detailed in the update here.]
In addition, it appears our old friend Matthias Clasen has carelessly refactored the drag and drop code in GTK 3.20 (commits), causing DnD breakage and crashes in SpaceFM and Firefox, among others. Arch users have reported SpaceFM 1.0.5 crashing when using drag and drop in GTK 3.20 (even with Adwaita). In fact, this bug may cause the X server itself to crash or freeze, and there have been reports of other X-related issues with 3.20. Thus far I’ve been unable to reproduce that SpaceFM crash in tests on Archbang (which includes SpaceFM on its live ISO.) Further information is welcome on that crash report, but there are indications that the crash may be in GTK’s code itself, or perhaps due to the updated Adwaita. Other minor stderr warnings are also visible when running SpaceFM under GTK 3.20, although these should not cause a functional change.
As your upgrade to GTK 3.20 approaches, remember that SpaceFM may be built to run as a GTK2 or GTK3 application, and most distros provide a spacefm-gtk2 package. In fact, GTK2 is still SpaceFM’s default build (if you have those dev libs installed at build time). GTK2 tends to be much more stable through upgrades, which is handy in a file manager. The GTK3 version of SpaceFM does run well in general, but frequent theme and functional breakage may occur during upgrades to GTK3, which is NOT handy in a file manager.
Even if you normally prefer GTK3, you may want to consider holding back the upgrade to 3.20, or switch temporarily to a GTK2 build of SpaceFM, if you want to avoid GTK3’s growing pains for the next few weeks/months. Other applications may also be affected.
Overall, SpaceFM and my other projects are in a slow development phase, mostly just critical bugfixes being addressed recently. If you want a little adventure you can try SpaceFM alpha for some new features, including deep directory sizes and faster directory load.
UPDATE: Matthias Clasen has provided a more detailed explanation and documentation links for the changes in 3.20, makes excuses for breaking applications yet again, and asks application developers to give feedback.
The times are changing for open/free/libre software and OSes, and what the words mean. Make no mistake: collaborative, truly open projects are powerful sources of innovation and problem solving. The only way proprietary, corporate models can even survive is through sheer bullying and anti-competition tactics, as have been used for years to keep Linux from wider adoption. Now that that is changing, the tactics are changing too.
The latest trend in this area seems to be bringing disinformation and propaganda tactics into the fray. The latest is “open washing”. Techrights.org explains:
NON-TECHNICAL FOLKS may easily be led into the illusion of ‘open’ Microsoft and ‘open’ Apple (openwashing), much like that of ‘green’ (and yellow) BP or ‘green’ Shell (greenwashing). There is also whitewashing, e.g. of Bill Gates, but these two examples are different matters. They all involve mass deception with a huge budget. it’s quite a theatre!
I think at least as important is the why of it, which can be seen in another article on the same site:
Microsoft is in trouble and there is no denying that. According to British media, Vista 8 continues to be a disaster technically and in some nations, unsurprisingly, GNU/Linux has greater market share than the latest Vista (Windows 8.1). The desktop monopoly too is in jeopardy, especially where governments made it their policy to embrace Free/libre software (Uruguay and Venezuela in this case).
While this may sound like good news for Linux, it also means we must watch these corporate players carefully for what they’re doing IN Linux. Linux has always been under attack by corporations seeking to poison its free nature. What form are those poisons taking today, aside from openwashing and other misdirection? Could it be that some of the corporations involved in (or in control of) Linux’s engineering are seeking to take it away from the community? And how would this be done?
I think you can see it being done in technologies like systemd, which as many of us observe, brings Linux closer in design to Windows. They can still call it Linux forever, and the large masses of uninformed users will follow them off the cliff, but is it really UNIX-like in its design anymore? How can Linux be controlled when it is ‘open’? By making components which are large, complex, and difficult to maintain and review, and by requiring services that lock out the administrator.
Remember Heartbleed? Don’t let that example escape your attention. OpenSSL is open, yet it is so large and poorly designed that it’s a dark mystery. Heartbleed was easily shown to be a deliberate hack, and was even deliberately coded to hide itself from tools that would otherwise have shown the leak. And it was sitting there in ‘open’ sight. Instead of using small, well-reviewed crypto libraries, corporate Linux developers choose to use corporate-maintained tools like OpenSSL, which are deeply compromised. Do you think the people responsible for HeartBleed were held accountable, and fundamental changes were made? Guess again. It’s simply ignored by most of Linux. (You’ll notice real UNIXes like OpenBSD did not ignore it and have begun serious changes. Yet even there, it took such a serious, obvious exploit for them to see the engineering problem.)
The point is, if Linux is going to continue to be genuinely open and libre, accessible and changeable, it must use technologies that are simple and manageable by the community, not just by large teams of corporate developers whose intentions are questionable at best, and who are not held accountable.
Make no mistake – corporations aren’t just going to let Linux destroy their income. They are responding, deceptively and desperately.
Really, I think it’s too late for mainstream “Linux”. It’s gone. It’s done. Geeks of the world were easily fooled by a shiny new toy and a corporate propaganda campaign to match, without considering the engineering implications. You can still use a real (systemd-free) version of Linux, or move toward the BSDs, but if you stay with the easy-to-use, polished distros, you’re no longer really using Linux. You’re just fooling yourself, and they’re fooling you. Nor will systemd be the end of it – it’s just the beginning, the setup for future changes.
Because of this corporate pressure, using Linux has always been more of a challenge. It has less hardware support, and more knowledge and problem-solving is required for installation and maintenance. The same remains true today. If you take the easiest, effortless path, the one they have paved for you, it’s not really taking you in the direction of genuinely open and libre computing. Non-buyer beware.
As a rat who will be among the first to flee any sinking ship, my whiskers are twitching at the prospect of staying aboard Linux. Despite all the fine efforts some people are making to stay in a systemd-free parallel universe, there seem to be changes coming to the kernel from the same folks that brought us systemd, and these changes are symbiotic.
With the same political-like moves used to push systemd into most major distros in record time, kdbus (a kernel-based implementation of dbus) was recently dug out of its grave, propped up to make it look half-alive, and is being pushed into the kernel whether it fits or not. When Linus said a week or two ago, “Now this looks like a big oversight, and serious” in politely talking about one of kdbus’s ridiculous approaches to security, one wonders whether he was prophesying about the fate of Linux and kdbus in general. This Gentoo forum thread is a good read for catching up on the sensationalized push to put kdbus into the kernel the last few weeks, it’s relationship to systemd (Red Hat of course), and some of the history on this.
I think with kdbus and systemd installed, you will have a completely bugged system, from the inside out, kill switch included. That’s just a hunch, mind you, but what else are smartphones good for? Coming soon, if Red Hat doesn’t like your program, it won’t run on Linux – only approved apps are ‘safe’. I think they simply told Linus, “kdbus goes in now, like it or not”. One person can’t stop all of the pressures involved, so don’t expect him to. Instead, we have to know when to jump ship. Especially if Linus retires soon and hands the kernel over to a Red Hat developer, run-don’t-walk for the door.
As for BSDs, you can see FreeBSD lead developers already acclimating their users to systemd, and trying to turn BSD too into a mobile phone kinda thing. Even master Linux-slayer Lennart Poettering gave it his official ‘okie dokie’.
Of course, the heretofore-known-for-stability Debian recently released Jessie featuring systemd. I’m definitely in the crowd taking the road less traveled on this one. I think this is a time for conservative changes, hanging back, sniffing the air, even if you just prefer huge amounts of new code running as PID 1 to be better tested, or if you don’t care for Red Hat overwriting your boot firmware and blacklisting manufacturers who don’t play ball. Linux is being redesigned, eaten alive really, so at some point it’s no longer what it was. Its course of development is not based on the same principles, even if the GUI looks the same for now. Knowing how entrenched things get, I think this is the time to take a new direction, even if that direction is regression.
Even if you don’t mind that NSA toy Red Hat single-handedly controls xorg, udev, etc. (the list is long), the new systemd that rocketed to fame and widespread adoption overnight, and now the large, complex, new and wildly non-secure-on-principle kdbus kernel patch being slipped in to complement it, you may see some other potential problems with this picture.
I don’t think long-term planning is possible for Linux anymore, because one thing about the crowd that develops systemd and kdbus is for sure: they break things and make unpredictable changes without consulting anyone. It’s not Grandpa’s style of cooperative Linux development anymore. It’s their OS and you’re just a user. Overall I think the only reasonable long-term plan for Linux is to plan for, wait for, or create something else.
Yet for the short-term, in addition to Devuan‘s plans to fork Debian soon (some pre-alpha ISOs already), there are some distros that are staying systemd-free already, and I think this is about the best you can do in Linux for now. Here’s a list (thanks to everyone who brought these to my attention):
Several systemd-free Distros
- Alpine Linux
- antiX (based on Debian)
- Calculate Linux
- Entropy GNU/Linux (formerly Less Systemd GNU/Linux)
- Gentoo (ready options exist)
- Manjaro (see OpenRC options)
- Puppy Linux
- Void Linux
For more see without-systemd.org.
In his Q&A to his keynote address at the World Hosting Days Global 2014 conference in April, the world’s largest hosting and cloud event, Julian Assange discussed encryption technology in the context of hosting systems. He discussed the cypherpunk credo of how encryption can level the playing field between powerful governments and people, and about 20 minutes into his address, he discussed how UNIX-like systems like Debian (which he mentioned by name) are engineered by nation-states with backdoors which are easily introduced as ‘bugs’, and how the Linux system depends on thousands of packages and libraries that may be compromised.
I recommend watching his 36 minute Q&A in its entirety, keeping in mind my recent warnings about how GNU/Linux is almost entirely engineered by the government/military-affiliated Red Hat corporation.
The Voice of Russia website has an article on Assange’s address with a few quotes:
“To a degree this is a matter of national sovereignty. The news is all flush with talk about how Russia has annexed the Crimea, but the reality is, the Five Eyes intelligence alliance, principally the United States, have annexed the whole world as a result of annexing the computer systems and communications technology that is used to run the modern world,” stated Julian Assange in his keynote address…
Don’t just read the short article, listen to the address yourself, because Assange goes into many areas, and the work being done in these fields.
Assange mentions how Debian famously botched the SSH random number generator for years (which was clearly sabotaged). Speaking of botched security affecting Red Hat, Debian, Ubuntu, Gentoo, SuSE, *BSD, and more, the nightmarish OpenSSL recently botched SSL again (very serious – updated comments on how a defense contractor in Finland outed the NSA here?) It’s very hard to believe this wasn’t deliberate, as botching the memory space of private keys is about as completely incompetent as you can get, as this area is ultra-critical to the whole system. As a result, many private keys, including of providers, were potentially compromised, and much private info of service users. Be sure to update your systems as this bug is now public knowledge. (For more on how OpenSSL is a nightmare, and why this bug is one among many that will never be found, listen to FreeBSD developer Poul-Heening Kamp’s excellent talk at the FOSDEM BSD conference.)
From the start, my revelations on this blog about Red Hat’s deep control of Linux, along with their large corporate/government connections, hasn’t been just about spying, but about losing the distributed engineering quality of Linux, with Red Hat centralizing control. Yet as an ex-cypherpunk and crypto software developer, as soon as I started using Linux years ago, I noted that all the major distributions used watered-down encryption (to use stronger encryption in many areas, such as AES-loop, you needed to compile your own kernel and go to great lengths to manually bypass barriers they put in place to the use of genuinely strong encryption). This told me then that those who controlled distributions were deeply in the pockets of intelligence networks. So it comes as no surprise to me that they jumped on board systemd when told to, despite the mock choice publicized to users – there was never any option.
A computer, and especially hosting services (which often run Linux), are powerful communication and broadcasting systems into today’s world. If you control and have unfettered access to such systems, you basically control the world. As Assange notes in the talk, encryption is only as strong as its endpoints. eg if you’re running a very secure protocol on a system with a compromised OS, you’re owned.
As Assange observed:
“The sharing of information, the communication of free peoples, across history and across geography, is something that creates, maintains, and disciplines laws [governments].”
UPDATE: Wikileaks is officially denying that Julian Assange literally said “Debian Is Owned By The NSA”. For people who are choking on the mere summary title of this article, please see definition of Owned/Pwn (and get some hip!)
- kdbus: systemd’s Kid Cousin Come To Stay (No, Not PID 1, In Your Kernel, Silly)
- Ts’o and Linus And The Impotent Rage Against systemd
- Biography of a Cypherpunk, and How Cryptography Affects Your Life
(second half details Red Hat’s involvement in Linux)
Bringing some links buried in comments below to the top, I think these critiques of systemd’s integration and maintenance deserve some review.
First, kernel developer Theodore Ts’o, the developer of e2fsprogs and current maintainer of ext4, shares his reservations about systemd’s engineering, and the trouble he has had understanding and using it.
…a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix.
He goes on to describe how he previously had to neuter policykit’s security (rendering his system very vulnerable) just to get his system working, and how he has found systemd “very difficult sometimes to figure out”. Should we be concerned that a kernel developer, obviously a very qualified computer user (an MIT graduate in his 40s), has trouble understanding and using policykit and systemd to configure his own system? Where does that leave the average Linux user in handling these atrociously complex and built-to-be-broken technologies?
…Kay Sievers and Lennart Poettering often have the same response style to criticisms as the GNOME developers [read other Red Hat developers] — go away, you’re clueless, we know better than you, and besides, we have commit privs and you don’t, so go away.
Predictably, fanboys rush to systemd’s defense in the comments, telling us how wonderfully documented and supported it is, what a quiet, fascist paradise the systemd mailing list is, and how responsive the developers are to every bug, request and patch submission.
Yet just two days ago, we see Linus Torvalds (the creator of Linux and maintainer of the Linux kernel), launching into a tirade against – yes, you guessed it – systemd developers because of their atrocious response to a bug in systemd that is crashing the kernel and preventing it from being debugged. Linus is so upset with systemd developer Kay Sievers (gee, where I have heard that name before – oh, that’s right, he’s the moron who refused to fix udev problems) that Linus is threatening to refuse any further contributions from this Red Hat developer, not just because of this bug, but because of a pattern of this behavior – a problem for Kay because Red Hat is also foaming at the mouth to have their kernel-based, no doubt bug- and security-flaw-ridden D-Bus implementation included in our kernels. Other developers were so peeved that they suggested simply triggering a kernel panic and halting the system when systemd is so much as detected in use.
So much for systemd developers’ responsiveness, and its great engineering, witless fanboys. (Are we really sure many of these fanboys aren’t part of an Infiltrate, Manipulate, Deceive, and Destroy program?)
While Ts’o’s discussion of systemd wanted to make me wretch for its usual polite, politically-correct crap, he did at least bring up some core problems in that typically watered-down way that mainstream developers express their opinions so as not to offend any fascists in their midst. Yet even Linus’s tirade, and the lengthy user discussion which followed it, completely miss what’s really happening to Linux. It seems these developers and users can’t rise up enough to get a 3D view – all they can do is focus on minute issues in isolation and fail to put the pieces together in any coherent way. Are they just afraid or feeling awkward to discuss it, or are they like other kernel developers I’ve heard from who are completely clueless about what Red Hat developers represent?
I’ll put it together for you once again. For those who missed it in my other articles, Red Hat is a billion-dollar corporation with deep ties to the US military (their largest customer), and thus inevitably the NSA (a military security organization), etc. Adding to the conflict of interest, they have as direct corporate partners Google, Apple, and other too-large-to-imagine corporations with their hands in slime. Red Hat developers dictatorially control the core engineering of Linux, including components such as udev, udisks, xorg, dbus, systemd, etc., used by every major Linux distribution, as well as other common desktop components such as GNOME and GTK. (As Ts’o put it, “we have commit privs and you don’t”.) These are simple facts, though curiously never discussed. In many developers’ views, these Red Hat developers have consistently introduced closed, overly complex, security-breaking technologies to Linux for years, and have a long and tired history of sabotaging kernel development, creating unending bugs and problems for kernel developers, which they often categorically refuse to address. Linus knows them well – or does he?
Yet the myth continues that Linux is somehow not surreptitiously developed as a product of the military-industrial complex, and that its core engineering is based on open and free contributions. Discussions like these ones above revolve around whatever the bugs of the day are, and completely fail to assess what appears to be deliberate and systemic damage done to the Linux ecosystem, primarily through Red Hat developers.
Wake up, morons – and that includes you Linus (who likes to call out morons as such himself). Start telling it like it is, and start addressing the real systemic problems in Linux’s engineering – namely that brown shirts like Kay Sievers and Lennart Poettering are just front men for a much uglier reality. Otherwise you’re just trying to sweep back the ocean with a broom – your actions are useless and doomed to fail. Getting angry won’t help – start getting smart, and start developing a genuinely free and open operating system, taking you-know-who out of the loop. If you can’t or won’t do that, then you may as well just surrender Linux to them entirely, which is pretty much the case already.
- kdbus: systemd’s Kid Cousin Come To Stay (No, Not PID 1, In Your Kernel, Silly)
- Julian Assange: Debian Is Owned By The NSA
- Biography of a Cypherpunk, and How Cryptography Affects Your Life (second half details Red Hat’s involvement in Linux)
At the risk of turning this into the ‘bad news blog’, I have discouraging news regarding the release of GTK 3.10, which has now reached Debian Testing.
While working on SpaceFM recently, I noticed that all of the menu icons are gone.
No menu icons, meaning no app icons in the Open menu. This is the new GTK3 default, unannounced as far as I can tell, and not publicly discussed. I see from an Ubuntu thread back in 2009 that GNOME made this their default back then. That thread indicated that GNOME (which I don’t use) has a configuration editor to turn menu icons back on, and there was rumor of the option being removed eventually. The developers deemed it “less cluttered”.
In GTK 3.10, you can still add the line ‘gtk-menu-images = true‘ to ~/.config/gtk-3.0/settings.ini to turn them back on. Yet if this was already the GNOME default, why make it a new GTK default five years later, breaking current behavior? Are they planning to disable them entirely soon? A quick search reveals no discussion or documentation on this change.
As an app developer, I can tell you that most GTK and GNOME users won’t change that setting, or even be aware that it exists. Thus my app will be icon-less, and the settings for customizing menu icons in SpaceFM won’t have any effect. I thought GNOME was always the icon-driven UI compared to KDE, so this seems very strange.
No Mnemonics Either – At All
In addition, as you can see in the above shot, mnemonics have been removed entirely. These are where eg “Copy” in the menu has an underlined ‘C’, allowing you to press Alt+C to activate it. SpaceFM allows you to customize these too. Mnemonics have also been removed from dialog labels, meaning, for example, you can no longer press Alt+N in SpaceFM’s rename dialog to put the cursor in the Name box, and you can’t click an OK button by pressing Alt+O.
Unlike the missing menu icons, it appears that mnemonics have been permanently disabled. Per the GTK 3.10 docs: “gtk-enable-mnemonics has been deprecated since version 3.10 and should not be used in newly-written code. This setting is ignored.” IOW, it’s also impossible to turn them back on with gtk-enable-mnemonics = true in settings.ini, and themes can’t override this either. I say this appears to be the case, because I can find no further documentation or discussion of this change. [UPDATE: It seems you can press the Alt key once to make the mnemonics appear while the mouse is over an item. Anyone know how to disable this feature and make them always shown? Please leave a comment.]
Good luck to disabled persons with limited or no mouse use. And based on feedback, many people use these mnemonics, myself included. Key shortcuts provide a much faster UI than clicking a mouse, especially for commonly repeated tasks.
Fortunately, SpaceFM users can choose a GTK2 build of SpaceFM (most distros offer packages for both for compatibility with MATE, etc), and I personally plan to drop use of GTK3 due to this change, as well as their breaking existing defaults and behavior. I don’t want to deal with lost and broken functionality everytime I update my system – it interrupts my workflow. Plus I use mnemonics at times, especially with annoyingly slow touchpads. Yet for apps that have ‘moved forward’ to GTK3, such as Roxterm, we’re stuck with mnemonic-less menus and dialogs.
What is the vision and motivation behind permanently removing such core UI functionality, not just changing the toolkit default, which is bad enough, but killing it entirely? All that GTK and app code, debugged and working well, now in the trash bin. Whatever their vision is, I don’t like it. Their rampage of removing functionality is clearly just getting started.
At some point, I believe I may need to drop GTK3 support entirely from SpaceFM, but we haven’t reached that point yet. This change doesn’t require me to re-code anything, it just diminishes the user experience when GTK3 is used. I had planned to make the GTK3 build the default soon, but I believe I will stick with GTK2 as a default, and for stability I recommend that to users. If it comes to a point where I can’t support both, I will drop GTK3. I’m not chasing after all their time-wasting breakage. And many projects have been resisting the move to GTK3, which I think is wise. I guess it’s telling that the GIMP project, the original developer of GTK (GIMP Toolkit), is sticking to GTK2, and they’ve been told not to expect to be able to use GTK3 for such a robust app.
This still presents problems, because using a mixture of GTK2 and GTK3 apps on your system is wildly inefficient. This means that library components of both versions must be resident in memory, as well as all the components related to GTK, such as icon caches, etc. You’re basically doubling the system requirements and slowing it down. For this reason, I strongly advise app developers to support a hybrid GTK2/GTK3 build. While it requires a few ifdefs, it’s reasonable. See SpaceFM’s gtk2-compat.h for some ideas.
Further, developing an app on a toolkit that is no longer actively developed or supported presents obvious problems. Yet GTK3 is supported so poorly, and the developers of it respond to app developers and users so arrogantly and dismissively, that it’s effectively the same. Yet how long will GTK2 remain compatible with changes in X, glib, and other components? Lets hope some forks get going strong.
This solidifies my conspiratorial opinions that GTK is deliberately being driven into the ground by Red Hat, alienating users and developers, both to turn the corporate-developed Qt into THE monolithic Linux UI toolkit, and perhaps to convert GTK into some kind of tablet-only nightmare. “Linux is a government, military product, right down to its core” – the core engineering is controlled almost exclusively by Red Hat, regardless of what distro or DE you use. I guess the military isn’t keen on recruiting disabled persons, so why bother with mnemonics? And who needs icons in a colorless corporate world? I can understand why app developers, even in Xfce and LXDE, are being slowly driven to Qt, yet once everyone is in that corporate boat, where will the captain take it?
In the latest sprint away from all things Red Hat, Ubuntu is planning to develop its own file manager and is asking for feedback. From Phoronix:
The latest piece of the desktop Linux stack that Ubuntu developers are planning to replace with their own home grown solution is a file manager. For likely inclusion into Ubuntu 14.10 would be a new Ubuntu file manager to replace GNOME’s Nautilus. Users and developers of Ubuntu are growing increasingly unhappy with the direction of Nautilus… Oliver Grawert is currently seeking feedback on the requirements and other sought after features of the new default file manager.
While Ubuntu’s likely file manager doesn’t excite me, the discussion is interesting. And it was good to see SpaceFM and udevil raised in the discussion. Isn’t it time for file managers to support ad hoc commands for mounting and other tasks, instead of binding users to one set of hard-coded system tools?
LWN.net’s Nathan Willis, who previously covered this blog’s viral Arch’s Dirty Little Secret article a few years ago with unusual courage and honesty, has an article back from August which covers several talks at GUADEC 2013, wherein lead GNOME developers talk about the limited uses and ill future of GTK.
In my clear view, the Red Hat corporation has declared itself sole owner of the community-developed GTK project, and is driving it into the ground, making it unusable, probably at Google’s bequest. Their greatest vision for it is making a desktop clock. Any apps larger than that are pushing the usability envelope. GIMP, the original creator of GTK, need not apply.
Meanwhile, Linux developers are flocking to Qt. Yet it should be noted that as soon as Digia aquired Nokia’s Qt, they pledged to become Google’s bitch everlasting. Today, they’re very excited about Chromium. They are controlled by large corporations who make all the decisions and decide the directions. Where do you think that will lead? Why do you think Google didn’t buy Qt themselves? Short of cash? Why use a pawn like Digia?
To me, all of this powerful corporate drive to support ‘cross-platform’ development is merely a game to turn Linux into Windows – to make it so it doesn’t matter what you run, you’re still running a Google product. Google is the new Microsoft. It amazes me how many Linux users think Google is their friend. The Linux community has really become nothing short of stupid, absorbing corporate press releases like populations absorb propaganda. They can’t see even the most obvious attacks, and give their full support to their own demise.
I think it’s safe to say that any spirit of freedom and diversity that once drove Linux is dead. The new people entering the realm of development in Linux are just Windows developers looking for a larger base and more money, or simply corporate whores tearing it apart for short-sighted, malicious goals (which they themselves understand very poorly). They care not for any of the principles that made Linux what it is, or was.
So Linux has been lost because the community has failed to protect it and help it grow. And this isn’t just about toolkits – the infection goes deep into the kernel, udev, the init system, and other areas. In the next few years any remaining GNU Linux users who even know what a principle is, will need to find a new home.
Meanwhile, while you still have a non-Google-implanted brain, you might want to try to figure out why corporations want to (and have always wanted to) completely control the software and abilities of your computer. And you might want to consider differences between Windows and Linux beyond how widgets look. They once represented very different visions of the personal computer.
A little GUI toolkit news, courtesy of some links from a reader…
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.