SpaceFM 1.0.4 Released

SpaceFM 1.0.4 was released today using the streamlined release and distribution methods previously announced. Packagers in particular should make note of new download locations. This release officially introduces SpaceFM’s new net installer (which can download, build and install any branch or version), and there are a few other new features and bugfixes.

Some code that did not make it into this release but is very usable can be tried in the ‘alpha’ testing branch. To install it, just run:

    spacefm-installer --version=alpha

(Even if you’re using a Debian package of SpaceFM, for example, you can run the above command to overwrite it, upgrading your version. This is a bit brutal but I do it all the time and you can always reinstall the repo package. If you keep both /usr/bin/spacefm executables (rename them), you can run either at will.)

The alpha branch contains some new features for faster loading of directories via background type loading, backgrounded calculation and display of deep sizes of directories, and some changes to the Refresh function. Especially the dir sizes have been a popular request for a long time, and now that I use it, it actually is a great feature to have.

Adding those features turned into a quagmire the last few weeks, mainly trying to get the threading stable. Even though my careful changes didn’t alter the threading code, the heavier load on the multi-threading revealed some ‘unmasked regressions’ which were not easy to reproduce, track down or correct (multi-threading can be very bizarre to work with – it creates some real head-scratchers). Due to some race conditions revealed, eventually I ended up redesigning some of the asynchronous thread handling modules.

While this seems to have improved the situation greatly, it still has some very obscure issues. These can cause crashes or hangs, usually only if you do something extreme like holding down the Refresh key with lots of tabs open, etc., and even that is very hard to reproduce. For normal use, you probably won’t encounter any instability, even if you try to force it to extremes. I dare ya!

So that turned into very frustrating code to work with, but sometimes that’s how it goes. I hope to make a few more minor adjustments, and OmegaPhil will be doing some memory testing for all our sakes, but for the most part it’s running solid.

The more early testing it gets in a variety of conditions, the smoother the release of this code will be. You can read the alpha details here. Thanks for testing.

New SpaceFM Net Installer, Changes To Distribution Sites

SpaceFM’s release methods are being streamlined, which affects where source packages may be downloaded from, what packages will be available, and the contents of assorted documentation and websites. Also, SpaceFM has a new interactive net installer which can download and install any version or branch of SpaceFM with a single command.

To use the new net installer (beta test), see the updated homepage instructions. This installer replaces the old self-extracting installer and self-building packages, which are no longer being produced after version 1.0.3.

IgnorantGuru’s PPA will no longer include spacefm or udevil packages (they will be removed shortly). If the official Debian packages don’t work for you or you want custom build options, the new net installer is recommended, or see the SpaceFM Debian Wiki for other options (if you find other solutions, feel free to add them to the wiki).

Sourceforge will no longer host copies of SpaceFM’s source archives, as Sourceforge is under new ownership and there have been some questionable malware practices with other projects. Plus, those files are no longer being created. However, SpaceFM’s forum will still be hosted on Sourceforge for now.

The new location for downloading source archives is Github Releases. Signed source archives and other packages are no longer being created. (If you want to check a GPG signature, see the new README.)

The README file has been rewritten, and contains some new sections, including on how to use git to get SpaceFM.

That’s a summary of the changes underway, and udevil will be seeing similar changes in a bit. For more details on the above changes, or to participate in testing, please see Issue #571.

Why? This project is several years old, and is suffering from a bit of sprawl in terms of sites managed, packages created, etc. In order to spend less time on overhead like that, the release process is being streamlined, and most of the work is now being done within git. This is also more feasible now that SpaceFM and udevil are more widely known and are available in most distros’ repos, meaning they can pick up the packaging work and I can focus on development.

SpaceFM 1.0.3 Released

SpaceFM 1.0.3 has been released, and you can see the changes. Main highlights of this release are that the icon chooser now works in GTK3 builds, and handlers can now be imported/exported, so custom ones you create can be shared on the wiki. Also, non-latin keyboard shortcuts should now work better, and some issues involving some terminals (lxterminal, urxvtc, konsole, gnome-terminal, lilyterm) have been addressed.

SpaceFM has seen some nice improvements the last few months (the 1.0 series), including OmegaPhil’s work on adding an icon chooser dialog. This allows you to select icons visually, which is nice because SpaceFM allows you to change any icon in the application, using almost any icon or image file. The toolbar has also been redesigned, allowing you to right-click directly on toolbar items to configure the toolbar using design mode. And the bookmarks pane was partially extended, now including submenus and separators, and allowing not just bookmarks, but commands and applications to be bookmarked there. Video thumbnails are supported along with extra large icons, plus a new Large Icons mode for detailed and compact list views. Finally, customisable handlers were added for devices, protocols, archives, and files. And all of this is now pretty well debugged and stable.

As promised, development on SpaceFM and udevil has been active but slower lately, but these are mature projects that have been running very well, and mostly bug-free. Critical issues that do arise are usually addressed promptly. The plan is to keep these projects running and bugfixed for the foreseeable future, with occasional feature additions and other developments.

Summer doesn’t usually inspire much coding from me or work at the computer – I’d rather be mountain climbing and hiking. And I’m still pondering which OS direction to take, mainly weighing OpenBSD vs systemd-free Linux choices. I will probably get into that more again in the coming months, and I’ll share anything good I find. For now progress in that area has stalled, but I’ve been enjoying the break and look forward to approaching it with a fresh perspective when I get to it.

Hope everyone is having a good summer/winter, depending your hemispheric preference. Feel free to drop any related Linux/BSD/GTK/etc news in the comments below.

Openwashing And Other Deceptions In Linux

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.

OpenBSD As A Linux Desktop Replacement

I recently tried out OpenBSD as a possible answer to recent Linux engineering. I thought I’d share my notes here on my results, from a beginner’s and Linux user’s perspective. (I tried FreeBSD briefly before as well.) If you’ve used OpenBSD more extensively on the desktop, your feedback on any of this is welcome too – I’d like to know what you think of my opinions, you being a longer-term user.

