[wplug-internet] CentOS 7 RC

[Bryan J Smith]

On Sun, Jul 6, 2014 at 3:27 PM, Pat Barron <pat at lectroid.com> wrote:

>  At least for our current situation, WPLUG is planning a server migration
> to one of the new, lower cost Linode offerings, that is going to involve
> doing a complete server rebuild anyway - our current server is a 32-bit
> install, and the newer Linode offerings only support 64-bit.  Since we need
> to do a complete rebuild anyway, we might as well do so with CentOS 7, as
> long as we're at it.
>
If we could just bring up the current virtual disk image from our server
> under the new lower cost service offering, I'd totally want to keep it on
> CentOS 6 - I too see no reason to upgrade for the sake of upgrading, given
> Red Hat's lengthy support timeframe - I don't like to change things simply
> for the sake of changing,
>

There are even a few Red Hat customers who have such a view that they
didn't bother going to RHEL6, and stayed on RHEL5.



> so I ordinarily would not be enthusiastic about upgrading at this time,
> unless there were some specific new feature in RHEL 7 that we really
> wanted.  (I know that Justin is very enthusiastic about the idea of running
> a distro that uses systemd, which is being used in RHEL as of RHEL 7 -
> though of course, I personally see systemd as more of an "anti-feature"
> than anything else....  ;-) ).
>

​Obviously you didn't see the Debian commentary and voting.  ;)

I.e., a major reason why systemd was adopted was because major volume,
commercial Debian users were basically asking for it.

CoreOS and other, cloud-based solutions also leverage systemd.  So many
other UNIX flavors have adopted similar solutions.  Why?  In this day'n
age, lacking a system management system -- let alone just the init portion
-- that cannot check subsystems, verify resources are available, and
auto-determine dependencies (not just services, but resources and other
units) need to be available, is a major hinderence.  The Linux kernel, the
D-Bus solution, udev, etc... are all there, yet nothing has taken advantage
of it ... before the systemd and related *d solutions.

No more static dependencies, no more specialized auditing, no more
differences in monitoring tools, all unified, built around existing
services in any Linux distribution today, along with CIM (OpenLMI being one
project designed around instrumentation), etc...

Even the newer NetworkManager and firewalld is a Godsend once you learn
your way around it, and it's 10x quicker to try things out without having
to tear-down and rebuilt rules and settings over and over, often
conflicting.  When one is running anything libvirt atop as well, having
dynamic network and firewalling rules are also crucial, such as for oVirt
(RHEV), various OpenStack components and related infrastructure.  So
despite a lot of commentary out there, systemd has always been more about
the server than desktop.  It removes the need to run a lot of other
solutions which are often disconnected.

In fact, more often than not, systemd drops numerous Red Hat-SuSE'isms and
sides with Debian paths by default, with a few, legacy exceptions.

So much of the systemd commentary out there is from people who haven't used
it, or are frustrated when they are first presented with it.  But in
reality, there are so many cases where 1 command + 1-2 arguments can tell a
sysadmin everything going on in the system, where there was nothing before,
let alone stale.  Once you learn it, you really have trouble going back at
all.  The main issue with systemd has been lack of familiarity.  Although I
will fully admit it is breaking BSD and other compatibility.  But several
cloud-related projects have already been forcing that too.

-- bjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wplug.org/pipermail/wplug-internet/attachments/20140706/899fe07d/attachment-0001.html