Announcement

Collapse
No announcement yet.

systemd Breached One Million Lines Of Code In 2017

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

  • Originally posted by aht0 View Post
    You sound like Pawlerson's second or third account, so it makes you pointless troll to waste time on. Just insults.

    Claim that intentional design nuances rendering software unusable to a certain segment of end users is not "design issue" is ludicrous.
    https://github.com/systemd/systemd/issues/5771

    The reality here is once you have sent resolved configuration files to have a DNS the "FallbackDNS" is not used unless there is a bug in systemd. This bug is a person asking for the behaviour you are talking about and being refused. So /etc/resolved.conf existing with entries automatically kills built in FallbackDNS entry even a stupid entry like 0.0.0.0 will prevent FallbackDNS built in being used.

    There are complains that resolved cycles too fast though the resolved.conf list.
    https://github.com/systemd/systemd/issues/5755.

    But the logs show everything functional as expected. Sometimes as the person here does you need to run a proper dns cache. Dnsmasq is a local cache.

    A dns resolve not a DNS cache. The DNS resolver built in libc behaves no better in fact worse.

    aht0 just because something appears random does not mean it is. From all those who have in fact looked at their logs no one has found it a random problem coming from the way resolved does things but from issues with the DNS server the system is dealing with. Yes some routers are known for being under powered and causing these issues and some cases with VPN having time out problems so it does what its meant to moving on to the next DNS server in the lookup list.

    If your problem requires dns cache and dns cache intelligence attempt to use systemd-resolved will give you problems because it the wrong tool for the job. Maybe someone might put in a feature request for systemd-resolved to add the features of dnsmasq with domain being direct-able to particular DNS servers and caching so that unstable dns servers get less requests basically grow DNS cache functionality.

    Comment


    • At last some reasonable argument, rather than bashing.

      And if systemd-resolved thinks for some reason that all the configured DNS servers are down (while all are actually up and functioning) then what..? FallbackDNS. Correct?

      Comment


      • Originally posted by aht0 View Post
        At last some reasonable argument, rather than bashing.
        And if systemd-resolved thinks for some reason that all the configured DNS servers are down (while all are actually up and functioning) then what..? FallbackDNS. Correct?
        Not all because once a /etc/resolved.conf exists even if contains non working entries FallbackDNS option is disabled. No configuration file attempts Fallback so basics can work. Invalid configuration file fails to function at all.
        https://github.com/systemd/systemd/issues/5771
        Bug 5771 was asking why when they had resolved configured and none of the DNS servers were working why FallbackDNS option was not used.

        The reality FallbackDNS is disabled as soon as systemd-resolved has valid configuration file/s. Only reasons why systemd-resolved will be using FallbackDNS is you don't have configuration file/s or your configuration file/s are invalid either way fix your configuration. Configuration issue is the only reason why FallbackDNS is activated.

        So you point about FallbackDNS was making absolute no sense as that is not how systemd-resolved operates. Of course anyone who knows how systemd-resolved operates would normally think you are clueless trolling.

        Do note I said garbage like dns address 0.0.0.0 in the resolved.conf is enough to turn FallbackDNS off. So looks at a resolved.conf finds addresses in file in correct format be them existing dns servers or not FallbackDNS feature is off at that point.

        There are a lot of bogus defect claims around systemd. It does pay to go read the issue list carefully before thinking you have a real issue.

        Comment


        • Originally posted by oiaohm View Post
          Not all because once a /etc/resolved.conf exists even if contains non working entries FallbackDNS option is disabled. No configuration file attempts Fallback so basics can work. Invalid configuration file fails to function at all.
          https://github.com/systemd/systemd/issues/5771

          Bug 5771 was asking why when they had resolved configured and none of the DNS servers were working why FallbackDNS option was not used.

          The reality FallbackDNS is disabled as soon as systemd-resolved has valid configuration file/s. Only reasons why systemd-resolved will be using FallbackDNS is you don't have configuration file/s or your configuration file/s are invalid either way fix your configuration. Configuration issue is the only reason why FallbackDNS is activated.
          Thanks for clearing the bit. My own experience to systemd is limited to OpenSUSE and even then it's more than year old - when I actually dug deeper into systemd in it. I prefer to avoid that thing at all costs now for multiple reasons, which are not all "ideological".
          Originally posted by oiaohm View Post
          So you point about FallbackDNS was making absolute no sense as that is not how systemd-resolved operates. Of course anyone who knows how systemd-resolved operates would normally think you are clueless trolling.

          Do note I said garbage like dns address 0.0.0.0 in the resolved.conf is enough to turn FallbackDNS off. So looks at a resolved.conf finds addresses in file in correct format be them existing dns servers or not FallbackDNS feature is off at that point.

          There are a lot of bogus defect claims around systemd. It does pay to go read the issue list carefully before thinking you have a real issue.
          I am not so sure rest of the "idelogical pro-systemd crowd" here had any better clue about it's exact operating principles or I would have received particulars exactly how you did post them way earlier, not just multiple repeated "you are an incompetent idiot" followed by more-or-less-silence after I presented the list of issues as I saw 'em.

          You are correct about trolling though. Successful politicians have discovered that they do tend to have most effect while speaking to people in the language they use and are used to.
          For example: No point using Londoner accent and quoting Shelley while talking to bunch of Scottish dockworkers. You'd have to speak their own brogue in order to "get through".
          You may extrapolate that to internet forums. When your opponents are doing nothing but trolling, there is no real point trying to start anything intellectual. So I would troll the trolls back and throw in some "bone" time-to-time trying to see, if anyone actually knows anything about subject matter itself. It's win-win either way. At worst it annoys the trolls, at best I and whoever else may read it, may read and learn something useful in the end. Thank you.

          I am BSD guy, so your assumption is correct. I have very little use or need for systemd. Like set of titties on a boar hog. While I think Linux had need for some of it's functionalities, it's implementations could have be better thought out and executed with less feature creep. But also as I said, my experience with it is by now dated. I'll just install OpenSUSE now and then, see how it does cause issues to end user sometimes OTB (you cannot accuse end user in configuration errors in this particular case): does not make me want to educate myself more about it.
          Last edited by aht0; 01-08-2018, 02:27 PM.

          Comment


          • Originally posted by aht0 View Post
            At last some reasonable argument, rather than bashing.
            Uhm, you came in here like "zomg systemd is the sucks and it ate my dns because of bugz devuan rules??" like all the other braindead anti-systemd lunatics. You also claimed Lennart Poettering was evil, so why on earth would you not be bashed? The guy above here had the patience to spoon-feed you, but really that's kind of your job if you wanna do complex VPN setups? Like I said, you are an idiot because you are bashing free open source software for absolutely no reason other than your own incompetence.

            Perhaps try creating a thread somewhere titled "Hey everybody, I'm a complete noob could someone help me work out systemd-resolved?" and you might actually get somewhere.

            Comment


            • Originally posted by arokh View Post
              Uhm, you came in here like "zomg systemd is the sucks and it ate my dns because of bugz devuan rules??" like all the other braindead anti-systemd lunatics.
              Please point out the particular quote where I wrote this

              It's you who went "zomg you don't like systemd, learn to use it stupid". Idiot texts deserve idiot answers, or your meager intelligence might be unable to grasp the meaning.
              Originally posted by arokh View Post
              You also claimed Lennart Poettering was evil, so why on earth would you not be bashed?
              It was pal666 on page 4 I believe and even there in a sarcastic manner. I choose not to participate in the verbal brawl before page 7. Also I avoid using words like "evil" - it's meaningless. It first assumes that target of this statement is sharing your own moral values (especially meaningless when applied to artificial constructs like companies) and that he or she is violating them with malicious intent.

              Please again, point out where I specifically stated THAT. The only mention I did about Poettering was following.
              Despite RFC's Poettering keeps pointing at and closing the requests for a change in behaviour.
              At the very moment it's YOU making fool of yourself. He had the knowledge to "spoon-fed" - you did not have anything besides typing skills for throwing insults against people violating your ideologic bias. Maybe I should use simpler words, based on how you seem to ignore some of what I wrote, you have rather limited vocabulary.

              Originally posted by arokh View Post
              The guy above here had the patience to spoon-feed you, but really that's kind of your job if you wanna do complex VPN setups? Like I said, you are an idiot because you are bashing free open source software for absolutely no reason other than your own incompetence.
              I never claimed I did want to make complex VPN setups. Some dudes, boldly went along the lines that "if I wanted to use VPN for illegal file sharing.." I never claimed that either. VPN is actually something which has myriad of legitimate uses, like connecting between company offices in geographically different sites, accessing your office from public internet and so forth..

              In reality, some dude here had trouble with systemd sending DNS queries meant for VPN through public DNS (or something like this), I just supported him, because he was verbally torn to shreds. I already mentioned it at least once before. Had you bothered to actually READ - or asked help for reading the parts you cannot comprehend, you would not have made yourself look like ideologic nut case yet again.
              Last edited by aht0; 01-08-2018, 04:35 PM.

              Comment


              • Originally posted by aht0 View Post
                In reality, some dude here had trouble with systemd sending DNS queries meant for VPN through public DNS (or something like this), I just supported him, because he was verbally torn to shreds. I already mentioned it at least once before. Had you bothered to actually READ - or asked help for reading the parts you cannot comprehend, you would not have made yourself look like ideologic nut case yet again.
                https://github.com/systemd/systemd/issues/7182

                Did you bother reading to end of the issue you use the answer is on on dec 9 2017 poettering gives a valid answer.Well before your post.

                Of course being foolish you were not aware freebsd, openbsd, glibc resolver, windows resolver.... will all do the same screw up. When using a vpn and you want all dns traffic to go by vpn you have to declare vpn dns servers as being domain
                .
                Yes single full stop this is not much of a configuration error. It is a universal configuration error mistake does not matter if you are using OS X, Windows, FreeBSD, OpenBSD, Solaris, LInux running sysvinit, Linux running some random init or Linux running systemd.

                So problem was really nothing systemd particular. There are sites to check if you are leaking to public dns servers due to how often people stuff up resolver settings. Its not like systemd-resolved is doing anything wrong is doing exactly what the configuration file told it to-do. You use a different resover note that /etc/resolve.conf is a standardised configuration across Linux/BSD/Unix including the using of . in the search configuration to push all requests into that DNS server/servers.

                So maybe this is a issue with /etc/resolve.conf .

                It was another case just because systemd is new it has to be the problem. Its not because I don't know what I am doing and have configured it wrong this happens a lot. Then you have trolls saying go to sysvinit or bsd this will fix the problem when in reality it will change nothing because they will do the same exact problem there as well.

                When someone is pointing to a RFC something could be cross platform standard behaviour with logical reasons why it the way it is. Changing standards is not a easy process..

                Just because you set up a VPN does not mean you want to sent all traffic though the vpn. So who is more important the person who only want limited list of domains over a vpn or those who want all or those who have set up a vpn who want no internet traffic at all over the vpn.

                I have vpn into locations to get logs and ssh into servers to repair stuff I don't need internet DNS resolve going that way either. Setting up a VPN is not straight forwards there are multi different configurations required. Why items like openvpn allow scripting to allow it to be customised to its usage case.

                After you have worked support for a while you understand you get those people who are I want it does X way I don't care if that will badly effect people who need it Y and Z way and I don't want to have to configure it so I can have it X way and I don't want to read that it standard. Those people are basically jerks who are never going to be happy no matter what you do. So you end up ignoring them and closing there bugs.

                So systemd did not make all the issues users run into. Many are decades old requirements to configure stuff yet some how systemd gets blamed for this. Yes systemd has enough real issues it did make without blaming issues on it that are just standard required things to configure.

                Comment


                • Originally posted by oiaohm View Post
                  https://github.com/systemd/systemd/issues/7182
                  Did you bother reading to end of the issue you use the answer is on on dec 9 2017 poettering gives a valid answer.
                  Did you notice the exact status of the issue? He may have explained how it should work but left the status "Open" not "Closed". Which means, issue is still open and not resolved. Which is why I chose to "not read" it.

                  Originally posted by oiaohm View Post
                  So problem was really nothing systemd particular. There are sites to check if you are leaking to public dns servers due to how often people stuff up resolver settings. Its not like systemd-resolved is doing anything wrong is doing exactly what the configuration file told it to-do. You use a different resover note that /etc/resolve.conf is a standardised configuration across Linux/BSD/Unix including the using of . in the search configuration to push all requests into that DNS server/servers.

                  (1)So maybe this is a issue with /etc/resolve.conf .

                  It was another case just because systemd is new it has to be the problem. Its not because I don't know what I am doing and have configured it wrong this happens a lot. (2) Then you have trolls saying go to sysvinit or bsd this will fix the problem when in reality it will change nothing because they will do the same exact problem there as well.
                  (1) Well, let's assume so.
                  (2) Not precisely so. No chance for race condition.
                  Last edited by aht0; 01-09-2018, 04:39 AM.

                  Comment


                  • Originally posted by aht0 View Post
                    Did you notice the exact status of the issue? He may have explained how it should work but left the status "Open" not "Closed". Which means, issue is still open and not resolved. Which is why I chose to "not read" it.
                    That is the problem.
                    https://github.com/systemd/systemd/issues/7777
                    Notice with issue 7777 it has "needs-patch" label so is confirmed as have a real problem problem.
                    https://github.com/systemd/systemd/issues/7182
                    Notice 7182 that you have based stuff on only label is that is related to resolve. So its not confirmed as a real problem.

                    Hmm, can you please provide "systemd-resolve --status" for your system?
                    When you read the last entry on 7182 the person doing bug triage has asked a question that has not been answered yet to absolute confirm if it a configuration error. If it is an configuration error it not a software bug. Of course it still could be a documentation bug.

                    This is something about systemd that bugs stay open longer because they care equally about the documentation as well as the code so they do direct bugs down two paths.

                    Originally posted by aht0 View Post
                    (1) Well, let's assume so.
                    (2) Not precisely so. No chance for race condition.
                    Race conditions have happened with glibc resolver. This would be why there is the question about exact configuration before closing.

                    Highest probability is that there is nothing in fact wrong other than possibly documentation not being clear enough with 7182.

                    In 7182 there were notes about network manager doing wrong configuration so causing systemd-resolved to do wrong things and any other resolver with network manger would have had the same problems.

                    Yes openvpn race condition with /etc/resolv.conf that predate systemd is why https://github.com/jonathanio/update-systemd-resolved add-on script for openvpn was created.

                    Interesting enough the /etc/resolv.conf race condition effects OS X, BSD and solaris as well. So the race condition is not systemd particular.

                    One of the reasons for using systemd-resolved over what was using in sysvinit systems is to in fact avoid a race condition when resolve information changes. Yes what was normally uses what the glibc resolver what was reload config by reloading all applications running with the old settings so start VPN and you could have applications using vpn and not using vpn under an older sysvinit distributions no matter how you did it with default system parts.

                    aht0 basically picking up issues and attempting to use them for a point without read and understanding is a very fast way to make a mistake like you did and pick up a bug that reported to project that turns out not to be that project issue. This one openvpn the way it registers DNS is a little questionable, network manager has had a issue and the user could have manually stuffed the configuration up. Worst the configuration stuff up is generic mistake.

                    Something else if a project it waiting for a third party project to fix something this can be a reason for them to keep a bug open to remind them to go bug the third party project again in future. So open bugs don't always equal faults in that project. This case it was 2 other projects with problems 1 project is fixed being network manager but openvpn still has issues and the openvpn issues don't just effect systemd systems.

                    Comment


                    • Originally posted by hussam View Post
                      Less lines of code don't mean faster/more performant/leaner/better quality code either.
                      The main systemd daemon uses half the memory it did in 2014.
                      Yes it does. It is well known that there are a constant amount of bugs in lines of code. If you have 1000 lines, you have say, 10 bugs. If you manage to compress it to 100 lines, you have 1 bug instead. A skilled developer writes less code than a newbie. When I started to develop, my code was really verbose, and a senior skilled programmer was always able to rewrite it and discard half of my code. There is a famous story where developers at Apple(?) had to report how much code they produced each day. And the star programmer (Steve Wozniak?) spent a day with refactoring the code and deleted 18.000 lines. So he reported "-18.000 lines of code".

                      If you have two code bases doing the same thing, one code base uses 10.000 LoC and the other use 2.000 LoC - guess which code base that probably is more well written and has fewer bugs? Bad developers write lot of code. Skilled developers write small amounts of code.

                      Comment

                      Working...
                      X