找了十好几个源都没有，郁闷透了。 
另求各位推荐个软件比较全，速度差不多的源吧。
没有。 这个软件很冷门，而且是 java 软件。 Linux 社区比较反感 java 软件
1，你从 freeplane 的 官方网站 ](http://sourceforge.net/projects/freeplane/files/freeplane%20stable/) 下载 freeplane_bin- 版本号.zip
2，解压到家目录下的任意目录
3，运行 sh freeplane.sh
前提：已安装 jre 或者 jdk
优点：绿色、无需安装、重装系统后还能正常运行
缺点：系统不能管理 freeplane 的版本。
为啥反感 java？必须安装 java 解释器？
现在呢会说：
1，有些发行版默认不安装 JRE，或者安装的 JRE 不是 Oracle 的
2，Oracle 是个开源吸血鬼
3，JRE 个头太大了
其实在我看来，linux 桌面环境不待见 Java 的根本原因（企业应用市场其实对 Java 还是没有成见的）：
1，linux 桌面环境的应用是 C（Gnome）、C++（KDE）、Python 的天下，容不得 Java 来插一脚,
2，Java 在整个桌面应用开发生态体系中确实没有占据有利位置
3，有些人认为 Java 慢（其实我不认同，Python 不是更慢吗？）
补充一个可能不算问题的问题：Swing 界面太二，不论放哪儿都是四不像
这是算是一个，可是 SWT 程序界面是原生的，还是一样不受待见。
Java 软件很烦人…… 乱七八糟。
这里是以前一个 jpackage 项目对 Java 程序开发者表达的几点期望，openSUSE 的 wiki 上也转载了。这也是我讨厌大部分 Java 软件的原因，很多 Java 软件乱搞了一堆外部的 Jar 文件放在里面，导致我不知道怎么完全自己编译、怎么完全使用我信赖的源所编译的软件，导致依赖关系的跟踪完全乱得一团糟，大量制造冗余的文件、浪费磁盘空间，等等。Java 的依赖关系似乎是不够明了的，比如说某个软件可能依赖 libpng，Java 软件应该也依赖很多其它包啊，比如说某个 Java 软件可能依赖一个处理 PDF 的 java 包，但是在 Java 里我感觉很难把这些关系给自动化得处理清楚。
糟糕的比如说 Eclipse，Eclipse Foundation · GitHub 实话说我不知道怎么自己编译、打包这个软件。 水平不够，呵呵。
Freeplane 还好，有一个指导：cd 到某个目录运行 ant 编译。 但是依赖关系呢？ Java 也有很多库，他有没有依赖什么别的库？ 不知道，作者没有提供。 或许要去看 ant 的 xml 文件啊。 但是很多其它语言的软件，在 README 活着 INSTALL 里都详细著名了依赖的软件包和版本。 而 Java 最后就是作者自己把依赖和软件一起编译成 jar 然后你下载运行。 实在是不敢恭维。
另外我不止一次遇到 Mac 用户写的 Java 程序，比一般的 Java 程序还要恼火，不光直接给你一堆和依赖打包在一起的东西，而且有很的竟然直接无视系统权限，要在根分区里面创建临时文件（我特意试验了 Mac 系统确实对根分区缺乏权限保护，我没有获取任何 root 权限就可以篡改 /usr/bin 的文件！这软件的作者估计都被惯坏了，一个 temp 都要扔进根分区）。
当然这只是某一个软件。但是前面叙述的关于依赖关系、第三方 Jar、源代码发行的问题，在 Java 里是普遍存在的。
楼上列出的原因是 jpackage 社区提出的，是我反感 Java 程序的主要原因，openSUSE wiki 英文版也引用了 jpackage 的陈述。
当然最根本的 java 在这个社区里用的人少。 企业市场不关心这些细节，企业要的就是成本低、能提高企业运行效率。 Java 软件满足了这些需求。 而且 Java 程序员数量达（不过 Lnux 社区里的数量应该少），解雇程序员就会更方便，可以随时解雇（在美国解雇员工比中国容易，在中国是很多劳动者不懂法律武器，中国的劳动法实际上是比较严苛，对雇主不利的）、换人，这就可以压低劳动者的劳动价格。 如果使用小众的程序语言的话，那么雇主就面临解聘现有程序员之后招新人比较困难的局面，就会使劳动者在劳动关系的谈判中处于主动地位、抬高劳动者的身价。 这样的市场化就业机制使得新兴的先进技术在积累到极其巨大的突破（比如说出现一种编程语言使得开发同一个软件所需的代码量、劳动量缩小了 100 倍，可能很多老板就要使用先进技术了）之前，存在市场的阻力阻止企业使用新兴技术，一定程度上阻碍、妨碍的创新。
** 关于依赖关系和第三方 Jar：**
采用 Java 语言编写的程序，主张的是一次编写，到处运行。对于普通用户来说，无需你关心安装问题，因为无需你安装而只需要拷贝 ; 也无需普通用户关心依赖问题，程序通过内置所依赖的 Jar 包来解决，与 linux 发行版通过包管理机制来进行依赖管理不同的是，大多数的 Java 应用为了屏蔽操作系统 / 发行版的差异性，只能采用内置依赖这种做法，毕竟不同的操作系统 / 发行版的软件依赖管理机制有差异性。只能说 Java 程序为了平台无关性，牺牲了磁盘空间，这个是取舍问题。
而对于开发人员来说，Java 有自己的包依赖管理机制，常见的有 Maven，Ivy，gradle 等，也有自己的在线包仓库，只要不是太烂的 Java 工程也会提供自己的构建脚本，只是和 linux 的 make 或其它构建程序不同而已。至于你说 Java 程序的依赖关系不明确，以你提到的 freeplane 为例,freeplane 既然可以通过 ant 完成编译，说明了它提供了 ant 构建脚本，所有的依赖关系都在构建脚本中有描述, 只能说你不清楚 Java 的构建工具，所以你不知道。有的 Java 工程不提供构建脚本，那是开发人员的问题，就好比 linux 下的一些 C/C++ 工程一样也没有提供 makefile 或其它构建脚本一样。
** 关于 eclipse 的编译：**
首先，eclipse 官方提供了适合各个操作系统的可执行程序，直接下载解压就可运行；其次，eclipse 自己提供了版本自动更新的机制，也无需操作系统来关心。
至于编译，说实话，我也不会，也没有怎么关心过。我只会基于 eclipse 开发插件，依据需求开发封装打包成自己的应用，就如同 xmind 那样。
** 关于你遇到的 Mac 用户写的 Java 程序写临时文件到根分区：**
我只能说你遇到的这些 Java 开发人员顶多算刚刚入门。
我们 linux 桌面用户不喜欢 Java 程序，我能理解，但是举出来的论据无法支撑论点，那我觉得我还是可以解释下的。
或者你说“不管怎样我就是不喜欢 Java 程序嘛”，我还是能理解，各有所好嘛。
说得不错，确实有跨平台的因素。
ant 脚本是有，但是你看作者的态度一般是不同的，freeplane 是有 ant 脚本，但是 readme 文件里没有说清楚，我必须读 ant 脚本。很多其它程序有一个 INSTALL 文件，对于我这种普通用户只需要看 INSTALL 文件即可，不需要阅读 makefile，我也很少阅读 makefile
我觉得我的论据很好地支撑了论点，java 的这些包管理机制让很多具有“依赖洁癖”（不愿意让 lib 重复安装）和“源代码洁癖”（不接受第三方编译好的文件）的 Linux 用户感到不爽。 openSUSE 和 Fedora 的 Java 打包守则都提及了 jpackage 所提出的守则，这说明这一观点确实是得到很多 Linux 发行版官方源打包者的基本认同的。
我们谈论的是为什么 Linux 发行版社区不待见 java，Linux 发行版社区并不是普通用户的群体。很多普通用户就装得乱七八糟，根本不希望使用 zypper、yum 这样的工具。但是 Linux 发行版社区确实有不少，我感觉不是很待见 Java 的。 我感觉.net 比 java 更受待见，我也更喜欢.net