* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-05 19:30]:
Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:
* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:
Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:
at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).
What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.
In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the
Everything is either abandoned or de-facto controlled by somebody.
You are missing the point, the someone greatly matters and is in this case a single commercial entity whose decisions will reflect the needs for their products and their business interests. That is certainly their right by virtue of funding much of its development, it should however by noted that these decisions are not necessarily in the best interests or even detrimental to the interests of other projects and vendors. Init and udev are the most central and important pieces apart from the kernel and there is an ever increasing amount of previously loosely-coupled, separate userland components such as cron, atd, acpid, syslog, ConsoleKit, and now user sessions which are being sucked up into systemd. While it probably makes sense for RedHat to streamline and take control of or at least exert significant influence over this middle stack, it also represents a radical departure from the current Linux ecosystem where distros have a certain degree of flexibility in what and which components they include based on their specific needs and technical merit. Once they're in the systemd train they more or less have to take what gets handed down to them, that is what systemd depends on or replaces next, as getting off becomes increasingly costly, just as avoiding it altogether since RH seems to be eager on pushing dependencies up the stack. In the FOSS world competition or even the potential threat of a fork or alternative solution and users voting with their feet are important means of driving progress, pushing towards technically optimal solutions, and ensuring a degree of responsiveness to consumers. After systemd has gathered enough momentum, there is even less incentive to take the needs of from anyone but their own and their paying customers into account or to strive for technically optimal design. You can already see the symptoms of that reflected in design decisions, such as the offline updates feature designed around the deficiencies of RH's package management, the requirement to upgrade systemd and the kernel in lockstep, udev dropping support for installation in /lib, the inclusion of FSS in order to boost the academic career of developers family members and so on.
overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.
This means expensive, not proprietary.
Lets please move any further discussion to opensuse-offtopic or private since this is getting off topic here. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org