Mailinglist Archive: opensuse-packaging (267 mails)

< Previous Next >
Re: [opensuse-packaging] package looking for maintainer: the AT daemon
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Tue, 6 Nov 2012 12:52:04 +0100
  • Message-id: <20121106115202.GA7026@hal.local.invalid>
* Krzysztof Żelechowski <giecrilj@xxxxxxxxxxxx> [2012-11-05 19:30]:
Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:
* Krzysztof Żelechowski <giecrilj@xxxxxxxxxxxx> [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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >