On 10/04/2017 08:39 AM, Mark Haney wrote:
> On 10/04/2017 08:22 AM, Gary Stainburn wrote:
>> On Wednesday 04 October 2017 12:54:44 Mark Haney wrote:
>>> Sorry, but if you have to use packages that don't originate from CentOS
>>> and they do that, then I wouldn't use them. Period. I'd compile from
>>> source before I used something configured that way.
>> This perspective to some extent employs cutting your nose of dispite youre
>> face. Before Packages were introduced, everyone compiled from source. That
>> was a pain, and a long process, especially when you had dependancies that you
>> also had to compile. Packages eased this process but kept the dependancy
>> issue.
> If you think using non-standard packages that put /persistent/ items in
> non-persistent locations like /var/run in production environments is far
> more acceptable than compiling from source because of package management
> 'benefits' then (to me anyway) you're lazy and dangerous with critical
> data. My statement still stands. Let me be clear:
>
> THIS. IS. NOT. ACCEPTABLE.
>
> The fact you'd rather bandaid a problem (in production no less) than
> follow proper standards or compile from source to avoid said bandaid
> would be a fire-able offense in any IT shop I've ever worked at.
>> Package managers got round (mostly) both the dependancy problem and updating
>> too. The problem with package maintainers not keeping up to date shows that
>> this still isn't perfect.
>>
>> However, if you go back to compiling from source then you lose all of these
>> benefits.
>>
>> Thankfully I do not earn my keep by watering lawns. I do not believe that
>> this is acceptable, but by the same token I have to earn my keep and that
>> involves having working production servers and services.
>>
>> I have managed to get round this problem in the past through manually doing
>> the same function as systemd-tmpfiles. It is a small price to pay to have a
>> working, (relatively) up to date server.
> The fact you find this acceptable means you're either the only
> 'qualified' (and even that is subject to doubt) person there, or your
> management is too ignorant to understand the danger. I'm sorry, but in
> no way is this acceptable for production level servers. I'm sure, if you
> asked 100 IT people you'd get 100 to agree with me. Being flippant with
> production servers is never acceptable.
>
> Of course, most people refuse to listen to logic and reason because they
> are convinced they are right despite evidence (and best practices over
> 40+ years of Unix) to the contrary.
>
> I'll end this by saying, I hope the production servers you have don't
> provide critical services that could jeopardize the lives of people.
> I'd ask who you work for, to make sure I avoid them at all costs, but
> I'm not sure I'd be told.
>
> Again, denying 40+ years of Unix design and best practices because
> you're too lazy to manage compiling from source to avoid denying those
> practices is truly one of the most astonishing things I've ever seen in
> the 25 years I've been in IT.
>
> Then again, maybe I'm old-fashioned when I expect to do something and do
> it right rather than half-ass it.
>
Don't know how long you have been working with UNIX but there was no /var/run 40 years ago!
http://www.rhyshaden.com/unix.htm
--
Stephen Clark
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
