Some of the bugs that I wrote about here in 2012 have been fixed (hooray!) For most of the others I have now (2014) found a different path involving a much cleaner Linux system (Arch Linux), a rational graphical environment (FVWM without any "desktop" at all), and a whole slew of rather annoying configuration details. See the Notebook ../ How to Build a Useful Computer.
The major exception to this progress the file saving behavior of GIMP 2.8, which is simply wrong and remains unfixed, and the continued inability of Firefox to handle symbolic links with fragment URLs.
These bugs are "stupid" not simply because they are annoying but also becase they tend to arise out of the ignorance of 40 or more years of computer science (and in some cases 120 years of automated information processing).
For years, the main desktop distributions of Linux have been getting better and better. By around 2010 they had reached a point of being the most useful operating systems ever. Now they have stumbled, and each release is getting worse very quickly. Linux is now an annoying environment in which to do serious work, and I can no longer recommend it without embarrassment to anyone with a background in computer science. For Linux to become useless for serious work, if it continues on this present path, would be a great tragedy.
This has been fixed, although the default behavior is still wrong and the solution is buried in an invisible configuration file. See: ../ How to Build a Useful Computer -> Basic Principles: The CWD and GTK.
Update (2014): This has NOT been fixed. Indeed, the developers are defensively entrenched and have explicitly refused to fix it (or even to offer alternatives). As such it has escalated from simply being a very bad bug to being an attack on free and open software generally. This is not the Linux way. See also: ../ How to Build a Useful Computer -> Basic Principles: Avoid Hubris (GIMP 2.8).
GIMP versions through 2.7 all had a minor annoyance. Because GIMP works with many kinds of image formats, internally it uses its own image format which in theory should be more capable than all of them. This means that it is easy to do work in the GIMP which cannot be saved in the image format you started with. For example, you might have an image in a format which doesn't support layers or transparency, but in doing fancy work in the GIMP on it your image might come to have layers or transparent areas. When saving these images, GIMP 2.7 and earlier warned you that you were saving to a format which didn't support these features and that they wouldn't be saved with the image. This was, indeed, slightly annoying, but it was, at least, correct.
Starting with GIMP 2.8, the developers deliberately "fixed" this annoyance by introducing behavior which (1) is simply not correct (from a semantic point of view), (2) introduces more serious annoyances for anyone attempting to use the GIMP in a logical manner, and (3) is itself a worrying case of hubris.
The basic behavior of any program which deals with external data is that it reads that data, does something with it, and writes it. You can often cause a program to write to a different data format, but that's a choice - the default behavior has, since the 1890s and punched cards, been to write the same style of data that you read. This is sensible operation that is deeply ingrained into computer science and computer use. If you open a PDF, and then want to save that PDF, your PDF program shouldn't save it automatically as a LibreOffice ODT file because it thinks that ODT is better. When you take a book off a shelf, you don't expect it to transform itself into a Kindle when you put it back.
But that is exactly what the GIMP does from 2.8 on. It covertly redefines the semantics of "open" to mean "import." You cannot actually open a file in the GIMP. For example, trying to open a PNG file will cause the GIMP to read the PNG file you specify, convert it into its own internal format, and then forget that it was ever a PNG file in the first place. Converting to an internal format on opening is fine; forgetting the identity of the format read is not. If you open a PNG, do nothing, and then just save the file you "opened," the GIMP will save a conversion of it in its own internal XCF format. If you tell the GIMP in the popup window for saving that, no, this is not an XCF file but a PNG file, the GIMP refuses to do this. In order to open a file and save the exact same file, you must now "export" the file to itself.
This quite obviously breaks the semantics of "open" and conflicts with 120 years of data processing and 60 years of computer programming. But it is a bug which goes beyond stupid. The developers of the GIMP who, very deliberately, introduced this bug are not literally stupid - I'm sure they passed their classes in college. Rather, they are suffering from a bad case of hubris - thinking that they are like unto the Gods. I'm sure that the GIMP's XCF format is lovely, but it is an internal file format - not a standard for image exchange. To redefine "open" to mean "import to XCF" and "close" to mean "save as XCF only, never anything else" is to believe that one's own internal image file format should replace all other image file formats, regardless of what the user actually needs to do. Hubris.
It is of course possible to work around this - one simply ignores the fact that the GIMP has this broken "save" option. You just always must use export when you mean save. This is annoying because every time you do this it is impossible not to think about how dumb the GIMP has become.
This workaround does, however, introduce a more serious annoyance. Because you're exporting a file each time you want to save it, the GIMP never registers the fact that you have in fact really saved your file. So when you want to close the file or quit the GIMP, it warns you that you have "unsaved" files and you must take action to ignore this warning. This is a minor annoyance if you've just "exported" (that is, saved) the file recently. If it happens that you've had the GIMP up for a few days and can't recall if you did in fact "export" (save) the file, you must go in manually and verify whether or not you did save ("export") it. This annoyance is of course much worse than the trivial one that the GIMP developers were trying to avoid when they broke the GIMP.
Update (2014): This has not been fixed either, but it is a much less serious issue than the GIMP 2.8 Save behavior. See also: ../ How to Build a Useful Computer -> Miscellaneous Application Notes -> Inkscape's File Saving Types.
In current (e.g., 0.48) versions of Inkscape, the save menu will only allow show you files with certain extensions - and the list of extensions does not include an "all files" option. So let us say that you want to use Inkscape to annotate a PNG image (something that is common if, for example, you are writing technical documentation). You open Inkscape, import the PNG, and scribble all over it. You probably want to save the file to an SVG file based on the filename of the original image - but neither PNG or "all files" are in the list of possible file extensions, so the actual PNG file can never be seen by you in the save dialog. You just have to retype it all - you cannot get it from the "save" dialog and modify it.
Both the GIMP and Inkscape are coded as Gnome applications and so they use the crippled Gnome file choosing and saving dialogs even if you're running KDE. Combining Gnome's inability to use the Current Working Directory with GIMP's need to export or Inkscape's refusal to show you all the files in a directory results in a system in which is hideously difficult to do simple and very common tasks.
Update (2014): This was fixed in bash 4.3. It is now preferable to upgrade to bash 4.3 rather than to downgrade to 4.1. Unlike the GTK/GIMP/Inkscape bugs, this one wasn't the result of a bad design decision but rather was an unexpected consequence of an otherwise rational design change. In other words, it was simply a normal bug, and like all normal bugs it was fixed.
In Firefox 15 (at least, maybe slightly earlier) fragment URLs (the ones with "...#location-in-file") of at least the "file://" type lose the after-the-pound fragment when they include a filename which is a symbolic link. The hyperlink, which now no longer has the #fragment location within the page, just takes you to the top of the page. This is newly broken behavior (it was correct in all versions through at least 13). I had to rebuild an 80 Gigabyte website to work around this bug.
This forces any development version of a website, or any information organized locally using HTML (which is very, very useful) to avoid symbolic links. Symbolic links are integral to UNIX, but Firefox breaks UNIX.
As of about Firefox 13, the autocompletion of URLs (a) would often simply not work (and do this irregularly - you'd open a tab and autocompletion would fail, then open another tab and it would work there), and (b) would often take so long that keystrokes were lost while typing. It is possible to tune it so as to minimize these problems, but still they are bugs. Any computer running Linux today is powerful enough that it would have been called a supercomputer a couple of decades ago. For an interactive application on such a machine to run so slowly that it drops keystrokes is embarrassing. Hollerith didn't drop keystrokes in the 1890s using cast iron machinery; have we fallen behind him in the 2010s?
Update (2014): This hasn't been fixed in the more mainstream Gnome world, and remains problematic in KDE. But I've discovered that neither are necessary, and that the most effective graphical working environment simply requires a good, lightweight window manager such as FVWM which provides both Viewports and Workspaces. See: ../ How to Build a Useful Computer -> Viewports and Workspaces; FVWM.
Update (2014): 7+ Terabytes, and 4.3 million files. So-called "semantic" indexing remains both a misnomer and a denial-of-service attack against the serious user. Fortunately, in Arch Linux it is not enabled by default, as it is in Ubuntu. See: ../ How to Build a Useful Computer.
The real problem is that it is not practical for serious quantities of data. At the moment, for example, my desktop system has over 6 terabytes of data and nearly 3 million files. Each time I install a new version of Linux, I have to scramble to turn off these "features" before nepomuk and its cousins start consuming the CPU for days on end trying to grind through it all and produce indexes which themselves consume vast amounts of storage.
All portions of this document not noted otherwise are Copyright © 2012 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]