Sorry if you caught the jag I went off on there. I think that I may actually have it installing correctly now. I don't know what changed or what I did different but things are going a lot smoother now.
have Funtoo in one box and it work great, did you choose the stable or current branch ? the current branch has alot of new-version/new-patch, it means alot of recompilation when updating.
Yea, the latest attempt turned into another fail. Installed stage3, got it all configured out, installed X, had that going with twm, installed KDE, fail. No KDE, no more X. It took about 10 hours to compile KDE. I'm not going through that again. Gnome wouldn't have been that much easier at ~380 packages compared to KDEs ~425. While it was fun trying, it not a viable option for "general desktop use".
I can run Slack on it with no issues, just did a clean install on it and compiling and testing custom kernels without issue. (Dual-boot Windows 7-custom/Slackware64-current-custom) Not that I know for sure that there aren't bad sectors, I just haven't had any issues with anything else that I've tried on that laptop. I just think that their install process is a bit too much. I know that a long time ago when I started with Linux that is how it was done, but things like KDE and Gnome have become too bloated to compile from source without leaving a bunch of junk out. For instance, from my KDE installs I remove all the games, Calligra, and a ton more of the "bundled programs" that I myself will never use. It would take a lot of reading and prob a bunch of forum time to be able to figure out how to do that while drawing from a repo and building in real time. The "relearning" curve is too great for me to make a full-time switch to Funtoo or Gentoo. That and tons of compiling and recompiling. It is nice to see that there are distros out there that still do things that way, but for my little processors it's a bit strenuous and time consuming. If it were just the kernel and a few other things that needed to be compiled it wouldn't be such a big deal. I know that revertex mentioned distcc to help compiling, but I would have to track down dependencies that I'm sure I don't have installed and set up a network that I know I don't have drivers and dependencies for currently. Or just do a full Slack install, which I really don't want to do. * This Funtoo experience has got me currently thinking about making my own little Slackware based distro that would be compiled completely from source. Just as a learning experience.
I used gentoo in some machines in the past, only time I've got compiling erros where when I've hardware failure. Most compiling errors are cause by bad RAM, run memtest in this case won't hurt. Bad RAM is not easy to detect by daily usage, sometimes the bad sector is only used when memory is almost full.
I ran memtest86+ for 10 passes with 0 errors. (Took ~5 hours) It is not a memory error. I am installing FreeBSD compiling xorg from source as I post this. So far no errors. *Edit Scratch that, had to use test laptop for other purposes. xorg compiled fine though, with no fatal errors. Was able to log into x and begin to compile KDE, but had to quit.
3 years ago every major distro had sys v init. Now every major distro has systemd. Actually nothing has changed. The whole systemd debate is essentially nonsense. systemd is just a piece of software that starts other programs on system startup. Linux does not get less "free" because of that. I really don't understand the whole discussion. Probably this is all about that debian has decided to adopt a piece of software from another distributior (RedHat) that some debian people see as an arch rival or at least a competitor.
What you actually need is systemd, systemd-udevd and systemd-journald. Anything else is completely optional independent from each other daemon systemd-udevd is the same udevd by Kai Sievers (a co-author of systemd and also the author of the original udevd) that has been in use for many years. It just has been renamed from udevd to systemd-udevd. systemd requires it start certain services not earlier before some devices are actually up and running. systemd-journald is not meant as a replacement for the various syslog daemons (e.g. rsyslog or syslog-ng). The problem here is that there are many syslog daemons and they can be configured in various ways including that the actual log is on a remote machine. systemd needs logs at defined place where it can access them. Thus it provides journald in addition to an existing syslog daemon which is untouched by systemd or systemd-journald. Most distributions also now use systemd-logind for graphical login (gdm session) instead of ConsoleKit. But you can easily switch back from systemd-logind to ConsoleKit. systemd-logind is completely independent from systemd. You are also absolutely free to switch back from systemd to sys v init or any other init system. In this case you may remove system-journald. You should keep systemd-udevd which is required by most distributions. You'll never need daemons like systemd-networkd, systemd-timedated, etc. and distributions do not use it. Well, people should better build their opinion on facts instead of "Famous Quotes" especially when they come from obviously less techical people. For example systemd does not do "GPT partition discovery" simply because it is a little bit too late for partition discovery when the kernels load /sbin/init. What systemd-nspawn (a complete optional component that is not even a daemon) actually does is partition discovery when you start a container that consists of a disk image instead of individual files. But every program that handles disk images has to do partition discovery to do something useful with a disk image. systemd also does no "time management". systemd-timedated does this, if you want. The hostname is actually a kernel variable which systemd may set. Other utilities (hostname, sysctl, etc.) can also be used for that. Every dhcp client sets the hostname if it receives one in a dhcp response. So no big deal. As I said before, there are various systemd-xxxxxd components, that no one actually needs. There is no demand for replacements of dhcpd, ntpd, crond, etc. So the systemd people should have focused on that whats needs a replacement. However, these daemons are completely independent and no distro I am aware of is actually using them. What distros actually use is systemd (the init replacement), systemd-udevd (which is the same udevd used for many years) and systemd-journald (because systemd requires it and does not replace any syslog daemon). Most distributions also replaced ConsoleKit by systemd-logind for login to the graphical session. That is the whole story. And this makes things a lot easier. You now start your daemons (like sshd) with a config file that actually has 10 - 20 lines instead via a complex bash script that has 100+ lines.
the fact still remains that if one was so concerned by any one feature becoming standardized, that one could easily create their own build of debian using whatever they like... when something is open-source, it is essentially "free" until that source becomes closed because any one can add to, modify, or scrap that source in favor of producing something that suites their needs / desires for that particular piece of software. this debate is really no different in my opinion from the selinux discussion in the linux android kernel. far from trying to be an ass, but if you don't like something that is open source, then change it and build it how you want it, that's why it's open source.