Re: systemd-free alternatives are not off topic.
On 11/24/2014 10:52 AM, Scott Ferguson wrote:
> On 25/11/14 01:57, Jerry Stuckle wrote:
>> On 11/24/2014 8:54 AM, Miles Fidelman wrote:
>>> Jerry Stuckle wrote:
>>>> On 11/24/2014 2:56 AM, Scott Ferguson wrote: <snip>
>>>>>> Yes, and while the Linux community continues, Debian will
>>>>>> lose a lot of dedicated users due to this decision. Possibly
>>>>>> another fork, or possibly another distro. But Debian will
>>>>>> lose users.
>>>>> 1. At best that's pure speculation. With all due respect to
>>>>> Gypsy Rose Lee (who is really just a naughty boy), some of us
>>>>> "engineer types" place little stock in soothsaying.
>>>>>
>>>> It is more than speculation. Read the posts here - some people
>>>> (including me) are already looking for alternatives. And so are
>>>> many companies I know of who have looked at jessie.
>>>>
>>>>> 2. It's false logic to conclude *only* losses from change (and
>>>>> duplicitous to deny that systemd is your only choice) - it
>>>>> overlooks the possibility that the additional *choice* of
>>>>> systemd will attract more users (and more instances - you do
>>>>> know that many "administrators" manage large numbers of
>>>>> instances, right?). There is no evidence to show that other
>>>>> distros and projects that adopted systemd as the *only* choice
>>>>> lost users - quite the reverse.
>>>>>
>>>> These are the ones who are abandoning Debian. Some of them came
>>>> to Debian because it was one of the last holdouts. But they see
>>>> the way Debian is going also, and don't like it. They'll
>>>> probably end up on BSD.
>>>>
>>>>>> Sure, people who only run software in .deb packages won't be
>>>>>> hit as hard.
>>>>> At all. And then only if *they* don't elect to stay with sysv.
>>>>>
>>>>> But that is definitely not the entire Debian user base.
>>>>>
>>>> I never said it was the entire Debian user base. But even
>>>> staying with sysv is only a temporary situation. They see the
>>>> handwriting on the wall - whether you agree with it or not.
>>>>
>>>>> Those that deploy customisations in the "Debian Way" should
>>>>> file bug reports if those customisations are not supported *if*
>>>>> they change init systems. Upgrades have *always* supported
>>>>> customisations done the "Debian Way" - and I have every
>>>>> confidence they will continue to do so
>>>>>
>>>> And exactly what is the "Debian way" to add custom (NOT
>>>> customized pre-packaged) software to the system?
>>>>
>>>>
>>>
>>> Alien, checkinstall, and equivs come to mind.
>
> Agreed (also fs guidelines)
>
>>>
>>> Then again, Debian has, to date, been pretty friendly to the
>>> basic: download to /usr/local/src; unzip; untar ./configure; make;
>>> make install
>
> and "checkinstall"
>>>
>>>
>>
>> Do you expect customers to build .deb files for every piece of
>> software they create?
>
> No, I expect the admin to 'try' and do that (e.g. checkinstall) or
> install the upstream package to the appropriate place where it *will*
> withstand upgrade. But not everyone follows BP (e.g. ITIL, PCI, and
> whatever relevant guidelines apply to their use-case). I don't know what
> your use-case is...
>
These are system admins who have either started with Unix in the 1980's,
or people who learned from those sysadmins. Back then you did put stuff
in /bin and/or /sbin, for instance. And the company is not changing.
>>
>> It doesn't happen - and is not going to happen. It's much faster
>
> Convenience is the antipathy of security? (security also mean reliability).
>
It is reliable. And has been for many years. That's what testing is
all about.
And even if they did create .deb files for everything, that would not
negate the need for testing.
>> to just copy the files to the appropriate directories. And since
>> they have complete control over the code,
>
> Complete control over the code? Are you sure you mean what you wrote? If
> so don't conflate "complete control over the code" with "no control over
> whether the code will continue to function" - as it would contradict
> your previous complaints.
>
Yes, complete control. This is code they have written themselves and/or
contracted out. They have complete control over the code. When there
is an upgrade to their code, they know about it and install it.
And when there is an upgrade to the underlying OS and/or tools, there is
also extensive testing to see that the code will continue to work. If it
doesn't, either the code changes or the upgrade is cancelled and a new
solution is looked for.
Most of the time it's only a matter of recompiling the code (new libs,
etc.). But there is much more concern with them now.
Jerry
Reply to: