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
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
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
> – 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.”
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
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:
> 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
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
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
(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.
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.
For a little over two years, I have been on a strange odyssey into the heart of Linux, and I think now is a good time to summarize that journey for some readers that haven’t followed every step, and to answer some questions that it has opened. Like most users, I came to Linux with the impression that it was an openly and freely developed OS, a saner alternative to the corporate OSes such as Windows. I knew corporations had developed some of the software and had infiltrated the kernel, but I thought Linux was largely driven by users and community development, largely volunteers. And I thought the assertions that Linux took security more seriously were based in facts – that things were basically done smartly, because this is ‘our OS’.
Being semi-retired from such work, I never intended to develop software in Linux. This happened as a result of my first encounter with something ‘not quite right’ in Linux. Originally a user of the KDE version of Ubuntu, I began to see disturbing patterns in how daemons were being used, and generally how the system was being engineered to be increasingly locked down, intrusive, and overly complex. I knew these patterns well because I had used and developed on Windows for many years. With the advent of KDE4, I was driven to abandon KDE and Ubuntu completely, moving to Arch Linux with just Openbox. This was also my first real introduction to the ‘g’ side of Linux (GNOME and GTK apps and daemons), since now I was avoiding any KDE dependencies.
When I first began using Linux, a little over a decade ago, I chose the name “IgnorantGuru” because I was a guru in some areas of computers, certainly not a novice, but I was also a Linux noob and ignorant of plenty! I always feel this way about knowledge: acknowledge both what you know and what you don’t know – this is where learning begins, or continues. The surest way to learn nothing is to believe you know it all. So I got to know bash a bit and started sharing scripts, and eventually set up this blog to maintain my scripts and let people see what I was up to in my own explorations and uses of Linux. This blog also saw some fame in the form of an article I did on the lack of package signing in Arch Linux, a large controversy at the time which established this blog as a controversial news and discussion site. Then as I started hacking the legacy PCManFM so I could add a few custom commands to it, PCManFM-Mod was born. Feedback on this small mod convinced me that I wasn’t the only person interested in simple, flexible software, and this interest eventually grew into the SpaceFM and udevil projects. I am a Linux developer and blogger, when I had set out to be neither! Such is life.
I’m not new to all of this. I don’t usually go into my history much as I prefer a layer of anonymity to work in peace, and it helps me stay on topic. Yet here I would like to share a little of my general background so you can understand where I’m coming from. Sometimes I get the impression that people are confused as to why their file manager developer takes some of these blogging issues so seriously. Why does he care?
I care because I am a cypherpunk, or I was. Much of the software I’ve developed in the past has been in the general area of crypto and various related clients, servers, etc. If you were around back then, you knew my name (alias) – I wrote popular software of the day and had articles published by the EFF, etc. For those of you too young to know or remember, this was the period, and just following the period, when Phil Zimmerman first released strong cryptography into the civilian domain (PGP). The US federal government started a virtual war against this, and did everything they could to make Phil’s life miserable for years – he was persecuted. To help characterize the times for you, the only way he could release the source was to print it in books, then sell the books worldwide. This was still legal (although it infuriated the feds) because printed books had censorship protections and freedoms. People would buy the books, scan in the code (a very tedious and error-prone process, especially for crypto code), and (try to) compile it. This is how strong crypto first left the military domain and found use around the world, even something as simple as the https you now take for granted. Crypto wasn’t just used to keep secrets, but to expose them and to protect people (dissidents, activists, even intelligence agents). Anonymous and pseudonymous remailers, the precursors to today’s tor network, were developed and basically created chaos for those who numbered and controlled everyone. It became much more difficult to suppress information.
It was an exciting time – people are now revisiting some of that excitement with the Snowden affair and such – and we were all eager to master these new tools and free the world. Although some commercial software did exist, the 80s were very much a do-it-yourself time in computers. Much of what you used, you wrote yourself, so adding crypto to that mix created an explosion of new tech. “Conspiracy theory” was not a term then, and no one would have taken it seriously. If you didn’t distrust every government and newspaper, you were simply a damn fool. This is why I still consider most of you damn fools. ;) It’s hard for me to comprehend the naiveté in today’s world, and the easy validity given to people who ‘debunk’ revelations of obvious corruption.
I’ll share two personal anecdotes to give you an idea of those times for me. For one, I personally discovered a crypto key in a widely used crypto server of that day that had most of its bits set to 0x00 (rendering it compromised). No paranoia required – I witnessed it. People had been relying on this sophisticated tool for their anonymity (in some cases their LIVES) for a few years and it hadn’t been detected, despite alleged peer review. I happened to be examining the source to borrow some code and I couldn’t believe my eyes. A chill went down my spine. I immediately published my findings to the mailing list so that I would not become anyone’s target (paranoid? perhaps, but I was scared). The server’s developer quickly corrected it, but it left a lot of serious crypto people shocked and questioning, and it pretty much outed him (or someone he worked with – we didn’t have git in those days to find who did it) as someone’s agent, probably some government’s agent. He was actually a very likable fellow, though, and I had spoken to him on occassion. It was disturbing to see his likely involvement. I have never completely trusted anyone since.
The other event also left an indelible memory. My work was strictly legal (I even did my best to obey the ridiculous code export rules of the day, though they were mostly useless, locking the barn door after the horse had left), so I didn’t often have overt friction with the various agencies harassing people. As with the mailing list event, I tried to use openness to protect me. Release first, explain later. They knew of me and let me know that, and my web pages would routinely be shut down on spurious copyright claims, etc., but it was mostly just annoyances. Although I worked behind a layer of strong anonymity in those days, being a developer, one was always logging into servers and such, and we didn’t have the tools of today, so I knew I wasn’t hidden from serious players. Yet in this case I was sure I had heard from them. Although writing hard crypto (in the mathematical sense) wasn’t my central area, I had combined two crypto algorithms in a unique way. I was excited – it seemed to create an exponentially stronger algorithm and method. As was my habit, I released my notes immediately – everything to reproduce it – don’t want the hot potato. And I promised it would be in my next software release. It was then I received the oddest emails, like I had stepped on someone’s toes. Someone was desperately trying to convince me that I shouldn’t use the algorithm. First, they tried various broken technical arguments (which only revealed to me that they were lying), and then it turned into virtual threats. Who would be this motivated to make me stop using this algorithm, I wondered. I had the impression that the guy in some agency who monitored this area realized it would make a whole lot of new work.
It was almost like he was trying to protect me, to save me from myself. It wasn’t my first contact with ‘weird’ – I had received out-of-place business offers and other questionable things in the past. I got phone calls in the middle of the night, hang ups, just to let you know you were on someone’s list (this was common then among us, before cell phones existed). Yet this was eerie, and we never knew who we dealt with in those days. Intelligence agencies to an extent helped the process, even against the government’s own wishes and laws, because their agents used these same tools as us, and basically all the people using PGP and other tools were creating lots of cover traffic for their spooks. So even within governments there has always been a mixed reception to crypto breaking loose, and we found ourselves in strange company at times.
Long story short, within a few years of that incident, I quit the business and destroyed my PGP keys. It was always stressful having someone’s life depending on your code and keystrokes. (File management is blissfully relaxing by comparison, even though this is generally considered stressful work since you have people’s data in your hands.) After working for quite a few years in this area, I was developing shortness of breath and heart palpitations, and my nerves were simply shot. I had also come to see that the biggest players had developed ways of manipulating our systems. I saw the emergence of the new strategies of keyloggers, plausibly deniable code errors, weak OS security, network sniffing, and other non-brute-force attacks. All of the OSes of the day were simply not up to the task of providing a secure platform for anything. So the greatest algorithms were basically at the mercy of Microsoft’s (deliberately) botched security.
Plus, I had done my part, and I was burned out. Twenty-some years ago, I was working hard to help develop the technologies you’re using today. Now, I can barely follow the manuals I wrote back then – seems like gibberish to me and I simply don’t remember enough detail to understand most of it. When I decided to develop SpaceFM, I figured it would be a relatively relaxing project, with just basic security issues. The last thing I ever expected to be involved with again was spies.
I feel like I’m in one of those movies where the expert tries to retire but his retirement is invaded and he’s pulled back into ‘the game’. I don’t want to be in the game. How did this happen? I’ll tell you.
I’m a problem solver. I can analyze systems, find what’s not working or not optimum, track it down and correct it. I’m very good at this, you might say gifted. That’s why my software generally works well. Yet some aspects of SpaceFM were not working well. As I followed the trail of why they were not working well, I was led right into Red Hat and company.
For those who haven’t followed this blog, here are a few of the steps. I noted how udisks2 was built broken, seemingly deliberately breaking everyone’s work. Even before this, Linus and other kernel developers had noted horrible dev practices in the kernel, with some commenting that it seemed like Red Hat was engineering it to be broken. This is what I saw too – all these Red Hat developers doing surgery on the deepest parts of Linux, breaking it! I asked outright, What Is Red Hat Doing To Linux? It’s unusual seeing such high motivation in Linux developers – usually they have obvious reasons for the changes they take the time to make. Yet many of Red Hat’s changes had no immediate purpose or advantage – it was like watching a chess player putting pieces in place for some later conquest.
Next came my GNOME (et al): Rotting In Threes article, originally based on an email from someone who didn’t want their name involved (gee, that’s odd in open source), which exposed a climate of hostility to users and developers, and basically demonstrated how Red Hat completely controlled GTK and GNOME. This article went viral, bringing over 50,000 visitors to this blog and attracting the attention of Linux Users and Developers magazine’s editor. I eventually wrote my A Linux Conspiracy Theory article for them, extending on the material in the GNOME 3 article. I didn’t really want to write this (writing is a lot of work, especially when you have an editor in a print magazine ;) Yet I felt it was a good opportunity to make people aware of some of these development practices I was seeing, so I did my best to present what I was seeing at the time.
Since then, more has happened to reveal the true story here, the depth of which surprised even me. The GTK development story and the systemd debate on Debian revealed much corporate pressure being brought to bear in Linux, which I ranted about in GTK fesses up – this ain’t for you; Qt takes over the world. In comments there and in Ubuntu To Dump Nautilus, some really startling facts about Red Hat came to light. For me the biggest was the fact that the US military is Red Hat’s largest customer:
“When we rolled into Baghdad, we did it using open source,” General Justice continued. “It may come as a surprise to many of you, but the U.S. Army is ‘the’ single largest install base for Red Hat Linux. I’m their largest customer.” (2008)
This is pretty much what I had figured. I’m not exactly new to this, and I figured that in some way the military-industrial/corporate/intelligence complex was in control of Red Hat and Linux, and was devolving it into a useless, compromised toy. But I didn’t expect it to be stated so plainly. Any fool should realize that “biggest customer” doesn’t mean tallest or widest, it means the most money. IOW, most of Red Hat’s money comes from the military – they have first say in its development. And the connection between the military and spying agencies, etc. should be obvious. Not to mention the fact that dealing with Red Hat developers always creeps me out, just like those weird emails in the 90s. Something just isn’t right there.
Next, a reader posted this FOSDEM: NSA Operation ORCHESTRA Annual Status Report. Well worth watching in its entirety (including the Q&A at the end), to me this turned out to be a road-map detailing how Red Hat is operating on Linux! I recognized so much of it from personal experience at this point (and trust me, Red Hat controls almost every core component in Linux, in case you didn’t know). Presented by FreeBSD developer Poul-Heening Kamp (aka PHK), it does a great job of introducing some very subtle concepts, and I was shocked by how closely the examples he gave matched what I had been seeing Red Hat (and other corporations) doing in Linux the last few years. He also explains that “PSYOPS For Nerds” is a reality – our communities are being engineered and propagandized very effectively, pushing them in the directions desired not by us, but by… whom?
Well, what do you know? Without even trying to get there, my simple explorations into what was broken in Linux led a trail straight to the NSA (or whoever is behind such three-letter agencies). As usual, just follow the money. And these days, they admit much of it openly – secrets are just too hard to keep.
While I don’t use PGP much these days except to sign releases (old, good habit), what is an ex-cypherpunk rebel like me to think of such things? I honestly don’t know. It seems people have become very complacent and accepting of corporations and governments running their lives. We wouldn’t have been so appeasing in the 80s and 90s, but these are different times, and I understand that. Largely people are oppressed and heavily propaganda-fed. PHKs belief that this is not merely a technological problem but a social/political one is a view I have expressed several times, almost verbatim.
I think all of these revelations bring up questions for Linux users. For example, why should I care about encryption if I have no secrets to hide from a government or enemy? Why should I care about them rooting everyone’s system and being in charge of its core engineering decisions? Why should I care that Linux’s security is just a myth, as is the idea that it’s freely and openly developed, and anyone can participate? Why should I tell the truth about it? Why should the reality that Linux is a military- and spy-agency-created OS be important? Here are some of my answers to those questions.
It turns out that cryptography is not just for keeping secrets, and intrusive spying is not just about finding bad guys.
Computer technology, like any technology, has been weaponized. It is not merely used to serve homes and businesses, it is used to gain supremacy and control over people, governments, and other institutions. Today’s computers, the military versions of which are far beyond civilian specs, are very powerful to put it mildly. Anytime you have great power, held in darkness in the hands of a few people, you have a recipe for tyranny. Do you enjoy war and destruction in your neighborhood? If not, you should be paying attention to this, NOW. Because one thing I can tell you: All these people know how to do is create war.
Let’s be clear: This is not a new problem. Humans on earth have been enslaved for thousands of years. Governments and banks have always been corrupt and severe. Every form of communication, even something as simple as a typewriter or printing press, has come under constraints and control designed ultimately to control people. It’s that simple. There are those who would enslave and control the world. While some of them may believe in their causes and feel they are ‘the good guys’ despite the insane things they do every day as ends-to-means, one thing that history has shown is that power corrupts absolutely. And governments abuse every power they assume, without exception. It’s history, including modern history. This is the world we have always lived in, and we always manage to scrape out some small degree of freedom from absolute tyranny (although there has been plenty of it experienced). Where does it end?
While PHK in the video says just use politics to solve this problem, most of us know that politics and media are as crippled as technology. They are largely controlled. I would say use everything to help address these problems: technology, politics, and in general, social change. Many people think they can change something by just voting once a year. But that requires almost no effort or risk, and as such produces almost no result. Real change requires real efforts, affecting every area of our lives. It’s costly – a genuine investment.
Cypherpunks have always advocated using strong cryptography as a tool of social change because it helps level the playing field. It is way to help distribute and balance power and information, rather than having it in the hands of a few people. How does this work?
I am not an advocate of battling the NSA, creating lots of secrets, private armies, and all of that. Rather, what we can do with this technology can be open and free. Cryptography can be used to keep information free, including information on corruption (eg whistleblowers). Simply put, it can empower and protect people who stand up for people. Who is stealing what from the people of this world? Let’s shine some light there.
Cryptography is also used in authentication – webs of trust – so that you can identify someone. Why would this be socially powerful? Ask yourself why we need elected representatives (vastly overpaid, corrupt lawyers) deciding the laws that control our societies? Why can we not simply micro-vote on each issue ourselves? We cannot do this because we are not allowed to, and the technology that could easily make it happen is suppressed. If the current electronically corrupt voting systems were replaced and recreated, many old tricks wouldn’t work. It is simply ridiculous that we have legal representatives in their current form – it is a total failure to use cryptography effectively.
Why is it important to have an OS that is free of rootkits and security holes? Because the computer is a very important tool in the modern world, and for citizens to exercise their power, they need such a tool to be reliable. They must own and control it. Beyond this, there are the many creative freedoms found in computers (or any information-based technology), and all the social growth they represent.
While this may sound strange for a cypherpunk, I am not a big believer in secrets. Rather, I am a big believer in openness (in finance, governments, business), and a believer in the free flow of information. I also feel that most intellectual property schemes do more to hold back progress than any other system – the idea of owning information is simply a system of mind control and exploitation. Many of the people reading this are deeply invested in that exploitation system whether they want to admit it or not, and are inclined to defend it because it serves short-sighted interests. But when you’re a slave breaking rocks, you may not think so much of where that system has brought you. You too are being herded aboard the trains, and your perks are temporary. History will show you this if you look at it.
Cryptography, and especially the larger concepts of distributed, non-centralized systems, open and participatory government and development groups, open accessible hardware, and many other powerful ideas that you see open source people advocating DO affect you. They protect you and everything you value in your life. Using such tools effectively and routinely is investing in your future.
Having grown up in the 80s, I am used to visions of the future – we spent a lot of time thinking about such things back then. We were a generation of dreamers, with nuclear annihilation hanging over us. A lot of our dreams from 20 years ago are now encoded, in your web browser for example, as reality. We lost the war against intrusion, but I believe we did take some steps toward openness and computing freedom. The primary threat today seems to be technological tyranny – the old Big Brother concept coming to living life (and death). Primarily it is an attack on the mind and creativity of man. I don’t see as much dreaming of the future today – the generations today seem to lack vision. Maybe it’s time to get some, to dream a little, and to put those dreams into action with real technology and POWER. The power that large groups of people united in certain principles acquire. This is different from concentrated power that oppresses people. It is distributed power that you share in, and which protects you and everyone.
One of the first and foremost principles is honesty. It’s time to start telling the truth about what’s happening in Linux, despite all the paid disruptors interfering in such discussions. Many Linux users and developers operate from myths that are simply no longer true, and really never were. Linux is a government, military product, right down to its core. There’s a start to truth-telling for you.
I’ll tell you one secret: It’s very, very difficult to control information, and to control people. In the long term it’s impossible. We have an easy advantage in many ways, because information is free by nature, and people are ever recreating themselves, defying control. I wouldn’t want to be a power-monger trying to rule the world! It’s a very tough job. And everything we can do to make that job more difficult is worth it.
The powers that be in this world don’t want to protect you, they want to protect themselves and their power. Nor do they want to share that power with you. They are not creating systems that create security for you and end corruption (stealing from you), they are creating systems that create vulnerabilities and concentrate corruption (wealth) in their hands. The solution is to distribute power, and to reveal the ‘plots’. Terrorists (the favorite theme of the day) don’t want open, authenticated systems anymore than governments do. Thieves always want closed, complex, dark systems where they can hide and manipulate without being exposed for what they are. Governments want the same (surely an amazing coincidence). People should have the wisdom to see that such systems serve no one but thieves.
So that’s my little pep talk. To be honest, I am as overwhelmed by the state of this world as anyone. There are no simple solutions. But I do believe in certain principles, and I do believe in how powerful they are – if you apply them. Learn to use the tools that matter, and use them well. Use them to create nothing less than a new world.
It’s been a few months now with no activity on Github from IG, or responses to mail which he usually responds pretty quickly to, even when he has a lot of mail. I have asked for Editor access here in order to cull the spam, but that probably wont get anywhere.
Hopefully he is just taking a well-earned break from pouring effort into SpaceFM, and we can welcome him back soon.
Update: IgnorantGuru returns!
I have been developing free software for a long time, originally as an independent freeware author in Windows (oh the stories I could tell you there) and more recently in Linux. Why do it? And what are the values and principles that are most functional when working for free? I thought I would take some time out to share the strategies I have developed over the years that make this work.
First, why do anything for free? I think this is a core question to address before even contemplating working for free. My answer to this is that I don’t really believe that money as motivation works to the benefit of humanity. That system, which in my world is a relic of the past, leads to exploitation and corruption. The people who make the most money in this world typically do the least work, certainly the least beneficial work (usually exploiting people, other life forms, and the environment). Work produced based on the promise of financial reward is increasingly of low quality, designed to fail, and primarily seeks to make more money and create dependence. Any money made (usually most of it on the corporate level) is further used to enslave and exploit, as well as to destroy the very planet we depend on for life. (Do you know how many products are designed to fail after a period of time, and thus need to be manufactured again and again, just for the sake of profit?) I think if humanity is ever to eliminate poverty, exploitation and environmental suicide, and provide real means for people to better themselves, the money system has to be replaced, and that has to begin somewhere, and soon. I believe some approaches common in Linux are good examples of what community-based effort can produce. Regardless of your financial standing, you can download great software, learn and grow. Being a contributor to that community has many rewards, immediate and also in terms of long range dreams of what is possible.
Most of us come from cultures that aren’t based on free contribution and availability, and are based in competition, so some adjustment of values and motivations is necessary to work effectively in such a community. Especially professional software developers are accustomed to being very well-paid for their time and efforts. I find that if they bring their normal motivations and values with them into the free community, they wind up feeling resentful and frustrated, and so do their users.
Software development involves hard work and real effort. I love getting creative on the computer, designing good tools and innovating, and that is my primary motivation – to make something cool. A painter loves to paint – just try to stop him from painting! I share some of my work as public projects as a way of giving back to the community and contributing to the growth of Linux. Yet even the most fun creative project involves drudgery – chores which need to be done to make the overall project polished and usable. Further, for software to be more than just someone’s mostly-broken pet project (which if you’re lucky, you can even build with the instructions provided), it requires continuous efforts in publishing, support, documentation, web site maintenance, forum participation, etc. At times, it’s simply a LOT like work.
When people come to this work from traditional employment-based backgrounds, they tend to become resentful and quickly disillusioned. Normally they would keep thinking of their coming paycheck or their needs as a source of motivation, but there is not much pay involved in free work. If you think you will get rich off of a popular Linux project, guess again. While some developers manage to scratch out a living from donations, and corporations exploit it in the business environment, in general donations to developers are rare events, at least in my experience. My donations page has received only a handful of donations in the past year, despite thousands of people using my software daily. My software is offered genuinely for free, so I don’t have high expectations in this area – it’s a treat if a donation comes in, but I mostly avoid resentment at the tip jar being ignored. But if your motivation for doing the drudge work is money, you can easily begin to feel misused, unappreciated, ill-treated, and enslaved. You begin to ask, “Why am I devoting hundreds of hours to this? Why am I investing my time and energy?” This resentment can easily build until it paralyzes your work, and you forget your original reasons for creating it.
Simply put, the motivations for doing free work need to be different, because the conditions are different. In some cases, your expenses of maintaining servers and so forth can exceed what little income exists. If you depend on monetary reward, you’ll be disappointed. Further, there is little reward for success. Even if your project becomes hugely successful and gains many thousands of users, your ‘profits’ don’t increase much, while your workload does! More users mostly mean more work in terms of greater activity, bug reports, feature and support requests, etc. (I originally almost decided not to release SpaceFM publicly, expressly because I knew it would be popular.) Yes, it’s gratifying to see people appreciating your work, and knowing that you’re contributing something useful. This can be a little ‘ego boost’ to help push the work forward, but it’s not very tangible, and won’t feed you. Also, even if you make a great piece of software, it may never get much recognition or use – you won’t have much of an advertising budget. So pats on the back may be rare even for the finest work – don’t depend on them for motivation.
Beyond this, while most users are appreciative and often take the time to give you a ‘thanks & well done’, not all users will make you happy. You’re dealing with the public, and this can take patience. A few users will even be obnoxious and rude. Back in the days of Windows freeware, I even had a user threaten to sue me, alleging installation of my software broke their system. Despite all the helpful and kind users, just a few negative experiences can cause real resentment toward ‘the users’, especially if your skin hasn’t thickened yet, or you’re already feeling resentful at working for free.
Because of some of these dynamics, people often believe that ‘free == junk’. If it’s for free, don’t expect my product to be of high quality. You’re lucky to be getting anything, so don’t expect excellence in something that is offered for free. Yet this is a trap, because it’s no fun producing junk. It’s much more rewarding to take the time and effort to produce something that shines and really works well. Yet a resentful developer won’t want to make that investment, and thus will not reach that rewarding state of accomplishment.
Sounds pretty bad at this point, doesn’t it? Hard to imagine why anyone would work so hard and put up with the hassles without monetary compensation. Yet actually I find free software development very rewarding, and that is why I have done it for so long. It’s all a question of motivation, and there are some unique rewards not found elsewhere.
Motivations That Work For Free
As I said, my primary motivation, especially in a larger project, is to make something cool – something that demonstrates excellence and innovation. Why? Simply because a painter loves to paint, and paint well. Also, genuinely serving people is always rewarding – it’s a human thing, we want to help, to contribute. Making junk is not rewarding, especially on a personal level. (Even when people work for money this is true, which is why much employment is un-gratifying.) Taking the time to dot the i’s and cross the t’s, and produce something that is genuinely useful and reflects my creativity and attention to detail is something which I have come to know as personally very rewarding, and that is motivating. This is my art, in a sense – I want it to be excellent.
Much falls out of that primary motivation. For example, I see bug reports, negative feedback, and feature requests in this light. These people are contributing to the project, helping to make it better. Often users are almost apologetic for reporting bugs or making requests with free software – they too suffer from a sense that they are merely asking for something for free, that they don’t deserve it. They will often be surprised when I thank them for a bug report or request, and say, “No, I should be thanking you.” Thank me, sure – I’m contributing – but so are you. I encourage users to contribute in these ways because just as my work helps to make the project excellent, so does such input from users – it is essential, in fact. Especially when software is free, the user is the whole reason software exists – the user is its reason for being. (Ironically, commercial software forgets this, as its reason for being is to make the developer or his/her boss the most money.)
As developers, we often spend time fixing bugs or implementing features that don’t affect our personal use of the software. Working for free, this too can build resentment. Why am I spending my free time working on this aspect that doesn’t affect me? Yet I look at this from the higher perspective of what serves the software, what helps to make it the best it can be (within what I’m willing to invest). Users may not view it this way – they may just want a feature or bug fixed for their own use. Yet I review bugs and requests with an eye toward how they serve the software, and by extension the users (who again are the whole point it exists). So contribute to the software by making reports and requests, yet remember not to make demands, which are not appropriate in a free context. At any rate, I never view them as demands, even when they are worded imperatively – to me they represent people making contributions to the software in the form of feedback and ideas. Thus I appreciate what another developer may discourage or resent, because I remember to set myself free.
Beyond the ‘make something cool’ motivation and rewards, there are many perks to free software development that can create an entirely novel context of what ‘work’ means, making it a very enjoyable process, and washing away some of the stains of exploitation which we all carry. In this sense, contributing to free projects can be liberating in unequaled ways. I still have to continuously remind myself of some of this, and remember to take this perspective, as it’s easy to fall back into conventional modes of thinking.
Working on anything free, it’s important to assert your rights. Working for a boss, one is at the mercy of another – told what to do with one’s time and efforts, often working on things one disdains, at times when you’d rather be doing something else. This creates an atmosphere of misery, and many developers bring this atmosphere with them to free development. They are in this habit of being driven by others’ demands, so they view users and ‘co-workers’ as telling them what they have to do. This is why developers often get so cranky at bug reports – they’re being handed more work, demands! Eventually, when you’re not being paid, this can spell deep resentment. Even I fall into this trap sometimes, until I remind myself that there’s nothing I have to do!
As a free software author, my time is my own, and I’m my own boss. This is especially true because I tend to be a one-man band, not usually contributing to larger projects that incur expectations and timelines. And because I’m working for free, not working has no financial consequence – in that sense it’s even freer than being your own boss in business. If at any time I feel “I don’t want to be doing this”, I simply walk away from the computer, or put those files away for now. This means that my work is not a product of misery, of me forcing myself to do something at a time when I’d rather be doing something else. If I’d rather be doing something else, I do it! Thus when I am working on the project, it has my natural attention and motivation – I’m interested and engaged, enjoying the work. I think this contributes to its quality – it becomes a labor of love.
You might think I’d never get anything done under those conditions, but in fact it’s natural work for me, and at least some of the time I want to do it. I would like a bumper sticker: “I’d rather be working on SpaceFM“, because I really enjoy it. And when I stop enjoying it, I quit it for the moment. If I stop enjoying a project routinely, I quit it entirely. Of course, there are chores and drudgery involved in anything useful, aspects of the work that I can’t say I would prefer to do. But if they are a necessary part of something I want to add or make more functional, then I am willing to do the chore because I want to achieve the larger goal. Overall the process is still one of enjoyment. It’s sort of like cleaning your house or fixing your car – you may not actually ‘enjoy’ vacuuming per se, but you enjoy having a clean house to live in or a car to use, so it’s a necessary ingredient of a larger joy. Thus I do manage to get most of the chores done, often promptly, because I want the enjoyable result – the rewards. So in a sense you do work for rewards, but the primary reward is no longer money.
You may notice that I rarely involve myself in estimates of when something will be done. I may speak of general plans, and things coming up soon, but as a free software author I simply don’t do deadlines – they run contrary to my way of working. When selecting what in a project to work on next, I do consider what most needs attention, but I also consider what I simply feel like working on at the time. Sometimes I’m more in a mood for coding, or web site maintenance, or just answering questions and chatting about potential improvements. Other times I don’t feel like working on it at all, sometimes for extended periods, so I don’t. While bug fixing is usually a chore, sometimes I’m sufficiently motivated to knock a few bugs off the list – that too can be rewarding, and I know it serves the software. If I’m going to produce something of quality, bug-fixing occasionally needs to be done – it’s part of the ‘job’. If I don’t want that job, I wouldn’t share the project publicly in the first place, or would drop it.
I also almost never accept bounties, or promise to do something if a particular sum is paid on delivery. You’ll note that my donations page reminds you that “donations are not associated with feature requests, but feedback is always welcome”. I view donations as a ‘thank you’ and as general support of me and my projects – and it does boost motivation when I see a donation roll in. Just because a project is available for free doesn’t mean you can’t pay, it just means that your forms of contribution are voluntary too (and not all involve money). It does feel good to get some cash, as any developer will tell you. In fact it tends to be all the more appreciated, because you know it wasn’t required. But I find making promises to do something for pay interferes with my way of working on free projects, so I mostly avoid bounties. No one can effectively force or pressure me to do anything in this area, and I like that freedom. It’s one of the perks of free software development – guard it.
This may sound like over-analyzation of motivations, but it’s important to get and keep your head straight on these issues, as it makes a huge difference on a day-to-day basis, because it is a lot like work. Because I don’t really force myself to do anything, no one else can successfully force me, and I know that I genuinely want to be doing what I’m doing. Part of managing this level of freedom in time involves good project management. I need to be able to let some things pile up without losing or forgetting them. In addition to issue trackers, I use casual (usually downright messy) lists to remind me where I left off, what high priority items are pending, etc. So when I am able and in the mood to devote a few time clicks to the project, I can choose wisely where they’re spent.
I tend to like things to work right! I want to achieve a level of excellence – it’s rewarding, and I take it personally when it fails. I feel that if I’m going to publish something, basic support is part of that effort. So it’s hard for me to leave things go that ‘should’ be addressed – this is actually something I have to work at, letting things go. Yet if I don’t, the ratio of users to developers will overwhelm me, I’ll burn out, and I’ll become resentful of the work. It may only take a minute to add a bug report or feature request, or even to throw something on a list myself, yet each of those items can take hours to address. Thus the TODO lists and open issues tend to grow faster than items are removed. This can be discouraging if one doesn’t take an effective approach.
I do NOT accept “If it’s free, excellence doesn’t apply.” I believe working toward excellence in any product is the whole point, and rewarding. Yet there are also realities of time and will, and if you don’t work effectively with what is available, you’ll burn out or lose motivation for the project entirely. Thus a balance needs to be achieved between the desire for excellence and the investments one is willing to volunteer. If not, a free project will become sidelined or ignored. And this too is okay – as a free author there really is nothing you have to do.
Another perk to free software development, and a good routine reminder: it’s my program. This is my software and I’ll do what I want with it. I’m the captain of this ship, the benevolent dictator. Others can offer suggestions and even judgments, but the decisions are mine. The reason this is important is that often without meaning to, some users can become very pushy, applying pressure to a developer’s inclination to make things work well. Usually they have their own vision of the software, or they’re having problems which they feel ‘should’ be fixed. Perhaps they have a sense of quality and want things done ‘right’. Whatever the reason, in some cases people can become almost hostile in their attempts to get you to do a particular task, or make a particular change, forgetting that they are making demands on your personal time. As a volunteer, it’s easy to resent this. As a free software author, it’s important to retain command of your project, and not allow others to define it or your tasks. Always remind yourself and others that since it’s open source, they are welcome to create a fork and take it in new directions too. “While I appreciate your feedback, you are not my boss, and this is MY project.” Most users are not like this at all, but all it takes is one to begin building resentment toward all. Ultimately, this robs you of enjoying your project and the community – don’t let them rob you.
While perhaps not a perk per se, another strategy that works is to advertise your limitations. In commercial environments, this is not done. You want people to try and buy your product – you’re not likely to point out what it can’t do, or why they won’t like it. Yet with a free project, I get no kickbacks from having more users. And if users try my software with warped expectations, they will often be upset and negative, in part because they feel their time was wasted trying a tool that doesn’t do the job. While I don’t typically make long lists of limitations, I do try to make clear in web sites, screenshots, and in documentation exactly what this software is about, and what niche it fills. I don’t want to waste my users’ time, and they don’t appreciate having it wasted. It’s much better to clearly define the tool without embellishment. Nor is it necessary to defend or fight for it. This is another habit that developers import from other environments. While you tend to be a fan of your own software, there is simply no reason to fool anyone when its free. The only reason to advertise at all is to see your work put to good use where applicable.
Another strategy and perk I tend to use: use free stuff. I use free web hosts, free issue trackers, free forums, free servers, etc. Many commercial organizations involved with Linux, such as github, offer free services to the developer if your software is free and open source. Rarely do I invest money much in the process of developing and maintaining my software.
In short, get your head straight on what you’re doing and why you’re doing it, and free software development can be a tremendous experience. Having an audience, especially a large audience, can be rewarding in many ways to any artisan, and free software development is no exception in this. Not only is having your work appreciated and used personally rewarding, but the effects of community contributions and ideas to your projects can cause them to grow in directions you didn’t expect. In a sense, users become co-authors of the projects, and this is a very different experience than developing something in a vacuum (which I also know from the projects I don’t take the time to publish). Plus, it’s simply nice to work on something without a need for money involved – it’s liberating to experience ‘the other side’.
Keep expectations low in terms of financial support. Depending on how hard you push for donations and other factors, you may receive some support, but mostly the community doesn’t kick much in. I think to some extent this can use improvement – free software authors need to pay their bills too, and if no one is willing to support them in cold hard cash, opportunities become limited. Remember that “free software” doesn’t mean it’s free to produce, or that you can’t contribute financially, just that what you contribute is voluntary. I believe this is one reason why Linux is being overrun with poorly developed, corporate-driven products which ultimately undermine it – people have come to take the developers for granted. So I do encourage users to support your free developers. Yet I also advise developers to not expect a lot in that area, and to not depend on it for motivation.
Don’t let the lack of financial rewards rob you of a very rewarding experience. If you enjoy writing software (or anything that contributes to the Linux community), do so for your own reasons, and remember the perks of working for yourself, for others.
“Surprisingly I haven’t found much info on the topic searching the forums…”
“Please search before posting… Marked for deletion.”
This is good comic strip material.
I think something is not quite right in Archville. And speaking of deal breakers, I was thinking earlier today how quickly most devs address a root exploit, and how serious they consider the issue to Linux. How can any dev be so nonchalant (for years) about insecure package management, when it is nothing less than a root exploit?
I happened to come across this message posted in July from someone who ran a popular Arch mirror for 4 years:
This mirror will shut down in the upcoming days.
Few funny facts:
* We never got contacted by anyone before we got added in the official mirror list. We just posted this thread and all of the sudden it appeared. No verification of whom we were and what our intension were.
* ArchLinux is fundamentally unscalable in the package manager aspect.
* ArchLinux puts the trust in the hands of every mirror owner and their security. ftp.archlinux.se is the prime example of a machine vulnerable to all sorts of things. This affect YOUR security. This is why it’s being put down. If the ArchLinux authors would start signing packages this would not be a risk to you.
* We posted a suggestion of this in 2006. http://bugs.archlinux.org/task/5331 — This is 4 years of insecurity.
* We recommend all of you to switch to a distribution caring about user security and atleast signs their packages. Most RPM and APT based distros does this (Ubuntu, Debian, RedHat, CentOS, SuSE, OpenSuSE, etc etc etc).
Have fun. :-)
Of course the moderators closed the thread and moved it to the troll bin for what was said there. Then Mikael wrote in another thread :
Just noticed that the forum admin/moderator “Misfit138” moved a thread which we started 2006-08-31 to the “Dust/troll-bin” area. smile
This after hosting several TB of data to the community, and then speaking our minds and telling some perhaps stinging facts.
What kind of a community is that.
Thread located @ http://bbs.archlinux.org/viewtopic.php?id=24666
As always, yours,
which was also moved to the troll bin. It seems the Arch moderators REALLY don’t like anyone discussing Arch’s security issues.
Of all the things about Arch, I have always found the forum the most disappointing. It is over-moderated to a ridiculous extent – looking through the troll bin I have to think “Why was this thread closed?” again and again. And the attitude toward newbies is ugly. There are some helpful people in the Arch community, but the forum as it stands is not worthy of that community.
This blog is just getting started, so check back over the coming weeks and months for updates. I have a lot of scripts to add. For now, you can check out the Library for my wikibook How To Backup Operating Systems and also Script Installation Instructions, and in Downloads there is repic – a script to resize and email jpeg images, as well as installscript – a script that installs scripts.