Announcement

Collapse
No announcement yet.

systemd Clocks In At More Than 1.2 Million Lines

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

  • Originally posted by oiaohm View Post
    This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

    Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

    Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.
    Look, you're digging a deeper hole in which to bury yourself. Linux was and is a kernel. The other stuff is fluff.
    Unix/UNIX/SYSV and then BSD was kernel plus userland binaries, ALWAYS.


    Originally posted by oiaohm View Post
    No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making upBSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.
    Again, what the hell are you talking about? "self hosting"? "1 single project"? This is just plain gibberish.

    I've been using *BSD since 386BSD with my first exposure being Unix/BSD on Pyramids, I've seen the history unfold. I remember loading tapes of the thing.

    You're talking nonsense.

    The kernel has always been the kernel. Your attempt to obfuscate your argument into one of "the kernel" equals "the project" is just plain desperation.

    If I can recall correctly, the original BSDs had a /src directory rather than a /sys but apart from that little has changed in structure, even across multiple branches, though I do admit not using openbsd at all.


    Originally posted by oiaohm View Post
    Exactly the double standard much.

    People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.

    BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.
    Again, you're talking nonsense.

    Just to make it clear, you're totally wrong. Absolutely.

    You're also wrong, as is this topic, in comparing lines of code to some sort of metric of efficiency or waste. It's neither. It's a failed metric that means nothing apart from a meaningless comparison of lines. It's akin to measuring lines in a book and considering their worth based on that fact. Utter nonsense and long discredited by anyone who deals with large projects.

    That's why I originally wrote that this article posted by Michael seems to be an attempt to draw out the trolls and ignoramuses. Mission accomplished.

    Going back to your original accusation:
    FreeBSD devd when you get the project its from is quite a monster.
    https://github.com/freebsd/freebsd/t...ster/sbin/devd
    Yes devd is in the Freebsd project that happens to include everything you need to boot the system from the kernel to bootloaders to file system validation tools.

    If you are suggesting Linux copies how FreeBSD does it you are in fact suggesting merging systemd into the Linux kernel tree.
    You are clearly wrong. devd is a userland utility it is not part of the kernel.
    But rather than accept your error, you continue with this fantasy.
    So, continue believing BSDs are a kernel with all the userland included (nonsensical argument by virtue of the name 'userland', but hey, that's the depth of your argument).


    I'm done conversing with you. I can argue points with logical beings but no matter how hard I try, this would not occur with you.

    Comment


    • Originally posted by tildearrow View Post

      50 to 18. I switched to systemd in my Arch install now, and I can finally:

      - Mount my disks without root (Artix can't do this)
      - Power off from the desktop (without logging out)
      I believe you could do either from Artix too. Polkit & udisks/udisks2 for the former, systemd-logind & polkit for the latter (Edit: somehow escaped me that you initially didn't use systemd. In that case polkit/upower combo would probably work, it does for me in BSD. Combined with doas but you could replace it with sudo and give your user shutdown/reboot rights. Should enable powering off from desktop)
      Last edited by aht0; 05-23-2019, 11:22 PM.

      Comment


      • Originally posted by aht0 View Post
        Frankly, does not look like a situation I should meet more often than winning a million in lottery. Unless there is gazillion processes, software isn't quite stable and/or I somehow try to mass-kill many processes at once. Is the latter reason causing timeouts when trying to shut down systemd Linux machine? I remember it completely baffled me when I used OpenSUSE awhile a go - boot was actually fine but something during shutdown ALWAYS timed out..
        Those timeouts that systemd does on shutdown is not a defect in systemd.

        The cause of why systemd does timeouts on shutdown and service stop/restart is that it detects due to cgroups that processes are still running. So systemd runs the stop command on a service on shutdown then checks if all processes owning to that service have in fact stopped if not it waits after X amount time it brute force kills it.

        Lets look how sysvinit and the like handle it.
        On shutdown.
        1) sends all the services running stop in order of the kill number.
        2) After all services have been sent stop run a killall to clean house.
        Please note if the last process to get a stop order next operation is the killall by sysvinit there basically no delay between killall clean up coming. Systemd changes this to a predictable delay. Yes this is one of the cause how sysvinit at times screwed over databases delayed by IO for some reason to be killed before final writes were done due to no delay.

        Next is kind of worse.
        You attempt a sysvinit service restart and the service fails to restart. There is a leaked process holding something the service needs to restart. Yes systemd by systemctl doing a restart on something like this you would see a timeout as well and the service be successfully restarted.

        Basically systemd using normal sysvinit scripts if you are seeing timeouts you sysvinit scripts have a defect that needs fixing.

        Systemd turns what was a silent failure on shutdown with sysvinit into a loud message making failure with those timeout messages. That failure does not just effect the services with that problem at shutdown it also effect those services when ever you wish to restart them.

        This is some of the problem. People complain about the shutdown timeout issue of systemd without think maybe systemd is right here might pay to research why. Systemd shutdown timeouts is point you to broken init scripts.

        For the complete time I run systemd I have not had a single shutdown timeout but my init scripts had been audited well before using PID namespaces for process leakage. Process leakage has been insanely common defect causing random issues well before systemd existance.

        Systemd timeout messages on shutdown are just symptom of non systemd defects. Yes defects that sysvinit would silent hide until the day it catches you where you end up reboot a server instead of just restarting a service because a service will not restart.

        Yes these messes is why I say systemd is the init system we had to have. One of the results of systemd was a lot of sysvinit scripts in fact got fixed or deprecated with a systemd unit file that is also fixed.

        Comment


        • Originally posted by tildearrow

          What if the user has no smartphone or another computer to be able to Google? (remember that his computer is borked and can't connect to Internet)
          Sure, let's play the mitigating game. We can come up with ever increasing silly scenarios and how we get out of them.

          This user had access to install media - so they could have live booted it, done the google search and fixed their problem.

          Not knowing is fine (how would we ever learn anything knew?). Being able to figure out what is going on is a real learnt skill - and I understand that too.

          Annoying problem? sure (I'd be annoyed too). But pining for the "Good Old Days (tm)" and forgetting that there nightmares there too is a little on the nose.

          Comment


          • Originally posted by oiaohm View Post

            Those timeouts that systemd does on shutdown is not a defect in systemd.

            The cause of why systemd does timeouts on shutdown and service stop/restart is that it detects due to cgroups that processes are still running. So systemd runs the stop command on a service on shutdown then checks if all processes owning to that service have in fact stopped if not it waits after X amount time it brute force kills it.
            ..

            Systemd timeout messages on shutdown are just symptom of non systemd defects. Yes defects that sysvinit would silent hide until the day it catches you where you end up reboot a server instead of just restarting a service because a service will not restart.

            Yes these messes is why I say systemd is the init system we had to have. One of the results of systemd was a lot of sysvinit scripts in fact got fixed or deprecated with a systemd unit file that is also fixed.
            Diagnose done, after administering the cure and all the problems fixed, we can then happily ditch 1,2M loc diagnostic software? :P
            Just kidding.

            I am not going to try further autopsy on the topic. Just happy to be in non-Linux camp.

            Comment


            • Originally posted by aht0 View Post
              Diagnose done, after administering the cure and all the problems fixed, we can then happily ditch 1,2M loc diagnostic software? :P
              Just kidding.

              I am not going to try further autopsy on the topic. Just happy to be in non-Linux camp.
              LOL this is such a joke of answer. Process leak issues with background services effects OS X, Windows, BSD, Linux ...

              Unless you are using SMF from Solaris or Systemd init at this stage you are lacking the tools to deal detect the defect.

              Really we cannot ever 100 percent ditch the diagnostic software. With cgroup and pidfile stuff fixed up items like openrc could be built and have the required diagnostics to detect this issues early.

              Also the 1.2 million lines of code in systemd is way smaller than freebsd min selfhost. If you are suggesting BSD as option you are a hypocrite because it has a large block of diagnostic software..

              This is the laugh this is the hard reality of systemd its find issues that have been silent faults in background that random-ally hit people. Systemd is also working on the frameworks required to address these silent faults.

              aht0 serous-ally look closely at your current solution how would you find a process leak event and know you are going to need to fix it. Under freebsd you will have to put services in jails to find out. Out the box you will not be informed you have a problem.

              So since aht0 is happy to live with random hard to diagnose problems I cannot stop him/her from being that foolish.

              Comment


              • and here was me thinking this thread would not deliver fireworks since hreindl got banned

                Comment


                • Originally posted by grumbert View Post
                  and here was me thinking this thread would not deliver fireworks since hreindl got banned
                  It's a thread about systemd. That's all that I should have to say.

                  Comment


                  • Originally posted by Raka555 View Post
                    In the "old days" linux was for power users only - People that understood or wanted to understand how things work.
                    Linux was very user friendly, but it was picky about it's users.

                    Then came the drive to bring linux to the masses.
                    Slowly but surely they took away the character of what was "linux" to make it more "windowsy", so that people with limited capacity can still feel at home.
                    The current state of "Linux" is a bunch of bloated applications trying to mimic windows.

                    Systemd is just another (albeit huge) step towards taking control away from power users.
                    If you like systemd you are not a power user, you are just someone who wants a free OS.

                    Sadly the power users have to start looking elsewhere.
                    I recommend they look at "Alpine linux" and "Void linux"
                    I won't even recommend Devuan since its based on Debian, who has lost its way.

                    The world urgently needs a new OS.
                    I suspect that if that OS ever sees the light, it will be written in zig.

                    The beauty of Linux are all the flavours avaliable to us!
                    That's the true spirit.
                    More flavours mean more choice, and that is always good.

                    Comment


                    • Originally posted by oiaohm View Post
                      LOL this is such a joke of answer. (a)Process leak issues with background services effects OS X, Windows, BSD, Linux ...
                      Unless you are using SMF from Solaris or Systemd init at this stage you are lacking the tools to deal detect the defect.
                      Really we cannot ever 100 percent ditch the diagnostic software. With (b)cgroup and pidfile stuff fixed up items like openrc could be built and have the required diagnostics to detect this issues early.
                      (a)Hold your horses for a second! You are basing this claim on what precisely? Have you actually tested it against OS X, Windows XP - 10 RS5, all 4 BSD's, Solaris..? Or it's just an extrapolation based on what init/service manager any of the OS'es in question happens to have. In latter case, it's speculative. Fact that Linux happens to have particular issue does definitely not mean everything else has. None of OSes in question has any historic relation to Linux nor share any relevant code historically.

                      (b)Cgroup is purely Linux-specific implementation. None of the others share this particular way of managing resources.

                      Originally posted by oiaohm View Post
                      (a)Also the 1.2 million lines of code in systemd is way smaller than freebsd min selfhost. If you are suggesting BSD as option you are a hypocrite because (b)it has a large block of diagnostic software..
                      You know, replace your term "self-host" with a "core system". More easily understandable and it's more fitting. You won't see FreeBSD in "pieces" anyway.

                      (a) Are you very sure in your claim? Because there's drastic difference to "FreeBSD installed by default" and "FreeBSD updated by compiling". I'll explain, it's bit lengthy but nothing to do about it..
                      -RELEASE is updated by binary packages - lots like your average Linux distro. What components are included by FreeBSD team you'll get.
                      -STABLE is something like rolling release but wholly compiled. You'd pull in latest code revision, build new world and kernel, do mergemaster -Ui, reboot and voila, upgrade done. Trick is, based on what's written in your /etc/src.conf - your system build may exclude lots of core system components you deem unnecessary.

                      https://www.freebsd.org/cgi/man.cgi?query=src.conf shows you possible options for building upgrades. Based on this, I suspect, IF I wanted to build truly minimal FreeBSD core system, LOC ratio 'FreeBSD vs systemd' would take serious adjustment and not for latter's favor. Current FreeBSD standard install source loc should be around 10 million somewhere. IF I stripped out everything, leaving just FreeBSD kernel, libc and init, I am pretty sure, code base left would be smaller than systemd loc stand-alone

                      But, why are you comparing systemd (stand-alone) vs FreeBSD (complete OS) loc? systemd itself is not stand-alone. It, at minimum, needs kernel as well. And, oh boy, kernel is 25+m loc. Let's be fair. systemd+kernel vs freeBSD base install - latter's loc is almost three times less.

                      When we take comparison further, though it's pointless... lets compare Linux distro vs FreeBSD. Recent Debian distro installed is something like half a billion loc.

                      (b) Partially correct. It has. But are testing/debugging bits installed? Read what I wrote above. It's much like Gentoo or Arch. I can 'massage' the OS in au quite few ways. You don't have to guess what I run. Besides, excluding non-used components from core system reduces build time spent on system upgrades, there's incentive to exclude bits.


                      Originally posted by oiaohm View Post
                      This is the laugh this is the hard reality of systemd its find (a) issues that have been silent faults in background that random-ally hit people. Systemd is also working on the frameworks required to address these silent faults.
                      (a) Issues for Linux kernel, mind you. Which has been developed on it's own. You seem to think that almost all OSes have identical flaws hidden inside them and only systemd can find them..

                      Do you know that BSD pkill and Linux's pkill aren't even strictly same program? Share name, do similar thing, true but authors differ, code both are based on, differs.. All BSD's differ internally. Bold claims.


                      Originally posted by oiaohm View Post
                      aht0 serous-ally look closely at your current solution how would you find a process leak event and know you are going to need to fix it. Under freebsd you will have to put services in jails to find out. Out the box you will not be informed you have a problem.
                      First, I don't really think there is actually such an issue present. I tried searching information about it but came up blank. Just no information. Problem either does not exist, expresses itself extremely rarely && people never bothered writing about it.Kindly provide me with pointers, please.

                      Originally posted by oiaohm View Post
                      So since aht0 is happy to live with random hard to diagnose problems I cannot stop him/her from being that foolish.
                      IF I had problems, I'd look for alternatives
                      And FIY, I am ~40y male.
                      Last edited by aht0; 05-24-2019, 04:25 PM.

                      Comment

                      Working...
                      X