lazlo.vii

Dispatch-conf is like a kinder, gentler etc-update.

When I did a fresh Funtoo 1.3 install on my desktop PC I just set my profile with epro and installed the KDE meta package and it worked (nearly) flawlessly. I did something like this: #epro flavor desktop # epro mix-ins kde-plasma-5-new # epro mix-ins no-systemd # epro mix-ins gfxcard-nvidia # emerge -vauND --with-bdeps=y @world # (say yes to any USE flag changes) # dispatch-conf # emerge -vauND --with-bdeps=y @world #emerge -va xorg-server nvidia-drivers nvidia-settings # emerge -va plasma-meta # (say yes to any USE flag changes) # dispatch-conf # emerge -va plasma-meta I have zero USE flags set in my make.conf and in package.use I only have what portage added.

I don't know much about Daniel's decision making process or about how ego and Funtoo kits work. What I do know is that I want a stable OS that gives me a large amount of control with minimal effort. No other distro gives us this level of control and stability for this level of effort. I am willing to give up the rolling release model if it helps Daniel perfect the cost/benefit ratios of Funtoo. I don't want to fight with my computer systems, I want to use them. The same is true for my friends, my family, and their businesses. It can take a lot of time and effort to keep a production server stable without worrying about a rolling release model that builds a major system malfunction into the OS every six months. People will put up with a lot of things in life but smart people will not but up with wasted time. Most people won't use Funtoo because they see source based distros as a waste of time. I think addressing those concerns is vital to the future of the Funtoo project if it is going to grow financially. My best guess is that if the project doesn't grow financially it will not expand far beyond what we have now because Daniel needs to feed a family and pay his bills.

For the first time in several years I am testing Funtoo on my desktop. If I can keep it stable I'll stick with it. Here is my KDE Plasma Desktop:

I want to ask a few questions before I take action. I think it's better than asking questions after I have broken my system. 😉 In /etc/genkernel.conf we can add all of the kernel modules to the initramfs by un-commenting the following line: # =========MISC INITRD CONFIGURATION============ # # Copy all kernel modules to the ramdisk #ALLRAMDISKMODULES="1" This seems like it's all or nothing. I just want to add the proprietary Nvidia drivers and the ath9k drivers for my usb WNIC in this case but it could be handy for quite a few other things as well. In Gentoo groups of pre-defined modules can be loaded from /usr/share/genkernel/defaults/modules_load and this file does exist in Funtoo but the related section is missing from /etc/genkernel.conf. Is it safe to enable this in Funtoo? If so I could easily add custom modules from there. If it isn't safe is there a better way to do this?

I really do recommend checking out the Devuan live CD. It has a tool named refactra that will allow you to create a customized Devuan live iso. If you truly want to create your own personal mini-distro you could even use the Devuan Simple Distro Kit (SDK). Unless you are stuck with very limited bandwidth either option will give you a great deal of choice and perhaps help you create the perfect personalized tool kit.

I saw that on distro watch yesterday. I don't think it will affect me much. I started using the Devuan Ascii live CD to do my Funtoo installs. It uses a Debian 4.9 kernel and supports UEFI. If there is anything I need that isn't already installed it's just two apt commands away. In fact the biggest problems are not really problems at all. First /bin/sh points to /bin/dash and second I have to remember to type /usr/sbin/chroot at the correct point during the install.

I have never tried to make grub see a RAID created with mdadm. I always keep /boot somewhere off of the RAID. So I don't know if either of these two suggestion will work. 1.) Tell grub to use /dev/sda as it's root. Something like "set root=(hostdisk//dev/sda,msdos1)" in you grub.cfg would work for that. 2.) Try installing grub on the RAID itself: "grub-install --boot-directory=/boot/ --modules='part_msdos mdraid1x' /dev/md127" Honestly though, I am not really sure that will work. For easy recovery in the event of catastrophic error I have learned the hard way (HINT: Don't make typos when executing a wipefs command) that having /boot accessible without any bells and whistles is the best way to go.

OK, I finally got around to adding a desktop to my server:

It will only have an effect if: 1.) The code being compiled comes from portage and 2.) The ebuild for that code specifies the use of the CPU_FLAGS. So, no ebuild = no settings from Portage are used by gcc.

CPU_FLAGS used to be standard USE flags until some people that know a lot more about Portage than I do decided that they were tired of having a lot of USE flags for CPU options that could be enabled globally or per package and might have different meanings depending on which package you were talking about. In an effort to stream line the code base and end the confusion they decided that all CPU options would be moved into the CPU_FLAGS settings. I don't think that Portage will care if a CPU_FLAG is included even if no ebuilds use it. I think that they will just be ignored in the same way that Portage ignores invalid USE flags. So if I am right you could add "CPU_FLAGS_X86="12_dozen_hamsters_running_on_wheels" and Portage wouldn't not care, but PETA might.

Hardkernel.com has released the Odroid-H2. It's an SBC based around an Intel Celeron (14nm, 10W TDP) with dual Realtek 1Gb NICs, dual channel DDR4 SODIMM slots, 2 SATA3, and one m.2 NVMe slot. This looks like a fun project with some very serious uses. While I don't need another computer at all I am having to talk myself out of buying one so I don't blow my budget for Christmas. https://www.hardkernel.com/shop/odroid-h2/

I think that Microsoft knows the kind of problems that would be caused if they abused their ownership of GitHub and I think they know beyond a shadow of a doubt what it would cost them: https://www.theregister.co.uk/2018/06/08/nat_friedman_github_ceo_elect_ama_session/ Let's face it, when it comes to freedom, privacy, an open market, and just about every other category of economic threat you can imagine Google/Alphabet/Android/Chrom* is bigger than Microsoft ever was. If Microsoft wants to stop their market share slide (much less regain market dominance) then they need software developers to like them and to work with them.

For a long time I have wanted a simple and secure way to deploy NFS. While there are some options such as Kerberos it's not what I would call easy to set up. This may change based on what I read here: https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-00 I won't claim to understand a lot of what is there. If this becomes the new standard for NFS or even RPC in general could it then be possible to add USE="tls" to a later version of the packages and have it work "out of the box" with a stable and sane default config? If someone has a valid SSL/TLS cert via Let's Encrypt could that same cert be used for encrypting all of their NFS and/or RPC traffic? Thanks for putting up with my questions.

I have changed my mind about the size of LV's and decided to go with 8GB instead of 4GB so I don't have to guess about having enough space in /*/tmp to compile a new kernel. I'll edit this post to add my results when I get done. Hopefully that will be within the next 3 hours. Well, I have run basic tests with defrag and zlib compression and changed RAID back and forth from 0,1, and 10, added large amounts of data, deleted some of it, did it all again, made a few snap shops, deleted them, and so on. I can't find any obvious problems with the usage or functionality of kernel 4.9 on a btrfs filesystem created with newer kernel. I know that data point doesn't make a statistically useful sample, but it does put my mind at ease.