Announcement

Collapse
No announcement yet.

Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

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

  • #91
    Originally posted by oiaohm View Post
    Really I would like to see the benchmarks. As I have not seen a performance benchmarks where debian loss to Devuan. The lack of containerisation in Devuan does effect your ability to bias correctly as well


    That is a double sided sword. Shell script might be open to sysadmin to look at its also open of sysadmin to typo in as well. .service files where the template code is no there has some serous advantages in error reduction.

    Its easy to forget that majority of a sysvint/openrc scripts is template code being duplicated over and over again increasing risk of human error.
    But Still,
    A editable language, would be preferred, if you make a typo, its your responsibility.
    We are used to do changes on-the-fly.
    Sometimes without machines to test the code..

    I am doing that, with some great amount of oracle databases code, with lots of terabytes, for some years, and no problems...also with other products in same scale..
    _BUT_, you do need to know what you are doing!
    Because all Company business is at stake..and any change you do, you feel the pressure of a possible failure on your shoulders..

    But Editable code, on the fly, trust me, is a way better solution.
    I still have a dream to see a language like Lua, for a init system..
    Open, fast, editable, double floating precision, and so on..

    Compiled code is... impossible for us..
    Believe me or not,
    But I do know what I am talking about, I work with linux for some 20 plus years, for Several Countries in the world..

    Comment


    • #92
      Originally posted by tuxd3v View Post
      Compiled code is... impossible for us..
      Believe me or not,
      But I do know what I am talking about, I work with linux for some 20 plus years, for Several Countries in the world..
      I have also worked with Linux for over 20 years.

      I also know what I am talking about I also have over 20 years of experience. In my 20 years I have learnt not to through the baby out with the bath water like you are doing. Facebook and other are not using systemd heavily for no reason. cgroup/namespace setup in systemd is fairly straight forwards and makes bias between services easy.

      Originally posted by tuxd3v View Post
      A editable language, would be preferred, if you make a typo, its your responsibility.
      Editable language is not always preferable. Heck if editable language was always prefer you would be using tccboot to build Linux kernel at boot and tcc runtine to build bash... The problem comes where should be binary and where should not be and this comes a double side sword problem or more. And I bet it not you who is pay the money when you your typo causes your firm to miss SLA requirements so has to pay customers at times millions of dollars in compensation.

      The lack of flexibility to administrators by systemd is offset by lower error rate. Yes if you employer is seeing lower downtime issues using systemd due to less human error of course they are not going to support you using script based init. So it is a double sided sword like it or not.

      Systemd .service files are not a bad idea but they are most likely not the ideal solution for everything.

      Some of the work with openrc there were a few developers looking at adding systemd .service support to openrc. This would make a init system that has the best of both worlds.

      Think of it this way you have a double sided sword 1 side is sharp and one is quite bunt. The sharp side is good for taking down people without heavy armour and the blunt side is good to use with heavy armour. Use the wrong side of sword things don't work well. This is what you see with openrc script based vs systemd.

      .service files in systemd are good for basic services and setting up protections and biasing around those services. Don't mess around with complex scripting when you don't have to.
      Script init system good for complex services to start but are many times the complexity you need for simple services so just increase error rates that hurt bottom line.

      So this is a classic double side sword with blunt and sharp edge if you choose one side the sword is no longer good for all possible enemies. Yes choosing only template or only script has the same problem with services. Yes I do end up with scripts inside system.service files.

      Depending the services, bias and uptime requirements systemd can be be best choice over script based init. Now a init that offers script based init features and systemd .service hard template could be a nice middle ground.

      Really those who are saying script is then they always include
      Originally posted by tuxd3v View Post
      you do need to know what you are doing!
      that is garbage. Why is it garbage.
      Human error does not care how many years of experience you have or how well you are trained. It called human error because anyone who is human will do it at some point.

      You control human error by reducing amount of work human need to-do.

      The fact that script requires more lines to-do the same things systemd .service file does increases your human error rate. It about time you pull your head out the sand. Future init systems need to take in what systemd has done with .service files as these reduce human workload. Of course humans have the option to use script for more complex problems would not be a bad thing. But to control human error you need to provide a system so simple things are well reduced lines of typing.

      Human work to make service function is something those designing historic init systems never considered instead went for flexibility. Flexibility+light as possible human work would be a good init system. Currently I don't know of any production init system that gives you both.

      Comment


      • #93
        Originally posted by oiaohm View Post
        In my 20 years I have learnt not to through the baby out with the bath water like you are doing.

        Facebook and other are not using systemd heavily for no reason. cgroup/namespace setup in systemd is fairly straight forwards and makes bias between services easy.
        I don't uderstood the baby bath thing...by that, you mean, the people doing the first steps in administration?
        What Facebook does, at least is not my concern, I deal with serious business,with real money, not with 'personal perfil chat like companies'

        Originally posted by oiaohm View Post
        The problem comes where should be binary and where should not be and this comes a double side sword problem or more. And I bet it not you who is pay the money when you your typo causes your firm to miss SLA requirements so has to pay customers at times millions of dollars in compensation.

        Systemd .service files are not a bad idea but they are most likely not the ideal solution for everything.
        Thanks god , I don't remember last time that happened..
        Code, then analyze...confuse? Don't implement it!
        Wait check again, step by step, calmly, then release it..only when you know for sure what will happen, at each step..

        There are different types of Business.
        The serious ones, like Banks Systems, Insurance companies, and so on, and the virtual ones like Facebooks, google, and so on..

        The requirements for each of them are different..
        The first one, require very talented, and above all, responsible people, but the second its not the same thing..the losses are not equal, when a failure comes..
        So maybe in the second one, systemd is more adjusted to their business.

        Systemd .services...or let call them SysVinit copy..
        A lot of people talk about that, of Systemd Services like if it was an invention......systemd copies the exact same way from SysVinit ...

        /etc/init.d/rcS on inittab
        will go after all scripts in /etc/init.d

        Were is the big thing you are talking about?

        its the same process, but worst...in the core..its like magic, you don't have editable code to analyze..so its worst than SysVinit( because you can't look at the code on the fly..so they copied SysVinit...but done it in compiled code...puff )

        The unique thing that I see in systemd is about the names space, a easier way to separate user processes from root processes or so..but they complicated it..

        Originally posted by oiaohm View Post
        Some of the work with openrc there were a few developers looking at adding systemd .service support to openrc. This would make a init system that has the best of both worlds.

        Think of it this way you have a double sided sword 1 side is sharp and one is quite bunt. The sharp side is good for taking down people without heavy armour and the blunt side is good to use with heavy armour. Use the wrong side of sword things don't work well. This is what you see with openrc script based vs systemd.

        .service files in systemd are good for basic services and setting up protections and biasing around those services. Don't mess around with complex scripting when you don't have to.
        Script init system good for complex services to start but are many times the complexity you need for simple services so just increase error rates that hurt bottom line.

        So this is a classic double side sword with blunt and sharp edge if you choose one side the sword is no longer good for all possible enemies. Yes choosing only template or only script has the same problem with services. Yes I do end up with scripts inside system.service files.

        Depending the services, bias and uptime requirements systemd can be be best choice over script based init. Now a init that offers script based init features and systemd .service hard template could be a nice middle ground.

        Really those who are saying script is then they always include

        that is garbage. Why is it garbage.
        Human error does not care how many years of experience you have or how well you are trained. It called human error because anyone who is human will do it at some point.

        You control human error by reducing amount of work human need to-do.
        Systemd do the same as SysVinit in that regard, you have scripts that they call services, that do things..after all its the same
        But you will have to create the scripts systemd services call...so in the end...the same capability, but worst..compiled code and a init system that pretends to be a Operating System..

        Maybe it reduces a bit the human error..maybe..

        Originally posted by oiaohm View Post
        The fact that script requires more lines to-do the same things systemd .service file does increases your human error rate. It about time you pull your head out the sand. Future init systems need to take in what systemd has done with .service files as these reduce human workload. Of course humans have the option to use script for more complex problems would not be a bad thing. But to control human error you need to provide a system so simple things are well reduced lines of typing.

        Human work to make service function is something those designing historic init systems never considered instead went for flexibility. Flexibility+light as possible human work would be a good init system. Currently I don't know of any production init system that gives you both.
        In systemd you need to create your scripts to run on a systemd service..no the systemd service file is simpler, but your script that will be executed its almost the same..
        The amount of work needed in sysVinit to do the same is almost the same as in systemd, no gains on that regard.

        I continue to say systemd makes to nexus, apart from parallelization of boot( that also could be done in other ways ), and centralization of several tasks...this centralization is for me the biggest feature..but I also agree that systemd is not the answer.

        We need a init system open, and by that I mean editable,
        With a language that is fast, low resources, double precision floating point,WORA( write once run everywhere )..
        I agree on Centralization of some common tasks, and with a simple way to implement your deamons or whatever you want

        But systemd is NOT the Saint-Grail that a lot of people says it is..

        For me, it is a stone in middle of progress, that delayed what a init system should be.
        If it was not for him, today we will be with joy on our faces because a better init have appeared..it delayed that progress..


        Comment


        • #94
          Originally posted by tuxd3v View Post
          In systemd you need to create your scripts to run on a systemd service..no the systemd service file is simpler, but your script that will be executed its almost the same..
          The amount of work needed in sysVinit to do the same is almost the same as in systemd, no gains on that regard.
          Once you are putting cgroups and namespaces around you services sysvinit scripts don't come fun any more. For the Linux kernel default scheduler to work right you need cgroups. Yes sysvinit is less work when you are not meeting what the Linux kernel scheduler requires. Manually allocating cgroups to services in sysvinit is path to human error and massive failures. Systemd .service file process by something smart enough to avoid incorrect allocations in cgroups is a massive improvement.

          Originally posted by tuxd3v View Post
          But you will have to create the scripts systemd services call...so in the end...the same capability, but worst..compiled code and a init system that pretends to be a Operating System..
          I have a problem here majority of services converted to systemd I have seen directly call the executable binary no scripts. This is like you have never read systemd .service files to see what they normally contain.

          Yes when systemd is coverting sysvinit service scripts to systemd tracked you have scripts called a lot. But when you have native systemd services very little script usage. Also I guess you have never used systemd a lot just pure avoid it.

          https://access.redhat.com/documentat...emd-unit_files

          .service files of systemd has a lot of human error reduction. You need to add something to a .service file under systemd you don't need to edit the service file instead you create a .conf file in a .d directory of that service file.

          Systemd service files design is designed so human error is controlled. Yes this .d usage had come standard in lots of other services just never made it into the init system. .d extending does not suit scripted files.

          Originally posted by tuxd3v View Post
          /etc/init.d/rcS on inittab
          will go after all scripts in /etc/init.d
          Pure systemd system those directories don't exist. Pure systemd systems are using .service files only.

          Comment


          • #95
            Originally posted by oiaohm View Post

            Pure systemd system those directories don't exist. Pure systemd systems are using .service files only.
            Of course they don't exist..._EXPLICITLY_,
            BUT they exist somewhere in the code, not in the exact same form, but happens to do the same thing, plus a lot more things that are avoidable.

            Seems that you do not adapt Big Midleware Infraestructure products..to your operating systems..
            In that products, you do need to deal with some thousands of lines, could be bash, ksh,csh,perl,C or whaever, and in the majority of the cases you don't have that "binary thing"..that you have in desktops..
            By the way, lots of that machines could be running AIX5,6,7, or Linux in a variety of forms, and arch's

            With systemd you need to create the script, them create the service, and only then, its the same as SysVinit...enabling the service.
            But even then you get always systemd messing with your stuff..

            Its the same garbage as Network Manager that in fact come from the same 'dark-side' company called RedHat..
            Yes unfortunately, I deal with hundreds of servers RedHat too, unfortunately..

            Comment


            • #96
              [QUOTE=tuxd3v;n1052797]
              Of course they don't exist..._EXPLICITLY_,
              BUT they exist somewhere in the code, not in the exact same form, but happens to do the same thing, plus a lot more things that are avoidable.

              Originally posted by tuxd3v View Post
              Seems that you do not adapt Big Midleware Infraestructure products..to your operating systems..
              Some are systemd aware some are not. So no its not that I don't use Big Middleware infrastructure I would guess I would have a broader experience with it.

              Originally posted by tuxd3v View Post
              In that products, you do need to deal with some thousands of lines, could be bash, ksh,csh,perl,C or whaever, and in the majority of the cases you don't have that "binary thing"..that you have in desktops..
              Lot of the cases when you covert to systemd those thousands lines drop to less than 200 lines in service files. If you have never done the process of full conversion from script start up to systemd service files you don't understand the differences.

              Like you would not have done
              https://coreos.com/os/docs/latest/us...emd-units.html
              Setting up the environmental variables from the service files.

              Originally posted by tuxd3v View Post
              By the way, lots of that machines could be running AIX5,6,7, or Linux in a variety of forms, and arch's
              This most likely means you have not spend enough time researching the Linux kernel to understand how it different.

              Originally posted by tuxd3v View Post
              With systemd you need to create the script, them create the service, and only then, its the same as SysVinit...enabling the service.
              But even then you get always systemd messing with your stuff..
              Majority of the time if you have created a script with a systemd .service you have made a critical error.

              You should only have 1 service per unit/.service file. This is not about a systemd limitation. Each .service gets it own cgroup. The Linux kernel standard schedulers designed for servers in Linux depend on cgroups around your services. Yes a script inside a systemd .service file starting multi services starts you losing system performance like you lost when you were using SysVinit.

              Even under Sysvinit linux where you are falling back on autogroup(what is a system to attempt to auto assign cgroups) you don't want large multi service starting init scripts. Yes multi service init scripts don't cause trouble under AIX but they are a big thing you should avoid where you are running on a Linux kernel.

              If you read docker documnetation
              https://docs.docker.com/config/conta...ice_container/
              You will also see multi service per container are not recommended this is the same problem.

              Under the default Linux kernels in all server distributions cgroups are always messing with your stuff the question is do you have any control over it or understanding of the rules.

              Generally Linux kernel compatible sysvinit scripts should not be longer than 500 lines majority should be less than 200 lines. Systemd service files most should be less than 50 lines with no scripts straight up starting the required binaries.

              Just by correcting this stuff I have seen even with sysvinit 20 to 30 percent through put gains on particular workloads. This is why I am not anti systemd I know systemd like it or not used right gives you control over the cgroups system that will be messing with your performance anyhow.

              Now openrc need to be filled out more. But the many thousand of line start up scripts you see in a lot of middle ware needs to die its Linux incompatible crap.

              Also when a person says that for systemd to be the same as sysvinit it need to run a script means they have not read though the conditional options of service files or many other features. Once you cut a sysvinit file to what it should be it translates into .service files. Only reason why something does not translate to .service find most of the time is that you have multi things in your sysvinit files that you should not have. Features in sysvinit files that harm Linux performance.

              Comment


              • #97
                [QUOTE=oiaohm;n1053029]
                Originally posted by tuxd3v View Post
                Some are systemd aware some are not. So no its not that I don't use Big Middleware infrastructure I would guess I would have a broader experience with it.


                Lot of the cases when you covert to systemd those thousands lines drop to less than 200 lines in service files. If you have never done the process of full conversion from script start up to systemd service files you don't understand the differences.

                Like you would not have done
                https://coreos.com/os/docs/latest/us...emd-units.html
                Setting up the environmental variables from the service files.


                This most likely means you have not spend enough time researching the Linux kernel to understand how it different.
                Who told you that I was thinking that Linux Kernel is equal to Aix kernel..?

                You need to control the environments were you work..A zillion scripts plus a zillions service files in unmanageable.
                More over, majority of big products are NOT systemd aware, and I don't think that will change fast..

                For the sake of simplicity you should do it in one place only..systemd fails big here!
                It also fails when I want to look into the flow of the code..its compiled...what is there?A bank company should be happy with that?
                SysVinit by itself is ways more adaptable, open and less introsive..

                [QUOTE=oiaohm;n1053029]
                Originally posted by tuxd3v View Post
                Majority of the time if you have created a script with a systemd .service you have made a critical error.

                You should only have 1 service per unit/.service file. This is not about a systemd limitation. Each .service gets it own cgroup. The Linux kernel standard schedulers designed for servers in Linux depend on cgroups around your services. Yes a script inside a systemd .service file starting multi services starts you losing system performance like you lost when you were using SysVinit.

                Even under Sysvinit linux where you are falling back on autogroup(what is a system to attempt to auto assign cgroups) you don't want large multi service starting init scripts. Yes multi service init scripts don't cause trouble under AIX but they are a big thing you should avoid where you are running on a Linux kernel.

                If you read docker documentation
                https://docs.docker.com/config/conta...ice_container/
                You will also see multi service per container are not recommended this is the same problem.
                Who told you, that I do my scripting inside the systemd services..?

                You need to Follow protocol Rules, compliance's, that the majority of the products brake, and they know nothing about systemd..
                When you deal with Big products, you need to adapt,and when are errors you need to look into the Scripts...here is were SysVinit is great.
                And if I have to choose to only have one Script, why should I have: one script and a systemd service file...2 separated things..why?
                Plus the blackbox of compiled code..

                [QUOTE=oiaohm;n1053029]
                Originally posted by tuxd3v View Post
                Under the default Linux kernels in all server distributions cgroups are always messing with your stuff the question is do you have any control over it or understanding of the rules.
                One of the problems starts when RedHat tries to force systemd into free distributions, with a lot of damage to the Opensource world..
                A lot of interference from systemd, in the way the things work...pretending himself to be the Operating system...
                It should be only a init system, nothing more..
                systemd is a stone in the path of progress...it could be something a lot better, if RedHat was listening..

                [QUOTE=oiaohm;n1053029]
                Originally posted by tuxd3v View Post
                Generally Linux kernel compatible sysvinit scripts should not be longer than 500 lines majority should be less than 200 lines. Systemd service files most should be less than 50 lines with no scripts straight up starting the required binaries.

                Just by correcting this stuff I have seen even with SysVinit 20 to 30 percent through put gains on particular workloads. This is why I am not anti systemd I know systemd like it or not used right gives you control over the cgroups system that will be messing with your performance anyhow.
                You can't dictate the size of a Script...
                Some company by a product, and its what it is..you need to adapt..

                You are too much focused in one reality, the containers world..probably applications which have 1 binary, and less dependencies than some other people..
                And because of that, you think systemd is the Saint Grall.

                I am not against systemd...
                let those guys do what they want, _inside their own garden_,
                BUT they should not interfere in the Opensource world, in the way RedHat has been doing for quite some time..

                And if you look around, you will see that nobody is against systemd( providing that it doesn't get in their paths ).
                The problem is the interference, that systemd causes, and the vendor-lock-in introduces..

                [QUOTE=oiaohm;n1053029]
                Originally posted by tuxd3v View Post
                Now openrc need to be filled out more. But the many thousand of line start up scripts you see in a lot of middle ware needs to die its Linux incompatible crap.

                Also when a person says that for systemd to be the same as sysvinit it need to run a script means they have not read though the conditional options of service files or many other features. Once you cut a sysvinit file to what it should be it translates into .service files. Only reason why something does not translate to .service find most of the time is that you have multi things in your sysvinit files that you should not have. Features in sysvinit files that harm Linux performance.
                I agree, that lots of the products need to change..but that thousands of lines you see..."they are not there, just for fun.."
                In majority of cases, they are their for compatibility reasons..you can't take them from their not even in 10 years

                You can do a lot with systemd...but you can also do it without it...so its some sort of "undesirable gift", for some people.

                New product started from zero,
                Yes they should be adapted in a way that make life easier, but at same time, don't depend too much from a init system( portability )..

                But any one "should pick you poison.."


                Comment


                • #98
                  Originally posted by tuxd3v View Post
                  You need to control the environments were you work..A zillion scripts plus a zillions service files in unmanageable.
                  More over, majority of big products are NOT systemd aware, and I don't think that will change fast..
                  Really I have found that lot of big products have over init files that if you submit a bug they will fix.

                  Originally posted by tuxd3v View Post
                  For the sake of simplicity you should do it in one place only..systemd fails big here!
                  It also fails when I want to look into the flow of the code..its compiled...what is there?A bank company should be happy with that?
                  SysVinit by itself is ways more adaptable, open and less introsive..
                  Problem here sysvinit was not built for the Linux kernel. Places like facebook build their own systemd.

                  By the way your shell is also a C based binary blob running you sysvinit script do you bother checking that? You will find out auditing the shell you use is way more complex than auditing the systemd ini/service file processing system and does less.

                  Basically don't ignore the elephant in the room. This is what people do when they say shell scripts are auditable. The reality if it audited you need to have audited from top to bottom. So that is the shell that runs you init scripts in sysvinit has to be inspected as well to make sure code flow will go where it meant to.

                  Sorry I have done work with banks. Yes they insist that everything is audited. That when you wake up just auditing scripts is not enough.

                  Originally posted by tuxd3v View Post
                  You need to Follow protocol Rules, compliance's, that the majority of the products brake, and they know nothing about systemd..
                  When you deal with Big products, you need to adapt,and when are errors you need to look into the Scripts...here is were SysVinit is great.
                  And if I have to choose to only have one Script, why should I have: one script and a systemd service file...2 separated things..why?
                  Plus the blackbox of compiled code..
                  Service file is placing predictable cgroup around your service. Instead of depending on Linux kernel random luck with the CFS group scheduling.

                  The code is not blackbox on debian and other distributions that has reproducible builds. So maybe now you have to have some skill in C and be able to read and in fact audit the start up correctly. Not get away with doing a half job.

                  Originally posted by tuxd3v View Post
                  You can't dictate the size of a Script...
                  Some company by a product, and its what it is..you need to adapt..
                  Sorry you can dictate the size of the script. What it means is you have to submit issue with supplier and be about bench the problems.

                  Originally posted by tuxd3v View Post
                  You are too much focused in one reality, the containers world..probably applications which have 1 binary, and less dependencies than some other people..
                  This is not it. The problem first started appearing in 2007 with the introduction of CFS group scheduling.

                  Originally posted by tuxd3v View Post
                  I agree, that lots of the products need to change..but that thousands of lines you see..."they are not there, just for fun.."
                  In majority of cases, they are their for compatibility reasons..you can't take them from their not even in 10 years
                  Majority of the reason why those massive sysvinit files are in /etc/init.d is
                  1) People you don't bench it. So don't see that the file split into multi service files in fact performs better even in sysvinit.
                  2) The first init file was written before 2007 when it was common to start as much as possible in a single file.
                  3) No one has complained to get it rewritten correctly.

                  Yes we are over 10 years in yet people like you still let these application ship you broken init setups that don't in fact work properly on current Linux kernels. \

                  Lets be blunt most of those massive messes of scripts still exist because customers have administrators that are pure incompetent or over worked.

                  Originally posted by tuxd3v View Post
                  New product started from zero,
                  Yes they should be adapted in a way that make life easier, but at same time, don't depend too much from a init system( portability )..
                  If you want performance portability is the least of your problems. Your performances are linked very much to having the tools to control the kernel you are running on. The big thing systemd gives you over sysvinit is proper control over the information the Linux kernel need for CFS and other parts to perform properly.

                  Sysvinit has to die it was based off the ideas of sysv not how the Linux kernel is in fact implemented. Openrc is a maybe because it could be extend to set the information the Linux kernel needs.

                  Comment


                  • #99
                    Originally posted by oiaohm View Post
                    Really I have found that lot of big products have over init files that if you submit a bug they will fix.
                    Really?
                    That is not the way it works..
                    They will not change a product because you ask them too..sure in the OpenSource world, there are tendency to change things at request...
                    But not Big Products, that is a massive pile of work to do that..
                    Sure they can change,with that, they redesigned their entire application stack,and there are the risk factor here...years of development and so on..
                    but you need to show them your "Big Wallet", then, they provide the product to other company's at zero plus cost...

                    In OpenSource Applications you can do that, in a better way, because everybody gets the improvements , but in closed source no way..
                    How can you then, be competitive in the Market?

                    Originally posted by oiaohm View Post
                    Problem here sysvinit was not built for the Linux kernel. Places like facebook build their own systemd.
                    Places like Facebook are shit Chat companies, with zero value...
                    And you continue to be focused on that type of companies, with ZERO real value...

                    Originally posted by oiaohm View Post
                    By the way your shell is also a C based binary blob running you sysvinit script do you bother checking that? You will find out auditing the shell you use is way more complex than auditing the systemd ini/service file processing system and does less.
                    Hummm...I don't think so...
                    Even more when lots of user-space tools are provided under the respectful GNU Umbrella..

                    And please don't compare, GNU with RedHat bad reputation, they are in opposed poles..
                    Its almost a Sacrilege..

                    Originally posted by oiaohm View Post
                    Basically don't ignore the elephant in the room. This is what people do when they say shell scripts are auditable. The reality if it audited you need to have audited from top to bottom. So that is the shell that runs you init scripts in sysvinit has to be inspected as well to make sure code flow will go where it meant to.

                    Sorry I have done work with banks. Yes they insist that everything is audited. That when you wake up just auditing scripts is not enough.
                    I use to work in places were that happens!
                    Sysadmin is responsible only for its tasks, OS is audited by Security Teams directly..
                    I don't even install a image, that was not authorised by the Security Team...

                    But that happens in some places,
                    The majority of places don't have the resources to do that, and so they install what comes in the downloaded image...its a blackbox.
                    It is always difficult because there are tons of compiled code...

                    2 wrongs don't make one right..
                    A init system, seems to me, too much important to be running in compiled code Sincerely..its easier in editable( interpreted ) code.

                    Originally posted by oiaohm View Post
                    Service file is placing predictable cgroup around your service. Instead of depending on Linux kernel random luck with the CFS group scheduling.

                    The code is not blackbox on debian and other distributions that has reproducible builds. So maybe now you have to have some skill in C and be able to read and in fact audit the start up correctly. Not get away with doing a half job.
                    Again...
                    You continue too much Focused in Containers..!
                    Yes cgroups in contaires is a must...

                    BUT there are tons of places were the OS runs only a application user, cgroups has almost ZERO impact here.
                    Because OS is minimal, the user that will be using the system will be the Application User, forget cgroups in this places...
                    Sure you tune, but is has minimal impact here.

                    You can only use debian in some places, not everywhere, and systemd comes from RedHat..
                    debian has we saw, is not independent like it was in the past...now RedHat seems to rule in debian, which by its turns, turns the best OS, in something very inferior.

                    Best Debian ever was version 7, SysVinit based very fast,low resources, very stable.

                    Originally posted by oiaohm View Post
                    Sorry you can dictate the size of the script. What it means is you have to submit issue with supplier and be about bench the problems.
                    Like I said..in places with Minimal OS, and a user...forget cgroups...
                    in containers, or in places were you have lots of users, yes ofcourse..

                    Sometimes submitting issues, don't solve a application architectural diference..
                    Application will continue like it his, no one will change it.. because that means years of development and test.

                    Big money and time, resuming..

                    Originally posted by oiaohm View Post
                    This is not it. The problem first started appearing in 2007 with the introduction of CFS group scheduling.

                    Majority of the reason why those massive sysvinit files are in /etc/init.d is
                    1) People you don't bench it. So don't see that the file split into multi service files in fact performs better even in sysvinit.
                    2) The first init file was written before 2007 when it was common to start as much as possible in a single file.
                    3) No one has complained to get it rewritten correctly.

                    Yes we are over 10 years in yet people like you still let these application ship you broken init setups that don't in fact work properly on current Linux kernels. \

                    Lets be blunt most of those massive messes of scripts still exist because customers have administrators that are pure incompetent or over worked.
                    They are only Broken Setups, in your mind..
                    Each one should speak by itself..
                    SysAdmin can do only the best it can to adapt things..it cannot rewrite the entire stack application...that's crazy.
                    Also the Application to be adapted could have to suffer big changes, and maybe that company is not very pleased to that..

                    The fact that, you have multiple scripts, don't per-sé, turns the application faster....
                    For it, you need parallelism, but if one part depends on the other...this type of parallelism cannot scale..

                    I like only one Script per service...config in one place, no mess around, no Buggy scripts + service things..one thing to rule them all..CLEAN.
                    And you can always launch things in parallel, without having multiple scripts or service + scripts, what systemd have, I call it a MESS..

                    But here depends..
                    I have also saw lots of craziest things..made by SysAdmins too, to be honest that things makes me upset!
                    Because you will have to try to improve it..
                    And by that, would mean that you would have to convince clients, mesure the risk, convince Security Teams, convince your bosses, and so on...and after that...
                    You can make a draft, then will be exposed to all entities involved, and it will be approved or not..
                    So its lots of work, to correct one bad thing..and a lots of times is rejected because of the risk factor, or because the way the security teams have though the security is not compatible..

                    I am not talking about fake companies like Facebook, that they say the companys value is tremendous, but that is only in WallStreet..
                    No reputation, no credibility, no value as a trade mark, all is imaginary..no serious business there..
                    And in this Companies business it could make a lot of sense,because of the amount of parallelism, containers, or access times for zillion users..

                    That is not the case with the majority of companies, but all tend to massively change, I also see that in some companies..

                    You don't change the OS image because you want too, here, it depends on the company, and so on..
                    Lots of places only allow you to change the image when they want/or Client want..
                    There are down times, adjust, Hardings to be done( Above initial Harding made by Security Teams when they build the image first time), and this all costs money, and above all Reputation...
                    Moreover, in some countries...downtime...you pay it with big money...
                    YES there are countries where the Legislation don't allow you to have DownTime( depending on the business ), or you will be sued by State Organisms..

                    you don't dictate nothing here, "its not like disneyland.."
                    If you are in a Real Company, you will play with lots of obstacles, its not like when you run websites..that you can shutoff one server in the backend, and maybe only the sessions there suffers..and you change what you want..

                    This is a complex factor, and will not change at once...will be changing with time..
                    Also some changes that come to the Linux kernel, do not favor the work this Real Companies do, only the work that the people are working there submit..

                    We cannot blame SysVinit, because of cgroups, an example is the embedded world, you could be running only one app.
                    In lots of spaces, cgroups don't actually translate in something important..when you run a OS minimal and a user..

                    Originally posted by oiaohm View Post
                    If you want performance portability is the least of your problems. Your performances are linked very much to having the tools to control the kernel you are running on. The big thing systemd gives you over sysvinit is proper control over the information the Linux kernel need for CFS and other parts to perform properly.

                    Sysvinit has to die it was based off the ideas of sysv not how the Linux kernel is in fact implemented. Openrc is a maybe because it could be extend to set the information the Linux kernel needs.
                    SysVniit will not die, because it his needed in lots of places..
                    It will reduce its share, but not die..

                    I don't see systemd, after 10 years more.. its a stone in the path of progress, to much interference in other areas that should not do, and so on..
                    But I also acknowledge that something have to come up, that restrain systemd, to a init system, and takes what is best from sysvinit, with already developed ideias and formats...do not reinvent the wheel..

                    Comment


                    • Originally posted by tuxd3v View Post
                      Really?
                      That is not the way it works..
                      They will not change a product because you ask them too..sure in the OpenSource world, there are tendency to change things at request...
                      But not Big Products, that is a massive pile of work to do that..
                      Really maybe you have not been in companies pay half a million dollars+ a year on a support contract on a big product support contract.

                      Its suprisng how fast they move when you mention performance and that it may cause you to look at competitors..

                      Originally posted by tuxd3v View Post
                      Sure they can change,with that, they redesigned their entire application stack,and there are the risk factor here...years of development and so on.. but you need to show them your "Big Wallet", then, they provide the product to other company's at zero plus cost...
                      Most of reordering the init process does not have large risk factors. Improves performance a lot.

                      Originally posted by tuxd3v View Post
                      Like I said..in places with Minimal OS, and a user...forget cgroups...
                      in containers, or in places were you have lots of users, yes ofcourse..
                      This is wrong. A lot of IOT is find cgroups critical.
                      cgroups put proper tracking around you minimal OS so when something crashes it can be properly watchdog and restarted. Even minimal OS and user using Linux not using cgroups causes you trouble.

                      Originally posted by tuxd3v View Post
                      SysVniit will not die, because it his needed in lots of places..
                      It will reduce its share, but not die..
                      There is no question SysVinit need to completely die or grow cgroup support. Using PID and other things for track services is bug prone.

                      Originally posted by tuxd3v View Post
                      I don't see systemd, after 10 years more.. its a stone in the path of progress, to much interference in other areas that should not do, and so on.. But I also acknowledge that something have to come up, that restrain systemd, to a init system, and takes what is best from sysvinit, with already developed ideias and formats...do not reinvent the wheel..
                      Really I see keeping sysvinit alive as just taken resources away from what should be going into making openrc fully functional.

                      You what you service init system using tracking around services that truly do track if they are up or not.

                      If you don't like how systemd works. You still need a init service system that has cgroup support on Linux so you always have proper tracking.

                      Linux recycling PID numbers and break away processes means without using cgroups you have incorrect tracking on what your services are upto.

                      Yes you get performance by having control over cgroups. I find performance issues get better response that we had to reboot the complete server because some service part lost. For some reason even when you are paying half a million+ on a product having to reboot server to restart their product is classed as acceptable. Yet they get upset when you can document a 10 to 20 percent performance problem and then fix it. Both are the same problem.

                      The reality here with the Linux kernel cgroups is critical to anything needing reliability so that you can watchdog it correctly and when you shut a service down you know some random fragment of the service is not running somewhere. If there is some random fragment of a service still running it can preventing you from restarting that service.

                      Cgroups give many advantages once you get use to having them not having them comes a major problem.

                      Basically those arguing for sysvinit mostly don't get they are unable to deliver the same level of dependability those using solutions based on cgroups can on the Linux kernel. Sysvinit no matter where you look is a noncompetitive solution because the issues around not tracking your services leading to not being able to restart services and performance issues make it useless.

                      Of course I am not saying people cannot hate systemd. That fine. But make sure you are investing time into a solution who design contain support for cgroups so that long term you have something that is competitive on dependability.

                      Comment

                      Working...
                      X