https://news.ycombinator.com/item?id=10015639
 |
|
vezzy-fnord on Aug 6, 2015 [-]
Could you please elaborate why?
Leaving aside licensing issues, the technical effort to strip down and port systemd from its obscenely opinionated GNU/Linux target to AOSP would be herculean. It would need to be taught to understand Android system properties and initialize the property workspace, it would have to be ported from glibc to Bionic, the directory hierarchy must be adjusted, it would need to interact with the Android verified boot mechanism, use the Android-specific SELinux extensions, understand the keychord driver, understand the Android subsystem IDs, mix with the hardware RNG, handle /dev/socket links and a host of other things.
All for what? systemd is based on a dependency model, it's made for proactive use and it has sprawling configuration. It's opposed to Android init's event/trigger system and having monolithic boot scripts for stuffing into an initramfs and never touching again.
Let's not even talk about moving from /ueventd.rc to udev rulesets.
Ultimately that would be a terrible idea and a waste of time bringing zero benefit.
|
|
|
|
2bluesc on Aug 7, 2015 [-]
Primarily because other then some open source ROMs, I've never seen a AOSP build that wasn't hacked to oblivion by our friends at the chip companies with little glue logic that doesn't fit. Systemd would natively support all of these things and there would be less hackery at the vendor levels let alone the strange way things are inherited from system to vendor to product levels.
To understand the android property system would be somewhat trivial, getprop, setprop, watchprop. Again, I see so many hacked properties by hardware vendor to manage hardware state like wifi on or what not.
I've never met a person with a good understanding of the Android init system and thought "oh this is nice" or even close when compared to upstart, launchd or systemd (SysV init bash madness is dead thank god).
Besdies, the world could better with a little less fragmentation. Imagine a world where you could develop Android product and then re-use a fair chunk of the init system for your hardware development/validation/burn-in test platform.
|
|
|
|
vezzy-fnord on Aug 7, 2015 [-]
I can't make any judgment whether systemd would natively support all of this glue logic without knowing the specifics of the logic in question. Further, the major modifications that would need to be made for an AOSP systemd might invalidate some of them.
It's not just adding some unit file options for properties. You have to build ordering, synchronization and whole-scale system integration around it. Besides all other features and minutiae of AOSP.
I would think the Android init is intentionally limited, reflecting its use for configure-once embedded devices? It's not a sysadmin's tool by any means.
You see fragmentation, I see multiple approaches. Imagine a world where everyone votes for the same one-world government political party. Is reusing a fair chunk of the init system even that major an aspect of developing these devices? It certainly might be with systemd because of how all-encompassing it is, but in principle it shouldn't be.
|
|
|
|
adestefan on Aug 6, 2015 [-]
It will never happen because both are covered by the GPL. You're more likely to see Google strip out the Linux kernel and replace it with something else.
|
|
|
|
|
|