Re: systemd requiring Linux >= 3.7
Hi Jean, I'm not here to complain about systemd. Did you read my Emails? I said that Jessie with systemd is good. I already maintain a Jessie+systemd build of my work, though it's not useful because platform-specific kernel modules were written for 3.0 even though 3.0 was already quite old at the time.Le 24. 10. 14 07:49, email@example.com a écrit :
I'm here wondering if adding this circumstance to consideration for retaining sysvinit capability in Jessir is worth throwing into the discussion. Given that so far I seem to be the only one on the planet in this predicament stuck supporting new, current hardware that's locked into kernel 3.0, perhaps not.
Sent from my android device.
From: Jean-Christian de Rivaz <firstname.lastname@example.org>
Sent: Fri, 24 Oct 2014 23:27
Subject: Re: systemd requiring Linux >= 3.7
> With our dear universal operating system set to switch over to
> systemd, I am just wondering if anybody has communicated that this
> breaks many ARM platforms with "typical" vendors who only care to ship
> a kernel they once hacked at product launch, and/or the one provided
> by CPU vendor who barely does much more than fork and abandon stuff on
> linaro <http://linaro.org>. <http://linaro.org>org <http://linaro.org>.
> Okay, Linaro isn't that bad, the expensive ARM chips are better
> supported than that and the sky isn't really falling. I actually
> really do like systemd features (though I think complaints about its
> monolithic approach are valid) and I currently maintain a systemd
> build of my work for a candidate ARM target which mostly works well.
> Except that critical out-of-tree kernel modules written for 3.0 need
> to be ported to a newer kernel, and undergo expensive re-validation.
> Eg. Congatec still actively maintains its fork of Freescale's fork of
> Linaro kernel 3.0.15 <tel:3015>: https
> Count how many of gumstix' offerings officially run Linux kernels >=
> 3.7 (hint: zero) http://www.gumstix.org/access-source-code.html
> These vendor's products easily run Debian today but won't boot a
> Jessie image with systemd.
> Not because the CPUs are unable but just the sheer fork-happy,
> hack&slash insanity of software practice in the embedded space. Has
> this been communicated to the vote participants?
> Or am I completely off-base here? Most of my career has been x86-only
> until recently.
I few days ago I completely switched a SAMA5D35 ARM Cortex-A5 custom
board from EmDebian Whezzy Grip with system V inito a pure Debian Jessie
with systemd. I simply configured the apt sources files and do a normal
dist-upgrade (aside as having to force the version of a few packages to
completely avoid gripped version). The process was so smooth that all
the realtime processing applications running on that board didn't even
notice the unusual activities (well until the postgresql database
restarted with both 9.1 and 9.4 revisions running alongside). At the
reboot, systemd was in charge of the base of the system and everything
was good. Even the old custom /etc/init.d/* custom scripts specific on
that board was executed the right way. It was a complete success, and I
enjoy the systemd-analyze command.
Debian Jessy with systemd is just already incredibly perfect. I predict
that Jessis will be one of the most successful Debian release to date
and will play a major role in the embedded market. For the first time
ever, the armhf port is so complete that you can do on armhf everything
you can do on a amd64 port. I used to work on custom build, on
scratchbox build, on buildroot build, on openembedded build, but now I
do everything natively on armhf directly on the target board and really
enjoy doing so. Really, Debian Jessie is a major wonderful advance, try it.
To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
Archive: [🔎] 544A419E.firstname.lastname@example.org">https://lists.debian.org/[🔎] 544A419E.email@example.com