this post was submitted on 23 Sep 2024
766 points (95.5% liked)

linuxmemes

21378 readers
1297 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
  •  

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.

    founded 1 year ago
    MODERATORS
    766
    submitted 2 months ago* (last edited 2 months ago) by renzev@lemmy.world to c/linuxmemes@lemmy.world
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] msage@programming.dev 31 points 2 months ago (4 children)

    I will take OpenRC to my grave

    [–] renzev@lemmy.world 16 points 2 months ago

    I'm more of a runit guy, but I started using Alpine recently, and I have to say, openrc is also pretty nice!

    [–] possiblylinux127@lemmy.zip 8 points 2 months ago* (last edited 2 months ago) (2 children)

    Unit files, sockets and systemctl

    Stop it Patrick, you're scaring him!

    [–] msage@programming.dev 15 points 2 months ago (2 children)

    What "scares" me the most is the journal... for some reason it takes too long to get specific unit logs, and should anything break down in it, there is no way for me to fix it. Like logging has been solved forever, and I prefer specific unit logs to the abomination of journalctl.

    But like unit files are everywhere, and systemctl at its core is a nice cmd utility.

    [–] possiblylinux127@lemmy.zip 5 points 2 months ago (2 children)

    The thing with journalctl is that it is a database. Thus means that searching and finding things can be fast and easy in high complexity cases but it can also stall in cases with very high resource usage.

    [–] jj4211@lemmy.world 9 points 2 months ago (1 children)

    Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the 'fanciness'. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an 'old fashioned' way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.

    [–] possiblylinux127@lemmy.zip -2 points 2 months ago (2 children)

    Plain text is slow and cumbersome for large amounts of logs. It would of had a decent performance penalty for little value add.

    If you like text you can pipe journalctl

    [–] msage@programming.dev 3 points 2 months ago (1 children)

    But if journalctl is slow, piping is not helping.

    We have only one week of very sparse logs in it, yet it takes several seconds... greping tens of gigabytes of logs can be sometimes faster. That is insane.

    [–] possiblylinux127@lemmy.zip 2 points 2 months ago

    Strange

    Probably worth asking on a technical

    [–] jj4211@lemmy.world 1 points 1 month ago

    As I said, I've dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it's easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.

    [–] msage@programming.dev 3 points 2 months ago

    But why?

    I just can't grasp why such elementary things need to be so fancied up.

    It's not like we don't have databases and use them for relevant data. But this isn't it.

    And databases with hundreds of milions of rows are faster than journalctl (in my experience on the same hardware).

    [–] SynopsisTantilize@lemm.ee 2 points 2 months ago

    Just like windows even log

    [–] m4m4m4m4@lemmy.world 2 points 2 months ago

    What scared me about it is this kind of shit.

    [–] weker01@sh.itjust.works 4 points 2 months ago (1 children)

    science progresses one funeral at a time

    Planck's principle

    [–] msage@programming.dev 3 points 2 months ago

    There is nothing scientific about systemd

    [–] mogoh@lemmy.ml 2 points 2 months ago