Am 14.06.2014 15:49, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 15:08 +0200, Reindl Harald a écrit :
> Am 14.06.2014 14:56, schrieb Michael Scherer:
>> Le samedi 14 juin 2014 à 13:45 +0100, Jon Kent a écrit :
>>> Concerns me greatly when someone thinks cli is the wrong way to
>>> automate things. Agree Reindl comment 're this statement.
>>
>> CLI is not scalable, you need to fork processes for that. There is also
>> no way to communicate errors to the software that do the automation,
>> since you can only transmit string without any formatting or
>> translation.
>
> oh my god - CLI is used for decades and now as machines
> are some hundret times faster in IO and CPU performance
> it's not scalable......
Performant different from scalable.
And you didn't address the problem of not having proper error
communication
if tasks in cronjobs are failing they generate emails
not in recent Fedora setups but in proper maintained ones
come to vienna and reserve at least 4 hours to look and understand
basic pieces of what i am doing all day long and how i achieve
failsafe systems - until now i did not meet anybody in person
who was not impressed about how things are working here
and I can add the lack of format API and mechanism to
signal deprecation to issue of CLI as a automation mechanism. You can
also add the fact that all CLI calls are synchronous ( since shell lack
advanced synchronisation primitives )
*god bless* that they are
that's the intention of a script
which is also something going against modern scalability
( and by scalability, I do not mean "20 machines" like
you seems to do )
you seriously want install/update packages in parallel?
if no than *stop* going off-topic all the time
The fact we use command line tools in %post in rpm rather than
clearly
defined API to affect the system is one of the reason why rollback is
hard to automate
leave me in peace with that off-topic discussion only
because you can't really argue CLI breakage
you don't like a CLI?
fine then just don't use it
but don't explain others which are using it they are all wrong while
maintainance of critical services over many years *prove* the opposite
and no i do not need to explain you my workloads on a public list
you only have to accept they exists and as long as i am responsible
it's my job not yours to qualify what is a working and stable
solution and it is working and stable until someone from oustide
breaks it intentionally