OpenBSD is a bit of a leap from Linux – not everything will be familiar, but it is UNIX-style, so some things feel the same. It was my thought that if OpenBSD desktop is ready, it might be worth the investment to go there directly, rather than fighting systemd and such in Linux distros. I’ve liked what I read about some of OpenBSD’s approaches to security. They ship a very simple, locked down, code-reviewed system, to which you add components. They don’t use SELinux or other similar technologies (which I think is wise), so they take a simpler approach. Compared to FreeBSD, which seems to be more open to systemd (you can see FreeBSD lead developers acclimating their users to systemd already, and trying to turn it too into a mobile thing), OpenBSD seems to be rejecting it thus far.

If you’re fairly familiar with setting up Linux systems, you can try out OpenBSD in a day, including reading some docs. The FAQ is a good place to start – seems to be their install manual. While OpenBSD is well-known for being meticulously documented, I find introductory documentation and explanation lacking. Simply put, it’s a bit difficult to figure out what the hell they’re talking about at times, because they make so many assumptions. There’s also a horrible lack of hits on Google for questions/problems compared to Linux. With the forums rumored to be intolerant of entry-level quesions, I suspect you’ll be largely on your own. Getting a decent book on OpenBSD is probably a good idea if you plan to use it seriously.

Yet the install is fairly simple. The boot CD just asks a few questions, and to most you can press Enter for the default. The tricky part is partitioning. The OpenBSD partition is split into slices with something called disklabel. So they basically use partitions within partitions. On my first install, when I told it not to use the whole disk, but to let me edit the MBR (partition table), it ran fdisk. I set a 10G partition to type A6 (OpenBSD), set the boot flag, and updated the MBR. So far so good.

Next it layed out the disklabel setup for that partition, breaking the partition into 5 or 6 slices with mount points (/, /tmp, /usr, etc). But later when I tried to install a few X apps, I ran out of space in /usr. Clearly their default partitioning for a smaller space is not well done. So I did the installation over, and chose a custom layout. It put me into disklabel, where I deleted all the slices except the root filesystem (/). (Also be careful not to delete ALL the slices, because some seem to refer to other partitions on the drive – just delete the ones with mount points.) Saving changes, it continued with the installation okay. This way the whole root filesystem is in one slice. It’s okay to do this (slightly less secure as they explain in the FAQ), and later you can repartition if you know how you want the space shared.

So basically the partitioning requires a little adjustment and reading, and use of fdisk and disklabel. They could improve this with a few simple typical setups – how many variations are there really for most users? Either you do a whole disk install, or just want it on a smaller partition. Also, I updated the MBR boot code in fdisk, making the system boot directly into OpenBSD, but you can also tell grub to boot a BSD partition.

Next it boots into an xdm login (if you told it to boot into X in the install). I pressed Ctrl-Alt-F1 to get a root prompt, create a user, and add some software.

The package manager is easy and simple, and they recommend using packages (versus ports, which create packages from source, similar to gentoo or Arch). However, they have an odd release method, which I’m not sure works well, and which their FAQ explains poorly.

The ‘release’ branch is what they release every six months, and is never updated otherwise. It quickly accumulates security advisories. These are corrected in a ‘stable’ repo. But the ‘stable’ repo is only available as source (ports), not binary packages. People generally recommend that you start with ‘release’ and manually patch bugs as needed. They claim you learn the system better doing this.

So there’s no packages branch comparable to Debian’s stable, where security fixes are added. That is clearly something missing, as evidenced by the fact that a third party now offers pre-built packages for the ‘stable’ branch. The ‘release’ branch is already open to a serious Xorg bug that lets a normal user run arbitrary code as root (Red Hat is doing a great job – and notice how OpenBSD too is susceptible to their ‘bugs’ through Xorg). So you pretty much need to run a manually patched ‘release’ branch, staying attuned to security notices, or run the full ‘stable’, building everything from source (or third party packages).

There’s also a ‘current’ branch, and this is rolling release. It’s packaged in binary ‘snapshots’, similar to Debian unstable. But I didn’t immediately see any instructions on how to switch to using ‘current’ – there seem to be a few manual changes required. Some people do say they use ‘current’, but it’s also considered a more advanced use. You also have to update the whole system, you can’t just update pieces and expect it to work. So using ‘current’ looks more maintenance intensive as well, and may require more experience.

The update/upgrade path seems primitive too – more manual steps required. Generally it all seems geared to servers that want stability while being able to patch minimally.

All of that said, the package/ports system does seem clean and simple, as does OpenBSD overall. Longer-term users seem to like their ability to maintain their system, so I suspect once you get used to it, it works well. It may require more knowledge, but it also doesn’t change much. Overall I’d say it looks usable.

So I installed some packages:

    pkg_add openbox dillo geany nano roxterm geeqie gnash gimp \
        libreoffice vlc mpv imagemagick htop jhead smplayer file-roller \
        gnash claws-mail filezilla pdnsd bash pcmanfm firefox xchat

A few things I couldn’t find in their packages: deluge, gftp, flashplugin-nonfree, and spacefm

Adobe Flash is pretty much unavailable, unless maybe you get into some i386 linux emulation for it. Hard to find answers on how *BSD users handle this, but the preferred methods seem to be to use programs that download videos so you can play them in mplayer, or to use HTML5 on Youtube (see Firefox’s ‘All HTML5’ plugin). Yet while HTML5 works for me in Linux, it just showed a black box in Firefox on OpenBSD. Nor would Gnash work – it locked up Firefox with network errors in stderr. So in my brief attempts I didn’t find any in-browser support for Flash sites.

I also tried the Dillo web browser. It’s a very simple browser – doesn’t look like it has javascript – but for browsing simpler sites it’s much faster than Firefox, and has a nice look.

I also found that Firefox ran more slowly, and programs seemed to start slowly. Overall the system didn’t seem fast. This seems to be a known issue of OpenBSD on the desktop (some attribute it to scheduling).

