4 ms·

Using an abandoned free software project is rarely going to be much fun, either. In fact, using actively maintained free software projects is rarely much fun, s

by _yosefk 10y ago

Using an abandoned free software project is rarely going to be much fun, either. In fact, using actively maintained free software projects is rarely much fun, since many of them tend to often abandon old features and introduce new incompatible ones, and you either have to keep using old versions of everything or update everything at once, breaking a ton of things. (Of course at times you're way better off with a free program than you'd be with a proprietary alternative, but the reverse can be true just as much in other cases.)

pjc50 10y ago
using actively maintained free software projects is rarely much fun, since many of them tend to often abandon old features and introduce new incompatible ones GNOME has a lot to answer for. Most other projects try hard to avoid this and lean the other way, preserving ancient features at the cost of clarity.
- _yosefk 10y ago
  I dunno, KDevelop 4, based on KDE's rather than Gnome's libraries, was nothing like KDevelop 3 and couldn't do some of the old things, and there was no way you could compile KDevelop 3 on an Ubuntu box bundled with KDevelop 4 and the new KDE libraries unless you were really good at this shit. Eclipse, based on the JVM, had a popular plugin that was broken, I think, in Juno or a bit earlier, and whose author refused to update it for the new Eclipse because too much of the things in Eclipse he depended on changed. Upgrading Emacs broke everyone's emacs-lisp hacks that they copied from each other. And so forth. I think that in the land of Linux, the only things which remain backward compatible are the kernel (if you want to run statically linked userland binaries - not if you want to run driver binaries) and the GNU userspace utitilies like sh and grep (though sh is bash on some distros and dash on others, breaking the very popular assumption that sh is in fact bash, and env might reside in either /bin/env or /usr/bin/env, defeating its purpose of letting you deal with the fact that #!/bin/tcsh will break on systems keeping tcsh at /usr/bin. But a given distro will usually keep its shit where it last put it, which I guess is better than it could have been.)

by _yosefk 10y ago

pjc50 10y ago

using actively maintained free software projects is rarely much fun, since many of them tend to often abandon old features and introduce new incompatible ones GNOME has a lot to answer for. Most other projects try hard to avoid this and lean the other way, preserving ancient features at the cost of clarity.

_yosefk 10y ago
I dunno, KDevelop 4, based on KDE's rather than Gnome's libraries, was nothing like KDevelop 3 and couldn't do some of the old things, and there was no way you could compile KDevelop 3 on an Ubuntu box bundled with KDevelop 4 and the new KDE libraries unless you were really good at this shit. Eclipse, based on the JVM, had a popular plugin that was broken, I think, in Juno or a bit earlier, and whose author refused to update it for the new Eclipse because too much of the things in Eclipse he depended on changed. Upgrading Emacs broke everyone's emacs-lisp hacks that they copied from each other. And so forth. I think that in the land of Linux, the only things which remain backward compatible are the kernel (if you want to run statically linked userland binaries - not if you want to run driver binaries) and the GNU userspace utitilies like sh and grep (though sh is bash on some distros and dash on others, breaking the very popular assumption that sh is in fact bash, and env might reside in either /bin/env or /usr/bin/env, defeating its purpose of letting you deal with the fact that #!/bin/tcsh will break on systems keeping tcsh at /usr/bin. But a given distro will usually keep its shit where it last put it, which I guess is better than it could have been.)