Hi,
My suggestion is that you keep both init systems, SysV/LSB and systemd,
as separate offerings out of many, and forever so.
You would install them as suitable for your individual system needs.
The SysV/LSB system init would be default as is now.
The reason for it is twofold:
- SysV/LSB init system
- it is established, with a long history of familiarity within UNIX/Linux
OS environments, whether by a professional or amateur sysadmin, a system
programmer or architect, a technical or casual user
- adherence to UNIX principles
- ease of use due to shell scripting
- transparency of code due to shell use
- ease of system setup
- ease of prototyping, editing, experimenting, etc
- based on the above, it has a distincit advantage over systemd
- systemd
- as of today, it does not offer any functional advantage over SysV/LSB,
except a new make-up with heavy use of lipstic in form of unit
configuration files (and control functions)
- there is no promised land of "parallelization" and speed, which can not
be achieved without applying concurrency and all system programming
models and tools available today (client-server/master-slave, sockets,
multithreading, synchronization constructs, synchronous/asynchronous
programming, or even hybrid event- and threads-driven programming where
appropriate, etc)
- the project, to achieve full benefits of concurrency, should become fully
autonomous and self-contained
- it should abandon any utilization of or allowing shell processing
(internally or externally)
- it should use coding in C exclusively, with a separate execution
environment, data structures, config files, services definition and
execution, controls, secure programming, etc.
- advantages:
- a separate development env
- speed
- clearer paths to utilization
- availability and possible customization for and in devices or systems
that would have unique requirements, where traditional (script based)
init systems would be impossible or inappropriate
- ability to tailor it for cooperation with other environments (GNOME, etc)
JB
ZZTop
http://www.youtube.com/watch?v=p-y33Uq6HGs
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