Another issue I encountered was my laptop hard drive powering down every 1 or 2 seconds. Linux had this problem too, but there is no hdparm or sdparm for *BSD. The closest I found was atactl, and I eventually solved the problem like this:

    atactl sd0 apmset 253  # use 127 to 253 for no standby

I didn’t actually try openbox, I just logged into a plain X session and started some programs from xterm. PCManFM did run, but did not show any devices. After inserting a USB stick to try playing a movie in mpv, I realized I didn’t know how to mount the USB stick, or even what its device name would be. So I never got to try that.

As far as a possible port of SpaceFM to *BSD someday, it looks promising. SpaceFM depends on only glib, gtk, and udev (and inotify in the kernel, but I did see gamin on OpenBSD, and SpaceFM can use gamin instead of inotify already). udev code would have to be removed from the build, and there is no HAL either. To show and detect device changes, it might need to do some polling for something like sysfs, not sure. But with SpaceFM’s Device Handlers and overall design, I think it would make an excellent conversion to a BSD file manager. Also, people were saying there is no Brasero, so what will they use to burn, but SpaceFM can be used as a burning app. That and other automation, as well as its few dependencies, makes it a good candidate for a *BSD port.

Hardware seemed to be detected well in OpenBSD – and it has a good reputation for this, in some cases better than FreeBSD. My ATI video seemed okay and required no initial tweaking, though I didn’t see it play any video. (Nvidia is less supported on BSD, from what I read. That’s seems true on Linux too.)

Overall, OpenBSD looks like it’s usable for my purposes, minimally. It doesn’t seem quite ready for full-featured desktop use unless you’re willing to keep things very simple, have more limited web, and limited software choices (but still quite a few – you’ll have a lot of Linux there with you). I also have some speed concerns, but the laptop I tried it on isn’t very fast.

OpenBSD reminds of some of the earlier versions of Linux I tried a few decades ago, before it really became Ubuntu-easy to install and maintain. It’s also similar to Arch Linux, yet with less software and less information available.

I read that many of the OpenBSD developers actually use other OSes for their desktop – even among them it’s not the most popular desktop OS. If true, that also means they don’t optimize it for that (because they simply won’t encounter the issues). Plus it is designed for servers.

I also tried FreeBSD some time ago, and that is similar. My impressions are that somewhat more software is available for FreeBSD, there are more Linux-like forums for discussion, there is more on Google when you have a problem. I think more people are using FreeBSD on the desktop. However, FreeBSD developers also seem to be more accepting of Red Hat’s engineering, Adobe Flash (a security nightmare we’re all better off without, except that they have made it hard to avoid), complex and poorly reviewed things like SELinux, and other questionable choices. OpenBSD on the other hand seems to avoid the Red Hat camp actively and wisely.

Having given OpenBSD that initial try, I have decided that it’s still a candidate, but that it seems a little too primitive on the desktop yet, and that I would be giving up quite a bit without getting much in return, in terms of my needs. It also means learning new BSD filesystem tools, backup tools, porting my file manager, and other differences between BSD and Linux.

So now I’m thinking that a good systemd-free Linux distro may be the more usable and convenient route for now, maybe keeping an eye on OpenBSD development for longer-term. I think my next stop is going to be Gentoo. I tried Gentoo a few years ago, and I liked it overall. The USE flags setup can be a bit much for the newcomer (I wish they would choose some reasonable defaults). I also had a problem with momentary hangs of the whole system, which is really annoying. This appeared to be a possible scheduling issue. Hopefully that won’t recur. I also had problems with my Brother laser printer driver, but I see they have some new ‘overlays’ for similar printers, so maybe that will be improved. (I’ve decided not to make the printer a critical issue.)

I liked what I saw of the Gentoo community in response to systemd, with eudev, etc. They seem to have many genuine contributors, flexibility, and a policy that allows it, so I think that will be a boon in countering some of the upcoming power plays in Linux.

While BSD looks promising, there is a lot of software and work that has gone into Linux, and it seems unfair to have to dump it all just because of things like systemd. Maybe with something like Gentoo’s flexibility it will be possible to move it forward on another track. Gentoo also has good security protocols, so I look forward to trying it out again.

If you’re looking for systemd-free Linux distros, there’s a large list at Without systemd.

UPDATE: Speaking with a few OpenBSD people in email, I can clarify a few things which I didn’t find to be clear in the FAQ. In OpenBSD, the OS is not part of the ports or packages systems, unlike in Gentoo or Arch, for example. The OS is built separately from a CVS tree, manually. Or patched manually. Or, you install or reinstall the system using the install ISO (or manually extract the files). That is also how you switch from release to current – you must reinstall. Software is updated via ports (like Gentoo) or packages (like Arch).

Also, OpenBSD was not as vulnerable to the Xorg bug I mentioned because it doesn’t run Xorg as root! In fact it runs it with even less privs than a normal user. Great work there!

And, according to one person who seemed to know, OpenBSD developers are commited to using OpenBSD on their own desktops, because they want to improve it. FreeBSD is where they tend to not use it as much on their own computers. That’s encouraging to hear.

Overall, I probably gave a more negative impression of OpenBSD than I intended. In general it looks good in many ways, even on the desktop. Probably comparable to Arch or Gentoo in terms of setup and maintenance challenges. I’m still weighing it, and I think it’s worth getting to know.

Red Hat / Gnome Developers Censoring GTK+ Bugtracker

I submit the following for your review because it’s an interesting case study in how Red Hat developers are running the GTK+ bugtracker, censoring non-flattering input, and misusing their code of conduct. Since they deleted several of my comments, and threatened another participant merely for using the word “overengineered” (lol – if the shoe fits…), I thought it might be valuable to bring what they deleted to larger attention.

I and the others involved are not the only people who are treated this way by these developers. But most people will back down because they don’t want to be banned and censored, which I can understand, but it creates an atmosphere where there can be no open discussion of larger issues facing GTK+. But I don’t have to kiss ass, and they have never once done anything useful in response to bugs I have tried to get them to fix. In fact I don’t think they’ve ever taken an action that has benefited libre software at all. They are an obstacle – some great upstream to have on your GUI toolkit.

