OT: Systemd Poll

Home » CentOS » OT: Systemd Poll
CentOS 79 Comments

According to “Arthur Schopenhauer”:

“All truth passes through three stages.
First, it is ridiculed.
Second, it is violently opposed.
Third, it is accepted as being self-evident.”

I must admit that I skipped through the first and second stages – I
never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd’s service files without fuss.

So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?

79 thoughts on - OT: Systemd Poll

  • All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.

    Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one’s own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.

    For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.

  • I wish the documentation was a bit better. systemd and networkmanager definitely change the rules… I had a minimal C7 VM where I had a heck of a time getting it to use the right DNS servers, only way I got it set up was to use nmtui, my attempts at using nmcli were an exercise in frustration. maybe this is more of a networkmanager problem more than systemd, but they are both tied together in my mind.

  • ​Yes, lack of documentation is a big bug-a-boo in my mind also. However, I
    do think working with systemd is a bit like working with udev​

    ​ hooks. My first experience with systemd was probably back in late 2011. In any case, the RH documentation on it may be beneficial at this point:


    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html

    or maybe take a look at the Fedora projects info:

    https://www.freedesktop.org/wiki/Software/systemd/


    ———————————————————————-
    MzK

    “Every time you hear a bell ring, it means that some angel’s just got his wings.”
    — Clarence, “It’s a Wonderful Life”

  • I agree. I never had a problem with init scripts. Anyone who understood bash/sh could fairly easily come to grips with init scripts.
    I have no idea where to look for whatever starts up services with systemd. What language is systemd written in…? no idea. Yes, I
    tried reading docs, but they’re so vague and inscrutable that I gave up. E.g., what is a “unit”? Could they have picked a word more vague?
    What does “unit” tell us which “thing” doesn’t? Basically, a service is either running or stopped… so what is “static”? “Static” means the opposite of “moving” or “dynamic”. How does “static” describe a service?

    In short, although computer geeks generally aren’t known for being good at documentation, in the commercial world at any rate. But this is GNU/Linux. We rely on online documentation and the open source community to figure out problems and make improvements. Lacking sensible documentation, it’s hard to figure out problems. If problems can’t be figured out, we’re faced with problematic systems. And who’s going to tolerate that for long? How is that an improvement over Redmondware?

  • The same here. Could repeat that word for word. I fled what I could to FreeBSD, but in that process systemd was just the last drop that confirmed that my earlier decision to abandon Linux to the extent I can was right. Whatever has to stay Linux sucks … more time for any problem than it used to.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Like you, I have been looking for alternatives to Linux due to systemd, SELinux, desktop environments gone way off course, etc.  What can and can’t be replaced with FreeBSD or other alternatives (and why)?

    —– Original Message —–
    From: “Valeri Galtsev”
    To: “CentOS”
    Sent: Monday, April 10, 2017 8:38:03 AM
    Subject: Re: [CentOS] OT: systemd Poll

    The same here. Could repeat that word for word. I fled what I could to FreeBSD, but in that process systemd was just the last drop that confirmed that my earlier decision to abandon Linux to the extent I can was right. Whatever has to stay Linux sucks … more time for any problem than it used to.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I am using systemd, don’t really have a problem with it.

    It was different at first but so far I manage to have adjusted.

    It’s different. For better or worse I can’t say, but I can do what I
    need to do with it.

  • I’ve never had to write my own init scripts before so I’m not feeling the pain of others, but having professionally managed machines running SystemD for a while now honestly I don’t mind it. While the language used (units, targets) is confusing and documentation could be better, there are some things I like about it more than SysVInit.

  • FWIW this is a distro issue, not a Linux issue. Slackware still has not switched to systemd IIRC. I would imagine there are other distros that haven’t switched (yet).

    –keith

  • Once upon a time, Pete Orrall said:

    Yeah, the old init script setup was sorely lacking in some areas
    (especially dependencies). While there were well-written init scripts that were easy to understand, had plenty of configuration options, etc., there were many that were largely unreadable.

    I like to distinguish systemd-the-pid-1 from systemd-the-project; I
    generally like systemd-the-pid-1 (it isn’t perfect by any means, but I
    think it is an improvement). On the other hand, I dislike the scope creep and “replace all the wheels” approach of systemd-the-project.

  • As someone who has both debugged and written many init scripts, I’m a big fan of the way systemd does things. Every distro provided their own shell functions, so you ended up with a debian init script, a redhat init script, and usually some weird “kinda works everywhere”
    init script that used neither and reinvented the wheel.

    Quite often, what was going wrong was *NOT* apparent by glancing at the init script. How do you enforce limits on the service? Run ulimits in the script? The service starts fine if you run
    ‘/etc/rc.d/init.d/myservice start’, but then if you run
    ‘service myservice start’, it fails. On top of that, there’s no journal so you can’t even *SEE* why it is failing during boot unless it is kind enough to write an error to the console. Hope you have a crash cart!

    Also, how configurable is the init script? You had to hope that upstream was smart enough to use environment variables that were sourced from /etc/sysconfig/servicename. Sometimes I had to do evil things like put executable code into /etc/sysconfig/servicename which fixed problems with the init script.

    Also, that reminds me, there’s no simple way to override some or all of a packaged init script, except to provide your own alternative init script that had a different name. And don’t get me started on the terrible startup sequence rules. I’ve seen several people who have edited the init script itself and then had it replaced by a yum update, breaking their service. The RPMs don’t mark the init script as a config file.

    I don’t know… I find the unit syntax pretty simple to read. It says what processes are going to be run, what user it’ll run under, you can see what order it wants to be run, etc. There are dozens of man pages for systemd, each with examples.

    Don’t get me wrong, I have a lot of anger about some of the stuff that systemd does. But lets not reminisce about SysVinit as if it was anything but a horrible mess. systemd’s best feature is that it finally makes managing services better.

  • Pete Orrall wrote:
    Don’t look at me – I still *loathe* systemd. Change for no other reason than to put it on your resume, and write papers about.

    Examples: is it service, or target, and where of many places do I have to look to find a given service name? Why change names, such as rpc-idmapd to nfs-idmapd? And I’ve just been fighting today, because I have to munge the MAC address for a workstation, because they have old software that is very usefull, and there’s no budget to pay the company that bought the software
    $15k (no kidding) so that they can shift the license to the new workstation, and that’s tied to eth0 and the MAC.

    And *why* random NIC names? Quick, you’ve got servers from 5
    manufacturers, of different ages… what’s the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?

    And the binary message log…. At home, I’m staying on CentOS 6 until it EoLs.

    mark

  • I know this is systemd-punching day, but at least get your information straight.

    Unrelated to systemd, as far as I can tell. Fedora adopted new names that made more sense, and it was incorporated into RHEL7.

    Unrelated to systemd. This actually started happening in RHEL6 with the biosdevname feature. systemd can handle the NIC naming stuff, but it started happening well before systemd appeared in RHEL.

    Having consistent device names is helpful when you’ve got more than one NIC and you don’t want to rely on the order in which the network driver is loaded to define the interface name.

  • Jonathan Billings wrote:

    In what universe are those “consistant” device names, as opposed to eth[0…]? And how could it help automated scripts that you can run on
    *any* system you’re administering?

    mark

  • if I have a Intel gigE interface and a Marvell 10g interfaces, which one is eth0 and why?

    Say its Intel on eth0 and Marvell on eth1, if I then add another intel, is the Marvell now eth2 ?

  • Without intent to contradict… I really would prefer them numbered according to their bus address. Not in the order (or reverse order – as it was once) of them been discovered. And if you add hardware with bus address between those of eth0 and eth1, you will have newly added one become eth1, and former eth1 becomes eth2. I know, it stems from old idiotic habit to always look inside the boxes… call me an old UNIX
    outcast. (No, don’t, that would be a complement I unlikely deserve ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • John R Pierce wrote:
    And if I have a 5-yr-old Penguin (OEM-branded Supermicro), and a Dell PowerEdge R530 and an HP ProLiant dl580 and a hot-off-the-presses Penguin/Intel, what will their primary device be named?

    As opposed to you installing a new NIC in addition to one that’s there… which, since you’ve just installed it, I suppose you could add the UUID to whatever you want to name it.

    mark

  • bus address is a somewhat nebulous concept on PCI, afaik, its not neccessarily slot specific. its even messier on things like USB

  • It is what it is.

    I can see that systemd may not look as straightforward as init scripts, but it has been clear for a while that SysVinit is generally not really fit-for-purpose. Things like the mystic incantations embedded in comments at the top to try and make chkconfig work properly, or the lack of a consistent approach to configuring parameters (are they embedded in the script? In /etc/sysconfig? The package’s own config files?).

    The fact that there was at one point multiple solutions to the problem
    (with systemd eventually becoming the accepted one) and that no dev is really going to voluntarily go through the pain and abuse of implementing something new like this shows that it really was thought to be necessary.

    I think what is/was the issue is the abrasive way that some of it was done. It seems to have put people’s backs up no end and makes them predisposed to find fault with it.

    It’s just different, that’s all. It does the job it was designed to do. It even copes with legacy init scripts, so you can still use them if you want.

    And I remember when these new fangled init scripts first appeared – boy did everyone find them confusing and hated them.

    P.

  • indeed. BSD just used /etc/rc.conf and /etc/rc.d/{servicename}…. then AT&T SystemV came along with the whole levels and init.d and everything.

  • My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system… Monolithic. No process start/stop, but I
    understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess… Every distro developer had his own idea of what functions were needed.

    In all three of those cases, there was a single, simple start up entity. That was the literal binary program init. It read /etc/inittab and used that to handle process management and those management processes were completely transparent. Standardized, well known locations were used. It was considered to be a not just good practice, but excellent practice to do so. It wasn’t commonly done, but it was relatively simple to swap between them too.

    The current crop of system initialization systems, do everything possible to obscure the details of operation… Boot status on the console? Nope, obscured. Processes logged to standard places? Nope, someone might hijack the logs (we had a technique for that… remote logging, but that isn’t important enough to make work… Too much trouble).

    The bottom line seems to be, “I’ve looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way”… And if things get broken in the process… Oh well, that’s progress.

    I’ve had my init system lose communication with the desktop gui and decide to reboot my system. Yes, systemd did that. dbus got an upgrade and was restarting so systemd rebooted my system.

    While not directly a systemd problem, I’ve haddistro builds of apache that didn’t work because of some patch “needed” so systemd could manage apache (We need systemd hooked so deeply into every process now?!). Yes, each of these was corrected… But they didn’t need to happen and NEVER happened with earlier init systems.

    The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others. The implementations of the ideas have been poorly thought out and tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been “if we don’t force it, it will never be tested”. Completely unacceptable.

    This is MY issue with the new shiny toy. Heedless and needless system breakage by an escaped lab rat.

  • And I have to wonder, why in /usr/lib/systemd/system/ is there a file named -.slice ?? Didn’t anyone see a problem with this…? or countless possible problems? Doesn’t instill confidence.

  • Well wonder no more!! Simply look it up in the man pages. It is documented after all!!

    Hummm, lets see:
    (vcliff pts2) # grep Documentation= /usr/lib/systemd/system/-.slice Documentation=man:systemd.special(7)
    (vcliff pts2) #

    I will let you do the rest of the research yourself. :-)

    Regards,

  • As someone else had stated, it’s not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it’s a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.

  • FreeBSD uses the driver in the name, such as bge0, em0, and so on, as opposed to bge0 or em0, depending upon the make of the card.

  • Okay that makes sense.

    eno1: flags@99 mtu 1500
    ether 0c:c4:7a:c8:a5:4c txqueuelen 1000 (Ethernet)
    eno2: flags@99
    mtu 1500
    ether 0c:c4:7a:c8:a5:4d txqueuelen 1000 (Ethernet)

    Those two are my onboard nic, Intel – Scheme 1

    enp10s0f0: flags@99 mtu 1500
    ether 00:1b:21:94:72:37 txqueuelen 1000 (Ethernet)
    enp10s0f1: flags@99
    mtu 1500
    ether 00:1b:21:94:72:36 txqueuelen 1000 (Ethernet)
    enp9s0f0: flags@99
    mtu 1500
    ether 00:1b:21:94:72:35 txqueuelen 1000 (Ethernet)
    enp9s0f1: flags@99
    mtu 1500

    Those four are on a PCI-E card, Intel – Scheme 3

    05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
    06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
    09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
    09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
    0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
    0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)

    Anyway thanks for that link.

  • er, I meant to add that the 09: seems to correspond with the enp9s* and the 0a: seems to correspond with the enp10s*

  • I wrote myself a little script that uses /sys/class/net, ethtool and lspci to identify which interface corresponds to which bus slot/lspci entry.

  • And to add to the issues concerning consistency, what if you have a fail over unit and you’re replicating configuration (i.e. NIC), you really prefer that NIC names remain the same. Given the hardware morass underneath all of this, the only safe choice (regardless of whether you use systemd, init scripts, whatever) is to take control and force the association of the name to the MAC address in the appropriate file. It doesn’t allow total configuration replication but it does allow enough (with judicious use of segregation) to be useful.

    This does concern me, another post referred to the heavy-handed way in which systemd has been implemented and I totally agree. “You will conform” – no exceptions. What I fear is that we will lose the ability to control the name, MAC address association at some future point because “no one needs to do that” (speaking from their ivory tower).

    —– Original Message —

  • Another huge concern: It breaks, someone else has to fix it because it’s in the C source – after it reaches a high enough priority. At least with scripts you could conceivably hack it. From what I’ve read there is some ability to get systemd to defer to a script, I’m going to have to become an expert at that.

    —– Original Message —

  • To be honest, if you use systemd-networkd (instead of NM or the network init script), you can arbitrarily name your interfaces whatever you want, in a much more configuration-management-friendly way.

    It’s just that systemd-networkd isn’t that well-known yet. I’m on the fence about whether I like it or not. It is nice that its really simple files and consistent across distros, but it doesn’t yet do stuff like wifi well. Also, most GNOME desktops have a NM applet that gets confused if you’re using systemd-networkd. I still feel like systemd-networkd is a lot less convoluted than NetworkManager.

    https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

  • FreeBSD here too. But we should be quieter about the direction we are fleeing. Microsoft has already made big donation to FreeBSD foundation ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Even as a former C programmer, that disturbs me too. I’d much rather have a bash script to look at– and manually step through.

  • Is that a joke? Bash is an almighty impenetrable nightmare. I’ve been doing
    *nix for nearly 10 years and *still* am unable to read anything vaguely complicated in bash whereas I can write fairly decent python after 6
    months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don’t have to think about it anymore.

    What is it about SystemD that brings out the Richard Stallman in everyone?

  • Jonathan Billings wrote:
    want, in a files using

    I may need to look into that. I mean, I’ve disliked NM since I first saw it in 6. I mean, why would I want it to even try wpa-supplicant on a wired network? And perhaps for home users or laptops, but for a server install, I NEVER want avahi running.

    mark “Do what I tell you to do, and stop trying to think you know better”

  • Andrew Holway wrote:
    Same here. vaguely

    Sorry, other than my manager’s extreme use of regular expressions, most scripts are perfectly clear. I’m not sure what you’re seeing as an
    “impenetrable nightmare”

    mark “likes bash, because I can use my c-shell-isms”

  • This is the Richard Stallman assumption:

    He assumes that the average normal person is able to program Fortran 77 and Lisp and are able to spend inordinate amounts of time debugging and getting obscure OSS software packages working because using Skype and other proprietary software is somehow evil. Bash is a significant barrier for entry unless you spend a significant amount of your time writing bash whereas a service file is 6 lines for a proper service management solution.

    From a usability point of view init is a disaster.

  • *10 WHOLE years*… And bash is *STILL* impenetrable for you?

    How about over 30 and it took me a week? No, I don’t carry a CS degree or cert of any kind either, just some high school.

    For me, systemd has been an absolute nightmare of unexpected reboots and non-transparently broken processes with just plain bad implementations crammed onto my system. Faster boot they said, except it ISN’T faster now, it’s slower and MUCH more difficult to sort through to find out why with it’s monolithic architecture and poor documentation.

    It wasn’t broken before. What was being fixed?

  • I feel like this conversation has reached the “lets just keep repeating FUD about systemd” stage and probably won’t progress in a useful direction.

    Maybe we should just jump right to the end that we always have each time this comes up. systemd is the death of linux and you’re leaving for FreeBSD/devuan/whatever. Lets just move along now.

  • Well, sorta yes and sorta no Jonathan. Yes, in that I’ve moved my personal systems to Linux distros that don’t use systemd.

    No in the it’s not “FUD”… The complaints about the code and development are facts. Not alternative facts, real, verifiable incidents and outages.

    Professionally, I end up having to deal with these incidents that suck my time and effort and irritate my customers.

    Just move on, ISN’T a solution.

    I deal in solutions. Partially, where possible, I move my customers to system that don’t have this viral infection just as I moved them off of windows, where possible.

    systemd isn’t “the death of linux”. It is a serious quagmire that needs to be resolved. That can only happen by confronting the issue head on. step one is admitting a problem exists.

  • Interesting that you should cite Stallman because freedom is an issue here, we’ve been reduced to Microsoft when it comes to init. We’ve lost most of our flexibility with no option to choose piecemeal what we want and don’t want.

    —– Original Message —

  • While some of these might be valid concerns, the CentOS mailing list isn’t really the place where you’ll be able to achieve those goals. CentOS is a rebuild of RHEL, with very little change. Maybe as a Red Hat customer, you might get more traction complaining about how their OS runs.

    I suggest getting involved with the systemd project if you’d like to make positive change there. You can also participate in the Fedora Project if you’d like to influence how systemd manages the OS. You’ll also have plenty of heads-up about things coming down the pipe before they hit CentOS.

    If you want a real head-scratcher, take a look at how systemd –user runs on Fedora 25. It is my current painful interaction with systemd.

  • You also don’t have the flexibility to replace the kernel. Or glibc.

    Does anyone here remember Red Hat 5, when libc5 was replaced with glibc? The noise about systemd seems *awfully* familiar.

  • Young man, You feel down on your luck Young man You’re tired of Linux Young Man You want to free Of trying to figure out systemd

    Why don’t you try…. Freeeeee BSD
    FreeeBSD
    It still has an init that you can see
    (though they’re talking of trying OpenRC)

    And so on. Sorry, that’s all I was allowed to sing at work before people got annoyed.
    (We’re a FreeBSD shop though).

  • Yes.

    I have a hundred or so CentOS desktops, ~10 webservers hosting many virtual sites, an LDAP infrastructure, a couple of VM servers, a number of large computational clusters, mail servers, mail relays, a Nextcloud host and so on all running on CentOS of various flavours (but mostly 7
    now) and ALL of them rock solid. I don’t see any of these random reboots because of systemd, it is just not something I recognise – the uptimes are usually in the months to years region.

    Look, CentOS is a RHEL clone, RH make money out of this and they aren’t going to produce an OS that is flaky. If they did, no one would use it.

    P.

  • Years uptime, wow! What do you do when security update for kernel or glibc is released? These come as often as once every 45 days in my observation.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • They’re non-exposed hosts doing very specific things – think internal network with an air-gap to the internet.

    P.

  • Ah, that explains. Doesn’t suite me though: I do run machines in an assumption that bad guy is already inside. Saved me twice: I watched attempts of elevation of privileges (unsuccessful) before I locked regular user account that was compromised. So this doesn’t suit me, alas, even for backend servers. I guess I had too “strict” teachers ;-)

    Thanks for clarifying!

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Similar. When user jobs can run for a couple of months you can’t just do a reboot every few days. Yum makes doing updates easy, but that can bring another problem: I’ve seen people do “yum update” multiple times and not realise that they need to reboot.

  • Boot speed isn’t everything. My servers take far longer to initialise than boot, so having to repeat the boot to sort out the black magic takes __much__ longer than having a steppable script.

  • Not just talking. TrueOS, neé PC-BSD, now runs on OpenRC.

    So let me tell you about how my recent TrueOS server upgrade broke virtually all of my services on the TrueOS server, roached the X configuration, and now has the system in an un-upgradeable state, to the point that it’s looking like I’ll have to reinstall if I ever want to install software from pkg again.

    Oh, and let’s also talk about how FreeBSD has been training people to run services via direct /etc/rc.d/$service script calls, but now you must use rc-service calls, with no graceful fallback. Got scripts calling the old style scripts? Too bad.

    The grass isn’t always greener on the other side of the fence.

  • All systems suck. And thanks to that I got my job.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • And as for me, I was just trying to make people laugh. :)


    Scott Robbins PGP keyID EB3467D6
    ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
    gpg –keyserver pgp.mit.edu –recv-keys EB3467D6

  • But you do, don’t you? It’ll take you months to replace them, or years to rewrite, but you *can* do it. That is the freedom that open source software provides that proprietary OSes do not; it does not come with the additional promise to provide exactly the software you specify.

    –keith

  • I agree. We had once new machine with 32 bit CPUs and 8GB of RAM – that time RAM was cheap, but amd664 architecture didn’t exist yet,- and standard kernel only supported 1 GB user space. Not changeable in kernel config. It took me between one and two weeks to find hardcoded boundaries, and change them; 3.5 GB for userspace was max I could squeeze leaving the rest to kernel + stack + … and still having stable solid system. That was decent solution.

    I wholeheartedly agree with Keith.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Why don’t we discuss something ***less*** controversial, like politics or religion?

    —– Original Message —

  • On Mon, 2017-04-10 at 22:45 +0200, Nicolas Kovacs a écrit:

    Un bon idea !
    Ich auch Ikki ook :-)


    Regards,

    Paul. England, EU. England’s place is in the European Union.

  • In my experience the new interface would be eth2, because the startup scripts create a mac binding to ethx name in the
    /etc/udev/rules.d/70-persistent-net.rules file, so even if the intel is probed before the marvel the scripts rename them to keep them in the original order.

    Steve

  • So, the hornets are swarming…..

    But to answer your question: None of the above. If I want to run CentOS 7, I need to learn systemd. It doesn’t matter what my opinion is of the systemd developers, or of systemd itself; CentOS is an RHEL
    rebuild, and RHEL 7 ships systemd. If I do not want to deal with systemd, then I need to use something other than CentOS 7. My
    ‘feelings’ on the subject are irrelevant.

LEAVE A COMMENT