On Tue, January 26, 2016 9:01 am, Johnny Hughes wrote: > On 01/26/2016 05:51 AM, Peter Duffy wrote: >> On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote: >>> Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said: >>>> The thing which always gets me about systemd is not the thing itself, >>>> but the way it was rolled out. When I first installed Red Hat 7, if a >>>> window had appeared telling me about systemd and asking me if I wanted >>>> to use it, or stick with the old init framework, I'd have opted for >>>> the >>>> latter (as I was interested primarily in continuity from the previous >>>> version.) >>> >>> That's not really practical for something as core as the init system. >>> Trying to support two init systems in parallel, especially for as long >>> as Red Hat supports a RHEL release, would require a massive amount of >>> work. A distribution is about making choices and implementing them in >>> the best way possible; for "leaf" packages like an editor or a web >>> browser, it is easy to have multiple options (where they don't >>> conflict), but core stuff like the kernel and init system don't leave >>> lots of room for choice. >>> >> >> Ultimately it's all software, and software can be >> written/changed/updated to do anything required - all that's needed is >> the skill and the motivation. If systemd is so "core" that it can't be >> unplugged and plugged easily, and glues together a lot of otherwise >> unrelated components, then it's just bad software - end of story (the >> problems with tightly-coupled components were first identified over 40 >> years ago, and modularization has been the watchword ever since.) >> >> In my view, it's high time someone independently analysed systemd down >> to basic code level, and understood why it's so invasive (if it actually >> is.) Then the way forward would be clear - fork it, and produce a new >> version which wasn't so invasive, and which could be swapped in/out. I'm >> not saying it would be easy! ("We do not do these things because they >> are easy - we do them because they are hard!") >> >>> I remember people complaining about SysV-style init too, "what's with >>> all these scripts" and "why can't I just add a line to /etc/rc". >>> systemd is a different way of thinking, but it isn't exactly original >>> (Sun and Mac have similar launchers); practical experience has shown >>> that this can be a better way of managing services. >> >> No one is saying that sysvinit is perfect. What I can't grasp is why >> replace it with something which is no less imperfect, and is almost >> certainly worse in at least some respects - and to make that replacement >> unavoidable and mandatory. >> >> I'm also still trying to figure out in what way systemd is supposed to >> be "better". I've seen the following things claimed for it: >> >> - faster boot time (this was apparently the main motivation behind it.) >> My experience with systemd-managed systems has been limited - but so >> far, I've not noticed faster boot times with systemd (maybe because the >> boxes booted fast enough previously.) >> >> - parallel startup of services. Not sure that I'd want that anyway - too >> much risk of two services trying to grab the same resource at the same >> time - I'm absolutely happy with the sysvinit approach of one service >> startup completing/failing before the next one happens. That way, things >> are nice and orderly. >> >> - better handling of hot-plug devices. I've not yet seen that in action, >> but that is the one thing which makes me inclined to investigate systemd >> in more detail. >> >>> Nobody is forcing you to run systemd; you can continue to run CentOS 6 >>> and earlier for years. But if you are a system administrator, your job >>> is about learning and adapting, not trying to keep a static setup for >>> life. systemd is different (just like SELinux was years ago), but I >>> suggest you learn it. It can make your admin life easier. Is it >>> perfect? No, nothing ever is; I do think it is a big improvement >>> though. >>> >> >> My job as a system administrator is to serve the users who use the >> servers I manage and administer, and to keep those servers and services >> in suitable condition for the users to do their work and earn their >> daily bread. >> >> As we all know (don't we just?) sysadmin work and responsibilities are >> heavy, and frequently eat into evenings, nights, weekends and >> (so-called) holidays. Anything which increases the sysadmin workload - >> e.g. suddenly faced with a vertical learning curve just to do the tasks >> they did yesterday, or a GUI which leaves them unable to find anything >> on their screens - is a major issue, and prejudicial not only to the >> sysadmin's own work, but also to that of the users to whom he/she is >> responsible. And when you're talking about systems used by hundreds and >> thousands of users, that's a big problem. > > So don't use it then .. EL6 has support until 30 Nov 2020. > > SystemD is not better, the 3.x and 4.x Linux kernels are not better, > Gnome 3.x is not better, KDE 4.x is not better. Blah, Blah, Blah. > > Red Hat Linux 3.0.3 with the 1.2.13 kernel .. now there was an operating > system. > > I have been doing this stuff since 1981/82 time frame, starting with > AT&T Unix on an 3B system > (https://en.wikipedia.org/wiki/3B_series_computers) that had floppy > disks, 10 MB hard drives, real-to-real tapes for backups, and used a > brand new UNIX System V (https://en.wikipedia.org/wiki/UNIX_System_V). > > Now, your cell phone has hundreds of times the computing power and > storage and it literally fits in your front pocket. > > So tell me about long nights doing sysadmin. Tell me about change in > the way the OS or the Desktop or the hardware works. Been there, done > that. > > If you don't like it, every bit of the source code is available. You > and everyone else who doesn't like can take that and build 'something > else'. And before you accuse me of being an ass .. that is EXACTLY what > I (and the rest of the CentOS team) did 12-13 years ago. That's why you > have CentOS today, and that's why it's free. If you think you can do it > better, then show us. Maybe you can. I like hard core arguments. I will try to not push _this_ argument in the direction of one or another side. Even though I myself am on one of them. I will try to show "different dimension". Basically, being sysadmin, even though I did program quite a lot, I prefer not to put my dirty hands into somebody's else nice clean code. As a sysadmin, leaving mostly thanks to open source developers, whose highest reward often is just to see the fancy thing they have created, I do my best to hold myself from criticizing their results (unless they go way out of line IMHO). This helps me to convince myself to adjust to minor changes all the time pretty much like Johnny suggests. However, things sometimes go grossly out of "normal", which makes me start arguing against these changes for some time, as, like Peter, I don't like gross changes where they are not needed. But after some period of arguing I start realizing that there is rather large crowd that thinks differently than I do. HERE is where extra dimension comes in: I just find the replacement for something that went awfully out of normal (again, just IMHO) that is withing my views of what that should be. Way out of normal, yet it has big crowd of supporters. So, here is what happened to me and allowed me to keep harmony of the World for myself: servers are migrated to FreeBSD when upgrade time comes (there are other systemd-free choices: Open Solaris, OpenBSD, NetBSD, and soon to be solid release of Linux: Devuan); Mate instead of GNOME and KDE (but there are were other choices mentioned here). So, when something has already happened that we grossly unhappy about, let's find extra dimension, and move there (it exists!). This is not intended to feed more flames between sides. Calmly walking away to something that suites the task better (in your opinion) is more productive, and makes better statement (even though no statement is intended). And we can keep CentOS list for technical CentOS related stuff - we still use CentOS where it fills the bill (even if just our of habit): workstations, laptops, number crunchers. Good luck everybody, and be happy with YOUR choices! Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++