Announcement

Collapse
No announcement yet.

FreeBSD Developers Continue Work On Shortening Boot Time, Improving WiFi Driver Support

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

  • #11
    Originally posted by kpedersen View Post
    That said, I do feel a typical server / desktop init system such as sysv / systemd will never be perfectly suited for this and as such a more bespoke solution will be needed for hyperscalers anyway.
    You may be right but I suspect engineering such a solution into freebsd would be more than enough disruption regular freebsd users would appreciate. It would violate POLA and require an extensive rewrite (and testing) of service scripts throughout the entire ports tree. Improving boot performance without any of the above would bring freebsd on par with the average linux distro, which is a nice bonus for regular users and good enough a reason for customers looking for something other than linux on various cloud providers.

    Comment


    • #12
      Originally posted by dreich View Post
      You may be right but I suspect engineering such a solution into freebsd would be more than enough disruption regular freebsd users would appreciate. It would violate POLA and require an extensive rewrite (and testing) of service scripts throughout the entire ports tree. Improving boot performance without any of the above would bring freebsd on par with the average linux distro, which is a nice bonus for regular users and good enough a reason for customers looking for something other than linux on various cloud providers.
      Sorry for the ignorance, but what does "POLA" mean?

      Comment


      • #13
        Originally posted by dreich View Post
        It would violate POLA and require an extensive rewrite (and testing) of service scripts throughout the entire ports tree. Improving boot performance without any of the above would bring freebsd on par with the average linux distro,
        I think something like systemd ported to FreeBSD would already break more than what the FreeBSD guys are willing to put up with. If this wasn't the case, I am sure there would be some merit in going the whole way and make it suitable for microservers rather than only going as far as systemd* which I personally still don't quite see a specific market for (needlessly fast for desktops/laptops/servers but still not fast enough for hyperscalers). That said, as it stands I believe the FreeBSD project is firmly in the camp of "no breakage".

        *Not to be harsh to systemd. Breakage aside, in many ways I actually liked that it provided some consistency to the very wild west state of Linux many years ago. I also quite like systemd .ini files. They have a quirky and retro feel of simplicity like back in the Windows 3.1 days
        Last edited by kpedersen; 16 June 2022, 04:15 PM.

        Comment


        • #14
          Originally posted by sinepgib View Post

          Sorry for the ignorance, but what does "POLA" mean?
          In this context it would be "Principle of Least Astonishment".

          Comment


          • #15
            Originally posted by kylew77 View Post
            but FreeBSD tries to strike a balance and is far and above the best "engineered" OS-- by that I mean that a team puts it together as a collective whole. Linux is piece meal distros with the kernel having Linus as its final say person and OpenBSD has Theo as its final say on everything. FreeBSD and NetBSD are team projects that build every part of the OS into a cohesive whole product. Debian is probably the closest Linux equivalent but is still built piece meal.
            It just means FreeBSD is easier to break if you go outside it's base system. FreeBSD is easier to slow down and break if you want an use-able system by adding ports and libs.

            Comment


            • #16
              Originally posted by dreich View Post
              In this context it would be "Principle of Least Astonishment".
              Thanks. Now, why it would violate that? IMO ad-hoc scripts tend to create more astonishment. I heard those are more polished and consistent than sysvinit ones on Linux tho, but I find having a consistent service definition to be much more intuitive in practice than having to read arbitrary scripts. Is it because of the non-determinism in ordering?

              Originally posted by Rallos Zek View Post
              It just means FreeBSD is easier to break if you go outside it's base system. FreeBSD is easier to slow down and break if you want an use-able system by adding ports and libs.
              I can't compare with FreeBSD as I only used Linux, but Linux is stupidly easy to break as soon as you try to use anything not shipped with your distro. IME the worst offender is Ubuntu and derivatives in that regard. And really mix-and-match tends to lead to poor integration and poor testing. I think an OS being an OS makes a lot of sense, and works for pretty much everyone except the odd one out: Linux distros.

              Comment


              • #17
                Originally posted by Steffo View Post
                What did they do in order to reduce the boot time? Have they something like systemd?
                Dunno what was done in kernel but when you actually happen to need service manager, FreeBSD Ports contains half dozen of those you can choose from.
                Traditional RC init has Lua-scripting backend support (if you want to go creative) and FreeBSD Ports has at least OpenRC and S6, possibly also runit (cant recall for sure). Using custom inits means mandatory changes to ports tho. Be easier to mess with Lua. Worth noting that RC init on BSD's ain't mess of cross-linked scripts like SysV in Linux. Its using sort of standard library for boot scripts and pretty simple to use. No self-inflicted wounds (sysv) justifying later even more complicated masochisms (systemd).
                Last edited by aht0; 20 June 2022, 12:11 PM.

                Comment


                • #18
                  Originally posted by aht0 View Post
                  Dunno what was done in kernel but when you actually happen to need service manager, FreeBSD Ports contains half dozen of those you can choose from.
                  Traditional RC init has Lua-scripting backend support (if you want to go creative) and FreeBSD Ports has at least OpenRC and S6, possibly also runit (cant recall for sure). Using custom inits means mandatory changes to ports tho. Be easier to mess with Lua. Worth noting that RC init on BSD's ain't mess of cross-linked scripts like SysV in Linux. Its using sort of standard library for boot scripts and pretty simple to use. No self-inflicted wounds (sysv) justifying later even more complicated masochisms (systemd).
                  Just to add on this, now knowing s6 is an option: s6 does pretty much all the things systemd does right in terms of boot speed, except socket activation for dependency handling (which is a rather controversial feature, I like it but I know many don't for some understandable reasons). It does support it for xinetd-like behavior as a separate tool.

                  Comment


                  • #19
                    Nah, boot speed ain't much of an issue. 20s or 2s makes little enough difference. Shutdown speed is more important when your laptop's battery is nearly empty - stalled shutdown while battery reaches 0% and turns machine off- THAT might corrupt your file system.

                    Comment


                    • #20
                      Originally posted by aht0 View Post
                      Nah, boot speed ain't much of an issue. 20s or 2s makes little enough difference. Shutdown speed is more important when your laptop's battery is nearly empty - stalled shutdown while battery reaches 0% and turns machine off- THAT might corrupt your file system.
                      Good thing for root on ZFS support in FreeBSD then Nearly impossible to corrupt a ZFS pool with a power failure and I've lived in some places with some sorry power.

                      Comment

                      Working...
                      X