Announcement

Collapse
No announcement yet.

systemd 246-RC1 Released

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

  • #41
    Originally posted by trek View Post
    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.
    is it too hard to count the contents only of some folders inside the systemd project folder?

    Comment


    • #42
      Originally posted by k1e0x View Post
      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.
      No it isn't, as said by another guy above:
      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


      • #43
        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.
        OpenRC is the only other Init that has a feature set remotely comparable with Systemd. Everything else mentioned in that post is extremely simple and will have issues if outside basic desktop or embedded usecases.

        Even OpenWrt's Procd (a very light systemd-like init) has more intelligence and features than runit.

        Comment


        • #44
          Originally posted by k1e0x View Post
          And I agree isn't not all bad. Things like automotive applications, I want something like systemd there.
          Systemd does not add anything of value in automotive (if by "automotive" we mean actual car control and not infotainment system).

          I'd rather see VXWorks or similar realtime OSes in a car, just because they keep the development straight and has no risk of turning into a massive clusterfuck where everything is run on the same CPU and the same OS, car control and infotainment and internet access

          Comment


          • #45
            Originally posted by starshipeleven View Post
            is it too hard to count the contents only of some folders inside the systemd project folder?
            if you could do it, you would have already written the numbers.

            Comment


            • #46
              Originally posted by trek View Post
              if you could do it, you would have already written the numbers.
              you shell script lovers should know better than me how to use wc to count lines in text files.

              Comment


              • #47
                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.
                Well,
                I do understand that at least some fields of a datastructure( or a lot of them ), are made in utf8, because the Idea is to be read later by humans( i think everybody understands that.. )
                What you don't understand is that the systemd Journal, uses structures to hold this data, and the problem lies there..
                The Idea of it working like a database, seems nice( in principle, but only if they run ok ), but when that structures get corrupted, you are out of luck

                When you are writing logs in its pure format as text, the most "indivisible object" is a char, so even if you get corruption, you are still able to see the logs with that char corrupted only.( as the files are text based.. ).

                Comment


                • #48
                  Originally posted by tuxd3v View Post

                  Well,
                  I do understand that at least some fields of a datastructure( or a lot of them ), are made in utf8, because the Idea is to be read later by humans( i think everybody understands that.. )
                  What you don't understand is that the systemd Journal, uses structures to hold this data, and the problem lies there..
                  The Idea of it working like a database, seems nice( in principle, but only if they run ok ), but when that structures get corrupted, you are out of luck

                  When you are writing logs in its pure format as text, the most "indivisible object" is a char, so even if you get corruption, you are still able to see the logs with that char corrupted only.( as the files are text based.. ).
                  You do understand very little. You have structure even in a text based format, those are field and length delimiters, if you lose those you lose structure.
                  The journal from systemd has text, and even if you remove all binary structures you can restore alot if that.
                  A corruption is actually easier to fix, as index is stored as well. So you have your structure boundaries, entries are packed together, the possibility to infer alot missing information because it has more structure (and redundant one) than your puny little char delimiters.

                  If you want extra fault tolerancy, you would use error correcting polynomial codes. Your education does not have to stop at using text editors.

                  Comment


                  • #49
                    Originally posted by starshipeleven View Post
                    No it isn't, as said by another guy above:
                    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.
                    You know instead of arguing with me, why don't you try it yourself.

                    Scribble some random data on these files a few times..

                    dd if=/dev/urandom of=/var/log/journal/uid/user-1000.journal seek=$RANDOM count=1
                    dd if=/dev/urandom of=/var/log/journal/uid/system.journal seek=$RANDOM count=1
                    dd if=/dev/urandom of=/var/log/syslog seek=$RANDOM count=1

                    And you tell me what one you can read.

                    Comment


                    • #50
                      Originally posted by discordian View Post
                      You do understand very little. You have structure even in a text based format, those are field and length delimiters, if you lose those you lose structure.
                      No you don't have structures..
                      You have a fictional "indexation" on the time you write or read from the file as it is "like an array", you can seek, jump n chars and do a lot of stuff with that( usually you just write in the end of the file..append ), and they are all primitive C types, the most "indivisible part" is a char..

                      It's not a object structure like in the case of systemd journal, which is not a primitive C type but instead real structs created for that matter, with a pre-structured size and list of fields, ofcourse some content( of some fields ) is char based,( because its what Humans reads), but the other content is binary, and if it corrupts, good luck with that..

                      Comment

                      Working...
                      X