On 09/13/2011 08:34 PM, Jef Spaleta wrote: > > > On Tue, Sep 13, 2011 at 4:13 PM, Genes MailLists <lists@xxxxxxxxxxxx > <mailto:lists@xxxxxxxxxxxx>> 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 .. > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
