Hacker News Reader

Jdee is a pile of garbage which made me quit emacs twice before finally ignoring the package altogether on my third (successful) attempt to switch. While other deb packages exhibit the same symptoms from time to time, jdee specifically doesn't surprise me. JDEE has the midas touch but instead of gold you get shit. I feel pity for the debian package maintainer attempting to salvage such a horrible mess of code.

I didn't realize how angry JDEE made me. Two years passed since I tried to use it and that package can still bring out some latent rage.

Is it a pile of garbage because it is hard to install , or because it isn't very useful?

Is it worse than say eclipse?

I never had a fully functional install of JDEE, so I won't compare it to eclipse. Configuring JDEE itself gave me nightmares. From what I remember, I would set variables to the proper VM and experience no change. At the time I gave up on JDEE I had the opportunity to switch to Python and I never looked back at Java.

I think JDEE suffers from being too large with too many dependencies. Emacs configurations make almost every install unique and I think the maintainers of emacs projects in general have a hard time supporting users because people generally stop writing documentation when "It works for me." The same way you find your keys in the last place you look.

For instance http://jdee.sourceforge.net/install.html

Download the latest versions of Eric Ludlam's speedbar, eieio, and semantic bovinator packages and install them on your system, each in their own directory.

You can download these packages from SourceForge.

Note Emacs and XEmacs include earlier versions of speedbar that are incompatible with the JDEE. You must delete the earlier version or ensure that it is not on the Emacs load path. Otherwise you will get a Lisp error when trying to start Emacs.

That documentation might have made sense at the time. but I'm currently using emacs 23.3.1. Is my version of speedbar still out of date? Do I have to downgrade it? Upgrade it?

http://cedet.sourceforge.net/ The cedet page for getting those "newer" packages only provides download links to the entire cedet package. And without version references in the documentation how can I tell if my debian installed version might be good enough?

incidentally if anyone has a solution to this particular problem with jdee I'd love to know :)

Shameless self-promotion ... over the past year, I've been working on a project that aims to solve this dependency hell problem: http://www.stanford.edu/~pgbovine/cde.html

All you need to do is find a distro where jdee works, package it up with CDE, and then transport it to your own machine. email me if you have questions.

Oh , that is very cool. I think you should try and setup some sort of repo for common problematic software though since I don't have a space machine to build on.

Does seem like quite a drastic solution to this problem though.

So you are using ptrace to intercept system calls and then copying files that are used. I suppose the problem with this is that when you are running CDE to generate the dependency list it is down to what is actually used, so if you don't hit every piece of code in the program when doing the "generation" part you may not get a completely working package.

I suppose you can do some evaluation on the binary to figure out which calls it might make during execution but this wouldn't work to well if the software in question is built using something dynamic like python where library calls may not necessarily be the same so cannot be predicted in advance?

I have run into errors like this and share your frustration. I mitigate them as follows:

0) I think problems like this are often fixable if you are an APT wizard, which I am not. But sometimes a look at the Debian docs makes an inscrutable error scrutable. I also usually get more helpful (and current) advice on the debian-users list than search engines turn up. [1]

1) I run Debian stable. I think errors like this are fairly common on unstable and mixed systems; I don't know how common they are on Ubuntu. But I believe I have never run into a problem like this on the stable release.

2) If trying to compile everything from source, the deb tools can help a lot, too (apt-get source, apt-get build-dep). It's only if you get to the point of downloading a source tarball from a third party that you have to completely leave the cozy world of APT. (And even then, I find I have better luck than on other platforms, because I can still use APT to install dependencies. No such luck on, say, OS X, at least not without a third party package tool.)

[1] See http://lists.debian.org/search.html to search the list archives.

I run Linux mint (based on ubuntu which I think in turn is based on debian testing) , usually I search for Ubuntu related troubleshooting as there is allot more of it but of course not all is applicable. I think this becomes more of a problem the more each distro gets forked, if there was one definitive Linux desktop distro then this problem would mostly go away I think.

I've tried asking on mailing lists in the past (admittedly a long time ago) but generally find that I often get no answer or an answer which asks all kind of questions I don't know the answer too.

I've used build-dep stuff before , but I sometimes find that build-dep breaks when the packages break.

What I find odd is that complex stuff like kernel/driver/server upgrades usually go without a hitch and I only tend to get these problems with stuff like jdee (which is basically just a text editor plugin).

Don't use Debian Unstable/sid unless you know how to fix packages and are prepared for the whole thing to break. It's called unstable for christsakes.

I've experienced this problem with Ubuntu and Linux Mint which are supposedly easy distributions.

Unfortunately, they are not billed as stable distributions - they're based on Debian Unstable (sid). This fits their emphasis on user-friendliness, as the packages in more stable Debian branches can be years old, in some cases. In essence, Ubuntu has chosen features over stability. In this, it's much more friendly than vanilla Debian, especially for the GUI-only user, but tends to have more bugs (including APT packaging/dependency bugs) than the legendarily rock-solid Debian.

To me a big part of user-friendliness includes being able to install programs easily without having to wade through dependency problems.

This is a big problem with Linux , debian based distros in particular. There is always a sense of "If you want A you should use distro X , if you want B you should use distro Y". When A and B are often just sides of the same coin and should not be mutually exclusive.

I agree, but I feel that this is part of a bigger problem - bugs are not user-friendly, but sometimes bringing in user-friendly features - like the newer, more intuitive/well-rounded version of a package - introduced bugs, which are not helpful to the user at all.

I don't feel that this is at all an artifact of distribution niches. Rather, this is a universal phenomenon of software engineering: every change (including bugfixes!) tends to introduce bugs. While bugfix changes usually (though, as many readers will know, not always) reduce the total bugginess of your product, most other changes tend to increase bugginess. So there's an inherent trade-off between on the one hand having a short development cycle, a good (for some definition of good) feature set and quick latency between the design and implementation stages, all of which can be used to make a product more user-friendly; and on the other hand having no bugs, which is also a big contributer to user-friendliness.

tl;dr: Ubuntu's customized design and up-to-date packages are not orthogonal to its bugginess; Debian's years-long testing and integration process is not orthogonal to its years-old package selection.

I entirely agree, but I think having so many distributions exacerbates the problem because there is so much fragmentation in terms of stuff like testing and support documentation.

If I have a problem with my Linux Mint install and find something related to fixing the problem in Debian there is a fair chance it will work, but then again there's a chance it doesn't. If the solution is written by a slackware user the chance that it will help is even smaller.

Lack of bugs and issues is a huge part of the overall user experience. There seems to be a belief that making a shiny product that looks like something from apple will make it more friendly to users, this is fallacious.

I think the original reason that the mac was perceived as being more user friendly was only partly down to it's UI and mainly down to the fact that Apple had a simpler and more focused idea about how their product should work and what it should do (controlling the hardware helps somewhat here) and therefor there was just less surface area for bugs.

Linux has the problem of being a patchwork of software with different levels of quality put together by different people with different ideas about how things should be. Whilst this has it's merits it does lead to some problems which really have no right to be real problems.

If you use aptitude in the ncurses ui mode then you can generally get somewhat more information and ways to solve problems.