Announcement

Collapse
No announcement yet.

systemd 246-RC1 Released

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

  • #31
    Originally posted by tuxd3v View Post

    Encoding is the first thing that you look into when you are designing a protocol, for example, to transmit data, and its not by chance, but by necessity.

    What makes me wondering is why you can't see it?
    When you write systemd logs or any information to a file, in binary format you right structures or objects( in this case, log objects, with a certain pre-accorded protocol ), and those objects have certain characteristics..
    It's clear you don't understand that most entry fields are in UTF-8, which is basic text, and that the journal is not structured in such an imagined way that results in any corruption leaving all data unrecoverable. "Binary format" is not some boogeyman. You're ultimately responding with "it's the truth" because you have no actual evidence to show that it is more vulnerable to corruption.

    Comment


    • #32
      Originally posted by Space Heater View Post
      It's clear you don't understand that most entry fields are in UTF-8, which is basic text, and that the journal is not structured in such an imagined way that results in any corruption leaving all data unrecoverable. "Binary format" is not some boogeyman. You're ultimately responding with "it's the truth" because you have no actual evidence to show that it is more vulnerable to corruption.
      And what about it causing that system not to boot? Want to talk about that? System design is pretty busted when the logger can prevent a system from booting.

      Comment


      • #33
        Originally posted by k1e0x View Post
        And what about it causing that system not to boot? Want to talk about that? System design is pretty busted when the logger can prevent a system from booting.
        I agree that isn't good, it's not as if I'm defending all design aspects of systemd.

        Comment


        • #34
          Originally posted by Space Heater View Post

          I agree that isn't good, it's not as if I'm defending all design aspects of systemd.
          And I agree isn't not all bad. Things like automotive applications, I want something like systemd there. The problem a lot of times is the focus and choice, I would rather a lot more of it be optional or "just an init" really. There are times when it isn't a good fit or causes complications.

          I think there is just too much pro/anti culture around it and it causes the developers not to listen to critics or write them off as haters. It doesn't help when the project just casts you off by saying "we don't care about your use case".. because if that is the case, people will go out and find other solutions.
          Last edited by k1e0x; 09 July 2020, 05:58 PM.

          Comment


          • #35
            Originally posted by k1e0x View Post
            OpenRC at 33.7k lines can do:
            • Portable between Linux, TrueOS, FreeBSD, and NetBSD
            • Parallel service startup (Off by default)
            • Dependency based boot-up
            • Process segregation through cgroups
            • Per-service resource limits (ulimit)
            • Separation of code and configuration (init.d / conf.d)
            • Extensible startup scripts
            • Stateful init scripts (is it started already?)
            • Complex init scripts to start multiple components (Samba (smbd and nmbd), NFS (nfsd, portmap, etc.))
            • Automatic dependency calculation and service ordering
            • Modular architecture and separation of optional components (Cron, syslog)
            • Expressive and flexible network handling (including VPN, bridges, etc.)

            It isn't feature light. It can do all the state tracking, restarting, cgroup, limiting stuff systemd can. It doesn't have a DNS server in it though.. you know.. because you need that.
            Based on andyprough's numbers, OpenRC seems pretty bloated compared to runit. Shouldn't you advocate using it instead? I heard runit has great parallel service startup, stateful init scripts, and dependency management.

            Comment


            • #36
              Originally posted by caligula View Post

              Based on andyprough's numbers, OpenRC seems pretty bloated compared to runit. Shouldn't you advocate using it instead? I heard runit has great parallel service startup, stateful init scripts, and dependency management.
              Pure bloat. One implementation of a busybox init I saw had 1396 lines of code. I think the holy grail of minimalist init systems would be under 1000 lines.

              Comment


              • #37
                Originally posted by rtfazeberdee View Post
                The systemd count - is that just systemd, journald and udev or is it those 3 plus the rest of the project that is optional?
                You should also add syslog/rsyslog, udev (or replacement) to the others to get a better comparison to the systemd/journald/udev bundle. You have to compare apples with apples.
                It would be nice to know the actual lines of code count when using only the non-optional components of systemd. The fact that it's not so easy to know is part of the problem, in my opinion.

                Comment


                • #38
                  Originally posted by tuxd3v View Post

                  Encoding is the first thing that you look into when you are designing a protocol, for example, to transmit data, and its not by chance, but by necessity.

                  What makes me wondering is why you can't see it?
                  When you write systemd logs or any information to a file, in binary format you right structures or objects( in this case, log objects, with a certain pre-accorded protocol ), and those objects have certain characteristics..

                  Obviously if corruption occurs you are unable to retrieve those objects, since they are corrupt, after that point doesn't matter what those objects hold inside..since you can't get them back( as they are not the original information written..).

                  Maybe you can' t see it, but its the plain truth..
                  Text files use a simple encoding system, that is very efficient, and they are not object structures..

                  This problem( while very rare in Aix, thanks god.. ) sometimes happens with the ODM database,
                  And I can tell you that is a PITA to get your configuration back, correctly.
                  I missed this before but this is exactly right. Good post. it's a strong reason why servers really should use text format for log.. I know having all the fancy object structures is cool but things can go spectacularly wrong in the datacenter and when you HAVE to know why it's important to have this. Can we have it optional? Please?

                  I sometimes think dev's need to hang out with sysadmins more because they will hear stories that start like "We were running auto-vacuum on postgress ..." and end like ".. and then it caught fire."
                  Last edited by k1e0x; 09 July 2020, 08:04 PM.

                  Comment


                  • #39
                    Stop feeding the trolls, you're giving them the attention they're craving for.

                    Comment


                    • #40
                      Originally posted by k1e0x View Post
                      Systemd also needs syslog because alone it can't log to plain text and that is unacceptable
                      To the contrary of sysvinit that instead... still needs syslog.

                      Sysadmins do not like proprietary log formats.
                      systemd log format isn't proprietary.

                      Comment

                      Working...
                      X