SpaceFM 1.0.0 has been released. Please see the SpaceFM News page for changes in this version.
Did you know that SpaceFM is a systemd-free file manager which also supports eudev as a replacement for udev? When used with udevil or another mount solution, SpaceFM can be used completely without systemd, consolekit, policykit, dbus, udisks, gvfs and fuse (although it can coexist with and use any of these).
Please see the details here. Please help test this version so the release will be more stable.
SpaceFM and udevil have entered a slow development phase, and you can read the details there.
Currently, the next branch has been updated with some minor fixes and requested features (including BwackNinja’s maintenance fork). Testing of this branch is appreciated, as that helps the releases to be more reliable. Nothing is ever deliberately included in the next branch which is highly unstable (all commits are tested before they reach this branch), so it’s almost always as stable as using the release version, and you can help report minor bugs.
Translators please note that SpaceFM’s translation server is available again on Transifex. Because the old server was originally setup by someone else (I was merely a maintainer, not the owner), it was removed when I went on hiatus. Thus you will need to join the translation team again to receive announcements. (udevil’s server was not affected.) The server currently contains the translation which were pushed to the next branch on April 28, 2014. If you changed translations after that date, they will not appear on the server, but if you have the po file you can upload it again. (Users may want to email their translator to let them know all this – see Help|About in SpaceFM.)
If you’ve never translated, note that Transifex makes it very easy. See instructions for translators.
SpaceFM 0.9.5 is currently being worked on, so if you know of any fairly urgent or critical issues, now is a good time to report them. (You can report any issues, but they may not be addressed in this release.) Same for udevil.
Thanks for your patience and participation.
Greetings! Just thought I’d check in from my extended hiatus and offer a few info items on SpaceFM.
My development work on SpaceFM and my other projects is still currently suspended, so no change there, but mostly they are still running as they were. I’ve been working elsewhere and have only been a user on Linux lately. I can’t tell you much about my plans, except that I am that much more determined to not ever run a system that includes systemd, especially seeing the direction it’s going (IP forwarding, etc), growing way beyond a safe and stable init system. Clearly many people aren’t happy with it, but they never were, and I doubt major distros are going to listen to their users. So I’ve been giving things some time to bubble, seeing what falls out of this mess as options.
When I have some free time, I may try gentoo without systemd, or I may try one of the BSDs. Let me know below if you’ve found a promising road away from systemd. My only real hesitation is my Brother MFC-4720 printer, which is a good printer but always hell to install, and I never could get it working on gentoo or BSD last I tried. But I’m told desperate times call for desperate measures. Once I find my next OS direction, then I will decide what if anything I want to do in the area of software dev. For now I’m just using SpaceFM on a retro Debian system, nice and quiet while all hell is breaking loose in Linux, but I think my days of using Debian are soon done.
A few notes on SpaceFM…
My thanks to previous SpaceFM contributor BwackNinja, who has been maintaining a maintenance fork of SpaceFM with a few bugfixes, plus he has added the ability to have transparent desktop backgrounds. Nice work there, so if you want to use that feature, you can grab the source, and if you have an urgent issue with SpaceFM, you might want to politely bring it to his attention. You are also still welcome to post issues to the main SpaceFM issue tracker, so others can review them, offer possible fixes, and I may eventually see them.
If you encountered an error in the console saying Attempt to unlock mutex that was not locked some months ago when starting SpaceFM, or were unable to start it, this was caused by an update in glib 2.41 which broke many GTK apps, especially when used with GTK 2.24.24. This problem was corrected upstream in the release of GTK 2.24.25, but still may affect some older versions of GTK2, as well as GTK3. BwackNinja’s fork includes a fix for this, and you can read more details here. Thanks to everyone who helped troubleshoot that in my absence!
Also, those using the IgnorantGuru PPA should have noticed a key expired error on my key. Rather than replace the key at this time, I have simply removed the expiration date from my public key (0x01937621), so it’s no longer expired, and have re-uploaded it to keyservers. You can get and add the updated key with these commands, and the PPA should work again:
gpg --keyserver keys.gnupg.net --recv-keys 0x01937621 # If you receive an error, try again later. # Then, add the keys to apt-key: bash -c 'gpg --export -a 01937621 | apt-key add -'
Alternatively, you can use the keyserver at keyserver.ubuntu.com, and it should migrate to others in time.
I haven’t been keeping up with Linux or SpaceFM discussions much, so if there’s something you want me to know (keeping in mind that I’m not currently working on these projects), some thoughts or resources you’d like to share with other SpaceFM users (the homepage directs them here and many users are subscribed), etc., now is your chance to leave your comments, links, etc. I’ll leave this thread open for comments for a few weeks. Also feel free to give any thoughts on anti-systemd migration – I’d like to know what people are using. Thanks and best wishes!
I will be beginning a hiatus from my public projects shortly, which means those projects will be suspended indefinitely, including development on SpaceFM and udevil, updates to this blog, and other little works. Suspended means all motion will stop, but most sites I maintain should remain accessible and unchanged. The duration of this hiatus is undefined. This may morph into a retirement, or I may restart some of it eventually in OpenBSD or another platform, or I may simply return and resume work on some or all of the projects.
If you are using SpaceFM or udevil, etc. and want to continue using them, I suggest doing so. Some distros may drop them automatically once they are ‘unmaintained’, but there’s nothing to stop you from using them indefinitely, and these are well-debugged at this point. Eventually some breakage may occur (eg GTK3), but there are probably enough people using SpaceFM now that someone can offer a patch if needed. It’s very easy to make and share a fork on github. I will also be using them myself, so if something major breaks I may come out of hibernation (like an angry bear woken early from slumber!) with an update.
With regard to Linux, I plan on falling behind the systemd wave in Debian, avoiding it. I may eventually move toward Gentoo, or over to one of the BSDs as well. But in avoidance of systemd, I won’t be keeping up with the latest edge of Linux for awhile, which makes for a poor developer’s environment. You’re welcome to join me, in which case SpaceFM and udevil should keep working as they are, even without current maintenance. To give you an idea, in the past six months I’ve needed to fix only a handful of bugs, none of them critical. So this isn’t abandoning ship, it’s more like setting sail for real.
I have weighed this decision carefully, because I know a lot of people really like SpaceFM, and I like to give projects decent support, even if free. I tried to put it on a back burner, but the project has too much energy and mass now for that, and I feel like I’m leaving people in limbo. So I decided to be realistic based on the last few months, and simply put these projects into suspension. I do sometimes continue such things, as I did last year after being on hiatus for several months. So overall, I again suggest that if SpaceFM works well for you, there’s nothing to stop you from continuing to use it indefinitely, supporting it indirectly, or forking it for any purpose.
This blog is now closed to comments in order to eliminate spam being added. If you would like to be informed of any temporary or permanent returns from my hiatus, you can subscribe for email updates. My other sites will shortly show ‘suspended’ notices just to let people know the status of projects. Yet I’ll do my best to merely freeze everything and keep it available. I may leave the issue trackers open, so any bugs can be tracked, yet note that only I have write access to the Github repositories I own, as well as this blog. The wikis should remain available for additions.
Thanks for all the support and interest, and good luck navigating.
Also see February 17, 2015 Update above for the latest info.
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)
SpaceFM 0.9.4 has been released. Please check out SpaceFM News for a few announcements and the changes to this version.
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?
I’m happy to announce that udevil is now available in Debian’s official testing and unstable repos. Thanks to Mateusz Łukasik for his work maintaining udevil and SpaceFM packaging on Debian, as well as his Ubuntu PPAs. For older Debian versions, you can still use the build-from-source packages in my PPA. Please see the updated Debian wiki page for details.
For those not familiar with udevil, it is a small tool that can simplify your system’s handling of devices, used by itself on the command line or within the SpaceFM file manager. udevil can replace need for udisks, consolekit, policykit, etc., creating a simple and easily configured system. udevil also includes the optional devmon automounting daemon, which will automount just about any device inserted, hassle-free, and can autostart apps and take other automatic actions you specify. Visit udevil Homepage