david <david at daku.org> writes: > I'm sure the Centos team has done a yeoman's job getting Centos7 > ready, and that the Redhat team has done marvels in creating rhel7, > but here's a little voice from a personal hobbyist user. I'm not sure why you're voicing these here. Since CentOS matches RHEL bug-for-bug, you'd stand a better chance of getting your voice heard by talking to Red Hat. > If someone has some elegant solution, I'd love to try, but Centos7 is > still unusable for me. Define "unusable". Clearly it's objectively untrue that it's "unusable" because many people are in fact using it. > 1: Firewall changes > The change in firewall technology forced a complete re-do of my > scripts which maintain firewalls, respond to attacks, etc. I think > I've programmed my way around the issues, but it wasn't easy. So...you've already done the work to adapt your current setup. > 2: Apache changes > These were subtle, but again were solved. Not sure what you're referring to here, but again, you've already done the work. > 3: Service -> systemd > The change from object-oriented view of service: (service httpd > restart) to function-oriented (systemctl restart firewall) seems to be > unnecessary, and counter to the way stuff is generally done in the > modern world. Nonetheless, it was possible to solve that with some > adaptive script programming. systemd, like it or not, appears to be the current future of Linux, with essentially every distribution adopting it. I can't say I'm a huge fan of this trend, but it is what it is. And again, you've already done the work. > 4) Something with Unknown lvalue 'ControlGroup' in section 'Service' > I don't know what to do with this. I constantly get the diagnostic: > [/usr/lib/systemd/system/rtkit-daemon.service:32] Unknown lvalue > ControlGroup' in section 'Service' > and attempts to browse the internet for solutions come across > barriers that require some paid subscription to view. This is > currently a progress-stopper. The messages I see deal with boinc, > which does not show up on my system using "rpm -qa | grep -i boinc". A quick glance at https://bugzilla.redhat.com/show_bug.cgi?id=999986 makes this look to be primarily a logging issue. Obviously it should get fixed, since it's a bug, but I don't understand why this is a "progress-stopper". Or am I misreading? > 5) Sendmail is out, postfix is in. > This is a huge change, since I had lots of scripts that tailored the > Sendmail system for spam protection, dealing with SmartHosts that > required SMTP-AUTH and others required weird configurations, etc. > Whether this is working yet I don't quite know, but it seems the > scripts can accommodate the change. # yum install sendmail{,-cf,-doc} > 6) Installation > I have no idea why, when using the net-install, one must explicitly > turn on the network. It seems unnecessary. That's a fair point, but presumably one Red Hat would have to answer. > 7) Lack of 32-bit support > I think I understand this. After all, 32-bit machines may become > "unusable" when the clock overflows, but isn't that a few years away, > and couldn't some solution be found, even if kludgy? Some of the > 32-bit hardware was of very high quality, and still runs perfectly. > I'd hate to spend a few hundred dollars each to replace all those > systems. As far as I know, there's no solution to be found. The 32-bit address space is just too small. Wikipedia says that 64-bit processors have been around since 1961, though for most uses (i.e., Intel/AMD) they only became practical starting in 2003, which is still over a decade ago. Practically speaking, at some point you'll inevitably have to replace those systems anyway. Wouldn't you rather do it on a planned schedule than as disaster recovery when something fails? When doing so, you might as well go to 64-bit. > 8) And more Don't know what this means. > I haven't got a server or desktop running to my satisfaction yet, so I > don't yet know what pitfalls await. Any advice would be appreciated. My advice is to read the documentation.