systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Posted Oct 24, 2014 8:02 UTC (Fri) by csirac2 (guest, #99520)In reply to: systemd needs linux > 3.7, which excludes most ARM embedded hardware by johannbg
Parent article: The Debian init system general resolution returns
In my own case, I have to support a fleet of devices sold with *current* product lines from vendors who think kernel 3.0 is still an acceptable thing to tie all their customers to for another 5 years. That's including a dual-core 1GHz Freescale I.MX6, Cortex A9 upgrade option which to my dismay, is also still on kernel 3.0.
I have experimented with Linaro kernels for these CPUs but porting over the platform drivers is a non-trivial task (custom peripheral bus, magic numbers, strange undocumented timing quirks), and then I'd have to pitch a business case to go through re-validation all over again.
Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie, but dismissing this concern as "helpless n00bs don't want to do the slightest bit of work" and that I should just back-port cgroups and BPF_XOR isn't exactly the pinnacle of enlightenment either.
Posted Oct 24, 2014 8:46 UTC (Fri)
by johannbg (guest, #65743)
[Link]
That is an industry/vendor problem that has chosen to go down the path of added burden of continues back porting which you unfortunately have to maintain from the looks of it. I guess pushing back harder that it is the wrong thing to do or rather the *costly* thing to do, which perhaps those that make those decision would understand better.
"Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie"
It requires package split, an sub package that contains the relevant init script for the init system being supported, ( one for unit file, one for sysv script and one for upstart for example ) and last time I checked none of the embedded devices are running "stock" distributions on their devices but heavily customized systems, which in turn they could just as well carry/maintain this stuff themselves could they not?
Bottom line asking of or expecting others to do the work for you, is the fallacy in open source project in general as Thomas Gleixner touched upon in the "future of the realtime patch set". There seems to be whole lot of consumers be it users or industries that expect they get the whole pie without having to pay for it ( in this case in the form of contributing back to the relevant project(s) they are depended upon )
Posted Oct 24, 2014 9:53 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (8 responses)
For the record, any claims that Debian package maintainers are falling over themselves to get rid of sysvinit scripts for jessie are wildly exaggerated. Removing existing (and working) sysvinit support from packages is not Debian policy so far, or even a good idea. We would of course like Debian maintainers to add systemd unit files to packages, but since systemd can deal with sysvinit's init files there is no particular hurry, and there is no problem whatsoever if a package contains both systemd and sysvinit support.
Posted Oct 24, 2014 11:29 UTC (Fri)
by johannbg (guest, #65743)
[Link] (7 responses)
The backwards compatibility to legacy sys V format is not 100% so technically yes there is ( since those init scripts are to put it mildly vary in quality and LSB compliance ) and then there are the problems from a practical, usable standpoint so indeed there are dragons if you chose that path. ( Remember Debian is not the first distribution to be migrated we have gone through the same discussion, the same dance in each community that was deciding to make the switch, Fedora,Mageia,OpenSuse, Arch etc all of them )
If you ship both the administrator/end user is under the assumption he can use either the legacy sysv initscript or the systemd native service unit ( since both of them are now installed ) which they will quickly and painfully realize they cannot ( followed by usual complains,bug reports to the relevant maintainer(s) and mailinglists ).
Systemd units take precedence over legacy sysv initscripts which results in the administrator or the end user, who thinks units are junk and the shell scripts are the holy grail of all things as written in the illusion of existence of some kind of unix bible, is to "delete" the service unit and their problems are all solved. ( As I have observed )
Ding Ding Ding wrong answer, on next package update for the component that unit file "re-appears" and takes precedence ( again ) over the existing legacy sysv initscript, effectively rendering it's usage and potential customization it carry's with it useless.
So if the intent is to support more then one init system you have split the initscript, relevant to each init system into it's own component and have that sub-package installed based on what init system is installed on the system.
The alternative is just to ship ( and fix the legacy initscript to be compliance with LSB ) but if you do that you effectively render the work and benefits of switching the init system in the first place useless as can be seen previously with all the distribution that switched to upstart, since with the exception of ChromeOS no distro ever attempted to integrate upstart with the distribution to any extent.
If they had switched to native upstart format it would have caused just as much "disruption as systemd currently is doing.
Now the question that's on everybody's mind and depends on the outcome of the GR' who's going to do all that work necessary to support multiple init system if/when it comes down to it in the distribution.
Posted Oct 24, 2014 12:23 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (6 responses)
I don't buy this. LSB compliance for init scripts has been standard in Debian for a very long time. Lintian has included checks for LSB compliance since 2006. My system has 98 init scripts and not a single one of them does
not have an LSB metadata header. I don't think non-LSB init scripts are
actually a real issue on Debian.
Debian packages for jessie that provide background services should ideally contain both an LSB-compatible sysvinit init script and a systemd service unit file (which may enable systemd-specific bells and whistles that are difficult to support with sysvinit). If systemd finds the service unit file it disregards the init script. Sysvinit of course disregards the systemd unit file completely. Nothing about this is rocket science. There is no need to provide separate packages depending on the init system in use. Add upstart/… configuration files to taste.
If this doesn't work on a systemd-based jessie system you file a bug against the package. If this doesn't work on a sysvinit-based jessie system you file a bug against the package. Where's the problem?
Of course – but that is neither here nor there.
As far as I'm concerned, packages must support the default init system (systemd). If packages have working support for sysvinit, as pre-jessie packages will, it makes little sense to remove it (at least for jessie, but probably also going forward). People who want packages to support other non-default init systems – or sysvinit, for packages newly added to Debian after jessie's release whose upstream versions only support systemd – are free to volunteer their efforts if package maintainers won't do it by themselves, and package maintainers should include appropriate patches from third parties if possible. This is how things generally get done in FLOSS, and I'd presume that most package maintainers would have pursued this course in any case, even without a GR. Personally I'd be surprised if the GR will say anything substantially different but who knows.
Posted Oct 24, 2014 13:26 UTC (Fri)
by johannbg (guest, #65743)
[Link] (5 responses)
My experience tells a different story by overseeing and handling the process of integration as well as doing the most of the migration/integration of systemd into Fedora. I too was under the assumption that those maintainers actually knew what they where doing and adhered to standards but oh boy oh boy was I wrong and as I was crawling through those up to 1000 components in total. looking at and migrating them I came across one fuckup after another ( including pourly written initscripts up 900 lines long ) ranging from packaging mistakes and or simply outdated spec files ( or full of if fucking this RH platform then do this or if this fucking RH release do this ), to broken initscript, useless cron jobs, incorrect dependency's ( or no dependency's ), half migrated features to literally no maintainers existing maintaining that component at all ( as long as it builds it shipped hurray for wasting service support community time and potentially exposing users to security risks ) and remember these are just the components on core/baseOS and or contained services daemons and on top of that I had to deal with the incompetence of FESCo ( with the exception of Miloslav Trmač ) and the FPC.
And I can tell you despite what Red Hatters might claim and state that Fedora has migrated to systemd after doing precisely that for what 5 years or since the initial push in F14. the integration/migration to Fedora is ca 80% done roughly 1000 man hour I had calculated myself to finish that to be on par what I considered acceptable for our end user base and as a project ( apparently I held things at much higher standards then most people in Fdora ) stuff that when I left the project due to certain Red Hatters and them demolishing what the project had stood for all these years.
I can also tell those Red Hat conspiracy theorist that Red Hat is to busy misusing contributors and their time in Fedora for their own benefit and that it as an company is as organized as bunch of cats ( and I ain't talking about Lions ) that they dont have neither the intelligence nor the time to cook up any kind of world conspiracy plot and I know for a fact that certain individuals from the self dubbed systemd cabal would walk away from the company if it ever tried to influence the systemd project and it's community.
My message to anyone that thinks about contribute to Fedora, dont for the life of it contribute to it or any other distribution or basically anything that Red Hat associates itself with as an "Community sponsor". What it as an corporate sees as "community sponsorship" is equivalent of corporate oppression in rest of the world
Posted Oct 24, 2014 13:58 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
Great. So what does that tell us about Debian?
Posted Oct 24, 2014 14:42 UTC (Fri)
by johannbg (guest, #65743)
[Link] (3 responses)
How much and for how long that transitioning pain depends on themselves but they should in all be able to catch quickly to same point the other distribution are due to the collaboration effort of existing distribution that have *already* handled the migration for at least the half of what the initscripts Debian ships and they should be able to easily achieve that if they work *together* before Jessie gets released.
Unfortunately they seem to be choosing the route of most resistance with all these GR's and thus the route of most distraction and most transaction pain ( and length of that pain ) in the process ( and arguably also the route of the harder maintainership during the life cycle of Jessie ).
Based on my experience and if it was up to me and I was doing this all over again from scratch and at this point in time ( the current work that distributions have done would have already be done which was not the case when I was working on this ) then I would delay Jessie until it had caught up with the point other distributions are now at with systemd, release and then gradually migrate the rest in unstable ( and hopefully manage to have that covered for next Debian release ) but it's not up to me so meh...
Posted Oct 24, 2014 15:18 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
”They” is perhaps a dozen people or so. In addition, the GR is not about jessie at all, and shouldn't impact the jessie release in any way other than by distracting attention from the upcoming freeze (which is annoying but probably not really a problem). I don't think the discussion has anything useful to add at this point, so most Debian developers will probably lose ten minutes or so in order to fill in a ballot when the vote comes around. Anything more is really luxury.
This is probably what will happen in the end. The GR doesn't really matter as far as jessie is concerned, and I don't think we're in that bad a shape to begin with – most of the packages in question have reasonable sysvinit scripts that we will be able to use with systemd in jessie even if they don't have native systemd unit files. Various bugs have been identified and fixed recently, we'll probably shake out some more bugs during the freeze, and we'll have a couple of years after jessie is released to do the rest of the conversion. The end of the world is not nigh.
Posted Oct 24, 2014 15:49 UTC (Fri)
by johannbg (guest, #65743)
[Link] (1 responses)
Distractions for individuals working in the IT sector not only delay task completion and increase the number of bugs ( encase you are a developer ), but can also lead to increased stress and frustration levels, which can then lead to even more delays and in some cases, burnout for contributors.
And what you are basically saying if that is the case is that this stunt by Ian and his seconders was deliberately made to distract the community from it's work since it wont have any effect on Jessie hence could have waited until Jessie would have been released.
Something I personally would not take lightly and would immediately propose or insist that at some point in the development cycle GR's would be put on Freeze until after release to prevent misuse of the process and distracting people from doing their work.
"most of the packages in question have reasonable sysvinit scripts that we will be able to use with systemd in jessie even if they don't have native systemd unit files"
As I mentioned elsewhere dont hesitate to be in contact upstream if you need help with that migration since these kind of migration/integration work in distributions with systemd is beneficial to *all* so it does not take many resources from systemd community from every distro to lend a hand and help with that migration. ( It's better to get a crew already familiar with this rather then expecting each maintainer being able to put themselves into inner workings of systemd, they can always do so *after* the component shipped native systemd units ) It just requires a bit of organizing and packagers ( in all distros ) to be on stand by when that happens and it will be quickly over and integrated for *everybody* involved.
Posted Oct 24, 2014 17:27 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
If you look at the debian-vote mailing list it seems that 95% or more of Debian developers aren't bothered by the GR. At least it doesn't seem to distract them to a point where they feel the need to add to the discussion. The whole thing really seems to be a tempest in a teacup. We'll see how the vote comes out when it comes out.
Posted Oct 24, 2014 10:01 UTC (Fri)
by tao (subscriber, #17563)
[Link] (1 responses)
While the "helpless n00bs" thing is uncalled for (though I must say that a lot of the systemd opponents use arguments amount to "I've learned to do things this way, I don't want to try to adapt to systemd"), your scenario when you already run a non-Debian kernel is hardly a scenario that Debian should be expected to take into consideration. With over 30000 packages there's enough work as it is to keep things working with *is* part of Debian...
Besides, for Jessie sysvinit scripts *WILL* be retained, so I don't really see much cause to worry about that. The GR, mistimed though it is, would only affect Jessie + 1 (where I *personally* think that dropping sysvinit scripts would be the sane thing to do; no one required upstart support while sysvinit was the default; requiring sysvinit scripts with systemd as default seems similarly stupid). For your particular product I'm bravely gonna assume that you won't be supporting an upgrade to Jessie+1 while still running a 3.0 kernel...
Posted Oct 24, 2014 14:00 UTC (Fri)
by dlang (guest, #313)
[Link]
And you really don't want to have to fight backporting software, especially if the newer versions start depending on systemd, which is going to be very hard to backport.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Perhaps it really is asking too much of Debian package maintainers to retain sysvinit scripts in packaging for Jessie
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
So if the intent is to support more then one init system you have split the initscript, relevant to each init system into it's own component and have that sub-package installed based on what init system is installed on the system.
If they had switched to native upstart format it would have caused just as much "disruption as systemd currently is doing.
Now the question that's on everybody's mind and depends on the outcome of the GR' who's going to do all that work necessary to support multiple init system if/when it comes down to it in the distribution.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Unfortunately they seem to be choosing the route of most resistance with all these GR's and thus the route of most distraction and most transaction pain
then I would delay Jessie until it had caught up with the point other distributions are now at with systemd, release and then gradually migrate the rest in unstable
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware
Something I personally would not take lightly and would immediately propose or insist that at some point in the development cycle GR's would be put on Freeze until after release to prevent misuse of the process and distracting people from doing their work.
systemd needs linux > 3.7, which excludes most ARM embedded hardware
systemd needs linux > 3.7, which excludes most ARM embedded hardware