Hi,
Zbigniew Jędrzejewski-Szmek:
And it doesn't appear to regulate the system clock frequency, which
basically makes it an inaccurate dumb SNTP client which steps the clock when
it synchronises.
Please see
On 29/11/14 13:30, Vincent Bernat wrote:
❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry
alastair.mckins...@sceal.ie :
One concern I'd have is the lack of flexibility to produce a cut-down
system. The option of a dedicated init=/custom-program, but lack of
an ntpd, for example, because
On Mon, Dec 01, 2014 at 10:58:45PM +, Roger Lynn wrote:
On 29/11/14 13:30, Vincent Bernat wrote:
❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry
alastair.mckins...@sceal.ie :
One concern I'd have is the lack of flexibility to produce a cut-down
system. The option of a dedicated
On Sun, Nov 30, 2014 at 3:11 AM, Ben Hutchings wrote:
working upstream
Are there any vendors of ARM-based devices who are doing that?
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
On Sun, 2014-11-30 at 21:48 +0800, Paul Wise wrote:
On Sun, Nov 30, 2014 at 3:11 AM, Ben Hutchings wrote:
working upstream
Are there any vendors of ARM-based devices who are doing that?
Most of the SoC vendors seem to be doing *some* work to get their chips
supported upstream, but I don't
this as easily fixable.
Mmh. If we're talking about
building future embedded systems using systemd
then presumably that system's kernel is new enough. Otherwise,
a legacy system running sysVrc will presumably continue to do so
_and_ Debian will probably continue to ship sysVrc files that are
good
Why, precisely, do you foresee future problems with embedded systems
development? Personally, I'm looking forward to a much easier time
building future embedded systems using systemd, or the occasional
too-small-for-anything-else embedded system (that couldn't run standard
sysvinit
❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry alastair.mckins...@sceal.ie
:
One concern I'd have is the lack of flexibility to produce a cut-down
system. The option of a dedicated init=/custom-program, but lack of
an ntpd, for example, because ntp has been absorbed into systemd's
orbit
Hi,
On 29.11.2014 08:37, Tollef Fog Heen wrote:
I'm not Simon, but one valid argument I've heard is that embedded stuff
has a tendency to get stuck on old vendor kernels, something that
doesn't work so well when systemd uses newer kernel interfaces.
Correct, and I don't see the situation
Hi,
On 29.11.2014 13:41, Alastair McKinstry wrote:
I'm heartened that some developers are doing the work to make
non-systemd remain a
viable option in debian, but for it not to degenerate into the systemd
way / the less maintained
and tested non-systemd way, we need to promote the APIs and
On Sat, 2014-11-29 at 17:10 +0100, Simon Richter wrote:
Hi,
On 29.11.2014 08:37, Tollef Fog Heen wrote:
I'm not Simon, but one valid argument I've heard is that embedded stuff
has a tendency to get stuck on old vendor kernels, something that
doesn't work so well when systemd uses newer
, precisely, do you foresee future problems with embedded systems
development? Personally, I'm looking forward to a much easier time
building future embedded systems using systemd, or the occasional
too-small-for-anything-else embedded system (that couldn't run standard
sysvinit or Debian for that matter
development from emdebian.org.
Why, precisely, do you foresee future problems with embedded systems
development? Personally, I'm looking forward to a much easier time
building future embedded systems using systemd, or the occasional
too-small-for-anything-else embedded system (that couldn't run
13 matches
Mail list logo
