Hi,

So to replace my car's battery, I have to first have an understanding
like that of a car engineer. What I am being repeatedly battered to
accept, is the irrationality that the whole always entirely affects
the parts! I take this as an attack on my intelligence: this is
insulting my intelligence. How can one be certain that in ALL
circumstances the whole always affects the parts. There are isolated
sets of interdependent elements in many sets and reality is no
exception. How come changing a power transistor to another type with a
higher voltage rating and the same gain affect circuit performance?
Notwithstanding power transistors were not listed as equivalent I used
to replace them in TV sets in this way and no customer came back
complaining.

NO, I have been scolded to first understand the whole before I can do
anything to a subset. And yes, an init system shouldn't affect all
software: many programs will still do what they are expected. I am
being expected to work in an unnatural way by producing a finished and
polished product before producing a rough approximate product. That is
not how the world works. Not even nature with its feedback mechanisms
works that way as it takes many many tries before it makes a
functioning living cell/organism. Look at how evolution works: it does
not need freaking knowledge of all parts to work, and yet, it
continuously renews itself in new functional mutations.

Why should I refrain from coding in C? Why? I love C for its power
notwithstanding of the existence of other programming languages that
are ADVERTISED as being easier. The fact is that they are harder to
use as they hand hold so much making programming beyond their scope
often needing awful hacks. Yes, I have a problem reading pointer
symbolisation, but so what? I love the language for its simplicity and
power: leaving it is like cutting off some part of me, and no, pointer
symbolisation is not an issue as long as compilers continue issuing
errors. Syntax errors are one of the reasons why compile time errors
exist and why they are fatal.

Sorry, coding in C is a passion I cannot discard.

Edward



On 18/06/2016, aitor_czr <aitor_czr@???> wrote:
>
>
> On 06/17/2016 04:25 PM, KatolaZ <katolaz@???> wrote:
>> On Fri, Jun 17, 2016 at 09:44:56PM +0200, Adam Borowski wrote:
>>> >On Fri, Jun 17, 2016 at 08:19:12PM +0100, KatolaZ wrote:
>>>> > >Then you can provide any other alternative definition of "init
>>>> > >system", but if there is no procedure that does those things for
>>>> > > you,
>>>> > >then you have to manually do those tasks, at each reboot. In that
>>>> > > case
>>>> > >the 12-lines init might just spawn a shell
>>> >
>>> >Why would you even need a separate process to spawn the shell?
>>> > /bin/bash is
>>> >a perfectly capable init that can reap zombies, start processes, do any
>>> >interactive tasks, or be automated (.bashrc, trap EXIT, etc).
>> ...exactly, and that's why I remain convinced that writing a shell is
>> actually a far more instructive exercise than writing a 12-lines init
>> that calls rc to do all the work...
>>
>>> >
>>> >Specifying init=/bin/bash via grub on the cmdline is a common rescue
>>> >technique for systems with a broken init. Guess what init
>>> > implementation
>>> >needs to be rescued this way most often...
>>> >
>> That's too harsh of you, Adam :D
>>
>> HND
>>
>> KatolaZ
>
> *Joey Hess* was good developing in perl...
>
> He disappeared from debian. Little is known about him.
>

>    Aitor.

>
>