> Let the good people who develop your distro worry about these hard parts.
I needed RHEL7 in January. It sort of works in November. I work in devops and know better than anyone developers can not be trusted to sort the shit out for us.
I don't use automount because it is flakey. Admittedly this seems to be a solved problem on Ubuntu. But on RHEL7, you best be using automount or you are going to have a bad time. But with solutions like this, who needs problems? It will be the first of many RHEL6 it is.
Truespace is a very acessible 3D program. I loved the simplicity of its binary object tools. You might not make the most efficient model in TS, but its solid.
And when it fails it fails hard. I can't say I agree with your approach either. If you are concerned about how fast your server boots up after downtime you've already lost. A Server failure should not take down multiple critical systems. That's how you save real money.
>Because, you know, Zimbra can't use the postfix, apache httpd, amavis, tomcat or openldap that comes with RHEL
Part-time problems. I suggest you haven't looked closely enough at RHEL's capabilities (see channel subscriptions) or you should probably just go with something like Ubuntu or Fedora if you want/need bleeding edge. Though I did a check and I'm not sure what your issue with Zimbra on RHEL is anyway.
Congratulations you've decided that uptime matters more than your stability. Such wisdom!
> given that when the server is down, the phones are down, the security system's video recording is down, the internet access and internal networking is down, the environmental controls for the building are down, etc.
What?
> but if you're doing security updates, it boils down to having update everything sooner or later - might as well have it all on one machine.
The assumption that I am free to choose what platform I support is bonkers. I am asking to choose the init system. I make multiplatform software. I need to support every distro, and it has fractured in to SysV and SysD. It will fracture again further in the future. Locking in is stupid stupid stupid and anti-UX
THe problem is this has been top down dictated. The correct way would have been to offer both, and let developers develop for BOTH. Not systemd primacy. Beg for secondary.
What actual issues and typical usecases do systemd address? I've heard about all the minor nuisances it supposedly addresses although none of them have ever effected me personally. But please tell me why I **need** it. And if you can't please tell me why it is default? It should not be default is all.
Apps should support SysV init and Systemd and if this is the case, why is systemd default as it is quite frankly not the lowest common denominator? Each time I ask this question I get personally berated by the pulseaudio meathead's personal fan club. I want actual answers because so far I haven't been shown a good reason for this, other than "Why not stupid old neckbeard?"
It flies in the face of everything I've ever been taught about UNIX. But don't berate me with bullshit like "Linux isn't UNIX".
Yes. I'm beginning to wonder if Adam uses RHEL7 outside of 'vanilla' norms, very frustrating although I'm sure the kinks are worked out.....but I'm still left with WHY did we break it? Couldn't we have made systemd an option not a requirement?
Well I get shiny RHEL7. I build my systems like RHEL6 (I don't do a lot of custom init stuff).
RHEL7 fails to boot after a while because of systemd. No one knows why. At first I was told it was hardmounts. Take them out in rescue mode, no booty.
Systemd by design tries to mount nfs shares, before it even starts up the network, out of the box! Systemd supresses everything unless you tell it to. Why? Because some hotshot idiot thought I was using RHEL to run a desktop? Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION.
This is the problem with systemd, it is unportable, monolithic and subject to dictatorship. And what does it offer me day to day in a grinding development lab? Nothing. Also yes, Embedded systems. I still support those too.
observance of Occams razor is traditional on slashdot. It'like you have this car that you love and every time you see it you run your hand up it from end to front.
Slashdot Mirror
I don't recall Al Capone leaving the country.
Lets take a moment to remember Justin Beiber has purchased a ticket.
That's just it. No one here is AGAINST NEW TECH. They are against defaulting new tech on reference and enterprise software.
Systemd is half baked. Wake me when its cooled and ready to eat.
> Let the good people who develop your distro worry about these hard parts.
I needed RHEL7 in January. It sort of works in November. I work in devops and know better than anyone developers can not be trusted to sort the shit out for us.
I don't use automount because it is flakey. Admittedly this seems to be a solved problem on Ubuntu. But on RHEL7, you best be using automount or you are going to have a bad time. But with solutions like this, who needs problems? It will be the first of many RHEL6 it is.
Truespace is a very acessible 3D program. I loved the simplicity of its binary object tools. You might not make the most efficient model in TS, but its solid.
And when it fails it fails hard. I can't say I agree with your approach either. If you are concerned about how fast your server boots up after downtime you've already lost. A Server failure should not take down multiple critical systems. That's how you save real money.
>Because, you know, Zimbra can't use the postfix, apache httpd, amavis, tomcat or openldap that comes with RHEL
Part-time problems. I suggest you haven't looked closely enough at RHEL's capabilities (see channel subscriptions) or you should probably just go with something like Ubuntu or Fedora if you want/need bleeding edge. Though I did a check and I'm not sure what your issue with Zimbra on RHEL is anyway.
I'm in the exact same boat. RHEL7 GA stability has been atrocious. Most of my problems have been related in some way or another to systemd.
Congratulations you've decided that uptime matters more than your stability. Such wisdom!
> given that when the server is down, the phones are down, the security system's video recording is down, the internet access and internal networking is down, the environmental controls for the building are down, etc.
What?
> but if you're doing security updates, it boils down to having update everything sooner or later - might as well have it all on one machine.
Oh ok, you're trolling.
I am so old the teardrops are coming to my eyes.
Well technically it is.
Thank you, this is my every day as systemd's birth has been painful to say the least.
The assumption that I am free to choose what platform I support is bonkers. I am asking to choose the init system. I make multiplatform software. I need to support every distro, and it has fractured in to SysV and SysD. It will fracture again further in the future. Locking in is stupid stupid stupid and anti-UX
Why not indeed!
THe problem is this has been top down dictated. The correct way would have been to offer both, and let developers develop for BOTH. Not systemd primacy. Beg for secondary.
Great, so what happens when journald breaks>?
Answer the question AC.
What actual issues and typical usecases do systemd address? I've heard about all the minor nuisances it supposedly addresses although none of them have ever effected me personally. But please tell me why I **need** it. And if you can't please tell me why it is default? It should not be default is all.
Apps should support SysV init and Systemd and if this is the case, why is systemd default as it is quite frankly not the lowest common denominator? Each time I ask this question I get personally berated by the pulseaudio meathead's personal fan club. I want actual answers because so far I haven't been shown a good reason for this, other than "Why not stupid old neckbeard?"
It flies in the face of everything I've ever been taught about UNIX. But don't berate me with bullshit like "Linux isn't UNIX".
dash now apparently in debian.
Systemd gives me nothing I need. So tell me again why I need it or should want it.
Yes. I'm beginning to wonder if Adam uses RHEL7 outside of 'vanilla' norms, very frustrating although I'm sure the kinks are worked out.....but I'm still left with WHY did we break it? Couldn't we have made systemd an option not a requirement?
Actually no, this is informative to me. Thanks.
I am not a troll. I am frustrated because RHEL7 is a heaping pile of poop presently.
>Sys-V is an utter shambles when automating that many machines.
That's funny it works for my broad spectrum workloads and systemd does not. Why do I not have a choice?
Well I get shiny RHEL7. I build my systems like RHEL6 (I don't do a lot of custom init stuff).
RHEL7 fails to boot after a while because of systemd. No one knows why. At first I was told it was hardmounts. Take them out in rescue mode, no booty.
Systemd by design tries to mount nfs shares, before it even starts up the network, out of the box! Systemd supresses everything unless you tell it to. Why? Because some hotshot idiot thought I was using RHEL to run a desktop? Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION.
This is the problem with systemd, it is unportable, monolithic and subject to dictatorship. And what does it offer me day to day in a grinding development lab? Nothing. Also yes, Embedded systems. I still support those too.
I don't know it make me think that maybe systemd is trying to be it's all the time when sometimes people just want its because it makes more sense.
observance of Occams razor is traditional on slashdot. It'like you have this car that you love and every time you see it you run your hand up it from end to front.