[systemd-devel] question

[Genes MailLists]

On 09/13/2011 08:34 PM, Jef Spaleta wrote:
> 
> 
> On Tue, Sep 13, 2011 at 4:13 PM, Genes MailLists <lists at sapience.com
> <mailto:lists at sapience.com>> wrote:
> 
>      The kernel has undergone more updates than systemd ... all for very
>     good reasons - making it better and solving problems. Sure the same
>     would apply to systemd.
> 
> 
> We also go to some lengths to make sure that there is a fall back kernel
> on the system by making sure the update kernel is _installed_ in
> parallel with the running kernel and not _updated_ in the rpm packaging
> sense. And optionally you can configure your system to hold N older
> kernels (I have N=6 for testing purposes currently cuz I'm that sort of
> crazy)
> 

 ,,,

  Good points - up to a point - but lets go slow and think for a few
minutes - unlike the kernel which is very hardware dependent and
therefore may run on many machines but not all, systemd is no - or
should not be for its core functionality.

  Its a piece of software that should run exactly the same way for all
hardware - this is certainly true for its core functionality - it does
indeed take on additional roles and I have not looked at the source code
to see how well / robustly it handles exceptions ...

  The chances of it failing for a subset of users after being decently
tested is way lower than for kernel code - assuming the code is well
written and will perform is core functionality even if faced with
exceptions in its peripheral functionality (which in my view should be a
separate daemon(s) .. never mind that for now .. )

  If the code such crap that it cannot handle its core functionality
then perhaps we should dump it, and go back to something more robust.
but it seems to be handling it ok on F16 ... so far.

 So, while the argument by analogy to kernel (a dangerous road to take
almost always) has some merits, it is not by any means convincing ...

 And actually if indeed systemd was hardware sensitive - then of course
we should have multiple fall backs just like we do for the kernel - but
it isn't and it definitely should -not- be hardware dependent ... so
having one version should be fine ..



>