If you plan to use GTK on a new project, don’t. Unless you’re part of Gnome, this is the kind of support environment you can now expect. And do not be fooled by their “please submit a patch”. First, why are they demanding that API users fix their low-level I/O bugs? Second, even the person asking for the patch has no authority to include it – they are more like (ARE) a corporation’s customer service representatives that are there to merely give people the runaround.

The case in study is a bug report regarding the way the GTK+ file chooser (file browser) only shows FUSE mounts made by gvfs, and is blind to those made by almost all other file managers. This is a simple bug. All that needs to be done to fix it is add the traditional location used for fuse mounts to the heuristics – a 5 minute job. Yet instead of simply fixing it, first a Red Hat employee immediately closes it as “RESOLVED WONTFIX” with a “No.” Then after I point out some details, they reopen it, but embroil it in a huge debate about gvfs dependency and udisks, which has nothing to do with this simple bug. As such, they are obstructing, not resolving anything. When their inaccurate gvfs dependency information is pointed out, they delete the comment. Further, it’s revealed that it’s broken in the first place because someone inserted a hack for gvfs into gio, breaking the chooser for non-gvfs use. When this is pointed out, they delete the comment.

You should recognize some of the names involved from previous articles on this blog. Emmanuele Bassi states he doesn’t work for Red Hat. I don’t know who he does work for, but he is very prominent in Red Hat’s projects (allegedly open and free projects, but in which Red Hat dictates all decisions), and he seems to be given carte blanche by them administratively, for whatever reason.

Here is the full thread, with comments deleted by Red Tape restored and indicated.

---

GNOME Bugzilla – Bug 750182

GtkFileChooser should also search for mountpoints in $HOME/.cache

Last modified: 2015-06-04 13:21:15 UTC

Summary: GtkFileChooser should also search for mountpoints in $HOME/.cache

Status: REOPENED

Product: glib

Component: gio

Assigned To: gtkdev

