Announcement

Collapse
No announcement yet.

BusyBox Drops Systemd Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by oleid View Post

    Why is that stupid? I use systemd in the initramfs for booting up our workstations at university. They use NFS as rootfs and thus, networking is configured in the initramfs. By using systemd in initramfs, the init system was clever enough not trying to reconfigure network later during the boot and thus the NFS connection doesn't get interrupted. By using systemd, booting our gentoo workstations on NFS-root was a breeze - it basically worked out of the box. I tried openrc before, but I stopped after editing the 5th init script and trying to figure out what blocks bootup or shutdown.

    Furthermore, as GreatEmerald mentioned, systemd is used by Sailfish OS. It works great there.
    NFS root isn't anything new. I've used LTSP systems that do exactly that since like 2005. It was more adhoc, but it still worked. I hope the distros will soon adopt this as a default. There are so many things you could do in initramfs once systemd is there. Some examples: text to speech, bluetooth input devices for crypto

    Comment


    • #32
      Is Vlasenko paid by Redhat to work on Busybox? Because if it is, with systemd being also a Redhat project, we can predict some shit hitting the fan, don't we?

      I mean, one can disagree with the systemd technical and political decisions made by those involved, but if I were a Redhat HR manager I would hardly overlook this childish, imature Vlasenko's way of handling things.

      Comment


      • #33
        Originally posted by atari314
        "strong language"? are you one of those sensive SJW that gets offended with anything? /roflmao /dealwithit
        You mean as opposed to that sensitive flower who felt the need to remove a total of 76 lines (there are programming languages with "Hello Worlds" longer than that) because ebil, ebil systemd developers didn't agree with him?

        PS: The very mention of "SJW" makes you look like an uneducated douchebag with no real life experience and no sexual experience with anyone but your hand.

        Comment


        • #34
          Originally posted by unixfan2001 View Post
          You mean as opposed to that sensitive flower who felt the need to remove a total of 76 lines (there are programming languages with "Hello Worlds" longer than that) because ebil, ebil systemd developers didn't agree with him?
          "Vlad" is pretending to speak on behalf of the entire world. His "objection" is utterly unspecific and vague. Seems like a drama queen. Also his response to a perceived problem is to respond in kind. Highly pathetic, especially reading the small amount of code this deals with.

          Comment


          • #35
            Originally posted by bkor View Post

            "Vlad" is pretending to speak on behalf of the entire world. His "objection" is utterly unspecific and vague. Seems like a drama queen. Also his response to a perceived problem is to respond in kind. Highly pathetic, especially reading the small amount of code this deals with.
            Yea. Basically he just removed some sort of small compatibility shim written by someone else. Something that wasn't even enabled by default.
            There is no reason for the removal as it's unlikely to have incompatibilities arise because of it. A decision based purely on zeal.

            Comment


            • #36
              Originally posted by caligula View Post

              NFS root isn't anything new. I've used LTSP systems that do exactly that since like 2005. It was more adhoc, but it still worked. I hope the distros will soon adopt this as a default.
              Sure it's nothing new, but the init scripts of the system have to support it. If systemd supports it and is shared between all distros, you should be able to nfs-boot any distro.

              Comment


              • #37

                BusyBox is a single executable file.

                "As it is a complete bootstrap system, it will further replace the init daemon and udev (or the latter-day systemd) using itself to be called as init on startup and mdev at hotplug time, respectively."

                Comment


                • #38
                  Way too much buzz and drama out of nowhere. Have somebody actually looked into that "systemd support" code? UTTER BULLSHIT. Dropped chunk of code barely used one of systemd features. So much "support", dammit. TBH, I would have hard time to call it "systemd support" at all, but it seems busybox devs have very interesting notion of "support". IMHO it mostly looks like dirty PR bullshit.

                  And on side note, on systems where busybox actually makes sense (e.g. small routers/serial converters/etc with 32Mb RAM, etc) systemd is kinda overkill anyway (do you really want to spend something like 3-4Mb out of 32 just to start other programs?). Not to mention busybox comes with own init implementation, and hence a "competitor" in some sense, so it would be naive to expect fair/unbiased approach. Yet, busybox's own init haves really sucking boot times compared to better init systems, btw. Not to mention it lacks any goodies upstart or systemd have, so good luck to handle all errors in scripts, set processes priorities, limits and so on, handle startup timeouts and watchdog processes, etc. That's what prompted openwrt devs to code their procd, etc. When it comes to init, busybox's init suxx. It exposes worst properties you can get from init system. But it seems busybox devs are better at throwing shit than solving hard technical problems these days. Busybox? "Rest of world"? Whoa, really impressive arrogance showcase!
                  Last edited by SystemCrasher; 02 November 2015, 04:29 PM.

                  Comment


                  • #39
                    Originally posted by duby229 View Post
                    Well, busybox has been running on embedded systems and initramfs'es for a long time now. Obviously systemd is something that is not needed in that arena at all. You shouldn't be using systemd in that space anyway. Anybody trying to shove systemd into an initrd is stupid.
                    As one of those who implements custom embedded systems I dare to object this statement. In embedded I'm really fond of some systemd features. Say, systemd can track service startup timeout. Systemd provides useful process watchdog facility. And so on.

                    Imagine I have some critical service, which performs important task related to device's mission. It would be bad if critical service would just stuck during boot, right? It would make a lot of sense to try to restart service (or whole device), retrying before completely giving up, failing hard and demanding human supervision ("contact supplier", etc). While it "should not happen", shit happens. E.g. due to EMI or cosmic particles, just software bugs or whatever. Error can be transient and retry makes sense, because troublesome condition possibly vanished. And it is nice if device can recover on its own, because there could be no human to press RESET at all. And it's not like if classic init (or busybox) can offer tracking of program startup timeout. Coding it myself is not a good idea either. This area haves many interesting pitfalls (e.g. what would happen if NTP adjusts system time while we were measuring time?).

                    Then, systemd has got reasonable watchdog API. It can check if critical service alive and if service does not calls watchdog API in alotted time, action could be taken. To make picture complete, systemd could service hardware watchdog to prove it alive (and able to watchdog processes). "Watchdog tree" appears. And it is damn good idea. What is the point of whole device, if service wihch is critical for device bahavior has locked up? And what others have to offer? Code my very own process watchdog API, home-grown, poorly tested and incompatible? Fuck that.

                    Not to mention systemd can change process priority, set realtime scheduler if you need that, change user, limits, apply SECCOMP filter or alter CAPS, and do many other low level system things. Which are hard to do it right from scripts, and even in C code it is one of most tricky and delicate areas (you have to check for many errors and sequence it right, one wrong step and it would not do what expected, etc).

                    And if we take a look on "competitors", most of them just do not give a fuck what would happen in many cases. It is rather common to see busybox-based router hanging dead until human would appear and toggles power. I do not think it is how devices should work.

                    ...and systems are getting more powerful. These days you can easily get 1-2 CPU cores @ 1+ GHz, 1Gb RAM and so on at sub-$30 price, at size smaller than credit card. Needless to say, systemd is okay on such hardware. And since it offloads heck a lot of system coding from implementers, it could be viable option. Over time it would "getting worse".
                    Last edited by SystemCrasher; 02 November 2015, 05:14 PM.

                    Comment


                    • #40
                      Originally posted by SystemCrasher View Post
                      As one of those who implements custom embedded systems I dare to object this statement. In embedded I'm really fond of some systemd features. Say, systemd can track service startup timeout. Systemd provides useful process watchdog facility. And so on.

                      Imagine I have some critical service, which performs important task related to device's mission. It would be bad if critical service would just stuck during boot, right? It would make a lot of sense to try to restart service (or whole device), retrying before completely giving up, failing hard and demanding human supervision ("contact supplier", etc). While it "should not happen", shit happens. E.g. due to EMI or cosmic particles, just software bugs or whatever. Error can be transient and retry makes sense, because troublesome condition possibly vanished. And it is nice if device can recover on its own, because there could be no human to press RESET at all. And it's not like if classic init (or busybox) can offer tracking of program startup timeout. Coding it myself is not a good idea either. This area haves many interesting pitfalls (e.g. what would happen if NTP adjusts system time while we were measuring time?).

                      Then, systemd has got reasonable watchdog API. It can check if critical service alive and if service does not calls watchdog API in alotted time, action could be taken. To make picture complete, systemd could service hardware watchdog to prove it alive (and able to watchdog processes). "Watchdog tree" appears. And it is damn good idea. What is the point of whole device, if service wihch is critical for device bahavior has locked up?

                      Not to mention systemd can change process priority, set realtime scheduler if you need that, change user, limits, apply SECCOMP filter or alter CAPS, and do many other low level system things. Which are hard to do it right from scripts, and even in C code it is one of most tricky and delicate areas.

                      And if we take a look on "competitors", most of them just do not give a fuck what would happen. It is rather common to see busybox-based router hanging dead until human would appear and toggles power. I do not think it is how devices should work.
                      Don't forget hotplug stuff. Many routers nowadays work as audio/file/print servers. I still think the main reason for not having systemd there is the persistent space, not RAM. Even some 802.11ac routers have only 8 MB of ROM. It's not much. You might need 1 MB just for the firmware, 3 megs for the kernel. The hardware might reserve 1/2 megs. You really don't have room for systemd.

                      Flash space should be cheap nowadays. Around $0.25 to $1.00 per gigabyte (NAND). NAND is good enough if you have enough of it. I can't see why the routers have less than a meg of flash. They already have 128-512 megs of RAM ($70 to $200 routers).

                      Comment

                      Working...
                      X