On Dec 12, 2015, at 7:03 AM, Alice Wonder <al...@domblogger.net> wrote: > > In the server environment you almost certainly are using a virtual machine
I think you’re committing the same kind of error here that Fedora is: assuming your “typical” use case is typical of the wider world. We do use a lot of VMs here, but they’re far outnumbered by the number of bare-metal installations. You’re describing the appliance model, which is a fine and valid use of CentOS, but hardly the only one. One of the big recent trends in the virtualization space is containerization (e.g. Docker, BSD jails, Solaris zones…) where there may be little to no “OS” inside the container. Its growth is partly at the expense of the old “full OS inside a VM” model of virtualization. Like most displaced tech, I don’t expect heavyweight VMs to ever disappear, but the tech might be slowly marginalized. General purpose OSes remain useful in a world of increasing appliance VMs, embedded OSes, cloud services, and mobile OSes because you can use them as the base for anything a computer can do. Where once upon a time, GP OSes were the only thing available, they remain useful to handle all the weird edge-case things that aren’t covered by the existing cookie-cutter cases. That has a practical consequence, though: you can’t predict, a priori, how someone will use a GP OS. “Streamlining” it amounts to putting barriers up on many of those edge case paths. Instead of trying to make CentOS simpler to use for a predetermined task set, I’d rather they made it simpler to access all of its power, and leave it to *me* to decide what the tasks are. That means not hiding functionality behind task-focused interfaces, because my tasks are not your tasks. I gave one example of a case where EL7 is now harder for us to use than earlier versions in the other thread. (The “NM swaps static and IP interfaces” problem.) Let me give another here: In EL5 on a single-NIC machine, it was possible to set it up for a static IP, then create an ifcfg-eth0:0 file with a DHCP configuration, so that the interface would also get an IP alias, DNS info, and a default route from the DHCP server. You can’t do that in EL7 any more because NetworkManager only knows about static IP aliases. It knows nothing about alias interfaces, which are a much more powerful concept. In the end, I had to configure enp3s0 as DHCP, then hack in a static IP alias with an ifconfig call in rc.local. I’ll forgive you if that solution makes you nearly puke, because it did that to me, too. In case you’re thinking about the previous complaint, yes, this is the single-NIC version of the same problem, but with a different consequence, which is suspect all by itself. Why is there a behavior difference between static+DHCP in the dual-NIC and alias interface cases? The whole idea of alias interfaces is that they act like independent NICs that just happen to share the same physical medium as their parent NIC. Answer: Because NM doesn’t know what alias interfaces *are*. Instead of adding the ability to create alias interfaces to the NM GUI/TUI, they just added a field that lets you list additional static IP aliases, which captures part of the *function* of the previous mechanism while missing out on much of its full power. They made it task-focused for a task that does not need doing in my world. It’s like giving a mop to the owner of a fully-carpeted home. I characterize this as an EL7 issue because there were fewer consequences to disabling NM in EL6. Here in EL7, things break if you disable NM, so that they’re basically forcing you to use it, even though it doesn’t do everything the old scheme could yet. > I was one of the systemd haters initially but now I don't have an issue with > it. I remain ambivalent about systemd. I’m with you insofar as I recognize that systemd serves a useful purpose, and it is mostly fit for that purpose. Pretty much everything you could do on a pre-systemd box, you can do under systemd, too. systemd provides real value to CentOS. The biggest problem I have with it is its monopolization of system functionality. The most commonly cited example of this I see is that systemd now owns logging. Never mind the whole binary logging problem, why does a process launcher own logging in the first place? What was wrong with syslogd? You know, the Unix philosophy and all? Small pieces, loosely joined? Why aren’t we dancing with the one who brought us to the dance any more? But it goes much further than that, with more serious consequences. For example, systemd has usurped udev and dbus, which are key parts of the freedesktop.org standards, which allow GNOME, KDE, and other *ix desktop environments to interoperate. But that in turn means that non-systemd based OSes that want to ship FreeDesktop-compatible DEs like GNOME and KDE must now include systemd. FreeBSD doesn’t *want* systemd. This feels an awful lot like “embrace, extend, and extinguish.”[1] I sure hope Red Hat isn’t the new Microsoft. If you want to see what systemd *could* have looked like, take a look at launchd.[2] There’s talk in the BSD world of using it instead of systemd, though that may not be practical given the FreeDesktop standards problem. By the way, what NIH process went on in North Carolina that led them to reject the Apache-licensed launchd, available 5 years prior to the creation of systemd, and used in a production capacity that whole time? Or upstart, created 4 years prior for Ubuntu? This is what I mean about EEE: systemd is derailing other OSes’ development processes. I understand the ambivalence toward the use of XML in launchd, and there are Mac-isms in launchd, but those are both easier problems to solve than creating systemd from scratch. So much easier, in fact, that it’s been solved multiple times.[3][4] The inverse of that sort of effort — “fixing” systemd to make it suitable for non-Linux OSes — seems to be too difficult to bother with.[5] [1]: https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish [2]: https://en.wikipedia.org/wiki/Launchd [3]: https://github.com/mheily/relaunchd [4]: http://www.nextbsd.org/clarifying-near-term-expectations/ [5]: http://uselessd.darknedgy.net/ > Gnome is the only place where I have serious issue with the direction Fedora > is going. I loved Gnome 2 but hate Gnome 3 with a passion. I tried to love > it, but I just can’t. What is this GNOME thing you speak of? Is it part of ssh? :) > But Fedora is too bleeding edge for my liking now, and CentOS is the Linux > distribution I recommend for desktop use. Why? Bleeding-edge Linuxes work best in places where there are hands on the box constantly, so you can cope with the blood loss, so to speak. In such an environment, the benefits outweigh the costs. Contrast a stable Linux use case, where it’s mainly important that the provided packages be reasonably up-to-date at the time of development and deployment. Once you’ve got an unattended server up and running, it is rare to need newer package versions on it; you just need security patches and bugfixes, the very thing that a stable OS provides. Newer services typically get deployed on new servers, not on the one that’s been running for 5 years, and is now 2 major OS versions behind. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