Description Psy[H[] 2015-05-31 19:30:12 UTC

$HOME/.cache is a logical place for applications to place user-level mountpoints such as FUSE filesystems. Those should be visible in GtkFIleChooser.
Right now it seems to exclude all hidden dirs in $HOME from mountpoint search. $HOME/.cache should be whitelisted.

Comment 1 Matthias Clasen 2015-06-01 16:06:23 UTC

No. XDG_CACHE_DIR has defined semantics that don’t match mounting things.

[ Marked RESOLVED WONTFIX ]

Comment 2 IgnorantGuru 2015-06-02 15:18:22 UTC

I realize that GTK development is effectively dead for non-Gnome projects, but you may wish to consider that several widely used XFCE and LXDE file managers which use GTK, such as Thunar and PCManFM, as well as other programs, do mount fuse and network filesystems in XDG_CACHE_DIR, and have done so for years. This is common usage, and not every GTK project follows Freedesktop specs to the letter (specs which are poorly maintained and often incorrectly documented and implemented). fuse filesystems are mounted in a user-writable directory, usually somewhere $HOME, and it’s poor form to create non-hidden directories in the user’s home. The file chooser as it stands apparently ignores all hidden directories, which doesn’t leave good options.

Since the GTK File Chooser does discovery of mounted volumes, and since the .cache location has been commonly used for this for years, it would be helpful to the general set of software which uses GTK if the chooser listed volumes mounted in these common locations as well as those used by Gnome/Freedesktop. Otherwise it is blind to them and fairly useless outside of Gnome.

Just quoting the specs and ignoring common usage to avoid updating it just makes the file chooser irrelevant for real uses. Is GTK now documented as a Freedesktop/Gnome-only project? You have several non-Gnome file managers using GTK, so perhaps supporting their uses as well as Gnome would be appropriate.

Comment 3 Matthias Clasen 2015-06-02 15:41:20 UTC

> Right now it seems to exclude all hidden dirs in $HOME from mountpoint search.
> $HOME/.cache should be whitelisted.

The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.

> GTK development is effectively dead for non-Gnome projects

GTK development for non-gnome projects depends on developers from those projects participating and making their needs heard.

> The file chooser as it stands apparently ignores all hidden directories, which > doesn’t leave good options.

That is not true.

Comment 4 IgnorantGuru 2015-06-02 15:48:43 UTC

> The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.

Then how is it that the GTK file chooser still finds volumes even when gvfs is not installed? (In case you didn’t know, GTK can be and is used without gvfs.)

> GTK development for non-gnome projects depends on developers from those projects participating and making their needs heard.

We are doing so here, and as usual, those needs are summarily dismissed if not coming from Red Hat.

> That is not true.

Perhaps you can clarify, since the file chooser documentation says nothing.

Comment 5 Psy[H[] 2015-06-02 16:18:25 UTC

> The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.

I can confirm that I do not have any gvfs package in my system, but GtkFileChooser still successfully finds mountpoints in /media, /run/media/$USER, $HOME/ (excluding hidden dirs).

> No. XDG_CACHE_DIR has defined semantics that don’t match mounting things.

Is there any standardized place for user-level mounts that won’t noticeably interfere with user’s home dir but GtkFileChooser would find?

Comment 6 Matthias Clasen 2015-06-02 16:39:14 UTC

(In reply to Psy[H[] from comment #5)
> > The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.
>
> I can confirm that I do not have any gvfs package in my system, but
> GtkFileChooser still successfully finds mountpoints in /media,
> /run/media/$USER, $HOME/ (excluding hidden dirs).

GIO has code to find mounts. I don’t know if it avoids hidden directories.

> > No. XDG_CACHE_DIR has defined semantics that don’t match mounting things.
>
> Is there any standardized place for user-level mounts that won’t noticeably
> interfere with user’s home dir but GtkFileChooser would find?

I’ll move this bug to glib – I’m not 100% sure what heuristics gunixmounts.c applies when looking for mounts.

Comment 7 Emmanuele Bassi (:ebassi) 2015-06-02 16:54:53 UTC

(In reply to Psy[H[] from comment #5)
> > The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.
>
> I can confirm that I do not have any gvfs package in my system, but
> GtkFileChooser still successfully finds mountpoints in /media,
> /run/media/$USER, $HOME/ (excluding hidden dirs).
>
> > No. XDG_CACHE_DIR has defined semantics that don’t match mounting things.
>
> Is there any standardized place for user-level mounts that won’t noticeably
> interfere with user’s home dir but GtkFileChooser would find?

Non-system wide FUSE mount points should really go in the user’s XDG_RUNTIME_DIR; using XDG_CACHE_DIR is a known fallback used in the past when XDG_RUNTIME_DIR did not exist — but should really be ignored (e.g. GVFS will fall back to $HOME/.gvfs instead if it finds out that XDG_RUNTIME_DIR is XDG_CACHE_HOME, since it’s where GVFS mounts FUSE file systems).

The strong suggestion is for file managers willing to interoperate with the system and various toolkits to follow the basedir specification; if the spec is unclear, asking on xdg-list yields timely replies.

(In reply to Matthias Clasen from comment #6)

> I’ll move this bug to glib – I’m not 100% sure what heuristics gunixmounts.c
> applies when looking for mounts.

g_unix_mount_guess_should_display() will discard system directories (like /proc or /sys), but only uses user-accessible mount points under /media and /run/media/$USER. The check for ‘/run’ is hard-coded, which is not right: it should get the XDG_RUNTIME_DIR environment variable instead.

Comment 8 Psy[H[] 2015-06-02 17:06:52 UTC

Thanks for comments!
GtkFIleChooser does not find mount in $XDG_RUNTIME_DIR/mountpoint (3.14.5-1).

Comment 9 Emmanuele Bassi (:ebassi) 2015-06-02 17:24:45 UTC

(In reply to Psy[H[] from comment #8)
> Thanks for comments!
> GtkFIleChooser does not find mount in $XDG_RUNTIME_DIR/mountpoint (3.14.5-1).

It won’t, as I said in comment #7.

If no GVFS is present, the fallback code will list the Unix mounts coming from /proc/mounts or /etc/mtab; each mount point will be checked via g_unix_mount_guess_should_display(), which will return TRUE for user-accessible mount points under /media, /run/media/$USER, or directly under $HOME.

If you want your mount points to be visible in the GTK file chooser and you don’t have GVFS running, you should mount them under “/run/media/$USER”.

The bug in GIO is that the code doing the check hardcodes /run instead of using XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is unset, it should fallback to XDG_CACHE_DIR (which is what g_get_user_runtime_dir() does), but that would mean that the FUSE mount points would go under XDG_CACHE_DIR/media/$USER, which is a bit ridiculous.

Hence my suggestion is to set XDG_RUNTIME_DIR to /run and create the /run directory at system start up, and remove it at system shutdown, following the basedir specification recommendation.

Comment 10 Psy[H[] 2015-06-02 17:31:36 UTC

/run/media/ AFAIK is usually created by udisks, and here are two difficulties:
– udisks moved mounts to /media/$USER/
– udisks is not installed on every system.

Since /run is not user-writable, there could be no tool to create /run/media/$USER in the system.

Comment 11 Psy[H[] 2015-06-02 17:35:21 UTC

According to spec, $XDG_RUNTIME_DIR should be owned by user, it can not be set to /run.

Comment 12 Psy[H[] 2015-06-02 17:38:37 UTC

As far as I can tell, $XDG_RUNTIME_DIR is typically resolved into /run/user/$UID
700 permissions are mandatory by the spec.

Comment 13 Psy[H[] 2015-06-02 17:51:07 UTC

/run/user/$UID is a tmpfs mount by itself. Maybe that is why GtkFileChooser does not see other mounts inside, despite it looks into /run. If that is so, then search logic should be changed to search through tmpfs mounts for user’s mounts in case of $XDG_RUNTIME_DIR

Comment 14 IgnorantGuru 2015-06-02 18:01:56 UTC

Based on traditional use, gio should look in XDG_CACHE_HOME for mounts, regardless of the current specs. For example, file managers traditionally mount fuse to ~/.cache/program-name/mount-point. This makes some sense since XDG_RUNTIME_DIR used to (or does?) fall back to a cache dir.

The point here is not to design a spec from scratch (yet again), but to realize that there are already many GTK apps using that location for mounts (with users trying to find mounts in that location), based on traditional use. If you merely support a new spec then the file chooser still won’t show mounts created by most file managers in use. In other words, it won’t have practical value, no matter how spec-compliant. It seems like the only exception you support is gvfs’s ~/.gvfs, ignoring traditional use of fuse.

Arguing what’s theoretically best while ignoring what’s already in use and established is not of any practical value. This means GTK’s file chooser will continue to be blind and useless for finding mounts, unless it searches XDG_CACHE_HOME to a reasonable depth.

Comment 15 IgnorantGuru 2015-06-02 18:08:19 UTC

Also, “XDG_CACHE_DIR” isn’t even in the spec, you apparently mean XDG_CACHE_HOME, so it’s not helping clarity by referring to non-existent variables. eg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736448

Comment 16 OmegaPhil 2015-06-02 18:52:06 UTC

I would also appreciate XDG_CACHE_HOME being consulted for mounted filesystems.

Comment 17 IgnorantGuru 2015-06-02 21:26:50 UTC

> Non-system wide FUSE mount points should really go in the user’s XDG_RUNTIME_DIR; using XDG_CACHE_DIR is a known fallback used in the past when XDG_RUNTIME_DIR did not exist – but should really be ignored (e.g. GVFS will fall back to $HOME/.gvfs instead if it finds out that XDG_RUNTIME_DIR is XDG_CACHE_HOME, since it’s where GVFS mounts FUSE file systems).

Why should it “really be ignored”, when it “is a known fallback used in the past” (iow it is still widely used)? That is the real source of this bug – that gio included a gvfs-specific hack, breaking Freedesktop. If g_get_user_runtime_dir() falls back to XDG_CACHE_HOME, then that is what should be searched. Nowhere in Freedeskop does it mention “~/.gvfs”, and I doubt glib suggests ignoring g_get_user_runtime_dir().

Most glib apps will not read XDG_RUNTIME_DIR directly, they will use g_get_user_runtime_dir() – that’s what it’s for. It does indeed fallback to “~/.cache” on Debian at least. In fact this is probably why mounts have been placed there for years by many file managers, and why the chooser is blind to those mounts – it’s not looking in XDG_RUNTIME_DIR or its glib fallback and predecessor, XDG_CACHE_HOME.

> but that would mean that the FUSE mount points would go under XDG_CACHE_DIR/media/$USER, which is a bit ridiculous.

No, it would generally mean mounts are placed beneath XDG_CACHE_HOME, such as XDG_CACHE_DIR/Thunar/mount-point (which is exactly the case). Apps can use the cache as they please. Discovery should be reasonably general, not specific to just gvfs behavior and hacks.

So the question is, why does gio switch to a gvfs hack instead of searching for mount points in g_get_user_runtime_dir() ? If you want to include gvfs hacks in gio’s discovery, so be it, but you should not break existing apps that are using g_get_user_runtime_dir() without such hacks.

So I think the proper behavior is to search g_get_user_runtime_dir(), at least down to a few subdirs. That will fix this bug and also preserve discovery of common mount points (which will continue to be created in ~/.cache for years in practice, even if you now change the spec to match gvfs hacks). For even better discovery, it should look expressly in ~/.cache in addition to XDG_RUNTIME_DIR/XDG_CACHE_HOME, since that location is commonly used. The whole point of mount point discovery is convenience, not contrived spec compliance (and hacks) to the point where it only works with a small subset of systems. That’s why the file chooser is blind – you’re basing it on theory rather than actual practices, which isn’t much good for discovery.

Comment 18 IgnorantGuru 2015-06-02 21:44:22 UTC

Also, you may want to consider that the reason /run was hardcoded is that XDG_RUNTIME_DIR may rarely be set. It isn’t in Debian, and g_get_user_runtime_dir() returns “/home/user/.cache”.

Also, if XDG_RUNTIME_DIR defaults to /run/media/$USER on some systems, that may not be appropriate for fuse mounts. And /run does not allow the user to write to it, again no good for fuse mounts. XDG_RUNTIME_DIR is also sometimes set to /tmp, which may have noexec and other restrictions. These are reasons why file managers may use XDG_CACHE_HOME as a more reasonable default, and why the chooser should search all locations. Personally, I’ve never seen such mounts in /run, except by root daemons such as the old udisks2 behavior (which was eventually deemed non-FHS compliant and moved elsewhere).

All of that said, for practical discovery, it would be smart to search /run (hardcoded), XDG_RUNTIME_DIR, XDG_CACHE_HOME, AND $HOME/.cache, if they differ.

Comment 19 Emmanuele Bassi (:ebassi) 2015-06-02 21:45:36 UTC

(In reply to OmegaPhil from comment #16)
> I would also appreciate XDG_CACHE_HOME being consulted for mounted
> filesystems.

I would gladly review a patch that added that to the checks inside g_unix_mount_guess_should_display(). I’m not a GIO maintainer, though, so you will need somebody else’s ACK for it.

(In reply to Psy[H[] from comment #10)
> /run/media/ AFAIK is usually created by udisks, and here are two
> difficulties:
> – udisks moved mounts to /media/$USER/
> – udisks is not installed on every system.

To be absolutely blunt, not installing components and then complaining that things are broken is not really cool. It’s not like we want to duplicate the logic everywhere: we put it inside some component for a *reason*. GIO depends on GVFS on Linux, and GVFS depends on udisks. If you’re using some other OS, the chain of dependencies is different, but we kind of treat the stack as a stack, not as a pick and mix bowl of “may be nice to have”. The reason the dependency is “soft” (i.e. we don’t make GIO depend some libraries) is mostly a case of 1. historical accidents; 2. a convenience for integrators to avoid dependency cycles; and 3. because on Windows, *BSD, or MacOS, the dependencies are fairly different.

In any case, there’s nothing that says that udisks *must* be the component creating the /run/media/$USER directory.

Finally, /media is also another location that is checked when going through the list of mount points.

> Since /run is not user-writable, there could be no tool to create
> /run/media/$USER in the system.

Anything that creates /run can also create /run/media/$USER when the user session starts; since it’s going to be a privileged user, it can change the directory’s permissions as well.

Anyway, I’ll stand by what I wrote at the top: I’ll gladly review a patch that adds a check for a user-accessible mount point under XDG_CACHE_HOME.

Comment 20 IgnorantGuru

COMMENT DELETED by André Klapper

> To be absolutely blunt, not installing components and then
> complaining that things are broken is not really cool. It’s not like
> we want to duplicate the logic everywhere: we put it inside some
> component for a *reason*. GIO depends on GVFS on Linux, and GVFS
> depends on udisks.

Actually, you’re being absolutely inaccurate. gio does not depend on gvfs – it is part of glib and runs fine without gvfs. Perhaps you should review what a dependency is. From your own docs: “One of the big advantages of putting the VFS in the GLib layer is that GTK+ can DIRECTLY use it, e.g. in the filechooser.”
https://developer.gnome.org/gio/stable/ch01.html

Iow, GTK+ does NOT depend on gvfs for a reason. The point of putting it in the glib layer was to avoid GTK+ dependencies on DE-specific filesystem abstraction layers like gvfs. I really [sic – realize] Red Hat has done everything in their power to break that separation and create a monolithic stack, but for now glib is not gvfs dependent.

> Finally, /media is also another location that is checked when going
> through the list of mount points.

That’s not useful for fuse, since the user cannot write to /media, and not all systems use acls.

> Anyway, I’ll stand by what I wrote at the top: I’ll gladly review a
> patch that adds a check for a user-accessible mount point under
> XDG_CACHE_HOME.

So no gio maintainers are willing to maintain gio to correct gvfs hacks they included that break Freedesktop, even though they’re the ones who broke it in the first place. Thanks for being predictable.

Perhaps you can point us to the gio discovery function at least? Or is that too much trouble too? But I doubt I would waste time on coding as I’m sure you’ll just make an excuse to reject it, just as you’re making excuses instead of fixing this bug.

Comment 21 IgnorantGuru

COMMENT DELETED by André Klapper

For people who don’t know the history on this, modern GTK devs (iow Red Hat – some of the same names we see here) tried desperately to make GTK dependent on gvfs. However, it broke everyone’s work and gvfs didn’t work everywhere, so they were forced to backtrack. To no one’s surprise but theirs, GTK still runs just fine without gvfs (except where they deliberately break it, like this gvfs hack interfering with other software), but I’m sure it’s still their agenda to make it a dependency just because they want it to be, and the inaccurate information being given here is right in line with that history.

So basically gio is only now supported for gvfs use at most – they won’t even think of making or accepting any changes which help other general users of GTK. And I’ve heard this “please submit patches, test cases, more info”, etc. before from these same people. That is their way of just ignoring you – they’d rather waste your time than tell you flat out that they refuse to support gio (or really GTK), and won’t accept any changes that do so. At least that has been the pattern of behavior.

Comment 22 Psy[H[] 2015-06-03 08:25:21 UTC

> To be absolutely blunt, not installing components and then complaining that things are broken is not really cool.

I also disagree, GTK has nothing to do with with udisks. Only gvfs-daemons has dependency on udisks, and we are not touching that here.
Plus, udisks does not use /run/media/$USER anymore anyway. And /media/* is not user-owned, so it’s no good for fuse.

$XDG_RUNTIME_DIR also seem to be only maintained by systemd-related components which is not universal. So, fallback to $XDG_CACHE_HOME or $HOME/.cache seems reasonable.
There are no non-homedir user-owned locations that do not depend on optional overengieered stuff like udisks, gvfs, systemd, etc.
$XDG_CACHE_HOME or $HOME/.cache is the only 100% backwards compatible fallback.

Comment 23 Emmanuele Bassi (:ebassi) 2015-06-03 08:54:58 UTC

(In reply to IgnorantGuru from comment #21)
> For people who don’t know the history on this, modern GTK devs (iow Red Hat
> – some of the same names we see here)

This will be the only time I reply to one of your comments, and it’s also your final warning. Bugzilla is under the code of conduct of GNOME, and you have been consistently rude, dismissive, and flat out insulting in every single interaction with the developers.

Either you stop, or you get your account revoked.

Comment 24 Emmanuele Bassi (:ebassi) 2015-06-03 09:06:39 UTC

(In reply to Psy[H[] from comment #22)

> > To be absolutely blunt, not installing components and then complaining that things are broken is not really cool.
>
> I also disagree, GTK has nothing to do with with udisks.

As you may have noticed, it does.

> Only gvfs-daemons
> has dependency on udisks, and we are not touching that here.

GIO has a soft-dependency on GVFS; the reason why GIO does not implement the functionality of GVFS directly inside its code base is one of expedience and historical reasons; GVFS had to be implemented as a separate code base to avoid adding dependencies to GLib. Nevertheless, on Linux, GIO is pretty much dependent on the functionality provided by GVFS, and it falls back to internal implementations, but the fall backs are not heavily tested.

> Plus, udisks does not use /run/media/$USER anymore anyway.

Nevertheless, /run/media/$USER is what modern Linux uses for user-accessible mount points — including FUSE.

> And /media/* is not user-owned, so it’s no good for fuse.

At no point I’ve said that FUSE mount points should go under /media; I’ve just listed /media as another location used.

> $XDG_RUNTIME_DIR also seem to be only maintained by systemd-related
> components which is not universal.

It should be universal, and it’s not systemd-related; that’s why it’s in the basedir specification on fd.o.

XDG_RUNTIME_DIR was introduced because XDG_CACHE_HOME is not a good place for storing session-related files in a secure way. Please, read the discussion that led to the creation of XDG_RUNTIME_DIR:

http://lists.freedesktop.org/archives/xdg-list/2010-November/011681.html

> So, fallback to $XDG_CACHE_HOME or $HOME/.cache seems reasonable.

As I said (and I won’t say it again), I’d gladly review a patch that adds this; you’ll have to also convince a GLib/GIO maintainer. You should join the #gtk+ channel on irc.gnome.org.

> There are no non-homedir user-owned locations that do not depend on optional
> overengieered stuff like udisks, gvfs, systemd, etc.

Please, refrain from making comments like these in the future. The reason why things like GVFS or udisks are complex systems is because they solve real problems. If you decide to not use them because your requirements are simple or unchanging it does not invalidate the problems and requirements of people actually using them.

Comment 25 André Klapper 2015-06-03 12:39:34 UTC

Psy[H[]: See comment 23 and read https://wiki.gnome.org/CodeOfConduct . Thanks.

Comment 26 Psy[H[] 2015-06-03 15:05:19 UTC

GtkFileChooser can successfully look for mounts without udisks and gvfs installed. The sole purpose of this bug report is to tweak existing behavior.
At least to look into $XDG_RUNTIME_DIR according to basedir spec.
just like Emmanuele Bassi said:

> g_unix_mount_guess_should_display() will discard system directories (like /proc or /sys), but only uses user-accessible mount points under /media and /run/media/$USER. The check for ‘/run’ is hard-coded, which is not right: it should get the XDG_RUNTIME_DIR environment variable instead.

As for $XDG_CACHE_HOME, I’ve asked about proper XDG_RUNTIME_DIR fallbacks on XDG mailing list, waiting for reply.

Comment 27 OmegaPhil 2015-06-03 19:33:12 UTC

Responding as I was quoted here – sorry but I’m not the maintainer, I have my own projects I’m struggling with (feeling the pain of C++…) so I won’t be working on a patch (ha, at least currently with my progression I doubt I could make such a patch and have it pass muster). The problem is simply occassionally annoying for me, its not a big deal.

I see IG’s post has been deleted, censorship is unacceptable (for the record I have no interest in a ‘code of conduct’, if you see shit you call it out, although currently I don’t have any personal grudge here). This is the correct place to discuss and hash out problems and presumably should act as the public record, so I’ve summarised IG’s points here without his anger at least (to preempt things, just because you don’t like this doesn’t mean the information is not useful for others coming to this ticket):

o GTK is not supposed to be dependent at all on GVFS.
o In recent times, Red Hat developers have attempted to make it dependent (e.g. the ‘soft dependency’ mentioned previously).
o This broke a lot of things, thus a more serious dependency had to be backtracked.
o With the current situation and this bug, it looks like the maintainers don’t care to be compatible/accessible with client software that already has well-established behaviour, and is not involved with the GNOME software stack.

Basically hes very concerned that with this and other issues, important core software is being stolen away from normal non-GNOME usage.

Comment 28 Emmanuele Bassi (:ebassi) 2015-06-03 20:03:07 UTC

(In reply to OmegaPhil from comment #27)

> I see IG’s post has been deleted

Nothing has been deleted; he removed himself from the Cc: of this bug. Stop spreading false accusations.

> censorship is unacceptable (for the record I have no interest in a ‘code of conduct’,

It does not matter if you have no interest: the code of conduct for GNOME services exists, and it’s enforced on Bugzilla.

> if you see shit you call it out,

No, it does not work that way.

You behave like a decent human being, and you afford some level of courtesy to the people that work on the stack that you use. You assume people mean well, and you treat them like intelligent people that are trying to solve problems and work on an open, volunteer-driven project.

> o GTK is not supposed to be dependent at all on GVFS.

While GTK does not depend on GVFS, GTK depends on a set of functionality that is *implemented* by GVFS. If nothing implements it, then GTK simply will fall back to a subset of that functionality.

> o In recent times, Red Hat developers have attempted to make it dependent
> (e.g. the ‘soft dependency’ mentioned previously).

Red Hat does not enter in the picture; I’m not a Red Hat employee. You can leave you conspiracy theories at the door.

> o This broke a lot of things, thus a more serious dependency had to be
> backtracked.

This has broken nothing. Not showing FUSE mount points from random, unspecified locations that just so happen to be used by some project is not a break in functionality.

> o With the current situation and this bug, it looks like the maintainers
> don’t care to be compatible/accessible with client software that already has
> well-established behaviour, and is not involved with the GNOME software
> stack.

I’ve said *multiple* times that I’ll gladly review a patch; I also said that, while I routinely work on the G* core platform, I’m also not a GIO maintainer, thus I cannot guarantee that the patch I review will be integrated. You can try and convince a GIO maintainer — join IRC and state your case.

What I’m not going to do is write the patch for you, since I don’t have any issue with the current stack, and I also have other projects — as well as work — that I maintain and have to care about.

Since the people in this bug use applications that do not conform to the basedir specification it’s entirely up to them to pursue a fix in GIO.

> Basically hes very concerned that with this and other issues, important core
> software is being stolen away from normal non-GNOME usage.

Honestly, if 1% of the energy spent finger-pointing, complaining, and resorting to rude and unfounded accusations were instead spent writing the patch in question, we could have closed this bug already.

Comment 29 OmegaPhil 2015-06-03 20:09:42 UTC

Take a look at the page here: https://bugzilla.gnome.org/show_bug.cgi?id=750182

You quoted his post that has been removed – I searched the page for ‘history’ and found his post had gone – thats all.

Literally, I don’t have strong feelings for this, I have just posted his points and you have responded, which is fine.

Comment 30 André Klapper 2015-06-04 13:20:21 UTC

[offtopic]

(In reply to OmegaPhil from comment #27)
> I see IG’s post has been deleted, censorship is unacceptable

Your interpretation of “censorship” is incorrect. See http://xkcd.com/1357/
In the GNOME community, the GNOME Code of Conduct applies.
(And technically, I have hidden two postings from being shown to non-admins.) [He says this after they stated previously that nothing was deleted – always nice to be technically accurate while you’re lying.]

GNOME Bugzilla is indeed the correct place to discuss and hash out problems and your input is very welcome IF you stick to technical aspects instead of personal attacks.

---

Editorial: Personally, I don’t see discussing Red Hat’s motivations and history of involvement in this area as irrelevent or as a personal attack. There was no name calling here by anyone, really no references to any person in particular. In my view they are using their code of conduct (which also specifies that we must assume they mean well!) merely to hide misinformation they’re spreading about gvfs, and to hide the involvement of Red Hat and their history and agendas with regard to gvfs dependency. When a person uses the word “overengineered” to justify why they’re not using udisks (which they shouldn’t have to justify at all, as it’s a valid choice and nothing to do with this bug), and they are threatened with a code of conduct for using the word, there is something seriously wrong. So effectively, none of these central issues can be discussed on a GTK+/glib bugtracker without heavy-handed censorship and threats.

I feel personally attacked because Emmanuele Bassi called us “not really cool” for thinking we can pick and choose components in Linux.

kdbus: systemd’s Kid Cousin Come To Stay (No, Not PID 1, In Your Kernel, Silly)

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
• Crux
• Entropy GNU/Linux (formerly Less Systemd GNU/Linux)
• Funtoo
• Gentoo (ready options exist)
• Manjaro (see OpenRC options)
• Porteus
• Puppy Linux
• Slackware
• Void Linux

For more see without-systemd.org.

Related Articles:

• Julian Assange: Debian Is Owned By The NSA
• Ts’o and Linus And The Impotent Rage Against systemd

SpaceFM 1.0.1 and udevil 0.4.4 Released

SpaceFM 1.0.1 and udevil 0.4.4 have been released.

SpaceFM 1.0.0 Released

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).

 

SpaceFM 1.0 Alpha-Testing Has Begun

Please see the details here. Please help test this version so the release will be more stable.