Announcement

Collapse
No announcement yet.

OpenWRT 14.07 RC1 Brings Native IPv6 Support, New Init System

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

  • #11
    Originally posted by caligula View Post
    Couldn't it run systemd, too?
    I believe systemd is a bit too heavy on the storage side of the equation for old and not so old routers. Every byte of flash memory counts.

    Comment


    • #12
      Originally posted by Pseus View Post
      I believe systemd is a bit too heavy on the storage side of the equation for old and not so old routers. Every byte of flash memory counts.
      But systemd is modular? You could statically link with uclibc and use gcc's -Os.

      Comment


      • #13
        Hi,

        systemd seems to run on openwrt, see here: https://forum.openwrt.org/viewtopic.php?id=49599, but the integration is not very good AFAIK.
        Would be awesome, though. Just imagine having all your logs from all your tiny devices on your sever so you always see then there is a problem,
        not having to remember if the device is a router or a real server and finally, having easy port activated services on openwrt.


        I also find it funny, that the openwrt guys do not list any reason why we need a new init system (procd) on their own wiki: http://wiki.openwrt.org/doc/techref/procd

        Let me quote this as they might change this in the future:
        "Why do we want procd?

        One thing that procd does much better then ?

        It boils down to the fact that the current ? are rather constrained and inflexible:

        ?
        ?
        ?

        procd will be able to ? - and of course all that without adding unnecessary bloat. AFAIK there are no alternatives to procd. "

        Well, we will see if procd is a good solution or not.

        Comment


        • #14
          There you go:
          [11 of July 2014] [11:18:49] <txomon|fon> have you thought about including systemd in openwrt?
          [11 of July 2014] [11:19:05] <txomon|fon> or is it too heavy?
          [11 of July 2014] [11:19:18] <jow_laptop> its too heavy
          [11 of July 2014] [11:19:30] <jow_laptop> and too tightly integrated with other subsystems we do not want
          [11 of July 2014] [11:19:48] <txomon|fon> replacing the init by a binary loader?
          [11 of July 2014] [11:19:56] <jow_laptop> hm?
          [11 of July 2014] [11:20:03] <txomon|fon> it would be really impressive the result, wouldn't it?
          [11 of July 2014] [11:20:09] <jow_laptop> the init is already replaced by a binary loader in trunk
          [11 of July 2014] [11:20:25] <jow_laptop> unless you mean init scripts
          [11 of July 2014] [11:20:30] <txomon|fon> yeah, sorry
          [11 of July 2014] [11:20:35] <txomon|fon> the init scripts and so
          [11 of July 2014] [11:20:45] <jow_laptop> those are mostly stubs that send service descriptions to procd already
          [11 of July 2014] [11:21:00] <jow_laptop> procd then handles reload, process tracking etc.
          [11 of July 2014] [11:21:15] <txomon|fon> yes, but I was speaking about suppressing those scripts
          [11 of July 2014] [11:21:24] <txomon|fon> I suppose it's on the roadmap
          [11 of July 2014] [11:22:03] <jow_laptop> well many init scripts still perform config transformation
          [11 of July 2014] [11:23:42] <jow_laptop> and this requires still scripting
          [11 of July 2014] [11:23:49] <jow_laptop> which in turn still requires spawning a shell
          [11 of July 2014] [11:23:58] <jow_laptop> unless we come up with a custom script language to do so
          [11 of July 2014] [11:24:02] <jow_laptop> which in turn will likely upset people
          [11 of July 2014] [11:24:07] <txomon|fon> yeah
          [11 of July 2014] [11:24:50] <txomon|fon> or maybe if the config setup is really simple, they don't miind
          [11 of July 2014] [11:24:54] <jow_laptop> however services that have fixed args can be probably described by fixed service description files
          [11 of July 2014] [11:25:27] <txomon|fon> well, they can also be patched to have those defaults, can't they?
          [11 of July 2014] [11:27:24] <jow_laptop> probably, but patching any possible software package to accomodate for an init mechanism is a dead-end
          [11 of July 2014] [11:27:42] <jow_laptop> too much maintenance work and a too small niche
          [11 of July 2014] [11:28:55] <txomon|fon> well, if you trim functionalities in the binaries... Anyway, the truth is that the workflow of openwrt is to adecuate incoming sources
          [11 of July 2014] [11:29:20] <plntyk> btw - does the dbus -> kdbus kernel integration have any effect on openwrt ?
          [11 of July 2014] [11:30:00] <jow_laptop> plntyk: yes, the kernel becomes bigger and multiple targets will fail
          [11 of July 2014] [11:30:47] <txomon|fon> do you have any stats on how big usually images are, or package usage statistics?
          [11 of July 2014] [11:31:31] <jow_laptop> not really
          [11 of July 2014] [11:32:01] <txomon|fon> maybe that could be interesting to prioritize packages, updates, designs
          [11 of July 2014] [11:36:02] <nbd> txomon|fon: in my opinion, systemd would be completely useless to us, because it solves boring problems in a slightly different way, while leaving the interesting problems completely unsolved
          [11 of July 2014] [11:36:17] <builder> build #5 of x86.kvm_guest is complete: Failure [failed shell] Build details are at http://buildbot.openwrt.org:8010/bui...guest/builds/5
          [11 of July 2014] [11:36:49] <txomon|fon> nbd, example?
          [11 of July 2014] [11:36:52] <nbd> starting a service and keeping track of it is boring, it has been done in so many different variations with so many different implementations
          [11 of July 2014] [11:37:29] <txomon|fon> and the interesting problems part?
          [11 of July 2014] [11:37:37] <nbd> having a unified config storage where the part that's changing the config does not need to keep track of what needs to be done to apply it
          [11 of July 2014] [11:38:08] <nbd> and our own init system plays an important role in that
          [11 of July 2014] [11:45:39] <ifdm_> the companies use to make a mess when they try to make their own process tracking system
          [11 of July 2014] [11:46:45] <txomon|fon> nbd, so you mean that not having to restart apps if config hasn't changed is that interesting?
          [11 of July 2014] [11:47:48] <jow_laptop> it is if restarting the ap has side effects
          [11 of July 2014] [11:47:51] <jow_laptop> *app
          [11 of July 2014] [11:52:22] <nbd> the restart-everything-after-changing-something model is quite stupid
          [11 of July 2014] [12:01:01] <txomon|fon> usually apps have reload mechanisms, don't they?
          [11 of July 2014] [12:03:30] <nbd> some do, some don't
          [11 of July 2014] [12:03:44] <nbd> but for many apps, configuration isn't stored in their native format
          [11 of July 2014] [12:03:47] <nbd> it's converted from uci
          [11 of July 2014] [12:05:28] <txomon|fon> sure

          Comment


          • #15
            What about a solution to enable channel 13 and 13 in Europe?

            Comment


            • #16
              Originally posted by Zajec View Post
              There you go:
              This looks like good click-bait material
              So much for systemd being good for embedded devices...
              Last edited by asdfblah; 16 July 2014, 10:06 PM.

              Comment


              • #17
                Originally posted by asdfblah View Post
                This looks like good click-bait material
                So much for systemd being good for embedded devices...
                IMHO it's the responsibility of OpenWRT developers to adapt systemd to these smaller devices. It's modular so you could make it as small as the one they use. Besides OpenWRT already uses tons of scripting languages like Lua for the web interface. Why not use only one interpreter if there's not much room? This all sounds suspicious. They could use LTO kernel to make to smaller. And better compression algos for initramfs. If they used systemd, they'd have more time to fine tune the rest of the system.

                Comment


                • #18
                  Why none of the forums experts come to the project in question? Why not post proposal of improvement, post a patch, prove the benefits.
                  If you know how to improve sth (like initramfs size), come and help!

                  Comment

                  Working...
                  X