Announcement

Collapse
No announcement yet.

TrueOS Finishes Porting Scripts To OpenRC

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

  • #31
    Originally posted by aht0 View Post
    Such systems are ON 24/7 365 days a year. How fast it would boot is utterly meaningless because you do not normally worry about it shutting down or rebooting, except for scheduled inspections in every n'th year ...
    I never said anything about Systemd, just boot times are important. Time to reboot and bootstrap is time that you cannot capture reportable incidents. 5 minutes down can mean life and death.

    Life Safety systems are designed to RUN 24/7 365 not be ON 24/7 365. They are just like every other computer; firmware / system updates, hardware changes, and configuration changes which require a reboot.

    I occasionally deal with Fire Panels and major of the systems run propriety protocols across 3-wire or 4-wire RS485, solid wire only and at least 18 gag. They are more reliable hard-wire Security systems, requiring Fail-Safe wiring; AKA Normally Closed connections.

    Fire Panel technology is quite bad and it would be a good place for a new company to get a foot into with better technology. How many smoke detectors do you know that inform you about the particulate count in the aerosol? That would let you / software know if the smoke was building up or dissipating instead of a concentration above X. Nor is there really any redundancy with the main head-end, still the same old master/slave setups. Once that line is cut you don't know what is really going on, just that there is a systems fault.

    By the way, my life safety design motto is, "Communicate Of Things where the Internet cannot be trusted".

    Comment


    • #32
      Originally posted by k1e0x View Post

      I imagine partly. I know there were a lot of Linux'isms that had to be fixed since Gentoo has had stewardship since its creation for quite a while now. I don't think TrueOS uses bash by default either, I'm unsure if it it installs it in its default install. This is good progress I'd like to see OpenRC in FreeBSD but that may be some time off, they are pretty slow at making drastic changes in the core OS. (and thats a good thing)

      I like OpenRC a lot, its easy to use, sane to configure and modify and very fast. I've seen Gentoo systems go from bios to gdm in 2 seconds with OpenRC.
      Gentoo's init scripts are GPL infected so they need to be rewritten anyway. They are mostly POSIX sh though, aside from some occasional use of local variables.

      Comment


      • #33
        Originally posted by Yndoendo View Post

        I never said anything about Systemd, just boot times are important. Time to reboot and bootstrap is time that you cannot capture reportable incidents. 5 minutes down can mean life and death.

        Life Safety systems are designed to RUN 24/7 365 not be ON 24/7 365. They are just like every other computer; firmware / system updates, hardware changes, and configuration changes which require a reboot.

        I occasionally deal with Fire Panels and major of the systems run propriety protocols across 3-wire or 4-wire RS485, solid wire only and at least 18 gag. They are more reliable hard-wire Security systems, requiring Fail-Safe wiring; AKA Normally Closed connections.

        Fire Panel technology is quite bad and it would be a good place for a new company to get a foot into with better technology. How many smoke detectors do you know that inform you about the particulate count in the aerosol? That would let you / software know if the smoke was building up or dissipating instead of a concentration above X. Nor is there really any redundancy with the main head-end, still the same old master/slave setups. Once that line is cut you don't know what is really going on, just that there is a systems fault.

        By the way, my life safety design motto is, "Communicate Of Things where the Internet cannot be trusted".
        Unless you plan on drowning a kitchen sink into software somewhere, you would never need to deal with 5min boot times. Look at LEDE in that regard. SysVInit and it would boot reasonably fast because it's stripped down to bare-minimum-necessary.

        Systemd is necessary for this only in your imagination. Such systems need to be as simple and lean as possible - in order to minimize impacts of possible software bugs. Can you call systemd "simple and lean"? (look at github, for lines of code count). It may feel necessary for you but it's factually one of the most horribly bloated piece of software out there..

        Comment


        • #34
          @ath0 Yeah, I don't think systemd is faster than OpenRC anymore. (was it ever?) Too bloated.

          19 seconds for rc on FreeBSD? I think it can prob do a lot better than that, your prob loosing a lot of speed due to ZFS kernel modules being loaded in. Tell ya what, I'll put FreeBSD 12 on my ryzen nvme drive and use UFS and clock it.

          Edit: 12.2 seconds on FreeBSD 12-CURRENT, w/ DHCP and SSH standard server install all defaults. Most of it's the kernel loading up. - Hardware is Ryzen 7 1700, Samsung EVO 960 m2. Started clock at enter on loader, stopped at login prompt. It's not bad, I don't think FreeBSD has ever really cared too much about it's boot times or ever claimed to be the fast here. I'd compare it to CENTOS or Ubuntu Server (or whatever you ppl are using) but... god I really don't want to install those OS's. lol TrueOS I may install.. If Linux can't beat an un-optimised OS here, something is wrong.
          Last edited by k1e0x; 08-07-2017, 08:28 AM.

          Comment


          • #35
            Originally posted by Vistaus View Post

            Wrong. 24 hours later and I still have to make an exception for their SSL certificate. So they haven't fixed anying.
            it's working now

            Comment


            • #36
              Originally posted by k1e0x View Post
              @ath0 Yeah, I don't think systemd is faster than OpenRC anymore. (was it ever?) Too bloated.

              19 seconds for rc on FreeBSD? I think it can prob do a lot better than that, your prob loosing a lot of speed due to ZFS kernel modules being loaded in. Tell ya what, I'll put FreeBSD 12 on my ryzen nvme drive and use UFS and clock it.

              Edit: 12.2 seconds on FreeBSD 12-CURRENT, w/ DHCP and SSH standard server install all defaults. Most of it's the kernel loading up. - Hardware is Ryzen 7 1700, Samsung EVO 960 m2. Started clock at enter on loader, stopped at login prompt. It's not bad, I don't think FreeBSD has ever really cared too much about it's boot times or ever claimed to be the fast here. I'd compare it to CENTOS or Ubuntu Server (or whatever you ppl are using) but... god I really don't want to install those OS's. lol TrueOS I may install.. If Linux can't beat an un-optimised OS here, something is wrong.
              We shall see. Testing on a spare SSD (Sandisk SSD Plus 240GB). I'd say binaries, even bloated, are generally faster than scripts being run through interpreter.
              Machine being used: Asus H81M-Plus mobo, running Pentium G3258 clocked at 4GHz, 8GB RAM
              Methodology: I would install and set the system up, give basic conf for it, when necessary. Do 3 reboots and take the average.
              • [systemd init] OpenSUSE Leap 42.3 (server mode - boot from the end of GRUB time-out to reaching a login prompt - 10.30 sec
              • [systemd init] OpenSUSE Leap 42.3 (MATE) - boot from the end of GRUB time-out to reaching the desktop (autologin)) - 10.38 sec
              • Windows 10 Pro v.1703 b.15063.483 - 9.13 sec
              • Windows 7 Pro SP1 (all updates applied) - 9.43 sec
              • (OpenRC 0.26.2) TrueOS Server (latest Stable release) - 19.07 sec
              • (OpenRC) TrueOS Desktop (latest Stable release) - 35.64 sec
              • (SMF) OpenIndiana Hipster 2017.04 (MATE) - 16.3 sec
              • (SMF) OpenIndiana Hipster 2017.04 (console) - 12.93 sec
              • (OpenRC 0.24.1) Alpine Linux Extended 3.6.2 (console login, no NTP/SSH services) - 8.27 sec
              • (OpenRC 0.24.1) Alpine Linux Extended 3.6.2 (console login, chronyd and dropbear) - 15.92 sec (chronyd causing noticeable delay)
              • (OpenRC 0.24.1) Alpine Linux Extended 3.6.2 (console login, openntpd and openssh) - 9.24 sec
              • (OpenRC 0.24.1) Alpine Linux Extended 3.6.2 (LXDM+XFCE, without NTP/SSH) - 9.46 sec
              • (SysV init) PCLinuxOS 2017.07 (MATE) - 11.79 sec
              • (OpenRC 0.26.3) Manjaro-OpenRC 17.0.2 (XFCE autologin) - 10.05 sec
              • (RC) FreeBSD 11.1-RELEASE (UFS2 file system, console, OpenSSH service enabled) - 9.65 sec
              • (RC) FreeBSD 11.1-RELEASE (UFS2 file system, Slim autologin, XFCE4, no OpenSSH) - 12.66 sec (X default config, no manual edit, switched multiple times before remaining on proper resolution. Probably could reduce the time doing proper X setup.)
              • (RC) FreeBSD 11.1-RELEASE (ZFS file system, console, OpenSSH service enabled) - 11.93 sec
              • (RC) FreeBSD 11.1-RELEASE (ZFS file system, Slim autologin, XFCE4, no OpenSSH) - 15.04 sec

              Remarks:
              -Alpine. Had to swap Nvidia dedicated graphics out and Radeon in. Alpine would not want to know anything about Nvidia (musl libc?). Since it's installation script offered optional install for 2 different NTP and SSH servers, I did tests for both services, both for servers offered by default, for offered alternates and without. Since it's "console-Linux", had to manually install and set up XFCE and Xorg (so not really "standard" per se)
              -OpenIndiana - Had to disable onboard USB3 (Asmedia). Or the installation media just went to reboot-loop while on USB detection.
              -TrueOS - checking by kldstat revelead that it had loaded up like 40 different drivers, most of them utterly un-needed. OpenRC init itself took little time, majority of time was seemingly spent on getting the kernel going. Tried looking where those bunches of drivers were being initialized from but usual suspect files (/etc/rc.local and various files in /boot) were all empty. Too unfamiliar with TrueOS custom changes to test with just needed drivers being initialized during boot. No real desire for compiling new kernel without unneeded drivers - so be it.
              -Manjaro-OpenRC - despite me specifying drive designated as /dev/sdb as first drive in BIOS boot order, Manjaro decided to write GRUB on /dev/sda instead (ignored BIOS drive boot order completely nor asked me about it. Shame, since it fucked up the boot sector of other drive.
              - PCLinuxOS 2017.07 - Threw it in for shits and giggles. Wanted to see how traditional SysV init would do compared to systemd and openrc. First 2 boots took hell of a time because hardware detection and user creation. Once such mundane tasks completed I found that it booted up remarkably fast despite scorned SysV init.
              - Windows 10 - Cloned from another disk, daily-use windows, just drivers reinstalled for this particular machine. Installation about 2 months old.
              - Windows 7 - As with previous, cloned from another disk to save time and just reinstalled drivers for particular machine's hardware. In my experience RTM is actually bit better performing than SP1 (snappier response and better fps in games). Won't be testing RTM though - bad security practice.
              - FreeBSD 11.1 - Set up basic network, enabled/disabled SSH, installed X, Slim, XFCE4 and associated packages. No tuning/tweaking whatsoever.

              EDIT: Downloading latest TrueOS image now. Adding results later
              EDIT2: Might as well take whole bunch of different OSes and put them through same SSD.
              EDIT3: Added OpenIndiana Mate and Windows 7 Pro SP1.
              Last edited by aht0; 08-18-2017, 10:17 AM.

              Comment


              • #37
                Cool, so most are +/- about 5 sec. TrueOS being slow I'm not sure whats with that, It should be beating out rc, otherwise whats the point? There is a step more here were when you go to a graphics console X either has to autodetect it's setting or use a pre-config and we really aren't testing the speed of X (or wayland) Also OpenRC has a parallel mode, is that enabled on TrueOS? - I had Gentoo on that Ryzen system for about a week (with OpenRC) and it was super fast boot, faster than windows but it was minimal too, I didn't clock it but it'd go to login prompt before my monitor could switch modes.. You'd expect Linux to be faster being that this has been one of their calling cards for a long time and the amount of work that has gone into embedded devices.
                Last edited by k1e0x; 08-11-2017, 04:03 PM.

                Comment


                • #38
                  Originally posted by k1e0x View Post
                  Cool, so most are +/- about 5 sec. TrueOS being slow I'm not sure whats with that, It should be beating out rc, otherwise whats the point? There is a step more here were when you go to a graphics console X either has to autodetect it's setting or use a pre-config and we really aren't testing the speed of X (or wayland) Also OpenRC has a parallel mode, is that enabled on TrueOS? - I had Gentoo on that Ryzen system for about a week (with OpenRC) and it was super fast boot, faster than windows but it was minimal too, I didn't clock it but it'd go to login prompt before my monitor could switch modes.. You'd expect Linux to be faster being that this has been one of their calling cards for a long time and the amount of work that has gone into embedded devices.
                  TrueOS wanted to start up every possible and impossible driver imaginable, especially among wifi drivers. For example: when I checked kldstat it did show me pretty much every Intel wireless driver, supported by FreeBSD, loaded up.

                  Main problem is probably there being really no facility for hardware auto- detection/-configuration for drivers not built into kernel - So, TrueOS devs have simply put sort of a shim in a place - somewhere is a a list of driver modules, which OS would start up on boot - just in case user happens to have such hardware.

                  It's a non-issue on vanilla FreeBSD, because when you install vanilla - you would set up everything by your preferences and you DO know what hardware is in your machine. Automatic shit would just get in your way.

                  If I should happen to find out, just how to massage TrueOS not to load up half a /boot/, I'll do another measurement..
                  Last edited by aht0; 08-11-2017, 05:12 PM.

                  Comment

                  Working...
                  X